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

[Brian Olson]

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)

>  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


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.

>  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?

>  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.

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.