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

[Michael Niedermayer]

On Mon, Mar 07, 2011 at 03:01:46PM -0500, Justin Ruggles wrote:
> 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.

can you send a patch that does this?


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

Theres no need anymore to accomodate mans philosophical ideas.
the ac3 decoder is a float decoder and should output float.
the convertion code should be improved but thats unrelated and no reason
to delay 1)

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20110307/44b135d6/attachment.pgp>