一． 问题背景
目前流媒体播放的主要资源消耗处于服务端，包含解码、转码、压缩等，如果大量虚拟机同时播放流媒体，会造成服务端负载过重，影响流媒体播放效果。

现考虑将流媒体的解码和渲染都放在客户端处理，同时避免转码和压缩，这即需要进行流媒体重定向，将Guest OS内流媒体文件或网络流媒体资源传输到客户端处理，而又让用户感觉和在Guest OS内播放一致。

二． 当前方案描述

问题：1）增加网络负载
2）增加服务端CPU负载，降低虚拟机负载数量
3）增加延迟，抖动和丢包的几率

4）可能引起画质或音质降低

三． 新方案描述

主要变化：1）Local Media的码流通过RPC协议传输到Client的Media Engine；Net Media的URL通过RPC协议传输到Client的Media Engine后，由Media Engine直接请求Net Media码流
2）Server和Client之间新建一条TCP通道用来传输RPC Client和Service之间的通讯数据
3）Media Engine放在Client，Media Player通过RPC远程调用

4）增加Overlay Renderer用于在虚拟机系统画面之上，播放器位置渲染视频信息

四． 架构设计注意事项
基于组件的通用设计原则：
1）应该允许实现对其它远程计算机系统的支持
2）作为Spice的扩展，而非耦合其中的一部分

RPC系统的选择：
1）Apache Thrift with custom transport
2）Google Protocol Buffers marshaling with custom RPC and transport
 

Overlay Renderer画面和虚拟机系统画面的合成

五． 异常情况考虑
1） RPC链接断线后允许自动重连
2） 当RPC Service不可达时自动停止信息发送

3） RPC Service崩溃时自动恢复

六． 主要开发项
1） Media Engine开发或集成
2） RPC Service&Client开发或集成
3） Overlay Renderer开发，包括画面合成

其中2），3）涉及到和已有的spice-gtk,spice-server和remote-viewer的结合

备注：需要找到一款DirectShow Filter作为Media Engine的开发基础（如Lavfilter），以能够适应大多数播放器，替换其自带的解码器。从而在播放器解码前将流媒体发送到终端，这里有条件则直通，否则需要通过类似usbredir chardev的字符设备作为管道发送到spice server，再建新的channel发送到终端。

原文链接：https://blog.csdn.net/xx306/article/details/80160889