[FFmpeg-devel] Audio conversion and floating-point codecs

Axel Holzinger aholzinger
Sat Jul 10 12:06:15 CEST 2010


Bonjour Daniel,

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
where 
> >>> 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
or 
> > 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
format"?
> > 
> 
> 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
format.

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.

Cheers
Axel




More information about the ffmpeg-devel mailing list