轉自：http://www.samirchen.com/video-concept/
視頻相關概念
視頻文件格式
文件格式這個概念應該是我們比較熟悉的，比如我們常見的 Word 文檔的文件格式是 .doc，JPG 圖片的文件格式是 .jpg 等等。那對於視頻來說，我們常見的文件格式則有：.mov、.avi、.mpg、.vob、.mkv、.rm、.rmvb 等等。文件格式通常表現爲文件在操作系統上存儲時的後綴名，它通常會被操作系統用來與相應的打開程序關聯，比如你雙擊一個 test.doc 文件，系統會調用 Word 去打開它。你雙擊一個 test.avi 或者 test.mkv 系統會調用視頻播放器去打開它。
同樣是視頻，爲什麼會有 .mov、.avi、.mpg 等等這麼多種文件格式呢？那是因爲它們通過不同的方式實現了視頻這件事情，至於這個不同在哪裏，那就需要了解一下接下來要說的「視頻封裝格式」這個概念了。
視頻封裝格式
視頻封裝格式，簡稱視頻格式，相當於一種儲存視頻信息的容器，它裏面包含了封裝視頻文件所需要的視頻信息、音頻信息和相關的配置信息(比如：視頻和音頻的關聯信息、如何解碼等等)。一種視頻封裝格式的直接反映就是對應着相應的視頻文件格式。
下面我們就列舉一些文件封裝格式：
- AVI 格式，對應的文件格式爲
.avi，英文全稱 Audio Video Interleaved，是由 Microsoft 公司於 1992 年推出。這種視頻格式的優點是圖像質量好，無損 AVI 可以保存 alpha 通道。缺點是體積過於龐大，並且壓縮標準不統一，存在較多的高低版本兼容問題。 - DV-AVI 格式，對應的文件格式爲
.avi，英文全稱 Digital Video Format，是由索尼、松下、JVC 等多家廠商聯合提出的一種家用數字視頻格式。常見的數碼攝像機就是使用這種格式記錄視頻數據的。它可以通過電腦的 IEEE 1394 端口傳輸視頻數據到電腦，也可以將電腦中編輯好的的視頻數據回錄到數碼攝像機中。 - WMV 格式，對應的文件格式是
.wmv、.asf，英文全稱 Windows Media Video，是微軟推出的一種採用獨立編碼方式並且可以直接在網上實時觀看視頻節目的文件壓縮格式。在同等視頻質量下，WMV 格式的文件可以邊下載邊播放，因此很適合在網上播放和傳輸。 - MPEG 格式，對應的文件格式有
.mpg、.mpeg、.mpe、.dat、.vob、.asf、.3gp、.mp4等等，英文全稱 Moving Picture Experts Group，是由運動圖像專家組制定的視頻格式，該專家組於 1988 年組建，專門負責視頻和音頻標準制定，其成員都是視頻、音頻以及系統領域的技術專家。MPEG 格式目前有三個壓縮標準，分別是 MPEG-1、MPEG-2、和 MPEG-4。MPEG-4 是現在用的比較多的視頻封裝格式，它爲了播放流式媒體的高質量視頻而專門設計的，以求使用最少的數據獲得最佳的圖像質量。 - Matroska 格式，對應的文件格式是
.mkv，Matroska 是一種新的視頻封裝格式，它可將多種不同編碼的視頻及 16 條以上不同格式的音頻和不同語言的字幕流封裝到一個 Matroska Media 文件當中。 - Real Video 格式，對應的文件格式是
.rm、.rmvb，是 Real Networks 公司所制定的音頻視頻壓縮規範稱爲 Real Media。用戶可以使用 RealPlayer 根據不同的網絡傳輸速率制定出不同的壓縮比率，從而實現在低速率的網絡上進行影像數據實時傳送和播放。 - QuickTime File Format 格式，對應的文件格式是
.mov，是 Apple 公司開發的一種視頻格式，默認的播放器是蘋果的 QuickTime。這種封裝格式具有較高的壓縮比率和較完美的視頻清晰度等特點，並可以保存 alpha 通道。 - Flash Video 格式，對應的文件格式是
.flv，是由 Adobe Flash 延伸出來的一種網絡視頻封裝格式。這種格式被很多視頻網站所採用。
從上面的介紹中，我們大概對視頻文件格式以及對應的視頻封裝方式有了一個概念，接下來則需要了解一下關於視頻更本質的東西，那就是視頻編解碼。
視頻編解碼方式
視頻編解碼的過程是指對數字視頻進行壓縮或解壓縮的一個過程。
在做視頻編解碼時，需要考慮以下這些因素的平衡：視頻的質量、用來表示視頻所需要的數據量（通常稱之爲碼率）、編碼算法和解碼算法的複雜度、針對數據丟失和錯誤的魯棒性（Robustness）、編輯的方便性、隨機訪問、編碼算法設計的完美性、端到端的延時以及其它一些因素。
常見的視頻編碼方式有：
- H.26X 系列，由國際電傳視訊聯盟遠程通信標準化組織(ITU-T)主導，包括
H.261、H.262、H.263、H.264、H.265。H.261，主要用於老的視頻會議和視頻電話系統。是第一個使用的數字視頻壓縮標準。實質上說，之後的所有的標準視頻編解碼器都是基於它設計的。H.262，等同於MPEG-2 第二部分，使用在 DVD、SVCD 和大多數數字視頻廣播系統和有線分佈系統中。H.263，主要用於視頻會議、視頻電話和網絡視頻相關產品。在對逐行掃描的視頻源進行壓縮的方面，H.263比它之前的視頻編碼標準在性能上有了較大的提升。尤其是在低碼率端，它可以在保證一定質量的前提下大大的節約碼率。H.264，等同於MPEG-4 第十部分，也被稱爲高級視頻編碼(Advanced Video Coding，簡稱 AVC)，是一種視頻壓縮標準，一種被廣泛使用的高精度視頻的錄製、壓縮和發佈格式。該標準引入了一系列新的能夠大大提高壓縮性能的技術，並能夠同時在高碼率端和低碼率端大大超越以前的諸標準。H.265，被稱爲高效率視頻編碼(High Efficiency Video Coding，簡稱 HEVC)是一種視頻壓縮標準，是H.264的繼任者。HEVC 被認爲不僅提升圖像質量，同時也能達到H.264兩倍的壓縮率（等同於同樣畫面質量下比特率減少了 50%），可支持 4K 分辨率甚至到超高畫質電視，最高分辨率可達到 8192×4320（8K 分辨率），這是目前發展的趨勢。
- MPEG 系列，由國際標準組織機構(ISO)下屬的運動圖象專家組(MPEG)開發。
MPEG-1 第二部分，主要使用在 VCD 上，有些在線視頻也使用這種格式。該編解碼器的質量大致上和原有的 VHS 錄像帶相當。MPEG-2 第二部分，等同於H.262，使用在 DVD、SVCD 和大多數數字視頻廣播系統和有線分佈系統中。MPEG-4 第二部分，可以使用在網絡傳輸、廣播和媒體存儲上。比起MPEG-2 第二部分和第一版的H.263，它的壓縮性能有所提高。MPEG-4 第十部分，等同於H.264，是這兩個編碼組織合作誕生的標準。
- 其他，AMV、AVS、Bink、CineForm 等等，這裏就不做多的介紹了。
介紹了上面這些「視頻編解碼方式」後，我們來說說它和上一節講的「視頻封裝格式」的關係。可以把「視頻封裝格式」看做是一個裝着視頻、音頻、「視頻編解碼方式」等信息的容器。一種「視頻封裝格式」可以支持多種「視頻編解碼方式」，比如：QuickTime File Format(.MOV) 支持幾乎所有的「視頻編解碼方式」，MPEG(.MP4) 也支持相當廣的「視頻編解碼方式」。當我們看到一個視頻文件名爲 test.mov 時，我們可以知道它的「視頻文件格式」是 .mov，也可以知道它的視頻封裝格式是 QuickTime File Format，但是無法知道它的「視頻編解碼方式」。那比較專業的說法可能是以 A/B 這種方式，A 是「視頻編解碼方式」，B 是「視頻封裝格式」。比如：一個 H.264/MOV 的視頻文件，它的封裝方式就是 QuickTime File Format，編碼方式是 H.264。
音頻編解碼方式
視頻中除了畫面通常還有聲音，所以這就涉及到音頻編解碼。在視頻中經常使用的音頻編碼方式有：
- AAC，英文全稱 Advanced Audio Coding，是由 Fraunhofer IIS、杜比實驗室、AT&T、Sony等公司共同開發，在 1997 年推出的基於 MPEG-2 的音頻編碼技術。2000 年，MPEG-4 標準出現後，AAC 重新集成了其特性，加入了 SBR 技術和 PS 技術，爲了區別於傳統的 MPEG-2 AAC 又稱爲 MPEG-4 AAC。
- MP3，英文全稱 MPEG-1 or MPEG-2 Audio Layer III，是當曾經非常流行的一種數字音頻編碼和有損壓縮格式，它被設計來大幅降低音頻數據量。它是在 1991 年，由位於德國埃爾朗根的研究組織 Fraunhofer-Gesellschaft 的一組工程師發明和標準化的。MP3 的普及，曾對音樂產業造成極大的衝擊與影響。
- WMA，英文全稱 Windows Media Audio，由微軟公司開發的一種數字音頻壓縮格式，本身包括有損和無損壓縮格式。
關於 H.264
概念
H.264 是現在廣泛採用的一種編碼方式。關於 H.264 相關的概念，從大到小排序依次是：序列、圖像、片組、片、NALU、宏塊、亞宏塊、塊、像素。
我們先來解釋幾個概念：
- 圖像。H.264 中，「圖像」是個集合的概念，幀、頂場、底場都可以稱爲圖像。一幀通常就是一幅完整的圖像。當採集視頻信號時，如果採用逐行掃描，則每次掃描得到的信號就是一副圖像，也就是一幀。當採集視頻信號時，如果採用隔行掃描（奇、偶數行），則掃描下來的一幀圖像就被分爲了兩個部分，這每一部分就稱爲「場」，根據次序分爲：「頂場」和「底場」。「幀」和「場」的概念又帶來了不同的編碼方式：幀編碼、場編碼。逐行掃描適合於運動圖像，所以對於運動圖像採用幀編碼更好；隔行掃描適合於非運動圖像，所以對於非運動圖像採用場編碼更好。
-
片(Slice)，每一幀圖像可以分爲多個片。
-
網絡提取層單元(NALU, Network Abstraction Layer Unit)，NALU 是用來將編碼的數據進行打包的，一個分片(Slice)可以編碼到一個 NALU 單元。不過一個 NALU 單元中除了容納分片(Slice)編碼的碼流外，還可以容納其他數據，比如序列參數集 SPS。對於客戶端其主要任務則是接收數據包，從數據包中解析出 NALU 單元，然後進行解碼播放。
-
宏塊(Macroblock)，分片是由宏塊組成。
顏色模型
我們聽過最多的顏色模型應該就是經典的 RGB 模型了。
在 RGB 模型中每種顏色需要 3 個數字，分別表示 R、G、B，比如 (255, 0, 0) 表示紅色，通常一個數字佔用 1 字節，那麼表示一種顏色需要 24 bits。那麼有沒有更高效的顏色模型能夠用更少的 bit 來表示顏色呢？
現在我們假設我們定義一個「亮度(Luminance)」的概念來表示顏色的亮度，那它就可以用含 R、G、B 的表達式表示爲：
Y = kr*R + kg*G + kb*B
Y 即「亮度」，kr、kg、kb 即 R、G、B 的權重值。
這時，我們可以定義一個「色度(Chrominance)」的概念來表示顏色的差異：
Cr = R – YCg = G – YCb = B – Y
Cr、Cg、Cb 分別表示在 R、G、B 上的色度分量。上述模型就是 YCbCr 顏色模型基本原理。
YCbCr 是屬於 YUV 家族的一員，是在計算機系統中應用最爲廣泛的顏色模型，就比如在本文所講的視頻領域。在 YUV 中 Y 表示的是「亮度」，也就是灰階值，U 和 V 則是表示「色度」。YUV 的關鍵是在於它的亮度信號 Y 和色度信號 U、V 是分離的。那就是說即使只有 Y 信號分量而沒有 U、V 分量，我們仍然可以表示出圖像，只不過圖像是黑白灰度圖像。在YCbCr 中 Y 是指亮度分量，Cb 指藍色色度分量，而 Cr 指紅色色度分量。
現在我們從 ITU-R BT.601-7 標準中拿到推薦的相關係數，就可以得到 YCbCr 與 RGB 相互轉換的公式：
Y = 0.299R + 0.587G + 0.114BCb = 0.564(B - Y)Cr = 0.713(R - Y)R = Y + 1.402CrG = Y - 0.344Cb - 0.714CrB = Y + 1.772Cb
這樣對於 YCbCr 這個顏色模型我們就有個初步認識了，但是我們會發現，這裏 YCbCr 也仍然用了 3 個數字來表示顏色啊，有節省 bit 嗎？爲了回答這個問題，我們來結合視頻中的圖像和圖像中的像素表示來說明。
圖片是由類似下面的像素組成：
一副圖片就是一個像素陣列：
上圖中，每個像素的 3 個分量的信息是完整的，YCbCr 4:4:4。
上圖中，對於每個像素點都保留「亮度」值，但是省略每行中偶素位像素點的「色度」值，從而節省了 bit。
上圖中，做了更多的省略，但是對圖片質量的影響卻不會太大。
對於更細節的內容，可以查詢與 YCbCr 4:2:0、YCbCr 4:2:2、YCbCr 4:1:1 和 YCbCr 4:4:4 相關的知識。
碼流格式
在上節中，我們簡單的介紹了和 H.264 編碼相關的圖片、像素以及顏色模型相關的概念，那這一節就接着簡要介紹一下 H.264 碼流的結構，以及如何從 H.264 的碼流中找到那些像素。
對於一個解碼器來說，它的工作對象就是從一個特定結構的數據流中去獲取有效的 bit 流，而這個數據流則是結構化後分爲數據包傳輸的，其大致結構如下：
我們可以看到，在 NAL 包之間存在着一些間隔標記。
NAL 包的第一個字節是定義包類型的頭文件，NAL 包有這樣一些類型：
| 類型 | 定義 |
|---|---|
| 0 | Undefined |
| 1 | Slice layer without partitioning non IDR |
| 2 | Slice data partition A layer |
| 3 | Slice data partition B layer |
| 4 | Slice data partition C layer |
| 5 | Slice layer without partitioning IDR |
| 6 | Additional information (SEI) |
| 7 | Sequence parameter set |
| 8 | Picture parameter set |
| 9 | Access unit delimiter |
| 10 | End of sequence |
| 11 | End of stream |
| 12 | Filler data |
| 13..23 | Reserved |
| 24..31 | Undefined |
NAL 的類型說明了當前這個 NAL 包的數據結構和數據含義，它可能是片(Slice)，參數集或者填充數據等等。
如上圖所示，NAL 包將其負載數據存儲在 RBSP(Raw Byte Sequence Payload) 中，RBSP 是一系列的 SODB(String Of Data Bits)。
下面，我們來具體看看 H.264 的碼流結構：
一張圖片可以包含一個或多個分片(Slice)，而每一個分片(Slice)又會被分爲了若干宏塊(Macroblock)。對於分片(Slice)來說，有如下這些類型：
| 類型 | 定義 |
|---|---|
| 0 | P-slice. Consists of P-macroblocks (each macro block is predicted using one reference frame) and / or I-macroblocks. |
| 1 | B-slice. Consists of B-macroblocks (each macroblock is predicted using one or two reference frames) and / or I-macroblocks. |
| 2 | I-slice. Contains only I-macroblocks. Each macroblock is predicted from previously coded blocks of the same slice. |
| 3 | SP-slice. Consists of P and / or I-macroblocks and lets you switch between encoded streams. |
| 4 | SI-slice. It consists of a special type of SI-macroblocks and lets you switch between encoded streams. |
| 5 | P-slice. |
| 6 | B-slice. |
| 7 | I-slice. |
| 8 | SP-slice. |
| 9 | SI-slice. |
如我們所見，每個分片也包含着頭和數據兩部分，分片頭中包含着分片類型、分片中的宏塊類型、分片幀的數量以及對應的幀的設置和參數等信息，而分片數據中則是宏塊，這裏就是我們要找的存儲像素數據的地方。
宏塊是視頻信息的主要承載者，因爲它包含着每一個像素的亮度和色度信息。視頻解碼最主要的工作則是提供高效的方式從碼流中獲得宏塊中的像素陣列。
從上圖中，可以看到，宏塊中包含了宏塊類型、預測類型、Coded Block Pattern、Quantization Parameter、像素的亮度和色度數據集等等信息。
至此，我們對 H.264 的碼流數據結構應該有了一個大致的瞭解。
幀內預測和幀間預測
在上一節的末尾，我們介紹了宏塊的數據結構，其中提到了「預測類型」這個字段，這裏就接着說說「幀內預測」和「幀間預測」這兩種在視頻編碼中常用到的壓縮方法，也可以稱爲「幀內壓縮」和「幀間壓縮」。
幀內壓縮類似於圖片壓縮，跟這一幀的前面（或後面）一幀（或幾幀）無關，由當前幀中，已編碼的部分來推測當前待編碼的這一部分數據是什麼。幀間壓縮是由這一幀的前（或後）一幀（或幾幀）來推測當前待壓縮的這一部分數據是什麼。
上節中，我們說過圖片可以劃分爲宏塊。一般來說，運動多細節多的部分，劃分成小塊來編碼，無變化的大片的部分，劃分成大塊來編碼。其大致效果如下：
幀內預測
對於幀內壓縮，我們可以看下圖示例：
我們可以通過第 1、2、3、4、5 塊的編碼來推測和計算第 6 塊的編碼，因此就不需要對第 6 塊進行編碼了，從而壓縮了第 6 塊，節省了空間。
幀內預測在 H.264 編碼標準裏有以下幾種預測方法：
幀間預測
對於幀間壓縮，可以看下面連續的兩幀：
可以看到前後兩幀的差異其實是很小的，這時候用幀間壓縮就很有意義。
做幀間壓縮常用的方式就是塊匹配(Block Matching)，就是找找看前面已經編碼的幾幀裏面，和我當前這個塊最類似的一個塊，這樣我就不用編碼當前塊的內容了，只需要編碼當前塊和我找到的那個塊的差異（稱爲殘差）即可。找最像的塊的過程叫運動搜索（Motion Search），又叫運動估計（Motion Estimation）。用殘差和原來的塊就能推算出當前塊的過程叫運動補償（Motion Compensation）。
視頻業務
我們平常最常接觸到的視頻相關的業務方式通常有：本地視頻文件播放、網絡視頻點播、網絡視頻直播等等幾種。對於網絡視頻點播、網絡視頻直播，整個過程大致如下圖所示：
而本地視頻文件播放就更簡單了，是在上面的過程中省略掉解協議的過程。
流媒體協議
隨着互聯網基礎設施越來越完善，網絡視頻點播和直播業務也越來越多，這其中少不了流媒體協議的支持。常見的流媒體協議有：
- RTP，實時傳輸協議，Real-time Transport Protocol，是一種網絡傳輸協議，運行在 UDP 協議之上，RTP協議詳細說明了在互聯網上傳遞音頻和視頻的標準數據包格式。RTP協議常用於流媒體系統（配合 RTSP 協議）。
- RTCP，實時傳輸控制協議，Real-time Transport Control Protocol，是實時傳輸協議（RTP）的一個姐妹協議。RTCP爲RTP媒體流提供信道外（out-of-band）控制。RTCP 本身並不傳輸數據，但和 RTP 一起協作將多媒體數據打包和發送。RTCP 定期在流多媒體會話參加者之間傳輸控制數據。RTCP 的主要功能是爲 RTP 所提供的服務質量（Quality of Service）提供反饋。
- RTSP，實時流傳輸協議，Real Time Streaming Protocol，該協議定義了一對多應用程序如何有效地通過 IP 網絡傳送多媒體數據。RTSP 在體系結構上位於 RTP 和 RTCP 之上，它使用 TCP 或 UDP 完成數據傳輸。使用 RTSP 時，客戶機和服務器都可以發出請求，即 RTSP 可以是雙向的。
- RTMP，實時消息傳輸協議，Real Time Messaging Protocol，是 Adobe Systems 公司爲 Flash 播放器和服務器之間音頻、視頻和數據傳輸開發的開放協議。協議基於 TCP，是一個協議族，包括 RTMP 基本協議及 RTMPT/RTMPS/RTMPE 等多種變種。RTMP 是一種設計用來進行實時數據通信的網絡協議，主要用來在 Flash/AIR 平臺和支持RTMP協議的流媒體/交互服務器之間進行音視頻和數據通信。
- RTMFP，是 Adobe 公司開發的一套新的通信協議，全稱 Real Time Media Flow Protocol，協議基於 UDP，支持 C/S 模式和 P2P 模式，即該協議可以讓使用 Adobe Flash Player 的終端用戶之間進行直接通信。
- HTTP，超文本傳輸協議，HyperText Transfer Protocol，運行在 TCP 之上，這個協議是大家非常熟悉的，它也可以用到視頻業務中來。
- HLS，是蘋果公司實現的基於 HTTP 的流媒體傳輸協議，全稱 HTTP Live Streaming，可支持流媒體的直播和點播，主要應用在 iOS 系統，爲 iOS 設備（如 iPhone、iPad）提供音視頻直播和點播方案。對於 HLS 點播，基本上就是常見的分段 HTTP 點播，不同在於，它的分段非常小。要實現HLS點播，重點在於對媒體文件分段。對於 HLS 直播，相對於常見的流媒體直播協議，例如 RTMP 協議、RTSP 協議等，HLS 最大的不同在於直播客戶端獲取到的並不是一個完整的數據流，而是連續的、短時長的媒體文件（MPEG-TS 格式），客戶端不斷的下載並播放這些小文件。由於數據通過 HTTP 協議傳輸，所以完全不用考慮防火牆或者代理的問題，而且分段文件的時長很短，客戶端可以很快的選擇和切換碼率，以適應不同帶寬條件下的播放。不過 HLS 的這種技術特點，決定了它的延遲一般總是會高於普通的流媒體直播協議。
業務方案
在國內主流的一些視頻業務相關的公司中，主要採用的視頻業務方案有：
網絡視頻點播
| 公司 | 協議 | 封裝 | 視頻編碼 | 音頻編碼 | 播放器 |
|---|---|---|---|---|---|
| CNTV | HTTP | MP4 | H.264 | AAC | Flash |
| CNTV（部分） | RTMP | FLV | H.264 | AAC | Flash |
| 華數 TV | HTTP | MP4 | H.264 | AAC | Flash |
| 優酷網 | HTTP | FLV | H.264 | AAC | Flash |
| 土豆網 | HTTP | F4V | H.264 | AAC | Flash |
| 56網 | HTTP | FLV | H.264 | AAC | Flash |
| 音悅臺 | HTTP | MP4 | H.264 | AAC | Flash |
| 樂視網 | HTTP | FLV | H.264 | AAC | Flash |
| 新浪視頻 | HTTP | FLV | H.264 | AAC | Flash |
網絡視頻點播業務採用 HTTP 有兩方面優勢：
- HTTP 是基於 TCP 協議的應用層協議，媒體傳輸過程中不會出現丟包等現象，從而保證了視頻的質量。
- HTTP 是絕大部分的 Web 服務器支持的協議，因而流媒體服務機構不必投資購買額外的流媒體服務器，從而節約了開支。
網絡視頻點播服務採用的封裝格式有多種：MP4，FLV，F4V 等，它們之間的區別不是很大。
視頻編碼標準和音頻編碼標準是 H.264 和 AAC，這兩種標準分別是當今實際應用中編碼效率最高的視頻標準和音頻標準。
視頻播放器方面則都使用了 Flash 播放器。
網絡視頻直播
| 公司 | 協議 | 封裝 | 視頻編碼 | 音頻編碼 | 播放器 |
|---|---|---|---|---|---|
| 華數 TV | RTMP | FLV | H.264 | AAC | Flash |
| 六間房 | RTMP | FLV | H.264 | AAC | Flash |
| 中國教育電視臺 | RTMP | FLV | H.264 | AAC | Flash |
| 北廣傳媒移動電視 | RTMP | FLV | H.264 | AAC | Flash |
| 上海IPTV | RTSP+RTP | TS | H.264 | MP2 | 機頂盒 |
網絡視頻直播服務採用 RTMP 作爲直播協議的好處是可以直接被 Flash 播放器支持，而 Flash 播放器在 PC 時代有着極高的普及率，並且與瀏覽器結合的很好。因此這種流媒體直播平臺基本上可以實現了「無插件直播」，極大降低了用戶使用成本。
封裝格式、視頻編碼、音頻編碼、播放器方面幾乎全部採用了 FLV、H.264、AAC、Flash。FLV、RTMP、Flash 都是 Adobe 公司的產品，天生有着良好的結合性。
在現在看來，以上的數據已經有些過時了，比如現在隨着移動互聯網時代的爆發，H5 以及客戶端應用的普及，行業中對視頻業務技術方案的選擇也逐漸在發生着變化，而我們則需要結合眼下的實際情況和技術發展的趨勢去做出合適的技術選型。