[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