gpuimage視頻android
A. 有沒有手機端用於rtmp推流(串流)直播的軟體apk格式
播推流端即主播端，主要通過手機攝像頭採集視頻數據和麥克風採集音頻數據，經過一系列前處理、編碼、封裝，然後推流到CDN進行分發。趣拍直播SDK可以滿足以下所有的功能和應用場景，幫助開發者解決各種直播難題。採集手機直播SDK通過手機攝像頭和麥克風直接採集視頻數據和音頻數據。其中,視頻采樣數據一般採用RGB或YUV格式、音頻采樣數據一般採用PCM格式。對於採集到的原始音視頻的體積是非常大的，因此需要經過壓縮技術來處理，降低視頻的大小來提示傳輸效率。在手機視頻採集方面，iOS系統在硬體的兼容性方面做得比較好，系統本身提供了比較完整的視頻採集的介面，使用起來也比較簡單。但是，Android系統就比較麻煩了，千奇百怪的機型都有，適配起來非常難。我們在初期做了一項調研，發現Android的適配率還不到50%。2.前處理在這個環節主要處理美顏、水印、模糊等效果。特別是美顏功能幾乎是直播的標配功能，沒有美顏的直播主播們根本提不起興趣。我們見過太多case是因為沒有美顏功能被拋棄使用的。另外國家明確提出了，所有直播都必須打有水印並回放留存15天以上。所以，在選擇直播SDK時，沒有美顏和水印功能基本就可以選擇放棄了。美顏實際上是通過演算法去識別圖像中的皮膚部分，再對皮膚區域進行色值調整。通常情況下人的膚色與周邊環境色調存在較大差異，通過顏色對比，找到皮膚的基本輪廓，進一步進行膚色檢查還可以確定人臉范圍。找到了皮膚的區域，可以進行色值調整、添加白色圖層或調整透明度等來等來達到美白效果。美顏除了美白效果還需要磨皮功能，磨皮實際上就是用模糊濾鏡實現的。濾鏡有很多種，如高斯濾波，雙邊濾波，導向濾波，到底選擇什麼樣的模糊濾鏡各家也有自己的喜好。在美顏處理方面，最著名的GPUImage提供了豐富的效果，同時可以支持IOS和Android，還支持自己寫演算法實現自己最理性的效果。GPUImage本事內置了120多種常見濾鏡效果，添加濾鏡只需要簡單調用幾行代碼就可以了，比如大家可以試試使用GPUImageBilateralFiter的雙邊濾波濾鏡來處理基本的磨皮效果，想要實現更理想的效果還是要通過自定義演算法去實現的，各家也都有自己一套演算法。3、編碼為了便於手機視頻的推流、拉流以及存儲，通常採用視頻編碼壓縮技術來減少視頻的體積。現在比較常用的視頻編碼是H.264，但具有更高性能的H.265編碼技術正在飛速發展，並可能很快成為主流；在音頻方面，通比較常用的是用AAC編碼格式進行壓縮，其它如MP3、WMA也是可選方案。視頻經過編碼壓縮大大提高了視頻的存儲和傳輸效率，當然，經過壓縮後的視頻在播放時必須進行解碼。通俗點講就是編碼器將多張圖像進行編碼後產生一段段GOP（GroupofPictures），播放時解碼器讀取一段段GOP進行解碼後讀取圖像並進行渲染顯示。在編碼方面的核心是在解析度、碼率、幀率等參數中找到最佳平衡點，達到體積最小畫面最優的效果，這些參數各家也都有自己的一套核心參數。2012年8月，愛立信公司推出了首款H.265編解碼器，六個月後，國際電聯(ITU)就正式批准通過了HEVC/H.265標准，稱之為高效視頻編碼(HighEfficiencyVideoCoding)，相較於之前的H.264標准有了相當大的改善，做到了僅需要原來一半帶寬即可播放相同質量的視頻，低於1.5Mbps的網路也能傳輸1080p的高清視頻。國內，如阿里雲、金山雲都在推自己的H.265編解碼技術，隨著直播的快速發展和對帶寬的依賴，H.265編解碼技術已有全面取代H.264的趨勢。當然，全面推開應用還需要些時間。另外，硬體編碼已經成為手機直播的首選方案，軟編碼處理在720p以上的視頻頹勢非常明顯。在IOS平台上硬體編碼的兼容性比較好，可以直接採用，但在Android平台上，Android的MediaCodec編碼器，針對不同的晶元平台表現差異還是非常大的，要完全實現全平台兼容的4、推流要想用於推流還必須把音視頻數據使用傳輸協議進行封裝，變成流數據。常用的流傳輸協議有RTSP、RTMP、HLS等，使用RTMP傳輸的延時通常在1–3秒，對於手機直播這種實時性要求非常高的場景，RTMP也成為手機直播中最常用的流傳輸協議。最後通過一定的Qos演算法將音視頻流數據推送到網路斷，通過CDN進行分發。在直播場景中，網路不穩定是非常常見的，這時就需要Qos來保證網路不穩情況下的用戶觀看直播的體驗，通常是通過主播端和播放端設置緩存，讓碼率均勻。另外，針對實時變化的網路狀況，動態碼率和幀率也是最常用的策略。當然，在網路傳輸方面全部自己來做基本不現實，找提供推流服務的CDN服務商提供解決方案是最好的選擇，可參考文章開頭介紹的雲視頻服務商。據了解，阿里雲是國內唯一能自研CDN緩存伺服器的廠商，性能還是非常有保障的。通常，大多數直播平台都會同時接入多個視頻雲服務提供商，這樣可以做拉流線路互備，對推流後視頻集群再進行優化也可提高直播的流暢性和穩定性。
B. 短視頻編輯：可實時交互的播放器
如何開發一個類似剪影或抖音的視頻剪輯工具？
其開發任務如上圖，一個短視頻生產app的首要任務在於實現一個高度可實時交互的播放器，在播放預覽時支持多種編輯能力。
最初我們調研了多種方案，乍一看Android原生播放器肯定不夠用，估計要在眾多c++的開源播放器中尋找參考方案，最好自己實現一個播放器，高度靈活高度可控。然而我們發現exo這個男團播放器的厲害之處，雖然這個播放器如此常用，但是我們不知道其潛力值爆表，可以拓展得如此強大。
事實上直到現在，我們仍然在自研視頻剪輯工具中使用exoplayer做編輯預覽。為什麼選擇exoplayer,基於以下幾點原因（一句話，性價比高）：
使用基於exoplayer播放器進行二次開發，快速高效實現視頻剪輯功能。視頻剪輯播放器用於視頻編輯過程中的實時預覽播放，支持有功能有：
針對上述視頻剪輯所需要支持的功能，逐一對照explayer的api文檔，尋找拓展實現的方法。
其中，視頻旋轉、文字貼紙、美顏濾鏡、素材轉場需要調用setVideoSurface控制視頻呈現層，自定義GLSurfaceView，使用opengl實現對視頻的旋轉、美顏濾鏡、添加貼紙。exoplayer播放輸出的surface與自定義GLSurfaceView的渲染紋理相綁定。
視頻裁剪播放使用ClippingMediaSource設置裁剪素材，按api文檔傳入起始時間和結束時間。
多個視頻拼接播放，使用ConcatenatingMediaSource可以用來無縫地合並播放多個素材，為了能對單個素材進行編輯，isAtomic設為true。
變速使用setPlaybackParameters設置速度參數
這三個功能使用exoplayer已提供的api就可以實現，相對容易。在執行編輯操作後即時更新播放器素材和參數即可。在我們的產品中，有一個撤銷操作的交互，所以需要保留一份數據拷貝，如果用戶撤銷操作則更新為原來的數據。
exoplayer本身不支持圖片格式的素材播放。注入一個自定義渲染器來實現圖片（格式為jpg、png、gif等）
其中ImageRender繼承BaseRenderer，實現了圖片的自定義渲染。render主要工作是將每幀數據解碼流渲染為屏幕圖像。對於圖片來說，我們定義ImageMediaSourceImage、SampleStreamImpl和ImageMediaPeriod，分別繼承於BaseMediaSource、SampleStream和MediaPeriod，從原素材解析並傳送每幀圖片數據。圖片不需要真正的解碼，實現SampleStream的readData方法讀取圖片uri為解碼buffer。
實現圖片播放的核心在於實現render介面：
在這個方法內，我們創建opengl環境，將bitmap繪制到屏幕上
添加的文字或貼紙支持移動、旋轉、縮放和設置時間軸。對於多個文字貼紙，我們最終包裝為一個與渲染屏幕同尺寸的bitmap，在這個bitmap的畫布上繪制一系列帶坐標大小、起止時間的小bitmap(即stickerItem.getBitmap)。
將這張貼紙畫布bitmap與原視頻幀像素混合就實現了所有文字貼紙的繪制。用opengl繪制貼紙，就是對屏幕上像素做一個水印濾鏡的運算。採用GLSL內建的mix函數做兩個紋理的混合，以下是水印濾鏡所用的片元著色器。
和文字貼紙一樣，要實現實時的美顏濾鏡效果，必須使用幀緩沖fbo。幀緩沖的每一存儲單元對應著屏幕每一個像素。而美顏濾鏡涉及較復雜演算法，由部門內的人工智慧組提供sdk接入，在繪制過程中調用sdk方法如下，就是使用fbo進行一次圖像紋理轉換。傳入參數為屏幕方向、攝像頭方向和渲染尺寸。
目前產品實現了左右移、上下移、拉近拉遠、順時針逆時針旋轉等幾種轉場效果。轉場的實現方法是：對於兩個在其中添加了轉場的素材，在上一個素材的最後1000ms繪制轉場濾鏡，轉場濾鏡即將兩張圖片的像素以一定的規律進行渲染，轉場演算法由opengl使用glsl著色器實現。轉場基類的片元著色器如下，移動轉場（左右向移動和上下移動）、縮放轉場（拉近拉遠）、旋轉轉場對getFromColor與getToColor執行的行為不同。
以移動轉場的轉場glsl著色器為例
轉場的具體實現參考了GPUImageFilter庫，和美顏濾鏡以及文字貼紙不同的是，轉場濾鏡需要在渲染前預先設置將下個素材的首幀圖。
在預覽編輯過程中，由於音樂並不需要真正合成於視頻中，因此可以使用另一個播放器單獨播放音頻，我們採用android更原始的MediaPlayer單獨播放音樂，單獨支持音樂的裁剪播放和seek。
抽幀預覽即每隔固定時間取視頻的一幀圖片構成時間軸，我們使用ffmpegMediaMetadataRetriever庫進行抽幀 ，使用方法為
該庫內部使用ffmpeg進行解碼取幀，介面易用但是其軟體解碼方式效率過低，相對較慢。因為exoplayer播放器是默認使用硬體解碼的，可以採用另一個exoplayer播放器快速播放一次素材，然後每隔一段時間獲取屏幕圖像，但此種方法開銷過大，兩個exoplayer播放器不利於管理。
最後，我們發現常用的圖片載入庫glide也能進行視頻抽幀，使用更為簡單方便，其內部採用mediaMetadataRetriever進行抽幀。
1.調整素材，拼接、裁剪、變速
https://vod.cc.163.com/file/5f896ef25655da63cc2d3237.mp4
2.轉場、文字貼紙、美顏濾鏡
https://vod.cc.163.com/file/5f896edad70f81a0e3c77dbe.mp4
C. GPUImage（四）：你們處理的都是GPUImageFramebuffer類型
在使用GPUImage處理圖片或者視頻時，並不能直接對iOS官方定義的的UIImage、CGImage、CIImage進行操作。那麼如果要使用GPUImage的話，第一步操作就是把你想處理的數據類型用一個GPUImage定義的載體承載，才能在GPUImage的處理鏈中進行一步一步的操作，這個載體就是GPUImageFramebuffer。我們把一張圖像的像素等攜帶的全部信息看成好幾種散裝液體顏料的集合，系統提供了UIImage（最常用的圖像類型）相當於一個顏料盒子，想把圖片顯示在iPhone設備屏幕上的話首先就是要把散裝顏料裝到這個顏料盒子里。GPUImageFramebuffer就是GPUImage中的顏料盒子，所以要先把UIImage盒子中的顏料倒到GPUImageFramebuffer中，才可以用GPUImage對這些顏料進行再次調色。調色的過程之前的文章中比喻成了一個多維度的管道，因此，在處理過程中就像GPUImageFramebuffer帶著顏料在管子里流動，經過一個節點處理完後會有一個新盒子把調好色的顏料接住再往下流動。
從以上GPUImageFramebuffer.h的內容可看到，主要內容分為三大部分：1.framebuffer及texture的創建。2.GPUImage中GPUImageFramebuffer類型對象的內存管理。3.實際操作過程中數據存儲的CVPixelBufferRef類型對象的具體操作。接下來就來看一下這三點中涉及到的具體類型到底是個啥以及在GPUImage框架中做了哪些事。
網路中對紋理的解釋：
在大學時期有一門計算機圖形課，主要是在Windows上使用C進行OpenGL開發。當時我做了一架直升飛機，雖然具體如何開發OpenGL現在已經有點陌生，但是其中印象非常深刻的有兩個地方：1.只能畫三角形，正方形是通過兩個三角形組成的，圓形是有非常多個三角形組成的，三角形越多，鋸齒越不明顯。2.畫好各種形狀組成三維圖形後可以往圖形上面貼圖，就好像罐頭的包裝一樣，剛做好的罐頭其實只是一個鋁制或者其他材料製成的沒有任何圖案的圓柱體，出產前最後一道工序就是給罐頭貼上一圈紙或者噴上相應的圖案。最後出廠運往各個賣場，我才能買到印有「某巢」以及各個信息在罐子上的奶粉。紋理就是貼在上面的紙或者印在上面的圖案。
紋理的WRAP設置解釋如下（截圖內容來自：http://blog.csdn.net/wangdingqiaoit/article/details/51457675）
字面上的意思是幀緩存，在OpenGL中，幀緩存的實例被叫做FBO。個人理解：如果texture是罐頭上的內容，那framebuffer就是那張裹在罐頭上的紙，它負責對紋理內容進行緩存並渲染到屏幕上，這個過程就叫做render to texture。當然framebuffer中不僅可以緩存原始的紋理內容，還可以是經過OpenGL處理後的內容。比如照片中牛奶罐頭上除了有本身的名字、圖案和說明這些內容，我們看上去還有相應的質感和反光效果，這個就可以通過獲取反光中的實際影像進行透明、拉伸、霧化等效果處理後得到與實際反光一模一樣的圖，最終渲染到牛奶罐上。
從這個角度理解的話，可以把texture看作是framebuffer的一部分，因此在GPUImage中把指向texture的地址作為GPUImageFramebuffer的一個屬性。當然也有不需要創建frambuffer的情況，比如在初始化輸入源時例如GPUImagePicture類型對象，載入圖片資源時只需要創建texture即可，GPUImageFramebuffer的其中一個初始化方法的其中一個參數onlyGenerateTexture為YES時，就可以只創建texture，把圖片信息轉化成紋理，而沒有進行framebuffer的創建。
有創建就有銷毀，GPUImageFramebuffer有一個私有方法- (void)destroyFramebuffer，在dealloc時調用。其中主要的操作是：
相信很多使用過GPUImage都會有同樣的經歷，都會遇到這個斷言。以下就拿具體案例來解釋GPUImage對GPUImageFramebuffer到底做了哪些事情。場景是：創建一個GPUImagePicture對象pic，一個GPUImageHueFilter對象filter和一個GPUImageView對象imageView，實現效果是pic通過filter處理後的效果顯示在imageView上。具體的處理過程就不過多說明，我們來主要看一下GPUImageFramebuffer在整個處理過程中發生的情況。
·GPUImagePicture對象pic中的framebuffer
在對初始化傳入的UIImage對象進行一系列處理後，pic進行自身的framebuffer的獲取：
可以看到，framebuffer對象並不是通過初始化GPUImageFramebuffer來創建的，而是通過調用單例[GPUImageContext sharedFramebufferCache]的其中一個方法得到的。sharedFramebufferCache其實是一個普通的NSObject子類對象，並不具有像NSCache對象對數據緩存的實際處理功能，不過GPUImage通過單例持有這個sharedFramebufferCache對象來對過程中產生的framebuffer進行統一管理。獲取framebuffer的方法有兩個入參：1.紋理大小，在pic中的這個大小正常情況下是傳入圖片的初始大小，當然還有不正常情況之後再說。2.是否返回只有texture的的framebuffer對象。
第一步：
傳入的紋理大小，textureOptions（默認）、是否只要texture調用sharedFramebufferCache的- (NSString *)hashForSize:(CGSize)size textureOptions:(GPUTextureOptions)textureOptions onlyTexture:(BOOL)onlyTexture;方法得到一個用於查詢的唯一值 lookupHash。 由此可見如果紋理大小一致的GPUImagePicture對象獲取到的lookupHash是相同的。
第二步：
lookupHash作為key，在sharedFramebufferCache的一個字典類型的屬性framebufferTypeCounts獲取到 ，如字面意思，在緩存中滿足條件的GPUImageFramebuffer類型對象的個數。轉換為整數類型為 numberOfMatchingTextures 。
第三步：
如果 小於1也就是沒找到的話，就調用GPUImageFramebuffer的初始化方法創建一個新的framebuffer對象。否則：將lookupHash和（numberOfMatchingTextures - 1）拼接成key從sharedFramebufferCache的另一個字典類型的屬性framebufferCache中獲取到framebuffer對象。再更新framebufferTypeCounts中數值（減1） 。
第四步：
以防最後返回的framebuffer對象為nil，最後做了判斷如果為nil的話就初始化創建一個。
第五步：
調用作為返回值的framebuffer對象的- (void)lock;方法。主要是對 framebufferReferenceCount 進行+1操作。framebufferReferenceCount為framebuffer的一個屬性，初始化時候為0，作用也是字面意思：對象被引用的次數。此時需要進行+1操作是因為framebuffer對象即將被獲取它的pic引用並將圖片內容載入。
但是！與GPUImageFilter類型對象不同的是在pic獲取到framebuffer後，進行了[outputFramebuffer disableReferenceCounting];。這個方法里將framebuffer的 referenceCountingDisabled 設置為YES。而這個屬性的值在- (void)lock;方法中又會導致不一樣的結果。如果referenceCountingDisabled為YES的話將不會對framebufferReferenceCount進行+1操作。
然而問題就出在這里 ，在pic獲取到framebuffer之前，從sharedFramebufferCache找到framebuffer後就對它調用了- (void)lock;方法，此時pic獲取到的framebuffer對象的framebufferReferenceCount已經被+1，而referenceCountingDisabled是在這之後才設置為YES，從而導致在pic對象dealloc時候自身的outputFramebuffer屬性並未得到釋放從而引起內存泄漏。為了解決這個問題我寫了一個GPUImagePicture的caterogy，重寫dealloc方法，將原本的[outputFramebuffer unlock];替換成 [outputFramebuffer clearAllLocks];， 保證outputFramebuffer的framebufferReferenceCount被重置為0，從而保證outputFramebuffer能順利釋放。
·GPUImageHueFilter對象filter中的framebuffer
我們以結構最簡單的單輸入源濾鏡對象作為例子，通過GPUImageHueFilter對象filter。filter相比pic來說相同點是：自身都會通過sharedFramebufferCache獲取到一個framebuffer用來存儲經過自身處理後的數據並傳遞給下一個對象。不同點是：filter有一個 firstInputFramebuffer 變數，作用是引用上一個節點的outputFramebuffer。如果是繼承自GPUImageTwoInputFilter的濾鏡對象來說，它的成員變數將會多一個secondInputFramebuffer。若想進行到filter這，必須將filter作為pic的target，並調用pic的processImage方法。filter中方法調用順序是：
1. 對輸入的framebuffer引用並調用lock方法。假設pic的framebuffer為初始化創建的，傳入前framebufferReferenceCount為1，經過此方法後framebufferReferenceCount則為2
2. filter的處理操作，也就是framebuffer的渲染紋理。這里就復雜了，那就不涉及到具體的渲染過程了。
filter的outputFramebuffer與pic一樣，都是通過shareFramebufferCache查找獲得。因此，outputFramebuffer變數被賦值時framebuffer的framebufferReferenceCount已經為1。接下來有一個判斷條件： usingNextFrameForImageCapture 。在類中全局搜一下，發現在調用 - (void)useNextFrameForImageCapture; 方法時會將usingNextFrameForImageCapture設置為YES。那麼什麼時候會調用這個方法呢？有用GPUImage寫過最簡單的離屏渲染功能實現的都會覺得對這個方法有點眼熟，那就是在filter處理完後導出圖片前必須要調用這個方法。為啥呢？原因就在這個判斷條件這里，如果usingNextFrameForImageCapture為YES，那麼outputFramebuffer要再lock一次，就是為了保證在處理完成後還需要引用outputFramebuffer，從而才可以從中生成圖片對象，否則就被回收進shareFramebufferCache啦。
進行過一頓操作後，最後會調用輸入源的unlock方法。這時候firstInputFramebuffer的framebufferReferenceCount按照正常情況的話將會為0，就會被添加到shareFramebufferCache中。
3. 接下來執行的方法中會把自身的outputFramebuffer傳遞給鏈中的下一個節點，就像pic到filter的過程一樣。
這里的[self framebufferForOutput]在正常的filter中會返回outputFramebuffer。如果usingNextFrameForImageCapture為YES的話，可以簡單理解當前對象的outputFramebuffer傳遞給下一個target後還有其他用處的話就不置空outputFramebuffer變數。如果usingNextFrameForImageCapture為NO的話，當前outputFramebuffer被置為nil，但是原先outputFramebuffer指向的framebuffer並不會被回收到shareFramebufferCache。原因是：framebuffer已經傳遞給下個target，在相應賦值方法中對framebuffer調用了lock方法。周而復始，直到最後一個節點，要麼生成圖片，要麼顯示。
D. 視頻直播APP開發怎麼做
一、直播的技術架構：
直播視頻採集SDK（PC/IOS/Anddroid）——直播CDN
（直播流分發加速）——直播視頻播放器SDK（PC/IOS/Android）
二、音視頻處理的一般流程：
數據採集→數據編碼→數據傳輸(流媒體伺服器) →解碼數據→播放顯示
1、數據採集：
攝像機及拾音器收集視頻及音頻數據，此時得到的為原始數據
涉及技術或協議：
攝像機：CCD、CMOS
拾音器：聲電轉換裝置（咪頭）、音頻放大電路
2、數據編碼：
使用相關硬體或軟體對音視頻原始數據進行編碼處理（數字化）及加工（如音視頻混合、打包封裝等），得到可用的音視頻數據
涉及技術或協議：
編碼方式：CBR、VBR
編碼格式
視頻：H.265、H.264、MPEG-4等，封裝容器有TS、MKV、AVI、MP4等
音頻：G.711μ、AAC、Opus等，封裝有MP3、OGG、AAC等
3、數據傳輸：
將編碼完成後的音視頻數據進行傳輸，早期的音視頻通過同軸電纜之類的線纜進行傳輸，IP網路發展後，使用IP網路優傳輸
涉及技術或協議：
傳輸協議：RTP與RTCP、RTSP、RTMP、HTTP、HLS（HTTP Live Streaming）等
控制信令：SIP和SDP、SNMP等
4、解碼數據：
使用相關硬體或軟體對接收到的編碼後的音視頻數據進行解碼，得到可以直接顯示的圖像/聲音
涉及技術或協議：
一般對應的編碼器都會帶有相應的解碼器，也有一些第三方解碼插件等
5、播放顯示：
在顯示器（電視、監視屏等）或揚聲器（耳機、喇叭等）里，顯示相應的圖像畫面或聲音
涉及技術或協議：
顯示器、揚聲器、3D眼鏡等
三、常見的視頻直播相關協議：
1、RTMP(Real Time Messaging Protocol，實時消息傳送協議)
RTMP是Adobe Systems公司為Flash播放器和伺服器之間音頻、視頻和數據傳輸開發的開放協議。它有三種變種：
1）、工作在TCP之上的明文協議，使用埠1935；
2）、RTMPT封裝在HTTP請求之中，可穿越防火牆；
3）、RTMPS類似RTMPT，但使用的是HTTPS連接；
RTMP協議是被Flash用於對象、視頻、音頻的傳輸。這個協議建立在TCP協議或者輪詢HTTP協議之上。RTMP協議就像一個用來裝數據包的容器，這些數據既可以是AMF格式的數據，也可以是FLV中的視音頻數據。一個單一的連接可以通過不同的通道傳輸多路網路流，這些通道中的包都是按照固定大小的包傳輸的。
2、RTSP(Real Time Streaming Protocol，實時流傳輸協議)
RTSP定義了一對多應用程序如何有效地通過IP網路傳送多媒體數據。RTSP提供了一個可擴展框架，數據源可以包括實時數據與已有的存儲的數據。該協議目的在於控制多個數據發送連接，為選擇發送通道如UDP、組播UDP與TCP提供途徑，並為選擇基於RTP上發送機制提供方法。
RTSP語法和運作跟HTTP/1.1類似，但並不特別強調時間同步，所以比較能容忍網路延遲。代理伺服器的緩存功能也同樣適用於RTSP，並且因為RTSP具有重新導向功能，可根據實際負載情況來切換提供服務的伺服器，以避免過大的負載集中於同一伺服器而造成延遲。
3、RTP(Real-time Transport Protocol，實時傳輸協議)
RTP是針對多媒體數據流的一種傳輸層協議，詳細說明了在互聯網上傳遞音頻和視頻的標准數據包格式。RTP協議常用於流媒體系統（配合RTCP協議），視頻會議和一鍵通系統（配合H.323或SIP），使它成為IP電話產業的技術基礎。
RTP是建立在UDP協議上的，常與RTCP一起使用，其本身並沒有提供按時發送機制或其它服務質量（QoS）保證，它依賴於低層服務去實現這一過程。
RTP 並不保證傳送或防止無序傳送，也不確定底層網路的可靠性，只管發送，不管傳輸是否丟包，也不管接收方是否有收到包。RTP 實行有序傳送，RTP中的序列號允許接收方重組發送方的包序列，同時序列號也能用於決定適當的包位置，如在視頻解碼中，就不需要順序解碼。
4、RTCP(Real-time Transport Control Protocol，實時傳輸控制協議）
RTCP是RTP的配套協議，為RTP媒體流提供信道外的控制。RTCP和RTP一起協作將多媒體數據打包和發送，定期在多媒體流會話參與者之間傳輸控制數據。
RTCP的主要功能是為RTP所提供的服務質量（QoS）提供反饋，收集相關媒體連接的統計信息，例如傳輸位元組數，傳輸分組數，丟失分組數，單向和雙向網路延遲等等。網路應用程序可以利用RTCP所提供的信息來提高服務質量，比如限制流量或改用壓縮比小的編解碼器。
E. android gpuimage 怎麼使用
GPUImage 是iOS下一個開源的基於GPU的圖像處理庫，提供各種各樣的圖像處理濾鏡，並且支持照相機和攝像機的實時濾鏡。GPUImage for Android是它在Android下的實現，同樣也是開源的，託管在Github上。
版本：android-gpuimage-1.1.1
Android模擬器上不支持OpenGL ES 2.0所以會報錯，可以選用Genymotion測試，或真機上運行。
引用
Caused by: java.lang.IllegalStateException: OpenGL ES 2.0 is not supported on this phone.
(1)使用自定義的ImageView
Xml代碼
<jp.co.cyberagent.android.gpuimage.GPUImageView
android:id="@+id/gpuimage"
android:layout_width="wrap_content"
android:layout_height="0dp"
android:layout_gravity="center"
android:layout_weight="1" />
Java代碼
mImageView.setFilter(new GPUImageSepiaFilter()); // sepia
mImageView.setFilter(new GPUImageGrayscaleFilter()); // gray
mImageView.setFilter(new GPUImageSharpenFilter()); // sharp
mImageView.setFilter(new GPUImageSobelEdgeDetection()); // edge
F. 最簡單的iOS直播推流如何使用GPUImage，如何美顏
視頻直播，可以分為 採集，前處理，編碼，傳輸，解碼，渲染 這幾個環節，下面分別說下： 採集，iOS是比較簡單的，Android則要做些機型適配工作，PC最麻煩各種奇葩攝像頭驅動，出了問題特別不好處理，建議放棄PC只支持手機主播，目前幾個新進的直播平台都是這樣的。 前處理，現在直播美顏已經是標配了，80%的主播沒有美顏根本沒法看。美顏演算法需要用到GPU編程，需要懂圖像處理演算法的人，沒有好的開源實現，要自己參考論文去研究。難點不在於美顏效果，而在於GPU佔用和美顏效果之間找平衡。GPU雖然性能好，但是也是有功耗的，GPU佔用太高會導致手機發燙，而手機發燙會導致攝像頭採集掉幀，iPhone6尤其明顯，因為iPhone6的CPU和前置攝像頭很近。 編碼，肯定要採用硬編碼，軟編碼720p完全沒希望，勉強能編碼也會導致CPU過熱燙到攝像頭。硬編碼兼容性又是一個大坑，android上要有人去填。編碼要在解析度，幀率，碼率，GOP等參數設計上找到最佳平衡點。 傳輸，自己做不現實，交給CDN服務商吧，也就是貴了點，相信有志於做直播平台改變世界的你不差錢。假設2W PCU大約每月帶寬費用100萬左右，因為清晰流暢的720p要1.5mbps左右。CDN只提供了帶寬和伺服器間傳輸，發送和接收端的網路連接抖動緩沖還是要自己寫的。不想要卡頓，必然要加大緩沖，會導致延遲高，延遲高影響互動性，要做權衡。 解碼，也肯定要硬解碼，目前手機普遍支持硬解了，只是android上還是有兼容性大坑要填。 渲染，這個難點不在於繪制，而在於音畫同步，目前幾個直播做得都不好。 此外音頻還有幾個坑要填，比如降噪，音頻編碼器的選擇，各種藍牙耳機，各種播放模式的適配等，如果你想做主播和觀眾連線聊天，還有個回聲消除問題。 以上是媒體模塊，還有信令控制，登錄、鑒權、許可權管理、狀態管理等等，各種應用服務，消息推送，聊天，禮物系統，支付系統，運營支持系統，統計系統等。 後台還有資料庫，緩存，分布式文件存儲，消息隊列，運維系統等。 第一期至少要融資2000萬RMB，組建至少10人的技術團隊，10人的產品運營團隊，爭取3個月產品上線，半年達到5W在線（2w 根本不夠）然後融資1個億，或許還有希望一搏。 這些對於創業者來說是一個難度系數非常大，創業初期還是建議接入第三方的直播SDK，可以節省成本，趣拍直播還是很不錯的，不管是轉碼還是推流，支持1000多萬人在線不卡頓，可以去了解下。 祝你朋友好運。
G. GpuImage 在Android 上的應用以及各種效果參照表
在布局中加上GPUImageView,為了顯示處理後的圖片載體
2：獲取對應想要處理的效果Filter
3:通過Filter設置想要的效果展示出來
圖片有點小，湊合著看吧
最後附上Android 最全的效果對應工具類：
項目github地址
H. IOS錄制的視頻在Android播放異常的問題
IOS使用GPUImage錄制的視頻默認是mov格式，如果直接轉化為mp4，其實裡面的文件編碼還是mov，mov在Android上使用系統播放器表現為有視頻沒有音頻，或者直接無法播放。
如果ios要和android同步上線，需要ios支持，轉化為標準的mp4文件。這樣android不僅能支持播放，還可以保存到相冊讓系統播放器播放。通過ffmpeg來編碼是一種選擇。
- 在iOS中使用FFmpeg命令
I. 怎麼在github上開源ios代碼
1. AFNetworking 在眾多iOS開源項目中，AFNetworking可以稱得上是最受開發者歡迎的庫項目。AFNetworking是一個輕量級的iOS、Mac OS X網路通信類庫，現在是GitHub上第三大Objective-C庫。它建立在NSURLConnection、NSOperation等類庫的基礎上，讓很多網路通信功能的實現變得十分簡單，因此，許多iOS應用開發都會使用到它。 支持HTTP請求和基於REST的網路服務(包括GET、POST、PUT、DELETE等); 支持ARC; 要求iOS 5.0及以上版本; 有一些插件擴展已有的功能，還有一個功能齊全的API; 從URL中獲取JSON特別簡單。 2. Three20 Three20原本是iPhone版Facebook中所使用的工具庫，包括照片查看器等一系列的iPhone UI類集，以及HTTP磁碟緩存等一些通用工具。後來從Facebook iPhone應用中剝離出來，成為了一個深受開發者喜愛的通用框架。 3. facebook-ios-sdk 此前在“GitHub上最受歡迎的開源項目”Android系列文章(一)中，我們曾介紹過允許開發者將Facebook集成到Android應用中的Facebook SDK for Android。Facebook SDK for iOS和它一樣，可以讓開發者將Facebook相關功能集成到自己的iOS App中。 Facebook無疑是最成功的SNS社區，如果能夠讓App具有與Facebook集成的功能，那勢必會帶來非常好的效果。Facebook SDK for iOS項目更新頻率很高，想要獲取更多關於示例、文檔、將SDK集成到App中、源代碼等信息，可直接登陸Facebook Developers查看。 4. RestKit Restkit是一個主要用於iOS上網路通信的開源Objective-C框架，除了發送請求、接受響應這些基本功能外，還附帶Core Data，以及將遠程JSON映射為本地對象的功能。 主要特點： 可在iOS和Mac OS X的Objective-C中與RESTful Web服務進行簡單交互; 包含簡單的HTTP Request/Response API; 帶有強大的對象映射系統，用於減少代碼長度; RestKit可降低JSON/XML的處理的資源消耗，支持通過SBJSON和YAJL進行JSON解析。 5. asi-http-request ASIHTTPRequest是一款極其強勁的HTTP訪問開源項目，能夠讓簡單的API完成非常復雜的功能，比如非同步請求、隊列請求、GZIP壓縮、緩存、斷點續傳、進度跟蹤、上傳文件、HTTP認證。 ASIHTTPRequest適用於基本的HTTP請求，和基於REST的服務之間的交互。使用Objective-C編寫，能夠同時用於Mac OS X和iPhone應用中。 6. cocos2d-x 在《GitHub上最火的40個Android開源項目(一)》中，我們已經非常詳細地介紹了cocos2d-x開源項目。cocos2d-x支持iOS、Android、Windows Phone 8、Bada、BlackBerry、Marmalade、Windows、Linux等多個平台。 7.cocos2d-iphone(cocos2d) cocos2d for iPhone是一個開源框架，用於為iPod Touch、iPhone、iPad及Mac OS X構建2D游戲、演示程序及其他圖形互動式應用。基於cocos2d設計，使用相同的API，但不同於cocos2d使用Python，cocos2d for iPhone是使用Objective-C實現的。 cocos2d for iPhone主要特性： 快 免費 易於使用 社區支持 8.cocos2d-iphone(jpsarda) 該項目是對cocos2d for iPhone的擴展。 9. GPUImage GPUImage是一個基於GPU圖像和視頻處理的開源iOS框架。 主要功能如下： 提供各種各樣的圖像處理濾鏡，並且支持照相機和攝像機的實時濾鏡; GPUImage顧名思義，是基於GPU的圖像加速，因此圖像處理速度非常快，並且能夠自定義圖像濾鏡; 支持ARC。 10. MonoGame MonoGame是一個Microsoft XNA 4.x Framework的開源跨平台實現。此前在Android開源項目系列文章(一)中我們也進行了詳細的介紹。 MonoGame支持平台： iOS(包括Ritina Display) Android Windows(OpenGL) Mac OS X Linux Windows Store Apps(Windows 8、Windows RT) Windows Phone 8 PlayStation Mobile(目前僅支持2D) OUYA 11. Nimbus Nimbus是一個開源的iOS框架，比起Three20，Nimbus的文檔更為全面、豐富，能夠實現很多非常炫的界面特效。因此，開發者可以藉助Nimbus來降低項目設計的復雜度。 12. cheddar-ios Cheddar是一個簡單即時的任務管理器，Cheddar for iOS是Cheddar的iOS客戶端，通用於iPhone和iPad。 13. ViewDeck IIViewDeckController能夠實現類似於Path 2.0 的視圖左右滑動的效果，支持向左或向右順滑的滑動操作。 14. ShareKit ShareKit是iPhone開發的第三方介面，允許你一鍵分享文字、圖片、網址、文件等內容到Facebook、Twitter、Delicious、Tumblr、Google Reader等第三方網站上。 15. GMGridView GMGridView是一款開源的iOS(iPhone/iPad)表格視圖，允許用戶手勢對表格單元進行排序，在單元格需要展示時才進行裝載，這樣極大地提高了表格的效率。其中的伸縮/旋轉/平移手勢能夠讓用戶改變視圖，還能夠實現從CellView到全屏的切換。 16. QuickDialog QuickDialog可以幫助開發者快速創建復雜的表單，實現包括登錄界面在內的各種樣式的TableView輸入界面，此外，還可以創建帶有多個文本域的表格及項目。 17. appirater Appirater是一個可以直接使用到任何iPhone應用(iOS4.0及以上)中的開源類，用於提醒用戶在打開App時，對應用進行或打分。 18. SVProgressHUD SVProgressHUD能夠實現多種HUD效果，多用於程序正在執行耗時較長的任務，需要用戶等待。除了顯示等待的HUD，還可以顯示命令執行成功或者失敗的HUD。 19. Reader 該項目能夠讓iOS開發者輕而易舉地在iOS設備屏幕上顯示PDF文件。代碼通用，不需要任何XIB(因為所有UI元素都是代碼生成的，具有極大的靈活性)，運行於iOS 4.0及其以上版本設備中，同時還支持所有Retina Display設備。 支持： 諸如iBooks等的文檔導航; 設備全方位旋轉; 對PDF進行加密(密碼保護); PDF鏈接(URI及跳轉頁面); PDF旋轉頁面。 20.CocoaAsyncSocket CocoaAsyncSocket提供了十分強大而又易用的Mac OS X及iOS非同步套接庫，支持TCP和UDP，其中，AsyncSocket類是支持TCP的，AsyncUdpSocket是支持UDP的。 AsyncSocket是封裝了CFSocket和CFSteam的TCP/IP socket網路庫，提供非同步操作。AsyncUdpSocket是UDP/IP socket網路庫，包裝自CFSocket。
J. 如何快速搭建一個完整的移動直播系統
移動直播行業的火熱會在很長一段時間內持續，通過和各行業的整合，從而成為具有無限可能性的行業。主要因為以下三個原因：
第一，移動直播的UGC生產模式比PC端的直播更明顯，人人都有設備，隨時隨地開播，完全順應了互聯網時代的開放性原則，能刺激更多人去創造和傳播優質內容。
第二，網路帶寬和速度在逐漸提高，網路成本在逐漸下降，為移動直播提供一個極佳的發展環境。文字、聲音、視頻、游戲等都會在移動直播中呈現，創造出更加豐富的用戶體驗。直播可以以SDK的形式接入到自己的應用中，比如，教育領域中的課後輔導完全可以以直播的形式開展業務、電商也可藉助直播讓用戶挑選商品，促進銷售。
第三，一個與VR/AR技術相結合的移動直播為整個行業的未來提供了新的發展空間。VR/AR直播能夠讓用戶身臨其境，帶動主播與觀眾更貼切真實的互動，大大提高平台的用戶參與度。
當下，有技術實力和流量優勢的互聯網從業者都不願錯過直播這個風口，如何快速搭建一個直播系統成了大家關心的問題，我想和大家分享下我的經驗。我從事於一家直播產品開發商，我們的產品為了快速趕上市場，並沒有自己完全去自己做，而是使用了趣拍雲服務提供的直播SDK。
從業者都知道，一個完整直播產品應該包含以下環節：推流端（採集、前處理、編碼、推流），服務端處理（轉碼、錄制、截圖、鑒黃），播放器（拉流、解碼、渲染）、互動系統（聊天室、禮物系統、贊）。 下面我就一一講述下直播SDK在各個環節所做的工作。
一、移動直播推流端需要做哪些工作？
直播推流端即主播端，主要通過手機攝像頭採集視頻數據和麥克風採集音頻數據，經過一系列前處理、編碼、封裝，然後推流到CDN進行分發。
1、採集
移動直播SDK通過手機攝像頭和麥克風直接採集音視頻數據。其中，視頻采樣數據一般採用RGB或YUV格式、音頻采樣數據一般採用PCM格式。採集到的原始音視頻的體積是非常大的，需要經過壓縮技術處理來提高傳輸效率。
2、前處理
在這個環節主要處理美顏、水印、模糊等效果。美顏功能幾乎是直播的標配功能。我們調研中發現太多case是因為沒有美顏功能被拋棄使用的。另外國家明確提出了，所有直播都必須打有水印並回放留存15天以上。
美顏實際上是通過演算法去識別圖像中的皮膚部分，對皮膚區域進行色值調整。通過顏色對比找到皮膚區域，可以進行色值調整、添加白色圖層或調整透明度等來等來達到美白效果。在美顏處理方面，最著名的GPUImage提供了豐富的效果，同時可以支持iOS和Android，支持自己寫演算法實現自己最理性的效果。GPUImage內置了120多種常見濾鏡效果，添加濾鏡只需要簡單調用幾行代碼就可以了。
3、編碼
為了便於手機視頻的推流、拉流以及存儲，通常採用視頻編碼壓縮技術來減少視頻的體積，現在比較常用的視頻編碼是H.264。在音頻方面，比較常用的是用AAC編碼格式，其它如MP3、WMA也是可選方案。視頻經過編碼壓縮大大提高了視頻的存儲和傳輸效率，當然，經過壓縮後的視頻在播放時必須進行解碼。
相較於之前的H.264，2012年誕生的H.265編解碼標准有了相當大的改善，做到了僅需要原來一半帶寬即可播放相同質量的視頻，低於1.5Mbps的網路也能傳輸1080p的高清視頻。像阿里雲、金山雲都在推自己的H.265編解碼技術，隨著直播的快速發展和對帶寬的依賴，H.265編解碼技術已有全面取代H.264的趨勢。
H264和H265個模塊技術差異：
另外，硬體編碼已經成為移動直播的首選方案，軟編碼處理在720p以上的視頻頹勢非常明顯。在iOS平台上硬體編碼的兼容性比較好，可以直接採用，但在 Android 平台上，MediaCodec 編碼器針對不同的晶元平台表現差異還是非常大的，要完全實現全平台兼容的成本還是非常高的。
4、推流
要想用於推流還必須把音視頻數據使用傳輸協議進行封裝，變成流數據。常用的流傳輸協議有RTSP、RTMP、HLS等，使用RTMP傳輸的延時通常在1–3秒，對於移動直播這種實時性要求非常高的場景，RTMP也成為移動直播中最常用的流傳輸協議。最後通過一定的Qos演算法將音視頻流數據推送到網路斷，通過CDN進行分發。在直播場景中，網路不穩定是非常常見的，這時就需要Qos來保證網路不穩情況下的用戶觀看直播的體驗，通常是通過主播端和播放端設置緩存，讓碼率均勻。另外，針對實時變化的網路狀況，動態碼率和幀率也是最常用的策略。
當然，在網路傳輸方面全部自己來做基本不現實，找提供推流服務的CDN服務商提供解決方案是最好的選擇，可參考文章開頭介紹的雲視頻服務商。據了解，阿里雲是國內唯一能自研CDN緩存伺服器的廠商，性能非常有保障。當然，大多數直播平台都會同時接入多個視頻雲服務提供商，這樣可以做拉流線路互備，對推流後視頻集群再進行優化也可提高直播的流暢性和穩定性。
二、服務端處理需要做哪些工作？
要想適配各終端和平台，服務端還需要對流進行轉碼，如支持RTMP、HLS、FLV等格式拉流，支持一路轉多路適配不同網路和解析度的終端設備。
1、截圖、錄制、水印
像阿里雲等雲服務商都提供了實時轉碼技術，將用戶推流碼率較高（比如720P）實時轉化成較低清晰度（比如360P）的流以適應播放端的需求。如果要自己搭建實時轉碼系統，這個成本是極高的，一台8核設備只能實時轉10路流，如果一個正常的直播平台有1000路流，就需要100台設備，加上後期的運維成本，一般公司就吃不消了。
2、鑒黃
2016年4月14日，文化部查出了斗魚、虎牙、YY、熊貓TV、六間房、9158等涉嫌提供含宣揚淫穢、暴力、教唆犯罪的網路直播平台，被列入查處名單。政府介入管制有利於直播行業打造健康的生態，進入良性發展。這也意味著為了安全直播產品鑒黃成了必需環節，使用技術手段去鑒黃是移動直播平台必然採用的方案。
市面上提供鑒黃服務的方案主要有兩種，第一種是對視頻進行截圖，然後對圖片進行鑒黃，返回鑒黃結果和分值。典型的企業有阿里（綠網）、圖譜科技，他們目前都支持直接傳入視頻，經過服務端分析返回結果。通常由業務系統接入鑒黃服務，根據鑒黃結果對直播流進行控制，如切斷直播流、封禁賬號等。第二種是和CDN結合，直接對直播流進行分析，識別結果分為色情、疑似色情、性感和正常，業務系統根據識別結果直接控制直播流。典型的企業是Viscovery，這套方案的優點是實時性保證比較好，缺點是必須部署到CDN或自己的機房，使用成本相對高一些。
還有像趣拍雲服務這種一站式直播解決方案提供商，他們的做法是，用戶只需在控制台對鑒黃服務進行配置就可以針對每個應用、每一路直播流進行實時審核。在控制台中，趣拍視頻雲服務實時將鑒黃結果返回，用戶可以直接查看色情直播和違規界面的截圖，同時可以對直播流進行控制，切斷問題直播流。該服務商還提供了簡訊、郵件和站內信功能，避免漏掉任何一個非法視頻，給平台造成損失，我們就使用了這種方式。
三、播放器端需要做哪些工作？
在播放器端如何做到秒開，直播過程中保證畫面和聲音清晰度的同時，穩定、流程、無卡頓的直播流量，這些工作都需要播放器端配合服務端來做優化，做到精確調度。
1、拉流
拉流實際是推流的逆過程。首先通過播放端獲取碼流，標準的拉流格式有RTMP、HLS、FLV等。RTMP是Adobe的專利協議，開源軟體和開源庫都支持的比較好，如開源的librtmp庫，播放端只要支持flashPlayer的就能非常簡單的播放RTMP直播，直播延遲一般在1–3秒。HLS是蘋果提出的基於HTTP的流媒體傳輸協議，HTML5可以直接打開播放，通過微信、QQ等軟體分享出去，用戶也可以直接觀看直播，可以說移動直播app，HLS拉流協議是必須支持的，缺點是延遲通常大於10秒。FLV（HTTP-FLV）協議是使用HTTP協議傳輸流媒體內容的一個協議，也不用擔心被Adobe的專利綁架，直播延遲同樣可以做到1–3秒。
各拉流協議的差異：
我們使用的趣拍視頻雲服務的直播拉流技術提供了以上三種格式，滿足不同業務場景的需求，如對即時性要求較高或有互動需求的可以採用RTMP或FLV格式進行直播拉流播放；對於有回放或跨平台需求的，推薦使用HLS。當然，三種協議是可以同時使用的，分別用到自己的場景就可以了。
2、解碼和渲染
拉流獲取封裝的視頻數據後，必須通過解碼器解碼、渲染後才能在播放器上播放。它是編碼的逆過程，是指從音視頻的數據中提取原始數據。前面介紹的H.264和H.265編碼格式都是有損壓縮，所以在提取後的原始數據，並非原始采樣數據，存在一定的信息丟失。因此，在視頻體積最小的情況下通過各種編碼參數保留最好的原始畫面，成為了各視頻公司的核心機密。
考慮對高清的支持，解碼肯定還是要選擇硬解碼的。前面介紹過，iOS系統由於硬體比較單一、比較封閉，支持的比較好，Android系統由於平台差異非常大，編解碼要完全兼容各平台還需要很多工作要做。
四、移動直播中的交互系統
移動直播中最常見的交互有聊天室（彈幕）、點贊、打賞和禮物等，交互系統涉及消息的實時性和互動性，在技術實現上大多是使用IM的功能來實現的。對於在線人數比較多的房間，彈幕消息量是非常大，主播與用戶其實都看不過來，為了緩解伺服器壓力，在產品策略需要做一些必要的優化。
1、聊天室
移動直播中的彈幕交互是用戶和主播互動的主要方式，實際上就是IM中的聊天室功能。聊天室和群聊功能類似，但聊天室的消息是不需要分發給不在線的用戶的，歷史消息也不需要查看，用戶只有進入聊天室後才能查看聊天消息和群成員信息。面對復雜多變的網路狀況，還需要根據用戶位置就近選擇近對應運營商的單線機房接入彈幕消息服務，讓彈幕更及時。
2、禮物系統
禮物系統更是絕大多數移動直播平台的標配了，它是這些平台主要的收入來源。送禮物的形式也增強了用戶和主播之間的互動交流，也是主播依賴平台的最主要原因。
禮物的收發在技術實現上也是用聊天室介面做的，通常採用IM中的自定義消息實現，當用戶收到或發送禮物時將自定義消息對應的禮物圖形渲染出來。
以上就是我們在使用了第三方SDK服務後總結出來的直播產品經驗，希望能幫助到創業者和從業者們。
蔣先生（微信號love-drunk-hard），直播行業老兵。