其实吧，我又想的太美好了…
老式的Video作为显示对象的一种，由CPU负责渲染，某些情况下GPU承担一点事情。虽然可以实现很有创意的想法，但也因此导致CPU负担加大。
新式的StageVideo并不是一种显示对象，由GPU负责渲染，它和视频、硬件、平台都有着密切的关系。效率大幅提升的同时，也有很多限制和要求。
以下是StageVideo的一些限制
# StageVideo无法任意旋转，只能做直角旋转（每次转90度）
# StageVideo不能设置colorTransform和3D形变，也不能斜切(skew)。
# StageVideo不能设置透明，混合模式，滤镜，遮罩和scale9Grid。
# video无法被BitmapData.draw# video不能设置位图缓冲(bitmap-cached)。
# video不能嵌入到swf中。StageVideo只能通过NetStream播放。
# 由于基于底层硬件，所以有些颜色空间(color space)可能不支持。如果碰到这种情况Flash Player会选择一个合适的颜色空间。提供了查询颜色空间的API。
# 播放video的个数根据平台不同是有区别的。大多数手机系统，只有一个。也就是说，即使有几个SWF同时播放，也只有一个可以享受到硬件加速。
# 为确保Flash Player在桌面和TV设备的兼容性，请设置wmode=direct
# 避免wmode=transparent。有些平台比如Google TV不支持这个。wmod=window都支持。
强烈建议设置wmode=direct，其他如wmode=window,transparent,opaque，都有可能导致StageVideo不可用。
关于API
StageVideo直接由FP创建，我们无法实例化。创建个数由所在平台决定，保存于 stage.stageVideos:Vector<StageVideo> 。
一般来说，并不是SWF一运行就马上创建好的，什么时候创建好，需要通过监听 StageVideoAvailabilityEvent.STAGE_VIDEO_AVAILABILITY 事件。
这个事件中，会告知StageVideo是否可用
可用是指，至少创建了一个StageVideo对象等待被使用，即 stage.stageVideos.length > 0
注意StageVideoEvent还有几个和渲染相关的事件
这几个事件当NetStream一被附在StageVideo对象上时，就会触发。
一旦触发StageVideoEvent.RENDER_STATUS_SOFTWARE，可以尝试切换另一个视频文件，比如H.264的，也就是能让硬件加速发生几率更高些。
如果硬件加速突然失灵了，也可以马上切换到一个无法加速的视频，来强制转换为软件解码。
关于resize，因为StageVideo不是一个显示对象，所以width,height,scale等之类的属性都不能用，应该采用viewPort，其类型是Rectangle
一个StageVideo对象有如下属性
colorSpaces:Vector.<String>: 硬件可用的颜色空间。
depth:int: 多个StageVideo之间可以切换的层深控制。
pan:Point: 类似设置x/y。
videoHeight:int: 视频流的高度，只读。
videoWidth int: 视频流的宽度，只读。
viewport:Rectangle: 类似设置width/height。
zoom:Point: 类似设置scaleX/scaleY。默认(1,1)。
关于颜色空间
播放器会根据视频所用的颜色空间找到匹配的，但如果不一致会找相似的。
比如某个视频采用的是”BT.709″，那么会匹配BT601，而这时你可以选择放弃采用软件解码，或者接受颜色误差。
如果匹配结果是UNKNOWN，则表明没法提供一个可用的颜色空间。
更多具体详细的就看原文吧
原文链接：https://www.cnblogs.com/holybozo/archive/2010/12/09/1901265.html
原创文章，作者：优速盾-小U，如若转载，请注明出处：https://www.cdnb.net/bbs/archives/8301
