Closing the Chapter on OpenH264 | Hacker News Reader

Closing the Chapter on OpenH264

bbhtt.space

69 pointstodsacerdoti68 comments

I hope the future is bright with AV1. But even scene groups heavily release in 265 instead of AV1. Hardware support is going to get better over the years and hopefully everyone will just use AV1 and leave this license BS behind.

I avoid AV1 sources for anything I care about, because of film grain synthesis.

Does AV1 just emulate the film grain from the source video, or are people adding/customizing the grain when encoding?

Emulates it, which strikes me as extremely silly. The original grain is in the film itself, it's part of it, it's what the image is made of. Fake grain is just noise. Either denoise it or keep the real grain, I have no interest in fake grain.

Can't you turn it off in the player and get the denoised version?

Probably? Though I don't think those kinds of controls are exposed in most of the players I use (usually set-top box video players). Besides, if I'm dealing with a 20 to 80GB 4k copy of something that originally had grain, I prefer it still be present—if I'm dedicating that kind of space, the point is fidelity. If I'm dealing with something smaller than about 8GB 1080p, I probably don't really care what it looks like aside from preferably not having obvious artifacting, so I guess AV1 would be OK in that case, though all else being equal I'll still pick h265 just to avoid the fake-grain concern entirely.

including digital footage with film grain added in post?

I don't watch a ton of films with noticeable fake grain. Even the ones that do fake it, it's barely perceptible, so I wouldn't care on those—not many of them are emulating the huge, obvious grain of high-sensitivity '60s and '70s film, for instance. A lot of what I watch is from the '90s or earlier, so the grain's real.

Why? It's a feature you have to explicitly turn on when encoding, and I've not seen people using it for most stuff.

I can't know if it was used in advance, so favor h265. Which is far more common (and so's h264) so it's not much trouble to avoid AV1.

vp9 is widely used (e.g. YouTube is mostly vp9, av1 and fallback h264) and not much worse

I'll continue to use h264 because it has hardware acceleration on my Thinkpad X220, whereas x265 doesn't enjoy the same luxuries on this laptop.

It might be time to consider some new hardware. That machine is going on 15 years old now!

To be honest, if a 15 year old machine is still working fine for somebody, and h.264 is fine (if you don't care about HDR/4k, it really sort of is!), I'm not sure the benefit of suggesting somebody junk a machine

I have considered, but so far there's no other hardware which has this form-factor with Libreboot support (although I'm unsure whether the X230 has x265 hw accel)

> But even scene groups heavily release in 265 instead of AV1.

I believe this is because scene groups don't really care about patent licensing, and there's around 5-6 years of computers with hardware H.265 decoding and no hardware AV1 decoding. I think we'll see AV1 and successors take over in 5-10 years when it's safer to assume users will have AV1 decoding.

AV1 is extremely slow to encode last time I tried.

For now most of the focus has been on the slow encodes, but in theory it can match h264 for speed and quality on encoding. In practice I've seen it get very close already.

My guess is you were using the reference AOM encoder. This is actually a real branding problem! It was never designed for encoding speed, and it shows.

SVT-AV1 is the production encoder you should be using. It's high quality and fast in software, and should really always be the default.

It is not a branding problem. Only in recent few years has SVT caught up to AOM in terms of encoding quality.

Using SVT for encoding in the early days is basically trading quality for speed.

> I hope the future is bright with AV1.

I bought an Intel Arc A580 and then later B580 which also has an AV1 hardware encoder, and I have to say that it's really pleasant, good enough for real time streaming, video recording even at lower bitrates (e.g. 1080p30 at ~10 Mbps is okay) and ends up saving a lot of space when compared to both H264 and H265, which previously wasn't viable because the CPU based encoder is painfully slow.

I saved a few hundred GB of space by re-encoding all of my local videos in AV1, I'm guessing it might be have been one of the better cases because most of the videos were anime instead of more detailed video like regular movies, but it worked out nicely for me! Plus, the software support is also quite good: OBS and Handbrake had no issues, neither does VLC seem to have any.

All of that makes me wish it'd become more widespread in the next decade or so, everywhere from YouTube and Twitch to even our phone cameras.

> 1080p30 at ~10 Mbps is okay

FWIW Most Streaming TV Services like Zattoo do 1080p50 using H264 using that Bitrate and while not perfect it's fine - using AV1 one could probably go way below that.

1080p30 at ~10 Mbps isn't a low bitrate unless you are aiming for something very specific. Not to mention there is H.265 hardware encoder inside Intel Arc, although I have no idea about their quality. Nvidia seems to do a much better job in this area.

If you record a video game, I find that anything much lower really messes with the visual quality, especially if it portrays a forest scene or something with lots of detail like snow. Admittedly, you have to zoom in to notice and it's more apparent during fast movement, though VBR and other options seem to help.

The H265 encoder is also lovely, from what I've seen! Bigger file sizes, but a bit more software support in some places.

Because scene groups are still done by enthusiast that actually cares about encoding quality rather than patents licensing.

Of h.264, h.265, vp8, vp9, and av1, h.264 is the only codec with consistent support across all of chat/messaging clients, browsers, smart TVs/phones, tablets, and streaming devices. The population of active, supported devices and software is much larger and much older than people realize. As such, it remains the only viable video codec if you don't want to be forced to provide multiple encodings.

Isn't it already patent free in Europe? You can't patent algorithms in Europe. For example MP3 was royalty free in Europe because there was no patent on it.

Too often the organisation behind projects is in the US, so is restricted to only what is legal in the US.

I suspect that’s the case here. IIRC, the Freedesktop servers are hosted in the US, so are also affected by what’s legal there too.

And in this case, they were shipping a userspace for their sandboxes, which is a dependency for many others. If it contains code that cannot be distributed in the US, then anyone in the US will have to pick an alternative.

seems like another reason to hop onto "move your servers to Europe" bandwagon

Well, they recently did (Hetzner specifically) although for different reasons. It was down most of last week and there is still this banner up on the GitLab instance:

> The migration is almost done, at least the rest should happen in the background. There are still a few technical difference between the old cluster and the new ones, and they are summarized in this issue. Please pay attention to the TL:DR at the end of the comment.

Link: https://gitlab.freedesktop.org/freedesktop/freedesktop/-/iss...

> the Freedesktop servers

Think they just moved to Hetzner.

Weird considering a ton of codec patents are held by Fraunhofer, which is based in Germany. https://www.iis.fraunhofer.de/en/ff/amm.html

Formerly MP3 (expired 2017), MPEG-H Audio, xHE-AAC, EVS, LC3/LC3plus, Symphoria, Sonamic and upHear

So apart from US, H.264 High Profile will be patent free by this August!

It is possible to do something like webrtc without using one of h264 or h265 and have it work on all browser versions ?

Normally, apple quicktime containers with h264 payloads are playable everywhere. If you drop h264 or h265 there is no such play anywhere container available anymore right ?

Correct. The most supported container and codec families are those coming out of the MPEG - .mp3, .m4a, .mp4, H.264, H.265 etc. - because they are the products of a giant standards effort. A lot of modern TVs and set-top boxes will accept content in e.g. the Matroska container, and VP/AV video content, but unfortunately support still isn't at the level of the MPEGs.

VP8 should be required by the base WebRTC spec, but some devices only have hardware acceleration for H.264 so you should test the actual performance before changing codecs. Also consider using VP9 / AV1 if you know all the devices in a call support it and are fast enough to encode/decode it.

https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Fo...

> Which codecs can be within those tracks is not mandated by the WebRTC specification. However, RFC 7742 specifies that all WebRTC-compatible browsers must support VP8 and H.264's Constrained Baseline profile for video, and RFC 7874 specifies that browsers must support at least the Opus codec as well as G.711's PCMA and PCMU formats.

https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Fo...

The binary would be downloaded on the end user’s machine, inside a sandbox and then the “recipe” would be executed to create a working extension. This avoids various “redistribution” restrictions entirely since we aren’t shipping the binary itself.

That makes me wonder, why not just download the source code and compile it. You're definitely not distributing any binaries that way.

As I understand it, Cisco licenses the relevant patents and sublicenses them gratis to every user who uses Cisco’s binaries obtained from Cisco directly and not redistributed (thus also the difficulties in the article with working with Cisco’s unmaintained web server). The sublicense doesn’t apply to binaries built independently from source. I suppose this was imposed by the patent holders.

Can that library be rebuilt in a reproducible manner? If so, what's the difference between the library hosted by Cisco and a locally built one that is identical bit-for-bit? Is there any mechanism to ensure that the library was genuinely downloaded from Cisco rather than procured through alternative channels? If the Cisco server is turned off tomorrow, how can one tell if a copy of the library wasn't downloaded from the Cisco server while it was available?

I'm most likely missing a lot of crucial context, but it appears to me that this peculiar licensing scheme was a compromise made between lawyers that makes little practical sense on a technical level. That, or I'm far too chaotic for such nonsense.

The difference is legal, not technical. You don't have the right to redistribute copyrighted material with permission, except according to exceptions to copyright law (which are narrow enough to not apply here). Cisco gives permission for users to use the software only if downloaded directly from Cisco, and doesn't grant anybody permission to mirror and redistribute it.

Can you tell if a copy was downloaded from Cisco directly? No. Does it make a technical difference? No. But those are the rules Cisco chose, and so there it is.

One potential reason I can think of for this happening is Cisco being required to count the number of downloads of the software (or something like that). But, in the end, there's no requirement that there be logical sense to a rule like this.

Can you tell if a copy was downloaded from Cisco directly? No. Does it make a technical difference? No. But those are the rules Cisco chose, and so there it is.

Is it enforceable if there is no observable difference?

Legally, it is enforceable. That's not the same as practically enforceable.

This is long overdue. Cisco's decade-long refusal to deliver binaries, or even hashes of the binaries, over an https connection astounds me.

So they decided to just ignore the patent problem? Fair, I guess, that’s what other open source projects do.

Why hasn’t canonical been sued by MPEG-LA et.al? Are they no redistributing compiled FFMPEG for commercial purpose?

It really is too bad AV1 hasn't had a successor yet. x264 and x265 are patent ridden scourges and should be avoided wherever possible.

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

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.

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.

Does AV1 need a successor right now? At least as of some years ago SVT-AV1 was stronger than x265 on both software encoding speed and quality/bitrate[1], and a successor would reset the timer on getting hardware decoders rolled out.

[1] https://medium.com/@ewoutterhoeven/av1-is-ready-for-prime-ti...

It looks like VVC (H.266) will be significantly better compared to HVEC and AV1. But due to the patent issues it'll bound to have, I suspect common usage will practically be nonexistent, just like HVEC.

Really? Last I checked it seemed to be similar to AV1

I'd love to see a well-done comparison between quality and encoding time that isn't this increasingly old graph: https://people.videolan.org/~unlord/SVT-AV1_BD-rate.png

I've seen some strong claims for VVC but not with a lot of detail on encoding settings.

> I suspect common usage will practically be nonexistent, just like HVEC

HEVC is used in all TV broadcast station. FaceTime and other Cameras, Netflix, Amazon Prime, Disney+ and many other large streaming services outside US. The only one that doesn't have any usage of HEVC is Youtube.

Seems like the last h264 patents expires in about 5 months, silly to start moving around to options that might have submarine patents when we'll have something functional that's patent free in quite a short time.

They've been working on it for years but I'm not sure there's any great need for it right now. The various MPEG alternatives seem to be eating themselves with patent infighting and fragmentation.

The problem with the patents are largely misunderstood. Most importantly the patents do not directly apply to the individual consumer downloading and decoding such audio/video content. The patents only apply to commercial settings - the sales of software that can encode or decode audio and video in the MPEG formats, and sales of audio and video content encoded in those formats. This is why Mozilla made a big fuss over not wanting to include H.264 decoding in Firefox years ago, because they feared they'd have to spend a bit of their money since they are after all a commercial endeavour. No, really, it was never about wanting to "protect" users, it was always about their earnings. You can happily encode AAC audio and H.264 video and share it free of charge with everyone, and they can always listen to and watch that content, without any worries.

And pardon the nitpick but it's H.264 and H.265, not x264 and x265.

edit: Got confused by Wikipedia.

It says AV1 is open source and royalty free, and all modern hardware seems to have hardware decode for it. It doesn't seem any of the big players are realistically worried about bogus patent claims.

AV2 from what I heard is aiming to be released this year.

Reply on news.ycombinator.com