Written by James Taylor Senior Vice President of Cloud Solutions at Ideal Systems

Transcription

1 Interoperability of broadcast devices in COTS IP networks. Written by James Taylor Senior Vice President of Cloud Solutions at

2 Introduction As the SDI epoch draws to a close after dominating the broadcasting world for a generation; the limitations of fixed point-to-point SDI topologies that have long constrained infrastructure designs are consigned to room 0 and a brave new world of software defined IP architectures comes into view. The rise of SDN IP networks as a viable replacement to SDI infrastructure will reshape production & broadcast and further blur the lines between the physical and the cloud. This evolution is facilitated by new standards which define how to transport production quality audio & video signals in IP networks with a level of reliability and accuracy that far exceeds SDI. But IP is not a replacement for SDI, rather software defined video networking represents a higher order topology and thus SDI can not only transit its fabric but can also co-exist as islands of legacy in a sea of IP. The bulk of this paper examines the standards we observed in the 207 Broadcast Asia IP Inter-Op Lab and provides a technical introduction to some of the key concepts. The latter part of the document looks at some the architecture of the Inter-Op Lab and how the new media over IP standards can play a key role in helping broadcasters bridge into decentralized cloud centric architectures. The Inter-Op Lab was established by Asia-Pacific Broadcasting (APB), presented with Broadcast Asia 207 designed and built by. It was supported by ABU, SMPTE and the IABM bodies and a number of equipment manufacturers listed at the end of this paper.. Differences between IP and SDI transport of A/V signals. The ultimate difference between SDI and IP networks is that SDI is a unidirectional bitstream transmitted between directly connected nodes within a network the topology of which is defined only by these connections. Monolithic core routers were used to provide a measure of flexibility by circuit switching to modify the connections between nodes. Node A Node B Node C Node D figure : SDI signal path is fixed and defined by the connections between nodes, data flow is unidirectional and one to one Limitations of Serial Digital Interface as a video transport mechanism Degradation of signal quality on an SDI link results in unrecoverable picture loss; SDI has only error detection no correction is possible. Hardware IO must be correctly configured for a specific SDI format. A mismatch between inputs and outputs will result in a link failure. Connections are point to point, changes can require significant work; specialized cables and connectors are required and new cables must be hand crafted and dressed. SDI data payloads are statically defined and constrained by specifications; no change in payload is possible without changing/updating all devices in the network. Software Defined Video IP Networks IP introduces layered abstractions through the IP stack that enables data encapsulation and routing between nodes anywhere within a network fabric even if they are not directly connected and must use an intermediary node as part of route between source and sink; multiple networks can exist as logical abstractions of the same physical network fabric. Whilst this is simply stated the ramifications of handling video within this paradigm are profound.

3 Physical Fabric Node C Node D Logical Signal Path A Node C Node B Node E Node F Node B Node A Node E Node D Node F Node B Node G Node F Node G Logical Signal Path B figure 2: Logical signal paths as an overlay (right) to a physical network fabric(left). Data flow is bidirectional and can be one to many Software defined networking allows for the dynamic manipulation the network fabric to create layered logical signal paths with a known transit path and latency. Advantages of IP based transport for video signal Signal paths are defined within the network fabric by logical routing, the physical network can be optimized to a specific fabric topology or to reduce cable run lengths, distribute heat loads due to practical limitations etc. Synchronisation signals can easily be propagated, mature timekeeping protocols are available to facilitate the Synchronisation of devices, moreover different framerate signals can coexist within the same network. Forward error correction provides detection and protection from packet loss IP allows two-way communication between nodes so information from a video sink can be relayed back to a video source without an additional communication network. No reconfiguration of links within a network is required to handle different types of data payload; the same network can transport raw HD, Audio only, compressed 4K etc. Device discovery protocols facilitates the rapid integration and configuration of new devices into a system. Fibre & Ethernet cabling are cheap and handle ever increasing data payloads. This results in a reduction in the number and distance of cable runs inherent with IP systems. IP architectures can transport most real-time payloads and data transport protocols form an important element in many of the new AV transport standards that alleviate the need for additional cabling. Signal duplication to serve multiple video end points in IP networks can be achieved via multicasting so each source stream from a node can be assigned multiple sink nodes. Note on Spine-Leaf Topology Networks as a Software Defined Video Network (SDVN) fabric One of the most recent developments in IP network design has been the adoption of the Spine-Leaf topology as a fabric for software defined networking. The Leaf network is a variation of the Mesh topology. The design goal of the Spine-Leaf topology is to optimize the path of traffic traversing between nodes within a spine plane; The leaf layer consists of access switches connecting to device nodes e.g. cameras, encoders and video servers. Every leaf switch is connected to every spine switch in the same plane. Spine switches enable layer 3 switching and serve the sole purpose of routing traffic between leaf switches. Communication between spine planes can be via a core router which eases the joining of spine planes to an existing network. The benefits of this design are highly deterministic, low latency performance and mitigation of bottlenecks at aggregation switches in traditional spanning tree designs. Virtual layer 2 networks are then created as overlays onto the Spine-Leaf fabric by a SDN controller.

4 Leaf L2 switches Spine L3 Switches Core/SDN Controller Spine Planes Spine L3 Switches Leaf L2 switches figure 3: The Sine-Leaf system provides an architecture well suited to SDVN. The SDN controller can monitor the traffic on the spine switches and dynamically reassign routes between leaf switches (or other spine planes) to ensure there are no bottlenecks at a particular spine switch. Because all spine switches are connected to all leaf switches the route may be changed freely with no change of latency to packets traversing within a spine plane the route length is constant. In traditional spanning tree protocol (STP) networks there is relatively little control over how packets transit the network with data often taking inefficient routes through a network resulting in much higher levels of packet jitter. In a Spine-Leaf topology timing protocols like PTP work particularly well due to this ability to constrain the effect of packet jitter. 2. The SMPTE 2022 Standard Suite To transport audio, video and attendant metadata across an IP network a standard is required to define how the data will be packaged and routed within the IP network. The SMPTE 2022 collection of standards has been the most widely adopted approach to handling AV IP transit. ST 2022 currently has 7 sections: Standard ST 2022-:2007 ST :2007 ST :200 ST :20 ST :203 ST :202 ST :203 Function FEC for real-time Audio/Video transport over IP networks Unidirectional transport of constant bit rate MPEG-2 transport streams on IP networks Unidirectional transport of variable bit rate MPEG-2 transport streams on IP networks Unidirectional transport of non piecewise variable/constant bit rate MPEG-2 transport streams on IP networks Forward error correction for transport of high bit rate media signals over IP networks [HBRMT] Transport of high bit rate media signals over IP networks [HBRMT] Seamless protection switching of SMPTE 2022 IP datagrams figure 4: Table of the SMPTE 2022 standard family Note that the form of these SMPTE standard numbers. The form is ST <standard>-<section>:<year revised>

5 ST 2022-[:2007] Defines how forward error correction [FEC] can be utilized to provide data resilience within lossy networks. Different FEC patterns carry an increasing level of overhead but offer increasing resilience, the `FEC data is contained in separate packets of data to the audio/video payload and therefore is not required to process the original transport stream data. This is a core standard that makes IP transport viable in real world networks. FEC is discussed in more detail in section 4. ST [:2007] Defines how constant bit rate MPEG2 transport streams 2 are to be encapsulated within the OSI 7 layer reference model. Datum Unit OSI Stack Layer # payload Standard Transport Host Data Data Data Segments Packets Frames Application Presentation Session Transport Network Data Link (Ethernet) 42 bytes RTP overhead IP bytes UDP 8 bytes RTP 2 bytes TS Packet 88 bytes TS Packet 88 bytes TS Packet Group bytes TS Packet 88 bytes MPEG-2 Part SMPE RFC 3550 RFC 768 RFC 79 / RFC2460 IEEE Bits Physical Bits figure 5: OSI stack with Datagram visualized. A variable number (-7) of transport stream packets each nominally of 88 bytes are combined into an RTP packet. This layer of encapsulation [Session, OSI Layer 5] adds 2 byte overhead but provides sequence numbering so RTP payload can be reconstructed in the correct order. The RTP packet is encapsulated into a UDP packet. This layer of encapsulation [Transport, OSI Layer 4] adds an 8 byte overhead but provides a CRC check for identifying corrupt packets and a destination port number. The UDP packet is encapsulated into an IP packet. This layer of encapsulation [Network. OSI Layer 3] adds a 20 byte overhead but provides source and destination addresses so packets can be routed between nodes within the network. The final layer of encapsulation is wrapping of the IP packets into the network specific transport packet for the link layer of the network. Usually this will mean Ethernet. Ethernet packets [Link & Physical, OSI layers &2] contain a CRC check for detecting corrupt packets in addition to source and destination MAC addresses. Note IPv6 adds an additional 20 bytes to each packet. Ethernet encapsulation adds 42 bytes however the Data Link layer is not part of the 2022/20/TR-03 standards and other link technologies can be exploited by media over IP systems leveraging these standards. The overhead for encapsulation in an IPv4 Ethernet network is always 82 bytes regardless of the payload size. Number of TS packets per RTP packet Payload (bytes) Encapsulation (bytes) Overhead 44 % 2 % 4.5 % 0.9 % 8.7 % 7.3 % 6.2 % 2 Ergo any medium that can be encapsulated by a CBR MPEG2-TS stream can be transported by

6 figure 6: Table showing how encapsulation overheads reduce as the number 88 byte MPEG-TS packets per RTP packet increases. ST [:200] & ST [:20] Defines how variable bit rate MPEG-2 TS encapsulation and unidirectional transport over IP networks. The key constraint is that the spacing between consecutive [MPEG-2 TS] PCR packets is bounded ensuring that the pieces of the transport stream arrive within a certain interval time Defines an extension of to support variable bit rate streams without the constraint of max inter-pcr interval time 3. Note that very few manufacturers support the & 4 standards. The additional complexity and complexity to support VBR signals is largely invalidated by the ability of networks to carry higher payloads & 4 have been excluded from the IABM interoperability testing and it is unlikely these sections of the standard will see much commercial adoption. ST [:203] Expands on and defines larger FEC row/column sets to provide forward error correction to high bit rate data payloads in lossy networks. Note that as the packet rate across the transmission line increases the potential of transit errors increases thus is a key enabler for the transit of uncompressed high bit rate video through a network fabric. ST [:202] Defines a standard for High Bitrate Media Transport over IP networks in real time [HBRMT]. These signals are not MPEG-2 transport streams but rather an encapsulation of the SMPTE 259, 292 or 424 bitstream 4 into HBRMT packets which are then encapsulated into a RTP datagram in the same way as with ; Each HBRMT payload chunk is encapsulated as an RTP packet which is in turn encapsulated as a UDP datagram and finally as an IP packet ready for transport where it is wrapped into a link layer packet, usually an Ethernet packet however just as with the Data Link layer is not specified and both IPv4 and IPv6 encapsulation are valid transport methods for 2022 packets. Datum Unit OSI Stack Layer # payload Standard Transport Host Data Data Data Segments Packets Frames Application Presentation Session Transport Network Data Link (Ethernet) 42 bytes HBRMT overhead IP bytes UDP 8 bytes RTP 2 bytes HBRMT 8-6 bytes SDI chunk 376 bytes SMPTE 259/ 292/424M SMPE RFC 3550 RFC 768 RFC 79 / RFC2460 IEEE Bits Physical figure 7: OSI stack with Datagram visualized. 3 Note that very few manufacturers support the & 4 standards. The additional complexity and complexity to support VBR signals is largely invalidated by the ability of networks to carry higher payloads; the need to optimize for capacity is not worth the computational overhead as higher bitrate CBR signals are easier to work with & 4 have been excluded from the IABM interoperability testing. 4 SMPTE-259 is SD-SDI, SMPTE-292 is HD-SDI and SMPTE-424 is 3G-SDI

7 The RTP Header The RTP header used for is a standard RFC3550 type with no utilization of RTP header extensions: 32 bits V P X CC M Payload Type Sequence Number Timestamp SSRC Synchronization Source 2 bytes Field Name Function Bits V Version RTP Version (always set to 2) 2 P Padding If this bit is true additional non payload padding bytes are used X Extension Are header extensions being used? CC CSRC count The number of Contributing Source Identifiers after the fixed header 4 M Marker Marks the frame boundary is present in this payload if set PT Payload Type Type = 98 for HBRMT and 99 for FEC 7 SN Sequence Number Increments monotonically for each payload sent 6 TS Time Stamp Timestamp of the first byte in the RTP packet 32 SSRC Sync Source ID Randomly assigned ID to identify source 32 CSRC Contributing Source Additional payload, 0-5 additional chunks of 32 bits (not shown) 0-5 x 32 figure 8: The standard RFC RTP packet is used in 2022-/2/5/6 datagram encapsulation. Note that the timestamp in the RTP header is not a standard UTC timestamp as might be encountered in a station sync, instead the networks 27 MHz reference clock is sampled at the start of each media frame and the lowest 32 bits used as the RTP timestamp. For subsequent packets within a frame they are assigned a sequence number that increases monotonically. It is the combination of Timestamp and Sequence number that permits media packets to be re-ordered correctly at the receiving node. The HBRMT Payload Header payload data represents a direct sample of 376 bytes of an SDI stream. To make this data usable some additional metadata describing the source SDI data stream is required. This metadata is carried in the HBRMT header. The HBRMT header is 8-6 bytes of data defined as follows: 32 bits EXT F VSID FRCount R S FEC CF Reserve MAP FRAME FRATE SAMPLE FMT Reserve Video Timestamp [optional] 6 bytes Header Extension [optional] figure 9: The HBRMT packet Field Name Function Bits EXT Extended Header This flag indicates the size of the additional extended payload. 4 F Format Flag Flags if the payload format is indicated in header VSID Video Source ID The video source ID (main, protect, reserved) FRCoun 8 Frame Counter All datagrams of the same frame will have the same number, t R Reference Identifies if the source is reference locked, self locked or UTC locked 2 S Scrambling Payload Scrambling 2 FEC FEC FEC present & type 3 CF Clock Frequency The clock frequency used for the video time stamp 4 Reserve Reserve Reserved for future use 5 MAP SDI Mapping Direct or multi link 4 FRAME Frame Properties Horizontal or vertical, progressive or interlaced 8 FRATE Frame Rate Frame rate 8 SAMPL E Colour Sampling The chroma sub-sampling scheme used 4:2:2, 4:4:4 etc 4 FMT FMT Reserve Reserved 8 VTS Video Timestamp 32 bit timestamp of the first whole pixel in the datagram payload 32 HEXT Header Extension Additional 4 bytes for additional 32 for datagram encapsulation. 3 standard is used

8 The ability of to directly packetize the SDI stream offers broadcasters a key advantage in the adoption of broadcast IP; by introducing ST <-> SDI converters legacy SDI devices can be interoperable with IP devices. This ability to create hybrid SDI/IP architectures allows for gradual introduction of IP into a mature facility or the (re)use of SDI equipment in a greenfield site. However directly encapsulating the SDI bitstream has disadvantages: Audio, Video and VANC/VITC etc. data are wrapped together, the stream must be disassembled and the required elemental stream extracted. This increases the complexity of engineering divergent audio/video/data workflows SDI contains considerable data that is extraneous to each SDI frame; the horizontal and vertical blanking period, the VANC, uncompressed PCM audio channels etc, can account for between 5% and 40% of the payload data in This overshadows the 3% overhead from IP encapsulation but the situation is exacerbated when FEC is applied One key technology that should be highlighted is the availability of encapsulate/unwrap devices that permit a 3G-SDI encapsulator to be hosted on the switch itself. This is made possible by modern low power FPGA technologies that permit IP addressable controllable signal processing services to be embedded into an SFP formfactor cage. The impact on designing hybrid architectures is that high density IP network fabrics can be deployed and ports freely assigned between native IP and SFP IP- SDI gateway nodes without effecting the underlying network fabric. Device Control & Service Management HD-SDI Rx Buffer RTP Encapsulator IP Encapsulator IP TxRx out FEC Generator figure 0:FPGA signal processing embedded into an SFP form factor(right)cage allows /20/TR-03 encapsulation (left) at the IP switch ST [:203] The assumptions with the previous standards is that signal sinks are connected via a single path through a managed network fabric and the limited number of errors or losses in the datagram stream are resolvable by utilizing 2022s error correction. However, FEC is limited in its ability to deal with very lossy networks and certain distributions of packet loss, even on a link with low error rates, can render FEC matrices unrecoverable. Whilst this is not an issue in an optimally provisioned and managed network fabric it is an issue for contribution of 2022 payloads across a lossy inter-network links. With traditional ASI contribution over divergent fibre paths, received signals were buffered at frame syncs to re-align the received signals. An automatic changeover switch would detect various parameters and be able to freely toggle between the two inputs. This process is called seamless redundancy switching and methodology enables this risk mitigation strategy to be applied to 2022 IP media signals in an elegant way.

9 A A X A X X Tx Path A Tx Path B Latency = X msec SLA = 90% Latency = Y msec SLA = 95% Rx Path A Rx Path B Packet selector Good packets selected from Rx Buffers A A B A B B B X B B B B figure : seamless switching of divergent pathed streams allows packet by packet selection at the receiver To transport /2 encapsulated signals reliably between geographically diverse locations where there is potential for large bursts of packet loss or total link failure a redundant path through the network is desired. Consider the example of a live event in a geographically remote area where the two provisioned internet paths are very lossy, often exceeding the capacity of FEC to recover error packets and suffering frequent outages with only 90% and 95% link uptimes observed. Given the poor transmission characteristics of the links a simple AB switch is not sufficient and a mechanism for dynamically picking packets from the stream with the lowest error rate is desired. To meet this requirement defines a technique to synchronize two streams on divergent paths through a network and enabling seamless merging between 2022 datagram streams by reconstructing the output on a packet by packet basis based on RTP timestamps. Tx Path A Tx Path B ea p 2 p pt A A A A A A md A pd A A A Rx Buffer A Rx Buffer B p = Path A transit time p 2 = Path B transit time pd = instantaneous path differential = p - p 2 pt = total transit latency from Tx to reconstruction at buffer output md = max differential determined by total buffer length ea = earliest time a packet can arrive figure 2: The drawing presented is the abstraction used in the specification redrawn here for illustrative purposes. All packets transiting the redundant paths suffer latency dependent on the number and type of intermediate nodes in that route and each route will have a unique path transit time, p and p2. The difference between these latencies is the instantaneous path differential, pd and the incoming receive buffer delay, md, defines the maximum permissible value of the path differential. The earliest time a packet can arrive across the network, ea, summed with the buffer transit time gives the total latency from transmission to reconstruction, pt. The situation is further complicated by the effective jitter in packet timing over these two routes which force larger buffers to be used and increase the effective latency in transporting the signal through the network Seamless Packet Merging The standard specifies the characteristics of 2022 streams and how timing should be handled to realize seamless packet selection at a receiver compliant transmission is achieved by using IGMP multicasts to send two identical RTP streams through different paths. The RTP Timestamp combines with the sequence numbers 5 are used to select packets at the receiver buffer and reorder them correctly because the streams are multicast these two values will be identical. Sequence Numbers from RDP header, all have timestamp of 0xE42A 0 02 X X 03 X 04 X Packet selector Reconstructed sequence for timestamp 0xE42A note the distinction between RTP frame numbers and payloads media- frame number in 2022/20/TR04 streams.

10 figure 3: seamless merge uses RTP sequence and timestamp to select and re-construct the source 2022 packet stream The specification defines a number of profiles which relate principally to the size of pd which determines the effective buffer length requirement: Rx Classification Stream Stream Functional Usecase Rx pd constraint Rx pd constraint Class A Low Skew < 0 ms < 0 ms Intra-facility tielines Class B Medium Skew < 50 ms < 50 ms Inter-facility links Class C High Skew < 450 ms < 50 ms Long haul, high jitter links, figure 4: Receiver Classification Profiles The situation is further complicated by the effective jitter in relative packet timing (skew) over these two routes which results in values for P and P2 tending towards a normal distribution, and by extension force larger buffers to be used and increase the effective latency in transporting the signal through the network. The combined probability distribution for both paths should be considered when attempting to optimize a link for minimal latency. Probability of packet N arriving at a buffer Optimal latency = 35ms Low skew <0ms -20ms -5ms -0ms -5ms 0ms +5ms +0ms +5ms +20ms figure 5: Packet jitter is important when optimizing for latency; In the above example for % confidence buffer latency would be 35ms. 3. Next steps from 2022: Leading the way forward. Due to the limitations of simply packetizing the SDI byte stream the Video Services Forum have published two Technical Recommendations, TR-03 & TR-04, to address these issues and offer an evolution of Note that TR-03 is only concerned with the transport of uncompressed elementary streams 6. VSF TR-03 TR-03 is a very important parallel of the 2022 standards; It amalgamates the recommendations of several (non SMPTE) working groups to define a technique of transporting the elementary components of a media signal as well as attendant metadata as discrete data streams by using a separate encapsulation technique for each elementary type. This allows for different elements to be routed to different devices and removes the overhead associated with simply wrapping and transporting SDI. Key to the success of TR-03 as an amalgamated standard has been the use of the precision timing protocol PTP, defined in IEEE 588, as the common synchronization source for each elementary stream. TR-03 is notable because it moves away from use of proprietary intellectual property and defines an open protocol that is extensible and not tied inextricably with the limitations of SDI itself. There were already a number of mature open standards than covered the elementary components of a media signal that were brought together to form the VSF TR-03 recommendation: 6 The current draft can be found at

11 IP UDP RTP PTP Timestamp RFC 475 IP UDP RTP PTP Timestamp Optional FEC Data IP UDP RTP PTP Timestamp AES67 IP UDP RTP PTP Timestamp IETF ANC29 figure 6: TR-03s standard selection all use RTP datagram encapsulation of open standard payloads Video is packetized using the IETF standard RFC475 7 ; RTP Payload Format for Uncompressed Video:. RFC475 supports the encapsulation of ITU-R BT.60 & BT.656, SMPTE 274M and SMPTE 296M video. RFC475 does not encapsulate SDI. Standard Colour Space Maximum Resolution BT /70 525/625 line, 720 I/P, 080 I/P RFC-475 BT.60/70/2020 Max 32,767px by 32,767px Aspect Ratio Bit Depth 4:3 & 6:9 only 8/0 4:2:0/4:2:2 Colour/Chrominance Encodings Any Any RGB/4:2:0/4:2:2/4:4:4 figure 7: Table showing Vs RFC475 supported video standards Audio is packetized using AES67 which defines an open standard for audio transport over IP networks. AES67 8 supports 44. bits per sample or greater at a maximum latency of 0ms. The AES67 already has established itself in the audio market as AoIP (Audio over Internet Protocol) and this out-of-the-box interoperability with specialized audio devices is a defining advantage over Ancillary or attendant data (metadata rather than the actual AV data stream) is still not finalized but the current draft recommendation proposes adopting the IETF ANC29 draft. Synchronisation of essences at a receiving node uses timestamps in the RTP header which are compared to a reference time base that is distributed to all valid nodes in the network using IEEE 588 precision time protocol [PTP] VSF TR-03 offers significant advantages over the SMPTE 2022 collection of standards, notably SMPTE streams carry the entire HD-SDI stream whereas RFC475 only deals with active pixels that are part of a frame and not blanking etc. This results in dramatic bandwidth reduction in the order of 40% for some video formats. Note that this is not compression, rather only the useful picture data is being transmitted. Inherent with encapsulating each component separately comes the ability to target different end points for each elementary type; assuming separate devices for audio, video and data processing, significant bandwidth is saved compared to delivering a complete stream to each device. This results in greatly reduced load on IP infrastructure. Converting from packetized SDI in to extract and manipulate the elementary streams is simple but computationally expensive. VSF TR-04 TR-04 is a derivative of TR-03 whereby the SDI encapsulation technique defined in SMPTE is used in addition to the elementary streams defined in TR-03 for audio, ancillary data and synchronization. Whilst this does permit routing of stream elements to different sinks it still suffers 7 Detailed discussion of RFC475 is out of scope of this document but the complete standard may be found on the IETF website: 8 Discussion of AoIP and AES67 may be found on the AES website:

12 from highly inefficient bandwidth utilization. It does however provide significant interoperability advantages when bridging between and TR-03/20-20 standards. SMPTE 20 Media Inter-Networking with Separate Essence Flow The SMPTE group is in the process of drafting a new suite of standards under the group name ST- 20. ST-200s sub standards aim to codify the VSF recommendations TR-03/04 as a formal SMPTE standard. The new standard is being supported by AIMS but sadly is not due for ratification until 208. SMPTE 20 is being positioned as the Studio Video Over IP [SVIP] standard. Many manufacturers are still supporting the draft versions of the 20 standard. One important standard that is closely associated with SMPTE 20 but specifically not part of it is the NMOS IS-04 Discovery & Registration framework. 20 and NMOS will be explored in a future paper. Draft Standard ST 20-0 ST ST 20-2 ST ST 20-3 ST ST System Timing & Definitions Uncompressed Active Video Timing PCM Digital Audio Transport Domain Full AES3 Transparent Transport Ancillary Data Transport of SMPTE IP datagrams figure 8: Table showing the current draft standards in the SMPTE 20 family ST-20-0: System Timing and Definitions The use of SMPTE to provide timestamped packets that facilitate the synchronization of remote end-point nodes. SMPTE 2059 and the PTP are examined in further detail in section 5. ST & 2: Uncompressed Active Video & Timing The use of RFC 475 to transport uncompressed video as per TR-03. ST-20-xx: Compressed Video [TBD] The inclusion of this standard in the final suite has not yet been confirmed by the SMPTE standards group 0 however it is slated to cover the transport of compressed J2000 and I-Frame only H.264 video streams. ST-20-30: PCM Digital Audio Transport AES67 is a well established standard for the RTP packetization, transport and synchronization of uncompressed PCM audio streams in an IP network and ST will be an operational subset of AES67 optimized for transporting broadcast audio signals. Synchronisation is based on the IEEE 588 PTP/ SMPTE 2058 protocol. ST-20-3: Full AES3 transparent Transport [TBD] AES67 is concerned with the transport of raw PCM data however AES3, a well established digital audio standard encodes both two channels of PCM data and a sync clock using biphase mark code. The inclusion of this standard has not been confirmed by the SMPTE committee 0. 9 The derivative standard in the SMPTE family of the IEEE588 Precision Time Protocol 0 As of the February 9 th 207 Standards Update published by the SMPTE council

13 ST-20-40: Ancillary Data When only the active pixels of an SDI source are transmitted the ancillary data payload is lost. Ancillary data is non-video data embedded in the SDI bitstream outside of the active picture provides a mechanism for encapsulating and transporting the ANC payload as RTP IP packets. Indications are that this will be RTP transport of ST-2038 data packets leveraging the ability engineer separate data workflows such as subtitle insertion as network services without the overhead of having to engineer an SDI decoder. ST-20-50: Transport of HBRMT Essences ST0-50 is the SMPTE codification of VSF TR-04 and this draft standard has greatly simplified bridging between and and many manufacturers have been quick to provide support for it. The main strength as a bridge is that it allows for a HBRMT encapsulated SDI essence to interoperate within a 20 environment. Note that streams can still benefit from FEC and seamless merge. TR-04/20-50 demonstrate the elegance of the standards and interoperability that has been facilitated by the industry wide considered approach of groups such as the VSF and SMPTE; The TR-04 specification is concerned largely with the SDP parameters and defining the clock source for RTP headers. A note on TICO Compression the SMPTE RDD35 specification and 4K UHD production SMPTE RDD35 provides a framework for using lightweight compression to enable visually lossless transport of 4K over 3G-SDI and by extension this allows an or architecture to handle UHD and 4K. Whilst some are against the use of compression in HBMRT in almost all use cases the tiny errors introduced are irrelevant. Advantages of TICO compression 0 Gbps infrastructure that is already commonplace in modern facilities can transport 3x 260p60 UHD streams. Compression ratios are around 4: which is visually lossless in UHD. For comparison JPEG2000 ratios are typical in the 7: to 30: range. Because it is computationally cheap it TICO compression can be implemented on SFP gateway type devices This standard was originally put in place to define how SMPTE 29M ANC data could be transported in MPEG2 transport streams.

14 4. Forward Error Connection Whilst IP networks support the concept of re-requesting packets of data this is not practical in media signal transport: Real world networks often experience packet loss across the transmission line; for inter-site communications travelling through the internet this problem can be particularly bad The real-time nature of media signals can result in very short windows of opportunity to re-request a packet The potential for hybrid nodes 2 where SDI is being encapsulated by a slave device with a short (or no) buffer for holding packets for retransmission Forward error correction [FEC] attempts to mitigate these issues by sending additional data from the source that allow for the recreation of missing and corrupted packets arriving at the sink. The cost of FEC is increases in latency and the total data propagated through the network. FEC techniques aim to meet one of three goals:. To detect errors in a data stream; classified as error detection codes 2. To detect & correct a finite number of errors in a data stream; classified as error correction codes 3. To detect & correct a finite number of errors in a data stream where the positions of the missing data are known; classified as erasure codes 4. The ST2022 standards prescribe a form of erasure code that promotes interoperability through using a transparent 3, systematic and industry standard methodology. Note that ST2022-/5 does not prohibit the use of higher order encapsulation & error correction being used in point to point links that are part of a network, but to prevent corruption of the ST-2022 payload the original data (payload + FEC packets) must be restored upon egress from the link FEC FEC Link Layer FEC FEC Packet Source Intersite Link Packet Sink figure 0: The use of ST-2022-/5 FEC does not prohibit the use of higher orders of encapsulation and FEC that may be required in point to point links. For example, a SONET 0GbS - OC-92 link could be employed to link an edge site with a central IP studio. The ST-2022 standard is an evolution of the Pro MPEG forum s COP3r2 standard which is a set of recommendations for optimal matrix XOR FEC algorithm of IP video streams, which is turn based upon the RFC 2733 standard for FEC in RTP payloads. 2 A node in the network that has it s SDI output encapsulated into IP by a slave device that assumes the identity of the Master device in the IP network. 3 In a transparent systematic method data is present in its original form and the additional FEC data is transmitted as a discrete data stream that is not required to restore the original data. A Non-systematic method would only send a steam of codewords and would require the FEC decoder to restore the source data even if no data was lost in transit.

15 Basic FEC principle FEC techniques fall into two broad categories; block coding and convolutional coding. Convolutional coding applies to symbol streams of arbitrary length, block coding relies on using fixed sized sets of symbols. IP traffic is particularly well suited to block coding techniques, being of known length p, and the FEC used in 2022-/5 is of this type. The operation of block coding is to divide the output datastream into a series of chunks each of length k symbols and use this to generate FEC codeword chunks of n symbols. The codewords are propagated through the transmission line along with the source data chunks and are received at the sink where they can be used to detect and/or recover loss chunks. There are many different FEC algorithms some of which require transposing from a binary domain to symbols that represent N states, for example the LDCP codes used in DVB-S2, however these impose significant computational overhead and are not suitable for high bandwidth IP network applications based on a binary symbol set /5 Forward Error Correction In the case of 2022-/COP3r2/RFC 2733 the chunks are packets and the symbols are bits and the FEC algorithm that is used is a simple XOR function applied over a 2-dimensional matrix [Width(l) x Depth(d)] of IP packets to generate to generate a stream of parity packets. Each Matrix dimension is limited to 256 packets in and 020 packets in The operation of the XOR is as follows: If a protection set of two packets is defined as {A,B} then the FEC packet, F, can be defined as the XOR of the protection set or F = A B and due to the reversible nature of the XOR function B= F A and A = F B. F = A B figure 2:A FEC packet is a bit by bit XOR of the bits in the contributing packets Note that the intention here is not to enable bit recovery of a corrupted packet but rather the reconstruction of packet(s) that have been lost. Because the input packets are of length p and represents one chunk of length n, the FEC codewords are an XOR of the bits in each packet so the FEC packet have the same length, k. [l,d ] [l 2,d ] [l 3,d ] [l 4,d ] = f d figure 3: One dimensional FEC with the minimum permitted matrix size would add a 25% increase in total traffic A single dimension matrix allows for only one error to be recovered per FEC matrix but packet loss tends to be bursty and a number of consecutive packets are lost. By adding an additional dimension and calculating FEC packets based on the XOR of the packets in each column of the matrix the effect of sequential packet errors can be mitigated: [l,d ] [l 2,d ] Recoverable [l 4,d ] = f d [l,d ] Lost Lost [l 4,d ] = f d figure 4: In single row FEC only a single packet can be lost per matrix 4 For a limit of 6000 datagrams per matrix was set, with the bounds at lxd > 500 for SD, >3000 for HD and <6000 for 3G.

16 [l,d ] [l 2,d ] Recoverable [l 4,d ] = f d [l,d 2 ] Recoverable Recoverable [l 4,d 2 ] = f d2 [l,d 3 ] [l 2,d 3 ] [l 3,d 3 ] [l 4,d 3 ] = f d3 = = = = f l f l2 f l3 f l4 figure 5: Increasing the depth of the FEC matric offers greater resilience to sequential packet errors Selecting FEC dimensions A few simple guidelines can be applied to select an appropriate FEC dimension for a network: FEC works by spreading the probability of an error packet across a larger number of packets so to optimize FEC so where latency is not an issue the matrix size should be increased until the BER of the network prevents the complete recovery of a matrix. For short bursty packet loss scenarios use a network analyzer to determine the worst case for subsequent lost packets through the desired path and select a row width that exceeds this duration. Additional rows add depth to the matrix but add considerable overhead for small matrices; for a 2 by 4 matrix the smallest 2 dimensional matrix size generates 75% as many packets (6) as are present in the protection set(8) so increase the depth as much as possible within the minimum burst error interval; if two burst errors occur within the same matrix the lost packets may not be recoverable. Note that the maximum duration of burst error that can be protected for varies by the standard: for SD the maximum protection length is 33ms, for HD 6ms and for 3G can only offer 3ms of protection. For 3G and beyond becomes increasing important for transport across lossy links. 5. Precision Time Protocol The standards discussed so far describe the mechanisms by which media signals may be efficiently transported in the IP domain as RTP packets. A well-engineered network can provide a stable low latency, low jitter environment but the accurate synchronization of devices operating in the IP domain is a little more problematic. Whilst relying on the internal clocks of nodes for point to point communication of a encapsulated transport stream is sufficient, operating a professional studio or broadcast facility requires every device to be accurately locked to a common reference. This is particularly important in environments requiring stream-switching; the timestamps used in RTP headers require a common source so they can be correctly aligned. Station Synchronisation in traditional SDI environments was easily achieved by slaving a master station clock to the UTC reference transmitted by GPS satellites and the same approach can be taken in the IP domain with some additional benefits due to the bidirectional nature of IP communication.

17 SC Slave Node Master Clock TC Slave Node Grand Master Boundary Clock SC Slave Node SC Slave Node TC Slave Node latency t t 2 Slave Clock t 3 t 4 (t 2 t ) (t 4 -t 3) Offset to correct slave clock = 2 figure 6: PTP provides a Master-Slave standard clock that corrects for network latency (right) and can be used to sync clocks or just master timing frequency or a mix (left) Although many networks provide NTP reference for application level timekeeping this is not accurate enough for use in broadcast IP networks. PTP, the Precision Time Protocol is a mature standard for providing a stable, high granularity master synch in IP networks. PTP is codified as IEEE 588 although the SMPTE group has defined a profile for interoperability in professional broadcast environments under SMPTE NTP Vs PTP (SMPTE ) NTP is stable to ms granularity x 0-3 s, PTP is stable to 00ns granularity x 0-7 s NTP requires a time source node to be polled for a timestamp, PTP is pushed to registered slave devices by master time nodes. In a PTP environment slaves can calculate the transit time of the clock based on exchanging requests with the PTP master to accurately offset their clocks. PTP supports synchronization and syntonization PTP Clock Types PTP provides for three clock types for different network conditions, all slave clocks are derived from the grandmaster clock. Standard Clock Master and Slave communicate, master sends timestamp and slave corrects for path latency. The issue is jitter in the time packets take to transverse the fabric cannot be corrected for. This is not an issue in SDVN using a spine-leaf topology that has a very low jitter in transit latency of the PTP packets. Boundary Clock Facilitate a chain of PTP nodes to be configured that correct for the packet jitter and retransmit to slaves or another boundary clock. This is a useful technique for linking a network segment that suffers problematic levels of latency jitter. Transparent Clock/ Transparent Peer to Peer Clock A transparent clock communicates only a clock tick that allows slave nodes to synchronize internal clocks to the same frequency without taking the time of the Grandmaster or boundary clock. This syncing of internal clock frequencies to a master s called syntronization. PTP made the frame accurate synchronization of all IP devices in the lab a simple procedure. The scale and performance of the Inter-Op lab networks meant only standard clocks needed to be used.

18 6. Considerations for designing IP based Broadcast systems: What the InterOp lab proves Ideal have been involved with a number of IP deployments in addition to the Inter-Op lab at BCA207. One critical factor for large scale IP systems has become very clear; If the network fabric is well designed and makes use of quality COTS hardware many of the possible complications involved with HBRMT in IP are avoided. IP can be adopted by a facility in a piece meal fashion if a logical approach is taken to creating segregated networks and keeping HBRMT traffic constrained to suitable domains. Over the next decade IP will supplant traditional infrastructure so planning for upgrading core networking infrastructure should form the backbone of any new IP solution that is to be deployed Spine-Leaf Fabric Broadcast Lan Native IP Equipment Hybrid Legacy SDI Infrastructure Cloud SaaS Spine-Leaf Fabric Broadcast Lan Native IP Equipment Hybrid Legacy SDI Infrastructure Cloud SaaS Spine-Leaf Fabric Native IP Equipment Hybrid Cloud SaaS figure 7: The next decade will see broadcast migrate to IP based solutions which will increasingly extend into the Cloud The adoption of IP based infrastructure has a number of ancillary advantages that became very apparent during the Inter-Op lab: The BOM for a system consists of far fewer items; the need for patch panels, ref distribution amps etc is greatly reduced. The rack volumes required are significantly reduced although the thermal density of the racks does increase The skillset requirements for engineers is different; it requires a firm grasp of networking and Unix like operating systems. Extending the infrastructure into the cloud with monitoring, analytics and distribution is much simpler to provision for. IP Networks for Professional Media; Design Guidelines Use a spine and lead topology for the network fabric. If multiple sites are involved try and treat each as a separate plane and minimize traffic that needs to transverse between them. Use separate PTP boundary clocks across large networks with multiple zones e.g. studios and production networks to ensure synchronization. Port to port latency across and jitter in this latency are critical in switches being used in a IP fabric, especially a spine-leaf topology. The smaller this latency the better a system scales and PTP clocks require less correction across large networks. Jitter in this latency creates a more deterministic fabric where PTP clocks are more accurate and dynamic load balancing of traffic between spine switches in a SDVN can occur safely without causing delays to HBRMT streams. Investing in quality spine switches is critical.

19 jitter Spine B Spine A Port to port latency Time in μs Spine A Spine B Leaf Leaf 2 figure 8: Switch performance characteristics are critical when architecting a fabric for broadcast media IP streams, port to port Network traffic shaping with QoS helps guarantee critical traffic, such as PTP sync data, is given the highest priority but QoS should not become a crutch for poorly designed or under provisioned networks. Using ST HBRMT the limit for 0Gb/S - infrastructure is 080p60 [3G HD-SDI]. Consider using TICO compression to transport 4K SDI where 40/00Gb/S- infrastructure is not a viable option. When procuring links to transport media signals between facilities care should be taken to ensure the link performance is suitable. Of particular importance will be latency, jitter, packet loss and effective guaranteed bandwidth. Do not forget to account for 2022/20 encapsulation and FEC overheads! 7. IP as a stepping stone to decentralized cloud architectures One major issue that prevents the lift and shift of live broadcast infrastructure into public clouds is the lack of multicast support prevents use efficient use of PTP and although users create virtual, software defined networks the ability how traffic moves through the providers fabric is not available. Although SMPTE-20 works best in a multicast environment it still offers an elegant solution for unicast stream essences in a microservice architecture and as a transport mechanism for high quality streams in and out of the cloud. Studio 260p60 Service jitter =+/- 3.5ms 080i50 Affiliate A 720p60 Affiliate B Service latency 20ms PTP might not be available in public clouds but that should not discourage the experimentation of using public cloud services for use with live broadcast signals. It is proposed that cloud services be modelled as a transmission line with a packet latency and jitter; the average processing time and variation thereof. Whilst PTP timing is not available within the cloud NTP is and that combined with the timestamps in IP payloads could, with some careful design, prove to sidestep the usual issues with synchronization of signals in public cloud. We may also see major cloud vendors start to offer PTP like Time Keeping as a Service to support the broadcast industry. There is great synergy between private cloud architectures and media over IP; Multicast can be supported, spine-leaf networks are ideal for virtual machine hosts and other clustered resources and real-time monitoring of components allows dynamic allocation of resources as needs change.

20 figure 8: Whilst using standards such as 20 in private clouds with FPGA provisioning is the next logical step, much experimentation is needed to see how they can be leveraged in public cloud environments. This concept can be taken even further with the introduction of FPGA servers. A pool of FPGA servers are able to act as network addressable hosts for highly optimized custom FPGA functions allowing for a low latency resource pool that can be dynamically reassigned as different functions are required. FPGA processors are ideally suited for processing high bitrate media signals and can provide elastic compute capacity for: Compression Frame rate conversion High quality scaling Colour correction Audio up/down mix Being able to take advantage of the SaaS marketplace and FPGA-As-A-Service opens up the potential for truly elastic, high bitrate IP based signal processing in public clouds that can provide pop-up infrastructure and make truly decentralized dial-in production in the cloud a reality. This barely scratches the surface of the topic of IP media signals in public and private cloud architectures and certainly provides ample scope for future Inter-Op labs. One area for possible investigation is to leverage the work that has been done in the new standards to allow essences to be routed to different services within a SOA. 20 In 20 Out figure 8: The new standards could play a valuable role in the cloud service marketplace 8. BCA 207 Broadcast IP Inter-Op Lab System Diagram & Notes Architecture Overview The lab was split into two zones, each running a dedicated spine-leaf network. The 20 zone ran on Arista 7 series fabric and the 2022 zone on a Cisco 9 series fabric. Some of the devices were IP native and some elements were hybridized by using Embrionix SFP gateways. A separate SDVN demonstration system was provided by Evertz linked to the 2022 plane via LAWO Remote 4 to simulate IP system interoperability over WAN.

21 figure 9: The 20 plane of the IP lab. figure 20: The Evertz SDVN plane of the IP lab.

22 figure 2: The plane of the IP lab. Conclusions The feedback consensus from Broadcasters who visited the Broadcast IP Inter-OP Lab at broadcast Asia 207 was incredibly positive and appreciative. The Lab demonstrated that whilst there is an initial learning curve when moving to IP, the SMPTE and VSF standards are an elegant solution that are easy enough to grasp once some IP fundamentals are understood. The transition to IP opens up many exciting new architecture opportunities and further blurs the classic hardware/software divide. The Inter-Op lab clearly demonstrated that both and 20 are not just functional and viable but that broadcast infrastructure and the approach to architecting solutions will move incrementally closer to a purely software defined model running on COTS IP fabrics. The interoperability of devices leveraging the new SMPTE standards was beautifully illustrated by the lab. One final noteworthy mention is deserved regarding the rapid deployment of the IP lab. The entire process of building the Broadcast IP Inter-Op Lab took less than two days with no pre-build. These we fixed constraints due to access to the show halls and the time needed to do the physical both construction ahead of setting up the systems. And whilst there were a few minor configuration hiccups the overall experience was that IP offers a significant reduction in the Time to Live for new system builds. For high quality versions of the drawings please visit What next? APB and will be holding seminars in both Hong Kong and Singapore in October which will build on the experience and knowledge learned from the IP Lab and focus on how to migrate to IP based Broadcast Systems. For more information on these seminars APB or Ideal System