CasparCG
Support new video modes 2160p50 and 2160p60
The new Decklink 4K Extrem 12G offers UHD at 50p and 60p. But those modes are not yet supported by Caspar. It would be good to supoprt those 2 video modes as they are becoming the broadcasting standards.
By the way, for graphics an host flash templates has to be generated for the 3 new video modes: 2160p50, 2160p5994 and 2160p60.
for testing I have renamed the existing fth 2160p25 to 2160p50 and it works. But not sure this is clean.
FTh sources are not on github. So a core developper has to do it.
Actually the sources are here: https://github.com/CasparCG/Framework/tree/master/as3/TemplateHost/trunk so they are on github.
Oh that's great. Many thanks. My template "expert" will have a look at them then. If we feel comfortable in creating the missing ones, I'll submit a pull request.
Host template is done.
I haven't submit a pull request yet because I have the following 2 issues:
- at startup, Caspar can successfully initialize the Decklink in 2160p50, but there is warning saying that the video mode is not supported. Looking at the code, device->DoesSupportVideoMode fails with 2160p50 and 8bitBGRA. However, caspar is working properly
- We also found that audio is very bad in 2160p50 if you start caspar when the decklink is not configured in NTSC before. for now, we put an ugly workaround in dekclink consumer initialization, we first configure it in NTSC and then switch to the video mode configured in caspar.config...
any thoughts?
DoesSupportVideoMode() seems to be a little bit buggy. For example it returns "not supported" with a Decklink Quad at 720p50 with BGRA, when it really should return "supported with conversion", so I think it is fine to let it warn about not supporting that video mode.
Why does setting it to NTSC before 2160p50 help? Can you explain more about that point?
On the last point, we don't know yet exactly why resetting to NTSC before configuring the decklink to 2160p sort the audio issue. We just found that workaround by trial and error... We are not happy with that solution. We think may be something is missing during the initialization process in 2160p... It has probably nothing to do with NTSC...
Maybe the framerate is not correctly set when the initial decklink setting is already 2160p... another company developping a software based on the same board, told us they've sort the issue by switching their software from 10bit to 8bit... But we don't (and can't) have more details on this.
Maybe it is an issue about too few audio samples being scheduled. You could try giving audio_frame_buffer_ a capacity of 2.
setting audio_frame_buffer to 2 is not changing anything (I also tried 4: same result). However, changing video_frame_buffer from 1 to 2, results in much better audio, but then we lose audio/video sync.
Hi Aurelien,
I made a custom build to support 2160p5994 but I'm seeing some issues when I connect a decklink card to a SDI monitor. Is your code online to take a look at (here is mine -> https://github.com/aruanoc/Server/commit/5a3f6315ddd74ef13c69069498dcfe034f4ca80a)? Did you get to use casparCG with 2160p5000 successfully?
I'm also having some issues with the 4K Extreme 12G not outputting the key/alpha channel through the B out SDI port. Did you run into this?
Thank you!
Hi,
Yes i managed to have casparcf work in 2160p5000.
Concerning the alpha output, I don’t remember having testing it. But not surprised.
My code is not online yet, I had to switch to another project. I ‘ll try to do some cleanup on Monday an post it on my github.
Cheers Aurélien
From: aruanoc [mailto:[email protected]] Sent: vendredi 27 mai 2016 00:07 To: CasparCG/Server Cc: Aurelien Revault D'allonnes; Mention Subject: Re: [CasparCG/Server] Support new video modes 2160p50 and 2160p60 (#406)
Hi Aurelien,
I made a custom build to support 2160p5994 but I'm seeing some issues when I connect a decklink card to a SDI monitor. Is your code online to take a look at (here is mine -> aruanoc@5a3f631https://github.com/aruanoc/Server/commit/5a3f6315ddd74ef13c69069498dcfe034f4ca80a)? Did you get to use casparCG with 2160p5000 successfully?
I'm also having some issues with the 4K Extreme 12G not outputting the key/alpha channel through the B out SDI port. Did you run into this?
Thank you!
— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHubhttps://github.com/CasparCG/Server/issues/406#issuecomment-222009102
please find my modifications here : https://github.com/AurelienRevault/Caspar-Server/commit/03eba4685a4af40e58652fc54785c2d565f0cd7f
Aurelien,
Thank you very much! Your link wasn't working but I found your commit:
https://github.com/AurelienRevault/Caspar-Server/commit/03eba4685a4af40e58652fc54785c2d565f0cd7f
Our code changes are very similar and I'm not seeing the audio issues you were experiencing in my build, at least using system audio. Was that an issue with embedded audio?
Regarding the issues with the key using the 4K Extreme 12G, it turns out it was because we were using a cable that didn't have enough bandwidth and couldn't handle 2160p5994. If someone else runs into this, we had a successful test using a Belden 1694A 4.5Ghz SDI cable.
Thanks for the corrected link.
Yes, Audio issue with embedded audio. We never use system audio in production.
From: aruanoc [mailto:[email protected]] Sent: mardi 31 mai 2016 19:25 To: CasparCG/Server Cc: Aurelien Revault D'allonnes; Mention Subject: Re: [CasparCG/Server] Support new video modes 2160p50 and 2160p60 (#406)
Aurelien,
Thank you very much! Your link wasn't working but I found your commit:
AurelienRevault@03eba46https://github.com/AurelienRevault/Caspar-Server/commit/03eba4685a4af40e58652fc54785c2d565f0cd7f
I'm not seeing the audio issues you were experiencing, at least using system audio. Was that an issue with embedded audio?
Regarding the issues with the key using the 4K Extreme 12G, it turns out it was because we were using a cable that didn't have enough bandwidth and couldn't handle 2160p5994. If someone else runs into this, we had a successful test using a Belden 1694A 4.5Ghz SDI cable.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/CasparCG/Server/issues/406#issuecomment-222759021, or mute the threadhttps://github.com/notifications/unsubscribe/AF0K6WFQaTiLuQ3X_fcPTcNYNR7pp_SBks5qHG7ZgaJpZM4G9_jt.
Hi!
Has anyone had any progress on this?
What needs to be done to support 2160p6000 correctly an merge this to the main branch?
Hi Joao,
I have my own fork where I added support to 2160p5000, 2160p5994 and 2160p6000 (in both 2.1.0 and 2.0.7). Tested and working.
https://github.com/aruanoc/CasparCG-Server
The thing that I don't like is the workaround with going to NTSC and back. Otherwise I would have merged a long time ago. Is the workaround still needed with newer drivers? I have no hardware to test this properly on.
I see no workaround in @aruanoc branch.
Maybe it doesn't have those issues with the more recent drivers?
I didn't add the workaround programmatically to avoid future conflicts with future merges. However, we use blackmagic 4K Pros and I can confirm that we do need to have the card set to NTSC when windows boots up and then let caspar reset it to the right video mode on start. Otherwise, we have the issue described by Aurien.
That said, I never got to succesfully upgrade the blackmagic API on 2.0.7 and I haven't tested embedded sound on 2.1.0. So I'm not sure if more recent drivers do the trick.
@aruanoc Make a pull from your branch and I will merge it if it contains no merge conflicts.
I have compiled @aruanoc branch but I have encountered some performance issues. It seems that, for some reason, the machine cannot handle sending the video at 2160p6000. The video stutters a lot. Trying to fix this by increasing the buffer-depth removes the stutter but makes it run at a non-constant speed (fast-slow-fast-slow-fast-slow).
I don't think it's an hardware issue, since I managed to run this on a machine with the following specs: Decklink 4k Pro, Intel i7-6700 @3.4Ghz, Windows 10 64bit, NVIDIA GTX 980TI
Do you guys think there needs to be more changes to fix this?
I don't think it's an hardware issue, since I managed to run this on a machine with the following specs: Decklink 4k Pro, Intel i7-6700 @3.4Ghz, Windows 10 64bit, NVIDIA GTX 980TI
Why couldn't it be a performance problem? What are the specs of the machine that you have problems on?
@HellGore I'll look into that next week.
@joaoportela Are you testing on 2.0.7 or 2.1? Our application runs smoothly in 2160p5994 in 2.0.7, but it does run slow(er) in 2.1 out of the box. We haven't spent much time looking into the performance issues in 2.1 using 4K because we use 2.0.7 in production and it's stable.
Also, we tested the system with NVIDIA GTXs and we ending up using NVIDIA Quadros because their architecture gave us much better performance. We use a NVIDIA Quadro M4000, which is enough for us, but there are far better (and more expensive) Quadros as well.
@HellGore Sorry, the way that I worded that was ambiguous.
It didn't work in the machine with those specs (Decklink 4k Pro, Intel i7-6700 @3.4Ghz, Windows 10 64bit, NVIDIA GTX 980TI). And I expected those specs to be enough.
@aruanoc I compiled the 2.1 branch from your repo. I will cherry pick your changes to 2.0.7 and report back.
@joaoportela ok, that processor only has 16 PCI Express lanes and the Nvidia needs all of them, so I guess there is some kind of bandwidth sharing going on since you have a Decklink requiring 8 PCI Express lanes in addition summing upp to 24 lanes.
Try to use the HD graphics and run without the Nvidia alltogether, then it might actually work better.
@aruanoc I compiled your master branch (2.0.7). Same results.
@HellGore I'll check if it's a PCI lanes issue. It'll be harder to test the HD graphics card because the motherboard I'm using doesn't have the monitor output.
I'm still suspicious if the PCI lanes really are an issue since DaVinci Resolve seems to be able to output a proper 2160p60 video signal (although it is upscaling a 720p60 video).
Will report back with more info soon. :)
@joaoportela, @HellGore made a good point. We've also had bandwidth issues before due to lack of PCI lanes.
@HellGore, I've created the pull requests for both master and 2.1.0. Before doing so, I reverted some changes that I had made to my branch for local compilation and they look clean.