Opened 10 months ago

Last modified 3 weeks ago

#8862 reopened defect

Wrong color space selected

Reported by: airbete Owned by:
Priority: normal Component: ffplay
Version: git-master Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no


Summary of the bug + How to reproduce:

I recorded part of my screen with vokoscreenNG ( x264 / high-4:4:4 / Quality 0 ) where a static png image was displayed.

I then played the resulting mkv file (joined to this ticket) with mpv, vlc and ffplay and took a screenshot in each. Here is what I observed :

Original image == mpv == vlc != ffplay .

This is the screenshot with mpv (identical to vlc and the original):

And this is the screenshot with ffplay:

Clearly ffplay doesn't select the good color space. Also, when I load the clip into kdenlive (which uses ffmpeg/ffplay/ffprobe), I observe the same wrong colors in the clip monitor, project monitor and rendering.

Here are some additional info:

ffplay / ffprobe
Stream #0:0(eng): Video: h264 (High 4:4:4 Predictive), yuv444p(tv, bt470bg/smpte170m/bt709, progressive), 480x300 [SAR 1:1 DAR 8:5], 30 fps, 30 tbr, 1k tbn, 60 tbc (default)

[vf] [in] 480x300 yuv444p bt.601/bt.601-525/bt.1886/limited/display SP=1.000000 CL=mpeg2/4/h264
[vf] [out] 480x300 yuv444p bt.601/bt.601-525/bt.1886/limited/display SP=1.000000 CL=mpeg2/4/h264


The color_range=tv shown by ffprobe looks very strange to me.

Thank you

ps: My version of ffmpeg is ffmpeg-4.2.4-1.fc32.x86_64.rpm

Attachments (1)

vokoscreenNG.x264_q0_high.mkv (59.4 KB ) - added by airbete 10 months ago.

Download all attachments as: .zip

Change History (10)

by airbete, 10 months ago

comment:1 by Carl Eugen Hoyos, 10 months ago

Keywords: color space removed
Version: 4.2unspecified

Please test current FFmpeg git head (the only version supported on this bug tracker), please test with ffmpeg instead of ffplay and please provide your ffmpeg command line together with the complete, uncut console output to make this a valid ticket.

comment:2 by airbete, 10 months ago

Ok, I compiled the git head version and extracted a frame with

> ./ffmpeg -i vokoscreenNG.x264_q0_high.mkv -vframes 1 output.png
ffmpeg version N-98810-ga469d29c08 Copyright (c) 2000-2020 the FFmpeg developers
  built with gcc 10 (GCC)
  configuration: --enable-sdl
  libavutil      56. 58.100 / 56. 58.100
  libavcodec     58.101.100 / 58.101.100
  libavformat    58. 51.100 / 58. 51.100
  libavdevice    58. 11.101 / 58. 11.101
  libavfilter     7. 87.100 /  7. 87.100
  libswscale      5.  8.100 /  5.  8.100
  libswresample   3.  8.100 /  3.  8.100
Input #0, matroska,webm, from 'vokoscreenNG.x264_q0_high.mkv':
    encoder         : GStreamer matroskamux version 1.16.2
    creation_time   : 2020-08-22T12:37:13.000000Z
  Duration: 00:00:04.38, start: 0.000000, bitrate: 111 kb/s
    Stream #0:0(eng): Video: h264 (High 4:4:4 Predictive), yuv444p(tv, bt470bg/smpte170m/bt709, progressive), 480x300 [SAR 1:1 DAR 8:5], 30 fps, 30 tbr, 1k tbn, 60 tbc (default)
      title           : Video
    Stream #0:1(eng): Audio: vorbis, 44100 Hz, stereo, fltp (default)
      title           : Audio
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> png (native))
Press [q] to stop, [?] for help
Output #0, image2, to 'output.png':
    encoder         : Lavf58.51.100
    Stream #0:0(eng): Video: png, rgb24, 480x300 [SAR 1:1 DAR 8:5], q=2-31, 200 kb/s, 30 fps, 30 tbn, 30 tbc (default)
      title           : Video
      encoder         : Lavc58.101.100 png
frame=    1 fps=0.0 q=-0.0 Lsize=N/A time=00:00:00.03 bitrate=N/A speed=1.25x    
video:28kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown

The resulting output.png image is, to my surprise, perfect (no color degradation). In fact the same ffmpeg command with version 4.2.4 generates a perfect png too!

However, ffplay (git head version) still produce muddy and degraded colors. There is an unwanted color conversion that takes place somewhere...

comment:3 by Carl Eugen Hoyos, 10 months ago

Component: undeterminedffplay
Resolution: invalid
Status: newclosed
Version: unspecifiedgit-master

FFplay depends on an external library that we do not control, I am closing this ticket assuming it cannot be fixed in the FFmpeg codebase.

comment:4 by Balling, 10 months ago

The color_range=tv shown by ffprobe looks very strange to me.

Why? It is Color range: Limited indeed. It is correct. All video in the world is limited)) Except Dolby Vision profile 5 if it uses IPTPQc2... You can of course use pixel format of full range.

Last edited 3 months ago by Balling (previous) (diff)

comment:5 by Balling, 6 months ago

So, is this SDL library we are talking about? Maybe there is an open bug there? As I understand from Mediainfo output you should dequantize it, then use Matrix coefficients: BT.601 (different from BT.709) and then use BT.709 transfer function (the same as in BT.601) and then as ColourPrimaries are not sRGB but with the same white point D65, you need to colour manage it to display, that last step is broken, let me guess?

comment:6 by Balling, 3 months ago

As it turns out it does not support sRGB transfer on video too. Sigh. Like at all.

That is -color_primaries bt709 -color_trc iec61966_2_1 -colorspace smpte170m

What it looks like is happening here is that it cannot understand that it is BT.601 matrix!! Why? Well, we can force BT.709 matrix in mpv: gamma=srgb:colormatrix=bt.709:colorlevels=limited 2.mp4

where 2.mp4 is from issue #9167, that has gamma=srgb:colormatrix=bt.601:colorlevels=limited

and ffplay -i 2.mp4 -vf extractplanes=y is 120
ffplay -i 2.mp4 -vf extractplanes=u is 90
ffplay -i 2.mp4 -vf extractplanes=v is 201

and it will looks the same as in ffplay. Just saying.

Last edited 3 months ago by Balling (previous) (diff)

comment:7 by Balling, 2 months ago

Resolution: invalid
Status: closedreopened

Okay, so this is just a bug here.


So frame->colorspace == AVCOL_SPC_SMPTE170M (SMPTE 170M matrix) should force that mode, but it does not.

Also why AVCOL_SPC_SMPTE240M matrix uses BT.601?? It is a different matrix as derived from SMPTE 170M primaries (yeah, SMPTE 170M matrix is not derived from SMPTE 170M primaries, I know, confusing).
Obviously it is not primaries that define the matrix, even though it should be (not the case for JPEG (BT.601 a.k.a. SMPTE 170M matrix is derived from System M primaries ACTUALLY, see SMPTE 177 and but BT.709 is the default in JPEG, since that is used in the default sRGB, also not the case for DCI-P3 in BT.2020 matrix as Netflix uses).

I think we should try to fix that. Or at least deprecate ffplaying sYCC files...

Since they migrated to github I will try to open an issue there too.


ffplay -i vokoscreenNG.x264_q0_high.mkv -vf scale=in_color_matrix=bt601,format=gbrp
Last edited 8 weeks ago by Balling (previous) (diff)

comment:8 by Balling, 6 weeks ago

FFplay also does not support linear transfer. Yes, that is RGB, not R'G'B'. While mpv does. See samples in #6725.


comment:9 by Balling, 3 weeks ago

What we should do is force -vf scale=in_color_matrix=auto,format=gbrp! It will work even for SMPTE 240M matrix and BT.2020-ncl matrix! Of course for YCbCr pixel formats it will be double converted. Will not work for YCgCo, alas. Why, BTW? Please do not tell me it is fake protection.

Note: See TracTickets for help on using tickets.