4 ms·

Video chat systems/protocols look to be somewhat stagnate/immature. I just wanted to do 720p 30FPS screen sharing across the internet (Europe to America), and t

Video chat systems/protocols look to be somewhat stagnate/immature. I just wanted to do 720p 30FPS screen sharing across the internet (Europe to America), and this can be done with $10,000 dedicated hardware encoders and a ridiculously expensive mile for mile dedicated layer 2 network route. -OR- Alternatively, we could purchase a ~$200 elgato HDMI capture box, and create a free youtube account to stream 60FPS 1080p across the planet. Currently there is no in between for high FPS video streaming systems on the internet. There's also https://jitsi.org/ https://jitsi.org/ and https://obsproject.com/ https://obsproject.com/ , but they don't seem to allow P2P connections with buffering options. The trade off for low/unreliable bandwidth is allowing larger buffers which would impose greater latency.

jallmann 11y ago
If you want a dedicated circuit, then of course it's going to be expensive. But there's really no reason to spend that much money on an encoder, unless you're doing something like integrating an ASIC [1]. > Video chat systems/protocols look to be somewhat stagnate/immature Eh. There's a lot of work being done with WebRTC, but I'm not going to say that's significantly advancing the state of the art with respect to video transport -- SDP, RTP, DTLS have all coexisted for a long time. What has happened, though, is that by abstracting away media handling, the traditional "control plane" is being disintermediated. As a result, we're seeing 1) a lot of reinventing the wheel, and 2) more siloing among service providers. Both lead to feature fragmentation among providers and slows the progress of video-based services. While I'll be the first to admit that SIP (and XMPP and H.323 and BFCP and ...) is rather too involved to be used outside a fully federated telecom environment, it's a bit of a shame that a nicer signaling protocol hasn't really gained any traction in in its stead. Having most services work from a higher level baseline could reduce feature fragmentation and speed up the perceived progress of video services. And hopefully encourage more interoperability, but that's probably a lost cause... [1] I'm aware there are encoders that cost in that range, eg VBrick, and it's crazy -- you don't need to spend that much for video conferencing.
amelius 11y ago
> Video chat systems/protocols look to be somewhat stagnate/immature. I just wanted to do 720p 30FPS screen sharing across the internet (Europe to America) And this can't be done with any of the current clients based on webrtc, such as Hublin?
TD-Linux 11y ago
Your two examples are not equivalent at all. Video conferencing is generally designed for very low delays, whereas Youtube live streaming has a many second delay. This is critical to improving quality - not only can fancier video compression schemes be used with a large delay (B frames etc), but larger buffers mean that spikes in bitrate can be smoothed out. This is especially noticeable for screensharing where screen data updates tend to come in huge spikes with lulls of no changes in between.
- nosuchthing 11y ago
  Your two examples are not equivalent at all. Well yes, that's what I stipulated by mentioning The trade off for low/unreliable bandwidth is allowing larger buffers which would impose greater latency Video conferencing systems mostly prioritize low latency, so as bandwidth decreases (cross continent internet connections currently almost always have latency/bandwidth issues) either frames will drop, or resolution will need to drop. For our purposes of screen sharing/broadcasting we didn't care as much about low latency as much as we wanted high FPS and high resolution.
tty7 11y ago
well, sure. I could stream my desktop in HD @ twitch. But what about latency? Your examples don't add up.

jallmann 11y ago

If you want a dedicated circuit, then of course it's going to be expensive. But there's really no reason to spend that much money on an encoder, unless you're doing something like integrating an ASIC [1]. > Video chat systems/protocols look to be somewhat stagnate/immature Eh. There's a lot of work being done with WebRTC, but I'm not going to say that's significantly advancing the state of the art with respect to video transport -- SDP, RTP, DTLS have all coexisted for a long time. What has happened, though, is that by abstracting away media handling, the traditional "control plane" is being disintermediated. As a result, we're seeing 1) a lot of reinventing the wheel, and 2) more siloing among service providers. Both lead to feature fragmentation among providers and slows the progress of video-based services. While I'll be the first to admit that SIP (and XMPP and H.323 and BFCP and ...) is rather too involved to be used outside a fully federated telecom environment, it's a bit of a shame that a nicer signaling protocol hasn't really gained any traction in in its stead. Having most services work from a higher level baseline could reduce feature fragmentation and speed up the perceived progress of video services. And hopefully encourage more interoperability, but that's probably a lost cause... [1] I'm aware there are encoders that cost in that range, eg VBrick, and it's crazy -- you don't need to spend that much for video conferencing.

amelius 11y ago

> Video chat systems/protocols look to be somewhat stagnate/immature. I just wanted to do 720p 30FPS screen sharing across the internet (Europe to America) And this can't be done with any of the current clients based on webrtc, such as Hublin?

TD-Linux 11y ago

Your two examples are not equivalent at all. Video conferencing is generally designed for very low delays, whereas Youtube live streaming has a many second delay. This is critical to improving quality - not only can fancier video compression schemes be used with a large delay (B frames etc), but larger buffers mean that spikes in bitrate can be smoothed out. This is especially noticeable for screensharing where screen data updates tend to come in huge spikes with lulls of no changes in between.

nosuchthing 11y ago
Your two examples are not equivalent at all. Well yes, that's what I stipulated by mentioning The trade off for low/unreliable bandwidth is allowing larger buffers which would impose greater latency Video conferencing systems mostly prioritize low latency, so as bandwidth decreases (cross continent internet connections currently almost always have latency/bandwidth issues) either frames will drop, or resolution will need to drop. For our purposes of screen sharing/broadcasting we didn't care as much about low latency as much as we wanted high FPS and high resolution.

tty7 11y ago

well, sure. I could stream my desktop in HD @ twitch. But what about latency? Your examples don't add up.