Automatically adding ccs based on OWNERS file / target commit history.

If this is incorrect, please add ClusterFuzz-Wrong label.

I have a local repro: 57 seconds local execution time for the repro case. Investigating.

This looks less like an MP4-specific issue. Rather it is the poor performance of media::SourceBufferStream<media::SourceBufferRangeByPts>::Append when performed on every single audio frame.

tl;dr: this looks like behavior that the eventual CL ala https://chromium-review.googlesource.com/c/chromium/src/+/1232485 should fix.

related to part of bug 879970

Data backing up #6: profile of part of a repro run indicates that, out of overall sample time:
~83% of time spent in MP4StreamParser::Parse,
~62% of time spent in FrameProcessor::ProcessFrames,
~30% of time spent in FrameProcessor::FlushProcessedFrames.

(Parse involves running ProcessFrames, which runs FlushProcessFrames).

Also, rerun of the fuzzer case locally with:

Just the ByDts part enabled: 22 seconds
Just the ByPts part enabled: 35 seconds

--> ByPts audio buffering perf (along with, perhaps, MP4 atom count) is culprit behind this issue

In addition to fixing the ByPts audio buffering perf, maybe we should also tighten the sanity checks on number of empty (sample_size = 0 in trun) samples in the track_run_iterator code. Currently, we only check roughly that the sample_count * metadata-per-sample storage footprint doesn't exceed the 'demuxer memory limit'.

cc+sandersd@ for this part.

w.r.t. chat w/Dan on #9, perhaps "we should ban sample size zero if that's not happening in the wild much" --> we should instrument our demuxers (both SRC= and MSE) to see if this happens in the wild much before arbitrarily choosing some cap on number of empty samples in a trun.

(@#10, See bug 907268, focused on just the MSE MP4 case which the fuzzer keeps hitting...)

ClusterFuzz testcase 5495402156261376 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.