視頻編解碼和流媒體協(xié)議

1、RTP參考文檔RFC3550/RFC3551Real-timeTransportProtocol)是用于Internet上針對多媒體數(shù)據(jù)流的一種傳輸層協(xié)議。RTP議詳細說明了在互聯(lián)網(wǎng)上傳遞音頻和視頻的標準數(shù)據(jù)包格式。RTPi辦議常用于流媒體系統(tǒng)（配合RTCPW議），視頻會議和一鍵通（PushtoTalk）系統(tǒng)（配合H.323或SIP）,使它成為IP電話產(chǎn)業(yè)的技術基礎。RTP協(xié)議和RTP控制協(xié)議RTC屋起使用，而且它是建立在UDPB議上的。RTP本身并沒有提供按時發(fā)送機制或其它服務質量（QoS保證，它依賴于低層服務去實現(xiàn)這一過程。RTP并不保證傳送或防止無序傳送，也不確定底層網(wǎng)絡的可靠性。RTP

2、實行有序傳送，RTP中的序列號允許接收方重組發(fā)送方的包序列，同時序列號也能用于決定適當?shù)陌恢?，例如：在視頻解碼中，就不需要順序解碼。RTP由兩個緊密鏈接部分組成：RTP一傳送具有實時屬性的數(shù)據(jù)；RTP控制協(xié)議（RTCP一監(jiān)控服務質量并傳送正在進行的會話參與者的相關信息。RTCP實時傳輸控制協(xié)議（Real-timeTransportControlProtocol或RTPControlProtocol或簡寫RTCP是實時傳輸協(xié)議（RTB的一個姐妹協(xié)議。RTCPRTP媒體流提供信道外（out-of-band）控制。RTCF身并不傳輸數(shù)據(jù)，但和RT屋起協(xié)作將多媒體數(shù)據(jù)打包和發(fā)送。RTCP定期在流多媒

3、體會話參加者之間傳輸控制數(shù)據(jù)。RTCP勺主要功能是為RTP所提供的服務質量（QualityofService）提供反饋。RTCP收集相關媒體連接的統(tǒng)計信息，例如：傳輸字節(jié)數(shù)，傳輸分組數(shù)，丟失分組數(shù)，jitter,單向和雙向網(wǎng)絡延遲等等。網(wǎng)絡應用程序可以利用RTCP所提供的信息試圖提高服務質量，比如限制信息流量或改用壓縮比較小的編解碼器。RTCW身不提供數(shù)據(jù)加密或身份認證。SRTCPT以用于此類用途。SRTP&SRTCP參考文檔RFC3711安全實時傳輸協(xié)議（SecureReal-timeTransportProtocol或SRTP是在實時傳輸協(xié)議（Real-timeTransportProto

4、col或RTP）基礎上所定義的一個協(xié)議，旨在為單播和多播應用程序中的實時傳輸協(xié)議的數(shù)據(jù)提供加密、消息認證、完整性保證和重放保護。它是由DavidOran（思科）和RolfBlom（愛立信）開發(fā)的，并最早由IETF于2004年3月作為RFC3711發(fā)布。由于實時傳輸協(xié)議和可以被用來控制實時傳輸協(xié)議的會話的實時傳輸控制協(xié)議(RTPControlProtocol或RTCP有著緊密的聯(lián)系，安全實時傳輸協(xié)議同樣也有一個伴生協(xié)議，它被稱為安全實時傳輸控制協(xié)議(SecureRTCP或SRTCP;安全實時傳輸控制協(xié)議為實時傳輸控制協(xié)議提供類似的與安全有關的特性，就像安全實時傳輸協(xié)議為實時傳輸協(xié)議提供的那些一樣

5、。在使用實時傳輸協(xié)議或實時傳輸控制協(xié)議時，使不使用安全實時傳輸協(xié)議或安全實時傳輸控制協(xié)議是可選的；但即使使用了安全實時傳輸協(xié)議或安全實時傳輸控制協(xié)議，所有它們提供的特性(如加密和認證)也都是可選的，這些特性可以被獨立地使用或禁用。唯一的例外是在使用安全實時傳輸控制協(xié)議時，必須要用到其消息認證特性。RTSP參考文檔RFC2326是由RealNetworks和Netscape共同提出的。該協(xié)議定義了一對多應用程序如何有效地通過IP網(wǎng)絡傳送多媒體數(shù)據(jù)。RTS%供了一個可擴展框架，使實時數(shù)據(jù)，如音頻與視頻的受控、點播成為可能。數(shù)據(jù)源包括現(xiàn)場數(shù)據(jù)與存儲在剪輯中的數(shù)據(jù)。該協(xié)議目的在于控制多個數(shù)據(jù)發(fā)送連接，

6、為選擇發(fā)送通道，如UDP多播UD叫TCP提供途徑，并為選擇基于RTP上發(fā)送機制提供方法。RTSP(RealTimeStreamingProtocol)是用來控制聲音或影像的多媒體串流協(xié)議，并允許同時多個串流需求控制，傳輸時所用的網(wǎng)絡通訊協(xié)定并不在其定義的范圍內，服務器端可以自行選擇使用TCP或UDP來傳送串流內容，它的語法和運作跟HTTP1.1類似,但并不特別強調時間同步，所以比較能容忍網(wǎng)絡延遲。而前面提到的允許同時多個串流需求控制(Multicast),除了可以降低服務器端的網(wǎng)絡用量，更進而支持多方視訊會議(VideoConference)。因為與HTTP1.1的運作方式相似，所以代理服務器

7、Proxy的快取功能Cache也同樣適用于RTSP并因RTSPM有重新導向功能，可視實際負載情況來轉換提供服務的服務器，以避免過大的負載集中于同一服務器而造成延遲。RTSP和RTP的關系RTP不象http和即可完整的下載整個影視文件，它是以固定的數(shù)據(jù)率在網(wǎng)絡上發(fā)送數(shù)據(jù)，客戶端也是按照這種速度觀看影視文件，當影視畫面播放過后，就不可以再重復播放，除非重新向服務器端要求數(shù)據(jù)。RTSP與RTPM大的區(qū)另1J在于：RTS幅一種雙向實時數(shù)據(jù)傳輸協(xié)議，它允許客戶端向服務器端發(fā)送請求，如回放、快進、倒退等操作。當然，RTSP可基于RTP來傳送數(shù)據(jù)，還可以選擇TCRUDR組播UD商通道來發(fā)送數(shù)據(jù)，具有很好的擴

8、展性。它時一種類似與http協(xié)議的網(wǎng)絡應用層協(xié)議。目前碰到的一個應用：服務器端實時采集、編碼并發(fā)送兩路視頻，客戶端接收并顯示兩路視頻。由于客戶端不必對視頻數(shù)據(jù)做任何回放、倒退等操作，可直接采用UDP+RT圖播實現(xiàn)。應用層CRTSP)RTF(RtCP)TCP傳輸層UDP網(wǎng)絡層(IP,RSVP)數(shù)據(jù)鏈路層物理層藪據(jù)由RTP傳輸視頻質值由RTCP控制 (RSVP)視頻控制由RTSPN是供CUUJ.comRTP實時傳協(xié)議(Real-timeTransportProtocol)RTP/RTC厚實際傳輸數(shù)據(jù)的協(xié)議RTP傳輸音頻/視頻數(shù)據(jù)，如果是PLAYServer發(fā)送到Client端，如果是RECORD可

9、以由Client發(fā)送到Server整個RTP協(xié)議由兩個密切相關的部分組成：RTP數(shù)據(jù)協(xié)議和RTP控制協(xié)議（即RTCPRTSP實時流協(xié)議（RealTimeStreamingProtocol,RTSPRTSP的請求主要有DESCRIBE,SETUP,PLAY,PAUSE,TEARDOWN,OPTIONS顧名思義可以知道起對話和控制作用RTSP的對話過程中SETU網(wǎng)以確定RTP/RTC咂用的端口,PLAY/PAUSE/TEARDOWNA開始或者停止RTP的發(fā)送，等等RTCPRTP/RTC厚實際傳輸數(shù)據(jù)的協(xié)議RTCPtSenderReport和ReceiverReport,用來進行音頻/視頻的同步以及

10、其他用途，是一種控制協(xié)議SDP會話描述協(xié)議（SDP為會話通知、會話邀請和其它形式的多媒體會話初始化等目的提供了多媒體會話描述。會話目錄用于協(xié)助多媒體會議的通告，并為會話參與者傳送相關設置信息。SDP即用于將這種信息傳輸?shù)浇邮斩?。SDP完全是一種會話描述格式一它不屬于傳輸協(xié)議一它只使用不同的適當?shù)膫鬏攨f(xié)議，包括會話通知協(xié)議（SAB、會話初始協(xié)議（SIP）、實時流協(xié)議（RTSP、MIME擴展協(xié)議的電子郵件以及超文本傳輸協(xié)議（HTTB。SDP的設計宗旨是通用性，它可以應用于大范圍的網(wǎng)絡環(huán)境和應用程序，而不僅僅局限于組播會話目錄，但SDP不支持會話內容或媒體編碼的協(xié)商。在因特網(wǎng)組播骨干網(wǎng)（Mbone）

11、中，會話目錄工具被用于通告多媒體會議，并為參與者傳送會議地址和參與者所需的會議特定工具信息，這由SDP完成。SDP連接好會話后，傳送足夠的信息J合會話參與者。SDP信息發(fā)送利用了會話通知協(xié)議（SAB,它周期性地組播通知數(shù)據(jù)包到已知組播地址和端口處。這些信息是UDP數(shù)據(jù)包，其中包含SAP協(xié)議頭和文本有效載荷（textpayload）。這里文本有效載荷指的是SDP會話描述。此外信息也可以通過電子郵件或WWW（WorldWideWeb）進行發(fā)送。SDP文本信息包括：會話名稱和意圖;會話持續(xù)時間；構成會話的媒體；有關接收媒體的信息（地址等）。協(xié)議結構SDP信息是文本信息，采用UTF-8編碼中的ISO1

12、0646字符集。SDP會話描述如下：（標注*符號的表示可選字段）：v=（協(xié)議版本）o=（所有者/創(chuàng)建者和會話標識符）s二（會話名稱）i=*（會話信息）u=*（URI描述）e=*EEmail地址）p=*（電話號碼）c=*（連接信息一如果包含在所有媒體中，則不需要該字段）b=*（帶寬信息）一個或更多時間描述（如下所示）：z=*（時間區(qū)域調整）k=*（加密密鑰）a=*（0個或多個會話屬性行）。個或多個媒體描述（如下所示）時間描述t=（會話活動時間）r=*（0或多次重復次數(shù)）媒體描述m=（媒體名稱和傳輸?shù)刂罚﹊=*（媒體標題）c=*（連接信息一如果包含在會話層則該字段可選）b=*（帶寬信息）k=*（加

13、密密鑰）a=*（0個或多個會話屬性行）RTMP/RTMPSRTMP(RealTimeMessagingProtocol)實時消息傳送協(xié)議是AdobeSystems公司為Flash播放器和服務器之間音頻、視頻和數(shù)據(jù)傳輸開發(fā)的開放協(xié)議。它有三種變種：1)工作在TCP之上的明文協(xié)議，使用端口1935;2)RTMPT封裝在HTTP1青求之中，可穿越防火墻；3)RTMP砥似RTMPT但使用的是HTTPS1接；RTMP協(xié)議(RealTimeMessagingProtocol)是被Flash用于對象，視頻，音頻的傳輸.這個協(xié)議建立在TCP協(xié)議或者輪詢HTTP協(xié)議之上.RTMPB議就像一個用來裝數(shù)據(jù)包的容器，

14、這些數(shù)據(jù)既可以是AMFB式的數(shù)據(jù)，也可以是FLV中的視/音頻數(shù)據(jù).一個單一的連接可以通過不同的通道傳輸多路網(wǎng)絡流.這些通道中的包都是按照固定大小的包傳輸?shù)?mmsMMS(MicrosoftMediaServerProtocol),中文“微軟媒體服務器協(xié)議”，用來訪問并流式接收WindowsMedia服務器中.asf文件的一種協(xié)議。MMS協(xié)議用于訪問WindowsMedia發(fā)布點上的單播內容。MMS是連接WindowsMedia單播服務的默認方法。若觀眾在WindowsMediaPlayer中鍵入一個URL以連接內容，而不是通過超級鏈接訪問內容，則他們必須使用MMS協(xié)議引用該流。MMS勺預設埠(

15、端口)是1755當使用MMS協(xié)議連接到發(fā)布點時，使用協(xié)議翻轉以獲得最佳連接?！皡f(xié)議翻轉”始于試圖通過MMSU連接客戶端。MMSU是MMS協(xié)議結合UDP數(shù)據(jù)傳送。如果MMSU連接不成功，則服務器試圖使用MMSTMMSTMMS協(xié)議結合TCP數(shù)據(jù)傳送。如果連接到編入索引的.asf文件，想要快進、后退、暫停、開始和停止流，則必須使用MMS不能用UNC路徑快進或后退。若您從獨立的WindowsMediaPlayer連接到發(fā)布點，則必須指定單播內容的URL。若內容在主發(fā)布點點播發(fā)布，則URL由服務器名和.asf文件名組成。例如：mms:/windows_media_server/sample.asf。其中

16、windows_media_server是WindowsMedia服務器名，sample.asf是您想要使之轉化為流的.asf文件名。若您有實時內容要通過廣播單播發(fā)布，則該URL由服務器名和發(fā)布點別名組成。例如：mms:/windows_media_server/LiveEvents。這里windows_media_server是WindowsMedia服務器名，而LiveEvents是發(fā)布點名HLSHTTPLiveStreaming(HLS)是蘋果公司(AppleInc.)實現(xiàn)的基于HTTP的流媒體傳輸協(xié)議，可實現(xiàn)流媒體的直播和點播，主要應用在iOS系統(tǒng)，為iOS設備(如iPhone、iPa

17、d)提供音視頻直播和點播方案。HLS點播，基本上就是常見的分段HTTP點播，不同在于，它的分段非常小。相對于常見的流媒體直播協(xié)議，例如RTM項、議、RTS的議、MMSJ、議等，HLS直播最大的不同在于，直播客戶端獲取到的，并不是一個完整的數(shù)據(jù)流。HLS協(xié)議在服務器端將直播數(shù)據(jù)流存儲為連續(xù)的、很短時長的媒體文件(MPEG-T骼式)，而客戶端則不斷的下載并播放這些小文件，因為服務器端總是會將最新的直播數(shù)據(jù)生成新的小文件，這樣客戶端只要不停的按順序播放從服務器獲取到的文件，就實現(xiàn)了直播。由此可見，基本上可以認為，HLS是以點播的技術方式來實現(xiàn)直播。由于數(shù)據(jù)通過HTTPtH傳輸，所以完全不用考慮防火墻

18、或者代理的問題，而且分段文件的時長很短，客戶端可以很快的選擇和切換碼率，以適應不同帶寬條件下的播放。不過HLS的這種技術特點，決定了它的延遲一般總是會高于普通的流媒體直播協(xié)議。根據(jù)以上的了解要實現(xiàn)HTTPLiveStreaming直播，需要研究并實現(xiàn)以下技術關鍵占八、采集視頻源和音頻源的數(shù)據(jù)對原始數(shù)據(jù)進行H264編碼和AAC編碼視頻和音頻數(shù)據(jù)封裝為MPEG-T典HLS分段生成策略及m3u8索引文件HTTP傳輸協(xié)議FFMPEG多媒體視頻處理工具FFmpeg有非常強大的功能包括視頻采集功能、視頻格式轉換、視頻抓圖、給視頻加水印等。H.264,同時也是MPEG-4第十部分，是由ITU-T視頻編碼專家組(VCEG)和ISO/IEC動態(tài)圖像專家組(MPEG)聯(lián)合組成的聯(lián)合視頻組(JVT,JointVideo