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

151–160 of 211 posts

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

#151

Post by Artlav »

Aengeuad wrote: post #22
ccostes wrote: 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.

John Carmack always has an interesting point to make about latency: https://twitter.com/ID_AA_Carmack/status/193480622533120001 >I can send an IP packet to Europe faster than I can send a pixel to the screen. How f’d up is that? and to relate to the other post about landlines: https://twitter.com/ID_AA_Carmack/status/992778768417722368 >I made a long internal post yesterday about audio latency, and it included “Many…

> Many people reading this are too young to remember analog local phone calls, and how the lag from cell phones changed conversations

Is there somewhere to read about the changes in question?

I'm old enough to remember extensive use of analog landlines, and can't really think of any difference to a cellphone other than audio quality.

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

#152

Post by projektfu »

Artlav wrote: post #151
Aengeuad wrote: post #22

Earlier quoted context omitted.

John Carmack always has an interesting point to make about latency: https://twitter.com/ID_AA_Carmack/status/193480622533120001 >I can send an IP packet to Europe faster than I can send a pixel to the screen. How f’d up is that? and to relate to the other post about landlines: https://twitter.com/ID_AA_Carmack/status/992778768417722368 >I made a long internal post yesterday about audio latency, and it included “Many…

> Many people reading this are too young to remember analog local phone calls, and how the lag from cell phones changed conversations Is there somewhere to read about the changes in question? I'm old enough to remember extensive use of analog landlines, and can't really think of any difference to a cellphone other than audio quality.

In my world, using regular cell service (not VoLTE), seems nearly as instantaneous as I remember analog lines. I remember how hard a satellite phone call was and I never have that much latency in a call.

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

#153

Post by blahbhthrow3748 »

pedrocr wrote: post #53
ccostes wrote: 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.

Cisco "telepresence" solved this 15 years ago. Standardized rooms on both sides with high quality cameras and low latencies. Polycom had a similar but worse setup at the time. The Cisco experience was very close to being in a shared meeting with the other people. It made meetings across continents work very well and was an actual competitor to flying everywhere. Between the hardware being too expensive and the link r…

My first job out of school was doing product verification for the cameras that were used in those Cisco systems! It was pretty impressive, I think they managed to squeeze 1080p at 60fps over USB2. Had a lot of fun building jigs and testing setups to test the MTBF on a tight time frame

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

#154

Post by eqvinox »

sneak wrote: post #94
clpwn wrote: post #41

Earlier quoted context omitted.

You're right, that sounds way too fluffy. To clarify, we're targeting "transparent" sounding audio, not "FLACs or bust" audio. Right now we send stereo 48kHz 96kb/s Opus (CELT, not SILK) that we found hit the voice transparency sweet-spot compared to the lossless audio source. We had used higher bitrates in the past, and could easily go back to them, but quality plateaued at around 96k in our experimentation. More th…

Voice does not extend above 22.05khz, so using sampling rates above 44.1khz is entirely objectively wasteful and useless, unless your codec only works at 48khz input or something. Are you using 48khz for a specific reason?

44.1 kHz is essentially deprecated on the hardware level since it's annoying to deal with the extra clock. It's a few cents for an extra crystal, way too expensive ;). 44100 also makes for very poor multipliers/dividers to other clocks since it includes 3²×5²×7² as factors. 48000 is much nicer with 3×5³.

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

#156

Post by ronyfadel »

zelly wrote: post #76

The bottleneck is not on the CPU. I'm afraid this company may have wasted their time trying to reinvent WebRTC. If you really want to get realtime video, I think the best approach is a custom codec on CUDA or better yet custom hardware (FPGA). You can only go so far on general purpose hardware before you hit a wall and get Zoom/WebEx quality.

Is or is not? I’m confused: if the bottleneck is not on the CPU what does CUDA solve?

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

#157

Post by novok »

izacus wrote: post #109
Filligree wrote: post #96

Earlier quoted context omitted.

Okay, but I want to wear wireless headphones. Why can't I have both? Wifi doesn't seem to have this latency problem.

How do you know? :) The latency doesn't come from bluetooth radio part itself (there ARE low latency BT headphones after all). It comes from the fact that all audio is encoded (usually into SBC or AAC or AptX), transmitted and then decoded in the headphones. And each of those steps has buffers. And those buffers are configured by the manufacturer. The bigger the buffer, the more stable the audio connection - there's…

Or use wireless mics that don't use bluetooth and are dedicated to low latency wireless audio. Like the ones they use for theatre: https://www.adorama.com/alc/how-to-choose-a-wireless-microph...

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

#158

Post by smabie »

Filligree wrote: post #96
izacus wrote: post #85

Earlier quoted context omitted.

Well, all the effort is regularly defeated by poor hardware - you can have 40ms latecy in the video call stack, but when people attach Bluetooth headphones which buffer everything for 300ms there's nothing really to be done. (Be gentle on your coworkers and use cabled headphones.)

Okay, but I want to wear wireless headphones. Why can't I have both? Wifi doesn't seem to have this latency problem.

Wifi's latency has a high dispersion. I've seen absolutely terrible wifi latency, and latency that is under 1ms. wifi degrades gracefully, which makes it really tough to work with.

But pretty much all serious gamers use an ethernet connection because wifi is a pain in the ass. In fact, the first thing a support representative for any game will tell you when complaining about excessive lag is to try a wired connection.

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

#159

Post by megameter »

bob1029 wrote: post #147
Mirioron wrote: post #91

Earlier quoted context omitted.

Video is related to this though. If audio is synced to the video then a delayed video stream also means a delayed audio stream.

In my approach, these would be 2 completely independent streams. I haven't implemented audio yet, but hypothetically you can continuously adjust the sample buffer size of the audio stream to be within some safety margin of detected peak latency, and things should self-synchronize pretty well. In terms of encoding the audio, I don't know that I would. For video, going from MPEG->JPEG brought the perfect trade-off. For…

Discord does something like what you describe. It's kind of awful for music(e.g. if it's a channel with a music bot) as you'll hear it speed up and slow down in an oscillating pattern. The same effect also appears in games if you should have a game loop that always tries to catch up to an ideal framerate by issuing more updates to match an average - the resulting oscillation as the game suddenly slows down and then jerks forward is hugely disruptive, so it's not really done this way in practice.

Oscillations are the main issue with "catch-ups" in synchronization, and dropping frames once your buffer is too far behind is often a more pleasant artifact. It's not really a one-size-fits-all engineering problem.

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

#160

Post by jupp0r »

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 that’s unachievable.

Post reply on HN