Hacker News new | past | comments | ask | show | jobs | submit login

WebRTC was the #1 most requested web platform feature for Safari. Now coming to macOS and iOS: https://webkit.org/blog/7726/announcing-webrtc-and-media-cap...

You can even try it out now on Safari Technology Preview: https://webkit.org/blog/7627/safari-technology-preview-32/




About fucking time. I've literally been waiting for this for two and a half years!

This is absolutely huge. Many, many services that could once only be provided at a premium fee or by large to massive companies like Skype or Google can now be offered for free by small start-ups without having to worry about "this page was designed to be viewed in [preferred browser] version [foo] or higher" hassles.


> I've literally been waiting for this for two and a half years!

Well, I have been figuratively waiting for it for 6 years.


If people had just built on Doug Engelbart's NLS then we could have had this decades ago :P


Well the version part still doesn’t go away ;)


Does it support VP8 as required by RFC 7742 "WebRTC Video Processing and Codec Requirements"?


Not in the version that will ship in iOS 11 / High Sierra. Not yet determined for future versions.


If there's anything we (Mozilla) can do to help, please let us know.


So, "full support" might be misleading to put in the title.


Is that a political or technical decision?


They would likely argue that HEVC and H.264 are hardware accelerated on nearly all of their devices whereas VP8 likely isn’t. This would mean compromising on battery life as they’d have to provide a software fallback where needed. I don’t see Apple being very willing to provide a bad user experience and given how hard they were pushing HEVC during their 2017 WWDC keynote the best bet is that they think that’s the better option.

Alternatively they’d have to add VP8 support in their chips and one suspects they would be unwilling to spend silicon on that which could otherwise be used for whatever witchcraft their silicon designers are whipping up.

I’d grant that as a valid technical reason for limited video codec support. Silicon and battery are at a premium.



I always find it disappointing when video from Apple doesn't work in Firefox. There are quite a few JavaScript libraries available these days which support HLS in browsers which don't have built-in HLS support but Apple doesn't make use of them.


Apple should stop fooling around, and start using DASH+MSE instead. But being Apple, they have very hard time letting go of their NIH and lock-in.


The problem with DASH these days is that you might have to buy a patent license to use it. The MPEG LA wants to sell you one anyhow:

http://www.mpegla.com/main/programs/MPEG-DASH/Pages/Intro.as...

HLS has no such problems which makes it the better choice.


Ah, so these freaks already managed to make claims. I hope someone will work on busting them. I highly doubt HLS is in any better shape in this regard.

And Columbia University is in that patent trolls list. Disgusting.

UPDATE:

Going through that site, I found their attempt to leech on VC-1: http://www.mpegla.com/main/programs/VC1/Documents/vc-1-att1....

And they list Microsoft there, which is strange, since MS are part of Alliance for Open Media which is an antithesis of this trolling cartel. Either MS are sitting on both chairs, or MPEGLA are trying to fool everyone.


Apple should stop fooling around, and start using DASH+MSE instead. But being Apple, they have very hard time letting go of their NIH and lock-in.

Apple was doing video [1] long before Firefox and the web were a thing; perhaps it's Mozilla that needs to get with the times and industry standards.

[1]https://en.wikipedia.org/wiki/QuickTime


> perhaps it's Mozilla that needs to get with the times

Mozilla is with the times. HLS works well in Firefox. You just do it with JavaScript and it's disappointing that Apple doesn't bother to do that on their website.

Here's an article on JavsScript based HLS from a couple of years ago:

https://blog.peer5.com/http-live-streaming-in-javascript/


Again, performance and battery life is going to be better with Apple’s approach for mobile devices, especially since iOS devices have hardware accelerated playback.


> with Apple’s approach for mobile devices

Web browser considerations aren't relevant on iOS because Apple forbids alternative browser engines. Firefox on iOS is not Firefox because Apple doesn't allow it to use Firefox's JS runtime or Firefox's render engine. As a result there isn't any true browser competition on the iOS platform, which is a shame.

Personally, I want to run full, real Firefox on my iPhone. It's a low quality move from Apple that they stop me doing that.


Well, ditch Apple. Why do you put up with this?


That's a bogus argument, since nothing stops Apple from supporting common standards in their hardware, instead if NIH.


DASH is being with the times and standards. HLS is being Apple.


> They would likely argue that HEVC and H.264 are hardware accelerated on nearly all of their devices whereas VP8 likely isn’t.

I'm sure a lot of them do, but it's also true that there are a lot of Mac laptops out there which will be upgraded to High Sierra that don't have hardware HEVC acceleration.


WebRTC has codec negotiation, which means you can give preference to a particular codec while still supporting both.


Except that open source and free software can't (legally) do that.

Both HEVC and H.264 require the patent holders to be paid in order to be allowed on either a device or content.


Right.... so an open source program/device might only offer VP8. While Apple could offer both H264/HEVC and VP8, preferring the former.


They could, but as discussed in this thread, they won't. This means chromium, for example, will not be able to webrtc video with Apple devices.


Cisco provides a fully licensed encoder, OpenH264, that you can download for free (Firefox uses it). That loophole was removed for H.265, though. I would have rather had only VP8 mandatory to implement in the standard, but at least this situation is better than the reverse.


Is that a political or technical decision?

One obvious technical issue is that, as far as we know, there's no VP8 decoding hardware in any of Apple's products; implementing VP8 decoding in software might be more of a power drain than Apple wanted.


> there's no VP8 decoding hardware in any of Apple's products

But what I found interesting in the WWDC session you linked to was that a lot of Apple products don't have hardware HEVC decode and\or hardware HEVC encode support. Apple has implemented software HEVC decoding and encoding in a lot of places. From that perspective, adding support for VP8 and VP9 wouldn't be much different.


Apple avoid supporting free codecs, because they are part of closed codecs cartel. So they do all they can to delay adoption of free codecs. Note, that they didn't join Alliance for Open Media, while even Microsoft did: http://aomedia.org


Do you think you would get an answer to this question?


I can't get many WebRTC projects/test pages to actually work on the new Safari preview. Is there anywhere they list the specific features implemented from the spec?


We're working individually with WebRTC sites to get them running. There's complications because many sites use legacy APIs that are not in the spec but still exist in Chrome. We're adding some of those for more compatibility.


Is there any chance for Screen(or window or tab) Sharing to make it in?


Not in High Sierra / iOS 11 but we're aware of this and considering it for a future version.


Shame it didn't make the current version, but great to hear it will be available in a later one.


To be clear, no promises. But we're definitely considering it and it seems like useful functionality.


It looks like RTCPeerConnection(config) is throwing an error if you don't pass in a null config.


Actually, the problem was using the deprecated 'url' property, rather than the newer 'urls' (which works).


Most on this page work: https://webrtc.github.io/samples/



Unfortunately this test page uses legacy APIs that have been removed from the spec years ago, so it can't give an accurate assessment.



The audio capture fails, then the camera gets stuck on "Check resolution 320x240" without error.

If I tick "Remove Legacy WebRTC API", and retry, they all fail until it gets stuck with no message on "Udp enabled".




Applications are open for YC Winter 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: