4 ms·

Apple and Microsoft waited five years to deploy this thing. Given how quickly it was implemented and adopted by other browsers, I have to wonder what their moti

Apple and Microsoft waited five years to deploy this thing. Given how quickly it was implemented and adopted by other browsers, I have to wonder what their motives were for deliberately not integrating it; because frankly they could've done it pretty quickly at any point in the last five years. I remember having to integrate WebRTC through cordova (thank goodness somebody did it first) a couple years ago, and wondering why on earth Apple didn't find time or money for this. libwebrtc has been stable for years, it represents effectively no security risk, it performs well on all of their platforms. It truly boggles the mind.

abalone 9y ago
Don't forget energy efficiency. That's a huge priority for Apple and explains a lot of delays. Safari is way more energy efficient than Chrome.[1] [1] https://daringfireball.net/2017/05/safari_vs_chrome_on_the_mac https://daringfireball.net/2017/05/safari_vs_chrome_on_the_m...
- microcolonel 9y ago
  This is completely unrelated. This is a feature which their platform completely lacks, if they added this feature it would not have an effect on the energy efficiency of code which does not use it.
  - om2 9y ago
    In a sense you're right. But we also want to make sure WebRTC websites don't blow out your battery, and we went to some effort to make sure it uses efficient video encoding/decoding paths. That said, this was not a majority of the effort.
    - nottorp 9y ago
      Besides battery life, Chrome on the Mac prevents sleep indefinitely sometimes. If you check with pmset -g assertions, you'll see Chrome saying "WebRTC has active PeerConnections". No thanks Google, you shouldn't get to decide when my PC goes into sleep mode. I really hope Safari is better than that... Edit: just as i'm typing this, Chrome has: pid 19325(Google Chrome): [0x001ccbbb00018b19] 01:55:40 NoIdleSleepAssertion named: "WebRTC has active PeerConnections" 2 hours for... what? I have no idea which page is guilty.
      - om2 9y ago
        I believe Safari will block sleep only if there's actively playing video or audio in a foreground tab.
      - microcolonel 9y ago
        That seems more like a leak than normal behaviour. If you go to Window > Task Manager it'll tell you which PID corresponds to which tab.
        nottorp 9y ago
        It's the main Chrome process, I killed it and all Chrome windows were gone :) And i wouldn't call it a leak, you need to do extra work to prevent the system from sleeping, so someone did this intentionally. Oh well, since I had to close Chrome last evening to my computer will sleep, today I opened Safari as my main browser instead. Google annoys too much lately.
        microcolonel 9y ago
        I meant that whatever was supposed to clear the wakelock didn't run, thus leaking the wakelock. I really do find your problem odd, I recommend taking a look at your extensions if you want to track it down at some point. Safari's fine these days though, so you do you.
        nottorp 9y ago
        I've seen 6 hour wake locks as well. From Chrome. Even if it's a leak, why 6 hours?
  - matthewmacleod 9y ago
    But it would affect the efficiency of code that does use it, which is the whole point.
om2 9y ago
WebRTC is actually quite complicated to implement and it took a large effort by a big chunk of the WebKit team, even though we had a lot of code that we could reuse. People have a lot of theories about Safari deliberately omitting one feature or another, but the truth is there's only so much we can do at once. ETA: If you look at the page counts of all the required specs (ECMAScript APIs, WebRTC protocol specs, underlying codec and protocol specs like Opus and RTC) it adds up to multiple thousands of pages. By comparison, the whole HTML5 spec (current WHATWG version) is 855 pages.
- Matthias247 9y ago
  I'm not related to the Safari or any other browser team in any way. But I totally believe that it's a giant amount of work. I personally researched the effort which would just be required to implement webrtc data channels in a server application and have been rapidly been put off after seeing that I would need to have support STUN, TURN, ICE, DTLS and DTCP. With each of them having giant specs. The media formats and all the JS APIs would add on top of that. I guess it's also not an easy decision to "just include libwebrtc" into ones own application, since that's a giant dependency which pulls in lots of chromium code.
  - om2 9y ago
    We did end up using libwebrtc but we had to strip a lot of the dependencies and also update it use system services instead where appropriate.
    - dbrgn 9y ago
      That means you're aiming for WebRTC 1.0, not for ORTC, right?
      - om2 9y ago
        For now, yes. Our main goal in the short term is interop, since we are a little late to this party.
    - 9y ago
matthewmacleod 9y ago
WebRTC is a total pain in the arse in practice - maybe I've just had a bad experience, but it seems to be a ludicrously over complicated solution to the problem, and still ends up unreliable. I don't think that implementation of it is anywhere near as easy as you think.
- microcolonel 9y ago
  Most of the complexity in the WebRTC ecosystem (aside from things that are already done for you) is in the server space. You need STUN/TURN, you need to scale it, you have no idea how exactly to achieve that without spending infinite money. If your clients don't support your codecs, or you're proxying to SIP land (where you often won't have common codecs aside from A-law PCM), then you have to figure out a way not to blow your budget (both money and latency) on transcoding. That said, if you don't have the client in your browser, nobody gets to even try. You may think that WebRTC is a pain, but try implementing video chat with getUserMedia and WebSockets, or a custom plugin, and get back to me on how much of a pain WebRTC is.

abalone 9y ago

Don't forget energy efficiency. That's a huge priority for Apple and explains a lot of delays. Safari is way more energy efficient than Chrome.[1] [1] https://daringfireball.net/2017/05/safari_vs_chrome_on_the_mac https://daringfireball.net/2017/05/safari_vs_chrome_on_the_m...

microcolonel 9y ago
This is completely unrelated. This is a feature which their platform completely lacks, if they added this feature it would not have an effect on the energy efficiency of code which does not use it.
- om2 9y ago
  In a sense you're right. But we also want to make sure WebRTC websites don't blow out your battery, and we went to some effort to make sure it uses efficient video encoding/decoding paths. That said, this was not a majority of the effort.
  - nottorp 9y ago
    Besides battery life, Chrome on the Mac prevents sleep indefinitely sometimes. If you check with pmset -g assertions, you'll see Chrome saying "WebRTC has active PeerConnections". No thanks Google, you shouldn't get to decide when my PC goes into sleep mode. I really hope Safari is better than that... Edit: just as i'm typing this, Chrome has: pid 19325(Google Chrome): [0x001ccbbb00018b19] 01:55:40 NoIdleSleepAssertion named: "WebRTC has active PeerConnections" 2 hours for... what? I have no idea which page is guilty.
    - om2 9y ago
      I believe Safari will block sleep only if there's actively playing video or audio in a foreground tab.
    - microcolonel 9y ago
      That seems more like a leak than normal behaviour. If you go to Window > Task Manager it'll tell you which PID corresponds to which tab.
      - nottorp 9y ago
        It's the main Chrome process, I killed it and all Chrome windows were gone :) And i wouldn't call it a leak, you need to do extra work to prevent the system from sleeping, so someone did this intentionally. Oh well, since I had to close Chrome last evening to my computer will sleep, today I opened Safari as my main browser instead. Google annoys too much lately.
        microcolonel 9y ago
        I meant that whatever was supposed to clear the wakelock didn't run, thus leaking the wakelock. I really do find your problem odd, I recommend taking a look at your extensions if you want to track it down at some point. Safari's fine these days though, so you do you.
        nottorp 9y ago
        I've seen 6 hour wake locks as well. From Chrome. Even if it's a leak, why 6 hours?
- matthewmacleod 9y ago
  But it would affect the efficiency of code that does use it, which is the whole point.

om2 9y ago

WebRTC is actually quite complicated to implement and it took a large effort by a big chunk of the WebKit team, even though we had a lot of code that we could reuse. People have a lot of theories about Safari deliberately omitting one feature or another, but the truth is there's only so much we can do at once. ETA: If you look at the page counts of all the required specs (ECMAScript APIs, WebRTC protocol specs, underlying codec and protocol specs like Opus and RTC) it adds up to multiple thousands of pages. By comparison, the whole HTML5 spec (current WHATWG version) is 855 pages.

Matthias247 9y ago
I'm not related to the Safari or any other browser team in any way. But I totally believe that it's a giant amount of work. I personally researched the effort which would just be required to implement webrtc data channels in a server application and have been rapidly been put off after seeing that I would need to have support STUN, TURN, ICE, DTLS and DTCP. With each of them having giant specs. The media formats and all the JS APIs would add on top of that. I guess it's also not an easy decision to "just include libwebrtc" into ones own application, since that's a giant dependency which pulls in lots of chromium code.
- om2 9y ago
  We did end up using libwebrtc but we had to strip a lot of the dependencies and also update it use system services instead where appropriate.
  - dbrgn 9y ago
    That means you're aiming for WebRTC 1.0, not for ORTC, right?
    - om2 9y ago
      For now, yes. Our main goal in the short term is interop, since we are a little late to this party.
  - 9y ago

matthewmacleod 9y ago

WebRTC is a total pain in the arse in practice - maybe I've just had a bad experience, but it seems to be a ludicrously over complicated solution to the problem, and still ends up unreliable. I don't think that implementation of it is anywhere near as easy as you think.

microcolonel 9y ago
Most of the complexity in the WebRTC ecosystem (aside from things that are already done for you) is in the server space. You need STUN/TURN, you need to scale it, you have no idea how exactly to achieve that without spending infinite money. If your clients don't support your codecs, or you're proxying to SIP land (where you often won't have common codecs aside from A-law PCM), then you have to figure out a way not to blow your budget (both money and latency) on transcoding. That said, if you don't have the client in your browser, nobody gets to even try. You may think that WebRTC is a pain, but try implementing video chat with getUserMedia and WebSockets, or a custom plugin, and get back to me on how much of a pain WebRTC is.