目錄

• 一、綜述
• • 需求分析
  • 協議定制
• 二、MPEG2-TS協議
• 三、RTSP協議、RTP、RTCP、SDP
• • RTSP
  • RTP、RTCP、SDP
• 四、RTMP
• 五、HLS、HDS、HSS
• • HLS
  • HDS和HSS
• 六、MPEG-DASH
• • 協議具體內容
  • 應用
• 七、流媒體服務器
• • 流媒體服務器的功能與挑戰
  • • 客戶端支持
    • 協議支持
    • 應用場景
    • 應用特點
    • 擴展技術
    • • 廣告投放
      • 錄屏
      • 其他

一、綜述

需求分析

流媒體技術需要解決的問題：

1.允許客戶端在不下載完整文件的時候即可以開始播放視頻；

2.允許客戶端從完整內容的任何位置開始播放（不包括視頻直播）；

3.針對視頻直播，允許客戶端從任意時間開始觀看頻道內容；

4.允許在客戶的帶寬條件和客戶端的硬件條件下播放；

5.提供相對平穩的傳輸速度，以便用戶基本流暢地完成播放。

并伴隨兩個衍生技術：

1.支持CDN傳輸，以提供服務擴展能力和較好的用戶訪問質量。

2.支持視頻內容的加密，避免版權內容被人依靠復制傳播牟利

協議定制

設計流媒體網絡協議需要注意的問題：

1、協議應對傳輸的音視頻格式進行規約，保證客戶端可以容易解析并啟動播放，并且數據冗余較小

2、流媒體的需求決定了數據必然將被分成較小的片段進行發送

3、是倚仗TCP的保證送達機制，還是基于UDP但加入糾錯能力，客戶端又如何應對數據缺失的狀況

4、協議應具備機制幫助客戶端可以盡量勻速或按可控的速度獲取到視頻數據

二、MPEG2-TS協議

MPEG2-TS 稱Transport Stream或TS，是ISO/IEC標準13818-1或ITU-TRec.H.222.0中規定的標準的音視頻傳輸協議，因傳輸的Packet可不經轉換地存到文件中，又可被視為文件格式。

TS流可視為由一系列188字節的包組成（在一些擴展中可能有不同長度）的“列車”，包頭固定為4字節，以0x47作為同步碼起始，其中的關鍵信息是PID。

TS流由對一個或多個PES碼流進行再封裝得到，也即一個TS流可以包含多個PES流，一個音頻PES包需要小于或等于64KB，視頻PES包即是視頻的一幀，由于TS包的負載大小僅為184字節，一個PES包需要被分成多個TS包進行傳輸。
除了數據，TS流中還需要Program Specific Information 信息。

·PAT（Program Association Table，節目關聯表）。

·PMT（Program Map Tables，節目映射表）。

·CAT（Conditional Access Tables，條件訪問表）。

·NIT（Network Information Table，網絡信息表）。

·TSDT（Transport Stream Description Table，傳輸流描述表）。

客戶端收到一個PAT包，則可以獲得TS流中包含的所有節目和節目表好，以及不同節目對于PMT的PID值，同時也提供了NIT的PID。

PMT表用于指示組成某一頻道的視頻、音頻或數據，可查到其PID值，以及節目時鐘PCR的PID。

故而當客戶端獲取PAT和PMT包之后，即可了解TS流中包含哪些內容。

PID描述了TS流內所包含PES流的信息，用于拼接連續的包。

三、RTSP協議、RTP、RTCP、SDP

RTSP

RTSP通常與RTP和RTCP協議共同使用，其中RTSP是服務端與客戶端間的雙向協議，它不負責傳輸音視頻數據，而是用來控制多個音視頻流。

它基于TCP建立會話，與HTTP1.1類似。

一次使用RTSP協議的播放過程：

RTSP通過不同的命令構建完整的控制會話，同時依賴RTP和RTCP或其他協議傳輸音視頻本身的數據。

一次典型的播放過程將在客戶端和服務器間建立5個不同的Session：一路RTSP的Session、兩路RTP的Session（音頻和視頻各一）以及兩路RTCP Session（分別對應兩路RTP Session），占用5個不同的端口（RTSP協議的默認端口是554，RTP及RTCP的端口由SETUP命令指定）

RTSP協議支持重定向，即將播放會話重定向，讓其他服務器提供服務。協議也可選擇不同的傳輸通道，例如基于TCP、UDP以及組播UDP傳輸RTP協議

RTP、RTCP、SDP

RTP是Real-time Transport Protocol的簡稱

RTP協議將不同編碼和封裝格式的音視頻數據進行再封裝，加上RTP頭形成RTP包，再行發送，RTP包頭內的重要信息包括序列號、時間戳、負載格式等。

RTP協議提供抖動補償和數據無序到達的檢測機制。

RTCP即RTP Control Protocol，協議本身并不發送數據，而是收集客戶端的統計信息，包括傳輸字節數、傳輸分組數、丟失分組數、網絡延遲、Jitter（抖動）等，服務器可籍此改變碼率或調節數據發送速度。

Session DescriptionProtocol（會話描述協議）用于和RTSP以及SIP等協議協同工作。

SDP同樣基于文本，前述RTSP協議中DESCRIBE命令的回復即是SDP格式，SDP的格式異常簡單，由多個<類型>=<值>的字符串組成，用于描述會話信息，也用于描述音視頻的類型和格式，所需要的帶寬、時間范圍甚至郵件地址、編碼參數等。

允許雙向交換信息，使用多達5個會話交換數據的RTSP方式流媒體傳輸，很像是在雙向多車道的馬路上奔馳，無疑很大程度上解決了交通的問題，但“成也蕭何，敗也蕭何”，多車道對資源的占用或許就是被后來的RTMP等協議擠占的根源。

四、RTMP

RTMP（Real-Time Messaging Protocol，即實時消息傳輸協議）

RTMP并非一個單獨協議，而是由多個相關協議組成的協議族。

1.RTMP，默認使用TCP端口1935的明文協議。

2.RTMPS，即通過TLS/SSL連接傳輸的RTMP。

3.RTMPE，使用Adobe私有安全機制加密的RTMP。

4.RTMPT，使用HTTP封裝的RTMP、RTMPS或RTMPE，利于穿透防火墻。

5.RTMPFP，使用UDP的RTMP，允許用戶進行P2P連接。

RTMP是基于TCP的可靠傳輸層協議，僅需一個會話即可相互通信，與RTSP協議相比，如同由軌道支撐的高速鐵路，雖然形式略重，但效率高、速度快。

將音視頻及其他數據封裝為RTMP Message發送，而在實際傳輸時會進一步將Message劃分為帶有Message ID的Chunk。每個Chunk可以攜帶一個Message。但更多情況下，一個Message將由多個Chunk承載，直到客戶端接收后將其還原。Chunk Stream是基于RTMP Chunk的邏輯抽象，客戶端將據此區分不同類型的數據并組織接收以及還原。
BasicHeader可被擴展一到兩個字節［stream id（c）］，Chunk Header則含有如Message長度等信息。

建立TCP連接后，RTMP協議會要求進行3個包的握手代表連接的建立，客戶端發送一個代表協議版本號的0x03初始化連接，隨后發送1536個字節（包括4個字節的時間戳消息、4個值為0的字節以及1528個隨機生成的字節），服務器亦將發送0x03的版本消息、1536字節消息，客戶端和服務器隨后發送回聲字節（本方及對方的時間戳對以及1528個隨機字節），并在收到后確認連接的建立.

實踐中，由于只要滿足了接收條件，即可建立RTMP連接，為減少交互次數，縮短連接建立時間，可以采用以下順序：客戶端發送C0和C1，服務端回復S0、S1和S2，客戶端發送C2。

當握手完畢后，連接將被復用來發送一個或多個Chunk流，Chunk的默認大小為128字節，由客戶端和服務器設置其可以接受的Chunk大小（可以動態調整），Chunk承載的Message類型不同，其Message Header亦有多種，不同的fmt取值將用以鑒別不同的Chunk類型。

RTMP協議定義了一些特殊的值來表示控制消息。

RTMP還定義了Command、Data、Audio、Video、Aggregate、Shared Object等多類消息，其中Command Message如下

RTMP協議支持Push和Pull兩種模式，Pull即是普遍的客戶端根據URL進行播放的方式，而Push基于RTMP的視頻直播，其握手順序和createStream步驟類似，由客戶端使用Publish命令而非Play命令，發起自客戶端到服務端的推送。

RTMP協議在進行視頻服務時，對動態碼率切換廣告插入、播放列表、直播頻道快速切換等較為無力，故而在許多解決方案中，被設計以通過SMILSMIL格式是一種描述多媒體集成的格式，常用于和RTMP協議一道構建流媒體服務，但應用范圍遠不限于此。的方式與服務器進行帶外通信。使用SMIL進行碼率切換的示例。

五、HLS、HDS、HSS

RTSP和RTMP是基于會話的流媒體協議，HLS(Http Live Streaming)、HDS(Http Dynamic Streaming)和Smooth Streaming(HSS)則是基于HTTP的協議。

HLS

協議的原理是將點播所需的多媒體文件或直播的視頻流，切分成許多小塊的文件，讓客戶端基于HTTP進行下載，當播放時，客戶端需下載包含metadata信息的M3U8文件（也稱作索引文件、Playlist或Manifest文件），根據M3U8文件的內容，同時依據網絡條件選擇不同碼率的內容進行播放。

HLS支持如下音視頻格式，首先是MPEG2-TS或fMP4（即Fragmented MP4）格式封裝的切片文件（Segment）。其次，它支持打包的純音頻格式，包括以ADTS頭封裝的AAC幀、MP3、AC3和EAC3格式，對字幕，它只支持WebVTT格式

一個點播文件的M3U8示例如下

#EXTM3U、#EXT-X-TARGETDURATION等是M3U8文件規定的tag，其中包括原有的定義和由蘋果擴展的tag，這個點播文件一共21s，分為3個TS的Segment。

直播的M3U8示例如下
此例中，協議希望客戶端規律地訪問服務器（例如7.975s訪問一次）以觀察是否有Segment持續被更新，而Segment的文件名也按順序增加。

多碼率的視頻流的Master類型M3U8示例，描述了高、中、低三種碼率的音視頻流以及一路僅包含音頻內容的AlternativeM3U8的訪問URL

多碼率HLS流的組織結構：

特點：

HLS協議的一大特點在于，將以往RTSP、RTMP等協議中實現復雜的多碼率、多音軌的音視頻流變得容易，并可以明晰地表達、理解和優化，在協議中規定需要傳遞給客戶端的信息可以由Master和Alternative兩種M3U8來表達。

在此設計中，客戶端承擔起了碼率控制和選擇的主要職責，每個播放器可以根據自己的網速選擇合適的碼率播放，并在網絡環境波動或某些文件下載失敗的情況下切換到其他碼率，保持流暢播放，服務端則對緩存和CDN友好，毋需針對不同用戶予以不同處理。

HLS協議支持在同一視頻流中提供不同編碼器的音頻或視頻流供客戶端選擇，于播放會話中，客戶端根據自己的需求，切換碼率進行下載播放。同一機制也可用于多語言的支持，對不同語言分提供不同的音軌。為支持多碼率、多語言或不同Codec的切換，在節目制作時，應保證不同碼率的流中，所有視頻關鍵幀其時間戳完全對齊，否則客戶端難以正確工作。

Tag功能

HLS協議中定義了許多不同的Tag以支持各類功能。例如EXT-X-DISCONTINUITY意味著后續的Segment和前面的內容并不連續，或許是Codec有所變化；EXT-X-I-FRAME-STREAM-INF可用于在Playlist中定義一個全由I幀組成的流，通常由縮略圖預覽使用；在直播流中，嵌入形如#EXT-X-PROGRAM-DATE-TIME：2018-0219T14：54：23.031+08：00的Tag將指明下一個Segment中第一幀對應的絕對時間，可用于估量直播流的延遲；EXT-X-DATERANGE用于指定一段時間內的特征，例如SCTE-35信息。

首先，早期的HLS流中大多使用固定長度為10s的Segment文件，但在啟動時間和直播延遲上并不令人滿意，現今常見的Segment長度根據不同公司的需求被設置成1～6s不等，在同一音視頻流的不同碼率間保持一致。

其次，為便于TS流的解析，PSI包即PAT/PMT表應插在Segment的頭部，且視頻的關鍵幀亦應置于Segment的頭部，每個Segment中的視頻由一個完整GOP組成是常見的做法。

蘋果公司于2010年即將HLS協議提交為RFC，隨后的多年中對其不斷修訂，添加新的功能，但正因此，使用者需要注意協議的版本，較舊的設備或客戶端可能不支持某些新的功能，需要慎用。

HDS和HSS

與HLS同一時期制定的，具備相似特性（基于HTTP、支持多碼率、音視頻文件切片）的流媒體協議另有Adobe推出的HDS（HTTP Dynamic Streaming）和微軟推出的SmoothStreaming，它們與MPEG-DASH一道，被稱作AdaptiveBitrate Streaming技術（碼率自適應的流媒體技術）。

HDS由Adobe自己的Flash Media Server支持，其文件格式為FLV、F4V和MP4，索引文件格式為F4M，支持直播和時移電視。

多碼率、多音軌的F4M文件示例。

微軟的Smooth Streaming是IIS服務器的多媒體服務擴展，支持PIFF格式的MP4文件，后綴為ISMV和ISMA，索引文件為ISM或ISMC，同樣支持直播和時移電視

多碼率的ISM文件示例

與服務端主導的舊式協議之間相區別，以HLS為代表的流媒體協議給予客戶端極大的自由，并對Web服務器和CDN有天然的親和性，讓傳輸過程走向更加靈活和個性化的方向。

六、MPEG-DASH

MPEG-DASH是由MPEG牽頭開發的基于HTTP的自適應碼率流媒體技術，于2011年11月形成國際標準，其標準文檔為ISO/IEC 23009-1。

基于HTTP的流媒體協議流行，從環境上考量，主要的原因是HTTP協議對防火墻友好，又天然適合CDN以緩存的方式分發。

鑒于互操作性的需求，私有協議終歸不能成為主流，操作系統、瀏覽器的支持都將是促進標準化的推手，如果說之前各家推出的HLS、HDS、Smooth等協議是在用快遞物流替代集中購物，那么DASH就好比快遞公司接入了統一的菜鳥網絡，能夠以統一的方式提供服務。

協議具體內容

MPEG-DASH與前面介紹的HLS、HDS、Smooth Streaming的設計理念相近，將音視頻文件或直播流分割成一系列可下載播放的文件切片，使用MPD文件描述切片信息。

MPD內有時間戳、編碼、分辨率、碼率等信息，對音視頻內容的組織方式分為SegmentBase、SegmentTemplate、SegmentList和SegmentTimeline等類型，在客戶端對MPD文件解析后，再行下載所需的文件切片，交由播放器組裝并播放。

下面是不同基于HTTP的流媒體協議功能比較

DASH協議原則上可以支持任何編碼格式，作為指導意見，推薦使用與HLS協議兼容的TS文件或ISO-BMFF的擴展作為多媒體文件格式（即Fragmented MP4），后者的文件后綴多見.mp4、.m4v、.m4a或.m4s。DASH所使用的MP4文件擴展來自于微軟于2009年發布的PIFF文件擴展（ProtectedInteroperable File Format，如下圖），這意味著SmoothStreaming協議可以MPEG-DASH協議和在音視頻文件層面相互兼容。

DASH協議將對于音視頻流描述的部分（也即文件頭上的信息）封裝為init文件并于MPD文件中提供URL，任何時候客戶端均可單獨下載解析，這就避免了TS文件反復插入PSI信息的消耗，客戶端下載init文件后，則可任意下載切片文件播放（反之，切片將因缺少解碼信息無法播放）。針對音視頻，還可提供不同的init文件，增加客戶端的靈活度。

DASH中的MPD符合XML格式，協議定義了大量標簽以幫助描述，其中以Period定義一段連續的音視頻片段，每個Period內包含多各音視頻內容的集合（主要應用于多分辨率、幀率、碼率或者多語言，相互可以切換）稱作AdaptationSet，每個AdaptationSet內含多個Representation，即一個獨立的音頻或視頻流，每個Representation再由一系列的多媒體Segment組成。

DASH協議在播放期間并不能隨意從Representation切換，需要等到初始幀為一個關鍵幀的視頻Segment。若AdaptationSet中各個視頻流編碼時是以關鍵幀對齊的，則可以從不同的流間進行切換。

應用

一些現代瀏覽器（如Chrome、Edge、Firefox、Safari等）均對W3C標準定義的MSE（MediaSource Extension，媒體源拓展）和EME（Encrypted MediaExtensions，加密媒體擴展）進行了支持，將以往由插件提供的功能收歸瀏覽器，運用Javascript開發的網頁播放器只需下載MPD文件并解析，再將音視頻文件送給瀏覽器，就能很容易地播放。MSE和EME的詳細內容可參考W3C網站：

** MSE原理**

ESE原理

除瀏覽器以外，Android、Chrome、Roku等多種平臺上均有對MPEG-DASH的支持。在不支持DASH的平臺上，亦可通過移植瀏覽器（Chromium，Chrome的開源版本）的方式加入視頻播放功能。DASH協議為統一混亂的流媒體市場推進了一大步，但由于DASH和HLS的互不兼容，意味著為支持各類設備的全覆蓋，在線視頻服務商需要準備MPD和M3U8兩種Manifest文件，更糟的是，需要編碼fMP4和TS兩份不同的音視頻文件，同時，拋開研發和存儲的成本，CDN將需要在所有邊緣節點上存儲兩份視頻文件，這意味著雙倍的成本。

為避免上述尷尬的局面，微軟、思科、蘋果、Comcast等公司發起了CMAF標準（CommonMedia Application Format，通用媒體應用格式），這份標準統一了視頻文件的容器格式，不論HLS，還是DASH，都可以使用同一份節目內容，在需要加密保護的場景，也可通過不同的DRM方案加密或解密同一份文件。此外，CMAF的一項新設計即對數秒長度的切片再分塊傳輸，也對HTTP類型的流媒體協議最令人詬病的延遲問題大有裨益。

下面是CMAF的對象模型:

七、流媒體服務器

如同物流體系里物流中心的概念一樣，流媒體服務器負責內容的高效分發。

雖然由于近年基于HTTP的流媒體協議大行其道，通用HTTP服務器附加流媒體協議插件的方案廣泛應用，侵占了支持多協議的專用流媒體服務器的市場份額，但鑒于通用HTTP服務器和專用流媒體服務器之間對于高I/O、高并發、低延遲以及高可靠的追求高度一致，充分理解相關技術仍然對流媒體體系的搭建和優化非常重要。

流媒體服務器的功能與挑戰

功能需求囊括點播和直播兩類。

點播服務需要將硬盤或其他存儲設備上的音視頻文件轉化成流媒體傳輸協議規定的一系列包（Packet），發送給不同的客戶端。

直播服務則需要先將基于IP網絡，由流媒體協議封裝的音視頻流導入服務器，再通過服務器轉化成不同設備可以接收的流媒體封裝，發送給各個客戶端。

客戶端支持

服務器面對的客戶端多種多樣，電腦上有Chrome、Edge、IE、Firefox、Opera、Safari等瀏覽器，也有VLC、QQ影音、暴風影音等播放器，其他設備從舊式基于嵌入式Linux或Symbian、黑莓系統的智能手機，到現代的蘋果或Android設備，從Roku、FireTV、小米盒子類型的機頂盒到XBox、Play Station、Nintendo系列游戲機，從Chromecast類的無線投影設備到Oculus、Vive、HoloLens等虛擬現實、增強現實設備，各個設備上的音視頻應用均是目標服務對象。

協議支持

不論點播，還是直播，由于不同的流媒體協議規定了不同的傳輸格式，也即對相同的音視頻編碼格式基礎上采取了不同的封裝，所以服務器主要的工作是

1、將文件轉化為流媒體協議

2、流媒體協議轉化為文件

3、一種流媒體協議轉化為另一種流媒體協議

轉化時根據文件格式和流媒體協議格式進行解包和封包（英文是Packetize和De-packetzie）

以H.264和AAC格式的音視頻內容，在傳輸時需要封裝為NAL格式和ADTS、LOAS格式，再封裝到不同的協議包中，例如RTP包、TS包等，以此為單位發送或接收。

自服務器到客戶端的流媒體傳輸，利用了前文介紹的MPEG2-TS、RTSP/RTP、RTMP、HLS、MPEG-DASH等協議。

MPEG2-TS和其他流媒體協議的不同之處在于，它只能用于主動推流的Push模式，而其他協議可能采取Pull或Push兩種不同模式。

MPEG2-TS主要適用于有線電視領域，任何用戶默認都是持續接收電視節目，其他協議則在設計時較多地考慮由客戶端按需發起流媒體的傳輸連接。服務器導入直播流時，于不同的場景可以采取Pull和Push兩種方式。

應用場景

流媒體服務器常見的應用位置是視頻網站的源站，以及CDN服務中包括源站（Origin）、中間站（Proxy）、邊緣站（Edge）在內的各級節點，構成視頻分發的核心。

流媒體服務器根據所部署的位置，可以被定義成不同角色，如Publisher和Subscriber，Publisher即源站或上游站，Subscriber即下游站或邊緣站，則對于直播流服務器而言，我們面對的主要問題是如何可靠和低延時地將流分發到邊緣節點，對點播服務，請求邊緣節點上不存在的視頻會導致回源請求，而訪問過的文件片段將被緩存在邊緣節點以供下次訪問，服務器的特殊挑戰是如何高效地對緩存進行使用和管理。

專門的CDN服務商需要對服務器進行改造，實現VirtualHosting功能，其主要概念是對一臺服務器進行虛擬化拆分。由于客戶大小不同，對不同地域的邊緣服務大半僅是零散地使用，為每個客戶單獨分配計算、存儲和網絡資源并不經濟，其使用的流媒體服務器，可以根據用戶請求的資源信息或Cookie分辨出其來自于哪家客戶，在服務器內部的按需分配資源和計費）。

應用特點

針對于點播流：

對HTTP服務器而言，需要緩存的文件片段是基于Range請求獲得的。

可以假設是某一個文件的從3000到7000字節，但于音視頻文件則略有不同，由于視頻關鍵幀概念的存在，獲取或存儲不完整的GOP數據并無意義，因此不論返回用戶請求的內容還是在本地緩存音視頻片段，都以貼近所請位置的GOP為單位較有效率，此時緩存中應有音視頻片段對應的時間戳信息以便索引。

針對直播流：

因為用戶可以從任意時間開始觀看，為節約帶寬并加快播放啟動的速度，服務器應從自身持有的音視頻流的隊列中找到關鍵幀，由該處起始服務，避免發送不完整的GOP數據。

當用戶在不同頻道間切換時，如果音視頻格式相同，流媒體服務器可以使用當前與用戶之間的連接，從新頻道的關鍵幀開始發送等方法（見圖4-25），達到最佳的用戶體驗。

因為視頻流的傳輸受到帶寬、網絡傳輸穩定性、客戶端等待渲染等多方面限制，從編碼器、源站服務器、代理服務器到邊緣站服務器，以及播放器本身，每一個環節都會保持一份緩存，這有助于整個傳輸過程的流暢，但代價即是播放器的播放存在延遲，若在直播情況下，還將導致看到的節目系數秒乃至數十秒之前所發生的內容。服務器內部通常維護的Packet隊列，可根據不同場景調整大小，在直播特有的追求低延時的場景下，該隊列甚至可以被取消，即服務器收到任一Packet都會立刻處理轉發。

流媒體服務器由于其流式服務的特性，對可靠性提出了極高的要求，畢竟用戶偶爾訪問網頁失敗，只需刷新重試即可獲得服務，但視頻播放中途失敗對用戶體驗的打擊要大得多，直播用戶可能希望繼續觀看適才錯失的片段，點播用戶則預期觀看進度可以被自動恢復。

較苛刻的服務器測試會構造各種模擬應用，經歷7天或更長時間的播放測試，覆蓋時間戳溢出，頻繁播放等用例。對直播服務在高并發環境下仍要求全天候無中斷的要求，服務器需支持熱備份，可行的方式是預先配置多個冗余的直播流，服務器負責判斷和切換，下圖給出了一種直播流冗余備份方案的示意。

擴展技術

廣告投放

不論點播抑或直播，對廣告的動態插入均是普遍需求，根據廣告投放的人群不同，其插入的位置有所不同。

對于直播服務：

例如，若將一份廣告如同電視頻道一樣期望投放給所有用戶，則首先適合在網站的編碼側直接編入直播流中，次選則是網站的直播源服務器上，替換原節目中的若干GOP，此時如廣告長度和被替換的GOP不同，可以考慮對廣告進行重新編碼，丟棄部分幀，對整個直播節目的Timeline進行調整等手段。

如果希望可以針對不同人群投放不同廣告，尤其是基于地理位置的投放，則投放可以在邊緣站的流媒體服務器上進行。

對于點播服務：

對于點播服務，可行的做法是直接嵌入廣告內容到實際內容之前

之后或某兩個GOP之間，此時需由服務器調整Timeline[插圖]，保證播放的連續性。由于在已有音視頻節目中嵌入廣告的技術復雜性，更實用的方法是向播放器提供形成包含廣告和實際節目的播放列表，將Timline的調整交由客戶端完成。

錄屏

針對直播服務的另一項常見需求，是用戶選擇對其中某個片段進行錄像，以便日后回味。在流媒體服務器上開發這項功能是常見的選擇，其中，與攝像采集設備一樣對音視頻流編碼沒有必要，相反，由于不論視頻還是音頻，各個流媒體協議定義的Packet都包含時間戳信息，對于視頻有每一幀的起止信息和是否關鍵幀的標記，很容易將其收集并轉換為視頻文件。

其他

傳統的流媒體服務器，除卻基本用途外，還承載了許多額外功能，例如服務器文件瀏覽，簡易的CMS（內容管理系統），循環播放，通過播放連接、時長、成功率、流量和存儲占用等統計進行計費等。由于單獨的流媒體服務器負責音視頻內容的分發，它需要提供完整的API，令視頻網站、內容導入、內容管理系統、廣告服務、調度系統、用戶交互系統、日志、計費等模塊可以采取細粒度的控制。