Dr. Panos Nasiopoulos EECE 541 - Courses
Dr. Panos Nasiopoulos EECE 541 - Courses
Dr. Panos Nasiopoulos EECE 541 - Courses
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
U N I V E R S I T Y O F B R I T I S H C O L U M B I A<br />
Efficient Transmission of H.264 Video<br />
over Wireless Networks<br />
<strong>Dr</strong>. <strong>Panos</strong> <strong>Nasiopoulos</strong><br />
<strong>EECE</strong> <strong>541</strong><br />
March 08 <strong>EECE</strong> <strong>541</strong> 1<br />
March 08<br />
Video Transmission over Wireless Networks<br />
Video Streams may incur significant packet loss, delay and<br />
delay jitter in Wireless Environments.<br />
2<br />
QoS-<br />
Internet<br />
<strong>EECE</strong> <strong>541</strong><br />
1
March 08<br />
Wireless LAN Access Network Problems<br />
What is different about wireless networks?<br />
Delay, Jitter, Packet Loss and Data Corruption are<br />
considerably higher in wireless networks than in wired<br />
networks<br />
transport service in wireless networks is not consistent or<br />
predictable<br />
WLAN problems may come from two sources<br />
PHY: fading, noise and interference may corrupt packets.<br />
MAC: collision in MAC layer may not be resolved on time, so<br />
packets are dropped. Mobility may cause excessive delay.<br />
Packet loss may occur in any layer<br />
PHY drops the packet if a bit error is detected, or MAC collision<br />
destroys the packet<br />
MAC drops the packet if too many retransmissions happen, and a<br />
fragment of the packet is lost.<br />
RTP/UDP or IP drop the packet if a fragment of the packet is lost<br />
Application drops the packet if it arrives too late<br />
March 08<br />
Why do we need new techniques?<br />
Enhancements may be achieved in<br />
several layers, either separately or in a<br />
cross layer fashion<br />
Application Layer ( H.264 Video )<br />
Error Resiliency Schemes<br />
Scalable Video Coding<br />
MAC Layer<br />
Scheduling to provide Differentiated and<br />
Guaranteed Services<br />
Packet size adjustments to reduce packet loss<br />
PHY Layer<br />
Link Adaptation<br />
3<br />
4<br />
App. Layer:<br />
H.264 Video<br />
<strong>EECE</strong> <strong>541</strong><br />
RTP/IP<br />
MAC:<br />
Scheduler<br />
PHY:<br />
Link<br />
Adaptation<br />
App. Layer:<br />
H.264 Video<br />
<strong>EECE</strong> <strong>541</strong><br />
RTP/IP<br />
MAC:<br />
Scheduler<br />
PHY:<br />
Link<br />
Adaptation<br />
2
March 08<br />
NALU – slice1<br />
H.264, Video Slice Coding<br />
When packet sizes exceed the maximum allowable amount for<br />
reliable transmission, we need to slice the frames into smaller data<br />
decodable unit –<br />
the alternative is to let the network fragment the packet.<br />
Slices<br />
Frame Data<br />
Self contained, all information for decoding slice available within slice.<br />
Each slice encapsulated in a NAL (Network Abstraction Layer) Unit.<br />
Size chosen to allow for optimal transport given underlying network MTU (max<br />
transfer unit) size constraints, as well as wireless network BER and<br />
acceptable PER.<br />
Advantages: losing a slice only affects part of a picture, not an entire<br />
frame<br />
Disadvantages: More overhead, less compression efficiency<br />
March 08<br />
NALU – slice2 NALU – slice3 NALU–slice4<br />
5<br />
<strong>EECE</strong> <strong>541</strong><br />
H.264 Error Resiliency - Flexible Macroblock<br />
Ordering (FMO)<br />
The H.264 provides various error resiliency schemes, including<br />
“Flexible Macroblock Ordering” (FMO)<br />
H.264 allows macroblocks within pictures to use a variety of slice<br />
mapping patterns.These include:<br />
Interleaving<br />
Dispersed<br />
Foreground<br />
Box-out<br />
Raster Scan<br />
Wipe<br />
Explicit<br />
user defined<br />
6<br />
<strong>EECE</strong> <strong>541</strong><br />
3
March 08<br />
FMO – different configurations<br />
Two typical scenarios of bad channel in Wireless LANs:<br />
BER of 5*10E-4 with MAC layer fragmentation threshold of 340B.<br />
BER of 10E-4 with MAC layer fragmentation threshold of 1000B.<br />
Retransmission limit: MAC layer may retransmit packet 5 times<br />
PSNR & Video Quality Metric (VQM) were averaged over the 120 frames, 10 runs<br />
of the simulation.<br />
Avg PSNR<br />
40<br />
35<br />
30<br />
25<br />
20<br />
15<br />
10<br />
5<br />
0<br />
March 08<br />
Avg PSNR Vs. BER/Packet Size<br />
BER 0.0005/ Frag<br />
Thresh 340<br />
BER/ Packet Size<br />
BER 0.0001/ Frag<br />
Thresh1000<br />
Interleave<br />
Dispersed<br />
Foreground w ith left over<br />
Box-out<br />
Raster scan<br />
Wipe<br />
Explicit<br />
Our Solutions?<br />
7<br />
Avg V QM<br />
9<br />
8<br />
7<br />
6<br />
5<br />
4<br />
3<br />
2<br />
1<br />
0<br />
Avg VQM Vs. BER/Packet Size<br />
BER 0.0005/ Frag<br />
Thresh 340<br />
BER/ Packet Size<br />
Cross Layer Optimization: Use Video information and<br />
optimize the operation of the MAC and PHY layers<br />
Simpler solutions<br />
Frame Size Adjustment: Find the (near) optimal frame size in<br />
MAC and PHY, slice the video accordingly.<br />
More complex cross layer optimized solutions<br />
Intelligent Link Adaptation<br />
BER 0.0001/ Frag<br />
Thresh1000<br />
Use Scalable Video Coding, adjust the configuration of the<br />
multirate PHY, and the traffic control (shaping) module in MAC<br />
and Network layers<br />
Multi-class Fair Scheduling<br />
Guaranteed service provisioning for more important parts of the<br />
video stream<br />
The objective of the algorithm is to provide long term fairness for<br />
all sessions, while providing reduced delay for video traffic.<br />
Specially useful for WiMAX.<br />
8<br />
Interleave<br />
Dispersed<br />
<strong>EECE</strong> <strong>541</strong><br />
Foreground w ith left over<br />
Box-out<br />
Raster scan<br />
Wipe<br />
Explicit<br />
App. Layer:<br />
Optimal size<br />
Video Slice<br />
Coding<br />
<strong>EECE</strong> <strong>541</strong><br />
RTP/IP<br />
MAC:<br />
Multi-Class<br />
Fair<br />
Scheduling<br />
PHY:<br />
Intelligent<br />
Link<br />
Adaptation<br />
4
March 08<br />
H.264 Error Resiliency: Data Partitioning<br />
The Compressed Frame is partitioned<br />
into :<br />
Partition A, contains the most important<br />
information such as MB types,<br />
quantization parameters, and motion<br />
vectors.<br />
Partition B (intra partition), contains intra<br />
coded block pattern and intra coefficients.<br />
Partition C (inter partition), contains only<br />
inter coded block pattern and inter<br />
coefficients.<br />
Partitions may be treated differently<br />
by the delivery layer<br />
Unequal Error Protection in PHY and MAC<br />
Prioritized or Guaranteed Services in MAC<br />
March 08<br />
9<br />
Frame/slice<br />
data<br />
RTP Packets<br />
Video Source<br />
VCL: Video Coding Layer<br />
IDR A B A B C<br />
NAL: Network Abstraction Layer<br />
IDR A B A B C<br />
<strong>EECE</strong> <strong>541</strong><br />
Enhancing H.264 Video<br />
Transmission over 802.11 WLANs<br />
Many enhancements are possible<br />
Enhancements in Application Layer –error resiliency<br />
Cross-layer Enhancements, packet size control (covered<br />
background)<br />
Cross-layer Enhancements, unequal error protection in MAC<br />
Partitioned video or scalable video – different layers – different<br />
priority<br />
10<br />
<strong>EECE</strong> <strong>541</strong><br />
5
March 08<br />
Enhancing H.264 Video Transmission<br />
over 802.11 WLANs<br />
First, we focus on cross layer enhancements for packet<br />
size control<br />
We determine Optimal size using knowledge of the delivery layer<br />
(MAC & PHY) to achieve lowest PER<br />
Video slicing is done in application layer, instead of<br />
fragmentation in MAC, to achieve optimal packet size.<br />
If Optimal size is larger than Slice Size, Aggregation is done in<br />
application layer (or transport layer) to achieve optimal packet<br />
size.<br />
March 08<br />
11<br />
<strong>EECE</strong> <strong>541</strong><br />
Effect of Packet (Slice) Size on Packet Loss Ratio<br />
and Video Quality, in 802.11 WLANs<br />
Large packets => high packet loss ratio in PHY due to high PER<br />
Small packets => high Packet loss in MAC due to congestion<br />
There MAY exist an optimum value for packet length<br />
Packet Loss Ratio<br />
0.6<br />
0.5<br />
0.4<br />
0.3<br />
0.2<br />
0.1<br />
0<br />
MAC and PHY (BER 10E-4)<br />
MAC only (BER = 10E-5)<br />
PHY only (BER 10E-4, Retx 5)<br />
250 500 750 1000 1250 1500 1750 2000<br />
Packet Size (Bytes)<br />
12<br />
<strong>EECE</strong> <strong>541</strong><br />
6
March 08<br />
802.11: Effect of Packet Size on Packet<br />
Loss Ratio<br />
Using large packets:<br />
Advantages<br />
reduce RTP/IP/UDP, and more importantly PHY overhead<br />
reduce collision (MAC operation overhead)<br />
Disadvantages<br />
March 08<br />
Higher PER in PHY layer: PER = 1 – (1-BER)pkt_len ~ BER * pkt_len<br />
Packet Loss Ratio<br />
0.6<br />
0.5<br />
0.4<br />
0.3<br />
0.2<br />
0.1<br />
0<br />
MAC and PHY (BER 10E-4)<br />
MAC only (BER = 10E-5)<br />
PHY only (BER 10E-4, Retx 5)<br />
250 500 750 1000 1250 1500 1750 2000<br />
Packet Size (Bytes)<br />
13<br />
<strong>EECE</strong> <strong>541</strong><br />
Packet Size Adjustment: MAC vs. App.<br />
Adjusting MAC packet size to optimal value can be done in<br />
MAC layer<br />
Application layer (Cross-Layer optimization)<br />
MAC<br />
Fragmentation<br />
Video Slicing<br />
MAC packet<br />
Video Slice<br />
Video Frame (NAL packet)<br />
MAC packet MAC packet MAC packet MAC packet<br />
Video Slice Video Slice Video Slice Video Slice<br />
MAC packet MAC packet MAC packet MAC packet MAC packet<br />
14<br />
<strong>EECE</strong> <strong>541</strong><br />
7
Packet Error Rate: fragments or slices of size K, picture of size L,<br />
n fragments, X transmission attempts, e bit error rate.<br />
Assuming an acceptable or optimal packet size, we prefer video<br />
slicing to MAC fragmentation<br />
March 08<br />
H.264<br />
Encoder<br />
March 08<br />
Video Slicing vs. MAC Fragmentation<br />
15<br />
Experiment Test-bed<br />
16<br />
<strong>EECE</strong> <strong>541</strong><br />
H.264<br />
Decoder<br />
H.264 file, RTP format H.264 file, RTP format<br />
Traffic<br />
Pattern<br />
Applicator<br />
RTP<br />
Packet<br />
Pattern<br />
802.11e<br />
Simulator<br />
<strong>Dr</strong>opped Late<br />
Receiver<br />
Buffer<br />
Simulator<br />
PSNR, Video, …<br />
Pattern for RTP packets<br />
delivered to decoder<br />
Offline<br />
Network<br />
Simulator<br />
<strong>EECE</strong> <strong>541</strong><br />
8
March 08<br />
Effect of Slice Size on PLR & Video PSNR<br />
Slice Size: 2300B 700B 300B<br />
PSNR<br />
40<br />
35<br />
30<br />
25<br />
20<br />
15<br />
10<br />
5<br />
0<br />
March 08<br />
40<br />
30<br />
20<br />
10<br />
0<br />
Average PSNR<br />
2300 700 300<br />
Fragment or Slice Size (Bytes)<br />
17<br />
<strong>EECE</strong> <strong>541</strong><br />
Video Slicing vs. MAC Fragmentation<br />
NoSlice 340B Frag<br />
Slice 300B<br />
1 10 19 28 37 46 55 64 73 82 91 100<br />
Frame #<br />
Application Layer frag. (Video Slicing) 18 MAC Fragmentation<br />
30<br />
25<br />
20<br />
15<br />
10<br />
5<br />
0<br />
Average PSNR<br />
MAC Fragmentation<br />
Video Slicing<br />
2300 700 300<br />
Slice or Fragment Size<br />
<strong>EECE</strong> <strong>541</strong><br />
9
35<br />
30<br />
25<br />
20<br />
15<br />
10<br />
5<br />
0<br />
March 08<br />
Video Slicing at the Optimal Size (700B)<br />
Average PSNR<br />
MAC Fragments<br />
Video Slices<br />
2300 700 300<br />
Fragment or Slice Size (Bytes)<br />
19<br />
PSNR<br />
40<br />
35<br />
30<br />
25<br />
20<br />
15<br />
10<br />
5<br />
2300B Slice<br />
2300B Fragments<br />
700BSlice (2304 frag)<br />
740Fragment<br />
300B Slice<br />
300B Fragments<br />
0<br />
1 11 21 31 41 51 61 71 81 91 101 111<br />
frame #<br />
<strong>EECE</strong> <strong>541</strong><br />
Transmission of Partitioned H.264 Video<br />
over WLANs<br />
March 08<br />
20<br />
<strong>EECE</strong> <strong>541</strong><br />
10
March 08<br />
MAC QoS Solutions<br />
Video Communications requires QoS provisioning.<br />
QoS in 802.11 WLAN<br />
802.11e Standard defines two access methods<br />
EDCA (Enhanced Distributed Channel Access)<br />
Prioritized contention access: higher success probability<br />
for video, voice, …<br />
Aggregate QoS<br />
HCCA (HCF Controlled Channel Access)<br />
Scheduled access – requires a user defined scheduler<br />
Per-session QoS<br />
EDCA Based<br />
March 08<br />
21<br />
QoS Support using 802.11e<br />
22<br />
<strong>EECE</strong> <strong>541</strong><br />
only provides aggregate and prioritized QoS, poor delay and jitter<br />
performance<br />
does not perform well at heavy loads, very sensitive to MAC<br />
parameters<br />
HCCA Based<br />
Scheduled access to the medium is possible through HCCA, thus<br />
service guarantee is feasible<br />
The scheduling scheme is user-defined in HCCA<br />
Challenges of Scheduling in 802.11e<br />
CSMA/CA: channel shared between Uplink/downlink at all times<br />
Mixed contention based & contention free (controlled) access<br />
Multi-rate PHY: Each packet may be sent at a different PHY rate<br />
Our Solution: Controlled Access Phase Scheduling, CAPS<br />
<strong>EECE</strong> <strong>541</strong><br />
11
Video Source (downstream)<br />
VCL: Video Coding Layer<br />
IDR A B A B C<br />
NAL: Network Abstraction Layer<br />
IDR A B A B C<br />
Other traffic<br />
EDCA<br />
queues<br />
Select access mode (HCCA or EDCA)<br />
EDCA<br />
Contention<br />
Access<br />
March 08<br />
March 08<br />
HCCA<br />
Queues<br />
HCCA<br />
Access<br />
Application Layer<br />
Transport and Network<br />
Layers: RTP/UDP/IP<br />
MAC layer: 802.11e<br />
(CAPS enabled)<br />
CAP (Poll Message)<br />
Indication<br />
Station<br />
Traffic Pattern Information<br />
Physical Layer<br />
Access Point<br />
UPSTREAM<br />
Requests from<br />
stations<br />
Virtual<br />
Packets<br />
HCCA<br />
Queues<br />
23<br />
24<br />
Virtual Packet<br />
Generator (VPG)<br />
Time Stamping<br />
scheduler<br />
Video Source (upstream)<br />
VCL: Video Coding Layer<br />
IDR A B A B C<br />
NAL: Network Abstraction Layer<br />
IDR A B A B C<br />
Actual<br />
Packets<br />
classifier<br />
Select access mode (HCCA or EDCA)<br />
MAC QoS Based Solutions<br />
EDCA<br />
Contention<br />
Access<br />
<strong>EECE</strong> <strong>541</strong><br />
<strong>EECE</strong> <strong>541</strong><br />
Application Layer<br />
Transport and Network<br />
Layers<br />
MAC layer (CAPS)<br />
Other traffic<br />
EDCA<br />
queues<br />
Techniques for Transmission of Partitioned H.264 Video over WLANs<br />
TECHNIQUE<br />
1. Single Stream<br />
served by EDCA<br />
2. Single Stream<br />
served by CAPS<br />
3. Partitioned<br />
Video served by<br />
EDCA<br />
4. Partitioned<br />
Video served by<br />
CAPS<br />
5. Partitioned<br />
Video, Partially<br />
Aggregated,<br />
served by CAPS<br />
Supported<br />
H.264<br />
Profiles<br />
baseline,<br />
extended<br />
(all profiles)<br />
baseline,<br />
extended<br />
(all profiles)<br />
extended<br />
extended<br />
extended<br />
Supporte<br />
d 802.11e<br />
WLAN<br />
EDCA<br />
EDCA &<br />
HCCA<br />
with CAPS<br />
EDCA<br />
EDCA &<br />
HCCA<br />
with CAPS<br />
EDCA &<br />
HCCA<br />
with CAPS<br />
Network-Awareness In<br />
The Multimedia Source<br />
Limited: Tagging all<br />
frames with type of<br />
service<br />
Limited: Tagging all<br />
frames with traffic stream<br />
ID<br />
Tagging different<br />
partitions for different<br />
priority levels.<br />
Tagging different<br />
partitions for different<br />
traffic streams.<br />
Tagging different<br />
partitions for different<br />
traffic streams,<br />
aggregating partitions B<br />
and C (or A & B).<br />
Media-Awareness In The WLAN<br />
Serving tagged video in priority<br />
levels (AC2)<br />
Requires video pattern information,<br />
serving tagged video in guaranteed<br />
access traffic session<br />
Serving packet of each partition in<br />
a different priority level (A: AC2, B<br />
& C: AC1)<br />
Requires video pattern information,<br />
serving partition A packets in a<br />
separate guaranteed access traffic<br />
session from partitions B & C<br />
Requires video pattern information,<br />
serving partition A packets in a<br />
separate guaranteed access traffic<br />
session from the aggregated<br />
packets of partitions B & C<br />
12
March 08<br />
March 08<br />
Loss Ratio<br />
Loss Ratio<br />
1<br />
0.8<br />
0.6<br />
0.4<br />
0.2<br />
0<br />
Delivering H.264 Partitions using<br />
EDCA and CAPS<br />
12 14 16 18 20 22 24 26 28<br />
Number of Background Traffic Sources (500 Kbps each)<br />
Delivery of Partitioned Video using CAPS and EDCA<br />
1<br />
0.8<br />
0.6<br />
0.4<br />
0.2<br />
0<br />
Partition A CAPS<br />
Partition B & C - CAPS<br />
Partition A - EDCA<br />
Partition B & C - EDCA<br />
25<br />
26<br />
<strong>EECE</strong> <strong>541</strong><br />
Effect of Aggregation on<br />
Performance pf EDCA and CAPS<br />
CAPS single stream<br />
EDCA single stream<br />
CAPS Partitioning & Aggreg<br />
CAPS Partitioning-No Aggreg<br />
2 4 6 8 10 12 14 16<br />
Number of Video Sources<br />
Total loss ratio for EDCA, CAPS, and partitioned video with CAPS (aggreg. and no aggreg.)<br />
<strong>EECE</strong> <strong>541</strong><br />
13
March 08<br />
Loss Ratio<br />
1<br />
0.9<br />
0.8<br />
0.7<br />
0.6<br />
0.5<br />
0.4<br />
0.3<br />
0.2<br />
0.1<br />
0<br />
Delivering H.264 Partitions using<br />
EDCA and CAPS<br />
Prt B & C EDCA<br />
Prt A EDCA<br />
Prt B&C CAPS-Aggreg<br />
Prt A CAPS-Aggreg<br />
CAPS single stream<br />
EDCA single stream<br />
2 4 6 8 10 12 14 16<br />
Num of Video Sources<br />
Results of experiment to determine WLAN capacity to support video sources<br />
EDCA may be used :<br />
March 08<br />
27<br />
EDCA<br />
<strong>EECE</strong> <strong>541</strong><br />
Conclusion<br />
(Data-Partitioned Video over WLAN)<br />
for delay and jitter tolerant video applications (streaming)<br />
when capacity is not a concern<br />
CAPS based guaranteed service provisioning can provide<br />
the required QoS for real time video<br />
When Data Partitioning (DP) is available<br />
CAPS with DP provides better quality than EDCA with DP<br />
Aggregation of partitions B & C or A & B is necessary in<br />
WLANs<br />
28<br />
<strong>EECE</strong> <strong>541</strong><br />
14
March 08<br />
APPENDIX<br />
Acronyms<br />
NAL – Network Adaptation Layer<br />
LAN – Local Area Network<br />
VCL – Video Coding Layer<br />
VLC – Variable Length Coding<br />
AIFS[TC]<br />
+SlotTime<br />
March 08<br />
29<br />
<strong>EECE</strong> <strong>541</strong><br />
802.11e DCF/EDCA Operation<br />
Prioritized Access provided through traffic specific<br />
parameters:<br />
1. Initial Deferment, AIFS<br />
2. Backoff window size<br />
3. Allowed Burst size (TXOP)<br />
Immediate access when<br />
medium is idle >=<br />
AIFS[TC]+SlotTime<br />
Busy medium<br />
AIFS[TC]<br />
DIFS<br />
PIFS<br />
SIFS<br />
Contention Window<br />
from [1,1+CWmin[TC]]<br />
SlotTime<br />
30<br />
Backoff<br />
Window<br />
Defer Access Select Slot and decrement backoff<br />
as long as medium stays idle<br />
Next Frame<br />
<strong>EECE</strong> <strong>541</strong><br />
15
QAP<br />
(downstream)<br />
…<br />
QSTAs<br />
(upstream)<br />
EDCA<br />
March 08<br />
March 08<br />
802.11e HCCA Operation<br />
Access Point can use PIFS waiting time and generate<br />
a contention free duration (CAP) at almost any time<br />
PIFS<br />
Poll<br />
SIFS<br />
Data<br />
SIFS<br />
Polled TXOP<br />
Ack<br />
31<br />
…<br />
EDCA TXOP<br />
PIFS<br />
Data<br />
Controlled Access Phase (CAP)<br />
Existing Solutions<br />
SIFS<br />
Ack<br />
TXOP obtained by QAP<br />
…<br />
EDCA<br />
<strong>EECE</strong> <strong>541</strong><br />
Perceptual ARQ in Application Layer (prioritized) [Buc04]<br />
Claims to achieve better performance compared to blind MAC<br />
ARQ in 3GPP<br />
Does not consider MAC collision and congestion problems<br />
Partitioning and assigning a separate priority to each<br />
partition [Cas05] [Ksen06]<br />
Better Performance compared to only using one high priority for<br />
all partitions<br />
Only applicable to extended profile<br />
Does not consider MAC collision and congestion problems<br />
Ignores the effect of PHY errors<br />
32<br />
<strong>EECE</strong> <strong>541</strong><br />
16
March 08<br />
FMO – WLAN Scenarios<br />
We conducted several experiments to determine which pattern<br />
can provide the best quality of video for a given packet loss<br />
<br />
scenario, typical for WLAN environments.<br />
Two typical scenarios of bad channel cases in Wireless LANs<br />
were considered:<br />
The first scenario: a WLAN with BER of 5*10-4 was considered<br />
with MAC layer fragmentation threshold set at 340Bytes.<br />
The second scenario: a WLAN with BER of 10-4 was<br />
considered with MAC layer fragmentation threshold of<br />
1000Bytes.<br />
March 08<br />
The retransmission limit was set to 5 for lost packets.<br />
33<br />
Assumption<br />
34<br />
<strong>EECE</strong> <strong>541</strong><br />
A higher I-frame frequency increases the video quality<br />
(PSNR)<br />
fI-frames = 1/10 * fframe I-frame<br />
f I-frames = 1/5 * f frame<br />
P-frames<br />
Less time between decoder refreshes (good)<br />
Higher likelihood of I-frame errors (bad)<br />
<strong>EECE</strong> <strong>541</strong><br />
17
March 08<br />
Bit Errors and Frame Size<br />
I-frame packet size ≠ P-frame packet size<br />
f I-frames = 1/5 * f frame<br />
f I-frames = 1/10 * f frame<br />
March 08<br />
I I<br />
I<br />
9 frames affected<br />
18 frames affected<br />
35<br />
Refreshing with I-Frames<br />
36<br />
I<br />
<strong>EECE</strong> <strong>541</strong><br />
• Higher I frame frequency usually increases video quality in lossy environments<br />
• However,<br />
- I frames are larger in size -> more error prone since PER ~ length<br />
- Increase in stream bitrate may result in higher packet loss due to congestion.<br />
Assuming availability<br />
of enough BW, we<br />
observe the quality in<br />
different situations<br />
PSNR<br />
32<br />
30<br />
28<br />
26<br />
24<br />
22<br />
PSNR vs I-Frame Interval<br />
20<br />
0 20 40 60 80 100<br />
I-frame Interval<br />
Retry 5; 1E-4 & Frag1000 Retry 5; 5E-4 & Frag1000 Retry 1; 1E-5 & Frag 340<br />
Retry 1; 1E-5 & Frag 1000 Retry 5; 5E-4 & Frag340<br />
<strong>EECE</strong> <strong>541</strong><br />
18
Conversational<br />
Streaming<br />
March 08<br />
RTCP<br />
March 08<br />
Application Requirements, 3GPP Example<br />
37<br />
Real Time Control Protocol<br />
Responsible for management of real time session<br />
RTCP receiver reports indicate quality of link<br />
Reports can be used to increase error resiliency of:<br />
DPA NAL packets<br />
Duplicate packet transmissions of critical info<br />
MB Coefficients<br />
Redundant representations of the same MBs<br />
MBs coded using different coding parameters<br />
Fine quantization packet<br />
Coarse quantization packet<br />
Increased error coding (FEC)<br />
38<br />
<strong>EECE</strong> <strong>541</strong><br />
<strong>EECE</strong> <strong>541</strong><br />
19
March 08<br />
UDP<br />
March 08<br />
39<br />
User Datagram Protocol<br />
Transmission Control Protocol (TCP)<br />
Connection-oriented service<br />
Reliable data transfer<br />
40<br />
<strong>EECE</strong> <strong>541</strong><br />
Uses Sequence Numbers, Acknowledgements, retransmissions<br />
Creates delays<br />
Not well suited to video streaming<br />
Responds to channel conditions through flow control<br />
UDP provides connection-less service<br />
No reliability, sequence numbers, acknowledgements, retransmissions,<br />
or flow control<br />
Corrupted packet are dropped<br />
Sequence numbering provided by upper layer (RTP)<br />
Has 16 bit length field – MTU size 65,535 bytes (IPv6 jumbograms<br />
supported)<br />
<strong>EECE</strong> <strong>541</strong><br />
20
IP<br />
Routing protocol<br />
March 08<br />
Internet Protocol & Media Access Control<br />
Not germane to our WLAN environment<br />
MAC<br />
IEEE 802.11b, a, e?<br />
Need to identify which implementation we are using and the maximum<br />
size of a frame in this implementation since this size will determine the<br />
data partitioning, number of packets required per frame (we assume we<br />
are using progressive video since it will be displayed on a computer<br />
screen) and error protection mechanisms.<br />
March 08<br />
41<br />
H.264 profiles<br />
<strong>EECE</strong> <strong>541</strong><br />
Baseline Profile (BP): Primarily for lower-cost applications demanding less computing resources,<br />
used widely in videoconferencing and mobile applications.<br />
Main Profile (MP): Originally intended as the mainstream consumer profile for broadcast and<br />
storage applications, the importance of this profile faded when the High profile was developed for<br />
those applications.<br />
Extended Profile (XP): Intended as the streaming video profile, this profile has relatively high<br />
compression capability and some extra tricks for robustness to data losses and server stream<br />
switching.<br />
High Profile (HiP): The primary profile for broadcast and disc storage applications, particularly for<br />
high-definition television applications (this is the profile adopted into HD DVD and Blu-ray Disc,<br />
for example).<br />
High 10 Profile (Hi10P): Going beyond today's mainstream consumer product capabilities, this<br />
profile builds on top of the High Profile — adding support for up to 10 bits per sample of decoded<br />
picture precision.<br />
High 4:2:2 Profile (Hi422P): Primarily targeting professional applications that use interlaced video,<br />
this profile builds on top of the High 10 Profile — adding support for the 4:2:2 chroma sampling<br />
format while using up to 10 bits per sample of decoded picture precision.<br />
High 4:4:4 Profile (Hi444P): This profile builds on top of the High 4:2:2 Profile — supporting up<br />
to 4:4:4 chroma sampling, up to 12 bits per sample, and additionally supporting efficient lossless<br />
region coding and an integer residual color transform for coding RGB video while avoiding colorspace<br />
transformation error.<br />
42<br />
<strong>EECE</strong> <strong>541</strong><br />
21