Recalling that I started EasyDarwin in 2012, there should be no concept of H5 at the time. RTSP/RTP are relatively new technologies. I used live555's DarwinInjector for RTSP streaming, EasyDarwin as a streaming media server, and live555's RTSPClient. As a client, I started to build a complete streaming media server system.
Later, in 2014, I felt that DarwinInjector was inconvenient to use and poorly controllable (mainly because the structure of live555 was too complicated and it was difficult to change), so I developed my own RTSP push SDK: EasyPusher, and playback SDK: EasyPlayer, the perfect combination of EasyPusher+EasyDarwin+EasyPlayer, helped us build a lot of live broadcast systems, with low latency, distributed, load-balanced, everything can work, but at that time as long as the delay is within 1s, it is considered very Low latency;
In 2017, we began to turn to the RTMP streaming + playback field, copying the previous successful experience of RTSP, we soon made the RTMP live streaming effect almost the same as RTSP, of course, we also experienced a lot of twists and turns. Question, we have developed a whole line of "EasyRTMP push stream+EasyDSS streaming media server+EasyPlayer player". This architecture foundation is currently used in all our products, RTMP push stream input, EasyDSS synchronous output RTSP, RTMP, Protocol videos such as HTTP-FLV and HLS are suitable for the playback needs of all platforms and all terminals.
It's now 2020. Since the beginning of the year, we have overcome what we think is the last mountain of this architecture: H5's H.265 playback problem. We have felt that this path of audio and video transmission is the same?
Later, we made the EasyRTC video conference system, which is completely different from the traditional live broadcast system. The traditional live broadcast system gives people the feeling that there will always be hiccups during the live broadcast, and you want to take a long time. Smooth playback is almost difficult; and when we experience the EasyRTC video conference effect, we feel very comfortable. The entire call process is smooth, clear, and hiccups. We considered this effect if it could be transplanted. In the current live broadcast field, isn't the effect disruptive?
Finally, today, our RTC team gave me a few breakthrough images:
Our RTC live broadcast process ran through, and the effect is very good, the delay of the whole process is basically controlled within 200ms, and there is a very large room for optimization~
I believe that within this year, we should be able to launch RTC-type technical products to help more application scenarios and improve existing bottlenecks;