一：推流需要的三方庫和一些常用格式和協議介紹
1.rtmp協議 ：實時消息傳輸協議,Adobe Systems公司為Flash播放器和服務器之間音頻、視頻和數據傳輸開發的開 ?放協議，因為是開放協議所以都可以使用了。RTMP協議用于對象、視頻、音頻的傳輸。這個協議建立在TCP協議或者輪詢HTTP協議之上。RTMP協議就像一個用來裝數據包的容器，這些數據可以是FLV中的視音頻數據。一個單一的連接可以通過不同的通道傳輸多路網絡流，這些通道中的包都是按照固定大小的包傳輸的
2.nginx:免費開源web服務器，常用來配置流媒體服務器。（后面會寫一篇介紹如何在mac上搭建Nginx服務器）
3.常用直播協議介紹與對比
HLS:由Apple公司定義的用于實時流傳輸的協議,HLS基于HTTP協議實現，傳輸內容包括兩部分，一是M3U8描述文件，二是TS媒體文件。可實現流媒體的直播和點播，主要應用在iOS系統
HLS是以點播的技術方式來實現直播
HLS是自適應碼率流播，客戶端會根據網絡狀況自動選擇不同碼率的視頻流，條件允許的情況下使用高碼率，網絡繁忙的時候使用低碼率，并且自動在二者間隨意切換。這對移動設備網絡狀況不穩定的情況下保障流暢播放非常有幫助。
實現方法是服務器端提供多碼率視頻流，并且在列表文件中注明，播放器根據播放進度和下載速度自動調整。
HLS與RTMP對比:HLS主要是延時比較大，RTMP主要優勢在于延時低
HLS協議的小切片方式會生成大量的文件，存儲或處理這些文件會造成大量資源浪費
相比使用RTSP協議的好處在于，一旦切分完成，之后的分發過程完全不需要額外使用任何專門軟件，普通的網絡服務器即可，大大降低了CDN邊緣服務器的配置要求，可以使用任何現成的CDN,而一般服務器很少支持RTSP。
HTTP-FLV:基于HTTP協議流式的傳輸媒體內容。
相對于RTMP，HTTP更簡單和廣為人知，內容延遲同樣可以做到1~3秒，打開速度更快，因為HTTP本身沒有復雜的狀態交互。所以從延遲角度來看，HTTP-FLV要優于RTMP。
RTSP:實時流傳輸協議,定義了一對多應用程序如何有效地通過IP網絡傳送多媒體數據.
RTP:實時傳輸協議,RTP是建立在UDP協議上的，常與RTCP一起使用，其本身并沒有提供按時發送機制或其它服務質量（QoS）保證，它依賴于低層服務去實現這一過程。
RTCP:RTP的配套協議,主要功能是為RTP所提供的服務質量（QoS）提供反饋，收集相關媒體連接的統計信息，例如傳輸字節數，傳輸分組數，丟失分組數，單向和雙向網絡延遲等等
關于協議的選擇方面：即時性要求較高或有互動需求的可以采用RTMP,RTSP；對于有回放或跨平臺需求的，推薦使用HLS
4.視頻封裝格式：
TS: 一種流媒體封裝格式，流媒體封裝有一個好處，就是不需要加載索引再播放，大大減少了首次載入的延遲，如果片子比較長，mp4文件的索引相當大，影響用戶體驗
為什么要用TS:這是因為兩個TS片段可以無縫拼接，播放器能連續播放
FLV: 一種流媒體封裝格式,由于它形成的文件極小、加載速度極快，使得網絡觀看視頻文件成為可能,因此FLV格式成為了當今主流視頻格式
5 需要的庫文件
librtmp：這是一個C++的開源工程。主要作用是下載RTMP流媒體
libfaac ：將獲取到的音頻數據編碼成acc格式以及將aac數據合成flv格式
libx264：把視頻原數據YUV編碼壓縮成H.264格式
libyuv：將獲取到的視頻轉化為yuv(NV12)格式
二：推流流程
關于推流流程我會主要用代碼截圖來展示
1 ：獲取視頻音頻流 此處主要用不帶美顏效果的系統獲取方法
（1）：初始化視頻設備
（2）創建輸入輸出管道
（3）創建會話
（4）創建預覽
（5）在前面幾步實現后我們就可以來用系統方法獲取視頻音頻流了，這個方法是AVCaptureAudioDataOutputSampleBufferDelegate的代理方法，由于系統返回沒有區分是視頻數據還是音頻數據 所以我們需要自己代碼判斷如下圖：
2.視頻編碼及推流
（1）將視頻流變成yuvdata數據
-(NSData*) convertVideoSmapleBufferToYuvData:(CMSampleBufferRef) videoSample{
//獲取yuv數據
//通過CMSampleBufferGetImageBuffer方法，獲得CVImageBufferRef。
//這里面就包含了yuv420數據的指針
CVImageBufferRefpixelBuffer =CMSampleBufferGetImageBuffer(videoSample);
//表示開始操作數據
CVPixelBufferLockBaseAddress(pixelBuffer,0);
//圖像寬度（像素）
size_tpixelWidth =CVPixelBufferGetWidth(pixelBuffer);
//圖像高度（像素）
size_tpixelHeight =CVPixelBufferGetHeight(pixelBuffer);
//yuv中的y所占字節數
size_ty_size = pixelWidth * pixelHeight;
//yuv中的u和v分別所占的字節數
size_tuv_size = y_size /4;
uint8_t*yuv_frame =aw_alloc(uv_size *2+ y_size);
//獲取CVImageBufferRef中的y數據
uint8_t*y_frame =CVPixelBufferGetBaseAddressOfPlane(pixelBuffer,0);
memcpy(yuv_frame, y_frame, y_size);
//獲取CMVImageBufferRef中的uv數據
uint8_t*uv_frame =CVPixelBufferGetBaseAddressOfPlane(pixelBuffer,1);
memcpy(yuv_frame + y_size, uv_frame, uv_size *2);
CVPixelBufferUnlockBaseAddress(pixelBuffer,0);
NSData*nv12Data = [NSDatadataWithBytesNoCopy:yuv_framelength:y_size + uv_size *2];
//旋轉
return[selfrotateNV12Data:nv12Data];
}
（2）yuv格式---->nv12格式
-(NSData*)rotateNV12Data:(NSData*)nv12Data{
intdegree =0;
switch(self.videoConfig.orientation) {
caseUIInterfaceOrientationLandscapeLeft:
degree =90;
break;
caseUIInterfaceOrientationLandscapeRight:
degree =270;
break;
default:
//do nothing
break;
}
if(degree !=0) {
uint8_t*src_nv12_bytes = (uint8_t*)nv12Data.bytes;
uint32_twidth = (uint32_t)self.videoConfig.width;
uint32_theight = (uint32_t)self.videoConfig.height;
uint32_tw_x_h = (uint32_t)(self.videoConfig.width*self.videoConfig.height);
uint8_t*rotatedI420Bytes =aw_alloc(nv12Data.length);
NV12ToI420Rotate(src_nv12_bytes, width,
src_nv12_bytes + w_x_h, width,
rotatedI420Bytes, height,
rotatedI420Bytes + w_x_h, height /2,
rotatedI420Bytes + w_x_h + w_x_h /4, height /2,
width, height, (RotationModeEnum)degree);
I420ToNV12(rotatedI420Bytes, height,
rotatedI420Bytes + w_x_h, height /2,
rotatedI420Bytes + w_x_h + w_x_h /4, height /2,
src_nv12_bytes, height, src_nv12_bytes + w_x_h, height,
height, width);
aw_free(rotatedI420Bytes);
}
returnnv12Data;
}
（3）nv12格式數據合成flv格式
-(aw_flv_video_tag*)encodeYUVDataToFlvTag:(NSData*)yuvData{
if(!_vEnSession) {
returnNULL;
}
//yuv變成轉CVPixelBufferRef
OSStatusstatus =noErr;
//視頻寬度
size_tpixelWidth =self.videoConfig.pushStreamWidth;
//視頻高度
size_tpixelHeight =self.videoConfig.pushStreamHeight;
//現在要把NV12數據放入CVPixelBufferRef中，因為硬編碼主要調用VTCompressionSessionEncodeFrame函數，此函數不接受yuv數據，但是接受CVPixelBufferRef類型。
CVPixelBufferRefpixelBuf =NULL;
//初始化pixelBuf，數據類型是kCVPixelFormatType_420YpCbCr8BiPlanarVideoRange，此類型數據格式同NV12格式相同。
CVPixelBufferCreate(NULL, pixelWidth, pixelHeight,kCVPixelFormatType_420YpCbCr8BiPlanarVideoRange,NULL, &pixelBuf);
// Lock address，鎖定數據，應該是多線程防止重入操作。
if(CVPixelBufferLockBaseAddress(pixelBuf,0) !=kCVReturnSuccess){
[selfonErrorWithCode:AWEncoderErrorCodeLockSampleBaseAddressFaileddes:@"encode video lock base address failed"];
returnNULL;
}
//將yuv數據填充到CVPixelBufferRef中
size_ty_size =aw_stride(pixelWidth) * pixelHeight;
size_tuv_size = y_size /4;
uint8_t*yuv_frame = (uint8_t*)yuvData.bytes;
//處理y frame
uint8_t*y_frame =CVPixelBufferGetBaseAddressOfPlane(pixelBuf,0);
memcpy(y_frame, yuv_frame, y_size);
uint8_t*uv_frame =CVPixelBufferGetBaseAddressOfPlane(pixelBuf,1);
memcpy(uv_frame, yuv_frame + y_size, uv_size *2);
//硬編碼CmSampleBufRef
//時間戳
uint32_tptsMs =self.manager.timestamp+1;//self.vFrameCount++ * 1000.f / self.videoConfig.fps;
CMTimepts =CMTimeMake(ptsMs,1000);
//硬編碼主要其實就這一句。將攜帶NV12數據的PixelBuf送到硬編碼器中，進行編碼。
status =VTCompressionSessionEncodeFrame(_vEnSession, pixelBuf, pts,kCMTimeInvalid,NULL, pixelBuf,NULL);
if(status ==noErr) {
dispatch_semaphore_wait(self.vSemaphore,DISPATCH_TIME_FOREVER);
if(_naluData) {
//此處硬編碼成功，_naluData內的數據即為h264視頻幀。
//我們是推流，所以獲取幀長度，轉成大端字節序，放到數據的最前面
uint32_tnaluLen = (uint32_t)_naluData.length;
//小端轉大端。計算機內一般都是小端，而網絡和文件中一般都是大端。大端轉小端和小端轉大端算法一樣，就是字節序反轉就行了。
uint8_tnaluLenArr[4] = {naluLen >>24&0xff, naluLen >>16&0xff, naluLen >>8&0xff, naluLen &0xff};
//將數據拼在一起
NSMutableData*mutableData = [NSMutableDatadataWithBytes:naluLenArrlength:4];
[mutableDataappendData:_naluData];
//將h264數據合成flv tag，合成flvtag之后就可以直接發送到服務端了。后續會介紹
aw_flv_video_tag*video_tag =aw_encoder_create_video_tag((int8_t*)mutableData.bytes, mutableData.length, ptsMs,0,self.isKeyFrame);
//到此，編碼工作完成，清除狀態。
_naluData=nil;
_isKeyFrame=NO;
CVPixelBufferUnlockBaseAddress(pixelBuf,0);
CFRelease(pixelBuf);
returnvideo_tag;
}
}else{
[selfonErrorWithCode:AWEncoderErrorCodeEncodeVideoFrameFaileddes:@"encode video frame error"];
}
CVPixelBufferUnlockBaseAddress(pixelBuf,0);
CFRelease(pixelBuf);
returnNULL;
}
（4）發送視頻flv到rtmp服務器
3 音頻數據編碼和推流
（1）將音頻流轉換成data數據
-(NSData*) convertAudioSmapleBufferToPcmData:(CMSampleBufferRef) audioSample{
//獲取pcm數據大小
NSIntegeraudioDataSize =CMSampleBufferGetTotalSampleSize(audioSample);
//分配空間
int8_t*audio_data =aw_alloc((int32_t)audioDataSize);
//獲取CMBlockBufferRef
//這個結構里面就保存了PCM數據
CMBlockBufferRefdataBuffer =CMSampleBufferGetDataBuffer(audioSample);
//直接將數據copy至我們自己分配的內存中
CMBlockBufferCopyDataBytes(dataBuffer,0, audioDataSize, audio_data);
//返回數據
return[NSDatadataWithBytesNoCopy:audio_datalength:audioDataSize];
}
（2）將音頻data數據編碼成acc格式并合成為flv
-(aw_flv_audio_tag*)encodePCMDataToFlvTag:(NSData*)pcmData{
self.curFramePcmData= pcmData;
AudioBufferListoutAudioBufferList = {0};
outAudioBufferList.mNumberBuffers=1;
outAudioBufferList.mBuffers[0].mNumberChannels= (uint32_t)self.audioConfig.channelCount;
outAudioBufferList.mBuffers[0].mDataByteSize=self.aMaxOutputFrameSize;
outAudioBufferList.mBuffers[0].mData=malloc(self.aMaxOutputFrameSize);
uint32_toutputDataPacketSize =1;
OSStatusstatus =AudioConverterFillComplexBuffer(_aConverter,aacEncodeInputDataProc, (__bridgevoid*_Nullable)(self), &outputDataPacketSize, &outAudioBufferList,NULL);
if(status ==noErr) {
NSData*rawAAC = [NSDatadataWithBytesNoCopy: outAudioBufferList.mBuffers[0].mDatalength:outAudioBufferList.mBuffers[0].mDataByteSize];
self.manager.timestamp+=1024*1000/self.audioConfig.sampleRate;
returnaw_encoder_create_audio_tag((int8_t*)rawAAC.bytes, rawAAC.length, (uint32_t)self.manager.timestamp, &_faacConfig);
}else{
[selfonErrorWithCode:AWEncoderErrorCodeAudioEncoderFaileddes:@"aac編碼錯誤"];
}
returnNULL;
}
（3）發送音頻flv到rtmp服務器
至此 我們就把flv格式的音視頻數據發送到了rtmp服務器，服務器通過cdn分發后我們用ijkplayer打開就可以播了
三 需要注意的部分
1：獲取完視頻退出是要記得銷毀會話
2 編（解）碼分硬（解）編碼和軟編（解）碼
軟編碼：使用CPU進行編碼，性能高，低碼率下通常質量低于硬編碼器，但部分產品在GPU硬件平臺移植了優秀的軟編碼算法（如X264）的，質量基本等同于軟編碼。
硬編碼：使用非CPU進行編碼，如顯卡GPU、專用的DSP、FPGA、ASIC芯片等，實現直接、簡單，參數調整方便，升級易，但CPU負載重，性能較硬編碼低，低碼率下質量通常比硬編碼要好一點。
