wm4 <[email protected]> skrev: (24 februari 2016 11:51:26 CET) >On Wed, 24 Feb 2016 10:32:24 +0000 (UTC) >Carl Eugen Hoyos <[email protected]> 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 >[email protected] >http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Good point. -- Mats Peterson http://matsp888.no-ip.org/~mats/ _______________________________________________ ffmpeg-devel mailing list [email protected] http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
