Hacker News Reader

Comment by ddtaylor | Hacker News Reader

I encode a lot of my media as h264 because it makes it easy for my kids to stream it from Jellyfin without transcoding.

unless the content is 4k. Then you want h265 ;P

Why?

2160p content in h264 will be too big to normally manage. h265 is way better at it. file sizes stay within normal limits.

Can you be more specific? I can't really tell what you mean by "normal" here.

And while I do like smaller files, if I compare with a few years ago my connection is faster and my drives are bigger so presumably the limit for "normal" has gone up...

H.264 does just fine with 4K. If you know what you're doing you really don't need to throw 10 Mbit/s at it to get crisp quality.

(p.s. I'm fully onboard with H.265 being fantastic, it's amazing to see what e.g. x265 can do for it, being able to provide practically identical output at 30-50% lower bitrate. I'm just saying that H.264 isn't in any way incapable.)

H.264 may allow 2160p video, but the 4K UHD standard is more than just 2160p. For example, HDR is absolutely critical to 4K, and the only way to do that in H.264 is to use Hi10P which isn't supported by most devices.

In fact, I'd say HDR is more important than 2160p resolution in that I'd rather watch 1080p HDR video than 2160p SDR video.

The trick is knowing what the optimum settings are to use.. with h.265 as you lower the bitrate it smooths more and more and you lose detail. h.264 does blocking instead, so there is an image quality difference.

At the lower end of useful bitrate there's absolutely a difference. Video encoding is complex territory and there's no way around knowing and understanding "optimum settings" when wanting to keep bitrate down, no matter MPEG-4 ASP, H.264, H.265, AV1, what-have-you.

My experience is that CRF by itself works well down to very low bitrates.

Compared to other modes of operation, CRF doesn't work better or worse at any arbitrary bitrate. In itself it doesn't do anything fundamentally different about how changes between frames are analyzed or how the changes are encoded. It's a "constant quality" mode of operation, and it will use as much data as it deems necessary in order to meet the quality target. That is, CRF produces a varying bitrate product and you have no actual control over the final bitrate requirement.

I know it's not doing anything very different. But that's my point, that you don't need fancy tuning features.

As for final bitrate, maybe we need to talk more about use case here. Because for very small encodes (often around 250kbps), I never cared about moment to moment bitrate, just the final file size. And if that's too far off I change the factor and run it again.

For things I intend to stream I usually have a bitrate limit on top of the CRF setting, but that's the only optional flag and it doesn't kick in very often. The result is quite high quality out of 2-3Mbps AV1, without any flags that affect the details of the video encoder, so I don't see a need for knowing and understanding optimum settings. And the same setup worked with h.264 at a moderately higher bitrate.

The best thing you can do for the encoder is give it time to work.

Reply on news.ycombinator.com