Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

blog.tonari.no

Post reply on HN
Print view View original

171–180 of 211 posts

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

#171

Post by jonny383 »

bschwindHN wrote: post #170
jonny383 wrote: post #161

"we truly don't believe we could have achieved these numbers with this level of stability without Rust" Oh please. This is just rust sensationalism. People don't truly believe rust is faster than C do they?

I don't believe Rust is faster than C, but I would argue it's faster to develop new products in Rust vs. C, and easier to produce programs which don't have data races or invalid memory accesses.

Sure, if you wrap everything in unsafe and/or import third party libraries (with the assumption they are also safe).

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

#172

Post by jonny383 »

bufferoverflow wrote: post #164
jonny383 wrote: post #161

"we truly don't believe we could have achieved these numbers with this level of stability without Rust" Oh please. This is just rust sensationalism. People don't truly believe rust is faster than C do they?

In some problems Rust is the fastest: https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Every single one of those rust implementations is using unsafe {}, thus defeating the purpose of using rust in the first place. Run the same benchmark without unsafe {}.

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

#175

Post by clpwn »

LockAndLol wrote: post #115

After reading it, I'm still not entirely sure what's being done. Is it live streaming or is it the transport? Are they doing video encoding (the audio encoding seems to be done by that webrtc-audio thing)? Have they chosen a progressive encoding format that compresses frames and pumps them out to the wire as soon as they're done? Is TCP or UDP involved or a new Layer 3 protocol entirely? Have I just missed all of tho…

> After reading it, I'm still not entirely sure what's being done. > Is it live streaming or is it the transport?

tonari is the entire stack, similar in "feature scope" to WebRTC but with different goals and target environments.

> Are they doing video encoding (the audio encoding seems to be done by that webrtc-audio thing)?

Yep, this includes video encoding and transport. We don't use the WebRTC audio library for encoding or transport, just for echo cancellation and other helpful acoustic processing.

> Have they chosen a progressive encoding format that compresses frames and pumps them out to the wire as soon as they're done?

Yep, basically, if by that you mean we don't use B-frames or other codec features that would require buffering multiple video frames before receiving a compressed stream, so we're able to send out encoded frames as they arrive.

> Is TCP or UDP involved or a new Layer 3 protocol entirely?

We encapsulate our protocol in UDP since we operate on normal internet - a new protocol is out of the question without a huge lobbying force and 15 years of patience on your side.

> Have I just missed all of those parts or were they really missing amid all the Rust celebration?

We intentionally didn't get into the protocol details because we are saving that for a dedicated post (and code to back it up).

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

#176

Post by sephamorr »

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 stream, and the resulting quality of audio and video is...understandably poor.

Latency too totally feels like a software problem, perhaps with too many layers of abstraction. (60fps->16ms for the camera, ~10ms for encoding with NVENC/equivalents, 35ms measured one-way latency from my laptop to my parents 4000km away, ~10ms decode, 16ms frame delay = 87ms one way). Maybe I'm asking for too much from non-realtime systems (I'm used to RTOS, extensive use of DMA, zero-copy network drivers, etc), but it seems that there is a lot of room to improve.

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

#177

Post by rasz »

sephamorr wrote: post #176

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.

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

#178

Post by clpwn »

sephamorr wrote: post #176

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…

It's worth mentioning that in our case, a significant chunk of the latency in our 130ms measurement is just the input lag of our display that we currently use. We were surprised by how slow they can be.

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

#179

Post by turndown »

jonny383 wrote: post #172
bufferoverflow wrote: post #164

Earlier quoted context omitted.

In some problems Rust is the fastest: https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Every single one of those rust implementations is using unsafe {}, thus defeating the purpose of using rust in the first place. Run the same benchmark without unsafe {}.

>defeating the purpose of using rust in the first place

I don't think this is true; the whole point of Rust is that unsafe operations are explicit, not that you never do so.

Also, I looked at the first one, and it's only using unsafe on what are basically op code calls; I don't think it is realistic to complain about that.

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

#180

Post by blackrock »

fludlight wrote: post #132
glandium wrote: post #100

Earlier quoted context omitted.

And a standardized wall color and camera location, so that everyone that joins in from another telepresence room blends in as if they were really there.

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.

Post reply on HN