Deprecate MediaRecorder.isTypeSupported() by limiting it to fixed list of identifiers w/wildcards #226

jan-ivar · 2025-02-17T22:48:25Z

Fixes #202.

Preview | Diff

MediaRecorder.bs

Pehrsons

lgtm

MediaRecorder.bs

jan-ivar · 2025-03-06T00:59:56Z

@youennf does this LGTY without "mp4a"? Full disclosure https://jsfiddle.net/jib1/sw1mu6Lv/ in Safari produces:

Supported mimeTypes (7) = [
  "video/mp4",
  "video/mp4;codecs=avc1",
  "video/mp4;codecs=avc1,mp4a",
  "video/mp4;codecs=avc1,mp4a.40.2",
  "video/mp4;codecs=avc1.64003E",
  "video/mp4;codecs=avc1.64003E,mp4a",
  "video/mp4;codecs=avc1.64003E,mp4a.40.2"
]

jan-ivar · 2025-03-06T15:09:16Z

I suppose for browsers with only one audio choice (like Safari and Firefox), this might matter less since you get the only audio codec available by default.

guidou · 2025-03-20T14:54:25Z

FWIW, Chrome (on Windows) produces the following output with the same script:

Supported mimeTypes (59) = [
  "audio/webm",
  "audio/webm;codecs=opus",
  "video/webm",
  "video/webm;codecs=vp8",
  "video/webm;codecs=vp8,opus",
  "video/webm;codecs=vp9",
  "video/webm;codecs=vp9,opus",
  "video/webm;codecs=av1",
  "video/webm;codecs=av1,opus",
  "video/webm;codecs=av01",
  "video/webm;codecs=av01,opus",
  "video/webm;codecs=av01.0.19M.08",
  "video/webm;codecs=av01.0.19M.08,opus",
  "video/webm;codecs=h264",
  "video/webm;codecs=h264,opus",
  "video/webm;codecs=avc1",
  "video/webm;codecs=avc1,opus",
  "video/webm;codecs=avc1.64003E",
  "video/webm;codecs=avc1.64003E,opus",
  "video/webm;codecs=avc3.64003E",
  "video/webm;codecs=avc3.64003E,opus",
  "video/mp4",
  "video/mp4;codecs=vp9",
  "video/mp4;codecs=vp9,opus",
  "video/mp4;codecs=vp9,mp4a.40.2",
  "video/mp4;codecs=av01",
  "video/mp4;codecs=av01,opus",
  "video/mp4;codecs=av01,mp4a.40.2",
  "video/mp4;codecs=av01.0.19M.08",
  "video/mp4;codecs=av01.0.19M.08,opus",
  "video/mp4;codecs=av01.0.19M.08,mp4a.40.2",
  "video/mp4;codecs=avc1",
  "video/mp4;codecs=avc1,opus",
  "video/mp4;codecs=avc1,mp4a.40.2",
  "video/mp4;codecs=avc1.64003E",
  "video/mp4;codecs=avc1.64003E,opus",
  "video/mp4;codecs=avc1.64003E,mp4a.40.2",
  "video/mp4;codecs=avc3.64003E",
  "video/mp4;codecs=avc3.64003E,opus",
  "video/mp4;codecs=avc3.64003E,mp4a.40.2",
  "video/x-matroska",
  "video/x-matroska;codecs=vp8",
  "video/x-matroska;codecs=vp8,opus",
  "video/x-matroska;codecs=vp9",
  "video/x-matroska;codecs=vp9,opus",
  "video/x-matroska;codecs=av1",
  "video/x-matroska;codecs=av1,opus",
  "video/x-matroska;codecs=av01",
  "video/x-matroska;codecs=av01,opus",
  "video/x-matroska;codecs=av01.0.19M.08",
  "video/x-matroska;codecs=av01.0.19M.08,opus",
  "video/x-matroska;codecs=h264",
  "video/x-matroska;codecs=h264,opus",
  "video/x-matroska;codecs=avc1",
  "video/x-matroska;codecs=avc1,opus",
  "video/x-matroska;codecs=avc1.64003E",
  "video/x-matroska;codecs=avc1.64003E,opus",
  "video/x-matroska;codecs=avc3.64003E",
  "video/x-matroska;codecs=avc3.64003E,opus"
]

youennf · 2025-07-31T14:42:32Z

Some thoughts:

It would be good to allowing value with avc1. prefix instead of just avc1. Ditto for other values
It would be good to add hevc support, allowing hvc1..
With those changes, I think this would be good to merge.

youennf · 2025-07-31T14:44:35Z

It might be good to check whether we need vp9 and vp09 as well, same for vp8

youennf · 2025-07-31T14:49:35Z

We should try to only include av01, not av1.

guidou · 2025-07-31T14:51:02Z

cc @handellm

youennf · 2025-07-31T14:52:41Z

With regards to hev1 variant to hvc1 and avc3 variant to avc1, we should decide whether to include them or not. Chrome and Safari are supporting both hevc versions, only Chrome supports avc3.

youennf · 2025-07-31T14:56:04Z

Safari is also supporting vp08 and vp09, but not Chrome. I'll check internally whether we can remove those checks in Safari.

jan-ivar · 2025-07-31T22:56:34Z

Good news is this updated fiddle shows browsers for the most part ignore profile levels. I.e. both Chrome (mostly) and Safari accept anything after the period. E.g.:

  "video/webm;codecs=av01",
  "video/webm;codecs=av01.",
  "video/webm;codecs=av01.*",
  "video/webm;codecs=av01,opus",
  "video/webm;codecs=av01,opus.",
  "video/webm;codecs=av01,opus.*",
  ...

Safari is even more flexible, not even requiring the period (except for hvc1 and hev1). E.g.:

  "video/mp4;codecs=avc1*",
  "video/mp4;codecs=avc1,mp4a*",
  "video/mp4;codecs=hvc1.",
  "video/mp4;codecs=hvc1.*",
  "video/mp4;codecs=hev1.",
  "video/mp4;codecs=hev1.*"

But there are notable exceptions in Chrome (note lack of wildcard):

  "video/mp4",
  "video/mp4;codecs=vp9",
  "video/mp4;codecs=vp9,opus",
  "video/mp4;codecs=vp9,mp4a.40.2",
  "video/mp4;codecs=av01",
  "video/mp4;codecs=av01.0.19M.08",
  "video/mp4;codecs=av01,opus",
  "video/mp4;codecs=av01,mp4a.40.2",
  "video/mp4;codecs=avc1",
  "video/mp4;codecs=avc1.64003E",
  "video/mp4;codecs=avc1,opus",
  "video/mp4;codecs=avc1,mp4a.40.2",
  "video/mp4;codecs=avc3",
  "video/mp4;codecs=avc3.64003E",
  "video/mp4;codecs=avc3,opus",
  "video/mp4;codecs=avc3,mp4a.40.2",
  "video/mp4;codecs=hvc1.1.6.L186.B0",
  "video/mp4;codecs=hev1.1.6.L186.B0",

But updating these to a wildcard should be largely backwards compatible (insofar as it won't break any recording that used to work — and there doesn't appear to be significant choice between profiles here yet)

So we should be able to standardize on the wildcard version (with or without a period — slight preference for requiring the period).

MediaRecorder.bs

handellm · 2025-09-11T08:46:03Z

MediaRecorder.bs

        while recording, the User Agent has to be prepared to re-encode it to
        avoid interruptions.
      </div>
+      <li>If the User Agent does not support the specified combination of media


In our opinion this is a good addition. However the current Chromium implementation will actually synch-check for support already in the ctor. Can we allow "either a ctor exception, or an event on start"?

We do. This is covered by is type supported called from the constructor with deferNewerCodecsCheck = true:¹

If type contains a standalone or comma-separated codec specifier string that in its entirety is not a case-insensitive exact match for any item in the list of synchronously exposed codec specifiers and deferNewerCodecsCheck is true, then return true.

If the MediaRecorder does not support the specified combination of media type/subtype, codecs and container then return false.

So the rules are:

Only old codecs → throws in constructor

any new codec mentioned → event on start instead

_{1. Note I'm in the process of updating this text to allow for wildcard, so this was the text at time of writing this, ahead of that change, for reference. I'll preserve its behaviors relevant here.}

I mean I think this spec text says "is type supported" with codecs=h264.bla from the ctor will return true in step 8, whereas currently the Chromium ctor will throw an exception instead. Allowing either exception in the ctor or error event on start() seems reasonable and allows for relaxed rules on UA implementation. Maybe 8 + 9 could be merged in the spec text somehow?

Yes the "exact match" language in step 8 was from a simpler era (when the sync list was quite small). This should be better now.

Allowing either exception in the ctor or error event on start() seems reasonable and allows for relaxed rules on UA implementation

Unless we're willing to commit to changing shipped behavior, I don't think we should entertain variance across implementations. Concerns over compat across versions mirror those across implementations.

It might hurt web compat if some browsers throw and others fire an event — in a way that some codecs throw and others fire an event, would not, provided it was consistent across browsers.

The latest text mandates forever throwing in the ctor for codec descriptors on the list (which has now grown quite a bit). This perhaps hurts the original premise that we wanted to get away from sync detection. But if shipped is shippped, then I don't see a good way here to have it both ways.

This perhaps hurts the original premise that we wanted to get away from sync detection. But if shipped is shippped, then I don't see a good way here to have it both ways.

But I think the text now in |is type supported| ignores the part after leading dot, so Chromium's ctor behavior would not be compliant (since it can return true or false depending on the string after first dot)?

The isTypeSupported algorithm seems acceptable as it stands now from Chromium. We will need to do changes (allow wildcarding for the hevc types) but I think these changes are for the better.

handellm · 2025-09-11T08:49:06Z

MediaRecorder.bs

+    </li>
+    <li>If the MediaRecorder does not support the specified combination of media
+    type/subtype, and container then return false.</li>
+    <li>If |type| contains a standalone or comma-separated codec specifier string


Can we make L580 bullet behavior optional and allow returning false from synch execution here?

This is already conditional, and step 9 below returns false. See previous comment. LMK if that solves your concern.

Let's continue this discussion in the thread above :)

handellm · 2025-09-11T08:56:16Z

Hi @jan-ivar, when adding HEVC support we had some internal discussion on wether we should allow wildcardish operation and the conclusion at the time was to not allow it.

We support allowing user agents that implement the wildcard strategy to fire an event asynchronously, but we want to allow Chrome to continue to do what it is doing (i.e. throw exception at construction or have isTypeSupported return false for codec.* types) for backwards-compat reason. We think it would be more ideal to feature freeze rather than change.

jan-ivar · 2025-09-11T17:12:50Z

Hi @jan-ivar, when adding HEVC support we had some internal discussion on wether we should allow wildcardish operation and the conclusion at the time was to not allow it.

Understood, but doesn't this leave it inconsistent within Chrome? Above I listed only 18 "notable exceptions" out of 158. The full list below shows Chrome supporting wildcard for all the other codecs:

Full Chrome list (showing inconsistent support for wildcards across codec types):

Supported mimeTypes (158) = [
  "audio/webm",
  "audio/webm;codecs=opus",
  "audio/webm;codecs=opus.",
  "audio/webm;codecs=opus.*",
  "audio/webm;codecs=pcm",
  "audio/webm;codecs=pcm.",
  "audio/webm;codecs=pcm.*",
  "audio/mp4",
  "audio/mp4;codecs=opus",
  "audio/mp4;codecs=mp4a.40.2",
  "video/webm",
  "video/webm;codecs=vp8",
  "video/webm;codecs=vp8.",
  "video/webm;codecs=vp8.*",
  "video/webm;codecs=vp8,opus",
  "video/webm;codecs=vp8,opus.",
  "video/webm;codecs=vp8,opus.*",
  "video/webm;codecs=vp8,pcm",
  "video/webm;codecs=vp8,pcm.",
  "video/webm;codecs=vp8,pcm.*",
  "video/webm;codecs=vp9",
  "video/webm;codecs=vp9.",
  "video/webm;codecs=vp9.*",
  "video/webm;codecs=vp9,opus",
  "video/webm;codecs=vp9,opus.",
  "video/webm;codecs=vp9,opus.*",
  "video/webm;codecs=vp9,pcm",
  "video/webm;codecs=vp9,pcm.",
  "video/webm;codecs=vp9,pcm.*",
  "video/webm;codecs=av1",
  "video/webm;codecs=av1.",
  "video/webm;codecs=av1.*",
  "video/webm;codecs=av1,opus",
  "video/webm;codecs=av1,opus.",
  "video/webm;codecs=av1,opus.*",
  "video/webm;codecs=av1,pcm",
  "video/webm;codecs=av1,pcm.",
  "video/webm;codecs=av1,pcm.*",
  "video/webm;codecs=av01",
  "video/webm;codecs=av01.",
  "video/webm;codecs=av01.*",
  "video/webm;codecs=av01,opus",
  "video/webm;codecs=av01,opus.",
  "video/webm;codecs=av01,opus.*",
  "video/webm;codecs=av01,pcm",
  "video/webm;codecs=av01,pcm.",
  "video/webm;codecs=av01,pcm.*",
  "video/webm;codecs=h264",
  "video/webm;codecs=h264.",
  "video/webm;codecs=h264.*",
  "video/webm;codecs=h264,opus",
  "video/webm;codecs=h264,opus.",
  "video/webm;codecs=h264,opus.*",
  "video/webm;codecs=h264,pcm",
  "video/webm;codecs=h264,pcm.",
  "video/webm;codecs=h264,pcm.*",
  "video/webm;codecs=avc1",
  "video/webm;codecs=avc1.",
  "video/webm;codecs=avc1.*",
  "video/webm;codecs=avc1,opus",
  "video/webm;codecs=avc1,opus.",
  "video/webm;codecs=avc1,opus.*",
  "video/webm;codecs=avc1,pcm",
  "video/webm;codecs=avc1,pcm.",
  "video/webm;codecs=avc1,pcm.*",
  "video/webm;codecs=avc3",
  "video/webm;codecs=avc3.",
  "video/webm;codecs=avc3.*",
  "video/webm;codecs=avc3,opus",
  "video/webm;codecs=avc3,opus.",
  "video/webm;codecs=avc3,opus.*",
  "video/webm;codecs=avc3,pcm",
  "video/webm;codecs=avc3,pcm.",
  "video/webm;codecs=avc3,pcm.*",
  "video/mp4",
  "video/mp4;codecs=vp9",
  "video/mp4;codecs=vp9,opus",
  "video/mp4;codecs=vp9,mp4a.40.2",
  "video/mp4;codecs=av01",
  "video/mp4;codecs=av01.0.19M.08",
  "video/mp4;codecs=av01,opus",
  "video/mp4;codecs=av01,mp4a.40.2",
  "video/mp4;codecs=avc1",
  "video/mp4;codecs=avc1.64003E",
  "video/mp4;codecs=avc1,opus",
  "video/mp4;codecs=avc1,mp4a.40.2",
  "video/mp4;codecs=avc3",
  "video/mp4;codecs=avc3.64003E",
  "video/mp4;codecs=avc3,opus",
  "video/mp4;codecs=avc3,mp4a.40.2",
  "video/mp4;codecs=hvc1.1.6.L186.B0",
  "video/mp4;codecs=hev1.1.6.L186.B0",
  "video/x-matroska",
  "video/x-matroska;codecs=vp8",
  "video/x-matroska;codecs=vp8.",
  "video/x-matroska;codecs=vp8.*",
  "video/x-matroska;codecs=vp8,opus",
  "video/x-matroska;codecs=vp8,opus.",
  "video/x-matroska;codecs=vp8,opus.*",
  "video/x-matroska;codecs=vp8,pcm",
  "video/x-matroska;codecs=vp8,pcm.",
  "video/x-matroska;codecs=vp8,pcm.*",
  "video/x-matroska;codecs=vp9",
  "video/x-matroska;codecs=vp9.",
  "video/x-matroska;codecs=vp9.*",
  "video/x-matroska;codecs=vp9,opus",
  "video/x-matroska;codecs=vp9,opus.",
  "video/x-matroska;codecs=vp9,opus.*",
  "video/x-matroska;codecs=vp9,pcm",
  "video/x-matroska;codecs=vp9,pcm.",
  "video/x-matroska;codecs=vp9,pcm.*",
  "video/x-matroska;codecs=av1",
  "video/x-matroska;codecs=av1.",
  "video/x-matroska;codecs=av1.*",
  "video/x-matroska;codecs=av1,opus",
  "video/x-matroska;codecs=av1,opus.",
  "video/x-matroska;codecs=av1,opus.*",
  "video/x-matroska;codecs=av1,pcm",
  "video/x-matroska;codecs=av1,pcm.",
  "video/x-matroska;codecs=av1,pcm.*",
  "video/x-matroska;codecs=av01",
  "video/x-matroska;codecs=av01.",
  "video/x-matroska;codecs=av01.*",
  "video/x-matroska;codecs=av01,opus",
  "video/x-matroska;codecs=av01,opus.",
  "video/x-matroska;codecs=av01,opus.*",
  "video/x-matroska;codecs=av01,pcm",
  "video/x-matroska;codecs=av01,pcm.",
  "video/x-matroska;codecs=av01,pcm.*",
  "video/x-matroska;codecs=h264",
  "video/x-matroska;codecs=h264.",
  "video/x-matroska;codecs=h264.*",
  "video/x-matroska;codecs=h264,opus",
  "video/x-matroska;codecs=h264,opus.",
  "video/x-matroska;codecs=h264,opus.*",
  "video/x-matroska;codecs=h264,pcm",
  "video/x-matroska;codecs=h264,pcm.",
  "video/x-matroska;codecs=h264,pcm.*",
  "video/x-matroska;codecs=avc1",
  "video/x-matroska;codecs=avc1.",
  "video/x-matroska;codecs=avc1.*",
  "video/x-matroska;codecs=avc1,opus",
  "video/x-matroska;codecs=avc1,opus.",
  "video/x-matroska;codecs=avc1,opus.*",
  "video/x-matroska;codecs=avc1,pcm",
  "video/x-matroska;codecs=avc1,pcm.",
  "video/x-matroska;codecs=avc1,pcm.*",
  "video/x-matroska;codecs=avc3",
  "video/x-matroska;codecs=avc3.",
  "video/x-matroska;codecs=avc3.*",
  "video/x-matroska;codecs=avc3,opus",
  "video/x-matroska;codecs=avc3,opus.",
  "video/x-matroska;codecs=avc3,opus.*",
  "video/x-matroska;codecs=avc3,pcm",
  "video/x-matroska;codecs=avc3,pcm.",
  "video/x-matroska;codecs=avc3,pcm.*",
  "video/x-matroska;codecs=hvc1.1.6.L186.B0",
  "video/x-matroska;codecs=hev1.1.6.L186.B0"
]

jan-ivar · 2025-09-11T18:37:18Z

We support allowing user agents that implement the wildcard strategy to fire an event asynchronously, but we want to allow Chrome to continue to do what it is doing (i.e. throw exception at construction or have isTypeSupported return false for codec.* types) for backwards-compat reason. We think it would be more ideal to feature freeze rather than change.

I plan to update the PR based on #226 (comment) to include hev1, hvc1, avc3, avc1 to the list, making them "old codecs", effectively freezing (making throwing in the constructor spec for them).

The compromise is to limit detection to wildcards, to reduce the fingerprinting surface.

In my experience, web compat issues usually comes in the form of web devs forgetting to test their input with Safari or Firefox, not Chrome. So Chrome having a stricter test on input than spec (for a subset of its codecs) shouldn't break any web devs here. It seems Chrome should be able to unify detection of its latest codecs with its other codecs here without breaking anyone.

handellm · 2025-09-12T06:19:44Z

Understood, but doesn't this leave it inconsistent within Chrome?

Yes it is (which isn't optimal).

I will await the wildcard update :)

jan-ivar · 2025-09-15T22:05:12Z

Now updated. @handellm PTAL.

handellm · 2025-09-18T06:53:40Z

MediaRecorder.bs

+  The <dfn>list of synchronously exposed codec identifiers</dfn> is:
+  <code>"vp8"</code>, <code>"vp9"</code>, <code>"h264"</code> aka
+  <code>"avc1"</code>, <code>"av1"</code> aka <code>"av01"</code>,
+  <code>hvc1</code> aka <code>hev1</code>, <code>avc1</code> aka <code>avc3</code>,


Typo? avc1 != avc3.

handellm · 2025-09-18T06:54:27Z

MediaRecorder.bs

  <dd>
+  This method is deprecated; it exists for legacy compatibility reasons only.
+  The <dfn>list of synchronously exposed codec identifiers</dfn> is:
+  <code>"vp8"</code>, <code>"vp9"</code>, <code>"h264"</code> aka


Perhaps also add vp08/vp09 weaving in @youennf 's comment above?

handellm · 2025-09-18T09:04:45Z

The isTypeSupported algorithm seems acceptable as it stands now from Chromium. We will need to do changes (allow wildcarding for the hevc types) but I think these changes are for the better.

Still some clarifications to do regarding Chromium ctor behavior, spec text and intentions.

MediaRecorder.bs

henbos · 2025-09-18T14:06:16Z

Still some clarifications to do regarding Chromium ctor behavior, spec text and intentions.

Can you clarify, are you talking about adding an informative note or changing one of the steps of the constructor algorithm?

handellm · 2025-09-18T14:14:55Z

Still some clarifications to do regarding Chromium ctor behavior, spec text and intentions.

Can you clarify, are you talking about adding an informative note or changing one of the steps of the constructor algorithm?

I mean, this thread isn't reconciled yet.

handellm · 2025-09-24T07:50:56Z

Just a progress update, this is still being circled internally. I'll update once we have a clear view on consequences.

handellm · 2025-09-26T07:30:13Z

Hi @jan-ivar
There are concerns that false iTS return values are used for codec support detection, so to not break sites we'll need to add some usage stats and make some informed guesstimate before LGTM. We're still positive in general about the change, and also the new error event could be OK as we emit other error events anyway, but let's see what counters say. Thanks for continued patience.

youennf · 2025-10-02T14:26:33Z

@handellm, it seems the main change for Chrome to align with this PR is to relax the checks for HEVC.
HEVC support in MediaRecorder being quite new, I am hoping this should not be a big compat issue?
Or are you checking other compat issues?

jan-ivar · 2025-10-02T14:33:07Z

One downside is the PR essentially defers establishing the non-throwing code-path to whenever a new codec is built in the future.

Editor's meeting suggestion: We could add something like "User agent MAY attempt to shorten the list of synchronously exposed codec identifiers" to allow UAs a head start on establishing this second code path if they're comfortable with the web compat effect.

handellm · 2025-10-20T08:18:48Z

I've added some histograms to Chrome to try to figure out how iTS and the MR ctor are used in production, we'll need another week to get initial data from Chrome Canary. See crbug.com/450757339

Deprecate MediaRecorder.isTypeSupported() to vp8, vp9, h264 and opus

5b16006

jan-ivar requested review from Pehrsons, guidou and youennf February 17, 2025 22:48

jan-ivar self-assigned this Feb 17, 2025

fix bikeshed errors

01cd901

jan-ivar mentioned this pull request Feb 18, 2025

H26x Codec support updates for MediaRecorder mozilla/standards-positions#1174

Closed

alvestrand reviewed Feb 18, 2025

View reviewed changes

MediaRecorder.bs Show resolved Hide resolved

Pehrsons approved these changes Feb 18, 2025

View reviewed changes

MediaRecorder.bs Show resolved Hide resolved

jan-ivar added 2 commits February 18, 2025 08:40

Mention difficulty of detecting hardware synchronously

74b43f0

minor wordwrap

8829a55

guidou reviewed Feb 20, 2025

View reviewed changes

MediaRecorder.bs Outdated Show resolved Hide resolved

alvestrand reviewed Feb 27, 2025

View reviewed changes

MediaRecorder.bs Outdated Show resolved Hide resolved

Add avc1 and av01, and clarify profile levels are not exposed

ee35165

jan-ivar changed the title ~~Deprecate MediaRecorder.isTypeSupported() by limiting it to vp8, vp9, h264 and opus~~ Deprecate MediaRecorder.isTypeSupported() by limiting it to vp8, vp9, h264 aka avc1, av01, and opus Mar 6, 2025

Add av1 as alias for av01

485e795

jan-ivar changed the title ~~Deprecate MediaRecorder.isTypeSupported() by limiting it to vp8, vp9, h264 aka avc1, av01, and opus~~ Deprecate MediaRecorder.isTypeSupported() by limiting it to vp8, vp9, h264 aka avc1, av1 aka av01, and opus Mar 6, 2025

Add "pcm"

9ccf3a8

youennf closed this Jul 31, 2025

youennf reopened this Jul 31, 2025

handellm reviewed Sep 10, 2025

View reviewed changes

MediaRecorder.bs Show resolved Hide resolved

handellm reviewed Sep 11, 2025

View reviewed changes

Add hvc1(aka hev1, and avc1 aka avc3, and wildcard matching

0dd8b64

handellm reviewed Sep 18, 2025

View reviewed changes

jan-ivar commented Sep 18, 2025

View reviewed changes

MediaRecorder.bs Outdated Show resolved Hide resolved

avc1 != avc3

d0b61be

jan-ivar changed the title ~~Deprecate MediaRecorder.isTypeSupported() by limiting it to vp8, vp9, h264 aka avc1, av1 aka av01, and opus~~ Deprecate MediaRecorder.isTypeSupported() by limiting it to fixed list of identifiers w/wildcards Sep 18, 2025

Deprecate MediaRecorder.isTypeSupported() by limiting it to fixed list of identifiers w/wildcards #226

Are you sure you want to change the base?

Deprecate MediaRecorder.isTypeSupported() by limiting it to fixed list of identifiers w/wildcards #226

Conversation

jan-ivar commented Feb 17, 2025 • edited by pr-preview bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Pehrsons left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jan-ivar commented Mar 6, 2025

Uh oh!

jan-ivar commented Mar 6, 2025

Uh oh!

guidou commented Mar 20, 2025

Uh oh!

youennf commented Jul 31, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

youennf commented Jul 31, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

youennf commented Jul 31, 2025

Uh oh!

guidou commented Jul 31, 2025

Uh oh!

youennf commented Jul 31, 2025

Uh oh!

youennf commented Jul 31, 2025

Uh oh!

jan-ivar commented Jul 31, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

handellm commented Sep 11, 2025

Uh oh!

jan-ivar commented Sep 11, 2025

Uh oh!

jan-ivar commented Sep 11, 2025

Uh oh!

handellm commented Sep 12, 2025

Uh oh!

jan-ivar commented Sep 15, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

handellm Sep 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

handellm commented Sep 18, 2025

Uh oh!

Uh oh!

henbos commented Sep 18, 2025

Uh oh!

handellm commented Sep 18, 2025

Uh oh!

handellm commented Sep 24, 2025

Uh oh!

jan-ivar commented Feb 17, 2025 •

edited by pr-preview bot

Loading

youennf commented Jul 31, 2025 •

edited

Loading

youennf commented Jul 31, 2025 •

edited

Loading

handellm Sep 18, 2025 •

edited

Loading