Hacker News .hnnew | past | comments | ask | show | jobs | submitlogin

H.265 requires getting a license from at least 2 patent pools[0], and who knows how many other patents are out there waiting to get sued over.

If you want a new cross platform video codec, check out AV1.[1]

[0] https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding#P...

[1] https://aomedia.org/av1/



Three patent pools, and some major companies that you need patents for aren't in any of them. Also unlike H.264, there was no limit to how much you could spend on licensing every year. And that was only the beginning of the disaster.

https://hackernews.hn/reply?id=31318663&goto=item%3Fi...


>there was no limit to how much you could spend on licensing every year.

Both MPEG-LA and HEVC Advance offer Max Cap per year.


MPEG LA had a cap, Access Advance (formerly known as HEVC Advance) now has a cap though I do not believe there was a cap originally. However, my statement is still correct because to use HEVC you need to also talk to Velos Media (pricing and terms not public), and you also need to contact several individual companies not in pools like Technicolor (who also do not have their pricing and terms public).

EDIT: HEVC / Access Advance does have a cap if you put their branding on any product you make containing HEVC technologies - including, oddly, 4K Blu Ray discs (see LOTR Extended Edition 4K, it has the HEVC logo on the box, as if literally anyone cares about HEVC as a brand). If you don't put their logo on your products, no caps.


>If you don't put their logo on your products, no caps.

New HEVC-Only Platform License - Royalty Rate Structure for Licensees In-Compliance without Trademark Discount has Caps. And the Standard Structure for HEVC Licensees with no caps are there for specific uses only under trademark dispute.


The licenses have already been paid for the hardware implementation, that doesn't explain, eg, Chrome's refusal to leverage hardware decoding (and stop burning so much power on laptops).


Chrome and Mozilla both want their competitor format AV1 to “win”.

Plus, partial support is a burden - one of the patent holders might come by and ask you to prove you didn’t accidentally violate one of their patents while fastidiously only using that approved hardware. I think there’s a lot of lawyer risk there below the waterline.


It would also be extremely confusing to support something with only hardware decoding. People running supported hardware would start saying things like "Firefox supports HEVC" which would sound plainly wrong to someone with unsupported hardware.


On the other hand, basically all platforms of the last few years support hardware decoding of HEVC. nVidia does, Intel does, AMD does... so pretty much for every PC made in the last ~six or so years:

- You paid the royalties for HEVC, possibly multiple times

- It can almost certainly encode and decode HEVC without breaking a sweat

- You (practically) can't use it ("if it's not on the web, it's dead")


Yes a decade ago this was the Firefox approach to h264 -- leverage OS/hardware support if available. Can confirm horrible experience for devs and viewers


Google already paid the Max Cap for HEVC patents on their Pixel Phone and other hardwares. Turning on Hardware acceleration option on Chrome isn't a partial support or cost issues. It was simply an ideology issue.



I don't buy the patent argument. AV1 is not unique, it would not be hard to find some similarities in the math and argue infringement of one of tens of thousands of patents these companies sit on. The companies simply don't want to upset the largest tech companies, though apple already buys from them.


The AOM foundation has spent millions on legal reviews. There is always a chance of something slipping through, but that could happpen with any technology. Someone unknown company could come forward with a claim that h.265 infringes on a patent.


Chrome leverages hardware decoding in general it just doesn't support h.265 at all, hardware or software.


Let's just say HEVC Patent Pools got greedy and demanded a per-software license, either paid by Windows (who decided not to pay) or by Chrome (who also decided not to pay).

https://hackernews.hn/reply?id=31318663&goto=item%3Fi...


The correct way to see this is probably that licenses have already been patented for the existing implementations, and dropping support for future ones means money saving.


I've yet to see any hardware decoder supporting AV1. And while you can decode with software, at the cost of using obscene amounts of CPU cycles for extended periods of time which not all devices are designed to sustain, forget about software encoding. Encoding is just not going to happen without a hardware accelerator.


The devices with hardware AV1 decoders have begun to appear this year.

For example the new Rockchip RK3588 (for cheap computers with ARM CPUs and for TV top boxes) has a 4k @ 60 fps hardware AV1 decoder and the new Intel ARC GPUs also have hardware AV1 decoders.

There are some new chips for smartphones that will have hardware AV1 decoders.

The NVIDIA GeForce RTX 30 Series GPUs have hardware AV1 decoders, but I have no experience with them, as the most recent NVIDIA GPU that I use is an older RTX 2060 Super.

It is not known yet for sure whether the next generation of AMD GPUs will have hardware AV1 deoders. If they would not have it, they would remain the only new GPUs without hardware AV1 decoders.


But if an application merely uses the graphic's drivers API to decode a stream, presumably the GPU vendor (and therefore the buyer) already paid for those licensing costs? Otherwise the hardware wouldn't support h265, right?


Right, but neither Google neither Mozilla wants to support it even if they don't need to pay a cent.


They'd both have supported it if the codec was offered freely to all users for any purpose.

But it wasn't, so they'd be letting the entire internet be held to ransom if they supported it.


That's actually not entirely clear to me. Which is another reason to avoid H265 altogether....

I mean, even if say Chrome started using the hardware decoders, do you think someone from the MPEG-LA would _refrain_ from suing Google since "they're just using the Windows API"? It's already not rare to have to pay both for the hardware _and_ the software in this world.


Perhaps there are software patents involved in the codecs and a license for those is different from the hardware ones


FFmpeg and VLC seem to use (lib)x265 for H.265 content.

Is a license also required if the x265 codec is used? Or does that depend on whether the software is for commercial use?


>FFmpeg and VLC seem to use (lib)x265 for H.265 content.

copypaste of previous comment:

The FFmpeg project does not distribute binaries with unlicensed or illegal code. E.g. if you want ffmpeg to use libdvdcss for decrypting DVDs or use libfdk-aac to encode aac/m4a without paying license royalties to Fraunhofer, the end user has to download those components and build a custom ffmpeg binary on their own. No legitimate website will host ffmpeg built with the "illegal/unlicensed" libraries. E.g. When the popular Zeranoe website hosted ffmpeg executables for download, it was only built with the free GNU components and was missing x265.

The VLC project says they can include libdvdcss because they are a French company instead of American. E.g. The USA-based Microsoft removes DVD playback from Windows 8 but France-based VLC does not: https://www.zdnet.com/article/if-vlc-can-ship-a-free-dvd-pla...


> When the popular Zeranoe website hosted ffmpeg executables for download, it was only built with the free GNU components and was missing x265

Not the case. See https://web.archive.org/web/20200916062932mp_/https://ffmpeg...


ffmpeg/x265 don't own the patents, so their license has no right to grant you them.

Beware that using ffmpeg/x265 may be illegal if you're in a country that recognizes software patents. You need to pay patent fees even if you wrote the software 100% yourself. You need to pay even if you independently invented the same algorithms later than the patent was filed.

To quote Carmack:

> "The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying."


This explains why browsers do not include their own software decoder, but they should not need a license to use the decoders provided by the host platform.


- Neither Linux nor Windows provide one, due to licensing costs

- Most browsers do not deem it worth the risk of relying on host software decoders, as the plug&play infrastructure behind them usually translates into "nobody feels responsible for patching anything" which translates into incalculable vulnerabilities

That leaves MacOS (why bother when Safari exists), iOS (dito), and Android (why bother when Android users don't spend money), and trying to use hardware codecs without stepping on patents enough to make lawyers smell blood (why bother).


Microsoft provides a separate h265 codec you can buy in the Microsoft store: https://www.microsoft.com/en-us/p/uitbreidingen-voor-hevc-vi...

Some hardware comes with the codec pre-purchased (my laptop does). I don't think I've ever heard of anyone buying a codec in the MS Store, though.

I think most Android phones come with HEVC support. Mine did, anyway; I suppose it's up to the vendor to choose if they want to support it. Apps like VLC will also play the codec just fine. My camera app even records in h.265. This is a phone from Xiaomi, which not exactly known for their great software packages and compatibility.

I'm pretty sure Safari already supports h.265 because Apple switched to HEIF pictures while the rest of the world still just uses JPEGs for everything, and HEIF is pretty close to a single h.265 frame packaged as a picture. Not even Apple would be so foolish to switch default formats on their mobile devices and not support it across their software products.

Browsers don't feel like paying license fees over downloads of their free products and I can't blame them. Mozilla's h.264 decoder is only published along with it because Cisco had reached the license fee cap (which doesn't exist for h.265) and they decided to use their license so that Firefox can play videos freely.

I think Apple and physical disks formats are the only players heavily invested in h.265 right now. AV1 hardware decoding support is slowly coming along, so soon enough everyone can just use AV1 and be free of the proprietary patent bullcrap.


Mobile support comes from the chips (SOC) that the phones are using. Hardware codec support is a major differentiating factor for mobile chips. It has a huge impact on power usage, e.g. decoding video or audio in hardware could be 10x more efficient.

It's common that the manufacturer doesn't actually get a patent license, they get "indemnity". If someone were to sue you, the chip manufacturer would handle it, because they have their own patents and have cross-licensed with the others in the pool. You may have to pay the chip manufacturer for the indemnity in addition to the chip costs, i.e. "paying protection money". "That's a nice restaurant you have there, it would be a shame if someone set it on fire. We can protect you from bad people like that."


> I think most Android phones come with HEVC support. Mine did, anyway; I suppose it's up to the vendor to choose if they want to support it.

The official requirements for Android phones can be found on the Android CDD (https://source.android.com/compatibility/cdd). From a quick look at the CDD for Android 12, section 2.2.2 says that the required codecs for encoding are "H.264 AVC" and "VP8", and for decoding are "H.264 AVC", "H.265 HEVC, "MPEG-4 SP", "VP8", and "VP9". So it seems that all Android 12 phones will come with HEVC decoding support, but not necessarily encoding support. Looking at past CDDs, it seems that "H.263" was required for encoding and decoding before Android 7.0, and "H.265 HEVC" was required for decoding starting with Android 5.0.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: