Avivo Video转换rmvb-pspMP4效率问题？4850+8.12

jhj9

原帖由 koppie 于 2008-12-18 12:59 发表
你说的东西基本概念上有很多问题.
1) 源数据流跟解码器有什么关系? 我需要解释什么问题?
2) AVIVO转换RMVB至其它编码, 由于ATI没有提供直接的Transcoding, 所以只能采用先解码再编码的方式。转换软件的界面基本上除 ...

如果你的转码器存在N种编码，那么你就需要n*(n-1)个针对性编写的转码模块。
而这种事情显然不是正常人回去干的。
现在各种编码都有官方的编码器和解码器，那么转成中间的RAW格式，再压缩是再正常不过的地球人会去选择的合理行为。因为这时转码软件完全无需编写n*(n-1)个彻底不同，而且都需要极端优化甚至支持各种硬件加速的转换代码。只要从别人那里借用n种编码器+解码器就好。
现实中，转码器如果对于某一种或几种转换方式认为特别常用，而且开发者也特别有心得和技巧，那么还是可能采用你说的方式的。但一旦源编码和目标编码不满足特定的条件，就只能选择中间RAW格式来作为标准处理方案了，这种做法得到的兼容性是无与伦比的。

jhj9

原帖由 cellwing 于 2008-12-18 23:39 发表
竟然还有这么多菜人不知道视频压缩的工作原理！rmvb是封闭格式，很难很难很难作出能用gpu硬加速的软件

解码采用通用的codec生成中间raw格式，再利用硬件加速编码也是可行的，而且也能带来很高的效率，毕竟压缩比解码运算量大不少。
比如badaboom在处理非MPEG类的输入源时，就是使用的这种方法。

jhj9

原帖由 koppie 于 2008-12-18 13:21 发表
当然对于区别很大的编码标准, 不通过中间的YUV进行转码是比较困难的(一般不用RGB色彩空间, YUV是RGB的线性变换).

可以说，不少编码方式的区别就是很大的
比如MPEG的8x8块划分方式，就未必能很好的和别的压缩算法匹配上，不过光是这个问题的话也不是不能解决，但视频文件中还有更致命的问题。
这个致命问题就是这里讨论的是视频数据，而不是静态图像数据，因此除了可能几秒才出现一次的静态帧以外，视频数据流基本都是由指定区域的更新子块或者运动矢量的运动预测帧信息组成的。
这些内容在不同格式的视频文件中恐怕就没法直接转换了，因为很可能其中一种格式根本就不支持这个。
比如更新的子块坐标和大小，有些算法可能随意指定以获得更准确的结果或更高的压缩率，而有些算法则有必须是8的整倍数之类的限制，甚至可能根本就不支持区域更新。
这些因素加起来，导致了你一开始提出的直接转换没有中间结果的方式在现实中根本就没有可实施性。

[ 本帖最后由 jhj9 于 2008-12-19 11:12 编辑 ]