H264和h265编码

最新推荐文章于 2023-09-01 15:55:32 发布

~怎么回事啊~

最新推荐文章于 2023-09-01 15:55:32 发布

阅读量2.7k

点赞数

分类专栏： ffmpeg 文章标签： ffmpeg

本文链接：https://blog.csdn.net/LIJIWEI0611/article/details/118309089

版权

ffmpeg 专栏收录该内容

18 篇文章 5 订阅

订阅专栏

未压缩的码流：一秒钟码流大小:640x480x1.5x15x8=55296000 (是55MB)其中 1.5是yuv占用1.5倍，rgb是3倍,8是一个字节是八位bit

H264的建议码流是500kpbs,因此压缩比是100

电影一般帧率大于60帧；在线教育，实时通信一般是15帧

工具使用

https://blog.csdn.net/leixiaohua1020/article/details/34553607

https://sourceforge.net/projects/videoeye/

码流参考表

https://docs.agora.io/cn/Video/video_profile_windows?platform=Windows

GOP

在视频编码序列中，GOP即Group of picture（图像组），强相关的一组帧

10分钟的帧数按照相关性进行分组：将看望远镜的分成一组，打游戏的分成一组，每一个GOP都是同一个动作的细微差别；在同一个组内的视频帧强相关，即GOP，Group of picture（图像组），不同组的帧弱相关

对这样一组帧来说，进行压缩时就比较容易：因为所有的图片都是这个小人，区别在小人的姿势；可以将相同的区域用一张图进行表示

编码帧的分类：

在视频编码序列中，主要有三种编码帧：I帧、P帧、B帧，如下图所示。

● I帧即Intra-coded picture（帧内编码图像帧），不参考其他图像帧，只利用本帧的信息进行编码，解码时只需要本帧数据就可以完成
● P帧即Predictive-codedPicture（预测编码图像帧），利用之前的I帧或P帧，采用运动预测的方式进行帧间预测编码，P帧没有完整画面数据，只有与前一帧的画面差别的数据
● B帧即Bidirectionallypredicted picture（双向预测编码图像帧)，提供最高的压缩比，它既需要之前的图像帧(I帧或P帧)，也需要后来的图像帧(P帧)，采用运动预测的方式进行帧间双向预测编码

　　在视频编码序列中，GOP即Group of picture（图像组），指两个I帧之间的距离，Reference（参考周期）指两个P帧之间的距离（如下图3.1）。一个I帧所占用的字节数大于一个P帧，一个P帧所占用的字节数大于一个B帧（如下图3.1所示）。

编码顺序：编码I帧后，向后找到相似程度相差30%的P帧，然后向前编码B帧

　　所以在码率不变的前提下，GOP值越大，P、B帧的数量会越多，画面细节更多，也就更容易获取较好的图像质量；Reference越大，B帧的数量越多，同理也更容易获得较好的图像质量。

　　需要说明的是，通过提高GOP值来提高图像质量是有限度的，在遇到场景切换的情况时，H.264编码器会自动强制插入一个I帧，此时实际的GOP值被缩短了。另一方面，在一个GOP中，P、B帧是由I帧预测得到的，当I帧的图像质量比较差时，会影响到一个GOP中后续P、B帧的图像质量，直到下一个GOP开始才有可能得以恢复，所以GOP值也不宜设置过大。

　　同时，由于P、B帧的复杂度大于I帧，所以过多的P、B帧会影响编码效率，使编码效率降低。另外，过长的GOP还会影响Seek操作（找I帧）的响应速度，由于P、B帧是由前面的I或P帧预测得到的，所以Seek操作需要直接定位，解码某一个P或B帧时，需要先解码得到本GOP内的I帧及之前的N个预测帧才可以，GOP值越长，需要解码的预测帧就越多，seek响应的时间也越长。

从上面的解释看，我们知道I和P的解码算法比较简单，资源占用也比较少，I只要自己完成就行了，P呢，也只需要解码器把前一个画面缓存一下，遇到P时就使用之前缓存的画面就好了，如果视频流只有I和P，解码器可以不管后面的数据，边读边解码，线性前进，大家很舒服。
但网络上的电影很多都采用了B帧，因为B帧记录的是前后帧的差别，比P帧能节约更多的空间，但这样一来，文件小了，解码器就麻烦了，因为在解码时，不仅要用之前缓存的画面，还要知道下一个I或者P的画面（也就是说要预读预解码），而且，B帧不能简单地丢掉，因为B帧其实也包含了画面信息，如果简单丢掉，并用之前的画面简单重复，就会造成画面卡（其实就是丢帧了），并且由于网络上的电影为了节约空间，往往使用相当多的B帧，B帧用的多，对不支持B帧的播放器就造成更大的困扰，画面也就越卡。

一般平均来说，I的压缩率是7（跟JPG差不多），P是20，B可以达到50，可见使用B帧能节省大量空间，节省出来的空间可以用来保存多一些I帧，这样在相同码率下，可以提供更好的画质。

宏块原理

H.264的宏块，也是编码标准的基本处理单元，通常它的大小也为16x16像素。但在H.264的简介一文中我们就说过，H.264的预测图块可以小到4x4像素。所以这也促成了，16x16像素的宏块，可以接着再划分成子宏块这一操作。

在这里插入图片描述

在实际的H.264编码时，可能会使用8x8、或4x8、或8x4、或4x4像素的子宏块，也有可能是它们的组合。
//像素块越小，编码的复杂度也会随之增加，编码效率自然就会降低。但是这样是值得的，因为图像的压缩效率有了显著提高，也就是编码后得到的相同质量的图像，H.264的压缩比更大，占用的空间及带宽更小。

而在H.264编码过程中，与宏块的划分直接相关的，就是帧内预测和帧间预测了。注意我们现在讨论的，是H.264的帧内预测和帧间预测。

这里有两点需要注意：
（1）在H.264里，我们说的是帧内预测，注意是预测，并不是帧内编码。
（2）在H.264里，我们试图描述的，是把宏块与帧内预测和帧间预测联系起来。

例如：VideoEye中：

SPS 和PPS

https://blog.csdn.net/u010925568/article/details/75040492?utm_medium=distribute.pc_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromMachineLearnPai2%7Edefault-13.control&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromMachineLearnPai2%7Edefault-13.control

H264中的profile和level

profile

Main > CONSTERAINED BASELINE，用的最多的是垂直分支

在每一层都是增加了新的压缩特性，使得压缩比更高

H264SPS中的重要参数

PPS与Slice Header

H264 码流结构详解

一、码流的组织形式

在 H264 中完全没有 I 帧、P 帧、B 帧、IDR 帧的概念，之所以沿用这些说法是为了表明数据的编码模式。H264 码流的组织形式从大到小排序是：视频序列(video sequence)、图像(frame/field-picture)、片组(slice group)、片(slice)、宏块(macroblock)、子块(sub-block)、像素(pixel)。

二、码流功能的角度

从码流功能的角度可以分为两层：视频编码层（VCL）和网络提取层（NAL）

VCL：进行视频编解码，包括预测（帧内预测和帧间预测），DCT 变化和量化，熵编码和切分数据等功能，是为了实现更高的视频压缩比。
NAL：负责以网络所要求的恰当的方式对 VCL 数据进行打包和传送。

VCL 是管理 H264 的视频数据层，是为了实现更高的视频压缩比，那 VCL 究竟是怎么管理 H264 视频数据的呢？抛开 H264 压缩算法细节来看就 3 步：

压缩：预测（帧内预测和帧间预测）-> DCT 变化和量化 -> 比特流编码；
切分数据，主要为了第三步。这里一点，网上看到的“切片（slice）”、“宏块（macroblock）”是在VCL 中的概念，一方面提高编码效率和降低误码率、另一方面提高网络传输的灵活性。
压缩切分后的 VCL 数据会包装成为 NAL 中的一部分。

下面要重点讲解下 NAL。

三、网络提取层（NAL）

NAL，英文全称为 Network Abstraction Layer，这块和 H264 压缩算法无关，涉设计出 NAL 的目的就是为了获得 “network-friendly”，即为了实现良好的网络亲和性，即可适用于各种传输网络。

终于要讲 NAL 了，但是，我们需要先看 NAL的组成单元 - NALU。

3.1 NAL单元 - NALU

NALU 的格式如下图（引用H264 PDF）所示：

很明显，NALU 由头和身体两个部分组成：

头：一般存储标志信息，譬如 NALU 的类型。前面讲过 NAL 会打包 VCL 数据，但是这并不意味着所有的 NALU 负载的都是 VCL，也有一些 NALU 仅仅存储了和编解码信息相关的数据；
身体：存储了真正的数据。但实际上，这块也会相对比较复杂，前面其实也提到过 H264 的一个目的是“网络友好性”，说白了就是能够很好地适配各种传输格式。所以根据实际采用数据传输流格式，也会对这部分数据格式再进行处理。

3.2 NALU Header

首先，NALU Header只占 1 个字节，即 8 位，其组成如下图所示：

forbidden_zero_bit

在网络传输中发生错误时，会被置为 1，告诉接收方丢掉该单元；否则为 0。
nal_ref_idc
用于表示当前NALU的重要性，值越大，越重要。
解码器在解码处理不过来的时候，可以丢掉重要性为 0 的 NALU。
nal_unit_type
表示 NALU 数据的类型，有以下几种：

其中比较注意的应该是以下几个：

1-4：I/P/B帧，如果 nal_ref_idc 为 0，则表示 I 帧，不为 0 则为 P/B 帧。
5：IDR帧，I 帧的一种，告诉解码器，之前依赖的解码参数集合（接下来要出现的 SPS\PPS 等）可以被刷新了。
6：SEI，英文全称 Supplemental Enhancement Information，翻译为“补充增强信息”，提供了向视频码流中加入额外信息的方法。
7：SPS，全称 Sequence Paramater Set，翻译为“序列参数集”。SPS 中保存了一组编码视频序列（Coded Video Sequence）的全局参数。因此该类型保存的是和编码序列相关的参数。
8: PPS，全称 Picture Paramater Set，翻译为“图像参数集”。该类型保存了整体图像相关的参数。
9：AU 分隔符，AU 全称 Access Unit，它是一个或者多个 NALU 的集合，代表了一个完整的帧，有时候用于解码中的帧边界识别。

特殊的 NALU 类型：SPS和PPS

SPS 和 PPS 存储了编解码需要一些图像参数，SPS,PPS 需要在 I 帧前出现，不然解码器没法解码。而 SPS,PPS 出现的频率也跟不同应用场景有关，对于一个本地 h264 流，可能只要在第一个 I 帧前面出现一次就可以，但对于直播流，每个 I 帧前面都应该插入 sps 或 pps，因为直播时客户端进入的时间是不确定的。

3.3 NALU Payload

很少有资料会称身体部分为 Payload，绝大部分资料对 NALU 组成的定义是这样子的：

NALU = NALU Header + SODB // 定义1
NALU = NALU Header + RBSP // 定义2
NALU = NALU Header + EBSP // 定义3

于是新的问题来了：SODB，RBSP和EBSP都是什么东西呢？这块概念，在博客NALU详解二（EBSP、RBSP与SODB）中介绍得非常清楚，总结来说就是：

SODB

英文全称 String Of Data Bits，称原始数据比特流，就是最原始的编码/压缩得到的数据。

RBSP

英文全称 Raw Byte Sequence Payload，又称原始字节序列载荷。和 SODB 关系如下：

RBSP = SODB + RBSP Trailing Bits（RBSP尾部补齐字节）

引入 RBSP Trailing Bits 做 8 位字节补齐。

EBSP

英文全称 Encapsulated Byte Sequence Payload，称为扩展字节序列载荷。和 RBSP 关系如下：

EBSP ：RBSP插入防竞争字节（`0x03`）

这里说明下防止竞争字节（0x03）：读者可以先认为 H264 会插入一个叫做 StartCode 的字节串来分割 NALU，于是问题来了，如果 RBSP 中也包括了 StartCode（0x000001 或 0x00000001）怎么办呢？所以，就有了防止竞争字节（0x03）：

编码时，扫描 RBSP，如果遇到连续两个 0x00 字节，就在后面添加 防止竞争字节（0x03）；解码时，同样扫描 EBSP，进行逆向操作即可。

最后，以一幅图总结 NALU 这段内容：

四、码流解析的角度

H264 码流实际可以理解为由一个一个的 NALU 单元组成。（下图中的 RBSP 类似 NALU Payload）

前面提到的一帧图像（I 帧, P 帧, B 帧）就是一个 NALU 单元，NALU 单元除了代表图像外还能包含其他类型的数据，如 PPS 和 SPS。

五、H264更详细的分层结构

第一层：比特流。该层有两种格式：Annexb 格式和 RTP 格式。
第二层：NAL Unit 层。包含了 NAL Header 和 NAL Body 信息。
第三层：Slice 层。一帧视频图像可编码成一个或者多个片，每片包含整数个宏块，即每片至少一个宏块，最多时包含整个图像的宏块。
第四层：Slice data 层。Slice 由宏块（macro block, MB）组成。宏块是编码处理的基本单元。
第五层：PCM 类。
第六层：残差层。

片的目的：

为了限制误码的扩散和传输，使编码片相互间保持独立。片共有 5 种类型： I 片（只包含 I 宏块）、P 片（P 和 I 宏块）、B 片（B 和 I 宏块）、SP 片（用于不同编码流之间的切换）和 SI 片（特殊类型的编码宏块）。

六、扩展：怎么区分 NALU 的边界？

了解了 NALU 之后，关于 H264 格式，还有一个问题：解码器怎么知道一个 NALU 要结束了？或者说它怎么区分 NALU 的边界？

要回答这个问题，就必须了解 H264 的打包方式，通俗来说是H264 如何组织一连串的 NALU 为完整的 H264 码流。目前 H264 主流的两种格式：

Annex-B：本文关于 NALU 的很多细节介绍都是 Annex-B，它依靠前文提到的 Start Code 来分隔 NALU，打包方式如下：
```
[start code]--[NALU]--[start code]--[NALU]...
```
AVCC：笔者对这个格式了解的不多，从网上找到很多资料知道以下几点：
- 由 NALU 和 extradata/sequence header 组成，由于在 extradata/sequence header 中存储了 NALU 的长度，因此 NALU Payload 不需要做字节对齐，不过防竞争字节还是有的；
- SPS 和 PPS 被放在了 extradata/sequence header。
- 打包方式如下：
```
[SIZE (4 bytes)]--[NAL]--[SIZE (4 bytes)]--[NAL]... // 请注意，SIZE一般为4字节，但是具体以实际为准
```

至于为什么要有这两类格式，还需要查阅更多的资料。不过 StackOverflow 上关于Possible Locations for Sequence/Picture Parameter Set(s) for H.264 Stream的回答可以帮助深入了解这两种格式，推荐阅读。

下面是一个Ｈ264 码流，可以看到每个 NALU 前有一个 StartCode（0x000001 或 0x00000001），作为 NALU 的分割符：

起始码：如果NALU对应的Slice为一帧的开始，则用4字节表示，即0x00000001；否则用3字节表示，0x000001。 NAL Header：forbidden_bit，nal_reference_bit（优先级），nal_unit_type（类型）。脱壳操作：为了使NALU主体不包括起始码，在编码时每遇到两个字节（连续）的0，就插入一字节0x03，以和起始码相区别。解码时，则将相应的0x03删除掉。

分析其中比较有代表性的３帧：

00 00 00 01 67
00 00 00 01 是一个 NALU 开始，67 是Header, 二进制为 0110 0111, nal_unit_type 为00111，即７为 SPS 帧。
00 00 00 01 68
68 二进制为 0110 1000，nal_unit_type 为0 1000，即 8 为 PPS 帧。
00 00 00 01 65
65 二进制为 0110 0101，nal_unit_type 为 00101, 即 5 为 IDR 帧。

NAL单元解码的流程为：

首先从NAL单元中提取出RBSP语法结构，然后按照如图4所示的流程处理RBSP语法结构。输入的是NAL单元，输出结果是经过解码的当前图像的样值点。 NAL单元中分别包含了序列参数集和图像参数集。图像参数集和序列参数集在其他NAL单元传输过程中作为参考使用，在这些数据NAL单元的片头中，通过语法元素pic_parameter_set_id设置它们所使用的图像参数集编号；而相应的每个图像参数集中，通过语法元素seq_paramter_set_id设置他们使用的序列参数集编号。

SSP PPS格式

h264文档

SPS（序列参数集）的结构，再7.3.2.1.1里面包含了SPS结构的介绍

https://blog.csdn.net/yp18792574062/article/details/104776931/?utm_medium=distribute.pc_relevant.none-task-blog-2~default~baidujs_title~default-0.control&spm=1001.2101.3001.4242

H265编码

参考：https://blog.csdn.net/u011003120/article/details/83411445

h265（HEVC）nal单元头

与h264的nal层相比，h265的nal unit header有两个字节构成，如下图所示

从图中可以看出hHEVC的nal包结构与h264有明显的不同，hevc加入了nal所在的时间层的ＩＤ，取去除了nal_ref_idc，此信息合并到了naltype中，

通常情况下F为0，layerid为0, TID为1。

H265 帧类型判断：

和264的&0x1f不同。265是 :
int type = (code & 0x7E)>>1;

在文件中查找00 00 00 01NALU头，发现在有6种开头分别为：

00 00 00 01 40 01 的nuh_unit_type的值为 32，语义为视频参数集 VPS

00 00 00 01 42 01 的nuh_unit_type的值为 33，语义为序列参数集 SPS

00 00 00 01 44 01 的nuh_unit_type的值为 34，语义为图像参数集 PPS

00 00 00 01 4E 01 的nuh_unit_type的值为 39，语义为补充增强信息 SEI

00 00 00 01 26 01 的nuh_unit_type的值为 19，语义为可能有RADL图像的IDR图像的SS编码数据 IDR

00 00 00 01 02 01 的nuh_unit_type的值为1，语义为被参考的后置图像，且非TSA、非STSA的SS编码数据

在编码过程中，从编码器获取码流的时候，1、2、3、4、5是在一帧数据当中。相当于H264的I帧。

Nalu Type的定义

enum NalUnitType  
{  
  NAL_UNIT_CODED_SLICE_TRAIL_N = 0,   // 0  
  NAL_UNIT_CODED_SLICE_TRAIL_R,   // 1  
    
  NAL_UNIT_CODED_SLICE_TSA_N,     // 2  
  NAL_UNIT_CODED_SLICE_TLA,       // 3   // Current name in the spec: TSA_R  
    
  NAL_UNIT_CODED_SLICE_STSA_N,    // 4  
  NAL_UNIT_CODED_SLICE_STSA_R,    // 5  
  
  NAL_UNIT_CODED_SLICE_RADL_N,    // 6  
  NAL_UNIT_CODED_SLICE_DLP,       // 7 // Current name in the spec: RADL_R  
    
  NAL_UNIT_CODED_SLICE_RASL_N,    // 8  
  NAL_UNIT_CODED_SLICE_TFD,       // 9 // Current name in the spec: RASL_R  
  
  NAL_UNIT_RESERVED_10,  
  NAL_UNIT_RESERVED_11,  
  NAL_UNIT_RESERVED_12,  
  NAL_UNIT_RESERVED_13,  
  NAL_UNIT_RESERVED_14,  
  NAL_UNIT_RESERVED_15, NAL_UNIT_CODED_SLICE_BLA,       // 16   // Current name in the spec: BLA_W_LP  
NAL_UNIT_CODED_SLICE_BLA,       // 16   // Current name in the spec: BLA_W_LP  
  NAL_UNIT_CODED_SLICE_BLANT,     // 17   // Current name in the spec: BLA_W_DLP  
  NAL_UNIT_CODED_SLICE_BLA_N_LP,  // 18  
  NAL_UNIT_CODED_SLICE_IDR,       // 19  // Current name in the spec: IDR_W_DLP  
  NAL_UNIT_CODED_SLICE_IDR_N_LP,  // 20  
  NAL_UNIT_CODED_SLICE_CRA,       // 21  
  NAL_UNIT_RESERVED_22,  
  NAL_UNIT_RESERVED_23,  
  
  NAL_UNIT_RESERVED_24,  
  NAL_UNIT_RESERVED_25,  
  NAL_UNIT_RESERVED_26,  
  NAL_UNIT_RESERVED_27,  
  NAL_UNIT_RESERVED_28,  
  NAL_UNIT_RESERVED_29,  
  NAL_UNIT_RESERVED_30,  
  NAL_UNIT_RESERVED_31,  
  
  NAL_UNIT_VPS,                   // 32  
  NAL_UNIT_SPS,                   // 33  
  NAL_UNIT_PPS,                   // 34  
  NAL_UNIT_ACCESS_UNIT_DELIMITER, // 35  
  NAL_UNIT_EOS,                   // 36  
  NAL_UNIT_EOB,                   // 37  
  NAL_UNIT_FILLER_DATA,           // 38  
  NAL_UNIT_SEI,                   // 39 Prefix SEI  
  NAL_UNIT_SEI_SUFFIX,            // 40 Suffix SEI  
  NAL_UNIT_RESERVED_41,  
  NAL_UNIT_RESERVED_42,  
  NAL_UNIT_RESERVED_43,  
  NAL_UNIT_RESERVED_44,  
  NAL_UNIT_RESERVED_45,  
  NAL_UNIT_RESERVED_46,  
  NAL_UNIT_RESERVED_47,  
  NAL_UNIT_UNSPECIFIED_48,  
  NAL_UNIT_UNSPECIFIED_49,  
  NAL_UNIT_UNSPECIFIED_50,  
  NAL_UNIT_UNSPECIFIED_51,  
  NAL_UNIT_UNSPECIFIED_52,  
  NAL_UNIT_UNSPECIFIED_53,  
  NAL_UNIT_UNSPECIFIED_54,  
  NAL_UNIT_UNSPECIFIED_55,  
  NAL_UNIT_UNSPECIFIED_56,  
  NAL_UNIT_UNSPECIFIED_57,  
  NAL_UNIT_UNSPECIFIED_58,  
  NAL_UNIT_UNSPECIFIED_59,  
  NAL_UNIT_UNSPECIFIED_60,  
  NAL_UNIT_UNSPECIFIED_61,  
  NAL_UNIT_UNSPECIFIED_62,  
  NAL_UNIT_UNSPECIFIED_63,  
  NAL_UNIT_INVALID,  
};

SPS解析

重新定义类型

typedef unsigned char   uint8;   
 
typedef unsigned short uint16;
 
typedef unsigned longuint32;
typedef unsigned __int64uint64;
typedef signed charint8;
typedef signed shortint16;
typedef signed longint32;
typedef signed __int64int64;

定义Sps 需要的相关参数

struct vc_params_t
{
	LONG width,height;
	DWORD profile, level;
	DWORD nal_length_size;
	void clear()
	{
		memset(this, 0, sizeof(*this));
	}
};

定义网络抽象层Nal类

1、H265一个图像序列的组成：VPS+SPS+PPS+SEI+一个I帧+若干个P帧。VPS、SPS、PPS、SEI、一个I帧、一个P帧都可以称为一个NALU。

2、H265的NALU结构：开始码+NALU头+NALU数据
（1）、开始码大小为四个字节，是一个固定值00 00 00 01（十六进制），标识一个NALU的开始。
（2）、NALU头大小为两个字节，共16位，第1位值为0，第2-7位为NALU的type位（共6位），标识当前NALU的类型
，第8-15位值为0，第16位值为1。
（3）、NALU数据为编码器编出来的图像信息或图像数据。

3、六种类型的NALU
（1）、VPS（视频参数集）：NALU头值为0x40 01（十六进制），NALU头type位值为32（十进制）。
（2）、SPS（序列参数集）：NALU头值为0x42 01（十六进制），NALU头type位值为33（十进制）。
（3）、PPS（图像参数集）：NALU头值为0x44 01（十六进制），NALU头type位值为34（十进制）。
（4）、SEI（补充增强信息）：NALU头值为0x4e 01（十六进制），NALU头type位值为39（十进制）。
（5）、I帧：NALU头值为0x26 01（十六进制），NALU头type位值为19（十进制）。
（6）、P帧：NALU头值为0x02 01（十六进制），NALU头type位值为1（十进制）。

4、H265的NALU打包成RTP包的模式（下面是用到的两种模式）
（1）、一个NALU打包成一个RTP包，只需要在一个12字节的RTP包头后添加去掉开始码的NALU即可
（这种模式在一个NALU的大小小于MTU时使用）。
（2）、一个NALU打包成几个RTP包（FUs模式），在12个字节的RTP头后面有两个字节的PayloadHdr和一个字节的FU
header。PayloadHdr的值等于NALU头的type位改为49（十进制）后的值，FU header第1位标记RTP包是否为NALU的第一片，第2位标
记RTP包是否为NALU的最后一片。后6位是NALU头的type位。

~怎么回事啊~

关注

0
点赞
踩
14

收藏

觉得还不错? 一键收藏
0
评论
H264和h265编码

未压缩的码流：一秒钟码流大小:640x480x1.5x15x8=55296000 (是55MB)其中 1.5是yuv占用1.5倍，rgb是3倍,8是一个字节是八位bitH264的建议码流是500kpbs,因此压缩比是100电影一般帧率大于60帧；在线教育，实时通信一般是15帧码流参考表https://docs.agora.io/cn/Video/video_profile_windows?platform=WindowsGOP 在视频编码序列中，GOP即Group of...
复制链接

扫一扫