3 ms·

WebRTC was created to replace the need for apps that handle calling, without web push notifications (like every other WebRTC supporting browser has) there is no

WebRTC was created to replace the need for apps that handle calling, without web push notifications (like every other WebRTC supporting browser has) there is no way for inbound calls to cause the phone to receive a notification unless Safari is open and has the webpage pulled up. WRT VP8/VP9, bandwidth is much more of a concern than you make it out to be. Network bandwidth on mobile devices is inconsistent, unstable, and often relatively low (say hello to congested towers, or fringe 700Mhz coverage where 500Kbps is all you get :P), thus the best compression possible ensures that video quality and usability is top notch. By restricting video to H.264, your stuck with a legacy codec that has relatively poor compression rates compared to the other standardized codecs. Is it good for interop with a 2005 era deskphone? Sure, but not much else.

eridius 8y ago
Google Meet is a video conferencing app, not a telephone replacement. AFAIK there's no way to "call" someone. So Web Push seems to be rather irrelevant. > Network bandwidth on mobile devices is inconsistent, unstable, and often relatively low I'm not using Google Meet on a cellular network. I'm using it on a wifi network. And if it comes to it, I'd rather have slightly worse video quality with H.264 than slightly better video quality with VP8/9 if it means it preserves my battery life (which is to say, set a network bandwidth target and then use whatever video quality meets that target). > By restricting video to H.264, your stuck with a legacy codec that has relatively poor compression rates compared to the other standardized codecs. It's apparently really hard to find an actual practical comparison of compression quality of H.264 vs VP8. What info I did find is about 8 years old now and itself was pretty wishy-washy. My vague impression of all of this is "lots of people think VP8 has better compression quality, but won't say by how much, while other people think you can get about the same results, but either way VP8 is rarely hardware-accelerated on mobile". In any case, if you want better than H.264, how about H.265, which macOS and iOS both support? I have no idea if WebRTC allows the endpoints to negotiate alternative codecs, and I'm having difficulty finding the answer to that.
- StudentStuff 8y ago
  > Google Meet is a video conferencing app, not a telephone replacement. Great, I really don't care about Google's WebRTC app of the month, it is unlikely to be with us in 10 years. Your root question about why Google hasn't supported Safari with their Meet product likely boils down to the codec wars, as without VP8/VP9 support, Safari does not support the WebRTC standard. A reasonable thing Safari could do is rank codecs by power usage, prioritizing H.264 front and center. Another take is the failing tests listed here, Google could easily depend on a component that Safari has not implemented (once again not WebRTC spec compliant): https://wpt.fyi/results/webrtc?label=stable&aligned https://wpt.fyi/results/webrtc?label=stable&aligned > In any case, if you want better than H.264, how about H.265 H.265 is a patent encumbered, licensed codec that is only supported by Safari & Edge (if you download the H.265 codec manually on Win10). At this point, Apple, Mozilla, Google, Microsoft and others are working on AV1 as a successor: https://headjack.io/blog/hevc-vp9-vp10-dalaa-thor-netvc-future-video-codecs/ https://headjack.io/blog/hevc-vp9-vp10-dalaa-thor-netvc-futu... > I have no idea if WebRTC allows the endpoints to negotiate alternative codecs, and I'm having difficulty finding the answer to that. You can send literally anything in the SDP that you want, WebRTC is a forklift of traditional SIP onto the web, but with things like TLS enforced (otherwise idiots like the entire existing VoIP industry will run all signaling & calls over UDP with no crypto, then claim its "secure"). The only limitations you have are the codecs supported by your device, though you could totally write your own fairly complex codec in javascript :P
  - eridius 8y ago
    > once again not WebRTC spec compliant According to the page you linked, nobody is spec-compliant. I'm going to guess that Google's lack of support for Safari boils down to video codec and nothing else. > A reasonable thing Safari could do is rank codecs by power usage, prioritizing H.264 front and center. Apple does not have any support for VP8/9, period. And I will be extremely surprised if they ever add support for a non-hardware-accelerated video codec. Apple believes in power efficiency over pretty much anything else, which makes hardware acceleration mandatory for something like this.

eridius 8y ago

Google Meet is a video conferencing app, not a telephone replacement. AFAIK there's no way to "call" someone. So Web Push seems to be rather irrelevant. > Network bandwidth on mobile devices is inconsistent, unstable, and often relatively low I'm not using Google Meet on a cellular network. I'm using it on a wifi network. And if it comes to it, I'd rather have slightly worse video quality with H.264 than slightly better video quality with VP8/9 if it means it preserves my battery life (which is to say, set a network bandwidth target and then use whatever video quality meets that target). > By restricting video to H.264, your stuck with a legacy codec that has relatively poor compression rates compared to the other standardized codecs. It's apparently really hard to find an actual practical comparison of compression quality of H.264 vs VP8. What info I did find is about 8 years old now and itself was pretty wishy-washy. My vague impression of all of this is "lots of people think VP8 has better compression quality, but won't say by how much, while other people think you can get about the same results, but either way VP8 is rarely hardware-accelerated on mobile". In any case, if you want better than H.264, how about H.265, which macOS and iOS both support? I have no idea if WebRTC allows the endpoints to negotiate alternative codecs, and I'm having difficulty finding the answer to that.

StudentStuff 8y ago
> Google Meet is a video conferencing app, not a telephone replacement. Great, I really don't care about Google's WebRTC app of the month, it is unlikely to be with us in 10 years. Your root question about why Google hasn't supported Safari with their Meet product likely boils down to the codec wars, as without VP8/VP9 support, Safari does not support the WebRTC standard. A reasonable thing Safari could do is rank codecs by power usage, prioritizing H.264 front and center. Another take is the failing tests listed here, Google could easily depend on a component that Safari has not implemented (once again not WebRTC spec compliant): https://wpt.fyi/results/webrtc?label=stable&aligned https://wpt.fyi/results/webrtc?label=stable&aligned > In any case, if you want better than H.264, how about H.265 H.265 is a patent encumbered, licensed codec that is only supported by Safari & Edge (if you download the H.265 codec manually on Win10). At this point, Apple, Mozilla, Google, Microsoft and others are working on AV1 as a successor: https://headjack.io/blog/hevc-vp9-vp10-dalaa-thor-netvc-future-video-codecs/ https://headjack.io/blog/hevc-vp9-vp10-dalaa-thor-netvc-futu... > I have no idea if WebRTC allows the endpoints to negotiate alternative codecs, and I'm having difficulty finding the answer to that. You can send literally anything in the SDP that you want, WebRTC is a forklift of traditional SIP onto the web, but with things like TLS enforced (otherwise idiots like the entire existing VoIP industry will run all signaling & calls over UDP with no crypto, then claim its "secure"). The only limitations you have are the codecs supported by your device, though you could totally write your own fairly complex codec in javascript :P
- eridius 8y ago
  > once again not WebRTC spec compliant According to the page you linked, nobody is spec-compliant. I'm going to guess that Google's lack of support for Safari boils down to video codec and nothing else. > A reasonable thing Safari could do is rank codecs by power usage, prioritizing H.264 front and center. Apple does not have any support for VP8/9, period. And I will be extremely surprised if they ever add support for a non-hardware-accelerated video codec. Apple believes in power efficiency over pretty much anything else, which makes hardware acceleration mandatory for something like this.