求科普：移动设备的硬解能力与什么相关（已转型为液内讲
硬件层面上，是与CPU相关还是与GPU相关？软件层面上，是否与ROM（官方/CM等）相关？
具体说的话，比如我手上的DZ（MSM7230/Adreno205），刷CM，AVC+AAC片源，720P只能到L3.2@Main/High，480P通吃，这是哪方面的因素限制的？ 硬解，硬件解压，自然这能力是和硬解的硬件相关了，95年以前解码都是所谓vcd解压卡干的，现在pc都是用GPU来干
至于手机，如果真的可以硬解，可能是和GPU相关，或者哪个手机加个芯片专门解码也可以
软解，软件解压，所有软件都是跑在CPU上的，这能力自然和CPU相关~ 简单来说，硬解就是非CPU直接参与处理的解码方式。楼上也说很清楚了。
那这么说来的话软件方面则播放器，解码器，驱动，系统等等必须要输出能够给硬解芯片识别并且运算的数据，然后它再反馈一个数据让你的系统驱动，解码器，播放器识别。（大意，专业人士轻拍）。也就是像你说的和ROM存在相关。
不过相关程度怎样就是另一回事了XD 回楼上：
移动设备上硬解肯定和软件有关，因为这里的软件包含了底层驱动，就像你PC上A/N卡不装驱动照样不能硬解。
手机上的硬解视频对压制参数有要求，我举的例子里是720P@L3.2，再高的level直接拒绝播放，而不是掉帧/花屏。想问问这个阈值到底由谁决定？芯片还是rom？ 引用第3楼hhtrivial于2011-11-24 02:43发表的 :
回楼上：
移动设备上硬解肯定和软件有关，因为这里的软件包含了底层驱动，就像你PC上A/N卡不装驱动照样不能硬解。
手机上的硬解视频对压制参数有要求，我举的例子里是720P@L3.2，再高的level直接拒绝播放，而不是掉帧/花屏。想问问这个阈值到底由谁决定？芯片还是rom？ http://bbs.saraba1st.com/2b/images/back.gif
类比于GPU支持DX版本
一般是处理芯片不够强劲所以没法播 手机硬解码和CPU有关（和解码模块封装在一起），和GPU无关，要了解这些你可以翻看各个手机处理器的构架封装。
手机的硬解码是个独立的模块进行的（和CPU封装在一起），但是CPU本身靠指令集也是支持视频加速的，而这种加速会吃CPU的频率。
（比如ARM9构架处理器，支持Xvid解码加速，300mhz就可以流畅播放QVGA上千码率的Xvid；）
（比如ARM11构架处理器，除了更好的支持Xvid解码加速，还支持H264 Baseline2.1解码加速，几千码率很轻松，只是不能超过Baseline2.1的规范；）
（比如酷睿I系列SNB构架处理器，SSE4指令集带了高清解码加速，在CPU占用25-50%的情况下就可以流畅软解码1080P，而老酷睿CPU放高清却很卡。）
以上例子都是CPU靠指令集加速解码的，都是需要CPU进行处理的，当视频码率高的时候CPU负担就越大，而且对视频的编码有严格的要求。
硬解码自然是最好的解决方法，省电不说对各种级别编码支持也完善，码率方面轻松播放20mbps以上的片子。
现在主流手机都可以降CPU降低到200mhz进行硬解码1080P影片。判断是否调用硬解码模块而非CPU指令集加速，降低CPU频率进行播放可以很快的判断出来。
当碰到CPU加速、硬解码模块都不支持的视频格式时候（RMVB、VP6），就是低效率的纯跑频率了。
记得当年我赛扬300A超550，看个平均450kbps码率的rm动画片，在画面复杂的地方都丢帧... ...
至于播放器方面，官方为了用户更好的体验，一般都做了很多限制。
而用户可以下载很多第三方播放器，这些播放器听朋友说大都是调用系统的解码方案，所以播放方面没有啥突破，基本和官方播放器差不多。
而少数播放器，开发者貌似从写了驱动，调用自己的解码方案，可以做到突破官方播放器的限制，达到硬件能支持什么就能播放什么的程度。 LS民科？ 跟芯片用的解码ip核和运行频率和软件效率有关
Re: [手机]求科普：移动设备的硬解能力与什么相关
基本正确，不过RMVB在手机上属于可用CPU加速，尤其是A8架构的，基本都支持NEON指令集加速。
刚才用yp-g1搜了个emd字幕组的天元突破进行播放,rmvb 125mb。
画面复杂时候拖慢,导致音画不同步了。画面是锯齿感,没有过滤画面吗。
播放器用的是dice,不知道播放rmvb用那个播放器好?
另外我看他们i9000在线看flash都还能看啊,我yp-g1是个在线视频就卡爆了,在别说标清啥的了。
2.2.1版本太低的原因?
换了个mobo流畅播放了。
不知道是rmvb编码渣,还是播放器问题,感觉画蛮糟糕,模糊+色块+马赛克。
回头在PC上面看了下这个rmvb视频，完全没有大色块马赛克... ... 从这楼来看硬解的理解果然很扭曲，不过对于国内的用户，问题更多出在千奇百怪的数据结构上 引用第3楼hhtrivial于2011-11-24 02:43发表的 :
回楼上：
移动设备上硬解肯定和软件有关，因为这里的软件包含了底层驱动，就像你PC上A/N卡不装驱动照样不能硬解。
手机上的硬解视频对压制参数有要求，我举的例子里是720P@L3.2，再高的level直接拒绝播放，而不是掉帧/花屏。想问问这个阈值到底由谁决定？芯片还是rom？ images/back.gif
都有关
比较典型的例子是DXVA仅仅支持到一定Profile的硬解，再高就算硬件和驱动都支持也不给你搞
另外GPU这东西其实不管视频解码，虽然硬解的芯片也在显卡上…… 引用第5楼liaojings1于2011-11-24 03:04发表的:
手机硬解码和CPU有关（和解码模块封装在一起），和GPU无关，要了解这些你可以翻看各个手机处理器的构架封装。
手机的硬解码是个独立的模块进行的（和CPU封装在一起），但是CPU本身靠指令集也是支持视频加速的，而这种加速会吃CPU的频率。
（比如ARM9构架处理器，支持Xvid解码加速，300mhz就可以流畅播放QVGA上千码率的Xvid；）
（比如ARM11构架处理器，除了更好的支持Xvid解码加速，还支持H264 Baseline2.1解码加速，几千码率很轻松，只是不能超过Baseline2.1的规范；）
（比如酷睿I系列SNB构架处理器，SSE4指令集带了高清解码加速，在CPU占用25-50%的情况下就可以流畅软解码1080P，而老酷睿CPU放高清却很卡。）
....... images/back.gif
有些用词不准确哦～
首先介绍下CPU，不感兴趣可以直接跳过下面几段～
事实上，我们通常意义上理解的CPU，是由微控制器发展而来的，主要的功能是处理控制类型的任务，对应到现在就是我们常说的程序流。通俗点讲就是处理类似于“我下午工作完就回家，然后根据吃完饭的时间，决定是看动画还是直接睡觉”的任务。在这个例子里，做的事情有这样的特点：
1.任务有严格的先后关系，只有“工作”完了才能“回家”，只有“回家”了才能“吃晚饭”...这些任务不能够打乱顺序，也很难同时执行
2.任务有大量的条件判断，例如“看动画”或者“睡觉”，必须根据“吃完饭”之后的时间来定。
这些特点反映在程序里就是if-else，for这样的循环判断语句，这些语句编译成CPU的命令就是分支跳转（Branch或者Jump）
因此，CPU的主要工作是针对程序流的执行进行优化，这里面诞生了很多技术，比如说奔腾Pro的分支预测，按照上面的例子就是“CPU会分析过去一个月我吃完晚饭的时间，发现这个家伙每天晚饭吃完后时间很早，所以CPU预测他今天也看动画”。
而视频解码任务的特点与上面所说的程序流迥然不同。它没有明显的先后关系，也没有条件判断，比如处理一帧的画面，这么多像素点，可以一起解码，不同的像素点之间没有先后关系。具有这种特点的任务一般是科学计算、信号处理或者多媒体。执行多媒体任务，处理器需要有强大的并行能力。硬件上可以专门针对某种解码算法写单独的硬件ASIC逻辑，不需要将解码算法分解成加减乘除等运算，速度最快代价最小，但是没有通用性。
常用方法是采用数字信号处理器（DSP）。DSP和CPU一样，执行接收到的指令，但相比于偏向于控制的CPU的指令，DSP指令更偏重于算术运算，支持的数据宽度更大，运算更复杂。软件将常见的编解码算法分解成DSP支持的运算，然后通过DSP执行。DSP的常用技术有SIMD（单指令多数据，比如“一次加16个数据的加法”，这样就可以一次处理16个像素点），VLIW（超长指令字，一条指令包含可以并行执行的多次运算）等等。GPU就是一种典型的DSP，比如NV的GPU内置了几十上百个处理单元，能够并行处理大量的图形图像数据，在这种任务上的性能要高于CPU。
为了增强CPU对于大数据量的并行任务的处理能力，现在流行在处理器里面增加协处理器接口，可以理解为内部的一个协助CPU的小单元。协处理器执行浮点计算和SIMD计算指令，能够部分增强多媒体的性能。这个接口是CPU内部的接口，不在外部总线上，因此协处理器算CPU内部单元。ARM的NEON就是协处理器。
不知道写的是否通俗，反正在我能力内尽量解答。 感谢楼上几位的热心解答。讨论的展开已经超出我的预期了，肯定是我提问的方式不对……
有人提到了，主流手机可硬解1080p，我想其应该仅限于流媒体吧，难以想象下载到的1080p是baseline或main profile的。要转码的话，与其转成1080p baseline，还不如直接转成WVGA或qHD，节省码率。
作为一介普通消费者&硬解省电党，我面对的是这样一个问题：如何从广告资料中获得某设备硬解各分辨率AVC片源时的最高level和profile限制？目前国内外的测评很少有详述这方面的，一般都是“xx码率的1080p流畅播放”这种模棱两可的话。（如果a设备使用某芯片方案能硬解720p@high4.1，那么使用相同方案的b设备是否也有同样的硬解能力？还是说，即使用的同一套芯片方案，不同厂商的rom会导致不同的硬解限制？ 我对手机不熟
如果所谓的“手机硬解”是靠CPU的话
这种硬解就是噱头，还是软解
另外，硬解软解从用户体验方面有啥区别了，我的PC硬解1080p各种花屏卡屏，软解流畅清晰且CPU占用率不超过50%~~~~ IP4可硬解720P 1080P的H264编码MP4
但是对LV有限制
好像不能超过3.1 管你解码IP是和什么绑一起的，有区别吗？只要解码过程能在硬件级别大量并行化，效率和能耗都有显著改善 引用第18楼66666于2011-11-24 15:54发表的 :
手机硬解和显卡硬解本质上没有区别，硬解花屏马赛克等问题你要找微软和压制人员去算账。 images/back.gif
不找黄老板和小AA和Outel吗……
（黄老板的坑爹2，小AA一直不支持高Level，Outel的硬解整个一杯具还不如iPad1） 引用第15楼adrftgyh于2011-11-24 15:30发表的:
我对手机不熟
如果所谓的“手机硬解”是靠CPU的话
这种硬解就是噱头，还是软解
....... images/back.gif
降频到200MHz，硬解仍能流畅播放，软解就吃瘪。硬解最大的优势就是省电（移动设备受益
引用第14楼66666于2011-11-24 14:55发表的 回 13楼(hhtrivial) 的帖子 :
Supported devices
* Honeycomb tables(TF101,GT10.1,Iconia500) : 720p High@4.1 ( no weighted prediction )
* Samsung Galaxy S2 : 1080p H.264 high@5.1/MPEG-4,1080i AVCHD MTS
* Samsung Galaxy S and variants : 720p H.264 High@5.1
* Samsung Galaxy Tab(7') : 1080p H.264 High@5.1. 1080i have interlace artifacts.
....... images/back.gif
求渔
放狗搜了一下，这个是diceplayer的作者写的。又跑到高通主页上下了白皮书来看，发现也是含糊其辞 关于PC在线Flash花屏问题，主要问题是视频的B帧、Ref关键帧参数。
PC现在的硬解码是不支持高B帧、高Ref关键帧的，具体超过多少不知道，我自己压的B15、Ref15一播放就卡屏。
网上看视频花屏的，你可以缓存视频后查看参数，播放器调节成软解码即可正常播放。
而手机硬解码出乎意料的可以支持这些高参数。。。
最近开始流行的10bit压片也都是高B帧、高Ref，这也是PC平台看10bit片子只能软解码的原因。
我使用的PC机器是AMD第二代视频硬解码，至于最新的第三视频硬解码支持高参数就不清楚了：
◇延续UVD3—高清解码依然给力
http://tech.163.com/digi/11/0630/14/77Q77OVK001618J7_5.html
厂商一般只会给出一个保守的播放能力，可能是为了用户体验，也可能是为了下一个产品增加卖点。
同处型号处理器也可能存在解码能力不同，之前论坛就讨论过双蜂鸟C110 C111硬解码1080P的问题，结果三星I9000（C111）不支持1080P硬解码，M9（C110）支持1080P硬解码。
如何获知这些产品的解码能力，最好请有机器的人帮忙测试吧。
“Samsung Galaxy S and variants : 720p H.264 High@5.1”
Galaxy S的各种马甲，只要拆机图是C110处理器的产品都是支持1080P硬解码的，反之不支持。 引用第20楼hhtrivial于2011-11-24 16:00发表的:
求渔
放狗搜了一下，这个是diceplayer的作者写的。又跑到高通主页上下了白皮书来看，发现也是含糊其辞
images/back.gif
如果你所谓的硬解软解都是依赖CPU的话
那么这种硬解其实只是代码和效率的优化吧？？？ 光720p就要多大的屏了啊。。。 引用第21楼liaojings1于2011-11-24 16:16发表的:
关于PC在线Flash花屏问题，主要问题是视频的B帧、Ref关键帧参数。
PC现在的硬解码是不支持高B帧、高Ref关键帧的，具体超过多少不知道，我自己压的B15、Ref15一播放就卡屏。
网上看视频花屏的，你可以缓存视频后查看参数，播放器调节成软解码即可正常播放。
而手机硬解码出乎意料的可以支持这些高参数。。。
最近开始流行的10bit压片也都是高B帧、高Ref，这也是PC平台看10bit片子只能软解码的原因。
....... images/back.gif
10bit不能硬解是ref bf的关系,咱喷出来了 引用第12楼dennisyy于2011-11-24 12:44发表的 :
有些用词不准确哦～
....... images/back.gif
一句话概括：标量机VS向量机
引用第15楼adrftgyh于2011-11-24 15:30发表的 :
我对手机不熟
如果所谓的“手机硬解”是靠CPU的话
这种硬解就是噱头，还是软解
....... images/back.gif
严格来说不一定
ARM这个东西很神奇，是可以带DSP的。要使用ARM片子本身那肯定是软解，上DSP就不一定了
这样的话视频解码的硬件还是在那个处理器上，所以硬要说是CPU在搞也不能算太离谱
好比新i7的视频编码加速你说它是CPU干的似乎也不算说不过去……
引用第19楼a4840639于2011-11-24 15:59发表的 :
不找黄老板和小AA和Outel吗……
（黄老板的坑爹2，小AA一直不支持高Level，Outel的硬解整个一杯具还不如iPad1） images/back.gif
我记得农企本身似乎没怎么推过他自己的视频接口
走DXVA的话编码复杂度就被DX限制死了，就算硬件支持也不好上 引用第25楼ldenny于2011-11-24 17:26发表的 :
10bit不能硬解是ref bf的关系,咱喷出来了 images/back.gif
10bit自然不光是高B帧、Ref关键帧的事情了，这里只是说PC连这个都硬解码不了10bit根本没戏，起码等支持高B帧、高Ref才能说10bit的事。
当然你压10bit也可以用低参数，只是现阶段10bit压片是为了保证画面情况下劲量降低容量，基本都是用高参数压的。 引用第27楼liaojings1于2011-11-24 18:11发表的:
10bit自然不光是高B帧、Ref关键帧的事情了，这里只是说PC连这个都硬解码不了10bit根本没戏，起码等支持高B帧、高Ref才能说10bit的事。
当然你压10bit也可以用低参数，只是现阶段10bit压片是为了保证画面情况下劲量降低容量，基本都是用高参数压的。 images/back.gif
我没见过任何一块PC显卡的硬解和连续B帧有关，只听说过PSP无法解码连续B帧>3的视频
ref开那么高只有两种解释：Placebo和Trolling 引用第28楼a4840639于2011-11-24 18:30发表的 :
我没见过任何一块PC显卡的硬解和连续B帧有关，只听说过PSP无法解码连续B帧>3的视频
ref开那么高只有两种解释：Placebo和Trolling images/back.gif
嘛，自己用MediaCoder压个高参数的视频用播放器硬解码试试吗。
我是经常压60帧的游戏视频，超级吃码率，为了保证画质还要文件小都是用高参数压的。
每次放这些游戏视频我都要关闭播放器的硬件加速... ...怪麻烦的，不知道那位能提供解决办法。
bilibili碰到一些视频绿屏、花屏，开软解码就没事了，之后缓冲文件查看信息发现都是高参数视频。 其实我觉得真正的硬解应该是像mp3解码芯片那样的，专用ASIC电路
其它的都是将算法转换成指令，区别就是指令专门对这种算法加速多少
比如我最近手头上设计的这个CPU，乘法可以有三种配置，最慢的32个周期，最快的1个周期
慢配置下，做解码性能肯定不行，性能偏向于“软解”，快配置下，就是所谓的“硬解”性能了 路过围观各位液内 引用第29楼liaojings1于2011-11-24 18:45发表的 :
嘛，自己用MediaCoder压个高参数的视频用播放器硬解码试试吗。
我是经常压60帧的游戏视频，超级吃码率，为了保证画质还要文件小都是用高参数压的。
每次放这些游戏视频我都要关闭播放器的硬件加速... ...怪麻烦的，不知道那位能提供解决办法。
bilibili碰到一些视频绿屏、花屏，开软解码就没事了，之后缓冲文件查看信息发现都是高参数视频。 images/back.gif
你干嘛不自己试试ref6和ref16/b 6和b16在质量上的差别，好吧在这两年的IU上速度可能是差得很小了，至少多费了电吧
另外1080p60确实是过于凶残了，大多数硬件不能硬解，建议不对画质太执着就用720p60 引用第32楼a4840639于2011-11-24 19:39发表的 :
你干嘛不自己试试ref6和ref16/b 6和b16在质量上的差别，好吧在这两年的IU上速度可能是差得很小了，至少多费了电吧
另外1080p60确实是过于凶残了，大多数硬件不能硬解，建议不对画质太执着就用720p60 images/back.gif
囧我压的是512X384......720P那还不大的要死啊......
主要就是为了方便传播，不然看的人等半天，尽可能的文件小的情况下保证画面。
Re:回 13楼(hhtrivial) 的帖子
引用第14楼66666于2011-11-24 14:55发表的 回 13楼(hhtrivial) 的帖子 :Supported devices
* Honeycomb tables(TF101,GT10.1,Iconia500) : 720p High@4.1 ( no weighted prediction )
* Samsung Galaxy S2 : 1080p H.264 high@5.1/MPEG-4,1080i AVCHD MTS
* Samsung Galaxy S and variants : 720p H.264 High@5.1
* Samsung Galaxy Tab(7') : 1080p H.264 High@5.1. 1080i have interlace artifacts.
....... images/back.gif
原来android能支持baseline以上？刚好在做的几个平台的流媒体视频项目，看了开发文档android写的是baseline - http://developer.android.com/guide/appendix/media-formats.html，试了下hero就算是baseline如果ref>6就必死，wp7和ios因为本身硬件有要求比较好调，但是因为android的关系要降低压制参数
页:
[1]
2