On 06/05/2011 05:33 PM, Justin Ruggles wrote: > On 06/05/2011 05:00 PM, Stefano Sabatini wrote: > >> On date Sunday 2011-06-05 22:28:22 +0200, Stefano Sabatini encoded: >>> On date Sunday 2011-03-13 17:27:24 -0400, Justin Ruggles wrote: >>>> On 03/13/2011 05:24 PM, Alex Converse wrote: >>>> >>>>> On Sun, Mar 13, 2011 at 2:20 PM, Justin Ruggles >>>>> <[email protected]> wrote: >>>>>> On 03/13/2011 04:59 PM, Stefano Sabatini wrote: >>> [...] >>>>>>> The second one, av_get_bits_per_sample_fmt(), is misnamed (should be >>>>>>> av_get_bits_per_sample()), so we may change the name to >>>>>>> av_get_bits_per_sample2() for avoiding the conflict with the name >>>>>>> already taken. >>>>>> >>>>>> >>>>>> I agree. But as long as we're reworking it, why not >>>>>> av_get_bytes_per_sample() so it doesn't have to be divided by 8 >>>>>> everywhere? >>>>>> >>>>> >>>>> Don't some ADPCM codecs have less than 8 bits per sample. >>> >> >>> First variant attached, if we have no reasons to in the future we >>> won't add some sample format with a non integer number of bytes then >>> I'll post the av_get_bytes_per_sample() variant. >> >> In case the sense of the text above was not clear, I meant: do you >> have some reason to suppose that we may add a sample format with a non >> integer number of bytes? > > no.
Well, I guess maybe someday we might encounter some hardware device that uses fractional bits per sample, in which case it might be nice to convert to such a theoretical sample format in our theoretical future audio conversion lib. So maybe we should have both variants in libavutil to avoid dividing by 8 everywhere now and also stay adaptable to future unknowns. >> If this is not the case, I suppose it is safe to just use >> av_get_bytes_per_sample(). > > > I think it should be av_get_sample_fmt_bytes() to match the other > functions. av_get_bits_per_sample() is something completely different > having to do with the codec, unrelated to the sample format. It's > mostly just a convenience function for libavformat. > > -Justin > _______________________________________________ > libav-devel mailing list > [email protected] > https://lists.libav.org/mailman/listinfo/libav-devel > _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
