[MPlayer-users] [BUG] mencoder -vf softpulldown -oac mp3lame ==> audio corruption?

[D Richard Felker III]

On Sun, Oct 26, 2003 at 01:26:30AM -0800, Corey Hickey wrote:
> [Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]
> Hi,
> 
> I seem to have run into an odd bug wherein using -vf softpulldown seems
> to cause bad audio distortion for mencoder, with this message:
> 
> Too many video packets in the buffer: (4096 in 8274071 bytes).
> Maybe you are playing a non-interleaved stream/file or the codec failed?
> For AVI files, try to force non-interleaved mode with the -ni option.
> ds_fill_buffer: EOF reached (stream: audio)
> 
> [--full logs uploaded--]

You you sure? The logs seem to lack -v...

> If I encode the audio to mp3lame, the sound gets distorted at 72
> seconds, and then gets completely bad at 82 seconds. If I use -oac copy,
> the audio sounds fine but the encoded video looks like it "jumps
> backward" a frame every couple seconds.
> 
> Normally, I would have just thought I ripped the disk poorly, clean it
> off, and try again, but mplayer can play the troublesome section without
> a problem, even with -vf softpulldown.

A couple comments...

Framerate-increasing filters are _not_ supported in mplayer/mencoder
g1. They're huge hacks! Note that the movie is only 82 seconds long,
but when encoding with your options, you end up with 92 seconds of
output! The problem is that softpulldown has no way to tell mencoder
that it's output 2 frames, so a/v sync drifts off to hell until the
demuxer buffers overflow.

If you use -vf softpulldown,ivtc=1 then it works fine.

> ===================================================
> Now, before anybody reminds me that encoding right after using
> softpulldown is a bad idea, I know that. :) These are just simplified
> test cases.

No, they're really not. Encoding like this will inherently fail. If
you're really having problems with this file you should give a valid
command line. :)

Rich