On Wed, 24 Feb 2016 10:32:24 +0000 (UTC)
Carl Eugen Hoyos <ceho...@ag.or.at> wrote:

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

Adding dozens of small very specialized features leads to
unmaintainable and unusable software, even if the change itself is
inoffensive. Powerful, orthogonal mechanisms will always be superior.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Reply via email to