+1 - I made the same technology choice back in 2014. Seems like nothing has changed.
TL;DR: You can't keep things too simple.
We replaced H.264 streaming with JPEG screenshots (and it worked better)
271–280 of 332 posts
Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)
#272Earlier quoted context omitted.
> Serializable in principle, maybe. Actually serializable in the sense that the code contains a way to dump to a file and back, absolutely not. It's extremely rare for programs to expose a way to save and restore from a mid-state in the algorithm they're implementing. If you should ever look for an actual example; Cubemap, my video reflector ( https://manpages.debian.org/testing/cubemap/cubemap.1.en.htm... ), works l…
Why not hand off the fd to the new process spawned as a child? That’s how a lot of professional 0 downtime upgrades work: spawn a process, hand off fd & state, exit.
That's exactly what it's doing. The tricky part is the “hand off state” part.
Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)
#273why not media over quic
Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)
#274You know what else I don't quite get? Why isn't "Your network is broken. Fix your network. Blocking UDP is idiotic. Get someone to set it up who has at least stood within hailing distance of a clue" an acceptable thing to say here?
Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)
#275Earlier quoted context omitted.
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.
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.)
For mostly static content like screencasts by dropping duplicate frames and producing variable framerate h.264 yuv444 videos with lossless encoding I was getting <100 kbps files for 1024x768 resolution more than a decade ago.
Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)
#276Earlier quoted context omitted.
> They shared the polling code in the article. It doesn't request another jpeg until the previous one finishes downloading. You're right, I don't know how I managed to skip over that. > UDP is not necessary to write a loop. True, but this doesn't really have anything to do with using JPEG either. They basically implemented a primitive form of rate control by only allowing a single frame to be in flight at once. It wa…
> have limited control over their encode pipeline. Frustratingly this seems common in many video encoding technologies. The code is opaque, often has special kernel, GPU and hardware interfaces which are often closed source, and by the time you get to the user API (native or browser) it seems all knobs have been abstracted away and simple things like choosing which frame to use as a keyframe are impossible to do. I h…
I'm on a media engineering team and agree that applying the tech to a new use case often involves people with deep expertise spending a lot of time in the code.
I'd guess there are fewer media/codec engineers around today than there were web developers in 2006. In 2006, Gmail existed, but today's client- and server-side frameworks did not. It was a major bespoke lift to do many things which are "hello world" demos with a modern framework in 2025.
It'd be nice to have more flexible, orthogonal and adaptable interfaces to a lot of this tech, but I don't think the demand for it reaches critical mass.
Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)
#277You can do TURN using TLS/TCP over port 443. This can fool some firewalls, but will still fail for instances when an intercepting HTTP proxy is used. The neat thing about ICE is that you get automatic fallbacks and best path selection. So best case IPv6 UDP, worst case TCP/TLS One of the nice things about HTTP3 and QUIC will be that UDP port 443 will be more likely to be open in the future.
It's going to take those conservative netadmins another 10 to 20 years to learn that HTTP/3 or QUIC works over UDP and that it needs to be enabled. So... happy buffering and watching spinners until then.
Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)
#278The fact that they considered transmitting only keyframes speaks volumes about how inept they are. It can be a cool baseline test, but celebrating trendy choices, like Rust, and not understanding that keyframes and efficient differentials are key to achieving high video compression makes me go completely numb.
Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)
#279Everyone talks about Websockets for pushing real time data to the browser. This article highlights some of its drawbacks. I use Server Sent Events (SSE) instead. A lot of the problems the author of the article faced are solved with SSE. Also, SSE scales way better than polling all the time.
Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)
#280Wait what? 40Mbps for a remote desktop? Event 10Mbps is insane. I remember deploying sunrays over dialup and the image wasn't that bad, yes it was low resolution and I think it was UDP, but the desktop was usable with a surprisingly low latency.
To monitor an IA you can lower the bit depth considerably and not lose that much details on what is happening. If you control the web rendered, disable text anti aliasing, and there might be other optimization that can help. Tile & diff the image... But video encoders already does that so it might just work out of the box.
Also if your single h264 image is larger that jpeg then you are doing something wrong, jpeg is a very poor encoding compared to what we have today.
Look at how other remote desktop protocol does it, VNC, RDP...
Managing streams over corporate network is well documented, many web frameworks will include a "longpoll" fallback (or SSE) for streaming to play nice even without web sockets. "Discovering" you cannot deploy whatever you want to an enterprise network is quite alarming.
I really don't want to be the graybeard guy saying "young engineers are bad", as I am more on the side of believing on the new generations, but please, don't act like computers spawned into existence in 2020 and that nothing has been done before.