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

[Corey Hickey]

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". :)

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.

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

-Corey