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

OSC info in custom video mode at 1080i50 goes twice as fast / decklink doesn't support 'new' time-scale #1588

Closed
Sidonai-1 opened this issue Nov 25, 2024 · 11 comments

Comments

@Sidonai-1
Copy link

Sidonai-1 commented Nov 25, 2024

Observed Behavior

When creating a custom video mode we have to specify the time-scale like this:

    <video-mode>
      <id>1248x1080px50</id>
      <width>1248</width>
      <height>1080</height>
      <time-scale>50000</time-scale>
      <duration>1000</duration>
      <cadence>1920/2</cadence>
    </video-mode>

A couple years ago we gathered the info from here to create new ones, so when making a 1080i50 channel we set the time-scale to 50000.

I noticed that the OSC countdown was going twice as fast as it should, so I checked and I saw that after #1440 the time-scale of a 1080i50 channel changed to 25000.

I tried to update it in the config but the Decklink 8K Pro card throws an error.

  <channels>
    <channel>
      <video-mode>1248x1080px50</video-mode>
      <consumers>
        <decklink>
          <device>1</device>
          <video-mode>1080i5000</video-mode>
          <buffer-depth>5</buffer-depth>
        </decklink>
      </consumers>
    </channel>
  </channels>

  <video-modes>
    <video-mode>
      <id>1248x1080px50</id>
      <width>1248</width>
      <height>1080</height>
      <time-scale>25000</time-scale>
      <duration>1000</duration>
      <cadence>1920/2</cadence>
    </video-mode>
  </video-modes>
[decklink_consumer] Uninitialized.
Exception: D:\a\server\server\src\modules\decklink\consumer\decklink_consumer.cpp(189): Throw in function struct caspar::core::video_format_desc __cdecl caspar::decklink::get_decklink_format(const struct caspar::decklink::port_configuration &,const struct caspar::core::video_format_desc &)
Dynamic exception type: class boost::exception_detail::clone_impl<struct caspar::user_error>
[struct caspar::tag_msg_info * __ptr64] = Decklink does not support the channel format
[struct caspar::tag_stacktrace_info * __ptr64] =  0# 0x00007FF731C22C17 in casparcg
1# 0x00007FF731C4DAB6 in casparcg
2# 0x00007FF731DADB8E in casparcg
3# 0x00007FF731DA8B1B in casparcg
4# 0x00007FF731DAB39A in casparcg
5# 0x00007FF731C7573F in casparcg
6# 0x00007FF731CB7E9E in casparcg
7# 0x00007FF731CB2156 in casparcg
8# configthreadlocale in ucrtbase
9# BaseThreadInitThunk in KERNEL32
10# RtlUserThreadStart in ntdll

0# 0x00007FF731C22C17 in casparcg
1# 0x00007FF731C226A5 in casparcg
2# 0x00007FF731EDCEA9 in casparcg
3# 0x00007FFC58191080 in VCRUNTIME140_1
4# _NLG_Return2 in VCRUNTIME140_1
5# RtlCaptureContext2 in ntdll
6# 0x00007FF731C497C8 in casparcg
7# 0x00007FF731C4E039 in casparcg
8# 0x00007FF731C24952 in casparcg
9# 0x00007FF731C27E62 in casparcg
10# 0x00007FF731E99814 in casparcg
11# BaseThreadInitThunk in KERNEL32
12# RtlUserThreadStart in ntdll

Environment

  • Server version: 2.4.1 5e29af9 Stable
  • Operating system: Windows 10
@Julusian
Copy link
Member

Which field is it in the osc that looks wrong?

Some changes might be expected, as the after that change a 50i channel is running at 25hz, producing 2 frames each tick

@Sidonai-1
Copy link
Author

Which field is it in the osc that looks wrong?

The Timecode /countdown for the video remaining time is what goes twice as fast. As a result a video on LOOP will jump the loop in the middle of the video instead of at the end.

@Julusian
Copy link
Member

I'm still not sure what field you are referring to. This is the osc I am getting each tick:

Image

Which all looks correct. AMB is 10.7s long, and is taking 10.7 seconds to play through and loop.

This is with the config:

<video-modes>
        <video-mode>
            <id>1248x1080px50</id>
            <width>1248</width>
            <height>1080</height>
            <time-scale>50000</time-scale>
            <duration>1000</duration>
            <cadence>1920/2</cadence>
        </video-mode>
    </video-modes>
    <channels>
        <channel>
            <video-mode>1248x1080px50</video-mode>
            <consumers>
                <decklink>
                    <device>1</device>
                    <video-mode>1080i5000</video-mode>
                </decklink>

            </consumers>
            <producers>
                <producer id="10">AMB loop</producer>
            </producers>
        </channel>
    </channels>

@Sidonai-1
Copy link
Author

Sidonai-1 commented Jan 23, 2025

I just tested this on the newer 2.5.0 895a5a0 Dev and it is still present if you set the time-scale at 50000. Setting the time-scale at 25000 (as video_format.cpp says now) it also says "Decklink does not support the channel format"

I can see how AMB might not be the best test video for this, being an endless loop with no time-marks or visual cues.
I downloaded the videos from the Caspar webpage so you can replicate the test with the same media.

The behaviour is different between a normal 1080i50 channel (it reaches the end of the video) and a custom res. at 50i (it reaches only the middle point even if OSC info says it reached the end).

The screenshots are all for the last frame displayed
Image
Diag says it reached the end of the file, but the play time went so fast it actually only got to the mid point.

Image

@Julusian
Copy link
Member

huh, so trying this with some more clips, it seems to be a bit random that some clips will have this issue, but not all of them.
DIAG counters for AMB plays at the right speed but go1080p25 is double.
cg1080i50 is a fun one, it reports double speed, with cg1080i50_a (its separate alpha channel) playing at normal speed.

@Sidonai-1
Copy link
Author

Sidonai-1 commented Jan 23, 2025

huh, so trying this with some more clips, it seems to be a bit random that some clips will have this issue, but not all of them.
DIAG counters for AMB plays at the right speed but go1080p25 is double.
cg1080i50 is a fun one, it reports double speed, with cg1080i50_a (its separate alpha channel) playing at normal speed.

Oh that does sound like fun!

I confirmed that AMB plays correctly (took me a while to find a link for 2.0.7...) , then I tried to find a different video from my collection that would also play normally but no luck.

Note that if you don't add a decklink and set the time-scale at 25000 they all behave normally.

@Julusian
Copy link
Member

my testing today has been without a decklink, with no consumers attached in fact.
it behaves fine with 1080p5000, and 1080i5000 but not 1248x1080px50

@Julusian
Copy link
Member

Julusian commented Jan 23, 2025

ah I found the issue.

your cadence value is invalid. It is expecting a comma or space separated array of numbers.
So it is interpreting your 1920/2 value as 1920. Which means it is packing 1920 audio samples per frame at 50000/1000 meaning it is consuming 96000 samples a second.
Setting that to 960 to get it to correctly add up to 48000 samples, fixes the speed issue.

And that reveals thy some clips are fine and some not. amb and cg1080i50_a which play fine have no audio tracks. go1090p25 and cg1080i50 have audio tracks.
Presumably in its desire for 1920 audio samples per frame, it resulted in playing the clips at double speed to get enough samples

I did intend to have some logic checking the cadence looked sane, but I think I didn't figure out the rule..

@Julusian
Copy link
Member

d41402f will now cause it to refuse to start if the cadence values are very wrong like this (ie, won't result in exactly 48000 samples a second)

I think this is all that can be done on this

@Sidonai-1
Copy link
Author

ah I found the issue.

your cadence value is invalid. It is expecting a comma or space separated array of numbers.
So it is interpreting your 1920/2 value as 1920.

Thanks a lot,

So the correct way of setting a 50i cadence is 1920 / 2 ? ( with spaces)

@Julusian
Copy link
Member

No, simply 960

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

No branches or pull requests

2 participants