Bug 1757861 Comment 8 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

FYI FF101 docs work for this can be tracked here: https://github.com/mdn/content/issues/15463

My understanding is that 
[`HTMLMediaElement.canPlayType()`](https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement/canPlayType), [`MediaCapabilities.decodingInfo()`](https://developer.mozilla.org/en-US/docs/Web/API/MediaCapabilities/decodingInfo) and [`MediaSource.isTypeSupported()`](https://developer.mozilla.org/en-US/docs/Web/API/MediaSource/isTypeSupported) all take (either directly or as some configuration) a type. This is in most cases referred to as a mime type but in the examples in the docs also includes codec types - e.g. `var mimeCodec = 'video/mp4; codecs="avc1.42E01E, mp4a.40.2"';`

So previously this codec string was ignored for AV1 codec strings. My understanding is that now the string will be parsed so the user will get a more accurate answer as to whether the file can be played. 
- Is that right?
- Is it just AV1 strings that are now parsed? Are strings for other codecs still ignored?

From a docs point of view we want to make it clear anything that a developer has to/can now do differently. Looking at those docs it looks like we say that the codec string can be used. So what actually do web developers need to know about this change for the docs. We could perhaps make the existence of the codec strings a bit more obvious in the parameters section. 

Is there a required [browser compatibility change](https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement/canPlayType#browser_compatibility)? Normally you'd add an entry if two browsers do something markedly different when passed the same inputs.  In this case I'm not sure - yes we'll be parsing the strings a bit better, but to end users that will mostly mean they'll just get a better indication of support, but still not "guarantees".
FYI FF101 docs work for this can be tracked here: https://github.com/mdn/content/issues/15463

What docs work in MDN do you think needs to be done for this? 

My understanding is that 
[`HTMLMediaElement.canPlayType()`](https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement/canPlayType), [`MediaCapabilities.decodingInfo()`](https://developer.mozilla.org/en-US/docs/Web/API/MediaCapabilities/decodingInfo) and [`MediaSource.isTypeSupported()`](https://developer.mozilla.org/en-US/docs/Web/API/MediaSource/isTypeSupported) all take (either directly or as some configuration) a type. This is in most cases referred to as a mime type but in the examples in the docs also includes codec types - e.g. `var mimeCodec = 'video/mp4; codecs="avc1.42E01E, mp4a.40.2"';`

So previously this codec string was ignored for AV1 codec strings. My understanding is that now the string will be parsed so the user will get a more accurate answer as to whether the file can be played. 
- Is that right?
- Is it just AV1 strings that are now parsed? Are strings for other codecs still ignored?

From a docs point of view we want to make it clear anything that a developer has to/can now do differently. Looking at those docs it looks like we say that the codec string can be used. So what actually do web developers need to know about this change for the docs. We could perhaps make the existence of the codec strings a bit more obvious in the parameters section. 

Is there a required [browser compatibility change](https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement/canPlayType#browser_compatibility)? Normally you'd add an entry if two browsers do something markedly different when passed the same inputs.  In this case I'm not sure - yes we'll be parsing the strings a bit better, but to end users that will mostly mean they'll just get a better indication of support, but still not "guarantees".

Back to Bug 1757861 Comment 8