SDR Files Being Incorrectly Parsed as HLG

[yammes08]

Is there an existing issue for this?

• I have searched the existing open and closed issues

Current Behavior

When a 2160p SDR file is imported and renamed, if the MediaInfo VideoDynamicRangeType token is used in the renamed file then the value HLG is returned instead of SDR.

Expected Behavior

The file is renamed using SDR and not HLG.

Steps To Reproduce

1. Ensure Rename Movies is enabled, and that MediaInfo VideoDynamicRangeType is used somewhere in the file renaming scheme
2. Add a movie
3. Grab a 4K SDR release of that movie
4. On import, observe the renamed file contains HLG

Environment

- OS: Unraid 6.12.4
- Radarr: 5.4.4.8688
- Docker Install: hotio
- Using Reverse Proxy: Yes (local only)
- Browser: Safari 17.2.1
- Database: Sqlite 3.44.2

What branch are you running?

Develop

Trace Logs? Not Optional

Whilst I don't have any trace logs, I have carried out some diagnostics.

When running ffprobe -loglevel error -print_format json -show_frames -v quiet -sexagesimal -read_intervals "%+#2" -select_streams v "/path/to/4k/sdr/file", the following output is returned:

{
    "frames": [
        {
            "media_type": "video",
            "stream_index": 0,
            "key_frame": 1,
            "pts": 0,
            "pts_time": "0:00:00.000000",
            "pkt_dts": 0,
            "pkt_dts_time": "0:00:00.000000",
            "best_effort_timestamp": 0,
            "best_effort_timestamp_time": "0:00:00.000000",
            "pkt_duration": 41,
            "pkt_duration_time": "0:00:00.041000",
            "pkt_pos": "9171",
            "pkt_size": "2995",
            "width": 3840,
            "height": 2160,
            "pix_fmt": "yuv420p10le",
            "sample_aspect_ratio": "1:1",
            "pict_type": "I",
            "coded_picture_number": 0,
            "display_picture_number": 0,
            "interlaced_frame": 0,
            "top_field_first": 0,
            "repeat_pict": 0,
            "color_range": "tv",
            "color_space": "bt2020nc",
            "color_primaries": "bt2020",
            "color_transfer": "bt2020-10",
            "chroma_location": "topleft"
        },
        {
            "media_type": "video",
            "stream_index": 0,
            "key_frame": 0,
            "pts": 125,
            "pts_time": "0:00:00.125000",
            "best_effort_timestamp": 125,
            "best_effort_timestamp_time": "0:00:00.125000",
            "pkt_duration": 41,
            "pkt_duration_time": "0:00:00.041000",
            "pkt_pos": "35616",
            "pkt_size": "486",
            "width": 3840,
            "height": 2160,
            "pix_fmt": "yuv420p10le",
            "sample_aspect_ratio": "1:1",
            "pict_type": "P",
            "coded_picture_number": 0,
            "display_picture_number": 0,
            "interlaced_frame": 0,
            "top_field_first": 0,
            "repeat_pict": 0,
            "color_range": "tv",
            "color_space": "bt2020nc",
            "color_primaries": "bt2020",
            "color_transfer": "bt2020-10",
            "chroma_location": "topleft"
        }
    ]
}

When running ffprobe -loglevel error -print_format json -show_frames -v quiet -sexagesimal -read_intervals "%+#2" -select_streams v "/path/to/4k/hlg/file", the following output is returned:

{
    "frames": [
        {
            "media_type": "video",
            "stream_index": 0,
            "key_frame": 1,
            "pts": 0,
            "pts_time": "0:00:00.000000",
            "best_effort_timestamp": 0,
            "best_effort_timestamp_time": "0:00:00.000000",
            "pkt_duration": 40,
            "pkt_duration_time": "0:00:00.040000",
            "pkt_pos": "5819",
            "pkt_size": "511618",
            "width": 3840,
            "height": 2160,
            "pix_fmt": "yuv420p10le",
            "sample_aspect_ratio": "1:1",
            "pict_type": "I",
            "coded_picture_number": 0,
            "display_picture_number": 0,
            "interlaced_frame": 0,
            "top_field_first": 0,
            "repeat_pict": 0,
            "color_range": "tv",
            "color_space": "bt2020nc",
            "color_primaries": "bt2020",
            "color_transfer": "arib-std-b67",
            "chroma_location": "topleft"
        },
        {
            "media_type": "video",
            "stream_index": 0,
            "key_frame": 0,
            "pts": 320,
            "pts_time": "0:00:00.320000",
            "best_effort_timestamp": 320,
            "best_effort_timestamp_time": "0:00:00.320000",
            "pkt_duration": 40,
            "pkt_duration_time": "0:00:00.040000",
            "pkt_pos": "526258",
            "pkt_size": "187814",
            "width": 3840,
            "height": 2160,
            "pix_fmt": "yuv420p10le",
            "sample_aspect_ratio": "1:1",
            "pict_type": "P",
            "coded_picture_number": 0,
            "display_picture_number": 0,
            "interlaced_frame": 0,
            "top_field_first": 0,
            "repeat_pict": 0,
            "color_range": "tv",
            "color_space": "bt2020nc",
            "color_primaries": "bt2020",
            "color_transfer": "arib-std-b67",
            "chroma_location": "topleft"
        }
    ]
}

The primary difference between these two is the color_transfer property, which is bt2020-10 for SDR content and arib-std-b67 for HLG content. What is parsed and returned seems to be determined by this.

Should it be the case that if "color_transfer": "bt2020-10", then SDR is returned instead?

Trace Logs have been provided as applicable. Reports will be closed if the required logs are not provided.

• I have read and followed the steps in the wiki link above and provided the required trace logs - the logs contain trace - that are relevant and show this issue.

[yammes08]

Just checking in on this - is there any more information I can provide that would be helpful?