- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Fri, 17 Oct 2014 19:58:49 +1100
- To: Stefan HÃ¥kansson LK <stefan.lk.hakansson@ericsson.com>
- Cc: "public-media-capture@w3.org" <public-media-capture@w3.org>
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 08:59:37 UTC