This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
MIME type capability detection is really important for a lot of video player applications, and it has to be fast as to not introduce latency. It is currently really hard to tell what a MediaSource implementation is capable of playing. If you want to see if a user agent can play a certain MIME type via MediaSource you must currently: Create a MediaSource. Set it as the src on a <video> and add a callback to catch its transition to the "open" state. Once it is open, add a source buffer with the MIME that you want to play inside of a try catch statement. Catching a NOT_SUPPORTED_ERR is the current "no." Otherwise you can assume "yes." We should keep in mind the scenario where a user has a transcode that they prefer and that transcode cannot be played back via MediaSource but can be played back via <video>. Being able to get a synchronous answer here is probably most important. If there are strong feelings about reusing canPlayType from HTMLMediaElement that seems like a fine approach, otherwise we can define something specific for MediaSource.
http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html#byte-stream-formats says "Byte stream format specifications based on WebM and the ISO Base Media File Format are provided below. If these formats are supported then the byte stream formats described below must be supported." In other words, the spec requires that if you support WebM in plain <video>, then you must also support it using MSE. This means that you can just use HTMLMediaElement.canPlayType(), which is synchronous.
(In reply to comment #1) > http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source. > html#byte-stream-formats says > > "Byte stream format specifications based on WebM and the ISO Base Media File > Format are provided below. If these formats are supported then the byte > stream formats described below must be supported." > > In other words, the spec requires that if you support WebM in plain <video>, > then you must also support it using MSE. This means that you can just use > HTMLMediaElement.canPlayType(), which is synchronous. That wasn't my original intent when I wrote that. My original intent was "if you want to support WebM in MSE, then you must follow the rules that are outlined below". I didn't mean to imply that if canPlayType() indicates WebM support then the MSE implementation must support the associated bytestream as well. We can make that requirement explicit if people think that is the best path. I'm a little concerned that this would prevent UA's from incrementally adding support for different bytestream formats. If a UA supports both WebM & MP4 then they would have to add MediaSource support for both before exposing any MSE functionality. Chrome rolled out WebM-only support first and then eventually added MP4 later. I would assume that other UA's might want to follow a similar path. I was planning on responding to this bug with something along the lines of the following: partial interface MediaSource { static bool isTypeSupported(DOMString type); }; True would be returned if the UA is able to create a SourceBuffer for the specified type. This seemed a little more explicit than what canPlayType() returns.
Oh, you may want to rephrase what I quoted, then :)
(In reply to comment #2) > That wasn't my original intent when I wrote that. My original intent was "if > you want to support WebM in MSE, then you must follow the rules that are > outlined below". I didn't mean to imply that if canPlayType() indicates WebM > support then the MSE implementation must support the associated bytestream > as well. We should clarify this text. I think we definitely want to say that supporting a format in the HTML5 media element doesn't imply MSE support for it. > I was planning on responding to this bug with something along the lines of > the following: > > partial interface MediaSource { > static bool isTypeSupported(DOMString type); > }; Something like this seems reasonable.
Calling it canPlayType rather than isTypeSupported seems preferable to me, assuming that they have the same semantics.
Changes committed. http://dvcs.w3.org/hg/html-media/rev/0c638da9a67a isTypeSupported() was added based on discussion at TPAC. This method simply indicates whether the MediaSource implementation will accept a particular format. It was decided to keep this separate from HTMLMediaElement.canPlayType() because the ability to play a type does not mean that the MediaSource implementation can accept that type.
Changes committed http://dvcs.w3.org/hg/html-media/rev/43be42e69533