Number of positive characters: 2361 Reading time: 3 minutes
At present, video content accounts for nearly 70% of all Internet traffic (and it is still rising), so the importance of video streaming has never been more important. Today, most content is managed by content delivery networks (CDN). However, there are still many shortcomings when it comes to CDN video streaming involving real-time content.
Posted by Red5 Pro
url : https://www.red5pro.com/blog/3-problems-with-cdn-video-streaming-and-how-we-solved-them/
Since CDN requires you to import all content through its data network, some streaming media providers find that they need to use multiple CDNs to reach different regions. This means that managing different systems, decentralized streaming media, and adding more connections to transmit streams will bring longer delays and additional complexity.
This has prompted many people in the real-time streaming market to turn to multi-CDN solutions. In fact, it is predicted that by 2025, the multi-CDN market will grow to USD 24 billion. Although multi-CDN solves some of the problems of a single CDN network (regional/regional availability, price, etc.), it is actually only a stopgap measure for real-time video streaming. Now, pure WebRTC distribution service is the best way to create real-time streaming media.
Therefore, pure CDN solutions are gradually withdrawing from the market, at least in terms of live video distribution. The reasons are as follows:
delay
The CDN built on the HTTP architecture does not have the ability to handle the transmission of dynamically updated content (such as real-time video). They work by caching data in regional data centers to efficiently transfer large amounts of data. The focus of this design is throughput and scalability, resulting in a network most suitable for handling static objects, such as websites or pre-recorded videos.
Caching affects latency, and latency has nothing to do with delivering static elements (such as web pages and VOD). As real-time video experiences become more interactive, this means they increasingly rely on low-latency transmission. Even a delay of only one second can have a negative impact on the user experience and the usability of the application. If it is not live streaming, it cannot be broadcast live.
In order to solve this delay problem, we need to use a new solution: WebRTC. WebRTC is designed around low-latency streaming media. It can transmit real-time video with an end-to-end delay of less than 500 milliseconds, which is much faster than HLS transmission. Even if the latter is modified, it can only be reduced to 2-3 seconds at a minimum. Therefore, pure WebRTC services are expected to grow from 1.2% of total Multi-CDN traffic to 8.3%.
Unidirectional flow
In addition to high latency, CDN is actually designed around distributing data to clients instead of receiving information back. As the live experience becomes more interactive, integrating features such as zoom calls, co-viewing, and fan wall experiences into these events, the inability to stream content in multiple directions is a major damage to the usefulness of CNDs.
Each server in the CDN is essentially used as an ingestion point, which pushes the stream to the CDN for large-scale transmission. This means that it can distribute data from the origin to the edge very well, but it is not so good for the reverse transmission of flow information (back to the origin from the edge). Under this architecture, two-way communication is not efficient, because CDN is most suitable for broadcasting a single stream that is only watched by subscribers, rather than two-way chat, where subscribers are also broadcasting the video while subscribing to the video. The conversation goes back and forth between the two parties, so they must both send and receive video. This means that CDN does not provide this feature at all, and developers who want to build an interactive video experience have to piece together completely different technologies, which have always been prepared.
In the CDN model, the requested data needs to be transmitted from the origin to the edge. Once relayed to the nearest edge server, it must establish a separate connection with each client attempting to access the stream. This is called the "last mile" and is the main source of bandwidth consumption for CDN video streaming solutions. Some networks have found a way to solve this problem to reduce the cost of data transmission.
Some providers use WebRTC to increase CDN capacity. With WebRTC, up to 70% of peak traffic can be offloaded, which helps CDN suppliers avoid infrastructure upgrades and enables CDN distributors to use their existing budgets to do more.
For example, Peer5, StreamRoot, and StriveCast have created peer-to-peer shared networks to shift their total bandwidth consumption on CDN. They don't have to stream all the content from the edge to the client one-to-one, but create a data channel connection between all the clients that stream the same file. In this way, the video is sent from the source server to the edge server through the efficient block transmission HLS protocol. Once the subscriber pulls out those HLS (.ts) segments, it can establish a P2P connection on the WebRTC data channel to forward those segments to that peer. The peer can then establish a connection with the other party. Then repeat the connection process so that they can share the same video file. This means that each user does not have to redundantly pull out all data segments from the CDN (network that charges for data transmission).
Although these point-to-point mesh networks are effective for VOD transmission, they are not effective for low-latency real-time streaming media. First, they still use the HLS segment as the source of the stream, which will cause high latency problems. Second, this mesh network does not solve the problem of bidirectional flow. In addition, there is another emerging category of pure WebRTC basic providers, they do not use CDN at all, in fact they have completely replaced CDN.
Synchronization
Real-time delay also frees up the ability to properly synchronize with other data in the video stream. This opens up the addition of chat functions, real-time overlays and interactive graphics, virtual blackboards, real-time betting and auction bidding, GPS data and many other features. For example, a sports broadcast can have a real-time graphic display function, which can be synchronized with the latest state happening on the screen. The combination of proper synchronization and real-time delays can also prevent annoying spoilers, thus ensuring that the viewing experience of others is not disrupted. It can also ensure that the comments in the chat are consistent with the content currently displayed.
For these use cases, data can be sent through the WebRTC data channel or a separate websocket channel, which can be achieved using the SharedObjects method. SharedObjects manages the data feeds between multiple clients to achieve consistent data transmission. This ensures complete interaction between broadcasters, subscribers and any other functions.
More examples can be found on GitHub:
SharedObject：https://github.com/red5pro/streaming-html5/tree/master/src/page/test/sharedObject
SharedObject
iOS：https://github.com/red5pro/streaming-ios/tree/master/R5ProTestbed/Tests/SharedObject
Android：https://github.com/red5pro/streaming-android/tree/master/app/src/main/java/red5pro/org/testandroidproject/tests/SharedObjectTest
All these discussions about the limitations of CDN real-time streaming may give you the impression that they should be replaced by pure WebRTC solutions. However, they still play a very valuable role in video streaming. CDN is still useful for delivering video-on-demand content and static objects such as websites and static images. However, when it comes to dynamically updated elements (such as real-time video streams), CDN can never handle them correctly. Like many other technological elements, market demand has expanded and changed. CNDs are trying to adapt to this situation, but their basic HTTP-based architecture has caused high latency, unidirectional flow restrictions, and synchronization issues. These problems will be solved by the new live broadcast architecture model.
LiveVideoStackCon 2020 Beijing
October 31-November 1, 2020
Click [read original text] for more detailed information