A lot of developers mentioned that in the current open source player so widespread, why do we need to do the RTSP player of the research framework, research and open source player, what is good in the end? Here are some of our experiences. If you are interested, you can follow Github:
1. Low latency: If the delay is too large, it will seriously affect the experience. Therefore, low delay is a very important indicator to measure a good RTSP player. At present, the RTSP live playback delay of Daniu live SDK is better than that of open source player (daniu live SDK delay is about 1 second, open source player such as VLC, In addition, daniu Live SDK will not cause delay accumulation when it runs for a long time. Open source or third-party player is prone to delay accumulation when it runs for a long time.
2. Audio and video synchronization processing: In order to pursue low latency, most players do not even do audio and video synchronization, and directly play audio video, resulting in a/ V synchronization, and random timestamp jumping and other problems. Players provided by DANIu Live SDK have good timestamp synchronization and abnormal timestamp correction mechanisms;
Note: In ultra-low delay mode, 0 buffer can be used without audio and video synchronization:
3. Support for multi-instance: The RTSP live playback SDK provided by Daniu Live broadcast SDK supports multi-instance playing of RTSP stream data when the device performance allows. Most open source players are not friendly to multi-instance support;
4. Support buffer time Settings: In some scenarios with network jitter, players need to support buffer time Settings. Generally speaking, in milliseconds, open source players are not friendly enough to support buffer time Settings.
5. Real-time mute: For example, if RTSP streams are played in multiple Windows, the experience will be very bad if every audio is played, so the real-time mute function is very necessary. The open source player does not have the real-time mute function.
6. Video View rotation: many cameras due to installation restrictions, resulting in image inversion, so a good RTSP player should support real-time video view rotation (0° 90° 180° 270°), horizontal reversal, vertical reversal, open source or third-party players do not have this function;
7. Support audio/video data output after decoding: Daniu Live SDK has contacted many developers, hoping to obtain YUV or RGB data for face matching algorithm analysis while playing, which is not available in open source player;
8. Real-time snapshot: it is very necessary to capture interesting or important pictures in real time. Generally, players do not have the snapshot ability, and open source players do not have this function.
9. Network jitter handling (such as network disconnection and reconnection) : stable network handling mechanism and support, such as network disconnection and reconnection, etc. Open source player has poor support for network exception handling;
10. Long-term operation stability: the RTSP live broadcasting SDK provided by Daniu Live Broadcasting SDK is suitable for long-term operation, while the open source player has poor support for long-term operation stability;
11. Real-time download speed feedback: Daniu Live SDK provides real-time download callback of audio and video streams, and can set the callback interval to ensure real-time download speed feedback, so as to monitor network status. Open source player does not have this ability;
12. Abnormal state handling and Event state callback: if the playing process is interrupted, the player provided by DANIu Live SDK can call back the relevant state in real time to ensure that the upper module is aware of the processing, which is not well supported by the open source player;
13. Set the video fill mode (equal proportion display) : In many cases, some scenes need to be played with full view, and some scenes can be set to equal proportion display in order to prevent video stretching;
14. D3D detection: Generally speaking, most Windows on the market support D3D, some niche, only support GDI mode drawing, so in order to better compatibility, this interface is very necessary;
15. Real-time volume adjustment: Real-time volume adjustment, especially in multi-channel playing scenarios, such as large-screen window environment, can achieve better playing experience through fine-grained volume adjustment;
16. Playing only key frames: especially when playing large-screen multi-instance scenes, although our CPU usage is very low, it is a very good function point to play only key frames if we just view the general monitoring scene and achieve more playback. If original frames need to be played, real-time adjustment can be made.
17. Hard decoding for specific models: Hard decoding for specific models is also mainly used for multi-channel playback scenarios to achieve lower CPU usage through hard decoding;
18. Tcp-udp Settings: Considering that some servers or hardware devices or network environment for TCP, UDP support a better, we add the Settings interface;
19. Tcp-udp automatic switching: this is a more detailed interface. For example, TCP mode is set by default.
20. Setting of timeout time: for example, if the data cannot be received in 10-12 seconds, it will be automatically reconnected. Generally, open source players are not well supported.
conclusion
Based on the above factors, I want to do a RTSP or RTMP player, there are too many points to consider, especially in detail, the surface of open source provinces in the experience of the top 80%, but relatively large for most open source player system, suitable for on-demand playback, but support for live broadcast is very poor, if you want to do fine-grained control and bug fixes, The remaining 20 percent of the experience may take more effort from the r&d staff, but in other words, it is very good for the growth of the technical staff.