LATM Transport format Decode issue
CoreTechie opened this issue · comments
I have used the 'fdkaac' command line encoder to encode a .wav bit-stream to HE-AACv1 with LATM(MCP1) transport format. But the 'fdk-aac' decoder is not able to decode the .latm file and returns AAC_DEC_TRANSPORT_SYNC_ERROR everytime. My decoder-example test application fills 10240 bytes with aacDecoder_Fill (). Valid bytes returned is 0.
Enclosed the .latm encoded bit-stream.
sample_adts_HEAACv1_64K_LATM_MCP1.zip
Sorry, no idea about the LATM decoding support in the decoder right now, if there is just a small bug somewhere that prevents it from working in this case, or if it's far from working at all. (I don't develop this library myself but only repackage the sources from the android code tree; it's originally developed by Fraunhofer.)
But I did notice one bug in the existing example, see d61932a. Due to this issue, it failed when I tested decoding ADTS when just feeding a few bytes at a time.
Thank you for the reply. Does LATM decoding work with this fdk-aac distribution ? Have this been tried earlier or any sort of confirmation that it works ?
I'm not sure if anybody has tried it with latm at all. Most people use an external library to parse the transport stream and just pass raw aac packets to the decoder.
Ok. In order to rule out a possibility that my encoded bit-stream is corrupt., I would like to create another latm bit-stream using the fdk encoder in this distribution. Can you please recommend any suitable encoder-example branch that will be able to do this for me ?
I tested your bitstream with ffmpeg, and wasn't able to decode it with it. I created another test LATM bitstream with ffmpeg, which ffmpeg/ffplay itself can play just fine, but aac-dec.c (with small modifications, to use TT_MP4_LATM_MCP1 and to blindly feed bytes instead of trying to parse the ADTS structure) fails to decode it. So I can't really say...
Thank You Martin ! Can you please upload the ffmpeg created test bitstream you used for your testing ? Let me check it in my application environment.
The issue seems to be in tpdec_lib.cpp module in the function transportDec_FillData(). For LATM Packets, FDK Internal Bit-steam buffer is not fed / appended with new data (like the ADTS formats); rather the same external input buffer is used. The problem is with the length where a default of 65536 is assumed as the buffer size. I did the following changes in this module and also modified the example application in the main. This now decodes all frames of a valid LATM (MCP=1) bit-stream.
(-) FDKinitBitStream(hBs, pBuffer, 0x10000, (*pBytesValid)<<3, BS_READER);
(+) FDKinitBitStream(hBs, pBuffer, *pBytesValid, (*pBytesValid) << 3, BS_READER);
test-latm(https://github.com/mstorsjo/fdk-aac/files/2152152/test-latm.zip) does not decode may be for other reasons...
but my earlier latm bit-streams (https://github.com/mstorsjo/fdk-aac/files/2152152/test-latm.zip) goes through. This bit-stream was encoded with fdkaac CL encoder for latm (with MCP=1)
The Latm specific application main, I used for my testing is also attached.
latm-dec.zip
sorry the bit-stream that works is this one https://github.com/mstorsjo/fdk-aac/files/2148427/sample_adts_HEAACv1_64K_LATM_MCP1.zip
Ok, this explains some bits... I think LATM in general should be possible to parse like a stream, just like ADTS, but the code in TT_IS_PACKET in libSYS/include/FDK_audio.h clearly seems to indicate that fdk-aac treats it as packets that need to be passed one at a time.
So compared to ffmpeg's latm, I think the thing that fdk-aac produces lacks some of the outer framing that makes it a proper stream.
The line you found in tpdec_lib.cpp does seem a bit weird, but since it works fine for normal raw aac packets as it is right now, I'm not very confident in changing it either.
I'm not very familiar with LATM right now, it's been quite a few years since I touched it the last time, so I can't comment on it right now how it all fits together, though, and to figure out what fdk-aac's "latm" actually is.
To backtrack to your original issue, do I understand it right that you want to use LATM as low overhead container format for streamed AAC that is capable of storing the more advanced AAC profiles? Given the things right now, even though you with the suggested modification seem to be able to make it work, it doesn't seem like something that matches what everybody else calls LATM. I would suggest you either use another external library to write and parse LATM (libavformat has got a LATM muxer, but for demuxer it's all integrated into the decoder, unfortunately, so not easily usable with fdk-aac).
Alternatively, if you don't need a specific standard format, I'd suggest just invent your own custom framing and use raw aac packets. In this case you just need to pass the ASC (info.confBuf/info.confSize) and packets manually together with their individual size.
Actually the need is to support AAC decoding on an ARM based platform. So all the audio transport formats that can be contained in MPEG-TS streams coming over an ASI input needs to be able to decode. MPEG-TS (for ASI) specifications mentions ADTS and LATM/LOAS as the primary audio transport formats contained in PES packets.
One question: In your example for RAW AAC format decoding you have used 'libavformat' for extracting the ASC. Do you think there is any other simple way or method to get the ASC from the Raw AAC stream ? I am just trying to avoid including the whole 'libavformat' source (or its pre-built libraries) into my memory constrained embedded build and use a simpler way to configure the decoder for Raw streams.
There is no such thing as a "raw" stream; you need some sort of framing around raw aac packets and around the ASC. ADTS, LATM/LOAS and m4a are all different kinds of framing. The fdk-aac library has got some kind of support for the first three, but not for m4a; I only use libavformat for reading m4a files. You won't have m4a in mpeg-ts.
Ok, Thanks Martin !