I’m the guy who asperi talked about, having offered my services to him.
As he said: I wrote CEA708 passthrough code into a 2.1 fork with a single usecase of outputting it to NDI, we had that working fine besides framerate conversion (this can be solved, though the simplest solution is far from elegant), since our business requirement for it disappeared the code hasn’t been tested further than our lab environment.
I’d disagree with outputting the data via OSC, this creates a lot of issues in the chain and isn’t industry standard. Especially for caption data like CEA708 it makes a lot of sense for the caption data to travel with the frames, this way everything remains perfectly in sync. The simplest place to insert ancillary data produced by CasparCG into SDI is at the source: CasparCG.
Instead I’d opt for a ancillary container that travels along on the frames. That way the same framework for CEA708 can simply be extended to support other formats (OP47 etc.) or even other types of ancillary data all together (for example HDR metadata).
Besides that it can be easily consumed by other outputs besides Decklink this way (i.e.: v210 encoded ancillary lines send as NDI metadata packets).
As for Decklink specifically: newer hardware dropped the requirements for ancillary data to be in the same pixel format as the video data, this can be checked via the BMDDeckLinkVANCRequires10BitYUVVideoFrames attribute ID, if supported the conversion from RGBA to v210 can be entirely skipped, since only the ancillary data needs to then be encoded into v210. Otherwise, when the user configured it CasparCG could fallback to converting to v210 via FFmpeg, or drop an error if that is deemed undesirable. On modern hardware the overhead of conversion to v210 shouldn’t be to high, and we can make sure to only enable it when necessary (BMDDeckLinkVANCRequires10BitYUVVideoFrames evaluates to true AND user has requested via configuration to output vanc data).
That leaves the mixer, I think to start as a proof of concept an ON/OFF mixer command that enables pass through of caption data for a certain layer would be enough, ideally also checking other layers do not have caption pass through enabled, and returning an error if so.
After gleaning at the code I believe framerate conversion has moved out of the mixer mostly (wrt ffmpeg producer), I’m not sure how ffmpeg handles caption data in frames it repeats/drops, so this could be an issue. So anything other than matching framerates would indeed be unsupported territory.