[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