Re: [Libquicktime-devel] AAC audio

[Erik J. <eri...@gm...>]

Hi,

On Mon, Oct 7, 2013 at 2:02 PM, Burkhard Plaum
<bur...@ig...> wrote:
> - If an ffmpeg decoder outputs floating point samples, they should be
>    passed through and not converted to 16 bit int.
>
> - The prime samples are completely ignored by the faad2 based decoder so ignoring them
>    for the ffmpeg decoder would mean no feature regression.
>
> - The proper method for getting the prime samples can be a separate patch. If the data
>    is available in an itunes atom this can be used of course, but we shouln't write any
>    itunes specific stuff unless the file type is LQT_FILE_M4A.

I'll just add a few additional comments. As Phil wrote, we had an
internal discussion about whether to send our existing solution as a
patch to libquicktime. My comments at that time were:

> 1) The support for reading the iTunes atom is very limited, as we only read iTunSMPB.
> It appears most of the other supported atoms can be both read and written.
>
> 2) The parsing of the payload of the iTunSMPB is assumes the data is correctly
> formatted.

A little later, we switched to a newer version of ffmpeg, which is
where the horrible float to 16-bit audio hack enters the picture. My
unredacted notes with regards to that are as follows:

> AVCodecContext provides a field for audio sample format as follows:
>     /**
>      * audio sample format
>      * - encoding: Set by user.
>      * - decoding: Set by libavcodec.
>      */
>     enum AVSampleFormat sample_fmt;  ///< sample format
> The audio decoder in libquicktimes ffmpeg plugin sets sample_fmt to 16bit signed, and
> then relies on that being the case throughout the code. Only the latest ffmpeg resets
> sample_fmt to float as per the documentation. In addition, it appears memory
> allocated for audio decoded using avcodec_decode_audio4() is never free'd.

and

> Fixed memory leak and implemented horrible hack to get by for now. Opened bug
> 24574 for fixing properly ("broken gets fixed, shoddy lasts forever").

I realise I'm probably mixing issues on the same thread, but hopefully
it'll provide some context that may prove helpful to Derek :-)

Thanks,
Erik