GNOME Bugzilla – Bug 596772
mpegtsdemux: fails to detect HE-AAC audio stream
Last modified: 2014-06-22 13:21:58 UTC
There is a problem when the mpegtsdemux is used to demux h.264 video and he-aac audio. The pipeline "gst-launch-0.10 filesrc location="some_sample.mpg" ! mpegtsdemux name=demux demux. queue ! ffdec_h264 ! xvimagesink demux. queue ! faad ! audioconvert ! alsasink" does not work. When it is used just with the video decoder, the video is displayed. But when the audio decoder is added (like the command showed before), nothing happens: video is not displayed and audio is not played... The problem should be with the part of the demux responsible by demuxing the audio. A sample ts can be download here: http://www.dsc.ufcg.edu.br/~cezane/sample_h264_heaac.ts
Does this file really contain audio though ? Neither gst-discoverer nor ffmpeg -i report apparent audio. ffmpeg does report a fair number of errors, which may or may cause this issue (I assume due to the sample being cut). If the 'data' streams are meant to be audio, maybe they're corrupt. Input #0, mpegts, from 'sample_h264_heaac.ts': Duration: 00:00:03.67, start: 145.331833, bitrate: 22851 kb/s Program 59200 Globo HD Metadata: name : Globo HD provider_name : Stream #0.0[0x111]: Video: h264, yuv420p, 1920x1080 [PAR 1:1 DAR 16:9], 64.42 fps, 59.94 tbr, 90k tbn, 59.94 tbc Stream #0.1[0x112]: Data: 0x0011 Stream #0.2[0x113]: Data: 0x0011 Stream #0.3[0x116]: Data: 0x0006 Stream #0.4[0x384]: Data: 0x000b Stream #0.5[0x1f4]: Data: 0x0005 Program 59224 Globo 1Seg Metadata: name : Globo 1Seg provider_name : Stream #0.7[0x211]: Video: h264, yuv420p, 320x180 [PAR 1:1 DAR 16:9], 41.21 fps, 29.97 tbr, 90k tbn, 29.97 tbc Stream #0.6[0x212]: Data: 0x0011 Stream #0.8[0x216]: Data: 0x0006 Program 59201 Globo SD Metadata: name : Globo SD provider_name : At least one output file must be specified
> Does this file really contain audio though ? Yes, try with vlc.
(In reply to comment #1) > Does this file really contain audio though ? Stream type 0x11 is MPEG-4 LATM audio. This looks like a duplicate of bug 615681: https://bugzilla.gnome.org/show_bug.cgi?id=615681
http://file.kidwm.net/Taiwan_HiHD_slogan.ts Here is another example file. And I've tried the patch from #615681, it didn't work.
Audio works for me with: gst-launch filesrc location=Taiwan_HiHD_slogan.ts ! mpegtsdemux ! ffdec_aac_latm ! autoaudiosink
Wondering if this is not the same issue as bug #678078
Hi, Probably tsdemux doesn't properly check the audio stream format and profile. I see a similar issue in mpegtsmux which I'm currently fixing where in streamtype is hardcoded for mpeg4-audio to 0x0f which is wrong. I'm suspecting a similar issue in demuxer as well. Let me look into the code and post more details ~BO
Created attachment 270221 [details] [review] aacparse: put codec data on caps for loas format gst-libav audio decoder also needs codec data for LOAS format, otherwise it will complain about not having a decoder config and skip all packets, even though LOAS has the codec-data in its packets. This patch fixes the audio playback, but using playbin this sample still hangs at preroll. Might be related to the sample being incomplete, but I haven't investigated this part yet.
Erm... I accidentally pushed this patch. I was waiting on this because I wanted to see what libav developers would do with https://bugzilla.libav.org/show_bug.cgi?id=644 to see if we would need to have the codec-data. and also because the 'need_codec_data' variable should also be true for 'raw' format. It would be possible to live without a codec-data for LOAS as it might present on the stream at some points and let the decoder handle that just like ADTS. AFAIK the difference is that LOAS only puts the config data at some frames instead of on every frame like ADTS. What should be done here? Revert the patch and wait for libav feedback?
I would revert it for now, just because we might forget about it otherwise and then someone might start relying on what it does now. It seems a bit unexpected that you would need to have out-of-band codec_data here.
Reverted, will push for the fix on libav's side. Going to keep this open to remind myself of it :)
The fix on libav got in https://bugzilla.libav.org/show_bug.cgi?id=644 But I don't think it made to the version 10 branch we use. (yet?)
Maybe ask them if they could cherry-pick it into the stable branch? :)
It is not in the version 10 branch. So I guess we keep this open until we update our libav target to include that fix.
Comment on attachment 270221 [details] [review] aacparse: put codec data on caps for loas format Fix was made directly in libav
commit 650c2ad0a84f02b98db8a8a9acf644441d96800d Author: Sebastian Dröge <sebastian@centricular.com> Date: Sat Mar 29 10:45:16 2014 +0100 Update to libav v10 This is now fixed since this commit. Playback of this file still doesn't work with playbin, but this is a different issue: https://bugzilla.gnome.org/show_bug.cgi?id=727498