[MPlayer-dev-eng] [patch][rfc] screenshot. Aspect Ratio, problems

[Oded Shimon]

On Fri, Aug 26, 2005 at 06:24:02PM +0100, ObsessiveMathsFreak wrote:
> >Message: 5
> >Date: Fri, 26 Aug 2005 02:10:42 -0400
> >From: Rich Felker <dalias at aerifal.cx>
> >
> >It will just make playback incredibly slow.. Otherwise no problem.
> >Just use -vf scale,screenshot -zoom
> 
> This worked perfectly, also with the vo_png filter. I get it now. I 
> think. Software scaling vs Hardware scaling or at least internal mplayer 
> scaling vs scaling on output. I know nauzing.
> 
> For some reason the filter needs to be wrapped around two scale filters 
> like so
> -vf scale,screenshot,scale
> 
> I have no idea why.
> 
> >Message: 3
> >Date: Fri, 26 Aug 2005 13:49:40 +0300
> >From: Jan Knutar <jknutar at nic.fi>
> >
> >Now a cool thing, which would also open up the doors for many other neat 
> >features
> >at the same time, would be if MPlayer could reconfigure the vf filter 
> >pipeline in
> >realtime, to insert scale,screenshot,scale only when needed.
> >Even crazier, to have the frame-exact seek ability, so that one could do 
> >away with
> >the one-frame latency for taking screenshots too :-) But then it'd 
> >probably end up
> >being as slow as xine :(
> >
> >Those two combined would require some major surgery to mplayer.c's main, 
> >the
> >only person crazy enough to touch main(){} is Oded but we've so far been 
> >unsuccessful
> >in forcing him to do it :)
> >Maybe surgery is the wrong word, rewrite perhaps... It's all probably in 
> >the TODO/WISHLIST
> >too...
> 
> 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...

> This of course inserted the screenshot filter, but did not remove it 
> after the screenshot was taken. I'm just wondering could this be done 
> with a quick hack by getting the vf_screenshot filter to have its own 
> pointer point to its 'next' filter pointer and then 'deallocating' the 
> filter? Or could we be talking a serious internal train wreck here?
> 
> Ideally if there was a method to remove a filter, which could be called 
> from within the filter itself. Search me. I just work here. Or rather, I 
> don't.

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.

- ods15