Hacker News Reader

Comment by bufferoverflow | Hacker News Reader

Looks great, but, unfortunately, it's not supported by any browser:

Doesn’t popularity and somewhat widespread usage have to come before browser adoption?

I'm pretty sure nearly every modern web technology came about because Google just wanted it, so they just implemented it. If Fabrice worked for Google we'd probably already be using it.

You can actually see this same pattern as far back as the 60's. When the most dominant player in the tech market adopts a technology, and it's not encumbered by patents or proprietary technology or something stupid like that, it becomes a de facto standard. (It helps when they actually standardize it, but it isn't necessary)

It's certainly true that large players have had large influences. Which modern web technologies do you have in mind that Google wanted and forced to exist? JPEG, GIF, & PNG didn't come from Google.

File a bug :)

I guess nowadays you could even shim this (if you've got many pictures and do do it correctly, trading bandwidth against user's CPU time).

But you lose hardware acceleration. On a mobile this can matter.

Maybe but I wouldn't be so sure. Mobile browsers today don't use JPEG hardware decoders and for a single frame HEVC isn't _that_ expensive to decode. I believe the argument is that hardware decoders are inconsistent (what you can decode successfully depends on what platform you're running on) and have high latency due to needing to pass the data back and forth to another chip in the system. For something like HEIF which also lets you store short videos as a replacement for animated GIFs you'd still want hardware decoding at least some of the time though.

The website claims

>Supported by most Web browsers with a small Javascript decoder (gzipped size: 56 KB).

56kb isn't particularly small, but for an image galary it might be worth it.

When some websites are 5mb after all ad.content is loaded. It's doesn't seem that much

It isn't the size that is the problem as much as that it is on the critical path for every image that uses it and that it does not support progressive rendering or rendering parts of the image as the file is downloaded. go to https://bellard.org/bpg/lena.html and set your browser to throttle to GPRS speeds and you will see a pretty huge difference.

It's unlikely they'll care: browsers which don't want to deal with HEVC licensing aren't going to touch it (likely preferring AVIF), and browsers which are fine with HEVC licensing support the conceptually similar HEIC.

Could someone expand on this?

What are HEVC, AVIF, and HEIC licensing and why are browsers partial to some over the others?

The most common video compression right now is h.264, which has to be licensed but isn't super onerous.

The newer, better version is called h.265 or HEVC. BPG is a way to use HEVC's single-frame encoding to store an image. HEIC is essentially the same thing, but supported by Apple.

HEVC has ugly licensing, causing a lot of companies to come together to make their own license-free video format called AV1. AVIF is the image format based on AV1.

So nobody wants to go near HEVC, and if they did they would support HEIC over BPG. AVIF might get support, if they think it will be used enough to be worth it.

HEIC is based on HEVC ( H.265 ), and therefore requires licensing and paying royalty before using it, most likely paid by Microsoft (Windows), Apple or any of your hardware manufacture. It could cost up to ( capped ) $100M per year for hardware manufacture. HEVC Advance Group has made software decoding royalty free. But you still have to paid MPEG Licensing and Velos Media. Because Apple and Microsoft likely has cross patent arrangement to most of the companies within the group, so it wouldn't matter much to them. But for everyone else, HEVC licensing is still a bag of hurt.

AVIF is based on AV1, by Open Media Alliance lead by Google, is royalty free. ( But not patent free, please don't mixed this up ) It is new and the spec has only been released for no more then 6 weeks. Google doesn't want to pay the licensing, especially when the initial licensing terms for HEVC include cost per streaming. All of Youtube video requires VP9 ( the predecessor of AV1 ) for 2K+ resolution, and does not and likely will not ever include HEVC.

Chrome does not support HEVC decoding even if you have hardware decoding. The same for Firefox. That is why the parent said BPG won't ever be included in browser, or Chrome and Firefox. M$ IE 11 / Edge and Safari both support HEVC.

So what? That's literally the reason to file. If you don't file it, and no one else files it because "it's unlikely they'll care" then good news: you're just perpetuating a pointless self-fulfilling prophecy.

Want them to care? File bugs. Have _everyone_ file bugs. Bug popularity and duplicate marking surfaces issues that need to be prioritised. File them for _all_ the big browsers, right now, before you take the time to respond to this comment: file them on https://developer.microsoft.com/en-us/microsoft-edge/platfor..., https://bugzilla.mozilla.org, https://bugs.chromium.org/p/chromium/issues/list, and https://bugs.webkit.org

He gets it.

They get nothing whatsoever. "Getting it" would at the very least mean checking the open bug trackers for existing issues, which there are, in all three (closed WONTFIX for Firefox and never even triaged for Webkit, Chromium's activity doesn't seem to go beyond triaging — all the issue having been created circa 2014~2015).

"Getting it" is not creating worthless busywork for maintainers by spamming their bug trackers with pointless issues — unless you're reporting to the black hole that is Apple's RADAR — it might be actually deciding to take on the issue, getting a hold of the relevant stakeholders and asking if and what it would take for this to be merged if you implemented it, and being ready to be told "no" and "nothing because it won't be".

No, I really do get it. Searching for a previous bug is part of filing, and you're talking about bugs that were filed three or even four years ago - so back when none of the current browsers were anything remotely like what they are today. As such, you (and others) should refile them going "these were marked wontfix 3~4 years ago but the spec and adoption has changed since then, please reconsider implementing this". I lost track of how many specs had to go through that.

This is not "busywork for maintainers", that is how updating specs work. You WONTFIX a spec when it's too early, and then people can refile once the spec's been reworked, made usable, etc. If your project is the size of a browser, the number of issues you immediately close rivals or even eclipses the number of issues you actually work on - it's why you have weekly/daily triage sessions to go "what's now in our bin since last triage? dupe dupe wontfix dupe assign request-for-clarification wontfix, done let's get to work"

I work for one of these companies, pretty sure I have at least a decent idea what I'm talking about. We WONTFIX specs that are too drafty, and then one or even more years later, you refile an implementation issue because the world has changed, and what was WONTFIX in the past, is now worth doing.

Reply on news.ycombinator.com