lör 2019-09-28 klockan 17:47 +0200 skrev Michael Niedermayer: > On Thu, Sep 12, 2019 at 11:09:16PM +0200, Tomas Härdin wrote: > > tor 2019-09-12 klockan 00:21 +0200 skrev Michael Niedermayer: > > > On Wed, Sep 11, 2019 at 11:18:47PM +0200, Tomas Härdin wrote: > > > > tis 2019-09-10 klockan 16:16 +0200 skrev Michael Niedermayer: > > > [...] > > > > I've said multiple times that worrying about these timeout things is > > > > mostly a waste of time since any serious user will know to put time > > > > limits on jobs. > > > > > > Everyone probably has timelimits on jobs but these timeouts are still > > > a big problem. And i think this was discussed before ... > > > > > > I think if you just think about what timeout to use for each case > > > A. a web browser loading image, video and audio files > > > > Presumably browser devs know how to use TBB and friends. They also > > don't use g2meet, or cinepak, or anything else that isn't H.26* or VP* > > etc. Closest thing is GIF > > > > > > Resources would be better spent gearing the fuzzing > > > > toward finding memory corruption issues, since the harm from them is > > > > far more serious. > > > > > > Then fixing the timeouts would be a priority as they hold the fuzzer > > > up from finding other issues. > > > Time spend waiting for a timeout is time the fuzzer cannot search for > > > other issues > > > > I see this more as a fuzzer tuning thing. When I last did fuzzing with > > afl I certainly made sure to give it tiny samples and not a lot of time > > per round > > > > Question: is the fuzzer really allowed to spend 120 seconds on a test > > case like this one? Or is that timing just an after-the-fact thing? > > The fuzzer has a timeout of 25 seconds IIRC. Thats on the machiene > google runs it on. So local times (which is what would be listed in a > patch) will always differ a bit
OK, that sounds a bit more reasonable. > So what shall we do about these 2 patches here ? > Ok to push or do you want me to do something else ? Nah go ahead. They don't seem to hurt, beyond being a few more lines of code. /Tomas _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
