On 1/13/2023 11:38 AM, Jan Ekström wrote:
On Wed, Jan 11, 2023 at 9:31 PM James Almer <jamr...@gmail.com> wrote:
This ensures all defined types are supported, even if only to report
their presence and print their size if a custom implementation is
not added.
Signed-off-by: James Almer <jamr...@gmail.com>
---
This patch supersedes:
[PATCH 1/2] avfilter/vf_showinfo: remove superfluous line break
[PATCH 2/2] avfilter/vf_showinfo: add support for raw Dolby Vision RPU side data
By achieving the same effect in a future proof, generic way.
I quite like this approach, and agree with the idea. It did feel weird
that we have a single location which sets human readable names for
side data types, yet it was not utilized.
I think the only drawback is that I'm pretty sure there would be some
side data types printed out now with a different name, and I do know
that some people parse the output of this filter instead of utilizing
ffprobe. Granted, we generally don't promise that log lines are a
machine readable interface. Thus this is not a blocker, but something
to keep in mind.
ffprobe is what we provide for parseable output. Also muxers like
framehash, which are versioned and such. So yeah, av_log() output is not
something we promise will be unchanged.
I wonder if at some point (at the latest when we'll start wanting to
make a generic string/dict based side data setting interface) we'll
want to have separately a "long name" (more human readable) as well as
a shorter identifier similar to AVCodecs' "name".
Jan
Pushed.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
