這里我們分為三步走
創(chuàng)新互聯(lián)公司是專業(yè)的寒亭網(wǎng)站建設(shè)公司，寒亭接單;提供成都做網(wǎng)站、成都網(wǎng)站設(shè)計(jì),網(wǎng)頁設(shè)計(jì),網(wǎng)站設(shè)計(jì),建網(wǎng)站,PHP網(wǎng)站建設(shè)等專業(yè)做網(wǎng)站服務(wù);采用PHP框架,可快速的進(jìn)行寒亭網(wǎng)站開發(fā)網(wǎng)頁制作和功能擴(kuò)展;專業(yè)做搜索引擎喜愛的網(wǎng)站,專業(yè)的做網(wǎng)站團(tuán)隊(duì),希望更多企業(yè)前來合作!
我這邊采用的是 iOS利用VideoToolbox實(shí)現(xiàn)視頻硬解碼 中的方式，demo中提供了兩種解碼方式，一種是第三方庫ffmpeg，另外一種是系統(tǒng)的videotoolbox庫，效率基本上都差不多，作者封裝后都會(huì)有一個(gè)代理回調(diào)，
兩種回調(diào)都會(huì)有一個(gè)CMSampleBufferRef的對(duì)象，它是像素緩沖，其實(shí)就是我們解碼后的每一幀的圖片。
在第一步中我們已經(jīng)拿到了每一幀的圖片，現(xiàn)在我們?cè)谄浠A(chǔ)上合成本地圖片，合成圖片我首先想到的是下面的方法，
這個(gè)方法是通過兩個(gè)image的對(duì)象，最終合成一個(gè)新的image，效果可以實(shí)現(xiàn)，但是在我們這個(gè)場(chǎng)景中，我們?cè)趯?duì)視頻解碼時(shí)，是一個(gè)連續(xù)異步的操作，代理會(huì)不斷的回調(diào)，此時(shí)如果采用這個(gè)方式，會(huì)多次創(chuàng)建局部對(duì)象， 不能及時(shí)釋放，導(dǎo)致內(nèi)存爆增 ，引起閃退。所以我采用以下方式
這里我用的是CIImage，它提供了一個(gè)系統(tǒng)的api
公司的項(xiàng)目里有拉取H.264視頻流進(jìn)行解碼播放的功能，本來是采用FFMpeg多媒體庫，用CPU做視頻的編碼和解碼，就是大家常說的軟編軟解。但是軟解存在太占用CPU,解碼效率低等缺點(diǎn)，所以我們一合計(jì)干脆用硬解碼代替原來的方案。當(dāng)然硬件解碼使用的當(dāng)然就是蘋果大名鼎鼎的 Video ToolBox 框架，眾所周知，蘋果在iOS8開始才可以在iOS系統(tǒng)中調(diào)用該框架中的 API 。
圖2.1展示的是通過 AVSampleBufferDisplaylayer 播放網(wǎng)絡(luò)上獲取的H.264碼流。
但并不是說 AVSampleBufferDisplaylayer 能直接播放H.264碼流，需要將H.264碼流包裝成 SampleBuffer 傳給給 AVSampleBufferDisplaylayer 解碼播放。
再來看一下H.264碼流的構(gòu)成，H.264碼流由一系列的 NAL 單元組成。
NAL 單元一般包含：
所以如果要將H.264解碼播放就需要將H.264碼流包裝成CMSampleBuffer。由圖1.1可得 CMSampleBuffer = CMTime + CMVideoFormatDesc + CMBlockBuffer 。
解碼步驟：
1.從網(wǎng)絡(luò)獲取的碼流中獲取SPS和PPS生成CMVideoFormatDesc。
（1）H.264 NALU 單元的 Start Code 是"0x 00 00 01" 或"0x 00 01"，按照 Start Code 定位NALU。
（2）通過類型信息找到 SPS 和 PPS 并提取，開始碼后第一個(gè) byte 的第5位，7代表 SPS ，8代表 PPS 。
（3)使用CMVideoFormatDescriptionCreateFromH264ParameterSets函數(shù)來構(gòu)建CMVideoFormatDescription。
2.提取視頻圖像數(shù)據(jù)生成CMBlockBuffer。
(1)按照 Start Code 定位NALU。
(2)CMBlockBuffer數(shù)據(jù)需要的頭部碼為4個(gè)字節(jié)的長(zhǎng)度，為：0x 00 80 00,所以需要將H.264的header給替換掉。
(3) CMBlockBufferCreateWithMemoryBlock 接口構(gòu)造 CMBlockBufferRef 。
3.根據(jù)自己的需要設(shè)置CMTime
我的項(xiàng)目中的拉取的實(shí)時(shí)流需要實(shí)時(shí)播放，不需要設(shè)置時(shí)間間隔，所以不用設(shè)置CMTime。
4.根據(jù)上述得到 CMVideoFormatDescriptionRef 、 CMBlockBufferRef 和可選的時(shí)間信息，使用 CMSampleBufferCreate 接口得到 CMSampleBuffer 數(shù)據(jù)這個(gè)待解碼的原始的數(shù)據(jù)。
5.用 AVSampleBufferDisplayLayer 處理得到 sampleBuffer 來顯示圖像。
至此成功用 Video Toolbox 硬件解碼H.264碼流，并在設(shè)備上播放視頻。
可是，如果我們要拿到每一幀圖像進(jìn)行處理呢，那該怎么得到？
那么我們還需要用 VTDecompressionSession 解碼成 CVPixelBuffer ,通過 UIImageView 或者 OpenGL ES 上顯示。
(1)創(chuàng)建 VTDecompressionSession ，需要以下參數(shù)：
(2)調(diào)用 VTDecompresSessionDecodeFrame 接口進(jìn)行解碼。
(3)VTDecompressionSessionOutputCallback回調(diào)函數(shù)中可以得到解碼后的結(jié)果 CVPixelBuffer ，可以將 CVPixelBuffer 轉(zhuǎn)換成UIImage圖像顯示在ImageView上或者用 OpenGL ES 渲染圖像。
首先告訴你擺渡知道沒這方面的大神高手。懂的人也不會(huì)來這里混。。。你看到的回答大多數(shù)都是搬磚搬過來的，鐵耙也是，懂的人不會(huì)去那里混的。你應(yīng)該去多點(diǎn)論壇，什么CSDN，Cocoachina這一類。
然后，視頻處理解碼需要用到第三方庫，用蘋果默認(rèn)的是不支持的。然后截取部分視頻這個(gè)要用到一個(gè)代理方法。至于什么我忘記了，
iOS音視頻開發(fā)涉及的方面比較廣泛，一般分為采集、音視頻的封裝、編碼、推流、拉流、解封裝、解碼、播放等階段。其中音視頻的編碼和解碼階段是非常重要的步驟。其中編碼分為硬編碼和軟編碼，對(duì)應(yīng)解碼分為硬解碼和軟解碼。
硬編碼是指使用非CPU進(jìn)行編碼，如顯卡GPU、專用的DSP、FPGA、ASIC芯片等。
硬編碼一般性能高，對(duì)CPU沒有壓力，但是對(duì)其他硬件要求較高（如GPU等）。
軟編碼是指使用CPU進(jìn)行編碼，軟編碼通常使用：ffmpeg+x264。
軟編碼實(shí)現(xiàn)直接、簡(jiǎn)單，參數(shù)調(diào)整方便，升級(jí)易，但CPU負(fù)載重，性能較硬編碼低。
常見的直播服務(wù)普遍采用了RTMP作為流媒體協(xié)議，F(xiàn)LV作為封裝格式，H.264作為視頻編碼格式，AAC作為音頻編碼格式。
iOS中編碼方式：
在iOS8之前，蘋果并沒有開放硬編碼的接口，所以只能采用ffmpeg+x624進(jìn)行軟編碼
在iOS8之后，蘋果開放了接口，并且封裝了VideoToolBoxAudioToolbox兩個(gè)框架，分別用于對(duì)視頻音頻進(jìn)行硬編碼
四、視頻的編解碼-編碼篇
時(shí)間?2016-08-05 10:22:59 Twenty's 時(shí)間念
原文
主題 iOS開發(fā) MacOS
在此之前我們通常使用的FFmpeg多媒體庫,利用CPU來進(jìn)行視頻的編解碼,占用CPU資源,效率低下,俗稱軟編解碼.而蘋果在2014年的iOS8中,開放了VideoToolbox.framwork框架,此框架使用GPU或?qū)Ｓ玫奶幚砥鱽磉M(jìn)行編解碼,俗稱硬編解碼.而此框架在此之前只有MAC OS系統(tǒng)中可以使用,在iOS作為私有框架.終于蘋果在iOS8.0中得到開放引入.
2014年的WWDC Direct Access to Video Encoding and Decoding 中,蘋果介紹了使用videoToolbox硬編解碼.
使用硬編解碼有幾個(gè)優(yōu)點(diǎn): * 提高性能; * 增加效率; * 延長(zhǎng)電量的使用
對(duì)于編解碼,AVFoundation框架只有以下幾個(gè)功能: 1. 直接解壓后顯示;
2. 直接壓縮到一個(gè)文件當(dāng)中;
而對(duì)于Video Toolbox,我們可以通過以下功能獲取到數(shù)據(jù),進(jìn)行網(wǎng)絡(luò)流傳輸?shù)榷喾N保存： 1. 解壓為圖像的數(shù)據(jù)結(jié)構(gòu);
2. 壓縮為視頻圖像的容器數(shù)據(jù)結(jié)構(gòu).
一、videoToolbox的基本數(shù)據(jù)
Video Toolbox視頻編解碼前后需要應(yīng)用的數(shù)據(jù)結(jié)構(gòu)進(jìn)行說明。
CVPixelBuffer：編碼前和解碼后的圖像數(shù)據(jù)結(jié)構(gòu)。此內(nèi)容包含一系列的CVPixelBufferPool內(nèi)容
CMTime、CMClock和CMTimebase：時(shí)間戳相關(guān)。時(shí)間以64-bit/32-bit的形式出現(xiàn)。
pixelBufferAttributes:字典設(shè)置.可能包括Width/height、pixel format type、? Compatibility (e.g., OpenGL ES, Core Animation)
CMBlockBuffer：編碼后，結(jié)果圖像的數(shù)據(jù)結(jié)構(gòu)。
CMVideoFormatDescription：圖像存儲(chǔ)方式，編解碼器等格式描述。
(CMSampleBuffer：存放編解碼前后的視頻圖像的容器數(shù)據(jù)結(jié)構(gòu)。
CMClock
CMTimebase: 關(guān)于CMClock的一個(gè)控制視圖,包含CMClock、時(shí)間映射(Time mapping)、速率控制(Rate control)
由二、采集視頻數(shù)據(jù)可知,我們獲取到的數(shù)據(jù)(CMSampleBufferRef)sampleBuffer為未編碼的數(shù)據(jù);
圖1.1
上圖中,編碼前后的視頻圖像都封裝在CMSampleBuffer中,編碼前以CVPixelBuffer進(jìn)行存儲(chǔ);編碼后以CMBlockBuffer進(jìn)行存儲(chǔ)。除此之外兩者都包括CMTime、CMVideoFormatDesc.
二、視頻數(shù)據(jù)流編碼并上傳到服務(wù)器
1.將CVPixelBuffer使用VTCompressionSession進(jìn)行數(shù)據(jù)流的硬編碼。
(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的初始化參數(shù)說明:
allocator:分配器,設(shè)置NULL為默認(rèn)分配
width: 寬
height: 高
codecType: 編碼類型,如kCMVideoCodecType_H264
encoderSpecification: 編碼規(guī)范。設(shè)置NULL由videoToolbox自己選擇
sourceImageBufferAttributes: 源像素緩沖區(qū)屬性.設(shè)置NULL不讓videToolbox創(chuàng)建,而自己創(chuàng)建
compressedDataAllocator: 壓縮數(shù)據(jù)分配器.設(shè)置NULL,默認(rèn)的分配
outputCallback: 當(dāng)VTCompressionSessionEncodeFrame被調(diào)用壓縮一次后會(huì)被異步調(diào)用.注:當(dāng)你設(shè)置NULL的時(shí)候,你需要調(diào)用VTCompressionSessionEncodeFrameWithOutputHandler方法進(jìn)行壓縮幀處理,支持iOS9.0以上
outputCallbackRefCon: 回調(diào)客戶定義的參考值.
compressionSessionOut: 壓縮會(huì)話變量。
(2)配置VTCompressionSession
使用VTSessionSetProperty()調(diào)用進(jìn)行配置compression。 * kVTCompressionPropertyKey AllowFrameReordering: 允許幀重新排序.默認(rèn)為true * kVTCompressionPropertyKey AverageBitRate: 設(shè)置需要的平均編碼率 * kVTCompressionPropertyKey H264EntropyMode：H264的 熵編碼 模式。有兩種模式:一種基于上下文的二進(jìn)制算數(shù)編碼CABAC和可變長(zhǎng)編碼VLC.在slice層之上（picture和sequence）使用定長(zhǎng)或變長(zhǎng)的二進(jìn)制編碼，slice層及其以下使用VLC或CABAC. 詳情請(qǐng)參考 * kVTCompressionPropertyKey RealTime: 視頻編碼壓縮是否是實(shí)時(shí)壓縮?？稍O(shè)置CFBoolean或NULL.默認(rèn)為NULL * kVTCompressionPropertyKey ProfileLevel: 對(duì)于編碼流指定配置和標(biāo)準(zhǔn) .比如kVTProfileLevel H264 Main AutoLevel
配置過VTCompressionSession后,可以可選的調(diào)用VTCompressionSessionPrepareToEncodeFrames進(jìn)行準(zhǔn)備工作編碼幀。
(3)開始硬編碼流入的數(shù)據(jù)
使用VTCompressionSessionEncodeFrame方法進(jìn)行編碼.當(dāng)編碼結(jié)束后調(diào)用outputCallback回調(diào)函數(shù)。
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： 獲取到的這個(gè)sample buffer數(shù)據(jù)的展示時(shí)間戳。每一個(gè)傳給這個(gè)session的時(shí)間戳都要大于前一個(gè)展示時(shí)間戳.
duration: 對(duì)于獲取到sample buffer數(shù)據(jù),這個(gè)幀的展示時(shí)間.如果沒有時(shí)間信息,可設(shè)置kCMTimeInvalid.
frameProperties: 包含這個(gè)幀的屬性.幀的改變會(huì)影響后邊的編碼幀.
sourceFrameRefCon: 回調(diào)函數(shù)會(huì)引用你設(shè)置的這個(gè)幀的參考值.
infoFlagsOut: 指向一個(gè)VTEncodeInfoFlags來接受一個(gè)編碼操作.如果使用異步運(yùn)行,kVTEncodeInfo_Asynchronous被設(shè)置；同步運(yùn)行,kVTEncodeInfo_FrameDropped被設(shè)置；設(shè)置NULL為不想接受這個(gè)信息.
(4)執(zhí)行VTCompressionOutputCallback回調(diào)函數(shù)
typedefvoid(*VTCompressionOutputCallback)(void* CM_NULLABLE outputCallbackRefCon,void* CM_NULLABLE sourceFrameRefCon,? ? ? ? OSStatus status,? ? ? ? VTEncodeInfoFlags infoFlags,? ? ? ? CM_NULLABLE CMSampleBufferRef sampleBuffer );
outputCallbackRefCon: 回調(diào)函數(shù)的參考值
sourceFrameRefCon: VTCompressionSessionEncodeFrame函數(shù)中設(shè)置的幀的參考值
status: 壓縮的成功為noErr,如失敗有錯(cuò)誤碼
infoFlags: 包含編碼操作的信息標(biāo)識(shí)
sampleBuffer: 如果壓縮成功或者幀不丟失,則包含這個(gè)已壓縮的數(shù)據(jù)CMSampleBuffer,否則為NULL
(5)將壓縮成功的sampleBuffer數(shù)據(jù)進(jìn)行處理為基本流NSData上傳到服務(wù)器
MPEG-4是一套用于音頻、視頻信息的壓縮編碼標(biāo)準(zhǔn).
由 圖1.1 可知,已壓縮 $$CMSampleBuffer = CMTime(可選) + CMBlockBuffer + CMVideoFormatDesc$$。
5.1 先判斷壓縮的數(shù)據(jù)是否正確
//不存在則代表壓縮不成功或幀丟失if(!sampleBuffer)return;if(status != noErr)return;//返回sampleBuffer中包括可變字典的不可變數(shù)組,如果有錯(cuò)誤則為NULLCFArrayRefarray=? CMSampleBufferGetSampleAttachmentsArray(sampleBuffer,true);if(!array)return;? CFDictionaryRef dic = CFArrayGetValueAtIndex(array,0);if(!dic)return;//issue 3:kCMSampleAttachmentKey_NotSync:沒有這個(gè)鍵意味著同步, yes: 異步. no:同步BOOL keyframe = !CFDictionaryContainsKey(dic, kCMSampleAttachmentKey_NotSync);//此代表為同步
而對(duì)于 issue 3 從字面意思理解即為以上的說明,但是網(wǎng)上看到很多都是做為查詢是否是視頻關(guān)鍵幀,而查詢文檔看到有此關(guān)鍵幀key值kCMSampleBufferAttachmentKey_ForceKeyFrame存在,因此對(duì)此值如若有了解情況者敬請(qǐng)告知詳情.
5.2 獲取CMVideoFormatDesc數(shù)據(jù)由 三、解碼篇 可知CMVideoFormatDesc 包括編碼所用的profile，level，圖像的寬和高，deblock濾波器等.具體包含 第一個(gè)NALU的SPS （Sequence Parameter Set）和 第二個(gè)NALU的PPS （Picture Parameter Set）.
//if (keyframe !encoder - sps) {? ? //獲取sample buffer 中的 CMVideoFormatDesc? ? CMFormatDescriptionRef format = CMSampleBufferGetFormatDescription(sampleBuffer);? ? //獲取H264參數(shù)集合中的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并轉(zhuǎn)換成數(shù)據(jù)
CMBlockBufferRef blockBuffer = CMSampleBufferGetDataBuffer(sampleBuffer);? ? size_t? lengthAtOffset,totalLength;char*dataPointer;//接收到的數(shù)據(jù)展示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èi)存地址的起始位置開始拷貝n個(gè)字節(jié)到目標(biāo)dest所指的內(nèi)存地址的起始位置中
*/memcpy(NALUnitLength, dataPointer + bufferOffset, AVCCHeaderLength);//字節(jié)從高位反轉(zhuǎn)到低位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數(shù)據(jù)應(yīng)用于后面的RTMP協(xié)議做推流準(zhǔn)備。
內(nèi)容元素:
當(dāng)采集視頻信號(hào)時(shí)，如果采用逐行掃描，則每次掃描得到的信號(hào)就是一副圖像，也就是一幀。
當(dāng)采集視頻信號(hào)時(shí)，如果采用隔行掃描（奇、偶數(shù)行），則掃描下來的一幀圖像就被分為了兩個(gè)部分，這每一部分就稱為「場(chǎng)」，根據(jù)次序分為：「頂場(chǎng)」和「底場(chǎng)」。
「幀」和「場(chǎng)」的概念又帶來了不同的編碼方式：幀編碼、場(chǎng)編碼逐行掃描適合于運(yùn)動(dòng)圖像，所以對(duì)于運(yùn)動(dòng)圖像采用幀編碼更好；隔行掃描適合于非運(yùn)動(dòng)圖像，所以對(duì)于非運(yùn)動(dòng)圖像采用場(chǎng)編碼更好
網(wǎng)絡(luò)提取層單元(NALU, Network Abstraction Layer Unit)，
NALU 是用來將編碼的數(shù)據(jù)進(jìn)行打包的，一個(gè)分片(Slice)可以編碼到一個(gè) NALU 單元。不過一個(gè) NALU 單元中除了容納分片(Slice)編碼的碼流外，還可以容納其他數(shù)據(jù)，比如序列參數(shù)集 SPS。對(duì)于客戶端其主要任務(wù)則是接收數(shù)據(jù)包，從數(shù)據(jù)包中解析出 NALU 單元，然后進(jìn)行解碼播放。
宏塊(Macroblock)，分片是由宏塊組成。
重慶分公司
重慶分公司
