On 03/05/2020 23:38, Mark Thompson wrote: > On 03/05/2020 19:14, Michael Niedermayer wrote: >> On Sun, May 03, 2020 at 04:30:00PM +0100, Mark Thompson wrote: >>> If the RPS we are predicting from has maximum size then at least one of >>> the pictures in it must be discarded before adding the current one. >>> >>> Also revert 588114cea4ee434c9c61353ed91ffc817d2965f5, which added >>> now-redundant checks for the special case of a too-large RPS with all >>> pictures being in the same direction from the current one. >>> --- >> >>> It would be helpful to test this on the fuzzing samples from >>> 20446/clusterfuzz-testcase-minimized-ffmpeg_BSF_HEVC_METADATA_fuzzer-5707770718584832 >>> which prompted the original incomplete fix. Is there somewhere I can find >>> them? >> >> yes, the samples are automatically made public based on some rules >> like timelimits and if they are fixed, if they are reproduceable, ... >> this one should be public since 3 days and here: >> https://oss-fuzz.com/download?testcase_id=5707770718584832 > > Ha, cute. A stream with enough RPS entries hits this by overwriting with > all-ones in the SPS, because an all-ones RPS reads as inter predicted from > the previous RPS with all pictures used. > >> also your patch shows no regression with it here > > Confirmed here as well. > > Will apply tomorrow if there are no other comments.
Tomorrow came slightly later than expected. Applied. Thanks, - Mark _______________________________________________ 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".
