Color space/primaries/transfer not parsed correctly for HDR video
See original GitHub issueI’m converting an HDR clip with BT.2020 color space and PQ(HDR10) transfer. The source file’s HDR-related ffprobe JSON output says:
PS E:\> ffprobe -hide_banner -loglevel warning -select_streams v -print_format json -show_frames -read_intervals "%+#1" -show_entries "frame=color_space,color_primaries,color_transfer,side_data_list,pix_fmt" -i E:\kyoto.original.webm
{
"frames": [
{
"pix_fmt": "yuv420p10le",
"color_space": "bt2020nc",
"color_primaries": "bt2020",
"color_transfer": "smpte2084"
}
]
}
For the conversion options, I chose 20000kbps 2-pass, modified output filename, and remained everything else as default, including “Remove HDR” as No.
Pass 1 command line, generated by FastFlix:
"C:\Users\25305\AppData\Roaming\FFmpeg\bin\ffmpeg.exe" -y -i "E:/kyoto.original.webm" -max_muxing_queue_size 1024 -map 0:0 -c:v libx265 -pix_fmt yuv420p10le -x265-params ":pass=1:no-slow-firstpass=1" -passlogfile "C:\Users\25305\AppData\Roaming\FastFlix\temp_7t8l2imn\pass_log_file_482a2118f87cd48affc0.log" -b:v 20000k -preset medium -an -sn -dn -f mp4 NUL
Pass 2 command line:
"C:\Users\25305\AppData\Roaming\FFmpeg\bin\ffmpeg.exe" -y -i "E:/kyoto.original.webm" -max_muxing_queue_size 1024 -map 0:0 -c:v libx265 -pix_fmt yuv420p10le -x265-params ":pass=2" -passlogfile "C:\Users\25305\AppData\Roaming\FastFlix\temp_7t8l2imn\pass_log_file_482a2118f87cd48affc0.log" -b:v 20000k -preset medium -map_metadata -1 -map_chapters 0 -map 0:1 -metadata:s:1 title="" -metadata:s:1 handler="" -metadata:s:1 language=eng -c:1 copy "E:/kyoto.2passtest.mp4"
Seems no HDR-related data, other than pixel format, appeared in the commands.
After conversion I played the output file on an HDR-enabled device. The color was incorrect, looked pale. The output file’s HDR-related ffprobe JSON output says:
PS E:\> ffprobe -hide_banner -loglevel warning -select_streams v -print_format json -show_frames -read_intervals "%+#1" -show_entries "frame=color_space,color_primaries,color_transfer,side_data_list,pix_fmt" -i E:\kyoto.2passtest.mp4
{
"frames": [
{
"pix_fmt": "yuv420p10le",
"side_data_list": [
{
"side_data_type": "H.26[45] User Data Unregistered SEI message"
}
]
}
]
}
Color space/primaries/transfer data from the original clip seem to be lost. This problem also appeared in CRF encoding.
Full ffprobe output of both these 2 clips are included in attachments.
input_file_full_ffprobe.txt
output_file_full_ffprobe.txt
Finally I solved this problem with command line ffmpeg:
ffmpeg -i E:/kyoto.original.webm -map 0 -c:v libx265 -x265-params hdr-opt=1:repeat-headers=1:colorprim=bt2020:transfer=smpte2084:colormatrix=bt2020nc:max-cll=0,0 -crf 20 -preset veryfast -pix_fmt yuv420p10le E:/kyoto.crf20-veryfast.mp4
I removed the master-display data because ffmpeg spits out error when I tried to manually specify it.
The output file played well, the color was correct(maybe, I’m not able to tell if there’s any subtle color difference between source and output, but absolutly better than the previous output), and in the output file’s ffprobe all HDR-related entries were back(including master-display).
Issue Analytics
- State:
- Created 3 years ago
- Comments:19 (19 by maintainers)
Waiting for final 3.4.1 release & many thanks to your hardworking.
Re-fixed in 3.4.2