[FFmpeg-devel] [PATCH] deprecate SAMPLE_FMT_S24

[Aurelien Jacobs]

Michael Niedermayer wrote:

> On Sun, Aug 17, 2008 at 03:32:30PM +0200, Aurelien Jacobs wrote:
> > Peter Ross wrote:
> > 
> > > This patch flags SAMPLE_FMT_S24 as deprecated.
> > 
> > So what will happen if a user suply a 32-bits pcm sample and re-encode
> > it with a supposedly lossless encoder which only support 24-bits ?
> > There is no way to tell the user that the encoding won't be lossless.
> > There is also no way for the 24-bits encoder to apply dithering to
> > 32-bits samples (it would mess-up the real 24-bits samples stored in
> > 32-bits).
> > Also, what happens if you transcode a 24-bits sample to wav (pcm) ?
> > The "encoder" will have no way to know that it's a 24-bits sample
> > and will store it as 32-bits. This is a huge waste of bytes.
> > 
> > IMO, SAMPLE_FMT_S24 is useful, even if it's treated internally the
> > exact same way as SAMPLE_FMT_S32. This allows encoders to behave
> > more sensibly if desired.
> 
> and 20bit 22bit 18bit ...
> 
> I think a field in AVCodecContext that simply contains the number of
> bits in there would be more flexible.

I'm fine with another field in AVCodecContext.
As long as encoders have way to know the number of actually meaningful
bits in their input, that's fine.
It may be enough to set the output avctx->bits_per_sample to the same
value as the input one in ffmpeg.c or something like that.

> But i have no strong oppinion on this, we can keep SAMPLE_FMT_S24
> if you prefer

Not really. As long as the encoder knows it's input bits_per_sample,
I'm OK with dropping SAMPLE_FMT_S24.

Aurel