Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We replaced H.264 streaming with JPEG screenshots (and it worked better)

blog.helix.ml

Post reply on HN
Print view View original

41–50 of 332 posts

Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)

#41

Post by gspr »

embedding-shape wrote: post #33
ris wrote: post #24

Earlier quoted context omitted.

Corporate IT needs to die.

I think the general idea/flow of things is "numbers go up, until $bubble explodes, and we built up smaller things from the ground up, making numbers go up, bloating go up, until $bubble explodes..." and then repeat that forever. Seems to be the end result of capitalism. If you wanna kill corporate IT, you have to kill capitalism first.

I don't believe that. I don't necessarily love capitalism (though I can't say I see very many realistic better alternatives either), but if HN is full of people who could do corporate IT better (read: sanely), then the conclusion is just that corporate IT is run by morons. Maybe that's because the corporate owners like morons, but nothing about capitalism inherently makes it so.

Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)

#42

Post by Snild »

bambax wrote: post #8
robrain wrote: post #2

"Think “screen share, but the thing being shared is a robot writing code.”" Thinks: why not send text instead of graphics, then? I'm sure it's more complicated than that...

Yeah, I'm thinking the same thing. Capture the text somehow and send that, and reconstruct it on the other end; and the best part is you only need to send each new character, not the whole screen, so it should be very small and lightning fast?

Sounds kind of like https://asciinema.org/ (which I've never used, but it seems cool).

Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)

#43

Post by jodrellblank »

robrain wrote: post #2

"Think “screen share, but the thing being shared is a robot writing code.”" Thinks: why not send text instead of graphics, then? I'm sure it's more complicated than that...

Thinks: this video[1] is the processed feed from the Huygens space probe landing on Saturn's moon Titan circa 2005. Relayed through the Cassini probe orbiting Saturn, 880 million miles from the Sun. At a total mission cost of 3.25 billion dollars. This is the sensor data, altitude, speed, spin, ultra violet, and hundreds of photos. (Read the description for what the audio is encoding, it's neat!)

Look at the end of the video, the photometry data count stops at "7996 kbytes received"(!)

> "Turns out, 40Mbps video streams don’t appreciate 200ms+ network latency. Who knew. “Just lower the bitrate,” you say. Great idea. Now it’s 10Mbps of blocky garbage"

Who could do anything useful with 10Mbps. :/

[1] https://en.wikipedia.org/wiki/File:Huygens_descent.ogv

Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)

#44

Post by Jakob »

Yes, this is unfortunately still the way and was very common back when iOS Safari did not allow embedded video.

For a fast start of the video, reverse the implementation: instead of downgrading from Websockets to polling when connection fails, you should upgrade from polling to Websockets when the network allows.

Socket.io was one of the first libraries that did that switching and had it wrong first, too. Learned the enterprise network behaviour and they switched the implementation.

Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)

#45

Post by karhuton »

I made this because I got tired of screensharing issues in corporate environments: https://bluescreen.live (code via github).

Screenshot once per second. Works everywhere.

I’m still waiting for mobile screenshare api support, so I could quickly use it to show stuff from my phone to other phones with the QR link.

Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)

#46

Post by Dylan16807 »

HelloUsername wrote: post #40
Dylan16807 wrote: post #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 1…

> 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.

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.

Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)

#47

Post by gruez »

egorfine wrote: post #5

> 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…

>And you have to work around that, because IT dept of the corporation will never lift restrictions.

Because otherwise people do dumb stuff like pasting proprietary designs or PII into deepseek

Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)

#48

Post by layer8 »

gspr wrote: post #41
embedding-shape wrote: post #33

Earlier quoted context omitted.

I think the general idea/flow of things is "numbers go up, until $bubble explodes, and we built up smaller things from the ground up, making numbers go up, bloating go up, until $bubble explodes..." and then repeat that forever. Seems to be the end result of capitalism. If you wanna kill corporate IT, you have to kill capitalism first.

I don't believe that. I don't necessarily love capitalism (though I can't say I see very many realistic better alternatives either), but if HN is full of people who could do corporate IT better (read: sanely), then the conclusion is just that corporate IT is run by morons. Maybe that's because the corporate owners like morons, but nothing about capitalism inherently makes it so.

Apparently capitalism doesn’t pay enough for corporate IT admin jobs.

Re: We replaced H.264 streaming with JPEG screenshots (and it worked better)

#49

Post by jayd16 »

So they replaced a TCP connection with no congestion control with a sycnronous poll of an endpoint which is inherently congestion controlled.

I wonder if they just tried restarting the stream at a lower bitrate once it got too delayed.

The talk about how the images looks more crisp at a lower FPS is just tuning that I guess they didn't bother with.

Post reply on HN