[FFmpeg-user] ac3 to mp3 converting bug

Clément Bœsch ubitux at gmail.com
Wed Jul 4 15:53:16 CEST 2012


On Wed, Jul 04, 2012 at 03:19:43PM +0200, Ingo Brückl wrote:
> Clément Boesch wrote on Wed, 4 Jul 2012 10:13:15 +0200:
> 
> >> > Le sextidi 16 messidor, an CCXX, Ingo Brückl a écrit :
> >> >> Sure. What information would you need?
> >>
> >> > All you can give on how to reproduce the problem.
> >>
> >> I'm afraid there is hardly more I can tell than I already did in my
> >> postings
> 
> > What do you use for playback for instance (ffplay, MPlayer?)
> 
> MPlayer, but that shouldn't make a difference, because the mp3 output file
> only consists of large 0x55 blocks as stated earlier. This hardly is any
> converted audio data. (Don't know if it's typical for silence though.)
> 
> > Also, since you mentioned the *static* libmp3lame, is the issue
> > reproducible with a shared version?
> 
> Oops, a shared libmp3lame segfaults!
> 
>   Program received signal SIGSEGV, Segmentation fault.
>   0xb7ed87cd in count_bits () from /usr/lib/libmp3lame.so.0
> 
> This happens with non-2.0 ac3 like monsters_inc_5.1_448.ac3, but not with 2.0
> ac3 like monsters_inc_2.0_192.ac3, for example.
> 
> Configuring lame with --enable-debug=alot leads to:
> 
>   Program received signal SIGFPE, Arithmetic exception.
>   0xb7ec4f64 in lame_encode_buffer_template (gfp=<optimized out>,
>       buffer_l=0x8f26520, buffer_r=0x8f26522, nsamples=1152,
>       mp3buf=0x8f2794c "", mp3buf_size=10792, pcm_type=pcm_short_type, aa=2,
>       norm=1) at lame.c:1882
>   1882                    lame_copy_inbuffer(gfc, buffer_l, buffer_r, nsamples, pcm_type, aa, norm);
> 
> and a backtrace prints:
> 
>   #0  0xb7ec4f64 in lame_encode_buffer_template (gfp=<optimized out>,
>       buffer_l=0x8f26520, buffer_r=0x8f26522, nsamples=1152,
>       mp3buf=0x8f2794c "", mp3buf_size=10792, pcm_type=pcm_short_type, aa=2,
>       norm=1) at lame.c:1882
>   #1  0xb7ec52e6 in lame_encode_buffer_interleaved (gfp=0x8f7df88,
>       pcm=0x8f26520, nsamples=1152, mp3buf=0x8f2794c "", mp3buf_size=10792)
>       at lame.c:1995
>   #2  0x0846a007 in encode_frame_int16 (nb_samples=<optimized out>,
>       samples=<optimized out>, s=<optimized out>) at libavcodec/libmp3lame.c:165
>   #3  mp3lame_encode_frame (avctx=0x8f78560, avpkt=0xbffff01c, frame=0x8f26300,
>       got_packet_ptr=0xbffff160) at libavcodec/libmp3lame.c:209
>   #4  0x085aad20 in avcodec_encode_audio2 (avctx=0x8f78560, avpkt=0xbffff01c,
>       frame=0x8f26300, got_packet_ptr=0x8fccd28) at libavcodec/utils.c:1147
>   #5  0x08094b92 in do_audio_out (frame=<optimized out>, ost=<optimized out>,
>       s=<optimized out>) at ffmpeg.c:1583
>   #6  poll_filters () at ffmpeg.c:1990
>   #7  0x08098143 in transcode () at ffmpeg.c:3671
>   #8  main (argc=-487877, argv=0x0) at ffmpeg.c:5962
> 

Are you sure the problem is not in your libmp3lame copy? Valgrind doesn't
notice anything here (libmp3lame 3.99.5), and my output is fine.

> > Is that only reproducible with AC3 --> MP3? Can you try with, let's say
> > flac or a libvorbis?
> 
> I've neither installed flac nor vorbis libraries on my PC, but could do so
> if that'd help (please tell me). On the other side, we've already established
> that converting to wav or mp2 works fine, so it seems to be related to mp3
> output only.
> 

Ok. Note that FLAC encoder is native, you don't need to install anything.

> > Monster's Inc samples, as well as Broadway start with silence anyway, what
> > about TomorrowNeverDies-2.1-48khz-192kbit.ac3?
> 
> A completely mute file as well and, in addition, some errors (with static
> lame, shared lame crashing):
> 
>   [ac3 @ 0x9ab2620] frame sync error
>   Error while decoding stream #0:0: Operation not permitted
>   [ac3 @ 0x9ab2620] frame CRC mismatch
> 
> > Like the others I can't reproduce the issue as well. It's not about not
> > believing the issue does not exist and doesn't come from this commit,
> 
> I'm wondering what this commit changes in process with otherwise identical
> libraries.

This commit makes the audio processing passing through libavfilter (even
if you don't use it); maybe the code path being totally different is more
likely to trigger the issue (totally different stack, heap, etc).

-- 
Clément B.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-user/attachments/20120704/b6496fad/attachment.asc>


More information about the ffmpeg-user mailing list