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 <kier...@obe.tv> wrote: > > > On Wed, 15 Mar 2017 at 12:05 Ronald S. Bultje <rsbul...@gmail.com> wrote: > > > > > Hi, > > > > > > On Tue, Mar 14, 2017 at 11:12 PM, Michael Niedermayer < > > > mich...@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
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
