[FFmpeg-devel] [PATCH] ALS decoder

Thilo Borgmann thilo.borgmann
Sun Aug 23 13:57:30 CEST 2009

>>> and f course if something can be done about the 64bit that would be great
>>> speedwise ...
>> Unfortunately, the reference decoder also uses 64-bit for them.
> The specification indicates 64-bit as well.  I'm not sure if it is
> possible, but if you can somehow get bit-exact results using 32-bit then
> you should.
What the reference decoder does is to calculate everything using 64-bit
math and test the result if it is out of the limits of 32-bit.

I don't check for 32-bit overflow which might be useful to be added
becuase it might indicate some failure - the calculation would still
deserve 64-bit to detect that failure.
If we assume a non-broken stream, I think using 32-bit math would be safe.

>>>>>>> +        if (sconf->resolution == 2 || sconf->floating)
>>>>>>> +            const_val_bits = 24;
>>>>>>> +        else
>>>>>>> +            const_val_bits = avctx->bits_per_raw_sample;
>>>>>> why would const_val_bits != avctx->bits_per_raw_sample ?
>>>>> bits_per_raw_sample = 32 for floating sconf->floating.
>>>> To explain this further... The way floating-point in ALS works is that
>>>> it has a 24-bit integer part and a floating-point difference part.  So
>>>> the final output is 32-bit, even though the integer part decoded here is
>>>> only 24-bit.
>>> the sconf->resolution == 2 still is useless?
>> The output format in that case is also set to SAMPLE_FMT_S32.
> Even though the output sample format is S32, bits_per_raw_sample should
> still reflect the source bit depth, I think.
Oh, I think all that was meant was the check for sconf->resolution == 2
which is useless because bits_per_raw_sample == 24 in that case, so one
test in the if can be avoided.

Sorry, done.


More information about the ffmpeg-devel mailing list