What's the codec stack for this? x264 --tune zerolatency + opus with opus_delay=20ms?
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.
3K, 60fps, 130ms: achieving it with Rust
131–140 of 211 posts
Re: 3K, 60fps, 130ms: achieving it with Rust
#132Earlier quoted context omitted.
That's nothing like a Cisco telepresence room. You have to have used one to understand. It's nothing too sci-fi -- not floor to ceiling curved displays or whatnot -- but just the multiple large TVs all in a curved setup on the other side of a curved table makes a huge difference.
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...
Re: 3K, 60fps, 130ms: achieving it with Rust
#133Earlier quoted context omitted.
3DES is still military grade.
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.
Re: 3K, 60fps, 130ms: achieving it with Rust
#134Earlier quoted context omitted.
> but I tried with many people, and all of them noted the difference. Unless this was a double-blind study and the audio levels were exactly the same between runs, this is useless data. Even a 0.1dbSPL difference between runs is noticeable (people gravitate to louder sounds as better). > every time I switch sound cards to 24 bits This may be related to the sound card. I use an external DAC, not a soundcard, as most s…
I have actually never seen any proof double-blind study is the best way to do the audio comparison. I mean, yeah placebo effect does exist, but knowing what to look for in certain type equipment makes it a lot easier to find the phenomenon. Double-blind study, IMO has to be applied only after extensive amount of non-blind tests, Yes the final verdict has to be produced after the blind test, but people need to know wh…
> This a bold statement, which begs a proof itself.
Only if one doesn't understand what those bits mean or what they correspond to.
These bits are important for quantization, which is the process of converting analog sound into digital numbers. On a graph, X = time and Y = amplitude. The higher the bits, the higher the resolution.
A 16bit recording has 2^16 steps (discrete values) available for amplitude (65,536) and a 24bit recording is 2^24 or 16,777,216 steps.
So why is this important? Well, a 24-bit recording can more finely record differences in amplitude. Given that 1bit = 6dB: a regular 16-bit recording already has a dynamic range of 96dB. A 24-bit recording has a dynamic range of >144db. At ~125-130dB SPL is where hearing loss (permanent) begins.
You do not hear the difference because if you were listening to a 24-bit recording on a 24-bit capable system at sound levels loud enough to actually discern a difference, you would have permanently damaged your ears. Actually, I believe that applies to 20-bit, let alone 24-bit.
So why do 24-bit or higher recordings even exist? They are useful for people mixing and working with the raw audio, before it gets processed down to 16bit audio for distribution. At 24-bit resolution you have a larger amount of headroom before you start clipping, so it's easier to work with considering you have X amount of bits that are just part of the noise floor.
This is also assuming your input files are actually 24-bit to begin with. The vast majority of files are 16-bit because there is literally no point as a consumer to have larger file sizes for no humanly audible benefit.
44.1kHz 16-bit files are all that you need as a human consumer of audio. 48kHz has to do with video and is not better than 44.1kHz because you (a human) cannot hear the difference. 44.1kHz is 22.5kHz x 2. Humans hear sound from 20hz to 20kHz -at best-. This is assuming perfect hearing with no degradation. We sample at 44.1kHz due to the Nyquist-Shannon sampling theorem, and 22kHz gives us just a bit of headroom to apply filters to avoid aliasing. [2]
So I reiterate my initial assumption: flicking a switch to change from 16bit to 24bit should not magically change the quality of audio (in a humanly discernible manner). Assuming the file being played is 24bit lossless audio in the first place.
> BTW, following your logic there is no point in bying DAC
We're talking about dedicated external equipment vs an onboard soundcard+amp which are generally neglected. Not -all- onboard cards suck of course, the Realtek ALC1220 chip on my mobo seems to be comparable or better than entry level DACs from the specs I'm seeing. This is assuming no interference is happening, which is more likely to happen around unshielded electrical components. If you don't believe this is a thing, ask why the audio industry uses thick XLR [shielded AND grounded] cables as standard.
Certain headphones require equipment that can drive them properly, whether it's an onboard soundcard+amp or a DAC+amp. For example, my sennheiser hd600s are 300Ω but some models go up to 600Ω. And yes, the quality of the amp/preamp does make a huge difference.
If one can prove that a component is unable to drive a component, or is sub-par mathematically, one doesn't exactly need double abx trials. Those are for tests like "Monster says their $200 cable is better than standard cable?", or "Is a McIntosh amp better than a $ competitor?".
I don't need to do a double ABX study to realize that beats headphones are drastically worse in performance than sennheiser hd600s: [3], [4], [5]
[0]: https://www.mojo-audio.com/blog/the-24bit-delusion/
[1]: https://web.archive.org/web/20200202124704/https://people.xi...
[2]: https://en.wikipedia.org/wiki/44,100_Hz#Origin
[3]: https://reference-audio-analyzer.pro/en/report/hp/monster-be...
[4]: https://reference-audio-analyzer.pro/en/report/hp/sennheiser...
[5]: https://reference-audio-analyzer.pro/en/report/hp/audio-tech...
Re: 3K, 60fps, 130ms: achieving it with Rust
#135Earlier quoted context omitted.
The biggest problem is that of the video codecs which ultimately boils down to using interframe compression. This technique requires that a certain # of video frames be received and buffered before a final image can be produced. This requirement imposes a baseline amount of latency that can never be overcome by any means. It is a hard trade-off in information theory. Something to consider is that there are alternativ…
I think a larger issue is the focus on video as opposed to audio. Audio may be less sexy but it is far and away more important for most interpersonal communication (I'm not discussing gaming or streaming or whatever, but teleconferencing). Most of us don't care that much if we get super crisp, uninterrupted views of our colleagues or clients, but audio problems really impede discussion.
Early versions of Youtube nailed this. The video would frequently pause, degrade, or glitch due to buffering delays but the audio would continue to play. This made all the difference in user perception: youtube felt smooth. Other streaming services would pause both video and audio which did not feel smooth at all. Maybe they had some QoS code in their webapp to prioritize audio?
Re: 3K, 60fps, 130ms: achieving it with Rust
#136My WebRTC projects haven't suffered that much from latency. The biggest source of delays is usually caused by encoding video for me. I've had to limit streams to 720p and 25fps to reduce the time spent on CPU encoding a vp8 stream. There are also bandwidth considerations (real time encoding = significantly less compression) but the end result is slightly less than 200ms one way latency (including input lag from mouse, 15ms network latency and display lag) without any special settings. All I'm doing is feeding a ffmpeg stream to kurento and letting it broadcast it via WebRTC. This is not a web conferencing application and it is also not using WebRTC via p2p. It's closer to conventional live streaming with a sane amount of latency (compared to up to 30s of latency you commonly see on twitch). Of course I personally would prefer it if the latency can be brought down even further. 100ms or lower is like the holy grail for me and only appears to be doable with codecs that aren't supported by WebRTC. However, people don't want to install apps just for my little service and I certainly won't encode every stream via several codecs just for the tiny minority of the user base that actually ends up using the app.
Re: 3K, 60fps, 130ms: achieving it with Rust
#137Earlier quoted context omitted.
The biggest problem is that of the video codecs which ultimately boils down to using interframe compression. This technique requires that a certain # of video frames be received and buffered before a final image can be produced. This requirement imposes a baseline amount of latency that can never be overcome by any means. It is a hard trade-off in information theory. Something to consider is that there are alternativ…
Interframes are not a problem, as long as they only reference previous frames, not future ones. I was able to get latency down to 50ms, streaming to a browser using MPEG1[1]. The latency is mostly the result of 1 frame (16ms) delay for a screen capture on the sender + 2-3 frames of latency to get through the OS stack to the screen at the receiving end. En- and decoding was about ~5ms. Plus of course the network laten…
Interesting. I guess I'll have to rewrite a lot of code if what you are saying is true.
Re: 3K, 60fps, 130ms: achieving it with Rust
#138Earlier 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 seem like they relaxed rules about what's in the background. But then, my knowledge is from a Telepresence room having been setup at a previous employer somewhere between 10 and 15 years ago (and I wasn't directly involved).
Re: 3K, 60fps, 130ms: achieving it with Rust
#139Nitpick: “audiophile-quality sound” it seems, is becoming the new “military-grade encryption.” I don’t have many other comments to make other than I am surprised rust-analyzer was only mentioned in passing.
To me, "military grade encryption" means following industry standard. "Audiophile quality" means higher quality than you need, care about, or can even tell apart from lower quality.
No, "military grade encryption" means nothing. If it referenced a standard, than that might mean something. I've worked on products for the military that still used single pass DES encryption. So that was military grade. It might as well have been ROT13.
Re: 3K, 60fps, 130ms: achieving it with Rust
#140Earlier 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 doesn't seem to have this latency problem.
Wifi is one of the best things you can do to add unreliability and latency.