Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Subregion <dest-y> parameter doesn't work with custom resolution and decklinks at UHD without height and width #1538

Closed
Sidonai-1 opened this issue May 24, 2024 · 12 comments
Closed

Subregion <dest-y> parameter doesn't work with custom resolution and decklinks at UHD without height and width #1538

Sidonai-1 opened this issue May 24, 2024 · 12 comments
Labels
type/bug

Comments

@Sidonai-1
Copy link

Sidonai-1 commented May 24, 2024 •
edited
Loading

Observed Behavior

I've been trying different configurations to see what the problem could be. I think it is a combination of: dest-y needing to specify width and height when you use a custom video-mode and set the decklinks above HD resolution.

Here are all the tests that I did:

CASE 1
Standard UHD; no ports.
dest-y WORKS NO PROBLEM

    <channel>
      <video-mode>2160p2500</video-mode>
      <consumers>
            <decklink>
                <device>1</device>
                <buffer-depth>5</buffer-depth>
                <video-mode>2160p2500</video-mode>
                <subregion>
                    <src-x>0</src-x>
                    <src-y>0</src-y>
                    <dest-x>0</dest-x>
                    <dest-y>500</dest-y>
                    <width>0</width>
                    <height>0</height>
                </subregion>
            </decklink>
      </consumers>
    </channel>

CASE 2
Custom video-modes; set at UHD; no ports;
UNABLE TO INITIALIZE DECKLINK:

    <channel>
      <video-mode>10752x1728px25</video-mode>
      <consumers>
            <decklink>
                <device>1</device>
                <buffer-depth>5</buffer-depth>
                <video-mode>2160p2500</video-mode>
                <subregion>
                    <src-x>0</src-x>
                    <src-y>0</src-y>
                    <dest-x>0</dest-x>
                    <dest-y>500</dest-y>
                    <width>0</width>
                    <height>0</height>
                </subregion>
            </decklink>
      </consumers>
    </channel>

[2024-05-24 13:10:35.037] [error]   Exception: No diagnostic information available.

[2024-05-24 13:10:35.037] [error]    0# 0x00007FF791802C17 in casparcg
[2024-05-24 13:10:35.037] [error]    1# 0x00007FF7918026A5 in casparcg
[2024-05-24 13:10:35.037] [error]    2# 0x00007FF791ACF8AA in casparcg
[2024-05-24 13:10:35.037] [error]    3# 0x00007FF842631080 in VCRUNTIME140_1
[2024-05-24 13:10:35.037] [error]    4# _NLG_Return2 in VCRUNTIME140_1
[2024-05-24 13:10:35.037] [error]    5# RtlCaptureContext2 in ntdll
[2024-05-24 13:10:35.037] [error]    6# 0x00007FF7918A4A19 in casparcg
[2024-05-24 13:10:35.037] [error]    7# 0x00007FF7918A5298 in casparcg
[2024-05-24 13:10:35.037] [error]    8# 0x00007FF7918A02CB in casparcg
[2024-05-24 13:10:35.037] [error]    9# 0x00007FF79189B113 in casparcg
[2024-05-24 13:10:35.037] [error]   10# configthreadlocale in ucrtbase
[2024-05-24 13:10:35.037] [error]   11# BaseThreadInitThunk in KERNEL32
[2024-05-24 13:10:35.037] [error]   12# RtlUserThreadStart in ntdll
[2024-05-24 13:10:35.037] [error]   
[2024-05-24 13:10:35.098] [debug]   DeckLink 8K Pro [1-1|2160p2500] Destroying on asynchronous destruction thread.
[2024-05-24 13:10:35.098] [debug]   DeckLink 8K Pro [1-1|2160p2500] Uninitializing.
[2024-05-24 13:10:35.140] [info]    DeckLink 8K Pro [1-1|2160p2500] Uninitialized.

CASE 3 This was a client bug, not a server error.
Standard UHD; using ports. no "wait for reference" lines.
UNABLE TO INITIALIZE DECKLINK:

   <channel>
      <video-mode>2160p2500</video-mode>
      <consumers>
            <decklink>
                <device>1</device>
                <buffer-depth>5</buffer-depth>
                <video-mode>2160p2500</video-mode>
                <subregion>
                    <src-x>0</src-x>
                    <src-y>0</src-y>
                    <dest-x>0</dest-x>
                    <dest-y>500</dest-y>
                    <width>0</width>
                    <height>0</height>
                </subregion>
		<ports>
		    <port>
                        <device>2</device>
                        <video-mode>2160p2500</video-mode>
                        <subregion>
                            <src-x>0</src-x>
                            <src-y>0</src-y>
                            <dest-x>0</dest-x>
                            <dest-y>100</dest-y>
                            <width>0</width>
                            <height>0</height>
                        </subregion>
                    </port>
                </ports>
            </decklink>
      </consumers>
    </channel>
	
[2024-05-24 13:02:12.801] [error]   Exception: No diagnostic information available.
[2024-05-24 13:02:12.801] [error]    0# 0x00007FF791802C17 in casparcg
[2024-05-24 13:02:12.801] [error]    1# 0x00007FF7918026A5 in casparcg
[2024-05-24 13:02:12.801] [error]    2# 0x00007FF791ACF8AA in casparcg
[2024-05-24 13:02:12.801] [error]    3# 0x00007FF842631080 in VCRUNTIME140_1
[2024-05-24 13:02:12.801] [error]    4# _NLG_Return2 in VCRUNTIME140_1
[2024-05-24 13:02:12.801] [error]    5# RtlCaptureContext2 in ntdll
[2024-05-24 13:02:12.801] [error]    6# 0x00007FF7918A4A19 in casparcg
[2024-05-24 13:02:12.801] [error]    7# 0x00007FF7918A5298 in casparcg
[2024-05-24 13:02:12.801] [error]    8# 0x00007FF7918A02CB in casparcg
[2024-05-24 13:02:12.801] [error]    9# 0x00007FF79189B113 in casparcg
[2024-05-24 13:02:12.801] [error]   10# configthreadlocale in ucrtbase
[2024-05-24 13:02:12.801] [error]   11# BaseThreadInitThunk in KERNEL32
[2024-05-24 13:02:12.801] [error]   12# RtlUserThreadStart in ntdll
[2024-05-24 13:02:12.801] [error]   
[2024-05-24 13:02:12.865] [debug]   DeckLink 8K Pro [1-1|2160p2500] && DeckLink 8K Pro [2|2160p2500] Destroying on asynchronous destruction thread.
[2024-05-24 13:02:12.865] [debug]   DeckLink 8K Pro [1-1|2160p2500] && DeckLink 8K Pro [2|2160p2500] Uninitializing.
[2024-05-24 13:02:12.972] [info]    DeckLink 8K Pro [1-1|2160p2500] && DeckLink 8K Pro [2|2160p2500] Uninitialized.

CASE 3a: Adding <wait-for-reference>auto</wait-for-reference><wait-for-reference-duration>4</wait-for-reference-duration> fixes the CASE 3 problem and dest-y works. I don't know if this is a bug or intended behaviour.

CASE 4
Custom video-mode; set at UHD; no ports; Specifying width and height.
dest-y WORKS NO PROBLEM

<channel>
      <video-mode>10752x1728px25</video-mode>
      <consumers>
            <decklink>
                <device>1</device>
                <buffer-depth>5</buffer-depth>
                <video-mode>2160p2500</video-mode>
                <subregion>
                    <src-x>0</src-x>
                    <src-y>0</src-y>
                    <dest-x>0</dest-x>
                    <dest-y>500</dest-y>
                    <width>800</width>
                    <height>800</height>
                </subregion>
            </decklink>
      </consumers>
    </channel>

CASE 5
Custom video-mode; set at UHD; Specifying width and height; using ports
dest-y on primary decklink WORKS NO PROBLEM

    <channel>
      <video-mode>10752x1728px25</video-mode>
      <consumers>
            <decklink>
                <device>1</device>
                <buffer-depth>5</buffer-depth>
                <video-mode>2160p2500</video-mode>
                <subregion>
                    <src-x>0</src-x>
                    <src-y>0</src-y>
                    <dest-x>0</dest-x>
                    <dest-y>500</dest-y>
                    <width>800</width>
                    <height>800</height>
                </subregion>
		<wait-for-reference>auto</wait-for-reference>
                <wait-for-reference-duration>4</wait-for-reference-duration>
		 <ports>
                    <port>
                        <device>2</device>
                        <video-mode>2160p2500</video-mode>
                        <subregion>
                            <src-x>0</src-x>
                            <src-y>0</src-y>
                            <dest-x>0</dest-x>
                            <dest-y>0</dest-y>
                            <width>0</width>
                            <height>0</height>
                        </subregion>
                    </port>
                </ports>
            </decklink>
      </consumers>
    </channel>

CASE 5a: using dest-y in ports and specifying width and height also makes both dest-y work.

CASE 6
Custom video-mode; set at UHD; using ports; specifying width and height only in primary.
dest-y in port causes startup crash

    <channel>
      <video-mode>10752x1728px25</video-mode>
      <consumers>
            <decklink>
                <device>1</device>
                <buffer-depth>5</buffer-depth>
                <video-mode>2160p2500</video-mode>
                <subregion>
                    <src-x>0</src-x>
                    <src-y>0</src-y>
                    <dest-x>0</dest-x>
                    <dest-y>500</dest-y>
                    <width>800</width>
                    <height>800</height>
                </subregion>
		<wait-for-reference>auto</wait-for-reference>
                <wait-for-reference-duration>4</wait-for-reference-duration>
		 <ports>
                    <port>
                        <device>2</device>
                        <video-mode>2160p2500</video-mode>
                        <subregion>
                            <src-x>0</src-x>
                            <src-y>0</src-y>
                            <dest-x>0</dest-x>
                            <dest-y>500</dest-y>
                            <width>0</width>
                            <height>0</height>
                        </subregion>
                    </port>
                </ports>
            </decklink>
      </consumers>
    </channel>
	
[2024-05-24 13:37:04.918] [fatal]   #######################
[2024-05-24 13:37:04.918] [fatal]    UNHANDLED EXCEPTION: 
[2024-05-24 13:37:04.918] [fatal]   Adress:00007FF8429F12DB
[2024-05-24 13:37:04.918] [fatal]   Code:3221225477
[2024-05-24 13:37:04.918] [fatal]   Flag:0
[2024-05-24 13:37:04.918] [fatal]   Info:000000EB9E6F5510
[2024-05-24 13:37:04.918] [fatal]   Continuing execution. 
[2024-05-24 13:37:04.918] [fatal]   #######################

CASE 7
Custom video-mode; using ports; set at HD;
dest-y WORKS FOR BOTH

    <channel>
      <video-mode>10752x1728px25</video-mode>
      <consumers>
            <decklink>
                <device>1</device>
                <buffer-depth>5</buffer-depth>
                <video-mode>1080p2500</video-mode>
                <subregion>
                    <src-x>0</src-x>
                    <src-y>0</src-y>
                    <dest-x>0</dest-x>
                    <dest-y>500</dest-y>
                    <width>0</width>
                    <height>0</height>
                </subregion>
		<wait-for-reference>auto</wait-for-reference>
                <wait-for-reference-duration>4</wait-for-reference-duration>
		 <ports>
                    <port>
                        <device>2</device>
                        <video-mode>1080p2500</video-mode>
                        <subregion>
                            <src-x>0</src-x>
                            <src-y>0</src-y>
                            <dest-x>0</dest-x>
                            <dest-y>500</dest-y>
                            <width>0</width>
                            <height>0</height>
                        </subregion>
                    </port>
                </ports>
            </decklink>
      </consumers>
    </channel>

I went pretty deep into the rabbit hole, I just hope it helps!

Expected behaviour

Use dest-y in any resolution

Steps to reproduce

See configs above.

Environment

2.4 Stable Windows 10
Decklink 8K Pro
Julusian added a commit that referenced this issue May 24, 2024
@Julusian
fix: ensure decklink subregion copy doesn't copy beyond the height of…
ced9bcb 
… the frame #1538
@Julusian
Copy link
Member

I have a fix for case 2 and 6. It wasn't clamping the copy bounds to be within the height of the channel, resulting in a failed copy of in your case row 1729.

I'm not able to reproduce 3 (I am using a 8K pro for this test)

Julusian added a commit that referenced this issue May 24, 2024
@Julusian
fix: ensure decklink subregion copy doesn't copy beyond the height of…
2138aed 
… the frame #1538
@Sidonai-1
Copy link
Author

I have a fix for case 2 and 6. It wasn't clamping the copy bounds to be within the height of the channel, resulting in a failed copy of in your case row 1729.

I'm not able to reproduce 3 (I am using a 8K pro for this test)

I put it there because I couldn't tell them apart at that point, but case 3 is probably just about not having the "waiting for reference" part in the config. At that moment I had installed one 8K Pro with the 4 SDI separated and one Extreme 12G (not in use). It was fixed by adding that part to the config, so it's probably not related to this issue.

@Sidonai-1
Copy link
Author

Sidonai-1 commented May 24, 2024 •
edited
Loading

Actually for case 3 maybe I had the wrong connectors config at that moment (SDI 1 in, SDI 2 out) and maybe that's why it couldn't initialize?
I'll check again on monday.

@Sidonai-1
Copy link
Author

I have a fix for case 2 and 6. It wasn't clamping the copy bounds to be within the height of the channel, resulting in a failed copy of in your case row 1729.

I'm not able to reproduce 3 (I am using a 8K pro for this test)

Nevermind Case 3, it was a client bug on how I was conecting and restarting the server. If the wait for reference was more than 7 seconds it failed to connect and I wrongly believed it was a server error (and the omision of those config lines meant 10 seconds by default).

We can forget about that one.

Thanks.

@Sidonai-1
Copy link
Author

I believe this is fixed in 2.5.0 d3af0b0

@Sidonai-1
Copy link
Author

Sidonai-1 commented May 27, 2024 •
edited
Loading

I tested this a bit more on 2.5.0. It doesn't crash the server now, thanks a lot.

However; Is it possible that dest-y it's not moving the whole channel canvass correctly?

For example: I set a custom resolution: 3840 x 600.

I set a decklink to UHD,
and I want to add a black bar in the upper part and start the content after it so in subregion I set <dest-y> to 200px.

What I was expecting was for the whole 600px channel to shift down and be fully visible, so my signal will be showing from y=200 to y=800.

Instead what happened is the channel started at y=200 but cutting the upper part (200px) of the content, so instead of adding the black bar and moving the content, it's only adding the black bar leaving the content in the same place (y=0). Bottom still gets cut at y=600, making it effectively only 400px high instead of 600.

Because <dest-x> doesn't behave this way I'm assuming it's a bug. I put it here since it's a bit related but I can open a new issue if you prefer.

Thank you.

@Sidonai-1 Sidonai-1 reopened this May 27, 2024
Julusian added a commit that referenced this issue May 27, 2024
@Julusian
fix: decklink subregion vertical offset #1538
f310873
@Julusian
Copy link
Member

Continuing here is fine.
I've pushed a fix, which is building now

Julusian added a commit that referenced this issue May 27, 2024
@Julusian
fix: decklink subregion vertical offset #1538
2161c1c
@Sidonai-1
Copy link
Author

Continuing here is fine.
I've pushed a fix, which is building now

Now the content is properly moved, but I believe the "black bar after the content" also needs to be shifted down.

As it is 00f0099 right now the content is still cut at y=600 instead of going down to y=800.

Thanks.

@Julusian
Copy link
Member

@Sidonai-1 I'm not seeing anything wrong here.
If I do the following in 1080p, I get a small black bar along the bottom

 <subregion>
                        <dest-y>400</dest-y>
                        <height>650</height>
</subregion>

@Sidonai-1
Copy link
Author

@Sidonai-1 I'm not seeing anything wrong here. If I do the following in 1080p, I get a small black bar along the bottom

 <subregion>
                        <dest-y>400</dest-y>
                        <height>650</height>
</subregion>

Sorry, I should've mentioned that I was using a custom resolution channel.

This config is a good example:

<video-modes>
    <video-mode>
      <id>600x600px25</id>
      <width>600</width>
      <height>600</height>
      <time-scale>25000</time-scale>
      <duration>1000</duration>
      <cadence>1920</cadence>
    </video-mode>
  </video-modes>
  <channels>
    <channel>
      <video-mode>600x600px25</video-mode>
      <consumers>
            <decklink>
                <device>5</device>
                <buffer-depth>5</buffer-depth>
                <video-mode>1080p2500</video-mode>
				<subregion>
					<src-x>0</src-x>
					<src-y>0</src-y>
					<dest-x>0</dest-x>
					<dest-y>0</dest-y>
					<width>600</width>
                                       <height>600</height>
				</subregion>
            </decklink>
      </consumers>
    </channel>
  </channels>

image

Then we move dest-x 400px, and it does what it should:

<subregion>
	<src-x>0</src-x>
	<src-y>0</src-y>
	<dest-x>400</dest-x>
	<dest-y>0</dest-y>
	<width>600</width>
        <height>600</height>
</subregion>

image

But if we move dest-y then it crops the down part of the content

<subregion>
	<src-x>0</src-x>
	<src-y>0</src-y>
	<dest-x>400</dest-x>
	<dest-y>400</dest-y>
	<width>600</width>
        <height>600</height>
</subregion>

image

Using width and height or not doesn't change the outcome.

Julusian added a commit that referenced this issue May 30, 2024
@Julusian
fix: decklink subregion vertical height limit on mixed formats #1538
c0c4dd7
Julusian added a commit that referenced this issue May 30, 2024
@Julusian
fix: decklink subregion vertical height limit on mixed formats #1538
bdcfef0
@Julusian
Copy link
Member

Another fix pushed, it was some bad maths that only had an issue when the channel format has less height than the decklink

@Sidonai-1
Copy link
Author

Fixed on c0c4dd7.

Thanks a lot!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
type/bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@Julusian @Sidonai-1