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.

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

Bad performance on '2.4 Stable' with channels at 4K50p #1537

Closed
Sidonai-1 opened this issue May 10, 2024 · 3 comments
Closed

Bad performance on '2.4 Stable' with channels at 4K50p #1537

Sidonai-1 opened this issue May 10, 2024 · 3 comments
Labels

Comments

@Sidonai-1
Copy link

Sidonai-1 commented May 10, 2024

Observed Behavior

When configuring more than one channel with decklinks 8KPro set at 4K 50p, performance tanks and decklink output is not smooth. Tried with ProRes 422 files but any file at any resolution has the same effect.

This is with normal UHD50p video modes, even before playing anything:
2 4 0 1e25c7a Stable 4kfull50p

This is with custom video modes, smaller than full UHD, playing a couple of files.
2 4 0 1e25c7a Stable Custom 4k50p

Version 2.4.0 1e25c7a Stable and previous RC1 both have this issue.

Issue is not present at 4k 25p
2 4 0 1e25c7a Stable Custom 4k25p

Issue is still present if audio-embedded=false, but it improves slightly.
Issue happens with normal 4k video-modes as well as custom ones.

Expected behaviour

Version 2.4.0 80f8ee7 Dev does not suffer from this issue. (04/08/2023 16:38)

Full UHD:
2 4 0 80f8ee7 Dev 4kfull50p

Custom video-modes:
2 4 0 80f8ee7 Dev Custom 4k50p

Steps to reproduce

  1. Set 2 decklinks to 4K50p
  2. Play video files with audio

Environment

  • Server version: 2.4.0 1e25c7a Stable
  • Operating system: W10
  • BMD Driver version: 12.9
  • Videos: ProRes 422 25/50p
  • HP Z8 - Xeon Gold 6136 (x2) 24C/24T (Hyperthreading OFF / NUMA Nodes OFF)
  • Config:
 <channels>
    <channel>
      <video-mode>2688x1536px50</video-mode>
      <consumers>
        <decklink>
          <wait-for-reference>auto</wait-for-reference>
          <wait-for-reference-duration>4</wait-for-reference-duration>
          <device>1</device>
          <video-mode>2160p5000</video-mode>
          <subregion>
            <src-x>0</src-x>
            <src-y>0</src-y>
          </subregion>
          <buffer-depth>10</buffer-depth>
          <embedded-audio>true</embedded-audio>
        </decklink>
      </consumers>
    </channel>
	 <channel>
      <video-mode>1536x1536px50</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>2160p5000</video-mode>
          <subregion>
            <src-x>0</src-x>
            <src-y>0</src-y>
          </subregion>
          <buffer-depth>10</buffer-depth>
          <embedded-audio>true</embedded-audio>
        </decklink>
      </consumers>
    </channel>
	<channel>
      <video-mode>1080i5000</video-mode>
     <consumers>
        <decklink>
          <video-mode>1080i5000</video-mode>
		  <device>5</device>
          <buffer-depth>10</buffer-depth>
          <embedded-audio>true</embedded-audio>
        </decklink>
      </consumers>
    </channel>
  </channels>

  <video-modes>
    <video-mode>
      <id>2688x1536px50</id>
      <width>2688</width>
      <height>1536</height>
      <time-scale>50000</time-scale>
      <duration>1000</duration>
      <cadence>960</cadence>
     </video-mode>
      <video-mode>
      <id>1536x1536px50</id>
      <width>1536</width>
      <height>1536</height>
      <time-scale>50000</time-scale>
      <duration>1000</duration>
      <cadence>960</cadence>
    </video-mode>
  </video-modes>
@Julusian
Copy link
Member

I'm wondering if this is a consequence of 3816e08.
Could you try that build and the one before to see if this could have introduced it?

@Sidonai-1
Copy link
Author

Sidonai-1 commented May 24, 2024

I'm wondering if this is a consequence of 3816e08. Could you try that build and the one before to see if this could have introduced it?

I think your suspicions are correct.

version 3816e08 has this issue. And the previous one, 57f29cc works fine.

Julusian added a commit that referenced this issue May 24, 2024
tbbmalloc is necessary on windows to get satisfactory performance in many cases #1537

This reverts commit 3816e08.
Julusian added a commit that referenced this issue May 24, 2024
tbbmalloc is necessary on windows to get satisfactory performance in many cases #1537

This reverts commit 3816e08.
@Julusian
Copy link
Member

That commit is reverted for windows, hopefully that is enough to resolve this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants