[FFmpeg-devel] RFC: ADTS for AAC

[Robert Swain]

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.

>> 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.

>> 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?

>> 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).

Regards,
Rob