[FFmpeg-devel] [PATCH] dox/muxers: document how to use glob patterns in the image2 demuxers

[Alexander Strasser]

Stefano Sabatini wrote:
> On date Sunday 2012-08-05 12:13:49 +0200, Alexander Strasser encoded:
> > Stefano Sabatini wrote:
> [...]
> > > diff --git a/doc/demuxers.texi b/doc/demuxers.texi
> > > index 07d82c0..807ad95 100644
> > > --- a/doc/demuxers.texi
> > > +++ b/doc/demuxers.texi
> > > @@ -24,7 +24,22 @@ Image file demuxer.
> > >  
> > >  This demuxer reads from a list of image files specified by a pattern.
> > >  
> > > -The pattern may contain the string "%d" or "%0 at var{N}d", which
> > > +If @code{glob()} is supported on your system, and the provided pattern
> > 
> > NIT: Drop the glob() function reference and associate the support
> >      with lavf and not with the "system".
> > 
> > For example:
> > 
> >   "If your version of libavformat was compiled with globbing support, and..."
> 
> Changed locally.
> 
> >   BTW this reminds me of a comment I had when reviewing the original
> > patch. There is no easy way for the user to find out if the above
> > statement is true, besides trying it with a glob pattern that would
> > match one or more existing files. But again this is unrelated, I will
> > try to come up with a patch (including documentation updates relative
> > to this patch).
> 
> We could show if globbing support is enabled in the demuxer log
> (AV_LOG_VERBOSE), or we could print a warning if the pattern is
> recognized as a glob pattern but globbing support is not enabled.

  I wanted to implement the latter: print a warning if the pattern
would be detected as a glob pattern but the feature is not available.
Should probably not happen very often for most of our users.

> But I think the best solution would be to let the user specify the
> pattern type (e.g. -pattern glob|sequence), which will also avoid the
> need for % escaping in the glob pattern.
> In case the user selects:
> -pattern glob 'img-*.png'

  This was rejected back then (discussion excerpt follows).

Alexander Strasser wrote:
|Nicolas George wrote:
||Le nonidi 9 ventôse, an CCXX, Alexander Strasser a écrit :
|||   2. Do it only if it was explicitly enabled
||
||I find that rather user-unfriendly. OTOH, having options to ensure the mode
||of expansion would be useful for robust automated scripts:
|
|  I see. What do you think about the attached patch? It builds directly on
|Brian's work and tries to be user-friendly and consistent while not making
|currently working use cases more hard/impossible when globbing is compiled
|in.
|
|  The few examples are given in the patch commit message. I also attached
|my complete test log so you can dig in deeper. Beware the examples found
|in the test log are rather extreme to test more corner cases.
|
|| ffmpeg -f img2 -expand printf photo%05d.jpg
|| ffmpeg -f img2 -expand glob   photo\*.jpg
|
|  Looks like a nice idea. I am OK with adding such features later on.

> and libavformat has no glob support it will complain and fail
> loudly.
> 
> This should also allow other types of pattern in case of need
> (e.g. regexp, timestamps etc.).

  Taking into account the initial discussion and the time the feature
is available now; I tend to say leave it as it is now, and go for the
explicit variant with additional private option when someone wants to
add yet another pattern type.

  But not a really really strong opinion here. How about you?

> Since we still didn't document the glob feature, it should be no much
> harm to change the syntax now.

  This is not true however, as I said before the glob feature is
documented at a much more visible place in the earlier section
"Video and Audio file format conversion" of the ffmpeg manual.

  Alexander