[FFmpeg-devel] decklink 24/32 bit question
dheitmueller at ltnglobal.com
Wed Oct 18 23:27:15 EEST 2017
> On Oct 18, 2017, at 4:15 PM, Douglas Marsh <ffmpeg at dx9s.net> wrote:
> 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).
I think you and I are on the same page. It wasn't clear to me what would prompt someone to say they want 24-bit audio as opposed to 32 (which is way easier to work with because of alignment). That said, if you had such a use case I think this could be done.
That said, I'm all about not adding functionality nobody cares about.
Thanks for adding this functionality, as I need it to reliably do compressed audio detection (which is next on my list after support for multi-channel audio is working).
More information about the ffmpeg-devel