smp8635保存当前的屏幕（截屏）

嵌入式信息发布总是会有要将指定播放盒的当前屏幕内容截取下来并发送到后台，以便客户对播放器当前播放内容的监管。这里我设想过三种方案：

1） 由于在嵌入式系统中实现截屏还是有一定的难度的，特别是smp8635几乎是没有文档没有支持的情况。所以自然想过由播放器将当前盒子正在播放视频文件名、当前播放点，以及文字图片等等播放信息全部返回到后台，由后台来模拟。

2） 是增加成本，加入一个流编码设备到播放器，将播放器的输出实的编码并返回到后台。

3） 深入研究smp8635解码器，找出截屏的方法来。

 

针对以上三种方案分析如下：

第一种方案：带有一定的欺骗性，并且隐含的问题不少，并且很容易出现播放中途关了，还能截屏，或者截屏的视频与播放的内容不一样，另外服务器的压力很大，很难实现多人并发使用。

 

第二种方案：通过增加成本，在播放器中加入一个编码器，将播放器输出分流到编码器并以流媒体的方式发送到后，这种方案成本会增加不少，因为要做高清的编码，另外就是对带宽的要求，特别当在互联网络上时。

 

第三种方案：该种方案应是最佳的方案，以上两种方案也仅仅是当该方案不能实现时的备用方案。如果能实现第三种方案自然所有问题都不是问题。

 

所以我将精力都放在对RUA中的库、例子的源码分析上，将源码中可能的有关的代码标记下来，反复理解和实验，最后确定出一个截屏方案，从理论上说mainvideoscale,osdscale都有自已的surface ，然后再是通过mixer进行混合后直接输出，因面必须从scale的surface入手，实验发现osdscale的surface稳定很好控制，但video的surface有点麻烦，由于video的使用了DMA及smp8635内容的fifo机制，所以实际的地址在不断的变化，在源码分析过程中，发现不少scale新的功能，但没有任何文档的说明，也正是这些新的功能实现了对视频内容 的截取。

 

截取实现后又有新的问题，就是videoscale的色彩空间为yuv，还转成rgb，别外当放高清时单帧内容太大达到8M多，如何高效的解决这两个问题呢！！ 为了解决这两个问题我想到了gfx，使用2D加速器，将高清视频固定转换成640x480的rgb内容，如此，单帧内容太太减少，都 可以不用压制成jpg图片，直接发送到服务器，如此通信策略上会更加的简单。