<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>

CC BY-SA 4.0
2023-01-09T19:48:35.667Z
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?
Eric Marceau
CC BY-SA 4.0
2023-01-09T20:05:28.593Z
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?
Eric Marceau
CC BY-SA 4.0
2023-01-10T04:20:47.103Z
*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'.
Gyan
CC BY-SA 4.0
2023-01-10T04:26:09.687Z
*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.
Gyan
CC BY-SA 4.0
2023-01-09T04:02:51.447Z
2023-01-09T04:02:51.447Z
Gyan
<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>

<ffmpeg><colorspace><ffprobe>
Why does ffprobe report color space as unknown?
user40272
# 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 report color space as unknown ?
The video in question was obtained from Astronomy Picture of the Day (APOD) Spinning Moon.
Here is the snapshot from caja:

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:

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/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.  

---

