I am Tsahi Levent-Levi, also known as BlogGeek.me I offer consulting and analysis services for WebRTC and digital communication technologies.
For training courses on WebRTC check out webrtccourse.com For testing, monitoring and support of WebRTC applications see testrtc.com For me directly, look at bloggeek.me
It isn't, but I've noticed many in the video API domain struggling with it. The main difference is elsewhere - the video API space has a lot more variety and differences in behavior than many other domains, so you end up with an abstraction layer that ends up being quite complex if your use case isn't the most simple and straightforward one.
Missed this one somehow. The process isn't a simple one and won't fit a comment here. It is detailed in my WebRTC Protocols courses. Also, Gustavo has a nice explanation here: medium.com/@ggarciabernardo/loss-based-bandwidth-estimation-in-webrtc-8d650f72bb42
Theoretically you can. I am not sure that it is possible though To make VP8 or any other video codec encode with a temporal scalability scheme, you need to configure the encoder accordingly (it isn't there by default) WebCodecs' interface seems to have the ability to handle such configurations, but are these implemented by the browsers properly and for this purpose is a different question with likely a slightly different answer. This means you'll need to experiment with it to get to a conclusive answer.
your blog means a lot, i was just googling for options to my hobby project and suddenly i found myself opening 10 tabs full of your blog posts. Now i am interested in network systems more thanks 🙏
20 is correct. You're counting each connection twice. In mesh, since we send the data directly to other users, we need to count either only the uplink or the downlink. If we count them both, then A's uplink towards B is actually also the downlink to B from A. So the calculation needs to be 4*5=20
Is webrtc free i mean i want to create something like peer2peer livestream and dont want to store any videos data on my server, still do i need to pay lot of cloud bills i am aware of stun servers but from my understanding they are cheap to host.
STUN is cheap. TURN is more expensive. To make sure your sessions get connected in more scenarios, you will need to support TURN as well, which costs based on bandwidth consumption. This is because sometimes, there's no "direct" route available in P2P since NAT devices will block such routes. Hence a relay (TURN server) will be needed.
@@tsahil can TURN be used as a backup. For context. I want create an omegle like app and want it to be cost effective and scalable. What do you recommend?
@@bilalshaikh6603 TURN is always there as backup. It won't be used on all calls - only on those who need them. This typically amounts to 10- 20% of calls (depending on users and their networks)
This video is a year old. I'll probably be updating it at some point, but not yet While browsers generally have AV1 support these days (event for WebRTC), this is limited in capabilities and I'd still consider it "work in progress". For the most part, I won't suggest using AV1 in WebRTC for those who don't have first-hand experience with video codecs AND WebRTC (and first-hand doesn't mean "I installed and ran it once and it worked for me")
@@tsahil Indeed it seems like even though Firefox had officialy supported since early 2019, I couldn't find any mention of AV1 being used in WebRTC inside Firefox. Actively using AV1 in WebRTC calls is probably more complicated than just "supporting AV1". Awesome! I would be really interested in update to this series. WebRTC is such complicated and evolving piece of technology and somehow you can explain it in very clear fashion :)
I think the graphic is a bit misleading. Ruling out the old and expansive MCU technology, which is w.r.t the "load" having to be handled by each communicating part the optimal solution, it seems at the first glance, that the full mesh is the technology which fits best. I haven't viewed the rest of the video, but the correct math to calculate the load having to be handled by each communicating path would IMHO be like this: Mesh scales with N(N-1) and SFU with N+1. Example: In a full mesh of 10 parties each party would have to deal with 90 unidirectional streams while in an SFU solution each party would only have to deal with 11 (not to talk about MCU, where it would be 10). So with this in mind SFU scales way better than full Mesh at scale
You are correct - SFU is definitely the way to go. That's about the conclusion of the video. If you're using anything else then you need to have a really really good reason for doing so.
@@tsahil I saw that Google Stadia use the newer version of this extension - transport-wide-cc-02. So I decided to add it on the client side SDP and after that stream FPS decreases to zero in a couple of minutes. Strange but looks like the server supports this extension but I have no idea how to make it work as expected.
@@YuriiShypulin Stadia is no more, and its bandwidth estimator was tuned for cloud gaming/rendering, so unless that's your use case, I wouldn't bother. Also note that since there's no Stadia anymore, the question is will Google maintain this moving forward in its WebRTC implementation...
Host connectivity issues are tricky as they can happen due to a myriad of reasons - from wrong TURN server configuration to firewall blocking rules. Not something that can be done in a RU-vid comment...
Great tool, thank you! But I wish I could skip the camera check, it takes __forever__ and it is the least important thing (for my use)! I started to block the page from accessing my mic and camera :\ I sincerely hope you can make it optional ;) Again, thank you so much :)
Only if you want to miss the market... For anything that is browser based, WebRTC is your only option. And like any other technology it has its advantages and challenges. You just need to know them and figure out ways to make use of them (the advantages) or overcome them (the challenges).
I liked this interview session. Jeff was very informative laying out what Twilio does, and how its products and services add value to the market. I particularly liked his commitment to developers and delivering great developer/end user experience. A true developer in every sense of the word and it shows. I also liked how he clarified the position of Twilio (CPAAS) vs Unified Communication AS A Services, because I was stuck trying to understand why not use company X over Twilio. After watching this video I feel more committed to using Twilio's tools and services, I am excited and happy that I chose Twilio!
This specific course is a complete one that covers all aspects of WebRTC. The "simple video call between 2 pc with webrtc" in a weekend kind of a thing you can probably find elsewhere.
