TITRE Adaptive Packet Video Streaming Over IP Networks - LaBRI

More documents

Recommendations

Info

4.2.1.2 MPEG-4 System over RTP with Error Protection The design of this payload format has been proposed in [160]. It has been actually inspired by previous proposals for generic payload formats as presented in the previous subsection. Additionally, authors attempts to federate different error control approaches under a single protocol support mechanism. The rationale for this payload format consists in protection against packet loss with a protocol support easily adaptable to varying network conditions, for both "live" and "pre-recorded" visual contents. Despite of offering additional error control features, this approach requires to be aware of the characteristics of the network layer and the path MTU (Maximum Transfer Unit). 4.2.1.3 RTP Payload Format for MPEG-4 Audio/Visual Streams This approach is defined in [156]. It remains actually the only IETF RFC standard for transporting the MPEG-4 Audio/Visual streams over <strong>IP</strong> networks. This specification seems to be the most suitable and realist for coordination with the existing Internet QoS. It uses the MPEG-4 Simple profile Level 1 coding with only one video object in the scene (as in MPEG-2). Nevertheless, it does not use MPEG-4 systems at all. The RFC 3016 [156] provides specifications for the use of RTP header fields and fragmentation rules for MPEG-4 audio and video. MIME (Multipurpose Internet Mail Extension) type registration and SDP (Session Description Protocol) are used for the MPEG-4 session establishment. This is useful to configure the decoding parameters associated to a particular ES through the RTP session initialization. In this approach, MPEG-4 audio and video streams are not managed by MPEG-4 systems Object Descriptor but by H.245 session signaling protocol or other out of band means. The BIFS language is also not used to manage the scene that consequently reduces video content manipulation and interaction. The fragmentation rules described in this document are flexible. It defines the minimum rules for preventing meaningless fragmentation. LATM (Low-overhead MPEG-4 Audio Transport Multiplex) manages the sequences of audio data with relatively small overhead. In audio-only applications, it is desirable for LATM-based MPEG-4 Audio bit streams to be directly mapped onto the RTP packets without using MPEG-4 Systems. This help reducing the overhead caused by the Sync layer. 4.2.1.4 RTP Payload Format with Reduced SL Header This approach is represented by the MPEG-4 generic payload format described in [157] and its companion simplified draft [159]. Both of them are at status of Internet draft and seem to be an alternative for [156]. The approach presented in [159] implements a subset of the [157] features and addresses the AAC (<strong>Adaptive</strong> Audio Coding) and CELP (Coding Excited Linear Predictive audio) audio streams encapsulation over RTP. The approach recommends the use of few significant fields of the SL header with an eventual mapping to RTP header and RTP payload header. The RTP payload header (reduced SL Header) is fully configurable and can fit to different ESs types (video, audio, BIFS and ODs). In addition, this payload format can be configured to be compatible with [156]. With this payload format, only a single MPEG-4 elementary stream can be transported over a single RTP session. Information on the type of MPEG-4 stream carried in RTP payload is 76
conveyed by MIME format parameters through SDP message or others means. It is possible to carry multiple Access Units originating from the same ES in one RTP packet. 4.2.1.5 RTP Payload Format for MPEG-4 FlexMultiplexed Streams The approach [158] is a former Internet draft. It recommends encapsulating an integer number of FlexMux packets in the RTP payload. Inversely to other payload formats approaches, this one provides an elementary streams multiplexing over an RTP session and use the complete MPEG-4 terminal specification (i.e. the Sync Layer and FlexMux syntax). 4.2.1.6 Feature Comparison and Opens Issues MPEG-4 scene may involve a large number of objects, which are encapsulated in several distinct Elementary Streams (ESs). For instance, a basic audio-visual MPEG-4 scene needs at least 5 streams: a BIFS stream for scene description that specifies the number and location of individual media objects present in the scene, two additional streams for describing video and audio objects respectively (Object Descriptor), and finally, two other streams that encapsulate video and audio data. All these elementary streams, originated from the MPEG-4 codec, have to be transmitted to the destination player. Transporting each ES as an individual RTP session may be unpractical or inefficient. Allocating and controlling hundreds of destination addresses for each MPEG-4 session is a complex and demanding task for both source and destination terminals. The approaches described above are Internet draft and some of them are now obsolete since a number of open issues were identified with these proposals and which are summarized here: • Use of MPEG-4 systems vs. elementary streams. MPEG-4 has a complete system model, but some applications just desire to use the codecs. It is necessary to generate payload formats for both cases. MPEG-4 encompasses codecs which may have an existing RTP payload format, for example H.263 codec. This can lead to stop the use of MPEG-4 specific packetization. In addition, for error resilience, it is desirable to packetize in a media aware manner which does not imply a choice between systems or elementary streams. • Multiplexing multiple streams. The IETF has identified five multiplexing options that can be used for MPEG-4: GeRM (Generic RTP Multiplexing), FlexMux (Flexible Multiplexing), PPP Mux with Compressed RTP, don't multiplex, and don't multiplex, but compress headers. • Grouping within a stream. In order to amortize header overhead and to aid error resilience it is necessary to implement grouping. The open issue relating to grouping is how to group the MPEG-4 Access Unit? • Fragmentation. It is necessary to fragment a codec bit-stream in a media aware manner to achieve error resilience. We believe that the choice of fragmentation is a matter for the encoder, and that MPEG-4 should be able to fragment accordingly. • Error protection: There are two choices to apply an existing error protection mechanisms using packets-based protection such as parity FEC or to apply a specific FEC within the payload. 77
Page 1:
UNIVERSITÉ DE VERSAILLES SAINT-QUE
Page 4 and 5:
Résumé Nous constatons aujourd’
Page 6 and 7:
3 Related Work ....................
Page 8 and 9:
5.5.1.2 Simulation Results.........
Page 10 and 11:
List of Figures Figure 1-1: Structu
Page 12 and 13:
Figure 5-15: End-to-end packet tran
Page 14 and 15:
Acknowledgments The first person I
Page 16 and 17:
[11] Toufik Ahmed, Guillaume Burida
Page 18 and 19:
d’accès. Les interactions de QoS
Page 20 and 21:
Métrique MAX_DELAY PREF_MAX_DELAY
Page 22 and 23:
1.1.2 Proposition dun Protocole d'E
Page 24 and 25:
des paquets RTP. Reste toujours le
Page 26 and 27:
Nous pouvons distinguer trois possi
Page 28 and 29:
1.1.2.5.2 Multiplexage des Flux El
Page 30 and 31:
l’horloge est par défaut égale
Page 32 and 33:
La valeur R TCP représente le déb
Page 34 and 35:
Pour ces raisons, nous nous intére
Page 36 and 37:
Telles que illustrés par la Figure
Page 38 and 39:
3. DMIF2SIP vérifie si son propre
Page 40 and 41:
utilisée optionnellement pour loca
Page 42 and 43: Chapter 2 2 Introduction 2.1 Motiva
Page 44 and 45: conditions. Based on end-to-end fee
Page 46 and 47: Chapter 3 3 Related Work Nowadays,
Page 48 and 49: • multicasting: it takes the stre
Page 50 and 51: expensive, fixed delivery and recep
Page 52 and 53: 3.1.6 Static vs. Dynamic Channels T
Page 54 and 55: environment because they require a
Page 56 and 57: H.261 is called video codec for aud
Page 58 and 59: VideoScene (VS) VideoObject (VO) Vi
Page 60 and 61: The emphasis of MPEG-7 will be the
Page 62 and 63: Temporal scalability involves parti
Page 64 and 65: multitude of streams. It can switch
Page 66 and 67: increased linearly in the absence o
Page 68 and 69: 3.2.2.1 End-to-End Retransmission R
Page 70 and 71: correctly received block. The missi
Page 72 and 73: epresent user traffic. The delay ca
Page 74 and 75: 3.2.5 IP Signaling Protocols for Pa
Page 76 and 77: two H.323 endpoints or between an e
Page 79 and 80: Chapter 4 4 Adaptive Packet Video T
Page 81 and 82: 4.1.1 Video Classification Model Pr
Page 83 and 84: attributes can refer to the QoS par
Page 85 and 86: In RBF, 2 D = X − is the distance
Page 87 and 88: Figure 4-6: Experiment testbed In t
Page 89 and 90: 190 180 170 End-to-end delay MPEG-4
Page 91: Sync Layer. The SL-packetized strea
Page 95 and 96: the same value. This timing informa
Page 97 and 98: 4.2.2.1 Fragmentation We propose to
Page 99 and 100: Timestamp: Indicates the sampling i
Page 101 and 102: When G is used as generator matrix,
Page 103 and 104: 4.2.3 Performance Evaluation Intens
Page 105 and 106: 0.3 0.25 our proposal classical app
Page 107 and 108: lost packet at the receiver. Conseq
Page 109 and 110: marking scheme. The server must be
Page 111 and 112: The video server adds audio-visual
Page 113 and 114: Marker (TR3CM) [131] to mark the ba
Page 115 and 116: VO1 VO2 AVO Scenario Audio BL EL1 E
Page 117 and 118: Throughput (Kbits) 3000 2500 2000 1
Page 119 and 120: Throughput (Kbits) 3000 2500 2000 1
Page 121 and 122: 4000 3500 3000 2500 2000 1500 1000
Page 123 and 124: 45 40 Original Quality Received Qua
Page 125 and 126: Chapter 5 5 A Dynamic Packet Video
Page 127 and 128: The TCM algorithm is based on a tok
Page 129 and 130: BEGIN Initialize the classification
Page 131 and 132: User Profile (Token Bucket) Traffic
Page 133 and 134: 5.3.3 QoS Management Algorithm Spec
Page 135 and 136: Figure 5-7: Hierarchical aggregatio
Page 137 and 138: • Filters: to put packets into cl
Page 139 and 140: mechanism associated with the Drop
Page 141 and 142: Figure 5-16: Packets loss with IP D
Page 143 and 144:
5.5.2.3 Experimental Results Figure
Page 145 and 146:
1 MPEG-4 Based Layer Stream -AF11 M
Page 147 and 148:
0.2 0.18 MPEG-4 Based Layer Stream
Page 149 and 150:
By using our PBNM tool, we allocate
Page 151 and 152:
Id Condition Indicator Action 1 Net
Page 153 and 154:
The proposed marking algorithm bett
Page 155 and 156:
Chapter 6 6 A SIP/MPEG-4 Multimedia
Page 157 and 158:
performed by many ways like SLA (Se
Page 159 and 160:
6.1.1.4 SIP Communication Model SIP
Page 161 and 162:
• It assign a value (network sess
Page 163 and 164:
6.2.1 SIP2DMIF Subsystem The SIP2DM
Page 165 and 166:
Step 1: The MPEG-4 Terminal passes
Page 167 and 168:
1. Set the result C to the empty se
Page 169 and 170:
TCP/UDP port, our implementation us
Page 171 and 172:
Control & Data Plan Video Rate Cont
Page 173 and 174:
characteristics and relevance of ea
Page 175 and 176:
References [1] Kazaa Media Desktop
Page 177 and 178:
[43] B. Schuster, “Fine granular
Page 179 and 180:
[79] D. Bansal and H. Balakrishnan,
Page 181 and 182:
[115] N. Laoutaris, I. Stavrakakis,
Page 183 and 184:
[154] W. Almesberger, J. H. Salim,
Page 185 and 186:
Appendix A A Appendix A: Overview o
Page 187 and 188:
Media aware Delivery unaware ISO/IE
Page 189 and 190:
A.3.3 Scene Description Streams Sce
Page 191:
This appendix presents structure ex
show all

TITRE Adaptive Packet Video Streaming Over IP Networks - LaBRI

Create successful ePaper yourself

Delete template?

Save as template?