5 ms·

I hope everyone enjoys WebRTC for the Curious (I am one of the authors). If you have any ideas on how to make it better I would love to hear :) WebRTC is absol

I hope everyone enjoys WebRTC for the Curious (I am one of the authors). If you have any ideas on how to make it better I would love to hear :) WebRTC is absolutely magical. Having 'Web' in the name does it a disservice. I see it used to. * Remotely control excavators * Security Cameras * Connect autonomous robots in factories * Low latency streaming from sail boats and rocket ships * And all the use cases you expect (Conferencing, Telehealth etc..)

fidotron 2y ago
My experience is WebRTC has an on-ramp problem, which this is partly to address, but it is significantly helped if you are thrown in the deep end to work on it with someone that knows the quirks already. The big thing I got from that process was to stop being afraid of reading the SDP, because a huge amount of the problems you will run into are really the result of SDP oddities. It is credit to people like the libwebrtc maintainers that the complex morass of MediaStreamTrack processing is as solid and performant as it is these days. (And extendable). I share the view that it should form the basis of real time communication, humans involved or not, and a/v media involved or not. There seems to be some progress on applying absolute timestamps to frames, for example, however, at some point if we want to have rocket ships using it (and I do too) we will eventually need to have some way to reconcile divergent clocks used at different sources! Sean is modestly not mentioning Pion here, which is the lower level library many golang people reach to for webrtc components, and deservedly so.
- Sean-Der 2y ago
  I need to finish it but 'Reading the SDP' I hope to solve with https://pe.pion.ly/ https://pe.pion.ly/ (https://github.com/pion/explainer https://github.com/pion/explainer). You can just your Offer/Answer in and interactively explore what has been configured. WebRTC's complexity can be frustrating. I believe it is inherent to how many things it is trying to solve. If an alternative arrives that solves everything WebRTC does, it will end up being just as complex. Or maybe not! Time will tell.
- quantadev 2y ago
  For JavaScript developers "simple-peer" npm package is very popular and makes WebRTC very simple. I don't think its' an on-ramp problem, holding it back, it's just that most apps don't necessarily benefit from P2P coms, and also I'd hazard a guess not many people know about WebRTC, yet. Just guessing.
  - 01HNNWZ0MV43FF 2y ago
    In the c++ world I definitely felt the on ramp. Not surprised it is easier in js and go
    - quantadev 2y ago
      I was a C++ dev all thru the 1990s, but moved to Java, JS, Python. There's really no good argument for using C++ nowadays in 99.999% of apps. Unless you're doing something VERY special like realtime stuff, or something where each action of the CPU needs to be controlled directly, you just don't need it. I'm sure you know that, tho. Not preaching at you. I learned Python as recently as 2023, just so I could get deep into the AI landscape and access all those libraries/tools.
    - fidotron 2y ago
      In JS it's amazingly easier because of how you can just await on peerconnection calls, which makes developing the happy path version of the code much faster, that can then be progressively extended with proper error handling. My experience of it in Java/C++/Golang is in every case you have to deal with all the problems far more upfront before any of it works at all. And JS doesn't have the multithreaded aspect to handle, which is also the major weakness as it eliminates the extensability in that environment. I have a sort of proof of concept level SFU in golang, with a simple TypeScript/React client, and the whole client is this: https://github.com/atomirex/umbrella/blob/master/frontend/src/umbrella/SfuApp.tsx https://github.com/atomirex/umbrella/blob/master/frontend/sr... and most of the complexity there is because I can never remember if track ID or transceiver MID should be used in different situations!
      - 2y ago
lelandbatey 2y ago
I cannot thank you enough for writing this; the very first page with the "What, Why and How" is precisely what I wish were written for every "thing" I have ever worked with. It's so clear, and contextualizes so much so quickly, I'm frankly in awe. Thank you for your contributions!
- Sean-Der 2y ago
  Of course! I think the 'What, Why and How' captures the purpose and joy of learning. Nothing is better then getting lost in a fun problem. I don't want to just understand how it is solved, but the story about how it got solved. If you have any feedback on how the book could be better would love to hear!
spencerflem 2y ago
Thanks so much for the book! Its lovely
- Sean-Der 2y ago
  Of course! Glad you enjoyed it. If you have any feedback on how to make it better I would love to hear :)
neom 2y ago
WebRTC is amazing! I think it might be helpful for some younger folks if you talked about UDP, I realize it's maybe a bit "weird" - however coming from the UDP world helped me think about all the ways WebRTC can be used. I think it's one of the most underrated and underutilized technologies.

fidotron 2y ago

My experience is WebRTC has an on-ramp problem, which this is partly to address, but it is significantly helped if you are thrown in the deep end to work on it with someone that knows the quirks already. The big thing I got from that process was to stop being afraid of reading the SDP, because a huge amount of the problems you will run into are really the result of SDP oddities. It is credit to people like the libwebrtc maintainers that the complex morass of MediaStreamTrack processing is as solid and performant as it is these days. (And extendable). I share the view that it should form the basis of real time communication, humans involved or not, and a/v media involved or not. There seems to be some progress on applying absolute timestamps to frames, for example, however, at some point if we want to have rocket ships using it (and I do too) we will eventually need to have some way to reconcile divergent clocks used at different sources! Sean is modestly not mentioning Pion here, which is the lower level library many golang people reach to for webrtc components, and deservedly so.

Sean-Der 2y ago
I need to finish it but 'Reading the SDP' I hope to solve with https://pe.pion.ly/ https://pe.pion.ly/ (https://github.com/pion/explainer https://github.com/pion/explainer). You can just your Offer/Answer in and interactively explore what has been configured. WebRTC's complexity can be frustrating. I believe it is inherent to how many things it is trying to solve. If an alternative arrives that solves everything WebRTC does, it will end up being just as complex. Or maybe not! Time will tell.
quantadev 2y ago
For JavaScript developers "simple-peer" npm package is very popular and makes WebRTC very simple. I don't think its' an on-ramp problem, holding it back, it's just that most apps don't necessarily benefit from P2P coms, and also I'd hazard a guess not many people know about WebRTC, yet. Just guessing.
- 01HNNWZ0MV43FF 2y ago
  In the c++ world I definitely felt the on ramp. Not surprised it is easier in js and go
  - quantadev 2y ago
    I was a C++ dev all thru the 1990s, but moved to Java, JS, Python. There's really no good argument for using C++ nowadays in 99.999% of apps. Unless you're doing something VERY special like realtime stuff, or something where each action of the CPU needs to be controlled directly, you just don't need it. I'm sure you know that, tho. Not preaching at you. I learned Python as recently as 2023, just so I could get deep into the AI landscape and access all those libraries/tools.
  - fidotron 2y ago
    In JS it's amazingly easier because of how you can just await on peerconnection calls, which makes developing the happy path version of the code much faster, that can then be progressively extended with proper error handling. My experience of it in Java/C++/Golang is in every case you have to deal with all the problems far more upfront before any of it works at all. And JS doesn't have the multithreaded aspect to handle, which is also the major weakness as it eliminates the extensability in that environment. I have a sort of proof of concept level SFU in golang, with a simple TypeScript/React client, and the whole client is this: https://github.com/atomirex/umbrella/blob/master/frontend/src/umbrella/SfuApp.tsx https://github.com/atomirex/umbrella/blob/master/frontend/sr... and most of the complexity there is because I can never remember if track ID or transceiver MID should be used in different situations!
    - 2y ago

lelandbatey 2y ago

I cannot thank you enough for writing this; the very first page with the "What, Why and How" is precisely what I wish were written for every "thing" I have ever worked with. It's so clear, and contextualizes so much so quickly, I'm frankly in awe. Thank you for your contributions!

Sean-Der 2y ago
Of course! I think the 'What, Why and How' captures the purpose and joy of learning. Nothing is better then getting lost in a fun problem. I don't want to just understand how it is solved, but the story about how it got solved. If you have any feedback on how the book could be better would love to hear!

spencerflem 2y ago

Thanks so much for the book! Its lovely

Sean-Der 2y ago
Of course! Glad you enjoyed it. If you have any feedback on how to make it better I would love to hear :)

neom 2y ago

WebRTC is amazing! I think it might be helpful for some younger folks if you talked about UDP, I realize it's maybe a bit "weird" - however coming from the UDP world helped me think about all the ways WebRTC can be used. I think it's one of the most underrated and underutilized technologies.