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

311–320 of 332 posts

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

#311

Post by unethical_ban »

unethical_ban wrote: post #129
jeltz wrote: post #109

Earlier quoted context omitted.

Posting stuff into Deepseek is banned. The corporate firewall is like putting a camera in your home because you may break the law. But, yeah, arguing against cameras in homes because people find dead angles where they can hide may not be the strongest argument.

Disclaimer: I work in corporate cybersecurity. I know that some guardrails and restrictions in a corporate setting can backfire. I know that onerous processes to get approval for needed software access can drive people to break the rules or engage in shadow IT. As a member of a firewall team, I did it myself! We couldn't get access to Python packages or PHP for a local webserver we had available to us from a grandfat…

Gotta wonder who objects to this and why, and if they have any experience managing IT or business.

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

#312

Post by Dylan16807 »

mdavid626 wrote: post #288
Dylan16807 wrote: post #227

Earlier quoted context omitted.

Why would you do that? Nearly-static content is where you want even fewer keyframes than usual. In a situation like this you need them when the connection is interrupted and you reset things, and not much of anywhere else.

1 FPS with GOP 60 might just simply not play in some players.

Is this based on experience? I can't think of a reason for a decoder to care.

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

#313

Post by Dylan16807 »

antonkochubey wrote: post #306
TiredOfLife wrote: post #241

Earlier quoted context omitted.

Youtube 4k uses VP9 and AV1 codecs that are multiple generations ahead of H.264

VP9 is inferior to H.264

VP8 sucked, VP9 is somewhat better than H.264, and AV1 is a lot better.

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

#314

Post by kccqzy »

andai wrote: post #124

Many moons ago I was using this software which would screenshot every five seconds and give you a little time lapse and the end of the day. So you could see how you were spending your computer time. My hard disk ended up filling up with tens of gigabytes of screenshots. I lowered the quality. I lowered the resolution, but this only delayed the inevitable. One day I was looking through the folder and I noticed well al…

I did something similar about fifteen years ago. A command line utility to take screenshots. And QuickTime to convert the image sequence to a video. This was before I had heard of ffmpeg so the last bit was done with the QuickTime UI. I remember also adding the screenshot timestamps as a subtitle track.

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

#315

Post by queenkjuul »

mananaysiempre wrote: post #69
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’d say there’s nothing inherently capitalist about large and stupid bureaucracies (but I repeat myself) spending money in stupid ways. Military bureaucracies in capitalist countries do it. Military bureaucracies in socialist countries did it. Everything else in end-stage socialist countries did it too. I’m sorry, it’s not the capitalism—things’d be much easier if it were.

Maybe military people are just uniquely stupid

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

#316

Post by piskov »

throw-12-16 wrote: post #298
afiori wrote: post #251

Earlier quoted context omitted.

Just saying but LLM-ese as the common dominator of how people wrote, it is likely the writing style of a lot of people

How many people do you know that use em dashes —- none.

Do yourself a favour and use typography layout

https://ilyabirman.net/typography-layout/

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

#317

Post by somehnguy »

throw-12-16 wrote: post #299
somehnguy wrote: post #172

40mbps for video of an LLM typing text didn't immediately fire off alarm bells in anyone's head that their approach was horribly wrong? That's an insane amount of bandwidth for what they're trying to do.

If all you know is vibe coding and the llm didn’t tell you 40mbs is too much how would you know?

I'm afraid to see just how poorly we can utilize computing resources in the future due to cluelessness.

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

#318

Post by tylervigen »

piskov wrote: post #166
bugufu8f83 wrote: post #165

Earlier quoted context omitted.

>Setting aside...the LLM writing style I don't want to set that aside either. Why is AI generated slop getting voted to the top of HN? If you can't be bothered to spend the time writing a blog post, why should I be bothered spending my time reading it? It's frankly a little bit insulting.

Don’t assume something you cannot prove. It was great writing

The author replied below that they used Opus to write the blog post.

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

#319

Post by hn_acker »

vscode-rest wrote: post #53
Dylan16807 wrote: post #46

Earlier quoted context omitted.

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.

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.

I can confirm that 500Kbps is not pretty. But when I'm sending screen recordings where text doesn't have to be readable (or isn't present), I try to approach 500K from above.

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

#320

Post by Sesse__ »

mikepavone wrote: post #148
01HNNWZ0MV43FF wrote: post #126

Earlier quoted context omitted.

You can still get this backpressure properly even if you're doing it push-style. The TCP socket will eventually fill up its buffer and start blocking your writes. When that happens, you stop encoding new frames until the socket is able to send again. The trick is to not buffer frames on the sender.

You probably won't get acceptable latency this way since you have no control over buffer sizes on all the boxes between you and the receiver. Buffer bloat is a real problem. That said, yeah if you're getting 30-45 seconds behind at 40 Mbps you've probably got a fair bit of sender-side buffering happening.

> you have no control over buffer sizes on all the boxes between you and the receiver

You certainly do; the amount of data buffered can never be larger than the actual number of bytes you've sent out. Bufferbloat happens when you send too much stuff at once and nothing (typically the candidate to do so would be either the congestion window or some intermediate buffer) stops it from piling up in an intermediate buffer. If you just send less from userspace in the first place (which isn't a good thing to do for e.g. a typical web server, but _can_ be for this kind of video conference-like application), it can't pile up anywhere.

(You could argue that strictly speaking, you have no control over the _buffer_ sizes, but that doesn't matter in practice if you're bounding the _buffered data_ sizes.)

Post reply on HN