w.r.t. "simply mark h264 as not supported for calls coming from MediaSource.isTypeSupported()", I assume you mean, "h264 without any codec", right?

Is this actually broken? StreamParserFactory doesn't use that logic. It checks media::HasPlatformDecoderSupport() which should be correct.

> w.r.t. "simply mark h264 as not supported for calls coming from MediaSource.isTypeSupported()", I assume you mean, "h264 without any codec", right?

Sorry, my initial phrasing was unclear - but I don't follow your suggestion either. What I meant to say:

*When platform decoders are not available*, MediaSource.isTypeSupported should report NotSupported for h264 (represented as the usual avc codec id).

> Is this actually broken? StreamParserFactory doesn't use that logic. It checks media::HasPlatformDecoderSupport() which should be correct.

You're right that this will prevent creation of a source buffer, but that is a really bad experience for app developers. We said we could create the buffer (isTypeSupported), but fail to do so (and thats really the most important part). At this point apps may just break (likely) or may attempt fetching different codecs after already wasting bandwidth on h264 streams. 

Updated links for those in OP, pinning to git versions that were current with date of OP:

https://chromium.googlesource.com/chromium/src/+/8aeee0b5c65d2ea16d2c52839cf80bcf99273555/content/renderer/render_frame_impl.cc#739

and

https://chromium.googlesource.com/chromium/src/+/6cfb384ad0513ed6bdf6c6a5886ef5da0411b70a/media/base/mime_util_internal.cc#536

This has been P1 for a long time. I'm unclear on its impact currently, or even its validity as an issue.

Resetting to Unconfirmed.

Chris/Dale:
* As of [0] (and still today), StreamParserFactory uses the same internal type+codec+platform validator logic for isTypeSupported() and Create(). Both of them fail (false, null unique_ptr respectively) if !CheckTypeAndCodecs(). For video/mp4 and avc codec, on Android, CheckTypeAndCodecs's call to VerifyCodecs consults media::HasPlatformDecoderSupport() [1].

[0] https://chromium.googlesource.com/chromium/src/+/c72600f07436a0429d107cbc75442bd585dace

[1] https://cs.chromium.org/chromium/src/media/filters/stream_parser_factory.cc?sq=package:chromium&dr=CSs&g=0&l=410

* Chris, please recheck/confirm this issue to see if it is valid.
* If it is valid (I missed something), is this indeed a P1 (are there significant Android with !HasPlatformDecoderSupport() using MSE with H264)?
* Do we have any such devices/bots in our test profile (for instance, I don't see any current/recent failures for the test [2,3] which would fail on such a device if this issue needed fixing, IIUC.)

[2] https://cs.chromium.org/chromium/src/media/filters/chunk_demuxer_unittest.cc?q=codecprefixmatching&sq=package:chromium&g=0&l=2845

[3] https://test-results.appspot.com/dashboards/flakiness_dashboard.html#testType=media_unittests&tests=CodecPrefixMatching

Perhaps you meant htmlMediaElement.canPlayType(h264 video mime type) might report "maybe" or "probably" for this case, but MSE reports lack of support via isTypeSupported() and via mediaSource.AddId(...)? If that's the case, already there are other browsers that do similar for other codec types (at least, Edge IIRC says it doesn't support vp9 via canPlayType, yet does support it via MSE).

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot