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

[D Richard Felker III]

On Sun, Sep 14, 2003 at 11:19:05AM -0700, Corey Hickey wrote:
> [Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]

> D Richard Felker III wrote:
> >
> >If your image size if WxH, each field has a height of H/2, which in
> >turn means the chroma height of a field is H/4.
> >
> >Rich
> >
> 
> Oops, I didn't mean to say field, I meant something else and I was mixed
> up. Yesterday was rather hot and my brain was overheating. :)
> 
> 
> Anyway, I just ran into another segfault with pullup. I tried running
> pullup before crop, to see how that went, and on several DVDs I tried,
> the encoding segfaulted right after the message:
> 
> Could not get buffer from pullup!
> 
> To make it not fail, I can either remove the -ofps 23.976 or insert
> crop=704:480:6:0 before pullup. I know that cropping beforehand is the
> correct thing to do here, regardless, but I figured you might be
> interested in a bugreport anyway.

...

> [FAILS]
> mencoder pullup-buffer-segfault.vob -vf pullup -ovc lavc -lavcopts \
> vcodec=mpeg4 -oac copy -ofps 23.976
> 
> [WORKS]
> mencoder pullup-buffer-segfault.vob -vf crop=704:480:6:0:pullup -ovc \
> lavc -lavcopts vcodec=mpeg4 -oac copy -ofps 23.976
> 
> [WORKS]
> mencoder pullup-buffer-segfault.vob -vf pullup -ovc lavc -lavcopts \
> vcodec=mpeg4 -oac copy

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:

When direct rendering from the codec to pullup is available (this
should be available with crop too, so I'm not sure why it doesn't
segfault there), the codec requests a buffer from pullup to render
into, but then it never 'displays' that buffer. So pullup has no way
of knowing whether that frame was dropped, or whether it's a P frame
with a bunch of B frames before it. Therefore it exhausts all the
buffers, and with nowhere else to render to, it crashes. :)

Solutions for the time being.... (choose one)

1) Don't use -ofps 23.976 with pullup. This will result in choppy
   video, since every 4th frame will be shown for twice the duration,
   but it does allow mixed 24/30 fps material.

2) Hack code into pullup to force input:output frame ratio to remain
   at 5:4 by dropping a frame when necessary. The downside is that
   this is ugly.

3) Fix mencoder to drop frames at the end of the filter chain rather
   than the beginning. The downside is that this is difficult.

4) Fix mencoder to support variable-fps output formats. The downside
   is that this is difficult.

5) Use ivtc or detc instead of pullup. The downside is that they're
   not as good at choosing the right fields to make progressive
   frames.

6) Write mencoder-g2. :))) Again, difficult. :)


Rich