GNOME Bugzilla – Bug 731347
libav: If codec sets channels to 0, gst_ffmpegauddec_get_buffer () crashes
Last modified: 2015-08-16 13:40:17 UTC
Created attachment 278059 [details] Some logs and gdb stack traces I ran into this (in this case attachment 277975 [details] [review] 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
+ Trace 233675
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
Created attachment 278060 [details] Another crasher in gstaudioringbuffer I'm not entirely sure if this one is related, but it sure looks like it.
I'm not sure though if looking at AVFrame will help (maybe if we used get_buffer2): channel_layout = 0, and there doesn't appear to be a channels field in the version we're using. gdb) frame 5
+ Trace 233676
$3 = {data = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, linesize = {0, 0, 0, 0, 0, 0, 0, 0}, extended_data = 0x7fffc2db80e0, width = 0, height = 0, nb_samples = 2048, format = 8, key_frame = 1, pict_type = 0, base = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, sample_aspect_ratio = {num = 0, den = 1}, pts = -9223372036854775808, pkt_pts = 0, pkt_dts = 0, coded_picture_number = 0, display_picture_number = 0, quality = 0, reference = 0, qscale_table = 0x0, qstride = 0, qscale_type = 0, mbskip_table = 0x0, motion_val = {0x0, 0x0}, mb_type = 0x0, dct_coeff = 0x0, ref_index = {0x0, 0x0}, opaque = 0x0, error = {0, 0, 0, 0, 0, 0, 0, 0}, type = 0, repeat_pict = 0, interlaced_frame = 0, top_field_first = 0, palette_has_changed = 0, buffer_hints = 0, pan_scan = 0x0, reordered_opaque = -9223372036854775808, hwaccel_picture_private = 0x0, owner = 0x0, thread_opaque = 0x0, motion_subsample_log2 = 0 '\000', sample_rate = 44100, channel_layout = 0, buf = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, extended_buf = 0x0, nb_extended_buf = 0, side_data = 0x0, nb_side_data = 0, flags = 0}
This should be fixed by this commit, which is in git master and will be in 1.5.3. Please retest commit 0767bdda5f111aecc4b462c04f78a60a229d0ed9 Author: Sebastian Dröge <sebastian@centricular.com> Date: Sat Jun 27 20:08:46 2015 +0200 avauddec: Negotiate based on the AVFrame instead of just the AVCodecContext