[FFmpeg-devel] [PATCH] cbs_h265: Ensure that a predicted RPS doesn't contain too many pictures

[Mark Thompson]

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