@多核系统下H264解码器并行解码方案的疑惑？？？？

poty 2009-01-03 04:12:07

加精

现在正在做H264解码器针对多核系统的优化，到网上搜索了一些并行解码的方案；主要是基于gop、slice、mb三种数据结构的划分。
下面是我做的一些尝试，主要是slice层与MB层并行解码方案：
（1）Slice层的并行解码方案对基于帧编码的多Slice结构的码流解码性能提高明显；但基于场编码的单Slice结构的码流，由于仍然等同于串行解码，性能没什么提升，所以后来又做了基于MB的并行解码；
（2）MB的并行解码，让我很失望！！！从调整程序架构、修改代码、实现方案整整发了快两个星期，最后发现性能还远远不如以前的串行解码的方式；实现的方案大致是先构造一个扫描表，然后将对等的MB分别用线程并行去解的方式，但效率很低，起初我以为是自己的线程设计的不是很理想，然后直接用OPenMP将其放入并行区域去解，但解码性能都差不多，郁闷中……

后来，做了很多测试程序，感觉基于MB的并行解码这种方式的划分，视乎粒度太小了（相当每个宏块用一个线程去解）；而基于MB的并行解码的预处理阶段缓存了很多信息感觉Cache也有点问题；现在正在迷惘中…………，不知MB的并行解码究竟可行不可行？？？
还请有这方面经验的前辈不吝赐教，由衷感谢……

...全文

780 25 打赏收藏转发到动态举报

写回复

用AI写文章

25 条回复

切换为时间正序

请发表友善的回复…

发表回复

lixplayer 2012-03-06

打赏
举报

粒度太细，以至于多线程同步的开销很大。

suiwa 2009-11-18

打赏
举报

多线程并行在MB层确实是太变态了，在Slice层并行也不一定是必须的，多线程不是万金油，假设你有n个core，每个core跑100%还是不能实时处理的话，增加线程数量也于事无补。所以在多核环境中使用多线程的充分条件是core能提供的最大运算量必须大于264decode所需的运算量，但这还不是必要条件，多线程的并行效能还受制与264的解码逻辑。
对于多核多线程优化264，本菜可提供一些思路
1）在Frame层并行，莫要再slice层并行，得不偿失
2）将decode逻辑抽象成parse和recon 两个子过程，一个Frame先parse（无非 CABAC, slice mb初始化之类的操作）然后再Recon（无非interpre intrapre ...deblock 之类操作）就认为decode OK
3）在decoder前端设一解码任务队列（非DPB），线程从任务队列中取frame，下面用伪代了哈
thread_body
{
if(have frame wait parse in task_list)
parse(frame) and set the frame parse_tag
else if//no frame wait parse
recon(frame) and pop the frame out of the task_list
else //task_list empty
waitfor(frame coming)
}
3）线程数目可设与逻辑core数量相等
4）本方案缺点就在那个任务队列，他缓存了部分待解码的frame，缓存帧的数量理论上达到I P帧间距的一半并行效果就很好鸟，哈哈
5）为了坚定众看家的信心，发一组测试数据上来
Test case GOP
struct PreParse count I frame P frame B frame Cpu used ratio Decode frequende
(帧/s)
ptime Rtime Ptime Rtime Ptime Rtime core 1 core 2
1 IPPPPPP 1 16 16 16 16 -- -- 50 50 30.7
2 IPPPPPP 1 32 32 32 32 -- -- 51 53 15.4
3 IPPPPPP 1 22 11 22 11 -- -- 48 62 29.7
4 IPPPPPP 1 11 22 11 22 -- -- 51 59 29.5
5 IPPPPPP 1 7 25 7 25 -- -- 50 60 29.7
6 IPPPPPP 1 3 30 3 30 -- -- 53 59 29.8
7 IPPPPPP 2 3 30 3 30 -- -- 61 59 37.5
8 IPPPPPP 3 3 30 3 30 -- -- 68 80 44
9 IPPPPPP 4 3 30 3 30 -- -- 89 90 53.1
10 IPPPPPP 5 3 30 3 30 -- -- 99.5 99.9 59.3
11 IBBPBBPBBPBBP 1 3 30 3 30 3 30 47 58 29.3
12 IBBPBBPBBPBBP 2 3 30 3 30 3 30 77 78 45.5
13 IBBPBBPBBPBBP 3 3 30 3 30 3 30 99.3 99.4 59
14 IBBPBBPBBPBBP 4 3 30 3 30 3 30 100 100 61.5
15 IBPBPBPBPBPBP 1 3 30 3 30 3 30 46 54 29.5
16 IBPBPBPBPBPBP 2 3 30 3 30 3 30 95.5 91 54.7
17 IBPBPBPBPBPBP 3 3 30 3 30 3 30 100 100 61.3
18 IBBBPBBBPBBBP 1 3 30 3 30 3 30 51.5 51 30.5
19 IBBBPBBBPBBBP 2 3 30 3 30 3 30 52 87 41.3
20 IBBBPBBBPBBBP 3 3 30 3 30 3 30 97 98 58
21 IBBBPBBBPBBBP 4 3 30 3 30 3 30 99.2 99.6 59.5
22 IBBBPBBBPBBBP 5 3 30 3 30 3 30 99.6 100 59.8
23 IBBPBBPBBPBBP 4 17~36 17~36 13~30 13~30 15~35 15~35 100 100 61.5
24 IBBPBBPBBPBBP 4 3~30 3~30 3~30 3~30 3~30 3~30 99.7 99.8 59.4
3. 结论

smartsip 2009-09-30

打赏
举报

关注一下

jf_peng 2009-09-18

打赏
举报

帮顶！！！

intel_cyu 2009-01-07

打赏
举报

楼主可以参考 IPP H.264 解码的 sample code 实现多线程的方法：
http://www3.intel.com/cd/software/products/asmo-na/eng/219967.htm

实现的基本思想是创建一个任务队列：对于每一个MB,需要进行熵编码, 运动补偿、帧间/帧内预测、反变换，deblocking等解码步骤. 每个MB的解码步骤都是一个任务.

这些任务间有相互的依赖关系。如熵编码后，可以将后续的运动补偿, 帧间/帧内预测的任务放入任务队列中，同时MB间也有依赖关系，一个MB的任务完成后，对他有依赖其他MB的任务可以放入任务队列中：

主程序创建多个多线程，每个线程都从任务的队列中取得可以运行的任务，完成再获取新的任务。当一个任务完成后，检查后续有那些MB的解码步骤可以放入任务队列中。

ctcl1265 2009-01-07

打赏
举报

很复杂啊，看不太懂啊！！！！

sbl22924912 2009-01-06

打赏
举报

xunxian

poty 2009-01-06

打赏
举报

[Quote=引用 17 楼 Bill1212 的回复:]
MB不是要参考上面，左面等的MB吗？那么并行好像不太有意义吧。大多数情况下还是要一个一个的解吧。
何况启动新线程也是有开销的，总的看来得不偿失。
我倒觉得bitstream中语法element的提取，整数变换，loop-filter这些功能性的模块还像还有并行的可能性。
一点肤浅的看法供参考。
[/Quote]

对！
MB是要参考上面，左面等的MB，所以要做并行处理的化，就不能按扫描序逐行逐块的解了；
这里我是按自己构造的扫描表解的，所以并行处理的空间还是蛮大的。

Bill1212 2009-01-06