Peer network in video player
Some users have already noticed in our video player a window with a proposal to allow the use of a peering network. Watching videos using peer-to-peer technology is the last stage of testing. Of all the videos uploaded to the site at one time or another, as a rule, no more than 10–15% are viewed. Another 15–20% of these clips can be considered popular. Switching to P2P significantly reduces server load, allowing users to receive video stream from neighboring clients (of course, who also confirmed their participation in the peer-to-peer network).
The development uses the RTMFP protocol implemented by Flash Player 10.1 from the client side and Adobe Cirrus from the server side.
')
This reduces latency when playing videos at once for two reasons. On the one hand, direct requests to the north are rarely made, and it becomes easier for the server to breathe and respond to other requests. On the other hand, the speed of receiving data from the "neighbors" can often be higher than from the server in the data center, because the system selects partners based on considerations of maximum efficiency.
A video player can only distribute the video that is viewed at one time or another - and only that part of it that has been downloaded and is still in memory. At the same time, the size of the buffer can not exceed 64 MB, in order not to eat off too much RAM. Theoretically, it is enough to have two simultaneously watching video users to enable P2P mode. However, it is advisable only for those videos that are watched simultaneously by dozens of users (as mentioned above, for VKontakte, such videos make up about 15–20% of those that are actively viewed). In the case of playing videos for which the use of p2p will not bring visible results, the player switches to standard download.
To identify clients, only the key issued by the Adobe Cirrus server is used, neither the IP address nor the user's uid can be recovered using it).
As mentioned above, to merge into a separate group of users viewing the same video (in the same resolution), the Cirrus service from Adobe is currently used, interacting with the RTMFP protocol. Support for the corresponding NetGroup class appeared only in Flash Player version 10.1 - therefore, users with a tenth version player will not see the offer to use P2P.
To organize the exchange between users of parts of one video, the file is divided into chunks of 64 KB. Each chunk is first requested from neighboring peers (this whole process is governed internally by the Flash player and the Cirrus server), and if there is no answer, a request is made directly to Vkontakte video servers within a few seconds - the data is divided into chunks and distributed to other users.
To output the loaded chunks, the so-called “Data Generation Mode” of the NetStream class is used. Unfortunately, it doesn’t support the MP4 format, which is now used to store the V Kontakte video, so the video files collected from the chunks now have an MP4 to FLV container on the fly.
Due to the need to keep the reproduced file identical regardless of the starting point, it was decided to abandon the creation of key frames on the server side when playing from an arbitrary location. The selection of the frame closest to the selected moment is now also made by the client, which additionally reduces delays when rewinding the video.
The main results at the current stage are a noticeable reduction in delays:
The development uses the RTMFP protocol implemented by Flash Player 10.1 from the client side and Adobe Cirrus from the server side.
')
This reduces latency when playing videos at once for two reasons. On the one hand, direct requests to the north are rarely made, and it becomes easier for the server to breathe and respond to other requests. On the other hand, the speed of receiving data from the "neighbors" can often be higher than from the server in the data center, because the system selects partners based on considerations of maximum efficiency.
A video player can only distribute the video that is viewed at one time or another - and only that part of it that has been downloaded and is still in memory. At the same time, the size of the buffer can not exceed 64 MB, in order not to eat off too much RAM. Theoretically, it is enough to have two simultaneously watching video users to enable P2P mode. However, it is advisable only for those videos that are watched simultaneously by dozens of users (as mentioned above, for VKontakte, such videos make up about 15–20% of those that are actively viewed). In the case of playing videos for which the use of p2p will not bring visible results, the player switches to standard download.
To identify clients, only the key issued by the Adobe Cirrus server is used, neither the IP address nor the user's uid can be recovered using it).
Technical details
As mentioned above, to merge into a separate group of users viewing the same video (in the same resolution), the Cirrus service from Adobe is currently used, interacting with the RTMFP protocol. Support for the corresponding NetGroup class appeared only in Flash Player version 10.1 - therefore, users with a tenth version player will not see the offer to use P2P.
To organize the exchange between users of parts of one video, the file is divided into chunks of 64 KB. Each chunk is first requested from neighboring peers (this whole process is governed internally by the Flash player and the Cirrus server), and if there is no answer, a request is made directly to Vkontakte video servers within a few seconds - the data is divided into chunks and distributed to other users.
To output the loaded chunks, the so-called “Data Generation Mode” of the NetStream class is used. Unfortunately, it doesn’t support the MP4 format, which is now used to store the V Kontakte video, so the video files collected from the chunks now have an MP4 to FLV container on the fly.
Due to the need to keep the reproduced file identical regardless of the starting point, it was decided to abandon the creation of key frames on the server side when playing from an arbitrary location. The selection of the frame closest to the selected moment is now also made by the client, which additionally reduces delays when rewinding the video.
Subtotals
The main results at the current stage are a noticeable reduction in delays:
- When playing popular videos simultaneously downloaded by a large number of users.
- When playing any video from any place.
Source: https://habr.com/ru/post/124891/
All Articles