Predator and CL could not provide any possible suspects.
Using Code Search for the file, "values.cc" assigning to concern owner.

Suspecting Commit#
https://chromium.googlesource.com/chromium/src/+/cc9f5730ee747c92fb8340818ee185d36bf8a89a

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

The commit in comment 2 is unrelated. While it did change values.cc, the triggered DCHECK for UTF8 input has been there for a long time. From local debugging I figured out that the offending string is "V¡³P9" (that is "V\xA1\xB3P9"). This is likely caused by casting arbitrary input into an std::string in https://codesearch.chromium.org/chromium/src/media/formats/webm/webm_parser.cc?l=658&rcl=0e18feded8ea837baeb9628da1e2aac47b49e949, which then is set to codec_id_ in https://codesearch.chromium.org/chromium/src/media/formats/webm/webm_tracks_parser.cc?l=348&rcl=49110ea4bd0f9d1b60f70c5f24efc3ec6b595299 and later passed to InitializeConfig in https://codesearch.chromium.org/chromium/src/media/formats/webm/webm_tracks_parser.cc?l=245&rcl=2c63aa53b2c658de596ed550eb5267ec5967b351. This then fails to recognize this as a valid codec, and attempts to log it. During the log statement a base::Value is created from a non UTF8 string, hitting the DCHECK.

I'd suggest extending the checks done in WebMTracksParser::OnString, but I'll delegate to wolenetz@ as a //media OWNER to decide what should be done.

@#3 - yep, this is a defect in the webm parsers.

Though Matroska (and therefore WebM) define two kinds of valid "string"-valued EBML fields (either ASCII printable 0x20-0x7F, or UTF-8), I suspect it'd be overkill to enforce even the superset of "must be at least UTF-8" on parsing any string field.

I'll look at specific webm parser client overrides of OnString and do some focused cleanup on those cases where we actually use the result of a string-valued EBML-field.

I don't think this is P1 though.

CL: https://chromium-review.googlesource.com/644707

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

commit 9529a6ae15007abd5f99de7d32a59eddaf999960
Author: Matt Wolenetz <wolenetz@chromium.org>
Date: Thu Aug 31 02:20:51 2017

MSE: Give parse error on non-ASCII WebM Tracks CodecID and Name elements

BUG= 758808 
TEST=New unit tests; fuzzer with bad CodecID no longer repros

Change-Id: Ifab8b82f3b0c5cd9ea86c565e05a74c20eb1db29
Reviewed-on: https://chromium-review.googlesource.com/644707
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Commit-Queue: Matthew Wolenetz <wolenetz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#498730}
[modify] https://crrev.com/9529a6ae15007abd5f99de7d32a59eddaf999960/media/formats/webm/webm_parser.h
[modify] https://crrev.com/9529a6ae15007abd5f99de7d32a59eddaf999960/media/formats/webm/webm_tracks_parser.cc
[modify] https://crrev.com/9529a6ae15007abd5f99de7d32a59eddaf999960/media/formats/webm/webm_tracks_parser_unittest.cc

#7 should fix this issue. Pending CF verification...

ClusterFuzz has detected this issue as fixed in range 498710:498751.

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

Fuzzer: libFuzzer_mediasource_WEBM_VP9_pipeline_integration_fuzzer
Job Type: libfuzzer_chrome_asan_debug
Platform Id: linux

Crash Type: CHECK failure
Crash Address: 
Crash State:
  IsStringUTF8(*string_value_) in values.cc
  base::debug::DebugBreak
  base::Value::Value
  
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=498710:498751

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

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

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