视频的基本参数及H264编解码相关概念

时间  2021-08-12
标签 html ios 算法 缓存 bash markdown 网络 session 数据结构 框架 栏目 HTML 繁體版
原文   原文链接

概述

上几篇文章介绍了音频的采集以及编码，如今咱们开始学习视频相关的知识，一样先从概念开始。本篇文章的主要内容有：html

  • 视频相关参数
    • 帧率(fps)
    • 分辨率
    • DTS和PTS
    • 码率
    • 音视频同步
  • 对视频编解码的概述
  • H264编码原理以及对I帧、B帧、P帧的介绍
    • H264编码原理
    • 对序列的说明
    • 简单介绍压缩算法
    • 三种帧的不一样
    • DTS和PTS的不一样
  • IOS系统H.264视频硬件编解码说明
    • 对VideoToolBox的介绍
    • VideoToolBox中的对象
    • 硬解码流程
    • 硬编码流程

关于视频硬编码和软编码实现可参考--视频H264硬编码和软编码&编译ffmpeg库及环境搭建(附完整demo)ios

视频相关参数

帧率

帧率（Frame rate）是用于测量显示帧数的量度。所谓的测量单位为每秒显示帧数(Frames per Second，简称：FPS）或“赫兹”（Hz）算法

因为人类眼睛的特殊生理结构，若是所看画面之帧率高于24的时候，就会认为是连贯的，此现象称之为视觉暂留。这也就是为何电影胶片是一格一格拍摄出来，而后快速播放的。 而对游戏，通常来讲，第一人称射击游戏比较注重FPS的高低，若是FPS<30的话，游戏会显得不连贯。因此有一句有趣的话：“FPS（指FPS游戏）重在FPS（指帧率）。缓存

每秒的帧数(fps)或者说帧率表示图形处理器处理场时每秒钟可以更新的次数。高的帧率能够获得更流畅、更逼真的动画。通常来讲30fps就是能够接受的，可是将性能提高至60fps则能够明显提高交互感和逼真感，可是通常来讲超过75fps通常就不容易察觉到有明显的流畅度提高了。若是帧率超过屏幕刷新率只会浪费图形处理的能力，由于监视器不能以这么快的速度更新，这样超过刷新率的帧率就浪费掉了。bash

咱们能够根据帧率得出连续两帧的时间间隔。好比帧率为30FPS,那么相邻两帧的时间间隔为 33msmarkdown

分辨率

显示分辨率（屏幕分辨率）是屏幕图像的精密度，是指显示器所能显示的像素有多少。因为屏幕上的点、线和面都是由像素组成的，显示器可显示的像素越多，画面就越精细，一样的屏幕区域内能显示的信息也越多，因此分辨率是个很是重要的性能指标之一。能够把整个图像想象成是一个大型的棋盘，而分辨率的表示方式就是全部经线和纬线交叉点的数目。显示分辨率必定的状况下，显示屏越小图像越清晰，反之，显示屏大小固定时，显示分辨率越高图像越清晰。网络

IOS中常见的分辨率有： 1080P(1920 x 1080) 、720P(1280 x 720) 、480P（640 x 480）、360Psession

ios设置分辨率的代码：数据结构

+ (void)resetSessionPreset:(AVCaptureSession *)m_session andHeight:(int)g_height_size
	{
    [m_session beginConfiguration];
    switch (g_height_size) {
        case 1080:
            m_session.sessionPreset = [m_session canSetSessionPreset:AVCaptureSessionPreset1920x1080] ? AVCaptureSessionPreset1920x1080 : AVCaptureSessionPresetHigh;
            break;
        case 720:
            m_session.sessionPreset = [m_session canSetSessionPreset:AVCaptureSessionPreset1280x720] ? AVCaptureSessionPreset1280x720 : AVCaptureSessionPresetMedium;
            break;
        case 480:
            m_session.sessionPreset = [m_session canSetSessionPreset:AVCaptureSessionPreset640x480] ? AVCaptureSessionPreset640x480 : AVCaptureSessionPresetMedium;
            break;
        case 360:
            m_session.sessionPreset = AVCaptureSessionPresetMedium;
            break;
            
        default:
            break;
    }
    [m_session commitConfiguration];
	}
复制代码

DTS和PTS

概念

  • DTS(Decoding Time Stamp) : 即解码时间戳，是解码器进行解码时相对于SCR(系统参考时间)的时间戳。它主要标识读入内存的bit流在何时开始送入解码器中进行解码。
  • PTS(Presentation Time Stamp) : 即显示时间戳，是显示帧时相对于SCR的时间戳。它主要是度量解码后的视频何时被显示出来。

DTS主要用于视频的解码，在解码阶段使用。PTS主要用于视频的同步和输出，在 display 的时候使用。在没有B帧的状况下，DTS和PTS的输出顺序是同样的。框架

如下内容摘自网络

DTS 时间戳决定了解码器在SCR时间等于DTS时间时进行解码，PTS时间戳也是相似的。一般，DTS/PTS时间戳指示的是晚于音视频包中的SCR的一个时 间。例如，若是一个视频数据包的SCR是100ms（意味着此包是播放100ms之后从磁盘中读取的），那么DTS/PTS值就差很少是200 /280ms，代表当SCR到200ms时这个视频数据应该被解码并在80ms之后被显示出来（视频数据在一个buffer中一直保存到开始解码） 下 溢一般发生在设置的视频数据流相关mux率过高。若是mux率是1000000bits/sec（意味着解码器要以1000000bits/sec的速率 读取文件），但是视频速率是2000000bits/sec（意味着须要以2000000bits/sec的速率显示视频数据），从磁盘中读取视频数据时 速度不够快以致于1秒钟内不可以读取足够的视频数据这种状况下DTS/PTS时间戳就会指示视频在从硬盘中读出来以前进行解码或显示（DTS/PTS时间戳就要比包含它们的数据包中的SCR时间要早了）。

现在依靠解码器，着基本已经不是什么问题了（尽管MPEG文件由于应该没有下溢而并不彻底符合MPEG标准）。一些解码器（不少著名的基于PC的播放器）尽量快的读取文件以便显示视频，能够的话直接忽略SCR。

注意在你提供的列表中，平均的视频流速率为～3Mbps（3000000bits/sec）可是它的峰值达到了14Mbps（至关大，DVD限制在 9.8Mbps内）。这意味着mux率须要调整足够大以处理14Mbps的部分， bbMPEG计算出来的mux率有时候过低而致使下溢。 你计划让视频流速率这么高么？这已经超过了DVD的说明了，并且极可能在大多数独立播放其中都不能播放。若是你不是这么计划，我会从1增长mquant的值而且在视频设置中将最大码流设置为9Mbps以保持一个小一点的码流。

若是你确实想让视频码率那么高，你须要增大mux率。从提供的列表能够得出bbMPEG使用14706800bits/sec或者1838350bytes /sec的mux率（总数据速率为：1838350bytes/sec（14706800bits/sec）行）。你在强制mux率字段设置的值应该是以 bytes/sec为单位并被50整除。因此我会从36767（1838350/50）开始，一直增长直到不会再出现下溢错误为止；

码率(比特率)

关于码率

因为保存完整的一帧一帧图片的视频原文件太大，必需要经过某种视频压缩算法将视频中的图片压缩，以减少视频文件大小，那么压缩比越大，解压缩还原后用来播放的视频就会有越严重的失真，由于压缩的同时不可避免的丢失了视频中原来图像的数据信息。在理解这个的前提下，我来举个例子，一个分辨率为1080P的原视频（未经压缩）被压缩成分别为4GB 和 1GB的两个视频文件。因为1GB的视频的压缩比更大，因此在观看1GB视频的明显感受到没有4GB视频清晰（虽然他们的分辨率都是1080P)。

码率又称比特率，是指在压缩视频的时候给这个视频指定一个参数，用以告诉压缩软件指望的压缩后视频的大小。码率的英文名为bps(bit per second)，就是用平均每秒多少bit来衡量一个视频大小。

计算视频的码率

咱们能够根据一个视频的长度和大小来推断出该视频的比特率是多少。下面是一个具体的例子。

一段1080P的视频长度为100分钟，大小为1GB，那么该视频的比特率是多少？

100min = 100*60s = 6000s;
1G = 1024M = 1024*1024KB = 1024*1024*1024Bit = 1024*1024*1024*8bit = 8589934592bit;
比特率 = 8589934592/6000s = 1431655b/s = 1.4Mbit/s;
复制代码

那么这个视频的码率大概就是 1.4Mbit/s,这个比特率在在线视频中已是很是高的了，通常主流视频平台的最高码率在1Mbit左右，好比直播网站斗鱼的高清选项实际播放的视频码率是900Kbit/s(0.9Mbit)。

咱们能够得出结论：对于时间长度相同的视频，码率越大，视频的大小越大，视频的画质就越清晰(不考虑各类压缩算法的优劣)，这是最直观的感受。码率对于视频是很是重要的。

音视频同步

上面说了视频帧、DTS、PTS 相关的概念。咱们都知道在一个媒体流中，除了视频之外，一般还包括音频。音频的播放，也有 DTS、PTS 的概念，可是音频没有相似视频中 B 帧，不须要双向预测，因此音频帧的 DTS、PTS 顺序是一致的。

音频视频混合在一块儿播放，就呈现了咱们经常看到的广义的视频。在音视频一块儿播放的时候，咱们一般须要面临一个问题：怎么去同步它们，以避免出现画不对声的状况。

要实现音视频同步，一般须要选择一个参考时钟，参考时钟上的时间是线性递增的，编码音视频流时依据参考时钟上的时间给每帧数据打上时间戳。在播放时，读取数据帧上的时间戳，同时参考当前参考时钟上的时间来安排播放。这里的说的时间戳就是咱们前面说的 PTS。实践中，咱们能够选择：同步视频到音频、同步音频到视频、同步音频和视频到外部时钟。

对视频编解码的概述

软编码和硬编码的概念

软编码：使用CPU进行编码。

硬编码：不使用CPU进行编码，使用显卡GPU,专用的DSP、FPGA、ASIC芯片等硬件进行编码。

软编码和硬编码的比较

软编码：实现直接、简单，参数调整方便，升级易，但CPU负载重，性能较硬编码低，低码率下质量一般比硬编码要好一点。

硬编码：性能高，低码率下一般质量低于硬编码器，但部分产品在GPU硬件平台移植了优秀的软编码算法（如X264）的，质量基本等同于软编码。

ios系统中的硬编码

苹果在iOS 8.0系统以前，没有开放系统的硬件编码解码功能，不过Mac OS系统一直有，被称为Video ToolBox的框架来处理硬件的编码和解码，终于在iOS 8.0后，苹果将该框架引入iOS系统。

H264编码原理以及I帧B帧P帧

H264编码原理

H264是新一代的编码标准，以高压缩高质量和支持多种网络的流媒体传输著称，在编码方面，我理解的他的理论依据是：参照一段时间内图像的统计结果代表，在相邻几幅图像画面中，通常有差异的像素只有10%之内的点,亮度差值变化不超过2%，而色度差值的变化只有1%之内。因此对于一段变化不大图像画面，咱们能够先编码出一个完整的图像帧A，随后的B帧就不编码所有图像，只写入与A帧的差异，这样B帧的大小就只有完整帧的1/10或更小！B帧以后的C帧若是变化不大，咱们能够继续以参考B的方式编码C帧，这样循环下去。这段图像咱们称为一个序列（序列就是有相同特色的一段数据），当某个图像与以前的图像变化很大，没法参考前面的帧来生成，那咱们就结束上一个序列，开始下一段序列，也就是对这个图像生成一个完整帧A1，随后的图像就参考A1生成，只写入与A1的差异内容。

在H264协议里定义了三种帧，完整编码的帧叫I帧，参考以前的I帧生成的只包含差别部分编码的帧叫P帧，还有一种参考先后的帧编码的帧叫B帧。

H264采用的核心算法是帧内压缩和帧间压缩，帧内压缩是生成I帧的算法，帧间压缩是生成B帧和P帧的算法。

对序列的说明

在H264中图像以序列为单位进行组织，一个序列是一段图像编码后的数据流，以I帧开始，到下一个I帧结束。

一个序列的第一个图像叫作 IDR 图像（当即刷新图像），IDR 图像都是 I 帧图像。H.264 引入 IDR 图像是为了解码的重同步，当解码器解码到 IDR 图像时，当即将参考帧队列清空，将已解码的数据所有输出或抛弃，从新查找参数集，开始一个新的序列。这样，若是前一个序列出现重大错误，在这里能够得到从新同步的机会。IDR图像以后的图像永远不会使用IDR以前的图像的数据来解码。

一个序列就是一段内容差别不太大的图像编码后生成的一串数据流。当运动变化比较少时，一个序列能够很长，由于运动变化少就表明图像画面的内容变更很小，因此就能够编一个I帧，而后一直P帧、B帧了。当运动变化多时，可能一个序列就比较短了，好比就包含一个I帧和三、4个P帧。

对三种帧的介绍

I帧

为了更好地理解I帧的概念，我罗列了两种解释：

  • 帧内编码帧 ，I帧表示关键帧，你能够理解为这一帧画面的完整保留；解码时只须要本帧数据就能够完成（由于包含完整画面）。

  • 帧内编码帧 又称intra picture，I 帧一般是每一个 GOP（MPEG 所使用的一种视频压缩技术）的第一个帧，通过适度地压缩，作为随机访问的参考点，能够当成图象。I帧能够当作是一个图像通过压缩后的产物。

I帧的特色：

  • 它是一个全帧压缩编码帧。它将全帧图像信息进行JPEG压缩编码及传输
  • 解码时仅用I帧的数据就可重构完整图像
  • I帧描述了图像背景和运动主体的详情
  • I帧不须要参考其余画面而生成
  • I帧是P帧和B帧的参考帧(其质量直接影响到同组中之后各帧的质量)
  • I帧是帧组GOP的基础帧(第一帧),在一组中只有一个I帧
  • I帧不须要考虑运动矢量
  • I帧所占数据的信息量比较大

P帧

为了更好地理解P帧的概念，我也罗列了两种解释：

  • 前向预测编码帧。P帧表示的是这一帧跟以前的一个关键帧（或P帧）的差异，解码时须要用以前缓存的画面叠加上本帧定义的差异，生成最终画面。（也就是差异帧，P帧没有完整画面数据，只有与前一帧的画面差异的数据）
  • 前向预测编码帧 又称predictive-frame，经过充分将低于图像序列中前面已编码帧的时间冗余信息来压缩传输数据量的编码图像，也叫预测帧

**P帧的预测与重构：**P帧是以I帧为参考帧,在I帧中找出P帧“某点”的预测值和运动矢量,取预测差值和运动矢量一块儿传送。在接收端根据运动矢量从I帧中找出P帧“某点”的预测值并与差值相加以获得P帧“某点”样值,从而可获得完整的P帧。

P帧特色:

  • P帧是I帧后面相隔1~2帧的编码帧
  • P帧采用运动补偿的方法传送它与前面的I或P帧的差值及运动矢量(预测偏差)
  • 解码时必须将I帧中的预测值与预测偏差求和后才能重构完整的P帧图像
  • P帧属于前向预测的帧间编码。它只参考前面最靠近它的I帧或P帧
  • P帧能够是其后面P帧的参考帧,也能够是其先后的B帧的参考帧
  • 因为P帧是参考帧,它可能形成解码错误的扩散
  • 因为是差值传送,P帧的压缩比较高

B帧

为了更好地理解P帧的概念，我依然罗列了两种解释：

  • 双向预测内插编码帧。B帧是双向差异帧，也就是B帧记录的是本帧与先后帧的差异（具体比较复杂，有4种状况，但我这样说简单些），换言之，要解码B帧，不只要取得以前的缓存画面，还要解码以后的画面，经过先后画面的与本帧数据的叠加取得最终的画面。B帧压缩率高，可是解码时CPU会比较累。
  • 双向预测内插编码帧 又称bi-directional interpolated prediction frame，既考虑与源图像序列前面已编码帧，也顾及源图像序列后面已编码帧之间的时间冗余信息来压缩传输数据量的编码图像，也叫双向预测帧；

**B帧的预测与重构：**B帧之前面的I或P帧和后面的P帧为参考帧,“找出”B帧“某点”的预测值和两个运动矢量,并取预测差值和运动矢量传送。接收端根据运动矢量在两个参考帧中“找出(算出)”预测值并与差值求和,获得B帧“某点”样值,从而可获得完整的B帧。

B帧的特色：

  • B帧是由前面的I或P帧和后面的P帧来进行预测的
  • B帧传送的是它与前面的I或P帧和后面的P帧之间的预测偏差及运动矢量
  • B帧是双向预测编码帧
  • B帧压缩比最高,由于它只反映丙参考帧间运动主体的变化状况,预测比较准确
  • B帧不是参考帧,不会形成解码错误的扩散

I、B、P各帧是根据压缩算法的须要，是人为定义的,它们都是实实在在的物理帧。通常来讲，I帧的压缩率是7（跟JPG差很少），P帧是20，B帧能够达到50。可见使用B帧能节省大量空间，节省出来的空间能够用来保存多一些I帧，这样在相同码率下，能够提供更好的画质。

对压缩算法的说明

h264的压缩方法:

  1. 分组:把几帧图像分为一组(GOP，也就是一个序列),为防止运动变化,帧数不宜取多。
  2. 定义帧:将每组内各帧图像定义为三种类型,即I帧、B帧和P帧;
  3. 预测帧:以I帧作为基础帧,以I帧预测P帧,再由I帧和P帧预测B帧;
  4. 数据传输:最后将I帧数据与预测的差值信息进行存储和传输。

帧内（Intraframe）压缩也称为空间压缩（Spatial compression）。当压缩一帧图像时，仅考虑本帧的数据而不考虑相邻帧之间的冗余信息，这实际上与静态图像压缩相似。帧内通常采用有损压缩算法，因为帧内压缩是编码一个完整的图像，因此能够独立的解码、显示。帧内压缩通常达不到很高的压缩，跟编码jpeg差很少。

帧间（Interframe）压缩的原理是：相邻几帧的数据有很大的相关性，或者说先后两帧信息变化很小的特色。也即连续的视频其相邻帧之间具备冗余信息,根据这一特性，压缩相邻帧之间的冗余量就能够进一步提升压缩量，减少压缩比。帧间压缩也称为时间压缩（Temporal compression），它经过比较时间轴上不一样帧之间的数据进行压缩。帧间压缩通常是无损的。帧差值（Frame differencing）算法是一种典型的时间压缩法，它经过比较本帧与相邻帧之间的差别，仅记录本帧与其相邻帧的差值，这样能够大大减小数据量。

顺便说下有损（Lossy ）压缩和无损（Lossy less）压缩。无损压缩也即压缩前和解压缩后的数据彻底一致。多数的无损压缩都采用RLE行程编码算法。有损压缩意味着解压缩后的数据与压缩前的数据不一致。在压缩的过程当中要丢失一些人眼和人耳所不敏感的图像或音频信息,并且丢失的信息不可恢复。几乎全部高压缩的算法都采用有损压缩,这样才能达到低数据率的目标。丢失的数据率与压缩比有关,压缩比越小，丢失的数据越多,解压缩后的效果通常越差。此外,某些有损压缩算法采用屡次重复压缩的方式,这样还会引发额外的数据丢失。

三种帧的不一样

  • I frame:自身能够经过视频解压算法解压成一张单独的完整的图片。
  • P frame：须要参考其前面的一个I frame 或者B frame来生成一张完整的图片。
  • B frame:则要参考其前一个I或者P帧及其后面的一个P帧来生成一张完整的图片。
  • 两个I frame之间造成一个GOP，在x264中同时能够经过参数来设定bf的大小，即：I 和p或者两个P之间B的数量。
  • 经过上述基本能够说明若是有B frame 存在的状况下一个GOP的最后一个frame必定是P.

DTS和PTS的不一样

DTS主要用于视频的解码,在解码阶段使用.PTS主要用于视频的同步和输出.在display的时候使用.在没有B frame的状况下.DTS和PTS的输出顺序是同样的。

例子:

下面给出一个GOP为15的例子,其解码的参照frame及其解码的顺序都在里面:

CVPixelBuffer

如上图：I frame 的解码不依赖于任何的其它的帧.而p frame的解码则依赖于其前面的I frame或者P frame.B frame的解码则依赖于其前的最近的一个I frame或者P frame 及其后的最近的一个P frame.

IOS系统 H264视频硬件编解码说明

咱们知道，在IOS8系统之后，苹果将Mac OS中用于硬件编解码 VideoToolbox 框架引入IOS系统。

按照苹果WWDC2014 513《direct access to media encoding and decoding》的描述，苹果以前提供的AVFoundation框架也使用硬件对视频进行硬编码和解码，可是编码后直接写入文件，解码后直接显示。Video Toolbox框架能够获得编码后的帧结构，也能够获得解码后的原始图像，所以具备更大的灵活性作一些视频图像处理。

对VideoToolbox的介绍

在iOS中，与视频相关的接口有5个，从顶层开始分别是 AVKit - AVFoundation - VideoToolbox - Core Media - Core Video

其中VideoToolbox能够将视频解压到CVPixelBuffer,也能够压缩到CMSampleBuffer。

若是须要使用硬编码的话，在5个接口中，就须要用到AVKit，AVFoundation和VideoToolbox。在这里我就只介绍VideoToolbox。

VideoToolbox中的对象

  • CVPixelBuffer : 编码前和解码后的图像数据结构（未压缩光栅图像缓存区-Uncompressed Raster Image Buffer）

    CVPixelBuffer

  • CVPixelBufferPool : 顾名思义，存放CVPixelBuffer

    CVPixelBufferPool

  • pixelBufferAttributes : CFDictionary对象，可能包含了视频的宽高，像素格式类型（32RGBA, YCbCr420），是否能够用于OpenGL ES等相关信息

  • CMTime : 时间戳相关。时间以 64-big/32-bit形式出现。 分子是64-bit的时间值，分母是32-bit的时标(time scale)

  • CMClock : 时间戳相关。时间以 64-big/32-bit形式出现。 分子是64-bit的时间值，分母是32-bit的时标(time scale)。它封装了时间源，其中CMClockGetHostTimeClock()封装了mach_absolute_time()

  • CMTimebase : 时间戳相关。时间以 64-big/32-bit形式出现。CMClock上的控制视图。提供了时间的映射:CMTimebaseSetTime(timebase, kCMTimeZero); 速率控制: CMTimebaseSetRate(timebase, 1.0);

    CMTimebase

  • CMBlockBuffer : 编码后，结果图像的数据结构

  • CMVideoFormatDescription : 图像存储方式，编解码器等格式描述

  • CMSampleBuffer : 存放编解码先后的视频图像的容器数据结构

    视频H264编解码先后数据结构示意图

    如图所示，编解码先后的视频图像均封装在CMSampleBuffer中，若是是编码后的图像，以CMBlockBuffe方式存储；解码后的图像，以CVPixelBuffer存储。CMSampleBuffer里面还有另外的时间信息CMTime和视频描述信息CMVideoFormatDesc。

硬解码

经过如图所示的一个典型应用，来讲明如何使用硬件解码接口。该应用场景是从网络处传来H264编码后的视频码流，最后显示在手机屏幕上。

要完成以上功能须要通过如下几个步骤：

  1. 将 H.264码流转换为 CMSampleBuffer
  2. 将 CMSampleBuffer显示出来
将H.264码流转化成CMSampleBuffer

咱们知道，CMSampleBuffer = CMTime + FormatDesc + CMBlockBuffer . 须要从H264的码流里面提取出以上的三个信息。最后组合成CMSampleBuffer，提供给硬解码接口来进行解码工做。

在H.264的语法中，有一个最基础的层，叫作Network Abstraction Layer, 简称为NAL。H.264流数据正是由一系列的NAL单元(NAL Unit, 简称NAUL)组成的。

NAULs

H264的码流由NALU单元组成,一个NALU可能包含有：

  • 视频帧

    视频帧也就是视频片断，具体有 P帧, I帧，B帧

    NAULs

  • H.264属性合集-FormatDesc(包含 SPS和PPS)

    流数据中，属性集合多是这样的：

    NAULs

    通过处理以后，在Format Description中则是:

    NAULs

    要从基础的流数据将SPS和PPS转化为Format Desc中的话，须要调用CMVideoFormatDescriptionCreateFromH264ParameterSets()方法

NALU header

对于流数据来讲，一个NAUL的Header中，多是0x00 00 01或者是0x00 00 00 01做为开头(二者都有可能，下面以0x00 00 01做为例子)。0x00 00 01所以被称为开始码(Start code).

Start Code

总结以上知识，咱们知道H264的码流由NALU单元组成，NALU单元包含视频图像数据和H264的参数信息。其中视频图像数据就是CMBlockBuffer，而H264的参数信息则能够组合成FormatDesc。具体来讲参数信息包含SPS（Sequence Parameter Set）和PPS（Picture Parameter Set）.以下图显示了一个H.264码流结构：

H.264码流结构

1） 提取sps和pps生成FormatDesc

  • 每一个NALU的开始码是0x00 00 01，按照开始码定位NALU
  • 经过类型信息找到sps和pps并提取，开始码后第一个byte的后5位，7表明sps，8表明pps
  • 使用CMVideoFormatDescriptionCreateFromH264ParameterSets函数来构建CMVideoFormatDescriptionRef

2）提取视频图像数据生成CMBlockBuffer

  • 经过开始码，定位到NALU
  • 肯定类型为数据后，将开始码替换成NALU的长度信息（4 Bytes）
  • 使用CMBlockBufferCreateWithMemoryBlock接口构造CMBlockBufferRef

3）根据须要，生成CMTime信息。（实际测试时，加入time信息后，有不稳定的图像，不加入time信息反而没有，须要进一步研究，这里建议不加入time信息）

根据上述获得CMVideoFormatDescriptionRef、CMBlockBufferRef和可选的时间信息，使用CMSampleBufferCreate接口获得CMSampleBuffer数据这个待解码的原始的数据。以下图所示的H264数据转换示意图。

H264码流转换CMSampleBuffer示意图

将CMSampleBuffer显示出来

显示的方式有两种：

  • 将CMSampleBuffers提供给系统的AVSampleBufferDisplayLayer 直接显示
  • 利用OPenGL本身渲染

1）经过系统提供的AVSampleBufferDisplayLayer来解码并显示

使用方式和其它CALayer相似。该层内置了硬件解码功能，将原始的CMSampleBuffer解码后的图像直接显示在屏幕上面，很是的简单方便。

2）利用OPenGL本身渲染

经过VTDecompression接口来，将CMSampleBuffer解码成图像，将图像经过UIImageView或者OpenGL上显示。

  • 初始化VTDecompressionSession，设置解码器的相关信息。初始化信息须要CMSampleBuffer里面的FormatDescription，以及设置解码后图像的存储方式。demo里面设置的CGBitmap模式，使用RGB方式存放。编码后的图像通过解码后，会调用一个回调函数，将解码后的图像交个这个回调函数来进一步处理。咱们就在这个回调里面，将解码后的图像发给control来显示，初始化的时候要将回调指针做为参数传给create接口函数。最后使用create接口对session来进行初始化。
  • a中所述的回调函数能够完成CGBitmap图像转换成UIImage图像的处理，将图像经过队列发送到Control来进行显示处理。
  • 调用VTDecompresSessionDecodeFrame接口进行解码操做。解码后的图像会交由以上两步骤设置的回调函数，来进一步的处理。

硬编码

硬编码的使用也经过一个典型的应用场景来描述。首先，经过摄像头来采集图像，而后将采集到的图像，经过硬编码的方式进行编码，最后编码后的数据将其组合成H264的码流经过网络传播。

下面是对具体步骤的说明：

  1. 摄像头采集数据

    摄像头采集，iOS系统提供了AVCaptureSession来采集摄像头的图像数据。设定好session的采集解析度。再设定好input和output便可。output设定的时候，须要设置delegate和输出队列。在delegate方法，处理采集好的图像。

    图像输出的格式，是未编码的CMSampleBuffer形式。

  2. 使用VTCompressionSession进行硬编码

    1）初始化VTCompressionSession

    VTCompressionSession初始化的时候，通常须要给出width宽，height长，编码器类型kCMVideoCodecType_H264等。而后经过调用VTSessionSetProperty接口设置帧率等属性，demo里面提供了一些设置参考，测试的时候发现几乎没有什么影响，可能须要进一步调试。最后须要设定一个回调函数，这个回调是视频图像编码成功后调用。所有准备好后，使用VTCompressionSessionCreate建立session

    2）提取摄像头采集的原始图像数据给VTCompressionSession来硬编码

    摄像头采集后的图像是未编码的CMSampleBuffer形式，利用给定的接口函数CMSampleBufferGetImageBuffer从中提取出CVPixelBufferRef，使用硬编码接口VTCompressionSessionEncodeFrame来对该帧进行硬编码，编码成功后，会自动调用session初始化时设置的回调函数。

    3）利用回调函数，将因编码成功的CMSampleBuffer转换成H264码流，经过网络传播

    基本上是硬解码的一个逆过程。解析出参数集SPS和PPS，加上开始码后组装成NALU。提取出视频数据，将长度码转换成开始码，组长成NALU。将NALU发送出去。

下篇文章咱们将介绍H264硬编码和软编码的实现。

参考

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程