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 adding ccs based on suspected regression changelists:

Fix H.264 in MPEG2 TS. by dougsteed@chromium.org - https://chromium.googlesource.com/chromium/src/+/d1ca6be96591b2d6b717ee97aa69efa9fbd9d76e

Make AVDACodecAllocator thread safe. by liberato@chromium.org - https://chromium.googlesource.com/chromium/src/+/04ed2188b440cc9d7fc6b4fa3808368ea7f5ab0e

If this is incorrect, please let us know why and apply the Test-Predator-Wrong-CLs label.

I have a local repro case. It looks very very similar to that of  bug 798935  (which is msan failure vs this one is asan failure). Investigating together. Not marking duplicate in case that foils CF ability to eventually verify each independently fixed.

This impacts only BufferingByPts mode.
Fix in CR: https://chromium-review.googlesource.com/c/chromium/src/+/879408

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=6344560820355072

Fuzzer: libFuzzer_mediasource_MP2T_AACLC_AVC_pipeline_integration_fuzzer
Job Type: libfuzzer_chrome_asan
Platform Id: linux

Crash Type: CHECK failure
Crash Address: 
Crash State:
  buffers_.empty() || CanAppendBuffersToEnd(new_buffers, new_buffers_group_start_p
  media::SourceBufferRangeByPts::AppendBuffersToEnd
  media::SourceBufferStream<media::SourceBufferRangeByPts>::Append
  
Sanitizer: address (ASAN)

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

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

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

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