智慧財產權與網際網路/流媒體

流媒體是不斷由流媒體提供商提供並呈現在終端使用者面前的多媒體。使用流媒體，客戶端瀏覽器或外掛可以在整個檔案傳輸完成之前開始顯示資料。 該名稱指的是媒體的交付方式，而不是媒體本身。這種區別通常應用於透過電信網路分發的媒體，因為大多數其他交付系統要麼天生就是流媒體（例如，廣播、電視），要麼天生就不是流媒體（例如，書籍、錄影帶、音訊 CD）。動詞“流”也源於此術語，意思是透過這種方式交付媒體。網際網路電視是一種常見的流媒體。流媒體可以是影片和音訊之外的其他內容。即時閉幕字幕和股票程式碼被認為是流媒體文字，即時文字也是如此。

即時流媒體，透過網際網路進行即時交付，涉及一個媒體攝像頭，一個編碼器來數字化內容，一個媒體釋出者，以及一個內容分發網路來分發和交付內容。

歷史

在 20 世紀中葉計算的早期，人們就嘗試在計算機上顯示媒體。然而，在幾十年的時間裡，幾乎沒有取得進展，這主要歸因於計算機硬體的高成本和有限的能力。

從 20 世紀 80 年代後期到 90 年代，消費級個人計算機變得足夠強大，可以顯示各種媒體。與流媒體相關的首要技術問題是

• 具有足夠的CPU 能力和匯流排頻寬來支援所需的資料速率
• 在作業系統 (OS) 中建立低延遲中斷路徑，以防止緩衝區下溢。

然而，計算機網路仍然有限，媒體通常透過非流媒體渠道交付，例如從遠端伺服器下載數字檔案，然後將其儲存到終端使用者計算機上的本地驅動器，或者將其儲存為數字檔案並從CD-ROM中播放。

在 20 世紀 90 年代後期和 21 世紀初，網際網路使用者看到了

• 更大的網路頻寬，尤其是在最後一英里
• 更多網路訪問許可權，尤其是網際網路
• 使用標準協議和格式，例如TCP/IP、HTTP 和HTML
• 網際網路的商業化。

嚴重輪胎損壞是第一個在網際網路上進行現場演出的樂隊。1993 年 6 月 24 日，該樂隊在施樂 PARC 舉行了一場演出，而大樓的其他地方，科學家們正在討論新的技術（Mbone），用於使用多播在網際網路上廣播。作為其技術的證明，該樂隊被廣播，並且可以在澳大利亞和其他地方被即時觀看。

RealNetworks也是流媒體市場的先驅，他們在 1995 年透過網際網路廣播了早期音訊活動之一 - 揚基隊與西雅圖水手隊的棒球比賽。 他們在 1997 年推出了第一款流媒體影片技術，即RealPlayer。

當Word 雜誌在 1995 年推出時，他們在網際網路上推出了第一個流媒體配樂。他們使用當地的市中心音樂家，第一個音樂流是 Karthik Swaminathan 的“大輪子”，第二個是 Karthik Swaminathan 與Marc Ribot和 Christine Bard 合作的“當我們貧窮時”。

不久之後，在 1996 年初，微軟開發了一種名為ActiveMovie的媒體播放器，該播放器允許流媒體，幷包含專有的流媒體格式，它是後來在 1999 年的Windows Media Player 6.4 中的流媒體功能的繼任者。

1999 年 6 月，蘋果還在其Quicktime 4 應用程式中引入了一種流媒體格式。它後來也被廣泛應用於網站，以及 RealPlayer 和 Windows Media 流媒體格式。網站上的競爭格式要求每個使用者下載相應的應用程式以進行流媒體播放，導致許多使用者不得不將其計算機上安裝所有這三種應用程式以確保通用相容性。

大約在 2002 年，人們對單一、統一的流媒體格式的興趣以及Adobe Flash在計算機上的廣泛應用，促使人們透過 Flash 開發了一種影片流媒體格式，這是如今許多流行的影片託管網站（例如YouTube）中使用基於 Flash 的播放器中的格式。

不斷增長的使用者對即時流媒體的需求促使 YouTube 為使用者實施了其新的即時流媒體服務。

計算機網路的這些進步，加上功能強大的家用電腦和現代作業系統，使流媒體對普通消費者來說既實用又經濟實惠。獨立的網際網路廣播裝置出現，為聽眾提供無需計算機即可收聽音訊流的選擇。

一般來說，多媒體內容的體積很大，因此媒體儲存和傳輸成本仍然很高。為了在一定程度上抵消這一點，媒體通常會被壓縮，用於儲存和流媒體。

不斷增長的使用者對高畫質 (HD) 內容在家庭中不同裝置上的流媒體需求，促使業界開發了一系列技術，例如無線高畫質或ITU-TG.hn，它們針對流媒體高畫質內容進行了最佳化，無需使用者安裝新的網路電纜。

如今，媒體流可以進行即時流媒體或點播流媒體。即時流媒體通常透過一種稱為真流媒體的方式提供。真流媒體直接將資訊傳送到計算機或裝置，而不會將其儲存到硬碟。點播流媒體透過一種稱為漸進式流媒體或漸進式下載的方式提供。漸進式流媒體將檔案儲存到硬碟，然後從該位置播放。點播流媒體通常會儲存到硬碟和伺服器，供較長的時間使用；而即時流媒體僅在特定時間可用（例如，在足球比賽期間）。

隨著平板電腦和智慧手機等移動裝置的普及，這些裝置都依賴電池續航，數字媒體流的發展如今集中在不依賴 Adobe Flash 的格式上——Adobe Flash 以其相對較高的計算機資源使用量而聞名，因此會影響移動裝置的電池續航時間。

流媒體頻寬和儲存

例如，要將電影流式傳輸到 Apple TV、Google TV 或索尼電視藍光光碟播放器，建議使用 2.5 Mbit/s 或更高的寬頻速度，而對於高畫質內容，則建議使用 10 Mbit/s。

即使是流式傳輸相同內容，單播連線也需要來自同一個流伺服器的多個連線

流媒體儲存大小根據以下公式計算流媒體頻寬和媒體長度（對於單個使用者和檔案）：

儲存大小（以 兆位元組 為單位）= 長度（以秒為單位）× 位元率（以位元/秒為單位）/（8 × 1024 × 1024）

現實世界的例子

以 300 kbit/s 編碼的影片（這是 2005 年的典型寬頻影片，通常以 320 × 240 畫素的視窗大小編碼）將是

（3,600 s × 300,000 bit/s）/（8×1024×1024）大約需要 128 MiB 的儲存空間。

如果該檔案儲存在伺服器上以供按需流式傳輸，並且該流同時被 1,000 人使用 單播 協議觀看，則要求

300 kbit/s × 1,000 = 300,000 kbit/s = 300 Mbit/s 的頻寬

這相當於每小時大約 135 GB。使用 多播 協議，伺服器只發送一個對所有使用者通用的流。因此，此類流僅使用 300 kbit/s 的服務頻寬。有關這些協議的更多資訊，請參見下文。

直播的計算方法類似。

假設：編碼器的速度為 500 kbit/s。

如果節目持續 3 小時，有 3,000 名觀眾，則計算結果為

傳輸的 MiB 數 = 編碼器速度（以位元/秒為單位）× 秒數 × 觀眾數 /（8*1024*1024）

傳輸的 MiB 數 = 500,000（位元/秒）× 3 × 3,600（= 3 小時）× 3,000（觀眾數）/（8*1024*1024）= 1,931,190 MiB

編解碼器、位元流、傳輸、控制

音訊流使用音訊編解碼器進行壓縮，例如 MP3、Vorbis 或 AAC。

影片流使用影片編解碼器進行壓縮，例如 H.264 或 VP8。

編碼的音訊和影片流組裝在容器位元流中，例如 FLV、WebM、ASF 或 ISMA。

位元流使用傳輸協議從流伺服器傳遞到流客戶端，例如 MMS 或 RTP。

流客戶端可以使用控制協議與流伺服器進行互動，例如 MMS 或 RTSP。

協議問題

設計支援流媒體的網路協議會引發許多問題，例如

• 資料報 協議（例如 使用者資料報協議 (UDP)）將媒體流傳送為一系列小資料包。這很簡單且高效；但是，協議中沒有機制保證交付。接收應用程式負責檢測丟失或損壞並使用 糾錯 技術恢復資料。如果資料丟失，流可能會出現 中斷。
• 即時流協議 (RTSP)、即時傳輸協議 (RTP) 和 即時傳輸控制協議 (RTCP) 是專門為透過網路流式傳輸媒體而設計的。RTSP 在各種傳輸協議上執行，而後兩者則建立在 UDP 之上。
• 另一種似乎融合了使用標準 Web 協議的優點以及能夠用於流式傳輸即時內容的能力的方法是 HTTP 自適應位元率流。HTTP 自適應位元率流基於 HTTP 漸進式下載，但與之前的方法不同，這裡檔案非常小，因此可以與資料包流式傳輸相比，就像使用 RTSP 和 RTP 的情況一樣。
• 可靠的協議（例如 傳輸控制協議 (TCP)）保證媒體流中每個位元的正確傳遞。但是，它們透過超時和重試系統來實現這一點，這使得它們更難以實施。這也意味著，當網路上發生資料丟失時，媒體流會停止，直到協議處理程式檢測到丟失並重新傳輸丟失的資料。客戶端可以透過緩衝資料以供顯示來最大程度地減少這種影響。雖然緩衝造成的延遲在影片點播場景中是可以接受的，但如果緩衝帶來的延遲超過 200 毫秒，視訊會議等互動式應用程式的使用者將體驗到保真度的下降。
• 單播 協議從伺服器向每個接收者傳送媒體流的獨立副本。單播是大多數網際網路連線的標準，但在許多使用者想要同時觀看同一 電視節目 時，擴充套件性不佳。

多播將多媒體的同一副本廣播到整個網路上的一個客戶端組

• 多播 協議的開發是為了減少當多個接收者獨立地接收單播內容流時發生的資料複製（以及隨之而來的伺服器/網路負載）。這些協議從源頭向一個接收者組傳送一個流。多播傳輸是否可行取決於網路基礎設施和型別。多播的一個潛在缺點是失去了 影片點播 功能。無線電或電視材料的連續流式傳輸通常會阻止接收者控制播放。但是，快取伺服器、數字 機頂盒 和緩衝的 媒體播放器 等元素可以減輕此問題。
• IP 多播 提供了一種將單個媒體流傳送到 計算機網路 上一組接收者的方式。多播協議，通常是 Internet 組管理協議，用於管理將多播流傳遞到 LAN 上的接收者組。部署 IP 多播的挑戰之一是，LAN 之間的路由器和防火牆必須允許透過傳送給多播組的資料包。如果提供內容的組織控制著伺服器和接收者之間的網路（例如，教育機構、政府機構和企業 內聯網），那麼可以使用 協議獨立多播 等路由協議將流內容傳遞到多個 區域網 段。
• 點對點 (P2P) 協議安排預先錄製好的流在計算機之間傳送。這可以防止伺服器及其網路連線成為瓶頸。然而，它引發了技術、效能、質量和業務問題。