HN user

rwxsh

21 karma
Posts0
Comments8
View on HN
No posts found.

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.

Project leaders from Ffmpeg, Google, Mozilla, Microsoft (and probably Nvidia and AMD) need to all get together and decide on a single method.

Speaking non-officially as a browser implementer, VUI isn't always reliable as a source of color, both because the encoders don't always know, and the decoders don't always extract it reliably. The container is a more reliable place to put it (eg. MP4 'colr' box).

Browsers do differ in behavior when these sources of metadata differ. It currently looks likely that WebCodecs will require implementations to use app-provided color metadata over in-band metadata, which would be good for interoperability!

Firefox 70 7 years ago

You think this affects video decoding?

Speaking for Chrome's implementation, efficiently rendering video on macOS does require CALayer compositing, but it's not sufficient.

Only certain types of decoded frames can be efficiently scanned out (different from the types that can be used efficiently in OpenGL compositing). Actually entering the most efficient fullscreen video mode requires some magic. Matching macOS behavior exactly when a fallback to OpenGL compositing is required can be difficult (eg. colorspace bugs can result in flickering).

I have not looked at the new code in Firefox, but I would expect that not all of the benefit would be realized in a first release. In any case it's a huge undertaking to support a single platform; congrats to the team for making it happen!