On 07/06/2011 06:53 AM, Stefano Sabatini wrote: > On date Sunday 2011-06-05 19:37:36 -0400, Justin Ruggles encoded: >> On 06/05/2011 07:27 PM, Justin Ruggles wrote: >> >>> On 06/05/2011 06:31 PM, Stefano Sabatini wrote: >>> >>>> /** >>>> * Bits per sample/pixel of internal libavcodec pixel/sample format. >>>> * This field is applicable only when sample_fmt is AV_SAMPLE_FMT_S32. >>>> * - encoding: set by user. >>>> * - decoding: set by libavcodec. >>>> */ >>>> int bits_per_raw_sample; >>> >>> >>> This just describes the accuracy of the data inside the internal >>> libavcodec sample *after decoding* or *before encoding*. For example, >>> 24-bit audio data in AV_SAMPLE_FMT_S32 is still scaled to 32 bit range >>> as required by the sample format, but this field is set to 24 to >>> indicate that there is only 24 bits of information. So say you want to >>> convert 24-bit audio from 1 lossless codec to another lossless codec, >>> the encoder will know that it can discard the low 8 bits and encode in >>> 24-bit mode if it has one because bits_per_raw_sample is 24. >>> >>> bits_per_coded_sample refers to the size of the samples *before >>> decoding* or *after encoding*. >>> >>> The 2 values may be the same, and probably are in most cases, but >>> they're used for different purposes. bits_per_raw_sample depends on the >>> decoder implementation and sample format, where-as bits_per_coded_sample >>> depends only on the CODEC_ID and thus is the one used by libavformat. >> >> >> sorry... i just realized that last sentence isn't 100% true. >> bits_per_coded_sample does depend on the CODEC_ID, but sometimes it can >> be different for the same CODEC_ID and can be signaled as such by the >> demuxer (e.g. wavpack). theoretically the demuxer might not even know >> and might rely on the decoder init. but still bits_per_raw_sample and >> bits_per_coded_sample have different meanings. > > Check patch. > > The only drawback of the patch seems that the new > avcodec_get_bits_per_coded_sample() is only able to get the value for > *registered codecs* (which is not necessarily a problem), and requires > to iterate through the list of registered codec for getting the > information (this may be fixed by introducing an efficient search data > structure), but insofar should not have efficiency penalties since I'm > calling that function only during the init stage. > > Possibly we may move the code which sets the > avctx->bits_per_coded_sample in the libavcodec/utils.c. > > Comments are welcome.
bits_per_coded_sample is a stream property based on the codec_id and/or specified by the container. Accessing that information via AVCodec doesn't seem correct to me. AVCodec has implementation information, not stream/codec information. I like the name. I agree that accessing avctx->bits_per_coded_sample directly when possible is better, and also I do think it could be set in libavcodec/utils.c. But what is the problem with the current implementation? -Justin _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
