Project topics and materials
Get Complete Project Material File(s) Now! »
Functional elements
Endpoint: A software application or dedicated hardware equipment, which allows a user to participate in a conference. It consists of the following elements:
Equipment for capturing and rendering both audio and video: a screen, a microphone and a loudspeaker or headphones
Audio/video coder and decoder, in order to limit the throughput of streams sent on the network
A signaling protocol stack, which is responsible for the registering the user in the conferencing system, joining or leaving a conference, negotiation of media formats, etc.
A media transport protocol stack, which delivers encoded media over the network between endpoints and the middlebox Conference Control Application: A Graphic User Interface application, which allows the conference leader to fulfill different operations on the conference, such as reserving media resources for a future conference, inviting new participants or removing existing participants. Web technologies are often used for this type of applications, which can also be integrated with the endpoint software.
Media Server: Software component or hardware appliance, which comprises resources for media processing, like:
Audio mixing, that allows the voices of conference participants to be mixed into one stream, that can be sent to all the participants
Video mixing, that allows the images of several participants to be shown simultaneously on the screen (see Figure 2.4)Basic media processing facilities, like media mixing, can be integrated into endpoints and can thus be used in peer-to-peer mode. The use of a centralized Media Server gives some advantages like:
Media trans-coding if media is encoded by different endpoints in incompatible formats
Generating additional media streams based on the conference ones, for example for recording Application server: A software component or hardware appliance, which plays the central management role between other functional parts of the video conferencing solution (Endpoints, Conference Control Application and Media Server). Its functionality encompasses:
Localization of Endpoints (Endpoints register in the Application Server so their network locations are known) and management of Call Signaling sessions
Conference management: processing the requests of the conference leader made with the Conference Control Application (inviting/removing users, etc.) and translating them to Call Signaling session commands towards respective Endpoints.
Media Server management: based on the logic of the conference Application Server, the Media Server applies different media treatment to the conference participants, like playing a voice message to the participants, recording the session, etc.
Having management functions centralized allows the conference to continue smoothly even while some Endpoints leave the conference — which is hardly possible in the case when management logic resides on one of the Endpoints. Furthermore, centralized management facilitates integration with different enterprise software, like corporate directory with information about employees, shared calendars, etc.
Application and Media Servers can be combined in one box with specifically selected hardware optimized for delivering high quality audio/video experience.
Types of video coding
The codecs differ by the quantity of the data, needed to transport the video stream (which is called “bitrate”), the complexity of the encoding and decoding algorithms, robustness to data losses and errors, which occur when the stream traverses the network, end-to-end delay, and a lot of other parameters.
User endpoints vary in their capabilities to accept and process video streams. These differences can be explained by:
Different bandwidth capabilities
Different decoding complexity and power constraints
For example, a specialized hardware based video conferencing endpoint, which is normally installed in a meeting room, is typically able to process high quality video streams. However, a participant using a smart phone is only able to process low quality streams using small bitrates. Generally, this problem is resolved by a “Transforming middlebox”, which can adjust streams to the recipients’ needs (see Figure 2.5).
Scalable Video Coding (SVC) is another approach, allowing different types of devices to participate in the same video conference. With SVC, a high-quality video stream is divided into several layers of quality. For instance in Figure 2.6, the three layers are sent on the network. The mobile terminal (with poor network reception) will only receive the base layer, which corresponds to the lowest video quality. The other terminals, which can benefit from a better network throughput and/or CPU power, can receive additional layers (on top of the base layer) in order to get a better video quality.
The advantage of this technique is that processing at the SVC middlebox is extremely light, as the middlebox just needs to filter the different built-in layers, and processing of the content of the video stream is not required.
One of the following methods can be used to build the different layers:
Temporal scalability (frame rate): a low frame rate is used for the base layer, while additional frames are added on advanced layers, providing more fluidity to the video.
Spatial scalability (picture size): the base layer has a low image resolution, while advanced layers add additional pixels increasing it.
Quality scalability (coding quality): the coding quality corresponds to the number of bits associated with each pixel. The base layer is coded with the low coding quality, advanced layers with the better one.
Video mixing (Continuous presence)
Continuous presence mode is the most common method used in virtual meetings. Usually in this mode the screen is split into one large and several smaller surrounding windows. The conferencing software sends the video of the current speaker to the large window and other participants to the small ones. It’s also possible to use equal windows for all the participants. If the number of participants is too large to show them all, only the latest speakers are displayed.
Table of contents :
Glossary
1. Introduction
2. Video conferencing state-of-the-art
2.1. Video conferencing industry
2.1.1. Introduction
2.1.2. Functional architecture example
2.1.3. Video coding
2.1.4. Video processing
2.1.5. Protocols
2.1.6. Types of media servers
2.1.7. Types of clients
2.1.8. Topologies
2.1.9. Current trends
2.2. Academic research of video conferencing
2.2.1. Application Level Multicast
2.2.2. Peer-to-Peer
2.2.3. Video streaming
2.2.4. Conclusion
3. Node selection algorithms
3.1. General system description
3.2. Optimization criteria
3.3. State Change Events
3.4. MADM approach
3.5. CPU load criterion
3.6. MADM Example
3.6.1. Description
3.6.2. Calculations
3.7. Redeployment Penalty
3.8. Algorithms of Processor selection
3.8.1. Notation conventions for algorithms
3.8.2. Task is added
3.8.3. Task is removed
3.8.4. Processor is added
3.8.5. Processor is removed
3.8.6. Processor CPU load is increased
3.8.7. Processor CPU load is decreased
3.9. Possible extensions
3.9.1. Media stream relays
3.9.2. Taking RTCP feedback into account
3.10. Analysis of the process
3.10.1.Scalability
3.10.2.Algorithms complexity
4. Solution architecture
4.1. Standalone DGC system
4.1.1. DGC architecture
4.1.2. Delay estimation
4.1.3. Example of ALTO usage
4.2. Cloud integrated DGC system
5. Evaluation by simulation
5.1. Simulation input
5.2. Simulation topology
5.3. Simulation results
6. Impact of CPU Load on Video Quality
6.1. Introduction
6.2. Description of the testbed
6.3. Results of the experimentation
7. Conclusions and Future Work
7.1. Conclusions
7.2. Future Work
Annex A. Standalone DGC system design
A.1 Design static view
A.2 Design dynamic view
A.2.1 Add Task sequence
A.2.2 Add Processor sequence
Annex B. Cloud integrated DGC system design
B.1 Design
B.2 Algorithms
List of publications
References
