Closed Vanilagy closed 1 year ago
Thanks for the nicely written GitHub issue. Ultimately this sounds like a Chromium bug, so I've pasted it here (sadly without such pretty markup).
Please star that issue for updates. Is this on Windows?
Yes, I'm on Windows 10.0.19043 Build 19043 using Chrome 106.0.5249.119 (64-bit).
I'm writing a video recorder using my own WebM muxer for my web-based game and am encountering color space mismatches (I'm using Chrome). I first try just normally creating my VideoFrame using
new VideoFrame(canvas, { timestamp: 1000 * time })
and then feeding that into a VideoEncoder runningvp09.00.10.08
.Here's how it should look:![image](https://user-images.githubusercontent.com/1696106/197341646-e571a396-8b21-4163-b6c5-9df099134c78.png)
But it looks like:![image](https://user-images.githubusercontent.com/1696106/197341652-0da48461-4c9b-4e20-93e8-6e7b272d8bb3.png)
As you can see, the greens are darker. I've encountered this issue before when recording my screen using OBS, and the culprit was the color space being set to 601 instead of 709. So, 601-encoded video was being decoded as 709, causing these apparently "telltale" darker greens. But, looking at my VideoFrame, this can't be:![image](https://user-images.githubusercontent.com/1696106/197341727-295fc1d7-edd6-4a6a-a23e-d19f138dacd3.png)
Nothing 601-esque here it seems. Okay, then I thought I could manually set the color space and also write the same settings directly into the WebM files. I now create the VideoFrame like this:
(different color space from the automatic one). Then, in the WebM header directly, I specify the Colour part of my video track Video options with:![image](https://user-images.githubusercontent.com/1696106/197341877-45e2a3a3-1244-419c-9be2-a1ae3eb1bbde.png)
Referring to this and this specification, this sets the matrix, transfer and primaries all to BT709 - exactly what I had specified in my VideoFrame. It now looks like this:![image](https://user-images.githubusercontent.com/1696106/197342470-a8b7dcd9-2329-47e6-bc60-aca7e58e7836.png)
Still, too dark. I verified the WebM color space changes by running my file through MKVToolNix:![image](https://user-images.githubusercontent.com/1696106/197342016-9c14c621-5c4f-47e8-9786-edb29cd61193.png)
Also, it has to be noted that these WebM color space changes are only being respected by Chromium (playing the .webm inside Chromium), and VLC and Windows' Movies&TV seem to be unbothered by the changes I make to the metadata.
Soooooooooo... what exactly is going on? What can I do about it? Am I encoding it wrong? Am I decoding it wrong?