[Bug 731347] New: libav: If codec sets channels to 0, gst_ffmpegauddec_get_buffer () crashes

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Fri Jun 6 14:44:16 PDT 2014


https://bugzilla.gnome.org/show_bug.cgi?id=731347
  GStreamer | gst-libav | git

           Summary: libav: If codec sets channels to 0,
                    gst_ffmpegauddec_get_buffer () crashes
    Classification: Platform
           Product: GStreamer
           Version: git
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-libav
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: gstblub at gmail.com
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


Created an attachment (id=278059)
 --> (https://bugzilla.gnome.org/attachment.cgi?id=278059)
Some logs and gdb stack traces

I ran into this (in this case attachment 277975 from bug #731286 was applied,
although it shouldn't really matter) assertion while playing an AAC hls stream:

** (gst-launch-1.0:27393): CRITICAL **:
gst_audio_channel_positions_to_valid_order: assertion 'channels > 0' failed

Which is triggered while being in avcodec_decode_audio4 ():

(gdb) bt
#0  0x00007ffff75c1c13 in g_logv () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#1  0x00007ffff75c1d72 in g_log () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007ffff3f4a933 in gst_audio_channel_positions_to_valid_order
(position=<optimized out>, channels=0) at audio-channels.c:443
#3  0x00007fffc1449dcc in gst_ffmpegauddec_negotiate (ffmpegdec=0x7fffd0012aa0,
force=0) at gstavauddec.c:459
#4  0x00007fffc14496af in gst_ffmpegauddec_get_buffer (context=0x7fffd00133c0,
frame=0x7fffc2db80e0) at gstavauddec.c:328
#5  0x00007fffc17a9147 in ff_get_buffer (avctx=avctx at entry=0x7fffd00133c0,
frame=0x7fffc2db80e0, flags=flags at entry=0) at libavcodec/utils.c:646
#6  0x00007fffc18968ba in frame_configure_elements (avctx=0x7fffd00133c0) at
libavcodec/aacdec.c:188
#7  output_configure (ac=<optimized out>, layout_map=<optimized out>,
tags=<optimized out>, oc_type=OC_TRIAL_PCE, get_new_frame=1) at
libavcodec/aacdec.c:480
#8  0x00007fffc1897fa5 in aac_decode_frame_int
(avctx=avctx at entry=0x7fffd00133c0, data=data at entry=0x7fffc2db80e0,
got_frame_ptr=got_frame_ptr at entry=0x7fffc2db7fc4, gb=gb at entry=0x7fffc2db7ec0)
at libavcodec/aacdec.c:2847
#9  0x00007fffc1899024 in aac_decode_frame (avctx=0x7fffd00133c0,
data=0x7fffc2db80e0, got_frame_ptr=0x7fffc2db7fc4, avpkt=<optimized out>) at
libavcodec/aacdec.c:2950
#10 0x00007fffc17aa461 in avcodec_decode_audio4 (avctx=0x7fffd00133c0,
frame=0x7fffc2db80e0, got_frame_ptr=0x7fffc2db7fc4, avpkt=0x7fffc2db8010) at
libavcodec/utils.c:1537

If you look at the attached file this may occur if ffmpeg can't decode a chunk
of aac data.  It seems that in this example either the beginning or the end of
an hls fragment couldn't be decoded for some reason.  While most of the time
this doesn't appear to be causing issues, I run into this assertion frequently.

I don't think it's a good idea to look at values the AVCodecContext structure
while executing avcodec_decode_audio4 ().  We are currently using the
(deprecated) get_buffer callback, and the documentation[1] does not mention
much about what information can safely be relied upon.  However, when you look
at the new get_buffer2 callback (which is what new implementations should be
using), it clearly states the following[2]:

The following fields will be set in the frame before this callback is called:

* format
* width, height (video only)
* sample_rate, channel_layout, nb_samples (audio only) Their values may differ
from the corresponding values in AVCodecContext. This callback must use the
frame values, not the codec context values, to calculate the required buffer
size.

So, unless get_buffer's behavior is drastically different from get_buffer2, it
sounds like it's probably not a good idea to look at AVCodecContext values and
we should take the channel information from the supplied AVFrame instead.

[1]:
https://www.ffmpeg.org/doxygen/trunk/structAVCodecContext.html#ad2a02f9d24723a62e30a3cfecdb7c2c5
[2]:
https://www.ffmpeg.org/doxygen/trunk/structAVCodecContext.html#a7c93198032a3a728b13cb7d7e637d295

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.


More information about the gstreamer-bugs mailing list