[FFmpeg-devel] [PATCH 1/2] avcodec: Add AV_CODEC_FLAG2_FAST_UNSAFE, move unsafe uses of FAST to it

[Kieran Kunhya]

On Fri, 29 May 2020 at 14:11, Michael Niedermayer <michael at 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