[MPlayer-cvslog] r18780 - trunk/mplayer.c

[Uoti Urpala]

On Wed, 2006-06-21 at 23:43 +0200, Michael Niedermayer wrote:
> > I think this is wrong, even though it might not break anything now. At

> feel free to reverse and or implement it better, i simply dont understand
> the mplayer architecture well enough and dont have the time/motivation to
> RTFS the whole related code, which is IMHO quite alot of code

I could try to add support for inserting frames next (skipping them is
pretty easy). I'll need to look closer at the way the filter chain works
first though.

> > Does this even do anything useful with vf_framestep? There's already the
> 
> fixes yadif=3,framestep=2 and tfields=1:1,framestep=2 and others

OK so it doesn't do anything useful with framestep alone, but helps with
problems caused by filters that now add frames by invoking frameflip
internally. It doesn't work quite right in that case either though,
unless all the added frames are dropped their timing will be somewhat
arbitrary (the filters now invoke vo flip in the middle of running the
filter chain without any real timing). Unless you have further
objections I think I'll revert the mplayer.c and vf_framestep.c changes
and will try to implement proper support for adding frames later.