[MPlayer-users] [BUG REPORT] - zero length frames in mencoder output

[Loren Merritt]

On Fri, 31 Dec 2004, D Richard Felker III wrote:
> On Thu, Dec 30, 2004 at 07:27:40PM +0100, bond wrote:
>
>> i tried encoding with x264 with a compile made from cvs on the 
>> 29/12/2004 (but the issue is also there with older builds)

The problem is not related to x264. It occurs with any -ovc.

>> "C:\path\mencoder.exe" -ss 00:00:00.400 -frames 100 -noskip -mc 0
>> -sws 9 -vf crop=720:416:0:82,scale=640:256,harddup -vfm ffmpeg 
>> "C:\path\source.vob" -ovc x264 -of avi -ffourcc VSSH -o mencoder.avi
>>
>> i extracted the output to raw h.264 streams with the avi2raw tool 
>> provided by the mpeg4ip project (available on sourceforge), latest cvs, 
>> which is according to the devs able to handle avc-in-avi.

BTW, if you want raw h.264 streams, you can use "-of raw". This should 
avoid the null frame issue, too (as long as you keep harddup).

>> While doing 
>> this the tool reported that there are "zero length frames" in different 
>> amounts depending on the used settings in the output and also the total 
>> amount of "correct" avc frame it was able to output
>> - also i noticed that mencoder reports about "1 duplicate frame(s)" 
>> during encoding, leading to one frame being too few in the output 
>> (independant of the zero length frames)
>
> solution: use the harddup filter at the end of your video filter
> chain. this will prevent there from being stupid 0-length frames.

He did use harddup.

There are two separate issues here:
Null frames during encoding, which mencoder reports ("1 duplicate 
frame(s)"). These are fixed by harddup.

And then there's null frames at the beginning (before any real frames). 
Mencoder does not report these. These are not fixed by harddup.
Based on limited testing, I think these appear only when the source video 
contains B-frames.

--Loren Merritt