[FFmpeg-devel] [PATCH v2] ffprobe: Add a few common disposition cases

Stefano Sabatini stefasab at gmail.com
Wed Sep 19 09:48:52 CEST 2012


On date Wednesday 2012-09-19 00:26:47 +0200, Clément Bœsch encoded:
> On Tue, Sep 18, 2012 at 11:24:31PM +0200, Stefano Sabatini wrote:
[...]
> > Having a single field for each separate value is going to be pretty
> > verbose and would require manual updates, so I wonder what's the best
> > way to show flags in this case and in general (may be useful to show
> > codec properties for example).
> > 
> > It could be rendered as a string, something like:
> > disposition=default+attached_pic+forced
> > 
> > On the other hand we don't have a clean way to convert numerical
> > flags to a string (we could add options support to AVStream, and add a
> > flags->string serializer, but that would require some effort and
> > possibly an ABI break), and that would require more parsing on the
> > scripting side (as you need to split the flags in the various
> > components).
> > 
> > An intermediary solution could consist in a manual flags->int
> > conversion, then we may add options support to AVStream and a generic
> > av_opt_get_flags_string(), and rely on that when we will bump major.
> > 
> > What do people think?
> 

> I guess the sustainable solution will be to use your previous section work
> and introduce a disposition section for the flag at some point if it's
> worth the effort. But I'm not even sure from a user point of view it's
> that interesting.

That's indeed seems the right way to represent a flags set. I still
have to think about a sane way to represent it in the writers which
don't support deep nesting (e.g. default).
That could be similar to how we handle tags:
DISPOSITION:default=1
DISPOSITION:attached_pic:1

etc.

> I believed the current patch was good enough and didn't think a more
> complex solution was worth blocking it. The field default field is indeed
> quite useful.

Yes but we should try to follow the most flexible path, or we'll
regret it later (since we can't easily break backward compatibility).

I'll try to push forward my work on subsection nesting.
-- 
FFmpeg = Frightening & Fanciful Mastering Puritan Exxagerate Glue


More information about the ffmpeg-devel mailing list