移动播放器面临的情况：
1、渲染时按照时间戳渲染
2、播放端来的流是抖动不平滑的，可快可慢，可能延时只来一帧，后紧跟N帧。
VLC针对抖动的处理方式
1、收流时在收到第一帧TS1的时候取本地绝对时间，作为绝对时戳absPts1，第二帧TS2到来时取本地绝对时戳absPts2。差值计算absDvalue = absPts2 - absPts1 TsDvalue = Ts2-Ts1 ，如果absDvalue > TsDvalue 说明数据延时到来，否则时提前到来。这种方式的缺陷是：以第一帧作为参考，可能第一帧本身就晚到了。
2、将absDvalue值累计到clock机制里，clock里会计算这种误差，反应到送渲染的时戳里，这样达到播放端与发流端的速度保持一致，减少缓冲数据的堆积（即时钟漂移策略）。这样做对于视频流源端是IPC等摄像机来说是合理的，且是有优势的。但是对于移动手机作为采集端，加入了调整帧率、码率等手段做网络动态适配时，VLC的这些优势就变成了劣势。
移动端采集方案：动态监测网络状态，网络状态较差时
1、自动降低帧率、码率；
2、采集端产生堆积数据，导致播放端接收到的数据延时较大。如果此时网络情况突然改善，播放端会收到一大串的帧，类似脉冲式的效果。
移动播放端的改进
1、考虑到音视频同步问题，以音频作为调整的触发点；
2、收流侧实时统计每帧音频是否延时，计算延时时间。基准的缓存时间为500ms，如果延时时间>缓存时间，连续500ms时，可以增加缓存时间（即后续每帧的绝对时戳=curpts+新缓存时间），相当于渲染时间延后了。使用该方式可以在网络情况差的情况下，平滑播放但整体延时了。
3、当网络情况好转时，同样的方式计算出延时间<缓存时间，连续500ms时，可以减少缓存时间（即后续每帧的绝对时戳=curpts+新缓存时间（新的缓存时间比原先的缓存时间小）），并且通知渲染模块，调整已有的渲染队列中数据的pts值，这样启到加速渲染的效果。
4、注意：快速增加延时，但缓慢减少延时。如快速减少延时，会导致在网络情况好的时候，音视频卡顿。
1、渲染时按照时间戳渲染
2、播放端来的流是抖动不平滑的，可快可慢，可能延时只来一帧，后紧跟N帧。
VLC针对抖动的处理方式
1、收流时在收到第一帧TS1的时候取本地绝对时间，作为绝对时戳absPts1，第二帧TS2到来时取本地绝对时戳absPts2。差值计算absDvalue = absPts2 - absPts1 TsDvalue = Ts2-Ts1 ，如果absDvalue > TsDvalue 说明数据延时到来，否则时提前到来。这种方式的缺陷是：以第一帧作为参考，可能第一帧本身就晚到了。
2、将absDvalue值累计到clock机制里，clock里会计算这种误差，反应到送渲染的时戳里，这样达到播放端与发流端的速度保持一致，减少缓冲数据的堆积（即时钟漂移策略）。这样做对于视频流源端是IPC等摄像机来说是合理的，且是有优势的。但是对于移动手机作为采集端，加入了调整帧率、码率等手段做网络动态适配时，VLC的这些优势就变成了劣势。
移动端采集方案：动态监测网络状态，网络状态较差时
1、自动降低帧率、码率；
2、采集端产生堆积数据，导致播放端接收到的数据延时较大。如果此时网络情况突然改善，播放端会收到一大串的帧，类似脉冲式的效果。
移动播放端的改进
1、考虑到音视频同步问题，以音频作为调整的触发点；
2、收流侧实时统计每帧音频是否延时，计算延时时间。基准的缓存时间为500ms，如果延时时间>缓存时间，连续500ms时，可以增加缓存时间（即后续每帧的绝对时戳=curpts+新缓存时间），相当于渲染时间延后了。使用该方式可以在网络情况差的情况下，平滑播放但整体延时了。
3、当网络情况好转时，同样的方式计算出延时间<缓存时间，连续500ms时，可以减少缓存时间（即后续每帧的绝对时戳=curpts+新缓存时间（新的缓存时间比原先的缓存时间小）），并且通知渲染模块，调整已有的渲染队列中数据的pts值，这样启到加速渲染的效果。
4、注意：快速增加延时，但缓慢减少延时。如快速减少延时，会导致在网络情况好的时候，音视频卡顿。
