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

Mats Peterson matsp888 at yahoo.com
Wed Feb 24 11:56:40 CET 2016


wm4 <nfxjfg at googlemail.com> skrev: (24 februari 2016 11:51:26 CET)
>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.
>_______________________________________________
>ffmpeg-devel mailing list
>ffmpeg-devel at ffmpeg.org
>http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Good point.
-- 
Mats Peterson
http://matsp888.no-ip.org/~mats/


More information about the ffmpeg-devel mailing list