[FFmpeg-devel] [PATCH 1/3] avcodec/vp56: Require 1 undamaged frame for 5 damaged frames for concealment to be used

Michael Niedermayer michael at niedermayer.cc
Wed Mar 15 20:51:47 EET 2017

On Wed, Mar 15, 2017 at 08:58:39AM -0400, Ronald S. Bultje wrote:
> Hi,
> On Wed, Mar 15, 2017 at 8:21 AM, Kieran Kunhya <kierank at obe.tv> wrote:
> > On Wed, 15 Mar 2017 at 12:05 Ronald S. Bultje <rsbultje at gmail.com> wrote:
> >
> > > Hi,
> > >
> > > On Tue, Mar 14, 2017 at 11:12 PM, Michael Niedermayer <
> > > michael at niedermayer.cc> wrote:
> > >
> > > > Fixes timeout with 847/clusterfuzz-testcase-5291877358108672
> > > > Fixes timeout with 850/clusterfuzz-testcase-5721296509861888
> > > >
> > > > This likely will need to be tweaked
> > >
> > >
> > > Sorry, but this is getting insane. I can't possibly be expected to just
> > > approve this. What's your end game?
> > >
> >

> > I have tons of testcases for h264 that are 1KB and can make error
> > concealment run for ages.

and how is this related to a fix for th vp* decoder ?

> > Trying to fix them will just become a never ending set of heuristics to
> > guess the conditions like the above.

Thats only true to some extend. The issue that a file can take a long
time to decode isnt fixable, a file can always have a long duration
and high resolution.
The issue that a file that has few bytes size takes a long time to
decode can be fixed for some codecs.
Id say we should fix this where it can be done cleanly.
In formats that allow one to encode gigabyte sized blue frames in 1
byte theres no fix possible OTOH.

In cases where it is fixable the fix has to ensure that theres a
limit on the computations per byte. Thats exactly what happens by
limiting the number of concealed frames in relation to error free
frames. Keep in mind a "fixable" codec implies that undamaged frames
would not require unbound computational resources per byte.

> Right. Also, this is fuzz-specific code. I've made remarks about this
> before, but I'll say it again: ideally, I don't want fuzz-specific code
> anywhere. Especially not "carefully crafted" crap like this.

> I'm actually starting to believe that the error concealment code in this
> decoder (vp56) is fuzz-specific code also. Is there a real-world input
> where the user experience is improved by this code?

I have no real world damaged vp56 files iam aware of, in fact i dont
think i remember seeing vp56 in the wild, what i have are just our
samples or at least thats what iam concioulsy aware of

Damaged data is inevitable though from packet loss, damaged sectors
and other, so damaged data is real it occurs with anything eventually
that is stored or transmitted. The only way it can never occur is if
a codec is never used more or less

and error concealment can provide better quality than lack of EC.

when fixing fuzz issues iam trying to do something usefull when theres
a related feature like implementing the very basic EC code in vp56.
Working error concealment code would be nice for every codec IMO

but if people dont want EC code in vp56 then we can drop this code of
course, makes no difference to me.

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20170315/8b3ed1c1/attachment.sig>

More information about the ffmpeg-devel mailing list