Hacker News Reader

Comment by om2 | Hacker News Reader

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.

View on HN

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.

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.

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

logic.

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.

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.

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

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

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.

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.

Reply on news.ycombinator.com