GNOME Bugzilla – Bug 721697
aacparse: cannot parse some ADTS AAC streams
Last modified: 2018-11-03 14:50:55 UTC
aacparse element cannot parse AAC streams that set 0 to channel_config field in ADTS header.
Created attachment 265530 [details] [review] fix detection of ADTS streams
Thanks for the patch. Could you attach a small piece of a sample stream please?
Created attachment 265633 [details] sample AAC data which set 0 to channel_config in ADTS header This sample is a "dual mono" stream. Its channel configuration is defined outside in the applications, as described in the standard. > If channel_configuration equals 0, the channel configuration is not specified > in the header and must be given by a program_config_element() following as > first syntactic element in the first raw_data_block() after the header, or by > the implicit configuration (see subclause 8.5) or must be known in the application (Table 8).
This patch fixes the "cut off" when using aacparse ! faad. However, aacparse ! avdec_aac now criticals, due to libav asserting channels > 0, while it plays (albeit with a cut off part) without the patch. I think the channel code in _negotiate in gstavauddec.c could be bypassed, though that doesn't seem like an obviously no-side-effects thing.
I just tried to tweak a bit the gstavauddec.c code, but there's no sane way to get the audio info. Since 0 channels is apparently "custom", I'm not sure we really want to care about avdec_aac (or other generic decoders). So I'm of a mind to apply this patch, and maybe change avdec_aac to error out more gently on 0 channels. Thoughts ?
I had seen in the past a 5.1ch sample which specified 0ch in ADTS but has the PCE with non standard/irregular element ID assignments, (which I forgot to save). Those 0ch-ADTS streams with PCE should be decoded properly by generic decoders, but the sample I uploaded is really a corner case with *no* PCE, thus decoding errors from general decoders might be acceptable, I think. The sample is in fact specific to Japanese dtv, and application knows its channel configuration from PSI of the muxing transport stream. Ideally, it would be desirable if avdec_aac supports "the implicit configuration (see subclause 8.5)", even when AAC frames have no PCE.
Please do not push this in its current form, needs some more thought I think.
*** Bug 743332 has been marked as a duplicate of this bug. ***
*** Bug 752107 has been marked as a duplicate of this bug. ***
*** Bug 769215 has been marked as a duplicate of this bug. ***
-- 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/101.