4 ms·

https://www.obe.tv/how-to-lie-about-latency/ https://www.obe.tv/how-to-lie-about-latency/

by chgs 2y ago

imtringued 2y ago
My ancient latency claims of at most ~200ms (in practice ~100ms) are based around this test: https://humanbenchmark.com/tests/reactiontime https://humanbenchmark.com/tests/reactiontime Yes. Me clicking the mouse, the software transmitting the mouse click to a datacenter, software rendering the web browser using AVX2, software encoding the stream, sending it to the local browser and decoding it on the screen, shining photons in my eyes, me clicking the button a second time (which also needs to be transmitted to the datacenter), gets me around ~400ms over WebRTC on the reaction time benchmark vs ~200ms on the local computer. I'm not even trying. It's a janky as hell solution that is about to fall apart the moment you look at it funny. Also, I hate ffmpeg for streams that last longer than a day. The latency creep of streams lasting weeks is horrible.
- ta1243 2y ago
  I've had streams lasting years without any latency creep using professional encoders
half-kh-hacker 2y ago
> We've shown that many measurements of latency [...] ignore the full capture and playback pipeline In the repo linked in OP is a screenshot showing a wall clock next to its playback on the streaming site -- that's end-to-end to me. So how is this relevant?
- kierank 2y ago
  Because latency is a distribution and these photos are often selected at the best-case P0 end of all the encode/decode processes whereas actually what matters is the worst case P99. A proper implementation will make sure the worst-case latency is accounted for and not cherry-pick the best case.
to11mtm 2y ago
Can you show a connection between this site and the (AFAIK separate from UK OBE/OBS) Open Broadcaster Software itself? While the page provides some insightful comments I don't see how it relates to implementation details short of 'they did not build a hardware card'.

https://www.obe.tv/how-to-lie-about-latency/ https://www.obe.tv/how-to-lie-about-latency/

by chgs 2y ago

https://www.obe.tv/how-to-lie-about-latency/ https://www.obe.tv/how-to-lie-about-latency/

My ancient latency claims of at most ~200ms (in practice ~100ms) are based around this test: https://humanbenchmark.com/tests/reactiontime https://humanbenchmark.com/tests/reactiontime Yes. Me clicking the mouse, the software transmitting the mouse click to a datacenter, software rendering the web browser using AVX2, software encoding the stream, sending it to the local browser and decoding it on the screen, shining photons in my eyes, me clicking the button a second time (which also needs to be transmitted to the datacenter), gets me around ~400ms over WebRTC on the reaction time benchmark vs ~200ms on the local computer. I'm not even trying. It's a janky as hell solution that is about to fall apart the moment you look at it funny. Also, I hate ffmpeg for streams that last longer than a day. The latency creep of streams lasting weeks is horrible.

ta1243 2y ago
I've had streams lasting years without any latency creep using professional encoders

half-kh-hacker 2y ago

> We've shown that many measurements of latency [...] ignore the full capture and playback pipeline In the repo linked in OP is a screenshot showing a wall clock next to its playback on the streaming site -- that's end-to-end to me. So how is this relevant?

kierank 2y ago
Because latency is a distribution and these photos are often selected at the best-case P0 end of all the encode/decode processes whereas actually what matters is the worst case P99. A proper implementation will make sure the worst-case latency is accounted for and not cherry-pick the best case.

to11mtm 2y ago

Can you show a connection between this site and the (AFAIK separate from UK OBE/OBS) Open Broadcaster Software itself? While the page provides some insightful comments I don't see how it relates to implementation details short of 'they did not build a hardware card'.