[FFmpeg-devel] decklink 24/32 bit question
ffmpeg at dx9s.net
Wed Oct 18 23:15:21 EEST 2017
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).
*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'
More information about the ffmpeg-devel