[MPlayer-dev-eng] Re: MPlayer-dev-eng Digest, Vol 32, Issue 74
Jindrich Makovicka
makovick at kmlinux.fjfi.cvut.cz
Sat Aug 27 18:20:46 CEST 2005
ObsessiveMathsFreak wrote:
> I manged to get the screenshot function to dynamically insert the
> screenshot filter. As expected this did cause some kind of internal
> jostling. The output was affected, big black squares popped up
> everywhere. This didn't happen when playing DVD's though, so I suppose
> some kind of codec stuff is being jostled here.
>
> In any case, this doesn't seem to work. The screenshots taken are
> malformed, greyscales of the picture in triplicate. Problems arn't
> restricted to the screenshot filter. Dynamically inserting the scale
> filter seems to crash the player unconditionally!
>
>> I don't like the idea of dynamically messing with filter layer..
>> vf_screenshot should have absoloutely no overhead (about as much as
>> vf_harddup, i.e., none), it's only stupid and can't support
>> colorspaces and needs vf_scale, so that should be fixed. basically, i
>> think if we're really at it, we can just put vf_screenshot in vf_vo,
>> since there's no penalty in it.
>
>
> This would seem more rational as well, as a screenshot function in the
> 'filter' chain never really made much sense to begin with. Leastways,
> that was my way of thinking about it. Plus as you mention there was
> always that overhead slowing down every frame.
I have totally lost the track of what you actually want to achieve, but
would a screenshot filter having no cpu requirements when idle,
accepting all the colorspaces that vf_scale accepts and rescaling to a
correct aspect ratio please you?
--
Jindrich Makovicka
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vf_screenshot.c
Type: text/x-csrc
Size: 5047 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20050827/564a41a9/attachment.c>
More information about the MPlayer-dev-eng
mailing list