Live data from Hacker News

Google added HEVC support in Chrome

bitmovin.com

161–170 of 225 posts

Re: Google added HEVC support in Chrome

#161
post #46

Earlier quoted context omitted.

> It forces anyone who wants to decrypt (or encrypt) to write a full MP4 parser MP4 is seriously one of the easiest binary formats to parse, and even if you couldn't use an existing parser it would probably be the simplest part of whatever you were actually building.

> it would probably be the simplest part of whatever you were actually building Unless you've written a Widevine client, downloaded from DASH, parsed MP4, decrypted MP4 samples, then reassembled the decrypted fragments, then you're really not in a position to be making this claim. I have done all the above, and the MP4 parsing was by far the most difficult part of the process, and that includes parsing Protocol Buffe…

Back a while I tried to implement a MP4 demuxer, and I can kind of relate to that. The mdat box is sometimes an opaque blob and you need to parse the codec framing to split packets (fMP4 helps with this a bit), each codec has its own set of boxes, and the specs for each of them are paywalled...

Matroska/WebM is so much simpler and easier to parse, you can essentially abstract it away in a JSON-like DOM (obviously without loading 1GB of data into memory) and just get what you want, it's great.

Re: Google added HEVC support in Chrome

#163
post #98
post #85

Earlier quoted context omitted.

There may be more than one person posting on HN.

While true, I think it was illustrating the "damned if you do, damned if you don't" approach HN takes to Google in general.

Personally, I have no idea why people are so upset about WebM and AV1 and etc. Like sure, they're not necessarily God's gift to AV, but they're reasonable enough, and patent unencumbered. Google may be awful, but that doesn't mean the incentives can't align. I can tell you that my incentives are perpendicularly aligned with MPEG-LA's in this situation, so...

Re: Google added HEVC support in Chrome

#164

Earlier quoted context omitted.

I'm not sure how you think for-profit companies like Mozilla, Google or Apple would get away with shipping 'ha ha I tricked you!' patent circumventions to a billion people. It's not like Audacity. Keep in mind that Firefox AFAIK still relies on OS codecs for h264 because shipping it themselves is such a difficult proposition due to patents. And on Windows, if you want native HEVC or AV1 playback you have to buy it fr…

maybe i misunderstood, then. i thought that HEVC licensing was paid for by the hardware vendor, and hence acted as a broad tax even if you’re not using HEVC, or using GPUs in a HPC context, etc (and unnecessarily raises the barrier of entry to new HW vendors, etc). but if Windows users are individually paying those licenses, that’s probably not the case. i guess the worry then is that HEVC crowds out AV1/others, and…

There was a recent kerfuffle about Fedora removing support for hardware accelerated H.265 from their distribution of mesa because of threat of patent litigation. See https://www.phoronix.com/news/Fedora-Disable-Bad-VA-API. That would also seem to suggest that the OS has to pay royalties if it uses hardware acceleration. It seems pretty strange to me that the OS/library/driver has to pay royalties just to expose access to hardware, which is where the patented technology actually exists. But I also don't understand how a video codec can be patented in the first place. ¯\_(ツ)_/¯ IANAL.

Re: Google added HEVC support in Chrome

#165

Earlier quoted context omitted.

HEVC encoding is far more mature. Encoders are faster, of better quality, and hardware acceleration exists. Additionally, for video playback outside of a PC, HEVC support is ubiquitous, AV1 support is virtually unknown.

And -- universality of the playback. "Why don't people adopt Vorbis?" almost answers itself, "Where/on what devices are they going to play it?" Without looking -- does your Apple TV support X?

For the record, it seems like more and more devices are supporting Opus for general use cases. It seems to be the audio codec end game - at 16kbps it sounds as good to me as 64kbps mp3

Re: Google added HEVC support in Chrome

#166
post #16

No Widevine support so 1080p tops streaming; yay. It's supper frustrating in 2022 to need to switch to my Fire stick just to play UHD(R). Edit: Except with the Netflix windows app; it will do it.

that's why piracy is regaining currency - when you pay for DRM'd content, you're just paying money to be treated like a pirate. Better to be a pirate to start with :)

Re: Google added HEVC support in Chrome

#167
post #128
post #42

Earlier quoted context omitted.

Apple being the culprit doesn't surprise me. But didn't they back AV1 and AOM? So why are they causing this problem now?

Apple isn’t causing a problem in the manner you’re implying - they’ve been using those codecs for years at this point. All that’s happening here is chrome is adding support for an existing standardized format that is used by the general public in presumably sufficient amounts to warrant the complexity.

If Apple can stop using it to not proliferate it switching to AV1 by default and aren't doing it, then you can say they are part of the problem due to their size.

I.e. if you meant that Google went out of the way to enable it in Chrome because Apple users produce so much content with it (because of Apple), then Apple are causing a problem.

Compare it to someone who makes products that dump toxic waste in the environment when they are being used but due to their size others have to start dealing with it to interoperate instead of avoiding that. You can't say they aren't causing a problem.

When it comes to media codecs Apple were always very problematic, but I thought after them joining AOM something could improve.

Re: Google added HEVC support in Chrome

#168

Earlier quoted context omitted.

I think it's remarkable that the pirate scene has barely touched VP9 or AV1. We discussed this 2.5 years ago, nothing really has changed except there's more H.265 than before. https://news.ycombinator.com/item?id=19362098

I remember maybe ten years ago "real" pirates (from "the scene") thought that everything needed to be in rar format, and anything else was considered "p2p" and not as pure. They were also late with h264 and used xvid for far too long.

File size capped at 700mb to fit on cd's, bitrate be damned.

Re: Google added HEVC support in Chrome

#169
post #53
post #10

On one hand, that's great for anyone watching HEVC content in Chrome. On the other, I'd prefer to not see further adoption of HEVC and instead see increased deployment of VP9 and AV1 wherever possible. Let MPEG-LA and the other HEVC patent pools+holders... well I'll leave the rest to your imagination. Future looking, no one should even touch VVC/H.266. Unfortunately the above rant does not address the gap in hardware…

Did you tried to encode anything with av1? Even with a high end CPU it's just not feasible, I tried with ffmpeg and it was encoding a single digit fps per seconds. A video of just 10min would take many hours, on the other end h265 encoding is slow but doable. Edit: just retried on my laptop: 0.6fps with a 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz Using the lastest version of ffmpeg with the sample from the wiki:…

https://people.videolan.org/~unlord/SVT-AV1_BD-rate.png

This picture is a little old now but it should get across the point of why libaom isn't a meaningful speed test.

It can be set to go faster, but the default speed is only one notch faster than on this chart.

Re: Google added HEVC support in Chrome

#170
post #123

Earlier quoted context omitted.

Probably all comes down to ffmpeg not supporting av1 well. Pretty much everyone uses ffmpeg or a wrapper around ffmpeg like handbrake to encode. And my understanding is that ffmpeg implements an old and very slow and partially broken version of av1.

ffmpeg can also be built to link to libaom, and my package manager (Macports) does this by default. (Likewise, I think ffmpeg has its own H.264 and H.265 implementations, but also links to libx264 and libx265.) Does it really matter what ffmpeg's built-in implementation is like?

ffmpeg h265 implementation lacks support for alpha channel, and that is really important.
Post reply on HN