One of the things we’ve been spending a lot of time on recently is related to Ad Insertion for broadcasters. This includes providing the appropriate metadata in streams to denote when advertisements should begin and end, as well as information describing which advertisements should be inserted.
This largely delves into the realm of the SCTE-35 specification. While we won’t describe the entire spec here, we will discuss some of the use cases we’ve been working on. You can freely download the full specification from the SCTE website.
The particular use cases we care about involve taking raw HD-SDI feeds from broadcasters in the studio and transporting them across the network. These SDI feeds will typically contain advertising information in the form of SCTE-104 packets. As with the case of SCTE-35, the SCTE-104 spec is rather large and we’re focused on specific use cases. And as with the case of the SCTE-35 specification, the SCTE-104 specification is freely available on their website.
In order to reliably transmit advertising metadata, we need to take the raw SCTE-104 data, convert it to SCTE-35 when we encode the video into a transport stream, and then do the reverse process at the receiving end.
We were hoping to find some good open source libraries or functionality in existing encoding toolkits such as ffmpeg or gStreamer. However surprisingly few such libraries exist. The SCTE-67 specification does refer to an open source SCTE-35 decoding application written in Java, but this is clearly intended just as a decoder/viewer of existing SCTE-35 payloads. Further, while libraries such as VideoLAN’s biTStream project contain some decoding of SCTE-35 packets, it’s focused exclusively on decoding with no functionality for creating SCTE-35 payloads, and the support is nowhere near comprehensive.
Necessity is the mother of invention and I’m happy to announce the general availability of libklscte35. This new library is focused on both encoding and decoding of SCTE-35, and when used in conjunction with our libklvanc library, can convert back and forth between SCTE-35 and SCTE-104. The library is available under LGPL licensing and we’re happy to extend the library through Professional Services as needed.
The library today supports decoding of all of the SCTE-104 “Simple Profile” messages, and the corresponding routines to encode them are being actively worked on and will be completed soon. On the SCTE-35 side, the library contains encoding/decoding functionality for splice_insert (for both Normal and Immediate messages), splice_timestamp, and splice_null. The library does not currently support Component Mode or encrypted payloads (although we may add these in the future if need arises). The library also contains a handful of command line tools for demonstrating decoding/encoding of payloads, including displaying all of the fields that make up the decoded data.
In addition to having a generic decoding/encoding library, we also have patches to VLC which integrate with the library. This allows the user to open a MPEG transport stream containing SCTE-35, and play out the stream over a Blackmagic Decklink output device (such as the DeckLink Duo PCIe card or the UltraStudio Mini Monitor Thunderbolt adapter). The Decklink device will include audio/video as well as the SCTE-104 data encoded in the VANC region. This tool has been instrumental for our testing efforts especially given the cost and limited feature set of commercial H.264 decoders claiming to provide SCTE-35 to SCTE-104 translation.
The following diagram illustrates the basic workflow for libklscte35/libklvanc and how they can be integrated into existing solutions:
Feel free to try and download libklscte35/libklvanc, and send any feedback using the Contact form on this website.
2 thoughts on “SCTE-35 and SCTE-104 VANC Processing”
This sounds awesome. Thanks!
Do yo plan to support FFmpeg in the future?
I’m thinking an encoder based on FFmpeg + Blackmagic Decklink + your lib.
Thanks for writing!
We’ve been considering how the libraries would integrate with ffmpeg (in particular their relatively recent “side data” framework), but we don’t have plans at this time to do any integration. This could change if there is a commercial entity interested in financing the work, but there is nothing on the roadmap currently.