Live data from Hacker News

Google added HEVC support in Chrome

bitmovin.com

201–210 of 225 posts

Re: Google added HEVC support in Chrome

#201
post #182
post #175

Earlier quoted context omitted.

Presumably heif and/or hevc had an advantage when Apple adopted them as the default formats. Given they’re primarily on mobile devices it’s reasonable to assume there is hardware support. So switching to something else means battery life impact on everything else. What you are saying, is that because Google didn’t support a standard format that has been around, and in wide spread use, for years Apple should make all…

Today AV1 can be supported in hardware and is supported in all recent or upcoming SOCs and GPUs. So Apple have no excuse not to do it when they are even pouring tons of money into making and refreshing their own chips.

Cool.

Can you explain how a new or soon to be released device having hardware support for something adds hardware support to the last 9 years of devices apple has sold that still work with iMessage and Apple's Photos app? Or should Apple just break those because you have a personal bias against a standardized file format?

I guess Google and Android have demonstrated that supporting hardware after you've sold it isn't something that people actually care about so maybe you're right and apple should take the same approach - after all I'm sure breaking older hardware will result in sales, which is good for business.

Re: Google added HEVC support in Chrome

#202
post #157
post #120

Earlier quoted context omitted.

LAME is a really great example of why patents exist: the need to avoid the mp3 patents resulted in the development of technology that was superior to that covered by the mp3 patents. Do people really think LAME would have been developed if people were just reimplementing the existing mp3 encoder?

This is wrong in so many ways I'm not sure where to start. LAME was covered by the patents, so your whole idea is backwards and even if it weren't it's not supported by any evidence - there's just no relationship between patentability and how many encoders get implemented independently or not.

I had to wikipedia this - I would swear it wasn't, and that was apparently my incorrect interpretation 20+ years ago and has stuck with me since O_o

I'd edit my original comment to note it being false, but apparently I'm outside the HN edit window :-/

Re: Google added HEVC support in Chrome

#203
post #57
post #55

Earlier quoted context omitted.

For what it's worth, Intel & Netflix's AV1 encoder SVT-AV1 is extremely fast -- it changed my mind about what encoder rates are possible with AV1, to the point that I'm very happy with realtime CPU encoding.

I will try that because libaom was really slow.

libaom is the 'reference' encoder, it is built for correctness, not speed. rav1e and SVT-AV1 are built for speed.

Re: Google added HEVC support in Chrome

#204
post #118

Earlier quoted context omitted.

Surely that depends - is this a bunch of generic and vague detail-less patents, or do they provide the actual information required to implement the thing it purports to describe. The core problem with “software patents” in the US sense is that the patent office appear to grant them by default if they are vague, only accepts specific types of pre-existing evidence that they are not new or novel, and once a patent is g…

> at the same time I think that everyone on HN does believe that IP should exist, and people should have rights to what they create. Maybe, but I've never seen people protesting the idea that math can't be patented, and compression methods are pretty close.

You can't patent "pure math" but given that describes literally anything that it is possible to do on a computer, including simulating a physical device, we know that there is an intrinsic point where things go from "math" to something patentable.

The rationale for "you can't patent maths" is basically "you can't patent a fact".

Blanket anti-software patent people take a maximalist position: if it's a step of instructions it is maths, so should not be patentable. I think that is absolute nonsense, and it is an explicit statement that if you ever come up with anything idea, no matter how much it cost you to invent it, or develop it, it has zero value - because apparently the hard part of complex and new technology is writing code, not developing the technology in the first place. It also means you get some absurd results: the same invention would be patentable if you made a mechanical implementation, a purely electronic one, probably an ASIC, but probably not if it was an ASIC executing instructions from a builtin ROM. Because suddenly it becomes "math".

As I said originally, the problem is not patenting "software", it's that the idiocy of the US patent office means that you can make a patent document that has no information that can be used to implement the patent, and thus the patents are inherently open to abuse.

The core problem with software (and worse, process) patents is that they let you patent an idea, rather than an actual implementation of an idea, which is what physical object patents are required to do. The whole reason patents are public is so that the public can look at a patent, and use that document to implement the idea being patented, but if all you've done is patent the idea then all the public can do is see that you had an idea but didn't know how to actually build it (which is what patents are _meant_ to be for).

Re: Google added HEVC support in Chrome

#205

Earlier quoted context omitted.

What's the correlation between no widevine support and streaming resolution?

High resolutions like UHD require really high bitrates when encoded with H264, because H264 wasn't designed with such high resolutions in mind. HEVC/H265 improves upon its predecessor in this regard, so Netflix's edge hardware only keeps their UHD content encoded in HEVC/H265. If you request HD content, you're not only getting a different resolution, but also likely a different encoding scheme.

What streaming platforms will let you stream at 1080p without widevine? (or equivalent)

Re: Google added HEVC support in Chrome

#207
post #14

Earlier quoted context omitted.

Most older hardware has HEVC decoding but only the last few gens have AV1. My 10980XE is like 96% occupied while watching AV1 without HW acceleration so many smaller devices can't do anything resembling a smooth playback.

> My 10980XE is like 96% occupied while watching AV1 without HW acceleration That seems high. What resolution and frame rate is the video? And which decoder are you using? dav1d is a highly optimized software decoder so that's the one to try: https://code.videolan.org/videolan/dav1d/ It's used in Firefox, Chrome, ffmpeg, etc.

I tried it on some 8K HDR test video on YouTube on Linux/Firefox... All 18 cores and 36 threads at ~96%. NUC with an older Atom (7PJYH) gave like 0.1fps...

Re: Google added HEVC support in Chrome

#208
post #201
post #182

Earlier quoted context omitted.

Today AV1 can be supported in hardware and is supported in all recent or upcoming SOCs and GPUs. So Apple have no excuse not to do it when they are even pouring tons of money into making and refreshing their own chips.

Cool. Can you explain how a new or soon to be released device having hardware support for something adds hardware support to the last 9 years of devices apple has sold that still work with iMessage and Apple's Photos app? Or should Apple just break those because you have a personal bias against a standardized file format? I guess Google and Android have demonstrated that supporting hardware after you've sold it isn't…

Above was never about older devices. They can use H.264 and VP9 which have hardware support for years already. It was about newer ones. There isn't a need to ever use the toxic H.265.

Re: Google added HEVC support in Chrome

#209
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.

This'll be long-winded excitement to talk about the weird little community, but I think a lot of that depends on the circles you run in and the content you consume. There is surely a lot of low-effort GUI handbrake encodes online. But most of the """well-respected""" piracy groups put a surprising amount of effort into filtering and such to correct artifacts, both due to the compression and due to the source material…

Thank you for all these details! You confirm my suspicion, which is that the pirate scene has a lot of really valuable knowledge built up from years of using codecs in a very practical way.

Re: Google added HEVC support in Chrome

#210

Earlier quoted context omitted.

AV1 would be ideal to support. It is resource intensive for software, but with M2 MacBook Pros, for example and upcoming iPhone A17 processors, the AV1 decompression and compression codecs could be put in the hardware. AV1 reputedly is 30% more efficient than HEVC, important for a number of cases, such as more efficient use of bandwidth over cellular. For FaceTime over cellular Apple today uses the HEVC codecs if ava…

M2 doesn't have AV1 hardware decode. My guess is that the next shot is with a TSMC N3E chip, which _may_ debut with iPhone 15 Pro. There's been conflicting reports if N3E will be ready when Apple needs it - September 2023 if it's for iPhone 15. N3E based M3 Macbook Pro with hardware raytracing and hardware accelerated AV1 decode/encode would be nice.

No post body was provided.
Post reply on HN