[FFmpeg-devel] Audio conversion and floating-point codecs
Sat Jul 10 12:06:15 CEST 2010
On Sat, Jul 10, 2010 at 11:42 AM, Jean-Daniel Dupas wrote:
> Le 10 juil. 2010 ? 11:14, Axel Holzinger a ?crit :
> > Hi Peter et al,
> > On Sat, Jul 10, 2010 at 10:51 AM, Peter Ross wrote:
> > [...]
> >>> Regarding audio sample format, wouldn't an approach be nice
> >>> the user (the one using libav...) can define the native
> audio sample
> >>> format from a supported list (i.e. uint8_t, int16_t,
> int32_t, float,
> >>> ...) as the default sample format that all audio
> functions will then
> >>> use? Like a C++ template that can be instatiated with uint8_t,
> >>> int16_t, etc.
> >>> I know this is a bunch of work, because it concerns so
> many parts in
> >>> the code. But if thinking about adding more support than sole
> >>> int16_t (which is a good idea I think and high time), all the
> >>> possibilities should be on the table.
> >> we already support this via sample_fmt.
> >> (in the proposed implementation, frame->data[n] would by
> typecast to
> >> the datatype used by codec->sample_fmt. e.g.
> >> 16-bit signed interlaved, 32-bit float planar..)
> > sample_fmt is a codec property, would this be FFmpeg system wide
> > only codec wide?
> > Is the idea that every codec should be able to support all
> the formats
> > that are considered being standard formats (enum
> SampleFormat) or is
> > it up to the user to check the format the codec is
> > accepting/delivering and converting it from/to the "system
> Isn't sample_fmt equivalent to pix_fmt for images ?
> I imagine you may have some negotiation between client and
> codec to get the best format, and also have a swscale library
> for audio that provide a simple way to convert a sample
> from/to native codec format.
That was indeed the question. Will the client have to convert because
every codec will deliver its most admired format or if the codecs will
"know" the system wide chosen format and already deliver in that
I'm just thinking of cases where the desired format will have a higher
precision than what a codec would choose without "knowing" that a
higher precision was desired. A later conversion would then only
generate zeroes, while using a higher precision in the first place (in
the codec) would have generated more precise data. Of course this
example is based on decoding.
More information about the ffmpeg-devel