[FFmpeg-devel] suggestion for expanding audio bitdepth support in libav/ffmpeg
Mon Jan 21 15:02:40 CET 2008
On Mon, Jan 21, 2008 at 11:48:47AM -0000, M?ns Rullg?rd wrote:
> Benjamin Larsson wrote:
> > Andreas ?man wrote:
> >> 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.
> > Well I'm not sure that would work with 24bits data. And I don't like the
> > idea of codecs outputting scaled samples that something else has to
> > rescale. What's wrong with codecs being able to output regular float and
> > fast_float(range in 384 to 386) depending on the availability of SIMD?
> SIMD availability is irrelevant. That said, being able to select scale
> and bias would make sense.
adding float scale and bias to AVCodecContext and a CODEC_CAP_FASTBIASSCALE
should be easy
also it would allow some volume control for free ...
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel