<p><strong>Ad 1:</strong></p>

<p>Try adding the <code>-pix_fmt yuv420p10le</code> option (e.g. before <code>-vf)</code>. Or only <code>-pix_fmt +</code> for using the same pixel format as the input video has.</p>

<p>If it doesn't help, <em>you obviously have an inappropriate, albeit more common FFmpeg version — only for 8-bit colors.</em> (Your original video uses 10-bit colors, and FFmpeg will try use the best 8-bit pixel format in this case — with the colors' degradation, of course.)</p>

<p>FFmpeg may be built for 8-bit colors or for 10-bit colors, or — in recent time —  for both of them (for your HEVC encoded video). </p>

<p>So you need to build (or obtain by other way) version for 8-/10- or 10-bit color depth. </p>

<p><strong>Ad 2:</strong></p>

<p>Bitrate of <code>1700</code> is <em>very</em> low — only 1700 bits per second, i. e. about 212 bytes per second. </p>

<p>To reach such a low bitrate and at the same time reach your <code>23.98</code> frames per second, the encoder is limited with  average size for 1 frame about 212 / 24 = 9 bytes only! </p>

<p>Did you see a picture of such small memory? It has almost no information, so the gray image.</p>

<p>You probably wanted 1700k (Kilobits per second) — or, more probably — 170k:</p>

<pre><code>-b:v 170k
</code></pre>

<p>so correct your command in this way.</p>

<hr>

<p><strong>Addendum to Ad 1:</strong></p>

<p>You use the (default) 4:2:0 chroma subsampling (with inevitable color and contrast degradation).<br>
Try the maximum quality, i.e. 4:4:4 (no subsampling), or — if it will be sufficient for you — 4:2:2.</p>

<p>To reach this, use <code>-pix_fmt yuv444p10le</code> and change the video profile to main444-10 (with option <code>-profile:v main444-10</code>).</p>

CC BY-SA 4.0
2019-11-18T11:11:31.593Z
Thank you for all the very useful explanations. I tried with a compiled-from-source (with x265 enabled) version of `FFmpeg` and also with a packaged newer version. Even using (in both cases) `-pix_fmt yuv420p10le`, the problem is the same. Check out the error message I added in the question, if it is useful. Moreover, `FFmpeg` creates an `x264` output by default; how to preserve the original `HEVC` instead?
BowPark
CC BY-SA 4.0
2019-11-18T16:00:04.120Z
Use `ffmpeg -hide_banner -pix_fmts` to see if you have **yuv420p10le** pixel format in your build. If not, you build doesn't support 10-bit color depth. Add `-c:v libx265` to your commands for obtaining HEVC output. The error message appended into your question has nothing with your problems.
MarianD
CC BY-SA 4.0
2019-11-19T11:33:48.800Z
I am aware that this is very tricky. Anyway, you will find all the procedure I followed (and its results) in my updated question. The problem is still there, regardless of the output file using `yuv420p10le` format.
BowPark
CC BY-SA 4.0
2019-11-19T14:26:21.423Z
Try adding the option `-color_range pc` (for full color range 0 to 255 instead of 16 to 235 for TV).
MarianD
CC BY-SA 4.0
2019-11-19T15:13:27.873Z
Your input has a set of non-standard color parameters (`bt2020nc/bt2020/smpte2084`). Use the [colorspace](http://ffmpeg.org/ffmpeg-filters.html#colorspace) filter to convert to standard bt709. Color range is not relevant here, and low bitrates will degrade image color, but not the primary factor in this case.
Gyan
CC BY-SA 4.0
2019-11-19T16:15:32.673Z
@MarianD Unfortunately `-color_range pc` doesn't change the result.
BowPark
CC BY-SA 4.0
2019-11-19T16:17:27.423Z
@Gyan I edited the question with this new attempt. The video is still with "wrong" colors. However, note the `tv, bt709/unknown/unknown` in the output. Maybe also `colormatrix` and something else must be modified? I tried to add the option `-colormatrix bt709`, but this causes an error: `Unrecognized option 'colormatrix'.`.
BowPark
CC BY-SA 4.0
2019-11-19T16:19:01.593Z
The colorspace filter, not the option.
Gyan
CC BY-SA 4.0
2019-11-19T16:49:37.670Z
@Gyan Ok. I hope the syntax is correct: using `-vf "scale=1920:1080, colorspace=bt709"` produces an error: `[Parsed_colorspace_1 @ 0x560001239540] Unsupported input transfer characteristics 16 (smpte2084)
Error while filtering: Invalid argument
Failed to inject frame into filter network: Invalid argument
Error while processing the decoded data for stream #0:0`. The same even if I use only `-vf colorspace=bt709`.
BowPark
CC BY-SA 4.0
2019-11-19T17:04:22.197Z
I'll attend to this tomorrow.
Gyan
CC BY-SA 4.0
2019-11-21T06:59:29.883Z
See the update of my answer (**Addendum to Ad 1**).
MarianD
CC BY-SA 4.0
2022-01-17T05:35:56.330Z
[What should I do when someone answers my question?](https://video.stackexchange.com/help/someone-answers)
MarianD
CC BY-SA 4.0
2019-11-18T07:09:18.517Z
2019-11-21T10:49:22.113Z
2019-11-21T10:49:22.113Z
MarianD
<p>There is already a solution <a href="https://video.stackexchange.com/questions/32383/ffmpeg-vf-scale-shifts-colors-to-washed-out">here</a>. But I will try to summarize it in brief.</p>
<p>You need to specify the correct flags for color properties of the original file. Your original file (as probably many other files) has these properties: <code>yuv420p10le(tv, bt2020nc/bt2020/smpte2084)</code>. So you need to add the following arguments respectively: <code>-pix_fmt</code>, <code>-color_range</code>, <code>-colorspace</code>, <code>-color_primaries</code>, and <code>-color_trc</code>. The last four are just flags (those in parenteses), so if you encoded the file already, you do not need to do it again, just add the correct flags. Your arguments then should look like this:</p>
<pre><code>-c:v libx265
-pix_fmt +
-color_range tv 
-colorspace bt2020nc
-color_primaries bt2020 
-color_trc smpte2084  
-vf scale=1920:1080
</code></pre>
<p>As mentioned elsewhere, the color format property <code>-pix_fmt</code> with value <code>+</code> means &quot;use the same pixel format&quot;, but you can specify it manually: <code>-pix_fmt yuv420p10le</code>.</p>

CC BY-SA 4.0
2021-03-16T09:17:43.817Z
2021-03-16T09:28:05.547Z
2021-03-16T09:28:05.547Z
Tzamutzl
<p>I would like to resize a 4K mkv video to 1920×1080 with <code>ffmpeg version 3.4.6-0ubuntu0.18.04.1</code> on Ubuntu 18.04. The original file has the following features:</p>

<pre><code>Input #0, matroska,webm
encoder         : libebml v1.3.9 + libmatroska v1.5.2
Stream #0:0(eng): Video: hevc (Main 10), yuv420p10le(tv, bt2020nc/bt2020/smpte2084), 3840x2160 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 1k tbn, 23.98 tbc (default)
</code></pre>

<p>This version of <code>FFmpeg</code> may not support <code>x265</code>. I compiled a new version from the current <a href="https://ffmpeg.org/download.html#get-sources" rel="nofollow noreferrer">Git repository</a>, explicitly <a href="https://trac.ffmpeg.org/wiki/Encode/H.265" rel="nofollow noreferrer">enabling <code>x265</code></a>. Now, <code>ffmpeg -hide_banner -pix_fmts</code> has, in its output:</p>

<pre><code>FLAGS NAME            NB_COMPONENTS BITS_PER_PIXEL
-----
IO... yuv420p10le            3            15
</code></pre>

<p>This format should now be supported both for encoding and for decoding. I tried:</p>

<pre><code>ffmpeg -i original_file.mkv -c:v libx265 -pix_fmt + -vf scale=1920:1080 -colorspace bt709 -c:a copy test_output.mkv
</code></pre>

<p>This produces:</p>

<pre><code>Input #0, matroska,webm, from 'test_output.mkv':
  Metadata:
    ENCODER         : Lavf58.35.100
    Stream #0:0(eng): Video: hevc (Main 10), yuv420p10le(tv, bt709/unknown/unknown), 1920x1080 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 1k tbn, 23.98 tbc (default)
</code></pre>

<p>So, it is apparently ok. However, <code>test_output.mkv</code> colors still seem to be half the intensity of the original one, as if a grey layer was overlapped to the 4K video. I opened the file with both <code>vlc</code> and <code>mpv</code>, with no difference.</p>

<ol>
<li><p>How to preserve the original colors as much as possible?</p></li>
<li><p>If it is possible, I would also like to lower the bitrate, but my attempt</p>

<pre><code>ffmpeg -i original_file.mkv -s 1920x1080 -b 1700 output.mkv
</code></pre>

<p>produced a solid grey-only video with some moving squares.</p></li>
</ol>

<hr>

<p>I always get this message:</p>

<pre><code>[matroska,webm @ 0x55a5507ad100] Could not find codec parameters for stream 1 (Subtitle: hdmv_pgs_subtitle (pgssub)): unspecified size
Consider increasing the value for the 'analyzeduration' and 'probesize' options
</code></pre>

<hr>

<p><code>FFmpeg</code> built from source has the following configuration:</p>

<pre><code>ffmpeg version N-95768-gd831edc387 Copyright (c) 2000-2019 the FFmpeg developers
built with gcc 7 (Ubuntu 7.4.0-1ubuntu1~18.04.1)
configuration: --enable-gpl --enable-libx264 --enable-libx265
libavutil      56. 36.100 / 56. 36.100
libavcodec     58. 62.100 / 58. 62.100
libavformat    58. 35.100 / 58. 35.100
libavdevice    58.  9.101 / 58.  9.101
libavfilter     7. 66.100 /  7. 66.100
libswscale      5.  6.100 /  5.  6.100
libswresample   3.  6.100 /  3.  6.100
libpostproc    55.  6.100 / 55.  6.100
</code></pre>

<ffmpeg><video-quality><transcoding><mkv><scale>
FFmpeg does not preserve colors after resizing
BowPark
# FFmpeg does not preserve colors after resizing

(Asked by: username_0 on 2019-11-16)

I would like to resize a 4K mkv video to 1920×1080 with ffmpeg version 3.4.6-0ubuntu0.18.04.1 on Ubuntu 18.04. The original file has the following features:
Input #0, matroska,webm
encoder         : libebml v1.3.9 + libmatroska v1.5.2
Stream #0:0(eng): Video: hevc (Main 10), yuv420p10le(tv, bt2020nc/bt2020/smpte2084), 3840x2160 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 1k tbn, 23.98 tbc (default)

This version of FFmpeg may not support x265. I compiled a new version from the current Git repository, explicitly enabling x265. Now, ffmpeg -hide_banner -pix_fmts has, in its output:
FLAGS NAME            NB_COMPONENTS BITS_PER_PIXEL
-----
IO... yuv420p10le            3            15

This format should now be supported both for encoding and for decoding. I tried:
ffmpeg -i original_file.mkv -c:v libx265 -pix_fmt + -vf scale=1920:1080 -colorspace bt709 -c:a copy test_output.mkv

This produces:
Input #0, matroska,webm, from 'test_output.mkv':
  Metadata:
    ENCODER         : Lavf58.35.100
    Stream #0:0(eng): Video: hevc (Main 10), yuv420p10le(tv, bt709/unknown/unknown), 1920x1080 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 1k tbn, 23.98 tbc (default)

So, it is apparently ok. However, test_output.mkv colors still seem to be half the intensity of the original one, as if a grey layer was overlapped to the 4K video. I opened the file with both vlc and mpv, with no difference.

How to preserve the original colors as much as possible?
If it is possible, I would also like to lower the bitrate, but my attempt
ffmpeg -i original_file.mkv -s 1920x1080 -b 1700 output.mkv

produced a solid grey-only video with some moving squares.


I always get this message:
[matroska,webm @ 0x55a5507ad100] Could not find codec parameters for stream 1 (Subtitle: hdmv_pgs_subtitle (pgssub)): unspecified size
Consider increasing the value for the 'analyzeduration' and 'probesize' options


FFmpeg built from source has the following configuration:
ffmpeg version N-95768-gd831edc387 Copyright (c) 2000-2019 the FFmpeg developers
built with gcc 7 (Ubuntu 7.4.0-1ubuntu1~18.04.1)
configuration: --enable-gpl --enable-libx264 --enable-libx265
libavutil      56. 36.100 / 56. 36.100
libavcodec     58. 62.100 / 58. 62.100
libavformat    58. 35.100 / 58. 35.100
libavdevice    58.  9.101 / 58.  9.101
libavfilter     7. 66.100 /  7. 66.100
libswscale      5.  6.100 /  5.  6.100
libswresample   3.  6.100 /  3.  6.100
libpostproc    55.  6.100 / 55.  6.100

**Tags:** ffmpeg, video-quality, transcoding, mkv, scale


---

## 2 answers

### Answer by username_1 on 2019-11-18. Score: 1

Ad 1:
Try adding the -pix_fmt yuv420p10le option (e.g. before -vf). Or only -pix_fmt + for using the same pixel format as the input video has.
If it doesn't help, you obviously have an inappropriate, albeit more common FFmpeg version — only for 8-bit colors. (Your original video uses 10-bit colors, and FFmpeg will try use the best 8-bit pixel format in this case — with the colors' degradation, of course.)
FFmpeg may be built for 8-bit colors or for 10-bit colors, or — in recent time —  for both of them (for your HEVC encoded video). 
So you need to build (or obtain by other way) version for 8-/10- or 10-bit color depth. 
Ad 2:
Bitrate of 1700 is very low — only 1700 bits per second, i. e. about 212 bytes per second. 
To reach such a low bitrate and at the same time reach your 23.98 frames per second, the encoder is limited with  average size for 1 frame about 212 / 24 = 9 bytes only! 
Did you see a picture of such small memory? It has almost no information, so the gray image.
You probably wanted 1700k (Kilobits per second) — or, more probably — 170k:
-b:v 170k

so correct your command in this way.

Addendum to Ad 1:
You use the (default) 4:2:0 chroma subsampling (with inevitable color and contrast degradation).
Try the maximum quality, i.e. 4:4:4 (no subsampling), or — if it will be sufficient for you — 4:2:2.
To reach this, use -pix_fmt yuv444p10le and change the video profile to main444-10 (with option -profile:v main444-10).

> **Comments:**
> **username_0**: Thank you for all the very useful explanations. I tried with a compiled-from-source (with x265 enabled) version of `FFmpeg` and also with a packaged newer version. Even using (in both cases) `-pix_fmt yuv420p10le`, the problem is the same. Check out the error message I added in the question, if it is useful. Moreover, `FFmpeg` creates an `x264` output by default; how to preserve the original `HEVC` instead?  
> **username_1**: Use `ffmpeg -hide_banner -pix_fmts` to see if you have **yuv420p10le** pixel format in your build. If not, you build doesn't support 10-bit color depth. Add `-c:v libx265` to your commands for obtaining HEVC output. The error message appended into your question has nothing with your problems.  
> **username_0**: I am aware that this is very tricky. Anyway, you will find all the procedure I followed (and its results) in my updated question. The problem is still there, regardless of the output file using `yuv420p10le` format.  
> **username_1**: Try adding the option `-color_range pc` (for full color range 0 to 255 instead of 16 to 235 for TV).  
> **username_2**: Your input has a set of non-standard color parameters (`bt2020nc/bt2020/smpte2084`). Use the [colorspace](http://ffmpeg.org/ffmpeg-filters.html#colorspace) filter to convert to standard bt709. Color range is not relevant here, and low bitrates will degrade image color, but not the primary factor in this case.  
> **username_0**: @username_1 Unfortunately `-color_range pc` doesn't change the result.  
> **username_0**: @username_2 I edited the question with this new attempt. The video is still with "wrong" colors. However, note the `tv, bt709/unknown/unknown` in the output. Maybe also `colormatrix` and something else must be modified? I tried to add the option `-colormatrix bt709`, but this causes an error: `Unrecognized option 'colormatrix'.`.  
> **username_2**: The colorspace filter, not the option.  
> **username_0**: @username_2 Ok. I hope the syntax is correct: using `-vf "scale=1920:1080, colorspace=bt709"` produces an error: `[Parsed_colorspace_1 @ 0x560001239540] Unsupported input transfer characteristics 16 (smpte2084) Error while filtering: Invalid argument Failed to inject frame into filter network: Invalid argument Error while processing the decoded data for stream #0:0`. The same even if I use only `-vf colorspace=bt709`.  
> **username_2**: I'll attend to this tomorrow.  
> **username_1**: See the update of my answer (**Addendum to Ad 1**).  
> **username_1**: [What should I do when someone answers my question?](https://video.stackexchange.com/help/someone-answers)  

---

### Answer by username_3 on 2021-03-16. Score: 1

There is already a solution here. But I will try to summarize it in brief.
You need to specify the correct flags for color properties of the original file. Your original file (as probably many other files) has these properties: yuv420p10le(tv, bt2020nc/bt2020/smpte2084). So you need to add the following arguments respectively: -pix_fmt, -color_range, -colorspace, -color_primaries, and -color_trc. The last four are just flags (those in parenteses), so if you encoded the file already, you do not need to do it again, just add the correct flags. Your arguments then should look like this:
-c:v libx265
-pix_fmt +
-color_range tv 
-colorspace bt2020nc
-color_primaries bt2020 
-color_trc smpte2084  
-vf scale=1920:1080

As mentioned elsewhere, the color format property -pix_fmt with value + means "use the same pixel format", but you can specify it manually: -pix_fmt yuv420p10le.


---

