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 743946 - qtdemux: handle files with AAC streams that have ESDS atom but no codec data
qtdemux: handle files with AAC streams that have ESDS atom but no codec data
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Mac OS
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-02-03 18:02 UTC by Matej Knopp
Modified: 2018-11-03 14:57 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
Patch to build missing codec data (1.79 KB, patch)
2015-02-03 18:02 UTC, Matej Knopp 		reviewed Details | Review

Description Matej Knopp 2015-02-03 18:02:14 UTC 
Created attachment 296050 [details] [review]
Patch to build missing codec data

In which case the codec data needs to be built.
Comment 1 Thiago Sousa Santos 2015-02-03 19:19:30 UTC 
Could you point us to a sample, please?
Comment 3 Thiago Sousa Santos 2015-02-11 18:59:10 UTC 
Review of attachment 296050 [details] [review]:

::: gst/isomp4/qtdemux.c
@@ +10762,3 @@
+      /* if there is no codec data present attempt to build one */
+      if (!data_ptr && stream->n_channels > 0 && stream->rate > 0) {
+        gint profile = 2;

Shouldn't the profile be different based on the value of the switch?
Comment 4 Matej Knopp 2015-02-11 19:32:57 UTC 
I don't think there should be other value. Most decoders require audioObjectType value of 2 (AAC-LC), even for SBR, where the SBR is either signaled implicitly (2 byte codec data), or explicitly (5 byte codec data, where audioObjectType is still set to 2 and extensionAudioObjectType is set to 5(SBR) or 5(PS)). Given that implicit signaling is perfectly valid and used by many files I don't think we need to bother trying to build 5 byte header. Not that it affects the profile value in any way.

In theory if you know reliable way to map object type id from ESDS to audioObjectType from AudioSpecificConfig it can be done, but since most decoders only support AAC-LC (possibly with SBR and PS) I don't think it's worth the effort. I think if there are some files out there that require AAC Main or SSR they would have codec data.
Comment 5 Matej Knopp 2015-02-11 19:35:01 UTC 
Sorry, AAC PS extensionAudioObjectType is 29, not 5.
Comment 6 GStreamer system administrator 2018-11-03 14:57:35 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/157.