@frankplow. It looks like this PR has fixed all the fuzz tests. Could you please double-check on your side and review it? Your insights would be greatly appreciated!

@frankplow. It looks like this PR has fixed all the fuzz tests. Could you please double-check on your side and review it? Your insights would be greatly appreciated!

Hi, hope you're well!

Thank you very much for your patches. With this set applied, plus the fix for AV_CEIL_RSHIFT, I now only get a failure for one bitstream: 000311.bit. Ultimately this is due to the fact the subpicture structure is invalid: the picture is 704x576 luma samples with four subpictures, where pps->subpic_x, pps->subpic_y, pps->subpic_width and pps->subpic_height are as follows:

• pps->subpic_x = {0, 96, 0, 352}
• pps->subpic_y = {0, 0, 288, 288}
• pps->subpic_width = {352, 352, 352, 352}
• pps->subpic_height = {288, 288, 288, 288}

The first and second subpictures overlap in the region between (96,0) and (352,288) and the region between (448,0) and (704,288) is not covered by any subpicture.

Generally, I think these patches address some of the issues which could previously result from an invalid subpicture structure (those where pps_single_slice_per_subpic_flag = 1 and consequently the slice structure is also invalid) and should serve well to improve the robustness of the code. I still don't think they validate the subpicture structure itself however, and I don't see any way to do so besides the approach I previously put forward on the ML. Perhaps we could continue with the current approach to address the possible consequences of an invalid subpicture structure (I am not familiar with how subpics interact with inter prediction, I'm not sure how difficult this will be), but I feel it will be best to address the issue at its root by validating the subpicture structure, as this will not only fix these issues we have now, but also prevent issues in future, such as if we wished to implement subpicture extraction.

Hi @frankplow ,
Will 000311.bit crash on your side?

The first and second subpictures overlap in the region between (96,0) and (352,288) and the region between (448,0) and (704,288) is not covered by any subpicture.

It's challenging to validate everything comprehensively, as the process can be inefficient and prone to errors.
For an invalid clip, as long as it doesn't cause a crash, it should be acceptable.

I am not familiar with how subpics interact with inter prediction

inter mv and all filters will clip at subpic boundaries. see https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=11302

Hi @frankplow , Will 000311.bit crash on your side?

The first and second subpictures overlap in the region between (96,0) and (352,288) and the region between (448,0) and (704,288) is not covered by any subpicture.

It's challenging to validate everything comprehensively, as the process can be inefficient and prone to errors. For an invalid clip, as long as it doesn't cause a crash, it should be acceptable.

I am not familiar with how subpics interact with inter prediction

inter mv and all filters will clip at subpic boundaries. see https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=11302

Hi @nuomi2021, hope you're well. With the latest changes, 000311.bit no longer crashes for me, and I no longer have any crashing bitstreams 🎉

Hi @nuomi2021, hope you're well. With the latest changes, 000311.bit no longer crashes for me, and I no longer have any crashing bitstreams 🎉
Great! could you also help upload all fuzz test clips until 000318.bit

thank you

applied FFmpeg/FFmpeg@4de67e8
Thank you for the review