-
Notifications
You must be signed in to change notification settings - Fork 136
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HDR support #384
Comments
The values are aligned with the H.273 spec, but HDR and WCG are/were out of scope for WebCodecs v1. The primary blocker at this time is lack of HDR |
Re: Canvas HDR, the Color-on-the-web CG is tracking that deliverable with a strawman here. Lets use this issue to track the WC spec work. Off the top of my head, we want:
@sandersdan, what else? |
Those are the most important; we'll also need to update the relevant codec registrations, and verify that the codec and format detection APIs are sufficient. |
ProposalThis covers the most basic changes required to support HDR and WCG video in WebCodecs. This is becoming feasible to implement in Chrome as the infrastructure for Pixel Formats
The above list excludes:
AlternativelyIf we add a new
Color Primaries
Transfer Functions
The above list excludes:
Matrix Coefficients
The above list excludes:
HDR MetadataI am not currently proposing any HDR metadata. Typically HDR metadata includes per-frame light levels and the mastering color volume. I am uncertain about the future-compatibility of current ways of expressing this metadata, and have been told that it’s not a trusted input to tonemapping anyway. |
Thanks @sandersdan. I suggest seeking input from Color on the Web CG, which has a good number of HDR experts, and developed the HDR |
Do we even need the 16bit formats if we have a depth field? Wouldn't they just be I420, I420A w/ depth=16? |
They could be, but I think that is a compatibility hazard. The 16-bit formats are all binary-compatible but the 8-bit formats are not, and existing code would not be expecting these new formats under the existing names. |
I'm not sure that's a practical compatibility issue since you can't decode HDR w/ WebCodecs today, you'd have to go through a video element to VideoFrame which I suspect has fairly limited usage (if not nonexistent, especially with HDR content) |
FYI, some early user of the Canvas HDR spec wanted to use it for editing PQ video, and, to match rendering between a canvas and a video, they needed to specify HDR metadata. We've added a CanvasSmpteSt2086Metadata option when configuring HDR to allow further experimentation here. It strikes me that we will probably want to query this information from a video stream (and it may be that WebCodecs and Canvas should want to use the same type here). |
Thanks Chris, I think we can use |
Editor's call: Prefer explicitly including depth on pixel format since its what all other platforms do and since there's not too many of them. Open to strong reasons for depth. |
As described in w3c/webcodecs#384 (comment) Bug: 1297346 Change-Id: I80fc8dee177a43437587bfad49b1b0afa84fc46a Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3914160 Reviewed-by: ccameron chromium <ccameron@chromium.org> Reviewed-by: Dale Curtis <dalecurtis@chromium.org> Commit-Queue: Dan Sanders <sandersd@chromium.org> Cr-Commit-Position: refs/heads/main@{#1061260}
Video Color Space Interface currently supports SD (BT.601) and HD (BT.709), but not PQ and HLG. Syntax-wise, it seems that the values are taken from x264 colorimetry command line parameters. I would suggest using values defined in the CICP spec (see H.273 sec 8.1-8.3). Alternatively, the list of x265 colorimetry command-line parameters will contain the necessary human-readable values.
Also, how can we support backwards-compatible HDR dynamic metadata such as DolbyVision profiles 8.x and Samsung HDR10+? In both cases the underlying stream is a perfectly valid HDR10 stream while additional metadata from either one is used to enhance the experience. This way a single stream can be decoded as HDR10, DolbyVision, and HDR10+ by different decoders.
The text was updated successfully, but these errors were encountered: