8 ms·

Unfortunately Safari is still a major hold out on WebTransport with no clear update, considering all other browsers have now supported it in GA for 3+ years.

by gvkhna 3y ago

englishm 3y ago
I don't know the timeline, but Apple has committed [1] to adding WebTransport support to WebKit. [1]: https://github.com/WebKit/standards-positions/issues/18#issuecomment-1495890122 https://github.com/WebKit/standards-positions/issues/18#issu...
- kixelated 3y ago
  Eric Kinnear (linked post; Apple) is the author of the HTTP/2 fallback for WebTransport, so it's safe to say that WebTransport will be available in WebKit at some point.
- gvkhna 3y ago
  Great news! It looks like Google GRPC team is probably waiting for Safari Webtransport support to implement grpc over the web in WT. Even though Chrome has had it for 2 years they have kept saying they’ll wait until it becomes GA.
gs17 3y ago
Yeah, I have a project where WebTransport would be a huge improvement, but not being able to support Safari is a dealbreaker.
doctorpangloss 3y ago
Google Chrome never implemented trailers, so no gRPC. Every browser is guilty. > I spent almost two years building/optimizing a partial WebRTC stack @ Twitch using pion. Our use-case was quite custom and we ultimately scrapped it, but your millage may vary. So many words about protocols. Protocols aren't hard or interesting. QA is hard. libwebrtc has an insurmountable lead on QA. None of these ad-hoc things, nor WebRTC implementations like Pion, will ever catch up, let alone be deployed in Mobile Safari.
- Sean-Der 3y ago
  I am not at Twitch anymore so can't speak to what the state of the things today are. WebRTC was deployed and is in use. For twitch.tv you have Guest Star [0] You can use that same back-end via IVS Stages[1]. I always call it 'White-label Twitch', but it is more nuanced then that! Some pretty big/interesting customers were using it. [0] https://help.twitch.tv/s/article/guest-star?language=en_US https://help.twitch.tv/s/article/guest-star?language=en_US [1] https://docs.aws.amazon.com/ivs/latest/RealTimeUserGuide/what-is.html https://docs.aws.amazon.com/ivs/latest/RealTimeUserGuide/wha...
- fidotron 3y ago
  I agree with the general thrust of this, but libwebrtc has a tendency to have Google convenient defaults which are distinctly non obvious, such as the quality vs framerate tradeoffs being tied to what Hangouts needs to implement as opposed to useful general purpose hooks. (I hope they have updated that API since I last looked). Once you know how to poke it to make it do what you want, which tends to require reading the C++ source, it's definitely got a massive head start, especially around areas like low level hardware integration. Even bolting on ML inference and so on is not hard. The huge point though is everyone knows everyone has to talk to libwebrtc at some point, so it is the de facto implementation of SDP etc. Curiously I was working on a webrtc project for about 18 months which also hit the wall, however, since then I have learned of several high profile data only libwebrtc deployments, which really just use it in the way classic libjingle was intended to be used, P2P, NAT punching etc. I'd go so far as to say if you don't have a P2P aspect to what you're doing with libwebrtc you're missing the point. The big picture though is there seems to be a general denial of the fact that web style CDNs and multidirectional media streaming graphs are two totally different beasts.
  - kixelated 3y ago
    Yeah, if you're using WebRTC only for data channels, then 100% you should switch to WebTransport with all due haste. Once Safari adds support of course.
    - fidotron 3y ago
mehagar 3y ago
It's being worked on now: https://github.com/WebKit/WebKit/pull/17320 https://github.com/WebKit/WebKit/pull/17320
jeroenhd 3y ago
And Firefox hasn't implemented WebCodecs yet. At this moment, the WebTransport+WebCodecs solution is a no-go unless you only intend to serve Chromium. Fortunately, Mozilla is working on WebCodecs and Apple is working on WebTransport, so these problems will probably disappear in the future.
deleted 3y ago
[deleted]

Unfortunately Safari is still a major hold out on WebTransport with no clear update, considering all other browsers have now supported it in GA for 3+ years.

by gvkhna 3y ago

Unfortunately Safari is still a major hold out on WebTransport with no clear update, considering all other browsers have now supported it in GA for 3+ years.

englishm 3y ago

I don't know the timeline, but Apple has committed [1] to adding WebTransport support to WebKit. [1]: https://github.com/WebKit/standards-positions/issues/18#issuecomment-1495890122 https://github.com/WebKit/standards-positions/issues/18#issu...

kixelated 3y ago
Eric Kinnear (linked post; Apple) is the author of the HTTP/2 fallback for WebTransport, so it's safe to say that WebTransport will be available in WebKit at some point.
gvkhna 3y ago
Great news! It looks like Google GRPC team is probably waiting for Safari Webtransport support to implement grpc over the web in WT. Even though Chrome has had it for 2 years they have kept saying they’ll wait until it becomes GA.

gs17 3y ago

Yeah, I have a project where WebTransport would be a huge improvement, but not being able to support Safari is a dealbreaker.

doctorpangloss 3y ago

Google Chrome never implemented trailers, so no gRPC. Every browser is guilty. > I spent almost two years building/optimizing a partial WebRTC stack @ Twitch using pion. Our use-case was quite custom and we ultimately scrapped it, but your millage may vary. So many words about protocols. Protocols aren't hard or interesting. QA is hard. libwebrtc has an insurmountable lead on QA. None of these ad-hoc things, nor WebRTC implementations like Pion, will ever catch up, let alone be deployed in Mobile Safari.

Sean-Der 3y ago
I am not at Twitch anymore so can't speak to what the state of the things today are. WebRTC was deployed and is in use. For twitch.tv you have Guest Star [0] You can use that same back-end via IVS Stages[1]. I always call it 'White-label Twitch', but it is more nuanced then that! Some pretty big/interesting customers were using it. [0] https://help.twitch.tv/s/article/guest-star?language=en_US https://help.twitch.tv/s/article/guest-star?language=en_US [1] https://docs.aws.amazon.com/ivs/latest/RealTimeUserGuide/what-is.html https://docs.aws.amazon.com/ivs/latest/RealTimeUserGuide/wha...
fidotron 3y ago
I agree with the general thrust of this, but libwebrtc has a tendency to have Google convenient defaults which are distinctly non obvious, such as the quality vs framerate tradeoffs being tied to what Hangouts needs to implement as opposed to useful general purpose hooks. (I hope they have updated that API since I last looked). Once you know how to poke it to make it do what you want, which tends to require reading the C++ source, it's definitely got a massive head start, especially around areas like low level hardware integration. Even bolting on ML inference and so on is not hard. The huge point though is everyone knows everyone has to talk to libwebrtc at some point, so it is the de facto implementation of SDP etc. Curiously I was working on a webrtc project for about 18 months which also hit the wall, however, since then I have learned of several high profile data only libwebrtc deployments, which really just use it in the way classic libjingle was intended to be used, P2P, NAT punching etc. I'd go so far as to say if you don't have a P2P aspect to what you're doing with libwebrtc you're missing the point. The big picture though is there seems to be a general denial of the fact that web style CDNs and multidirectional media streaming graphs are two totally different beasts.
- kixelated 3y ago
  Yeah, if you're using WebRTC only for data channels, then 100% you should switch to WebTransport with all due haste. Once Safari adds support of course.
  - fidotron 3y ago

mehagar 3y ago

It's being worked on now: https://github.com/WebKit/WebKit/pull/17320 https://github.com/WebKit/WebKit/pull/17320

jeroenhd 3y ago

And Firefox hasn't implemented WebCodecs yet. At this moment, the WebTransport+WebCodecs solution is a no-go unless you only intend to serve Chromium. Fortunately, Mozilla is working on WebCodecs and Apple is working on WebTransport, so these problems will probably disappear in the future.

deleted 3y ago

[deleted]