[FFmpeg-devel] [PATCH] Get rid of SAMPLE_FMT_S24
Sun Nov 18 17:31:54 CET 2007
Justin Ruggles a ?crit :
> Baptiste Coudurier wrote:
>> Michael Niedermayer a ?crit :
>>> On Sun, Nov 18, 2007 at 02:35:17PM +0100, Baptiste Coudurier wrote:
>>>> Andreas ?man a ?crit :
>>>>> see $subj
>>>> Some codecs support 24 bit (alac, flac, aes3, dvd) samples, decoders
>>>> should output what is stored, ideally, so I don't see why SAMPLE_FMT_S24
>>>> should be dropped.
>>> there are no 24bit ints stored, what is stored are various vlc codes
>>> outputing them as 32bit is faster and more natural than 24bit
>>> also working with 32bit is a lot easier than 24bit, so few if any filters
>>> would support 24bit ...
>> There are 24 bits ints stored, in dvd pcm and aes 3 at least.
>> You are IMHO messing up sample format and stored format.
>> SAMPLE_FMT_S24 depicts the sample value range is using 24 bits.
>> I still don't see why SAMPLE_FMT_S24 should be dropped.
>> In contrary I think a better mechanism should be added, like
>> WAVEFORMATEXTENSIBLE does, if you want to tell application that sample
>> is on 24 bits but stored on 32 bits.
> How about:
> AVCodecContext.sample_fmt = SAMPLE_FMT_S32
> AVCodecContext.bits_per_sample = 24
> I tend to agree with Michael here. Working natively with 24-bit samples
> is not very useful or easy.
Well, that would mean padding and copying to specify SAMPLE_FMT_S32, for
at least aes3, dvd pcm, in24, all pcm variants which are using 24 bits
to store samples > 16 and <= 24 bits.
I don't know any format using 32 bits to store those samples.
For 20 bits samples (aes3, dvd pcm), storing on 32 bits will make you
loosing 12 bits per samples, this is IMHO huge.
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
checking for life_signs in -lkenny... no
More information about the ffmpeg-devel