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.