Live data from Hacker News

3K, 60fps, 130ms: achieving it with Rust

blog.tonari.no

181–190 of 211 posts

Re: 3K, 60fps, 130ms: achieving it with Rust

#181
post #177

Why exactly do existing video streaming solutions use such small amounts of bandwidth and have terrible quality as a result? Does anyone have a deep dive into why this is the case? It seems that it would be a killer feature to make better utilization of bandwidth. Even over wifi, speedtest shows 4ms/100mb/100mb on my internet connection, but Zoom, FaceTime, and others never use more than about 0.8Mbit/s for a video s…

OnLive "solved" encoder latency 15 years ago. You dont wait 16ms for the next frame. Instead you progressively start encoding after receiving first tens of lines. This way your encoded video stream lags just couple of milliseconds behind, same for decoding. You could crudely emulate this by dividing screen into 4 rows and sending 4 concurrent video stream, instant 1/4 latency drop.

Sure, many of the operations in the list can be pipelined as you mention. Something like G-Sync would also allow you to sync the destination display to the arrival of the (start of) frame.

Re: 3K, 60fps, 130ms: achieving it with Rust

#182
post #37

Earlier quoted context omitted.

The media lab has done a ton of research on this. I seem to remember people being able to notice visual latency at 30ms and audio latency at 80-120ms (this is because light is faster than sound).

Interesting, would love to read more if specific papers/authors come to your mind. I suspect there's a big gap between e.g. "noticing the audio latency when audio is played as a result of pressing a button" vs "audio latency affecting the flow of a multiparty conversation".

https://en.wikipedia.org/wiki/Delayed_Auditory_Feedback

Re: 3K, 60fps, 130ms: achieving it with Rust

#183
post #14
post #7

Aside from the Rust aspect (which is cool!), I can't believe we've come this far and still don't have low-latency video conferencing. Maybe I'm overly sensitive, but people talking over each other and the lack of conversational flow drives me crazy with things like hangouts.

There are hard limits at play. No matter what you do, you can't go from New York to London in less than ~20ms; add video/audio encoding, packet switching, decoding, etc. and it's easy to see why any latency under the 100ms mark at that spatial scale in a scalable, mainstream product would be close to a miracle. The thing is that when we talk in a room, sound will take See also this interesting comment about the feeli…

> The thing is that when we talk in a room, sound will take Digital communication could cheat, though!

There's a lot of latency hiding you can do, if you can predict well enough what's coming next. Humans are fairly predictable most of the time.

Re: 3K, 60fps, 130ms: achieving it with Rust

#185

If anybody is looking for a low latency high bandwidth P2P video streaming solution there is https://github.com/CESNET/UltraGrid/wiki It can do less than 80ms of latency

How do you use this over network? I have installed it but its very unclear to me what I need to do in order to call my colleague in another city.

It seems that it can only connect to publicly visible hosts? Overall it looks like somebody should develop an application on top of this.

Re: 3K, 60fps, 130ms: achieving it with Rust

#186

Earlier quoted context omitted.

Here's a picture: https://en.wikipedia.org/wiki/Cisco_TelePresence#/media/File...

It would be interesting if a camera was on top of every tv, so that you have a 1-to-1 with every recipient. That way, when you turn your head to the person on each tv, it would seem as if you were actually looking at them.

Getting off topic here, but this makes me think of what can be seen now in some Japanese programs because of social distancing measures. I don't know what kind of setup they have, but in some programs, from the spectator's perspective, you see people lined up behind a table, but some of them are actually on large monitors that make them appear at the right size. The interesting thing is that the ones on monitors act like if they were actually there, turning their head in the direction of the person speaking.

Re: 3K, 60fps, 130ms: achieving it with Rust

#187

Earlier quoted context omitted.

It would be interesting if a camera was on top of every tv, so that you have a 1-to-1 with every recipient. That way, when you turn your head to the person on each tv, it would seem as if you were actually looking at them.

Getting off topic here, but this makes me think of what can be seen now in some Japanese programs because of social distancing measures. I don't know what kind of setup they have, but in some programs, from the spectator's perspective, you see people lined up behind a table, but some of them are actually on large monitors that make them appear at the right size. The interesting thing is that the ones on monitors act…

What Japanese programs?

Re: 3K, 60fps, 130ms: achieving it with Rust

#188
post #128

Earlier quoted context omitted.

WiFi has terrible latency. Try playing a multiplayer FPS with wired networking and compare with WiFi. Or simply use remote desktop with WiFi.

Whatever wifi you're using is probably overloaded. You can easily have a one millisecond ping to your access point.

I have an under 2 ms ping to my AP, but WiFi has terrible buffer bloat, so ping latency doesn't mean much actually.

Re: 3K, 60fps, 130ms: achieving it with Rust

#189
post #188

Earlier quoted context omitted.

Whatever wifi you're using is probably overloaded. You can easily have a one millisecond ping to your access point.

I have an under 2 ms ping to my AP, but WiFi has terrible buffer bloat, so ping latency doesn't mean much actually.

Any idea what the state of the art is for reducing buffer bloat on access points?

And you can mitigate that by not using tons of bandwidth in the background while gaming.

Re: 3K, 60fps, 130ms: achieving it with Rust

#190
post #160

I love Rust, but them deciding to redesign/reimplement webrtc after being frustrated after a week seems like a prime candidate for not invented here syndrome with Rust being the justification. There is a reason webrtc is as big as it is, it’s a complex problem to solve. Regarding the premise of high latency in webrtc: Google Stadia has ~160ms round trip latency at 4k from my Macbook to a data center, so it’s not like…

Google is colocating in your basement.
Post reply on HN