<p>I followed up on the <code>yuv420p(tv, bt709)</code> portion of the encoding and discovered that this refers to the <a href="https://en.wikipedia.org/wiki/Rec._709" rel="nofollow">Rec. 709</a> colorspace for HDTV. In ffmpeg, colorspace is defined by the <a href="https://ffmpeg.org/ffmpeg-filters.html#colormatrix" rel="nofollow">colormatrix filter</a>. However, you must convert <em>from</em> some colorspace. According to <a href="http://ffmpeg-users.933282.n4.nabble.com/convert-from-bt601-to-bt709-td4665658.html" rel="nofollow">an ffmpeg mailing list conversation</a>, the default colorspace is assumed to be <code>bt601</code>:</p>

<blockquote>
  <p>ISTR that if you give ffmpeg RGB it assumes its full range, it also by
  default converts using 601 matrices. Although it has a number of
  colourspaces defined which can be accessed in the libs using the API,
  ffmpeg itself makes no use of them (Although I have a nagging feeling
  that that may not be completely true anymore either).</p>
</blockquote>

<p>So the final ffmpeg command that worked was:</p>

<pre><code>ffmpeg -y -start_number 0101 -i \\path\to\filename.%04d.dpx
-vf colormatrix=bt601:bt709 -pix_fmt yuv420p sample.mp4
</code></pre>

<p>The color is now correct, but there is no discernible difference in <a href="https://gist.github.com/kwill/088afc643ea9d93fa2a0019db12487fa" rel="nofollow">the output from ffprobe</a> or MediaInfo. (In other words, the colorspace of the ffmpeg-generated file does not appear in the output.)</p>

CC BY-SA 3.0
2016-07-19T18:32:03.740Z
Add `-colorspace 1` to tag the output.
Gyan
CC BY-SA 3.0
2016-07-20T08:57:28.597Z
@Mulvya great! is there a "tag everything" option? (I couldn't find one)
lofidevops
CC BY-SA 3.0
2016-07-19T12:44:57.200Z
2016-07-19T12:44:57.200Z
lofidevops
<p>Recent patches to ffmpeg fixed this issue <a href="https://github.com/FFmpeg/FFmpeg/search?q=dpx&amp;type=commits" rel="nofollow noreferrer">https://github.com/FFmpeg/FFmpeg/search?q=dpx&amp;type=commits</a></p>
<p>It now reads range, primaries, matrix and transfer. Not to mention SMPTE timecode and alternate framerate.</p>
<p>There is still a bug that it writes linear transfer on all files.</p>

CC BY-SA 4.0
2021-04-05T21:13:02.703Z
2021-05-15T12:48:08.887Z
2021-05-15T12:48:08.887Z
Валерий Заподовников
<p>We are converting a sequence of DPX files into an MP4. When the artist uses Adobe Media Encoder CC to generate the video, the colors match the original DPX. When we use ffmpeg, the video has a reddish hint. The command used is:</p>

<pre><code>ffmpeg -y -start_number 0101 -i \\path\to\filename.%04d.dpx -pix_fmt yuv420p sample.mp4
</code></pre>

<p>How can we generate a video that matches the color of the original DPX files?</p>

<hr>

<p>Inspecting the files with <code>ffprobe</code> revealed the following differences (correct file/bad file):</p>

<ul>
<li>major_brand: mp42 / isom</li>
<li>minor_version: 0 / 512</li>
<li>compatible_brands: mp42mp41 / isomiso2avc1mp41</li>
<li>encoder: not listed / Lavf57.34.102</li>
<li>Video: h264 (Main) / h264 (High)</li>
<li>Video: yuv420p(tv, bt709) / yuv420p</li>
<li>Video: 1920x1080 / 1920x1080 [SAR 1:1 DAR 16:9]</li>
<li>handler_name: Alias Data Handler / VideoHandler</li>
</ul>

<p>Probe references: <a href="https://gist.github.com/kwill/a6e8df2268d6e09e20c2e31f18081e13" rel="nofollow">dpx</a>, <a href="https://gist.github.com/kwill/832da451eab85d7d55eb737840629d0f" rel="nofollow">correct</a>, <a href="https://gist.github.com/kwill/182e0f504c8049a346bae0f871b42705" rel="nofollow">incorrect</a></p>

<ffmpeg><mp4><h.264><color>
How can I generate a color-correct h264/MP4 from a DPX sequence using ffmpeg?
lofidevops
# How can I generate a color-correct h264/MP4 from a DPX sequence using ffmpeg?

(Asked by: username_0 on 2016-07-19)

We are converting a sequence of DPX files into an MP4. When the artist uses Adobe Media Encoder CC to generate the video, the colors match the original DPX. When we use ffmpeg, the video has a reddish hint. The command used is:
ffmpeg -y -start_number 0101 -i \\path\to\filename.%04d.dpx -pix_fmt yuv420p sample.mp4

How can we generate a video that matches the color of the original DPX files?

Inspecting the files with ffprobe revealed the following differences (correct file/bad file):

major_brand: mp42 / isom
minor_version: 0 / 512
compatible_brands: mp42mp41 / isomiso2avc1mp41
encoder: not listed / Lavf57.34.102
Video: h264 (Main) / h264 (High)
Video: yuv420p(tv, bt709) / yuv420p
Video: 1920x1080 / 1920x1080 [SAR 1:1 DAR 16:9]
handler_name: Alias Data Handler / VideoHandler

Probe references: dpx, correct, incorrect

**Tags:** ffmpeg, mp4, h.264, color


---

## 2 answers

### Answer by username_0 on 2016-07-19. Score: 2 | Accepted answer

I followed up on the yuv420p(tv, bt709) portion of the encoding and discovered that this refers to the Rec. 709 colorspace for HDTV. In ffmpeg, colorspace is defined by the colormatrix filter. However, you must convert from some colorspace. According to an ffmpeg mailing list conversation, the default colorspace is assumed to be bt601:

ISTR that if you give ffmpeg RGB it assumes its full range, it also by
  default converts using 601 matrices. Although it has a number of
  colourspaces defined which can be accessed in the libs using the API,
  ffmpeg itself makes no use of them (Although I have a nagging feeling
  that that may not be completely true anymore either).

So the final ffmpeg command that worked was:
ffmpeg -y -start_number 0101 -i \\path\to\filename.%04d.dpx
-vf colormatrix=bt601:bt709 -pix_fmt yuv420p sample.mp4

The color is now correct, but there is no discernible difference in the output from ffprobe or MediaInfo. (In other words, the colorspace of the ffmpeg-generated file does not appear in the output.)

> **Comments:**
> **username_1**: Add `-colorspace 1` to tag the output.  
> **username_0**: @Mulvya great! is there a "tag everything" option? (I couldn't find one)  

---

### Answer by username_2 on 2021-04-05. Score: 0

Recent patches to ffmpeg fixed this issue <https://github.com/FFmpeg/FFmpeg/search?q=dpx&type=commits>

It now reads range, primaries, matrix and transfer. Not to mention SMPTE timecode and alternate framerate.

There is still a bug that it writes linear transfer on all files.


---

