[MPlayer-users] BUG: mencoder segvault with -vf pullup [partial bugreport]

[D Richard Felker III]

On Sun, Sep 14, 2003 at 10:37:32PM -0700, Corey Hickey wrote:
> [Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]
> D Richard Felker III wrote:
> 
> >RTFM. :) The man page says that pullup will not work with -ofps
> >23.976. The problem is that pullup doesn't have code to force dropping
> >at least one in every five frames (like detc and ivtc did) since it's
> >meant to gracefully handle and output mixed-fps material. Anyway, this
> >means that if it can't detect any pulldown pattern (e.g. during
> >stills) you'll get too many frames output.
> >
> >The correct way for an encoder to deal with this when writing
> >fixed-fps format like .avi is to drop frames at the very end of the
> >filter chain, right before encoding. But instead, mencoder drops the
> >frame after decoding, but before running the filter chain.
> >
> >Even in your command lines that "work", you're likely to get bogus
> >output, since pullup will not get a chance to see the dropped frames,
> >and thus will be working with limited information when trying to
> >figure out which fields go together. However, the first command fails
> >because of a design flaw in mplayer G1's buffer allocation:
> 
> Ok, that makes sense. IMHO the man page is a bit ambiguous with regard
> to the meaning of "having trouble". :)

OK, I'll add "(including sig11!)" to the man page or something. :)

> I figured I'd end up with erroneously dropped frames or something, but
> the test videos I've tried all seem to end up with the right frames in
> the right place. I haven't tried any 29.97fps progressive input (I knew
> that wouldn't work).
> 
> If I understand you correctly, are you saying that if I try to encode
> 29.97fps hard-telecined material with pullup and -ofps 23.976, then
> frames will be dropped before pullup has a chance to get at them? I
> tried doing just that, and mencoder never reports any skipped frames
> (would it say so?) and the resulting avi looked correct. Panning scenes,
> people walking, etc. look smooth and I never see any jumpy motion.

Well it's not as bad as it sounds, because pullup will give the right
input:output ratio (5:4) as long as telecine was performed cleanly and
it has motion to base its frame-making decisions on. So frames that
matter (usually) won't get dropped before pullup sees them. But during
a still, pullup has no way of 'seeing' the field duplication or
combing, and normally due to noise (quantization and other) it will
end up putting fields together the same way they were in the source
file for stills, since that will give the 'best match'. The one
problem you might have here is if mencoder decides to drop the first
frame after a still before passing it to pullup. I would expect that,
under most conditions, you won't get any bogus combed frames passing
through, but pullup will drop an extra field if it's missing the input
frame containing the sister field.

So, to summarize, it's more a problem of losing more frames than you
should around stills, rather than choppy motion. If this is ok with
you, it might work.

> I know I'm confused, and I'm trying to figure out what I'm confused
> about. :) Thanks for the help.

No problem.

Rich