Re: MediaStreams and canPlayType

On 17/10/14 13:15, Harald Alvestrand wrote:
> 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.

Yes, and I was only talking about the media-element.canPlayType, nothing 
on MediaStream(Track).

Stefan

>
> 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:57:17 UTC