Download Phillipe Lemonnier`s presentation

Safe Video Contribution & Distribution
over IP Networks
Philippe LEMONNIER
Compressed realtime Video over IP
>
Application
Network Process to Application
Host layers
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.
Presentation
Data Representation & Encryption
Session
MPEG2 A/V
MPEG2-TS
RFC2250
Interhost Communication
Transport
End-to-End Connection Reliability
Network
Path Determination/Logical Addressing
Media layers
>
RTP (RFC1889)
IGMP
UDP (RFC768) (RFC2236)
IP (RFC791)
Data Link
MAC & LLC (physical addressing)
Physical
Media, signal & Binary Transmission
OSI model
MPEG compressed A/V
contents mapped over
IP with the IETF
toolbox
MPEG-TS mapping over IP & Ethernet
MPEG Transport Stream packets
188 bytes
188 bytes
188 bytes
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
Ethernet header
IP header UDP header RTP header
MPEG-TS payload
Ethernet CRC
4 bytes
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.
IP networks main drawbacks
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…)
Origin of network errors
At OSI levels 1 and 2




At OSI levels 2 and 3
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.

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.
Medium impairment
Bridge / Router
CRC OK ?
Received frame
No
Yes
Proceed to MAC,
and upper to IP
Bridge / Router
Payload burst
Port 1 (in)
FIFO
Payload burst
Port 2 (in)
Port 1 (in)
Port 3 (out)
FIFO
Port 2 (in)
FIFO is full
Incoming
data
dropped
Pro-MPEG Forum WAN Group
Objectives
Provide a forum for manufacturers,
end-users and service providers to cooperatively develop interoperable
systems for real-time delivery of highquality 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
RTP stream to protect
Pkt 1
Pkt 2
Pkt 3
Pkt 4
Pkt 5
Pkt n
Pkt n+1
Pkt n+2
FEC 1
Pkt 1
Pkt 2
Pkt 3
FEC 1
Pkt n+3
FEC (n+2)/3
Pkt 4
Pkt 5
Pkt n
Pkt n+1
Pkt n+2
FEC (n+2)/3
RTP stream with embedded FEC
 Most simple FEC
 Low latency mechanism
 Can only protect from single packet loss
1D column FEC overview
RTP stream
to protect
0
1
2
L-1
L
L+1
L+2
2L-1
2L
2L+1
2L+2
3L-1
3L
Pkt 3L+1
3L+2
4L-1
(D-1)L
(D-1)L+1 (D-1)L+2
DL-1
D rows
RTP
&
FEC C0
FEC C1
FEC C2
L Columns
FEC CL-1
RTP-FEC
combiner
Example of correction hits
1 and at most 1 data packet per column
0
6
1
7
18
24
30
19
25
31
FEC0
FEC1
2
8
14
20
32
FEC2
3
9
15
21
27
33
burst of L consecutive data packets
4
10
16
22
28
34
0
6
1
7
2
8
11
17
23
29
35
18
24
30
19
25
31
20
26
32
FEC4
FEC5
FEC0
FEC1
FEC2
3
9
4
5
21
27
33
16
22
28
34
17
23
29
35
FEC3
FEC4
FEC5
Example of correction failures
2 data packets on the same column
0
6
12
18
24
30
1
7
13
19
25
31
FEC0
FEC1
2
8
1 data packet and its associated FEC
packet
32
3
9
15
21
27
33
4
10
16
22
28
34
5
11
17
23
29
35
0
6
12
18
24
30
1
7
13
19
25
31
2
8
14
20
26
32
FEC2
FEC3
FEC4
FEC5
FEC0
FEC1
FEC2
?
20
?
3
9
21
27
33
?
4
10
16
22
28
34
5
11
17
23
29
35
FEC4
FEC5
2D – FEC scheme overview
RTP stream
to protect
0
1
2
L-1
FEC R0
L
L+1
L+2
2L-1
FEC R1
2L
2L+1
2L+2
3L-1
FEC R2
3L
Pkt 3L+1
3L+2
4L-1
FEC R3
DL-1
FEC RD-1
(D-1)L
(D-1)L+1 (D-1)L+2
D rows
RTP
&
FEC C0
FEC C1
FEC C2
L Columns
FEC CL-1
RTP-FEC
combiner
Sample correction hit
6x6 data matrix with 9 data packets lost and 1 FEC packet lost
0
6
12
18
24
30
1
7
13
19
25
31
2
8
14
20
26
32
3
9
15
21
27
33
4
10
16
22
28
34
5
11
17
23
29
35
FEC0
FEC1
FEC2
FEC3
FEC4
FEC5
FEC’0
FEC’1
FEC’3
FEC’4
FEC’5
The 9 missing data packets are successfully recovered !!!
Sample correction failures
1 data packet and its 2 associated FEC
packets
0
6
12
18
24
30
1
7
13
19
25
31
2
8
14
20
26
32
FEC0
FEC1
FEC2
3
9
?
21
27
33
4
10
16
22
28
34
5
11
17
23
29
35
FEC4
FEC5
FEC’0
FEC’1
FEC’3
FEC’4
FEC’5
4 data packets positioned on exactly
2 rows and 2 columns
0
6
12
18
24
30
1
7
13
19
25
31
2
8
14
20
26
32
3
9
4
10
27
33
28
34
5
11
17
23
29
35
FEC0
FEC1
FEC2
FEC3
FEC4
FEC5
?
FEC’0
FEC’1
FEC’2
FEC’3
FEC’4
FEC’5
Video & FEC data & streams
UDP Port n
Media
UDP
IP
RTP
UDP
RTP
Elegant, does not break the
original AV stream
>
A receiving party can use :
MPEG-TS packets
UDP Port n+2
IP
>
Column FEC packets
>
IP
UDP
RTP
Row FEC packets
UDP Port n+4
Same destination IP address
(unicast node or multicast group)
>
>
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
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
overhead latency (ms)
In seconds
In days !
L D I
PLR
10 10 10
10 10 10
10 10 10
1,E-03
1,E-04
1,E-05
20%
20%
20%
525
525
525
2,74
27,40
274,00
32,87
42105,50
42336213,68
5 5 5
5 5 5
5 5 5
1,E-03
1,E-04
1,E-05
40%
40%
40%
127
127
127
2,74
27,40
274,00
35,13
35431,83
33688413,06
L D I
PLR
10 10 10
10 10 10
1,E-05
1,E-06
10%
10%
525
525
274,00
2740,00
70,47
7047,13
5 5 5
5 5 5
1,E-05
1,E-06
20%
20%
127
127
274,00
2740,00
158,56
15856,19
L D I
PLR
overhead latency (ms)
MTBE without FEC (sec) MTBE with FEC (day)
2D FEC
MTBE before FEC (sec) MTBE after FEC (day)
Column
only
1D FEC
Error distribution: random/uniform
overhead latency (ms)
MTBE before FEC (sec) MTBE after FEC (day)
10
10
1,E-05
1,E-06
10%
10%
30
30
274,00
2740,00
70,47
7047,13
5
5
1,E-05
1,E-06
20%
20%
16
16
274,00
2740,00
158,56
15856,19
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 !
[email protected]
http://www.thomsongrassvalley.com/