[MPlayer-dev-eng] Re: MPlayer-dev-eng Digest, Vol 32, Issue 74

[ObsessiveMathsFreak]

> Message: 5
> Date: Fri, 26 Aug 2005 21:41:07 +0300
> From: Oded Shimon <ods15 at ods15.dyndns.org>
> Subject: Re: [MPlayer-dev-eng] [patch][rfc] screenshot. Aspect Ratio,
> 	problems

>>> I did try that using vf_add_before_vo in vf.c . It worked, sort of. 
>>> Turns out the filter would only be inserted if there was at least one 
>>> other filter in the chain for some reason.
> 
> 
> It's pretty obvious, isn't it?
> sh_video->vfilter was pointing directly at the vo, and when you added a 
> filter, it went before the vo, and vfilter kept pointing at the vo..
> if there's a filter, vfilter would point at it, and your new filter would 
> be added after it...

Yes that was the problem. I was lost in a maze of pointer references.

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.