After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 596772 - mpegtsdemux: fails to detect HE-AAC audio stream
mpegtsdemux: fails to detect HE-AAC audio stream
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal normal
: 1.3.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-09-29 18:42 UTC by Dalton
Modified: 2014-06-22 13:21 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
aacparse: put codec data on caps for loas format (8.91 KB, patch)
2014-02-25 04:28 UTC, Thiago Sousa Santos
rejected Details | Review

Description Dalton 2009-09-29 18:42:34 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
Comment 1 Vincent Penquerc'h 2011-01-23 15:02:20 UTC
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
Comment 2 Tim-Philipp Müller 2011-01-23 15:15:07 UTC
> Does this file really contain audio though ?

Yes, try with vlc.
Comment 3 Raimo Järvi 2011-01-24 10:48:34 UTC
(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
Comment 4 WM 2011-12-02 13:41:21 UTC
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.
Comment 5 Raimo Järvi 2011-12-02 14:14:54 UTC
Audio works for me with:

gst-launch filesrc location=Taiwan_HiHD_slogan.ts ! mpegtsdemux ! ffdec_aac_latm ! autoaudiosink
Comment 6 Edward Hervey 2013-06-12 06:57:37 UTC
Wondering if this is not the same issue as bug #678078
Comment 7 Baby octopus 2013-07-26 12:36:40 UTC
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
Comment 8 Thiago Sousa Santos 2014-02-25 04:28:44 UTC
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.
Comment 9 Thiago Sousa Santos 2014-02-27 23:00:37 UTC
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?
Comment 10 Tim-Philipp Müller 2014-02-27 23:44:14 UTC
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.
Comment 11 Thiago Sousa Santos 2014-02-28 03:33:27 UTC
Reverted, will push for the fix on libav's side. Going to keep this open to remind myself of it :)
Comment 12 Thiago Sousa Santos 2014-02-28 22:33:48 UTC
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?)
Comment 13 Tim-Philipp Müller 2014-02-28 22:46:55 UTC
Maybe ask them if they could cherry-pick it into the stable branch? :)
Comment 14 Thiago Sousa Santos 2014-03-03 16:16:56 UTC
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 15 Thiago Sousa Santos 2014-03-03 16:17:25 UTC
Comment on attachment 270221 [details] [review]
aacparse: put codec data on caps for loas format

Fix was made directly in libav
Comment 16 Thiago Sousa Santos 2014-04-02 15:32:00 UTC
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