1237562 - h264 color spaces are not supported

Status: UNCONFIRMED

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

Description

[Vittorio Giovara]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:43.0) Gecko/20100101 Firefox/43.0
Build ID: 20151216175450

Steps to reproduce:

Open a h264 video with properly tagged color_matrix, transfer_charcteristic, color_primaires, the colors will not look correct.

This happens for bt709 and bt601 videos on any platform.


Actual results:

The output color does not match the original video


Expected results:

The output color should have matched the original video.

Comment 1

[Vittorio Giovara]

Attachment: example video

Comment 2

[Vittorio Giovara]

Attachment: how it looks

Comment 3

[Vittorio Giovara]

Attachment: how it should look

Comment 4

[Ralph Giles (:rillian)]

I can't tell if this is the embedded colour declaration (which we don't support) or the hardware decoder using video vs pc output levels (which is can't support, but nvidia's control panel has a pref).

Thanks for the report. Supporting colour-correction for video would be nice, be we don't have plans to implement it currently.

Comment 5

[Vittorio Giovara]

The hardware decoder gets it right on Windows, but that's about it. No matter of hw acceleration, it looks incorrect on OSX and Linux. I don't know if color range is involved, but the input video I tried all had tv/video level.

Comment 6

[Ralph Giles (:rillian)]

Maybe screenshot a standard testpattern, and measure the colour values vs what's expected, so we have some quantitative measure of the issue?

Comment 7

[Thomas Daede [:TD-Linux]]

Bug 1210357 has VP9 samples. Once this is fixed for VP9, it should also be easy to fix for H.264.

Comment 8

[Vittorio Giovara]

(In reply to Ralph Giles (:rillian) needinfo me from comment #6)
> Maybe screenshot a standard testpattern, and measure the colour values vs
> what's expected, so we have some quantitative measure of the issue?

Sorry for the delay, I don't have an exact test pattern, but you can generate correctly converted samples with this command line

for 30 fps videos (and multiples)
`ffmpeg -i input_tagged_bt709.mp4 -vf colorspace=all=bt601-6-525 -colorspace smpte170m -color_trc smpte170m -color_primaries smpte170m output_tagged_bt601ntsc.mp4`

for 25 fps videos (and multiples)
`ffmpeg -i input_tagged_bt709.mp4 -vf colorspace=all=bt601-6-625 -colorspace bt470bg -color_trc smpte170m -color_primaries bt470bg output_tagged_bt601pal.mp4`

Comment 9

[adorn]

We wrote a Test-Tool, to check the h264 colorspace support on different Browsers: 
http://hr-a.akamaihd.net/test/colorspaceTest/videoplayer.html

You can take videos from there, if you like. 
They have all the same colors but different resolutions and colorspaces.
The right colorspace signalized in the h.264 parameter sets.

On Win7 the behavior depends on the GPU: 
Intel uses only bt.601  

Nvidia is guessing the colorspace: 960x540 and larger it uses bt.709 and for 640x360 and smaller it uses bt.601.
Depending on the Nvidia-Driver-Settings the TV-Range does not match.

Comment 10

[Vittorio Giovara]

(In reply to adorn from comment #9)
> We wrote a Test-Tool, to check the h264 colorspace support on different
> Browsers: 
> http://hr-a.akamaihd.net/test/colorspaceTest/videoplayer.html

interesting, on OSX I get

firefox - bt601: ok, bt709: not ok 
chrome - bt601: not ok, bt709: ok
safari - bt601: ok, bt709: ok

I'll check your tool out more, thanks for sharing

Comment 11

[Vittorio Giovara]

the chrome and firefox difference is especially interesting since they should be using the same library (libyuv)

Comment 12

[adorn]

I think Firefox is ignoring the Colorspace-info in the SPS/PPS-Headers.

Without this Info Nvidia is guessing the colorspace: 960x540 and larger it uses bt.709 and for 640x360 and smaller it uses bt.601.
and Intel is allways using bt.601.

Chrome Canary has still wrong colors on OSX and Android. But it's working on Windows.