<p>I currently have a source video with the following properties:</p>
<pre><code>Stream #0:0: Video: h264 (High 4:4:4 Predictive), yuvj444p(pc, bt709/bt709/iec61966-2-1, progressive), 2560x1440 [SAR 1:1 DAR 16:9], 60 fps, 60 tbr, 1k tbn
</code></pre>
<p>I want to transcode it into the following formats after applying cuts and other effects:</p>
<ul>
<li>H.264 YUV444 (yuvj444p)</li>
<li>H.264 YUV420 (yuvj420p)</li>
<li>AV1 YUV444 10-bit (yuv444p10le)</li>
<li>AV1 YUV420 10-bit (yuv420p10le)</li>
</ul>
<p>However, except for the yuvj444p → yuvj444p transcode, the resulting files have significantly different colours than the original when played back. This seems to be because ffmpeg stripped the colour space information (to <code>unknown</code>) from the output files:</p>
<pre><code>$ ffmpeg -ss 1:00 -to 1:01 -i source.mkv -c:v libx264 -preset veryslow -pix_fmt yuvj444p -crf 16 x264-444.mkv
...
Output #0, matroska, to 'x264-444.mkv':
  Stream #0:0: Video: h264 (H264 / 0x34363248), yuvj444p(pc, bt709/bt709/iec61966-2-1, progressive), 2560x1440 [SAR 1:1 DAR 16:9], q=2-31, 60 fps, 1k tbn

$ ffmpeg -ss 1:00 -to 1:01 -i source.mkv -c:v libx264 -preset veryslow -pix_fmt yuvj420p -crf 16 x264-420.mkv
...
Output #0, matroska, to 'x264-420.mkv':
  Stream #0:0: Video: h264 (H264 / 0x34363248), yuvj420p(pc, unknown/bt709/iec61966-2-1, progressive), 2560x1440 [SAR 1:1 DAR 16:9], q=2-31, 60 fps, 1k tbn

$ ffmpeg -ss 1:00 -to 1:01 -i source.mkv -c:v librav1e -speed 9 -tiles 24 -pix_fmt yuv444p10le -qp 64 rav1e-444.mkv
...
Output #0, matroska, to 'rav1e-444.mkv':
  Stream #0:0: Video: av1 (AV01 / 0x31305641), yuv444p10le(unknown/bt709/iec61966-2-1, progressive), 2560x1440 [SAR 1:1 DAR 16:9], q=2-31, 60 fps, 1k tbn

$ ffmpeg -ss 1:00 -to 1:01 -i source.mkv -c:v libsvtav1 -preset 5 -svtav1-params tune=2:film-grain-denoise=0 -pix_fmt yuv420p10le -crf 16
...
Output #0, matroska, to 'svtav1-420.mkv':
  Stream #0:0: Video: av1 (AV01 / 0x31305641), yuv420p10le(unknown/bt709/iec61966-2-1, progressive), 2560x1440 [SAR 1:1 DAR 16:9], q=2-31, 60 fps, 1k tbn
</code></pre>
<p>I can fix it by passing <code>-colorspace bt709</code> to ffmpeg, but that relies on me already knowing the source video to be BT.709, so sounds error prone.<br />
<strong>Is there a way to have ffmpeg automatically preserve the source video's colour space?</strong></p>

CC BY-SA 4.0
2024-08-28T04:26:32.297Z
Which version? Recent versions should already do this.
Gyan
CC BY-SA 4.0
2024-08-28T06:39:05.447Z
ffmpeg 7.0.2-1 (specifically, 7:7.0.2-1 from debian testing)
小太郎
CC BY-SA 4.0
2024-08-28T15:14:21.397Z
I made this example file for another question, but also exhibits the same behaviour reported here when used as the source file: https://files.catbox.moe/q8oy1h.mp4
小太郎
<ffmpeg><transcoding><colorspace>
ffmpeg: How to preserve colour space automatically?
小太郎
# ffmpeg: How to preserve colour space automatically?

(Asked by: username_0 on 2024-08-27)

I currently have a source video with the following properties:
Stream #0:0: Video: h264 (High 4:4:4 Predictive), yuvj444p(pc, bt709/bt709/iec61966-2-1, progressive), 2560x1440 [SAR 1:1 DAR 16:9], 60 fps, 60 tbr, 1k tbn

I want to transcode it into the following formats after applying cuts and other effects:

H.264 YUV444 (yuvj444p)
H.264 YUV420 (yuvj420p)
AV1 YUV444 10-bit (yuv444p10le)
AV1 YUV420 10-bit (yuv420p10le)

However, except for the yuvj444p → yuvj444p transcode, the resulting files have significantly different colours than the original when played back. This seems to be because ffmpeg stripped the colour space information (to unknown) from the output files:
$ ffmpeg -ss 1:00 -to 1:01 -i source.mkv -c:v libx264 -preset veryslow -pix_fmt yuvj444p -crf 16 x264-444.mkv
...
Output #0, matroska, to 'x264-444.mkv':
  Stream #0:0: Video: h264 (H264 / 0x34363248), yuvj444p(pc, bt709/bt709/iec61966-2-1, progressive), 2560x1440 [SAR 1:1 DAR 16:9], q=2-31, 60 fps, 1k tbn

$ ffmpeg -ss 1:00 -to 1:01 -i source.mkv -c:v libx264 -preset veryslow -pix_fmt yuvj420p -crf 16 x264-420.mkv
...
Output #0, matroska, to 'x264-420.mkv':
  Stream #0:0: Video: h264 (H264 / 0x34363248), yuvj420p(pc, unknown/bt709/iec61966-2-1, progressive), 2560x1440 [SAR 1:1 DAR 16:9], q=2-31, 60 fps, 1k tbn

$ ffmpeg -ss 1:00 -to 1:01 -i source.mkv -c:v librav1e -speed 9 -tiles 24 -pix_fmt yuv444p10le -qp 64 rav1e-444.mkv
...
Output #0, matroska, to 'rav1e-444.mkv':
  Stream #0:0: Video: av1 (AV01 / 0x31305641), yuv444p10le(unknown/bt709/iec61966-2-1, progressive), 2560x1440 [SAR 1:1 DAR 16:9], q=2-31, 60 fps, 1k tbn

$ ffmpeg -ss 1:00 -to 1:01 -i source.mkv -c:v libsvtav1 -preset 5 -svtav1-params tune=2:film-grain-denoise=0 -pix_fmt yuv420p10le -crf 16
...
Output #0, matroska, to 'svtav1-420.mkv':
  Stream #0:0: Video: av1 (AV01 / 0x31305641), yuv420p10le(unknown/bt709/iec61966-2-1, progressive), 2560x1440 [SAR 1:1 DAR 16:9], q=2-31, 60 fps, 1k tbn

I can fix it by passing -colorspace bt709 to ffmpeg, but that relies on me already knowing the source video to be BT.709, so sounds error prone.
Is there a way to have ffmpeg automatically preserve the source video's colour space?

**Tags:** ffmpeg, transcoding, colorspace

> **Comments:**
> **username_1**: Which version? Recent versions should already do this.  
> **username_0**: ffmpeg 7.0.2-1 (specifically, 7:7.0.2-1 from debian testing)  
> **username_0**: I made this example file for another question, but also exhibits the same behaviour reported here when used as the source file: https://files.catbox.moe/q8oy1h.mp4  

---

## 0 answers

