GNOME Bugzilla – Bug 521542
AAC decoder doesn't support raw AAC streams
Last modified: 2009-01-09 22:55:15 UTC
It looks like sink_setcaps() in gstomx_aacdec.c doesn't do much with the caps it receives. Therefore the plugin only works when the stream contains enough information about stream contents (a.k.a. has either ADTS or ADIF header). Therefore this decoder plugin doesn't work when audio is coming from some container, e.g. from MP4 file, because in that case the stream information is passed in the caps: setcaps (sink): audio/mpeg, mpegversion=(int)4, rate=(int)48000, channels=(int)2, framed=(boolean)true, codec_data=(buffer)1190 AAC decoder element should parse these caps in a similar manner to FAAD plugin in gst-plugins-bad. When "codec_data" info is present in caps structure, element can be sure that it is dealing with a raw AAC stream and in this case it needs to initialize the underlying OpenMAX codec itself (by using OMX_SetParameter call I guess).
I've checked the code and the faad plug-in isn't parsing that "codec_data". It's passing the information to faad through faacDecInit2. The information to determine the stream format (ADTS or ADIF) is present in the normal stream, not on the "codec_data". The "codec_data" field contains information about the profile. I'm not aware of any facility to pass this "codec_data" to OpenMAX IL. I'm investigating.
There doesn't seem to be a specified way to do this. I will use OMX_BUFFERFLAG_EXTRADATA to mark the codec_data buffers, and send those to the decoder.
There will be a way to do this in the coming 1.1.2 spec with OMX_BUFFERFLAG_CODECCONFIG. This is already implemented in gst-openmax using the value (0x80) instead of the define. Regarding the ADTS or ADIF, it should be detected by the decoder, not handled by gst-openmax. So now it's the turn of the OpenMAX IL implementations, I think from gst-openmax side this is fixed.