Category: Live Streaming

WEBM格式是一種媒體文件格式，開源為Web使用設計，主要用於視頻的播放。

WebM簡介

WebM 是一個開源的媒體文件格式，主要用於封裝使用 VP8 或 VP9 編碼的視頻流和使用 Vorbis 或 Opus 編碼的音頻流。這個格式是由 Google 主導開發的，並於 2010 年首次推出。

以下是一些 WebM 格式的特點和詳情：

1. 設計目的

WebM 主要設計用於在線流媒體傳輸，特別是作為 HTML5 的 <video> 標籤的一部分。它旨在提供一個開放、高效、免版權費的視頻壓縮方案。

2. 視頻和音頻編碼

• 視頻：VP8 或 VP9
• 音頻：Vorbis 或 Opus

3. 優勢

• 開放和免費：WebM 是一個完全開源和免費的格式，這意味著任何人都可以使用和分發它，無需支付任何費用。
• 高效壓縮：使用 VP9 編碼的 WebM 文件可以提供與 H.264 相似的視頻質量，但文件大小通常更小。
• 廣泛支持：大部分主流瀏覽器，如 Chrome、Firefox 和 Opera，都支持 WebM 格式的播放。

4. 缺點

• 兼容性問題：一些瀏覽器（如 Safari）和一些媒體播放器可能不原生支持 WebM 格式。
• 硬體支持限制：與某些其他視頻格式相比，硬體支持可能較少。

5. 適用場景

由於 WebM 的高效壓縮和開放性質，它特別適合用於網頁視頻、視頻會議、流媒體服務等場景。

6. 文件結構

WebM 使用 Matroska 容器格式，這是一個流行的開源媒體容器格式，可以容納多種編碼的音頻和視頻流。

可使用的傳輸協議

1. HTTP/HTTPS：作為最常見的Web傳輸協議，HTTP和HTTPS可用於傳輸WEBM文件。這是在網頁中嵌入和播放WEBM視頻的標準方法。
2. RTSP (Real-Time Streaming Protocol)：用於控制多媒體流的傳輸，可以用於WEBM格式的傳輸。
3. HLS (HTTP Live Streaming)：由Apple開發的基於HTTP的流媒體通信協議，也可用於傳輸WEBM格式。
4. DASH (Dynamic Adaptive Streaming over HTTP)：另一種基於HTTP的適應流媒體傳輸協議，支持WEBM格式。
5. FTP (File Transfer Protocol)：用於在客戶端和服務器之間傳輸文件的協議，可以用於傳輸WEBM文件。
6. WebSocket：允許在Web瀏覽器和服務器之間建立全雙工通信通道，也可用於傳輸WEBM數據。
7. WebRTC：允許Web瀏覽器進行即時通信，也可以用來傳輸WEBM格式的視頻。

優缺點分析

優點：

1. 開放標準： WEBM是一個免費並開源的格式，這意味著它不受專利限制，可以自由使用。
2. 高質量和高效編碼： WEBM使用VP8/VP9視頻編碼，這些編碼器提供了與其他流行格式相當的視頻質量，但文件大小更小。
3. 廣泛支持： 大多數現代Web瀏覽器都支持WEBM格式，使其成為網絡視頻的理想選擇。
4. 支持HTML5： WEBM被設計為與HTML5 <video> 標籤完全兼容，使其在網頁中的集成變得簡單。
5. 支持透明度： VP8/VP9支持透明度（Alpha Channel），允許視頻有透明背景。

缺點：

1. 軟件兼容性： 雖然大多數現代瀏覽器支持WEBM，但一些舊的或非主流的瀏覽器和媒體播放器可能不支持。
2. 專業編輯支持有限： 相比其他格式如MP4，WEBM在專業視頻編輯軟件中的支持可能較少。
3. 不是所有設備都支持： 一些移動設備和媒體播放器可能不支持WEBM格式。
4. 沒有廣泛的工業標準： 雖然WEBM在Web環境中表現出色，但它還沒有像MP4那樣成為廣泛接受的工業標準。
5. 音頻格式限制： WEBM通常使用Opus或Vorbis作為音頻編碼，這可能不是所有應用的最佳選擇。

由Google開發的其他格式

WEBP 是一種圖像格式，用於同時提供有損和無損壓縮。同樣也是由Google開發，目的是加速圖片在網頁上的加載速度。

要把.jpg轉成.webp可使用下面的語法

ffmpeg -i input.jpg -c:v libwebp output.webp

QUIC：

• QUIC則是一個多路復用的傳輸層協議，使用UDP進行數據傳輸。
• 它的目的是減少連接建立的延遲，並且改善在不可靠網絡中的數據傳輸性能。
• QUIC還包括了一個內置的TLS，增強了安全性。

WEBM和QUIC解決了網絡中不同的問題。WEBM專注於視頻編碼和播放，而QUIC則專注於連接和數據傳輸的效率和可靠性。Google作為一個網絡技術的領先公司，一直在推動和創造各種新的技術標準，以改進整個互聯網的性能和體驗。

基於或可以使用UDP (User Datagram Protocol)的協定

RTP（Real-time Transport Protocol）

RTP（Real-time Transport Protocol，即時傳輸協定）是一個網絡協定，用於交付音頻和視頻等多媒體數據流。以下是RTP的一些關鍵特性和細節：

1. 即時性：RTP旨在實時交付數據，這意味著它需要以最小的延遲和抖動來傳輸數據。
2. 協議層次：RTP通常運行在UDP之上，這樣可以降低延遲，但可能會導致一些封包丟失。在某些情況下，它也可以運行在TCP上。
3. 封包結構：RTP封包包括了一個標頭和有效負載。標頭包括有關封包的資訊，如序列號、時間戳等，用於同步和順序排列。有效負載則包括媒體數據。
4. 同步和排序：RTP的頭部包含一個序列號，用於標識每個數據包。這使得接收端能夠檢測丟失的數據包並重新排序接收到的數據包。在實時通信中，尤其是視頻和音頻流，這一功能非常重要，因為它可以讓接收端正確地播放數據。每個RTP數據包還包含一個時間戳，用於表示數據的取樣時刻。這可以讓接收端同步不同類型的媒體流（例如音頻和視頻），並控制播放的速度和節奏。
5. 與RTCP的組合使用：RTP通常與RTCP（RTP控制協議）一同使用。RTCP可以提供有關媒體傳輸質量的反饋，如丟包率、抖動等，這有助於調整和改進傳輸質量。
6. 多播和單播：RTP支持單播和多播傳輸，使其能夠服務於一對一通信和一對多通信的場景。
7. 可擴展性：RTP本身是一個相對簡單的協議，但它的設計允許通過擴展標頭和其他機制來添加新功能。
8. 安全性：RTP可以與SRTP（安全RTP）結合使用，以提供加密和數據完整性保護。

RTP（Real-time Transport Protocol）和WebRTC（Web Real-Time Communication）是兩個密切相關但有所不同的技術。

1. 定義和目的：
   • RTP：是一個協議，用於實時傳輸多媒體數據，例如音頻和視頻流。它可以運行在各種應用和平台上。
   • WebRTC：是一個開放的框架，允許Web瀏覽器進行即時通信（RTC）。它包括一組協議和API，用於在Web瀏覽器之間建立P2P連接。
2. 組件和協議：
   • RTP：是實時數據傳輸的核心協議之一，通常與RTCP（RTP控制協議）一起使用。
   • WebRTC：使用了多個協議和技術，其中RTP就是其中之一，用於媒體數據的實時傳輸。WebRTC還使用了其他協議，如STUN/TURN/ICE（用於NAT穿透和對等發現）和DTLS/SRTP（用於安全性）。
3. 應用範圍：
   • RTP：不限於Web，可用於各種音頻和視頻通信應用。
   • WebRTC：主要用於Web應用，允許瀏覽器進行視頻和音頻通信。
4. 傳輸層：
   • RTP：通常運行在UDP上，也可以在TCP上。但是RTP在TCP上運行時，可能會有一些效能方面的考量，由於RTP自身具有序列號，用於檢測丟失的數據包並重新排序接收到的數據包，與TCP的可靠傳輸機制重疊。另外，TCP的可靠傳輸機制需要確認（ACK）機制，可能會增加傳輸的延遲
   • WebRTC：使用RTP作為其媒體數據的傳輸協議，並使用UDP作為傳輸層協議。

在WebRTC應用中，你可能需要使用WebSocket作為信令通道，以此幫助建立和協調P2P連接。在這種情況下，WebSocket用於傳送元數據（例如SDP描述和ICE結果），而WebRTC用於傳送實時語音、視頻和數據。

RTSP（Real Time Streaming Protocol）

RTMP 和 RTSP 都是使用 TCP 進行控制信令傳輸，但它們在傳輸媒體數據的方式上有所不同。RTMP 使用 TCP 進行媒體數據的傳輸，而 RTSP 使用 RTP/RTCP 在 UDP 上進行媒體數據的傳輸傳輸。RTSP允許客戶端通過建立和控制媒體流會話來請求和傳輸實時媒體數據。

以下是RTSP的一些特點和功能：

1. 實時性：RTSP主要用於實時傳輸音頻和視頻等實時媒體數據，能夠提供較低的傳輸延遲，適用於實時的音視頻通訊。
2. 客戶端/服務器模型：RTSP採用客戶端/服務器模型，客戶端通過發送請求來控制服務器上的媒體流，並獲取媒體數據。
3. 控制功能：RTSP支持控制功能，客戶端可以發送請求來控制媒體流的播放、暫停、快進、倒退等操作。
4. 媒體描述：RTSP支持媒體描述功能，客戶端可以通過請求獲取媒體流的描述信息，如編解碼器信息、媒體流格式等。
5. 使用RTP/RTCP：RTSP常用與RTP（Real-time Transport Protocol）和RTCP（RTP Control Protocol）結合使用，以在網絡上傳輸實時媒體數據。

RTSP在視頻監控、視頻會議、流媒體直播等場景中得到廣泛應用。它為實時媒體數據的傳輸提供了一種靈活、高效的通信機制，使實時音視頻通訊和流媒體播放成為可能。

SRT（Secure Reliable Transport）

SRT（Secure Reliable Transport）是一種基於UDP的開源傳輸協定，由Haivision公司發起並由SRT聯盟持續開發。它的主要目的是優化在公共網路（如互聯網）上進行高品質視訊串流的性能。

SRT旨在解決在廣播等高品質視訊串流場景下，對於低延遲、丟包率低的傳輸要求。它在UDP之上實現了數據包重傳機制，並且加入了AES加密，以確保傳輸的安全性。此外，SRT還提供了一個預測網路傳輸性能的機制（稱為「SRT預測模型」），該模型可動態調整傳輸參數，以優化傳輸性能並減少延遲。

因此，SRT協定將UDP的低延遲特性與TCP的可靠傳輸特性相結合，旨在在公共網路上提供一種安全、可靠、低延遲的視訊傳輸解決方案。這使得它在如廣播、遠程生產和OTT串流等領域中得到了廣泛應用。

QUIC (Quick UDP Internet Connections)

Quick UDP Internet Connections（QUIC）是一種實驗性的傳輸層協議，旨在優化網絡連接性能並提高網絡傳輸的安全性。QUIC主要依賴於用戶數據報協議（UDP）而非傳統的傳輸控制協議（TCP） 。這使得 QUIC 能夠降低網絡延遲、提高連接速度，並在保持安全性的同時減少握手次數。

要使用QUIC，您需要遵循以下幾個步驟：

1. 確保支持QUIC協議的瀏覽器或客戶端要使用QUIC，首先您確保的瀏覽器或客戶端支持該協議。許多現代瀏覽器（如Google Chrome和Mozilla Firefox）已默認啟用QUIC。如果使用或其他瀏覽器，請查看其文檔以確認是否支持QUIC，並了解如何實現。
2. 使用支持QUIC的服務器為了充分利用QUIC協議的優勢，您需要確保服務器端也支持QUIC。您可以選擇支持QUIC的雲服務商，如Google雲平台，或者手機搭建支持QUIC的服務器，例如使用Caddy或nginx 。
3. 配置服務器 如果您要搭建自己的服務器，需要配置服務器以啟用QUIC。對於Caddy和nginx等服務器軟件，您可以參考相應的文檔來配置QUIC支持。確保您已正確配置服務器以使用QUIC，並且需要時提供相應的加密證書。
4. 測試QUIC連接一旦服務器和客戶端都支持QUIC，您就可以通過訪問設置為使用QUIC的網站或服務來測試連接。可以使用瀏覽器的開發者工具檢查網絡連接是否成功地使用了QUIC協議。
5. 監控和優化使用QUIC協議後，您可能需要監控連接性能，並根據需要進行調整。可以使用各種網絡分析工具來評估QUIC連接的表現，並根據結果優化服務器配置。

MPEG-DASH（Dynamic Adaptive Streaming over HTTP）

在使用HTTP-TS進行傳輸時，需要對數據進行分片，以提高傳輸效率和穩定性。可以使用各種分片技術，例如MPEG-DASH的架構技術、HLS的架構M3U8文件等。雖然名稱中包含“HTTP”，但MPEG-DASH可以在任何數據傳輸協議上運行，包括UDP。

MPEG-DASH 通常使用 HTTP 協議，因此它可以通過標準的 HTTP 端口 80 進行傳輸。如果是使用 HTTPS 的話，則是端口 443。這樣的設計使得 MPEG-DASH 能夠更容易通過防火牆和代理伺服器，並且在現有的 Web 基礎設施上部署，因為它使用的是 Web 通信的標準端口和協議。

這種基於 HTTP 的流媒體傳輸方式還有其他的好處，例如緩存和兼容性，因為許多現有的 HTTP 伺服器和網絡設備已經能夠支持 MPEG-DASH，無需進行特殊的配置或升級。

MPEG-DASH（Dynamic Adaptive Streaming over HTTP）是一種自適應比特率流媒體技術，允許高品質的流媒體通過HTTP進行交付，從不同的比特率和質量的媒體文件中進行選擇。因此，你可以將其視為一種基於HTTP的分片技術，而非一個獨立的傳輸協議。

這種自適應技術的核心是將媒體內容分成多個小的段（或稱分片），然後通過HTTP傳輸。客戶端（例如視頻播放器）可以根據網絡條件和設備能力動態選擇不同的質量和比特率的段進行播放。

這使得MPEG-DASH可以在各種網絡條件下提供更好的視頻觀看體驗，適應網絡帶寬的變化，並提供流暢的播放，無論連接速度快慢。它不是一個新的傳輸協議，而是建立在現有的HTTP協議之上的一種媒體交付方法。

RTMP (Real-Time Messaging Protocol)

RTMP（Real-Time Messaging Protocol）和 RTSP（Real Time Streaming Protocol）都是基於 TCP 的應用層協議，它們都使用 TCP 協議進行數據傳輸。雖然它主要使用TCP，但也可以使用UDP。

RTMP是一種用於實時數據傳輸的協議，主要用於音頻、視頻等媒體數據的傳輸。它使用TCP連接來傳輸數據，因為TCP提供了可靠的數據傳輸機制，確保數據的可靠性和缺陷，適合實時數據的傳輸。

RTSP也是一種用於實時媒體數據傳輸的協議，它用於控制媒體流的傳輸和播放。RTSP使用TCP連接來發送控制命令和接收媒體描述信息等控制數據，以確保控制信令的可靠傳輸。而媒體數據本身通常使用RTP（Real-time Transport Protocol）和RTCP（RTP Control Protocol）協議在UDP上進行傳輸，因為UDP具有較低的傳輸延遲，更適合實時媒體數據的傳輸。

因此，RTMP 和 RTSP 都是使用 TCP 進行控制信令傳輸，但它們在傳輸媒體數據的方式上有所不同。RTMP 使用 TCP 進行媒體數據的傳輸，而 RTSP 使用 RTP/RTCP 在 UDP 上進行媒體數據的傳輸傳輸。

那RTSP和RTMP是同樣的數據，如果RTSP設計於UDP傳輸，不是有順序可靠的檢查的動作，而RTMP沒有？

其中，RTSP（Real Time Streaming Protocol）和 RTMP（Real Time Messaging Protocol）在設計上有一些不同，儘管它們都是用於實時媒體傳輸的應用層協議。

RTSP 是一個控制協議，主要用於控制媒體流的傳輸和播放。RTSP 使用 TCP 連接發送控制命令並接收媒體描述信息等控制數據，以確保控制信令的可靠傳輸。而媒體數據本身通常使用RTP（Real-time Transport Protocol）和 RTCP（RTP Control Protocol）協議在 UDP 上進行傳輸。

RTP和RTCP是專門設計用於傳輸實時媒體數據的協議。RTP負責傳輸媒體數據，並提供時序、序列號等信息來保證數據順序和實時性。而RTCP則用於傳輸控制信息，例如網絡RTCP的一項功能就是檢查丟包率並做出相應的調整，以保證媒體數據的傳輸質量。

相比而言，RTMP 是一種用於實時數據傳輸的協議，主要用於音頻、視頻等媒體數據的傳輸。RTMP 使用 TCP 連接來傳輸數據，保證數據的可靠性和缺陷。RTMP 協議本身並並沒有專門設計用於檢查丟包率和調整傳輸速率的機制，這些功能通常需要在應用層實現。

綜上所述，RTSP 和 RTMP 在傳輸實時媒體數據的方式和設計上有所不同。RTSP 主要用於控制媒體流的傳輸和播放，使用 RTP/RTCP 在 UDP 上進行媒體數據傳輸，並帶有丟包而RTMP則主要用於傳輸媒體數據，使用TCP進行數據傳輸，對於丟包率和傳輸速率的控制通常需要應用層實現。

基於 TCP 的串流協議

1. HTTP Live Streaming (HLS)：由 Apple Inc. 提出的基於 HTTP 的串流協議，被廣泛使用在各種串流場景中。它將串流內容分割成一系列小型的基於 HTTP 的文件來傳遞給客戶端。
2. MPEG-DASH（Dynamic Adaptive Streaming over HTTP）：這是一種領先的元率串流技術，使高品質的串流媒體成為可能，通過HTTP傳輸。
3. RTSP (Real-Time Streaming Protocol)：雖然 RTSP 本身是一種控制協議，用於控制串流媒體服務器，但實際上，它的串流通常用 RTP 跨越 UDP 實現。然而，RTSP 也可以跨越 TCP 串流實現傳輸。
4. RTMP (Real-Time Messaging Protocol)：RTMP 是由 Adob​​e Systems 為 Flash 播放器播放音訊、視訊和數據而開發的開放協議，主要使用 TCP。
5. Microsoft Smooth Streaming (MSS)：這是微軟開發的一種前置串流協議，通過HTTP進行傳輸。
6. HTTP/2：這是 HTTP 協議的第二個主要版本，它允許服務器將多個響應客戶端到客戶端，而無需客戶端明確的請求，這對於串流媒體來說是有利的。

FFmpeg介紹

FFmpeg 是一個應用程式工具，它的主要功能包括讀取、解碼、編碼、轉碼、重新封裝、串流等各種視頻和音頻格式。這種應用程式大多數情況下被認為是在應用層（Application Layer）

然而，如果從數據表示、編碼和轉換的角度來看，你也可以說 FFmpeg 做的工作涉及到表示層（Presentation Layer）的部分功能。例如，它會解碼影片檔案（從一種表現形式轉換為另一種），並將其轉換為對應的像素和音頻資料。

若是使用ffmpeg讀取HTTP-FLV的串流，HTTP-FLV 協議主要是在應用層工作，而接收端的應用程序（例如媒體播放器）則在應用層和表示層之間工作，負責解封裝和解碼接收到的數據

HTTP 和 WebSocket 協議

HTTP 協議的握手過程通常包括客戶端發送一個請求到伺服器，然後伺服器回應這個請求。這種請求/回應模式構成了 HTTP 的基本交互模式。

而 WebSocket 協議的握手過程稍微有些不同。WebSocket 的握手過程基於 HTTP，一開始由客戶端發送一個 HTTP 升級請求到伺服器。如果伺服器接受這個升級請求，它會回應一個升級的回應，此時連接就會從 HTTP 轉變為 WebSocket。然後這個 WebSocket 連接就可以用來做全雙工的通訊，直到一方選擇關閉連接為止。

這些握手過程都是在應用層進行的，並且直接涉及到最終的應用程序（例如網頁瀏覽器或者 Web 伺服器）的行為。

WebRTC（Web Real-Time Communications）的網路概念

WebRTC（Web Real-Time Communications）是一種用於網頁瀏覽器的 P2P（Peer-to-Peer，即點對點）通訊技術。它可以讓網頁瀏覽器直接與另一個網頁瀏覽器進行實時的音視頻通訊，不需要中間的伺服器轉發。

WebRTC 在 OSI 模型中的定位並不容易確定，因為它實際上涉及到了多個 OSI 層次。例如，WebRTC 使用了 RTP（Real-time Transport Protocol，實時傳輸協議）來傳輸音視頻數據，RTP 通常被認為是在傳輸層（第四層）。同時，WebRTC 還需要用到 STUN/TURN/ICE 這些協議來進行 NAT 穿透和對等節點的發現，這些協議也工作在傳輸層。而且，WebRTC 最終的實際應用（例如在網頁瀏覽器中進行音視頻通話）則是在應用層（第七層）。

所以，我們不能簡單地說 WebRTC 屬於 OSI 模型的某一個層次。相反，我們可以說 WebRTC 是一種跨層次的技術，它涉及到了 OSI 模型中的多個層次。這也再次顯示了 OSI 模型在實際應用中的限制，並非所有的網路技術都能夠簡單地映射到 OSI 的七個層次中。

WebRTC 是一個開放標準，允許通過網頁進行實時通信（RTC）。它使用一系列的協議和技術來實現這一點。下面是一些關鍵部分：

1. RTP（實時傳輸協議）：用於媒體數據（例如音頻和視頻）的傳輸，通常基於UDP。
2. STUN/TURN/ICE：這些協議和技術用於 NAT 穿透和對等節點發現。STUN 和 TURN 伺服器協助 WebRTC 節點找到彼此並建立直接連接。TURN 伺服器可以在需要時中轉數據，可能使用 TCP 或 UDP。
3. 信令：WebRTC 本身不規定信令協議。信令用於在通信的兩個端點之間交換元信息，例如呼叫設置、能力協商等。這可以通過各種方式實現，例如使用 WebSocket、HTTP 或其他協議，通常基於 TCP。

所以，WebRTC 使用了多個協議，其中一些是基於 UDP 的（如 RTP 和某些 TURN 場景），而其他一些可能是基於 TCP 的（如信令或當 TURN 使用 TCP 時）。

上圖展示了整個WebRTC所運用的協定架構，左邊(TCP)為Signal應用，右邊(UDP)為串流應用， 協定堆的搭配使用，補足彼此的不足，而本章主要專注在串流應用(右邊)上的協定上，為WebRTC提供了哪些功能。

SRT（Secure Reliable Transport）協定

SRT（Secure Reliable Transport）是一種基於UDP的開源傳輸協定，由Haivision公司發起並由SRT聯盟持續開發。它的主要目的是優化在公共網路（如互聯網）上進行高品質視訊串流的性能。

SRT旨在解決在廣播等高品質視訊串流場景下，對於低延遲、丟包率低的傳輸要求。它在UDP之上實現了數據包重傳機制，並且加入了AES加密，以確保傳輸的安全性。此外，SRT還提供了一個預測網路傳輸性能的機制（稱為「SRT預測模型」），該模型可動態調整傳輸參數，以優化傳輸性能並減少延遲。

因此，SRT協定將UDP的低延遲特性與TCP的可靠傳輸特性相結合，旨在在公共網路上提供一種安全、可靠、低延遲的視訊傳輸解決方案。這使得它在如廣播、遠程生產和OTT串流等領域中得到了廣泛應用。

SRT 加入了一些特性來強化它的穩定性和效能，這使得它能夠對傳輸過程進行更細膩的控制，同時也提供了比 TCP 更低的延遲。

這些特性包括：

1. 數據包重傳：如果檢測到數據包丟失，SRT 會嘗試重新傳輸這些丟失的數據包，這樣就可以保證數據的完整性。
2. 端到端的安全性：SRT 支持數據加密，確保數據在傳輸過程中的安全性。
3. 低延遲：相比 TCP，UDP 的傳輸延遲更低，這使得 SRT 更適合實時或近實時的視訊串流。

SRT通常不直接在網頁上播放的原因也是因為他是使用UDP的傳輸協定：

1. 協議支援：瀏覽器通常支援的協議，如HTTP和WebSocket，是基於TCP的。這些協議被廣泛用於Web應用程序中，因為它們提供了可靠的連接和內建的流控制。由於SRT是基於UDP的，它不是瀏覽器原生支援的協議之一。
2. UDP的限制：UDP不保證資料包的到達順序或可靠性。SRT在此基礎上增加了一些特性來改善這些問題，但這並不意味著它可以直接在所有客戶端上使用。瀏覽器可能因安全和可靠性的考量而限制或不支援UDP流量。
3. 轉碼和轉封裝：為了在網頁上播放SRT流，可能需要額外的伺服器組件來轉碼或轉封裝流為瀏覽器支援的格式，例如HLS或MPEG-DASH。這可能增加了複雜性和延遲。
4. 安全性考量：網頁的安全模型可能限制了直接使用UDP的能力。WebRTC是一個允許網頁使用UDP的技術，但即使如此，它也需要符合特定的安全和隱私要求。