[FFmpeg-devel] [PATCH]lavf/img2enc: Allow to reverse frame order

wm4 nfxjfg at googlemail.com
Wed Feb 24 11:51:26 CET 2016


On Wed, 24 Feb 2016 10:32:24 +0000 (UTC)
Carl Eugen Hoyos <cehoyos at 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.


More information about the ffmpeg-devel mailing list