NVIDIA Shadowplay color transfer characteristics wrong variable, color info read/set incorrectly

[odelllus]

hi, first thank you for the tool. i was trying to convert my bloated shadowplay library and noticed that it's setting the color transfer characteristics wrong. what happens when i try to use the tool normally:

PS D:\Shadowplay\StarCraft II\New folder> other-transcode *.mp4 --hevc Verifying "ffprobe" availability... Verifying "ffmpeg" availability... Verifying "mkvpropedit" availability... Finding encoders... Trying "hevc_nvenc" video encoder... Scanning media... duration = 00:05:00.417 Stream mapping: 0 = hevc_nvenc / 8000 Kbps 1 = copy Command line: ffmpeg -loglevel error -stats -i "StarCraft II 2020.08.30 - 05.31.06.18.DVR.mp4" -map 0:0 -c:v hevc_nvenc -pix_fmt:v p010le -b:v 8000k -maxrate:v 25000k -bufsize:v 25000k -color_primaries:v smpte170m -color_trc:v bt470m -colorspace:v smpte170m -metadata:s:v title= -disposition:v default -map 0:1 -c:a:0 copy -metadata:s:a:0 title= -disposition:a:0 default -sn -metadata:g title= -default_mode passthrough "StarCraft II 2020.08.30 - 05.31.06.18.DVR.mkv" Transcoding... [hevc_nvenc @ 0000014fb4892040] [Eval @ 00000007209fde30] Undefined constant or missing '(' in 'bt470m' [hevc_nvenc @ 0000014fb4892040] Unable to parse option value "bt470m" [hevc_nvenc @ 0000014fb4892040] Error setting option color_trc to value bt470m. Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height C:/Ruby30-x64/bin/other-transcode: transcoding failed: StarCraft II 2020.08.30 - 05.31.06.18.DVR.mkv

and the relevant mediainfo from the video:

Color primaries : BT.601 NTSC Transfer characteristics : BT.470 System M Matrix coefficients : BT.601

what's causing it to error is that the transfer characteristics variable "bt470m" isn't an actual ffmpeg variable even though it's the correct format, what you want is "gamma22" which is apparently the ffmpeg designated alias for bt.470 main for transfer characteristics (even though it is actually "bt470m" for primaries). if you take the tool's ffmpeg output, change color_trc to "gamma22", and run it it will work like normal and colors will look identical to the source file. also please forgive me if i'm using incorrect terminology, i have a VERY basic understanding of what's going on here.

i have a second color-related issue also. i was going to use this tool to convert my library of bowling practice session videos to HEVC and noticed the output videos have washed out color.

source video relevant mediainfo:

Color primaries : BT.709 colour_primaries_Original : BT.601 NTSC Transfer characteristics : BT.709 transfer_characteristics_Origi : BT.601 Matrix coefficients : BT.709 matrix_coefficients_Original : BT.601

when i play the source file in MPC-BE with madVR, it seems to be using the non-original color settings where your tool seems to be reading the "_Original" ones. i don't care that much about this as the difference in color is irrelevant for the kinds of videos i'm having this problem with but i figured it was worth mentioning.

thank you.

[lisamelton]

@odelllus I'm sorry you're having this problem but, to be honest, I don't understand what's going on here. Let's take one issue at a time, too, because I think the information for the second issue is clouding the first.

Here's what I need to know about the first issue to help:

1. Full MediaInfo results for your source/input video.
2. Confirm that your other-transcode options are simply --hevc.
3. The results from using other-transcode --dry-run --hevc on your source/input video.
4. Full MediaInfo results for your transcoded/output video

Thanks.

[odelllus]

1. Source MediaInfo
2. ✅
3. Dry run results
4. Output MediaInfo using corrected "color_trc" value

[lisamelton]

@odelllus Thanks! But I don't know what you mean by "using corrected 'color_trc' value." Does that mean you modified it after it was created by other-transcode?

[lisamelton]

@odelllus OK, after looking at your source/input, I see that this "Shadowplay" video is essentially using the old TV/DVD color space, with different transfer characteristics. And what you want is for those transfer characteristics to be copied into the transcoded/output, even though that output is 10-bit?

[odelllus]

@odelllus Thanks! But I don't know what you mean by "using corrected 'color_trc' value." Does that mean you modified it after it was created by other-transcode?

Sorry, yes. If I tried to run it as-is it would produce the error in the first quote in my original post. I checked the valid values for the "color_trc" option in ffmpeg's documentation since that's the one producing the error and found that the "color_trc" value that the tool was using of "bt470m" is invalid, and that the proper value for this video and that particular option ("color_trc") is "gamma22" which, per the ffmpeg documentation (just ctrl+f "color_trc" and you'll see what I mean), is the one that corresponds to the "bt470m" transfer characteristics of the source file. I think it's just a simple clerical error. "bt470m" is a valid value for color_primaries, but not color_trc for some reason.

@odelllus OK, after looking at your source/input, I see that this "Shadowplay" video is essentially using the old TV/DVD color space, with different transfer characteristics. And what you want is for those transfer characteristics to be copied into the transcoded/output, even though that output is 10-bit?

I think so, yeah. Once I ran ffmpeg with your tool's output, but with that one change to color_trc, it worked fine and the output video looked as it should.

Apologies for taking so long to respond, my power went out and my phone was dead.

[lisamelton]

@odelllus Is it possible for you to upload a snippet, maybe 30 seconds, of the original somewhere?

[mikaelmoutakis]

I was asked to crosslink this issue to another I opened, since I got a similar error message.

[odelllus]

@odelllus Is it possible for you to upload a snippet, maybe 30 seconds, of the original somewhere?

https://mega.nz/file/IItG3BSL#bEHm0rXSdRU-CrVDpgg91rl-ah522Z_45I-auSg20NA

[lisamelton]

@odelllus Thanks!

And thanks to @martinpickett for giving me a clue about what the bug actually is.

[lisamelton]

@odelllus OK, I have a fix for this. I wish it was a bit more elegant but it does seem to work. I'll test it some more today and probably check it in later so you and @martinpickett can test it.

[lisamelton]

@odelllus OK, I have finally checked in the workaround for this problem. My apologies for the long delay. Please test it if you are able. Thanks! I hope to release it soon.

[lisamelton]

I'm closing this now since a fix for this is already checked in and a release is imminent.