I guess this is great as long as you don't worry about audio sync?
at least the ai agents aren't talking back to us
You're behind by 1.5 years on that thought. They certainly can.
We replaced H.264 streaming with JPEG screenshots (and it worked better)
131–140 of 332 posts
Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)
#132We did something similar +12 years ago with `streaming` AWS running app inside the browser. Basically you can run 3d studio max on chromebook. App is actually running on AWS instance and it just sending jpegs to browser to `stream` it. We did a lot of QoS logic and other stuff but it was actually working pretty nice. Adobe used it for some time to allow user to run Photoshop in the browser. Good old days..
Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)
#133Earlier quoted context omitted.
… and JPEG XL is smaller than WebP.
JPEG XL looks to have pretty poor support. https://caniuse.com/jpegxl
Yes, though hopefully not for long; unfortunately not all codecs are given equal treatment...
If having native support in a web browser is important, though, then yes, WebP is a better choice (as is JPEG).
Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)
#134I wrote a motion jpeg server for precisely this use case.
https://github.com/crowdwave/maryjane
The secret to great user experience is you return the current video frame at time of request.
Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)
#135About eight years ago I was trying to stream several videos of a drone over the internet for remote product demos. Since we were talking to customers while the demo happened, the latency needed to be less than a few seconds. I couldn't get that latency with the more standard streaming video options I tried, and at the time setting up something based on WebRTC seemed pretty daunting. I ended up doing something pretty much like JPEGs as well, via the jsmpeg library [1]. Worked great.
[1] https://jsmpeg.com/ (tagline: "decode like it's 1999")
Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)
#136Earlier quoted context omitted.
At the same time, enterprise is where the revenue is.
Against all odds, you're right, that's where somehow revenue is being generated. IT idiocy notwithstanding.
Often, enterprises create moats and then profit from them.
It's not usually IT idiocy, that usually comes from higher up cosplaying their inner tech visionaries.
Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)
#137They might want to check out what VNC has been doing since 1998– keep the client-pull model, break the framebuffer up into tiles and, when client requests an update, perform a diff against last frame sent, composite the updated tiles client-side. (This is what VNC falls back to when it doesn’t have damage-tracking from the OS compositor) This would really cut down on the bandwidth of static coding terminals where 90%…
Copying how VNC does it is exactly how my first attempt would go. Seems odd to try something like Moonlight which is designed for low latency remote gameplay.
Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)
#138RTP is specifically designed for real-time video.
Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)
#139so did they reinvent mjpeg
An MPEG-1-based screen sharing experiment appeared here 10 years ago: - https://news.ycombinator.com/item?id=9954870 - https://phoboslab.org/log/2015/07/play-gta-v-in-your-browser...
Yup, when reading this I immediately thought of jsmpeg, which I'm fond of.
Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)
#140> When the network is bad, you get... fewer JPEGs. That’s it. The ones that arrive are perfect. This would make sense... if they were using UDP, but they are using TCP. All the JPEGs they send will get there eventually (unless the connection drops). JPEG does not fix your buffering and congestion control problems. What presumably happened here is the way they implemented their JPEG screenshots, they have some mechani…
They shared the polling code in the article. It doesn't request another jpeg until the previous one finishes downloading. UDP is not necessary to write a loop.