[MPlayer-users] mencoder hang (when using mp3lame)

Alexander Roalter alex at roalter.it
Fri Sep 11 01:32:33 CEST 2015


On 11.03.2014 11:59, Alexander Roalter wrote:
> Am 05.03.2014 20:47, schrieb Alexander Roalter:
>
> Just to reiterate, if I use oac mp3lame, I get mencoder stuck at 100%,
> with the message
>
> [ac3 @ 0x7f020d3545c0]incomplete frame
> Pos:  11.2s    270f (100%)  0.00fps Trem:   0min   9mb  A-V:0.049 [6784:151]
>
> and 100% CPU load (on one CPU).
>
> using other oacs (pcm, lavc) works.
>
It’s a long time, and no change, so I decided to have a look myself.

in libmpcodecs/ae_lame.c, in encode_lame, the lines

if (!src)
    n = lame_encode_flush(lame, dest, max_size);
else

were inserted, which is (according to gdb) where mencoder stays when 
invoked. If I comment it out again, mencoder terminates, but I get



[ac3 @ 0x7ff2b2acf680]incomplete frame
Pos:  10.7s    259f (100%)  0.00fps Trem:   0min   8mb  A-V:0.055 [6721:151]
Audio data left in buffer at end of file. Probably bug in audio encoder, 
please report.Pos:  10.8s    260f (100%)  0.00fps Trem:   0min   8mb 
A-V:0.054 [6719:151]
Audio data left in buffer at end of file. Probably bug in audio encoder, 
please report.Pos:  10.8s    261f (100%)  0.00fps Trem:   0min   8mb 
A-V:0.053 [6725:151]
Audio data left in buffer at end of file. Probably bug in audio encoder, 
please report.Pos:  10.8s    262f (100%)  0.00fps Trem:   0min   8mb 
A-V:0.053 [6727:151]
Audio data left in buffer at end of file. Probably bug in audio encoder, 
please report.Pos:  10.9s    263f (100%)  0.00fps Trem:   0min   8mb 
A-V:0.052 [6736:151]
Audio data left in buffer at end of file. Probably bug in audio encoder, 
please report.Pos:  10.9s    264f (100%)  0.00fps Trem:   0min   9mb 
A-V:0.051 [6753:151]
Audio data left in buffer at end of file. Probably bug in audio encoder, 
please report.Pos:  11.0s    265f (100%)  0.00fps Trem:   0min   9mb 
A-V:0.051 [6756:151]
Audio data left in buffer at end of file. Probably bug in audio encoder, 
please report.Pos:  11.0s    266f (100%)  0.00fps Trem:   0min   9mb 
A-V:0.050 [6760:151]
Audio data left in buffer at end of file. Probably bug in audio encoder, 
please report.Pos:  11.0s    267f (100%)  0.00fps Trem:   0min   9mb 
A-V:0.050 [6760:151]
Audio data left in buffer at end of file. Probably bug in audio encoder, 
please report.Pos:  11.1s    268f (100%)  0.00fps Trem:   0min   9mb 
A-V:0.049 [6765:151]
Audio data left in buffer at end of file. Probably bug in audio encoder, 
please report.Pos:  11.1s    269f (100%)  0.00fps Trem:   0min   9mb 
A-V:0.049 [6784:151]
Audio data left in buffer at end of file. Probably bug in audio encoder, 
please report.Pos:  11.2s    270f (100%)  0.00fps Trem:   0min   9mb 
A-V:0.049 [6784:151]
Audio data left in buffer at end of file. Probably bug in audio encoder, 
please report.Writing index...


I simply invoke

mencoder test.avi -o t.avi -ovc copy -oac mp3lame

and get the endless loop at the end. My libmp3lame is 3.99.5
If I log that function, initially only lame_encode_buffer_interleaved is 
called, and returns values of 0 or some three-digit value. At the end, 
lame_encode_flush is called (i.e. src is now 0), but initially 1313 is 
returned, then always 208 is returned. I don’t get why flush is even 
called twice?

A quick fix that correctly terminates is inserting a static variable 
"flushed" which gets set to 1 when src != 0, and to 0 if src == 0. Only 
if "flushed" is already 0, then 0 is returned. Then the program 
terminates, (but still prints out [ac3 @ 0x7fee2b55e680]incomplete frame)

There must be a correct solution to this.

-- 
Cheers,
Alex


More information about the MPlayer-users mailing list