Closed stefanalund closed 8 years ago
Seems reasonable to me, since supportVP8 is already included in the returned object. Might require a minor version bump.
yep.
@dagingaa that wouldn't break your use-case, right?
I pulled out the code I needed from this in my library some time ago. So that should be fine. We will probably make the same change to support other codecs as well. Having the VP8 support tests might prove useful in some cases though, but it's debatable if that should stick around in the webrtcsupport library. It's not fool proof for webrtc anyway the way it's written now.
For now, this doesn't affect us :)
On Sun, Oct 25, 2015, 18:09 Philipp Hancke notifications@github.com wrote:
yep.
@dagingaa https://github.com/dagingaa that wouldn't break your use-case, right?
— Reply to this email directly or view it on GitHub https://github.com/HenrikJoreteg/webrtcsupport/pull/20#issuecomment-150945788 .
We'll have RTPReceiver.getCapabilities at some point :-)
published as 2.2.0, thanks Stefan!
@legastero any idea why jingle still uses 1.x?
hrm. and simplewebrtc uses 1.x :-/ time for a breaking change there anyway.
No problem. Let me know when SimpleWebRTC.com is updated and I'll give it another try.
Would be nice if appear.in also adopts this change @dagingaa so that we could try if Bowser works.
That should work. Currently we only do advanced WebRTC testing in the API, our check at the service is much simpler (albeit a little outdated now perhaps). We only check if window.RTCPeerConnection and navigator.getUserMedia exists currently. Honestly we haven't touched the WebRTC bits in a little while, so if anything is broken, feel free to poke me at dagingaa@appear.in and I'll have a closer look :)
In some browser, such as Bowser, video playback is not the same as WebRTC video support.