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)