Re: MediaStreams and canPlayType

A MediaStream is a control surface for what the browser does with media.

The concept of a "type" is totally foreign to the concept of a 
MediaStream; if the MediaStream(track) can be created, the browser can 
play it - it was created by the very same browser!

Wherever the MediaStream converts into something that can be passed over 
the network, types are of relevance: MediaStreamRecorder, <video> tag 
rendering to canvas, WebAudio rendering to audio buffers, 
PeerConnections rendering to RTP - and at the corresponding interfaces 
for incoming, the media type is also of relevance.

But this needs to be functions that belong on that interface, not on the 
MediaStream.

MediaStreams are abstractions that live in the browser. The browser can 
always do it.

On 10/17/2014 10:48 AM, Stefan Håkansson LK wrote:
> I recently came across a WebRTC site that used video.canPlayType to
> check up front if the endpoint was compatible with their service or not.
>
> Our document says nothing about this, and I think it should (but I'm not
> sure what it should say).
>
> Off the top of my head there are a couple of paths we could follow:
>
> #1: state that canPlayType is unsuitable to check compatibility with
> MediaStreams of a certain format and that it can be assumed that
> anything the PeerConnection can negotiate can be played (as well as of
> course any strictly locally generated media). The follow up question is
> of course how you check if the PeerConnection will be able to decode
> your network streams without doing a call set up with negotiation, I
> guess there the answer would be to use createOffer and parse the SDP.
>
> #2: Define strings (mime-types?) that can be used with canPlayType to
> see if the video element can play the MediaStream format in question.
>
> Should we do something about this, and if so, #1, #2 or something else?
>
> Stefan
>

Received on Friday, 17 October 2014 11:15:16 UTC