200 likes | 427 Views
Safe Video Contribution & Distribution over IP Networks. Philippe LEMONNIER. High bandwidth IP networks bring new opportunities for transport of audiovisual contents. IETF has defined a basic set of RFCs so as to standardize Video transport over IP. Compressed realtime Video over IP.
E N D
Safe Video Contribution & Distribution over IP Networks Philippe LEMONNIER
High bandwidth IP networks bring new opportunities for transport of audiovisual contents. IETF has defined a basic set of RFCs so as to standardize Video transport over IP. Compressed realtime Video over IP Application Network Process to Application MPEG2 A/V Presentation Data Representation & Encryption MPEG2-TS Host layers Session Interhost Communication RFC2250 RTP (RFC1889) Transport End-to-End Connection Reliability IGMP (RFC2236) UDP (RFC768) Network Path Determination/Logical Addressing IP (RFC791) Data Link MAC & LLC (physical addressing) Media layers Physical Media, signal & Binary Transmission MPEG compressed A/V contents mapped over IP with the IETF toolbox OSI model
RTP encapsulation (optional) 12 bytes RTP header MPEG-TS payload 8 bytes UDP encapsulation UDP header RTP header MPEG-TS payload 20 bytes IP encapsulation IP header UDP header RTP header MPEG-TS payload 14 bytes Mapping over Ethernet 4 bytes Ethernet header IP header UDP header RTP header MPEG-TS payload Ethernet CRC IEEE802.3 Ethernet MTU (Max. Transfer Unit) of 1500 bytes✳, restricts the blocking factor (number of grouped TS packets) to 7. ✳Jumbo frames with bigger MTU exist, but would lead to IP fragmentation in the networks. MPEG-TS mapping over IP & Ethernet MPEG Transport Stream packets 188 bytes 188 bytes 188 bytes
Time transparency IP packet delay variation (IPDV) in the network is very high : 50ms as per ITU-T Rec. Y.1541, for Service Class 0 and 1 networks … to put in perspective of 3ms ATM Cell Delay Variation around the globe, as per ITU-T Rec. I.356. Information transparency Technologies used for IP transport (OSI level 2) don’t lose bits : they drop full frames (eg. up to ~1500 bytes chunks for Ethernet) Up to 7 MPEG-TS packets can be lost at once. The impact of an IP datagram loss is getting even worse as compression ratios rise (MPEG4…) IP networks main drawbacks
At OSI levels 1 and 2 Bits may get twisted for electrical reasons (impulse noise, crosstalk, etc) during their trip along cable runs. IP header processing principle in all hosts relies on header coherency. Therefore, all technologies used to carry IP datagrams use some form of signature to ensure that the received frames carry datagrams that are safe to pass to IP level. Dubious frames are silently discarded upon reception. At OSI levels 2 and 3 IP networks are heterogeneous by nature. Hopping across network segments implies crossing switches (level 2) and routers (level 3). Poor traffic engineering, network misuse or equipment problems can lead to congestion in these nodes. Router / switch policy when facing congestion will lead to frames drop. Origin of network errors Medium impairment Bridge / Router Bridge / Router No Payload burst CRC OK ? Port 1 (in) Port 1 (in) Port 3 (out) FIFO Payload burst FIFO Yes Received frame FIFO is full Incoming data dropped Proceed to MAC, and upper to IP Port 2 (in) Port 2 (in)
Objectives Provide a forum for manufacturers, end-users and service providers to co-operatively develop interoperable systems for real-time delivery of high-quality program material over Wide Area Networks Outcome Code Of Practice #3r2✳ (July ’04) professional MPEG-2 Transport Streams over IP networks contribution and primary distribution applications Addresses: Encapsulation Protocol Network Requirement Pro-MPEG Forum WAN Group ✳http://www.pro-mpeg.org/publications/pdf/Vid-on-IP-CoP3-r2.pdf
Pro-MPEG Forum FEC scheme • Based on Generic Forward Error Correction RFC2733 • Deployed at RTP level to cope with lost IP datagrams • FEC protection data is embedded in regular RTP packets with a specific payload type • Relies on simple XOR (⊕) arithmetics : If P=A⊕B⊕C, then one with only A,B,P can retrieve C with C=A⊕B⊕P
Pkt 3 Pkt 3 Pkt n+3 Pkt n+1 Pkt 1 Pkt n+2 Pkt 2 Pkt 5 Pkt 4 Pkt 3 Pkt n Pkt 1 Pkt 2 Pkt n Pkt n+1 Pkt n+2 Pkt 2 Pkt 5 Pkt 1 Pkt 4 FEC 1 FEC 1 FEC (n+2)/3 FEC (n+2)/3 RTP stream with embedded FEC Fundamentals : Row FEC principle RTP stream to protect Most simple FEC Low latency mechanism Can only protect from single packet loss
3L-1 L (D-1)L DL-1 (D-1)L+2 1 L-1 2 L+1 2L+1 0 L+2 2L-1 3L+2 4L-1 3L (D-1)L+1 2L+2 2L Pkt 3L+1 FEC C1 FEC C0 FEC C2 FEC CL-1 RTP & RTP-FEC combiner L Columns 1D column FEC overview RTP stream to protect D rows
1 and at most 1 data packet per column burst of L consecutive data packets 0 1 2 3 4 0 1 2 3 4 5 6 7 8 9 10 11 6 7 8 9 14 15 16 17 16 17 18 19 20 21 22 23 18 19 20 21 22 23 24 25 27 28 29 24 25 26 27 28 29 30 31 32 33 34 35 30 31 32 33 34 35 FEC0 FEC1 FEC2 FEC4 FEC5 FEC0 FEC1 FEC2 FEC3 FEC4 FEC5 Example of correction hits
2 data packets on the same column 1 data packet and its associated FEC packet 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 10 11 6 7 8 9 10 11 12 13 15 16 17 12 13 14 16 17 18 19 20 21 22 23 18 19 20 21 22 23 24 25 27 28 29 24 25 26 27 28 29 30 31 32 33 34 35 30 31 32 33 34 35 ? FEC0 FEC1 FEC2 FEC3 FEC4 FEC5 FEC0 FEC1 FEC2 FEC4 FEC5 ? ? Example of correction failures
Pkt 3L+1 2 L-1 0 1 (D-1)L+2 L (D-1)L L+1 2L DL-1 L+2 2L+1 3L-1 2L+2 3L 2L-1 4L-1 3L+2 (D-1)L+1 FEC R0 FEC R1 FEC R2 D rows FEC C0 FEC C2 FEC C1 FEC CL-1 FEC R3 FEC RD-1 RTP & RTP-FEC combiner L Columns 2D – FEC scheme overview RTP stream to protect
0 1 3 2 4 5 FEC’0 FEC’0 6 7 8 9 10 11 FEC’1 FEC’1 12 13 14 15 16 17 18 19 20 21 22 23 FEC’3 FEC’3 24 28 25 26 27 29 FEC’4 FEC’4 30 31 32 33 34 35 FEC’5 FEC’5 FEC0 FEC0 FEC3 FEC1 FEC4 FEC1 FEC2 FEC3 FEC4 FEC5 Sample correction hit 6x6 data matrix with 9 data packets lost and 1 FEC packet lost 1 3 8 21 25 28 29 30 33 The 9 missing data packets are successfully recovered !!!
1 data packet and its 2 associated FEC packets 4 data packets positioned on exactly2 rows and 2 columns 0 1 2 3 4 5 FEC’0 0 1 2 3 4 5 FEC’0 6 7 8 9 10 11 FEC’1 6 7 8 9 10 11 FEC’1 12 13 14 16 17 12 13 14 17 FEC’2 18 19 20 21 22 23 FEC’3 18 19 20 23 FEC’3 24 25 26 27 28 29 FEC’4 24 25 26 27 28 29 FEC’4 ? 30 31 32 33 34 35 FEC’5 30 31 32 33 34 35 FEC’5 ? FEC0 FEC1 FEC2 FEC4 FEC5 FEC0 FEC1 FEC2 FEC3 FEC4 FEC5 Sample correction failures
UDP Port n Column FEC packets Row FEC packets MPEG-TS packets UDP Port n+2 IP IP IP RTP RTP RTP UDP UDP UDP UDP Port n+4 Same destination IP address (unicast node or multicast group) Video & FEC data & streams • Elegant, does not break the original AV stream • A receiving party can use : • Just the original encapsulated A/V stream it is not FEC-capable • Use the row or column FEC data if only 1D-FEC capable • Use both row & column FEC streams if 2D-FEC capable Media
In seconds In days ! Typical performance Reference : Video at 4Mb/s transported with 7 MPEG-2 TS packets per RTP/IP datagram • Legend: • L : matrix row length • D : matrix column depth • I : Interleaving depth used in FEC packets sequencing • PLR : Network Packet Loss Ratio • MTBE : Mean Time Between Errors • Error distribution: random/uniform 2D FEC Column only 1D FEC Row only 1D FEC
Status • First complete 2D FEC unveiled at IBC’04 by Thomson/Grass Valley • Interop session held at the joint Vidtrans/SMPTE conference (On January 30..Feb 2, 2005 in Atlanta, GA), showed full interop of 1D FEC between manufacturers. • CoP#3 adopted by Video Services Forum (VSF) Pro-MPEG CoP#3 FEC is widely accepted as the recommended solution for high quality video contribution on IP
Perspectives • FEC on the access network, down to the STBs (under consideration by DVB-IP) • Further work in the uncompressed world Proposed Pro-MPEG Forum CoP#4, still leaves room for improvements (latency, etc)
Thank you for your attention ! philippe.lemonnier@thomson.net http://www.thomsongrassvalley.com/