[FFmpeg-devel] [PATCH] ffprobe integration

[Stefano Sabatini]

On date Monday 2010-01-11 12:44:42 +0100, Artur Bodera encoded:
> On Sat, Jan 9, 2010 at 11:47 PM, Stefano Sabatini <
> stefano.sabatini-lala at poste.it> wrote:
> 
> > I like this idea, we could make it even more general, maybe with
> > something like:
> > -format unit+sexagesimal+prefix+byte_binary_prefix
> >
> 
> I don't think it is a good idea, because this makes the format not
> customizable, just "switchable". For further parsing it would be harder, not
> easier, to parse - let's think regex for parsing "-format unit+prefix" vs.
> regex for parsing  "-format sexagesimal+byte_binary_prefix" or whatever
> combination.

I don't see why the commandline itself should be parsed, when you're
scripting you know which options you're setting (so in this case you
know the format of the ouput) so you know how you have to parse.

> To make it easier, other cli-based video manipulation tools (unnamed :-) )
> often use templates.

Please provide the name of the program and I'll do what is possible to
"steal" good ideas ;-).

> If a common naming convention is set, we just need to
> have "--dump-symbols" or "-symbols" that would output all possible
> variables.
> 
> Then we would write for example:
>      ffparse -format "Length: %length_sexagesimal %length_unit (%vframes,
> %fps)"  test.mp4
> 
> or:
>      echo 'Length: %length_sexagesimal %length_unit (%vframes, %fps)' >
> format.txt
>      echo 'Read from a file that has %audio_channels audio channels' >>
> format.txt
>      ffparse -formatfile format.txt test.mp4

That is format.txt in this case is a file specifying the syntax for
the output?

The problem is that it defines the format of a single field, when in
ffprobe now it is just possible to set the format of a *type* of
information (e.g. the format of timestamps, delay times, sizes, etc).
 
> This makes it ultra-flexible and easily extensible. For other tasks (not
> using formats), a generic info template would be used to output all the
> commonly-used information.
> 
> I can read your mind - I know it sucks because it's extra work, but it will
> probably be easier to maintain in the future - for you and other
> maintainers. It would also offer expandability if there is new info to
> output, instead of grepping multiple files, there would be one place to add
> a symbol and one place to add reader/parser.

Also remember that ffprobe is meant to be simple, that is it should be
a thin C wrapper for exposing the information provided by libav*, for
other manipulations I believe we should use some higher level
scripting language, which would allow everything you are proposing.

Regards.
-- 
FFmpeg = Free and Faithless Magic Perennial Elastic Gadget