[FFmpeg-devel] decklink 24/32 bit question

[Douglas Marsh]

On 2017-10-17 12:44, Devin Heitmueller wrote:
>> 
>> The decklink sdk only defines two BMDAudioSampleType values: 
>> bmdAudioSampleType16bitInteger and bmdAudioSampleType32bitInteger. I 
>> don't think there's an easy way to support a 24 bit input here. 
>> Generally in this case I've used bmdAudioSampleType32bitInteger and 
>> then encode it at pcm_s24le.
>> Dave Rice
> 
> For what it’s worth, I’ve got deinterleaving code in the works to
> handle capture of multiple pairs of audio (i.e. break 16 channels into
> 8 pairs and announce them as separate S16LE streams).  If we really
> thought 24-bit was desirable, that code could be adjusted accordingly
> (the hardware would still capture 32-bit, but the deinterleaver would
> put out S24LE).
> 

I am not really sure I follow. I am not sure supporting 24-bit is a big 
issue. A sample size of 32-bit should work fine for most folks. I can 
only think of people (in the output stream) converting to 24-bits (via 
truncate or dither*) to save disk space or pre-processing for some other 
step [compression] (but video is really the bit-hog). I only mentioned 
24-bits because the ADC/DACs are mentioned at supporting PCM 24-bits 
natively meaning the PCI card is (assuming) padding the LSB (hence 
truncate is more logical for any conversion 32->24). AS for what comes 
in digitally over SDI or HDMI is too assumed to only support PCM 24-bits 
(but it is subject to standards that can update).

Making the workflow (stream capturing) of 32-bits is simpler, and moving 
any bit-depth conversion to the output stream side. Only concerns would 
be CPU processing (of which truncating bits is very fast and logical due 
to the assumed padding).

--Doug (dx9s)

*dither= I am not aware of any audio bit-depth dithering algorithms in 
FFMPEG, however it would make sense they do exist as this software is 
quite simply an amazing 'swiss-army knife'