An Introduction to IP Video and Precision Time Protocol 8 JUNE 2016

An Introduction to IP Video and Precision Time Protocol 8 JUNE 2016

The Transition To IP Is Not New Video distribution began the transition from ASI to TS over IP almost 15 years ago IT technology enabled the transition to file-based workflows over 10 years ago Production is the last remaining stronghold for SDI

Why do we still use SDI? SDI works very well indeed Uncompressed content is outstanding quality It does not drop frames Extremely low latency and jitter Frame accurate switching is inherently simple A unidirectional thin protocol that is extremely easy to deploy SDI is an open, non-proprietary and universally supported standard

Why Video over IP? Can use IT-based COTS equipment Economy of scale Reduced cabling cost and weight Much greater flexibility provided by IP routing & networking versus SDI routing & networking Enabler for new workflows such as centralised/downstream production All-IP networks could enable new content and related sources of revenue Scalable - 400G Ethernet under development Scalability driven by bandwidth not ports

What Are The Challenges of Using IP? Latency Jitter Dropped Packets Asynchronous Cisco Nexus 3548 PTP Aware Switch Asymmetric A complex bi-directional set of protocols that requires knowledge of both the source and destination to deploy All are surmountable Trading floor switches deliver latencies <250nS

Video Over IP Methods

Open System Interconnection (OSI) Model Application (Layer 7) SDI Payload, PTP Presentation (Layer 6) SMPTE 2022-6 Session (Layer 5) Real Time Protocol (RTP) Transport (Layer 4) User Datagram Protocol (UDP) Network (Layer 3) Data Link (Layer 2) Physical (Layer 1) Internet Protocol (IPv4 & IPv6) Ethernet Media Access Control (MAC) & Logical Link Control (LLC) 10GigE

User Datagram Protocol (UDP) User Datagram Protocol (UDP) is a unidirectional and connectionless transport layer UDP is basically an interface between IP and upper level OSI layers Unlike the TCP, UDP adds no reliability, flow control, or error recovery functions to IP Requires upper level layers to provide error checking

Real Time Protocol (RTP) RTP is the standard protocol for the transport of real-time data over multicast or unicast networks IP Video applications run RTP on top of UDP The data part of RTP is a thin protocol providing support for applications with real-time properties such as audio and video Including timing reconstruction and loss detection RTP provides time stamping and sequence numbering to handle timing issues and loss detection

Unicast, Multicast and Broadcast Unicast Packets sent from one host to another host Multicast Packets sent form one host to a selected group of hosts Broadcast Packets sent from one host to all hosts in the network

SMPTE ST 2022 Family Of Standards Part 1 - Forward Error Correction for Real-Time Video/Audio Transport Over IP Networks Part 2 - Unidirectional Transport of Constant Bit Rate MPEG-2 Transport Streams on IP Networks Part 3 - Unidirectional Transport of Variable Bit Rate MPEG-2 Transport Streams on IP Networks Part 4 - Unidirectional Transport of Non-Piecewise Constant Variable Bit Rate MPEG-2 Streams on IP Networks Part 5 - Forward Error Correction for Transport of High Bit Rate Media Signals over IP Networks (HBRMT) Part 6 - Transport of High Bit Rate Media Signals over IP Networks (HBRMT) Part 7 - Seamless Protection Switching of SMPTE ST 2022 IP Datagrams

SMPTE ST 2022-6 SMPTE ST 2022-6 is an SDI payload carried over RTP/UDP RTP provides time-stamp and sequence numbering Synchronisation is provided using IEEE1588 PTPv2 (SMPTE 2059-2) Source IP Address Dest IP Address SMPTE RTP Headers SDI Payload SMPTE ST 2022-6 IP Packet Format (Single IP Stream Can Carry Video, Audio and Metadata)

ST 2022-5 Forward Error Correction SMPTE ST 2022-5 Row/Column FEC P1 P2 P3 P4 P5 FR1 P1 Video Data Packets P6 P7 P8 P9 P10 FR2 FR1 FC1 Row FEC Packets Column FEC Packets P11 P12 P13 P14 P15 FR3 P16 P17 P18 P19 P20 FR4 Fc1 Fc2 Fc3 Fc4 Fc5 FEC creates additional redundant packets used to correct errors in the video data packets Trade-off between error recovery ability, extra bandwidth required, extra processing needed and the associated receiver latency caused

ST 2022-7 Seamless IP Protection Switching Switches use IGMP multicasts Clean switch RTP packets using frame numbers Can tolerate complete failure of one path Doubles network bandwidth Sender Receiver Stream Sender M 3 2 1 IP Switch Main 3 2 1 Duplicate Stream B 3 2 1 IP Switch Backup 3 2 1 Packet Selection 3 2 1

ST 2022-7 Seamless IP Protection Switching Switches use IGMP multicasts Clean switch RTP packets using frame numbers Can tolerate complete failure of one path Doubles network bandwidth Sender Network Failure Packet Loss Receiver Stream Sender M 3 2 1 x IP Switch Main x x 3 2 1 Duplicate Stream B 3 2 1 IP Switch Backup 3 2 1 Packet Selection 3 2 1

Video Services Forum TR-03 Separates Video, Audio and Metadata Essence Uses Essence over RTP/UDP Supports IEEE1588 Default PTP Profile and SMPTE ST 2059-2 PTP Profile Source IP Address Dest IP Address RTP Header Video Payload (RFC 4175) Source IP Address Dest IP Address RTP Header Audio Payload (AES 67) Source IP Address Dest IP Address RTP Header Metadata Payload (IETF Draft) VSF TR-03 IP Packet Formats (Dedicated IP Streams Carry Video, Audio and Metadata)

Video Services Forum TR-04 TR-04 Defines how to interoperate SMPTE 2022-5, 2022-6 and 2022-7 within a VSF TR-03 environment Describes the interoperation of SMPTE 2022-6 media flows with VSF TR-03 media flows Describes the integration of SMPTE 2022-5 (FEC) and 2022-7 (Protection) into Session Description Protocol (SDP) Describes a set of constraints that together form a Studio Profile Well-formed SDI signals compliant with the relevant SMPTE standard Receiving devices shall be tolerant of the presence of SMPTE 2022-5 and 2022-7 datagrams if they are transmitted

Evertz ASPEN Separates Video, Audio and Metadata Essence Uses MPEG Transport Stream over RTP/UDP Compatible with SMPTE ST 2059-2 PTP Synchronisation Source IP Address Dest IP Address MPEG-2 TS Video Payload (SMPTE RDD 37) Source IP Address Dest IP Address MPEG-2 TS Audio Payload (SMPTE 302) Source IP Address Dest IP Address MPEG-2 TS Metadata Payload (SMPTE 2038) ASPEN IP Packet Formats (Dedicated IP Streams Carry Video, Audio and Metadata)

12G into 10G Won t Go! Light Video Compression

What Is The Impact Of 4K/UHD, HDR and HFR? An uncompressed 50 fps UHD 4:2:2 video element will (just) fit into a 10GigE IP flow (60 fps will not) SDI of course requires 12Gbps The deployment of UHD/4K will likely lead to the adoption of lightly compressed video over 10G IP 10-bit High Dynamic Range video has minimal impact on bitrate in production workflows 12-bit HDR results in an approximately 20% increase in bitrate over SDR High Frame Rate 4K/UHD (100/120fps) requires light compression for affordable (10GigE IP) deployment

Light Video Compression Light Video Compression is required to fit more data into a 10GigE pipe Compression is a trade off between Latency, Compression Ratio and Picture Quality LLVC Sony Low Latency Video Codec is being proposed to SMPTE as RDD 34 TICO Intopix Tiny Codec is being proposed to SMPTE as RDD 35 VC-2 BBC R&D Dirac Pro is standardised as SMPTE ST 2042

Light Video Compression LLVC, TICO, VC-2 All are intra-frame coded and use wavelet compression All are designed to deliver extremely high quality video at low levels of compression (~4:1) with low latency Block transform codecs (MPEG-2, H.264, HEVC etc.) deliver high levels of compression at the expense of high levels of complexity/latency Wavelet-based codecs deliver lower levels of compression for high quality or lossless applications, but with much lower levels of complexity/latency Wavelet Transform Predict DC Coefficients Partition Into Slices Scale Coefficients Quantise Variable Length Coding VC-2 Signal Processing Chain

Precision Time Protocol (PTP)

What is PTP? Ethernet-based networks are inherently asynchronous Precision Time Protocol (IEEE 1588) is intended to synchronise the real-time clocks of different nodes on an Ethernet network PTP does not make the network itself synchronous (as is the case with Synchronous Ethernet also referred to as SyncE). The most recent version is IEEE 1588-2008, also known as PTP version 2 SMPTE recently released a standard based on PTP version 2 specifically intended for broadcast video applications SMPTE ST 2059

PTP Terms and Definitions PTP Domain Logical grouping of clocks that are synchronised to each other using PTP, but may not be synchronised to other clocks in another domain Grandmaster Clock Ultimate source of time for clock synchronisation using PTP In broadcast applications, these are usually synchronised to GPS, GLONASS or both Master Clock A clock that is the source of time to which all other clocks in that domain are synchronised Slave Clock A clock that is synchronised to another clock GM Domain 1 Domain 2 S M M S

Relevant Standards IEEE 1588-2008 Standard for a Precision Clock Synchronisation Protocol for Networked Measurement and Control Systems SMPTE ST 2059-1 2015 Generation and Alignment of Interface Signals to the SMPTE Epoch SMPTE ST 2059-2 2015 Profile for Use of IEEE-1588 Precision Time Protocol in Professional Broadcast Applications AES67-2015 AES standard for audio applications of networks - High-performance streaming audio-over-ip interoperability

SMPTE ST 2059 SMPTE ST 2059-1 Defines SMPTE Epoch the same as IEEE-1588 Date 1970-01-01 Time 00:00:00 TAI (Temps Atomique International) International Atomic Time SMPTE ST 2059-2 PTP Profile is designed to: Enable a slave to be synchronized within 5secs Maintain network-based time accuracy between slave devices to within 1μs

PTP Message Types Announce Used to establish the synchronisation hierarchy Provides the clock status and clock criteria used to determine which clock becomes the Grandmaster Sync and Follow Up Transmitted by the Grandmaster and used by the Slaves to derive the time Delay Request Request for timing information sent from Slave to the Grandmaster in order to determine the propagation delay between the Slave and the Grandmaster Delay Response Time of receipt of the Delay Request message sent by the Grandmaster back to the Slave

PTP Message Types Announce IP Address Multicast Address

Keeping PTP Simple The Grandmaster periodically transmits Sync messages Slaves use these Sync messages to derive the time Delay in IP networks is both variable and asymmetric (different in forward and reverse paths) Slave devices must periodically send Delay Request messages to the Grandmaster The Grandmaster time-stamps the time of receipt of the Delay Request message and sends this to the Slave as a Delay Response massage The Slave device can now derive the difference between its own clock and that of the grandmaster

PTP in Pictures Master Clock @ 11:00 Slave Clock @ 11:05 Sent 11:00 T2-T1 = Master_To_Slave Δ t = 6 Mins T1 Sync Message Sync Follow Up Message T2 ARR 11:06 (Timestamped @ 11:00 therefore Propagation Delay = 1 min) Time ARR 11:02 T4 Delay Request Message T3 Sent 11:06 T4-T3 = Slave_To_Master Δ t = -4 Mins Delay Response Message (Timestamped @ 11:02) PTP Master-Slave Messages Offset = (Master_To_Slave Δ t Slave_To_Master Δ t )/2 = 5 Mins Oneway Delay = (Master_To_Slave Δ t + Slave_To_Master Δ t )/2 = 1 Min

Best Master Clock Algorithm (BMCA) Provides resilience by allowing the most accurate clock to take over in the event that the current Grand Master is unable to continue: Loses GPS lock Becomes disconnected from the network Unable to act as Grand Master for any other reason The BMCA runs on all clocks in the network

BMCA Criteria BMCA list of criteria 1. Priority 1 Field (lowest value <= 128 wins) 2. Clock class (e.g. GPS locked or free running) 3. Clock accuracy 4. Clock variance (jitter and wander) 5. Priority 2 Field (lowest value <= 128 wins) 6. Tie-breaker is Clock Source Port ID (usually the Ethernet MAC address) Announce message from better master Slave Power On, Reset Listen No announce message from better master Announce message from better master Determining Master/Slave Clock State No announce message from better master Grandmaster

Best Master Clock Algorithm (BMCA) Switch defaultds.priority1 = 128 defaultds.priority2 = 127 Router Router Router defaultds.priority1 = 128 defaultds.priority2 = 120 I am Grandmaster Switch defaultds.priority1 = 128 defaultds.priority2 = 126 Switch Switch defaultds.priority1 = 128 defaultds.priority2 = 126

Main and Backup Grandmaster Failover The Priority 2 Field is used to identify primary and backup clocks between two (or more) identical redundant Grandmasters Main Grandmaster Priority Field One = 128, Priority Field Two = 127 Backup Grandmaster Priority Field One = 128, Priority Field Two = 128 Domain 1 If both identical Masters are locked to GPS, they will have the same clock quality, so the lowest Priority Two Field value will select which is the Grandmaster If the Main clock loses GPS lock, then the Backup clock becomes the Better Master and will take over as Grandmaster S PF1 = 128 PF2 = 127 S GM (main) S GM (backup) S PF1 = 128 PF2 = 128 S

PTP Clock Types - 1 Ordinary Clock End Device on a network (not a switch or router) 1. Slave only Clock (never acts as a Master) 2. Preferred Grandmaster (never acts as a Slave) 3. Master/Slave Clock (can be either)

PTP Clock Types - 2 Transport Reserved Type Version Transparent clock Accounts for queueing delays in switches or routers Hardware time stamps Sync and Delay Request messages on arrival and departure and adds the difference to a correction field in the message header Boundary Clock Receives time from a Master on one Slave port Provides Multiple Master (not Grandmaster) ports to downstream Slaves in a domain Removes the effect of its own queue N.B. Switches/Routers in a PTP network must be PTP aware (Must be either a Transparent Clock or a Boundary Clock) Length Domain Reserved Flags Correction Field Reserved Source Port Sequence ID Control Log Time Stamp Sync/Delay Request Message Format

PTP Clock Types In A Network PTP Grand Master Ordinary Clock GM Sync Message PTP Domain 1 Sync Message (with correction) Router Transparent Clock S Camera Ordinary Clock (Slave) S Sync Message (with correction) PTP Master - Boundary Clock M Sync Message PTP Domain 2 S Camera Ordinary Clock (Slave)

Summary IP offers both opportunities and challenges to broadcasters It is necessary to gain a basic understanding of IP to be successful with deployment There is a need for open interoperability, as there are currently multiple methods for the transmission Video over IP Networks Standards are developing for lightly compressed Video over IP which will be driven by 4K/UHD and HFR deployment PTP provides the necessary synchronisation required to use IP in live production workflows The transition to IP will be gradual and Hybrid SDI/IP workflows will exist for the foreseeable future

Questions?