[FFmpeg-devel] [PATCH v3] ffprobe: Add bits_per_component to stream output
t.rapp at noa-audio.com
Fri Sep 5 13:40:17 CEST 2014
On 05.09.2014 11:56, Stefano Sabatini wrote:
> On date Friday 2014-09-05 08:29:45 +0200, Tobias Rapp encoded:
>> On 04.09.2014 17:39, wm4 wrote:
>>>> diff --git a/libavutil/pixdesc.h b/libavutil/pixdesc.h
>>>> index 41e81db..f8af18f 100644
>>>> --- a/libavutil/pixdesc.h
>>>> +++ b/libavutil/pixdesc.h
>>>> @@ -251,6 +251,13 @@ int av_get_bits_per_pixel(const AVPixFmtDescriptor *pixdesc);
>>>> int av_get_padded_bits_per_pixel(const AVPixFmtDescriptor *pixdesc);
>>>> + * Return the number of bits per component (bit depth) for the pixel format
>>>> + * described by pixdesc or 0 if the pixel format has unknown or non-uniform
>>>> + * bit depth.
>>>> + */
>>>> +int av_get_bits_per_component(const AVPixFmtDescriptor *pixdesc);
>>>> * @return a pixel format descriptor for provided pixel format or NULL if
>>>> * this pixel format is unknown.
>>> Does something such highly specialized really warrant its own API
>>> function? There are several ways how to handle the case if the
>>> component bit depths are not uniform, or even how the term "bit depth"
>>> is to be interpreted, so IMO this should just be internal to ffprobe.
>> That would also be fine for me. Do you suggest to put it directly in
>> ffprobe.c or cmdutils.c or some other file?
> Alternatively, we expose the pixdesc information through a specific
> ffprobe option (-show_pixel_descriptions?) so it can be processed by
> the caller.
You mean something like -pix_fmts with enhanced information in a more
machine readable format?
> The problem with the current approach is that it leads to
> inconsistency, the bits-per-component information is not really
> related to the stream but is computed starting from the pix_fmt
> information, which is duplicated in other parts of the ffprobe
That's true. I can also imagine that other parts of pixdesc information
could be added later (nb_components, chroma sub-sampling, alpha/rgb
flags) so this would mean a rather large amount of duplicated information.
> Having to process the output of ffprobe -show_pixel_descriptions may
> require much work but would provide a more general solution (and it
> would be useful for other purposes). Would that be acceptable to you?
If the output is somehow machine readable (e.g. format based on
-print_format) I agree that your proposal should be preferred.
Thanks for the feedback. Will try to come up with a new patch within the
More information about the ffmpeg-devel