Android 基於ffmpeg開發簡易播放器 – 基礎知識

音視訊基礎知識

視訊檔案格式

對於視訊來說，常見的檔案格式則有：.mov、.avi、.mpg、.vob、.mkv、.rm、.rmvb 等等。檔案格式通常表現為檔案在作業系統上儲存時的字尾名，它通常會被作業系統用來與相應的開啟程式關聯。之所以會有不同格式的視訊，是因為採用了不同的封裝方式來實現視訊的。

視訊封裝格式

視訊封裝格式相當於一種儲存視訊資訊的容器，它裡面包含了封裝視訊檔案所需要的視訊資訊、音訊資訊和相關的配置資訊(比如：視訊和音訊的關聯資訊、如何解碼等等)。一種視訊封裝格式的直接反映就是對應著相應的視訊檔案格式。

一些檔案封裝格式：

• AVI 格式，對應的檔案格式為 .avi。這種視訊格式的優點是影像質量好，無損 AVI 可以儲存 alpha 通道。缺點是體積過於龐大，並且壓縮標準不統一，存在較多的高低版本相容問題。
• DV-AVI 格式，對應的檔案格式為 .avi。常見的數碼攝像機就是使用這種格式記錄視訊資料的。它可以通過電腦的 IEEE 1394 埠傳輸視訊資料到電腦，也可以將電腦中編輯好的的視訊資料回錄到數碼攝像機中。
• WMV 格式，對應的檔案格式是 .wmv、.asf，是微軟推出的一種採用獨立編碼方式並且可以直接在網上實時觀看視訊節目的檔案壓縮格式。在同等視訊質量下，WMV 格式的檔案可以邊下載邊播放，因此很適合在網上播放和傳輸。
• MPEG 格式，對應的檔案格式有 .mpg、.mpeg、.mpe、.dat、.vob、.asf、.3gp、.mp4 等等。MPEG 格式目前有三個壓縮標準，分別是 MPEG-1、MPEG-2、和 MPEG-4。MPEG-4 是現在用的比較多的視訊封裝格式，它為了播放流式媒體的高質量視訊而專門設計的，以求使用最少的資料獲得最佳的影像質量。
• Matroska 格式，對應的檔案格式是 .mkv，Matroska 是一種新的視訊封裝格式，它可將多種不同編碼的視訊及 16 條以上不同格式的音訊和不同語言的字幕流封裝到一個 Matroska Media 檔案當中。
• Real Video 格式，對應的檔案格式是 .rm、.rmvb。使用者可以使用 RealPlayer 根據不同的網路傳輸速率制定出不同的壓縮比率，從而實現在低速率的網路上進行影像資料實時傳送和播放。
• QuickTime File Format 格式，對應的檔案格式是 .mov。這種封裝格式具有較高的壓縮比率和較完美的視訊清晰度等特點，並可以儲存 alpha 通道。
• Flash Video 格式，對應的檔案格式是 .flv，是由 Adobe Flash 延伸出來的一種網路視訊封裝格式。這種格式被很多視訊網站所採用。

在程式設計中，我們需要將視訊檔案以指定的格式獨取出來。

視訊編解碼方式

視訊編解碼的過程是指對數字視訊進行壓縮或解壓縮的一個過程。

在做視訊編解碼時，需要考慮以下這些因素的平衡：視訊的質量、用來表示視訊所需要的資料量（通常稱之為位元速率）、編碼演算法和解碼演算法的複雜度、針對資料丟失和錯誤的魯棒性（Robustness）、編輯的方便性、隨機訪問、編碼演算法設計的完美性、端到端的延時以及其它一些因素。

常見的視訊編碼方式有：

• H.26X 系列，由國際電傳視訊聯盟遠端通訊標準化組織(ITU-T)主導，包括 H.261、H.262、H.263、H.264、H.265。

  • 1.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。
• MP3，是當曾經非常流行的一種數字音訊編碼和有失真壓縮格式，它被設計來大幅降低音訊資料量。
• WMA，包括有損和無失真壓縮格式。

音訊需要轉換成音效卡支援的格式才能夠播放。重取樣。

封裝格式和編碼格式

畫素格式

畫素格式就是影像的具體畫素用什麼表示，主要有兩種，RGB和YUV。攝像頭採集的畫素格式和顯示器顯示的畫素格式都為RGB格式，但是很多的壓縮和解碼演算法都是基於YUV格式的，所以需要進行RGB和YUV格式的轉換。可以直接使用顯示卡的Shader語言來轉換。

PCM音訊引數

取樣率：44100 （CD，1s內採集了44100次，越大越接近真實情況）
通道：左右聲道
樣本大小：AV_SAMPLE_FMT_S16，AV_SAMPLE_FMT_FLTP（浮點格式，效率更高）。
AV_SAMPLE_FMT_FLTP無法直接播放，需要進行重取樣轉換成AV_SAMPLE_FMT_S16格式之後才能播放。

樣本型別planar

MP4格式分析

blog.csdn.net/shelldon/article/details/54144409

關於 H.264

H.264 是現在廣泛採用的一種編碼方式。

解釋幾個概念：

• 影像。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 – Y
Cg = G – Y
Cb = 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 指紅色色度分量。

YCbCr 與 RGB 相互轉換的公式：

Y = 0.299R + 0.587G + 0.114B
Cb = 0.564(B - Y)
Cr = 0.713(R - Y)
R = Y + 1.402Cr
G = Y - 0.344Cb - 0.714Cr
B = Y + 1.772Cb
複製程式碼

但是我們會發現，這裡 YCbCr 也仍然用了 3 個數字來表示顏色啊，有節省 bit 嗎？為了回答這個問題，我們來結合視訊中的影像和影像中的畫素表示來說明。

圖片是由類似下面的畫素組成：

一副圖片就是一個畫素陣列：

上圖中，每個畫素的 3 個分量的資訊是完整的，YCbCr 4:4:4。

上圖中，對於每個畫素點都保留「亮度」值，但是省略每行中偶素位畫素點的「色度」值，從而節省了 bit。

上圖中，做了更多的省略，但是對圖片質量的影響卻不會太大。

碼流格式

對於一個解碼器來說，它的工作物件就是從一個特定結構的資料流中去獲取有效的 bit 流，而這個資料流則是結構化後分為資料包傳輸的，其大致結構如下：

我們可以看到，在 NAL 包之間存在著一些間隔標記。

NAL 包的第一個位元組是定義包型別的標頭檔案，NAL 包有這樣一些型別：

NAL 的型別說明了當前這個 NAL 包的資料結構和資料含義，它可能是片(Slice)，引數集或者填充資料等等。

如上圖所示，NAL 包將其負載資料儲存在 RBSP(Raw Byte Sequence Payload) 中，RBSP 是一系列的 SODB(String Of Data Bits)。

H.264 的碼流結構：

一張圖片可以包含一個或多個分片(Slice)，而每一個分片(Slice)又會被分為了若干巨集塊(Macroblock)。對於分片(Slice)來說，有如下這些型別：

如我們所見，每個分片也包含著頭和資料兩部分，分片頭中包含著分片型別、分片中的巨集塊型別、分片幀的數量以及對應的幀的設定和引數等資訊，而分片資料中則是巨集塊，這裡就是我們要找的儲存畫素資料的地方。

巨集塊是視訊資訊的主要承載者，因為它包含著每一個畫素的亮度和色度資訊。視訊解碼最主要的工作則是提供高效的方式從碼流中獲得巨集塊中的畫素陣列。

從上圖中，可以看到，巨集塊中包含了巨集塊型別、預測型別、Coded Block Pattern、Quantization Parameter、畫素的亮度和色度資料集等等資訊。

GOP

一組可以獨立解碼並播放的資料：

分為I幀，B幀，P幀。

• I幀：關鍵幀。可以獨立解碼並播放。
• B幀：相對前一幀的變化，需要參考前一幀進行解碼。
• P幀：相對前一幀和後一幀的變化，需要參考前一幀和後一幀進行解碼。

所以解碼順序與顯示順序不一致。需要緩衝一定的幀數才能夠正確顯示。

PTS & DTS

視訊的播放過程可以簡單理解為一幀一幀的畫面按照時間順序呈現出來的過程。但是在實際應用中，並不是每一幀都是完整的畫面，因為如果每一幀畫面都是完整的圖片，那麼一個視訊的體積就會很大，這樣對於網路傳輸或者視訊資料儲存來說成本太高，所以通常會對視訊流中的一部分畫面進行壓縮（編碼）處理。由於壓縮處理的方式不同，視訊中的畫面幀就分為了不同的類別，其中包括：I 幀、P 幀、B 幀。

I、P、B 幀

I 幀、P 幀、B 幀的區別在於：

• I 幀（Intra coded frames）：I 幀影像採用幀內編碼方式，即只利用了單幀影像內的空間相關性，而沒有利用時間相關性。I 幀使用幀內壓縮，不使用運動補償，由於 I 幀不依賴其它幀，所以是隨機存取的入點，同時是解碼的基準幀。I 幀主要用於接收機的初始化和通道的獲取，以及節目的切換和插入，I 幀影像的壓縮倍數相對較低。I 幀影像是週期性出現在影像序列中的，出現頻率可由編碼器選擇。
• P 幀（Predicted frames）：P 幀和 B 幀影像採用幀間編碼方式，即同時利用了空間和時間上的相關性。P 幀影像只採用前向時間預測，可以提高壓縮效率和影像質量。P 幀影像中可以包含幀內編碼的部分，即 P 幀中的每一個巨集塊可以是前向預測，也可以是幀內編碼。
• B 幀（Bi-directional predicted frames）：B 幀影像採用雙向時間預測，可以大大提高壓縮倍數。值得注意的是，由於 B 幀影像採用了未來幀作為參考，因此 MPEG-2 編碼碼流中影像幀的傳輸順序和顯示順序是不同的。

也就是說，一個 I 幀可以不依賴其他幀就解碼出一幅完整的影像，而 P 幀、B 幀不行。P 幀需要依賴視訊流中排在它前面的幀才能解碼出影像。B 幀則需要依賴視訊流中排在它前面或後面的幀才能解碼出影像。

這就帶來一個問題：在視訊流中，先到來的 B 幀無法立即解碼，需要等待它依賴的後面的 I、P 幀先解碼完成，這樣一來播放時間與解碼時間不一致了，順序打亂了，那這些幀該如何播放呢？這時就需要了解另外兩個概念：DTS 和 PTS。

DTS、PTS 的概念

• DTS（Decoding Time Stamp）：即解碼時間戳，這個時間戳的意義在於告訴播放器該在什麼時候解碼這一幀的資料。
• PTS（Presentation Time Stamp）：即顯示時間戳，這個時間戳用來告訴播放器該在什麼時候顯示這一幀的資料。

需要注意的是：雖然 DTS、PTS 是用於指導播放端的行為，但它們是在編碼的時候由編碼器生成的。

當視訊流中沒有 B 幀時，通常 DTS 和 PTS 的順序是一致的。但如果有 B 幀時，就回到了我們前面說的問題：解碼順序和播放順序不一致了。

比如一個視訊中，幀的顯示順序是：I B B P，現在我們需要在解碼 B 幀時知道 P 幀中資訊，因此這幾幀在視訊流中的順序可能是：I P B B，這時候就體現出每幀都有 DTS 和 PTS 的作用了。DTS 告訴我們該按什麼順序解碼這幾幀影像，PTS 告訴我們該按什麼順序顯示這幾幀影像。順序大概如下：

   PTS: 1 4 2 3
   DTS: 1 2 3 4
Stream: I P B B
複製程式碼

音訊的播放，也有 DTS、PTS 的概念，但是音訊沒有類似視訊中 B 幀，不需要雙向預測，所以音訊幀的 DTS、PTS 順序是一致的。

音訊視訊混合在一起播放，就呈現了我們常常看到的廣義的視訊。在音視訊一起播放的時候，我們通常需要面臨一個問題：怎麼去同步它們，以免出現畫不對聲的情況。

要實現音視訊同步，通常需要選擇一個參考時鐘，參考時鐘上的時間是線性遞增的，編碼音視訊流時依據參考時鐘上的時間給每幀資料打上時間戳。在播放時，讀取資料幀上的時間戳，同時參考當前參考時鐘上的時間來安排播放。這裡的說的時間戳就是我們前面說的 PTS。實踐中，我們可以選擇：同步視訊到音訊、同步音訊到視訊、同步音訊和視訊到外部時鐘。

幀內預測和幀間預測

巨集塊的資料結構中包含了「預測型別」這個欄位，這裡就接著說說「幀內預測」和「幀間預測」這兩種在視訊編碼中常用到的壓縮方法，也可以稱為「幀內壓縮」和「幀間壓縮」。

幀內壓縮類似於圖片壓縮，跟這一幀的前面（或後面）一幀（或幾幀）無關，由當前幀中，已編碼的部分來推測當前待編碼的這一部分資料是什麼。幀間壓縮是由這一幀的前（或後）一幀（或幾幀）來推測當前待壓縮的這一部分資料是什麼。

上節中，我們說過圖片可以劃分為巨集塊。一般來說，運動多細節多的部分，劃分成小塊來編碼，無變化的大片的部分，劃分成大塊來編碼。其大致效果如下：

幀內預測

對於幀內壓縮，我們可以看下圖示例：

我們可以通過第 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 的這種技術特點，決定了它的延遲一般總是會高於普通的流媒體直播協議。

業務方案

網路視訊點播

網路視訊點播業務採用 HTTP 有兩方面優勢：

• HTTP 是基於 TCP 協議的應用層協議，媒體傳輸過程中不會出現丟包等現象，從而保證了視訊的質量。
• HTTP 是絕大部分的 Web 伺服器支援的協議，因而流媒體服務機構不必投資購買額外的流媒體伺服器，從而節約了開支。

網路視訊點播服務採用的封裝格式有多種：MP4，FLV，F4V 等，它們之間的區別不是很大。

視訊編碼標準和音訊編碼標準是 H.264 和 AAC，這兩種標準分別是當今實際應用中編碼效率最高的視訊標準和音訊標準。

視訊播放器方面則都使用了 Flash 播放器。

網路視訊直播

網路視訊直播服務採用 RTMP 作為直播協議的好處是可以直接被 Flash 播放器支援，而 Flash 播放器在 PC 時代有著極高的普及率，並且與瀏覽器結合的很好。因此這種流媒體直播平臺基本上可以實現了「無外掛直播」，極大降低了使用者使用成本。

封裝格式、視訊編碼、音訊編碼、播放器方面幾乎全部採用了 FLV、H.264、AAC、Flash。FLV、RTMP、Flash 都是 Adobe 公司的產品，天生有著良好的結合性。