Unable to find actual suspect through code search and also observing no CL's under regression range, hence adding appropriate label and requesting someone from dev team to look in to this issue.

xhwang@, can you please look into this change (https://chromium.googlesource.com/chromium/src/+/9b8b4b6867da07ca898e680e040c2c8342d5538e) and see if it's related?

Here is the change log: https://chromium.googlesource.com/chromium/src/+log/676d68809d3c70bdde04c81d9c87342fb93e38d8..858c0de5ad1cc3086efb0aa4a7ab082eb857753b?pretty=fuller&n=10000

Thank you!

I think this is just a new find due to 6d7b69ac40b01d87e8499cb8232631c69bd3269a. +mmoroz

I'll take a look tomorrow, but it shouldn't be P1.

Yeah, it might be. The new instrumentation is slower, but should be more efficient than the old one.

[0830/161045.320248:ERROR:vpx_video_decoder.cc(161)] Decode: timestamp=0 duration=0 size=12 side_data_size=0 is_key_frame=0 encrypted=0 discard_padding (us)=(0, 0)
[0830/161059.855760:ERROR:vpx_video_decoder.cc(326)] vpx_codec_decode() error: Corrupt frame detected

~14 seconds to fail out. So does seem to take quite a while on a single vpx frame, it's not asking the FrameBufferPool for any huge amounts of memory that I can tell either. I'm not sure what's taking so long inside the Decode() call, so =>jzern in case this is something worth caring about.

Let's let this cycle after:

https://chromium-review.googlesource.com/c/webm/libvpx/+/1197202

I missed that this had vp8 in the stacktrace. The change in comment #6 was for vp9. Given the regression range it doesn't look like anything changed in libvpx, but that doesn't rule out an existing issue in vp8. This is worth taking a look at locally, Jerome can you have a look?

The tested video has very big frames (541 mb_rows and 588 mb_cols which means the resolution is about 9393*8656). The timeout limit is set to 25 seconds which is not long enough to finish the run.

--timeout=50 will work.

I didn't get error (corrupted frame) mentioned in comment #5.

Re c#8, unfortunately we don't support timeout values bigger than 25 seconds. Would it be possible to reject inputs which are too large?

That information could be extracted from the bitstream header, it's pretty early on in the keyframe header. Chrome would still accept the files so this should be a last resort if there isn't something else about cases like this that can be used to fail more quickly.

ClusterFuzz testcase 6333945789284352 appears to be flaky, updating reproducibility label.

Please ignore the last comment about testcase being unreproducible. The testcase is still reproducible. This happened due to a code refactoring on ClusterFuzz side, and the underlying root cause is now fixed. Resetting the label back to Reproducible. Sorry about the inconvenience caused from these incorrect notifications.

Please ignore the last comment about testcase being unreproducible. The testcase is still reproducible. This happened due to a code refactoring on ClusterFuzz side, and the underlying root cause is now fixed. Resetting the label back to Reproducible. Sorry about the inconvenience caused from these incorrect notifications.