Ports' need for reference input seems arbitrary

[Sidonai-1]

Observed Behavior

When using more than one card, the requirement for reference input for the Decklinks to properly initialize don't seem to follow a clear logic.
If the video mode of the different cards is the same, reference is needed for it to work. If there is a different resolution then it initializes no problem.

This is a picture of the devices I am using for this test.

Devices 2,3,4,5 are the Decklink 8KPro, Device 1 is the Extreme 12G.

I'm using a custom video mode:

  <video-modes>
    <video-mode>
      <id>2688x1536px25</id>
      <width>2688</width>
      <height>1536</height>
      <time-scale>25000</time-scale>
      <duration>1000</duration>
      <cadence>1920</cadence>
    </video-mode>
  </video-modes>

If the port of the Extreme 12G has the same size as the main device, this config only works with genlock at 25p.

    <channel>
      <video-mode>2688x1536px25</video-mode>
      <consumers>
        <decklink>
          <wait-for-reference>auto</wait-for-reference>
          <wait-for-reference-duration>4</wait-for-reference-duration>
          <device>2</device>
          <video-mode>1080p2500</video-mode>
          <buffer-depth>1</buffer-depth>
          <embedded-audio>true</embedded-audio>
          <ports>
            <port>
              <device>1</device>
              <video-mode>1080p2500</video-mode>
            </port>
          </ports>
        </decklink>
      </consumers>
    </channel>

Without proper reference input it throws an error:

[2024-06-17 14:24:19.505] [info]    DeckLink 8K Pro [1-2|1080p2500] Disabled low-latency mode.
[2024-06-17 14:24:19.505] [info]    DeckLink 8K Pro [1-2|1080p2500] Enabled external keyer.
[2024-06-17 14:24:19.507] [info]    DeckLink 8K Pro [1-2|1080p2500] && DeckLink 4K Extreme 12G [1|1080p2500] Enabled embedded-audio.
[2024-06-17 14:24:19.507] [info]    DeckLink 8K Pro [1-2|1080p2500] && DeckLink 4K Extreme 12G [1|1080p2500] Disabled low-latency mode.
[2024-06-17 14:24:19.507] [error]   DeckLink 8K Pro [1-2|1080p2500] && DeckLink 4K Extreme 12G [1|1080p2500] Failed to enable external keyer.
[2024-06-17 14:24:19.551] [info]    DeckLink 8K Pro [1-2|1080p2500] && DeckLink 4K Extreme 12G [1|1080p2500] Reference signal: waiting for lock
[2024-06-17 14:24:23.575] [warning] DeckLink 8K Pro [1-2|1080p2500] && DeckLink 4K Extreme 12G [1|1080p2500] Reference signal: unable to acquire lock
[2024-06-17 14:24:23.591] [info]    [decklink_consumer] Uninitialized.
[2024-06-17 14:24:23.590] [error]   Exception: D:\a\server\server\src\modules\decklink\consumer\decklink_consumer.cpp(823): Throw in function void __cdecl caspar::decklink::decklink_consumer::start_playback(void)
[2024-06-17 14:24:23.590] [error]   Dynamic exception type: class boost::exception_detail::clone_impl<struct caspar::caspar_exception>
[2024-06-17 14:24:23.590] [error]   [struct caspar::tag_msg_info * __ptr64] = DeckLink 8K Pro [1-2|1080p2500] && DeckLink 4K Extreme 12G [1|1080p2500] Failed to schedule primary playback.
[2024-06-17 14:24:23.590] [error]   [struct caspar::tag_stacktrace_info * __ptr64] =  0# 0x00007FF7DF283427 in casparcg
[2024-06-17 14:24:23.590] [error]    1# 0x00007FF7DF2AF7C6 in casparcg
[2024-06-17 14:24:23.590] [error]    2# 0x00007FF7DF40BD85 in casparcg
[2024-06-17 14:24:23.590] [error]    3# 0x00007FF7DF404369 in casparcg
[2024-06-17 14:24:23.590] [error]    4# 0x00007FF7DF405CFA in casparcg
[2024-06-17 14:24:23.590] [error]    5# 0x00007FF7DF2D6CFF in casparcg
[2024-06-17 14:24:23.590] [error]    6# 0x00007FF7DF316EBE in casparcg
[2024-06-17 14:24:23.590] [error]    7# 0x00007FF7DF311806 in casparcg
[2024-06-17 14:24:23.590] [error]    8# configthreadlocale in ucrtbase
[2024-06-17 14:24:23.590] [error]    9# BaseThreadInitThunk in KERNEL32
[2024-06-17 14:24:23.590] [error]   10# RtlUserThreadStart in ntdll
[2024-06-17 14:24:23.590] [error]   
[2024-06-17 14:24:23.590] [error]   
[2024-06-17 14:24:23.590] [error]    0# 0x00007FF7DF283427 in casparcg
[2024-06-17 14:24:23.590] [error]    1# 0x00007FF7DF282EAA in casparcg
[2024-06-17 14:24:23.590] [error]    2# 0x00007FF7DF5390D9 in casparcg
[2024-06-17 14:24:23.590] [error]    3# 0x00007FF8CE271080 in VCRUNTIME140_1
[2024-06-17 14:24:23.590] [error]    4# _NLG_Return2 in VCRUNTIME140_1
[2024-06-17 14:24:23.590] [error]    5# RtlCaptureContext2 in ntdll
[2024-06-17 14:24:23.590] [error]    6# 0x00007FF7DF2AAEC6 in casparcg
[2024-06-17 14:24:23.590] [error]    7# 0x00007FF7DF2AFD4B in casparcg
[2024-06-17 14:24:23.590] [error]    8# 0x00007FF7DF2850C8 in casparcg
[2024-06-17 14:24:23.590] [error]    9# 0x00007FF7DF2883FF in casparcg
[2024-06-17 14:24:23.590] [error]   10# 0x00007FF7DF4F5B64 in casparcg
[2024-06-17 14:24:23.590] [error]   11# BaseThreadInitThunk in KERNEL32
[2024-06-17 14:24:23.590] [error]   12# RtlUserThreadStart in ntdll
[2024-06-17 14:24:23.590] [error]   
[2024-06-17 14:24:23.732] [info]    Initialized startup producers.
[2024-06-17 14:24:23.733] [info]    Initialized controllers.
[2024-06-17 14:24:23.733] [info]    Initialized osc.

So far so good, this is to be expected I guess.

The weird behaviour is when you set the port to a different size, suddenly the server starts no problem without any genlock present.

    <channel>
      <video-mode>2688x1536px25</video-mode>
      <consumers>
        <decklink>
          <wait-for-reference>auto</wait-for-reference>
          <wait-for-reference-duration>4</wait-for-reference-duration>
          <device>2</device>
          <video-mode>1080p2500</video-mode>
          <buffer-depth>1</buffer-depth>
          <embedded-audio>true</embedded-audio>
          <ports>
            <port>
              <device>1</device>
              <video-mode>2160p2500</video-mode>
            </port>
          </ports>
        </decklink>
      </consumers>
    </channel>

Is there anything in the SDK documentation that could explain this or it could be a bug?

Environment

• Commit: 2ffc202
• Server version: 2.5.0 Dev
• Operating system: Windows 10

[Julusian]

The relevant portion of the SDK docs is:

All we are doing in the code, is enabling a playback group for each device if the parent device supports it and for the secondary devices if they support it. (the check could do something internally such as checking for matching formats, I am unsure)
Then we are doing a "waiting for lock", either if explicitly enabled, or if on auto and the parent did enable a playback group.

So we aren't considering formats or anything here, which I suppose could be a bug, but knowing how it should behave in various scenarios is hard