Comment by jdashg | Hacker News Reader

Comment by jdashg | Hacker News Reader

Parent Full thread

I would say that much of it is actually solved in theory, just not in practice. (I.e. we know what it should display, but browsers get it wrong still) There are both outstanding issues with browsers being accidentally wrong/incomplete (e.g. both Firefox and Chrome have issues with full-range videos displaying incorrectly, just with different videos), and also with various implementations deviating from standards to "do the right thing" (though this is also a central dilemma of hdr display/tone-mapping).

There are definitely cases where it's clear what we (as browsers) are supposed to do, but some implementations have chosen to err on the side of user preference rather than correctness. I hope we can move that needle back towards "implement the specs". There's no good reason for any 601- or 709-marked content to display incorrectly in the year 2021.

Unfortunately, if you don't mark the videos, that's on you though. Fwiw Firefox generally does follow Chrome in inferring unmarked bt601/709 based on size: https://searchfox.org/mozilla-central/rev/1df3b4b4d27d413675...

Honestly I would rather issue warnings in these cases rather than silently guess.

It's been my experience that part of the reason browsers get stuff wrong even when it's clear what to do, is that entirely different teams work on parts of the browser that all need a poper color pipeline, and while one team will learn and do it correctly, the new team working on the diffrent part has to go through the same process again.

You can see this, for example in Firefox's image pipeline which seems to assume everything is 601 (because JPEG), and this means 709 AVIFs won't render correctly (and are thus off by default currently).

Or in Chrome, the MediaRecorder API will create HD H.264 streams that are untagged, and are 601. Which Chrome then assumes is 709 based off the res.

Or, also in Chrome, the WebCodecs team not having talked to the Media Team, seemingly (?) before starting work on what kind of buffer gets returned to the user, and what the semnatics of its color are. (I think this is resolved now, though - this was a year or two back when they engaged with VideoLAN over this API)

I probably shouldn't nitpick here, but Chrome's WebCodecs team is a subset of the Media team. Color simply wasn't the first priority to implement.

What has changed is that more functionality got pulled into WebCodecs as it became clear that existing web platform objects (eg. ImageBitmap) were not an ideal fit.

Honestly a big reason is that there simply aren't tests.

I miss the days when browsers took pride in announcing[1] their new version passed Acid2/Acid3. Sure, the tests had issues, but they were self contained and anyone could see which browsers mostly passed and which were missing half of the features. Unfortunately, the modern trend towards monopoly is increasingly hostile to ideas like "open standards" and "interoperability", so I doubt we'll see this kind of test used again anytime soon.

[1] https://en.wikipedia.org/wiki/Acid2#Timeline_of_passing_appl...

The modern equivalent is the Web Platform Tests[1], which are far more extensive than the Acid tests were. Browser conformance is tracked continuously[2].

[1] https://github.com/web-platform-tests/wpt [2] https://wpt.fyi/

The WPT is the exact opposite of what I was talking about. The interesting thing about the Acid tests isn't their utility as a conformance test. Sure, that's what the were, but even at the time the problems with the tests were well known. The features they tested were incomplete and somewhat arbitrary. Most browsers didn't even bolter trying to get the last 3 points on Acid3, which tested SVG fonts. I'm sure WPT is far more useful from a technical perspective.

Unfortunately, WPT is missing the actual feature that made the Acid tests interesting: a design that could be used and understand by anyone. Most people are not going to go do the incredibly complex work required to actually run the WPT tests (which apparently involves its own command line utility to manage the process, requires knowledge of python/pip/virtualenv, and understanding platform-specific documentation for both setting up and running the tests.

For Acid2/Acid3, anybody could simply load the test URL to run the tests themselves, on their own browser and OS, and see the results first-hand. It doesn't matter that most people didn't know the various CSS/Javascript/etc features being tested. Seeing that your browser completely failed Acid3 was obvious[1]. It was exciting to see for yourself if the latest browser update scored higher on Acid3.

[1] https://en.wikipedia.org/wiki/File:Acid3ie8rc1.png

If you want to run a specific wpt, you just load the URL. See https://wpt.live/ (which is linked to from the wpt.fyi bits).

But yes, if you want to run the full test suite and get overall results there's more work to do.

Reply on news.ycombinator.com