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/+/c4c936cf14b8c7f125a6087241b7b7983644ee49 (MSE: Signal SBS of new CFG more granularly when buffering ByPts).

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

Local repros:

---
On current ToT (without https://chromium-review.googlesource.com/c/chromium/src/+/879408 landed yet):

chrome_debug_asan:
(ByPts):
FATAL:source_buffer_stream.cc(1373)] Check failed: range_for_next_append_ != ranges_.end().

chrome_asan:
repro of failure of CHECK(!buffers_.empty()) at top of SBRByPts::SplitRange.
---

But with https://chromium-review.googlesource.com/c/chromium/src/+/879408 applied locally, **no repro** in either asan or debug_asan cases.

I'll look into understanding the repro case better next, though at lower priority (maybe another unit test is needed).

(Also, this doesn't need merging to M-65 since this appears to be specific to ByPts and that experimentation hasn't started yet -- it's planned for M-66).

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

commit fdeaf6e25bb2d2596de09eca9a902ea98e70d84c
Author: Matt Wolenetz <wolenetz@chromium.org>
Date: Sun Jan 28 16:44:16 2018

MSE: Use |highest_timestamp_in_append_sequence_| in PotentialNextAppendTimestamp()

SAP-Type-2 sequences may contain a nonkeyframe so far in advance of the
range's first GOP's keyframe timestamp that it may appear to belong to
the presentation interval of some other range. If we continued to use
|last_appended_buffer_timestamp_| when re-determining
|range_for_next_append_| upon consulting PotentialNextAppendTimestamp()
during buffer removal operations that touched the current
|range_for_next_append_|, we could incorrectly append to the earlier
range.

This change uses the |highest_timestamp_in_append_sequence_| in
PotentialNextAppendTimestamp(), enabling correct determination of
|range_for_next_append_| when such SAP-Type-2 scenarios are encountered
when BufferingByPts.

Note: This change continues the direction of the BufferingByPts logic so
far: it doesn't move a range's start time earlier if that range contains
a nonkeyframe from a SAP-Type-2 GOP before the range's starting
keyframe. This greatly simplifies adapting our existing logic to
gracefully handle SAP-Type-2, with the known caveat that range start
times don't indicate any potentially buffered earlier SAP-Type-2
nonkeyframes. See also  https://crbug.com/798935#c10 

BUG= 798935 , 804802 , 795655 
TEST=Added SBST.Sap2GopWithNonKeyframeInEarlierRangesInterval, and the
CF cases for bugs  798935  and  804802  no longer repro locally with this
change.

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: Ieff9b086ec9ac73f02a6bfbfa406765b434d9728
Reviewed-on: https://chromium-review.googlesource.com/879408
Commit-Queue: Matthew Wolenetz <wolenetz@chromium.org>
Reviewed-by: Chrome Cunningham <chcunningham@chromium.org>
Cr-Commit-Position: refs/heads/master@{#532280}
[modify] https://crrev.com/fdeaf6e25bb2d2596de09eca9a902ea98e70d84c/media/filters/source_buffer_stream.cc
[modify] https://crrev.com/fdeaf6e25bb2d2596de09eca9a902ea98e70d84c/media/filters/source_buffer_stream_unittest.cc

ClusterFuzz has detected this issue as fixed in range 532267:532325.

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

Fuzzer: libFuzzer_mediasource_MP2T_AACLC_AVC_pipeline_integration_fuzzer
Job Type: libfuzzer_chrome_asan
Platform Id: linux

Crash Type: Null-dereference READ
Crash Address: 0x000000000021
Crash State:
  base::circular_deque<scoped_refptr<media::StreamParserBuffer> >::empty
  media::SourceBufferRangeByPts::SplitRange
  media::SourceBufferStream<media::SourceBufferRangeByPts>::RangeSplitRange
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan&range=521938:521975
Fixed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan&range=532267:532325

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

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

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