[microcolonel]

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.

[om2]

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.

[microcolonel]

I understand, though when it comes to WebRTC, there is an existing, efficient, stable implementation in a license which is compatible with WebKit and Apple's proprietary embeddings of it. You aren't going to be translating the WebRTC protocol diagrams and interfaces yourself. The main effort would be elsewhere (adapting it to Apple's platform TLS libraries perhaps, verifying the bindings, fitting it into the compositor, sandbox, etc.).

I would think the greatest barrier to integrating Opus would be getting Apple legal to agree not to sue other Opus adopters . Fair enough, but that's not five years worth of legal research. I would be gobsmacked if Apple bothered to write their own encoder or decoder just for WebKit, you don't need to read the bitstream format documentation.

And again, Apple has so much cash on hand that it takes the accountants five minutes to walk across a line on their balance sheets. Maybe the rest of you are busy, fine, but there are people who are qualified to put WebRTC in WebKit in the general public. Apple could send some money to the qualified people at Collabora, Igalia, or Ericsson Research (who I think have had WebRTC in Webkit since 2015).

All in all, it's absolutely bogus that Safari hasn't had WebRTC for at least two years already. You can make all the excuses you want, but this API drives more customer value than any ES6 feature. Nobody actually deploys ES6 on the web today, because it has forced browser vendors to completely reengineer their compilers, taking half a decade each, and as a result it has not been deployed long enough with decent performance to offer any value. WebRTC has been deployed for going on five years in valuable applications which are otherwise completely impossible on the web, half the other crap has no userbase, and offers questionable tangible value.

[alwillis]

I understand, though when it comes to WebRTC, there is an existing, efficient, stable implementation in a license which is compatible with WebKit and Apple's proprietary embeddings of it.

Just like with all of the other web standards, I'm pretty sure the WebRTC code is in the publicly available repo.

Obviously Apple isn't afraid to collaborate with other entities--Igalia did the CSS Grid implementation that ships in Safari and WebKit.

[kalleboo]

"Nobody deploys ES6 today since no browsers support ES6 yet so there's no point in browsers spending engineering effort adding ES6 support"

logic.

[Matthias247]

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]

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.

[Matthias247]

Thanks for the info. One more question on that: Do you think it makes sense to rerelease that independently or upstream the changes so that others could also include a more lightweight webrtc library? Or are your changes too far tied to Safari? I guess an optimal solution would need to have some kind of platform abstraction layer which then gets implemented by integrators like Chrome or Safari. Probably a big effort.

[microcolonel]

There's OpenWebRTC, which is optimized for standalone applications like media servers and proxies. The version in Chromium is also pretty easy to build and run in C/C++ applications on Linux, but requires extra work for an application like Safari.

[dbrgn]

That means you're aiming for WebRTC 1.0, not for ORTC, right?

[om2]

For now, yes. Our main goal in the short term is interop, since we are a little late to this party.

[abalone]

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_m...

[microcolonel]

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]

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]

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]

I believe Safari will block sleep only if there's actively playing video or audio in a foreground tab.

[microcolonel]

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]

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.

[matthewmacleod]

But it would affect the efficiency of code that does use it, which is the whole point.

[matthewmacleod]

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]

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.