[FFmpeg-devel] [PATCH] add (e)ac3float decoders

[Justin Ruggles]

On 03/07/2011 02:25 PM, Ronald S. Bultje wrote:

> Hi,
> 
> On Mon, Mar 7, 2011 at 2:18 PM, madshi <madshi at gmail.com> wrote:
>> attached you'll find a patch which adds "ac3float" and "eac3float" decoders.
>> The only difference to the "ac3" and "eac3" decoders is that the float
>> decoders output float, obviously (which is the native decoding format)
>> instead of rounded down 16bit integer samples. This is quite important,
>> IMHO, because rounding down digital audio/video data is a violation of
>> processing laws. When bitdepth is reduced, dithering must be used, to avoid
>> quantization errors, which libav does currently not do. So outputting float
>> is a better solution for audio quality.
> 
> The idea is fine, but the execution isn't. IIUC, Justin has patches
> that move audio decoding to using something like an AVFrame, which we
> could eventually use to output "planar" audio formats, so each channel
> in its own buffer. This would prevent the loop in your patch and not
> cause the significant slowdown introduced here.
> 
> I'd prefer to wait for Justin's patches to mature and use that approach.


1) There is no need for separate int16 and float decoders. The AC3
decoder is a floating-point decoder. It just happens to output int16 at
the end.

2) Like Mans said, the goal needs to be to optimize the generic
conversion functions first so we don't slow things down, then change
decoders to output in their native format.

3) Yes, planar audio output would be great too.  The use of AVFrame for
audio decoding will be a step in the right direction, but we also need to:
- use AVFrame for encoding
- come to a concensus on the data/linesize arrangement for planar vs.
interleaved (see recent lavfi audio threads)
- add planar sample formats
- add generic conversion functions for those sample formats

Thanks,
Justin