[FFmpeg-devel] [PATCH v3] ffprobe: Add bits_per_component to stream output

[Tobias Rapp]

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
> output.

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 
next days.