ios视频开发解码,ios开发音视频编解码

提示：扫一扫查出行
【扫一扫了解最新限行尾号】
复制提示

ios 系统中，h.264 视频流可以硬件解码吗

可以的，硬解主要是看硬件（cpu）和系统两个方面：

1.iphone4以后的应该可以硬解h.264了。如果是手机里面的视频，你要下载专门的视频播放器，播放器里面有硬解播放选项。

2.其实至少从iPhone4开始，苹果就是支持硬件解码了，但是硬解码API一直是私有API，不开放给开发者使用，只有越狱才能使用，正常的App如果想提交到AppStore是不允许使用私有API的。从iOS8开始，可能是苹果想通了，开放了硬解码和硬编码API，就是名为 VideoToolbox.framework的API，需要用iOS 8以后才能使用，iOS 7.x上还不行。

相关问答

Q1: iOS 关于H265/HEVC解码的

Apple 对 HEVC 标准的态度就像过山车。Apple 曾非常活跃地参与 HEVC 的开发。这一标准最终在 2013 年 1 月完成，Apple 也在 2014 年 11 月宣布支持 HEVC 标准。但是几个月后 Apple 又基于一项 Apple 不能接受的版税条款撤回了这一决定。

时间快进到 2017 年 6 月 5 日，Apple 在 WWDC 大会上宣布：

将在 iOS11 支持 HEVC，首个支持 HEVC 的应用是自带的相机 app。

Mac OS High Sierra 将支持 HEVC

Apple TV 将支持 Amazon。我们可以假定这意味着对超高清的支持，暗示了将支持 HEVC。

WWDC 2017上，Apple已经宣布全面支持HEVC。在iOS11中释出了HEVC的硬件编解码接口，具体看图：

对应到移动端，iPhone 7、iPhone 7 Plus 支持8bpp硬编；iPhone 6s、iPhone 6s Plus及以上支持硬解；iPhone 5s及以上支持软解。

关于HEVC硬解的实现：已经在iOS11 beta3上完成了265的硬解，直接参照264的就可以，主要关注下HEVC格式的语法转换。另外性能也需要持续关注，目前测试硬解水平还比较瓶颈。

实际操作中，查阅了一些资料，显示iOS端的硬件解码、编码，软件解码还是有限制的。我本人在集成一些视频框架的时候，由于客户提供部分视频的是h265/HEVC的编码，导致部分视频在播放时有声音没画面。但是在iPhone 7 iOS11.2系统上一切播放正常。在iPhone 4s\5s\6sp等设备上无画面有声音，系统是10.3.3(包括10.3.3)以下。安卓播放正常。

苹果在h265/HEVC视频编码解码上是稍微有些迟疑和落后的。

推荐读者看看这篇文章：《基于iOS11的HEVC(H.265)硬编码/硬解码功能开发指南》

Q2: 视频的编解码-编码篇

四、视频的编解码-编码篇

时间 2016-08-05 10:22:59 Twenty's 时间念

原文

主题 iOS开发 MacOS

在此之前我们通常使用的FFmpeg多媒体库,利用CPU来进行视频的编解码,占用CPU资源,效率低下,俗称软编解码.而苹果在2014年的iOS8中,开放了VideoToolbox.framwork框架,此框架使用GPU或专用的处理器来进行编解码,俗称硬编解码.而此框架在此之前只有MAC OS系统中可以使用,在iOS作为私有框架.终于苹果在iOS8.0中得到开放引入.

2014年的WWDC Direct Access to Video Encoding and Decoding 中,苹果介绍了使用videoToolbox硬编解码.

使用硬编解码有几个优点: * 提高性能; * 增加效率; * 延长电量的使用

对于编解码,AVFoundation框架只有以下几个功能: 1. 直接解压后显示;

2. 直接压缩到一个文件当中;

而对于Video Toolbox,我们可以通过以下功能获取到数据,进行网络流传输等多种保存： 1. 解压为图像的数据结构;

2. 压缩为视频图像的容器数据结构.

一、videoToolbox的基本数据

Video Toolbox视频编解码前后需要应用的数据结构进行说明。

CVPixelBuffer：编码前和解码后的图像数据结构。此内容包含一系列的CVPixelBufferPool内容

CMTime、CMClock和CMTimebase：时间戳相关。时间以64-bit/32-bit的形式出现。

pixelBufferAttributes:字典设置.可能包括Width/height、pixel format type、• Compatibility (e.g., OpenGL ES, Core Animation)

CMBlockBuffer：编码后，结果图像的数据结构。

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

(CMSampleBuffer：存放编解码前后的视频图像的容器数据结构。

CMClock

CMTimebase: 关于CMClock的一个控制视图,包含CMClock、时间映射(Time mapping)、速率控制(Rate control)

由二、采集视频数据可知,我们获取到的数据(CMSampleBufferRef)sampleBuffer为未编码的数据;

图1.1

上图中,编码前后的视频图像都封装在CMSampleBuffer中,编码前以CVPixelBuffer进行存储;编码后以CMBlockBuffer进行存储。除此之外两者都包括CMTime、CMVideoFormatDesc.

二、视频数据流编码并上传到服务器

1.将CVPixelBuffer使用VTCompressionSession进行数据流的硬编码。

(1)初始化VTCompressionSession

VT_EXPORT OSStatus VTCompressionSessionCreate( CM_NULLABLE CFAllocatorRef allocator, int32_t width, int32_t height, CMVideoCodecType codecType, CM_NULLABLE CFDictionaryRef encoderSpecification, CM_NULLABLE CFDictionaryRef sourceImageBufferAttributes, CM_NULLABLE CFAllocatorRef compressedDataAllocator, CM_NULLABLE VTCompressionOutputCallback outputCallback, void * CM_NULLABLE outputCallbackRefCon, CM_RETURNS_RETAINED_PARAMETER CM_NULLABLE VTCompressionSessionRef * CM_NONNULL compressionSessionOut) __OSX_AVAILABLE_STARTING(__MAC_10_8, __IPHONE_8_0);

VTCompressionSession的初始化参数说明:

allocator:分配器,设置NULL为默认分配

width: 宽

height: 高

codecType: 编码类型,如kCMVideoCodecType_H264

encoderSpecification: 编码规范。设置NULL由videoToolbox自己选择

sourceImageBufferAttributes: 源像素缓冲区属性.设置NULL不让videToolbox创建,而自己创建

compressedDataAllocator: 压缩数据分配器.设置NULL,默认的分配

outputCallback: 当VTCompressionSessionEncodeFrame被调用压缩一次后会被异步调用.注:当你设置NULL的时候,你需要调用VTCompressionSessionEncodeFrameWithOutputHandler方法进行压缩帧处理,支持iOS9.0以上

outputCallbackRefCon: 回调客户定义的参考值.

compressionSessionOut: 压缩会话变量。

(2)配置VTCompressionSession

使用VTSessionSetProperty()调用进行配置compression。 * kVTCompressionPropertyKey AllowFrameReordering: 允许帧重新排序.默认为true * kVTCompressionPropertyKey AverageBitRate: 设置需要的平均编码率 * kVTCompressionPropertyKey H264EntropyMode：H264的熵编码模式。有两种模式:一种基于上下文的二进制算数编码CABAC和可变长编码VLC.在slice层之上（picture和sequence）使用定长或变长的二进制编码，slice层及其以下使用VLC或CABAC. 详情请参考 * kVTCompressionPropertyKey RealTime: 视频编码压缩是否是实时压缩。可设置CFBoolean或NULL.默认为NULL * kVTCompressionPropertyKey ProfileLevel: 对于编码流指定配置和标准 .比如kVTProfileLevel H264 Main AutoLevel

配置过VTCompressionSession后,可以可选的调用VTCompressionSessionPrepareToEncodeFrames进行准备工作编码帧。

(3)开始硬编码流入的数据

使用VTCompressionSessionEncodeFrame方法进行编码.当编码结束后调用outputCallback回调函数。

VT_EXPORT OSStatus VTCompressionSessionEncodeFrame( CM_NONNULL VTCompressionSessionRef session, CM_NONNULL CVImageBufferRef imageBuffer, CMTime presentationTimeStamp, CMTime duration,// may be kCMTimeInvalidCM_NULLABLE CFDictionaryRef frameProperties,void* CM_NULLABLE sourceFrameRefCon, VTEncodeInfoFlags * CM_NULLABLE infoFlagsOut ) __OSX_AVAILABLE_STARTING(__MAC_10_8, __IPHONE_8_0);

presentationTimeStamp：获取到的这个sample buffer数据的展示时间戳。每一个传给这个session的时间戳都要大于前一个展示时间戳.

duration: 对于获取到sample buffer数据,这个帧的展示时间.如果没有时间信息,可设置kCMTimeInvalid.

frameProperties: 包含这个帧的属性.帧的改变会影响后边的编码帧.

sourceFrameRefCon: 回调函数会引用你设置的这个帧的参考值.

infoFlagsOut: 指向一个VTEncodeInfoFlags来接受一个编码操作.如果使用异步运行,kVTEncodeInfo_Asynchronous被设置；同步运行,kVTEncodeInfo_FrameDropped被设置；设置NULL为不想接受这个信息.

(4)执行VTCompressionOutputCallback回调函数

typedefvoid(*VTCompressionOutputCallback)(void* CM_NULLABLE outputCallbackRefCon,void* CM_NULLABLE sourceFrameRefCon, OSStatus status, VTEncodeInfoFlags infoFlags, CM_NULLABLE CMSampleBufferRef sampleBuffer );

outputCallbackRefCon: 回调函数的参考值

sourceFrameRefCon: VTCompressionSessionEncodeFrame函数中设置的帧的参考值

status: 压缩的成功为noErr,如失败有错误码

infoFlags: 包含编码操作的信息标识

sampleBuffer: 如果压缩成功或者帧不丢失,则包含这个已压缩的数据CMSampleBuffer,否则为NULL

(5)将压缩成功的sampleBuffer数据进行处理为基本流NSData上传到服务器

MPEG-4是一套用于音频、视频信息的压缩编码标准.

由图1.1 可知,已压缩 $$CMSampleBuffer = CMTime(可选) + CMBlockBuffer + CMVideoFormatDesc$$。

5.1 先判断压缩的数据是否正确

//不存在则代表压缩不成功或帧丢失if(!sampleBuffer)return;if(status != noErr)return;//返回sampleBuffer中包括可变字典的不可变数组,如果有错误则为NULLCFArrayRefarray= CMSampleBufferGetSampleAttachmentsArray(sampleBuffer,true);if(!array)return; CFDictionaryRef dic = CFArrayGetValueAtIndex(array,0);if(!dic)return;//issue 3:kCMSampleAttachmentKey_NotSync:没有这个键意味着同步, yes: 异步. no:同步BOOL keyframe = !CFDictionaryContainsKey(dic, kCMSampleAttachmentKey_NotSync);//此代表为同步

而对于 issue 3 从字面意思理解即为以上的说明,但是网上看到很多都是做为查询是否是视频关键帧,而查询文档看到有此关键帧key值kCMSampleBufferAttachmentKey_ForceKeyFrame存在,因此对此值如若有了解情况者敬请告知详情.

5.2 获取CMVideoFormatDesc数据由三、解码篇可知CMVideoFormatDesc 包括编码所用的profile，level，图像的宽和高，deblock滤波器等.具体包含第一个NALU的SPS （Sequence Parameter Set）和第二个NALU的PPS （Picture Parameter Set）.

//if (keyframe !encoder - sps) { //获取sample buffer 中的 CMVideoFormatDesc CMFormatDescriptionRef format = CMSampleBufferGetFormatDescription(sampleBuffer); //获取H264参数集合中的SPS和PPS const uint8_t * sparameterSet;size_t sparameterSetSize,sparameterSetCount ; OSStatus statusCode = CMVideoFormatDescriptionGetH264ParameterSetAtIndex(format, 0, sparameterSet, sparameterSetSize, sparameterSetCount,0);if (statusCode == noErr) { size_t pparameterSetSize, pparameterSetCount; const uint8_t *pparameterSet;OSStatus statusCode = CMVideoFormatDescriptionGetH264ParameterSetAtIndex(format, 1, pparameterSet, pparameterSetSize, pparameterSetCount,0);if (statusCode == noErr) { encoder-sps = [NSData dataWithBytes:sparameterSetlength:sparameterSetSize];encoder-pps = [NSData dataWithBytes:pparameterSetlength:pparameterSetSize];} }}

5.3 获取CMBlockBuffer并转换成数据

CMBlockBufferRef blockBuffer = CMSampleBufferGetDataBuffer(sampleBuffer); size_t lengthAtOffset,totalLength;char*dataPointer;//接收到的数据展示OSStatus blockBufferStatus = CMBlockBufferGetDataPointer(blockBuffer,0, lengthAtOffset, totalLength, dataPointer);if(blockBufferStatus != kCMBlockBufferNoErr) { size_t bufferOffset =0;staticconstintAVCCHeaderLength =4;while(bufferOffset totalLength - AVCCHeaderLength) {// Read the NAL unit lengthuint32_t NALUnitLength =0;/**

* void *memcpy(void *dest, const void *src, size_t n);

* 从源src所指的内存地址的起始位置开始拷贝n个字节到目标dest所指的内存地址的起始位置中

*/memcpy(NALUnitLength, dataPointer + bufferOffset, AVCCHeaderLength);//字节从高位反转到低位NALUnitLength = CFSwapInt32BigToHost(NALUnitLength); RTAVVideoFrame * frame = [RTAVVideoFramenew]; frame.sps = encoder - sps; frame.pps = encoder - pps; frame.data = [NSData dataWithBytes:(dataPointer+bufferOffset+AVCCHeaderLength) length:NALUnitLength]; bufferOffset += NALUnitLength + AVCCHeaderLength; } }

此得到的H264数据应用于后面的RTMP协议做推流准备。

Q3: iOS硬编解码相关知识

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

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

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

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

需要注意的是：

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

一个序列就是一段内容差异不太大的图像编码后生成的一串数据流。当运动变化比较少时，一个序列可以很长，因为运动变化少就代表图像画面的内容变动很小，所以就可以编一个I帧，然后一直P帧、B帧了。当运动变化多时，可能一个序列就比较短了，比如就包含一个I帧和3、4个P帧。

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

说明：

I帧：红色；P帧：蓝色；B帧：绿色。

1、分组:把几帧图像分为一组(GOP，也就是一个序列),为防止运动变化,帧数不宜取多。

2、定义帧:将每组内各帧图像定义为三种类型,即I帧、B帧和P帧;

3、预测帧:以I帧做为基础帧,以I帧预测P帧,再由I帧和P帧预测B帧;

4、数据传输:最后将I帧数据与预测的差值信息进行存储和传输。

5、帧内（Intraframe）压缩也称为空间压缩（Spatial compression）。

当压缩一帧图像时，仅考虑本帧的数据而不考虑相邻帧之间的冗余信息，这实际上与静态图像压缩类似。帧内一般采用有损压缩算法，由于帧内压缩是编码一个完整的图像，所以可以独立的解码、显示。帧内压缩一般达不到很高的压缩，跟编码jpeg差不多。

6、帧间（Interframe）压缩。

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

7、有损（Lossy）压缩和无损（Lossy less）压缩。

无损压缩也即压缩前和解压缩后的数据完全一致。多数的无损压缩都采用RLE行程编码算法。

有损压缩意味着解压缩后的数据与压缩前的数据不一致。在压缩的过程中要丢失一些人眼和人耳所不敏感的图像或音频信息,而且丢失的信息不可恢复。几乎所有高压缩的算法都采用有损压缩,这样才能达到低数据率的目标。丢失的数据率与压缩比有关,压缩比越小，丢失的数据越多,解压缩后的效果一般越差。此外,某些有损压缩算法采用多次重复压缩的方式,这样还会引起额外的数据丢失。

DTS主要用于视频的解码,在解码阶段使用.

PTS主要用于视频的同步和输出.

在display的时候使用.在没有B frame的情况下.DTS和PTS的输出顺序是一样的。

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

如上图：

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

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

其中VideoToolbox可以将视频解压到 CVPixelBuffer ,也可以压缩到 CMSampleBuffer 。

但是我们常用的是 CMSampleBuffer .

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

存放CVPixelBuffer

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

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

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

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

CMTimebaseSetRate(timebase, 1.0);

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

编解码前后的视频图像均封装在CMSampleBuffer中，如果是编码后的图像，以CMBlockBuffe方式存储；解码后的图像，以CVPixelBuffer存储。

存放编解码前后的视频图像的容器数据结构。如图所示，编解码前后的视频图像均封装在CMSampleBuffer中，如果是编码后的图像，以CMBlockBuffer方式存储；解码后的图像，以CVPixelBuffer存储。CMSampleBuffer里面还有另外的时间信息CMTime和视频描述信息CMVideoFormatDesc。

实现步骤如下：

需要从H.264的码流里面提取出以上的三个信息。最后组合成CMSampleBuffer，提供给硬解码接口来进行解码工作。

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

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

2)H.264属性合集-FormatDesc(包含 SPS和PPS),即流数据中，属性集合可能是这样的：

经过处理之后，在Format Description中则是：

需要注意的是：

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

3)NALU header

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

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

（实际测试时，加入time信息后，有不稳定的图像，不加入time信息反而没有，需要进一步研究，这里建议不加入time信息）

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

显示的方式有两种：

1）、将CMSampleBuffers提供给系统的AVSampleBufferDisplayLayer 直接显示

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

2）、利用OPenGL渲染

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

初始化VTDecompressionSession，设置解码器的相关信息。初始化信息需要CMSampleBuffer里面的FormatDescription，以及设置解码后图像的存储方式。demo里面设置的CGBitmap模式，使用RGB方式存放。编码后的图像经过解码后，会调用一个回调函数，将解码后的图像交个这个回调函数来进一步处理。我们就在这个回调里面，将解码后的图像发给control来显示，初始化的时候要将回调指针作为参数传给create接口函数。最后使用create接口对session来进行初始化。

上所述的回调函数可以完成CGBitmap图像转换成UIImage图像的处理，将图像通过队列发送到Control来进行显示处理。

调用VTDecompresSessionDecodeFrame接口进行解码操作。解码后的图像会交由以上两步骤设置的回调函数，来进一步的处理。

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

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

1）初始化VTCompressionSession

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

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

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

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