Answers.Body: <p>caja is using mediainfo and mediainfo has some misleading labels.</p>
  <p>What mediainfo is describing as <code>Color space</code> is more accurately a <a href="https://en.wikipedia.org/wiki/Color_model" rel="nofollow noreferrer">color model</a>. What ffprobe displays is the pixel format (<code>pix_fmt</code>) which is the specific combination of color model, chroma subsampling, bit depth and component interleaving that the decoder will produce.</p>
  <p>A <a href="https://en.wikipedia.org/wiki/Color_space" rel="nofollow noreferrer">Color space</a> is a mathematical organization of reproducible colors. Two videos may both have YUV (or RGB) encoding and yet have different color spaces. If the output device doesn't know or guess the color space of the image/video, reproduced colors will be different from what is intended.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-01-09T19:48:35.667Z
Answers.Text: Trying to understand/integrate what you said.  If mediainfo is giving "color space" as YUV, and Chroma subsampling is 4:2:0, is that how ffprobe comes up with **pix_fmt** of **yuv420p** ? or is there a specific reference to yuv420p in the video header and that header does **not** have a value assigned to color space?
Answers.UserDisplayName: Eric Marceau
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-01-09T20:05:28.593Z
Answers.Text: As an aside, if videos automatically included "color space" definitions for each of standardized Red, Green and Blue, would that permit "normalizing" of generated video streams such that it would be near impossible to incorrectly remap the colors to an RGB space ... or any other for that matter?  Could ffmpeg define/build a proper color space definition using such a basic triplet of info?
Answers.UserDisplayName: Eric Marceau
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-01-10T04:20:47.103Z
Answers.Text: *how ffprobe comes up with pix_fmt of yuv420p ?* --> ffprobe opens the decoder and inspects the stream. If the colorimetry attributes are not set, then it's shown as 'unknown'.
Answers.UserDisplayName: Gyan
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-01-10T04:26:09.687Z
Answers.Text: *if videos automatically included "color space" definitions for each of standardized Red, Green and Blue, would that permit ...* --> that's what the 4 color attributes are for. ffmpeg is a video processor which transforms inputs into outputs, so they must be set in the input. ffmpeg can't "discover" these properties. You can get ffmpeg to manually record some user-set values in the output but the validity is for the user to ensure.
Answers.UserDisplayName: Gyan
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-01-09T04:02:51.447Z
Answers.LastActivityDate: 2023-01-09T04:02:51.447Z
Answers.UserDisplayName: Gyan
Body: <p>If the caja file properties report YUV for color space, why does <a href="/questions/tagged/ffprobe" class="post-tag" title="show questions tagged &#39;ffprobe&#39;" aria-label="show questions tagged &#39;ffprobe&#39;" rel="tag" aria-labelledby="ffprobe-container">ffprobe</a> report color space as unknown ?</p>
  <p>The video in question was obtained from Astronomy Picture of the Day (APOD) <a href="https://apod.nasa.gov/apod/ap180318.html" rel="nofollow noreferrer">Spinning Moon</a>.</p>
  <p>Here is the snapshot from caja:
  <a href="https://i.sstatic.net/UBLG9.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/UBLG9.png" alt="enter image description here" /></a></p>
  <p>ffprobe reports as follows:</p>
  <pre><code># ffprobe -v error -show_streams &quot;${file}&quot;
  FILE: VIDEO__MOON__SpinningMoon.mp4
  [STREAM]
  index=0
  codec_name=h264
  codec_long_name=H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10
  profile=Main
  codec_type=video
  codec_time_base=1/60
  codec_tag_string=[27][0][0][0]
  codec_tag=0x001b
  width=640
  height=800
  coded_width=640
  coded_height=800
  has_b_frames=2
  sample_aspect_ratio=1:1
  display_aspect_ratio=4:5
  pix_fmt=yuv420p     &lt;&lt;&lt;===
  level=32
  color_range=unknown     &lt;&lt;&lt;===
  color_space=unknown     &lt;&lt;&lt;===
  color_transfer=unknown     &lt;&lt;&lt;===
  color_primaries=unknown     &lt;&lt;&lt;===
  chroma_location=left
  field_order=progressive
  timecode=N/A
  refs=1
  is_avc=false
  nal_length_size=0
  id=0x1e1
  r_frame_rate=30/1
  avg_frame_rate=30/1
  time_base=1/90000
  start_pts=192410
  start_time=2.137889
  duration_ts=1959000
  duration=21.766667
  bit_rate=N/A
  max_bit_rate=N/A
  bits_per_raw_sample=8
  nb_frames=N/A
  nb_read_frames=N/A
  nb_read_packets=N/A
  ...{snip - DISPOSITION:*}...
  [/STREAM]
  </code></pre>
  <p>But when I play the video in VLC, it reports CODECs as follows:</p>
  <p><a href="https://i.sstatic.net/ftRV7.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/ftRV7.png" alt="enter image description here" /></a></p>
  <p>I must say that when I start the playing in VLC, the moon image is initally presented (for a fraction of a second) as an elipse going full width of the screen, but then it blanks out and continues with &quot;proper&quot; proportions (i.e. near circle), and when I tell VLC to go on repeat loop, you don't see that initial &quot;deformation&quot; (<em>as if it was able to figure something out and remember that as a setting, during ongoing playback</em>).</p>
  <p><strong>QUESTION:</strong>  Is the reporting of &quot;<strong>unknown</strong>&quot; for the color space parameters a bug with <strong><a href="/questions/tagged/ffprobe" class="post-tag" title="show questions tagged &#39;ffprobe&#39;" aria-label="show questions tagged &#39;ffprobe&#39;" rel="tag" aria-labelledby="ffprobe-container">ffprobe</a>/<a href="/questions/tagged/ffmpeg" class="post-tag" title="show questions tagged &#39;ffmpeg&#39;" aria-label="show questions tagged &#39;ffmpeg&#39;" rel="tag" aria-labelledby="ffmpeg-container">ffmpeg</a></strong>, even though it has recognized the pixel format at &quot;<strong>yuv420p</strong>&quot;?  Is that an oversight in coding?</p>
  <p><strong>My environment:</strong></p>
  <pre><code>Ubuntu MATE 20.04 LTS
  
  ffprobe version 4.2.7-0ubuntu0.1 Copyright (c) 2007-2022 the FFmpeg developers
  built with gcc 9 (Ubuntu 9.4.0-1ubuntu1~20.04.1)
  </code></pre>
  
Tags: <ffmpeg><colorspace><ffprobe>
Title: Why does ffprobe report color space as unknown?
UserDisplayName: user40272
ThreadText: # Why does ffprobe report color space as unknown?
  
  (Asked by: username_0 on 2023-01-08)
  
  If the caja file properties report YUV for color space, why does [ffprobe](/questions/tagged/ffprobe "show questions tagged 'ffprobe'") report color space as unknown ?
  
  The video in question was obtained from Astronomy Picture of the Day (APOD) [Spinning Moon](https://apod.nasa.gov/apod/ap180318.html).
  
  Here is the snapshot from caja:
  [![enter image description here](https://i.sstatic.net/UBLG9.png)](https://i.sstatic.net/UBLG9.png)
  
  ffprobe reports as follows:
  
  ```
  # ffprobe -v error -show_streams "${file}"
  FILE: VIDEO__MOON__SpinningMoon.mp4
  [STREAM]
  index=0
  codec_name=h264
  codec_long_name=H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10
  profile=Main
  codec_type=video
  codec_time_base=1/60
  codec_tag_string=[27][0][0][0]
  codec_tag=0x001b
  width=640
  height=800
  coded_width=640
  coded_height=800
  has_b_frames=2
  sample_aspect_ratio=1:1
  display_aspect_ratio=4:5
  pix_fmt=yuv420p     <<<===
  level=32
  color_range=unknown     <<<===
  color_space=unknown     <<<===
  color_transfer=unknown     <<<===
  color_primaries=unknown     <<<===
  chroma_location=left
  field_order=progressive
  timecode=N/A
  refs=1
  is_avc=false
  nal_length_size=0
  id=0x1e1
  r_frame_rate=30/1
  avg_frame_rate=30/1
  time_base=1/90000
  start_pts=192410
  start_time=2.137889
  duration_ts=1959000
  duration=21.766667
  bit_rate=N/A
  max_bit_rate=N/A
  bits_per_raw_sample=8
  nb_frames=N/A
  nb_read_frames=N/A
  nb_read_packets=N/A
  ...{snip - DISPOSITION:*}...
  [/STREAM]
  
  ```
  
  But when I play the video in VLC, it reports CODECs as follows:
  
  [![enter image description here](https://i.sstatic.net/ftRV7.png)](https://i.sstatic.net/ftRV7.png)
  
  I must say that when I start the playing in VLC, the moon image is initally presented (for a fraction of a second) as an elipse going full width of the screen, but then it blanks out and continues with "proper" proportions (i.e. near circle), and when I tell VLC to go on repeat loop, you don't see that initial "deformation" (*as if it was able to figure something out and remember that as a setting, during ongoing playback*).
  
  **QUESTION:** Is the reporting of "**unknown**" for the color space parameters a bug with **[ffprobe](/questions/tagged/ffprobe "show questions tagged 'ffprobe'")/[ffmpeg](/questions/tagged/ffmpeg "show questions tagged 'ffmpeg'")**, even though it has recognized the pixel format at "**yuv420p**"? Is that an oversight in coding?
  
  **My environment:**
  
  ```
  Ubuntu MATE 20.04 LTS
  
  ffprobe version 4.2.7-0ubuntu0.1 Copyright (c) 2007-2022 the FFmpeg developers
  built with gcc 9 (Ubuntu 9.4.0-1ubuntu1~20.04.1)
  
  ```
  
  **Tags:** ffmpeg, colorspace, ffprobe
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2023-01-09. Score: 0
  
  caja is using mediainfo and mediainfo has some misleading labels.
  
  What mediainfo is describing as `Color space` is more accurately a [color model](https://en.wikipedia.org/wiki/Color_model). What ffprobe displays is the pixel format (`pix_fmt`) which is the specific combination of color model, chroma subsampling, bit depth and component interleaving that the decoder will produce.
  
  A [Color space](https://en.wikipedia.org/wiki/Color_space) is a mathematical organization of reproducible colors. Two videos may both have YUV (or RGB) encoding and yet have different color spaces. If the output device doesn't know or guess the color space of the image/video, reproduced colors will be different from what is intended.
  
  > **Comments:**
  > **username_2**: Trying to understand/integrate what you said.  If mediainfo is giving "color space" as YUV, and Chroma subsampling is 4:2:0, is that how ffprobe comes up with **pix_fmt** of **yuv420p** ? or is there a specific reference to yuv420p in the video header and that header does **not** have a value assigned to color space?  
  > **username_2**: As an aside, if videos automatically included "color space" definitions for each of standardized Red, Green and Blue, would that permit "normalizing" of generated video streams such that it would be near impossible to incorrectly remap the colors to an RGB space ... or any other for that matter?  Could ffmpeg define/build a proper color space definition using such a basic triplet of info?  
  > **username_1**: *how ffprobe comes up with pix_fmt of yuv420p ?* --> ffprobe opens the decoder and inspects the stream. If the colorimetry attributes are not set, then it's shown as 'unknown'.  
  > **username_1**: *if videos automatically included "color space" definitions for each of standardized Red, Green and Blue, would that permit ...* --> that's what the 4 color attributes are for. ffmpeg is a video processor which transforms inputs into outputs, so they must be set in the input. ffmpeg can't "discover" these properties. You can get ffmpeg to manually record some user-set values in the output but the validity is for the user to ensure.  
  
  ---
  
  