H264与H265相关区别了解

Posted 2023-05-04

参考技术A H.265是 ITU-T VCEG 继 H.264 之后所制定的新的 视频编码 标准。H.265标准围绕着现有的 视频编码标准 H.264 ，保留原来的某些技术，同时对一些相关的技术加以改进。新技术使用先进的技术用以改善码流、编码质量、延时和 算法复杂度 之间的关系，达到最优化设置。

具体的研究内容包括：提高压缩效率、提高 鲁棒性 和错误恢复能力、减少实时的时延、减少信道获取时间和随机接入时延、降低复杂度等。

H.264由于算法优化，可以低于1Mbps的速度实现标清（分辨率在1280P*720以下）数字图像传送；H.265则可以实现利用1~2 Mbps 的传输速度传送 720P （分辨率1280*720）普通高清音视频传送。

H264由于算法优化，可以低于2Mbps的速度实现标清数字图像传送；H.265 High Profile可实现低于1.5Mbps的传输带宽下，实现1080p全高清视频传输。

除了在编解码效率上的提升外，在对网络的适应性方面H.265也有显著提升，可很好运行在 Internet 等复杂网络条件下。

H.265/HEVC的编码架构大致上和H.264/AVC的架构相似，主要也包含，帧内预测（intra prediction）、帧间预测（inter prediction）、转换（transform）、量化（quantization）、去区块滤波器（deblocking filter）、熵编码（entropy coding）等模块，但在HEVC编码架构中，整体被分为了三个基本单位，分别是编码单位（coding unit, CU）、预测单位（predict unit, PU）和转换单位（transform unit, TU）。

比起H.264/AVC，H.265/HEVC提供了更多不同的工具来降低码率，以编码单位来说，H.264中每个宏块（macroblock/MB）大小是的8x8或者16x16像素，而H.265的编码单位可以选择从最小的8x8到最大的64x64.

以该图为例，信息量不多的区域（颜色变化不明显，比如车体的红色部分和地面的灰色部分）划分的宏块较大，编码后的码字较少，而细节多的地方（轮胎）划分的宏块就相应的小和多一些，编码后的码字较多，这样就相当于对图像进行了有重点的编码，从而降低了整体的码率，编码效率就相应提高了。

H.265的帧内预测模式支持33种方向（H.264只支持8种），并且提供了更好的运动补偿处理和矢量预测方法。

反复的质量比较测试已经表明，在相同的图象质量下，相比于H.264，通过H.265编码的视频大小将减少大约39-44%。由于质量控制的测定方法不同，这个数据也会有相应的变化。

通过主观视觉测试得出的数据显示，在码率减少51-74%的情况下，H.265编码视频的质量还能与H.264编码视频近似甚至更好，其本质上说是比预期的信噪比（PSNR）要好。

H.264与H.265编码视频的主观视觉测试对比，我们可以看到后者的码率比前者大大减少了。

由于h265比较h264压缩率更高，编码视频更小，所以对机器的运算需求也要更大。

HEVC将之前标准中定义的宏块(macroblocks)用一种最大到64x64像素的并且可以进一步细分成可变大小的块。HEVC把编码树单元（coding tree units (CTUs)）变成亮度和色度的编码块（coding tree blocks (CTBs)）。一个CTB可以大小为64x64、32x32或者16x16.这样帧内（intra-picture）和帧间（inter-picture）的预测块(prediction units，PU)大小从64x64到4x4大小，只是对于双向预测，只能到8x4到4x8大小。预测残差编码的变换块大小可以是32x32、16x16、8x8、4x4.

内部色深增加（Internal bit depth increase (IBDI)）可以让编码器运行在色宽更高的内部状态。IBDI最多可以作用于14-bit位宽。

可以把图像分成独立编解码的矩形块和条带，即条带slice和tile瓷片的概念。条带大部分可以单独解码，只是最终需要同步成一个视频流。条带可以编码成条带间没有预测，互相独立。当然条带间可能还是需要环路滤波的。

HEVC采用基于上下文自适应的熵编码算法（context-adaptive binary arithmetic coding (CABAC)），和H.264类似。只不过HEVC只支持CABAC编码。

HEVC的帧内预测有33个方向模式，而h.264中只有8个，HEVC还指定了planar和DC帧内预测模式。

本质上H.265是在H.264基础上增加插值的抽头系数个数，改变抽头系数值以及增加运动矢量预测值的候选个数，以达到减少预测残差的目的。

H.265与H.264一样插值精度都是亮度到1/4，色度到1/8精度，但插值滤波器抽头长度和系数不同

H.265的增加了运动矢量预测值候选的个数，而H.264预测值只有一个

HEVC采用半像素或者1/4像素的精度运动补偿，以及7抽头或者8抽头的滤波器。H.264使用半像素精度和6抽头的滤波器。对于4：2：0视频的色度分量有1/8像素精度和4抽头的滤波器。HEVC中的加权预测可以是单向也可以是双向的预测。

HEVC定义了16-bit的水平和垂直运动矢量，支持范围到[-32768, 32767]，即最多-8192到8191.75个亮度像素点，H.264只支持到-512到511.75个像素点。HEVC的MV模式有高级运动矢量预测（Advanced Motion Vector Prediction (AMVP)）和合并模式。合并模式运行从邻近块继承mv向量值，从而有skip和direct模式。

HEVC有两个环路滤波器，解块滤波器（DBF， deblocking filter）与样本自适应偏移量（SAO，sample adaptive offset）滤波器 (DBF)。Deblocking滤波器和H.264/MPEG-4 AVC中的类似，HEVC中的DBF只能用于8x8的块（提高并行处理性能），而H.264适用于4x4的块。HEVC中DBF的强度从0到2.对垂直边界做水平滤波，对水平边界做垂直滤波。SAO滤波器在DBF滤波器之后，为了更好的重建原始图像。每个CTB的SAO滤波器可以使能或者禁止边界偏移模式或者子段偏移模式。

本质上H.265的去块滤波与H.264的去块滤波及流程是一致的，做了如下最显著的改变：

滤波边界： H.264最小到4x4边界滤波；而H.265适应最新的CU、PU和TU划分结构的滤波边缘，最小滤波边界为8x8

滤波顺序：H264先宏块内采用垂直边界，再当前宏块内水平边界；而H.265先整帧的垂直边界，再整帧的水平边界。

为了保证中间预测、变换以及量化过程中的内部比特精度，以达到更好的压缩性能

当前芯片架构已经从单核性能逐渐往多核并行方向发展，因此为了适应并行化程度非常高的芯片实现，HEVC/H.265 引入了很多并行运算的优化思路。

1.二维不可分离的自适应插补滤波器

2.可分离的 AIF

3.定向的AIF

4.不再使用运动补偿与1/8-pel运动矢量

5.Supermacroblock结构到64x64转换（H.264仅到32x32）

6.自适应预测误差编码组织（APEC）

7.自适应量化矩阵选择（AQMS）

8.运动矢量选择与编码的竞争方式

9.针对内部编码的模块相依的KLT

参考文档：

https://blog.csdn.net/knowledgebao/article/details/84647323

https://baike.baidu.com/item/H.265?fr=aladdin

https://zhuanlan.zhihu.com/p/71270595?utm_source=wechat_session

https://jingyan.baidu.com/article/08b6a591701e7c14a8092212.html

https://blog.csdn.net/guoyunfei123/article/details/106241136?spm=1001.2101.3001.6650.4&utm_medium=distribute.pc_relevant.none-task-blog-2%7Edefault%7ECTRLIST%7Edefault-4.no_search_link&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2%7Edefault%7ECTRLIST%7Edefault-4.no_search_link

与最大大小相关的数组和向量之间的区别？

【中文标题】与最大大小相关的数组和向量之间的区别？

【英文标题】：Difference between an array and vector related to maximum size?

【发布时间】：2016-05-10 08:55:08

【问题描述】：

当我在我的 Devcpp 编译器中运行此代码时->

#include<bits/stdc++.h>
using namespace std;
int main()

    vector<int> vec;
    for(int i=0;i<100000000;i++)
    vec.push_back(i);

它甚至可以在运行时工作。 但是当我运行时->

#include<bits/stdc++.h>
using namespace std;
int arr[1000000000];
int main()

    return 0;

它给了我链接错误。

只要需要空间，arr和vec都需要相同的空间。那么为什么vec代码在运行时运行得很好，但arr代码甚至无法编译。

【问题讨论】：

@dvenkatsagar 不，这没有意义。

@dvenkatsagar 这没有意义。

@MarcusMüller Jinx。你欠我一杯苏打水。 :)

什么编译器错误？它在 osx 上用 clang 为我编译。

Why should I not #include <bits/stdc++.h>?

【参考方案1】：

问题在于分配。在第一种情况下，std::vector 默认allocator 使用动态分配，原则上可以根据需要分配尽可能多的内存（当然受操作系统和物理内存量的限制），而在第二种情况下，它使用内存可用于静态分配（从技术上讲，数组具有static storage duration），在您的情况下小于1000000000 * sizeof int 字节。请参阅this 以获得有关 C 程序中各种类型分配的一个很好的答案（这也适用于 C++）。

顺便说一句，避免#include<bits/stdc++.h>，因为它是非标准的。仅包含您需要的 standard 标头。还有一个问题：我认为您不会收到编译时错误，您可能会收到运行时错误。换句话说，代码编译得很好，但无法运行。

【讨论】：

@StevenBurnap 我不确定 OP 是否出现编译错误，它可能是运行时错误。将编辑答案。

是的，如果 OP 出现运行时错误，您所说的非常有道理。

arr 未在堆栈上定义。它是一个全局对象。

@RSahu 错过了它是在函数之外定义的，将编辑，谢谢。

@StevenBurnap 你确定吗？全局数据段不是很小吗？在任何情况下，该标准都没有规定任何关于在何处/如何进行分配的内容。 只要索引是整数类型是什么意思？数组的大小必须是整数类型。

【参考方案2】：

好像对象

int arr[1000000000];

对于您的环境来说太大而无法容纳您的程序的全局数据。我没有收到编译时错误，但我的环境中也出现了链接时错误（cygwin/g++ 4.9.3）。

对我来说，将尺寸缩小十分之一。它也可能对你有用。我不知道如何确定可以放入全局数据的对象的最大大小。

堆栈中的可用空间是最小的。 全局数据中的可用空间比这要大。 堆中的可用空间是最大的。

如果您的对象太大而无法放入堆栈，请尝试放入全局数据。 如果您的对象太大而无法容纳全局数据，请使用堆。

【讨论】：

int arr[1000000000]; 是一个对象吗？真的吗？

@StahlRat，在 C++ 对象模型中，每个变量都是一个对象。

C++ 标准的附录 B 将 262144 命名为最大对象大小的指南。如果我理解正确，这意味着对于非动态 int 数组，任何不超过 262144 / sizeof(int) 的元素都应该可以通过高质量的实现。但当然，“这些数量仅作为指导，并不能确定合规性”。

@StahlRat：虽然对象不是类。它们更像是 ADT（抽象数据类型）。