鬥魚，熊貓APP 這類APP用到了哪些視頻，音頻方面的框架和技術？

01-11

鬥魚，熊貓APP 這類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所提供的信息來提高服務質量，比如限制流量或改用壓縮比小的編解碼器。

四、利益相關

我們團隊是做直播技術的，底層架構都是做好的，開放給開發者sdk和api介面，開發者接入後就可以實現直播的功能。歡迎相互交流學習。我的qq3103607948

我最近在做直播項目，參考的是映客我們用的是rtmp協議 flv格式用ffmpeg進行視頻解碼，用fdk進行音頻解碼。。。。然後用open gl播放視頻伺服器用的阿里雲的。。

GitHub - Bilibili/ijkplayer: Android/iOS video player based on FFmpeg n2.8, with MediaCodec, VideoToolbox support.

還有google的exoplayer

GitHub - google/ExoPlayer: An extensible media player for Android

GitHub - brianwernick/ExoMedia: An Android ExoPlayer wrapper to simplify Audio and Video implementations

可以看看。

如果是CodeC，ffmpeg是主流的（最新官網已經是3.5了），VLC也是不錯的，openMax，Google依然在用
對於協議：網易專家已經說的很詳細了，
直播最主要就是推流和拉流，流文件封裝容器有很多，TS、MKV、AVI、MP4，直播中m3u8和f4v用的多些
Android原生音視頻框架學習，可以瞅瞅：專欄：MultiMedia框架總結(基於6.0源碼) - 博客頻道 - CSDN.NET

當然是ffmpeg解碼，不用懷疑，流協議用的是httpcdn主線路和rtmp備用。

我反編譯過鬥魚的APP ，用的是B站開源的ijkMediaPlayer 和Danmaku，自己封裝的DYView，然後連亮度調節功能都沒做……傳輸協議無非就是RTP/RTSP/RTCP/HLS 等傳輸協議了，然後寫個緩衝就實現了拉流端和推流端，沒太多技術難點，核心還是伺服器。

可以看b站的github項目，針對ffmpeg視頻解碼的代碼，完整的解決方案。

Android 下的軟硬體編解碼會用到Openmax框架

編解碼這塊基本都是ffmpeg，視頻流協議這塊，rtp，hls也都是比較常見的。