On Fri, 29 May 2020 at 14:11, Michael Niedermayer <mich...@niedermayer.cc> wrote:
> On Thu, May 28, 2020 at 11:57:38PM +0100, Kieran Kunhya wrote: > > > > > > More generally though (outside this unsafe flag case) > > > i do disagree with your argument a bit, performance does matter. > > > Iam regularly reminded of that for example, so much software becomes > > > slower on each upgrade with few if any features added the real users > > > care about. Just to pick one, the editor i use to write replies in mutt > > > is slower to close than before i upgraded the OS. > > > > > > Also again to stay general here, this does not apply to the unsafe > flag. > > > speed / cpu load does add up. Slower code means more CO2 emissions if > > > the software is used alot. > > > If you want a real example insetad of this flag where we could improve > > > IIRC there was some code iterating over options in the iteration over > > > options resulting in some sort of O(n^3) or so. Thats from memory > though > > > would need to check where that was exactly but thats something we > should > > > fix. > > > > > > > Please provide evidence that the H.264 Decoder has got slower. > > while, what you quote above was not about h264 at all > let me provide benchmarks of most fate h264 samples with and without > flag_unsafe > the script that made that is after it. a reply to the 2nd part of your > mail is > also below > Yes, it's no surprise that a "fast" mode that violates the spec to produce some undefined and unsafe output is going to be faster. The responses are "aggressive" because many people want "fast" mode gone. I also would like it gone and I think the consensus is there to remove it. Kieran _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
