media-source/mediasource-is-type-supported.html incorrectly assume that some webm mimetype are invalid

[jyavenard]

In media-source/mediasource-is-type-supported.html
we read:

          test_type_support([
              'video',
              'video/',
              'video/webm',
              'video/webm;',
              'video/webm;codecs',
              'video/webm;codecs=',
              'video/webm;codecs="',                                            
              'video/webm;codecs=""',                                           
              'video/webm;codecs=","',                                          
              '',                                                               
              null                                                              
          ], false, 'Test invalid MIME format');                                

This assumes that video/webm mimetype is invalid unless the codec is specified.

However, the MSE WebM Byte Stream Format found at http://w3c.github.io/media-source/webm-byte-stream-format.html#webm-media-segments

At no stage defined that the codec be specified (especially as video/mp4 on itself is valid)

If the webm mimetype contains no codec, the issue of checking that the codec are valid fall onto the
"Initialization Segment Received Algorithm" http://w3c.github.io/media-source/index.html#sourcebuffer-init-segment-received step 5.1

That entire list should be removed.

[plehegar]

@wolenetz , any chance you can take a look at this?

[jdsmith3000]

I agree with this bug. It can be argued that the MIME Type alone with codec information is not sufficient to accurately "support" a given format, but the response should be made based on the information provided. That means if video/webm is supported for any codecs, and that's all that is supplied, then the API should respond true. I think that's also the only literal conclusion you could make based on the isTypeSupported algorithm in the spec.

Note that some "valid isTypeSupported tests" may fail because the format is legitimately not supported. That is the root cause for several failures of webm vp8 and vorbis tests, among others.

[wolenetz]

Hmm. I see that the spec allows implication that isTypeSupported("video/webm")==true --> canPlayType("video/webm")==either "maybe" or "probably". This does not go the other way, even in literal interpretation of the isTYpeSupported algorithm in the spec. See step 5:

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

Literal interpretation of this could be that support of the specified combo of "video/webm" with no codecs is not supported by the MediaSource. Chrome goes this route currently, not allowing late-binding of actual codec later. I can see that other user agents may do late binding of actual codecs in initialization segment received algorithm versus vetting up-front the specific codec support by requiring the codec details in "isTypeSupported" call.

(especially as video/mp4 on itself is valid)

Likewise, MediaSource.isTypeSupported("video/mp4") is false on Chrome, even though document.createElement("video").canPlayType("video/mp4") results in "maybe".

We can relax the test, but I do not believe that Chrome is incorrectly implementing, just more strict in requiring codecs for mp4 and webm in addSourceBuffer().

[wolenetz]

Also note that the webm bytestream spec mentions "Implementations SHOULD support all of the codec IDs mentioned in the table above".

Please file a VNext MSE spec issue to try to get more clarity on expectation here.

[wolenetz]

(I filed w3c/media-source#137 to track clarifying interop behavior around this in MSE VNext. I recommend implementors try to require more specificity in mime type strings in the interim to alleviate eventual web app breakages if we don't unify on this before VNext.)

[jdsmith3000]

I can see an argument for requiring complete format information. I think though that the combination algorithm step you reference wasn't intended to be interpreted as you've done above. A MIME type on it's own contains perhaps insufficient information about the rendering needs, but it's not inherently a false condition. It's more of a "maybe".

I believe the combination step is for MIME type/codec combinations that are explicitly unsupported, like "audio/webm; codecs='vp8'", where each component element might be supported.

[wolenetz]

Certainly the latter (reject invalid combos) is covered by that step.
Again, I don't think Chrome is incorrect by saying it can't support an
underspecified mime-type with its MSE implementation. I would like for
implementations to agree on this going forward, but changing the spec is
VNext.

On Wed, Aug 3, 2016 at 4:00 PM jdsmith3000 notifications@github.com wrote:

I can see an argument for requiring complete format information. I think
though that the combination algorithm step you reference wasn't intended to
be interpreted as you've done above. A MIME type on it's own contains
perhaps insufficient information about the rendering needs, but it's not
inherently a false condition. It's more of a "maybe".

I believe the combination step is for MIME type/codec combinations that
are explicitly unsupported, like "audio/webm; codecs='vp8'", where each
component element might be supported.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#2409 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALCtw9RsGgYBXxcge4IGzL2rDX_SUznuks5qcR2HgaJpZM4Gtw1V
.