[MEncoder-users] [BUG] a-v sync problems with pullup, softskip (only on some DVDs)

[D Richard Felker III]

On Fri, Mar 18, 2005 at 11:17:49AM -0800, Corey Hickey wrote:
> D Richard Felker III wrote:
> >Duplicate frames occur when pullup outputs less than 24 fps, because
> >it can't find valid matches for some fields. See the verbose output:
> >
> >affinity: .0..1+.2+.3.+4.+5.
> >breaks:   .0..1.|2..3..4|.5.
> >duration: 1
> >
> >This indicates that pullup thinks the second field of the
> >2-field-duration frame there matches better with the FOLLOWING frame
> >than with its own partner, and so it refuses to output either one as a
> >frame. (The internal pullup engine outputs both fields as lone fields,
> >but the vf_pullup wrapper for mplayer drops these.) Notice that the
> >same thing is happening with field 5 after the duration-3 frame.
> >
> >The only reason the duration-3 frame looks so clean itself (breaks on
> >both sides and ideal affinity between fields) is that pullup FORCES
> >these attributes whenever it gets a perfect duplicate field due to
> >soft telecine. Until the first patch I made earlier, it didn't force
> >the affinities on the duration-3 frame, so even more fields were
> >getting dropped...
> >
> 
> I'm doing my best to understand what you're saying here, but I haven't 
> quite figured out how to interpret pullup's verbose output. Actually, I 
> understand your description of what pullup is doing but I can't relate 
> it to your example yet.
> 
> I suppose 0, 1, 2, 3, 4, and 5 are the fields pullup has in its buffer, 
> the + sign indicates whether the field matches the previous or following 
> field, and the breaks show which fields pullup thinks should be grouped 
> into frames. Am I correct? This is the first time I've really looked at 
> that output so I'm not really sure what to make of it.

Affinity (the + sign on one side of the field or the other) shows
which field this field "prefers" to be paired with, based on how close
the adjacent fields are to being what you would get if you
linear-interpolated the missing sister field from the current field.

Breaks (the | signs) are more complicated, and come from the
identification of duplicate fields. Basically, if you have a sequence
of 4 fields, 0-3, you can ask the question: does field 0 match field 2
significantly better (or resp. worse) than field 1 matches field 3? If
so, then we can conclude that field 0 and 2 (or resp. 1 and 3) might
be duplicate fields from the same original progressive frame. At the
very least, we decide that it would be a very bad idea to put field 2
and 3 (or resp. 0 and 1) together as a frame, so we put a "break"
marker between them that says "do not match these".

> If what I said above is correct, then I have a few more questions. If 
> I'm wrong above then the questions may be irrelevant or way off-base.
> 
> 1. Does mencoder print the line of frame details before or after it 
> prints the corresponding output from pullup? "After" would make sense to 
> me but I can't be sure.

Unfortunately it's hard to correlate them, because pullup has to
buffer 2 frames ahead. :(

> 2. What duration does "duration:" indicate?

The duration is how many fields are begin grouped as a frame for
output, starting at the beginning of the sequence of fields printed.
If duration is 1, vf_pullup will drop the field entirely since it
can't make a progressive frame and mplayer's filter layer does not
support framerate-increasing filters.

> 3. Why are there sometimes two blocks of pullup output for one "frame 
> details" line?

If vf_pullup gets a duration-1 output, it tries again to get a frame
from pullup. Otherwise the buffer would fill up more and more whenever
there's a duration-1 output and eventually overflow (thus the buffer
errors you were seeing). Actually there was a bug before.. if you have
a long (rff-flagged) input frame, vf_pullup was only trying twice if
it got duration=1, and it needed to try a third time to keep the
buffer from growing every time it happened.

> 4. For each input frame, which field numbers (in pullup's output) are 
> the fields that make up that frame? Or is the input pairing not really 
> relevant?

The input fields are added at the end of the field buffer. Depending
on how full the buffer is already, they can be 4 and 5 or 5 and 6,
IIRC.

> >It seems really difficult...something is EXTREMELY bogus about this
> >file. ivtc seems to handle it better, but both ivtc and detc have
> >problems with it as well. You might see if you have better luck with
> >filmdint..
> >
> 
> I'll check it out when I have some time later on.

I tried it and it worked really well.

> >My guess is that this DVD is badly mastered...that it was telecined
> >first, and then an inverse-telecine'ing mpeg2 encoder was used to make
> >it mostly into soft-telecine. Further, my guess is that it did a bad
> >job and got some of these sequences with only very small motion
> >out-of-sync.
> >
> 
> From what I've read these new Star Wars DVDs have been "digitally 
> restored". I don't know what that involved, but probably your guess is 
> correct.

LMAO. :) "Digitally restored" sounds like a euphemism for
content-alterred to add bad CG, change character (the famous scene
where Han Solo murders in cold blood that was changed), and do bogus
telecine... :(

If you want a proper encode of Star Wars, I would find the widescreen
laserdisc edition, a laserdisc player, and a very high quality analog
capture card. That's the only way I know to get a decent rip of the
original movies, short of renting the film cans and using your own
film-to-video hardware...

Anyway, hope all this info helps..

Rich