Hacker News

Using multiple CPUs for encoding goes way back. The early (1994) C-Cube MPEG-1 and MPEG-2 real-time encoders for DirecTV were built with 8 chips running in parallel (out of necessity since they were only 60 MHz processors) to encode 704x480. Each chip encoded a slice of the image and an auxiliary bus was used to send reconstruction video between chips so that motion vectors could cross chip image boundaries.

Here's a picture of the VME bus development board. It was a two board sandwich to support 10 chips in parallel (only one board pictured).

https://www.w6rz.net/scorpio.jpg

The first real-time HDTV encoders for terrestrial digital television (ATSC) were built by Harris using an IBM encoder chip. It took 6 chips to encode 1920x1080. The IBM chips didn't have an auxiliary bus, so you could see motion vectors limited to chip image boundaries (in this case, 6 tiles arranged like so).

  -------------------------
  |       |       |       |
  |   1   |   2   |   3   |
  |       |       |       |
  -------------------------
  |       |       |       |
  |   4   |   5   |   6   |
  |       |       |       |
  -------------------------

Very cool. Took a similar approach to optimizing openutv by looking at flamegraphs. UTV is a fork of openrv which is an older release of the commercial RV. Like many things it uses ffmpeg and also native readers and writers for certain formats. Allowed me to get it to 8k@60fps buttery smooth playback with hardware acceleration. If you are still in the video/imaging space would love your feedback on UTV. openutv.com

That's all well and good, but let me know when I can buy a used $50 NUC or pi or such that has hw decoding of the same for my TV front ends.

And maybe ten more and enough hardware will support it that it will be mainstream.

If you really want to see magic, take a test sample of YUV420 video and AV1 encode it to an extremely low bitrate at like 720p, 24 fps to simulate something like the jerky handheld front-phone-cam in the example URL. Keep lowering the bitrate until the quality become unacceptable. Then compare it to the same bitrate/approx total file size in H264 and how bad it looks.

2018 AV1 demo

https://news.ycombinator.com/item?id=16796127

We need one final video codec.

Otherwise we will have this:

https://xkcd.com/927/

I feel as though AI is going to blow these all out of the water soon.

And then we'll get AI-designed hardware codecs for them.

FYI, both VP9 and AV1 support lossless as part of their base profiles, so lossless files using those codecs should be compatible with all implementations (at least in theory). Though those profiles only support 4:2:0, so it depends on your use case if that really counts as lossless.

x265 supports lossless as well (though I believe it's not part of the H.265 standard). It's what I use for video capture.

What is the purpose of lossless H.264 vs. ProRes or the like?

Is it similar to lossless audio were there's not a ton of optimization you can do?

you can easily record lossless h264 via obs and any ffmpeg-backed player will play it just fine

the days where the OS matters for video playback are long gone

I remember reading an article on here by one of the founders of MPEG about why he was leaving MPEG after several decades, and part of it was that modern AI is indistinguishable from compression and he wanted to explore new compression algorithms using the recent explosion of knowledge

The newest submissions to Hutter Prize made crazy jumps by just replacing the LSTM with a transformer and training it.

35'000$ for a prompt and some training is a nice chunk of cash.

Next steps are replacing the encoders and all the other human-biased compression parts by just raw data and training, probably another 20-30% is up for grabs.

It's still magic

On average, yes. But without hiccups: only very few NVMe drives can do this over really long runs without stalls. I've been working a lot with high rate SDR earlier this year and it took a lot of testing of different drives to find one that did not have this issue. I was quite surprised because you'd think that the underlying mechanism, if it works at all should be able to work sustainably but once every 10 minutes or so there would be a (brief) stall which would cause the SDR to start dropping data because it wasn't serviced fast enough. The only one that didn't do this was the 'Lexar SSD NM1090 PRO 4TB', which was surprising because it was one of the cheaper ones that I tried.

WebP stands on its own merits but it's profoundly annoying that as of Pop OS 22.04 I still have to open them up in Firefox instead of Eye of Gnome. Compatibility issues like this are littered everywhere. This laziness on the part of supporting WebP is a significant driver of continued use of PNG.

With JPEG XL finally being allowed into mainstream web browsers, we’ll hopefully see more native platform support and be able to slowly phase every older codec out, since JPEG XL does very well at more or less everything (except for animation, compared to video codecs).

WebP is limited to 16383x16383. I've run into this limit a handful of times and I would expect it to become more of an issue as screen pixel densities increase.

For completeness, my background job of the highest imaginable PNG compression yielded optimized: 528313 bytes. Took only several minutes...

It’s mostly mission dependent as you mentioned, if the value of some images are different than others, compressing several pictures and selecting the best to get in raw is a good strategy, and you can also crop them to get interesting areas as mentioned.

It can also depends on the downlink bandwidth available and power/energy budget, so the optimal strategy will differ.

It can be misleading at times though, for example some interesting feature may happen to be just a compression artifact. A cloud looking like some strange human-made object for example, happened to us one time.

Wait is this true? Will I finally be able to use h264 on da Vinci resolve for free?

I've done AV1 encodes where I was convinced the conversion must have failed in some way for it to be that small, scrubbed through it and it all looks fine, watched through the entire thing to confirm that wasn't the case, just waiting for the shoe to drop, but then to find out, no, it's really just that good.

Consider me confused. Isn’t quantizing a value, e.g. reducing the number of bits in an int, a form of discarding information from that value? Isn’t your comparison just about discarding information on another level (discarding entire values)?

The definition you quoted explains why quantization discards information: multiple distinct input values map to the same output value. Once that happens, you can no longer determine the original input from the output alone. The distinctions between those inputs are the information that has been lost.

Transmission cost of an interpolated frame: 0 with DLSS. But adding a little extra information could help reduce artifacts.

Sure, DLSS uses game engine information, such as motion vectors and depth, which is unavailable for video. But neural networks can estimate motion directly from video frames and interpolate without that information. Providing additional data to fix artifacts would cost little.

There are some interesting advances in neural video encoders and decoders - I suspect it will look a lot like the neural models in DLSS 5 for compression -> decompression/reconstitution. There have been some lossless text-compression neural models built that seem to surpass even high level compression algorithms so with time those could get there.

For personal use, if those are your only two choices, then go with H.265 for higher efficiency, or H.264 for wider compatibility. If other codecs are an option, go with AV1 for higher efficiency. It’s currently the best and already pretty widely supported.

The main reason to use H.264 in 2026 is legacy device support. Some devices cannot play H.265, but H.264 is playable almost anywhere, as a 20+ year old codec.

I was surprised that Twitter only lets you upload H.264 still, in 2026.

It depends on how you want to play or share the media.

E.g. I remember having lots of issues sharing smaller video files encoded with H.265 via both WhatsApp and Messenger. iMessage doesn't support H.265 (or at least it didn't work for me at the time).

H.264 (if you want to support 20 year old devices) or av1. Don't use h.265. The patent situation around it is a total mess.

h264, if you had a reason to use something else you wouldn't need to ask

That all depends on your use case.

How are you generating video?

How are you playing it back?

H.264 for 1080p and less. H.265 for 2160p.

Patents aside, h265 from my reading is almost universally better than h264. My understanding which could be wrong is that for a given quality h265 will always be smaller, and particularly for >1080p it's recommended. Hardware support has been around since at least the Shield days (2019) so that shouldn't be an issue. Only use h264 if you are needing to hw-decode on really old hardware.

AV1 is the future/present: Fully open standard, better than h265. Only downside is hardware support: You need hardware made in the last few years.

that's like asking "should I use an audi or a tesla"

Yes, as they explain shortly after, in the next section "shedding weight".

They're not actually confused here. It's a writing style, where you pose an interesting problem/scenario, then explain it.

Actually I had the same thought, but this is obviously an article for people who don't know the difference between lossless and lossy compression. Ok, you might argue that it's not a good fit for HN, but going by the many times it seems to have been posted here, some people disagree.

It makes tons of sense to compare those numbers. It's a big part of how you benchmark lossy compression. I guess in some sense they should use BMP instead of PNG but it's arguable.

Discussed elsewhere here: h.264 supports lossless storing.