On 17/01/2019 23:33, Michael Niedermayer wrote: > Would you be ok with rejecting RSCC files without a keyframe ? > or more precissely all frames before a keyframe and thus if there is > no keyframe the whole file > (that would be a superset of what this patch rejects)
This, to me, soundsp preferable, if hidden under ER being disable or something. > > I suggested that arbitrary check above as it would allow decoding more data > in case of a damaged or lost keyframe [...] > The gain these changes have is they increase the cost for an > attacker in a DOS attack. (they also improve the efficiency of the fuzzer but > thats secondary) By this logic, every single optimization is an anti-DoS measure and can be argued ad nauseam in favor of every such changed, regardless of cost. > As is you can have a file with huge resolution where each frame only encodes > 1 pixel in about a dozen bytes per frame. That transforms a very low cost of > network bandwidth from an attacker to a rather large computational cost on > anything processing such file. You don't need to explain what a DoS is to us... > Requiring more than 1 valid pixels in a billion or Requiring a valid keyframe > would increase the cost for an attacker. This is not codec specific, either. > Also do you see a cleaner way to achive this as the author of this > decoder ? People are disagreeing with the premise, not the implementation. - Derek _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel