[MEncoder-users] Assertion `picture_number<rcc->num_entries' failed.

[Corey Hickey]

Dominique Dumont wrote:
> Corey Hickey <bugfood-ml at fatooh.org> writes:
> 
>> Dominique Dumont wrote:
>>> Corey Hickey <bugfood-ml at fatooh.org> writes:
>>>
>>>> That's odd. Go ahead and upgrade to latest svn mplayer (see instructions
>>>> on the download page). If that doesn't fix the problem, upload the
>>>> source file (or a reproducible portion) to:
>>>> ftp://ftp.mplayerhq.hu/MPlayer/incoming
>>>>
>>>> ...and tell us what you named the file.
>>> I've uploaded lavc_pict_nb_rcc_num_entries_pb.mpg (17MB). This file is
>>> a replex'ed version of the original vdr file.
>>>
>>> This file triggers the following error during the 2nd pass:
>>> mencoder: ratecontrol.c:676: ff_rate_estimate_qscale: Assertion `picture_number<rcc->num_entries' failed.
>>>
>>> With the command:
>>> nice mencoder 'lavc_pict_nb_rcc_num_entries_pb.mpg' -oac mp3lame -lameopts preset=120 -vf pp=ci,crop=688:544 -ovc lavc -lavcopts vcodec=mpeg4:v4mv:vbitrate=1000:mbd=2:trell:vpass=2 -o 'test.avi'
>> I can't reproduce it. You didn't give a first pass command line, 
> 
> Sorry about that.
> 
>> so I assume it's the same but with vpass=1.
> 
> Almost the same except that I use -oac copy in the first pass:
> 
> mencoder 'lavc_pict_nb_rcc_num_entries_pb.mpg' -oac copy -vf pp=ci,crop=688:544 \
>   -ovc lavc -lavcopts vcodec=mpeg4:v4mv:vbitrate=1000:mbd=2:trell:vpass=1 \
>   -o 't_lavc_pict_nb_rcc_num_entries_pb.avi'
> 
> And the second pass is
> 
> mencoder 'lavc_pict_nb_rcc_num_entries_pb.mpg' -oac mp3lame -lameopts preset=120 \
>   -vf pp=ci,crop=688:544 \
>   -ovc lavc -lavcopts vcodec=mpeg4:v4mv:vbitrate=1000:mbd=2:trell:vpass=2 \
>   -o 't_lavc_pict_nb_rcc_num_entries_pb.avi'
> 
>> This line works fine for me:
>>
>> for i in 1 2 ; do
>>   mencoder 'lavc_pict_nb_rcc_num_entries_pb.mpg' -oac mp3lame \
>>   -lameopts preset=120 -vf pp=ci,crop=688:544 -ovc lavc -lavcopts \
>>   vcodec=mpeg4:v4mv:vbitrate=1000:mbd=2:trell:vpass=$i -o 'test.avi'
>> done
> 
> Err, this line works also for me. :-o
> 
> I guess that using '-oac copy' in the first pass is not a good idea. :-(

Ah. The reason this is happening, I _think_, is that using mp3lame for 
the second pass changes the A-V syncronization relative to what happened 
in the first pass. I don't think this should happen, but mencoder's 
mp3lame output is known to have some audio delay issues. As a result, 
mencoder skips or duplicates frames differently. Lavc doesn't know about 
what frames have been skipped/duplicated -- it just encodes the frames 
it gets in the order it gets them. So, when lavc receives different 
frames on the second pass, the ratecontrol gets messed up.

I'm surprised I haven't heard of this problem before. Maybe somebody 
reported it and I wasn't paying attention. On the other hand, I suspect 
that it might not happen all the time. With different videos, the 
skipped/duplicated frame differences might be minimal enough to stay 
within lavc's ratecontrol tolerance. Interestingly, your example works 
fine for me in 64-bit mode but failes in 32-bit.

There are two easy ways you can work around this issue:

1. Use -oac mp3lame for both passes.

2. Encode audio and video separately. Something like:
    a. mkfifo audiodump.wav
    b. lame audiodump.wav ...
    (in another terminal)
    c. mplayer input.avi -ao pcm:fast -vc null -vo null
    d. mencoder input.avi -nosound -ovc lavc -lavcopts vpass=1 ...
    e. mencoder input.avi -oac copy -audiofile audiodump.mp3 -ovc lavc 
-lavcopts vpass=2 ...


-Corey