Predator and CL could not provide any possible suspects.
Using Code Search for the file, "source_buffer_stream.cc" assigning to the concern owner.

Suspecting Commit#
https://chromium.googlesource.com/chromium/src/+/c485d6c706fe27268948c43e71ef9f68e743bcf7

@wolenetz -- Could you please look into the issue, kindly re-assign if this is not related to your changes.
Thank You.

Investigating. Not sure if this is P1-worthy yet.

This looks like track_buffer mismanagement on multiple append overlaps. As such, it may hamper PTS/DTS compliance verification, so at least temporarily keeping P1 and marking as blocking  bug 718641 .

Hmm. SBS |ranges_| management in this case results in distinct SBRs (which are sorted correctly by their starting time in |ranges_|) that have **overlapping** intervals. Upon completing a playback of a track_buffer whose last buffer had a timestamp in the overlapping portion of two |ranges_| entries, the earlier one is picked, and that could have a lower next buffer time than the last buffer fed out from track_buffer.

Simplified repro case is in https://chromium-review.googlesource.com/c/chromium/src/+/661323

Since this is related to track_buffer and multiple overlaps, probably lower pri (even though it could churn pre/post PTS/DTS compliance code/tests). Deprioritizing for now.

Automatically applying components based on information from OWNERS files. If this seems incorrect, please apply the Test-Predator-Wrong-Components label.

Not blocking  bug 718641 .

ClusterFuzz has detected this issue as fixed in range 506151:506187.

Detailed report: https://clusterfuzz.com/testcase?key=4638327658774528

Fuzzer: libFuzzer_mediasource_MP2T_MP3_pipeline_integration_fuzzer
Job Type: libfuzzer_chrome_asan_debug
Platform Id: linux

Crash Type: CHECK failure
Crash Address: 
Crash State:
  delta >= base::TimeDelta() (-2.2e-05 s vs. 0 s) in source_buffer_stream.cc
  media::SourceBufferStream<media::SourceBufferRangeByDts>::WarnIfTrackBufferExhau
  media::SourceBufferStream<media::SourceBufferRangeByDts>::GetNextBufferInternal
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan_debug&range=499783:499873
Fixed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan_debug&range=506151:506187

Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=4638327658774528

See https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reproducing.md for more information.

If you suspect that the result above is incorrect, try re-doing that job on the test case report page.

ClusterFuzz testcase 4638327658774528 is verified as fixed, so closing issue as verified.

If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.

I think perhaps 1b00c058d243fe00970562f1d6a369617e5ecac7 (Oct 2) may be rejecting the particular fuzzer case that otherwise might have hit this CHECK. Re-opening just in case there's a hidden issue that's still reachable perhaps with some other input.

For more information, please see https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reference.md.

The link referenced in the description is no longer valid.

The custom minimized repro case (as a unit test -- see #4), once rebased and attempted on current ToT, no longer demonstrates incorrect behavior. (See patch set #3 of https://chromium-review.googlesource.com/c/chromium/src/+/661323).

I suspect this was fixed by the various range adjacency/overlap fixes I've landed recently in M-65/start of M-66.

Note CF thought this was fixed long ago (#8), but per #10 that was due to needing an updated CF repro case to get past a different change.

In retrospect, removing ClusterFuzz-Wrong label: the CF test case indeed was made to no longer fail by an unrelated change (https://crrev.com/1b00c058d243fe00970562f1d6a369617e5ecac7) which didn't fix the real root cause.