Original (Author: winne)
In terms of coding and transmission of video, I will encounter mosaic, how to solve this problem, attract everyone's attention, the following is a simple analysis of the author, I hope everyone will discuss.
There is a mosaic: 1. CPU takes high, mosaic has lost some signals when encoding. (MPEG uses damage to damage)
2. The network link is not good, it must be dropped, this is to see the bottom protocol to drop the package. For TCP, it is generally re-issued so that it may cause a package wrong sequence, or may not be obtained, this is played in real time. Say, if you just buffer data, you will still have mosaic, and you can't even continue to play. If it is not real-time playback, it is a complete buffer playback form. If the package is sequence, but the data is complete, or can play normally, it is local data, of course, there is no mosaic, but if the data cannot be buffered, some players are The root cannot be played; for some real-time transport protocols, it is generally rare to dropped directly. If the subsequent data continues, it can also play. Therefore, if the network link is not good, it is impossible to completely solve the problem of online video playing mosaic. If it is particularly difficult, don't say mosaic, it will be problematic if you can continue to play. To solve such a problem, it is to achieve a good link to achieve a good connection.
3. Network transmission is likely to cause mosaic. When the TCP appears in mosaic, it is possible because there is no data, the compressed video data is mostly blocking compressed. Many times, it is normal to continue, if there is a pause, always show a still picture. It is also mosaic. The IP transport mechanism cannot guarantee that all packages are reached on time, while the display time of playback time makes the late package unable to play. In addition, as long as the network is unstable, there is a packet loss, mosaic is inevitable, but how much problems are generally, which is generally subjective. The RTP / RTCP is more unstable, but the data connection is more unstable, but the real-time data for transmitting large data, TCP is more stable due to multiple link confirmation and data re-acquisition mechanism, so that the data integrity is high. Relatively high real-time.
Try to avoid mosaic issues 1. Use QoS to ensure that channels can avoid mosaic. 2. If it is the mosaic generated by the error (UDP) during the network transmission, or add a layer of error correction, and the code stream is active. (TCP can be changed) 3. If you encounter the bandwidth In the case, the real-time live broadcast system may cause the server-side to increase the transmission buffer, which may cause slow motion. You need to actively throw the frame on the server side, actively throw the frame, so that the server sends the current aging frame. 4. If the receiving end encounters a packet loss, it begins to decompress from the next I frame, which will cause a relatively large pause (but if it is set, it is small, and the code rate will be increased.). Therefore, it is best to analyze the type of the frame where the packet is located. If it is the B frame, do not use the I frame, directly discard the down to remove the next frame, of course, if it is I or P frame, only Wait I frame. You can also adjust the decoding speed to control the decoding speed in a certain range, and start playing from the I frame when playing. 5. Reduce the network burden by reducing the yield rate. (For example: by interlaced scanning, the code rate is reduced. Reduce I frame interval. Adopt multi-level buffer, transmission rate adaptive adjustment mechanism, etc.)
