The SMPTE ST 2110-40 standard specifies the real-time, RTP transport of SMPTE ST 291-1 Ancillary Data packets. It allows creation of IP essence flows carrying the VANC data familiar to us from SDI (like AFD, closed captions or ad triggering), complementing the existing video and audio portions of the SMPTE ST 2110 suite.
This presentation, by Bill McLaughlin from EEG, is an updated tutorial on subtitling, closed captioning, and other ancillary data workflows using the ST 2110-40 standard. Topics include synchronization, merging of data from different sources and standards conversion.
Building on Bill’s previous presentation at the IP Showcase), this talk at NAB 2019 demonstrates a big increase in the number of vendors supporting ST 2110-40 standard. Previously a generic packet analyser like Wireshark with dissector was recommended for troubleshooting IP ancillary data. But now most leading multiviewer / analyser products can display captioning, subtitling and timecode from 2110-40 streams. At the recent “JT-NM Tested Program” event 29 products passed 2110-40 Reception Validation. Moreover, 27 products passed 2110-40 Transmitter Validation which mean that their output can be reconstructed into SDI video signals with appropriate timing and then decoded correctly.
Bill points out that ST 2110-40 is not really a new standard at this point, it only defines how to carry ancillary data from the traditional payloads over IP. Special care needs to be taken when different VANC data packets are concatenated in the IP domain. A lot of existing devices are simple ST 2110-40 receivers which would require a kind of VANC funnel to create a combined stream of all the relevant ancillary data, making sure that line numbers and packet types don’t conflict, especially when signals need to be converted back to SDI.
There is a new ST 2110-41 standard being developed for additional ancilary data which do not match up with ancillary data standardised in ST 291-1. Another idea discussed is to move away from SDI VANC data format and use a TTML track (Timed Text Markup Language – textual information associated with timing information) to carry ancillary information.
To the uninitiated, it’s not obvious how to send video over IP, what things are important to think about and how close it is to an analogue/SDI signal. Fortunately, Ed Calverley has this excellent tutorial on the basics needed to understand uncompressed video across the board.
This presentation from the IBC 2018 IP Showcase examines the need for timing, a reminder of what ‘blanking’ is and how this is treated in the over-IP world. Discussion of blanking wouldn’t be complete without a discussion of ancillary data (VANC, HANC, DPI, Embedded audio etc.) Whilst blanking was essential in analogue video and is filled with data in SDI, there is a benefit in breaking the signal up into its component parts: video, audio and ancillary data – not least removing up to 30% of dead space; blanking takes bitrate!
Now that Ed’s established the key points of the video which need to be transported, how and where they exist, it’s time to look at how to actually get the data on the network. To do this Ed presents a very accessible explanation of IP discussing how we can split up any message into packets and how we add headers to the packets to ensure they go to the right place. This leads on to a discussion of UDP and TCP, both ways of launching traffic onto a network but with their own pros and cons.
This builds into an examination of subnets, routing and multicast. Whilst these sound fairly academic – and to be clear they can be – they are also essential to a well-founded understanding of the topic and are useful day-to-day when working with SMPTE ST 2110 and SMPTE ST 2022-6 systems. Both of these terms are also explained by Ed along with and comparison of SDI timing (usually black and burst, or tri-Level sync) and PTP timing which is used for IP systems. For more detail on PTP, have a look at this talk, or this one also from the IP Showcase
Wrapping up by talking about the important topic of packet timing called ‘traffic shaping’, we see how important it is to ensure that each packet is equally spaced to avoid problems with buffers on receiving equipment or even within the network itself.
Views and opinions expressed on this website are those of the author(s) and do not necessarily reflect those of SMPTE or SMPTE Members.
This website is presented for informational purposes only. Any reference to specific companies, products or services does not represent promotion, recommendation, or endorsement by SMPTE