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

[Rich Felker]

On Wed, Apr 19, 2006 at 10:53:30PM -0700, Walter Belhaven wrote:
> --- Rich Felker <dalias at aerifal.cx> wrote:
> 
> > It's impossible for frame N to have TFF set unless frame N-1 ended
> > on the bottom field (i.e. also had TFF=1, RFF=0 or TFF=0,
> > RFF=1). This is not an arbitrary restriction, it's simply a fact of
> > interlaced video.
> 
> Agreed.  What I failed to realize is that, in addition to the above,
> softpulldown enforces Top Field First, which makes its state machine
> vastly simpler than if it didn't.  Turns out that TFF is *exactly*
> what I want (I'm transcoding for NTSC interlaced DVD, after all), and
> so, you're correct that softpulldown will work in my application.
> 
> HOWEVER ... I still have a couple of comments and concerns.
> 
> First, I have to completely disable mencoder's A/V sync algorithm in
> order to prevent the audio and video from diverging massively.  (I
> used "-noskip -mc 0" for that.)  Luckily, my source was well behaved
> enough that this didn't cause any harm.  Sure wish there was a way to
> "undo" the calculation that *R*FF normally does in the timing code, so
> that I don't have to disable A/V sync entirely.  Perhaps this is what
> you meant by "The core issue is that mencoder does not do what you
> want." :)

Well that's a small part of it but yes...
BTW I wonder if ffmpeg could better do what you want..

> Second, there are a couple of things about the implementation of
> softpulldown which seem odd.  First is the "Thou Shalt not pass mpi
> as-is" rule which it (sometimes) violates.  But also, when you ask
> vf_get_image() for an image of type MP_IMGTYPE_STATIC, are you
> *guaranteed* that it will pass you the same chunk of memory each time?

Yes, this is what static means. It's probably a stupid design but it's
how it works. Unless I misunderstood what you asked.

Rich