Predator and CL could not provide any possible suspects.
Using Code Search for the file, "frame_processor.cc" assigning to the concern owner who might be related.

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

I have a local repro.
It looks like we let streams in that violate the assumption in our MSE pipeline that audio streams consist entirely of keyframes:

VERBOSE3:mp4_stream_parser.cc(733)] Emit audio frame:  track_id=1, key=0, dur=104, dts=0, cts=0, size=6

I don't know of any Chrome MSE supported bytestreams that encapsulate audio codec coded frames that could have nonkeyframe audio frames.

cc+=dalecurtis@, chcunningham@

Rather than just giving parse-error for such streams, a less strict fix for this broken assumption would be to have the parser give a media-internals debug warning when it sees this, and also set the audio frame to be a keyframe.

This doesn't look like P1, though specialized audio buffering code in SourceBuffer{Stream,Range} depends also on this (apparently broken) assumption.

=> P2 and I'll start work on a fix that'll apply across all MSE bytestreams (eg, the planned fix will be in FrameProcessor).

Yeah all audio is a keyframe, so I'd just always set it and log a warning.

CL: https://chromium-review.googlesource.com/c/chromium/src/+/646233

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d930fca65ee48bee40fb6233f60c475d06f9ca11

commit d930fca65ee48bee40fb6233f60c475d06f9ca11
Author: Matt Wolenetz <wolenetz@chromium.org>
Date: Thu Aug 31 22:32:54 2017

MSE: Force audio frames to be keyframes, with warning MEDIA_LOG

All audio frames are expected to be key frames. But content metadata
may indicate otherwise and parsers typically oblige. This change
LIMITED_MEDIA_LOGs when this expectation is violated, and marks such
audio frames key before doing the bulk of the coded frame processing
algorithm (and consequent buffering operations).

Also includes drive-by cleanup of seek()->SeekStream() code-style in
related unit tests.

BUG= 759009 
TEST=new unit test; fuzzer case no longer hits DCHECK

Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: If5ad8ff292b63e36b09bf99f27fff41174ac16b5
Reviewed-on: https://chromium-review.googlesource.com/646233
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Commit-Queue: Matthew Wolenetz <wolenetz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#499051}
[modify] https://crrev.com/d930fca65ee48bee40fb6233f60c475d06f9ca11/media/base/test_helpers.h
[modify] https://crrev.com/d930fca65ee48bee40fb6233f60c475d06f9ca11/media/filters/frame_processor.cc
[modify] https://crrev.com/d930fca65ee48bee40fb6233f60c475d06f9ca11/media/filters/frame_processor.h
[modify] https://crrev.com/d930fca65ee48bee40fb6233f60c475d06f9ca11/media/filters/frame_processor_unittest.cc

#6 should fix this. Pending CF verification...

ClusterFuzz has detected this issue as fixed in range 498966:499054.

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

Fuzzer: libFuzzer_mediasource_MP4_FLAC_pipeline_integration_fuzzer
Job Type: libfuzzer_chrome_asan_debug
Platform Id: linux

Crash Type: CHECK failure
Crash Address: 
Crash State:
  buffer->is_key_frame() in frame_processor.cc
  base::debug::DebugBreak
  media::FrameProcessor::HandlePartialAppendWindowTrimming
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan_debug&range=497039:497107
Fixed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan_debug&range=498966:499054

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

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 5279660350111744 is verified as fixed, so closing issue as verified.

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