Hi Doug, > On Oct 18, 2017, at 4:15 PM, Douglas Marsh <ffm...@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). Devin _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
