TA的每日心情 | 慵懒
3 天前 |
|---|
签到天数: 156 天 [LV.7]常住居民III
星辰大海
- 积分
- 584884
|
本帖最后由 sommio 于 2024-11-19 13:27 编辑
我觉得除了 MX Player 的开发者应该没人知道它的「硬解+」是怎么实现的。
其它人基本都是依靠它的行为和开发者在 xda 上的回复推断它是什么东西。
「硬解+」的音频解码我认为仍然调用 mediacodec，理由单纯是它提供软解音频的选项。
如果 DSP 支持，那 mediacoec 应该会透过 DSP 解码，实现「硬件加速」。
它的视频解码我觉得仍然通过 mediacodec 解码及 android.view.Surface 渲染。通过 DSP 完成绝大部分工作。
理由是无论「硬解」还是「硬解+」都会存在一些「我觉得明显是 DSP 的锅的渲染错误」，就如楼上提到的色带。
虽然由此推断它「只是增强了 demuxer」虽然很自然，但并不能完全肯定。
在下图中可以理解 DSP 在「VPU」部分，MX Player 大概率通过 DSP 完成绝大部分工作。
绝大部分安卓电视的 SoC 都是基本依靠 DSP 加速渲染的。
因此 GCA 很弱，即便能通过 CPU 解码，也无法通过 GCA 完成渲染（ARM Mali 称为着色器）。
关于楼主提到的「硬解+模式如果出现色块说明你的设备根本就不支持硬解码此种视频编码」，我觉得是错的。
DSP 支持它并不代表渲染质量就会好，一些厂家的 DSP 对 10bit 视频渲染渣渣是不少安卓 SoC 的老问题了。
至于到 mpv 那边就是另外一种情况了，大部分用户 mpv 都会用 vo=gpu/gpu-next 这些渲染器，它们不会用 DSP 渲染。
唯一的变量是「hwdec=mediacodec」时，仍然会使用 DSP 完成 RGB 转换，虽然渲染仍由 mpv 的渲染器完成。
mediacodec is not safe. It forces RGB conversion (not with -copy) and how well it handles non-standard colorspaces is not known. In the rare cases where 10-bit is supported the bit depth of the output will be reduced to 8.
但可以通过「hwdec=mediacodec-copy」解决，让 mpv 用自己的实现完成从 RGB 转换到渲染的步骤。
因为除了解码以外的步骤不依赖 DSP，而是通过着色器，所以功耗会比 MXPlayer 那套高很多，好处是它可以保证跟你电脑一样的渲染效果。
|
|
不太清楚，听说硬解+是画面交给GPU还是CPU，音频是交给CPU还是GPU来着？是一种平衡的解码方式来着，听说还有个软解+，和硬解+相反，感觉这个和封装格式没关系吧。。。具体还是看编解码器来着？
嗯嗯，你说得对，我是提不出什么有理有据的观点，但又一直坚持我那毫无根据的猜测是怎么回事？我用的竟然是疑问句就表明我并不是很清楚，所以你如果觉得我说的有问题请好好的沟通，在我自己看来我说的更多的是自身使用遇到的情况及疑问，如果你这么说我也可以说你也没拿出什么有理有据的观点啊。