[FFmpeg-devel] [patch] glob matching for image series

[Alexander Strasser]

Hi Brian,

  very nice to hear you commenting on my proposal.

Brian Olson wrote:
> On Feb 27, 2012, at 2:11 PM, Alexander Strasser wrote:
> 
> >  Instead I would propose following ideal behaviour:
> >  1. Support globbing not only for picture input.
> 
> So, I think you mean that ideally everything that can accept multiple inputs via -i a -i b -i c would accept -i '[abc]'  (OR --input-glob '[abc]' if I understand your point 2)

  Yes, you got both of them right. Though for point 2 the name should be more
in the style of the existing ffmpeg options.

> >  2. Do it only if it was explicitly enabled
> 
> Explicitly enabled - at compile time or option time? (I'm guessing you mean something like the second)
> ./configure --with-glob
> OR
> ffmpeg --input-glob \*.jpg

  Yes, this one. (Also see comment above.)

  Another advantage of doing it that way is the average user doesn't need to
double escape characters that she didn't want to be expanded by neither her
shell nor ffmpeg.

> The current image sequence input has extra machinery to do expansion of %d  (or now glob) style image names, and seems to do that pretty well. I feel like something would be less efficient doing -i 1.jpg -i 2.jpg -i 3.jpg or an equivalent --image-glob that uses common code to expand the glob and pass thousands of frame arguments to the img import code. Or maybe it would be fine.

  You are right, it might not be trivial and that is why I said ideally in
the first sentence and advised to leave it out for now. If it can be done
cleanly, it can be done as incremental work. Also if no one needs/wants it,
we can very well live without it. I just thought it might be an interesting
goal and very convenient from time to time.

> >  3. Agree on a set of features like ?*[]{} and fail if is not available
> >     (maybe with the additional possibility to force it on with what is
> >      available)
> >  4. Tell the user if he requested to enable globbing but it wasn't
> >     available at all in his lavf binary.
> 
> My thinking behind the set of flags for glob is that I first read the documentation for an expanded non-posix glob() and thought "yes, all of these are good features, I want them" .. and then noticed that many are non-posix and shouldn't be relied on. In some more-is-better sense, having them is better than not having them. It does lead to possible inconsistency between ffmpeg deployments, but the ones that have it are better, right?

  OK, what do you want to have? I think we can go with it easily: I will
follow you on your next comments and it should be no problem.

  Maybe it is better to only go for one way of tilde expansion though. The
difference might be subtle when it is working one way on one machine and the
other way on another which I would like to avoid. It is IMHO a pain to explain
to users or to document in manuals.

> >  I know this is controversial, especially point 3. Also I do think point
> > 1 could left out at first and left as possible future enhancement.
> > 
> >  The described behaviour would allow for implementation of applications
> > that behave consistently across platforms. That is a property I appreciate
> > very much and that I would like to see from FFmpeg programs and libraries.
> 
> More consistency would be available if someone reimplemented an expanded glob() and bundled that source into ffmpeg, but of course that's maybe not the best thing to do either.

  Not really better; though it might not be that unreasonable after all. But
let's try without it first!

> 4 seems pretty uncontroversial. It could be pretty straightforward now to detect glob-chars in the filename (using the is_glob() function being added in this patch) and at least emit a warning if glob() was not compiled in.

  How about handling point 4 the same as point 3? Make it possible to tell if
anything or all (no glob() available) is missing in the binary and emit a
warning via av_log. The latter information that all is missing should be
available via the configure #define already.


  Alexander