1 / 19

Safe Video Contribution & Distribution over IP Networks

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.

erv
Télécharger la présentation

Safe Video Contribution & Distribution over IP Networks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Safe Video Contribution & Distribution over IP Networks Philippe LEMONNIER

  2. 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

  3. 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

  4. 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

  5. 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)

  6. 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

  7. 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

  8. 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

  9. 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

  10. 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

  11. 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

  12. 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

  13. 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 !!!

  14. 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

  15. 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

  16. 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

  17. 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

  18. 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)

  19. Thank you for your attention ! philippe.lemonnier@thomson.net http://www.thomsongrassvalley.com/

More Related