Re: MediaStreams and canPlayType

Hi Silvia,

I guess you're saying that gUM doc should say that canPlayType on the 
media element should not be used to understand if a MediaStream can be 
played (i.e. #1 below)?

For the proposal of adding canReceive/canSend on PeerConnection, that is 
a discussion that belongs in the WebRTC WG really. But personally I am a 
bit hesitant since this info is really in the SDPs where we have the 
possibility to add new formats (e.g. VP10, H.266) without any changes to 
the WebRTC spec. Adding canSend/Receive with the same content more or 
less means that we'd have to update the spec for new codecs.

Stefan



On 2014-10-17 10:59, Silvia Pfeiffer wrote:
> How about: Introduce an analogous canReceiveType() function on PeerConnection?
> Maybe even also a canSendType() ?
>
> I know, that's not gUM, but I don't think it really matters for gUM.
>
> Cheers,
> Silvia.
>
> On Fri, Oct 17, 2014 at 7:48 PM, Stefan Håkansson LK
> <stefan.lk.hakansson@ericsson.com> 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 10:07:48 UTC