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'
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
