1300170 - Wrong color matrix is used in BasicCompositor

Status: RESOLVED WONTFIX

(Core :: Audio/Video: Playback, defect, P3)

Description

[Gaston Crouton]

Attachment: Firefox vs Chrome on Youtube (Wrong colors vs Correct colors)

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:48.0) Gecko/20100101 Firefox/48.0
Build ID: 20160823121617

Steps to reproduce:

Hello,

I'm French (sorry for my bad English) and I noticed when I played videos on Dailymotion or YouTube, that colors are not correct.


Actual results:

You can see in the attached picture called "Firefox vs Chrome on Youtube (Wrong colors vs Correct colors).PNG", that the colors of a video are wrong with Firefox, compared to Google Chrome which is playing the video like the original, with correct colors.

Reds are darker that it shoud be with Firefox. But the problem is not only with Dailymotion or YouTube, but with every videos played in Firefox.


Expected results:

It's a problem of color matrix. The default color matrix used in HD video is Rec.709. The problem comes from a convertion of this color matrix in Rec.709 again.

The Rec.709 color matrix should be used to convert the YUV color space from the videos in RGB, but not convert the color matrix in Rec.709 again, and after convert YUV to RGB. It's redundant.

And the result of this are wrong colors with darker reds.

Comment 1

[Gaston Crouton]

Attachment: Original image.png

Here is a capture of a video with its original colors, zoomed in MS Paint.

I measured a red pixel to compare with the same pixel of the picture with wrong colors.

Comment 2

[Gaston Crouton]

Attachment: Image with color matrix converted to Rec.709 again.png

I converted the color matrix of the video in Rec.709 myself, to show you that it's really this problem.

The original video already used Rec.709 color matrix and convert the color matrix to Rec.709 again, results of wrong colors, with darker reds.

We see in the picture, the same capture than before, zoomed in MS Paint, but with the same problem of wronf colors that with Firefox.

I measured a red pixel to compare with the same pixel of the picture with original colors, and it looks darker. Colors are clearly wrong !

Comment 3

[Paul Adenot (:padenot)]

Gaston, thanks for the very detailed bug report !

Anthony, care to have a look ?

Comment 4

[Gaston Crouton]

Thanks Paul ! ;-)

Comment 5

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

Firefox output PC levels (range [0, 255]) where possible. The exception is that the nVidia D3D9 drivers only support TV levels [16, 235] so we have a choice between unaccelerated H.264 decode and PC levels. The remedy is to either:

* Upgrade to drivers that support PC levels
* Configure PC levels in the nVidia control panel

This is the background to what you're seeing. In order for us to understand the issue you're reporting, we'll need the graphics section from about:support as well as the "Stats for nerds" information from YouTube. It would also be helpful if you can set the URL field of this bug. We need all this information in order to reproduce the bug locally.

Comment 6

[Gaston Crouton]

Hello,

Thanks for your answer. But my graphic card is an ATI Radeon HD 4890 (a bit old, but still not bad).

But I didn't understand how I can display these "Stats for nerds" information. Maybe because my Firefox is in French. But I can't find anything like that in the "About:support" section.

Comment 7

[Gaston Crouton]

Attachment: stats YouTube.png

Is it this "Stats for nerds" ?

Here is the URL of the video : https://youtu.be/lBwvaHKTrgo

But as I said, the problem is for all videos played in Firefox, not only on YouTube and Dailymotion. When I open a video to read it in Firefox too.

Comment 8

[Gaston Crouton]

Attachment: stats video in Firefox.png

As you see, the problem of wrong colors is the same when I read a video with the player integrated in Firefox.

On this picture, I opened a video download from Dailymotion, instead of downloading it.

Comment 9

[Gaston Crouton]

Is is this that you want from "About:support" ?


Accélération graphique
----------------------

Fonctionnalités
Composition: Direct3D 11
Zoom/Panoramique asynchrones: aucun
Rendu WebGL: Google Inc. -- ANGLE (ATI Radeon HD 4800 Series Direct3D11 vs_4_1 ps_4_1)
Décodage matériel H264: No;
DirectWrite: false (6.1.7601.19061)
GPU 1
Actif: Oui
Description: ATI Radeon HD 4800 Series
ID du vendeur: 0x1002
ID du périphérique: 0x9460
Version du pilote: 8.970.100.3000
Date du pilote: 7-3-2012
Pilotes: aticfx64 aticfx64 aticfx64 aticfx32 aticfx32 aticfx32 atiumd64 atidxx64 atidxx64 atiumdag atidxx32 atidxx32 atiumdva atiumd6a atitmm64
ID du sous-système: 00000000
RAM: 1024

Diagnostics
AzureCanvasAccelerated: 0
AzureCanvasBackend: skia
AzureContentBackend: cairo
AzureFallbackCanvasBackend: cairo

Comment 10

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

Interesting. You are decoding in software which means you will be getting PC levels. You're asserting that you should be getting Rec.709 which IIUC is TV levels. We've had a number of complaints in the opposite direction.

Chrome could be giving you TV levels because they are using hardware decoding and we're not . A number of Radeon drivers are blacklisted due to crashes. I don't know if your GPU has updated drivers. Chrome uses D3D9 DXVA which doesn't give them control over PC vs TV levels. You could try disabling hardware decoding in Chrome in about:flags to see if you get the same result there.

Comment 11

[Gaston Crouton]

But I think I have the same problem on my notebook with a Nvidia GeForce GT 740M. I must verify.

With Chrome, the colors are only correct with YouTube, not Dailymotion. I must try when I read a video directly in the navigator. I will try your thing with "about:flags" too, if it works because it's a portable version.

I'll be back ! ^_^

Comment 12

[Gaston Crouton]

Attachment: Playing a video directly in the navigator Google Chrome.png

First, I played a video directly with the player integrated in the navigator Google Chrome. We can see that the problem of wrong colors is in the navigator when hardware acceleration is activated.

Colors are only correct with YouTube in this case.

Comment 13

[Gaston Crouton]

Attachment: Google Chrome settings.png

Then, I disabled hardware acceleration in Google Chrome. It didn't work with "about:flags", so I did it in the settings.

Comment 14

[Gaston Crouton]

Attachment: Dailymotion - without hardware acceleration.png

When I disable hardware acceleration in Chrome, it seams that PC levels are used. The picture is washed-out.

But on the other side, colors are correct.

Comment 15

[Gaston Crouton]

Attachment: Dailymotion - levels corrected - colors are correct.png

When I take the same capture and fix the RGB levels on VirtualDub, we can confirm that colors are correct.

Reds are not dark.

Comment 16

[Gaston Crouton]

But in Firefox, PC levels are not used. It's TV levels with wrong colors, like Google Chrome with the hardware acceleration.

Comment 17

[Gaston Crouton]

Attachment: Dailymotion on my notebook with Nvidia GPU - wrong colors in Firefox.png

I have the same problem of wrongs colors with Firefox on my notebook with Nvidia graphic card.


Here is the "about:support" section for this computer :

Accélération graphique
----------------------

Fonctionnalités
Composition: Direct3D 11
Zoom/Panoramique asynchrones: aucun
Rendu WebGL: Google Inc. -- ANGLE (Intel(R) HD Graphics 4600 Direct3D11 vs_5_0 ps_5_0)
Décodage matériel H264: Yes; Using D3D9 API
DirectWrite: false (6.1.7601.19061)
GPU 1
Actif: Oui
Description: Intel(R) HD Graphics 4600
ID du vendeur: 0x8086
ID du périphérique: 0x0416
Version du pilote: 9.18.10.3165
Date du pilote: 5-7-2013
Pilotes: igdumdim64 igd10iumd64 igd10iumd64 igdumdim32 igd10iumd32 igd10iumd32
ID du sous-système: 00000000
RAM: Unknown
GPU 2
Actif: Non
Description: NVIDIA GeForce GT 740M
ID du vendeur: 0x10de
ID du périphérique: 0x1292
Version du pilote: 10.18.13.5598
Date du pilote: 9-13-2015
Pilotes: nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um
ID du sous-système: 00000000
RAM: 2048
Diagnostics
AzureCanvasAccelerated: 0
AzureCanvasBackend: skia
AzureContentBackend: cairo
AzureFallbackCanvasBackend: cairo

Comment 18

[Gaston Crouton]

I think I was confused with TV and PC levels :-P 

I forgot that it's always PC levels on a computer. Not like TV which can switch with TV and PC levels.

Effectively, so on a computer, we can say that Firefox convert TV levels in PC levels with the videos.

Google Chrome do the same, but keep TV levels when hardware acceleration is disabled. OK ;-)

Comment 19

[Gaston Crouton]

So I begin to understand. It's maybe when it converts TV levels to PC levels that there is a mistake. Because it converts YUV in RGB with the Rec.709 color matrix, but because it doesn't recognize the flag in the video files.

Something like that. It converts the color matrix instead of keep keeping the original color matrix. It's like converting the color matrix again, as I said.

Comment 20

[Gaston Crouton]

My last sentence was strange ^_^ :

"Because it converts YUV in RGB with the Rec.709 color matrix, but because it doesn't recognize the flag in the video files."

Try without the 2nd because :-P :

"Because it converts YUV in RGB with the Rec.709 color matrix, but it doesn't recognize the flag in the video files."

Comment 21

[Gaston Crouton]

The second sentence isn't better -_- 

I correct :

"Something like that. It converts the color matrix instead of keeping the original color matrix. It's like converting the color matrix again, as I said."

It's not easy to speak English when we are French :-D

Comment 22

[Gaston Crouton]

Attachment: Safari - Dailymotion - Correct colors.png

I tested Dailymotion with the navigator Safari (an very old portable version) and colors are correct.

It's the first navigator which have correct colors with Dailymotion.

So the problem comes definitely from navigators.

Comment 23

[Gaston Crouton]

(In reply to Gaston Crouton from comment #2)
> Created attachment 8787735 [details]
> Image with color matrix converted to Rec.709 again.png
> 
> I converted the color matrix of the video in Rec.709 myself, to show you
> that it's really this problem.
> 
> The original video already used Rec.709 color matrix and convert the color
> matrix to Rec.709 again, results of wrong colors, with darker reds.
> 
> We see in the picture, the same capture than before, zoomed in MS Paint, but
> with the same problem of wronf colors that with Firefox.
> 
> I measured a red pixel to compare with the same pixel of the picture with
> original colors, and it looks darker. Colors are clearly wrong !

I think I understand why when I converted the color matrix, it was the same error with colors. Do you know VirtualDub and AviSynth ?

I used them for this convertion. But it wasn't really a convertion I Think. Just a flag. And normally, it's useless to use this flag when we convert the color space in YUV. Only to convert YUV to RGB. But with RGB, I couldn't reproduce this wrong colors.

And I read recently that VirtualDub only works with Rec.601 color matrix.

It's why I reproduced the wrong colors with this AviSynth script :

AviSource()
ConvertToYV12(matrix="Rec709")

But colors were correct when I choose Rec.601 :

AviSource()
ConvertToYV12(matrix="Rec601")

It's because VirtualDub works with Rec.601. So I understood ! When I used Rec.709 in this script, it's like a convertion of Rec.709 in Rec.601. But it doesn't change colors with Rec.601, because VirtualDub works with Rec.601 color matrix.

We can forgot all this about VirtualDub, because it can create confusion, even for me.


The only idea to retain is that I get these wrong colors when it was like a convertion of the Rec.709 color matrix to Rec.601.

So I suppose that the problem is simply that the wrong color matrix is used in Firefox.



I think that it's the Rec.601 color matrix that is used instead of Rec.709. Maybe I'm wrong, but it's my impression.

But it's weird, because I read that Firefox use Rec.709 color matrix. But the fact is that I have the same problem on my two computers with 2 different graphic cards (ATI and Nvidia).

Comment 24

[Gaston Crouton]

If I thought about that, it's because it wasn't logical for me that reds are darker after a convertion of the color matrix in Rec.709. Logically, when we convert Rec.601 to Rec.709, reds are brighter.

It's why I searched to understand. So the problem is that the video are played like it was a Rec.601 color matrix that is used.

Comment 25

[Gaston Crouton]

I noticed one difference on my 2 computers in the "about:support" of Firefox.


My descktop computer :

Rendu WebGL: Google Inc. -- ANGLE (ATI Radeon HD 4800 Series Direct3D11 vs_4_1 ps_4_1)
Décodage matériel H264: No;


My notebook :

Rendu WebGL: Google Inc. -- ANGLE (Intel(R) HD Graphics 4600 Direct3D11 vs_5_0 ps_5_0)
Décodage matériel H264: Yes; Using D3D9 API


With my desktop computer, the hardware acceleration is disabled, but it's enable with my notebook.

In the 2 cases, there are wrong colors.

Comment 26

[Gaston Crouton]

Attachment: Opera - Dailymotion - Wrong colors.png

I tested the navigator Opera on my notebook with Dailymotion and colors are wrong, but...

Comment 27

[Gaston Crouton]

Attachment: Opera - YouTube - Correct colors.png

... colors are correct with YouTube.

The results are very diversified :-P

But I can say one thing : it's possible to have good colors with Dailymotion and YouTube :-)

Dailymotion has correct colors with Safari and YouTube with Google Chrome and Opera ;-)

Comment 28

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

Jean-Yves - do we need to somehow plumb in the colour matrix?

Comment 29

[Jean-Yves Avenard [:jya]]

We can't do that at our end...

The buffers passed to layers are YUV buffers. The conversions can only be done there as the incorrect color range only occurs when converting to RGB.

Comment 30

[Jean-Yves Avenard [:jya]]

IIRC, roc had made some changes to automatically use Rec 709 for plain software conversion when required.
My guess is that the issues at hand are related to GPU images. not sure what can be done there.

Comment 31

[Gaston Crouton]

Thanks for your answer.

But I don't understand what is really the problem. The YUV color space should be converted to RGB with a Rec.709 color matrix.

And what is extacly the relation with the GPU ? If GPU is used, what is changing ?

Some navigators can decode the image with the good color matrix and lots of programs use the GPU to decode videos without any problem with color matrix (like Media Player Classic or Windows Media Player).

So why is there a problem with Firefox ?

Comment 32

[Gaston Crouton]

Attachment: Test with Media Player Classic.png

Here is a screenshot of the use of Media Player Classic with the same video that on Dailymotion.

The GPU is used too. But the colors are correct. The Rec.709 color matrix is used.

What's the problem ? ^_^

So it's possible !

Comment 33

[Jean-Yves Avenard [:jya]]

(In reply to Gaston Crouton from comment #31)
> Thanks for your answer.
> 
> But I don't understand what is really the problem. The YUV color space
> should be converted to RGB with a Rec.709 color matrix.
> 
> And what is extacly the relation with the GPU ? If GPU is used, what is
> changing ?

it's a different code path. For video accelerated playback (which is likely what you're using on windows), the GPU is used to decode as well as render to the screen. Firefox doesn't get involved much and there's no colour correction occurring.
It is known also that nvidia and amd drivers to behave differently on this matter.
With nvidia you need to set a global setting to use Rec 709.

> Some navigators can decode the image with the good color matrix and lots of
> programs use the GPU to decode videos without any problem with color matrix
> (like Media Player Classic or Windows Media Player).
> 
> So why is there a problem with Firefox ?
because I don't believe firefox has a concept of color matrix when not using software decoding or basic compositor

Comment 34

[Gaston Crouton]

> it's a different code path. For video accelerated playback (which is likely
> what you're using on windows), the GPU is used to decode as well as render
> to the screen. Firefox doesn't get involved much and there's no colour
> correction occurring.
> It is known also that nvidia and amd drivers to behave differently on this
> matter.
> With nvidia you need to set a global setting to use Rec 709.

I never saw a global setting in the Nvidia panel config to choose Rec.709. It's always the program which chooses I think.

But OK. I understand. But why Firefox couldn't use a renderer which recognize the color matrix ? Couldn't it be possible ?


> because I don't believe firefox has a concept of color matrix when not using
> software decoding or basic compositor

But the problem is the same with hardware acceleration. It seams that Firefox uses it on my notebook :

Rendu WebGL: Google Inc. -- ANGLE (Intel(R) HD Graphics 4600 Direct3D11 vs_5_0 ps_5_0)
Décodage matériel H264: Yes; Using D3D9 API

And so, this won't be corrected one day ? Because it's still a problem. Today, Firefox can't render the videos with correct colors. This is a fact !

I think one day it must be corrected ! It's the base with video decoding !


But I ask my question again : why some navigators can render the video with correct colors ?


Safari shows the good colors with Dalymotion, and Google Chrome and Opera with YouTube.

So I still believe it's somehow possible.

It just needs implication from Mozilla.

Comment 35

[Jean-Yves Avenard [:jya]]

I describe the *why* of the issue you're seeing today.
I've never stated that we couldn't fix it or work around specific video cards... So I'm not sure what you're on about. All I know is that it's typically not something exposed with Microsoft DXVA API.
Safari controls the entire chain with their own drivers, they also use non-public APIs.

Google Chrome and Opera gives you good colours with YouTube because by default they use VP9 software codec. Not hardware accelerated. Daily motion only serves H264, which would be HW accelerated with Chrome and Opera too, and so you will get inaccurate colours there. Again, that depends on the graphic cards you're using.

Set media.mediasource.webm.enabled to true in about:config, and you should be getting the same in Firefox (because your machine supports hardware h264, we prefer it over VP9 as it's better for battery life and CPU usage).
Won't fix dailymotion though.

That you didn't see a specific control with nvidia or amd cards doesn't mean it's not there. The settings is typically not shown on a laptop if you're using the laptop screen. But if connected to an external screen you should see it.

On my nvidia 965M laptop, connected to my TV, windows 10, I see it in NVIDIA Control Panel -> Video & Television -> Adjust video color settings -> Select "With the NVIDIA settings" -> Advanced tab -> Set Dynamic Range to "Full (0-255)".

AMD have a similar setting according to https://pcmonitors.info/articles/correcting-hdmi-colour-on-nvidia-and-amd-gpus/
Search for "The other problem – pixel format"
"When using HDMI, the default behaviour of AMD GPUs is not to use a ‘Limited Range RGB (16-235)’ signal like Nvidia GPUs, but rather to use a ‘YCbCr 444’ signal which is referred to by AMD as ‘YCbCr 4:4:4’. The use of ‘YCbCr 4:4:4’ compared to ‘Full Range RGB (0-255)’ has a slightly more pronounced effect on white point, contrast and measured colour values compared with on an Nvidia GPU. "

so you'll get different colours with AMD that nvidia by default.

Comment 36

[Gaston Crouton]

Ok. Goog explanation ! Thanks ! :-)

OK, I will try in the "about:config" this afternoon.


But if I change something in the control panel of my GPU, the problem is maybe that it will change everything with the others applications like Media Player Classic no ?

Comment 37

[Gaston Crouton]

Set "media.mediasource.webm.enabled" to true didn't change the wrong colors.

Comment 38

[Gaston Crouton]

I just want to add, that the HDMI output passes through the Intel HD chipset, and when I connect my laptop to my TV, I always have Full Range RGB selected.

I personally don't think it's related to that. I don't know why it should.

Comment 39

[Gaston Crouton]

The question is, how Mozilla can fix this problem ?

Comment 40

[Gaston Crouton]

Attachment: Firefox - YouTube - VP9.png

I tried with VP9 in Firefox, but same problem of colors.

Comment 41

[Gaston Crouton]

(In reply to Jean-Yves Avenard [:jya] from comment #35)
> I describe the *why* of the issue you're seeing today.
> I've never stated that we couldn't fix it or work around specific video
> cards... So I'm not sure what you're on about. All I know is that it's
> typically not something exposed with Microsoft DXVA API.
> Safari controls the entire chain with their own drivers, they also use
> non-public APIs.
> 
> Google Chrome and Opera gives you good colours with YouTube because by
> default they use VP9 software codec. Not hardware accelerated. Daily motion
> only serves H264, which would be HW accelerated with Chrome and Opera too,
> and so you will get inaccurate colours there. Again, that depends on the
> graphic cards you're using.
> 
> Set media.mediasource.webm.enabled to true in about:config, and you should
> be getting the same in Firefox (because your machine supports hardware h264,
> we prefer it over VP9 as it's better for battery life and CPU usage).
> Won't fix dailymotion though.
> 
> That you didn't see a specific control with nvidia or amd cards doesn't mean
> it's not there. The settings is typically not shown on a laptop if you're
> using the laptop screen. But if connected to an external screen you should
> see it.
> 
> On my nvidia 965M laptop, connected to my TV, windows 10, I see it in NVIDIA
> Control Panel -> Video & Television -> Adjust video color settings -> Select
> "With the NVIDIA settings" -> Advanced tab -> Set Dynamic Range to "Full
> (0-255)".
> 
> AMD have a similar setting according to
> https://pcmonitors.info/articles/correcting-hdmi-colour-on-nvidia-and-amd-
> gpus/
> Search for "The other problem – pixel format"
> "When using HDMI, the default behaviour of AMD GPUs is not to use a ‘Limited
> Range RGB (16-235)’ signal like Nvidia GPUs, but rather to use a ‘YCbCr 444’
> signal which is referred to by AMD as ‘YCbCr 4:4:4’. The use of ‘YCbCr
> 4:4:4’ compared to ‘Full Range RGB (0-255)’ has a slightly more pronounced
> effect on white point, contrast and measured colour values compared with on
> an Nvidia GPU. "
> 
> so you'll get different colours with AMD that nvidia by default.

Now I wonder about this. Why do you think it's the problem ?

It's not a problem of Limited Range RGB or Full Range RGB. Or I missed a step.

For me it's only a problem of color matrix !

Because I don't understand the link with the color matrix in this.

Comment 42

[Gaston Crouton]

Read this please ;-)

http://forum.videohelp.com/threads/329866-incorrect-collor-display-in-video-playback?p=2045830&viewfull=1#post2045830

Comment 43

[Gaston Crouton]

It's exactly my problem ! The videos on Dailymotion and YouTube look like the image on the left.

It's why I thought the wrong color matrix is used. I think that Rec.601 is used instead of Rec.709.

Comment 44

[Gaston Crouton]

Attachment: Comparaison Dailymotion vs YouTube vs Vidéo originale.gif

I did this GIF for the Dailymotion support.

But I will show you too, because the difference is more clear.

See how the reds are darker and greens more fluo.

Like the picture on the left :

http://forum.videohelp.com/attachment.php?attachmentid=4978&d=1294234370

Comment 45

[Gaston Crouton]

Attachment: Comparaison Firefox vs Media Player Classic.png

Here is the picture zoomed to compare.

Comment 46

[Gaston Crouton]

Do you see ?

It's a big difference ! :-P

Comment 47

[Gaston Crouton]

Attachment: Good vs Wrong.gif

This GIF is better ! ^_^

Comment 48

[Jean-Yves Avenard [:jya]]

(In reply to Gaston Crouton from comment #42)
> Read this please ;-)
> 
> http://forum.videohelp.com/threads/329866-incorrect-collor-display-in-video-
> playback?p=2045830&viewfull=1#post2045830

yes, interesting.. exactly what I've been saying all along:
"By switching it to "With the NVIDIA settings" and "Full (0-255)" it made the default renderer of VLC show the colors nicely."

now we need to find a way to do that without the user having to go and play with the graphic cards settings

Comment 49

[Gaston Crouton]

(In reply to Jean-Yves Avenard [:jya] from comment #48)
> (In reply to Gaston Crouton from comment #42)
> > Read this please ;-)
> > 
> > http://forum.videohelp.com/threads/329866-incorrect-collor-display-in-video-
> > playback?p=2045830&viewfull=1#post2045830
> 
> yes, interesting.. exactly what I've been saying all along:
> "By switching it to "With the NVIDIA settings" and "Full (0-255)" it made
> the default renderer of VLC show the colors nicely."
> 

OK. I understand now ;-)With this meaning I agree.

> now we need to find a way to do that without the user having to go and play
> with the graphic cards settings

I agree too :-P It's what I wanted do hear ^_^


Thank you very much !

Comment 50

[Gaston Crouton]

Do hou have news ? :-)

Comment 51

[Gaston Crouton]

"Do You have news ?" I wanted to say :-P

Thanks.

Comment 52

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

Bulk move of gfx-noted bugs without priority to P3 for tracking.

Comment 53

[Gaston Crouton]

What's new please ? :-)

What is planned ?

Comment 54

[Jean-Yves Avenard [:jya]]

Sotaro, is this something all your work on BT709 colorspace will fix?

Comment 55

[Sotaro Ikeda [:sotaro]]

(In reply to Jean-Yves Avenard [:jya] from comment #54)
> Sotaro, is this something all your work on BT709 colorspace will fix?

"webm + BT709 + colorspace tags" will be addressed by Bug 1210357.
"mp4 + BT709 + colorspace tags" will be addressed by Bug 1305906.

But the following video in comment 7 seems not have "colorspace tags". 
  > Here is the URL of the video : https://youtu.be/lBwvaHKTrgo
"mLib->av_frame_get_colorspace(mFrame)" returned AVCOL_SPC_UNSPECIFIED. If we want to handle the video color as BT709, we need to change default yuv color space to BT709. It is related to Bug 1305907.

Comment 56

[Jean-Yves Avenard [:jya]]

(In reply to Sotaro Ikeda [:sotaro] from comment #55)
> (In reply to Jean-Yves Avenard [:jya] from comment #54)
> > Sotaro, is this something all your work on BT709 colorspace will fix?
> 
> "webm + BT709 + colorspace tags" will be addressed by Bug 1210357.
> "mp4 + BT709 + colorspace tags" will be addressed by Bug 1305906.
> 
> But the following video in comment 7 seems not have "colorspace tags". 
>   > Here is the URL of the video : https://youtu.be/lBwvaHKTrgo
> "mLib->av_frame_get_colorspace(mFrame)" returned AVCOL_SPC_UNSPECIFIED. If
> we want to handle the video color as BT709, we need to change default yuv
> color space to BT709. It is related to Bug 1305907.

You would be using VP9 there isn't it ?

Didn't someone comment that all VP9 videos should default to BT709?

Comment 57

[Sotaro Ikeda [:sotaro]]

(In reply to Jean-Yves Avenard [:jya] from comment #56)
> You would be using VP9 there isn't it ?

Yes.

> 
> Didn't someone comment that all VP9 videos should default to BT709?

It might be Bug 1210357 Comment 19.

Comment 58

[Gaston Crouton]

Hello,

Are there news ? :-)

Comment 60

[Gaston Crouton]

Hi,

Do you think this problem will be solved soon ? :-)

Thanks !

Comment 61

[Janne]

I can reproduce this bug of color matrix. It seems to be a more general issue with browsers and html5. It is also a different issue from the Full vs. Limited scale and the difference is much more subtle. The following color bar videos can be used to diagnose:
Rec601: https://www.youtube.com/watch?v=SNMdYaY7RIo
Rec709: https://www.youtube.com/watch?v=IJUPC-zuDiM

If you play the Rec601 version, the bars have almost correct RGB values when played with the html5 player, but wrong values if Rec709 version is used. If, however, I change to flash player, then the situation is reversed: Rec709 is displayed properly while rec601 is not. To use the flash player, disable the following from about:config
media.mp4.enabled
media.webm.enabled

It seems that somewhere along the chain from Youtube backend to my screen, Rec601 is used to convert to RGB with html5 even if Youtube backend has the video with Rec709! 

To diagnose whether the issue is with the graphics card, I tried disabling and enabling the hardware acceleration from Firefox options, but it didn't change the playback. Also if I network stream the videos directly to VLC with hardware YUV->RGB conversion setting enabled, the Rec709 one plays correctly while the Rec601 one does not. Since the Firefox setting didn't change anything and VLC displays properly with hardware conversion, it doesn't seem to be an issue with Youtube backend or my Nvidia graphics card/graphics drivers.

Then the only thing left is the Firefox and the html5 player where it is my suspiction that Rec601 is used. The default html5 player also gives slightly different color results when compared to VLC or Windows Media Player.

Comment 62

[Sotaro Ikeda [:sotaro]]

(In reply to Janne from comment #61)
> I can reproduce this bug of color matrix. It seems to be a more general
> issue with browsers and html5. It is also a different issue from the Full
> vs. Limited scale and the difference is much more subtle. The following
> color bar videos can be used to diagnose:
> Rec601: https://www.youtube.com/watch?v=SNMdYaY7RIo
> Rec709: https://www.youtube.com/watch?v=IJUPC-zuDiM

Both streams does not have color matrix info in video stream. Therefore, browser side could not decide the color matrix. Then it just uses default color matrix.

Comment 63

[c319chris]

I've been working with video for 40+ years and you can't guess at these things. You need to use proper tools. You need a test pattern with known color values and something to measure them with such as Colorzilla, a free add-on for Firefox.

I have made two test patterns, one encoded with bt.601 and the other with bt.709.

https://www.youtube.com/watch?v=aDuRMw9vSfQ

https://www.youtube.com/watch?v=zDoK1qgLsi0

When Firefox plays them back, there are much bigger color errors on the 709 test pattern. The errors are +/- 2 on the 601 test pattern. That's as good as it gets in YUV encoding due to the floating-point calculations. This clearly suggests that Gaston is correct; whether using hardware or software decoding, Firefox is using 601 coefficients to decode the video. Firefox is using hardware decoding and my graphics card is an AMD Radeon HD 6450.

Inasmuch as sRGB is the web standard and uses bt.709 coefficients, Firefox should be using the bt709 coefficients. This is easily remedied with DXVA in Windows and VDPAU in Linux.

I do not ascribe these color errors to YouTube because a) the 601 video has colors that are within tolerance (+/- 2), and b) I get the same results playing the local file as on YouTube, so we can eliminate YouTube resampling or re-encoding as the source of color error.

Disabling the HTML5 player results in accurate colors on the bt.709 test pattern, but only when viewed on line using HTML5. There are still color errors when files are played on the local machine without HTML 5. The color errors are not confined to the HTML5 player.

In my test patterns, the values of the first six primary and secondary colors are supposed to be either 16 or 180. The bright magenta patch on the right is 255-0-255 to test the range of the graphics card.

These colors are measured on Firefox with the HTML5 player for the cyan patch:

Encoded with bt.709:
R=31 (error=15), G=197(error=17), B=180 (error=0)

Encoded with bt.601:
R=15 (error=1), G = 179(error=1), B = 179(error=1)

Original bmp colors:
R = 16, G = 180, B = 180

These colors are measured on Firefox with the HTML5 player for the bright magenta patch:

Encoded with bt.709:
R=235 (error=20), G=0(error=0), B=246 (error=9)

Encoded with bt.601:
R=255 (error=0), G=0(error=0), B = 254(error=1)

Original bmp colors:
R=255, G=0, B=255

Again, we are seeing much bigger errors in the 709 video than the 601. This leads me to conclude that non-standard bt.601 coefficients are being used to decode 709 video. This is contrary to the sRGB standard.

Here are the command lines used to encode the test patterns using ffmpeg:

ffmpeg -y -loop 1 -i test_patternnew601.bmp -t 10 -vf scale=out_color_matrix=bt601 test_patternnew601.mp4

ffmpeg -y -loop 1 -i test_patternnew709.bmp -t 10 -vf scale=out_color_matrix=bt709 test_patternnew709.mp4

Some encoders do not flag the video as bt.601 or bt.709. In the case of such ambiguity, the player should default to the standard bt.709. If a video was encoded with bt.601 coefficients, the user will simply have to live with the color errors.

I have had the opposite experience with VLC. Using hardware acceleration it plays back a bt.709 video with correct colors.

The selection of 709 or 601 color space is easily manipulated in Windows with DXVA (DirectX Video Acceleration) and with VDPAU in Linux.

https://msdn.microsoft.com/en-us/library/windows/hardware/ff564108(v=vs.85).aspx
==================================================================

https://en.wikipedia.org/wiki/SRGB

sRGB is a standard RGB color space created cooperatively by HP and Microsoft in 1996 for use on monitors, printers and the Internet, and subsequently standardized by the IEC as IEC 61966-2-1:1999.[1]

sRGB uses the ITU-R BT.709 primaries, the same as are used in studio monitors and HDTV,[2] and a transfer function (gamma curve) typical of CRTs. This specification allowed sRGB to be directly displayed on typical CRT monitors of the time, a factor which greatly aided its acceptance.

I was reviewing the bt.709 document. Viewable video is to occupy the range from 16 to 235. The values of 0 and 255 are reserved for sync. The ranges from 1 through 15 and 236 through 254 are allocated for "footroom" and "headroom" respectively, for overshoots. A well designed graphics card will display the entire range from 0 - 255 for computer video and 1 - 254 for "TV levels". Besides sRGB, bt.709 coefficients are standard for ATSC (American broadcast) video.

Please change the behavior of Firefox to the bt.709 coefficients by default, in compliance with the sRGB standard.

Comment 64

[Gaston Crouton]

The help of a professional is always welcome ! :-P Thank you very much for your help ! ;-)

Comment 65

[Gaston Crouton]

Hello,

Can we hope that this problem will be solved please ?

Thanks.

Comment 66

[c319chris]

Hi Gaston -

Thank you for fighting the good fight on this.

I have sent emails to Mozilla's Jeff Muizelaar, Anthony Jones and Sotaro Ikeda and so far nothing. Jeff does reply to my emails but says he doesn't have time and would only refer the issue to others at Mozilla, presumably Sotaro.

It doesn't seem like an insurmountable or particularly time-consuming undertaking to get Firefox, SeaMonkey, etc. to default to bt.709 coefficients, which are the sRGB standard. VLC player and Microsoft Edge default to bt.709 so Mozilla needs to get with it. IMO it's not asking too much for the Mozilla browsers to be standard-compliant.

https://www.w3.org/Graphics/Color/sRGB.html

It appears they have addressed the issue in VP9 but not in H.264 or H.265.

Comment 67

[Gaston Crouton]

Hello c319chris,

Thank you for your answer.

Yes, it should be easy for them to resolve the issue. But why is it taking so long time ? I don't know ^_^
Moreover, I think it's important. To watch videos in good conditions, it's the base !

Comment 68

[c319chris]

The Mozilla foundation solicits monetary donations. I would be willing to donate money but not until all of their video players across all platforms -- Firefox, SeaMonkey, Windows, Linux, Mac, with H.264 and H.265 -- default to bt.709 per the sRGB standard.

My money is probably safe for the foreseeable future.

Comment 69

[Gaston Crouton]

I agree ;-)

Comment 70

[c319chris]

There is some interesting code in the Firefox source file, gfx\thebes\gfxUtils.cpp, at lines 1154 and 1177:

  switch (aYUVColorSpace) {
  case YUVColorSpace::BT601:
    return rec601;
  case YUVColorSpace::BT709:
    return rec709;
  default: // YUVColorSpace::UNKNOWN
    MOZ_ASSERT(false, "unknown aYUVColorSpace");
    return rec601;
  }

https://dxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxUtils.cpp

Note that it defaults to rec601 if aYUVColorSpace is not explicitly defined as BT601 or BT709.

Inasmuch as sRGB is the formal standard for Internet graphics, it should default to rec709 which uses the coefficients used by sRGB. There is no logical reason for it to default to 601. Firefox should be standards compliant.

https://en.wikipedia.org/wiki/SRGB

https://webstore.iec.ch/publication/6169

I have not been able to determine if this has anything to do with DXVA (Windows DirectX Video Acceleration).

Comment 71

[Gaston Crouton]

Good work c319chris ! ;-)

Comment 72

[c319chris]

Hi Gaston!

I downloaded 9 GB of Firefox source code and changed the 601 default to 709. It didn't solve the color problem, though.

Firefox uses hardware acceleration for video playback (except for webm files) so you'd have to fix the DXVA code in Windows to default to 709, which is doable, and VDPAU in Linux.

Meanwhile, Microsoft Edge appears to correctly default to 709 and the colors are correct, so I think I'm going to give up on Firefox. SeaMonkey, Chrome, Chromium and Opera all have the same problem with colors.

I can honestly say I gave it a try. If you want to watch videos with correct colors, use Edge or even VLC.

Comment 73

[Gaston Crouton]

Thank you c319chris :-)

But I don't have Windows 10, so I can't install Microsoft Edge :-/

How can I change the DXVA code in Windows (I have 7) ?

Do you know an alternativ solution ?


Thank you ;-)

Comment 74

[Gaston Crouton]

Attachment: video VP9 - YouTube (Firefox 55).png

Hello :-)

I noticed that now, the color matrix is the good one with the VP9 format in Firefox (we can see that the squirrel is orange in the attached file). I don't know since which version of Firefox, but it's clear that it's good !

Comment 75

[Gaston Crouton]

Attachment: video MP4 - Facebook (Firefox 55).png

But with MP4, it's always the wrong color matrix as we can see in the attached file. It's a capture from the same video, but on Facebook.

So, the problem disappeared with VP9. Why ?
But not with MP4.

Why is it possible with the VP9 and not the MP4 please ? ^_^

Comment 76

[c319chris]

Hi Gaston -

Here are the colors I get with the test pattern encoded to vp9 on Firefox 55.0.1. This is a local file; no YouTube involved. Some colors are off by as much as decimal 9.

The white patch on the left should be 235-235-235. All other values should be either 16 or 180.

White 232-235-232
Yellow 178-180-22
Cyan 13-180-176
Green 14-180-21
Magenta 178-15-172
Red 179-16-16
Blue 14-15-171
Gray 177-180-177

Here is the same file on Chrome which also uses hardware acceleration. All colors are +/- 2.

White 233-234-233
Yellow 179-180-15
Cyan 14-179-179
Green 15-179-15
Magenta 179-15-179
Red 180-15-15
Blue 15-15-180
Gray 178-180-178

Chrome renders the colors accurately; Firefox does not.

Comment 77

[Gaston Crouton]

Hello c319chris,

Thanks for this test ;-) Yes, it's clearlt not very precise with Firefox :-/ We can see that particulary with the magenta and the blue.

I hope that it will be fixed in the future. For the MP4 format too.

Comment 78

[[github robot]]

Commit pushed to master at https://github.com/mozilla/balrog

https://github.com/mozilla/balrog/commit/d858985bf4320fc510d1c4c4c14dbf2ee3278d20
bug 1300170: Make page size selectable. (#414). r=bhearsum

Comment 79

[Paul Adenot (:padenot)]

Ben, wrong bug number on this one it seems.

Comment 80

[[e-mail] (:bhearsum)]

(In reply to Paul Adenot (:padenot) from comment #79)
> Ben, wrong bug number on this one it seems.

Yeah, sorry about that!

Comment 81

[Nguyen Trong Tuan]

Anthony, can you assign someone to work on this bug?

Only Firefox displays videos color wrong on my sRGB monitor, very irritating.

Comment 82

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

Does setting media.hardware-video-decoding.enabled=false fix the issue?

Comment 83

[Nguyen Trong Tuan]

No, it did not fix the issue regardless the value of "media.hardware-video-decoding.enabled".

Comment 84

[Nguyen Trong Tuan]

Attachment: Firefox 58.0.0.6520 vs Chrome 62.0.3202.89.png

Firefox 58.0.0.6520 (20171107220115) vs Chrome 62.0.3202.89

Comment 85

[c319chris]

"Does setting media.hardware-video-decoding.enabled=false fix the issue?"

No, but using the proper bt.709 coefficients, part of the sRGB standard, rather than the current bt.601 coefficients WILL fix the problem, a point I have made here more than once. You're grasping at straws asking users to fiddle with the hardware-decoding settings.

Comment 86

[adorn]

I tested the latest Firefox Nightly-Build (Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0)
with different h264-Videos on a Win7 x64 with Nvida-GPU and 
manually configured Nvida-Driver settings: Full-Range-Videoplayback (Not the Default TV-Range-Playback) 
It would be better if the Videoplayer/Firefox would signalize the right range.

The used colorspace and TV-Range are signalized in the h.264 picture/sequence parameter sets.(SPS/PPS)

All Videos have the same Color-Bar values:
White:255,255,255 Yellow:192,192,0 Cyan:0,192,192 Green:0,192,0 Pink:192,0,192 Red:192,0,0 Blue:0,0,192 Black:0,0,0 
(+-2 is still ok.)

Results: 
bt601 1280x720 50p 5000kbit: White:254,254,254 Yellow:194,179,0 Cyan:0,172,192 Green:0,162,0 Pink:205,30,198 Red:208,18,0 Blue:0,12,200 Black:0,0,0 (x)wrong Colorspace.
bt601 1280x720 50p 5000kbit: White:254,254,254 Yellow:194,179,0 Cyan:0,172,192 Green:0,162,0 Pink:205,30,198 Red:208,18,0 Blue:0,12,200 Black:0,0,0 (x)wrong Colorspace.
bt601 1280x720 50p 5000kbit: White:254,254,254 Yellow:194,179,0 Cyan:0,172,192 Green:0,162,0 Pink:205,30,198 Red:208,18,0 Blue:0,12,200 Black:0,0,0 (x)wrong Colorspace.
bt601 640x360 25p 1000kbit: White:254,254,254 Yellow:191,190,0 Cyan:0,190,189 Green:0,191,0 Pink:191,0,193 Red:192,0,0 Blue:0,1,192 Black:0,0,0 OK
bt601 512x288 25p 500kbit: White:254,254,254 Yellow:191,190,0 Cyan:0,190,189 Green:0,191,0 Pink:191,0,193 Red:192,0,0 Blue:0,1,192 Black:0,0,0 OK
bt601 480x270 25p 250kbit: White:255,255,255 Yellow:192,191,0 Cyan:0,191,190 Green:0,191,0 Pink:191,0,192 Red:191,0,0 Blue:0,1,192 Black:0,0,0 OK
bt601 320x180 12p 125kbit: White:255,255,255 Yellow:192,191,0 Cyan:0,191,190 Green:0,191,0 Pink:191,0,192 Red:191,0,0 Blue:0,1,192 Black:0,0,0 OK
bt709 1920x1080 50p 8000kbit: White:254,254,254 Yellow:190,189,0 Cyan:0,190,189 Green:0,190,0 Pink:191,0,193 Red:192,0,0 Blue:0,0,192 Black:0,0,0 OK
bt709 1280x720 50p 5000kbit: White:254,254,254 Yellow:191,191,0 Cyan:0,190,189 Green:0,191,0 Pink:191,0,193 Red:192,0,0 Blue:0,0,192 Black:0,0,0 OK
bt709 960x540 50p 1800kbit: White:254,254,254 Yellow:190,189,0 Cyan:0,190,189 Green:0,190,0 Pink:191,0,193 Red:192,0,0 Blue:0,0,192 Black:0,0,0 OK
bt709 640x360 25p 1000kbit: White:254,254,254 Yellow:190,203,7 Cyan:14,210,187 Green:14,224,4 Pink:176,0,186 Red:175,0,2 Blue:1,0,184 Black:0,0,0 (x)wrong Colorspace.
bt709 512x288 25p 500kbit: White:254,254,254 Yellow:190,203,7 Cyan:14,210,187 Green:14,224,4 Pink:176,0,186 Red:175,0,2 Blue:1,0,184 Black:0,0,0 (x)wrong Colorspace.
bt709 480x270 25p 250kbit: White:254,254,254 Yellow:190,203,7 Cyan:14,210,187 Green:14,224,4 Pink:176,0,186 Red:175,0,2 Blue:1,0,184 Black:0,0,0 (x)wrong Colorspace.
bt709 320x180 12p 125kbit: White:255,255,255 Yellow:191,204,9 Cyan:16,211,188 Green:16,224,6 Pink:176,0,186 Red:175,0,2 Blue:1,0,183 Black:0,0,0 (x)wrong Colorspace.
bt709 320x180 12p 125kbit: White:255,255,255 Yellow:191,204,9 Cyan:16,211,188 Green:16,224,6 Pink:176,0,186 Red:175,0,2 Blue:1,0,183 Black:0,0,0 (x)wrong Colorspace.

=> The SPS/PPS-Headers are ignored. 
=> Nvidia is guessing the colorspace: 960x540 and larger it uses bt.709 and for 640x360 and smaller it uses bt.601.
=> Intel-GPU allways using bt.601 
If you like to test: http://hr-a.akamaihd.net/test/colorspaceTest/videoplayer.html

Other Browsers: 
Safari does a good job on OSX and IOS
The latest Chrome Nightly-Build works well on Windows, but has wrong colors on OSX.
IE11 has some sometimes some issues, but in the most cases, it gets the right colorspace.

Comment 87

[Nguyen Trong Tuan]

VP9 videos (YouTube) now have the correct color matrix in Firefox 58, AFAICT. This is a great news.
MP4 videos (the rest of the Internet), however, are still in BT.601 in the latest Firefox Nightly.

I suggest we:
Read color space information from MP4 videos (probably bug 1237562), like Safari and Edge do. Firefox will then pass the color space test here (http://hr-a.akamaihd.net/test/colorspaceTest/videoplayer.html).
Untagged MP4 videos should be in BT.709 (probably bug 1423503), like Safari and Chrome do. This will resolve this bug.

Firefox may not have image and video color management at the moment (like Safari and Chrome do), but at least it should render contents correctly on my sRGB monitor, which is in standard color space.
Sotaro, any corrections? Can you help on this?

Comment 88

[Sotaro Ikeda [:sotaro]]

I looked into details of chromium implementation and found several problems around yuv color handlings and video decoding. I am going to address them. But I am very busy for another tasks now, then the priority of fixing them is low now, sorry about it.

Comment 89

[Nguyen Trong Tuan]

Attachment: bt601vonDV_1920x1080-50p-8000kbit.mp4

Comment 90

[Nguyen Trong Tuan]

Attachment: bt709vonAVCI_1920x1080-50p-8000kbit.mp4

Comment 91

[Nguyen Trong Tuan]

Attachment: bt709vonAVCI_1920x1080-50p-8000kbit (Untagged).mp4

Comment 92

[Nguyen Trong Tuan]

Nils, can you assign someone to work on this bug?

Comment 93

[NovarthaWoW]

First things first @Thomas Daede : Maybe this bug can also get attached to / added as dependency for meta bug 1459526? This one is old, refers to a similar issue and has quite some comments. ( Bug 1237562 is also on the same subject and maybe should be added to bug 1459526)

---

I just tested different configurations with the following system:

FF Developer Edition 76.0b5
Windows 10 x64 1909
AMD Radeon RX580
Latest AMD Driver 20.4.1

For the tests I used the colorspace website from Tuanese ( http://hr-a.akamaihd.net/test/colorspaceTest/videoplayer.html ). Left of the vertical bar (|) are the shortened results of the test website. On the right I manually checked the colors actually displayed on my screen. I did this in two ways:

1. I screenshoted the screen, pasted the content into MS Paint and used the color picker to get the RGB values of the bars.
2. I opened the videos in different tabs side-by-side and switched between them to check if they have the same color. I did that to rule out any errors due to copying and pasting the screen content.
   That check (MS Paint and judging by eye) was consistent and conclusive.

---

Without HW acceleration enabled in FF (about:support: Compositing Basic / HW_COMPOSITING disabled by user: Disabled by pref)
Results of test website:
bt601 1920x1080 50p 8000kbit: . OK | <-- Correct. Confirmed by manual inspection
bt601 1280x720 50p 5000kbit: .. OK |
bt601 960x540 50p 1800kbit: ... OK | <-- Correct. Confirmed by manual inspection
bt601 640x360 25p 1000kbit: ... OK |
bt601 512x288 25p 500kbit: .... OK |
bt601 480x270 25p 250kbit: .... OK | <-- Correct. Confirmed by manual inspection
bt601 320x180 12p 125kbit: .... OK |
bt709 1920x1080 50p 8000kbit: . (x)wrong Colorspace. | <-- Correct. Confirmed by manual inspection
bt709 1280x720 50p 5000kbit: .. (x)wrong Colorspace. |
bt709 960x540 50p 1800kbit: ... (x)wrong Colorspace. | <-- Correct. Confirmed by manual inspection
bt709 640x360 25p 1000kbit: ... (x)wrong Colorspace. |
bt709 512x288 25p 500kbit: .... (x)wrong Colorspace. |
bt709 480x270 25p 250kbit: .... (x)wrong Colorspace. | <-- Correct. Confirmed by manual inspection
bt709 320x180 12p 125kbit: .... (x)wrong Colorspace. |

---

With HW acceleration enabled in F (about:support: Compositing WebRender )
bt601 1920x1080 50p 8000kbit: . (x)wrong Colorspace. | <-- WRONG! The colors shown on the screen are correct!
bt601 1280x720 50p 5000kbit: .. (x)wrong Colorspace. | <-- WRONG! The colors shown on the screen are correct!
bt601 960x540 50p 1800kbit: ... OK | <-- Correct. Confirmed by manual inspection
bt601 640x360 25p 1000kbit: ... OK |
bt601 512x288 25p 500kbit: .... OK |
bt601 480x270 25p 250kbit: .... OK | <-- Correct. Confirmed by manual inspection
bt601 320x180 12p 125kbit: .... OK |
bt709 1920x1080 50p 8000kbit: . OK | <-- Correct. Confirmed by manual inspection
bt709 1280x720 50p 5000kbit: .. OK | <-- Correct. Confirmed by manual inspection
bt709 960x540 50p 1800kbit: ... (x)wrong Colorspace. | <-- WRONG! The colors shown on the screen are correct!
bt709 640x360 25p 1000kbit: ... (x)wrong Colorspace. |
bt709 512x288 25p 500kbit: .... (x)wrong Colorspace. |
bt709 480x270 25p 250kbit: .... (x)wrong Colorspace. | <-- WRONG! The colors shown on the screen are correct!
bt709 320x180 12p 125kbit: .... (x)wrong Colorspace. |

---

So my results summed up:

• Without HW-acceleration all videos are interpreted by Firefox to be bt601 and are rendered that way. bt709 is ignored and videos are erroneously decoded/rendered as bt601.
• With HW-acceleration all videos are decoded and rendered correctly on the screen. The colorspaces bt601/bt709 are checked on a per file basis, interpreted and handled correctly.
• When HW-acceleration is enabled there seems to be a mismatch between the colors actually shown on screen and the colors that are painted onto a Canvas in Javascript. (That's what Tuanese test website does: Play the video, draw a video frame onto a canvas and check the RGB values for each color bar of that canvas.) Using this method Firefox seems to fall back somewhere to the "stupid" algorithm of "SD videos are all bt601, HD videos are all bt709". Can anyone with a in-depth understanding of Firefox' rendering make any sense of that? Strangely without HW-acceleration FF is even more stupid ignoring the resolution entirely. With HW-acceleration the rendering to the Canvas at least tries to respect different colorspaces, but does it the easy way and gets it wrong sometimes. But the HW-accelerated decoder/renderer gets it right at the same time.

Comment 94

[Thomas Daede [:TD-Linux]]

Maybe file a separate bug for the canvas painting issue?

Comment 95

[Kelsey Gilbert [:jgilbert]]

New bug for the new investigation, please.

Comment 96

[Thomas Daede [:TD-Linux]]

It seems that BasicCompositor uses libyuv for conversion. Libyuv's source code has 3 color conversion functions in it - limited range 601, full range 601, and limited range 709. It should be possible to wire these up. It uses the rather archaic notations I420, J420, and H420 for these, respectively.

Comment 97

[c319chris]

601 is obsolete. It should have full-range 709 for completeness.

Comment 98

[Nils Ohlmeier [:drno]]

Declaring NI bankruptcy.