Видео

Thanks for this. By the looks of it, your focus is streaming - the question here was about realtime - live video - a conversation between people for example. In such a case, developers would love to use AV1, but they can't be certain the CPU their users have will be up for the task

There are RTP timestamps and NTP timestamps The RTP timestamps aren't "aligned" across streams and aren't absolute. They are like "relative" position in CSS The NTP timestamps are "absolute" position in CSS and enable WebRTC to lipsync channels Also, I wrote about this recently - bloggeek.me/lip-synchronization-webrtc/

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.

@@dewayn3 that's what you'll be using since TCP isn't optimal for the job

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.

​@@tsahilalright, 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

You can't...

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)

@@tsahil if i ran a webrtc app the only major cost would be of running turn servers. Am i right?

@@bilalshaikh6603 Yes, assuming it is P2P and I am ignoring hosting costs for the application logic itself

As far as I know - yes That said, Jitsi Meet also supports VP9

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 :)

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.

twcc is what is used by some of the media servers out there today already. It is considered the best approach today by many

@@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...

@@tsahil thank you!

Thank you for the kind words Marco

True

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 RUclips comment...

Today there are now 2 main courses for developers: 1. Architecture - which is a bit more theoretical 2. Codelab - which is purely practical

@@tsahil are you making any project in this course?

@@rezaulmasum205 Look at the course itself - the first few lessons are free. You can find them here: webrtccourse.com/course/webrtc-codelab

Not my tool, so can't do much about it. That said, its code is open source - just take it, remove what you don't like and host it elsewhere

Yes. Last update took place February 2020. There is also now a WebRTC Codelab course (from April 2020) that is available

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).

If you wait until things are cheap, you'll be the last in line.