MDC-Based P2P live video broadcast Solution

Source: Internet
Author: User

Abstract:
This paper proposes a multi-description encoding-based peer-to-peer video stream live broadcast solution, and introduces the P2P Video Publishing and receiving policies in this solution.
Keywords:
MDC peer to peer video stream

With the development of communication technology and digital video technology and the increasingly sophisticated network infrastructure, traditional internet services based on text and Image Browsing have gradually become more and more
Media Service is replaced. The occupation of network bandwidth by multimedia services based on audio and video, as well as the requirements for network service quality and real-time transmission are incomparable to those of traditional internet services. How
The existing Internet environment effectively sends audio and video data and provides network multimedia services satisfactory to users. This article discusses a method that combines multiple description encoding,
A scheme for sending video streams in P2P mode.
1 P2P Technology Introduction

P2P technology is a technology used to share computer resources between different PC users. Each user on the network is a peer object. They are independent and can collaborate with each other. They are both service providers and users. Early P2P networks have made remarkable achievements in distributed computing, instant messaging, and file sharing.
It is particularly worth mentioning that the P2P-based Bt (bit
Torrent) file download. Its basic idea is to divide a large file into many small parts and download parts of the file from other users in the network in an unordered manner. After a user downloads a file
You can share the entire part for other users to download. Compared with the traditional C/S File Download method, this P2P download method features that the more users download, the faster the download speed.
Network transmission capability.

However, this file download method cannot be directly used for Video Stream sending, especially for live video streaming. For a live video stream, its data streams are generated in real time (different from the file method, to be sent ).
The sent data is stored in the local storage. At the same time, the receipt and viewing of the live video stream must be performed in real time and in sequence. Currently, P2P-based live video streaming uses application-layer multicast to send video streams.
It is implemented by building a multicast tree. Each user (a node on the multicast tree) obtains the complete video stream from its parent node for viewing and forwards the video data to the downstream son node. In this way
The network I/O bandwidth of each peer node in the multicast tree is high (it is not ideal for some user access methods. For example, for ADSL users, the upstream and downstream channels are asymmetrical and the upstream bandwidth is very high.
Narrow ). In addition, when a node of the multicast tree, especially the node on the upper layer, fails, the recovery of the multicast tree is difficult and delayed.
2 Multi-description Encoding

Multiple Description
Coding) assume that there are multiple channels between the source and the channel, the probability of simultaneous error of each channel is very low. Multiple equally important and independently decoded encoding descriptions are generated to ensure that
When it is lost, it can still receive an acceptable signal. Therefore, multi-description encoding is applicable to packet-based networks, Internet systems without effective protection mechanisms, diversity communication systems (wireless channels with multiple antennas), voice encoding, and graphs.
Such as encoding, video encoding, and multi-distribution storage systems have good application prospects.
There are many methods to construct multi-description encoding for videos. The simplest and most intuitive method is to perform subsampling for spatial and temporal resolutions and encode them into multi-path description code streams. In addition, there are also multi-description quantization, multi-description transform encoding, and multi-description Encoding Based on FEC.
3. MDC-Based P2P live video Solution

Through the analysis of MDC and P2P technologies, we can see that these two technologies have significant advantages and characteristics in network multimedia data transmission. However, these two technologies are combined for direct video processing.
And their respective technical advantages have not been seen yet. The live video broadcast solution proposed in this article uses multi-description encoding for the original video to form a multi-path code stream. The encoded multi-channel description stream adopts the P2P method
Multi-Point (that is, multiple peers) collaborate to achieve multi-path transmission. The specific solution is as follows.
3.1 MDC encoding/decoding model

1. perform spatial subsampling on the original image frame to form a low-resolution video substream. Press 2N
(N can be 1, 2, 3 ,......) Perform subsampling in the horizontal and vertical directions. In this way, after a raw video passes through the sub-sample space, 22n, including 4 and 16, can be formed.
Sub-streams. The specific sampling interval is selected based on the actual application. Encode each video substream separately to obtain 22n.
Road
Encoding description sub-stream. The encoded description sub-streams pass through different channels to the receiver (in fact, in P2P transmission mode, different description sub-streams are sent to the receiver by different peers ). Each trace
The sub-stream is separately received and decoded, And the decoded video stream is merged into the original video stream. If you only receive some video substreams, you can use the corresponding interpolation algorithm to restore the original video image.

3.2 P2P publishing Network Model

Different from the tree-like P2P release network model currently used (the release model is a top-down hierarchical, one-to-many data distribution model), this article uses a top-down hierarchical mesh release model, 2.

3.3 P2P Video sending and receiving

Each description sub-stream is sent in RTP packaging. The header must contain the following private fields: the unique ID of the original stream, the sub-Stream ID, and the timestamp (or the frame synchronization ID ).
(1) initialize the publishing network
The first user to access the network sends a video transfer request to the Publishing Server, because the number of users is small at this time, the user uses the traditional C/S method to directly obtain data from the seed server (the seed server is the "birthplace" of the Video Stream.
(2) New Peer request addition Process
Step 1: Obtain the live stream information from the publisher. The main fields of the live stream information include the live stream ID and description.
Step 2: select the stream you are interested in and send a "Stream Application" to the Publishing Server (Optional: You can broadcast the application to the local LAN at the same time ).
Step 3: The Publishing Server Returns the response information (but also the local peer user returns the response information ). The main content of the response is 3.

Step 4: select the sub-stream forwarding server: ① Select the forwarding description from the peer in the local network first. ② Different substreams should be received from different peers as much as possible. After the forwarding server is selected, send the request to the selected peer and require the Peer to send their respective description sub-stream data.
(3) receiving process

Separate threads are started for receiving and decoding different description substreams. The decoded Multi-Channel Video Frames are placed in the merging buffer. Set a maximum tolerance time for processing each frame of data. When the tolerable time reaches
When the sub-frame number is received in the processing buffer, the corresponding original frame restoration algorithm should be selected to restore and display the image. If all the descriptions of a video stream are received and decoded in time, you can
Completely restore the original video image. Otherwise, the original image must be obtained through interpolation.

During the entire receiving process, the user also makes statistics on the description sub-streams correctly received. For substreams with high latency and packet loss, you can start a search thread to find a new peer to obtain the description substream. Pair
When receiving sub-streams in good status, you can generate report information and send it to the Publishing Server for "Registration ". "Tell" the Publishing Server which "substreams" of the video stream can be forwarded by "self.
(4) Handling of connection loss
If a user's connection is lost (may be due to a network failure, or the Peer of the stream download server shuts down or leaves), the recipient sends the connection to the Publishing Server (or local user) send a download request for this path stream to find a new download server (PEER ). At the same time, the user can still watch the video program normally based on other substreams that can be received.
4. Experiment Model Introduction

A preliminary simulation experiment is carried out in a small network environment consisting of two local networks connected by routers. A total of 15 PCs were used for the simulation experiment. All PCs are P ⅲ
800, memory above MB configuration, and equipped with MB Fast Ethernet Card. One pc serves as the seed Video Server and content publishing server, and the other hosts distributed in two LAN serve as the customer
User Machine. Based on the H.263 standard encoding model, the live video streams are sampled and divided into 4 qcif substreams. Encode these 4 streams separately to Form 4 streams.
Separate description sub-stream, and then the RTP package is sent to the user. Client Access, peer search, and video data receiving and forwarding algorithms are implemented according to the algorithms described in the previous chapter. Number of forwards simultaneously on the client
The packet loss and transmission latency are simulated through random packet loss and delayed transmission. The simulation experiment adopts subjective evaluation. Experiments show that the MDC-Based P2P Video Stream generation established in the lab environment
The distribution system model can be used for ideal video publishing and receiving. Users can watch clear and smooth video images, and have certain error tolerance for network packet loss and connection loss.
5 Summary

The solution proposed in this article can better utilize the multi-user collaboration feature in P2P mode and make full use of network bandwidth for video stream transmission. At the same time, because the encoding adopts the MDC method, this scheme
It can better adapt to network bandwidth changes, and has better adaptability and fault tolerance for packet loss and delay in network transmission. Of course, this solution is still in a relatively simple model phase and will be studied from the following aspects in the future
(1) Further improve the P2P Broadcast Algorithm. (2) Find MDC Encoding algorithms with higher efficiency. (3) Improve the system implementation and test the system in a wider range of real environments.
References

1 Tran d a, Hua k a, do t. Zigzag: an efficient peer-to-peer
Scheme for Media Streaming. In: IEEE Infocom, San Francisco CA, USA, 2003
2 Zhao yihong, Yu songyu, Cheng Guohua. Current Situation and Prospect of Multi-description encoding. Journal of communications, 2005; (1)
3 Xie Yong Jun. P2P streaming media service technology. Modern TV technology, 2004; (7)

 

Http://wenku.baidu.com/view/c1a59380d4d8d15abe234ea2.html

Http://www.doc88.com/p-91667718706.html

Http://www.docin.com/p-34501902.html

Http://www.kinghav.com/cpinfo.asp? Id = 84

Http://www.mscto.com/SoftEngin/SOA/2009022146488.html

Http://www.dzsc.com/data/html/2008-1-29/60310.html

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.