> I mashed F5 like a degenerate.
I love the style of this blog-post, you can really tell that Luke has been deep down in the rabbit hole, encountered the Balrog and lived to tell the tale.
We replaced H.264 streaming with JPEG screenshots (and it worked better)
11–20 of 332 posts
Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)
#12If you have latency detection already why not pause H.264 frames, then when ack comes just force a key frame and resume (perhaps with adjusted target bitrate)?
Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)
#13Would HLS be an option? I publish my home security cameras via WebRTC, but I keep HLS as a escape for hotel/cafe WiFi situations (MediaMTX makes it easy to offer both).
Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)
#14> Why JPEGs Actually Slap
JPEG is extremely efficient to [de/en]code on modern CPUs. You can get close to 1080p60 per core if you use a library that leverages SIMD.
I sometimes struggle with the pursuit of perfect codec efficiency when our networks have become this fast. You can employ half-assed compression and still not max out a 1gbps pipe. From Netflix & Google's perspective it totally makes sense, but unless you are building a streaming video platform with billions of customers I don't see the point.
Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)
#15> 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.
Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)
#16so did they reinvent mjpeg
from first principles.
Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)
#17> I mashed F5 like a degenerate
Bargaining.
Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)
#18> The constraint that ruined everything: It has to work on enterprise networks. > You know what enterprise networks love? HTTP. HTTPS. Port 443. That’s it. That’s the list. That's not enough. Corporate networks also love to MITM their own workstations and reinterpret http traffic. So, no WebSockets and no Server-Side Events either, because their corporate firewall is a piece of software no one in the world wants and…
They even break server-sent events (which is still my default for most interactive apps)
[deleted]
Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)
#19A very stupid hack that can work to "fix" this could be to buffer the h264 stream at the data center using a proxy before sending it to the real client, etc.
Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)
#20[deleted]