[MPlayer-dev-eng] Need help with A/V sync in new video filter

[Rich Felker]

On Sat, Apr 15, 2006 at 10:57:13AM -0700, Walter Belhaven wrote:
> Hi,
> 
> I'm trying to implement a filter that 'unpacks' mpg2 frames that have
> their Repeat_First_Field flag set.  Here's an example from an actual
> HD 1080i broadcast (INPUT) and how I'd like to transform it (OUTPUT):
> 
>       INPUT     |            OUTPUT
>   Frame TFF RFF | Frame TFF RFF  (input fields)
>   --------------+-----------------------------------
>     1    1   0  |   1    1   0   (top=1, bot=1)
>   --------------+-----------------------------------
>     2    1   1  |   2    1   0   (top=2, bot=2)
>   --------------+-----------------------------------
>     3    0   0  |   3    1   0   (top=2, bot=3)
>   --------------+-----------------------------------
>     4    0   1  |   4    1   0   (top=3, bot=4)
>                 |   5    1   0   (top=4, bot=4)       <-- "extra"
>   --------------+-----------------------------------
>     5    1   0  |   6    1   0   (top=5, bot=5)
> 
> Note the consistent TFF=1 and RFF=0 of the output pattern.  The
> reasons I need this are related to transcoding 1080i "video" (~60
> unique fields per second) to NTSC DVD, without deinterlacing, pullup,
> or anything else of the sort, and without having to fight seemingly
> mysterious "field order changes" in the interlaced result.
> 
> The closest thing I can find to what I want is '-vf softpulldown', but
> unlike that filter, I want mine to handle ALL cases of the RFF flag,
> not just the "special case" of the "proper" 3:2 soft-telecine pattern.
> (Softpulldown complains with lots of "Unexpected field flags" when
> analyzing my 1080i source, and doesn't do what I want when it
> encounters those 'unexpected' flags.)

I think you misunderstand the issues involved. I may be mistaken but
I'm pretty sure softpulldown allows any sequence as long as the
sequence is valid.

What you're trying to do does not look valid. Why are you trying to
add/remove fields? The repetition pattern in the original stream
should just be used as-is.

> First, the Video Filter section in tech/libmpcodecs.txt says, in
> effect, thou shalt not pass mpi down the chain as-is, even if you
> don't modify it.  Is this still considered appropriate advice?  I

Yes, this is absolute.

> found a handful of cases where implementors have ignored that, such as
> in the very softpulldown I mentioned.  If my filter is going to pass a
> PARTICULAR Frame as-is, can I just pass 'mpi' along?  What if I'm just
> changing one of the bits in mpi->fields?  Or in both cases (no change
> or just a flag change) should I really do this:

Yes you must use EXPORT type.

> Second, as the example above illustrates, my filter will generally
> output more Frames than it receives, and this has the potential of
> messing up the a/v sync algorithm.  In fact, I *think* my prototype is

Yes, it will mess it up. I'm still completely confused about why you
want to do this.. Just pass the original TFF/RFF flags to the encoder!

Rich