SPICE协议之流媒体算法

http://blog.csdn.net/haiq2006/article/details/50644956

流媒体维护是在渲染树维护过程中同时进行的。我们需要先了解几个知识：

1、可以作为流媒体数据的drawable一定是opaque drawable。

2、可以作为流媒体数据的drawable分为sized drawable和普通drawable，前者的尺寸比普通drawable增大，增大面积不超过一定门限（比如50%），且宽高都必须增大或者不变，不能有减小，覆盖的位置也必须包含普通drawable的位置。

3、流媒体使用CLIP来屏蔽不希望显示的部分。客户端收到CLIP消息之后所有的缓存帧也必须使用该CLIP。

流媒体启动有两个入口，一个是red_stream_maintenance()，另一个是red_use_stream_trace()。在这两个函数中会通过__red_is_next_stream_frame()看drawable是否可以是流媒体数据drawable，然后在red_stream_add_frame()进行以下判断：

首先判断是否为GRADUAL_LOW，如果不是我们可以称之为non_low drawable，有资格进行下个判断。接着判断是否需要复位计数器，如果超过RED_STREAM_FRAMES_RESET_CONDITION（100）个 drawable还没进入流媒体，就需要复位计数器重新开始判断。最后red_is_stream_start()判断是否出现了20帧以上数据，并且其中至少20%，也就是至少出现4个non_low_drawable。如果判断通过就启动流媒体。

流媒体维护入口函数是red_stream_maintenance()，如果prev drawable已经是 stream的current drawable了，则detach旧drawable，attach新drawable。注意后继发送函数marshall_qxl_drawable()中，如果是sized_stream drawable，那么即使在之前的流程中被detach掉，也会被作为流媒体数据编码发送出去。但是如果不是sized_stream drawable，发生这个场景之后就会作为普通drawable发送出去，这样就会潜在导致闪屏。这一点还需要请大牛看看是否理解错误。

流媒体detach还有几个地方，搜一下red_detach_streams_behind()就可以发现，一个是在渲染树维护的时候，如果不是opaque drawable就必须把重叠的stream detach掉。另一个是如果drawable依赖的区域有stream。这些detach并不是要去销毁流媒体，而是要避免依赖流媒体区域的drawable绘制错误，手段是把流媒体暂停等到非流drawable绘制完成之后再继续播放流。

谈流媒体还必须了解stream agent中clip和visible region的区别。clip是指客户端绘制流媒体时需要裁减掉哪些部分；visible region是过去所有流媒体数据drawable绘制区域的集合，也即是这片区域都是流媒体曾经画过的区域，都是有损压缩图。那么在流媒体销毁时，需要将visible region的部分需要用无损图填回去。

流媒体销毁条件是连续1秒钟没有sized或者普通drawable出现。red_handle_streams_timout()就会将stream销毁。

谈到流媒体的不足，首先是流媒体默认算法是MJPEG，大部分公司都将其改为H264。现在开源框架已经灵活支持多种编解码方式了，也许会有人考虑用VP8。其次sized_stream真是成也萧何败也萧何，它会使流媒体流畅度提高一个档次，但是对客户端硬解码带来了困难，因为很多硬解码器不支持流媒体尺寸的变化。如果客户端CPU给力就软解码吧。另一个不好的地方是sized stream的维护难度也大大高于非sized，因为这就需要频繁发送CLIP到客户端。最后就是在有些网页流视频的效果不佳，主要原因是网页视频中的绘制极为不规律，经常出现普通绘制覆盖了流媒体，那么就会发生CLIP操作裁去重叠部分，导致画面裂屏。只有到下一个流媒体数据drawable到来才能结束裂屏。