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.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
