We are a large media company based in Toronto-Canada. We have a project using CasparCG with Blackmagic Decklink cards. The SDI signal feeding the casparCG server has 607/608 CC embedded but are removed before the signal exits the server. Currently, we have to re-embed the closed caption data downstream of the casparCG server. We are looking for a developer to allow casparCG to pass 607/608 closed captions. Please msg to discuss details and compensation.
For curiosity I just googled around a bit and found, that the Decklink 4K Extreme should pass trough CC data, when in internal keying mode. I am not able to verify this, as I live in Switzerland and we do not use CC, so no source material around. But probably that would be worth a try.
We hired a casparCG developer to custom some code for us and they could not fix the issue. It would be nice if this is resolved with a simple fix, but I’m not confident it will. I’m going to check the config on our test server to be sure. Thank you for the info.
I am testing now with a 4K extreme. No dice. Any suggestions on how to make this work? All our stuff is 1080i or 720p mpeg-2 files - all have 608 and 708 captions. Playing out of Redcast with CasparCG 2.07.
<channels>
<channel>
<video-mode>720p5994</video-mode>
<straight-alpha-output>false</straight-alpha-output>
<consumers>
<decklink>
<device>1</device>
<key-device>1</key-device>
<embedded-audio>true</embedded-audio>
<channel-layout>stereo</channel-layout>
<latency>normal</latency>
<keyer>external</keyer>
<key-only>false</key-only>
<buffer-depth>3</buffer-depth>
<custom-allocator>true</custom-allocator>
</decklink>
</consumers>
</channel>
</channels>
Any help would be great, also willing to pay a developer…
Thanks!!
I think there is an incomatibility between CasparCG and 708 captions. I’m less sure about the older 608 captions. CasparCG sets the decklink card to operate as 8-bit RGBA, needed for the mixing and layering operations.
The documentation I have for the Decklink SDK, dated February 2017, has several statements about VNC data. For VNC capture the documentation says:
An application performing VANC data capture should perform the following steps:
IDeckLinkInput::EnableVideoInput
The pixel format that is specified will apply to both active picture and ancillary data with non-4K DeckLink devices.
When capturing ancillary data with a 4K DeckLink device, the ancillary data will always be in the 10-bit YUV pixel format.
The following paragraph describes the steps needed for VNC output:
DeckLinkOutput::CreateAncillaryData
Ensure that the pixel format is appropriate for the type of ancillary data. For example CEA 708 will require a 10-bit pixel format.
A later paragraph talks about the object interface used for Ancillary data:
IDeckLinkVideoFrameAncillary Interface
The IDeckLinkVideoFrameAncillary object interface represents the ancillary data associated with a video frame. CEA-708 closed-captions are encoded with data bits in the 2 least-signficant-bits of each 10 bit pixel component. These bits are not preserved when capturing in an 8 bit pixel format. To capture or output CEA-708 captions, a 10 bit pixel format such as bmdFormat10BitYUV must be used.
The SDK documentation has no references to CEA-608 captioning support. I have not worked with this standard, but one of the challenges seems to be that the active picture area in 525-line systems does not “play nicely” with some DCT based data reduction standards used for video data rate reduction. Commonly deployed DCT-based data reduction requires that the vertical size is a multiple of 16 lines. The selection of which 480 lines are extracted from a 525-line scan video source does not seem well defined (I base that statement on a quick web search). HD systems with 1080 active scan lines also do not integer divide by 16, but the relevant standards add 8 blank lines to the bottom of the 1080 to create an integer divide by 16 mappings.
If you want to pass the incoming signal with an overlay from CasparCG, you should be using internal key mode instead of external keying. This will cause the CasparCG signal to be keyed over the incoming SDI signal instead of originating with CasparCG. Internal keying seems like the only way for the card to pass other ancillary data that CasparCG is not designed to produce.
<keyer>internal</keyer>
I have internal… Not sure where in CasparCG I set it to 10 bit output. The file I am trying to play is a .mpg with both 608 and 708 captions. Any advice would be great, thanks!
Text #1
ID : 4096 (0x1000)-CC1
Menu ID : 1 (0x1)
Format : EIA-608
Muxing mode : A/53 / DTVCC Transport
Muxing mode, more info : Muxed in Video #1
Duration : 28 min 30 s
Bit rate mode : Constant
Stream size : 0.00 Byte (0%)
Language : English
CaptionServiceName : CC1
Text #2
ID : 4096 (0x1000)-1
Menu ID : 1 (0x1)
Format : EIA-708
Muxing mode : A/53 / DTVCC Transport
Muxing mode, more info : Muxed in Video #1
Duration : 28 min 30 s
Bit rate mode : Constant
Stream size : 0.00 Byte (0%)
Language : English
Playing out a mpeg file with captions is slightly different than passing captions already embedded in a live input with the casparCG output overlayed. There has been discussion on this for quite a while on github.
Thanks I have asked the question on that thread earlier too. No reply. Sucks because this limitation basically axes CasparCG for production in North America since captions are required here on all content being broadcasted with a few exceptions (programs under 5 minutes and religious programming)…
It looks like there is some work on processing ancillary data happening also over on this development fork. Closed caption information is a form of ancillary data these days. Hopefully we can find the right people to make this a reality. I know many of us in the US need CC data to work before we can use CasparCG or Sofie for main playout.