AAC raw decode issue

[nicoemsy]

I've slightly modified decoder example to support ADIF container, it is working well. However decoder returns errors such as AAC_DEC_PARSE_ERROR when using it with AAC raw files as input. Input AAC raw file has been encoded using aac-enc and aacDecoder_ConfigRaw set with buffer from aacEncInfo. After dumping the 2 bytes ASC from aacEncInfo, I got 0x11 0x90 (AACLC, @48khz, channel cfg 2) which seems to match with my input wav file parameters. The resulting .aac file is well decoded with FAAD decoder ... Does anyone manage to successfully decode AAC raw file ?

Thanks in advance

[mstorsjo]

It would be much easier to say what you're doing wrong if you could point to the actual code.

That said, if you use raw AAC payloads (you demux the ADIF stream yourself), remember to pass TT_MP4_RAW to aacDecoder_Open, and make sure you frame the packets properly when you send them to the decoder so that you pass in exactly one packet at a time. I don't have other advice to give unless I can test/read the code myself.

[georgesterpu]

It looks to me that the provided library (libMpegTP) already does adts/adif/latm/loas muxing and demuxing.

I was also looking for a transport format compatible with the ELD profile a couple of weeks ago, and LOAS seems suitable. At least it was easier to implement than having to encode and decode in RAW.

[nicoemsy]

Thanks, you pointed it right when you said to pass "exactly" one packet at a time. Indeed if I used the numOutBytes from the aac-enc output parameters (outargs parameter from aacEncEncode output) to fill aac-dec packet, it is now ok. However I wonder how to know aac raw packet length without knowing aac-enc output (let's say in real use without knowing of encoding output params)

[mstorsjo]

Just by looking at the data, you can't easily distinguish where the packet boundaries are, you basically need to decode it to know.

If you pass a decoder too little data, it can probably tell you that it seems like the packet was truncated. If you pass a decoder more data than one single packet, at least some decoders (the libavcodec AAC decoder at least can, I don't know off-hand about fdk-aac) can tell you how many bytes it did consume - which will then tell you where the next packet starts.

But the normal convention is to make sure the container keeps track of packet lengths and offsets.