server
server copied to clipboard
CasparCG
Update decklink sdk (Rec. 2020 support)
Related: #885
The 10.11 SDK added support for Rec. 2020 conversions. We should update the sdk headers so that it can be used.
We need to make sure that this won't limit the range of supported drivers, as many users have preferences on specific versions that work well and won't want to upgrade unless they need this colour space.
I had some issues where my output from decklink was flickering after a couple of seconds. What I noticed (and reported to BMD) was that using Desktop Video v10.8.2 worked like a charm without flickering and by using Desktop Video v10.9 and higher it started to flicker and only from decklink output.
However I did a lot of tests to find out what the issue was and I found that it's related to the sync used. Using black burst sync with CasparCG in HD with Desktop Video v10.8.2 worked perfectly without any issues (even if HD prefer Tri-level sync). As soon as I updated to Desktop Video to v10.9 or higher (still with black burst sync) it started to flicker and it continued even after all CasparCG processes was removed. The only way to get rid of the flicker was to reboot the machine.
Reason I'm writing this is because BMD may have changed some stuff related to the sync in newer SDK versions which could change the behaviour for some users. I'm waiting for an answer from BMD currently.
Otherwise it seems as a good idea to update the SDK! 👍
Have seen similar issue with flickering in >10.9, and reverted to 10.8.3 on advice from @Julusian as he knew about your current issues.
Have seen similar issue with flickering in >10.9, and reverted to 10.8.3 on advice from @Julusian as he knew about your current issues.
That's correct @jesperstarkar, I have been talking with @Julusian about this issue just to get a second opinion or just see what he thinks. It's really interesting issue and I will find time to put this in the help-repository and in the Wiki. It should also be mentioned in the forum.
I hope you don't mind me chiming in here, but I've just been looking at the SDK for other purposes—I'm trying/intending to implement some basic/static ancillary data on the Decklink consumer output. The 10.11 SDK also allows for the ancillary pixel format to differ from the active-picture pixel format, which is a big step for working with ancillary data (saves everything from having to be 10-bit YUV under the bonnet).
I appreciate that this is a tricky one to handle, as I presume that if CasparCG uses the 10.11 SDK, then it requires Desktop Video 10.11. It's already been pointed out that some users have their own known/stable/preferred versions they use.
Of course, this is all on top of the flickering issue spotted with 10.9!
I hope you don't mind me chiming in here, but I've just been looking at the SDK for other purposes—I'm trying/intending to implement some basic/static ancillary data on the Decklink consumer output. The 10.11 SDK also allows for the ancillary pixel format to differ from the active-picture pixel format, which is a big step for working with ancillary data (saves everything from having to be 10-bit YUV under the bonnet).
I appreciate that this is a tricky one to handle, as I presume that if CasparCG uses the 10.11 SDK, then it requires Desktop Video 10.11. It's already been pointed out that some users have their own known/stable/preferred versions they use.
Of course, this is all on top of the flickering issue spotted with 10.9!
Hello, could you, please, point me to where does Decklink SDK 10.11 allow for different pixel and VANC format ? I am currently trying to add VANC output to an 8 bit video pixel format on Decklink, and it does not work for me, it only works with a 10 bit pixel format. THANKS.
Hi Paul,
I'll look into this. I must admit that my understanding of the newer ancillary-handling capabilities in 10.11 was a bit fresher in my mind back in July than it is now! I've just had a very quick glance at the samples that come with the 10.11.1 SDK and they include one for Closed Captions that use newer ancillary functions/features, but I also see that that example has 10-bit YUV for the video pixel format so it doesn't really prove my understanding of things back in July. I'm sure I sure it quoted somewhere about it supporting VANC output on "other" pixel formats, but I'd have to dig around any remind myself where I'm quoting it from (hopefully I was quoting it accurately).
In the end, we found a different solution to the project we were looking at last year. Instead of adding VANC to CasparCG, we remembered we had some spare data-bridges sitting on the shelf so just wrote a separate/sidecar application to run alongside CasparCG to do the VANC data, and then merged the CasparCG A/V output with the sidecar VANC output with hardware. I appreciate that this doesn't really help anyone--unless you also have spare hardware sitting around, but that's not really the point of an open-source caption generator, to do extra bits outside the box!
I'll have a bit of a play with the Closed-Captions sample in the SDK and see if it'll work with 8-bit pixel formats and retain the VANC functionality. I really hope that I did understand things correctly back in July and haven't lead anyone up the garden path. If it does turn out that 10.11 comes with different VANC-handling functions but still necessitates that the active-picture pixel format is 10-bit YUV, then that's not quite as life-changing as I first thought.
In the meantime, it might be worth a quick look at the Closed-Captions sample yourself and check that you are using the same routines (based on the IDeckLinkAncillaryPacket interface with you implementing the GetBytes/GetDID/GetSDID functions).
Thanks, Bob
Thank you, Bob, for the reply.
The "ClosedCaption" sample is what I have tried. I converted it to 8 bit bmdFormat8bitYUV, adjusted the const kRowBytes. The output works if I disable the call to AttachPacket.
Calling the AttachPacket makes the subsequent call to ScheduleVideoFrame to fail with E_FAIL.
Paul.
Oh no! That's a real pity. It's looking like I was wrong and that the pixel format has to be the same (10-bit YUV) for the active picture and VANC, by the sounds of it. Sorry about that.
I will try to see if I can repeat the issue here (or hopefully not, but that's looking a bit optimistic). I'm away for the next few days, so it'll probably be next week before I get to try again.
Really sorry about this. It's really looking like I've misread the docs.
Thanks for all the help. I am new to this TV/Decklink technologies, so there certainly is a high probability I am doing something wrong.
Paul.
On Mar 12, 2019, at 17:18, Robert Yorke [email protected] wrote:
Oh no! That's a real pity. It's looking like I was wrong and that the pixel format has to be the same (10-bit YUV) for the active picture and VANC, by the sounds of it. Sorry about that.
I will try to see if I can repeat the issue here (or hopefully not, but that's looking a bit optimistic). I'm away for the next few days, so it'll probably be next week before I get to try again.
Really sorry about this. It's really looking like I've misread the docs.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/CasparCG/server/issues/1027#issuecomment-472070194, or mute the thread https://github.com/notifications/unsubscribe-auth/Atrpg3Vb-eyzj3dchYkly5GHWnmudVwAks5vV9NwgaJpZM4U7Cnf.
I doubt you're much newer to this than I am, Paul—if at all! :-) A couple of things to consider, at the risk that these too may be dead ends:-
-
Doing a bit more looking at the docs, I wonder if having a different pixel format for active picture and VANC is only available in the 4k cards (we mainly have HD-only cards, but I might be able to try this out on one of the odd 4k cards we have). I must admit that one paragraph I read give me hope and another in another part of the SDK docs then takes it away. What DeckLink card are you using, out of interest?
-
When you changed to 8-bit YUV, did you change the FillBlue() function to match? This might still be filling in V210 packets (twelve 10-bit words in four uint32_t LE words). Although the fact that disabling AttachPacket() stops the E_FAIL makes me think you've already got this sorted.
-
Bit of a last resort, but have you tried out the ConvertFrame() method? I've not had chance to test this myself, but it may be possible to build your 8-bit YUV frame and convert it to 10-bit in software before scheduling the frame. I guess this must come with a CPU overhead, but might be worth a try.
On another note, we may be at risk of hijacking this thread and going slightly off-topic. Might be worth us opening another if there's somewhere more appropriate for it.
Bob
Robert - maybe we can continue on Blackmagic SDK support forum ? I already posted related question there: https://forum.blackmagicdesign.com/viewtopic.php?f=12&t=87392
On Mar 13, 2019, at 11:35, Robert Yorke [email protected] wrote:
I doubt you're much newer to this than I am, Paul—if at all! :-) A couple of things to consider, at the risk that these too may be dead ends:-
Doing a bit more looking at the docs, I wonder if having a different pixel format for active picture and VANC is only available in the 4k cards (we mainly have HD-only cards, but I might be able to try this out on one of the odd 4k cards we have). I must admit that one paragraph I read give me hope and another in another part of the SDK docs then takes it away. What DeckLink card are you using, out of interest?
When you changed to 8-bit YUV, did you change the FillBlue() function to match? This might still be filling in V210 packets (twelve 10-bit words in four uint32_t LE words). Although the fact that disabling AttachPacket() stops the E_FAIL makes me think you've already got this sorted.
Bit of a last resort, but have you tried out the ConvertFrame() method? I've not had chance to test this myself, but it may be possible to build your 8-bit YUV frame and convert it to 10-bit in software before scheduling the frame. I guess this must come with a CPU overhead, but might be worth a try.
On another note, we may be at risk of hijacking this thread and going slightly off-topic. Might be worth us opening another if there's somewhere more appropriate for it.
Bob
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/CasparCG/server/issues/1027#issuecomment-472368178, or mute the thread https://github.com/notifications/unsubscribe-auth/Atrpg3u79VztfK78ZCVz5dnZ7QWQRFcfks5vWNSLgaJpZM4U7Cnf.
Great. I've tried to continue the discussion there. I have posted a reply, but it's my first so is awaiting moderation/approval. But the general message is that using IDeckLinkVideoConversion::ConvertFrame() worked for me. I created an 8-bit (BGRA, just to be awkward) video frame and converted it to 10-bit YUV before attaching the ancillary data.
Hopefully the BMD-forum post will get approval soon, as this contains a little more detail (although having got this far you're probably able to figure it out in the meantime).
Good luck!