1000 Fundamentals of IP in Broadcast Production

AIMS IP Showcase IBC 2019 September 2019
Curated by Video Services Forum vsf.tv
CURATED BY
Fundamentals of IP
in Broadcast Production
Wes Simpson Ed Calverley
Telecom Product Consulting Q3 Media Training
wes.simpson@gmail.com ed.calverley@q3media.co.uk
+1 203 376 3372 +44 20 3475 0250
https://www.telecompro.tv https://q3mediatraining.co.uk
Tailored
telecompro.tv Technology
IP Video Training Training
and Consulting IP SHOWCASE THEATRE AT IBC2019 : 13 –17 SEPT 2019
Q3MediaTraining.co.uk
© 2019 telecompro.tv & Q3 Media Training – no part of this presentation can be reproduced or repurposed without permission of the authors
Agenda (90-minute Session)
Ed • IP / Networking Basics
Wes • Media Transport Over IP (ST 2110-10/20/30/40 Deep Dive)
Ed • PTP: Timing & Synchronisation
Wes • ST 2110-21 Traffic Shaping
Wes • New parts of ST 2110 (ST 2110-22/23)
Wes • ST 2022-7 Redundant Transport
Ed • JT-NM TR-1001 / NMOS
telecompro.tv Tailored
Technology
and Consulting Q3MediaTraining.co.uk IP SHOWCASE THEATRE AT IBC2019 : 13 –17 SEPT 2019 2
Copyright 2019 - No part of this presentation my be reproduced or repurposed without

permission of the authors: telecompro.tv / Q3 Media Ltd. 1
IP / Networking Basics
Technology
Why IP?
• We must start by recapping the obvious!
• 2 main drivers for switching to IP Infrastructure:
‒ Flexibility
• Reconfigurable & infrastructure not limited by resolution/formats
• Operational functions easier to relocate and evolve over time
• More efficient architectures (don’t simply think about replacing SDI)
• Software on generic IT servers rather than vendor-badged systems
• may have to accept some compromises to change workflow
‒ Costs > Use of more COTS hardware/software
• minimise custom development and branched code makes systems easier to support
• Up-front cost may not be lower (overall lifecycle costs may be lower)
• Move to software-as-a-service (SaaS) – pay only for what you use when you need it!
Technology

COTS Confusion
COTS: Proprietary /
Commercial Off-The-Shelf Bespoke System
• Defined Costs • Variable Costs
• Standards based • Vendor lock-in
• Choice (interoperable) • Interfacing/Conversion
• Generic Features • Custom Features
• Stable • Higher risk of issues
• Supported • Fixed function
• Upgradable • Limited/Costly to evolve
However:
• Not all IP hardware is equal
• Networking for broadcast media production is specialist
telecompro.tv Tailored • Good system architecture & workflow planning is essential
Technology
The Rise of Software

• Dedicated Hardware still strong in production or wherever real-time
processing with low-latencies are important
• Media processing with Software is growing
in capability
• Software enables new architectures that
don’t have equivalents in SDI
• Motivation for vendors is changing to create
products which can be sold in scale
• IP Media Standards need to work
for both software & hardware
Technology

IP is all about Packets!
SDI Signal Routing IP Signal Routing

• Dedicated wire per signal • Multiple signals per wire
• Routed via crosspoint • Packet-level switching
switching • Full-Duplex (bi-directional)
Technology
IP is all about Packets!
SDI is a dedicated link Ethernet links can have higher

with constant data rate data rate so more data can be
SD-SDI: 270Mb/s carried in the same time
HD-SDI: 1.5Gb/s 10GE: 10Gb/s 40GE = 4x10GE
3G-SDI: 3Gb/s 25GE: 25Gb/s 100GE = 4x25GE
Data is sent in packets.

Network Switches &
Routers manage the
sending of packets
across the network
Technology

How do we send data in packets?
• Prepare Data
• Chose Protocol
• UDP
• TCP
• Address it
• Send It
Technology

TCP Header UDP Header
• Prepare Data
• Chose Protocol
• UDP
• TCP
• Address it
• Send It
• Link Handshaking • ‘Fire & Forget’

• Transmission Acknowledgments • Minimal Data Overhead
• Automatic resend on packet loss • Simple error detection
• Perfect for FILES • Perfect for REAL-TIME STREAMS
Technology

• Prepare Data Application Layer

• Chose Protocol
• UDP
• TCP Transport Layer
• Address it
• Send It
Technology

• Chose Protocol
• UDP
• Address it
• Send It Internet Layer
Por
Port: 20
20000 IP A
IP Address:
192.168.0.1 19
Technology


• Chose Protocol
• UDP
• Address it
• Send It Internet Layer
Link Layer
telecompro.tv
IP Video Training
Tailored
Technology
ETHERNET
Training
Example:
Sending SDI Over an IP Network SMPTE ST 2022-6
Name Standard Length
Application Layer
SMPTE 259M,
SDI Serial Digital Interface 1376 Bytes
292M, 424M
High Bitrate Media
HBRMT SMPTE 2022-6 8-16 Bytes
Transport
Not to scale! Reat-Time Transport
RTP RFC 3550 12 Bytes
Protocol
Transport Layer
UDP User Datagram Protocol RFC 768 8 Bytes

Internet Layer
RFC 791 /
IP Internet Protocol (v4/v6) 20 / 40 Bytes
RFC 2460
Link Layer
Media Access Control
MAC IEEE 802.3 42 Bytes
(e.g. Ethernet)
Technology

UDP Multicast
Multicast allows a
second device 239.10.0.25:20000 IGMP Subscribe
sending on the
239.10.0.25:20000
multicast group Network Switch
(same address/port) IP Camera
IP Camera 2
IGMP v3 > Source Specific Multicast
IGMPv3 Introduced Source Specific
Multicast (SSM) which ensures only
multicast packets from a specific source
address are received
Multicast address range to use
SSM may be limited to 232.0.0.1/8
Technology
What are we sending?

SMPTE ST 2022-6 SMPTE ST 2110
2110-20 x 1
2110-30 x16 (e.g.)
2110-40 x3 (e.g.)
1 RTP flow ~20 RTP flows

Technology

Media Transport Over IP

(2110-10/20/30/40 Deep Dive)
Technology
Media Transport over IP

SMPTE ST 2022-6 (‘SDI over IP’)
• Take entire SDI signal and encapsulate it in IP stream
‒ Includes audio and embedded data signals
• Easy to maintain audio/video synchronization
‒ Hard to process just one part of a stream
Data SMPTE 2022-6 IP Packets Data

Audio Video/Audio/Data Audio
De-embed
De-packet
Packetize
Embed
SDI SDI
Video Video
IP Packet Network
Technology

Media Transport over IP

SMPTE ST 2110
• Each media type in a separate packet stream
‒ Easy to process individual components
‒ Signals need to be resynchronized after processing
• PTP (Precision Time Protocol) used for packet timestamping
Data ST 2110-40 Data Data
De-packetize
Packetize
Audio ST 2110-30 Audio Audio
SDI SDI
Video ST 2110-20 Video Video
SDP File IP Packet Network
Technology
ST 2022-6 / ST 2110
Audio Processing Packet Flow
Using SDI/ST 2022-6 Using ST 2110
Audio
Processing Audio
Processing
De-pack/Pack
Data Data
De-packet Packetize
De-packetize
2110-30
Packetize
Data Data Audio Audio Audio

Audio Audio
De-embed
De-packet
Packetize
Embed
SMPTE 2022-6 IP Packets SDI SDI

SDI Video/Audio/Data SDI Video ST 2110-20 Video Video
Video Video
IP Packet Network SDP File IP Packet Network
Technology

How Did We Get Here? – ST 2110 Evolution

Compressed ST 2022-7 Uncompressed
ST 2110-22 ST 2110-21 RP 2110-23 ST 2110-31
TR-01
ST 2110-10 ST 2110-20 ST 2110-30 ST 2110-40
ST 2022-3,4 ASPEN
RDD 37
ST 2022-8 ST 2110
TR-04
ST 2022-5,6 RFC 8331
ST 2022-1,2 TR-03
AES 67
Pro-MPEG CoP3 RFC 4175
IP SHOWCASE THEATRE AT IBC2019 : 13 –17 SEPT 2019 21

SMPTE ST 2110 – Elements (NEW!)
• ST 2110-10 System and Timing

• ST 2110-20 Uncompressed Video
• ST 2110-21 Video Stream Packet Shaping
• ST 2110-30 Uncompressed Audio

• ST 2110-31 AES3 Audio Streams
• ST 2110-40 Ancillary Data
Technology

SMPTE ST 2110 – Elements (NEW!)

• OV 2110-0 Roadmap for the 2110 Document Suite
• ST 2110-10 System and Timing
• ST 2110-20 Uncompressed Video
• ST 2110-21 Video Stream Packet Shaping
• ST 2110-22 Constant Bit-Rate Compressed Video
• RP 2110-23 Single Video Essence Transport over Multiple ST 2110-20 Streams
• ST 2110-30 Uncompressed Audio
• ST 2110-31 AES3 Audio Streams
• ST 2110-40 Ancillary Data
Technology
ST 2110-10
System Timing and Definitions
• Maximum UDP datagram size: 1460 octets, including UDP header
‒ Extended UDP datagram allowed with up to 8960 octets
• SMPTE ST 2059-2 PTP Profile of IEEE 1588-2008
‒ If interchanging audio with AES67, then compatible parameters must be used
• RTP timestamps are tied to the media
‒ For video, RTP timestamps of all packets for video frame are the same
‒ For real-time sources, this should represent the Image Capture Time
‒ For SDI converters, RTP timestamp is moment when video frame alignment
point arrives at device input (SMPTE ST2059-1 defines alignment points)
• All media clocks must have an offset of zero
‒ This makes it easier to recover from loss of signal or unexpected system restart
Technology

ST 2110-20 Video Encapsulation

RTP Payload Header
MAC IP UDP RTP PH pg pg pg pg pg pg pg CS
• Multiple video pixel groups (pgroups)

• RTP Payload Header applied
• Inserted into an RTP packet
• Placed into UDP packet
• IP packet header attached
• Wrapped into Ethernet Frame
Technology
ST 2110-20 Video Encapsulation

RTP Payload Header
MAC IP UDP RTP PH pg pg pg pg pg pg pg CS
• Same idea as before – just draw differently

(and still not to scale!)
Technology

ST 2110-20 Pixel Groups

• Pixels formed into pgroups
‒ pgroup size depends on sampling format
‒ Must be integer number of octets
‒ Pixels that share samples must be in the same pgroup
• Example: 4:2:2 10-bit
‒ 2 pixels in 5 octets
Cb Y Cr Y
1 2 3 4 5
Technology
Pixel Group Sizes

• Every supported video format listed in ST 2110-20 tables
‒ Tables also include order of samples within each pgroup
Technology

ST 2110-20 Video Packet Header

16 Bits • 32-bit Sequence Number
(16 bit Sequence number would wrap in less than half a
V P X CC M PT second for Gigabit-class payloads)
RTP Sequence Number (low bits) • Length of Sample Row Data = Number of octets
RTP Header
from scan line in this datagram. Must be multiple
Time Stamp of pgroup
• F = 0 for progressive scan and first field in interlace
video
Synchronization Source
(SSRC) Identifier • F = 1 for second field in interlace video
RTP Sequence Number (high bits) • Video Line Number = Video scan line number,
RTP Payload Header

starts at 0 for first active line of video (note
Sample Row Data Length (bytes) difference from SDI line numbering)
F Sample Row Data Number (0…n) • C = 1 if more than one line is in datagram,
set to 0 for last line in each datagram
C Sample Row Data Offset (pixels)
• Sample Row Data Offset
= Location of first pixel of payload data within scan line
= 0 if first pixel in scan line; counts by pixels
Technology
ST 2110-20 Sample Row Data
Ancillary Data (VANC) • Packet 0

Packet 0 Packet 1 P2 – Sample Row 0
– Offset 0
Embedded Audio
Packet 2
X 2X
• Packet 1
(HANC)
Active Video
(e.g. 1920x1080) – Sample Row 0
– Offset X
• Packet 2
– Sample Row 0,1
Tailored
– Offset 2X, 0

ST 2110-30 Audio Encapsulation

RTP Timestamp
MAC IP UDP RTP CS
• Multiple Audio Samples (16 or 24 bit)

• Grouped into one RTP packet
• Placed into UDP packet
• IP packet header attached
• Wrapped into Ethernet Frame
Technology
ST 2110-30 Audio
• Based on AES67
‒ 48 kHz, 24-bit linear encoding must be supported in all devices
• Zero Offset Media Clock
‒ Forces all media clocks to be tied to common time base
• Audio Channel Grouping
‒ How audio channels relate to each other in a stream
• Receiver Classifications
‒ Three levels of receiver performance
• Packet size limit 1440 = 1460 – (12 (RTP) + 8 (UDP))
• No need for SIP or other connection management
Technology

Importance of “ptime”
• Audio streams are divided into fixed duration packets
‒ Common size is 1 msec, signaled using “a=ptime:1” attribute
• Number of samples from a channel depends on sampling rate
‒ For example, 48 kHz has 48 samples in 1 msec
‒ Each sample could be 2 bytes (16 bit audio) or 3 bytes (24 bit audio)
‒ Thus, 1 msec of 48 kHz, 24-bit audio is 48 * 3 = 144 bytes
• Number of channels in a packet limited by payload size
‒ Total RTP audio payload is 1440 bytes
‒ Jumbo frames not allowed for audio
Technology
ST 2110-30 Receiver Classifications
Technology

ST 2110-30 Audio
Channel Grouping Symbols
Technology
ST 2110-31 AES3 Audio Streams

• AES3 streams can be used for non-PCM audio applications
‒ Dolby E Compressed Audio is one common application
‒ Other signals defined in SMPTE ST 337/338 (e.g. AC-3 compressed audio)
‒ Has also been used for non-linear audio, one-bit audio and SACD
‒ Also know as AES/EBU Audio
• For these applications, transparent carriage across IP is a must
‒ Cannot change any bits within the stream
‒ Data cannot be interpreted as uncompressed linear audio signals
• ST 2110-31 should NOT be used for linear 16-bit or 24-bit audio
‒ Those should be carried using ST 2110-30 packet streams
Technology

ST 2110-31 Packet Format

• Based on AM824 data format
‒ 32 bit sub-frames, each with 8 bits of signaling and 24 bits of data
‒ Can hold all data plus signaling bits from AES-3 (B, F, P, C, U, V)
V P X CC M PT RTP Sequence Number
RTP Header
Time Stamp (32 bits)
Synchronization Source (SSRC) Identifier
B,F,P,C,U,V data bits AM824 sub-frame 0
Technology
ST 2110-40 Ancillary Data
• Extract ancillary data packets from VANC or HANC

• Captions, time code, ad triggers, etc.
• Place them into RTP packets with custom header
• Line numbers are based on SDI line numbering
• Don’t match 2110-20 line numbers
Ancillary Flag DID SDID DC User Data CS

ANC Data
000 3FF 3FF 41 07 xx SCTE 104 zz
Packet
RTP Header Payload Hdr. Anc. Packet Header DID SDID DC User Data CS
RTP
Seq. #, SSRC 01 Line #, Offset 41 07 xx SCTE 104 zz
Datagram
Technology

ST 2110-40 ANC Packet Format
C Line Number (11 bits) Horizontal Offset (12 bits) S Stream Num (7)
DID (10 bits) SDID (10 bits) Data Count (10 bits)
ANC Packet Payload
ANC Packet Payload
ANC Packet Payload Checksum (10 bits) Padding to 32 bits
‒ Each ANC packet in the RTP payload has its own header
‒ Color channel flag: C=1 – ANC packet is from HD color difference channel. C=0 in all other cases
‒ Line Number and Horizontal Offset refer to SDI raster values
‒ S=1 Multiple streams comprise the format of the original video signal containing the ANC packets
‒ Stream number indicates where the ANC packets were located within a multi-stream signal
‒ DID, SDID, Data Count, Packet Payload and Checksum are exact 10-bit values from ANC packet
‒ For each ANC packet within the RTP payload, padding makes the total number of bits a multiple of 32
Technology
SDP – Session Description Protocol

• Standardized format for describing video and audio content
‒ RFC 4566
• Provides key data needed to process content
‒ Structural metadata for each type of media stream
‒ Connection information for each stream
‒ Clock and timing information
‒ Stream associations for closely coupled streams (ST 2022-7 hitless and RP
2110-23 subdivided streams)
• Text file
‒ Can be accessed through NMOS APIs, other means
Technology

Parts of a Session Description
Session Information
Timing Information
Media Information
Connection Information
Technology
SDP Example
v=0
o=wes 203763372 89 IN IP4 10.201.33.19
s=Example of a 1080i29.97 video signal
t=0 0
m=video 31008 RTP/AVP 101
c=IN IP4 239.201.33.11/32
a=source-filter: incl IN IP4 239.201.33.11 10.201.33.19
a=rtpmap:101 raw/90000
a=fmtp:101 sampling=YCbCr-4:2:2; width=1920; height=1080; interlace;
exactframerate=30000/1001; depth=10; TCS=SDR; colorimetry=BT709;
PM=2110GPM; SSN=ST2110-20:2017;
a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:42
a=mediaclk:direct=0
Technology

PTP
Timing & Synchronisation
Technology
Time / Synchronisation
• Synchronous signals are essential for production to allow clean-
switching/mixing and capture to a common timebase
Date <> Time-of-day <> Frequency <> Phase

SMPTE-309M SMPTE-12M B&B/Tri-Level Sync
‘Offline’ ‘Real-time’
(genlock)
Technology

Time / Synchronisation
• PTPv2 (IEEE 1588-2008)
• Defines mechanism for accurately setting a local clock via exchange of
a few simple messages
• PTP timestamps are 80-bits in size: 48 bits Seconds : 32 bits nanoseconds
• Can handle all our needs from Date/Time Timecode through to
Frequency (Genlock)
• PTP Profiles defined by AES67 / SMPTE 2059-2
(see AES-R-16-2016 for compatibility recommendations)
• Epoc 1970-01-01 00:00:00

NTP – accuracy ~200 micro seconds
PTP – accuracy ~1 micro second We learned from Y2K!
Tailored
48bits is approx. 9 million years!
PTP Architecture PTP ensures all slaves have the same

time regardless of their distance
GPS (signal transit time) from the master
Antenna
PTP Master
PTP Slave PTP Slave PTP Slave PTP Slave PTP Slave
Technology

1-Step Sync with

End-to-End Delay
• Sync Message:
‒ “The time now is XX:XX” (sec:nanosec.)
‒ If slave immediately updated clock to be the
time in the sync message (T1), it would still be
offset equal to the time taken for the message
to transit the link
‒
• Delay Request & Response:

‒ Measures time taken to transit network link
‒ Assumes symmetrical delay
Technology
PTP Implementation Options

Time-Stamping Mechanism
• 1-Step
‒ Accurate timestamp written into packet at the point of egress
‒ Requires precision hardware implementation
• 2-step
‒ Message formed and passed to hardware for egress
‒ Actual time of egress reported and inserted in a follow-up message
• Messages affected:
‒ Sync Message
‒ Peer Delay Response Message (will cover later!)
Technology

2-Step Sync with

End-to-End Delay
• Sync Message:
‒ “The time now is XX:XX” (sec:nanosec.)
‒ If slave immediately updated clock to be the
time in the sync message (T1), it would still be
offset equal to the time taken for the message
to transit the link
‒ Actual time of egress sent in a follow-up
message
• Delay Request & Response:

‒ Measures time taken to transit network link
‒ Assumes symmetrical delay
Technology
PTP Architecture
GPS
Antenna
• Unicast Mode
PTP Master
• Multicast Mode
• Mixed Mode (Hybrid)
Technology

PTP Architecture
GPS
Antenna
• Unicast Mode
PTP Master
Sync/Follow-up Multicast
Delay Req/Resp Unicast
• Multicast Mode
Technology
PTP Architecture
GPS
Antenna
• Unicast Mode
PTP Master
Sync/Follow-up Multicast
Delay Req/Resp Unicast
• Multicast Mode
All messages Multicast
Delay Req/Resp ignored by
other slaves
Technology

PTP Architecture
GPS
Antenna
PTP Master
Network Switch
Technology
Passive Network
Switches
• Any network switch which is not
’PTP-Aware’
• Variable delay can be introduced as
messages transit
• QoS can be used to improve
performance
• The assumption of symmetry used
in the End-2-End delay mechanism
can result in clock jitter
• Passive switches can be used but
their impact needs to be considered
Technology

IEE 1598-2008 defines

the following device Types
• Ordinary Clock
‒ Device with a single PTP port, can be grandmaster-capable or can be slave-only
• Boundary Clock PTP Enabled
‒ has multiple PTP ports, synchronises network segments Network
• End-to-End Transparent Clock Switches
‒ has multiple PTP ports, modify timestamps in PTP messages
‒ residence times measured/added to the correctionField of Sync / Delay_Req (one-step) or
Follow_Up / Delay_Resp (two-step)
• Peer-to-Peer Transparent Clock
‒ has multiple PTP ports, modify timestamps in PTP messages
‒ residence times plus egress-link delays measured/added to the correctionField of Sync (one-
step) or Follow_Up (two-step) messages
• Management Node
Technology
Boundary Clock Network Switch

GPS
Antenna
PTP Master
Slave
Network Switch
Master Master Master Master Master
Technology

Boundary Clock Network Switch

• One port on the network switch
will be a PTP Slave
• All other ports become PTP
Master
• Provides independent links to
downstream clocks
• Allows expansion through
multiple tiers and with common
grandmaster
• Individual links use End-to-End
delay mechanism
Technology
Transparent Clock Network Switch

GPS
Antenna 2 functional modes:
PTP Master
• End-2-End
• Peer-2-Peer
Peer-2-Peer delay mechanism
also requires slaves to be
Network Switch appropriately configured
(Transparent Clock)
Technology

PTP Implementation Options

Delay Mechanism
• End-to-End
‒ Slave measures the delay between itself and the master
‒ Messages: Delay_Req / Delay_Resp
• Peer-to-Peer
‒ Each network element measures the delay between its port and the device on
the other end of the link
‒ Measured delays for each network element added to SYNC message as it
transits between master and slave
‒ Messages: Pdelay_Req / Pdelay_Resp (+Follow-up for 2-step)
Technology
Transparent Clock (TC)

Network Switch (E2E)
• PTP messages can be modified on
the way through the switch
• ‘Residence Time’
(the time spent in the switch)
is measured and added to the
correction field in PTP message:
‒ 1 Step: Sync / Delay_Req
‒ 2-Step: Follow_up / Delay Resp
• Each TC adds its measured value
to correction field value
(i.e. tracks the cumulative delay)
Technology

Transparent Clock (TC)

Network Switch (P2P)
• Peer-2-Peer Delay Mechanism
• Sends/responds to Peer Delay
Request messages on each port
to asses delay on local link
• Residence Time + Peer Delay on
Ingress Link added to Correction
Field
Technology
Real Networks
GPS GPS
Antenna Antenna
Master Master
Boundary Boundary Transparent

Slave
Clock Clock Clock
Boundary
Passive
Clock Slave
Switch
Boundary
Slave
Clock
Slave
Slave Slave Slave
Slave Slave
Technology

Electing a Grandmaster
• Best Master Clock Algorithm (BMCA) is used to elect a Grandmaster
• attributes are evaluated in the following order:
‒ Priority 1 (lowest number wins)
‒ Clock Class (GPS, free-run, etc)
‒ Clock Accuracy (accuracy to UTC)
‒ Clock Variance (jitter and wander)
‒ Priority 2 (lowest number wins)
‒ GMID (similar to mac address)
• These attributes are advertised in the PTP Announce Message
(typically 1 - 4 per second depending on config)
• NB: all other equipment should be set to be PTP Slave only to prevent accidental
election of inappropriate masters
Technology
Equipment Reference with PTP
NETWORK
SWITCH ?
Technology

Switching Packets Requires Buffering
Technology
Switching Packets Requires Buffering
Technology

Wireshark captures showing some 2110-20

flows from different hardware devices
Software processes
typically work with
frame buffers so this
could get a lot worse!
Technology
67
2110-21 Traffic Shaping
Technology

Networking Detail
ST 2110-21 Timing Models
• Senders can’t burst out all of their data at once
‒ Overloads receivers and network switch buffers
• Some variability is necessary
‒ HANC/VANC gaps, software-based senders
Technology
Two Constraints for ST 2110-20

Senders
• Network Compatibility Model
‒ Ensures streams will not overflow buffers inside network devices
‒ Scaling factor β of 1.1 means buffers drain 10% faster than they fill
• Virtual Receiver Buffer Model
‒ Buffer is modelled as input of every receiver device
• Note: Must be included in end-to-end system delay
‒ Packets read from buffer perfectly, based on video format
‒ Buffer not allowed to overflow or underflow
• All senders must comply with both models
Technology

ST 2110-21 Gapped, Linear

Packet Schedules
Tailored Image Source: SMPTE ST 2110-21 Traffic Shaping and Delivery Timing for Video
ST 2110-21 Sender Types

• Three Sender Types: N = Narrow, NL = Narrow Linear, W = Wide
‒ designed for real-time capture and processing

Type N (Narrow) ‒ Maximum required receiver buffer is about 9 packets in gapped mode
‒ Model assumes TROFFSET of a couple of video lines from SMPTE Epoch
‒ Small buffer means limited delay passing through each device in systems
‒ Pixels inside packets “roughly” in sync with pixels in SDI
Type NL (Narrow Linear) ‒ linear version of N
‒ no gaps corresponding to SDI VANC
‒ designed to support software-based video sources

Type W (Wide) ‒ Maximum receive buffer is 720 packets in some popular formats
‒ Larger buffer can handle packet bursts more easily
‒ Bursty transmission is more common to software-based senders
Technology

ST 2110-21
Sender/Receiver Compatibility
• Synchronous Receivers must have clock locked to Sender

• Synchronous Narrow Receivers are only required to work with
Senders that use the default TROFFSET
Technology
New parts of 2110
Technology

Forthcoming: SMPTE ST 2110-22

• Current Title:
“Professional Media over Managed IP Networks:
• Constant Bit-Rate Compressed Video”
‒ Supports CBR compression formats such as VC2
‒ Must be a registered RTP media type as per RFC 4855
‒ RTP Clock rate of 90 kHz
‒ Must conform to either “NL” or “W” network compatibility model of ST 2110-
21; virtual receiver buffer model does not apply
Technology

• Visually lossless compression cannot be seen by observer
‒ Some data must always be removed
‒ Done so as to be invisible to human viewer
‒ Can have very low latency – using slice-based compression
• Popular codecs available
‒ VC-2 DIRAC from BBC – RFC 8450
‒ Also JPEG XS – draft-lugan-payload-rtp-jpegxs-01
• 2:1 to 8:1 compression ratios
‒ 3Gbit/s SDI compressed to 1.5 to 0.5 Gbit/s
Technology


SDP for ST 2110-22
• Format parameters (a=fmtp) statement must include
‒ Image height in lines
‒ Image width in pixels
‒ TP of either 2110TPNL or 2110TPW
‒ Optional value of CMAX if different from default
• Bit rate parameter “b=AS:<bandwidth>“ must be included
‒ Bandwidth is in kilobits/second calculated over one frame period
• SDP must include a frame rate statement, either
‒ a=framerate xx.yy (as a decimal number)
‒ exactframerate=M/N (as a ratio of two integers) in “fmtp”
Technology
Forthcoming: SMPTE RP 2110-23

Recommended Practice
• Working Title:
“Single Video Essence Transport over Multiple ST 2110-20 Streams”
• Idea is to have a system where multiple low-bandwidth streams can
be used to transport one high-bandwidth signal
‒ High resolution streams, such as UHD1/4K or UHD2/8K
‒ High frame rate streams, such as those over 100 fps
‒ Also known as “multiport”
• Each sub-stream is a valid ST 2110-20/2110-21 stream
‒ Timestamps tied to original frames
‒ Comply with timing models
Technology

RP 2110-23 – Three Methods to Split Stream
Temporal Square Division

De-Interleave
Two-Sample
Interleave
Technology
2022-7 Redundant Transport
Technology

2022-7 Hitless Protection Switching

• Send identical signal on two separate paths
‒ Identical packet timestamps, sequence numbers
‒ Receiver aligns packets using buffer
‒ Transit time equal to delay of longest path
• SMPTE 2022-7 Standard
‒ “Seamless Protection Switching of SMPTE ST 2022 IP datagrams”
‒ Published 2013
Path A
Destin-
Source
ation
Path B
Technology
Route Diversity using ST 2022-7

• Diverse routes with SMPTE ST 2022-7 Hitless Protection Switching
East Readout
103
Pointer
East
East
Packet Source
201 200 107 106 105 104 103 102 101

Path 102 101 100 99
Packet Alignment
West Buffers
West Packet Output
201 200 105 104 103 102 101 100 99 Selector (Hitless)
Path
West Readout 103

Pointer
Technology

JT-NM TR-1001 / NMOS
Technology
Standards & Bodies (Related to 2110)

Industry Bodies
Marketing & Education
Joint
Industry Bodies Task
with working groups European Advanced Media Force on
defining specifications Broadcasting Workflow Video Services Networked
Union Association Forum Media
Society of Motion Audio

Standards Picture & Television Engineering
Industry Specific Engineers Society
Internet Institute of Electrical

Standards Engineering and Electronics
General Task Force Engineers
IP SHOWCASE THEATRE AT IBC2019 : 13 –17 SEPT 2019 84


JT-NM TR-1001-1:2018 v1.0
“System Environment and Device

Behaviours for ST 2110 Media Nodes
in Engineered Networks – Networks,
Registration, and Connection
Management”
• The goal of this document is to enable the
creation of network environments where
an end-user can take delivery of new
equipment, connect it to their network,
and configure it for use, with a minimum
amount of human interaction.
telecompro.tv Tailored http://www.jt-nm.org/documents/JT-NM_TR-1001-1:2018_v1.0.pdf

Technology
EBU: “The Technology Pyramid for Media Nodes”

The minimum stack of endpoint technologies to build an IP-based media facility
Widely Partially Rarely
Available Available Available
MEDIA TRANSPORT
Single link video (ST 2110-20)
Software-friendly video receivers (ST 2110-21)
Multichannel, low-latency audio (ST 2110-30)
TIME & SYNC Stream protection (ST 2022-7)
PTPv2 configurable within SMPTE/AES profiles
Multi-interface PTP redundancy
Synchronisation of A/V and data essences
DISCOVERY & CONNECTION
Discovery and registration (AMWA IS-04)
Connection management (AMWA IS-05)
Audio mapping (AMWA IS-08)
CONFIG & MONITORING Topology discovery (LLDP)
IP Assignment (DHCP)
Open configuration management
(e.g. API, config file, SSH CLI etc.)
Open monitoring protocol
(e.g. syslog, agent, SNMPv3 etc.) SECURITY
Security tests (EBU R 148)
Security safeguards (EBU R 143)
Secure HTTPS API calls
Technology https://tech.ebu.ch/docs/tech/tech3371.pdf (Dec 2018)

NMOS
Advanced Media
Workflow Association
• A set of specifications/protocols created by

AMWA’s Network Media Incubator working group
• Developed since 2015 alongside standardisation
of SMPTE ST-2110
(which evolved out of VSF’s TR-03 format)
• Modelled around concepts outlined in JT-NM’s
Reference Architecture document published at
IBC 2015 (http://jt-nm.org/RA-1.0/)
Technology https://amwa-tv.github.io/nmos/
IS-04 Discovery & Registration

• Keeping track of all the flows, what is generating them, and what can
consume them
• Protocols defined for both Peer-to-Peer discovery and discovery via
central Registry
• mDNS discovery (within subnet)
• HTTP-based protocols for Node/Registration/Query API’s (JSON payload)
• Flow properties/parameters via SDP file (RFC 4566)
Technology


• API’s defined Node NMOS Node NETW
by IS-04 Device Registry Device SW
‒ Node SDP Receiver
Sender Flow
‒ Registration Receiver
‒ Query
Node Node
• All devices
should be Device Device
SDP
PTP locked Sender Flow Receiver
Node Node
Device Device Device
SDP Receiver Receiver
Receiver Sender Node Receiver Receiver
Device Device Device Receiver Receiver
SDP Sender SDP Receiver Sender Flow
Receiver Sender Receiver Receiver Sender SDP Flow
SDP
Technology

ode IS-05 Device Connection Management Node
evice Device
SDP
• IS-05 works alongside IS-04 to Receiver
nder provide mechanism to configure CONTROL SYSTEM
Receiver
senders & receivers
• Commands can be ‘staged’
before making ‘active’
IS-04
(e.g. to allow validation)

• Support for applying immediately
or with time offset NMOS
Registry
• Single / Bulk mechanism
(e.g. Salvo routing)
Node Node
Device Device
SDP
Sender Receiver
Flow
Technology
Node Node
Device Device Device
SDP Receiver Receiver
Receiver Sender Node Receiver Receiver
Device Device Device Receiver Receiver
Copyright 2019 - No part of this presentationSDP
my be reproduced
Sender SDP
or Receiver
repurposedSenderwithout
Receiver Sender
permission of the authors: telecompro.tv / Q3 MediaReceiver
Ltd. Receiver Sender SDP 45
SDP
IS-06 Network Control
• IS-06 is an API for interfacing to

an SDN controller CONTROL SYSTEM
(e.g. when using software defined
network routing instead of standard
IGMP-based multicast routing)
IS-06
SDN SYSTEM
Node Node
Device Device
Sender Receiver
Technology
IS-06 is an API for interfacing to

an SDN controller
(e.g. when using software defined
network routing instead of standard
IGMP-based multicast routing)
IS-07 Event & Tally
IS-07 IS-07
• Mechanism to emit and consume states and state changes issued by sources
• ‘GPI for IP’ – General purpose interfacing for buttons/knobs/sliders/displays/lights
• Extensible to carry additional data/values (potentially much more than triggers & tallies!)
• Clients subscribe to message queues (MQTT / Websockets)
• Small message size with very low-latency
• Multiple option timestamps for tracking action/effect times
• Signalling device reboot/shutdown (in addition to general purpose state messages)
Technology
CONTROL SYSTEM

IS-06

Network Media Open Specifications

Id Name Spec Status Version(s) Repository
IS-04 Discovery & Registration AMWA Specification (Stable) v1.3 / v1.2.2 / v1.1.3 nmos-discovery-registration
IS-05 Device Connection Management AMWA Specification (Stable) v1.1 / v1.0.2 nmos-device-connection-management
IS-06 Network Control AMWA Specification v1.0 nmos-network-control
IS-07 Event & Tally AMWA Specification v1.0.1 nmos-event-tally
IS-08 Audio Channel Mapping AMWA Specification v1.0 nmos-audio-channel-mapping
IS-09 System Work In Progress nmos-system
IS-10 Authorization Work In Progress nmos-authorization
MS-04 ID & Timing Model Work In Progress nmos-id-timing-model
BCP-002-01 Natural Grouping AMWA Specification nmos-grouping
BCP-003-01 API Security: Communications AMWA Specification nmos-api-security
BCP-003-02 API Security: Authorization Work In Progress nmos-api-security
n/a Parameter Registers Continuing nmos-parameter-registers
Technology
JT-NM TR-1001 / NMOS at IBC 2019
Successfully met test Successfully met test Manufacturers who have

criteria at interop event criteria at interop event implemented NMOS
held prior to NAB 2019 held prior to IBC 2019 (‘Self-certified’)
Full list of both tests and successful participants here: http://jt-nm.org/jt-nm_tested/
Technology

Thank you
Wes Simpson Ed Calverley
Telecom Product Consulting Q3 Media Training
wes.simpson@gmail.com ed.calverley@q3media.co.uk
+1 203 376 3372 +44 20 3475 0250
https://www.telecompro.tv https://q3mediatraining.co.uk
Thank you to our Media Partners
Tailored
and Consulting IP SHOWCASE THEATRE AT IBC2019 : 13 –17 SEPT 2019 95
Q3MediaTraining.co.uk


1000 Fundamentals of IP in Broadcast Production

Uploaded by

Copyright:

Available Formats

1000 Fundamentals of IP in Broadcast Production

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

1000 Fundamentals of IP in Broadcast Production

Uploaded by

Copyright:

Available Formats

AIMS IP Showcase IBC 2019 September 2019

Curated by Video Services Forum vsf.tv

Agenda (90-minute Session)

Copyright 2019 - No part of this presentation my be reproduced or repurposed without

Copyright 2019 - No part of this presentation my be reproduced or repurposed without

The Rise of Software

Copyright 2019 - No part of this presentation my be reproduced or repurposed without

IP is all about Packets!

SDI Signal Routing IP Signal Routing

IP is all about Packets!

SDI is a dedicated link Ethernet links can have higher

Data is sent in packets.

Copyright 2019 - No part of this presentation my be reproduced or repurposed without

How do we send data in packets?

How do we send data in packets?

• Link Handshaking • ‘Fire & Forget’

Copyright 2019 - No part of this presentation my be reproduced or repurposed without

How do we send data in packets?

• Prepare Data Application Layer

How do we send data in packets?

• Prepare Data Application Layer

Copyright 2019 - No part of this presentation my be reproduced or repurposed without

How do we send data in packets?

• Prepare Data Application Layer

UDP User Datagram Protocol RFC 768 8 Bytes

Copyright 2019 - No part of this presentation my be reproduced or repurposed without

What are we sending?

2110-30 x16 (e.g.)

1 RTP flow ~20 RTP flows

Copyright 2019 - No part of this presentation my be reproduced or repurposed without

Media Transport Over IP

Media Transport over IP

Data SMPTE 2022-6 IP Packets Data

Copyright 2019 - No part of this presentation my be reproduced or repurposed without

Media Transport over IP

Data ST 2110-40 Data Data

Audio ST 2110-30 Audio Audio

SDP File IP Packet Network

Using SDI/ST 2022-6 Using ST 2110

Data Data Audio Audio Audio

SMPTE 2022-6 IP Packets SDI SDI

Copyright 2019 - No part of this presentation my be reproduced or repurposed without

How Did We Get Here? – ST 2110 Evolution

IP SHOWCASE THEATRE AT IBC2019 : 13 –17 SEPT 2019 21

SMPTE ST 2110 – Elements (NEW!)

• ST 2110-10 System and Timing

• ST 2110-30 Uncompressed Audio

Copyright 2019 - No part of this presentation my be reproduced or repurposed without

SMPTE ST 2110 – Elements (NEW!)

Copyright 2019 - No part of this presentation my be reproduced or repurposed without

ST 2110-20 Video Encapsulation

MAC IP UDP RTP PH pg pg pg pg pg pg pg CS

• Multiple video pixel groups (pgroups)

ST 2110-20 Video Encapsulation

MAC IP UDP RTP PH pg pg pg pg pg pg pg CS

• Same idea as before – just draw differently

Copyright 2019 - No part of this presentation my be reproduced or repurposed without

ST 2110-20 Pixel Groups

Pixel Group Sizes