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

goding

见图，用的朋友发的 http://www.ogg.cn:8080/Upload/Download/RealPack-20070103.exe 插件

基本上还是cpu在工作，100%load，显卡基本没用。

[ 本帖最后由 goding 于 2008-12-17 01:27 编辑 ]

goding

转换完毕，晕死，原文件472M，转成的pspMP4文件569M。。。完全白转了

jocover

目前不支持GPU转码

digitalera

只能设置码率吗 ？

diablo_zzy

8.12正式版好像不支持，beta版才有gpu加速。。。

goding

原帖由 fevaoctwh 于 2008-12-17 01:57 发表
现发布后补丁……如果需要的话……

后补丁？发一下看看吧

注册名太长

原帖由 goding 于 2008-12-17 10:38 发表
后补丁？发一下看看吧

意思是软件先发布，不管有没有bug，问题等后续hotfix解决
avivo看看就好，不管吹的怎么天花乱坠.....实质上还是这样子........

koppie

第一, 官方并没有说支持rmvb. 网友自创的方法表面上是用了AVIVO GPU加速, 实质上只不过是套了个壳子的CPU转换而已. 转码(Transcoding)算法并不是先解码再编码的过程, 因为那样浪费了很多计算资源. GPU加速必须是催化剂里面提供的Transcoding算法.
而rmvb转码应该只是先解码再重编码, 文件大了是很可能的事情, 因为rmvb在同分辨率下码率要低

第二, 既然官方没有说, 有些网友如楼上的, 就不要说了. 官方列表里面支持的编码都有明显的提速, 尽管有些bug导致少许画面错误.

原帖由 goding 于 2008-12-17 01:01 发表
见图，用的朋友发的 http://www.ogg.cn:8080/Upload/Download/RealPack-20070103.exe 插件

基本上还是cpu在工作，100%load，显卡基本没用。

goding

ls高手分析的好，顶下

hamasaki

至少也要支持MP@LVL 3.0 B-F/REF/CABAC等一系列特性再说罢,裸奔BP的编码实在是有点敷衍了,Avivo速度飞上天我还是用avs+x264 /w cpu

koppie

附件是一篇2003年发在IEEE SP MAG上面的综述文章， 建议补习一下功课。“貌似”的东西还是不要轻易说为好，套用Prision Break最新一集的一句台词，我自己翻译过来，‘事情并不是像看上去的那样“。 125k的附件限制很可爱

摘抄一段
In all of these cases, it is always possible to use a cascaded pixel-domain approach that decodes the original signal, performs the appropriate intermediate processing (if any), and fully reencodes the processed signal subject to any new constraints. While we also view this as a form of transcoding, it is often very costly to do so and more efficient techniques are typically utilized. This quest for efficiency is the major driving force behind most of the transcoding activity that we have seen so far.

原帖由 westlee 于 2008-12-17 14:18 发表


貌似现在所有的视频压缩算法都是基于rgb数据的，能直接压缩已经压缩过的视频数据的东西好像还没研究出来。无论是音频转换还是图像转换，无论是有损压缩还是无损压缩，只要源数据是已经压缩过的，就必须解码成未做 ...

koppie

另外，Dolby TrueHD就是LPCM无损压缩得到的，而Dolby TrueHD的音频流却包含有损压缩的Dolby AC3，也就是说不需要任何解码过程，就可以直接从TrueHD中提取出压缩的AC3流，因此即使是音频也很少会做您说的低效工作

一般压缩的原理都是基于寻找更适合的一组基，进而可以用更小的维数去近似无损的信号。而Transcoding是在两种不同的基（坐标空间）下的变换，根本没有必要去转换到pixel空间（就好比我可以直接翻译英语为中文，却非要先翻译成所有人都懂的符号文字，再编码成中文一样）。例如基于小波基的压缩视频或者图片，一般都是可以直接通过丢弃高分辨率的部分，得到低分辨率的部分。

原帖由 westlee 于 2008-12-17 14:18 发表


貌似现在所有的视频压缩算法都是基于rgb数据的，能直接压缩已经压缩过的视频数据的东西好像还没研究出来。无论是音频转换还是图像转换，无论是有损压缩还是无损压缩，只要源数据是已经压缩过的，就必须解码成未做 ...

koppie

你说的东西基本概念上有很多问题.
1) 源数据流跟解码器有什么关系? 我需要解释什么问题?
2) AVIVO转换RMVB至其它编码, 由于ATI没有提供直接的Transcoding, 所以只能采用先解码再编码的方式。转换软件的界面基本上除了美工没有任何技术含量. 至于转码的核心算法, 由于我不是很了解软件的具体代码, 不敢妄加猜测哪个软件用了什么方法. 但是我知道的是, MPEG1/2/4/AVC/VC-1之间的Transcoding已有成熟算法. 如果上不了IEEExplore, 可以上Google Scholar搜索
3) MPEG各种标准都不是微软的标准, AVI/Matroska等封装格式也不是微软定义的. VC1算是微软主导的标准. 费力根据已有的各种算法编写各种编码之间的转码代码是有意义的, 因为用户的计算资源将达到最大程度上节约.
4) 音频的东西我只是针对你"无论是音频转换还是图像转换，无论是有损压缩还是无损压缩，只要源数据是已经压缩过的，就必须解码成未做任何压缩的数据然后再行压缩"这句话的.
5) 某些软件只是解码再编码, 本质上讲只需要调用第三方解码器和第三方编码器就可以了. 这样的东西很容易支持多种编码, 但是效率之低是明显的.
6) Transcoding算法核心与操作系统无关

原帖由 westlee 于 2008-12-18 09:23 发表


在你的这个流程里，如何识别解释源数据流？解码器自带？

现在一般的转换流程，都是用解码器（也就是顶楼提供的rmvb 编码解码组件），把某种特有的坐标系（这里是rmvb），转换为微软定义的标准数据流（这个标准 ...

koppie

当然对于区别很大的编码标准, 不通过中间的YUV进行转码是比较困难的(一般不用RGB色彩空间, YUV是RGB的线性变换).

原帖由 westlee 于 2008-12-18 09:23 发表


在你的这个流程里，如何识别解释源数据流？解码器自带？

现在一般的转换流程，都是用解码器（也就是顶楼提供的rmvb 编码解码组件），把某种特有的坐标系（这里是rmvb），转换为微软定义的标准数据流（这个标准 ...