MPEG視頻拼接
綱要：
1. 簡介
2. Splicing算法
3. 幀轉換
4. 速率控制
5. 實驗結果: PSNR、Buffer、Splicing MPEG2 Stream
6. 感言
7. 參考文獻
1. 簡介
Splicing(拼接技術)通常用在視頻編輯應用中。當拼接一個無壓縮的視頻時，很明顯：只要丟棄無用的幀，連接剩餘的數據，換句話說，就是簡單的剪切粘貼操作。這種方式只能是對無壓縮的視頻數據。現代視頻壓縮算法(如MPEG)採用幀間預測以減少時間冗餘，這種算法能達到很高的壓縮率，但這樣帶來的問題是產生的碼流有很大的時間相關性。這種時間相關性使很多操作變得複雜起來---Splicing就是這種情況。
在這篇論文中，我們測試了兩個MPEG碼流之間拼接的問題。我們提出了一個基於壓縮的拼接算法—在計算複雜度和壓縮效率之間折衷考慮。這個算法能被裁簡化達到特殊系統的要求。這篇論文首先描述了拼接MPEG視頻的問題，然後討論了提交的算法、幀轉換、速率控制，最後是Splicing的軟件實現和實驗結果。
2. Splicing算法
視頻接接的目的就是爲了形成一個視頻序列的Nhead幀和另外一個視頻序列的
Ntail 幀組成的新序列。理想的拼接方案是完全解壓兩個視頻序列，再作剪切粘帖
操作，最後重壓縮。這種方法要求拼接序列每一幀都要重編碼，帶來的問題是高
的計算複雜度、高的內存要求、低的效率(重編碼的原因)。
|
序列一 |
|
序列二 |
|
序列一 |
|
Head |
|
Tail |
在這個算法中，僅僅計算拼接影響到的幀。例如，在絕大多數情況下，需要被
重編 碼的幀就是在頭、尾拼接點所在的GOP，最多頭一個GOP尾一個GOP。此
外，爲了提高性能，數據也不需要完全解壓到像素級，只到MV(運動矢量)和DCT就
可以了。
Splicing算法有三個步驟：形成序列一的”頭”幀序列(一個GOP??)，形成序列二的
尾幀序列(一個GOP???)，組合它們成一個新的MPEG碼流序列。頭、尾拼接點可以
是IBP中的任意幀。拼接中的一個難點是，在被拼接序列中需要解碼幀的依賴幀可
能不在最終序列中。(注：比如一個B幀也許需要它後面的參考幀來解碼)
在這個算法中，時間依賴問題能通過改變相關幀的預測模式來解決。這種幀轉
換保留原始MPEG的幀編碼順序，這樣大大簡化了計算的複雜度。這種算法結果就
是：最終序列爲變長的GOP，採用GOP頭不指定GOP的幀數目和結構，而是通過幀
的順序和類型來指定。這個算法用速率控制來保證拼接後的碼流能滿足緩衝要求。
下面是詳細步驟：(這裏說的IBP都是顯示順序，非編碼後順序)
1) 形成頭序列
最簡單的情況是拼接點在I或都P幀之後立即出現，這種情況，不相關的數
據簡單的丟棄，剩餘的數據不需處要處理。當拼接點出現在B幀後面時，需要
一些額外的處理，因爲B幀預測是基於前、後幀，預測幀可能不包括在最終的
拼接碼流中。這種情況下，前面部分直到最後一個I幀或P幀不變，後面的B幀全部轉
換成P幀(後面有詳細描述)。
示例：
Display order： I0 B1 B2 P3 B4 B5 | I6 B7 B8
Coded order(spliced)： I0 P3 B1 B2 P4 P5
2) 形成尾序列
最簡單的情況是拼接點出現在I幀之前，這種情況，此I幀前面的數據可以被丟棄並且後面部分不需要處理。當拼接點出現在P幀之前，P幀必須被轉成I幀並且後面數據不變。當拼接點出現在B幀之前，需要一些額外處理，因爲B幀的預測幀可能不在拼接後的序列中。這種情況下，如果後面的第一個非B幀是P幀時，此P幀必須被轉成I幀，而且此B幀及緊跟着的B幀都要被轉換成Bback幀。
示例：
Display order： I0 B1 B2 | P3 B4 B5 I6 B7 B8 P9
Coded order(spliced)： I3 I6 B4 B5 P9 B7 B8
Display order： I0 | B1 B2 P3 B4 B5 I6 B7 B8 P9
Coded order(spliced)： I3 Bback1 Bback2 I6 B4 B5 P9 B7 B8
3) 匹配頭、尾序列
頭、尾序列的IPB結構和緩衝參數決定了匹配操作的複雜度。這一步要連接
兩個流並且要處理拼接點附近的幀以確保緩衝區不會溢出。通常情況，再次量
化就能滿足要求，然而，更多的不同情況是，轉換過的幀也許要求防止緩衝區
溢出。這個問題會在下面速率控制一節再討論。
3. 幀轉換
此Splicing算法也許要求轉換I、P和B幀的預測模式。轉換P幀或B幀到I幀是
相當的簡單，但是其它轉換模式就困難得多（如I到P）。嚴格的算法要求在一個完
全解壓的視頻上作運動估計。在這裏，我們使用近似計算能明顯減少轉換的計算
量。當然，如果計算能力足夠，更多處理可以提高拼接質量。
前面兩步提到了B-to-P、P-to-I、B-to-Bback、I-to-P，第三步可能會出現I-to-P
轉換這些轉換都只解碼到DCT和MV(運動矢量)。產生的新的DCT數據和MV，從而
重編碼到新的MPEG流。幀轉換常常需要作運動補償，這種情況，需要對前面預測
幀的IDCT變換後的係數再做運動補償最後再對這些係數做DCT變換。
l P to I Frame Conversion
爲了解碼P幀，此GOP中的前面的I和P幀必須被解碼。同理，當需要轉換
P幀到I幀時，此GOP前面的I幀和P幀必須先解碼到DCT原始系統，然後根據
每一個P幀殘差數據，再做反運動補償計算出Intra(幀內)係數，最後作Intra DCT
變換到得I幀。
l I to P Frame Conversion
I幀轉換到P幀的難點是前向預測沒有MV可用。幀的每一個MB(宏塊)可以
被編碼成Intra模式或者前向預測模式(MV=(0,0))，如果計算能力足夠，可以查
找更好的MV以提高每個塊的運動補償預測。
l B to P Frame Conversion
通常，在P幀中每一個MB被編碼成Intra模式或者前向預測模式，在B幀中，
MB被編碼成Intra、前向預測、後向預測、雙向預測這幾種模式。B到P的轉換
要求B的每個MB都轉成P的MB。因而，如果B的MB被編碼成前向預測模式，
保留它，如果MB被編碼成後向或雙向預測模式，必須被轉成Intra或前向模式。
在我們的算法中，雙向預測模式的宏塊按它的前向MV轉成前向預測模式，新
的預測被計算並且適當調整殘差係數。如果宏塊是後向預測，既可把它編碼成
Intra模式也可以是前向預測模式（MV=0）。如果計算能力足夠，可以精確計
算MV。
l B to Bback Frame Conversion
Bback定義爲其宏塊被編碼成Intra或者後向預測模式。本質上同P幀，因而
B to Bback轉換同B to P轉換。
4. 速率控制
在MPEG中，每一幀都被編碼成長短不同的數據段。可是，顯示序列的幀速是
固定的，CBR傳輸MPEG流在編碼、解碼端對Buffer都有要求。在CBR傳輸中，解
碼器Buffer按固定速率填滿，I、B、P數據要在規定的時間間隔(幀速率)內處理完，
如果某一幀數據量太大，Buffer變空需要更多時間。因而，如果一個流含有連續的大
數據量的幀，可能會導致緩衝區溢出。例如，一個CBR通道，圖像數據可能不能按
時接收和顯示。
MPEG語法要求Buffer大小在序列頭指定，因而一旦在開始指定的大小就不再能
改變，MPEG也要求在每個Picture頭指定vbv_delay參數。Vbv_delay表示Picture開始
解碼到真正被解碼之間的時間長度。
在我們的算法中，在這向幾種轉換模式中，通常I幀比B、P幀數據量大很多，
如果出現太多I幀，最終的流可能導致緩衝區下溢。這個算法通過碼率控制防止緩衝
區上溢和下溢。
問題變成匹配頭、尾序列的緩衝區參數。恰好，在拼接點附近的頭、尾幀需要
被處理，於是剩餘的尾幀的vbv_delay參數保留它的原始值。因而，假設兩個原始流
滿足緩衝約束，可以通過適當的匹配頭、尾序列確保拼接後的序列也能滿足緩衝要
求。
Meng和Chang解決這個問題(碼率控制)是通過插入淡入(fade-in)圖片(它的碼率低)
的方式。他們也提到用數據分隔方法來修改碼率的可能性，但未做進一步確究。
在這裏，我們實現這兩種碼率控制方法中的一種。如果拼接點附近的圖片的
緩衝區大小相近，我們重量化DCT系統達到合適的碼率，如果最終的碼流滿足了緩
衝要求並且視頻質量可能接受，拼接操作就算完成；如果緩衝差異非常大，或者重
量化後的碼流導致緩衝下溢，需要更多的操作降低碼率，在這種情況時，把拼接點
附近的I幀轉換成P幀，尤其是頭序列的最後一個I幀和尾序列的第二個I幀。另外，
重量化始終是終極手段。注意：所以這些幀轉換不改變幀的編碼順序。
5. 實驗結果
6. 感言
7. 參考文獻
J. Meng and S.-F. Chang, "Buffer Control Techniques for Compressed-Domain Video Editing", Proceedings of IEEE International Symposium on Circuits and Systems, (Atlanta, GA), May 1996.
N. Merhav and B. Vasudev, "Fast Inverse Motion Compensation Algorithms for MPEG-2 and for Partial DCT Information", HP Laboratories Technical Report, Vol. HPL-96-53, April 1996.
MPEG-2 International Standard, Video Recommendation ITU-T H.262, ISO/IEC 13818-2, January 1995.