Short two-person technical discussion (YouTube transcript) about what resolution WebRTC ‘supports’. Speakers distinguish three aspects: camera capture limits (speaker suggests ~4K capture limit), network transmission (adaptive to bandwidth/frame-rate constraints), and screen sharing (4K displays require lower frame rates for static content). They also note application choices (apps may choose lower resolutions) and an example where send/receive roles differ (cloud gaming uses server-side encoding).
Chapters
What is the Highest resolution that WebRTC supports?
That's a good question. It depends on what you mean by support. We have three aspects here. First one is what does the camera capture in used by WebTC support? Second one is what resolution gets sent over the network. The third one is. But what about screen sharing?
Okay. And then there's the application. You know, I just don't want to support hd, so I'll do VGA because I want to.
Yes, yes. I mean, if you look at the camera capture, in the end of the day, that's limited by the bandwidth from the camera to the computer. And I would say 4K is currently the limit.
And that's what, 10, 20 Mbps?
It's a lot because on the. From the camera to the computer, okay. It's similar to the network. It has higher bandwidth, but you need to choose what you encode. Some cameras do H64 on that.
Okay.
Then we have the network and there it is. Usually you get the resolution that best fits your current requirements for bandwidth and frame rate. And that can vary over time.
Okay. And then the higher the resolution, the more bandwidth I would need.
Yes. And the third topic is screen sharing, which generally has. I mean, we typically have 4K displays these days. It's like, okay, the resolution we need to support is 4K.
Yep.
And that gets a problem because that's much higher than 720p resolution or 1080p resolution we use for cameras. Typically, that means we need to reduce the frame rate, which is okay for static content like slides.
And then there's also the fact that sending and receiving might not be aligned. And the best example would be cloud gaming. In cloud gaming, we actually play a game. We can play a game at 1080p with 60 frames per second or even 4k, but our ability to encode that on the browser is nonexistent. And since we do that on the server, we can enable that because the receiver can still handle it.