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

191–200 of 211 posts

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

#191

Post by user5994461 »

Twirrim wrote: post #133
user5994461 wrote: post #29

Earlier quoted context omitted.

No it's not. It stopped being approved for usage by NIST a few years ago.

Really? 3DES still appears here, https://csrc.nist.gov/projects/block-cipher-techniques , with DES and Skipjack being called out as deprecated.

That page says that 3DES is prohibited from usage in new applications and is prohibited for encrypting more than 1 GB of data, since 2017.

The attached documents have additional information on implementation and (non) usage, including deadline to migrate legacy military systems. It's sadly quite cumbersome to go through the tens of PDF to find the relevant information.

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

#192

Post by dbrgn »

"A week of struggling with WebRTC’s nearly 750,000 LoC behemoth of a codebase revealed just how painful a single small change could be — how hard it was to test, and feel truly safe, with the code you were dealing with."

I totally feel you. It's impressive what the WebRTC implementation has achieved, but it's just not pleasant at all to work with it.

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

#193

Post by igouy »

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 {}.

Not true.

Of those 4 tasks, the rust programs for task 3 and task 4 do not use the keyword "unsafe".

For task 2, the spectral-norm Rust #6 program does use "unsafe" but #5 does not and it's almost as fast.

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

#194

Post by SomeoneFromCA »

sneak wrote: post #150
SomeoneFromCA wrote: post #106

Earlier quoted context omitted.

I am talking about listening fatigue, first of all, which is a long-term effect. Second, I think double-blind test are worthless, if they are done in isolation; first, you need to run non-blind tests, let people play with audio equipment as much as they want, in any combination, completely open; only after that, when people have figured out what to look for, run the double blind test. Forcing unprepared people to go…

If you can’t distinguish A from B reliably, none of the rest matters at all. The idea that you have to “figure out what to look for” is nonsense if you cannot distinguish the two reliably. “Listening fatigue” when you know which is which is simply placebo.

You should probably read more attentively. I did not say you do not need double blind test.I said, once you learn what to look for, only that there is a point to do the blind test.

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

#195

Post by masklinn »

SomeoneFromCA wrote: post #112
masklinn wrote: post #108

Earlier quoted context omitted.

So what you're saying "actually does make sense" so long as it's a completely different subject than what one would normally assume in context, without you having mentioned such. When people talk about 24 bits (and >48kHz) in the context of "audiophilia", it's generally about the data at rest and "HD audio" (aka 24 bit music files and downloads). Not about the bit depth of the processing pipeline for which it's gener…

Extra bits won't hurt anyway. DAC are not ideal, and there is a comment above about the dynamic range. If your recording is not loud, you lose your dynamic range (say, if your loudest sound is only 40% of the full amplitude, you've already lost more than 1 bit), which can be partially recovered by a higher precision DACs. So it is true in both senses.

> Extra bits won't hurt anyway.

Nobody said it would hurt so I’m not sure why you’re pointing out the consensus like it’s some sort of profound statement.

> If your recording is not loud, you lose your dynamic range

If your sound engineer is wasting your dynamic range, maybe get a better sound engineer? And if they manage to fuck up something at the core of their job, there’s no reason they wouldn’t fuck up just as much with 24 bits to waste.

> So it is true in both senses.

In no meaning of “true” and “both” in common use.

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

#196

Post by glandium »

ponker wrote: post #187
glandium wrote: post #186

Earlier quoted context omitted.

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?

ひるおび is one of them IIRC.

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

#197

Post by fomine3 »

bufferoverflow wrote: post #162
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.)

LLAC/LHDC LL bluetooth codec adds only 30ms. AptX low latency codec adds only 40ms max. Just buy headphones with good low latency support. They aren't even expensive anymore.

LLAC/AptX LL isn't adopted well on host device now, especially on Apple devices.

And even 30ms delay, using it on headphone/mic and both talker means 3022=120ms delay.

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

#198

Post by namibj »

codys wrote: post #131
namibj wrote: post #123

Earlier quoted context omitted.

20ms is wasteful. Use minimum latency where SILK still works, afaik that's 7.5ms.

This assumes that video encoding latency is lower than the audio latency.

Shouldn't be more than a single frame, which is 16 2/3 ms for 60 fps. And for e.g. JPEG it can be even shorter, especially with a rolling shutter.

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

#199

Post by vlovich123 »

namibj wrote: post #111
vlovich123 wrote: post #47

Earlier quoted context omitted.

You can also just configure your video encoder to not use B-frames. Then if you make all consecutive frames P frames then the size is very maintainable. It gets trickier if your transport is lossy since a dropped P frame is a problem but it's not an unsolvable problem if you use LTR frames intelligently. All the benefits of efficient codecs, more manageable handling of the latency downsides. The challenges you'll run…

Actually, there are commercial CUDA JPEG codecs (both directions) operating at gigapixels per second. It's not a question of speed, but rather the fact that you can at least afford to use H.264's I-frame-only codec for much lower bandwidth requirements.

JPEG is still going to be larger & lower quality than H264. I still fail to see the advantage.

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

#200

Post by LockAndLol »

clpwn wrote: post #175
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 en…

Thank you very much for the answers. Glad I wasn't too far off.

Looking forward to the technical post. If you're planning on releasing all of this royalty-free and opensource, you'd be quite a boon to the free and open internet. Getting this picked up by the likes of Mozilla and getting it into a browser would be amazing.

Post reply on HN