[AVC(H.264)] 抛砖引玉话MBTree

2024-02-01 06:48
文章标签 h.264 avc 抛砖引玉 mbtree

本文主要是介绍[AVC(H.264)] 抛砖引玉话MBTree,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

从x264的1197版引入MB Tree Ratecontrol以来,时间已经过了将近两个月,本贴旨在从个人角度谈一点对MB Tree的理解和使用心得,供大家参考。由于MB Tree仍然是一个非常新鲜的内容,而且MB Tree引入给x264解码器,特别是CRF下码率控制带来了巨大的变化,本人的很多理解也许有错误,希望大家能从自己的角度畅所欲言,让大家共同摸清MB Tree这个葫芦里卖的是什么药。

什么是Macroblock Tree
Macroblock Tree是一个基于macroblock的qp控制方法。MB Tree的工作原理类似于古典的qp compression,只不过qcomp处理的对象是整张frame而MB Tree针对的是每个MB进行处理。工作过程简单来说,是对于每个MB,向前预测一定数量的帧(该数量由rc-lookahead和keyint的较小值决定)中该MB被参考的情况,根据引用次数的多寡,决定对该MB使用何种大小的qp进行quantization。而qp的大小与被参考次数成反比,也就是说,对于被参考次数多的MB,264的解码器认为此对应于缓慢变化的场景,因此给与比较高的质量(比较低的qp数值)。至于视频的变化率与人眼感知能力的关系,这是一个基于主观测试的经验结果:视频变化率越大 人眼的敏感度越低,也就是说,人眼可以容忍快速变化场景的某些缺陷,但相对而言某些平滑场景的缺陷,人眼则相当敏感。注意此处说的平滑,指的是沿时间维度上场景的变化频率,而非普通意义上的像素域中的场景。

MBTree File
这是一个临时文件,记录了每个P帧中每个MB被参考的情况。

MB Tree的处理对象
根据DS blog上的文章,目前mbtree只处理p frames的mb,同时也不支持bpyramid。

与Mbtree相关的参数
--qcomp qcomp有削弱mbtree强度的倾向,具体来说,qcomp的值越趋近于1(Constant Quantizer),mbtree的效力越差。
--rc-lookahead 决定mbtree向前预测的帧数。

Mbtree的效率
这点似乎是mbtree带来的最直接的实惠,比如之前1197中我的测试,同样crf中码率节省就达到30%。下面的log是VempX大人化物语第一卷BD NCED的测试结果,使用的是x264 rev.1259

启用mbtree

avis [info]: 1920x1080 @ 23.98 fps (2193 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile Main, level 4.1
x264 [info]: frame I:32    Avg QP:13.43  size: 81885
x264 [info]: frame P:984   Avg QP:17.83  size: 62360
x264 [info]: frame B:1177  Avg QP:18.68  size: 35058
x264 [info]: consecutive B-frames:  8.5% 52.2% 18.5% 13.7%  5.1%  1.4%  0.6%  0.0%  0.0%
x264 [info]: mb I  I16..4: 67.8%  0.0% 32.2%
x264 [info]: mb P  I16..4: 57.4%  0.0%  0.0%  P16..4: 39.5%  0.0%  0.0%  0.0%  0.0%    skip: 3.0%
x264 [info]: mb B  I16..4: 18.4%  0.0%  0.0%  B16..8: 37.3%  0.0%  0.0%  direct:14.9%  skip:29.3%  L0:44.5% L1:43.7% BI:11.8%
x264 [info]: direct mvs  spatial:99.8%  temporal:0.2%
x264 [info]: coded y,uvDC,uvAC intra:23.1% 41.6% 30.4% inter:26.5% 26.7% 9.8%
x264 [info]: kb/s:9205.2

encoded 2193 frames, 3.20 fps, 9205.83 kb/s



关闭mbtree

avis [info]: 1920x1080 @ 23.98 fps (2193 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile Main, level 4.1
x264 [info]: frame I:32    Avg QP:11.89  size:110902
x264 [info]: frame P:984   Avg QP:15.05  size: 94913
x264 [info]: frame B:1177  Avg QP:17.10  size: 44859
x264 [info]: consecutive B-frames:  8.5% 52.2% 18.5% 13.7%  5.1%  1.4%  0.6%  0.0%  0.0%
x264 [info]: mb I  I16..4: 65.9%  0.0% 34.1%
x264 [info]: mb P  I16..4: 60.1%  0.0%  0.0%  P16..4: 39.2%  0.0%  0.0%  0.0%  0.0%    skip: 0.7%
x264 [info]: mb B  I16..4: 25.9%  0.0%  0.0%  B16..8: 40.2%  0.0%  0.0%  direct:16.6%  skip:17.2%  L0:45.6% L1:42.2% BI:12.2%
x264 [info]: direct mvs  spatial:99.6%  temporal:0.4%
x264 [info]: coded y,uvDC,uvAC intra:49.8% 71.0% 63.4% inter:35.7% 36.6% 19.2%
x264 [info]: kb/s:13097.1

encoded 2193 frames, 3.44 fps, 13097.75 kb/s


开启mbtree后码率节省也达到了将近30%
至于两者压完后的主观质量上的区别,我觉得在如此极端的码率下,普通的观看场合是看不出区别的。(逐帧的比较让VempX来?)

一点深入的分析:
对于使用encoder的我们来说,也许需要更进一步的关注下mbtree具体是如何将码率节省到这个地步的,在这之前,我们先回顾下264的码率控制方法。
所谓码率控制,指的是在给定码率和解码端缓冲区的限制下,如何选择最优编码参数的系统优化问题。x264一共支持5种码率控制模式,而VBV的启用可以使264以mb为单位而非以帧为单位指定qp。
简而言之,CRF模式下码率控制的过程由下面三步决定:
1、首先确定当前正在处理帧的码率:由于x264使用了与画面复杂度相关的经验公式,于是问题被归结于如何预测画面复杂度。
2、对于1pass的CRF而言,画面复杂度由残差的SATD决定,后续GOP中的I帧qp则由之前编码的I帧qp继承决定。
3、之后,我们需要根据所选crf的数值,对2中获得的数据进行scaling,以获得最终码率。

对于VempX压制的化物语NCED,我稍微做点说明,这是一个符合ds描述的典型的anime片段,2193帧被分为了将近30个场景,而每个场景中大部分画面都是静止和缓慢运动的,也就是说这从理论上应是一个符合mbtree优化条件的样本。
我通过H.264visa仔细观察了下329-333这个GOP中首部P帧和中部B帧的mb码率分布情况,329-333的编码顺序如下
329(P)->333(P)->330(B)->331(B)->332(B)
根据前面分析,mbtree在处理第一个Pframe(329),会向前预测该帧在330-333帧中被参考的多少(以mb为单位)。

P Frame 329 with mbtree
f329_mbtree.jpg 
P Frame 329 without mbtree
f329_no-mbtree.jpg 

B Frame 331 with mbtree
f331_mbtree.jpg 
B Frame 331 without mbtree
f331_no-mbtree.jpg 

令人惊讶的是,对于没有进行mbtree处理的B frame,各mb的码率也都比关闭mbtree有了明显的减少,一个可能的解释在于mbtree的使用增加了P frame中被大量参考的mb的预测精度,从而使GOP内其他B frame的残差数据很少,有效降低了码率。

另外,完全和mbtree无关的I Frame,虽然整帧qp的数值相差很少,但具体来看开启mbtree后码率却也有很大的降低。这让我百思不得其解。
I Frame 310 with mbtree
f310_mbtree.jpg 
I Frame 310 without mbtree
f310_no-mbtree.jpg 

//补充1:
就mbtree本身而言,其理应不会影响某一mb编码时mode decision的判定(inter[p,b]/intra)。但由于之后该GOP内剩余的B帧皆要使用头尾的IDR frame做预测(no-bpyramid),开启mbtree之后由于影响了IDR frame(首位p frame)中的mb,而之前的假定又表明对于大量参考的mb,mbtree会分配一个较小的qp(意味着更准确的重建质量),故之后GOP中其余B frame的mb mode decision,会产生一定变化。如331帧中B-MB的数量增加了1000多(意味着从前后两个IDR中的预测更准确),而B-MB中skip的数量更是增加了接近300%(意味着重复利用的信息被高精度的保存了)。

我又做了一个简单的测试,使用的片源是Chobits的NCOP。

首先我使用我一直以来做DVDRip用的参数,在crf18下,以r1195版本进行了1pass的压制。

  1. avis [info]: 704x480 @ 23.98 fps (2336 frames)
  2. x264 [info]: using SAR=40/33
  3. x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
  4. x264 [info]: profile High, level 4.1
  5. x264 [info]: slice I:39    Avg QP:13.23  size: 21536  PSNR Mean Y:53.35 U:55.41V:56.60 Avg:53.75 Global:49.70
  6. x264 [info]: slice P:930   Avg QP:15.56  size: 11159  PSNR Mean Y:48.90 U:54.54V:55.38 Avg:49.78 Global:47.02
  7. x264 [info]: slice B:1367  Avg QP:17.43  size:  2578  PSNR Mean Y:46.41 U:52.17V:52.82 Avg:47.34 Global:45.86
  8. x264 [info]: consecutive B-frames:  8.9% 32.8% 26.1% 12.7%  9.4%  2.6%  4.9%  1.0%  1.6%
  9. x264 [info]: mb I  I16..4: 44.9% 29.2% 25.9%
  10. x264 [info]: mb P  I16..4: 11.4%  8.8%  5.7%  P16..4: 36.5% 16.2%  9.3%  0.0%  0.0%    skip:12.1%
  11. x264 [info]: mb B  I16..4:  3.5%  1.8%  0.4%  B16..8: 29.5%  1.8%  2.2%  direct: 3.0%  skip:57.8%  L0:46.5% L1:44.6% BI: 8.9%
  12. x264 [info]: 8x8 transform  intra:32.8%  inter:51.8%
  13. x264 [info]: direct mvs  spatial:88.1%  temporal:11.9%
  14. x264 [info]: coded y,uvDC,uvAC intra:64.3% 69.6% 35.9% inter:18.7% 21.9% 6.2%
  15. x264 [info]: ref P L0  64.4% 14.6%  8.5%  4.0%  3.1%  2.3%  1.9%  1.1%
  16. x264 [info]: ref B L0  75.9% 11.1%  5.5%  2.8%  2.0%  1.5%  1.2%
  17. x264 [info]: SSIM Mean Y:0.9903087
  18. x264 [info]: PSNR Mean Y:47.518 U:53.165 V:53.901 Avg:48.422 Global:46.332 kb/s:1210.44

  19. encoded 2336 frames, 5.67 fps, 1210.63 kb/s
复制代码

r1195的crf18得到了码率1200K,接下来,我用r1268,在保持所有参数不变的前提下,关闭了mbtree,以1200K码率进行了2pass的编码

  1. avis [info]: 704x480 @ 23.98 fps (2336 frames)
  2. x264 [info]: using SAR=40/33
  3. x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
  4. x264 [info]: profile High, level 4.1
  5. x264 [info]: frame I:39    Avg QP:13.52  size: 20717  PSNR Mean Y:53.32 U:55.32V:56.53 Avg:53.69 Global:49.66
  6. x264 [info]: frame P:932   Avg QP:15.50  size: 10972  PSNR Mean Y:48.90 U:54.48V:55.40 Avg:49.75 Global:47.44
  7. x264 [info]: frame B:1365  Avg QP:17.60  size:  2607  PSNR Mean Y:46.49 U:52.26V:52.90 Avg:47.41 Global:46.25
  8. x264 [info]: consecutive B-frames:  8.8% 32.4% 28.3% 11.5% 10.7%  2.1%  3.7%  1.0%  1.6%
  9. x264 [info]: mb I  I16..4: 42.1% 26.3% 31.6%
  10. x264 [info]: mb P  I16..4:  7.8%  6.4%  8.2%  P16..4: 38.9% 16.6%  9.4%  0.0%  0.0%    skip:12.6%
  11. x264 [info]: mb B  I16..4:  3.4%  1.5%  0.6%  B16..8: 33.7%  1.9%  2.2%  direct: 3.3%  skip:53.4%  L0:46.2% L1:43.9% BI: 9.9%
  12. x264 [info]: 8x8 transform intra:28.1% inter:39.7%
  13. x264 [info]: direct mvs  spatial:70.8% temporal:29.2%
  14. x264 [info]: coded y,uvDC,uvAC intra: 56.1% 55.1% 31.3% inter: 18.5% 17.7% 6.6%
  15. x264 [info]: i16 v,h,dc,p: 45% 26% 22%  7%
  16. x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 29% 15% 38%  2%  2%  5%  2%  4%  3%
  17. x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 33% 13% 40%  2%  2%  4%  1%  2%  1%
  18. x264 [info]: ref P L0: 62.0% 15.3%  9.1%  4.4%  3.4%  2.5%  2.0%  1.2%
  19. x264 [info]: ref B L0: 75.4% 11.4%  5.7%  2.7%  2.0%  1.5%  1.2%
  20. x264 [info]: SSIM Mean Y:0.9905871
  21. x264 [info]: PSNR Mean Y:47.561 U:53.195 V:53.958 Avg:48.450 Global:46.727 kb/s:1198.19

  22. encoded 2336 frames, 6.08 fps, 1198.19 kb/s
复制代码

参数不变,打开mbtree,2pass编码

  1. avis [info]: 704x480 @ 23.98 fps (2336 frames)
  2. x264 [info]: using SAR=40/33
  3. x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
  4. x264 [info]: profile High, level 4.1
  5. x264 [info]: frame I:39    Avg QP:14.38  size: 21184  PSNR Mean Y:52.98 U:54.21V:55.63 Avg:53.22 Global:50.16
  6. x264 [info]: frame P:934   Avg QP:17.07  size: 11250  PSNR Mean Y:49.13 U:54.56V:55.55 Avg:49.96 Global:47.98
  7. x264 [info]: frame B:1363  Avg QP:19.28  size:  2412  PSNR Mean Y:46.39 U:52.53V:53.11 Avg:47.32 Global:46.58
  8. x264 [info]: consecutive B-frames:  8.7% 33.6% 27.2% 11.0% 10.2%  1.8%  4.9%  1.0%  1.6%
  9. x264 [info]: mb I  I16..4: 44.4% 25.4% 30.2%
  10. x264 [info]: mb P  I16..4: 10.0%  6.3%  6.2%  P16..4: 38.1% 15.3%  8.8%  0.0%  0.0%    skip:15.3%
  11. x264 [info]: mb B  I16..4:  1.7%  1.1%  0.5%  B16..8: 32.7%  1.8%  1.8%  direct: 3.0%  skip:57.5%  L0:47.4% L1:41.8% BI:10.8%
  12. x264 [info]: 8x8 transform intra:28.4% inter:41.8%
  13. x264 [info]: direct mvs  spatial:64.9% temporal:35.1%
  14. x264 [info]: coded y,uvDC,uvAC intra: 45.6% 47.7% 24.1% inter: 17.1% 15.8% 6.0%
  15. x264 [info]: i16 v,h,dc,p: 54% 26% 13%  8%
  16. x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 30% 15% 36%  2%  2%  6%  2%  4%  3%
  17. x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 35% 12% 37%  2%  3%  5%  1%  3%  1%
  18. x264 [info]: ref P L0: 62.0% 15.9%  9.3%  4.3%  3.3%  2.4%  1.9%  1.1%
  19. x264 [info]: ref B L0: 77.2% 11.3%  5.4%  2.4%  1.6%  1.2%  0.9%
  20. x264 [info]: SSIM Mean Y:0.9908447
  21. x264 [info]: PSNR Mean Y:47.597 U:53.371 V:54.127 Avg:48.477 Global:47.137 kb/s:1200.50

  22. encoded 2336 frames, 7.99 fps, 1200.50 kb/s
复制代码

PSNR我只是顺便计算了,不过我们无视掉它好了,只看SSIM就够了
r1195 crf 18:        SSIM Mean Y:0.9903087
r1268 no-mbtree:  SSIM Mean Y:0.9905871
r1268 mbtree:       SSIM Mean Y:0.9908447

这是SSIM的比较结果,再看看各自的平均QP
r1195 crf 18:
x264 [info]: slice I:39    Avg QP:13.23
x264 [info]: slice P:930   Avg QP:15.56
x264 [info]: slice B:1367  Avg QP:17.43

r1268 no-mbtree:
x264 [info]: profile High, level 4.1
x264 [info]: frame I:39    Avg QP:13.52
x264 [info]: frame P:932   Avg QP:15.50
x264 [info]: frame B:1365  Avg QP:17.60

r1268 mbtree:
x264 [info]: frame I:39    Avg QP:14.38
x264 [info]: frame P:934   Avg QP:17.07
x264 [info]: frame B:1363  Avg QP:19.28

结果很有意思,打开了mbtree之后,平均的QP都比前两个有所提高,但是SSIM却没有降低,不知道这是不是dark shikari嘴里所说的Magic XD

 

这篇关于[AVC(H.264)] 抛砖引玉话MBTree的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/666405

相关文章

H.264量化参数QP和量化步长Qstep

1. 量化参数QP是量化步长Qstep的序号。对于亮度(Luma)编码而言,量化步长Qstep共有52个值,QP取值0~51,对于色度(Chroma)编码,Q的取值0~39。 QP取最小值0 时,表示量化最精细;相反,QP取最大值51时,表示量化是最粗糙的。 QP和Qstep具有线性相关性,Qstep随着QP的增加而增加,每当QP值增加6,Qstep便增加一倍。 量化是在

x264 编码器 AArch64汇编系列:运动补偿之MBtree相关汇编函数

x264_mbtree_propagate_cost_neon c 语言对应的实现函数: 函数参数: dst:指向int16_t类型的指针,用于存储传播成本的结果。propagate_in:指向uint16_t类型的指针,包含输入的传播成本。intra_costs:指向uint16_t类型的指针,包含帧内预测成本。inter_costs:指向uint16_t类型的指针,包含帧间预测成本。

android selinux报avc denied权限和编译报neverallow解决方案

avc: denied { read } for name=“present” dev=“sysfs” ino=42693 scontext=u:r:hal_health_default:s0 tcontext=u:object_r:sysfs:s0 tclass=file permissive=1 denied {xxx}: 表示缺少什么权限 scontext:表示谁缺少权限 tcontext:

v4l2(video4linux2) yuyv(yuv422)、MJPEG、H.264

V4L2(Video4Linux2)是Linux内核中的视频设备接口框架,专门用于捕获和输出视频数据。V4L2广泛应用于各种视频设备的驱动程序开发,如网络摄像头、电视调谐器、视频采集卡、以及其他视频输入/输出设备。 ### V4L2的主要功能 1. **视频采集**:    - 通过摄像头、视频采集卡等设备捕获视频数据。    - 支持多种视频格式,如YUYV、MJPEG、H.264等。 2

hevc和H.264格式的区别

HEVC(High Efficiency Video Coding)和H.264(也称为Advanced Video Coding,AVC)都是视频压缩标准,但它们之间存在一些显著的区别,主要集中在压缩效率、资源需求和兼容性方面。 压缩效率 HEVC,也被称为H.265,提供了比H.264更高的压缩效率。这意味着在相同的视频质量下,HEVC能够以大约一半的比特率进行编码,从而减少存储空间需求和

H.264的那些事

1.H265编码初探 2.H265 profile 3.H265编码等级以及图像的基础知识 4.H265码流格式 5.FFmpeg QT 实现h264、h265 音视频播放(Native方式) 6.Qt基于FFmpeg播放本地 H.264(H264)文件 7.H264码流和Mp4结构详解   FFMPEG的使用 #将264裸码流封装成mp4ffmpeg -f h264 -i s

H.264中最优运动矢量残差的输出

原文转自:http://www.360doc.cn/article/1412027_118336851.html H.264中最优运动矢量残差的输出 2010-07-27 10:03 最优运动矢量的求解是在encode_one_macroblock函数里面,因此该函数执行完毕运动矢量及分割模式也就相应的确定了,这里我们对这一块作一下简要的分析。 运动矢量的写码流是在

RTP RTSP H.264 实时视频

相关博文 :http://blog.csdn.net/evsqiezi/article/details/22881151                      http://blog.csdn.net/chen495810242/article/details/39207305

H.264官方文档下载

H.264是ITU(International Telecommunication Union,国际通信联盟)和MPEG(Motion Picture Experts Group,运动图像专家组)联合制定的视频编码标准。其官方文档可以在ITU官网上下载:https://www.itu.int/rec/T-REC-H.264 可以看到H.264最新版的文档是2021年8月发布的:

Linux 下实现RTP实时打包发送H.264视频文件

在实现H264实时RTP打包和发送之前,我们需要先熟悉H264的编码原理及语法结构,然后是熟悉RTP协议以及RTP协议传输H264数据的相关准则。下面是与此相关的几篇博客。     H264语法结构及编码原理     RTP Payload H264     Linux 下实现RTP实时打包发送H.264码流     下面是rtp.c的代码 [objc]  view pla