[FFmpeg-devel] suggestion for expanding audio bitdepth support in libav/ffmpeg

[Michel Bardiaux]

Reimar D?ffinger a ?crit :
> Hello,
> On Mon, Jan 21, 2008 at 11:34:55AM +0100, Michel Bardiaux wrote:
>> Andreas ?man a ?crit :
>>> Ian Caulfield wrote:
>>>> I think the idea was that the codec interface would be changed and a
>>>> new function would be added (avcodec_decode_audio3?) to use the new
>>>> interface, while avcodec_decode_audio2 would wrap the changes to
>>>> maintain the current API...
>>> Yes, but the real bugger is ff_float_to_int16_c() which, as of today,
>>> is embedded in the decoders (and thus, the decoders may prescale
>>> their coefficients to speed up the conversion). This needs some thought
>>> as well. Personally, i would think it would be cleanest (API-wise) if
>>> the SAMPLE_FMT_FLT would be data in the range of -1 to +1. I'm gonna
>>> make some speed tests on this to check the effect of doing such a
>>> change.
>>>
>> Oh, please! I admit speed must be a priority where video is concerned, 
>> but certainly not for sound!
> 
> You commit the error of thinking only of totally overblown
> desktop/server systems. For embedded systems things like this make the
> difference between being able to support and audio format or not (though
> admittedly for most of those systems nothing that uses float at all will
> work).
> In addition I have also heard about servers that decrypt 50 or more
> audio streams at once, I guess there things like these will matter as
> well.

I would think in such a case, I/O and possibly memory and cache would be 
the limitation. But yes, if a machine has to emulate FPU, then we need 
to have the equivalent of -pix_fmt, and the codecs will have to support 
several output codings.


-- 
Michel Bardiaux
R&D Director
T +32 [0] 2 790 29 41
F +32 [0] 2 790 29 02
E mailto:mbardiaux at mediaxim.be

Mediaxim NV/SA
Vorstlaan 191 Boulevard du Souverain
Brussel 1160 Bruxelles
http://www.mediaxim.com/