直播伺服器組播地址

❶ 為什麼央視頻直播沒有解說

央視頻直播沒有解說是因為你可以直接觀看到。央視頻直播自己可以看到情景發展。解說是相對於專業的東西或技能，一般的視頻是可以通過直觀的直播看懂的。只有不懂才需要講解。

視頻直播

視頻直播的實現過程當用戶發出直播請求時，該伺服器就會根據直播信息，是將該直播頻道的播放地址一般是一個組播URL，而非組播文件告訴用戶，用戶根據該地址加入對應的組播組，即可接收到該直播電視的碼流了。

直播業務一般採用組播的網路方式來實現。所謂組播就是利用一種協議將IP數據包從一個信息源傳送到多個目的地，將信息的拷貝發送到一組地址，送達所有想要接收它的接收者。IP組播是將IP數據包「盡最大努力」傳輸到一個構成組播群組的主機集合。

群組的各個成員可以分布於各個獨立的物理網路上。IP組播群組中成員的關系是動態的，主機可以隨時加入和退出群組，群組的成員關系決定了主機是否接收送給該群組的組播數據包，不是某群組的成員主機也能向該群組發送組播數據包。

❷ 什麼是IP組播單播、多播，在網路裡面分別指的是什麼很多人研究IP組播，那麼IP組播到底是什麼

一般是根據傳輸的消息特徵將IP地址分為單播、廣播或多播。
1 單播 （Unicast）
一個單播IP地址只能標識一台用戶主機，一台用戶主機只能識別一個單播IP地址。一份使用單播IP地址為目的地址的IP報文，只能被一台用戶主機接收。
2 廣播（Broadcast）
一個廣播IP地址能夠標識某確定網段內的所有用戶主機，一份使用廣播IP地址為目的地址的IP報文，能夠被該網段內的所有用戶主機接收。IP廣播報文不能跨網段傳播。 廣播分組的目標IP地址的主機部分全為1，如：
C類網路192.168.1.0的默認子網掩碼為255.255.255.0，其廣播地址為192.168.1.255，其主機部分為十進制數255或二進制數11111111（全為1）。
3 組播/多播（Multicast）
一個組播IP地址能夠標識網路不同位置的多個用戶主機，一台用戶主機可以同時識別多個組播IP地址。一份使用組播IP地址為目的地址的IP報文，能夠被網路不同位置的多個用戶主機接收。 多播地址范圍為224.0.0.0～239.255.255.255。

組播的特點：
組播就是類似於發布-訂閱模式，一端是出版商，進行數據發布（向組播地址發送數據），一端是訂閱者，根據內容決定訂閱哪些數據（加入多播組）。
出版商向組播地址發送數據，數據在網路中傳輸，只有一份就可以，經過交換機時，交換機之下的子網中如果沒有人訂閱，則數據繼續傳輸；如果有人訂閱，則交換機將把數據復制多份，轉發給子網的訂閱者。所以組播的最大好處就是節省帶寬。

❸ 採集外網直播節目,變成區域網IP進行組播

我們原來做組播測試的時候是使用VLC播放器 這個軟體可以直接向一個組播地址播放視頻的 也可以設置接收對應組播地址的數據 當時我們的組播源和接收端都是用VLC播放器來播放和接收視頻
你可以試試

❹ IPv6裡面沒有廣播什麼是單播、組播、任意播IPv4裡面呢這幾個波分別有什麼用

IPv6協議主要定義了三種地址類型：單播地址（Unicast Address）、組播地址（Multicast Address）和任播地址（Anycast Address）。與原來在IPv4地址相比，新增了「任播地址」類型，取消了原來IPv4地址中的廣播地址，因為在IPv6中的廣播功能是通過組播來完成的。

1、單播地址的作用：用來唯一標識一個介面，類似於IPv4中的單播地址。發送到單播地址的數據報文將被傳送給此地址所標識的一個介面。

2、組播地址的作用：用來標識一組介面（通常這組介面屬於不同的節點），類似於IPv4中的組播地址。發送到組播地址的數據報文被傳送給此地址所標識的所有介面。

3、任播地址的作用：用來標識一組介面（通常這組介面屬於不同的節點）。發送到任播地址的數據報文被傳送給此地址所標識的一組介面中距離源節點最近（根據使用的路由協議進行度量）的一個介面。

(4)直播伺服器組播地址擴展閱讀：

廣播地址的作用：

1、廣播地址允許數據包發往子網上的所有設備。一般情況下，廣播地址是藉由子網掩碼的比特反碼並和網上識別碼運行 OR 的比特運算得到，即廣播地址是子網中的最後一個地址。在A、B和C類網路中，廣播地址總是以255結尾。

3、專門用於同時向網路中所有工作站進行發送的一個地址。在使用TCP/IP 協議的網路中，主機標識段host ID 為全1 的IP 地址為廣播地址，廣播的分組傳送給host ID段所涉及的所有計算機。

❺ 直播設置編碼檔位什麼意思

直播設置編碼檔位是調整畫質的檔位。
直播的編碼檔位要選穩定的，最好要有信號強弱，網路信號，推流信號，視頻音頻信號等顯示，自帶電池，同時也能充電寶供電。
直播業務一般採用組播的網路方式來實現。所謂組播就是利用一種協議將IP數據包從一個信息源傳送到多個目的地，將信息的拷貝發送到一組地址，送達所有想要接收它的接收者。

❻ 什麼是RTSP

實時流協議RTSP(RealTimeStreamingProtocol)是由RealNetworks和Netscape共同提出的，該
協議定義了一對多應用程序如何有效地通過IP網路傳送多媒體數據。RTSP在體系結構上位於RTP
和RTCP之上，它使用TCP或RTP完成數據傳輸。HTTP與RTSP相比，HTTP傳送HTML，而RTP傳送的
是多媒體數據。HTTP請求由客戶機發出，伺服器作出響應；使用RTSP時，客戶機和伺服器都可
以發出請求，即RTSP可以是雙向的。
6.3 RTSP協議
實時流協議（RTSP）是應用級協議，控制實時數據的發送。RTSP提供了一個可擴展框架，使
實時數據，如音頻與視頻，的受控、點播成為可能。數據源包括現場數據與存儲在剪輯中數據
。該協議目的在於控制多個數據發送連接，為選擇發送通道，如UDP、組播UDP與TCP，提供途徑
，並為選擇基於RTP上發送機制提供方法。
6.3.1 簡介
6.3.1.1 目的
實時流協議（RTSP）建立並控制一個或幾個時間同步的連續流媒體。盡管連續媒體流與控制
流交*是可能的，通常它本身並不發送連續流。換言之，RTSP充當多媒體伺服器的網路遠程式控制
制。RTSP連接沒有綁定到傳輸層連接，如TCP。在RTSP連接期間，RTSP用戶可打開或關閉多個對
伺服器的可*傳輸連接以發出RTSP 請求。此外，可使用無連接傳輸協議，如UDP。RTSP流控制
的流可能用到RTP，但RTSP操作並不依賴用於攜帶連續媒體的傳輸機制。實時流協議在語法和操
作上與HTTP/1.1類似，因此HTTP的擴展機制大都可加入RTSP。協議支持的操作如下：
從媒體伺服器上檢索媒體：
用戶可通過HTTP或其它方法提交一個演示描述。如演示是組播，演示式就包含用於連續媒體
的的組播地址和埠。如演示僅通過單播發送給用戶，用戶為了安全應提供目的地址。
媒體伺服器邀請進入會議：
媒體伺服器可被邀請參加正進行的會議，或回放媒體，或記錄其中一部分，或全部。這種模
式在分布式教育應用上很有用，會議中幾方可輪流按遠程式控制制按鈕。
將媒體加到現成講座中：

如伺服器告訴用戶可獲得附加媒體內容，對現場講座顯得尤其有用。如HTTP/1.1中類似，RTSP
請求可由代理、通道與緩存處理。

6.3.1.2 協議特點
RTSP 特性如下：
可擴展性：
新方法和參數很容易加入RTSP。
易解析：
RTSP可由標准 HTTP或MIME解吸器解析。
安全：
RTSP使用網頁安全機制。
獨立於傳輸：
RTSP可使用不可*數據報協議（UDP）、可*數據報協議（RDP），如要實現應用級可*，可
使用可*流協議。
多伺服器支持：
每個流可放在不同伺服器上，用戶端自動同不同伺服器建立幾個並發控制連接，媒體同步在
傳輸層執行。
記錄設備控制：
協議可控制記錄和回放設備。
流控與會議開始分離：
僅要求會議初始化協議提供，或可用來創建唯一會議標識號。特殊情況下， SIP或H.323
可用來邀請伺服器入會。
適合專業應用：
通過SMPTE 時標，RTSP支持幀級精度，允許遠程數字編輯
演示描述中立：

協議沒強加特殊演示或元文件，可傳送所用格式類型；然而，演示描述至少必須包含一個RTSP
URI。
代理與防火牆友好：
協議可由應用和傳輸層防火牆處理。防火牆需要理解SETUP方法，為UDP媒體流打開一個"缺
口"。
HTTP友好：
此處，RTSP明智的採用HTTP觀念，使現在結構都可重用。結構包括Internet 內容選擇平台
（PICS）。由於在大多數情況下控制連續媒體需要伺服器狀態， RTSP不僅僅向HTTP 添加方法
。 適當的伺服器控制：
如用戶啟動一個流，他必須也可以停止一個流。
傳輸協調；
實際處理連續媒體流前，用戶 可協調傳輸方法。
性能協調：
如基本特徵無效，必須有一些清理機制讓用戶決定那種方法沒生效。這允許用戶提出適合的
用戶界面。
6.3.1.3擴展RTSP
由於不是所有媒體伺服器有著相同的功能，媒體伺服器有必要支持不同請求集。RTSP 可以
如下三種方式擴展，這里以改變大小排序：
以新參數擴展。如用戶需要拒絕通知，而方法擴展不支持，相應標記就加入要求的段中。
加入新方法。如信息接收者不理解請求，返回501錯誤代碼（還未實現），發送者不應再次
嘗試這種方法。用戶可使用OPTIONS方法查詢伺服器支持的方法。伺服器使用公共響應頭列出支
持的方法。
定義新版本協議，允許改變所有部分。（除了協議版本號位置）
6.3.1.4操作模式
每個演示和媒體流可用RTSP URL識別。演示組成的整個演示與媒體屬性由演示描述文件定義
。使用HTTP或其它途徑用戶可獲得這個文件，它沒有必要保存在媒體伺服器上。
為了說明，假設演示描述描述了多個演示，其中每個演示維持了一個公共時間軸。為簡化說
明，且不失一般性，假定演示描述的確包含這樣一個演示。演示可包含多個媒體流。除媒體參
數外，網路目標地址和埠也需要決定。下面區分幾種操作模式：
單播：
以用戶選擇的埠號將媒體發送到RTSP請求源。
組播，伺服器選擇地址：
媒體伺服器選擇組播地址和埠，這是現場直播或准點播常用的方式。
組播，用戶選擇地址：
如伺服器加入正在進行的組播會議，組播地址、埠和密匙由會議描述給出。
6.3.1.5 RTSP狀態
RTSP控制通過單獨協議發送的流，與控制通道無關。例如，RTSP控制可通過TCP連接，而數
據流通過UDP。因此，即使媒體伺服器沒有收到請求，數據也會繼續發送。在連接生命期，單個
媒體流可通過不同TCP連接順序發出請求來控制。所以，伺服器需要維持能聯系流與RTSP請求的
連接狀態。RTSP中很多方法與狀態無關，但下列方法在定義伺服器流資源的分配與應用上起著
重要的作用：
SETUP：
讓伺服器給流分配資源，啟動RTSP連接。
PLAY與RECORD：
啟動SETUP 分配流的數據傳輸。
PAUSE：
臨時停止流，而不釋放伺服器資源。
TEARDOWN：
釋放流的資源，RTSP連接停止。
標識狀態的RTSP方法使用連接頭段識別RTSP連接，為響應SETUP請求，伺服器連
接產生連接標識。

6.3.1.6 與其他協議關系
RTSP在功能上與HTTP有重疊，與HTTP相互作用體現在與流內容的初始接觸是通過網頁的。目
前的協議規范目的在於允許在網頁伺服器與實現RTSP媒體伺服器之間存在不同傳遞點。例如，
演示描述可通過HTTP和RTSP檢索，這降低了瀏覽器的往返傳遞，也允許獨立RTSP 伺服器與用戶
不全依*HTTP。
但是，RTSP與HTTP 的本質差別在於數據發送以不同協議進行。HTTP是不對稱協議，用戶發
出請求，伺服器作出響應。RTSP中，媒體用戶和伺服器都可發出請求，且其請求都是無狀態的
；在請求確認後很長時間內，仍可設置參數，控制媒體流。重用HTTP功能至少在兩個方面有好
處，即安全和代理。要求非常接近，在緩存、代理和授權上採用HTTP功能是有價值的。
當大多數實時媒體使用RTP作為傳輸協議時，RTSP沒有綁定到RTP。RTSP假設存在演示描述格
式可表示包含幾個媒體流的演示的靜態與臨時屬性。

6.3.2 協議參數

6.3.3 RTSP 信息
RTSP是基於文本的協議，採用ISO 10646 字元集，使用UTF-8編碼方案。行以CRLF中斷，但
接收者本身可將CR和LF解釋成行終止符。基於文本的協議使以自描述方式增加可選參數更容易
。由於參數的數量和命令的頻率出現較低，處理效率沒引起注意。如仔細研究，文本協議很容
易以腳本語言（如：Tcl、Visual Basic與Perl）實現研究原型。
10646字元集避免敏感字元集切換，但對應用來說不可見。RTCP也採用這種編碼方案。帶有
重要意義位的ISO 8859-1字元表示如100001x 10xxxxxx.。RTSP信息可通過任何低層傳輸協議
攜帶。
請求包括方法、方法作用於其上的對象和進一步描述方法的參數。方法也可設計為在伺服器
端只需要少量或不需要狀態維護。當信息體包含在信息中，信息體長度有如下因素決定：
不管實體頭段是否出現在信息中，不包括信息體的的響應信息總以頭段後第一和空行結束。
如出現內容長度頭段，其值以位元組計，表示信息體長度。如未出現頭段，其值為零。
伺服器關閉連接。
注意：RTSP目前並不支持HTTP/1.1"塊"傳輸編碼，需要有內容長度頭。假如返回適度演示描
述長度，即使動態產生，使塊傳輸編碼沒有必要，伺服器也應該能決定其長度。如有實體，即
使必須有內容長度，且長度沒顯式給出，規則可確保行為合理。
從用戶到伺服器端的請求信息在第一行內包括源採用的方法、源標識和所用協議版本。RTSP
定義了附加狀態代碼，而沒有定義任何HTTP代碼。
6.3.4 實體
如不受請求方法或響應狀態編碼限制，請求和響應信息可傳輸實體，實體由實體頭文件和試
題體組成，有些響應僅包括實體頭。在此，根據誰發送實體、誰接收實體，發送者和接收者可
分別指用戶和伺服器。
實體頭定義實體體可選元信息，如沒有實體體，指請求標識的資源。擴展頭機制允許定義附
加實體頭段，而不用改變協議，但這些段不能假定接收者能識別。不可識別頭段應被接收者忽
略，而讓代理轉發。
6.3.5 連接
RTSP請求可以幾種不同方式傳送：
1、持久傳輸連接，用於多個請求/響應傳輸。
2、每個請求/響應傳輸一個連接。
3、無連接模式。
傳輸連接類型由RTSP URI來定義。對 "rtsp" 方案，需要持續連接；而"rtspu"方案，調用
RTSP 請求發送，而不用建立連接。
不象HTTP，RTSP允許媒體伺服器給媒體用戶發送請求。然而，這僅在持久連接時才支持，否
則媒體伺服器沒有可*途徑到達用戶，這也是請求通過防火牆從媒體伺服器傳到用戶的唯一途
徑。
6.3.6 方法定義
方法記號表示資源上執行的方法，它區分大小寫。新方法可在將來定義，但不能以$開頭。
某些防火牆設計與其他環境可能要求伺服器插入RTSP方法和流數據。由於插入將使客戶端和
伺服器操作復雜，並強加附加開銷，除非有必要，應避免這樣做。插入二進制數據僅在RTSP通
過TCP傳輸時才可使用。流數據（如RTP包）用一個ASCII美圓符號封裝，後跟一個一位元組通道標
識，其後是封裝二進制數據的長度，兩位元組整數。

❼ obs的流名稱是什麼

URL就是直播伺服器的發布地址，流名稱是流媒體直播系統提供的。

流媒體採用流式傳輸技術在網路上連續實時播放的媒體格式，如音頻、視頻或多媒體文件。

流媒體文件一般定義在bit層次結構，因此流數據包並不一定必須按照位元組對齊，雖然通常的媒體文件都是按照這種位元組對齊的方式打包的。流媒體的三大操作平台是微軟公司、RealNetworks、蘋果公司提供的。

(7)直播伺服器組播地址擴展閱讀

實時流式傳輸指保證媒體信號帶寬與網路連接匹配，使媒體可被實時觀看到。實時流與HTTP流式傳輸不同，他需要專用的流媒體伺服器與傳輸協議。

實時流式傳輸總是實時傳送，特別適合現場事件，也支持隨機訪問，用戶可快進或後退以觀看前面或後面的內容。理論上，實時流一經播放就可不停止，但實際上，可能發生周期暫停。

實時流式傳輸必須配匹連接帶寬，這意味著在以數據機速度連接時圖象質量較差。而且，由於出錯丟失的信息被忽略掉，網路擁擠或出現問題時，視頻質量很差。如欲保證視頻質量，順序流式傳輸也許更好。

實時流式傳輸需要特定伺服器，如：QuickTime Streaming Server、RealServer與Windows Media Server。這些伺服器允許你對媒體發送進行更多級別的控制，因而系統設置、管理比標准HTTP伺服器更復雜。

實時流式傳輸還需要特殊網路協議，如：RTSP (Realtime Streaming Protocol)或MMS (Microsoft Media Server)。這些協議在有防火牆時有時會出現問題，導致用戶不能看到一些地點的實時內容。