Tema 6_Transporte de contenidos en IP ST.2110, ST.2022. Especificaciones NMOS de AMWA PDF

Transporte de contenidos en IP ST.2110, ST.2022. Especificaciones NMOS de AMWA Máster de formación permanente en ingeniería de producción y explotación de contenidos José Manuel Menéndez Catedrático de la ETSIT-UPM Departamento de Señales, Sistemas y Radiocomunicaciones E.T.S. Ingenieros de Telecomunicación Universidad Politécnica de Madrid Contents 2. Current standards for content transport over IP 1. Basic multimedia transport concepts RTP protocol Quick review on SDI SMPTE ST-2022-6 Why moving to IP networks? SMPTE ST-2110 What is IP Fabric? PTP synchronisation Basic differences between SDI vs IP Fabric NMOS specifications from AMWA 2 / 76 Basic multimedia transport concepts Contents 2. Current standards for content transport over IP 1. Basic multimedia transport concepts RTP protocol Quick review on SDI SMPTE ST-2022-6 Why moving to IP networks? SMPTE ST-2110 What is IP Fabric? PTP synchronisation Basic differences between SDI vs IP Fabric NMOS specifications from AMWA 3 / 76 Basic multimedia transport concepts Introduction ▶ Content production and operation centres have traditionally been designed and implemented around SDI links (oriented to audiovisual signal transport streams) for transport, monitoring, editing, multigeneration, etc. ▶ SDI networks guarantee point-to-point connectivity on each network link: ▶ between cameras and the video switching matrix ▶ between the matrix and the signal mixers ▶ between the mixers and the storage systems ▶ etc. 4 / 76 Basic multimedia transport concepts Introduction FLUJO DE TRABAJO GENERAL ▶ Example: General workflow description of Castilla La Mancha TV (TM Broadcast, February 2018): 5 / 76 Basic multimedia transport concepts Quick review on SDI Contents 2. Current standards for content transport over IP 1. Basic multimedia transport concepts RTP protocol Quick review on SDI SMPTE ST-2022-6 Why moving to IP networks? SMPTE ST-2110 What is IP Fabric? PTP synchronisation Basic differences between SDI vs IP Fabric NMOS specifications from AMWA 6 / 76 Basic multimedia transport concepts Quick review on SDI Reminder!! SDI ▶ Serial Digital Interface - SDI is created in the professional environment, in the production and post-production stages, to allow working with the highest possible signal quality, which implies the use of uncompressed format ▶ These formats require a very high bit rate on a continuous basis (transport oriented to stream, not to packets), so it is essential to define a high-speed interface (initially 270 Mbs, and currently up to 96 Gbs) point to point, without problems of contention in the network that could generate unacceptable latencies, and reduce its efficiency ▶ It allows connection over long distances (kms with optic fiber) at low cost, similar to the old analogue composite video interfaces ▶ It is very versatile, interoperable, easy to monitor and to identify potential problems 7 / 76 Basic multimedia transport concepts Quick review on SDI Reminder!! SDI ▶ One-way Point-to-Point Digital Video Communication ▶ Transport medium: 75 Ω coaxial cable OR optic fiber ▶ BNC type connector in different variants with coaxial cable, the most common in media studios ▶ Encapsulates all SDTV formats, HDTV and UHDTV video formats ▶ It has capacity for 16 audio channels, inserted in the ancillary data frame, according to SMPTE 272M recommendation, organised in four groups (numbered 1 to 4), each including 4 channels (numbered in increasing order from 1 to 16; channels 1 to 4 in group 1, and successive ones) ▶ With sampling frequencies of 32, 44.1 or 48 kHz ▶ 20 o 24 bits/sample ▶ Includes time codes and metadata 8 / 76 Basic multimedia transport concepts Quick review on SDI Reminder!! SDI in standardization ▶ All interfaces are standardised by the SMPTE to facilitate interoperability between manufacturers, with some input from ITU-R and EBU: Standard Name Bit rate Supported formats SMPTE 259M SDI 270 Mbs 480i, 576i SMPTE 344M ED-SDI 540 Mbs 480p, 576p SMPTE 292M HD-SDI 1,485 Gbs 720p, 1080i SMPTE 297M HD-SDI (Optical fibre) 1,485 Gbs 720p, 1080i SMPTE 372M Dual Link HD-SDI 2,970 Gbs 1080p SMPTE 424M 3G-SDI 2,970 Gbs 1080p SMPTE ST-2081 6G UHD-SDI 6 Gbs 4Kp30 SMPTE ST-2082 12G UHD-SDI 12 Gbs 4Kp60 SMPTE ST-2083 24G UHD-SDI 24 Gbs 3D 4Kp60 In preparation 48G UHD-SDI 48 Gbs 3D 4Kp120 o 8Kp60 9 / 76 Fiber loss (dB/km) 0.35 0.25 0.35 0.25 Output power (dBm) -3 0 Basic multimedia transport concepts Maximum input power (dBm) -7.5 / 0 (preferred) -7.5 / 0 (preferred) [minimum input overload] Quick review on SDI Minimum loss budget (dB) 4.5 / 0 7.5 / 0 Minimum link distance (km) 13 / 0 18 / 0 21 / 0 30 / 0 Reminder!! Optical fibre transmission of SDI signal Table E.3 – High-power (long-haul) link applications – minimum input overload ▶ SMPTE ST 297-1 sets out the parameters that facilitate 3G, Single mode fiber 6G and 12G-SDI signal transmission over optical fibre for long At minimum output power At maximum output power distances Wavelength Fiber loss (dB/km) 1310nm 0.35 1550nm 0.25 1310nm 0.35 1550nm 0.25 Output power (dBm) 0 10 ▶ Either single-mode or multimode fibre can be used, although Maximum input power (dBm) -7.5 / 0 (preferred) -7.5 / 0 (preferred) [minimum input overload] the longest ranges are obtained with the former Minimum loss budget (dB) 7.5 / 0 17.5 / 10 Minimum link distance (km) 21 / 0 30 / 0 50 / 29 70 / 40 ▶ Defines all the parameters involved in the link: maximum and minimum TX power and to be received by the RX, working Minimum ranges to be supported according to the window (1st, 2nd or 3rd), as well as the maximum attenuation recommendation SMPTE ST 297-1 (SMPTE® ) of the fibre, its dispersion, the maximum spectral width ∆λ, etc. ▶ SMPTE ST 297-2 does the same, but for the case of transmission over CWDM systems ▶ The optical connectors are also specified in the SMPTE ST 2091-1 standard Page 16 of 26 pages ▶ Optical interface for 24G-SDI is not defined yet Authorized licensed use limited to: Univ Politecnica de Madrid. Downloaded on October 17,2017 at 14:25:53 UTC from IEEE Xplore. Restrictions apply. 10 / 76 Basic multimedia transport concepts Why moving to IP networks? Contents 2. Current standards for content transport over IP 1. Basic multimedia transport concepts RTP protocol Quick review on SDI SMPTE ST-2022-6 Why moving to IP networks? SMPTE ST-2110 What is IP Fabric? PTP synchronisation Basic differences between SDI vs IP Fabric NMOS specifications from AMWA 11 / 76 Basic multimedia transport concepts Why moving to IP networks? Why moving to IP networks? ▶ Initial latency problems can be solved with careful network design ▶ IP network speeds are comparable to those of UHD-SDI links ▶ The SDI signal transport infrastructure is specific to the type of x-SDI signal being used. IP equipment is generic, and carries packets, regardless of the type of signal (audio or video) being handled ▶ The IP transport infrastructure facilitates scalability as the number of signals handled or equipment connected grows. There is no limitation by the size of the SDI video matrix ▶ IP transport facilitates the sharing of infrastructure: it is not necessary for a set to have its own associated production, video, sound and light control room. All the latter infrastructure can be reconfigured to serve several sets that do not operate simultaneously ▶ The sharing facility extends to any other infrastructure (material or personnel) in production companies that have several sites in different geographical locations, giving rise to concepts such as: ▶ PaaS: processing as a service (of one site to others inside the company) ▶ BaaS: broadcasting as a service (of one site to other companies) 12 / 76 Basic multimedia transport concepts What is IP Fabric? Contents 2. Current standards for content transport over IP 1. Basic multimedia transport concepts RTP protocol Quick review on SDI SMPTE ST-2022-6 Why moving to IP networks? SMPTE ST-2110 What is IP Fabric? PTP synchronisation Basic differences between SDI vs IP Fabric NMOS specifications from AMWA 13 / 76 Basic multimedia transport concepts What is IP Fabric? IP architectures ▶ Most generic data center networks have been implemented based on the traditional three-layer architecture ▶ This three-layer architecture is widely used, mature, stable and practical for most traffic models, including campus networks with southbound and northbound configurations ▶ In this architecture, a host communicates with the hosts on different network segments in the network through switches and routers. Hosts on the same network segment are typically connected to the same switch and can communicate with each other directly ▶ However, in the content sector, this architecture no longer satisfies the needs of data center networks, especially when there are severe latency constraints, such as in the case of streaming audiovisual signals, and the infrastructure is not in the same segment 14 / 76 Basic multimedia transport concepts What is IP Fabric? IP architectures ▶ Content centers can be assimilated to cloud computing, where horizontal (east-west) traffic dominates data centers ▶ The horizontal traffic model has become a bottleneck for data transmission on vertically designed networks, as data must pass through many unnecessary nodes (including routers and switches) ▶ Inter-host access traffic needs to pass through many uplink ports, greatly degrading the transmission performance 15 / 76 Basic multimedia transport concepts What is IP Fabric? IP Fabric ▶ In IP Fabric networks, communication between any two servers involves a maximum of three devices (two links), and each spine node and leaf node are fully meshed ▶ The maximum number of supported leaf devices is determined by the maximum number of ports supported by each spine ▶ Traffic can be transmitted between server nodes in almost all data center structures by traversing a certain number of switches ▶ This architecture consists of multiple high-bandwidth direct links, avoiding network transmission slowdowns caused by network bottlenecks and supporting high forwarding efficiency and low latency ▶ This architecture highly facilitates network scaling by simply increasing the number of spine nodes 16 / 76 Basic multimedia transport concepts Basic differences between SDI vs IP Fabric Contents 2. Current standards for content transport over IP 1. Basic multimedia transport concepts RTP protocol Quick review on SDI SMPTE ST-2022-6 Why moving to IP networks? SMPTE ST-2110 What is IP Fabric? PTP synchronisation Basic differences between SDI vs IP Fabric NMOS specifications from AMWA 17 / 76 Basic multimedia transport concepts Basic differences between SDI vs IP Fabric Differences between SDI vs IP Fabric. Infrastructure point of view (I) IP Fabric SDI Matrix 1 Signal type agnostic (equipment with longer 1 Equipment designed for a specific signal format lifetime) 2 The signal is at the receiver equipment 2 Any signal on any end equipment, no (wherever the cable or distributor takes it) restrictions or limitation to distributors 3 No bandwidth concerns. Reliability 3 Careful design with special attention to bandwidth (two links non-blocking design) 18 / 76 Basic multimedia transport concepts Basic differences between SDI vs IP Fabric Differences between SDI vs IP Fabric. Infrastructure point of view (II) IP Fabric SDI Matrix 4 The destination device is the one who requests 4 The final equipment receives the signal without the signal by means of the orchestrator requesting it 5 Scalability: ease of growth (COTS - 5 Growth limited to video matrix size Commercial Off The Shelf - equipment) 6 Consisting of a single node (monolithic) or 6 Normally a single video matrix several distributed and interconnected 7 It works on unidirectional circuit switching according to topology 7 Works over bidirectional packet switching 19 / 76 Basic multimedia transport concepts Basic differences between SDI vs IP Fabric Differences between SDI vs IP Fabric. Deployment point of view IP Fabric Video Matrix 1 Optic fibre cabling, each fibre carrying multiple 1 Copper wiring, each cable carries one bidirectional signals (streams) signal 2 Significant reduction of cabling, critical in OB vans 2 Large volume of cabling (each cable carries one signal in one direction 3 PTP Synchronisation only) 4 Subscriptions to multicast streams 3 Black burst Sync, tri-level signals usually 5 A/V signals transmitted over separate networks 4 Need for distributors, patch panels 6 Specific electrical requirements 5 Audio embedded in the video signal 7 Active and compatible cables / commercial SFP (Small Form-factor Pluggable) transceivers 20 / 76 Current standards for content transport over IP Contents 2. Current standards for content transport over IP 1. Basic multimedia transport concepts RTP protocol Quick review on SDI SMPTE ST-2022-6 Why moving to IP networks? SMPTE ST-2110 What is IP Fabric? PTP synchronisation Basic differences between SDI vs IP Fabric NMOS specifications from AMWA 21 / 76 Current standards for content transport over IP Standards for HBRMT over IP networks There are currently 2 main choices to transport uncompressed SDI High Bit Rate Multimedia Signals Transport – HBRMT over IP networks, both from SMPTE standards: 1 SMPTE ST 2022-6: The bundled approach. Video + audio + metadata all together 2 SMPTE ST 2110: The essence-based approach. Every essence in a separate way Both approaches rely on the RTP protocol, so let’s make a quick review on it!! 22 / 76 Current standards for content transport over IP RTP protocol Contents 2. Current standards for content transport over IP 1. Basic multimedia transport concepts RTP protocol Quick review on SDI SMPTE ST-2022-6 Why moving to IP networks? SMPTE ST-2110 What is IP Fabric? PTP synchronisation Basic differences between SDI vs IP Fabric NMOS specifications from AMWA 23 / 76 Current standards for content transport over IP RTP protocol RTP protocol ▶ Real-time Transport Protocol – RTP is a standard defined in IETC RFC ▶ RTP is a transport layer protocol (level 4 from the OSI model) ▶ High bitrate, real-time, low latency, unidirectional data transport ▶ RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio or video ▶ Without acknowledgement of receipt, therefore it must work on a reliable network. Each application can add its own error correction mechanism 24 / 76 Current standards for content transport over IP RTP protocol RTP protocol ▶ Usually implemented over UDP (although admits other types of underlying networks and protocols, such as TCP), does not guarantee quality-of-service – QoS for real-time services ▶ To allow monitoring of the data delivery, Real-time Transport Control Protocol – RTCP can be used (but it is not mandatory) ▶ Admits unicast (one to one) or multicast (one to many) network services 25 / 76 Current standards for content transport over IP RTP protocol RTP protocol ▶ The specification provides general definitions for any application, but leaves room for such specific applications to define their own fields in the header of transmitted packets. That implies to define: ▶ A profile, defining the set of payload type codes and mapping ▶ A payload format, defining how the payload is carried in RTP 26 / 76 Current standards for content transport over IP RTP protocol RTP protocol ▶ Payload profiles and formats for different media types are, in turn, specified in various standards: ▶ RFC 2250 for MPEG2-TS video ▶ RFC 6184 for H.264 video ▶ RFC 7798 for H.265 video ▶ RFC 2435 for JPEG compressed video ▶ RFC 4184 for Dolby AC-3 audio ▶ RFC 4598 for Enhanced AC-3 (E-AC-3) Audio ▶ etc. ▶ For more information: https://datatracker.ietf.org/ 27 / 76 Current standards for content transport over IP RTP protocol RTP protocol RTP defines a standard packet format for delivering the content, as shown in figure: ▶ Version (V): A 2-bit field indicating the protocol version. The current version is 2 ▶ Padding (P): A 1-bit field indicating padding at the end of the RTP packet ▶ Extension Header (X): A 1-bit field indicating the presence of an optional extension header ▶ CRSC Count (CC): A 4-bit field indicating the number of Contributing Source (CSRC) identifiers that follow the fixed header. It is presented only when inserted by an RTP mixer such as a conference bridge or transcoder ▶ Marker (M): A 1-bit marker bit that identifies events such as frame boundaries ▶ Payload Type (PT): A 7-bit field that identifies the format of the RTP payload ▶ Sequence Number: A 16-bit field that increments by one for each RTP packet sent. The receiver uses this field to identify lost packets ▶ Timestamp: A 32-bit timestamp field that reflects the sampling instant of the first octet of the RTP packet. Synchronization Source Identifier (SSRC): A 32-bit field that uniquely identifies the source of a stream of RTP packets ▶ Contributing Source Identifiers (CSRC): Variable length field that contains a list of sources of streams of RTP packets that have contributed to a combined stream produced by an RTP mixer. You can use this to identify the individual speakers when a mixer combines streams in an audio or video conference ▶ RTP Extension (Optional): Variable length field that contains a 16-bit profile specific identifier and a 16-bit length identifier, followed by variable length extension data. Intended for limited use ▶ RTP Payload: Variable-length field that holds the real-time application data (metadata, audio, video, and so on) We will NOT enter into the details of every packet!! 28 / 76 Current standards for content transport over IP RTP protocol RTP protocol ▶ RTP injects time markers and sequence numbers to the various multimedia streams (audio, video, etc.), controls the destination arrival of the packets, and identifies the type of information transported ▶ RTP CANNOT reserve resources in the network, provide reliability in the network, or guarantee delivery time ▶ RTP packets are finally mapped onto IP datagrams, which imply to encapsulate RTP packets into UDP (User Datagram Protocol) – if used, and then into IP datagrams 29 / 76 Current standards for content transport over IP ~~~ ~~~ PES PSI/SI RTP protocol PES packet Variable length Data table Variable length header header ~~~ ~~~ … … Encapsulation of MPEG2-TS using the RTP protocol Transport Stuffing byte … TS TS TS … … … stream (NULL) ▶ RFC-2250 specifies that the RTP payload of MPEG2-TS 188 byte fixed NULL packet is caused by fixed data rate (SDI core content) has no specific payload header and Fig. 2. MPEG2-TS multiplexing architecture. contains an integral number of MPEG2-TS packets MPEG2-TS through the DMB network. To fill the allocated 188 × 7 = 1,316 bytes ▶ The figure shows the rateencapsulation of the subchannel, we structure that must generate can bebitrate a constant 8th TS packet used to transmit MPEG2-TS, MPEG2-TS that using a toMaximum strictly fits the rate. Transport stream To realizeof Transmission Unit – MTU this, some additional 1500 MPEG2-TS packets bytes (maximum referred value to as NULL packets are inserted into the stream. The payload X for ethernet networks) of the NULL packets does not contain any valid data, so the MTU: 1,500 bytes IP UDP RTP RTP payload receiver can safely ignore them. As will be shown in subsection ▶ Larger packets results II.3, in the more number efficiency because of NULL packets each and stuffing bytes is far 40 bytes Generic RTP header packet carries morefrom usernegligible. data and thetoheader According overhead our experiment on various real Unallocated space TS packet Stuffing + NULL remains fixed DMB streams, it comprises 4% to 29% of the source data rate. If we remove NULL packets and stuffing bytes from the transmission, we can significantly improve transmission ▶ As the size of the RTP package is implementation efficiency by a corresponding percentage. MPEG2-TS packets. While it is simple and easy to implement, dependent, the overhead introduced by the TS packaging the payload format is not flexible in size, which may result in is not fixed 2. Encapsulation of MPEG2-TS in RTP transmission inefficiency. We will show some examples as to why inflexibility in size may result in transmission inefficiency. RTP defines a standardized packet format for delivering Figure 3 depicts the RTP encapsulation structure of MPEG2- audio and video over IP networks. RTP is used extensively in TS for an MTU of 1,500 B. MTU is the largest packet size that 30 / 76 Current standards for content transport over IP RTP protocol Content transport using the RTP protocol ▶ RTP packet size fixed by SMPTE ST 2110 or ST 2022 standards to avoid fragmentation ▶ Each packet contains a certain number of the complete YCbCr samples of a given number of pixels (pixel group) or audio ▶ Its headers include: ▶ Sequence numbers, order number of the packages to reorder them at reception ▶ Timestamps, the Image Capture Time to align different media streams (audio with video) and also to calculate the correct rate of data presentation. ▶ All packets of the same video frame contain the same timestamp (Image capture time) ▶ The timestamps are calculated by the sender through PTP (Precision Time Protocol) 31 / 76 Current standards for content transport over IP SMPTE ST-2022-6 Contents 2. Current standards for content transport over IP 1. Basic multimedia transport concepts RTP protocol Quick review on SDI SMPTE ST-2022-6 Why moving to IP networks? SMPTE ST-2110 What is IP Fabric? PTP synchronisation Basic differences between SDI vs IP Fabric NMOS specifications from AMWA 32 / 76 Current standards for content transport over IP SMPTE ST-2022-6 Standards for HBRMT over IP networks: SMPTE ST 2022-6 ▶ Intended for real time transport of uncompressed SDI audio, video and ancillary signals over IP networks (ST 2022-3 deal with VBR and ST 2022-4 with CBR, both compressed signals) ▶ Designed for contribution, primary distribution and digital cinema, but NOT intended for emission purposes ▶ The entire payload of the SDI signal, including VANC and HANC data, is encapsulated as one stream, using RTP datagrams, for unidirectional (both unicast or multicast) services ▶ Support of RFC 4566 Session Description Protocol (SDP) and/or RFC 3550 Real Time Control Protocol (RTCP) are not required for equipment supporting this standard, but could be utilized at the implementers discretion 33 / 76 Current standards for content transport over IP SMPTE ST-2022-6 Standards for HBRMT over IP networks: SMPTE ST 2022-6 ▶ The size of output Media Datagrams from a transmitting device shall be less than or equal to 1500 octets so that they can pass through most networks without fragmentation ▶ The video luminance and color-difference values shall be encapsulated into 1376 octet media payloads ▶ The last datagram of the video frame, being only partially filled with luminance and color-difference values, shall have additional null octets added to achieve a total length of 1376 octets ▶ As end-point devices will typically be connected to Ethernet style networks, this limits the maximum transmission unit (MTU) to 1500 octets 34 / 76 Current standards for content transport over IP SMPTE ST-2022-6 Standards for HBRMT over IP networks: SMPTE ST 2022-6 ▶ Concerning the RTP Header, the use of IP/UDP/RTP shall be required, as it provides a standard header for the media and FEC (if used) datagrams ▶ The Sequence number 16 bits field is the sequence counter, and increments by one for each RTP data datagram sent 35 / 76 Current standards for content transport over IP SMPTE ST-2022-6 Standards for HBRMT over IP networks: SMPTE ST 2022-6 ▶ The 32 bits Timestamp field reflects the sampling instant of the first octet in the RTP datagram. The transmission instant shall be derived from a clock that increments monotonically and linearly in time to allow synchronization and jitter calculations ▶ The RTP timestamp assists with datagram buffer management at the receiver and optionally with identification of received datagrams for protection switching ▶ The Media Datagram rate for the 3 Gb/s television formats is close to 270,000 datagrams per second. See SMPTE ST 2022-6 for a full detailed description of all the fields 36 / 76 Current standards for content transport over IP SMPTE ST-2022-6 Standards for HBRMT over IP networks: SMPTE ST 2022-6 Meaning of some fields of the payload header: 37 / 76 Current standards for content transport over IP SMPTE ST-2022-6 Standards for HBRMT over IP networks: SMPTE ST 2022-5 ▶ Created to provide interoperability between different manufacturers ▶ Defines a FEC technique (used with SMPTE ST 2022-6) that can be used to correct for errors induced when transporting SDI A/V essences over IP networks. BUT it is optional!! ▶ Defines two levels of FEC: Level A (one FEC stream) and Level B (two FEC streams) 38 / 76 Current standards for content transport over IP SMPTE ST-2022-6 Standards for HBRMT over IP networks: SMPTE ST 2022-5 ▶ On IP networks, datagram losses typically come from three sources: 1. Erroneous reordering 2. Bit-error induced datagram drops 3. Burst losses/drops ▶ For any FEC scheme to operate properly, errors from these sources need to be low enough so that the FEC scheme can correct enough of these errors to meet the application requirements 39 / 76 Current standards for content transport over IP SMPTE ST-2022-6 Standards for HBRMT over IP networks: SMPTE ST 2022-5 ▶ Maximum protection against burst errors varies with data rate as follows: ▶ 270 Mb/s (SD-SDI): maximum 33 ms protection ▶ 1,485 Gb/s (HD-SDI 1080i): maximum 6 ms protection ▶ 2,97 Gb/s (HD-SDI 1080p): maximum 3 ms protection ▶ For higher values, other mechanisms must be utilized to conceal errors, such as retransmissions or repetition of single frames ▶ This standard includes fields to easily detect missing datagrams so that frames can be easily repeated in the absence of expected datagrams 40 / 76 Current standards for content transport over IP SMPTE ST-2022-6 Standards for HBRMT over IP networks: SMPTE ST 2022-7 ▶ Standard for seamless reconstruction of a stream of RTP data- grams based on the transmission of multiple streams of identical content over potentially diverse paths ▶ The transmitter shall transmit, at least two streams, each containing copies of each RTP datagram ▶ The RTP header and the RTP payload shall be identical for each datagram copy ▶ The receiver will combine the streams arriving by the different paths to reconstruct the original stream. The reconstruction method is left to the implementer, who can choose between all copies for each datagram 41 / 76 Current standards for content transport over IP SMPTE ST-2110 Contents 2. Current standards for content transport over IP 1. Basic multimedia transport concepts RTP protocol Quick review on SDI SMPTE ST-2022-6 Why moving to IP networks? SMPTE ST-2110 What is IP Fabric? PTP synchronisation Basic differences between SDI vs IP Fabric NMOS specifications from AMWA 42 / 76 Current standards for content transport over IP SMPTE ST-2110 Standards for HBRMT over IP networks: SMPTE ST-2110 The SMPTE ST-2110 standard is really a family of specifications that cover different aspects of HBRMT: 43 / 76 Current standards for content transport over IP SMPTE ST-2110 Standards for HBRMT over IP networks: SMPTE ST-2110 SMPTE ST2110-10: Professional Media Over Managed IP Networks: System Timing and Definitions. It defines the synchronisation model and the requirements common to the other standards in the family. That is; the transport protocols of the different essences, the maximum size of the UDP datagram, the details of the description protocol of the data being sent (SDP) and the different clocks and how they interrelate 44 / 76 Current standards for content transport over IP SMPTE ST-2110 SMPTE ST2110-10: System Timing and Definitions Among other things, SMPTE ST2110-10 specifies the following general issues for HBRMT: ▶ All of the streams specified in this standard shall use the Real-time Transport Protocol – RTP as specified in IETF RFC 3550, and shall conform to the RTP profile specified in IETF RFC 3551 ▶ All RTP streams shall use UDP as specified in IETF RFC 768 for transport of RTP ▶ RTP session multiplexing shall not be used ▶ RTCP may be used 45 / 76 Current standards for content transport over IP SMPTE ST-2110 SMPTE ST2110-10: System Timing and Definitions Among other things, SMPTE ST2110-10 specifies the following general issues for HBRMT: ▶ The Standard UDP size limit shall be 1460 octets, although there is a Extended UDP size limit of 8960 octects ▶ Senders and receivers shall support IPv4 and IPv6 multicast transmission and reception ▶ Inter-stream synchronization relies on RTP timestamp values in the RTP packet header, used to synchronize RTP streams from various senders ▶ The common reference clock can be distributed to all participating senders and receivers via IEEE 1588-2008 Precision Time Protocol - PTP 46 / 76 Current standards for content transport over IP SMPTE ST-2110 SMPTE ST2110-10: System Timing and Definitions ▶ The standard states that: Devices which contain one or more senders shall construct one SDP object per RTP stream as specified in IETF RFC 4566. These SDP objects shall be made available through the management interface of the device ▶ SDP: SESION DESCRIPTION PROTOCOL ▶ The SDP file is created by the sender when it starts injecting a flow into the network. It contains the following information: ▶ The destination multicast address (which already existed in the network), where the endpoint sends the stream to ▶ The relevant details of the signal format, so that the receiver knows the type of signal to decode (type of essence, resolution, frame rate, audio sampling frequency, etc.) ▶ Primary and secondary flows are differentiated when redundant operation is used in accordance with SMPTE ST2022-7 47 / 76 Current standards for content transport over IP SMPTE ST-2110 Standards for HBRMT over IP networks: SMPTE ST-2110 SMPTE ST2110-20: Professional Media Over Managed IP Networks: Uncompressed Active Video ▶ It defines the real-time transport method (based on RTP) of the uncompressed active video signal over an IP network ▶ For the correct interpretation of the data by the receiver, it provides the metadata describing the content transported over SDP (type of essence, resolution, chroma sampling, bit deph, colorimetry, etc.) 48 / 76 Current standards for content transport over IP SMPTE ST-2110 Standards for HBRMT over IP networks: SMPTE ST-2110 SMPTE ST2110-20: Professional Media Over Managed IP Networks: Uncompressed Active Video ▶ To maximize efficiency in the packing process, the key element defined in the standard is the pgroup parameter, that defines de minimal group of samples that align to an octet boundary: pgroups shall not be fragmented across packets ▶ pgroup mapping can be done with 4:4:4, 4:2:2 and 4:2:0 sampling schemes ▶ An example of pgroup use for estimating the image generated bit/rate will be done later Examples of pgroup formation for 4:2:2 and 4:2:0 sampling schemes 49 / 76 Current standards for content transport over IP SMPTE ST-2110 Standards for HBRMT over IP networks: SMPTE ST-2110 SMPTE ST2110-21: Professional Media Over Managed IP Networks: Traffic Shaping and Delivery Timing for Video ▶ This standard specifies a timing model for SMPTE ST 2110-10 video RTP streams as measured leaving the RTP sender, and defines the sender SDP parameters used to signal the timing properties of such streams ▶ The standard considers both linear and non-linear packet rate senders 50 / 76 Current standards for content transport over IP SMPTE ST-2110 Standards for HBRMT over IP networks: SMPTE ST-2110 SMPTE ST2110-22: Professional Media Over Managed IP Networks: Constant Bit-Rate Compressed Video. This Standard specifies parameters for the real-time, RTP-based transport of constant bit-rate CBR compressed video over IP networks, referenced to a common reference clock. The packetization of the video compression shall produce a constant number of bytes per frame, or equivalently a constant number of RTP packets per frame 51 / 76 Current standards for content transport over IP SMPTE ST-2110 Standards for HBRMT over IP networks: SMPTE ST-2110 SMPTE ST2110-30: Professional Media Over Managed IP Networks: PCM Digital Audio. It defines the real-time transport method (based on RTP) of the AES67 compliant uncompressed PCM audio signal. It also defines the identification of channels in groups and levels based on parameters such as number of channels, sampling rate and packetisation times. It provides data of the signal transported via SDP 52 / 76 Current standards for content transport over IP SMPTE ST-2110 Standards for HBRMT over IP networks: SMPTE ST-2110 SMPTE ST2110-31: Professional Media Over Managed IP Networks: AES3 Transparent Transport. This Standard specifies the real-time, RTP-based transport of AES3 signals over IP networks (for those cases where transparent transport of entire AES3 signals are required, including their metadata and channel status), referenced to a network reference clock 53 / 76 Current standards for content transport over IP SMPTE ST-2110 Standards for HBRMT over IP networks: SMPTE ST-2110 SMPTE ST2110-40: Professional Media Over Managed IP Networks: SMPTE ST 291-1 Ancillary Data ▶ It defines the real-time transport mapping into RTP packets of ANC ancillary data packets (as specified in SMPTE ST 291-1) over an IP network ▶ The UDP size of each RTP packet shall not exceed the standard UDP size limit as specified in SMPTE ST 2110-10 ▶ The DID, SDID or DBN, DC, UDW, and CS portions of the ANC packet (as specified in SMPTE ST 291-1) are included in the RTP payload ▶ The Ancillary Data Flag (ADF) specified in SMPTE ST 291-1 is not included in the RTP payload ANC data types according to SMPTE ST-291-1 (1 or 2 Data ID words) 54 / 76 Current standards for content transport over IP SMPTE ST-2110 Estimation of the theoretical bit rate of an IP video signal with ST-2110 ▶ Let’s suppose that we want to calculate the bit rate of a 1080i25 or 1080p25 SDI signal (that is, 4:2:2 - 10 bits/pixel YCR CB ) ▶ According to SMPTE ST2110-10, the Standard UDP size limit shall be 1460 octets which imply 1521 bytes per Ethernet video packet 55 / 76 Current standards for content transport over IP SMPTE ST-2110 Estimation of the theoretical bit rate of an IP video signal with ST-2110 ▶ Next, looking up SMPTE ST2110-20 tables for the selected signal: =⇒ ▶ So, we have to work with pgroup (octects) = 5, and pgroup (pixels) = 2 ▶ 2 pixels × 2 samples/pixel = 4 samples ▶ 4 samples × 10 bit/sample = 40 bits ▶ 40 bits / 8 bits/octet = 5 octets 56 / 76 Current standards for content transport over IP SMPTE ST-2110 Estimation of the theoretical bit rate of an IP video signal with ST-2110 PGROUPS: 1426 bytes / 5 bytes/pgroup = 285,2 pgroups/packet. Rounded to 285, as it is not allowed to break pixel groups among packets PIXELS: 285 pgroups × 2 pixels/pgroup = 570 pixels/packet Packets in a video frame: ▶ 1920 × 1080 = 2.073.600 pixels/frame ▶ 2.073.600 / 570 = 3637,89 packets/frame. Rounded to 3638 Final bit rate: for the 1080i25 or 1080p25 SDI signal, and including IP overheads: 3638 packets/frame × 25 frames/sec × 1521 bytes/packet × 8 bits/byte = 1,106 Gbs IP vs SDI: 1,106 Gbs < 1,485 Gbs of the HD-SDI interface And for 1080p50?: The bit rate is doubled: 2,213 Gbs 57 / 76 Current standards for content transport over IP SMPTE ST-2110 Actual bit rate of an IP video signal with ST-2110 Validation testing done in Sant Cugat with a Tektronix PRISM monitor of an IP 1080p50 video signal shows: The IP Status measurement shows a detected bit rate of 2,184 Gbs (from a theroretical 2,213 Gbs) 58 / 76 Current standards for content transport over IP PTP synchronisation Contents 2. Current standards for content transport over IP 1. Basic multimedia transport concepts RTP protocol Quick review on SDI SMPTE ST-2022-6 Why moving to IP networks? SMPTE ST-2110 What is IP Fabric? PTP synchronisation Basic differences between SDI vs IP Fabric NMOS specifications from AMWA 59 / 76 Current standards for content transport over IP PTP synchronisation PTP synchronisation ▶ Based on IEEE 1588 Precision Time Protocol (2002) ▶ SMPTE publishes the ST-2059 standard, which describes how to synchronise audiovisual equipment over IP networks: ST-2059-1: Defines signal generation based on time information delivered by the IEEE 1588 protocol ST-2059-2: Defines an operating profile for the IEEE protocol optimized to the needs of multimedia synchronization ▶ PTP handles time with an accuracy of ns, being a digital value of 80 bit where: ▶ 48 bits represent the number of seconds since Epoch1 (1/1/1970 in Unix systems) ▶ 32 bits represent the number of nanoseconds contained in one second 1 Date and time relative to which a computer’s clock and timestamp values are determined. Traditionally it corresponds to 0 hours, 0 minutes, and 0 seconds (00:00:00 - UTC) on a specific date, which varies from system to system. Most versions of Unix use January 1, 1970; Windows uses January 1, 1601; Apple uses January 1, 1904, etc. 60 / 76 Current standards for content transport over IP PTP synchronisation PTP synchronisation ▶ With an accurate Grand Master clock and a PTP aware network, an accuracy of ±1µsec should be achieved ▶ PTP includes the option of hardware time stamping of message arrival and departure rates for greater accuracy ▶ The possibility of defining different PTP domains allows different clocks to coexist on the same physical network while devices are only attached to the clock of the domain in which they work ▶ Devices in PTP domains use the same multicast addressess, and therefore see the messages from all domains, but use only messages from the domain they are configured to operate in 61 / 76 Current standards for content transport over IP PTP synchronisation PTP synchronisation working mode (I) ▶ PTP relies on the delivery of 4 messages between 2 connected nodes ▶ Let’s assume a Master node and a Slave node, not synchronised, with internal clocks 1262 and 1216 respectively ▶ In time instant 1262, the Master reads its internal clock and, after processing, sends a Sync message in time 1263, noting this transmitting time ▶ The Slave notes the Sync receiving time: 1219 ▶ Some time later the Master delivers a Follow up message with the previous transmission time: 1263 ▶ The slave receives the Follow up message in time 1221 ▶ (1263-1219) + 1221 = 1265. Corrected time for the Slave, not considering the network delay 62 / 76 Current standards for content transport over IP PTP synchronisation PTP synchronisation working mode (II) ▶ To compute the network delay time, the Slave sends a Delay Request message with its internal transmission time (1269) ▶ The Master receives it, storing the time of reception: 1273 ▶ The Master delivers a Delay Response message including the previous time 1273 ▶ The Slave notes the time in which the Delay Response time is received: 1275 (1273−1269) ▶ 1275 + 2 = 1277. Both clocks are now synchronised!! ▶ The 1 previous 2 accounts for the 2 delivery times of the Delay Request message and the Delay Response message in the network ▶ This process is repeated periodically to keep synchronised nodes (For a detailed explanation, see David Gessner video) 63 / 76 Current standards for content transport over IP PTP synchronisation PTP synchronisation ▶ PTP synchronisation is critical for a network good operation ▶ Usually there are more than 1 Grand Master - GM clock in the network ▶ PTP defines a BMCA (Best Master Clock Algorithm) to determine the commanding GM 64 / 76 Current standards for content transport over IP PTP synchronisation PTP synchronisation At a device power up, it starts a Listening state, waiting for Announce Messages from its network reporting about the existence of a Master Clock. 2 possibilities: 1 If in the time period defined by Announce Time Out Interval it does not receive any Announce Message then it will set itself up as GM and start sending Announce Messages to periodically report its presence with a cadence defined by Announce Interval 2 If it receives an Announce Message it will analyse it to compare the current GM watch with its own. 2 Options again: 1 The existing clock is better: it sets itself to Passive State 2 The existing clock is NOT better: it starts advertising himself as a GM by sending Announce Messages The protocol establishes a permanent contest between potential GMs to determine the most accurate GM. Migration from one GM to another in a complex network can take minutes (~20) 65 / 76 Current standards for content transport over IP NMOS specifications from AMWA Contents 2. Current standards for content transport over IP 1. Basic multimedia transport concepts RTP protocol Quick review on SDI SMPTE ST-2022-6 Why moving to IP networks? SMPTE ST-2110 What is IP Fabric? PTP synchronisation Basic differences between SDI vs IP Fabric NMOS specifications from AMWA 66 / 76 Current standards for content transport over IP NMOS specifications from AMWA NMOS specifications from AMWA ▶ SMPTE ST2110 does not address interconnection / interoperability, only transport of media essences over the network ▶ AMWA2 promotes the NMOS specifications in order to provide a control plane solution to enable interoperability between different audio and video devices connected to a media network ▶ In NMOS, any equipment is modelled according to the Joint Task Force on Networked Media (JT-NM) Reference Architecture 2 Advanced Media Workflow Association, Inc., an open, collaborative forum for Networked Media workflows through the development and publication of specifications, tools, and current best practices. 67 / 76 Current standards for content transport over IP NMOS specifications from AMWA NMOS reference architecture The NOMS reference architecture includes the following elements: Node: Represents a logical device connected to the network. A node can host one or more devices Device: A device represents a logical block that can contain senders and receivers. For example, a camera would be modelled as a node with a single device Sender, Receiver: These are the logical inputs and outputs of the device (video, audio, etc.). The sender can have a source and a flow associated to it, being the source the origin of the flow Source, Flow: exists when there is sustained data transmission over time between a sender and a receiver 68 / 76 Current standards for content transport over IP NMOS specifications from AMWA NMOS reference architecture Examples of modelled end-devices: 69 / 76 Current standards for content transport over IP NMOS specifications from AMWA Specifications most widely adopted by manufacturers ▶ The AMWA NMOS specifications most widely adopted by manufacturers are: IS-04: NMOS Discovery and Registration Specification. Allows control and monitoring applications to find the resources on a network. Enables automation and reduces manual overhead in setting up networked sytems IS-05: NMOS Device Connection Management Specification. Provides a transport-independent way of connecting media nodes by providing them instructions that manage and stablish the QoS parameters of the connection ▶ They are provided in the form of RESTful APIs, available free of charge. Let’s remind that a RESTful API is a web service used by several clients to securely communicate with a server and exchange data 70 / 76 Current standards for content transport over IP NMOS specifications from AMWA AMWA IS-04 NMOS Discovery and Registration Specification ▶ As the name suggests, it defines the method for the discovery and/or registration of devices in a media network ▶ Devices announce their presence in the network (discovery) when they are connected to it ▶ They describe their constituent resources (Session Description Protocol - SDP file) and register them in a central registration server, accessible by the Broadcast Controller ▶ Two basic operation modes: ▶ REGISTERED mode for large networks ▶ PEER-TO-PEER mode for small networks ▶ External server (Registration and Discovery ▶ Nodes constantly announce their presence System - RDS) keeps an up-to-date database ▶ All announcements reach all devices ▶ Broadcast Controller queries the database, not ▶ As the number of devices increases, the number the devices of messages multiplies ▶ The server informs the control platform about what exists or does not exist 71 / 76 Current standards for content transport over IP NMOS specifications from AMWA AMWA IS-05 NMOS Device Connection Management Specification ▶ It defines the method for managing connections between devices on the network (sending a signal from one device to another) ▶ Standardises the connection method between compatible devices via SDP file patching (that is, virtualising a patch pannel through a file) ▶ This is done using a predifined API: IS-05 Connection API, described in the specification and available from AMWA 72 / 76 Current standards for content transport over IP NMOS specifications from AMWA Network connection process and between end devices Connection of a device to the media network: 1 The device (endpoint) has to discover an IS-04 Registration and Discovery System (RDS) via Domain Name System - Service Discovery (DNS-SD1 ), and then register to this system via the IS-04 Registration API 2 The Broadcast Controller (acting as NMOS client), through the IS-04 Query API, shall be able to request a list of registered resources from the RDS 1 An extension of the DNS protocol that allows nodes to advertise the services they provide to the local network or to detect the services offered by other nodes in the local network 73 / 76 Current standards for content transport over IP NMOS specifications from AMWA Network connection process and between end devices Connection between devices registered on the network: 3 The actions that will trigger the connection between a signal transmitter and a receiver can now be executed by the broadcast controller (SDP file patching) via the IS-05 Connection API 4 As a result, the receiver will request the network, via IGMP2 , to subscribe to the sender’s flow (described in the SDP file received). The network will send packets from the sender to the receiver 5 The connection of a transmitter to a receiver is also possible without the involvement of the RDS or a Broadcast Controller (this can be a simple software) via the IS-04 Node API 2 The Internet Group Management Protocol (IGMP) is a protocol that allows several devices to share one IP address so they can all receive the same data. IGMP is a network layer protocol used to set up multicasting on networks that use IPv4. Specifically, IGMP allows devices to join a multicasting group 74 / 76 Current standards for content transport over IP NMOS specifications from AMWA An SDN Orchestrator is needed! ▶ An external intelligent entity is needed to drive all device registration, service discovery, and communications management operations ▶ That intelligent entity is the SDN Orchestrator ▶ Example of orchestration implemented in Sant Cugat: 75 / 76 Questions?

Tema 6_Transporte de contenidos en IP ST.2110, ST.2022. Especificaciones NMOS de AMWA PDF

Document Details

Tags

Related

Summary

Full Transcript