Ronald S. Bultje <rsbultje <at> gmail.com> writes:
> > As requested on ffmpeg-user.
>
> I'm a little ambivalent to this. Let me explain. You can
> easily fix this with a shell script that creates links
> from img-{1000...1}.jpg to img_2_{1...1000}.jpg and deletes
> them after the ffmpeg run. This is super-trivial.
But the fact that this can be solved with other (non-FFmpeg)
tools never seemed to be an argument here (and I believe this
was usually a good thing): What has changed?
And don't you agree that using two steps to work around a
smalls self-contained patch is generally a very bad idea?
> The problem I have with this is that we're slowly, and very
> very hackishly, extending the sequential image support without
> addressing its fundamental weakness as a non-unix tool:
I am not sure I understand so far, but it may be related.
> it doesn't use shell expansion. I'd want to use
> ffmpeg -i img-*.jpg so it skips non-existing frames,
Could you elaborate?
I believe this either cannot work, or does already work,
depending on what you mean.
In any case, how is this muxer-related patch related to a
demuxing issue you see?
> or use other unix tools to rev the order or whatever,
> shell syntax is great for this but ffmpeg.exe does not
> support any of that.
(I find it striking that you use "shell syntax" and "exe"
in the same sentence...)
> So why hack in this one silly thing if we don't address
> the fundamental problem instead, which would also fix this?
How would fix a demuxing issue (that I don't think was ever
reported, but as said I may just misunderstand you) solve a
real enhancement request by a real user that sounds easily
understandable to me?
Carl Eugen
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
