Automatically applying components based on crash stacktrace and information from OWNERS files.

If this is incorrect, please apply the Test-Predator-Wrong-Components label.

Automatically assigning owner based on suspected regression changelist https://chromium.googlesource.com/chromium/src/+/c8842633b9ea324ecd3951c2620a67fa998272db (Introduce OffloadingVideoDecoder wrapper.).

If this is incorrect, please remove the owner and apply the Test-Predator-Wrong-CLs label.

I have a local repro. I also have a fix I'm about to send for review (https://chromium-review.googlesource.com/c/chromium/src/+/777778).

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

commit c4c936cf14b8c7f125a6087241b7b7983644ee49
Author: Matt Wolenetz <wolenetz@chromium.org>
Date: Wed Dec 06 02:30:27 2017

MSE: Signal SBS of new CFG more granularly when buffering ByPts

This change includes multiple fixes for various cases where
SourceBufferStream requires notification of a new coded frame group when
buffering by PTS (currently available via kMseBufferByPts feature) even
if there is no MSE coded frame processing algorithm DTS discontinuity
detected. This additional granularity allows for SourceBufferStream to
understand that the next buffers appended to it may overlap recently
appended buffers, and also allows for handling cases where the next
keyframe (continuous in DTS) jumps significantly forward in PTS but
still needs to remain continuous with the current append sequence.

On every keyframe, when buffering by PTS, FrameProcessor now considers
doing the extra signalling if DTS is continuous and buffering ByPts,
and:
a) keyframe PTS jumps significantly into the future relative to the
   highest PTS emitted already in the current coded frame group (in
   which case the highest PTS emitted already in the current CFG is used
   as the signalled PTS value), or
b) keyframe PTS is before the highest PTS emitted already in the current
   coded frame group (in which case the keyframe PTS is used as the
   signalled PTS value and tracking of the highest PTS emitted is reset
   to enable correct detection and signalling of both (a) and (b) cases
   for future keyframes in the continuous DTS append sequence.)

This change also includes a fix to SourceBufferStream when buffering
ByPts to appropriately split a range that is being overlap-appended.

A benign DCHECK is also removed from SBS::UpdateLastAppendStateForRemove
which could fail for a SAP Type 2 GOP at the beginning of a range (the
last appended buffer in that range might indeed be a non-keyframe with a
PTS prior to the range start time, which could be as late as the PTS of
the keyframe of that non-keyframe's GOP.)

New and updated unit tests are included. I locally confirmed this fixes
bugs  773115  and  788344 , and appears to fix nest.com and twitch.com
renderer crashes with dcheck_always_on=true.

Pre-existing  bug 791095  is demonstrated, but not yet fixed, by new
unit tests:
  BufferingByPts_ContinuousDts_SapType2_and_PtsJumpForward
  BufferingByPts_ContinuousDts_NewSap2GopEndOverlapsLastGop_1

Pre-existing bug 763620 is demonstrated, but not yet fixed, by new
unit tests:
  BufferingByPts_ContinuousDts_NewGopEndOverlapsLastGop_2
  BufferingByPts_ContinuousDts_NewSap2GopEndOverlapsLastGop_2
  BufferingByPts_ContinuousDts_GopKeyframePtsOrder_2_1_3

BUG= 773115 , 788344 , 791095 ,763620

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: I6f95cf85e1d1fa5b5f74ed1d99a3853ec6ccf686
Reviewed-on: https://chromium-review.googlesource.com/777778
Reviewed-by: Sergey Volk <servolk@chromium.org>
Reviewed-by: Dan Sanders <sandersd@chromium.org>
Commit-Queue: Matthew Wolenetz <wolenetz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#521961}
[modify] https://crrev.com/c4c936cf14b8c7f125a6087241b7b7983644ee49/media/base/test_helpers.h
[modify] https://crrev.com/c4c936cf14b8c7f125a6087241b7b7983644ee49/media/filters/chunk_demuxer_unittest.cc
[modify] https://crrev.com/c4c936cf14b8c7f125a6087241b7b7983644ee49/media/filters/frame_processor.cc
[modify] https://crrev.com/c4c936cf14b8c7f125a6087241b7b7983644ee49/media/filters/frame_processor_unittest.cc
[modify] https://crrev.com/c4c936cf14b8c7f125a6087241b7b7983644ee49/media/filters/source_buffer_stream.cc
[modify] https://crrev.com/c4c936cf14b8c7f125a6087241b7b7983644ee49/media/filters/source_buffer_stream_unittest.cc

ClusterFuzz has detected this issue as fixed in range 521933:521968.

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

Fuzzer: libFuzzer_mediasource_MP4_AACLC_AVC_pipeline_integration_fuzzer
Job Type: libfuzzer_chrome_msan
Platform Id: linux

Crash Type: Abrt
Crash Address: 0x03e9000041f5
Crash State:
  media::SourceBufferRangeByPts::AppendBuffersToEnd
  media::SourceBufferStream<media::SourceBufferRangeByPts>::Append
  media::ChunkDemuxerStream::Append
  
Sanitizer: memory (MSAN)

Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_msan&range=517260:517289
Fixed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_msan&range=521933:521968

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

See https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reference.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 6130141372874752 is verified as fixed, so closing issue as verified.

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