Simplified packet loss simulation for TV over IP scenarios · 2007. 10. 30. · e-mail:...

Bachelor Thesis

Simplified packet loss simulation for

TV over IP scenarios

Author: Fredrik Kling

DATE: 30.10.2007

e-mail: [email protected]

2/44

- 2-

3/44

- 3-

Abstract

This report presents an application layer approach to simulate network packet

loss for use within, but not limited to, IP-TV scenarios. The basis is drawn

from classical packet loss simulations operating directly on the network level

which has then been transformed into an application level method. An

implementation of such a method is presented and also the results from packet

loss infliction on IP-TV streams using said method.

4/44

- 4-

5/44

- 5-

Table of contents

1 Problem description .................................................................................9

2 Scenario.................................................................................................11

2.1 Preconditions .................................................................................12

3 Background/Theory ...............................................................................13

3.1 Subjective quality...........................................................................13

3.2 Television ......................................................................................13

3.3 Broadcasting ..................................................................................14

3.4 Digital Video .................................................................................14

3.4.1 Encoding and Decoding..........................................................15

3.4.2 Digital Video Broadcasting ....................................................16

3.5 IP Networks ...................................................................................16

3.6 Broadcasting over Internet .............................................................17

3.7 Transportation................................................................................19

3.7.1 UDP / RTP.............................................................................20

3.7.2 MPEG2 Transport Stream ......................................................21

3.7.3 MPEG4 ..................................................................................23

3.8 Packet loss .....................................................................................24

3.9 Forward Error Correction...............................................................25

4 Methods.................................................................................................27

4.1 IP Packet simulation.......................................................................28

4.2 Impairments ...................................................................................28

4.2.1 Congested packet loss.............................................................29

4.2.2 Uniform model.......................................................................29

4.2.3 Trace files ..............................................................................29

4.3 Media encoding and decoding........................................................30

5 Future / Next step ..................................................................................31

6 Results...................................................................................................33

7 References .............................................................................................39

8 Appendix A, Controlling script ..............................................................41

9 Appendix B, TS Demuxer software usage..............................................43

9.1 Examples with partial program output............................................43

6/44

- 6-

7/44

- 7-

Abbreviations

SD Standard Definition

HD High Definition

MPEG Moving Pictures Expert Group

MPEG2-TS MPEG2-Transport Stream

ES Elementary Stream

PES Packetized Elementary Stream

IP Internet Protocol

IPTV Internet Protocol TeleVision

FEC Forward Error Correction

VoD Video on Demand

DVB Digital Video Broadcasting

CBR Constant Bit Rate

NAL Network Abstraction Layer

IGMP Internet Group Management Protocol

ITU International Telecommunications Union

ITU-T International Telecommunications Union - Telecommunications

IPI IP Infrastructure

RTP Real Time Protocol

UDP User Datagram Protocol

AVC Advanced Video Coding

TV TeleVision

8/44

- 8-

9/44

- 9-

1 Problem description

Investigate and implement an application layer packet loss simulator equivalent

to a network packet loss simulator for usage within digital video broadcasting

(DVB) over Internet (or IP) targeting the testing of end products (decoders).

10/44

- 10-

11/44

- 11-

2 Scenario

As the title suggests, this thesis will try to show how it is possible to simplify,

or optimize, simulated packet loss for IPTV. This is particular interesting for

testing of end user devices, software, in digital broadcasting environments,

such as IPTV.

To simulate the complete IPTV environment would be quite complex and

tiresome, especially if a lot of test cases apply. There is an obvious need to

optimize, but still be faithful to the original process.

The optimization, or simplification, of stream impairments, or simulated packet

loss, for IPTV presented in this thesis was developed in a larger scope when

doing preparations for a subjective quality test. The preparations involved the

generation of around 700 clips where each clip was 16 seconds in length. The

first attempts to conduct packet loss impairments, true to the DVB process for

IPTV involved a high work load, with many manual steps, aiming to include a

complete broadcasting setup, thus there was a need to simplify this process.

The proposed solution is highly adjustable, can be applied without manual

intervention and offers support for different types of error patterns as well as

third party error patterns.

When testing decoders for error concealment and robustness it is necessary to

produce data which stress different situations. Within digital video

broadcasting (DVB) this is often caused by either data loss or data corruption,

and the ability of the decoder to handle such situations.

For DVB over IP (IPTV) the main topic is data loss (or packet loss), since data

corruption, at the end, will translate into packet loss. Therefore we need to find

means to produce such corrupted data, in a well documented and orderly

fashion, and the process must be repeatable and guarantee same result.

12/44

- 12-

The same applies when subjective quality testing is conducted. Data, which

matches a set of preconditions, needs to be prepared and then shown to a user

panel which is given the task to score the quality as perceived.

2.1 Preconditions

The focus in this thesis is on video signals, therefore when referring to

standards covering both audio and video only the video part has been

considered.

IPTV broadcasting is assumed to use MPEG2 Transport Streams to encapsulate

the actual media streams. No other transport mechanisms are considered in the

implementation. This is further discussed in section 3.6 “Broadcasting over

Internet” (p. 17).

The number of MPEG2-TS packets in one IP packet is fixed to seven (even

though the proposed standard [3] (now withdrawn) allows for a lower number

of MPEG2-TS packets). Exception is given to the last IP packets, which will

contain the stray number of MPEG2-TS packets, a further discussion is

presented in 3.7.2 “MPEG2 Transport Stream” (p. 21).

Forward Error Correction (FEC) has not been considered in the

implementation. However, the presence of FEC will not change the theory nor

the results. It will be briefly mentioned in: 3.9 “Forward Error Correction” (p.

25).

13/44

- 13-

3 Background/Theory

This chapter aims to give the reader a deeper understanding of the topics which

relates to this thesis. It is written using a top-down approach giving the reader

possibility to easily skip over sections which are already familiar.

Most of this chapter introduces the readers to already existing standards.

Presented within the thesis are excerpts or parts of such standards that are

important for this thesis.

3.1 Subjective quality

Subjective quality is the quality perceived by the user of a service or product. It

can be measured only by subjective test panels; a statistical relevant group of

typical users, between 4 and 40 people ([7], page 11), are invited to score the

perceived quality of a given signal. This quality perception is highly dependent

on the expectation and the experience of the user on such a signal or service.

In certain cases, degradations are expected and accepted such as band width

limitation in telephony environments. For that reason it is obvious that

subjective testing should come as close as possible to the real use case when

tested.

By exposure to different parameters of the service or product, the user is asked

to grade the subjective quality as perceived. Data from many test subjects are

collected and thereafter used to train a device, or software, to automatically

judge the quality as a user would.

From the varying parameters it is possible to derive a statistical model that

maps to the actual quality curve. Such a mathematical formula can also be used

as a planning tool to estimate the subjective quality at certain parameters. The

E-Model is such a subjective quality model used for telephony [2].

3.2 Television

Television is the common name for displaying of audio-visual content. The

analogue displays were built to display images of Standard Definition (SD)

14/44

- 14-

quality, which is built up by 576i1 lines. By convention the width is set to 720

elements, although this is an artificial translation since the standard is based on

analog displays, thus not having fixed width. The introduction of digital

storage and digital flat panel displays increased the possibilities, and demand,

for better quality and more effective storage. Television development today is

mostly about High Definition (HD) TV, which effectively increase the

resolution three to five times that of traditional SD TV.

While SD comes in different types (PAL, NTSC, NICAM) depending on

geographic location, HD was developed to support different resolutions out of

the box within the same standard, effectively uniting the various geographic

differences.

3.3 Broadcasting

Broadcasting in this context refers to; “the distribution of audio and/or video

signals which transmit programs to an audience. The audience may be the

general public or a relatively large sub-audience, such as children or

adults”.[16]

3.4 Digital Video

Digital video refers to the compression, storage and transmission of said signal.

Compression is divided into two types; lossy and lossless compression.

When the restored compressed signal differs from the original signal the

compression is said to be lossy [14]. Lossy compression is commonly used for

coding of digital video. Example on such, lossy compression algorithms, are

MPEG2 video (part of the ISO/IEC-13818 standard) and H.264/AVC [15].

1 This is PAL-SD (Standard Definition) resolution, other resolutions was used in the US and

Japan as well as other countries, ‘i’ stands for “interlaced” which means that half-size images

are interleaved.

15/44

- 15-

3.4.1 Encoding and Decoding

Encoding refers to the process of compressing a digital signal. Decoding refers

to the inverse encoding process, which translates the compressed signal back to

the signal or close to it (in case of lossy compression)2.

The process of encoding and decoding is closely coupled and the term “codec”

is often used, describing the device, or software, accomplishing the task.

Encoder

Source Video

Decoder

Lossless

Lossy

Raw Signal

Elementary Stream

Decompressed

signal

Decompressed

signal

Equal!

Codec

Layer

Figure 1, Encoding / Decoding process

The result of the encoding process is normally a so called Elementary Stream

(ES). The ES defines the lowest type of storage container, which can still be

decoded in an orderly fashion. The Elementary Stream, and the structure

thereof, defines many key parameters for later use, such as error robustness.

Today the use of the MPEG2 video codec is used for TV broadcasting and for

DVD movies. It provides fair enough compression, and is suitable for error free

environments. However, it is quite old (published in 1996), and the computer

power today allows for far better codecs.

2 Figure 1, Encoding / Decoding process

16/44

- 16-

MPEG43, first published in 2000, was to become the successor of MPEG2. But

it would take some time, until 2004 before the video part was extended to

MPEG4-Part 10 Advanced Video Coding (AVC) (or H.264 [15], which is the

ITU-T equivalent coding) thus allowing MPEG4 video to be used for MPEG2

video replacements in next generation DVD’s (HD-DVD and BlueRay4) and

broadcasting.

H.264 / AVC did also target some weak points in MPEG2 when used in error

prone environments, such as mobile networks or IP networks and low

bandwidth networks.

3.4.2 Digital Video Broadcasting

Digital Video Broadcasting (DVB) is the general term, referring to all types of

video broadcasting techniques in the digital domain. Some DVB techniques

worth mentioning are; DVB-T for terrestrial, DVB-H for handheld devices and

DVB-IPI [17] for IP networks. All of the above mentioned techniques are

maintained by the DVB Project5, an industry consortium with over 260

members.

3.5 IP Networks

Internet Protocol (IP) based networks have emerged as the most wide spread

consumer networks. When connected to each other they make up what we

today call the Internet. The foundation of Internet is the Internet Protocol (IP).

IP is used to address computers on the Internet and carry principal information

about what type of data is being transported, as well as carrying the data itself.

It is important to understand that IP very often refers to the family of IP related

protocols, such as TCP, UDP, ICMP and RTP (and many more).

One of the important features of IP is the possibility to split a data segment

across several packets, so called fragmentation. Since IP packets are

3 A number of documents (parts) that became the ISO/IEC 14496 standard 4 HD-DVD and BlueRay are competing standards for the next generation DVD 5 http://www.dvb.org

17/44

- 17-

encapsulated within link-layer frames for transport, the Maximum Transport

Unit (MTU), for said transport decides if a packet needs to be divided into

several packets. If one of those fragments is lost, the whole IP packet

(including all data) is lost. IP fragmentation has a big impact on the design and

architecture of network applications, especially streaming applications.

Regardless if the upper protocols are UDP, TCP or any other IP-family

protocol they are all affected by the IP fragmentation rules.

For Ethernet-based networks the MTU is defined to either 1492 bytes or 1500

bytes [3]. However, for some link layers (wide-area links) frame sizes can be

as low as 576 bytes ([8], p. 328). This will of-course put restrictions on how

well IPTV works depending on the underlying network architecture.

3.6 Broadcasting over Internet

Television broadcasting over Internet (IPTV) is a new market. This thesis

describes Internet broadcasting from the view of real time television in a

quality comparable, or better, to what we have today in our analogue or digital

(DVB-T) broadcasting network. It will not discuss the type of Internet

broadcasts presented by YouTube6 or web-based TV streaming. It is assumed

that IP is used as a carrier replacement for TV services (hence the name IPTV).

The focus is on simplification and optimization of test procedures of consumer

devices, or software, and problems related to the transmission of IPTV signals7.

Not the testing itself, nor the end user equipment, but rather optimization of

simulation of transmission problems that will have an impact on the final

quality.

6 http://www.youtube.com, an online video sharing service 7 Figure 2, Simplified IPTV end to end data flow

18/44

- 18-

transmission

consumer

producer

Media encoding

Multiplexing

Sending

Receiving

Demultiplexing

Media decoding

Transmission

over

Internet (IP)

Main dataflow

Figure 2, Simplified IPTV end to end data flow

There exist two principal types of delivery methods for IPTV. Multicast which

is used in broadcasting scenarios, and Unicast which is used to send a

dedicated data stream to a specific user. In both cases, the stream is

encapsulated inside a MPEG2 Transport Stream.

Multicast refers to the technique of sending one packet to many receivers in an

ordered fashion. The traffic is divided into groups and special messages are

sent by the client to access such groups. Each group carries a specific data

stream (or broadcast stream). Hence not all data streams are duplicated to all

users but only the necessary streams. Internet Group Management Protocol

Version 3 (IGMP v3) [9] defines the protocol between the client and the

directly attached router, for how clients (receivers) and server (sender)

interact8. This implies that multicast traffic requires network equipments, such

as routers, to be aware of multicast traffic. Multicast groups uses a fix address

space [10], making routing between operators some what complicated.

8 Figure 3, IGMP protocol communication

19/44

- 19-

IGM

P

IGM

P

IGM

P IGM

P

Figure 3, IGMP protocol communication

Unicast is the opposite of multicast. It is used by one user to consume a

specific data stream. Unicast is very often used in Video on Demand (VoD)

services, where the user receives a dedicated stream. Unicast is only mentioned

here to point out the existence of two different delivery methods, and the

difference between them.

3.7 Transportation

Transportation is the transmission of encapsulated media signals. The IPTV

related protocol stack is in this section discussed in detail. The rightmost

situation9 where RTP is placed directly on top of IP is consequence of; “The

transport over IP is via RTP only.” ([17], p. 22). Even if the RTP definition

[18] does not explicitly prohibit the use of RTP directly over IP it is neither

endorsed. H. Schulzrinne et al [18] (section 11, p. 67) presents a more detailed

discussion about RTP and encapsulation within various network protocols.

9 Figure 4, IPTV protocol stack

20/44

- 20-

Figure 4, IPTV protocol stack

3.7.1 UDP / RTP

There exist mainly two types of transportation, and a mix thereof, for IPTV.

IPTV can be broadcasted, on top of IP that is, using either User Datagram

Protocol (UDP [19]) or Real Time Protocol (RTP [18]) or RTP in UDP. Which

method is used depends on a few factors. Firstly there has not been any

standard defining clearly how IPTV should be transported. The DVB-IPI [17]

came out late 2006 and deals only with RTP for transportation; “The transport

over IP is via RTP only” ([17], p. 22). The, now withdrawn, standard [3]

defines the transport as: [IP, UDP, RTP, {MPEG2-TS,…}].

While connection oriented protocols like TCP guarantees data delivery and at a

first glimpse might seem suitable for almost all applications, it adds too much

overhead to the network infrastructure in the case of IPTV. Since TCP uses

internal states per connection to track the clients a service relying on TCP will

have to keep a separate connection per client. This will scale poorly when the

number of concurrent connections increases. Also, each data stream will be

duplicated per client access, thus filling the network with redundant data.

Instead connectionless protocols, such as UDP, are used. They provide fast

access without any requirement of response from the other side and do not

maintain states to track the clients, a server can (more or less) just start send

packets to the client as it see fit. These are the main differences from TCP, for

21/44

- 21-

a good list of reasons why UDP (and RTP) sometimes is to be preferred over

TCP ([8], p. 197).

3.7.2 MPEG2 Transport Stream

The core of any DVB service up to this date is using the MPEG2 System

standard [1] to define how the DVB streams are packetized before

broadcasting. The standard defines the MPEG2 Transport Stream (MPEG2-TS)

to be used when encapsulating, multiplexing10, the actual video and/or audio

content, together with other descriptive data such as subtitle, service provider,

program information and so forth.

Figure 5, MPEG2-TS Multiplexing

MPEG2 Transport Streams are independent of the media format (codec type),

hence they can, in theory, transport any type of codec data. All media data is

packetized into Packetized Elementary Stream (PES) packet before given to the

MPEG2-TS multiplexer. Special packet types, such as Program Map Table

(PMT) and Program Association Table (PAT), are used to map and identify the

different elementary streams with the different audio and video codecs.

According to the old (withdrawn) standard [3] the number of MPEG2-TS

packets per IP packet should be limited to seven (giving a maximum packet

length of 1 356 bytes). Where IP or RTP header options are used the number of 10 Figure 5, MPEG2-TS Multiplexing

Video stream (ES)

Audio stream (ES)

Transport stream (TS)

PES data

22/44

- 22-

MPEG2-TS packets per IP packet may need to be less than seven to stay within

the MTU.

Figure 6, MPEG2-TS inside an IP packet

The standard: ETSI TS 102 034, V1.2.1 (2006-09), Digital Video Broadcasting

(DVB); Transport of MPEG-2 Based DVB Services over IP Based Networks

[3] defines DVB broadcasting over IP by means of MPEG2-TS. Even though

the standard has officially been withdrawn it is still used, and referred to.

A new standard, which has not yet been fully published, is on the way.

However, in the meantime there is a continuing effort, called “Guidelines for

DVB IP Phase 1 Handbook” [17] (which actually refers to the withdrawn TS

102 034 [3] standard).

MPEG2 video, which was developed in conjunction with the transportation

mechanism was not really considered to be used in error prone environments.

When the Elementary Stream (ES) is broken down to frames only the frame

contains resynchronization points11 for the decoder. This has implications on

higher resolutions, where a packet in the middle of a frame will cause the rest

of the frame to become invalid; even if later parts of the frame are perfectly

retrieved the codec may not be able to resynchronize.

Vid

eo

sta

ndard

Figure 7, MPEG2 breakdown with Frame resynchronization points

11 Figure 7, MPEG2 breakdown with Frame resynchronization points

23/44

- 23-

3.7.3 MPEG4

MPEG4 does not specify the delivery layer but rather an interface; “DMIF

Application Interface” [5]. It allows MPEG2-TS as one of the supported

methods to encapsulate MPEG4 [5]. However, worth mentioning is that in the

AVC/H.264 standard (Part 10, of the MPEG4 standard) an important

component is added, called: “Network Abstraction Layer” (NAL), which is put

before the transport stream layer12. This allows MPEG4/AVC NAL units to be

delivered directly on top of UDP/RTP without the overhead, and limitations, of

MPEG2-TS.

Figure 8, MPEG2 and MPEG4 layers

12 Figure 8, MPEG2 and MPEG4 layers

24/44

- 24-

The NAL units basically break down the MPEG2 frame structure13 in finer

blocks. This allows for many more resynchronization points14 within each

frame, and allows the decoder easier recover from packet loss.

Vid

eo

sta

nda

rd

Figure 9, H.264 breakdown with NAL resynchronization points

Since each NAL unit acts as a partial image re-synchronization point, H.264 /

AVC becomes more robust than MPEG2 against packet loss.

3.8 Packet loss

Packet loss is the general term to describe a lost chunk of data (packet or

packets) within the transmission time frame of interest. Basically there are two

types of packet loss; uniformly distributed packet loss and congested packet

loss.

In the IP world packet loss is described on the IP-level (complete loss of an IP

packet, regardless of fragmentation) and the actual information loss is implicit

to the other levels of the protocol stack (since they are contained in the data

portion of the IP packet). However, packet loss could be described at the higher

application levels if a mapping between the IP layer and the higher application

layer exists.

When conducting studies of end user software behavior in digital broadcasting

environments, such as IPTV, there is often a need to inflict impairments on the 13 Figure 7, MPEG2 breakdown with Frame resynchronization points 14 Figure 9, H.264 breakdown with NAL resynchronization points

25/44

- 25-

data streams fed to the software. Normally this is done by using some sort of

artificial packet loss, or stream impairment (effectively causing the receiving

end to drop the packet), operating on the network layer. However, for studies

of the perceptual quality dimensions packet loss can be simulated higher up in

the protocol hierarchy15 thus it is possible to simplify the process dramatically.

Uniform packet loss occurs with an equal distribution over the time domain.

Each packet is given exactly the same probability of getting lost. It has certain

academic value but no real mapping to real world scenarios.

Congested packet loss is characterized by long periods of no packet loss and

short periods of high packet loss. Packet loss studies such as [4] and [6]

suggests that packet loss behavior is rather congested than uniform. In practice

it means that during a period of time, after the first packet is lost, the

probability of loosing yet another packet is higher than the first packet.

Kurose and Ross [8] attributes congested packet loss to queuing delay in nodal

points over the Internet; “a packet can arrive to find a full queue. With no place

to store such a packet, a router will drop that packet; that is, the packet will be

lost.” ([8], p. 42).

Packet loss is normally attributed to the network level. To simulate network

related packet loss correctly one would need to simulate a network, or impair

packet loss in real time on live streams. Using the mapping16 between the

application level and the network level, packet loss could be simulated directly

on the application level protocols.

3.9 Forward Error Correction

Forward Error Correction (FEC) is a description of methods used to minimize

the impact of packet loss, or to recover from it completely. FEC operates by

15 Figure 4, IPTV protocol stack 16 Figure 6, MPEG2-TS inside an IP packet

26/44

- 26-

extending the actual data and by making use of clever resending so that lost

data can be reconstructed. Kurose and Ross ([8], p. 591) presents a good

introduction to FEC, although they exemplify the use of FEC with only audio

streams, FEC is by no means limited to only audio.

For DVB broadcasting each of the MPEG Transport Stream packets is

extended by a shortened Reed-Solomon error protection code leading to a DVB

MPEG2-TS packet consisting of 204 bytes. In combination with convolution

coding and appropriate modulation schemes, a so called quasi-error free

transport of DVB services can be guaranteed which means that in average only

one non-correctable error occurs within one hour of program presentation.

More information about convolution coding and Reed-Solomon error

protection codes can be found at the Wikipedia17.

The presence of FEC does not change anything in the material presented in this

thesis. However, when simulating packet loss FEC must be taken into

consideration for the packet loss rates. The presence of FEC will lower the

packet loss rate, how much would depend on FEC settings and models and is

out of scope here.

17 http://en.wikipedia.org/wiki/Convolutional_code

27/44

- 27-

4 Methods

This section contains descriptions of the methods chosen when implementing

the solution.

A general overview of the different modules created to support the

implementation of the simplified packet loss generation is displayed in figure

10, overview of realisation. The data capture feeds the application with

MPEG2-TS packets, the application is responsible of grouping them into IP

packets (3.7.2 MPEG2 Transport Stream). Demultiplexing the MPEG2-TS into

the different elementary streams is done as part of the analysis module. The

loss model is invoked with statistics from IP Grouping, and depending on the

result the demultiplexed data is saved.

Capture data

Analyse

data

Application

Begin data

input

Packet delivery

AnalyzePacket

Result from Analyze

Consume

all data

MPEG2-TS

ES Handler

PES Parser

Media

Analyzer

ModulesLossModel

Calculate

Loss

Loss Indication

ES Storage

(demultiplex)

Handle

media

1

2

4

3

Figure 10, Overview of realisation

28/44

- 28-

4.1 IP Packet simulation

The simulation of IP packets is performed on the MPEG2-TS packet level, by

means of grouping. As described in 3.7.2, MPEG2-TS packets are packetized

into IP data portion with up to seven MPEG2-TS packets at the time. When

parsing the MPEG2-TS stream treating the packets as part of a specific group it

is easy to provide the said grouping to the application, and also create artificial

IP packet statistics. This defines the mapping from the higher application level

to the IP, thus enabling us to perform IP packet loss simulations directly on

MPEG2-TS groups. All IP options, related to packet loss, can be applied on

such artificial statistics.

Figure 11, MPEG2-TS in IP data

4.2 Impairments

Any kind of transmission related problem, except for jitter, is assumed to result

in packet loss. This is also the only type of impairment that is considered in this

thesis. Any other kind of impairment, such as data corruption, will translate to

packet loss on the receiving end. Since no such packet is normally allowed to

the application layer by the IP-stack.

29/44

- 29-

4.2.1 Congested packet loss

A two-state Markov model18 is a widely used method for simulation of

congested packet loss. It uses two states (loss and no-loss) and probability

factors to move between the states. For error prone environments a

modification of the two-state Markov model called Gilbert model [11] is

commonly used. The Gilbert model introduces two probability factors in the

two states for actual packet loss, essentially creating a multi-state Markov

chain. Such multi-state Markov model has not been considered in this thesis.

Figure 12, Two state Markov model

4.2.2 Uniform model

Uniform packet loss is given by a certain probability of loss equally distributed

over all packets across the time domain. Every packet is given an equal

opportunity of getting lost.

4.2.3 Trace files

Not an actual loss model, but more of a user feature. The trace contains an

entry per IP packet and can be written and read by the application. Upon

writing the application creates a “non-action” tag on each packet. This can later

be changed by a third party application, such as Matlab19. Upon reading, the

application can drop a specific packet, depending on the tagging. This

mechanism allows packet loss models to be implemented independent of the

application. The trace file employs a simple comma separated structure.

18 Figure 12, Two state Markov model 19 Matlab is a commercial application often used to solve mathematical problems, see:

http://www.mathworks.com/ for more details.

30/44

- 30-

4.3 Media encoding and decoding

All test files were encoded using the video standard H.264 with the encoder

x26420 (revision: R609, with slice support), a free h264/avc encoder. The files

were encoded with the following parameters:

Frame rate: Same as source (24 fps)

Resolution: Standard definition TV (720x576), progressive

Bit rate: 4 Mbit/sec

Key frame rate: 0.5 Hz

The source material was provided by SwissQual AG21, coming from an

uncompressed source. While important for later use of the processed material,

it has no direct implication on the results of the simulated packet loss.

After encoding, each file was encapsulated (multiplexing with only one stream)

into MPEG2 Transport Streams using the ffmpeg22 tool.

Packet loss was inflicted as part of the demultiplexing the H.264 Elementary

Stream (ES) from the MPEG2 Transport Stream, using the earlier mentioned

techniques. The demultiplexing / packet loss tool was written as part of this

thesis. A small description and user guide is provided in “9

20 http://www.videolan.org/developers/x264.html 21 SwissQual AG, www.swissqual.com 22 http://ffmpeg.mplayerhq.hu/

31/44

- 31-

Appendix B, TS Demuxer software usage”.

Decoding of the media was done with a H.264 decoder from T-Systems23. The

decoder was chosen because of the ability to handle packet loss and heavily

impaired streams. The decoder is not publicly available.

23 T-Systems is a division of Deutsch Telekom

32/44

- 32-

5 Future / Next step

This thesis has been dealing with a very limited problem. Within the large

scope (as mentioned in: “2

33/44

- 33-

Scenario”) of complete subjective testing there are many parameters to

consider. The work presented here has been part of a larger processing chain

used to prepare video clips for subjective testing.

When using packet loss simulation one should use real packet loss values,

taken from measurements of actual networks which correspond to the

environment of the simulated scenario.

The current solution is also limited to IP networks. Even if broadcasting

networks are converging towards IP based transmission in between themselves

it is by no means limited to IP. By extending the current solution to allow for

different grouping (and maybe even fragmentation within) settings other

network types could easily be simulated.

The actual packet loss could be made more predictable on short streams by

building drop tables that better match the targeted packet loss rate. As of now,

the targeted packet loss rate can be quite different from the actual packet loss

rate in case of low amount of packets.

34/44

- 34-

35/44

- 35-

6 Results

The results presented shows two of the different patterns of packet loss,

uniform and congested. Results are based on simulations of packet loss using

an implementation of the presented method.

The table shows the data that were used, and gathered, when doing the

simulation.

Target loss Nr. Lost packets Actual loss p-Factor q-Factor

2 % 116 2.79% 0.0032 0.15

4 % 248 3.83% 0.012 0.25

8 % 501 7.73% 0.025 0.25

16 % 973 15.01% 0.03 0.17

Table 1, Parameters for simulation of congested packet loss

The actual loss values are taken from the program output and should only be

used as a hint whatever the targeted packet loss was achieved or not.

The parameters for the Markov model (p-Factor and q-Factor) where derived

from experimentation. The p-Factor controls the probability to start a burst

(higher values on p-Factor gives more bursts), and the q-Factor controls the

size of that burst (higher values on q-Factor gives longer bursts).

There is no standardized way to set the factors of a Markov chain to achieve a

certain loss rate, therefore several different values were tested before the actual

values for the Markov factors were chosen.

36/44

- 36-

The following images (figure 13 to figure 16) illustrate the packet loss

distribution for congested packet loss at the various levels. A darker mark

means a lost packet. Each pixel column in the image corresponds to one IP

packet. Since the number of packets (6482) exceeds the number of pixels

(1024) in the image, the images should be used as indication and brief

overview of the packet loss distribution.

Figure 13, Distribution of 2% congested packet loss




In comparison to the uniform loss distribution (Figure 17 to Figure 20):

Figure 17, Distribution of 2% uniform packet loss




The images give a little bit better idea on how the overall distribution looks like

between the different models.

37/44

- 37-

When doing a close up of a specific section (no scaling of the image) it is

easily observed how packet loss pattern looks like, several packets are grouped

together, and therefore lost consecutively.

Figure 21, 16% congested packet loss, close up marking

Figure 22, close up within 16% congested packet loss

The pattern of figure 21 and figure 22 also show the outcome of the Markov

model. The selected “q” and “p” factors control the consecutive length of each

packet loss segment. By changing them we can create different loss patterns

and simulate, or stress, different problems in the end user equipment.

38/44

- 38-

Figure 23 to figure 26 show results from uniform packet loss of H.264 encoded

video (using the encoding parameters described in 4.3).

Figure 23, Capture from 2% uniform packet loss




39/44

- 39-

Figure 27 to figure 30 show results from congested packet loss of same data

stream.

Figure 27, Capture from 2% congested packet loss




Since it is almost impossible to draw some kind of conclusions from

screenshots alone, no further elaboration is made from the following

screenshots. However, the images do give an idea about the effect caused by

packets loss at certain rates.

40/44

- 40-

41/44

- 41-

7 References

[1] ISO/IEC 13818-1, “ISO/IEC 13818-1 (MPEG-2 Systems)”, March 1994

(Interim version, not fully published)

[2] ITU-T G.107 Recommendations, “The E-Model, a computational model for

use in transmission planning”, December 2008.

[3] ETSI TS 102 034, V1.2.1 (2006-09), Digital Video Broadcasting (DVB);

Transport of MPEG-2 Based DVB Services over IP Based Networks

[4] Seung-Hwa Chung et al., Analysis of Bursty Packet Loss Characteristics on

Underutilized Links Using SNMP, <

http://www.cs.purdue.edu/nsl/e2emon04.pdf >, July 4:th 2007.

[5] ISO/IEC 14496-1 Information technology, “Coding of audio-visual objects

— Part 1: Systems”, 1999-12-15, First Edition

[6] Konstantina Papagiannaki, Rene Cruz and Christophe Diot, Network

Performance Monitoring at Small Time Scales, Internet Measurement

Conference, Miami, Florida USA, October 2003.

[7] ITU-T P.910 Recommendations, “Subjective video quality assessment

methods for multimedia applications”, September 1996.

[8] Kurose, Ross (2005) Computer Network; A Top-Down Approach Featuring

the Internet, 3:rd Edition, Pearson Education Inc.

[9] B. Cain et al., RFC 3376, “Internet Group Management Protocol, Version

3”, October 2002,< http://www.rfc-editor.org/rfc/rfc3376.txt > (visted: July

18:th 2007).

[10] Charles M. Kozierok, “The TCP/IP Guide” (Version 3.0), September

20, 2005, < http://www.TCPIPGuide.com >,

free/t_IPMulticastAddressing.htm, (visited: July 4:th 2007).

[11] Packet Loss Burstiness, “VoIP Troubleshooter.com”, <

http://www.voiptroubleshooter.com/indepth/burstloss.html >, (visited: July

5:th 2007).

[12] IEEE 802.3-2000: “IEEE Standard for Carrier Sense Multiple Access

with Collision Detection (CSMA/CD) Access Method and Physical Layer

Specification".

[13] IEEE 802.2-1998: "IEEE Standard for Information technology--

Telecommunications and information exchange between systems - Local

42/44

- 42-

and metropolitan area networks – Specific requirements - Part 2: Logical

Link Control".

[14] Wikipedia, “Lossy compression”, <

http://en.wikipedia.org/wiki/Lossy_data_compression >, (visited: July 9: th

2007).

[15] ITU-T H.264 Recommendations, “Advanced video coding for generic

audiovisual services”, March 2005.

[16] Wikipedia, Broadcasting, < http://en.wikipedia.org/wiki/Broadcasting

>, (visited: July 9: th 2007).

[17] ETSI TR 102 542, V1.1.1 (2006-11), “Digital Video Broadcasting

(DVB); Guidelines for DVB IP Phase 1 Handbook”

[18] H. Schulzrinne et al, July 2003, “RTP: A Transport Protocol for Real-

Time Applications”,< http://www.ietf.org/rfc/rfc3550.txt >, (visited: July

18:th 2007)

[19] J.Postel, ISI, 28 August 1980, RFC 768, “User Datagram Protocol”, <

http://www.ietf.org/rfc/rfc768.txt >, (visited July 18 2007).

43/44

- 43-

8 Appendix A, Controlling script

The following is used to execute the script for uniform and congested packet

loss scenarios, for a detailed explanation see: demux.exe -p 256 -i input.ts –u percentage=2 -w 1 - o output.ts

demux.exe -p 256 -i input.ts -m p-factor=0.0002:q-f actor=0.3 -w 1 -o output.ts

Actual command line used to generate impaired streams: rem

rem uniform

rem

tsdemuxer.exe -p 256 -i output\[email protected] uv.br-4000.KI-48.264.ts -u

percentage=2 -w 1 -o output\[email protected]. br-4000.KI-

48.264.ts.264.imp-2-2.264



48.264.ts.264.imp-4-2.264



48.264.ts.264.imp-8-2.264


percentage=16 -w 1 -o output\[email protected] .br-4000.KI-

48.264.ts.264.imp-16-2.264

rem

rem bursty

rem

tsdemuxer.exe -p 256 -i output\[email protected] uv.br-4000.KI-48.264.ts -m

p-factor=0.0132:q-factor=0.55 -w 1 -o output\Dillis [email protected]

48.264.ts.264.bimp-2-2.264


p-factor=0.03:q-factor=0.58 -w 1 -o output\Dillisto [email protected]

48.264.ts.264.bimp-4-2.264


p-factor=0.05:q-factor=0.50 -w 1 -o output\Dillisto [email protected]

48.264.ts.264.bimp-8-2.264


p-factor=0.1:q-factor=0.47 -w 1 -o output\Dilliston [email protected]

48.264.ts.264.bimp-16-2.264

44/44

- 44-

45/44

- 45-

9 Appendix B, TS Demuxer software usage

This appendix is just a brief introduction via examples on how to use the

software to impair transport streams or just to demux them. The

implementation is done as a command line application.

Output when run without parameters (display of help): MPEG-2 TS Demuxer/Impairment simulator v0.1, (c) FK ling 2007

Useage: tsdemuxer [options]

Options:

-a Automatic ES demuxing and filenaming (no ou tput option needed)

-t Generate and save trace file, use: -t

-p Demux specific PID, use: -p , can not be used with -a

-i Specify input file (only for legacy with pr evious tools!)

-o Specify output file (only for legacy with p revious tools!)

-d Use IP based dropping from a previous trace file, use: -d

-m Use two-state markov modell for dropping, u se: -d (-d help,

for info)

-u Use uniform modell for dropping, use: -u (-u help, for info)

-w Wait number of frames before impairment sta rts

-v Be verbose

9.1 Examples with partial program output

Automatic demultiplexing of streams within a MPEG2 Transport Stream:

(Using the –a option) C:\DevResearch\DTAG\m2tsdemuxer\bin>tsdemuxer -a fi le.ts

Analysing: file.ts

Running

Program Identifiers in Stream

PID: 256 (100), Type: estVideoH264 (27)

Demuxing ES to file: out_256_estVideoH264.h264

PID: 7501 (1d4d), Type: 21 (21)

[!] Warning: Skipping unknown ES with ID: 7501

Demux completed!

Statistics:

IP-Packets 1655 (TS = 11588)

Media Frames: 0

Explicit demultiplexing with 2% target uniform packet loss: C:\DevResearch\DTAG\m2tsdemuxer\bin>tsdemuxer.exe - v -p 256 -i file.ts -u

percentage=2 -o result.264

Analysing: file.ts

Running


46/44

- 46-


Demuxing ES to file: result.264

PID: 7501 (1d4d), Type: 21 (21)

Dropping packet: 101


….



Demux completed!

Statistics:

IP-Packets 1655 (TS = 11588)

Dropped 22 (= 1.32930513595166%)

Media Frames: 378

Explicit demultiplexing with congested packet loss: C:\DevResearch\DTAG\m2tsdemuxer\bin>tsdemuxer.exe - p 256 -i file.ts -m p-

factor=0.0132:q-factor=0.55 -w 1 -o result.264

Analysing: file.ts

Running



Demuxing ES to file: result.264

PID: 7501 (1d4d), Type: 21 (21)



…







Demux completed!

Statistics:

IP-Packets 1655 (TS = 11588)

Dropped 35 (= 2.11480362537764%)

Media Frames: 374

C:\DevResearch\DTAG\m2tsdemuxer\bin>

Simplified packet loss simulation for TV over IP scenarios · 2007. 10. 30. · e-mail:...

Documents

Transcript of Simplified packet loss simulation for TV over IP scenarios · 2007. 10. 30. · e-mail:...