POPPUR爱换

标题: Avivo Video转换rmvb-pspMP4效率问题？4850+8.12 [打印本页]

作者: goding 时间: 2008-12-17 01:01
标题: Avivo Video转换rmvb-pspMP4效率问题？4850+8.12
见图，用的朋友发的 http://www.ogg.cn:8080/Upload/Download/RealPack-20070103.exe 插件

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

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

作者: goding 时间: 2008-12-17 01:08
转换完毕，晕死，原文件472M，转成的pspMP4文件569M。。。完全白转了

作者: fevaoctwh 时间: 2008-12-17 01:57
提示: 作者被禁止或删除内容自动屏蔽

作者: jocover 时间: 2008-12-17 08:37
目前不支持GPU转码

作者: digitalera 时间: 2008-12-17 09:45
只能设置码率吗？

作者: diablo_zzy 时间: 2008-12-17 09:48
8.12正式版好像不支持，beta版才有gpu加速。。。

作者: goding 时间: 2008-12-17 10:38

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

后补丁？发一下看看吧

作者: 注册名太长 时间: 2008-12-17 10:55

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

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

作者: koppie 时间: 2008-12-17 11:25
第一, 官方并没有说支持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，显卡基本没用。

作者: westlee 时间: 2008-12-17 14:18
提示: 作者被禁止或删除内容自动屏蔽

作者: goding 时间: 2008-12-17 20:29
ls高手分析的好，顶下

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

作者: koppie 时间: 2008-12-18 06:10
附件是一篇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 时间: 2008-12-18 06:21
另外，Dolby TrueHD就是LPCM无损压缩得到的，而Dolby TrueHD的音频流却包含有损压缩的Dolby AC3，也就是说不需要任何解码过程，就可以直接从TrueHD中提取出压缩的AC3流，因此即使是音频也很少会做您说的低效工作

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

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

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

作者: westlee 时间: 2008-12-18 09:23
提示: 作者被禁止或删除内容自动屏蔽

作者: koppie 时间: 2008-12-18 12:59
你说的东西基本概念上有很多问题.
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 时间: 2008-12-18 13:21
当然对于区别很大的编码标准, 不通过中间的YUV进行转码是比较困难的(一般不用RGB色彩空间, YUV是RGB的线性变换).

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

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

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

作者: 天下18 时间: 2008-12-18 13:29
提示: 作者被禁止或删除内容自动屏蔽

作者: westlee 时间: 2008-12-18 16:49
提示: 作者被禁止或删除内容自动屏蔽

作者: westlee 时间: 2008-12-18 22:39
提示: 作者被禁止或删除内容自动屏蔽

作者: cellwing 时间: 2008-12-18 23:39
提示: 作者被禁止或删除内容自动屏蔽

作者: jhj9 时间: 2008-12-19 01:00

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

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

作者: 奶牛老仙 时间: 2008-12-19 01:00
提示: 作者被禁止或删除内容自动屏蔽

作者: jhj9 时间: 2008-12-19 01:03

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

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

作者: westlee 时间: 2008-12-19 08:30
提示: 作者被禁止或删除内容自动屏蔽

作者: jhj9 时间: 2008-12-19 11:10

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

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

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

欢迎光临 POPPUR爱换 (https://we.poppur.com/)