马赛克问题

原创（作者: winne )

视频的编码与传输方面，会遇到马赛克，怎么去解决这个问题，吸引了大家关注的目光，下面是笔者做的简单的分析，希望大家共同讨论。

出现马赛克的情况：
1. CPU占用高，马赛克在编码时就已经损失了部分信号。(mpeg采用有损压缩）

2. 网络链接不好肯定要出现掉包，这是就要看底层协议这么处理掉包了，对于TCP一般是重新再发，这样就可能造成包错序，也可能仍然不能获取，这对实时播放来说，如果刚好缓冲数据用完了，还是会出现马赛克，甚至不能继续播放了。如果不是实时播放，对是完全缓冲的播放形式，如果包错序，但数据完整，还是能正常播放的，播放的是本地数据，当然没有马赛克了，但如果数据不能缓冲完，有些播放器就根不能播放了；对于一些实时传输协议则一般是很少的重试就直接掉包处理了，如果后续数据继续来，还能播放下去。
所以在网络链接不好的情况下要完全解决网络视频播放马赛克的问题是不可能的，如果特别不好，不要说马赛克了，就是能不能持续播放都会成问题的。要解决这样的问题还是要成保障良好的链接来实现才是根本之途。

3. 网络传输有可能造成马赛克。
   当TCP出现马赛克的时候，有可能是因为没有数据, 压缩后的视频数据因为大多是分块压缩的，很多时候要连续的看才是正常的，如果有停顿，老是显示一个静止的画面其实也是马赛克。
IP传输机制不能保证所有包都按时到达，而播放时的显示时间的限制使得迟到的包无法播放。
此外只要网络不稳定，存在丢包，马赛克就不可避免，只是多少的问题，一般这样的判断是很主观的。rtp/rtcp由于是实时传输，数据连接更不稳定，但适合传输大数据量的实时数据，tcp由于存在多次的链路确认和数据重新获取机制，所以连接更稳定，适合要求数据完整性高，实时性相对不高的。

尽量避免马赛克的问题
1. 用QOS保证信道才能避免马赛克。
2. 如果是网络传输过程中的误码(UDP)产生的马赛克, 还是自己加入一层纠错, 对码流作效验. (TCP可以做到遇错重传)
3. 如果遇到的带宽低于码率的情况实时直播系统在服务器端可能造成发送缓冲无限增大，对于文件播放，可能会造成慢动作现象。需要在服务器端，根据一定的策略，主动扔帧，使服务器发送当前时效的帧。
4。接收端如果遇到丢包，就从下一个I帧开始解压，这会造成比较大的停顿（但如果为了较小停顿，把I帧间隔设小，又会增加码率）。所以最好要分析丢包所在帧的类型，如果是B帧，则不用等I帧，直接抛弃去解下一帧，当然如果是I或者P帧，也就只有等待I帧了。
也可以通过调节解码速度，使解码速度控制在一定的范围之中，并在开始播放的时候从I帧开始播放。
5. 通过降低码率，减轻网络负担。（譬如：通过隔行扫描，实现码率降低。减小I帧间隔。采用多级缓冲、发送速率自适应调整机制等等）

 

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/winne_ll/archive/2005/03/10/316387.aspx