[FFmpeg-devel] RFC: ADTS for AAC

[Alex Converse]

On Wed, Dec 17, 2008 at 8:06 PM, Robert Swain <robert.swain at gmail.com> wrote:
> 2008/12/18 Baptiste Coudurier <baptiste.coudurier at gmail.com>:
>> Alex Converse wrote:
>>> The FFmpeg ADTS situation is a mess right now. This message covers a
>>> lot of different issues so I've broken this up into sections with
>>> headings.
>>>
>>> 1. Broken ADTS muxer (Issue 751) When channel_configuration == 0, the
>>> ADTS muxer omits the necessary PCE. There are a few ways to get the
>>> PCE to the ADTS muxer, we could try to pull the start and end offsets
>>> of the PCE from the MP4 demuxer. We could read in the PCE and write
>>> it back out. All the AudioSpecificConfig/GASpecificConfig is private
>>> in aac.c and contains some initialization crap. It needs some
>>> refactoring. Possibly to be moved to another file depending on how we
>>> wand the dependency chain for ADTS muxing to work.
>>
>> Humm, it would be nice to also have parsing of this information in aac
>> parser to set correct values to AVCodecContext I think. Putting code in
>> mpeg4audio.c seems reasonable to me.
>
> It will need to be source stream container agnostic I guess. Share
> code as you see fit.
>
>>> 2. Stop gap for broken muxer Until someone fixes ADTS muxing should
>>> we fail or spit out a warning when someone tries to write out an ADTS
>>> file with channel_configuration = 0?
>>
>> I think so.
>
> Yes. We should not be creating invalid files.

I also forgot to mention that in MPEG-2 mode, channel_configuration =
0 with no PCE is allowed but decoders are allowed to interpret it as
they wish.

>
>>> 4. Shared code with AC3 As far as ADTS decoding goes, I was told that
>>> should go directly in aac_parser.c and aac.c. But there is some code
>>> from ac3_parser.c/h that needs to be moved up to aac_ac3_parser.c/h.
>>> Should that be done in an earlier patch?
>>
>> If there is some code to share, seperate patch is for sure preferred, it
>> might need some justification based on what you will do with the shared
>> code, so having a patch that uses the new code is useful.
>
> Move it (and edit other code/build system stuff accordingly) then use
> it. :) But yes, group the patch with subsequent patches that justify
> the move.
>
>>> 5. Header representation As far as representing the the data in the
>>> ADTS header AC3 uses a struct called AC3HeaderInfo. AAC could use an
>>> AAC version of that or it could use an extended version of
>>> MPEG4AudioConfig from mpeg4audio.h.
>
> Hmm, whichever is cleanest and avoids duplication. If it's cleaner to
> 'inherit' from MPEG4AudioConfig, that's fine, else scratch written is
> fine. It's not a major issue anyway.
>
>>> 6. Broken old files created by FFmpeg In regard to the way we handle
>>> the broken files that our ADTS muxer has been spitting out up until
>>> this point.
>>
>> How broken ? You mean the channels == 0 ? Did many files have been
>> generated with this value ?
>
> Alex means channel_configuration == 0 and no PCE (or no PCE as the
> first element). As for how many... I have no idea.
>

It's hard to say. But it appears that gpac uses ffmpeg or is bug
compatible with us, so there might be quite a few.

>>> The specification says that we should ignore all data before the
>>> first PCE (aka ignore all data) when in MPEG4 mode. However,
>>> mp4audec_mc from 14496-5 decodes it anyway.
>>
>> Im not sure to understand, you mean mp4audec_mc decodes our files ?
>
> Alex means mp4audec_mc decodes these files that have
> channel_configuration == 0 and no PCE as first element/no PCE.
>
> Alex: Do these files just happen to have some default channel
> configuration or what?

I only tested mono files, so it's hard to say. It wouldn't surprise me
if they just get outputted in the order that they occur in the first
frame.

>
>>> 7. Other notes In general, I question the attitude that ADTS is the
>>> one true AAC elementary format. Eventually I'd like to see FFmpeg be
>>> able convert LATM, ADTS, ADIF, and MP4.
>>
>> Supporting LATM and ADIF would be great for sure, LATM support might
>> need some discussion with TS demuxing part I think.
>
> ADIF is less interesting as it seemed to be superseded by ADTS and
> there aren't many ADIF streams around. LATM is at least much more
> commonly used (for DVB streaming it seems).
>

Actually most of the conformance suite is available in ADIF and MP4.
Only a handful of files are available in ADTS format.

--Alex