spice局部视频流的判断改进

本文地址：https://blog.csdn.net/MagicFMan/article/details/127825558，严禁转载，后果自负

背景

当前spice判断一个连续图片是不是视频数据的方法：
连续帧满足：
（1） 图片width、height都相等；
（2） 图片绘制的目标区域都相同。

问题

（1） 当播放器在播放视频时，移动、窗口尺寸微调都会导致：退出流->检测流->进流；
（2） 遇到过chrome网页播放视频的一个场景，视频在播放时，区域位置会不断发生几个像素偏移，造成chrome视频频繁退流、进流。
（3） 窗口播放时，在进流之前，不断移动窗口，是无法检测进入到局部流的。 这些场景都会造成流的频繁退出，同时在检测进流的过程中，大量图片采用普通压缩方式，造成带宽峰值升高。

分析

进流的目的：采用h264压缩，降低带宽。采用h264压缩的条件：连续图片需要有固定的width和height。
也就是说我们在检测的时候可以去掉目标区域相同这一限制。
当前去掉目标区域限制的影响：桌面上同时播放两个大小相同的流就会进入同一个流，造成关键帧增多，影响带宽。

问题就简化为：当一条指令下发时，如果当前有个流的图片大小和该指令相同，但是区域不相同，如何判断指令是不是属于这个流。即：该指令是由流移动、或窗口大小发生变化而来，还是一个新的流。

从使用者角度分析：
区分窗口移动与是否是两个流：
窗口移动：
假设frame1先来，移动位置后来frame2，此时他的上一帧frame1将完全不可见。

两个交叉流：
视频A的A1先来，接下来视频B的B1，此时流的上一帧A1是可见的。

指令角度：
Win7下：
（1） 窗口移动时copy_bits指令，如果copybits指令的源包含视频位置，则视频调整视频位置，接下来来的帧就与视频位置吻合了。
（2） 窗口大小调整，下发drawcopy指令，此时判断流的最近的一帧是否被完全覆盖，判断：其region区域为空或者drawable已经从指令树上删除。

Win10下：
只有drawcopy指令，采用win7下场景(2)的方式。

客户端限制

当前客户端流创建后位置就无法发生改变，如果使用该方案的话，客户端需要进行相应修改。