Download Scalable Video Distribution in Peer-to

Distribuição de Vı́deo Multi-Ritmo em Arquitectura
Peer-to-Peer
Scalable Video Distribution in Peer-to-Peer Architecture
Roberto José Pontes Nunes
Dissertação para obtenção do Grau de Mestre em
Engenharia Electrotécnica e de Computadores
Presidente:
Orientador:
Co-Orientador:
Vogais:
Prof.
Prof.
Prof.
Prof.
Júri
Doutor Nuno Cavaco Gomes Horta
Doutor Mário Serafim dos Santos Nunes
Rui António dos Santos Cruz
Doutor Artur Miguel do Amaral Arsénio
Outubro de 2010
Acknowledgments
It is a pleasure to thank the many people who made this thesis possible.
It is difficult to overstate my gratitude to my MSc supervisors, Professor Mário Nunes and Professor
Rui Cruz. Without their enthusiasm, inspiration, good teaching, company and lots of good ideas, I would
have been lost.
I would like to express the deepest appreciation to Professor Jânio Monteiro for all it’s support and
expertise in the Scalable Video area.
I would like to thank INOV for supporting me with a scholarship during the last year, specially for
letting me participate in various projects, which provided me with a rich academic and professional
experience.
To all my friends and colleagues that helped me pass these though years, grow as a person and
were always there for me. You know who you are, thank you.
Lastly, and most importantly, I wish to thank my parents. Their motivation, patience and caring is
priceless.
”Flatter me, and I may believe you. Criticize me, and I may not like you.
Ignore me, and I may not forgive you. Encourage me, and I may not forget you.”
William Arthur
Abstract
The combination of Scalable Video and Peer-to-Peer overlay networks is a potential area of future
innovation in terms of video streaming on the Internet. File Sharing applications, such as BitTorrent,
have been broadly developed and nowadays they constitute the majority of Internet traffic, adding the
need for the exploration of real-time streaming services based on these overlay networks.
Several Peer-to-Peer streaming services have been deployed, but very few explore:
• Bandwidth adaptation for appropriate usage in heterogeneous networks
• The operation in diverse terminal types and computational setups
• Incentives for contributing available network resources at peers
• Maintenance of a stable Quality of Experience for the end user
This thesis presents the design, implementation and evaluation of a Scalable Video and Peer-toPeer Player prototype that fulfills all these related issues in terms of maintaining a stable Quality of
Service/Quality of Experience (QoS/QoE), using a novel algorithm for its adaptive system: Prioritized
Sliding Window.
The evaluation results show that the Peer-to-Peer Player prototype manages to achieve a robust realtime streaming service (due to the layered structure of the video), provides support to several terminal
setups, adapts to available bandwidth in various access networks, and discourages free-riders present
in the network.
Keywords
BitTorrent, Scalable Video, Peer-to-Peer, Adaptive Streaming, QoS
iii
Resumo
A combinação de vı́deo escalável e redes Peer-to-Peer é uma área de potencial inovação no futuro em termos do streaming de vı́deo na internet. As aplicações de partilha de ficheiros, tal como o
BitTorrent, que têm sido amplamente desenvolvidas e actualmente constituem a maioria do tráfego na
Internet, têm vindo recentemente a acrescentar a necessidade de exploração de serviços de streaming
em tempo real com base nestas arquitecturas de redes. Vários serviços de streaming em Peer-to-Peer
foram implementados, mas são poucos os que exploraram aspectos, tais como:
• Adaptação da largura de banda para o uso adequado em redes heterogéneas
• A operação em terminais com configurações diversas e capacidade de processamento variável
• Incentivos para contribuir com os seus recursos disponı́veis na rede
• Manutenção de uma Qualidade de Experiência estável para o utilizador final
Esta tese apresenta o projecto, a implementação e a avaliação do protótipo de um Media Player de
vı́deo escalável em redes Peer-to-Peer que responde a todas estas questões, em termos de manutenção
de uma Qualidade de Serviço/Qualidade de Experiência (QoS/QoE) estável, utilizando um novo algoritmo para o seu sistema adaptativo: Prioritized Sliding Window. Os resultados da avaliação mostram
que o protótipo apresenta um sistema robusto para o serviço de streaming em tempo real, para além
de que suporta várias configurações de terminal, adapta a largura de banda disponı́vel para diferentes
redes de acesso, e desencoraja os nós que não contribuem com os seus recursos na rede.
Palavras Chave
BitTorrent, Video Multi-Ritmo, Peer-to-Peer, Streaming Adaptativo, QoS
v
Contents
1 Introduction
1
1.1 Motivation and Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.2 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.3 Thesis research topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.4 Dissertation layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2 State of the Art
7
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.2 Scalable Video . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.2.1 Spatial Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.2.2 Temporal Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.2.3 Quality Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.2.4 Combination of the Scalability Dimensions . . . . . . . . . . . . . . . . . . . . . . .
12
2.2.5 Benefits of Scalable Video . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.3 Peer-to-Peer Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.3.1 BitTorrent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.3.2 Piece Picking Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.4 Peer-to-Peer Video Streaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
2.4.1 Tribler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
2.5 Scalable Video and Peer-to-Peer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
2.5.1 NextShare
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
2.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
3 Architecture
21
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
3.2 Functional and Non-Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . .
22
3.3 Architecture Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
3.3.1 Scalable Video Coding (SVC) File Structure Design . . . . . . . . . . . . . . . . .
24
3.3.2 Adaptation System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
vii
3.3.3 Peer Selection Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
3.3.4 Upload Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
3.4 System Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
3.4.1 Graphical User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
3.4.1.A Video Renderer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
3.4.1.B Video Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
3.4.1.C P2P Info/Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
3.4.2 Media Player . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
3.4.2.A SVC Decoder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
3.4.2.B Feed Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
3.4.3 Chunk Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
3.4.3.A Download Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
3.4.3.B Buffer Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
3.4.3.C SVC Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
3.4.3.D SVC Chunk Partitioner . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
3.4.3.E SVC Intra-Chunk Layer Partitioner . . . . . . . . . . . . . . . . . . . . . .
34
3.4.3.F SVC Layer Assembler . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
3.4.3.G Time Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
3.4.3.H CPU Load Adaptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
3.4.3.I
Screen Size Adaptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
3.5 BitTorrent engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
3.5.1 BiTorrent Engine Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
3.5.2 Architecture Design Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
3.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
4 Implementation
41
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
4.2 Development Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
4.3 Development Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
4.4 Graphical User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
4.4.1 Desktop Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
4.5 Media Player Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
4.5.1 Scalable Video Decoder Module . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
4.5.2 Feed Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
4.6 Chunk Manager Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
4.6.1 Download Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
viii
4.6.2 Buffer Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
4.6.3 SVC File Assembler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
4.6.4 Time Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
4.6.5 CPU Load Adaptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
4.6.6 Screen Size Adaptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
4.7 The BitTorrent engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
4.7.1 Client Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
4.7.2 Torrent Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
4.7.3 Piece Picking Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
4.7.3.A Standard Picker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
4.7.3.B Randomized Picker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
4.7.3.C Rarest First Picker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
4.7.3.D Custom Piece Picker . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
4.7.3.E Prioritized Sliding Window (PSW) Piece Picker Algorithm . . . . . . . . .
57
4.7.3.F Local Peer Piece Picker Algorithm . . . . . . . . . . . . . . . . . . . . . .
59
4.7.4 Choke-Unchoke Manager and Incentives Strategy . . . . . . . . . . . . . . . . . .
59
4.7.5 Tit-for-Tat Incentives Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
4.8 Live Streaming Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
4.9 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
5 Evaluation Tests
65
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
5.2 Evaluation Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
5.3 Experimental Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
5.4 Evaluation Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
5.4.1 Heterogeneous Network Behaviour . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
5.4.2 Live Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
5.4.3 Terminal Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
5.4.4 Scalability, Incentives and Performance . . . . . . . . . . . . . . . . . . . . . . . .
75
5.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
6 Conclusion and Future Work
83
6.1 System limitations and future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
84
6.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
A Description of Appendix A
93
A.1 Tracker Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
94
A.2 Peer Wire Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
96
ix
B Description of Appendix B
99
B.1 SVC Video Manifest Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
x
List of Figures
1.1 Increasing usage of P2P systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.2 File-types on Major P2P Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.1 Example of a combined temporal and spatial scalable coding considering two different
frame rates at lower and higher layers [1] . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.2 A temporal layer encoding structure using a hierarchical prediction structure for groups of
16 pictures [1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.3 Motion-estimation in Quality Scalability comparing Fine Grained Scalability (left side) versus Medium Grained Scalability (right side) [1] . . . . . . . . . . . . . . . . . . . . . . . .
12
2.4 Combined Scalability Dimensions [2] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.5 Centralized server-based service model and Peer-to-Peer (P2P) system of nodes without
central infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.6 The Graphical User Interface (GUI) of the SwarmPlayer . . . . . . . . . . . . . . . . . . .
18
3.1 File Data Process and Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
3.2 Structure of a binary H.264 SVC file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
3.3 NALs initial four byte code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
3.4 Additional bytes in NAL unit header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
3.5 NALs structure in a chunk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
3.6 Standard BitTorrent Piece Download Strategy . . . . . . . . . . . . . . . . . . . . . . . . .
26
3.7 Priority Sliding Window Piece Download Strategy . . . . . . . . . . . . . . . . . . . . . . .
29
3.8 Stack-based modular representation of P2P SVC Player . . . . . . . . . . . . . . . . . . .
29
3.9 System Design Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
3.10 Sequence number representation in a NAL unit . . . . . . . . . . . . . . . . . . . . . . . .
34
3.11 Modular architecture of The BitTorrent engine.
. . . . . . . . . . . . . . . . . . . . . . . .
38
3.12 Stack representation of the standard Piece picking algorithms . . . . . . . . . . . . . . . .
39
4.1 Development Stage Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
xi
4.2 Desktop Application Graphical User Interface . . . . . . . . . . . . . . . . . . . . . . . . .
44
4.3 Feed Manager State diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
4.4 Download Manager State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
4.5 Tasking Process Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
4.6 Specification and Description Language (SDL) diagram of the Standard Piece Picker algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
4.7 SDL diagram of the Randomized Piece Picker algorithm . . . . . . . . . . . . . . . . . . .
55
4.8 SDL diagram of the Rarest First Piece Picker algorithm . . . . . . . . . . . . . . . . . . .
56
4.9 Stack representation of the custom Piece Picking set of algorithms . . . . . . . . . . . . .
57
4.10 Adaptive PSW Priority Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
4.11 SDL diagram of the Local Peer Piece Picker algorithm . . . . . . . . . . . . . . . . . . . .
60
4.12 Layer file structure for Live Streaming mode . . . . . . . . . . . . . . . . . . . . . . . . . .
62
5.1 Local Test scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
5.2 Playback Rate on LAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
5.3 Playback Rate on WLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
5.4 Playback Rate on 3G . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
5.5 Distribution of the Download Rate in a LAN . . . . . . . . . . . . . . . . . . . . . . . . . .
70
5.6 Distribution of the Download Rate in a WLAN . . . . . . . . . . . . . . . . . . . . . . . . .
71
5.7 Distribution of the Download Rate on 3G . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
5.8 Received Chunk-Layer Ratio on LAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
5.9 Received Chunk-Layer Ratio on WLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
5.10 Received Chunk-Layer Ratio on 3G . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
5.11 Distribution of the Live Playback Delay from Real-Time Capture . . . . . . . . . . . . . . .
74
5.12 Chunk Layer Ratio on LAN with Screen Resize . . . . . . . . . . . . . . . . . . . . . . . .
74
5.13 Chunk Layer Ratio on LAN with CPU Load . . . . . . . . . . . . . . . . . . . . . . . . . .
75
5.14 Average Playback Rate with no free riders . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
5.15 Average Chunk Layer Ratio with no free riders . . . . . . . . . . . . . . . . . . . . . . . .
77
5.16 Distribution of the Average Download Rate with no free riders . . . . . . . . . . . . . . . .
78
5.17 Distribution of the Average Upload Rate with no free riders
. . . . . . . . . . . . . . . . .
78
5.18 Average Playback Rate with free riders . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
5.19 Average Chunk Layer Ratio with free riders . . . . . . . . . . . . . . . . . . . . . . . . . .
79
5.20 Distribution of the Average Download Rate with free riders . . . . . . . . . . . . . . . . . .
80
5.21 Distribution of the Average Upload Rate with free riders . . . . . . . . . . . . . . . . . . .
80
xii
List of Tables
3.1 Chunk partitioned structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
3.2 Network Abstraction Layer (NAL) units and their transmission Layer structure . . . . . . .
28
3.3 Layer order and filename structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
4.1 Video resolutions for SVC content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
4.2 Priority layer definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
5.1 Terminal timestamp distribution startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
xiii
xiv
List of Algorithms
4.1 Scalable Video Coding File Assembler . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
4.2 Tit-for-Tat Upload Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
xv
xvi
List of Acronyms
3G
3rd Generation
ADSL Asymmetric Digital Subscriber Line
API
Application Programming Interface
AU
Access Unit
AVC
Advanced Video Coding
CDF
Cumulative Distribution Function
CGI
Common Gateway Interface
CGS
Coarse-Grain Quality Scalable
CIF
Common Intermediate Format
CPU
Central Processing Unit
DCIF
Double Common Intermediate Format
DNS
Domain Name System
DHT
Distributed Hash Table
FGS
Fine-Grain Scalability
FIFO
First In, First-Out
FWA
Fixed Wireless Access
GOP
Group of Pictures
GUI
Graphical User Interface
HD
High Definition
xvii
HTTP Hypertext Transfer Protocol
HTTPS HyperText Transfer Protocol Secure
IETR
Institut d’Electronique et des Telecommunications de Rennes
IIS
Internet Information Services
INSA Institut National des Sciences Appliquees de Rennes
IP
Internet Protocol
ISP
Internet Service Provider
JVT
Joint Video Team of ISO/IEC MPEG and ITU-T VCEG
LAN
Local Area Network
MDC
Multi Description Coding
MGS
Medium-Grain Quality Scalable
NAL
Network Abstraction Layer
NAT
Network Address Translation
P2P
Peer-to-Peer
P2PTV Peer-to-Peer Television
PMP
Port Mapping Protocol
PSNR Peak Signal-to-Noise Ratio
PSW
Prioritized Sliding Window
QCIF Quarter Common Intermediate Format
QoE
Quality Of Experience
QoS
Quality Of Service
RAM
Random-Access Memory
SD
Standard Definition
SDL
Specification and Description Language
SEI
Supplemental Enhancement Information
xviii
SHA-1 Secure Hash Algorithm 1
SPPM Stanford Peer-to-Peer Multicast
SNR
Signal-to-Noise Ratio
SVC
Scalable Video Coding
TCP
Transmission Control Protocol
TFT
Tit-for-Tat Protocol
UDP
User Datagram Protocol
UMTS Universal Mobile Telecommunications System
URL
Uniform Resource Locator
VoD
Video On Demand
WAN
Wide Area Network
WLAN Wireless Local Area Network
WWAN Wireless Wide Area Network
WWW World Wide Web
XML
Extensible Markup Language
xix
xx
1
Introduction
Contents
1.1 Motivation and Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.2 Contributions
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.3 Thesis research topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.4 Dissertation layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
1
1.1
Motivation and Objectives
P2P overlay networks (e.g., BitTorrent [3], Gnutella [4], eMule [5]) have evolved over the past few
years to a point that the access to multimedia data, including video, occupies nowadays a considerable
share of the Internet traffic volume. The evolution of broadband access networks, with high speed
download and upload rates contributed also to the fast growth of these overlay networks.
Initially, P2P overlay networks were researched only in scientific and academic environments, but
afterwards they found their way to a wide range of mainstream applications. Today’s P2P applications
benefit from the fact that many users offer their resources (mostly in form of files) through them, due
essentially to their increasing popularity and wide development in the early years [6] (Figure 1.1).
Figure 1.1: Increasing usage of P2P systems
Currently, most of the P2P traffic in the Internet is used to distribute video files [6] (Figure 1.2). In this
mode, a user has to download the video file before being able to watch it, suffering from a long start-up
time. But users are often interested in streaming the video for online viewing rather than for delayed
playback, and this requires average streaming rates between 300 Kbps and 1 Mbps.
A crucial feature of P2P networks that distinguishes them from other architectures, such as the ClientServer model, lies in their decentralized approach. Not a single server is responsible for distributing the
content, but every interconnected peer acts as client and server at the same time, thus reducing the load
on source servers (i.e., servers from where the original content is at first provided).
Managing and assuring a certain service quality for all consumers within a P2P network becomes
a more challenging task than with other architectures, as the requirements and the conditions differ
extensively among peers in regard to both their system resources (i.e., processing power or screen
2
Figure 1.2: File-types on Major P2P Networks
size) and the available network bandwidth (i.e., uplink or downlink bitrates). The constraints associated
with the available network bandwidth are mainly connected to the relatively low uplink bandwidth of the
access networks (due to the asymmetric characteristics of Asymmetric Digital Subscriber Line (ADSL) or
cable networks), making it hard to stream audio visual contents. And that asymmetry is the main reason
for the adoption of downloading methods instead of streaming by the most common P2P systems.
Therefore, to provide streaming support in P2P systems, it is necessary, as a first requirement, to take
into account the typical asymmetric characteristics of the access networks. Another requirement is the
ability to support some form of adaptive media streaming. And here is where SVC techniques come of
help by allowing users with low bandwidth resources to watch the video as it is being downloaded.
The SVC techniques provide methods to encode videos into layers with nested dependencies, i.e.,
higher layers refine the video in lower layers. To decode and playback the video, the base layer (i.e.,
the first layer) is required, corresponding to a low definition, acceptable quality video with a low bitrate.
However, if higher layers can also be received then the decoding will produce a higher quality/definition
video.
The objective of the work in this thesis is the development of a prototype solution for streaming
scalable video in a P2P architecture. For that purpose, a study of the concepts associated with serving
Video On Demand (VoD) over P2P networks was performed, namely, Scalable Video Coding, Peer-toPeer overlay networks, applications supporting P2P video streaming and the associated standards or
recommendations. For the P2P architecture the option fall on the BitTorrent protocol, but modified in
order to comply with the key requirements for distributed video streaming:
• Real-Time streaming: Lost packets in enhancements layers neither affect the assembly nor the
decoding of lower layers. The proposed Chunk-Layer requesting and scheduling algorithms give
higher priority to more important layers.
• Real-Time adaptation: maximizes the end-user perceived quality by adapting the video streaming
to the terminal capabilities and the available bandwidth.
3
• Upload Policies: incentive method for peers as the more they contribute, the more they receive
video with better quality.
1.2
Contributions
The SVC P2P Player prototype solution described in this thesis was developed within the scope
of the European project SARACEN [7]. The solution was implemented and tested at INOV – INESC
Inovação facilities [8] .
The heterogeneity of the access networks to be supported and the diverse terminal capabilities
characteristics were the main constraints taken into consideration for the design of the prototype solution.
From the analysis of these constraints new key ideas were developed for the process of SVC media
content distribution and for the adequate data requesting and incentives strategies on P2P transport
mechanisms. These key ideas were applied, as proof of the concept, to a well known P2P core engine,
becoming the major contributions of the work developed in this thesis to the SARACEN project.
SARACEN stands for “Socially Aware, collaboRative, scAlable Coding mEdia distributioN” and it is
a research initiative funded partially by the Information Society and Media Directorate General of the
European Commission under the Seventh Framework Programme.
The SARACEN initiative will research on distribution of multimedia streams supported through innovative techniques, both as regards media encoding and media distribution including P2P schemes,
where the peer nodes will participate in an end to end media distribution system making use of social
networking related information [7].
The architecture, implementation and evaluation of the prototype has been described in a paper
[9] accepted and presented at the CRC 2010 – 10a Conferência sobre Redes de Computadores, at
Universidade do Minho, Braga, Portugal in November 2010 [10], and was awarded with the CISCO 2nd
Best Paper prize.
1.3
Thesis research topics
For the development of the SVC P2P Player prototype the following research topics were thoroughly
explored:
• Scalable Video Coding. How to use these coding techniques to achieve a layered structured
scheme for distribution? How to segment into pieces a layered video and later re-assemble the
several pieces (or chunks) into a single playable video stream?
4
• Underlying Peer-To-Peer Network. Which Peer-to-Peer structure to use? Which implementation?
• Adaptation Techniques. How to adapt download scheduling based on client terminal capabilities
and available bandwidth?
• Real-Time streaming. How to provide a platform such that given a lower bound of download rate,
streaming doesn’t stop?
1.4
Dissertation layout
This thesis is organized in six Chapters. Chapter1 introduces the work and presents the objectives
and the motivation. Chapter 2 gives an overview of the state of the art in the fields of research. Chapter 3
describes the architecture of the developed prototype and its functionalities. Chapter 4 describes the
implementation of the prototype. Chapter 5 evaluates the solution and discusses the results. Chapter 6
summarizes the contributions of this thesis and suggests improvements and future work.
5
6
2
State of the Art
Contents
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.2 Scalable Video . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.3 Peer-to-Peer Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4 Peer-to-Peer Video Streaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.5 Scalable Video and Peer-to-Peer
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7
2.1
Introduction
This chapter presents the current perspective and related work on Scalable Video Coding (SVC),
Peer-to-Peer (P2P) Networks, existing applications for Peer-to-Peer video streaming and the deployment
of scalable video standards in Peer-to-Peer networks.
2.2
Scalable Video
The H.264 Advanced Video Coding (AVC) standard is currently the preferred solution for video services in 3rd Generation (3G)/Universal Mobile Telecommunications System (UMTS) networks, public
online video sharing web sites, such as YouTube [11], messaging services, multimedia broadcast/multicast services [12].
This current adoption of the H.264 AVC has led to the later definition of a scalable extension of this
encoding method with the purpose of efficiently support the transmission of several layers of quality,
providing a distinct rate adaptation model that is ideal for a P2P distribution scenario.
The scalable extension of H.264 AVC [13], denoted as H.264 SVC or simply SVC, includes a sparse
number of quality layers. The scalability property of SVC supports the partitioning of a valid bit stream
into several other valid sub-streams by simply cutting parts of its data. This feature is very special
due to its advantages for adaptation purposes because, due to its simplicity, it may be performed in
intermediate network elements without requiring high load computational work, like what happens with
video transcoding. Additionally, the base layer of an encoded H.264 SVC bit stream is by definition
compatible with H.264 AVC, enabling backward compatibility with legacy equipments.
The reference software for the SVC standard (called Joint Scalable Video Model) can be found on the
Internet [14]. Several related papers on SVC can be found as well (Streaming [15], Performance [16],
RTP [17] and Mobile [18]).
Another concept besides scalable video, in some way related to it, is the concept of Multi Description
Coding (MDC) [19]. MDC has similar purposes to those of SVC - namely, altering the bitrate of a video
- but using a completely different approach. The idea of MDC is to divide the coded video into several
sub streams (i.e., descriptions). Each description alone can be decoded to a valid (but low quality)
video stream. The final quality of the video improves with the number of available descriptions, until all
descriptions decoded together finally form the original video stream [2].
The crucial difference of MDC to SVC lies in the prioritization of different parts of the video. While
in SVC the layers form a clear nested dependency (from the base layer to the last enhancement layer)
the opposite is true for different MDC descriptions. Therefore, all parts within a MDC coded bit stream
are equally important and contribute the same amount to the final quality. The same is not possible with
SVC layers if one of the underneath layers is missing. On the other hand SVC utilized the fact that not all
8
parts of a video are equally important to the final quality. Therefore, it becomes possible to convey the
essential parts in the base layer, adding details to the final video with enhancement layers. Furthermore,
data portioning of MDC demands a substantial amount of coding overhead and increases the complexity
of the decoder [2].
The scalable dimensions offered by SVC are three [2]:
• spatial (i.e., number of encoded pixels per image);
• temporal (i.e., pictures per second);
• quality (or Signal-to-Noise Ratio).
In a bit stream, each NAL unit (NAL units are packets that start with a one-byte header and have
an integer number of bytes) is associated with a given level of spatial, temporal and quality fidelities
using three identifiers: dependency id (D), temporal id (T), and quality id (Q). These identifiers are
associated in a (D,T,Q) tuple, where each ID is represented by an integer value. Higher ID values
designate components that stand higher in the encoded hierarchy. A wildcard “*” may be used to refer
to any number. For instance, a layer identified as (0,*,0) refers to all temporal identifiers of the lowest
encoded spatial and quality fidelities.
In the following section each of these scalability dimensions will be described in more detail.
2.2.1
Spatial Scalability
Spatial scalability provides support for several display resolutions with arbitrary ratios. Figure 2.1
presents an encoding structure which uses a dyadic spatial scalability, where the spatial base layer (or
reference layer) is represented by a Quarter Common Intermediate Format (QCIF) sequence and the
enhancement layer by a Common Intermediate Format (CIF) sequence.
Although this figure presents only two spatial layers, the encoder supports multiple spatial scalability
layers combined with temporal and/or quality layers.
In spatial scalability both motion-compensated and intra prediction techniques are employed within
the same spatial layer. However, to reduce the spatial redundancy between these layers, SVC also
includes an inter-layer prediction mechanism between spatial resolutions.
The spatial scalability feature of SVC was not restricted to the scaling ratio of 2 shown in the previous
example. In fact, the SVC encoder can be used to encode different regions of a video scene, in what
is referred as “generalized spatial scalability”. For instance, using this feature, two spatial layers can be
encoded and transmitted, with the first targeting Standard Definition (SD) television (4:3 aspect ratio),
and a second layer for High Definition (HD) television (16:9 aspect ratios).
9
Figure 2.1: Example of a combined temporal and spatial scalable coding considering two different frame
rates at lower and higher layers [1]
2.2.2
Temporal Scalability
Temporal scalability is a technique that allows the support of multiple frame rates through the partitioning of the set of Access Units (AUs) into several layers of quality that can be discarded after a certain
point. Although the main concepts of temporal scalability were already included in H.264 AVC, in SVC,
temporal scalability is usually implemented by using hierarchical B-pictures.
Figure 2.2 exemplifies such an encoding structure, for a video partitioned into several temporal layers
(from T0 to T4). Considering that the decoding of all temporal layers (from T0 to T4) results in a 30 fps
sequence, and that the hierarchical encoding structure is the same as represented in Figure 2.2, the
decoding of the base layer (T0) would lead to a 1.875 fps decoded video sequence; the combined
decoding of T0 and T1 originates a 3.75 fps sequence; T0, T1 and T2 originates a 7.5 fps frame rate;
and so forth. It can also be observed in Figure 2.2 the special frames f0 and f16, usually called “key
pictures”. They can be either intra-coded or inter-coded by using motion-compensated prediction from
previous key pictures.
The resulting number of temporal scalability levels depends on the specified Group of Pictures (GOP)
size, which in turn may be equal to, or a ratio of, the period between intra-coded pictures. For instance,
for a GOP size of 4 and a maximum frame rate of 30 fps, only three temporal scalability points are
encoded (7.5, 15 and 30 fps).
10
Figure 2.2: A temporal layer encoding structure using a hierarchical prediction structure for groups of 16
pictures [1]
2.2.3
Quality Scalability
Quality (or Signal-to-Noise Ratio (SNR)) scalability reuses some of the concepts defined for spatial
scalability, equally setting the picture sizes between base and enhancement layers. It relies on both
Coarse-Grain Quality Scalable (CGS) and Medium-Grain Quality Scalable (MGS) coding. CGS encodes
the transform coefficients in a non-scalable way, which may only be decoded as a whole. In MGS, which
is a variation of CGS, fragments of transform coefficients are split into several NAL units, enabling a
definition of up to 16 MGS layers, and increasing the rate granularity for adaptation purposes.
During the standardization process, the Joint Video Team of ISO/IEC MPEG and ITU-T VCEG (JVT)
also considered another form of scalability named Fine-Grain Scalability (FGS), which was already considered in MPEG-4 Visual [20]. In FGS, the transform coefficients are arranged as an embedded bit
stream, allowing truncation of the associated NAL units at any arbitrary point. This procedure aimed at
producing a much higher number of rate adaptation points when compared with MGS. However, to prevent drifting errors caused by the lack of synchronization between motion compensated prediction loops
at the encoder and decoder, the enhancement layers in FGS are intra-coded (see left side of Figure 2.3),
which introduces a high cost in terms of coding efficiency.
Due to that cost, FGS layers were replaced by MGS layers in the final stage of the first specification of
SVC (Phase I). The solution chosen for MGS was to define pictures from the temporal base layer (or T0)
as key pictures, for which SVC sets the motion parameters equal between the base and enhancement
layers. This solution enables a single loop decoding of these pictures, similar to the one used in spatial
11
Figure 2.3: Motion-estimation in Quality Scalability comparing Fine Grained Scalability (left side) versus
Medium Grained Scalability (right side) [1]
scalability. Regarding the remaining pictures, it is up to the encoder to decide whether to use the
reconstructed base layer or the enhancement layer to compute the motion parameters. However, it
usually uses the highest available quality for motion estimation and compensation. In such a case, the
loss of MGS layers causes a drift error that will only be limited by the GOP size, or by the number of
MGS layers available.
2.2.4
Combination of the Scalability Dimensions
All of the three scalability dimensions can be combined with each other. The schematic structure
of such a bit stream is exemplified in Figure 2.4. The most important classification refers to the spatial
layers of the SVC video stream. Within one spatial layer there can reside one or more temporal and
quality layers.
2.2.5
Benefits of Scalable Video
After clarifying the relevant aspects of encoding a video using scalable techniques, in comparison to
non-scalable videos, SVC provides the following advantages:
• In case of simulcasting (e.g., Smooth Streaming [21]), several different versions of the same video
must be available in order to serve diverse user requirements. Obviously, those different versions
bear a high degree of redundancy, requiring higher computational power from eventual heuristics
decision algorithms at the end user systems.
12
Figure 2.4: Combined Scalability Dimensions [2]
• Scalable video streams can be encoded in such a way that offer more than a simple limited number
of different bitrate points.
• The management of different bit rate versions of the same video is avoided. With scalable video
a single bit stream can serve a diversity of client needs. As a consequence the adjustment of the
bitrate can be simplified as it no longer involves switching between separate bit streams, but can
be carried out within the same video stream.
• In representing the encoded video in a layered structure, scalable video assigns different importance to each layer. The base layer of a scalable video stream comprises information that is
fundamental for the playback of the video. Thus, it represents the most important parts of the
video stream. As the order of the enhancement layers increases their importance decreases.
The advantage of this layered structure is that specific parts of the encoded video stream can be
prioritized.
• Especially for P2P networks, scalable video offers another advantage (related to the aforementioned one) that accommodates well to heterogeneous networked environments. Generally, all
peers of a network do not form a homogeneous group, but differ in their bandwidth or computing
capacities. Thus, in case of simulcast, they would demand different bit rates of the video and
consequently also request different streams. This leads to the problem of breaking apart the P2P
overlay network into smaller sub-groups, each sharing only one version (i.e., bitrate) of the video
stream.
13
2.3
Peer-to-Peer Networks
The most common architecture used in computer communications is the client-server architecture,
illustrated in Figure 2.5(a), and the most famous system designed with a client-server approach is the
World Wide Web (WWW), characterized by central “Web” servers that handle requests from clients
connected to the Internet and located anywhere in the world. However, this client-server approach
typically lacks modularity, scalability and reliability. With increasing requests, the available bandwidth
and computational power in the server side also needs to increase. Without any form of load and
capacity distribution, a server can easily become the single point of failure and stop handling incoming
requests, making the whole system unusable. And here, distributed architectures as are P2P systems,
offer solutions to gain scalability and reliability in computer communications.
(a) Client-Server
(b) P2P
Figure 2.5: Centralized server-based service model and P2P system of nodes without central infrastructure
Most P2P streaming networks of today use a neighbor selection strategy that can be described as
either tree-based or unstructured.
Tree Based Overlays
Tree based overlay protocols connect all peers via a rigid tree structure where each peer forwards
incoming data packets to all of its children peers. Since the depth of such a tree stays usually rather
small, information can be rapidly transmitted to all members of the network.
Two main disadvantages hinder the application of “basic” tree based protocols:
• The tree maintenance overhead is large. Since the construction of a tree can be a complex and
time consuming task, these protocols form rather static structures that react inflexibly to peers
constantly joining and leaving the network (phenomenon known by “churn”).
14
• The quite rigid nature of the tree creates dependencies. Typically, each peer in the tree is only
connected to one single parent peer. This not only puts a heavy upload burden on the parent
node, but also makes the child node directly depended from the parent capacities. Hence, all peers
following further down in the tree may suffer as well from a weak predecessor peer. Besides, leaf
peers of the tree have no children and can therefore just receive packets without contributing to
other peers.
PeerCast [22] and FreeCast [23] are examples of the tree based P2P streaming networks.
Unstructured Overlays
Due to the mentioned disadvantages of tree based peer-to-peer networks, some systems avoid a
rigid structure between the peers. Instead, each peer keeps just a list of its direct neighbors while there
exists no global overlay on top of all peers. As a result peers are only aware of their direct neighbors.
This leads to an improved flexibility in case of churn and avoids the time consuming task of setting up
a tree structure. Moreover, peers joining or leave the network only cause very local modifications of the
network. Like tree-based overlays, also unstructured networks suffer from two downsides – both related
to a missing global structure for coordinating the distribution of data packets. Nevertheless, unstructured
overlays are in most cases favored over tree based ones, due to their better robustness against churn.
Chainsaw [24] and GridMedia [25] are examples of an unstructured neighbor selection strategy, that
differ primarily in the number of neighbor nodes each peer has to keep. Some file sharing protocols, like
BitTorrent [3], Gnutella [4] and eMule [5] also use similar concepts.
2.3.1
BitTorrent
The BitTorrent [3] P2P system designed by Bram Cohen in 2003, is both a protocol suite used for
communications in a P2P fashion, and a client application that uses the protocol for file sharing. BitTorrent has been designed to allow a fast download of large files over a P2P network, distributing resources
and limiting individual bandwidth consumption. The protocol is based on an encryption algorithm, called
BEncode [26], used for client/server and client/client communications.
Unlike traditional file sharing systems, the goal of BitTorrent is to create and provide an efficient
system to reliably distribute the same file to the largest number of available peers. This is a mechanism
to automatically coordinate the work of a multitude of computers, obtaining the best possible common
benefit. BitTorrent is a protocol that allows distributing files of any type. To facilitate the transmission,
the original object file is split into many small fragments, named “pieces”, which will be recombined at
the destination into a copy of the original object file. The pieces have a fixed size, and for verification are
fingerprinted using a cryptographic Secure Hash Algorithm 1 (SHA-1), and distributed among the peers.
15
Every file-sharing program designed for a P2P network needs some share-ratio enforcement to guarantee the survival of the system. The share-ratio enforcement corresponds to the set of rules that enforce peers to share their upload bandwidth with other peers in the system. In BitTorrent, the share-ratio
enforcement is guaranteed by Tit-for-Tat Protocol (TFT) [27], a protocol that tries to gain a high sharingratio between peers. TFT is designed in a bidirectional way, i.e., a peer will be able to download from
another peer if it is uploading some content to that one. This gives peers an incentive to be available
and donate bandwidth to the BitTorrent network. Furthermore TFT provides a solution for the free-riding
problem by stimulating cooperation [28].
The search for available contents is done in a centralized way, typically through Web sites where
“torrent” files (*.torrent) are stored. The “torrent” file is a simple and small file, published by a user on a
Web site. This file corresponds to an encoded index describing all the “pieces” in which the original object
file(s) shall be divided for transmission, including their hash keys, ensuring therefore the integrity of the
whole set. The “torrent” file contains the address(es) of special servers of the BitTorrent system called
Trackers. In order to take advantage of the system, a user (peer) downloads the (*.torrent) file from
the web server and loads it in a BitTorrent application that will start to contacting the Tracker(s) in order
to bootstrap the P2P overlay network for that “torrent”. The Tracker is used to maintain the connection
properties of the group of peers exchanging the object file(s) indexed in the respective “torrent”. The
total group of peers of a “torrent” is called a “swarm”.
2.3.2
Piece Picking Policy
As mentioned, the BitTorrent system uses a special (temporary) file system to which the splitting and
hashing operations are applied, in order to manage the small fragments (“pieces”) of the object file(s)
for transmission in the overlay network. It is therefore in the core module of the BitTorrent system where
the real benefits of SVC and bandwidth adaptation take control. Common BitTorrent clients have piece
picking policies based on randomly selected pieces, keeping track of the pieces available at neighbored
peers (piece maps) to determine which are the rarest in order to achieve maximum availability of these
pieces in the swarm.
For streaming purposes these policies are inadequate since streaming requires in-order transfer of
pieces. There are already several methods applied to BitTorrent applications that cater for the in-order
piece picking policy, but none available, so far, that take into consideration Scalable Video Coding [29].
To use SVC this in-order transfer requirement must also include prioritization, i.e., pieces that constitute
the base layer of the scalable video must have the highest priority.
16
2.4
Peer-to-Peer Video Streaming
Many P2P client applications are already available on the Internet offering video streaming capabilities (but without the functionality for scalable video). Among the most interesting, still experimental
systems, it is worth mentioning Tribler [30] and BitLet [31]. Most of them rely on similar concepts: offering professional TV shows alongside private content and making money through advertisement, as
business model. The advantage for traditional TV stations (broadcasters) is that they can make their
programs available worldwide (apart from contents rights restrictions issues), while shifting the costs
for broadcasting to the individual users. Also, in Asia, Peer-to-Peer Television (P2PTV) applications like
TVUPlayer [32], PPLive [33] or CoolStreaming [34] are becoming more and more popular.
2.4.1
Tribler
Tribler [30] is an solution being designed and implemented since February 2006 in the Parallel and
Distributed System group of the Faculty of Electrical Engineering, Mathematics and Computer Science of
the Delft University of Technology in the Netherlands. The project started as a small enhancement to the
ABC client [35] but now integrates a wide range of functionalities that make it quite unique. Tribler differs
from other popular BitTorrent clients such as Vuze [36] and µTorrent [37] due to some of its features.
Tribler adds keyword search ability to the BitTorrent file download protocol by using a gossip protocol and
also includes the ability to recommend contents by estimation heuristics that retrieve user downloading
tastes. This feature is based on collaborative filtering, also featured on websites such as Last.fm [38]
and Amazon [39]. Another feature of Tribler is a limited form of social networking and donation of upload
capacity. Tribler includes the ability to mark specific users as on-line friends. Such friends can be used
to increase the download speed of files by using their upload capacity [40]. The last evolution of the
software integrates new functionalities to prevent free-riders and guarantee fairness [41].
2.5
Scalable Video and Peer-to-Peer
Although Scalable Video Coding and Peer-to-Peer networks have attracted enormous attention from
the research community, the amount of scientific publications focusing their interaction is rather small.
The authors in [42] employ SVC to guarantee smooth delivery of video content among the peers in the
network. Their performance tests were carried out with a quality scalable video stream delivered over a
Gnutella like (i.e., unstructured) P2P network. The evaluation results show an improved video throughput
rate to the peers, measured in kbps, and an enhanced quality of the received video, measured in Peak
Signal-to-Noise Ratio (PSNR).
17
The system described in [43] also uses SVC in a P2P environment. The theoretical analysis concentrates on quantifying the advantage of SVC with respect to single layer video coding. The quality gains
are measured in PSNR and are computed from bandwidth capacities measurements at the peers. Especially, in networks with a heterogeneous bandwidth distribution, the strengths of SVC becomes obvious.
The experimental tests were conducted with a real time streaming protocol called Stanford Peer-to-Peer
Multicast (SPPM) [44]. The results prove that in case of a congested network SVC outperforms single
layer coding, due essentially to the prioritization of layers that allow playing at least the most important
layers, even if the video is not completely received. Whereas, if bandwidth is not the bottle neck, single
layer coding benefits from its better coding efficiency.
The research project P2P-Next [45], is also conducting the study and deployment of an advanced
version of Tribler to use SVC encoding, but oriented to a fully distributed web platform, named NextShare
[46].
2.5.1
NextShare
NextShare [46] takes the form of a browser plug-in for video playback. Allowing playback directly in
a browser makes it easier for content providers to integrate P2P based video delivery into their existing
Web based distribution mechanisms (e.g., portals). As already happened with the most recent version
Figure 2.6: The Graphical User Interface (GUI) of the SwarmPlayer
of the Graphical User Interface (GUI) of Tribler, the NextShare SwarmPlayer (see Figure 2.6), is just an
18
interface to Triber’s Application Programming Interface (API) that enhances it with VoD functionality. The
NextShare SwarmPlayer is responsible for handling the download and to manage the video playback. To
obtain the VoD functionality some characteristics of Tribler, more precisely of the BitTorrent-like module,
had to be modified. For this purpose a new algorithm, called Give-to-Get [47], has been designed and
implemented to handle the upload policies.
The modification of the BitTorrent core module of Tribler is not Quality Of Service (QoS)/Quality Of
Experience (QoE) aware, since this was not the main concern of the research and development of the
project. The benefits of combining SVC, network and terminal characteristics were not also explored in
the NextShare project, more driven to large scale video distribution.
However, the upload incentives strategy applied through the Give-to-Get algorithm in these projects,
offers a quality and secure solution, resilient to free-riders present in the network.
2.6
Summary
In this chapter the concepts and properties of both Scalable Video Coding and Peer-to-Peer networks
have been presented.
Scalable video brings various benefits, due to its layered structure, achieving high performance in
Peer-to-Peer networks.
Different Peer-to-Peer network architectures were also briefly described with a focus on the BitTorrent
file sharing application to make the bridge to the compatibility with SVC and the required specific piece
picking policy.
Other video streaming applications for P2P networks were also mentioned but these are very scarce
in SVC compatibility, and the few that exist (NextShare) still remain in a research and development state.
19
20
3
Architecture
Contents
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2 Functional and Non-Functional Requirements . . . . . . . . . . . . . . . . . . . . . . 22
3.3 Architecture Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4 System Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.5 BitTorrent engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
21
3.1
Introduction
This chapter describes the architecture of the Scalable Video Coding Peer-to-Peer Player prototype.
The prototype has been realized within the scope of the European project SARACEN [7]. The first
section describes the functional and non-functional requirements for the whole design.
The following sections describe the Architecture Design and the System Modules of the prototype.
As the main module of the prototype is the network core, we shall take an overview on the architecture
design of the BitTorrent engine.
3.2
Functional and Non-Functional Requirements
The Scalable Video Coding Peer-to-Peer Player prototype functional requirements are the following:
• BitTorrent-like Network Core: The main core network module shall follow a BitTorrent-like standard for a P2P distribution network.
• Access Network independency: The solution shall be able to provide services to Clients connected over Local Area Networks (LANs) or Wireless Local Area Networks (WLANs) and over
several Wide Area Network (WAN)/Wireless Wide Area Network (WWAN) access network technologies, such as Ethernet, xDSL, Cable, Fixed Wireless Access (FWA) 3G or WiMax.
• Client independence: The same type of service shall be provided to all Clients requesting it
(terminal capabilities adaptation).
• Seamless video quality transition: This requirement is essential for the correct functionality of
the Real-Time adaptation.
• Client upload incentives: Incentive mechanisms help clients to contribute with maximum available upload bandwidth to the network. As a reward, more download bandwidth will be released for
each contributing client, hence more video quality.
To fulfill the above requirements, an essential non-functional requirement must be developed and
implemented on the prototype:
• Scalability and Reliability: The SVC P2P Player shall be scalable and use the hardware and
network resources efficiently while performing its required functions under a variety of conditions.
22
3.3
Architecture Design
The SARACEN system is basically composed by several Peers (i.e., Client Nodes of type Seeder
and Leecher) and one or more Trackers (i.e., Control Servers). Unlike what happens with a Client-Server
model, the Trackers of SARACEN do not relay video content but instead provide information about the
Peers on the network (i.e., contact information, streamed data status, etc.). An overview description of
the tracker protocol and peer message protocol is available in Appendix A.1 and Appendix A.2 respectively.
The technique used for the operation relies on a chunk transfer scheme (described in Section 3.3.1),
whereby the original video file data is chopped into small video Chunks with a duration of 2 (two) seconds. Each Chunk of video is then partitioned into various files, called Layers, for the transmission. The
only Layer that is required to reproduce the video, without dependencies, is the first Layer, called the
Base Layer. The remaining Layer files will consume more download time, but if the Peer manages to
download them, they will enhance the quality of the final assembled video.This scheme has the following
advantages:
• Increases time stamp and video bitrate adaptation granularity (very good for live streaming, and
time seeking purposes);
• Decreases the timeline delay for the streaming peers that are watching a live event.
The best way to understand how the content is distributed and streamed in the network, is by exemplifying a video content transfer between Peers (see Figure 3.1).
Figure 3.1: File Data Process and Distribution
23
The network is composed by two types of peers: a Seeder and a Leecher. The Seeder holds the
complete video content (i.e., the container with all file pieces), hence he will have all chunks and all layer
files. The Leecher is a peer which is downloading the content within the BitTorrent overlay network and
has not yet completed the transfer of all files.
In this case, the Seeder is the peer that produces the ”.torrent” file that holds information about the
pieces hash and correspondig index mapping within the container file system. The Seeder uploads this
file to a public/private web server where it can be accessible for download to other clients.
Once the Leecher starts the bootstrap procedure (not the original Seeder of the video) to initiate
streaming of contents, it first downloads the ”.torrent” file from the Torrent File Storage web server. It
then contacts the Tracker to register itself (via announce messages) and to ask for information on other
Peers that are sharing the desired content in the network.
After the Leecher succeeds with the transfer of some or all Layers of a certain Chunk using the
BitTorrent protocol to exchange data with the Seeder, it can be assembled into a playable video (with
2 seconds of duration), with variable quality that depends on the number of hierarchic Layer files used.
Each assembled Chunk is then put in the the SVC Player buffer for play-out.
The P2P network behaves therefore as a distributed file system (or a multi-source streaming system)
for video chunked layered files.
The next two sections describe the SVC file structure design, and the multi-source streaming Adaptation System.
3.3.1
SVC File Structure Design
In broad terms, a binary H.264 SVC file is divided in a sequence of NAL units, as illustrated in
Figure 3.2 where each line corresponds to a NAL unit.
Each NAL unit is preceded by the following four bytes start code: ‘00h’ ‘00h’ ‘00h’ ‘01h’. According
to [48] after the start code there is one byte with the structure illustrated in Figure 3.3.
In this byte, the value of “Type” is important for the analysis of the content of the NAL unit, as, also
according to [48], NAL unit types 14 and 20 indicate the presence of three additional octets in the NAL
unit header, as shown in Figure 3.4.
From these fields, mainly the values of the Definition (DID), Quality (QID) and Temporal IDs (TID) are
of importance for the analysis or extraction processes.
For the partitioning into Chunks and Layers the following methods were designed:
Chunk Partitioning:
The Chunks are delimited by Supplemental Enhancement Information (SEI) field NAL units (i.e., NAL
unit Type=6). Therefore, each Chunk starts when a SEI NAL unit appears in the encoded file and ends
in the NAL unit that precedes the next SEI NAL unit (see Figure 3.5).
24
Figure 3.2: Structure of a binary H.264 SVC file
Figure 3.3: NALs initial four byte code
Layer Partitioning:
Considering the structure described above, each and every Chunk should be partitioned as described
in Table 3.1. In this table, the value of Ci reflects the Chunk ID (which according to the description file
should be ‘C001’, ‘C002’, etc.).
Table 3.2 exemplifies the NAL unit classification in several transmission layers.
3.3.2
Adaptation System
When a user wishes to share a SVC video encoded stream via a BitTorrent-like engine, it should
create a “torrent” by generating a special index file (*.torrent) containing all the necessary information
for other Peers to initiate the download process of the “torrent”.
All the content of the SVC video encoded stream should be mapped accordingly into a list of equally
sized blocks named Pieces. These Pieces are normally in the order of 2N KB in size, i.e., 16 KB, 32 KB,
128 KB or 256 KB.
However, this simple equally sized blocks strategy for SVC video has a disadvantage: a single Piece
would contain data belonging to two adjacent layered files (e.g., base layer and the next enhancement
25
Figure 3.4: Additional bytes in NAL unit header
Figure 3.5: NALs structure in a chunk
layer), therefore, non requested payload data would be transferred causing overhead in the connections.
The option taken for the system prototype does not uses the equally sized blocks strategy of standard
BitTorrent protocols.
A Standard BitTorrent application would extract pieces from the peers in the network in a randomly,
rarest-first style order. This strategy is not suitable for a streaming application since it would require for
all video data of a present instant to be available. If a critical file isn’t available, the video rendering would
stop. Figure 3.6 illustrates this scenario.
Figure 3.6: Standard BitTorrent Piece Download Strategy
The strategy used for the Adaptation System relies on a special algorithm for choosing the adequate
26
Table 3.1: Chunk partitioned structure
Order of Interdependency
Filename
NAL units with (D,T,Q) = (0,*,0)
Ci-D0L0.264
NAL units with (D,T,Q) = (0,0,1)
Ci-D0L1.264
NAL units with (D,T,Q) = (0,1,1)
Ci-D0L2.264
NAL units with (D,T,Q) = (0,2,1)
Ci-D0L3.264
NAL units with (D,T,Q) = (0,3,1)
Ci-D0L4.264
NAL units with (D,T,Q) = (1,*,0)
Ci-D1L0.264
NAL units with (D,T,Q) = (1,0,1)
Ci-D1L1.264
NAL units with (D,T,Q) = (1,1,1)
Ci-D1L2.264
NAL units with (D,T,Q) = (1,2,1)
Ci-D1L3.264
NAL units with (D,T,Q) = (1,3,1)
Ci-D1L4.264
pieces from each Peer. The following example illustrates the adaptation algorithm developed for this
process, in the case of a SVC encoded file, layered up to 4 Layer files for each video Chunk.
A download time window of 2 seconds is applied giving only priority to the base layer file. If this file
is successfully downloaded, the number of corresponding Layer files to download can be increased up
to the maximum number of available layers, or subsequently decreased to the base layer, depending on
several conditions being monitored. At the initial time of the movie, a buffering state is set in progress.
This case pops up an exception since the order of download will not imply on visual disorder.
As the time window slides every 2 seconds, higher priority assignments are given to the next Chunks
in the timeline. In this order, previous Layer files that were not downloaded may have a change of being
downloaded, increasing the availability of Layers in the network even if the client didn’t take advantage
of them in the video rendering process.
Figure 3.7 demonstrates the file priority assignment as video rendering is being process by the Media
Player module.
In the Implementation chapter (Chapter 4) the details of the special piece picking policy for the chosen
BitTorrent module are discussed, as well as the approached taken for these modifications.
3.3.3
Peer Selection Strategy
The BitTorrent module uses standard peer selection and neighbouring algorithms. But it will also
take into consideration the closest peers in geographical location for file sharing, as the client engine
should give higher priority to request of pieces from the closest Peers rather than from Peers on very
distant geographical zones, essentially due to the following reasons:
27
Table 3.2: NAL units and their transmission Layer structure
NAL unit (D,T,Q)
Transmission Layer
(0,0,0)
(0,1,0)
D0L0
(0,2,0)
(0,3,0)
(0,0,1)
D0L1
(0,1,1)
D0L2
(0,2,1)
D0L3
(0,3,1)
D0L4
(1,0,0)
(1,1,0)
D1L0
(1,2,0)
(1,3,0)
(1,0,1)
D1L1
(1,1,1)
D1L2
(1,2,1)
D1L3
(1,3,1)
D1L4
• ISP Traffic Cost – Minimize traffic costs to international Internet Service Providers (ISPs), by trying
to request off pieces from local Peers, or from Peers in the same ISPs network.
• RTT Latency – It is preferable to relay traffic to local peers due to long distance latency (downloading even the base layer pieces from a Peer in China to Portugal using a limited bandwidth/bitrate
connection).
• Traffic Shaping – As P2P networks occupy most of today’s traffic in the Internet, ISPs tend to
apply traffic shaping (throtling) in order to limit peer download bandwidth and to decrease the load
in their border routers. Selection of local peers would also help to increase the availability of pieces
in the P2P network.
This strategy will be included as another piece picking modification from the standard policy, that will
work in parallel with the adaptation system.
28
Figure 3.7: Priority Sliding Window Piece Download Strategy
3.3.4
Upload Policies
Upload incentives must be applied in order to prevent Free-Riders. The incentives strategy lowers
priority to Peers with high asymmetric bandwithed in the network.
The standard BitTorrent strategy for incentives uses a the Tit-for-Tat algorithm in order to exchange
download bandwidth for upload bandwidth.
3.4
System Modules
To fulfil the functional requirements, a modular approached solution was designed. Figure 3.8 illustrates a stack-based modular representation of the solution.
Figure 3.8: Stack-based modular representation of P2P SVC Player
Each module definition is easily customizable and offers the possibility to be replaced by a new
redesigned module if required in the future. For example, the GUI can be replaced by a new module that
may represent a canvas in a Web Browser instead of a window in a Desktop Application.
29
Figure 3.9 illustrates the modular representation of the whole system, with more detailed information.
Figure 3.9: System Design Overview
The GUI, Media Player and Chunk Manager have for purpose the coordination of the video Chunk
scheduling and also to provide user controls and statistical information about both the network and
video quality. The BitTorrent-like module is the one responsible for coordinating and maintaining the
connection to the P2P overlay network and the transfer of the Chunks as ordered by the other modules.
It was on the BitTorrent-like core module that the major modifications and contributions of this work
were performed. Taking into consideration the data monitored by the sub-modules of the Chunk Manager
(i.e., CPU Load Adaptor, Screen Size Adaptor and Download Manager) it ws then possible to support
decisions in new developed algorithms for the Piece Picking sub-module of the Main Engine of the
BitTorrent module.
The following sections describe in detail the role of each of these main modules and corresponding
sub-modules.
3.4.1
Graphical User Interface
The Graphical User Interface Module is the front-end of the whole system.
As illustrated in Figure 3.9, all sub-modules require interaction with underlying modules such as the
Media Player for movie control, and the BitTorrent module for statistical information and control of the
network operation.
The Graphical User Interface module is composed by three sub-modules: Video Renderer, Video
30
Controls and P2P Info/Control.
3.4.1.A
Video Renderer
The Video Renderer module provides an interface to the Media Player in order to give access to it
and render the video frames to be used in the Player. The module also provides information for the user
in a static Panel of the GUI.
3.4.1.B
Video Controls
This sub-module will offer the following functionalities:
• Movie Control – Opens new stream contents from local stored files or Uniform Resource Locators
(URLs). It also provides Trick Function controls such as Play, Pause and Stop. Time seeking
functionality is also added as a feature.
• Video Quality Control – Video Quality levels can be chosen by the user, correspondig to the level
(higher number) of Layers for the Chunks.
3.4.1.C
P2P Info/Control
This sub-module will offer the following functionalities:
• Networking Info – Such as Downloading/Uploading rate, number of nodes in the network, current
transmission of Chunks and Layers.
• Networking Control - To limit the download/upload rate of the networking module.
3.4.2
Media Player
The Media Player module is responsible for the decoding of the H.264 SVC video Chunks. This
module is split into two sub-modules: The SVC Decoder module and the Feed Manager module.
The Decoder application for the H.264 SVC is transparent to the system in order to be replaceable
in the future by newer improved decoder applications.
3.4.2.A
SVC Decoder
The only objective of the Decoder module is to play-out a video file sent by the Feed Manager module.
The Decoder module must support inter-process communications for Trick Functions like Pause, Play,
Stop and Seek. It must also accept simultaneous Read and Write operations to the video files.
31
The development of a SVC Decoder module is out of the scope of work in this thesis. An open
source implementation of a decoder, or the integration of a special purpose SVC decoder, developed
under the SARACEN project are the options to consider. For the developed prototype the option felt on
an open-source SVC decoder.
3.4.2.B
Feed Manager
The Feed Manager module controls all operations associated with media Chunks sent to the SVC
Decoder module, by maintaining a continous feed to the Decoder and guaranteeing that the file feeds
never enters into starvation mode, preventing interruption of the decoding process.
As video Chunks are of 2 seconds long, the Feed Manager has a time window of less than 2 seconds
to write the next video Chunk into the SVC Decoder buffer. As time control within the process is not trivial,
feed starvation is prevented by means of feeding a look ahead Chunk whenever a Pause, Play or Seek
command is triggerd.
The video Chunk data is obtained from the Chunk Manager module, directly from the Buffer Manager
within it. If the Buffer Manager returns no data, it means that a buffering state has to be applied. The
Feed Manager terminates whenever it reaches the end of the video file. This data is provided by the
Chunk Manager as well.
When a Seek Command is received, the module restarts the download manager from the Chunk ID
that is being requested and enters in buffering mode.
3.4.3
Chunk Manager
The Chunk Manager module is responsible for the scheduling and monitoring of video Chunks download. It is comprised of several sub-modules: The Download Manager, the Buffer Manager, the SVC
Services module, the Time Controller, CPU Load Adaptor and Screen Size Adaptor.
This module contains terminal capabilities functionalities to evaluate the Central Processing Unit
(CPU) load of the process and the screen size of the GUI in order to provide the adequate support to
the adaption processes related to the hardware and software environment of the end-user terminal.
3.4.3.A
Download Manager
The Download Manager maintains the state of the downloading process: Buffering, Playing or Ready
state.
The Buffering state will order the download of the base layer of the next three Chunks, in orderly
manner, from a start Chunk (initially, it is Chunk with ID 1). The Playing state triggers the BitTorrent
32
module to transfer the Layer files of the next Chunk in due time order, whenever a clock event is raised
in the application.
This clock event occurs every 2 seconds (duration of a video Chunk) and is the time window available
for the BitTorrent module to download the Layer files of the next Chunk to be buffered. Every notice
received during the download time window will be compiled into a list of File Streams, and this information
will be passed to the Buffer Manager for further treatment.
The Ready state informs other modules that all Chunks have been downloaded, and that the download scheduling has been stopped.
3.4.3.B
Buffer Manager
The Buffer Manager is a First-In First-Out (FIFO) Chunk buffer list. The buffer has been designed for
a maximum capacity of either 10 Chunks, equivalent to the duration of 20 seconds of VoD, or 3 Chunks,
equivalent to the duration of 6 seconds of Live Video streaming.
Whenever the Download Manager invokes this module, it takes control of the File Writers provided
by the BitTorrent module, which are then enqueued into the buffer list. The Feed Manager will request
the Buffer Manager to provide the next chunk in buffer (the buffer only holds the File Writers descriptors).
This operation starts by reading each transmission Layer file (that has been downloading within the
time window) and invoke the SVC Service module in order to assemble the final video Chunk, that is
delivered to the Feed Manager.
The Buffer Manager may be restarted. Each restart will clear out the Chunk buffer list.
3.4.3.C
SVC Services
The SVC Services module offers the following fundamental operations:
• H.264 SVC Chunk Partitioner – Chops an encoded file into Chunks of 2 seconds.
• H.264 SVC Intra-Chunk Layer Partitioner – Splits the Chunks into transmission Layers.
• H.264 SVC Layer Assembler – From a set of transmission Layer files, it assembles all data
contained in the files, providing a memory output (without the final Chunk video file).
In Figure 3.9 the Chunk Manager makes use of the H.264 SVC Layer Assembler operation within
this module for the assembly functionalities of the SVC transmission files.
The Chunk Partitioner and the Intra-Chunk Layer Partitioner are operations executed in external
applications to support the process of transforming the original SVC file into the container file system as
described in Figure 3.1.
33
3.4.3.D
SVC Chunk Partitioner
The SVC Chunk Partitioner module partitions the encoded bit stream into a set of Chunks, each
corresponding to 2 seconds of H.264 SVC encoded video, as described in section 3.3.1. Each video
Chunk includes all the information needed for its play-out, independently of other Chunks. This feature is
the basic support for independent Peers joining the stream at any moment in the timeline of an ongoing
transmission, by not requiring the reception of any previous Chunks in order to start playing-out the
video.
The SVC Chunk Partitioner also generates a description file with the information about the starting
point of each Chunk. It also generates, for each encoded Chunk, a string with the description about the
available layers in the SVC encoded video. These layers are sorted by their order of interdependency.
3.4.3.E
SVC Intra-Chunk Layer Partitioner
In the SVC Intra-Chunk Layer Partitioner module, each Chunk is further partitioned into several
transmission Layers, as decribed in Section 3.3.1.
However, before the layer partitioning process, another task must be performed. The demultiplexing
of different NAL units in several files requires, from the receiver point-of-view, a numbering sequence to
enable the re-assembly of a bit stream with the original NAL units sequence.
In order to ensure the subsequent ordered re-assembly, the SVC Intra-Chunk Layer Partitioner module introduces a Sequence Numbering field (SeqNum, with 2 bytes) between the start code and the
beginning of the NAL unit, as illustrated in Figure 3.10.
Figure 3.10: Sequence number representation in a NAL unit
After the SeqNum insertion, Chunks can then be partitioned.
In summary, the tasks of the SVC Intra-Chunk Layer Partitioner are:
1. Inserts a sequence numbering (SeqNum) in each NAL unit of each Chunk,
2. Partitions the NALs of each Chunk in several transmission Layers.
3. Stores each transmission Layer as a file.
3.4.3.F
SVC Layer Assembler
The task of the SVC Layer Assembler is to actively request (during the Chunk period) as many Layer
files (of each Chunk) as possible, according to both the network and the terminal capabilities, to restore
34
the NAL order into a Chunk.
Table-3.3 presents the layer order and filename structure, where the value of Ci reflects the Chunk
ID (which according to the description file should be ’C001’, ’C002’, etc.).
Table 3.3: Layer order and filename structure
Layer Number
Filename
1
Ci-D0L0.264
2
Ci-D0L1.264
3
Ci-D0L2.264
4
Ci-D0L3.264
5
Ci-D0L4.264
6
Ci-D1L0.264
7
Ci-D1L1.264
8
Ci-D1L2.264
9
Ci-D1L3.264
10
Ci-D1L4.264
During reception, the SeqNum field should be used to restore the data order and afterwards should
be withdrawn from the received NALs, before submitting the bit stream to the decoder.
In summary, the tasks of the SVC Layer Assembler are:
1. Request the description file (.torrent) from the Server and interpret its content
2. Request the SVC layers from peers
3. Use SeqNum values to restore NAL order from different transmission layers,
4. Withdraw SeqNum values.
In Figure 3.9, the service used by the Chunk Manager in this module is the SVC Layer Assembler.
The other services are used every time a new video file is to be distributed in the network.
3.4.3.G
Time Controller
The Time Controller will launch a series of asynchronous events in order to perform diverse operations within CPU Load Adaptor and Screen Size Adaptor. Each event may have different time intervals
and will signal other sub-modules in order for them to execute the necessary functions.
35
3.4.3.H
CPU Load Adaptor
The CPU Load Adaptor module is launched at every second and evaluates the CPU load in order to
define the maximum number of layers to be downloaded by the Download Manager module. If the SVC
decoder module is consuming a very high percentage of the CPU, then less layers should be downloaded in order to maintain a stable decoding process and not to slow down the terminal performance.
3.4.3.I
Screen Size Adaptor
The Screen Size Adaptor module is launched at every second and reviews the rendered window
form size (the user may resize the players window form). If the window form size is at a low resolution
and the container file system has low resolution video Chunks, then higher resolution Chunks should
not be requested for download, improving therefore the Buffer Manager length and maintaining a steady
stream of video, resilient to network spiky variations.
3.5
BitTorrent engine
It was out of the scope of the work described in this thesis to develop a complete BitTorrent-like
engine, as its development process would occupy a very large amount of time and run huge risks of
testing failure (due to lack of number of testing components).
Therefore, the option was to use a well managed and implemented open-source version of a BitTorrent API and corresponding support tools, and make all the necessary modifications to adapt its characteristics in order to comply with the requirements of this project. The modifications and customizations
aim to be supported on cross-platform operating systems.
The next sections describe the main requirements for the BitTorrent engine and tools, makes an
overview of its architecture design and describes the main components that suffered adaptations for
compliance with the project requirements.
3.5.1
BiTorrent Engine Requirements
The BitTorrent engine should support and be compatible with the following tools or services:
• Standard Torrent Generation – The Torrent generation tool creates new Torrent Files (.torrent)
describing the piece hashes of the content intended for distribution.
• Standard Tracker Engine – Supports all functionalities for a serving Web Tracker, compatible with
most of the BitTorrent implementations available.
36
• BitTorrent Main Engine - Support all functionalities of a standard BiTorrent client application,
such as swarm functionalities, piece dowload/upload processes (leech/seed) and configurable
download/upload rates, also maintaining compatibility with most of the BitTorrent implementations
available.
Various BitTorrent features should also be supported in order to obtain high scalability and network
compliant hardware (i.e., routers), such as:
• Super-seeding
• UPnP and Network Address Translation (NAT)-Port Mapping Protocol (PMP) Protocol Support
• Peer-Exchange
• Local Peer Discovery
• Cache
• Web Seeding
• Selective or Prioritized Downloading
• Distributed Hash Table (DHT) Support
• IPv6 Support
The selective or prioritized downloading feature corresponds to the core functionality of the BitTorrent
engine, and it is over this component that the major modifications will be applied. The Torrent Generator
and the Tracker Engine are external applications used to set up the tracker process and to generate the
”.torrent” file for the file container system.
3.5.2
Architecture Design Overview
The major challenge in the adaptation of the BiTorrent Engine was to figure out a solution to prevent
deadlocking or stalling of the application.
The main reason is related to the usual large number of simultaneous operations/processes that are
running, such as:
• 60 or more active sockets sending/receiving data;
• Large number of disk I/O;
• Web Requests;
37
Figure 3.11: Modular architecture of The BitTorrent engine.
• DHT Requests (if used);
If all these operations were defined as single threads or blocking calls, the system would very easily
decrease its performance and most likely stall. To boost the performance and prevent deadlocks, a single
main working module, named MainLoop was designed to run all the mini-tasks in an asynchronous
mode.
The modular architecture of the BitTorrent Engine is represented in Figure 3.11. The main module
that initiates the core procedure is the Client Engine. The Client Engine may be running various Torrents
(overlays) simultaneously, each requiring a Torrent Manager process. All tasks from sub-modules in
both main modules (i.e., Client Engine and Torrent Manager) are always driven to the main thread (i.e.,
MainLoop) that is being executed at the Client Engine module.
Whenever a Peer initiates a connection to another Peer in the network (i.e., after the handshake
completed), both Peers must agree on showing interest in each other. The Peer that acts as client
sends an Interested message, followed by a response of UnChoke by the serving Peer, demonstrating
that it will reply to any future request from the client Peer.
After this process, and while connectivity between Peers is stable, the client will start to add Request
38
Figure 3.12: Stack representation of the standard Piece picking algorithms
messages to the main queue processing pipeline. To enqueue a Request message, the client must
choose which piece(s) it must request to the serving Peer (a more detailed description of the peer wire
protocol is available in Appendix A.2).
For a standard BitTorrent client, several piece picking algorithms are used in a combined order to
achieve maximum efficiency and availability by the P2P network.
Figure 3.12 illustrates the various Piece Picking algorithms (in a stacked representation) used in the
Piece Picking Module, by default. In Chapter 4 each of these algorithms are described in detail.
The Choke-Unchoke Manager is the module responsible for the upload policy/incentives functionality.
It is in this module that the Tit-for-Tat algorithm is implemented.
The Client Engine, the Torrent Manager and the Piece Picking Module will be described in detail in
Chapter 4.
3.6
Summary
In this chapter the general architecture of the solution with its component modules was presented.
The architecture of the SVC P2P Player prototype offers backward compatibility with BitTorrent functionalities and supports both Live and VoD Streaming of multimedia contents.
The design meets all the described requirements, such as a BitTorrent-like core, but suited for media streaming with bitrate adaptation. Client upload incentives are introduced in the BitTorrent module
turning the solution into a powerful and scalable application.
Both the Front-End and Middle-End components of the architecture were described, demonstrating
how the integration of the modified BitTorrent core with the SVC decoder module is processed.
This modular design is easily customizable and provides independency between each module.
39
40
4
Implementation
Contents
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2 Development Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.3 Development Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.4 Graphical User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.5 Media Player Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.6 Chunk Manager Module
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.7 The BitTorrent engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.8 Live Streaming Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.9 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
41
4.1
Introduction
This chapter describes the various stages followed in the development process for the implementation of the SVC P2P Player prototype. A general overview of the programming language and the
development environment used are presented, as well as the solutions used for building the various
modules.
4.2
Development Process
The development process of the entire prototype is presented in Figure 4.1 . The development
was divided into five stages: Requirements gathering and analysis, Research, Architecture design,
Implementation, and Validation.
In the first phase, the main functional and non-functional requirements were gathered and analysed.
Figure 4.1: Development Stage Process
The main focus of the development was to design a scheduling algorithm able to provide high performance using scalable video, when applied in a P2P network. Several parameters associated with
the End-User terminal device environment should also be considered, like computer CPU power, screen
resolution, visual focus and networking. To perform well in unstable environments, upload incentives
should also be added in order to achieve high upload bandwidth within the network and reduce buffering
timings (like video streaming interruption).
The research stage investigated the benefits or issues of using Scalable Video over P2P networks,
with special focus on applicable QoE metrics and techniques as valuable assets. The integration of
the Scalable Video encoding in BitTorrent-like applications revealed a challenging task, since standard
downloading schemes are typically incompatible either with VoD or with Live streaming modes.
After this process, the Architecture of the prototype was designed. A modular approach was adopted
and the main tasks for each module were defined.
In the implementation stage both the SVC Decoding and BitTorrent engine modules were carefully
selected due to the limited development time window constraint and effort estimated for the implementation of the prototype.
42
At a final stage the prototype was thoroughly evaluated by testing it against the functional and nonfunctional requirements, as well as its behavior and performance.
4.3
Development Environment
The prototype was developed on a Microsoft Windows Operating System, specifically, the most recent version at the time, the Windows 7. The programming language chosen for the development was
C#, due to its simplicity and ease of integration with all modules of the prototype, including the most
complex, the BitTorrent engine module. To test the functionalities of the prototype, extra software was
needed:
• A BitTorrent Tracker installed at an exposed server with domain smooth.inov.pt. This Tracker was
built using the same BitTorrent engine module of the Player prototype;
• Several seeding Peers were installed at different locations using the well known BitTorrent applications uTorrent, just for testing purposes;
• An encoding server, in order to capture live images from a webcam and provide base-layer content
for Live streaming testing.
4.4
Graphical User Interface
For the GUI, a windows form type was developed. The implementation build was targeted to a
desktop application, as it would be much easier to implement and debug. As described in the previous chapter, this module is easily reusable and customizable for other target environments. Another
approach would be the integration of the prototype code as a browser plug-in, with social networking
services support. However, most of the development time was consumed targeting a desktop application
but minding the applicability of the code to a browser plug-in.
4.4.1
Desktop Application
Figure 4.2 is a snapshot of the application User Interface in a real-time usage. At the top of the figure,
in the first panel, the user may open a SVC content, or start streaming a new Torrent using the “File”
menu to fetch the ‘corresponding ‘.torrent” file normally stored in an accessible web server and pointed
by an URL. At video playback, the user may also customize other controls using the “Video” menu,
where options such as Zoom, Brightness, Contrast, Gamma, Hue and Saturation may be manually
configured.
43
Figure 4.2: Desktop Application Graphical User Interface
The second panel of the GUI (Video Renderer) is where the video output of the Media Player Module
is rendered. The third panel (Video Controls) offers the ability to pause, play and stop a video streaming.
The green bar may be used to jump (video seeking) to a different video time available (in the case of a
VoD scenario. In Live operation, it is possible to seek only previous timestamps of the current timeline.
For debug and testing purposes, the fourth panel offers various groups of control items and information display (e.g., P2P Info/Control Module):
• Layer Control – To limit in the BitTorrent engine the maximum number of Layers to request for a
Chunk being downloaded;
• Layer Info – Provides information on the Chunk being played and of its composition in terms
of number of Layers assembled, the Chunck being downloaded and the respective number of
associated Layers as well as the average and peak bitrate of the BitTorrent downloading process;
• P2P Control – The user may limit the download/upload rate used by the BitTorrent engine;
• P2P Info – Provides information on the BitTorrent engine, such as the current download/upload
rate, and number of peers for the current video streaming session.
44
4.5
Media Player Module
The Media Player module is responsible for launching the Scalable Video Decoder module, and the
Feed Manager for its control. The Media Player module will only need, as input, the handle (memory
pointer) of a drawable surface (i.e., panel) to inform the video decoder of the location to output the
rendered video, which may be in a Windows Form application or within a Browser Active X or NPAPI
plug-in. After receiving this information, the decoder module is launched (as a background process) and
the feed manager controls all input/output to the decoder.
4.5.1
Scalable Video Decoder Module
As for the Scalable Video Decoder module, the available options were very limited on the two opensource frameworks available: the AceSVC [49], a non-public project, and the OpenSVC [50], a public
Source-Forge project.
The OpenSVC Decoder aims to provide a real-time coding framework for Scalable Video Coding (SVC) extension of H.264/AVC. This project is an AVC/SVC library of decoding tools created at
the Institut d’Electronique et des Telecommunications de Rennes (IETR)/Institut National des Sciences
Appliquees de Rennes (INSA) of Rennes. It provides two decoder tools: MPlayer [51] and TCPMP [52].
TCPMP is not fully stable nor SVC compatible,therefore immediately excluded.
The MPlayer is a free and open source media player. The program is available for all major operating
systems, including Linux and other Unix-like systems, Mac OS X and Microsoft Windows. Versions for
OS/2, Syllable, AmigaOS and MorphOS are also available. It plays most of the known video formats,
like MPEG/VOB, AVI, Ogg/OGM, VIVO, ASF/WMA/WMV, QT/MOV/MP4, RealMedia, Matroska, NUT,
NuppelVideo, FLI, YUV4MPEG, FILM, RoQ and PVA files, and is supported by many native, XAnim,
and Win32 DLL codecs. It is also capable of playing contents from VideoCD, SVCD, DVD, 3ivx, DivX
3/4/5, WMV and H.264 movies. The version of MPlayer used is in this project is the MPlayer SVN-r1874.2.4.
4.5.2
Feed Manager
Figure 4.3 illustrates the state flow diagram of the Feed Manager module. After the launch of the SVC
Decoder module the Feed Manager is informed to read the video data from a local file (e.g., xxx.264),
and then enters Pause mode. No reading task from the file is done yet at this point.
The Feed Manager starts up by creating the file in order to control all video Chunk writings. During
the operation the Feed Manager asks the Download Manager for its current state and if it is in Buffering
mode, it loops out until Buffering mode is changed, meaning that the Buffer Manager already possesses
Chunks to be requested.
45
Figure 4.3: Feed Manager State diagram
When this mode starts, the Feed Manager will periodically sleep for 2 seconds (duration of a video
Chunk) and request a new buffered Chunk from the Buffer Manager. If a new Chunk is retrieved it
will be appended in-order to the feed file, ready for the decoding process by the Decoder module and
subsequent play-out. If no Chunk is retrieved, the SVC decoder is paused and the Feed Manager,
returns to its previous loop state, asking the Download Manager for its current state.
The Feed Manager is disposed whenever the Download Manager is stopped.
4.6
Chunk Manager Module
The Chunk Manager is responsible for coordinating all Chunk downloading, buffering and scheduling.
Its main module is the Download Manager, which interacts with a Buffer Manager. This module works
as an interface between the media player and the BitTorrent networking tasks.
4.6.1
Download Manager
Figure 4.4 illustrates the state flow diagram of the Download Manager module. This module receives
as input the URL of the Torrent file (.torrent) available for streaming. The file is downloaded to the
end-user terminal local storage using Hypertext Transfer Protocol (HTTP) Protocol.
The Torrent file is then parsed, in order to obtain the number of Chunks and Layers that compose the
source video content.
The Media Player module and the BitTorrent engine are then launched and may start their tasks.
At an initial phase, the Download Manager enters a Buffering state, and so it orders to the BitTorrent
engine (launching the PiecePicking sub-module) the files needed for buffering. The Buffering state has
46
a 3 Chunk (6 seconds) download scheme.
Figure 4.4: Download Manager State
When Buffering is complete, and files are fully downloaded, these are then passed to the Buffer
Manager, and the state is updated to Downloading.
The Downloading state process consists in the sliding of a window of priority download in the Piece
Picking Module, triggering the special piece picking algorithm (fully detailed in Section 4.7.3). The
manager waits for 1.5 seconds, to check the number of layers of the current Chunk that were successfully
downloaded. At least the base layer should have been downloaded, but if not, it waits until this critical
layer is downloaded. If in this process the BitTorrent engine is caught at the middle of a transfer of
an enhancement layer then no problem exists, since the previous hierarchic layer was successfully
downloaded.
This state ends when no more Chunks are available to download, transiting to the Ready state, that
47
will wait for the Media Player disposal.
4.6.2
Buffer Manager
The Buffer Manager maintains a very simple First In, First-Out (FIFO) buffer in order to add data
Chunks. This FIFO buffer was limited to a capacity of 10 Chunks.
Whenever a module wants to add a new Chunk, it must pass a list of the layer descriptors and
respective file names, in order for the SVC File Assembler to reconstruct the Chunk data. If a request
for a chunk is made to this module, it will assemble the Chunk by reading data from the first list of file
descriptors in the Buffer queue, and therefore the final chunk is delivered.
4.6.3
SVC File Assembler
As described in the previous chapter, the SVC File Assembler is used to assemble a variable number
of transmission Layer files into the corresponding single video Chunk. The SeqNum field is used to
restore the data order being withdrawn afterwards from the received NALs.
The pseudo-code for the process used in the the SVC File Assembler is presented in Algorithm 4.1.
Algorithm 4.1 Scalable Video Coding File Assembler
f inalChunk = newMemoryStream();
nalsList = newEmptyList();
layerData = byte[numlayers];
for i = 0 to numlayers do
layerData[i] = readfile(f ileStreams[i])
end for
for i = 0 to numlayers do
nalsList.insert(GetH264LayerNALUnits(layerData[i]));
end for
nalsList.Sort(bySeqN um);
for element = 0 to nalsList.Count do
WriteToMemoryStream(nalsList[element]);
end for
return f inalChunk.toByteVector();
The algorithm starts by reading from each Layer file, the respective content into byte vectors. Each
of these vectors are parsed using a function called GetH264LayerNALUnits, which will get a set of
elements, where each element contains information about the start index and offset of each NAL unit,
48
and its associated SeqNum. After this list is correctly filled by all layer data vectors, the list is sorted out
by its sequence number.
Finally, the sorted list is used in order to output the data in a correct order into the final vector Chunk
data.
4.6.4
Time Controller
The Time Controller launches two types of asynchronous events in order to execute operations within
the CPU Load Adaptor and Screen Size Adaptor:
• At every second it signals the CPU Load Adaptor to obtain the CPU Load and compute an average
value.
• It signals the Screen Size Adaptor in order to communicate with the video render window for its
resolution review.
4.6.5
CPU Load Adaptor
As the SVC Decoder is not a light process, the decoder may have difficulties in decoding Chunks with
high number of enhancement Layers, namely in the case of terminals with low computational capabilities.
Therefore, it is of surmount need the monitoring of the CPU load of the decoding process.
For that purpose an event is triggered every 1 second to measure an average value of the CPU load,
in order to be adequately robust in reactions against CPU load peeks.
Therefore, as soon as the PSW algorithm run achieves 25% of CPU load, the maximum Layer level
to download is limited to a lower level but and if the CPU load lowers by at least 5%, it tries to increment
the Layers levels to achieve a stable balance.
A preliminary test of the module in different terminal setups, with high and low computational power,
was used to measure the average CPU load of the process in order to tune the most appropriate thresholds in the algorithm. Section 5.4.3 of the Evaluations Tests describes the measurements with detail.
4.6.6
Screen Size Adaptor
The Screen Size is an important metric for the downloading scheme as it helps on adapting the
spacial scalability of the SVC content (levels of Layers) being played-out to the viewing window, and
therefore, the corresponding adaptation of network traffic requirements (reducing it by requesting less
Layer levels in the case for small screen sizes).
Normally, two screen sizes are used in video encodings as presented in Table 4.1.
49
Table 4.1: Video resolutions for SVC content
Format
Resolution
Number Layers
DCIF
528 × 384
10
CIF
352 × 288
5
The information about the video resolution of a certain content is obtained after the Player has successfully downloaded and parsed the Torrent file. In Appendix B.1 the information exchanged between
the client and the HTTP server Tracker is described in detail.
Whenever the screen size ratio comes below any of the resolutions described in Table 4.1, the
number of enhancement Layers is automatically adjusted accordingly to the rules presented in that
table.
4.7
The BitTorrent engine
The BitTorrent protocol was implemented using the cross-platform library MonoTorrent [53], an opensource under the MIT/X11 licensing scheme library, due to the rich set of features it contains, that can
be summarized as:
• Cross-Platform: Supports Linux/Unix, Windows and Mac OS X;
• Development-Friendly: C# Programming Language;
• Supported Features: Super-seeding, Tracker, UpnP, NAT Port Mapping Protocol, DHT, Peer Exchange, Encryption, User Datagram Protocol (UDP) Tracker, Local Peer Discovery, Fast Extensions, Magnet URI, Cache, Web Seeding and Selective Downloading.
In further sections, the Client Engine and Torrent Manager are described in detail, as well as their
sub-modules presented in Chapter 3.5.2.
4.7.1
Client Engine
When the Client Engine module starts, it starts up all the sub-modules, as represented in Figure 3.11,
as well as the MainLoop thread. In this manner all information about the engine is available to the
Torrent Manager. The MainLoop thread consists of a FIFO queue and runs non-blocking asynchronous
delegated tasks from the sub-modules in either Torrent Manager or Client Engine.
50
The Buffer Manager controls the allocation and de-allocation of all data buffers used in the engine
whenever a buffer is need to receive/send data on a socket, or to read/write pieces from the Disk Manager.
The Disk Manager computes the hash of the pieces and controls the writes/read in the local storage.
This module also contains a MainLoop thread in order to synchronize the writing/reading of the same
pieces in the disk. The same FIFO queue strategy is used as in the Client Engine. The Piece Writer is
used in order to read/write the pieces data to files or to memory.
The Listen Manager listens for incoming connections and passes them to the correct Torrent Manager.
The Local Peer Manager listens for incoming information on a multicast channel, for new local Peers
that have recently joined the network, and passes the peer information to the correct Torrent Manager.
It also performs periodically a broadcast to inform others of its presence in the network.
The Connection Manager is the main controller for all incoming and outgoing connections. It handles
all new and pending connections and controls events such as Peer handshaking and Peer messaging
I/O. The Connection Listeners are used in order to distinguish between Peer Connections (Transmission
Control Protocol (TCP) Connection) and Local Discovery Connections (UDP connections).
4.7.2
Torrent Manager
To initiate a new Torrent, a new manager is launched. This Torrent Manager module will coordinate
all the operations associated with the new Torrent such as Peer discovery, Tracker announcements, and
piece transfers. All tasks that may have blocking calls (e.g., handshake start) are turned into asynchronous calls and are queued at the MainLoop thread of the Client Engine.
When the Torrent Manager starts, all sub-modules in Figure 3.11 associated to it are also initiated.
The Torrent Manager works through a series of modes in ordered manner:
• Hashing Mode - Consists in verifying the integrity of any data that is present on disk.
• Downloading Mode - Starts by announcing the Client on the Tracker server and retrieve as response the Peer information on the network. After successful connection to Peers the processes
will be initiated by the adequate sub-modules.
• Seeding Mode - Requires that the connection listener in the Client Engine are active in order to
upload piece data to new Peers in the network.
• Pause Mode – Stops the current Torrent Manager.
The Peer Exchange Manager is used to send at each minute a peer exchange message to those
Peers that have this protocol enabled.
51
The Connection Monitor is used to track upload/download speed and bytes uploaded/downloaded in
each connection.
The Inactive Peer Manager monitors periodically the Peers that have became inactive, giving order to
disconnect them, and if the maximum peer connection limit hasn’t been reached, it initiates connection
to a new available Peer.
The Peer Manager simply makes track of all the Peers in the network and categorizes them as:
Active Peers, Available Peers, Banned Peers and Busy Peers.
The Tracker Manager represents the connections to a Tracker (known by the Torrent Manager).
The Choke-Unchoke Manager decides which Peers to choke/unchoke based on reviews of the Peers
and of Interest messages on the network.
The Piece Manager contains the logic for determining the next pieces to download. Piece picking
algorithms are used to determine which pieces to request from each peer connection.
To understand the Downloading Mode and the interaction of these modules with the Torrent Manager
let’s take the example of starting the download of some pieces from a Peer.
Figure 4.5, represents the way used by each sub module to add tasks to the MainLoop, and how
asynchronous callbacks are processed. The tasking strategy for the rest of the modules is similar.
Figure 4.5: Tasking Process Flow
52
4.7.3
Piece Picking Module
This section describes all the algorithms used by the Piece Picking module. All the standard BitTorrent algorithms are described, in order to understand its normal operation. However, only a subset of
those algorithms will be used together with the novel adaptive algorithm developed in this work, specifically designed to provide SVC video content streaming over P2P.
All Piece Picking algorithms are called by passing some parameters as inputs:
• PeerID – Contains the endpoint of the other Peer (for the requests);
• PeerBitField – A binary representation of the pieces that the serving Peer has available;
• OtherPeers – A list containing information on other Peers in the swarm;
• Count – The number of pieces to request;
• Start and End Indexes – Defines the range (i.e., [0, EndIndex]) from which the piece picker will
choose the piece(s) to request.
For any Piece Picker in the stack, as represented in Figure 3.12, whenever a Piece Picker above it is
called, the mentioned parameters are passed.
4.7.3.A
Standard Picker
The Standard Picker maintains a list containing the information of all the current piece requests. Each
request made to the serving Peer, is a request for a block, with size 16 KB. This means that a piece can
be contained within one or more blocks, i.e., for piece sizes of 64 KB, one piece would be decomposed
in four blocks and four requests are therefore necessary to complete the transfer of one piece.
The Standard Picker algorithm SDL diagram is depicted in Figure 4.6.
The execution steps consist in the following:
1. If there is already a request on this Peer, try to request the next block. If the Peer is chocking us,
then the only requests that could be continued would be existing “Fast” pieces.
2. Check if there is any allowed “Fast” piece to download
3. If the Peer is choking, then we can’t download from them as they have no “Fast” pieces for us to
download
4. If we are only requesting one piece, then we can continue with any that exists. Otherwise we
should try to request the full amount first, then try to continue with any that exists.
5. Check if the Peer has suggested any pieces we should request.
53
Figure 4.6: SDL diagram of the Standard Piece Picker algorithm
6. See what pieces the Peer has that we don’t have and try and request one.
7. If all else fails, ignore how many pieces we are requesting and try to continue with any that exists.
4.7.3.B
Randomized Picker
The Randomized Picker algorithm SDL diagram is depicted in Figure 4.7.
The execution steps consist in the following:
1. If the PeerBitField has all values set to FALSE, return NULL.
2. If we are requesting only one piece, then call the picker above in the piece picker stack (in this
case, the Standard Picker).
54
Figure 4.7: SDL diagram of the Randomized Piece Picker algorithm
3. Choose random integer in the range [StartIndex, EndIndex].
4. Call the picker above in the piece picker stack with range [MidPointIndex, EndIndex].
5. If returned false, call the picker above in the piece picker stack with range [StartIndex, MidPointIndex].
4.7.3.C
Rarest First Picker
The Rarest First Picker maintains a stack of bitfields. On the top of the stack will reside the bitfield
containing information about the rarest pieces in the network, computed with n Peers. The next element
in the stack is the bit field with the rarest pieces in the network, computed with n − 1 Peers. The bottom
bitfield of the stack is the original bitfield before the rarest first computation. Therefore, the stack will be
constructed as a growing order of rarest first pieces directly proportional to the number of Peers in the
network.
The Rarest First Picker algorithm SDL diagram is depicted in Figure 4.8.
The execution steps consist in the following:
1. If the PeerBitField has all values set to FALSE, return NULL.
55
Figure 4.8: SDL diagram of the Rarest First Piece Picker algorithm
2. If we are requesting only one piece, then call the picker above in the piece picker stack (in this
case, the Randomized Picker).
3. Construct the stack of bitfields, computing the rarest first pieces on the top of the stack.
4. Pop the stack, and try to get a non empty message from the Randomized Picker.
5. Repeat the step while the bitfield stack is not empty.
4.7.3.D
Custom Piece Picker
The main and most difficult task to overcome is the limitations of the standard BiTorrent piece picking
policy. The SVC video streaming added a need to figure out a piece picking solution that would manage
to download the data in a ordered fashion and supporting the skipping functionality as described in
Chapter 3.3.2.
Figure 3.12 illustrates the piece picking policy of the standard BitTorrent engine. Such stack of piece
picking algorithms can be easily re-used and adapted in order to produce a Custom Piece Picker.
Figure 4.9 illustrates the new stack representation of the various Piece Picking algorithms used in
the modified BitTorrent engine of this project.
56
Figure 4.9: Stack representation of the custom Piece Picking set of algorithms
The Standard Picker algorithm works as the base piece picker, monitoring and managing all requests
for each block, in each piece and all Peers. This picker is essential for the piece picking policy to work,
since it is the one that will in fact construct the request messages based on the information from lower
stack piece picker algorithms will provide.
The Randomized Picker algorithm is inappropriate for the orderly picking as it randomly selects a
piece in a range of piece indexes, violating the need to request pieces in order.
The Rarest First algorithm is advantageous since it may increase the availability of a certain piece in
the P2P network. This algorithm will only be useful when a Chunk Layer file is distributed in more than
one piece.
At the bottom of the stack is the new Custom Piece Picker algorithm, quite similar to the Priority
Picker. The major differences between these pickers are:
• the Custom Picker isn’t controlled by the main queue pipeline, so delayed orders are eliminated;
• the Custom Picker may skip to further piece requests automatically.
4.7.3.E
Prioritized Sliding Window (PSW) Piece Picker Algorithm
The PSW Piece Picker algorithm holds the information of the files that are contained in the Torrent.
In this way it knows how to find the starting and ending piece indexes of each file.
The chosen piece size was of 16 KB (the same size of a block), since the base layers of all video
Chunks have approximately that size, and the overhead in transmission is small. In [54] it is proven that
maintaining high efficiency and availability in a P2P network requires the use of small fragment sizes.
Before starting the operation files are marked with different priorities, according to the Layer they
belong to, starting with highest priority for Layer 0 and decreasing the priority as the layer index increases. The layers that are not to be downloaded (e.g., due to bandwidth restrictions) are marked
“DoNotDownload”, as shown in the example of Table 4.2.
57
Table 4.2: Priority layer definitions
Priority
Value
Chunk i -Layer 0
Immediate (64)
Chunk i -Layer 1
Highest (32)
Chunk i -Layer 2
High (16)
Chunk i -Layer 3
Normal (8)
Chunk i -Layer 4
Low (4)
Chunk i -Layer 5
Lower (2)
Chunk i -Layer 6
Lowest (1)
Chunk i -Layer 7
DoNotDownload
It is assumed that the initial and last pieces of each file (Chunk/Layer) is known, this way it knows
how to find the starting and ending piece indexes of each file.
The PSW algorithm bases its strategy on the download of a number of Chunks (typically 3), starting
with Chunk1 and progressing to susequent Chunks until the end of file is reached or, without limit if in a
live stream mode. The change of the sliding window is synchronous and takes place every 2 seconds
(the assumed duration of each video Chunk).
The algorithm starts by defining the startindex = 0, the endindex is the last piece of the highest
allowed layer of third Chunk. Considering the defined priorities, this means that the pieces will be
downloaded in the corrrect order Figure 4.10 exemplifies the process for a 4 Layers condition.
Figure 4.10: Adaptive PSW Priority Definition
After two seconds, the sliding window moves one step, meaning that the files that are now allowed
58
to be downloaded are the ones from the second to the fourth Chunk.The sliding window is important
because it allows to download Chunks/Layers that have not been downloaded in the previous time-slot,
increasing the reliability of the algorithm.
Each time the window slides within the piece picker, it reviews the last higher level downloaded Layer
from the previous Chunk, and adjusts the next set of priorities for the next Chunk.
For example, if for the previous Chunk only 2 Layers were successfully downloaded, then no criteria
will define the next set of priorities for all remaining Layer levels, meaning that there was not enough
bandwidth to perform the downloads of higher level Layers. The algorithm should however increment
the number of priorities if for the previous Chunk, the defined Layer level limit was reached.
This strategy proves to work well when download rates decrease/increase suddenly.
4.7.3.F
Local Peer Piece Picker Algorithm
The BitTorrent engine will randomly select Peers in the network to request the pieces it needs. However, a special criterion should be added if in the range of pieces to pick some are available in a closely
located Peer (such as in the same local network, or same ISP).
All other pieces that aren’t locally available should be downloaded from Peers that are typically in
different networks.
The Local Peer Picker algorithm SDL diagram is depicted in Figure 4.11.
The execution steps consist in the following:
1. If the PeerBitField has all values set to FALSE, return NULL.
2. Check if the Peer we are requesting is a local Peer. We compare this Peer IPv4 address with
our local Internet Protocol (IP) address, and Public IP address using an external server. The
comparison is made using the first two field bytes of the IPv4 address.
3. Let’s generate a BitField vector were we will have all pieces that all local Peers have at the current
moment, using a bitwise operation AND with the pieces we are trying to request.
4. We execute operation XOR of the non-local PeerBitField with the BitField with all needed pieces
that local Peers have. In this way we will be able to request pieces that local peers don’t have from
non-local Peers.
5. POP the stack, and try to get a non empty message from the Rarest First Picker.
4.7.4
Choke-Unchoke Manager and Incentives Strategy
Periodically, the BitTorrent Engine executes a check to better manage its upload slots to Peers in the
network. The Choke-Unchoke Manager maintains all choking information related to this process and
59
Figure 4.11: SDL diagram of the Local Peer Piece Picker algorithm
executes a review for each Peer.
The Choke-Unchoke Manager is used together with an Incentives Strategy to provide a good equilibrium in the pieces transfer processes, helping to eliminate Free-Riders in the network.
The very well known Incentive Strategy used is called Tit-for-Tat [27] and is described in Section 4.7.5.
4.7.5
Tit-for-Tat Incentives Strategy
The Tit-for-Tat strategy uses the information on a requesting Peer, and based on its uploaded amount
of data, the serving Peer will upload more data to the client Peer. By this strategy, the requesting Peer will
achieve more downloading rate, if it contributes as well to the network. This strategy has demonstrated to
work well even for clients with an asymmetric connection such as ADSL, where the download bandwidth
is much higher than the upload bandwidth.
Although other strategies have been researched in this area (like the Give-to-Get strategy) showing
a resilient way of eliminating Free-Riders in the system their implementation is not trivial, therefore not
60
considered in the scope of work for this thesis.
To better understand the Tit-for-Tat strategy deployed in the MonoTorrent library used, lets analyze
carefully each of its steps for choosing Choked and Unchoked Peers. The BitTorrent engine triggers a
Choke-Unchoke Manager task event at every 30 seconds. It is in this event that each connected Peer is
either defined as Unchoked or Choked.
The pseudo-code for the process used is presented in Algorithm 4.2.
Algorithm 4.2 Tit-for-Tat Upload Policy
candidatePeers.Clear();
optimisticUnchokeCandidates.Clear();
for all connected.P eers do
if !connectedP eer.IsSeeder then
bytesT ransf erred
=
connectedP eer.M onitor.DataBytesDownloaded
-
connectedP eer.BytesDownloadedAtLastReview;
if connectedP eer.U nchoked and bytesT ransf erred > 0 then
candidatePeers.Add(connectedP eer);
connectedP eer.LastReviewU ploadRate
=
(connectedP eer.M onitor.DataBytesU ploaded
-
connectedP eer.BytesU ploadedAtLastReview) / timeSinceLastReview;
connectedP eer.LastReviewDownloadRate = (connectedP eer.M onitor.DataBytesDownloaded
- connectedP eer.BytesDownloadedAtLastReview) / timeSinceLastReview;
else if connectedP eer.IsInterested then
optimisticUnchokeCandidates.Add(connectedP eer);
end if
end if
end for
candidatePeers.Sort();
optimisticUnchokeCandidates.Sort();
ReallocateSlots(owningT orrent.Settings.U ploadSlots − 1, unchokedP eers);
Unchoke(optimisticUnchokeCandidates.GetOUPeer());
Choke(candidatePeer.MorePeer());
Choke(optimisticUnchokeCandidates.MorePeer());
The algorithm starts up by creating two lists: the candidate Peers for upload slots and the optimistic
Unchoke candidates for an upload slots. The BitTorrent engine has a limited number of upload connec61
tions, and, as such, the candidate Peers will all be Peers trying to request pieces. But only the best
serving Peers will have allocated upload slots, hence the Unchoke state for them. At every review a
random Peer is selected, giving a second chance for it to prove that it can contribute to the network.
For each connected peer (except for seeders), their last downloaded data is counted. If they have
been Unchoked and have downloaded data, they are candidates for a reallocation, unless they prove to
be good uploaders. A peer that shows interest is a candidate for optimistic allocation.
After these lists are fully created, they are sorted out by those Peers that demonstrate to be contributing to the network (by uploaded data since the last review). The same is done randomly to the optimistic
Unchoked candidates, since they haven’t been rated.
The upload slots are then reallocated to the best candidates, set therefore to Unchoked. A random
optimistic candidate is chosen for the only free slot.
The remaining Peers in the lists are all choked.
This strategy does really incentive uploading in the network, contributing to a lesser burden on the
serving Peers. If these incentives were not taken into account, most of the Peers would always request
pieces from only the server Peer, and not from other Peers.
However, there exists some security issues regarding the announcement of the requesting Peer
upload rates. This information is not authenticated and its integrity is not verified (security analysis was
out of the scope of the work in this thesis). But for a production solution they have to be taken into
consideration.
4.8
Live Streaming Support
The implementation described in this chapter is related to VoD mode. But the same implementation
is used for Live Streaming mode with a different performance since it is limited by the Torrent space
definition (as piece hashes cannot be verified, since the content pieces are unknown).
When the Torrent is generated, it is created with dummy data and with a limited number of Chunks,
since its content is dynamic and each Layer file must also have a pre-defined size. The Layer file
structure is as illustrated in Figure 4.12.
Figure 4.12: Layer file structure for Live Streaming mode
After the Client requests the video manifest (index) from the HTTP server (details in Appendix B.1), it
is parsed as a Live feed, and the Download Manager defines the starting Chunk as the one obtained from
62
the Manifest file that includes the Chunk end and video sizes. The Download Manager and BitTorrent
engine will then skip hashing and enter in Live mode, seeks to the Live Chunk and sets the PSW
algorithm to a maximum window of 2 Chunks to reduce delays and maintain a smaller buffer. Before
the Buffer Manager consumes de data in the file it must parse its content according to the structure
described in Figure 4.12.
4.9
Summary
The implementation of the SVC P2P Player prototype was presented in this chapter. All the development process were detailed, from the requirements phase to the validation phase.
All modules and sub-modules were described in detail, as well as all modifications done to the
BitTorrent engine used.
A novel network bitrate adaptation algorithm designed for the Piece Picking policy of the BitTorrent
engine was also described, together with the algorithms used to create the main functionalities of the
solution.
63
64
5
Evaluation Tests
Contents
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.2 Evaluation Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.3 Experimental Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.4 Evaluation Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
65
5.1
Introduction
This chapter describes the evaluation process of the P2P SVC Player prototype. The evaluation
objectives, experimental scenarios and metrics used are detailed, followed by an explanation of the
evaluation tests. The test results are then described, and conclusions on the implementation are also
drawn.
5.2
Evaluation Objectives
The goals of the evaluation process are to assess the prototype behavior in heterogeneous access
networks, evaluate the scalability of the solution and the functionalities it provides.
The tests applied to the prototype are separated into four sets that evaluate the various features:
• Heterogeneous Network Behavior
• Live Performance
• Terminal Capabilities
• Scalability, Incentives and Performance
These tests evaluate all functional and non-functional requirements of the prototype. As the solution
consists on a prototype, security analysis was not included on these sets of tests.
5.3
Experimental Scenarios
Two different experimental scenarios were used in order to study the solution results from different
network characteristics (e.g., bandwidth, delay). The first scenario covers almost all functional requirements. The purpose of the second scenario is to evaluate the scalability and upload incentive properties.
The first scenario considers three different access networks (Figure 5.1):
• Campus High-Speed LAN
• Campus High-Speed WLAN
• 3G/UMTS Network
The Tracker and super-seeder are located for both scenarios in a Web server placed in a controlled
network environment, at an University campus premises, providing services to an internal high-speed
100 Mbps LAN, a Wireless LAN (802.11g) and to the Internet. This Web server is based on Microsoft’s
Internet Information Services (IIS) 7.0 [55].
66
Figure 5.1: Local Test scenario
The functional test set included:
• Heterogeneous Network Behavior
• Live Performance
• Terminal Capabilities
The end user device for the tests possessed an Intel Core2Duo 2.26 GHz CPU, with 3 GB DDR2 of
RAM, running Windows 7 operating system.
The second scenario consists in using a set of Peers launched as various computer instances using
Amazons Elastic Compute Cloud system [56]. Each set of Peers was distributed in four world regions:
US East(Virginia), US West (N. California), EU West (Ireland) and Asia(Singapore). Each regions covers
4 Peers, making a total network of 12 active Peers.
Remote functionalities were inserted into the prototype code in order to control the start/stop of the
streaming process. This group of Peers has a very well designed timeline start mark for each Peer. In
this manner, the tests could be performed exactly in the same manner. This test evaluated the prototype
scalability, upload incentives and overall performance. The Peer instances corresponded to computers
67
with Intel Xeon 2.6 GHz CPU, 2 GB DDR3 of RAM, running Windows Server 2008 Datacenter Edition,
with 5 Mbps symmetric internet connections.
5.4
Evaluation Results
The purpose of the tests was to infer the behavior of the SVC P2P Player client under different
access networks, asses the bitrate variations during the timeline of the test, the video delay and the
bitrate adaptation due to variations in network conditions.
The main objective is to demonstrate that the PSW algorithm outperforms the standard piece picking
policies of BitTorrent for video Streaming. The results were plotted in graphs comparing the three distinct
piece picking policies: PSW, the Original BitTorrent Policy and the Sequential Policy.
The Original BitTorrent Policy requests pieces using a chain of Random and Rarest-First piece picking policies as explained in Chapter 4.7.3. The Sequential policy simply requests pieces in order without
any wait time.
For consistency of the evaluation process, the tests were performed using always the same movie
with a duration of 250 seconds, encoded using 10 transmission Layers, with Double Common Intermediate Format (DCIF) and CIF resolutions, and frame rates between 1.875 fps and 30 fps) and the player
placed in VoD mode.
5.4.1
Heterogeneous Network Behaviour
In the case of WLAN and 3G, the SVC P2P Player client reached the server via the Internet. In
Figure 5.2, Figure 5.3 and Figure 5.4 the playback rates measured in LAN, WLAN and 3G scenarios,
respectively, are traced.
In all the graphs it can be observed that the Original BitTorrent policy achieves the highest start delay
(nearly 20 seconds). In Figure 5.2, the PSW policy has the lowest start delay, but is also the slowest to
obtain, at initial phase, the best movie quality. This is due to the incremental number of Layers that the
PSW algorithm orders.
In Figure 5.3 for a 3G WLAN with permanent variable network conditions, it can be observed that the
PSW algorithm achieves a higher playback rate than the Sequential policy.
Figure 5.4 clearly demonstrates that the PSW algorithm outperforms all other policies, maintaining a
stable stream without buffering at all time. The other policies buffer most of the time and achieve very
low stream bitrates.
In Figure 5.5, it can be observed that the Sequential and Original BitTorrent policies obtain high
download rates (approximately 1.6 Mbps). This situation may be regarded as a disadvantage because
68
Figure 5.2: Playback Rate on LAN
Figure 5.3: Playback Rate on WLAN
69
Figure 5.4: Playback Rate on 3G
these policies are throttling the network and obtaining approximately the same playback rate as the PSW
algorithm, consuming more buffer, disk space and escaping the category of a streaming application.
The same occurs in Figure 5.6 and Figure 5.7.
Figure 5.5: Distribution of the Download Rate in a LAN
The worst case is represented in Figure 5.7 where the PSW obtains the lowest download rates
(average 500 Kbps) and is the one with best behavior, since it maintains a fluid playback without stops
(Figure 5.4 ).
Figure 5.8, Figure 5.9 and Figure 5.10 plot (in percentage) the received Chunk Layer ratio for LAN,
WLAN and 3G respectively. Due to the optimal network conditions on a LAN scenario, the Sequential
policy performs better at an initial phase than the PSW algorithm, achieving rapidly the best video quality
70
Figure 5.6: Distribution of the Download Rate in a WLAN
Figure 5.7: Distribution of the Download Rate on 3G
71
Figure 5.8: Received Chunk-Layer Ratio on LAN
and receiving all transmission Layers (Figure 5.8 ).
Figure 5.9: Received Chunk-Layer Ratio on WLAN
When applying the same conditions for the test on a WLAN scenario, the network conditions vary
constantly (Figure 5.9 ). In this case it can be observed that the PSW algorithm achieves a more stable
and seamless video stream than the Sequential policy (with deep rises and falls all the time).
In Figure 5.10 the same conclusions, as for the results observed in Figure 5.4 can be taken: the
PSW clearly outperforms the other download policies since it achieves higher levels of received Chunk
Layers, and a continous stream.
72
Figure 5.10: Received Chunk-Layer Ratio on 3G
5.4.2
Live Performance
In order to test the Live Streaming support both the Tracker and the Super-Seeder were equipped
with a web camera, supporting HTTP, to capture video frames. These frames were assembled by
ffmpeg [57] and produced H.264/AVC Chunks of 2 seconds duration. Since freely available softwarebased Live encoders for H.264/SVC are in the order of 50 times slower than H.264/AVC encoders, this
solution seemed to be most adequate for the tests. The Live content was created with a limited space
of 5 minutes of video timespan for streaming purposes. Each video Chunk file had a constant size of
96 KB, and the first 2 bytes of the file indicate the original file size. The overhead introduced was about
5 KB to10 KB per file, transferred as “garbage” data.
Live Streaming performance was tested on the LAN scenario in order to evaluate real-time playback
delay. In Figure 5.11 the playback values for real-time capture is plotted as a Cumulative Distribution
Function (CDF).
Delays observed were between 8 and 13 seconds, with more than 50% of probability to fall between
the 10 and 13 seconds time window.
5.4.3
Terminal Capabilities
Two simple tests were performed in order to demonstrate the terminal capabilities module advantages. In Figure 5.12 the Chunk Layer ratio variation along time is plotted, and it can be observed at
timestamp 1:05 minutes that the play-out window was resized to approximately a thumbnail size.
The Chunk Layer ratio decreased to a download/render of the number of Layers of 50%, i.e., half
the maximum number of layers. This is due to the spatial scalability feature of SVC. The video used for
73
Figure 5.11: Distribution of the Live Playback Delay from Real-Time Capture
testing has the first five Layers with a CIF resolution and the other five Layers with a DCIF resolution.
After some time the play-out window was resized to the previous normal size, and the PSW repeats the
incremental process to raise the stream to the optimal play-out quality.
Figure 5.12: Chunk Layer Ratio on LAN with Screen Resize
The prototype was tested in various computer hardware setups: some real fast, some slow. It was
noticed that the decoder process (of the MPlayer) was quite heavy for a single-core processor. For
the dual core processor terminal used in the tests the CPU load due to the decoder reached, with a
maximum Layer decoding, an average of 24%.
For comparison, the same application tested on a less powered computer, with just an Intel Pentium
III 750 MHz, 512 MB of memory Random-Access Memory (RAM) and running Windows XP operating
74
Figure 5.13: Chunk Layer Ratio on LAN with CPU Load
system reached, at low number of Layers, the same CPU load as on a dual-core computer, and the
video rendering was fluid. When all Layers were downloaded, the player went off to a very slow state
of rendering, harming the performance of the player and of other running processes, as the decoder
had already occupied more than 50% of CPU load. When applying the Terminal Capabilities module, as
soon as the PSW algorithm achieves 25% of CPU load, the maximum Layer download is then limited,
and if CPU load lowers at least 5%, it tries to increment the number of Layers and stabilize.
In Figure 5.13 the video Chunk Layer Ratio with the CPU Load heuristic is plotted. It can observed
that as soon as the player reaches 50% of the Layers (resolution at CIF), the CPU Load stays around
25% and no more Layers are downloaded. As soon as the player lowers its CPU Load it tries to increment the number of Layers. Several increments were tried until reaching 60% of Layers (DCIF resolution
of video) but they lasted for a very short time, as the CPU load threshold adaptation was fired immediately.
Therefore, the CPU load heuristic is a very useful module in order to maintain fluid video stream and
performance on any terminal setup.
5.4.4
Scalability, Incentives and Performance
The prototype was also tested for a group of Peers distributed geographically, using the PSW algorithm to evaluate the behavior of the piece downloading policy. For this test the Amazon Elastic Compute
Cloud Web Service was used, running 12 instances of terminals distributed into 4 regions (see description of scenario 2 in section 5.3).
The same test suite, as in [58] (tested with a non BitTorrent application) were applied: Test with no
75
Free-Riders in the network and Test with 15% of the peers being Free-Riders. The effect of the Tit-forTat strategy was then compared in order to prove that the incentives mechanism enhance the global
performance, taking for measurements the same metrics and video used in the other tests.
Each terminal was launched and waited for a signal, via the remote feature, to start streaming the
video. Each terminal was launched with different timestamps in order to evaluate the server load efficiency on the network. Table 5.1 lists the timestamps in which each terminal was launched.
Table 5.1: Terminal timestamp distribution startup
Terminal
TimeStamp(s)
PC-1
0
PC-2
3
PC-3
8
PC-4
10
PC-5
16
PC-6
17
PC-7
20
PC-8
25
PC-9
27
PC-10
28
PC-11
32
PC-12
34
In Figure 5.14 the average playback rate of the Peers when the system has no Free-Riders is plotted.
The low rate start-up is due to the bootstrapping of all Peers in the first 50 seconds, with the average
value always falling whenever a newer Peer joins the network with a very low bitrate.
The remaining part of the plot is very similar to the one obtained in Section 5.4.1 for a LAN environment. It can be noticed that applying the Tit-for-Tat policy at the end of the stream a higher playback
rate is achieved, mainly because of the periodic reviews done for each Peer every 20 seconds. As soon
as a low uploader is detected, the strategy swaps slots with Peers interested in downloading pieces that
proved to be better uploaders. The same situation can be observed in Figure 5.15 where at the end of
the stream, only 80-90% of the transmission Layers are received due to same fact.
Figure 5.16 and Figure 5.17 represent the cumulative distribution of the average download rate and
upload rate, respectively. In Figure 5.16 it can be noticed that at least in 50% of the time a playback rate
less than 750 Kbps was reached but achieving higher bitrates of approximately 1 Mbps.
The Tit-for-Tat policy also achieves lower bitrate for the same probability distribution between 750 Kbps
76
Figure 5.14: Average Playback Rate with no free riders
Figure 5.15: Average Chunk Layer Ratio with no free riders
77
Figure 5.16: Distribution of the Average Download Rate with no free riders
and 950 Kbps.
Figure 5.17 clearly demonstrates that the upload rate may reach high peek rates. These high peek
rates arise in a initial time window when all Peers start streaming the video. The Peers have buffers to
fill, and as no one has proven yet to be a good uploader, high upload rates are achieved. As uploading
pieces are not needed to be sent in order, and are requested by any peer and in an random order, unlike
what happen with the PSW downloading algorithm, the average upload rate (approximately 1 Mbps) is
much higher than the download rate.
Figure 5.17: Distribution of the Average Upload Rate with no free riders
With this test, the average server load dropped from 100% to a 30% load.
78
In Figure 5.18 the average playback rate of the Peers when the system has 2-3 Free-Riders is plotted.
It can be clearly noticed that the Peers who don’t contribute to the network will suffer consequences
from the Tit-for-Tat policy by lowering their playback rate (i.e., lower video quality received) forcing these
Peers to receive fewer transmission video Layers and lowering the average playback rate of the system.
An interesting fact is that higher playback rates are achieved as soon as five Peer reviews are made
(Figure 5.18 at t=100 seconds).
Figure 5.18: Average Playback Rate with free riders
The same situation can observed in Figure 5.19 as the percentage of received video Chunk Layer is
higher than the solution using no Tit-for-Tat strategy.
Figure 5.19: Average Chunk Layer Ratio with free riders
The Free-Rider Peers are prejudiced by the Tit-for-Tat strategy and with no Tit-for-Tat they receive as
79
much video as they can, but endanger the piece availability in the network.
Figure 5.20 plots the cumulative distribution of the average download rate of the network. Notice
that the Tit-for-Tat strategy obtains the highest download rate for the same percentages than the no
Tit-for-Tat strategy after some initial reviews of peers.
Figure 5.20: Distribution of the Average Download Rate with free riders
Figure 5.21 demonstrates that the average upload rate is maintained at a higher rate when applying
the Tit-for-Tat strategy, even though 15% of Peers are contributing with 0 Kbps. The network is clearly
affected when no incentives policy is applied.
Figure 5.21: Distribution of the Average Upload Rate with free riders
80
5.5
Summary
This chapter presented the evaluation tests for all the functional and non-functional requirements of
the P2P SVC Player prototype.
Two different scenarios were prepared in order to assess different aspects of the prototype.
The first scenario validates the prototype bandwidth adaptation system for heterogeneous access
networks such as LAN, WLAN and 3G, where in could be observed that the system clearly adapted its
video bitrate when network conditions changed, maintaining the user QoE.
The tests results also demonstrated the prototype performance when on Live Streaming mode activation.
Terminal capabilities were demonstrated with network traffic reduction on the client side reduced
whenever the screen resizing functionality was applied.
The prototype demonstrates that it is compatible to any terminal hardware set-up, as it is controlled
by the CPU load heuristic to determine the maximum number of Layers to decode in order not to harm
the video quality or other running processes on the system.
In a second scenario the prototype scalability was validated, demonstrating its performance with
a wider group of Peers geographically distributed in the world. Finally, the prototype client incentives
Tit-for-Tat strategy was also tested and demonstrated to provide a good and long term stable situation
preventing Free-Riders.
81
82
6
Conclusion and Future Work
Contents
6.1 System limitations and future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
6.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
83
6.1
System limitations and future work
The developed prototype presents some limitations that may be overcome in the future. Improvements and exploration of certain details may still be researched in order to refine the quality of the
adaptation techniques developed the and overall performance of the prototype.
Concerning the limitations of the current solution, the most critical is relative to the Decoder module.
The current SVC decoder/encoder has some limitations that deteriorate the user QoE:
• Only decodes NAL units with 0 or 1 values of quality scalability in the combination of all three
scalability dimensions.
• When decoding Chunks and have NAL units with different values of temporal scalability the user
experiences some image flickering and transposition with past frames.
• In order to evaluate the Live performance of this encoder, a much faster process must be deployed.
• Its performance regarding CPU usage should be optimized for embedded devices (targeting essentially the new breed of Touch-screen Smartphones) in order to optimize economizing their
power consumption.
With these improvements even better results could confidently be demonstrated.
As for the general bitrate adaptation algorithm, it could be improved, using some kind of simple
heuristic module in order to analyze the network conditions and estimate better future changes and
adaptation of the video bitrate stream. The Live Streaming mode is a feature that can still be enhanced
for the BitTorrent application using the SVCs benefits. The current usage of the Live mode is done by
skipping the hash verification and is time limited by the torrent initial creation process. Live mode should
have no time limit support.
As for the upload incentives, the algorithm Give-To-Get [47] would be well suited on P2P VoD streaming applications, since it discourages Free-Riding by letting Peers favor uploading to other Peers who
have proven to be good uploaders. The application of this algorithm to the prototype would be an interesting upgrade to the Tit-for-Tat strategy used.
Integration with a Web Browser and HTTP support would be the next development of this prototype
for the SARACEN project, as the code is fully supportive for these new features.
Security related aspects weren’t analyzed, but the BitTorrent engine does support encryption of all
data using the Diffie–Hellman key exchange cryptographic protocol, and all code is available.
Mono.Nat [59] is an add-on for the Monotorrent library that fully supports UPnP and PMP protocols
for automatic port mapping in the network, if routers have support and enabled any of these features.
Due to lack of time, automatic port opening features were not added to this prototype. When the
user is behind a NAT and using this application, it is critical that the user opens a port on the router
84
for uploading purposes, or it might be prejudiced by the Tit-for-Tat strategy. Other techniques such as
TCP hole punching or relaying were also briefly analyzed (not implemented on this solution) in order
to figure out alternative ways of maintaining inbound communication with running instances within a
network router without any of the automatic port mapping protocols.
6.2
Conclusion
This dissertation proposes a Scalable Video Player for P2P Networks, with QoS/QoE-Awareness
and adaptive streaming due to its layered structure, providing a very stable streaming application for
heterogeneous access networks, rich performance for high growing networks and fully compatible with
various terminal hardware setups.
At first, the SVC codec was studied, and its structure and compatibility with P2P networks were
presented. The codec was at this phase a very high quality candidate for achieving a high performance in
a sharing environment. Various P2P Networks and file sharing applications were studied and presented,
whereas the focus was made on the application of SVC to BitTorrent like application, due to its broad
usage in current end user systems and to its appealing protocol design. Other public P2P streaming
applications were also presented, but very few using integration with the SVC codec, and none with the
BitTorrent engine.
The second phase consisted on the design and implementation of the solution architecture, where
functional and non-functional requirements were specified. The main functionalities were to be bitrate
adaptive in order to support heterogeneous access networks and respond well to various network conditions, have Live and VoD support, support different terminal capabilities, insert upload incentives and
introduce scalability. A modular approach was followed in order for future modifications or customizations to be simpler. All module description and their internal and external connections were defined and
implemented.
The evaluation of the solution was performed with functional and non-functional tests, setting up two
different network scenarios, which allowed the testing of all the functionalities and mechanisms, as well
as assessing the behavior of the application under various networked conditions, such as a LAN, WLAN
and 3G networks, large network of Peers, in which the successful adaptation to the existent conditions,
upload incentives, scalability, live performance and terminal capabilities were presented.
The SVC P2P Player solution developed proved to be stable, with a novel stream adaptive algorithm
and unique features demonstrating satisfactory results.
The integration of the core developments of this prototype into a Web Browser plug-in with HTTP
support will be deployed for the SARACEN European project.
85
86
Bibliography
[1] J. F. Monteiro, “Quality Assurance Solutions for Multipoint Scalable Video Distribution over Wireless
IP Networks,” Ph.D. dissertation, Instituto Superior Técnico - Universidade Técnica de Lisboa, Dec.
2009.
[2] J. Rieckh, “Scalable Video for Peer-to-Peer Streaming,” Master’s thesis, Technical University of
Vienna, Summer 2008.
[3] B. Cohen, “BitTorrent Protocol Specification,” BitTorrent.org, BitTorrent Enhancement Proposals
BEP 3, Feb. 2008. [Online]. Available: http://www.bittorrent.org/beps/bep 0003.html
[4] GDF, “The Annotated Gnutella Protocol Specification,” The Gnutella Developer Forum, Annotated
Standard v0.4, Jul. 2003. [Online]. Available: http://rfc-gnutella.sourceforge.net/developer/stable/
index.html
[5] Y. Kulbak and D. Bickson, “The eMule Protocol Specification,” The Hebrew University of Jerusalem,
School of Computer Science and Engineering, Israel, Unpublished Report, Jan. 2005.
[6] A. Parker, “Addressing the cost and performance challenges of digital media content delivery,”
P2P MEDIA SUMMIT LA, DCIA Conference & Exposition, Oct. 2006, p2P Media Summit, Los
Angeles. [Online]. Available: http://www.dcia.info/activities/p2pmsla2006/
[7] SARACEN Consortium, “SARACEN: Socially Aware, collaboRative, scAlable Coding mEdia
distributioN project Home Page,” SARACEN Consortium, 2010. [Online]. Available:
http:
//www.saracen-p2p.eu/
[8] INOV, “INOV - INESC Inovação Home Page,” 2010. [Online]. Available: http://www.inov.pt/
[9] R. Nunes, R. S. Cruz, and M. S. Nunes, “Scalable Video Distribution in Peer-to-Peer Architecture,” in
10a Conferência sobre Redes de Computadores, CRC10, Universidade do Minho, Braga, Portugal,
Nov. 2010.
[10] C. 2010, “10a Conferência sobre Redes de Computadores,” Universidade do Minho, Braga, Nov.
2010. [Online]. Available: http://crc2010.di.uminho.pt/
87
[11] J. Ozer, “YouTube does 720P HD using H.264,” Feb. 2009. [Online]. Available:
http:
//www.streaminglearningcenter.com/articles/youtube-does-720p-hd-using-h264.html
[12] 3GPP, “Multimedia Broadcast/Multicast Service (MBMS); Protocols and Codecs,” 3rd Generation
Partnership Project (3GPP), Technical Specification TS 26.346, Mar. 2006.
[13] S. Rimac-Drlje, O. Nemcic, and M. Vranjes, “Scalable Video Coding extension of the H.264/AVC
standard,” in Proceedings of the 50th International Symposium, ELMAR 2008, vol. 1, Sep. 2008,
pp. 9 –12.
[14] JVT, “SVC Reference Software (JSVM software),” Joint Video Team (JVT) of ISO/IEC MPEG
and ITU-T VCEG, Jan. 2008. [Online]. Available: http://ip.hhi.de/imagecom G1/savce/downloads/
SVC-Reference-Software.htm
[15] M. Wien, R. Cazoulat, A. Graffunder, A. Hutter, and P. Amon, “Real-Time System for Adaptive
Video Streaming Based on SVC,” IEEE Transactions on Circuits and Systems for Video Technology,
vol. 17, no. 9, pp. 1227 –1237, Sep. 2007.
[16] M. Wien, H. Schwarz, and T. Oelbaum, “Performance Analysis of SVC,” IEEE Transactions on
Circuits and Systems for Video Technology, vol. 17, no. 9, pp. 1194 –1203, Sep. 2007.
[17] S. Wenger, Y.-K. Wang, and T. Schierl, “Transport and Signaling of SVC in IP Networks,” IEEE
Transactions on Circuits and Systems for Video Technology, vol. 17, no. 9, pp. 1164 –1173, Sep.
2007.
[18] T. Schierl, T. Stockhammer, and T. Wiegand, “Mobile Video Transmission Using Scalable Video
Coding,” IEEE Transactions on Circuits and Systems for Video Technology, vol. 17, no. 9, pp. 1204
–1217, Sep. 2007.
[19] V. Goyal, “Multiple description coding: compression meets the network,” IEEE Signal Processing
Magazine, vol. 18, no. 5, pp. 74 –93, sep. 2001.
[20] ISO/IEC, “Information Technology Coding of Audio-Visual Objects - Part 2: Visual,” International
Organization for Standardization/International Electrotechnical Commission, International Standard
ISO/IEC 14496-2:2001, 2001.
[21] Microsoft, “Smooth Streaming : The Official Microsoft IIS Web Site,” Microsoft Corporation, 2010.
[Online]. Available: http://www.iis.net/download/SmoothStreaming
[22] PeerCast.org,
“PeerCast Home Page,”
PeerCast.org,
//www.peercast.org/
88
2010. [Online]. Available:
http:
[23] Tryphon.org, “FreeCast: Peer-To-Peer Broadcasting Software Home Page,” Tryphon SARL, 2010.
[Online]. Available: http://www.freecast.org
[24] V. Pai, K. Kumar, K. Tamilmani, V. Sambamurthy, and A. Mohr, “Chainsaw: Eliminating trees from
overlay multicast,” in Peer-to-Peer Systems IV, ser. Lecture Notes in Computer Science, M. Castro
and R. van Renesse, Eds.
Springer Berlin / Heidelberg, 2005, vol. 3640, pp. 127–140.
[25] L. Zhao, “GridMedia+: A P2P Streaming System for Live and On-Demand Video,” in Proceedings
of the 6th IEEE Consumer Communications and Networking Conference, CCNC ’09., Jan. 2009,
pp. 1 –2.
[26] J. Rhoden and J. Jin, “BEncoding Specification,” Specification Version 1, Mar. 2006. [Online].
Available: http://rhoden.id.au/doc/BEncodingSpecification.html
[27] B. Cohen, “Incentives Build Robustness in BitTorrent,” in Proceedings of the 1st Workshop
on Economics of Peer-to-Peer Systems.
UC Berkeley, Jun. 2003. [Online]. Available:
http://www.sims.berkeley.edu/p2pecon/
[28] N. Andrade, M. Mowbray, A. Lima, G. Wagner, and M. Ripeanu, “Abstract Influences on Cooperation in BitTorrent Communities,” 2009.
[29] P. Shah and J.-F. Pâris, “Peer-to-Peer Multimedia Streaming Using BitTorrent,” in Proceedings of
the IEEE International Performance, Computing, and Communications Conference, IPCCC ’07.,
Apr. 2007, pp. 340 –347.
[30] J. A. Pouwelse, P. Garbacki, J. Wang, A. Bakker, J. Yang, A. Iosup, D. H. J. Epema, M. Reinders,
M. R. V. Steen, and H. J. Sips, “Tribler: A social-based peer-to-peer system,” in Proceedings of the
5th International Workshop on Peer-to-Peer Systems (IPTPS06), 2006.
[31] BitLet.org, “The BitTorrent Applet Home Page,” BitLet.org, 2010. [Online]. Available:
http:
//www.bitlet.org/
[32] “TVUnetworks: P2PTV Application,” 2010. [Online]. Available: http://www.tvunetworks.com/
[33] “PPLive: P2PTV Application,” 2010. [Online]. Available: http://www.pptv.com/en/
[34] S. Xie, B. Li, G. Y. Keung, and X. Zhang, “Coolstreaming: Design, Theory, and Practice,” IEEE
Transactions on Multimedia, vol. 9, no. 8, pp. 1661–1671, Dec. 2007.
[35] C. Rattanapoka, D. Pate, and T. Tucker, “ABC: Another BitTorrent Client Home Page,” 2010.
[Online]. Available: http://pingpong-abc.sourceforge.net/
[36] Vuze, “Vuze Home Page,” Vuze, Inc., 2010. [Online]. Available: http://www.vuze.com/
89
[37] BitTorrent, “uTorrent: a (very) tiny BitTorrent Client Home Page,” BitTorrent, Inc., 2010. [Online].
Available: http://www.utorrent.com/
[38] Last.fm, “Last.fm Home Page,” Last.fm, Ltd., 2010. [Online]. Available: http://www.last.fm/
[39] Amazon,
“Amazon Home Page,”
Amazon.com,
Inc.,
2010. [Online]. Available:
http:
//www.amazon.com/
[40] A. B. et al., Tribler Protocol Specification, Information and Communication Theory, Delft University
of Technology, January 2009.
[41] J. Mol, J. Pouwelse, D. Epema, and H. Sips, “Free-Riding, Fairness, and Firewalls in P2P FileSharing,” in Proceedings of the Eighth International Conference on Peer-to-Peer Computing , P2P
’08, sep. 2008, pp. 301 –310.
[42] M. Mushtaq and T. Ahmed, “Smooth Video Delivery for SVC Based Media Streaming Over P2P Networks,” in Proceedings of the 5th IEEE Consumer Communications and Networking Conference,
CCNC 2008, Jan. 2008, pp. 447 –451.
[43] P. Baccichet, T. Schierl, T. Wiegand, and B. Girod, “Low-Delay Peer-to-Peer Streaming Using Scalable Video Coding,” in Proceedings of Packet Video 2007, Nov. 2007, pp. 173–181.
[44] E. Setton, P. Baccichet, and B. Girod, “Peer-to-Peer Live Multicast: A Video Perspective,”
Proceedings of the IEEE, vol. 96, no. 1, pp. 25 –38, jan. 2008.
[45] “P2P-Next:
Next generation Peer-to-Peer (P2P) content delivery platform,” 2010. [Online].
Available: http://www.p2p-next.org/
[46] “NextShare streaming service,” 2010. [Online]. Available: http://www.livinglab.eu/
[47] J. J. D. Mol, J. A. Pouwelse, M. Meulpolder, D. H. J. Epema, and H. J. Sips, “Give-to-Get:
Free-riding-resilient Video-on-Demand in P2P Systems,” in Proceedings of the 15th Multimedia
Computing and Networking Conference, MCNC ’08, vol. 6818, Jan. 2008.
[48] S. Wenger, Y. Wang, T. ThomasSchierl, and A. Eleftheriadis, “RTP Payload Format for SVC
Video,” Internet Engineering Task Force, Internet-Draft draft-ietf-avt-rtp-svc-20, Oct. 2009, work in
progress. [Online]. Available: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-svc-20.txt
[49] T. Zgaljic, N. Sprljan, and E. Izquierdo, “Bit-stream allocation methods for scalable video coding
supporting wireless communications,” Signal Processing: Image Communication, vol. 22, no. 3,
pp. 298 – 316, 2007, special issue on Mobile Video. [Online]. Available: http://www.sciencedirect.
com/science/article/B6V08-4MS9RCS-2/2/5da5ce3350eb0dc1bbfded593f32d0b5
90
[50] Mederic Blestel and Mickael Raulet,
“Open SVC Decoder,”
2010. [Online]. Available:
http://sourceforge.net/projects/opensvcdecoder/
[51] “MPlayer - The Movie Player,” 2010. [Online]. Available: http://www.mplayerhq.hu
[52] “TCPMP: Open Source Media Player Project,” 2010. [Online]. Available: http://picard.exceed.hu/
tcpmp/
[53] Alan McGovern et al., “MonoTorrent: Cross platform and open source implementation of the
BitTorrent protocol,” 2010. [Online]. Available: http://projects.qnetp.net/projects/show/monotorrent
[54] S. Tewari and L. Kleinrock, “Analytical Model for BitTorrent-Based Live Video Streaming,” jan. 2007,
pp. 976 –980.
[55] A. Zambelli, “IIS Smooth Streaming Technical Overview,” Microsoft Corporation, March 2009.
[56] J. Dejun and G. P. C. hung Chi, “EC2 Performance Analysis for Resource Provisioning of ServiceOriented Applications,” in Proceedings of the 3rd Workshop on Non-Functional Properties and SLA
Management in Service-Oriented Computing, NFPSLAM-SOC’09, Nov. 2009.
[57] “FFmpeg: Complete, cross-platform solution to record, convert and stream audio and video,” 2010.
[Online]. Available: http://ffmpeg.org/
[58] Z. Liu, Y. Shen, K. W. Ross, S. S. Panwar, and Y. Wang, “LayerP2P: Using Layered Video Chunks in
P2P Live Streaming,” IEEE Transactions on Multimedia, vol. 11, no. 7, pp. 1340 –1352, Nov. 2009.
[59] “Mono.Nat: A library which allows you to easily forward ports on any uPnP capable router,” 2010.
[Online]. Available: http://projects.qnetp.net/projects/show/mono-nat
91
92
A
Description of Appendix A
Contents
A.1 Tracker Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
A.2 Peer Wire Protocol
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
93
A.1
Tracker Protocol
The tracker protocol is implemented on top of HTTP/HyperText Transfer Protocol Secure (HTTPS).
This means that the machine running the tracker runs a HTTP or HTTPS server, and has the behaviour
described below:
1. The client sends a GET request to the tracker URL, with certain Common Gateway Interface (CGI)
variables and values added to the URL. This is done in the standard way, i.e if the base URL is
”http://some.url.com/announce”, the full URL would be of this form:
”http://some.url.com/announce?var1=value1&var2=value2&var3=value3”.
2. The tracker responds with a ”text/plain” document, containing a bencoded dictionary. This dictionary has all the information required for the client.
3. The client then sends requests, either on regular intervals, or when an event occurs, and the
tracker responds.
The CGI variables and values added to the base URL by the client sending a GET request are:
• info hash: The 20 byte SHA1 hash calculated from whatever value the info key maps to in the
metainfo file.
• peer id: A 20 character long id of the downloading client, random generated at start of every
download. There is no formal definition on how to generate this id, but some client applications
have adapted some semiformal standards on how to generate this id.
• ip: This is an optional variable, giving the IP address of the client. This can usually be extracted
from the TCP connection, but this field is useful if the client and tracker are on the same machine,
or behind the same NAT gateway. In both cases, the tracker then might publish an unroutable IP
address to the client.
• uploaded: The amount of data uploaded so far by the client. There is no official definition on the
unit, but generally bytes are used
• left: How much the user has left for the download to be complete, in bytes.
• event: An optional variable, corresponding to one of four possibilities:
– started: Sent when the client starts the download
– stopped: Sent when the client stops downloading
– completed: Sent when the download is complete. If the download is complete at start up, this
message should not be sent.
94
– empty: Has the same effect as if the event key is non-existent. In either case, the message
in question is one of the messages sent with regular intervals.
There are some optional variables that can be sent along with the GET request that are not specified
in the official description of the protocol, but are implemented by some tracker servers:
• numwant: The number of peers the client wants in the response.
• key: An identification key that is not published to other peers. peer id is public, and is thus useless
as authorization. key is used if the peer changes IP number to prove it’s identity to the tracker.
• trackerid: If a tracker previously gave its trackerid, this should be given here.
As mentioned earlier, the response is a ”text/plain” response with a bencoded dictionary. This dictionary contains the following keys:
• failure reason: If this key is present, no other keys are included. The value mapped to this key is a
human readable string with the reason to why the connection failed.
• interval: The number of seconds that the client should wait between regular requests.
• peers: Maps to a list of dictionaries, that each represent a peer, where each dictionary has the
keys:
– peer id: The id of the peer in question. The tracker obtained this by the peer id variable in the
GET request sent to the tracker.
– ip: The address of the peer, either the IP address or the Domain Name System (DNS) domain
name.
– port: The port number that the peer listens on.
These are the keys required by the official protocol specification, but here as well there are optional
extensions:
• min interval: If present, the client must do requests more often than this.
• warning message: Has the same information as failure reason, but the other keys in the dictionary
are present.
• tracker id: A string identificating the tracker. A client should resend it in the trackerid variable to the
tracker.
• complete: This is the number of peers that have the complete file available for upload.
• incomplete: The number of peers that not have the complete file yet.
95
A.2
Peer Wire Protocol
The peer wire (peer to peer) protocol runs over TCP. Message passing is symmetric, i.e. messages
are the same sent in both directions.
When a client wants to initiate a connection, it sets up the TCP connection and sends a handshake
message to the other peer. If the message is acceptable, the receiving side sends a handshake message
back. If the initiator accepts this handshake, message passing can initiate, and continues indefinitely.
All integers are encoded as four byte big-endian, except the first length prefix in the handshake.
Handshake message The handshake message consists of five parts:
• A single byte, containing the decimal value 19. This is the length of the character string following
this byte.
• A character string ”BitTorrent protocol”, which describes the protocol.
• Eight reserved bytes for further extension of the protocol. All bytes are zero in current implementations.
• A 20 byte SHA1 hash of the value mapping to the info key in the torrent file. This is the same hash
sent to the tracker in the info hash variable.
• The 20 byte character string representing the peer id. This is the same value sent to the tracker.
If a peer is the first recipient to a handshake, and the info hash doesn’t match any torrent it is serving,
it should break the connection. If the initiator of the connection receives a handshake where the peer id
doesn’t match with the id received from the tracker, the connection should be dropped.
Each peer needs to keep the state of each connection. The state consists of two values, interested
and choking. A peer can be either interested or not in another peer, and either choke or not choke the
other peer. Choking means that no requests will be answered, and interested means that the peer is
interested in downloading pieces of the file from the other peer. This means that each peer needs four
Boolean values for each connection to keep track of the state.
am interested
am choking
peer interested
peer choking
All connections start out as not interested and choking for both peers. Clients should keep the
am interested value updated continuously, and report changes to the other peer.
The messages sent after the handshaking are structured as:
[message length as an integer] [single byte describing message type] [payload]
96
Keep alive messages are sent with regular intervals, and they are simply a message with length 0,
and no type or payload. Type 0, 1, 2, 3 are choke, unchoke, interested and not interested respectively.
All of them have length 1 and no payload. These messages simply describe changes in state.
Type 4 is a have. This message has length = 5, and a payload that is a single integer, giving the
integer index of which piece of the file the peer has successfully downloaded and verified.
Type 5 is bitfield. This message is only sent directly after handshake. It contains a bitfield representation of which pieces the peer has. The payload is of variable length, and consists of a bitmap, where
byte 0 corresponds to piece 0-7, byte 1 to piece 8-15 etc. A bit set to 1 represents having the piece.
Peers that have no pieces can neglect to send this message.
Type 6 is a request. The payload consists of three integers, piece index, begin and length. The piece
index decides within which piece the client wants to download, begin gives the byte offset within the
piece, and length gives the number of bytes the client wants to download. Length is usually a power of
two.
Type 7 is a block. This message follows a request. The payload contains piece index, length and the
data itself that was requested.
Type 8 is cancel. This message has the same payload as request messages, and it is used to cancel
requests made. Peers should continuously update their interested status to neighbours, so that clients
know which peers will begin downloading when unchoked.
97
98
B
Description of Appendix B
Contents
B.1 SVC Video Manifest Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
99
B.1
SVC Video Manifest Structure
This sections specifies the format and semantics of the manifest used by the client for VoD or Live
scenarios. As illustrated below, the client makes a simple HTTP request to the IIS Server, which responds with a Extensible Markup Language (XML) file containing the information. The response contains information about the torrents video time length, number of layers per chunks, if its a live feed and
its current time position, and the possible resolutions due to the spatial definition when the layers are
combined.
GET /Smooth/torrents/video_5.Manifest HTTP/1.1
Host: smooth.inov.pt
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://smooth.inov.pt/Smooth/torrents/
HTTP/1.1 200 OK
Cache-Control: max-age=2
Content-Type: text/xml
ETag: "e28c1314ed0fa0"
Server: Microsoft-IIS/7.0 IISMS/3.0
X-Powered-By: ASP.NET
Date: Sun, 05 Sep 2010 14:27:50 GMT
Content-Length: 274
<?xml version="1.0"?>
<SVCVideo Duration="150" MaxLayers="10" TimeScale="2" IsLive="TRUE" CurrentChunk="35">
<QualityLevel Index="0" MaxWidth="352" MaxHeight="288" NumLayers="5"/>
<QualityLevel Index="1" MaxWidth="528" MaxHeight="384" NumLayers="5"/>
</SVCVideo>
100
101