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

301–310 of 332 posts

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

#301

Post by mrguyorama »

nwallin wrote: post #222
taberiand wrote: post #118

Earlier quoted context omitted.

This blog post smells of LLM, both in the language style and the muddled explanations / bad technical justifications. I wouldn't be surprised if their code is also vibe coded slop.

> I wouldn't be surprised if their code is also vibe coded slop. That's my takeaway from this too. I think they tried the first thing the LLM suggested, it didn't work, they asked the LLM to fix it, and ended up with this crap. They never tried to really understand the problems they were facing. Video is really fiddly. You have all sorts of parameters to fiddle with. If you don't dig into that and figure out what tra…

>Video is really fiddly.

But it's really not! Not for "Tweak a few of the default knobs for your use case".

It takes five minutes to play around with whatever FFMPEG gui front end (like even OBS) to get some intuition about those knobs.

Like, people stream coding all the time with OBS itself.

Every twitch streamer and Youtube creator figured out video encoding options, why couldn't they?

They are using a copy of a game streaming code base for this, which is entirely the opposite set of optimizations they should have sought out.

Like, this is rank incompetence. Your average influencer knows more about video encoding than these people. So much for LLMs helping people learn!

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

#303

Post by mrguyorama »

stefan_ wrote: post #186
colechristensen wrote: post #171

Earlier quoted context omitted.

This is where LLMs shine, where you need to dip your toes into really complex systems but basically just to do one thing with pretty straightforward requirements.

The peak of irony, because you know how these people arrived at their 40 Mbit bitrate H264 and their ineffective tinkering with the same in the first place is guaranteed to be some LLMs expert suggestions. As is often the case, because they had no understanding of the really complex system subject matter whatsoever, they were unable to guide the LLM and ended up with .. slop. Which then turned into a slop blog post.…

>As is often the case, because they had no understanding of the really complex system subject matter whatsoever

Something I want to harp on because people keep saying this:

Video streaming is not complicated. Every youtuber and twitch streamer and influencer can manage it. By this I mean the actual act of tweaking your encoding settings to get good quality for low bitrate.

In 3 months with an LLM, they learned less about video streaming than you can learn from a 12 year old's 10 minute youtube video about how to set up Hypercam2

Millions and millions of literal children figured this out.

Keep this in mind next time anyone says LLMs are good for learning new things!

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

#305

Post by dpe82 »

andrewf wrote: post #276
londons_explore wrote: post #167

Earlier quoted context omitted.

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

I started doing media/codec work around 2007 and finding experienced media engineers at the time was difficult and had been for quite some time. It's always been hard - super specialized knowledge that you can only really pick up working at a company that does it often enough to invest in folks learning it. In my case we were at a company that did desktop video editing software so it made sense, but that's obviously uncommon.

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

#306

Post by antonkochubey »

TiredOfLife wrote: post #241
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.

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

VP9 is inferior to H.264

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

#307

Post by mschuster91 »

visiondude wrote: post #149

I very confused, couldn’t they have achieved much better outcome with existing hls tech with adaptive bitrate playlists? Seems they both created the problem and found a suboptimal solution.

They don't have ffmpeg in the video pipeline, making anything a true PITA. ffmpeg has long solved the task of outputting HLS, DASH or whatever else standard and it Just Works No Matter Where. But if you're not using ffmpeg... you're bound to learn all the mistakes the ffmpeg people had to learn, and there are so many hidden traps.

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

#308

Post by mdavid626 »

kccqzy wrote: post #294
mdavid626 wrote: post #288

Earlier quoted context omitted.

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

You wouldn’t use 1fps in conjunction with GOP 60. The original article wanted exactly one key frame every 60 frames and the server drops all frames other than keyframes. I was pointing out that this is a roundabout way of achieving 1 fps.

I don’t disagree.

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

#309

Post by xp84 »

andrewf wrote: post #276
londons_explore wrote: post #167

Earlier quoted context omitted.

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

> It was a major bespoke lift to do many things which are "hello world" demos with a modern framework in 2025.

This brings back a lot of memories -- I remember teaching myself how to use plain XMLHTTPRequest and PHP/MySQL to implement "AJAX" chat. Boy was that ugly JavaScript code. But on the other hand, it was so fast and cool and I could hardly believe that I had written that.

Post reply on HN