SDI OVER IP

SDI over IP — seamless signal switching in SMPTE 2022-6

and a novel multicast routing concept

Matthias Laabs
IRT

As bitrates increase and equipment prices drop, IP-based communication

technologies – both fixed and wireless alike – are pushing more and more dedicated
communication systems into retirement. The sheer amount of connectors currently
found on professional video cameras make some of the advantages obvious that an
IP/Ethernet-based solution brings. Also, the number of HD SDI signals that you can
squeeze into a 10GigE or even 100GigE line is a convincing argument for medium-
term migration to IP. With SMPTE 2022-6, the wrapping of all SDI formats within IP
will be defined, but previous wrappings were never used to actually do anything in
the IP-layer – they were just used as a transparent channel.
This article outlines the steps and required mechanisms to go “all-IP” and leverage
the possibilities that come with it. The first step to take is to achieve seamless
switching between signals in the IP layer, which was implemented at the IRT as a
software-based Proof of Concept, followed by a novel approach regarding multicast
signal distribution within a network. The applications made possible by these
features are only limited by your imagination.

SDI, IP, SDI-over-IP

The Serial Digital Interface (SDI) is a family of video interfaces standardized by SMPTE including:
 SD (@270 Mbit/s, formally defined in SMPTE 259M);
 HD (@1.485 Gbit/s, formally defined in SMPTE 292M) and;
 3G (@2.970 Gbit/s, formally defined in SMPTE 424M).
As the name indicates, (video) data is transported serially line-by-line, frame-by-frame. Each frame
has vertical ancillary data (VANC) where no video is transmitted and each line also contains horizon-
tal ancillary data (HANC). These usually contain audio, time code and other packetized data,
accompanying the video, which for most cases is transmitted as uncompressed YCbCr 4:2:2 with 10-
bit colour depth. Traditionally, SDI is carried over an electrical interface with 75Ω BNC connectors
but, today, there are optical fibre connectors as well.
In the case of IP-over-Ethernet, the BNC-based 10BASE2 cable has long been superseded by
Twisted Pair, also an electrical connection which is still sufficient for 10GigE speeds. However, and
especially in backbones and for higher speeds, fibre is more common. In contrast to SDI, where the
data is transmitted serially bit-by-bit at a constant rate, IP – the Internet Protocol – is packet-based:
all data is chunked into small packets (usually no more than 1500 bytes) and contains multiple proto-

EBU TECHNICAL REVIEW – 2012 Q4 1/7

M. Laabs
 SDI OVER IP
col layers stacked on top of each other. Each layer consists of a header part and usually the layer on
top of it is the payload. Thus an IP packet starts with several different protocol headers and finally
the innermost layer will contain the actual payload. The entire IP packet is then put inside an Ether-
net frame. The outermost layers (Ethernet, IP) contain address information, for the network to know
where to deliver the packet to, followed by UDP (or TCP) that define which networking socket within
the destination machine should receive the packet. Finally there are application-specific protocols
that contain metadata, timing information, etc. about the actual payload itself.

SMPTE 2022 is a group of standards that specifies the wrappings of professional video into IP.
There is always an even part for the actual wrapping accompanied by an odd part defining forward
error correction (FEC).

SMPTE 2022-2 and SMPTE 2022-4 define the wrapping of the MPEG-2 Transport Stream with con-
stant and variable bitrate, respectively. SMPTE 2022-6, still a draft at the time of writing, will define
the wrapping for SDI (and possibly also compressed and wrapped media formats). It is based on the
Real-time Transport Protocol (RTP) and adds another protocol layer for a high-precision clock and
extra metadata: the High-Bitrate Media Transport Protocol (HBRMT). The layer model of an IP
packet containing SDI according to SMPTE 2022-6 is depicted in Table 1. Each packet contains
1376 Bytes of SDI payload with the last packet of a frame being zero-padded to have each frame
packet-aligned.

Table 1 – SMPTE 2022-6 layer model

Layer Abbreviation Full name Standard Length

Application SDI Serial Digital Interface SMPTE 259M, 292M, 1376
(payload) 424M

HBRMT High Bitrate Media Transport SMPTE 2022-6 8-16 a

RTP Real-Time Transport Protocol RFC 3550 12 a

Transport UDP User Datagram Protocol RFC 768 8

Internet IP Internet Protocol (v4/v6) RFC 791 / RFC 2460 20/40 a

Link MAC Media Access Control IEEE 802.3 42

(e.g. Ethernet)
a. Plus optional fields

The layers (from outermost to innermost) are: Ethernet, IP, UDP, RTP, HBRMT and finally the SDI
payload. Table 2 summarizes the resulting figures for the three common SDI speeds.

Table 2 –Statistics for different SDI formats wrapped in SMPTE 2022-6

SDI format Speed Packets/frame Packets/second Streams

1GigE 10GigE 100GigE
SD@25i 270 Mbit/s 982 24’550 3 33 335

HD@50p 1.485 Gbit/s 2’699 134’950 - 6 60

3G@50p 2.970 Gbit/s 5’397 269’850 - 3 30

Deploying a new technology for the aging SD standard is economically not feasible and the high
bitrates for HD and 3G SDI demand 10GigE equipment, which has not yet entered the consumer
market (and price point) ... but prices for it have dropped to levels that are roughly comparable to
dedicated SDI hardware. Looking at the historical development of Ethernet in Table 3, a shift to
10GigE in consumer commodities would be due, but the limited speeds of consumer broadband and

EBU TECHNICAL REVIEW – 2012 Q4 2/7

M. Laabs
 SDI OVER IP
hard disks make it questionable whether this will happen anytime soon. Nevertheless with the rise of
100GigE technology, prices are expected to drop further.

Table 3 – Historical development of Ethernet standards

Name Standard Speed Published in Consumer

commodities
Ethernet 802.3a 10 Mbit/s 1985 1990s

Fast Ethernet 802.3u 100 Mbit/s 1995 Late 1990s till early
2000s

Gigabit Ethernet 802.3ab 1 Gbit/s 1999 Since mid-2000s

10 Gigabit Ethernet 802.3ae 10 Gbit/s 2003 Not foreseeable

100 Gigabit Ethernet 802.3ba 40, 100 Gbit/s 2010 Probably never

Seamless switching between signals

Switching between two SDI sources must be executed according to RP168-2009 for the down-
stream devices to handle the change seamlessly. Both signals must be synchronized and the actual
switch-over must occur within line 6 (for PAL), 10 (for NTSC) or 7 (for HD). As the SDI frame in IP is
packet-aligned, one can count down from the start of the frame (which is conveniently detectable by
the marker bit in the RTP header) to the switching position. To know the correct switching position,
one needs to know the exact SDI format (which is referenced as Video Source Format in the
HBRMT header) to calculate the packet in which to switch over. This calculation can be done once
for all existing SDI formats and then be stored in a lookup table in the device. Even the shortest SDI
line (NTSC with 2145 Bytes) is much longer than an HBRMT packet’s payload, thus there is at least
one possible switching position per line without the need to cross over the signal within a packet.
This has advantages for hardware and software implementations as only the headers need to be
manipulated; no copy operation from one packet’s payload to another is ever required.
If the SDI-over-IP signals are not received frame-synchronized, buffering of at least one frame is
required to synchronize the sources. In order to have not only the SDI layer switched seamlessly, but
to provide integrity for all layers during and after the switch-over, the system needs to calculate and
add proper offsets for all sequence counters and timestamps in both the RTP and HBRMT layers.

Abbreviations
10GigE 10 Gigabit Ethernet PAL Phase Alternation Line
100GigE 100 Gigabit Ethernet PoC Proof of Concept
DMA Direct Memory Access PTP Precision Time Protocol
FEC Forward Error Correction RAM Random-Access Memory
HANC Horizontal ANCillary data RFC Request For Comments (IETF standard)
HBRMT High Bit-Rate Media Transport RTP Real-time Transport Protocol
HD SDI High-Definition SDI SDI Serial Digital Interface
ICMP Internet Control Message Protocol SFP Small Form-factor Pluggable transceiver
IEEE Institute of Electrical and Electronics SMPTE Society of Motion Picture and Television
Engineers Engineers
http://www.ieee.org SNMP Simple Network Management Protocol
IETF Internet Engineering Task Force SOAP Originally stood for Simple Object Access
http://www.ietf.org/ Protocol, now doesn’t stand for anything –
IGMP Internet Group Management Protocol see http://www.w3.org/TR/soap12-part1/
IP Internet Protocol #intro
MAC Media Access Control TCP Transmission Control Protocol
NTSC National Television System Committee UDP User Datagram Protocol
(USA) VANC Vertical ANCillary data

EBU TECHNICAL REVIEW – 2012 Q4 3/7

M. Laabs
 SDI OVER IP

Regular vs. SDI-over-IP-aware Multicast-IP routing

Multicast-IP is a standard way of carrying out one-to-many communication in IP. The multicast group
to receive a packet is defined by its destination IP address. For both IPv4 and IPv6, there are spe-
cific IP ranges reserved for multicast: Ex.xx.xx.xx for IPv4 and ff00::/8 for IPv6.
Joining or leaving multicast groups is handled 239.0.1.1
by dedicated protocols, namely the Internet Source 1 Regular
Group Management Protocol (IGMP) for IPv4 239.0.1.2 239.0.1.1
Mulcast Sink
and the Internet Control Message Protocol Source 2
(ICMPv6) for IPv6. These protocols do not have
IGMP message from sink
guaranteed answering times and thus do not 239.0.1.1
suffice for exactly synchronized actions such as Source 1 Leave 1
Regular
switching of SDI-over-IP signals. Furthermore 239.0.1.2 Mulcast Sink
the control messages must originate from the Source 2
device that receives the multicast stream.
IGMP message from sink
Hence, controlling the flow of videos across a 239.0.1.1
big network would be difficult to manage for Source 1 Join 2
Regular
classic multicast routing. 239.0.1.2 239.0.1.2
Source 2 Mulcast Sink
Fig. 1 shows how source switching could be
realized with regular multicast IP. At the top, the Figure 1
sink receives data from Source 1 with the IP Regular multicast
Address 239.0.1.1. To change to Source 2, the
sink first sends an IGMP Leave message to
stop receiving data from Source 1 and in a second step sends an IGMP Join (Membership Report)
message to start receiving data from Source 2 at the IP address 239.0.1.2. This results in a discon-
tinuous data flow with changing IP address and random gaps between timestamps and sequence
numbers throughout all protocol layers.
The suggested approach defines two classes of multicast addresses: source addresses and sink
addresses.
Any device that generates a video stream, e.g. a video camera, has a (configurable but) static
source address attached, while a device that receives a video stream, e.g. a monitor, statically joins
one sink address (or more, depending on the device class). According to our proposal, the multicast
router will contain not only the traditional multicast-routing tables (to know on which port which multi-
cast groups are requested) but, additionally, a table to map the sources to sinks. It terminates the
incoming stream with a source address and generates a new stream with a sink address. The exe-
cution of stream forwarding according to this mapping must (especially upon changes) take into
account the above-stated requirements for seamless switching to achieve a continuous valid signal
across all protocol layers up to the SDI pay-
load. Obviously before the switch-over can
239.0.1.1 Re-label IP,
Re-label IP, happen, both multicast sources must be
Source 1
SN and
SN and received at the switch. Thus (if not yet joined),
239.0.2.1
239.0.1.2 mestamp Sink the switch must first join the multicast stream
Source 2 mestamps to which it will switch over to, and wait for the
s
arrival of packets from the said source.
the switching command can
>2 Fig. 2 depicts the process of source switching,
come from any device 1-
where the control message to alter the source
239.0.1.1 can originate from any device and the resulting
Re-label
Re-label IP,
IP, data stream is continuous and error-free
Source 1
SN and
SN and 239.0.2.1 throughout all protocol layers including the SDI
239.0.1.2 mestamp Sink payload.
Source 2 mestamps
s As the proposed source-to-sink mapping can
Figure 2 be controlled by any protocol, e.g., SNMP or
Suggested approach SOAP, it is easy to integrate it into any existing

EBU TECHNICAL REVIEW – 2012 Q4 4/7

M. Laabs
 SDI OVER IP
or new management system. The resulting multicast streams comply 100% with the standard and
therefore not every switch in the network needs to be SDI-over-IP-aware. Theoretically, one central
switch would be sufficient but, for a large network, a distributed approach will be advantageous.

Building SDI-over-IP-aware devices could happen at different levels. Preferably the logic would be
deeply integrated into the devices firmware, but programmable switches could be used to add this
new technology to existing devices. Alternatively, in a totally decentralized manner, the logic might
be shifted into the Small form-factor pluggable transceiver (SFP), this would allow for upgrading the
existing infrastructure, especially if there would also be SFPs that connect to electrical or optical SDI
and do the SMPTE 2022-6 conversion as well.

Proof of Concept
To demonstrate the general
soundness and applicability of
the idea, a software-based Proof
of Concept (PoC) with two Dek-
tec SD-SDI capture and playout
interface cards was realized at
the Institut für Rundfunktechnik
(IRT) in Munich. The PoC con-
sists of three different software
modules: an SDI-to-IP converter
and an IP-to-SDI converter, both
implementing SMPTE 2022-6 on
the IP side and using the Dektec
API on the SDI interface side, Figure 3
Proof of Concept
and thirdly an A-B-switch for
SDI-in-IP.

The PoC, as depicted in Fig. 3, consists of two physical SDI input ports, to each of which an SDI-to-
IP converter is attached. The A-B-switch receives the multicast streams generated from the said
converters and its output is sent to an IP-to-SDI converter attached to a physical SDI output port.
The setup was successfully tested using a Phabrix SX for long-term robustness and correct switch-
over behaviour over several thousand switching operations. A more advanced setup is planned
using newer HD-SDI capture/playout cards.

The computational power needed for the PC-based PoC is very low; mostly the data is moved
around using DMA transfers and only a few header bytes per packet need to be read and modified.
With a static ring buffer, no recurring memory allocations are required, and therefore only the system
load induced by the network stack and the Dektec driver is noticeable. A hardware implementation
within a switch should be possible without upgrading the computational power, as every packet can
be inspected and modified in several layers by professional switches. The memory required for buff-
ering at least one frame per stream (~4 MB for HD) may require RAM upgrades.

Reliability, FEC and error concealment

The UDP/IP protocol on which SMPTE 2022-6 is built is not a reliable protocol. There is no built-in
mechanism to guarantee arrival in the correct order, or even arrival of the packet at all. The order of
packets can be restored through sequence numbering in the RTP layer, but packet loss remains a
problem. Manufacturers claim to be able to build managed networks where packet loss does not
occur as long as the available bandwidth is not exceeded. For lossy networks, SMPTE 2022-5 offers
an XOR-based one- or two-dimensional forward error correction (FEC) scheme. This of course adds
network overhead and, for every step, additional delay and computation power.

EBU TECHNICAL REVIEW – 2012 Q4 5/7

M. Laabs
 SDI OVER IP
A trivial form of error concealment for video can be implemented by using a one-frame buffer (which
is required anyway), that can be utilized to regenerate lost packets using the content of the corre-
sponding packet of the previous frame. For audio or generic metadata, other concealment tech-
niques may apply.

Applications, synchronization and timecode

Developing IP-based solutions Matthias Laabs studied applied computer sci-
can be much faster and ence at RWTH Aachen University and the
cheaper than developing tradi- Czech Technical University (Prague), receiving
tional SDI equipment. Splicing his Dipl.-Ing. degree in 2007. While preparing
in any kind of extra data, such his thesis at Fraunhofer Institute for Applied
as subtitles, to an IP stream will Information Technology, he worked on parallel-
no longer require any dedi- isation of image processing algorithms and
cated hardware, and even add- developed a control system for semi-automatic
ing visual overlays could be cell cultivation.
done right in the IP layer. Also, Since joining the Institut für Rundfunktechnik
conversion from SDI to com- (IRT) in 2007, Mr Laabs has participated in var-
pressed video, e.g. JPEG2000 ious past and present EU research projects on topics such as mobile
or H.264, and back again to interactive TV, 3D TV and hybrid broadcast-broadband distribution.
uncompressed video can be He is heavily involved in several IRT software products for MXF, net-
implemented anywhere to tun- work-quality monitoring and user-friendly switching of DTM networks.
nel through the lower-band- Currently he is also carrying out research on SDI-over-IP and adap-
width networks. tive multicast streaming technologies.

With the rise of the Precision

Time Protocol (PTP/IEEE1588), a UDP/IP-based clock synchronization protocol with up-to-a-nano-
second precision, a possible solution is offered to synchronize SDI-over-IP sources without the need
of additional cables and equipment, such as for the currently used Black Burst or Tri Level Sync.
PTP can run on the same physical cable as the video stream, therefore reducing the infrastructure
complexity, costs and setup-time and, if studio-wide synchronization can be facilitated, the delays
caused through buffering in the SDI-over-IP-aware switches can also be minimized.

This version: 28 November 2012

EBU TECHNICAL REVIEW – 2012 Q4 6/7

M. Laabs
 SDI OVER IP

Published by the European Broadcasting Union, Geneva, Switzerland

ISSN: 1609-1469

Editeur Responsable: Lieven Vermaele

Editor: Mike Meyer
E-mail: [email protected]

The responsibility for views expressed in this article

rests solely with the author

EBU TECHNICAL REVIEW – 2012 Q4 7/7

M. Laabs