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/+/a4b1e71fd3146e936ab1668233218ab86eccdd2b (Add additional owners to media/gpu/vaapi/OWNERS).

If this is incorrect, please let us know why and apply the Test-Predator-Wrong-CLs label. If you aren't the correct owner for this issue, please unassign yourself as soon as possible so it can be re-triaged.

The regression range is suspect, and ancient. Likely this didn't regress in M66 or M67.

This looks unrelated to the M67 ffmpeg roll.

dalecurtis@/flim@, can one of you please take a look/help me understand the problem? Should the MSE parser(s) be rejecting something earlier, or is this some fault in the decode+rendering logic?

The following DCHECK_NE in AudioRendererImpl::DecodedAudioReady(...) fails in the repro:
c242c3a3b9242 media/renderers/audio_renderer_impl.cc (dalecurtis              2016-11-28 19:28:32 -0800  685)         // Input layouts should never be discrete.
c242c3a3b9242 media/renderers/audio_renderer_impl.cc (dalecurtis              2016-11-28 19:28:32 -0800  686)         DCHECK_NE(last_decoded_channel_layout_, CHANNEL_LAYOUT_DISCRETE);

Hmm, I thought we supported discrete layouts now for opus ambisonics?

Looks like this CHECK is hitting inside `if (expecting_config_changes_) {...}`. I hadn't seen this evaluate to true when previously testing with webaudio for opus ambisonics. Is this scenario to be possible?

(we should handle either way for fuzzing, just that if it's possible, I'll need to investigate further for that use case)

Since we set DISCRETE in webm_audio_client it can get on this path.

-> flim@ per #8-9.

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

commit 66db63398fb6e961f284b6e7a785999dd314d002
Author: flim <flim@chromium.org>
Date: Wed Mar 28 04:29:50 2018

Validate midstream audio config changes with CHANNEL_LAYOUT_DISCRETE

Bug:  822744 
Change-Id: I483e3f9644f4087295a0be95f9def4c6286ec72b
Reviewed-on: https://chromium-review.googlesource.com/972327
Commit-Queue: Felicia Lim <flim@chromium.org>
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#546403}
[modify] https://crrev.com/66db63398fb6e961f284b6e7a785999dd314d002/media/renderers/audio_renderer_impl.cc

ClusterFuzz has detected this issue as fixed in range 546391:546406.

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

Fuzzer: libFuzzer_mediasource_WEBM_OPUS_pipeline_integration_fuzzer
Job Type: libfuzzer_chrome_asan_debug
Platform Id: linux

Crash Type: CHECK failure
Crash Address: 
Crash State:
  last_decoded_channel_layout_ != CHANNEL_LAYOUT_DISCRETE in audio_renderer_impl.c
  media::AudioRendererImpl::DecodedAudioReady
  void base::internal::FunctorTraits<void
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan_debug&range=523270:523295
Fixed: https://clusterfuzz.com/revisions?job=libfuzzer_chrome_asan_debug&range=546391:546406

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

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

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