[MPlayer-dev-eng] patch: VFCTRL_RESET and vf_nailfps.c

[xiphmont at xiph.org]

On 11/7/07, Jan Knutar <jknutar at nic.fi> wrote:
>
> In the cases where I really wanted to use yuv4mpeg (like when I want to
> burn in ass subs) I've done it in several steps, first mencoder to
> "normalize" fps and av-sync

In that case, something is currently broken because mencoder is not
'normalizing' the sync-- no combination of fps, ofps, harddup,
softskip, framestep etc, were resulting in correct A/V sync when
attempting to to write intermediate files.  I tried several output
containers and all of the lossless codecs, just in case one specific
output was not working (although I suspect the battle was lost before
getting to the mux/output).

The files I'm trying to transcode either have dropped frames from
decode errors (it appears the in-tree wmv3 decoder isn't perfect yet)
or at random scene changes where three or four frames are just
missing.  One also has a 'slo mo' sequence that's actually
implementing the slow mo in the stream mux!  Mplayer could obviously
'see' the sync because these stay in sync when playing.  Mplayer,
however, currently has no means of imposing a fixed frame rate for any
output because it will only drop frames, not insert them, and no
current filter will either.  This is an issue for anything but
non-console playback as the vfr timestamps will be discarded.
Mencoder will add/drop frames to stay in sync, but does not appear to
be using the tps information from these WMV3 files.

Regardless, my *primary* use case is mplayer and yu4mpeg output, for
which this patch solves an actual problem.  If I was using mencoder,
it would only be as a hack, so I was not motivated to figure out what
mencoder was doing wrong.

Monty