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

[Michael Niedermayer]

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

also your patch shows no regression with it here

thanks

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20200503/aa19e1a2/attachment.sig>