[FFmpeg-devel] RFC: ADTS for AAC

[Baptiste Coudurier]

Hi Alex,

Alex Converse wrote:
> Hello,
> 
> 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.

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

> 3. PCE equivalence In some cases the PCE is equivalent to a
> channel_configuration > 0 and can be converted. Should we attempt to
> do this at all? In my opinion it is certainly more idomatic ADTS and
> makes operations like cutting and joining simpler. It could be
> implemented as a bitstream filter I suppose.

Would it be useful to other wrapper than ADTS ? If not, it could be put
simply in ADTS muxer.

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

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

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

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

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
checking for life_signs in -lkenny... no