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

[James Almer]

On 3/15/2017 3:51 PM, Michael Niedermayer wrote:
> 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

Afaik, old flv videos used VP6 (libavcodec reports them as vp6f). There
are some real world files out there, like video game trailers.
I have a Diablo 3 and a Starcraft 2 trailers encoded in VP6 here if you'd
like to check them.