Post on 25-Dec-2015
Compressed realtime Video over IP
> 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.
Application
Network Process to Application
Presentation
Data Representation & Encryption
Session
Interhost Communication
Transport
End-to-End Connection Reliability
Data Link
MAC & LLC (physical addressing)
Physical
Media, signal & Binary Transmission
Network
Path Determination/Logical Addressing
OSI model
MPEG compressed A/V contents
mapped over IP with the IETF toolbox
IP (RFC791)
UDP (RFC768)
RTP (RFC1889) IGMP
(RFC2236)
MPEG2 A/V
MPEG2-TS
RFC2250
Med
ia layers
Host
layers
MPEG-TS mapping over IP & Ethernet
188 bytes 188 bytes 188 bytes
MPEG Transport Stream packets
MPEG-TS payloadRTP header
RTP encapsulation (optional)12 bytes
MPEG-TS payloadRTP headerUDP header
UDP encapsulation8 bytes
MPEG-TS payloadRTP headerUDP header
IP header
IP encapsulation20
bytes
MPEG-TS payloadRTP headerUDP header
IP headerEthernet header
Mapping over Ethernet
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.
14 bytes
4 bytes
IP networks main drawbacksTime 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…)
Origin of network errorsAt 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.
Received frame
Medium impairment
CRC OK ?
Yes
Proceed to MAC, and upper to IP
NoPort 1 (in)
Port 2 (in)
Port 3 (out)
Bridge / Router
FIFO
Payload burst
Payload burst
Port 1 (in)
Port 2 (in)
Bridge / Router
FIFO
FIFO is fullIncoming
data dropped
Pro-MPEG Forum WAN GroupObjectives
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
✳ 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
Fundamentals : Row FEC principle
Most simple FEC Low latency mechanism
Can only protect from single packet loss
Pkt 2 Pkt n+2Pkt 1 Pkt n+3Pkt n+1Pkt nPkt 5Pkt 4Pkt 3Pkt 2Pkt 1 Pkt 3
FEC 1 FEC (n+2)/3
RTP stream to protect
Pkt 5Pkt 4FEC 1 Pkt n+2Pkt n+1Pkt n FEC (n+2)/3
RTP stream with embedded FEC
Pkt 2Pkt 1 Pkt 3
1D column FEC overview
(D-1)L DL-1(D-1)L+2
10 L-1 2
L+1L 2L-1L+2
2L+12L 3L-12L+2
Pkt 3L+13L 4L-13L+2
(D-1)L+1
FEC C0 FEC C2 FEC C1 FEC CL-1
RTP
&
RTP-FEC combiner
RTP stream to protect
D rows
L Columns
Example of correction hits1 and at most 1 data packet per
column
06
182430
17
192531
28
1420
32
39
15212733
41016222834
1117232935
FEC0 FEC1 FEC2 FEC4 FEC5
burst of L consecutive data packets
06
182430
17
192531
28
202632
39
212733
4
16222834
5
17232935
FEC0 FEC1 FEC2 FEC3 FEC4 FEC5
Example of correction failures
06
12182430
17
13192531
28
20
32
39
15212733
41016222834
51117232935
FEC0 FEC1 FEC2 FEC3 FEC4 FEC5
2 data packets on the same column
?
?
06
12182430
17
13192531
28
14202632
39
212733
41016222834
51117232935
FEC0 FEC1 FEC2 FEC4 FEC5
1 data packet and its associated FEC packet
?
2D – FEC scheme overview
(D-1)L DL-1(D-1)L+2
10 L-1 2
L+1L 2L-1L+2
2L+12L 3L-12L+2
Pkt 3L+13L 4L-13L+2
(D-1)L+1
FEC C0 FEC C2 FEC C1 FEC CL-1
RTP stream to protect
D rows
L Columns
RTP
&
RTP-FEC combiner
FEC RD-1
FEC R0
FEC R1
FEC R2
FEC R3
Sample correction hit
0
6
12
18
24
7
13
19
31
2
14
20
26
32
9
15
27
4
10
16
22
34
5
11
17
23
35
FEC’0
FEC’1
FEC’3
FEC’4
FEC’5
FEC0 FEC1 FEC2 FEC3 FEC4 FEC5
FEC’18
FEC’321
FEC0
30
FEC1
25
FEC4
28FEC’533
FEC’429
8
21
30 33
FEC3
33 FEC’011
25 28 29
The 9 missing data packets are successfully recovered !!!
6x6 data matrix with 9 data packets lost and 1 FEC packet lost
Sample correction failures
06
12182430
17
13192531
28
14202632
39
212733
41016222834
51117232935
FEC’0
FEC’1
FEC’3
FEC’4
FEC’5
FEC0 FEC1 FEC2 FEC4 FEC5
1 data packet and its 2 associated FEC packets
?
06
12182430
17
13192531
28
14202632
39
2733
410
2834
51117232935
FEC’0
FEC’1
FEC’3
FEC’4
FEC’5
FEC’2
FEC0 FEC1 FEC2 FEC3 FEC4 FEC5
4 data packets positioned on exactly2 rows and 2 columns
?
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
IP UDP RTP MPEG-TS packets
IP UDP RTP Column FEC packets
IP UDP RTP Row FEC packets
Media
Same destination IP address (unicast node or multicast
group)
UDP Port n
UDP Port n+4
UDP Port n+2
Typical performanceL D I PLR overhead latency (ms) MTBE without FEC (sec) MTBE with FEC (day)
10 10 10 1,E-03 20% 525 2,74 32,8710 10 10 1,E-04 20% 525 27,40 42105,5010 10 10 1,E-05 20% 525 274,00 42336213,68
5 5 5 1,E-03 40% 127 2,74 35,135 5 5 1,E-04 40% 127 27,40 35431,835 5 5 1,E-05 40% 127 274,00 33688413,06
L D I PLR overhead latency (ms) MTBE before FEC (sec) MTBE after FEC (day)
10 10 10 1,E-05 10% 525 274,00 70,4710 10 10 1,E-06 10% 525 2740,00 7047,13
5 5 5 1,E-05 20% 127 274,00 158,565 5 5 1,E-06 20% 127 2740,00 15856,19
L D I PLR overhead latency (ms) MTBE before FEC (sec) MTBE after FEC (day)
10 1,E-05 10% 30 274,00 70,4710 1,E-06 10% 30 2740,00 7047,13
5 1,E-05 20% 16 274,00 158,565 1,E-06 20% 16 2740,00 15856,19
2D FEC
Row only 1D FEC
Column only
1D FEC
Reference : Video at 4Mb/s
transported with 7 MPEG-2 TS packets per
RTP/IP datagram
Legend:L : matrix row lengthD : matrix column depthI : Interleaving depth used in FEC packets sequencingPLR : Network Packet Loss RatioMTBE : Mean Time Between Errors
Error distribution: random/uniform
In seconds In days !
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 worldProposed Pro-MPEG Forum CoP#4, still leaves room for improvements (latency, etc)