> When the network is bad, you get... fewer JPEGs. That’s it. The ones that arrive are perfect.

You can have still have weird broken stallouts though.

I dunno, this article has some good problem solving but the biggest and mostly untouched issue is that they set the minimum h.264 bandwidth too high. H.264 can do a lot better than JPEG with a lot less bandwidth. But if you lock it at 40Mbps of course it's flaky. Try 1Mbps and iterate from there.

And going keyframe-only is the opposite of how you optimize video bandwidth.

▲

HelloUsername 10 hours ago | parent | next [-]

> Try 1Mbps and iterate from there.

From the article:

“Just lower the bitrate,” you say. Great idea. Now it’s 10Mbps of blocky garbage that’s still 30 seconds behind.

▲

martinald 4 hours ago | parent | next [-]

The problem is I think that they are using moonlight which is "designed" to stream games at very low latency. I very much doubt that people need <30ms response times watching an agent terminal or whatever they are showing!

When you try and use h264 et al at low latency you have to get rid of a lot of optimisations to encode it as quickly as possible. I also highly suspect the vaapi encoder is not very good esp at low bitrates.

I _think_ moonlight also forces CBR instead of VBR, which is pretty awful for this use case - imagine you have 9 seconds of 'nothing changing' and then the window moves for 0.25 seconds. If you had VBR the encoder could basically send ~0kbit/sec apart from control metadata, and then spike the bitrate up when the window moved (for brevity I'm simplifying here, it's more complicated than this but hopefully you get the idea).

Basically they've used the wrong software entirely. They should try and look at xrdp with x264 as a start.

▲

Dylan16807 10 hours ago | parent | prev | next [-]

Rejecting it out of hand isn't actually trying it.

10Mbps is still way too high of a minimum. It's more than YouTube uses for full motion 4k.

And it would not be blocky garbage, it would still look a lot better than JPEG.

▲

vscode-rest 9 hours ago | parent [-]

1Mbps for video is rule of thumb I use. Of course that will depend on customer expectations. 500K can work, but it won’t be pretty.

▲

Dylan16807 9 hours ago | parent [-]

For normal video I think that's a good rule of thumb.

For mostly-static content at 4fps you can cut a bunch more bitrate corners before it looks bad. (And 2-3 JPEGs per second won't even look good at 1Mbps.)

	▲	9 hours ago \| parent \| next [-]
		[deleted]
	▲	jcalvinowens 7 hours ago \| parent \| prev [-]
		>> 10Mbps is still way too high of a minimum. It's more than YouTube uses for full motion 4k. > And 2-3 JPEGs per second won't even look good at 1Mbps. Unqualified claims like these are utterly meaningless. It depends too much on exactly what you're doing, some sorts of images will compress much better than others.

▲

brigade 9 hours ago | parent | prev [-]

Proper rate control for such realtime streaming would also lower framerate and/or resolution to maintain the best quality and latency they can over dynamic network conditions and however little bandwidth they have. The fundamental issue is that they don't have this control loop at all, and are badly simulating it by polling JPEGs.

▲

j45 9 hours ago | parent | prev [-]

It might be possible to buffer and queue jpegs for playback as well to help with weird broken stall outs.

Video players used to call it buffering, and resolving it was called buffering issues.

Players today can keep an eye on network quality while playing too, which is neat.