safe video contribution & distribution over ip networks philippe lemonnier

19
Safe Video Contribution & Distribution over IP Networks Philippe LEMONNIER

Upload: drusilla-conley

Post on 25-Dec-2015

219 views

Category:

Documents


0 download

TRANSCRIPT

Safe Video Contribution & Distribution over IP Networks

Philippe LEMONNIER

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)

Thank you for your attention !

[email protected]

http://www.thomsongrassvalley.com/