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

[Uoti Urpala]

On Fri, 2006-06-23 at 16:12 +0200, Michael Niedermayer wrote:
> ok, ill explain it again, the frames MUST be added as the next filter NEEDS
> them its not possible to not generate them
> again as i said the example is yadif (doubles frames), mcdeint (uses all
> frames for motion estimation and compensation ) and framestep to discard
> every second frame again

Your original commit message for framestep mentioned no other filters,
then your next example was "fixes yadif=3,framestep=2 and
tfields=1:1,framestep=2 and others". This is the first time you mention
mcdeint in the chain. For this use I think the best special-case fix
would be an option to remove the flip event generation from the filters,
you could then form the filter chain in such a way that one output frame
reaches the vo for each input frame, and that can then be flipped
normally from the main loop.

> you could of coarse not generate any flip is any filter ever but that also
> would make the half working double framerate filters non working, IMHO
> theres no advantage in doing this until we have a better solution in place

An option for the 2 special filters would be better than adding a
general filter chain vo flip mechanism that is only useful for a special
case.

> btw, in what case exactly does the "not even a dirty solution" break
> something which was working before it?

It doesn't break anything AFAIK. However it's not a solution for adding
frames in filters, and a special-case hack for a particular filter chain
would be better done in the problematic filters rather than adding a
"general" mechanism that is in fact not generally useful.