GNOME Bugzilla – Bug 770704
aacparse assumes the stream-format to be raw when there is codec_data
Last modified: 2018-05-06 13:58:52 UTC
aacparse assumes the stream-format to be raw when there is codec_data. This is not correct. Encoder might want to send codec_data even when the stream is loas or adts, with codec data containing audio specific parameters as per different subparts 14496-3 Following is the code which sets it /* This is needed at least in case of RTP * Parses the codec_data information to get ObjectType, * number of channels and samplerate */ value = gst_structure_get_value (structure, "codec_data"); if (value) { .... .... aacparse->header_type = DSPAAC_HEADER_NONE; .... ....
Do you want to provide a patch?
Sure. Let me work on that and provide it here
I'm not sure if it should be 'codec_data' when it's LOAS or ADTS, or perhaps rather a 'streamheader' then?
Is there any documentation or code reference on that as to when to use 'codec_data' and when to use 'streamheader'? I presume it should be codec_data for elementary streams and 'streamheader' for system streams such as Mpeg TS, RTP etc. No?
codec_data is used when it's out-of-band information that needs to be signalled outside of the data stream. streamheaders would be used in GStreamer to signal out-of-band information that when prepended to the actual stream data still results in a valid stream (e.g. you could signal H264 byte-stream SPS/PPS in caps as streamheaders for an H264 byte-stream stream). Your claim "This is not correct" seems dubious, since what is in codec_data for which caps is entirely a GStreamer convention, and so far the convention has been that codec_data is only in caps for raw aac, and must be in caps for raw aac. Anyway, let's backtrack and figure out what you want to do in which specific scenario. Could you describe the specific scenario you want to make work but can't make work currently?
Sorry, my understanding was wrong here. I was under the assumption that codec_data itself is something that the muxer(TS) can take and create stream descriptor Coming to the usecase 1. aac encoder is generating LOAS stream in addition to codec_data. This codec_data consists AudioSpecificConfig() as specified in 1.6.2.1 of 14496-3 subpart1 2. This codec_data is taken by tsmuxer and it will generate MPEG-4 audio extension descriptor as specified in 2.6.73 of H.222 What would be the better way to achieve this?
You want to specify the stream format in the caps then, stream-format=loas-latm in this case AFAIU.
Hi, how does the help in extracting codec_data? Sorry. Am I missing something?
aacparse should probably first check for a valid stream-format, and only then fall back to assume that codec_data means raw. But also there should not be any codec_data in the caps if there are no defined out of band configuration data for a specific stream format. From what I understand that is not the case of LOAS, so there should not be any codec_data to begin with. LOAS is self-contained and has no out of band configuration data. So in summary, aacparse should be improved a bit here but also what you do with the caps seems wrong. Do you want to provide a patch for aacparse? Your case should accidentially work then at least :)
I'm going to close this for now. As I see it everything is working as expected. You seem to want to do certain plumbing between your encoder and tsmux for convenience in a way which is currently not defined in GStreamer that way.