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 771994 - aacparse: Does not rezognize HE-AAC v2 stream
aacparse: Does not rezognize HE-AAC v2 stream
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal enhancement
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-09-26 16:09 UTC by Olivier Crête
Modified: 2018-11-03 15:12 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
ADTS AAC sample file (264.75 KB, audio/aac)
2016-09-26 16:09 UTC, Olivier Crête
Details

Description Olivier Crête 2016-09-26 16:09:09 UTC
Created attachment 336277 [details]
ADTS AAC sample file

It seems that our parser can't recognize the HE-AAC v2 profile

The attached sample file was created with:
ffmpeg -i 45s-48khz-16bit-2ch.wav -c:a libfdk_aac -profile:a aac_he_v2 -b:a 48k 45s-48khz-16bit-2ch-48kbps.aac
Comment 1 Tim-Philipp Müller 2016-09-26 16:18:43 UTC
Does ADTS even provide signalling for HE-AAC v2?
Comment 2 Vincent Penquerc'h 2016-09-27 15:28:07 UTC
That seems to work fine with gst-launch-1.0 filesrc location=~/Downloads/45s-48khz-16bit-2ch-48kbps.aac ! aacparse ! fdkaacdec ! pulsesink (both with and without https://bugzilla.gnome.org/show_bug.cgi?id=772067). Pipeline starts, I hear guitar.
Comment 3 Olivier Crête 2016-09-29 15:05:02 UTC
The "mediainfo" program recognizes this file as HE-AAC v2, so I assume it can be done somehow. 

The enhancement requested here are:
 - have aacparse recognize the HE-AAC profiles and set them in the caps
 - have the pbutils recognize those and print them so that gst-discoverer can print the right thing.
Comment 4 Olivier Crête 2016-09-29 15:05:55 UTC
I assume the parser need to find PS and SBR bits in the stream to know which profile it is?
Comment 5 A Ashley 2017-04-10 13:36:16 UTC
(In reply to Olivier Crête from comment #4)
> I assume the parser need to find PS and SBR bits in the stream to know which
> profile it is?

It depends upon how the stream is encapsulated.

In the case of an MP4 file, the ES descriptor should contain the profile information and if PS or SBR are being used. qtdemux should be passing that in the caps, but I don't think it does currently.

If LATM/LOAS is used, the signalling can be put in the AudioSpecificConfig section of StreamMuxConfig.

Ultimately the PS or SBR data goes in filler elements in the elementary stream. An AAC-LC decoder would skip those and decode the base AAC-LC stream. An HE-AAC or HE-AAC v2 decoder will know how to read this extra data and enhance the base AAC-LC stream.

The following white paper from Fraunhofer has a good overview of the different ways in which AAC can be encapsulated:

https://www.iis.fraunhofer.de/content/dam/iis/de/doc/ame/wp/FraunhoferIIS_Application-Bulletin_AAC-Transport-Formats.pdf
Comment 6 GStreamer system administrator 2018-11-03 15:12:04 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/302.