WebRTC提供了API，允許直接在客戶端捕獲視頻流，服務器則負責中繼和信號處理，確保NAT/防火墻穿透和點對點通信的穩定性。

總結：

linux 系統的 10 款最佳媒體服務器軟件

Linux系統不僅僅適合程序員和高級用戶，它同樣為藝術家、作家和音樂家等用戶群體提供很多非常棒的工具。 您可能聽說過媒體服務器，這類軟件或小工具的作用就是讓您能夠在直觀的界面中查看本地或云媒體（音樂、視頻等），甚至可以將內容直接串流傳輸到網絡的其它設備中。 下面將為大家介紹10款適用于Linux系統的最佳媒體服務器軟件，您可以根據自己的使用場景和需求，將其直接作為媒體播放器，或用作媒體服務器。 Kodi1. Kodi：這是最受用戶歡迎的媒體服務器和播放器軟件之一，Kodi 18.0進行了大量的改進，包括對數字版權管理（DRM）、游戲模擬器、ROM、語音控制等的支持。 2. PlexPlex：另一款令人印象深刻的媒體播放器，同時也可以作為Linux媒體服務器來使用。 與Kodi不同，Plex并非完全開源，但可以注冊免費用戶來使用。 3. JellyfinJellyfin：多功能開源媒體服務器軟件，實際上是Emby媒體服務器的一個分支。 4. LibreELECLibreELEC：有趣的媒體服務器軟件，基于Kodi v18.0。 5. OpenFLIXROpenFLIXR：自動媒體服務器軟件，可以與Plex集成，并支持通過Torrent自動下載電視節目和電影。 6. MediaPortalMediaPortal：開源的簡單媒體服務器軟件，具有良好的用戶界面。 7. GerberaGerbera：實現簡單，可以使用本地網絡進行流式傳輸，還支持轉碼功能。 8. OSMC（Open Source Media Center）Open Source Media Center：外觀優雅的媒體服務器軟件，基于Kodi媒體中心。 9. Universal Media ServerUniversal Media Server：不提供任何花哨功能，無需太多配置就可以幫助您轉碼/流式傳輸視頻和音頻。 10. Red5 Media ServerRed5 Media Server：為企業用戶量身定制的免費開源媒體服務器，可用于實時流媒體解決方案。

流媒體協議有哪些

問題一：流媒體用的是什么協議？流媒體的傳輸協議 大家在觀看網上電影或者電視時，一般都會注意到這些文件的連接都不是用或者ftp開頭，而是一些rtsp或者mms開頭的東西，為什么是這樣呢？實際上，這些和和ftp一樣，都是數據在網絡上傳輸的協議，只是它們是專門用來傳輸流式媒體的協議而已。 下面，讓我們來看一下現在使用的主要的流媒體協議： 1. RTSP（Real Time Streaming Protocol），實時流媒體協議，它是由RealNetworks和Netscape共同提出的，現在用于RealNetworks的Real Media產品中； 2. PNM（Progressive Networks Audio），這也是Real專用的實時傳輸協議，它一般采用UDP協議，并占用7070端口，但當你的服務器在防火墻內且7070端口被擋，且你的服務器把SmartingNetwork設為真時，則采用協議，并占用默認的80端口； 3. MMS（Microsoft Media Server protocol），這是微軟的流媒體服務器協議，MMS 是連接 Windows Media 單播服務的默認方法。 介紹了主要的三個，可能您還會問，apple的QuickTime使用哪種協議呢？在多數情況下，Quick盯ime使用協議，但實際上它也由標準的流媒體傳輸協議，這就是標準RTSP協議，而Real公司使用的RTSP是自己經過開發的。 在流媒體傳輸中，標準的協議就是RTP（Real time Transport Protocol，實時傳輸協議）、RTCP(Real-time Transport Control Protocol，實時傳輸控制協議)、RTSP（Real Time Streaming Protocol，實時流媒體協議）和RSVP（Resource Reserve Protocol, 資源預訂協議），廠商們的產品都是在這些協議的基礎上進行研究與開發，限于篇幅，在這里我們就不再深入討論了。 問題二：流媒體系統包括哪三部分？目前三大主流媒體格式以及協議是什么？1、編碼器：它由一臺普通計算機、一塊microvision 高清視頻采集卡和流媒體編碼軟件組成。 Microvision流媒體采集卡負責將音視頻信息源輸入計算機，供編碼軟件處理;編碼軟件負責將流媒體 采集卡傳送過來的數字音視頻信號壓縮成流媒體格式。 如果做直播，它還負責實時地將壓縮好的流媒體信號上傳給流媒體服務器 2、服務器：由流媒體軟件系統的服務器部分和一臺硬件服務器組成。 這部分負責管理、存儲、分發編碼器傳上來的流媒體節目。 3、終端播放器，也叫解碼器: 這部分由流媒體系統的播放軟件和一臺普通PC組成，用它來播放用戶想要收看的流媒體服務器上的視頻節目。 流媒體技術原理 目前主流的流媒體技術有三種，分別是RealNetworks公司的RealSystem、Microsoft公司的WindowsMediaTechnology和Apple公司的QuickTime。 這三家的技術都有自己的專利算法、專利文件格式甚至專利傳輸控制協議。 問題三：常見的流媒體協議有哪些？有MMS,RSVP,RTSP,RTP,RTPC等等 問題四：流媒體是什么?有什么類型?流媒體，又叫流式媒體，是邊傳邊播的媒體，是多媒體的一種。 邊傳邊播是指媒體提供商在網絡上傳輸媒體的“同時”，用戶一邊不斷地接收并觀看或收聽被傳輸的媒體。 “流”媒體的“流”指的是這種媒體的傳輸方式（流的方式），而并不是指媒體本身。 有兩種類型； 1.順序流式傳輸是順序下載，在下載文件的同時用戶可觀看在線媒體，在給定時刻，用戶只能觀看已下載的那部分，而不能跳到還未下載的前頭部分，順序流式傳輸不象實時流式傳輸在傳輸期間根據用戶連接的速度做調整。 由于標準的HTTP服務器可發送這種形式的文件，也不需要其他特殊協議，順序流式傳輸比較適合高質量的短片段，如片頭、片尾和廣告，由于該文件在播放前觀看的部分是無損下載的，這種方法保證電影播放的最終質量。 2.實時流式傳輸指保證媒體信號帶寬與網絡連接配匹，使媒體可被實時觀看到。 實時流與HTTP流式傳輸不同，他需要專用的流媒體服務器與傳輸協議。 實時流式傳輸總是實時傳送，特別適合現場事件，也支持隨機訪問，用戶可快進或后退以觀看前面或后面的內容。 理論上，實時流一經播放就可不停止，但實際上，可能發生周期暫停。 實時流式傳輸必須配匹連接帶寬，這意味著在以調制解調器速度連雞時圖象質量較差。 而且，由于出錯丟失的信息被忽略掉，網絡擁擠或出現問題時，視頻質量很差。 如欲保證視頻質量，順序流式傳輸也許更好。 問題五：流媒體協議RTMP，RTSP與HLS有什么不同流媒體協議RTMP,RTSP與HLS有什么不同？ HLS (HTTP Live Streaming) Apple的動態碼率自適應技術。 主要用于PC和Apple終端的音視頻服務。 包括一個m3u(8)的索引文件，TS媒體分片文件和key加密串文件。 常用的流媒體協議主要有 HTTP 漸進下載和基于 RTSP/RTP 的實時流媒體協議，這二種基本是完全不同的東西，目前比較方便又好用的是用 HTTP 漸進下載方法。 在這個中 apple 公司的 HTTP Live Streaming 是這個方面的代表。 它最初是蘋果公司針對iPhone、iPod、iTouch和iPad等移動設備而開發的流.現在見到在桌面也有很多應用了，HTML5 是直接支持這個。 但是HLS協議的小切片方式會生成大量的文件，存儲或處理這些文件會造成大量資源浪費。 如果要實現數天的時移，索引量將會是個巨額數字，并明顯影響請求速度。 因此，HLS協議對存儲I/O要求相當苛刻。 對此，也有公司提出了非常好的解決方案。 新型點播服務器系統，獨創了內存緩存數據實時切片技術，顛覆了這種傳統實現方法，從根本上解決了大量切片的碎片問題，使得單臺服務器的切片與打包能力不再是瓶頸。 其基本原理如下： 不將TS切片文件存到磁盤，而是存在內存當中，這種技術使得服務器的磁盤上面不再會有“數以噸計”的文件碎片，極大減少了磁盤的I/O次數，延長了服務器磁盤的使用壽命，極大提高了服務器運行的穩定性。 同時，由于使用這種技術，使得終端請求數據時直接從服務器的內存中獲取，極大提高了對終端數據請求的反應速度，優化了視頻觀看體驗。 RTSP協議，這應該是實時性最好的了，如果要想實時性要求很高，比如0.5s以內，這個是不錯的選擇。 前陣子模仿spydroid寫了個建議的rtsp 服務器，其實就是options，describe，setup，play，pause，teardown這幾步了，這個協議用的最廣泛，網上介紹也比較 多。 要想真正深入了解rtsp協議，c++語言功底好的可以查看live555 。 問題六：實現流媒體傳輸的主要協議有哪些？各自的功能和任務是什么基于Windows Media技術的流媒體系統的設計與實現 摘要：本文在簡介流媒體技術及其中的Windows Media技術的基礎上，結合實際簡述了Windows Media服務器的安裝、ASF文件的制作以及“點播單播發布點”、“廣播單播發布點”、“多播廣播站”的創建方法，從實踐角度闡述了在網絡中實現流媒體服務的技術和方法。 關鍵詞：Windows Media 流媒體 網絡視頻 Windows Media-based streaming media technology, Design and Implementation Abstract: This article profiles in streaming media technology in its Windows Media technology on the basis of the actual bined on a Windows Media server installation, ASF, as well as the production of documents on-demand unicast release point, Broadcast Unicast release point, Multicast broadcast stations, the creation of methods, and through links to web pages, etc. They may be related to the test, from the perspective of the practice described in the network to achieve streaming media services technologies and methods. Key words: Windows Media streaming video network 1.流媒體技術概述 流媒體簡單地說就是應用流式傳輸技術在Internet/Intranet上傳輸的連續時基媒體，如：音頻、視頻或多媒體文件。 流式媒體在播放前并不下載整個文件，只將開始部分內容存入內存，流式媒體的數據流隨時傳送隨時播放，只是在開始時有一些延遲。 流媒體實現的關鍵技術就是流式傳輸。 流式傳輸主要指通過網絡傳送媒體（如視頻、音頻）的技術總稱。 其特定含義為通過Internet將影視節目傳送到PC機。 流媒體技術是包含了采集、編碼、傳輸、儲存、解碼等多項技術的綜合技術。 2. Windows Media技術簡介 2.1 特點 Microsoft公司推出的Windows Media技術具有方便性、先進性、集成性、低費用等特點，而且其制作、發布和播放軟件與Windows NT/2000/9x集成在一起，不需要額外購買。 Microsoft的流視頻解決方案在Microsoft視窗平臺上是免費的，制作端與播放器的視音頻質量都上佳，而且易于使用。 2.2 Windows Media播放方式 Windows Media播放方式包括單播、多播、點播與廣播。 它們的含義如下表所示： 單播：是客戶端與服務器之間的點到點連接。 在客戶端媒體服務器之間建立一個單獨的數據通道，1臺服務器送出的每個數據包只能傳送給1個客戶機。 多播：是通過啟用多播的網絡傳遞內容流，網絡中的所有客戶端共享同一流。 由多播技術構建......>> 問題七：什么是流媒體播放協議流媒體技術基礎-流媒體傳輸協議 作者/來源：未知 實時傳輸協議RTP與RTCP RTP（Real-timeTransportProtocol）是用于Internet上針對多媒體數據流的一種傳輸協議。 RTP被定義為在一對一或一對多的傳輸情況下工作，其目的是提供時間信息和實現流同步。 RTP通常使用UDP來傳送數據，但RTP也可以在TCP或ATM等其他協議之上工作。 當應用程序開始一個RTP會話時將使用兩個端口：一個給RTP，一個給RTCP。 RTP本身并不能為按順序傳送數據包提供可靠的傳送機制，也不提供流量控制或擁塞控制，它依靠RTCP提供這些服務。 通常RTP算法并不作為一個獨立的網絡層來實現，而是作為應用程序代碼的一部分。 實時傳輸控制協議RTCP。 RTCP(Real-timeTransportControlProtocol)和RTP一起提供流量控制和擁塞控制服務。 在RTP會話期間，各參與者周期性地傳送RTCP包。 RTCP包中含有已發送的數據包的數量、丟失的數據包的數量等統計資料，因此，服務器可以利用這些信息動態地改變傳輸速率，甚至改變有效載荷類型。 RTP和RTCP配合使用，它們能以有效的反饋和最小的開銷使傳輸效率最佳化，因而特別適合傳送網上的實時數據。 6.2.1 RTP數據傳輸協議 RTP提供端對端網絡傳輸功能，適合通過組播和點播傳送實時數據，如視頻、音頻和仿真數據。 RTP沒有涉及資源預訂和質量保證等實時服務，RTCP擴充數據傳輸以允許監控數據傳送，提供最小的控制和識別功能。 RTP與RTCP設計成獨立傳輸和網絡層。 2.1.1 RTP固定頭 RTP 頭格式如下： ----------------------------------------------------------------------------------------------- |V=2|P|X| CC |M| PT | 系列號 | ----------------------------------------------------------------------------------------------- | 時標 | ----------------------------------------------------------------------------------------------- | 同步源標識(SSRC) | ----------------------------------------------------------------------------------------------- | 作用標識 (CSRC) | | .... | ----------------------------------------------------------------------------------------------- 開始12個八進制出現在每個RTP包中，而CSRC標識列表僅出現在混合器插入時。 2.1.2 復用 RTP 連接 為使協議有效運行，復用點數目應減至最小。 RTP中，復用由定義RTP連接的目的傳輸地址（網絡地址與端口號）提供。 例如，對音頻和視頻單獨編碼的遠程會議，每個媒介被攜帶在單獨RTP連接中，具有各自的目的傳輸地址。 目標不在將音頻和視頻放在單一RTP連接中，而根據SSRC段載荷類型進行多路分解。 使用同一SSRC ，......>> 問題八：流媒體協議RTMP，RTSP與HLS有什么不同RTMP是Real Time Messaging Protocol(實時消息傳輸協議)的首字母縮寫。 該協議基于TCP，是一個協議族，包括RTMP基本協議及RTMPT/RTMPS/RTMPE等多種變種。 RTMP是一種設計用來進行實時數據通信的網絡協議，主要用來在Flash/AIR平臺和支持RTMP協議的流媒體/交互服務器之間進行音視頻和數據通信。 支持該協議的軟件包括Adobe Media Server/Ultrant Media Server/red5等。 RTSP(Real Time Streaming Protocol)，RFC2326，實時流傳輸協議，是TCP/IP協議體系中的一個應用層協議，由哥倫比亞大學、網景和RealNetworks公司提交的IETF RFC標準。 該協議定義了一對多應用程序如何有效地通過IP網絡傳送多媒體數據。 RTSP在體系結構上位于RTP和RTCP之上，它使用TCP或UDP完成數據傳輸。 HTTP與RTSP相比，HTTP請求由客戶機發出，服務器作出響應;使用RTSP時，客戶機和服務器都可以發出請求，即RTSP可以是雙向的。 RTSP是用來控制聲音或影像的多媒體串流協議，并允許同時多個串流需求控制，傳輸時所用的網絡通訊協定并不在其定義的范圍內，服務器端可以自行選擇使用TCP或UDP來傳送串流內容，它的語法和運作跟HTTP 1.1類似，但并不特別強調時間同步，所以比較能容忍網絡延遲。 而前面提到的允許同時多個串流需求控制(Multicast)，除了可以降低服務器端的網絡用量，更進而支持多方視訊會議(Video Conference)。 因為與HTTP1.1的運作方式相似，所以代理服務器〈Proxy〉的快取功能〈Cache〉也同樣適用于RTSP，并因RTSP具有重新導向功能，可視實際負載情況來轉換提供服務的服務器，以避免過大的負載集中于同一服務器而造成延遲。 問題九：實時流媒體RTSP協議的開發，該看哪些書籍可以看看live555，那個代碼里面有rtsp，流程很清晰，很好理解 如果要做流媒體客戶端的話，可能會用到directshow 問題十：移動流媒體的控制協議流媒體使用的特有的應用和控制協議有RTP/RTCP、RSVP和RTSP。 （1）實時傳輸協議（RTP）和實時控制協議（RTCP）。 RTP/RTCP是基于IP的應用層協議，支持實時數據（音頻、視頻流）的傳輸，其思想是傳輸實時數據的同時發送一些關于傳輸和接收的質量的反饋信息，這兩個任務分別由RTP和RTCP完成。 RTP提供一些機制用于進行時間重建、定時、丟包檢測和重排序。 RTP支持單播和組播，可用于單向傳輸也可用于雙向業務，但是RTP本身不提供如何實時傳輸的機制，也不提供可靠的流阻塞控制，而是通過與RTCP和UDP的配合，使傳輸效率達到最優化。 RTP/RTCP為傳送實時數據提供需要的功能和控制機制，但是其本身不負責高層的任務，如重排序和同步，這些由應用程序完成。 （2）資源預留協議（RSVP）。 RSVP允許數據接收方為數據流請求特殊的端到端QoS。 實時應用使用RSVP在路由器上預留必要的資源，這樣在傳輸的時候可以得到所要求的帶寬。 RSVP流程是單一的，不區別發送方和接收方。 RSVP支持組播和單播，并適應變化的成員個數和路由。 使用RSVP要求傳輸路徑上的節點都支持RSVP，這很難得到保證，所以流應用一般不使用RSVP。 （3）實時流協議（RTSP）。 RTSP是一個應用層協議，利用RTSP可以在服務器和客戶端之間建立并控制連續的音頻媒體和視頻媒體流，進行服務器和客戶端之間的“網絡遠程控制”，提供類似VCR的音頻和視頻的遠程控制功能。 但是RTSP要在獨立于數據的通道中進行傳輸。 RTSP支持單播和組播，提供選擇傳送通道的方法，可以選擇UDP、組播UDP和TCP，而低層的傳輸機制依賴于RTP或TCP。 RTSP與低層的協議（如RTP、RSVP）一起協調運行，提供完全的流服務。 RTSP是有狀態的、對稱的協議，RTSP服務器維護會話狀態且RTSP中媒體服務器和客戶端都能發出請求。 RTSP的語法和操作與HTTP相似，使用專用于音頻和視頻的類似于HTTP中的URL。

流媒體服務器優缺點分析對比

本文對國內外主流流媒體服務器產品進行了優缺點分析對比，旨在幫助大家更好地選擇。 一、WowzaWowza是一款Java語言編寫的流媒體服務器，號稱提供10Gb的播出吞吐能力，但實際效果一般，對服務器硬件要求較高。 優點是產品成熟，可按月付費，有國內代理商和漢化界面。 自2014年后，該產品已更名為Wowza Streaming Engine 4，由美國科羅拉多州的Wowza Media Systems LLC開發。 優點：產品成熟，版本可持續性強。 缺點：國外產品，支持力度不足，付款渠道有限，需使用Paypal付款。 二、NTV Media Server G3NTV Media Server G3由云視睿博研發，是C語言編寫的Linux系統流媒體服務器，滿足廣播級視頻播出要求。 特點為產品成熟可靠，穩定性高，提供加密播出和完善的API接口，有較多的大客戶群，技術支持和研發團隊在北京。 優點：產品化程度高，性能優異，集成方便，技術咨詢和服務專業成熟。 缺點：售價偏高，市場分級不足。 三、Flash Media ServerFlash Media Server是Adobe出品的流媒體服務器，雖然是鼻祖，但支持和后續研發逐漸減弱，國內已無分支機構。 優點：老牌產品，對協議適配性好。 缺點：無技術支持。 四、Live555Live555是一個為流媒體提供解決方案的C++開源項目，支持標準流媒體傳輸協議。 優點：開源免費。 缺點：成熟度較低，需有較高的技術能力。 五、Red5Red5是采用Java開發的Flash流媒體服務器，支持音頻/視頻轉換、錄制、直播流發布等功能。 優點：開源免費，較成熟。 缺點：性能一般。 六、Open AMFOpen AMF是免費的開放源碼替代Macromedia的遠程Java Flash，提供應用服務。 優點：開源免費。 缺點：小眾，支持文檔較少。

java可以做網頁上的直播嗎

可以的，我做課程設計的時候就是用java。 用到了集成的red5做流媒體服務器。 然后找了個支持rtmp的網頁嵌入的flash播放器。

上一篇：掌握Red5的高級功能解鎖無限的流媒體可能性

下一篇：Red5入門打造一個令人驚嘆的流媒體應用程序