转AVS--视频编辑码扩展方案性能分析及建议
时间:2007-04-21 来源:xiewei1287
1 概述
本提案对使用video_edit_code_extension实现视频随机访问及视频编辑的方案进行了性能分析,并指出了该方案潜在的问题及给出了相应的解决方法。
2 视频编辑码扩展方案性能分析
根据AVS 18次会议及视频组邮件列表的讨论结果,在现有AVS 1.0标准中采用video_edit_code +Extension的方案实现视频随机访问及视频编辑,既解码器在视频序列头判断是否存在video_edit_code Startcode,找到VEC码后既读取VEC码后面8 bit video_edit_code_extension 并进行相应操作,video_edit_code_extension的现有定义如下:
视频编辑码扩展
video_edit_code_extension |
含义 |
0 |
禁止 |
1 |
在比特流中,紧跟video_edit_code_extension的第一个I帧与这个I帧后续的第一个非B帧之间的B帧无法正确解码,解码器应丢弃这些B帧。 |
2 |
在比特流中,紧跟video_edit_code_extension的第一个I帧与这个I帧后续的第一个非B帧之间的B帧可能无法正确解码。 |
3 |
在比特流中,紧跟video_edit_code_extension的第一个I帧与这个I帧后续的第一个非B帧之间的B帧可正确解码。 |
4 ~ 255 |
保留 |
其中video_edit_code_extension=2时,其功能与VEC码最初所起的作用一样,既视频编辑。
因为在现有AVS标准中,B帧采用了双向编码,P帧采用了前向两帧编码,正如图1所示。在发生随机访问时,带有VEC码的I帧之前的参考帧或已丢失,从而导致紧跟I帧之后的B帧和第一个P帧无法被正常解码。根据AVS视频组邮件讨论结果,目前AVS码流的随机访问可通过使用 video_edit_code_extension=1或video_edit_code_extension=3这两种方式实现。但是这两种方案都存在一定的问题。当video_edit_code_extension=1时,系统需要将紧跟用VEC 标识的I帧之后、第一个P帧之间的全部B帧丢弃。考虑到在广播应用中用户换台时所允许的时间间隔为0.5s,在帧率为30fps或25fps时每隔12帧或15帧就要在I帧头插入VEC码以作为随机访问切入点。这意味着每隔12或15帧解码器就要将若干个B帧给丢弃。这会导致视频播放序列的不连续,并会严重影响到用户对该视频的观看。若解码器能获知用户换台的操作,并进而判断出在播放时发生了随机访问,解码器遇到VEC码时将B帧丢弃,否则B帧正常解码。但此种设定既意味着解码器对VEC码之后B帧的操作需依赖与换台信息,增加了解码器的复杂度及降低了解码器的通用性。
图1 AVS编码示意图
若采用video_edit_code_extension=3的方案实现视频随机访问,既意味着紧跟带有VEC码的I帧之后的B帧仅使用单向(后向)参考,参考帧为I帧,且此I帧之后的第一个P帧亦只使用前向一帧参考,参考帧为I帧。此种方案能够实现视频的随机访问,同时保证视频序列播放时的连续性。但该方案限制了紧跟带有VEC码的I帧之后的B帧的预测编码方向,这些B帧由双向编码改为单向(后向编码),以致这些B帧的编码性能大幅度降低,并且由于P帧的参考帧数目亦受到影响,采用该方案的视频序列其编码效率将大幅降低。
对于上述video_edit_code_extension=3的方案,我们在AVS 1.0参考软件平台rm52h上做了以下试验以证其编码效率:按照广播应用的要求我们定义了两种类型的视频序列,其中第一种类型的序列为不支持随机访问的序列,其I帧与P帧或P帧与P帧之间间隔2个B帧,I帧每隔15帧出现一次,既其编码结构为I1B2B3P4B5B6P7B8B9P10B11B12P13B14B15I16B17B18P19….;第二种类型的视频序列为支持随机访问的序列,其I帧与P帧或P帧与P帧之间间隔2个B帧,I帧每隔15帧出现一次,其编码结构亦为I1B2B3P4B5B6P7B8B9P10B11B12P13B14B15I16B17B18P19…,但在编码顺序上紧跟I16帧的B14B15帧的编码方向被强制为后向参考,P19帧仅能前向参考I16帧一帧。我们选择22个视频序列按上述两种类型的视频序列进行了编码,其中包括8个CIF序列,4个480i序列,4个576i序列,6个720P序列,编码条件为通用测试条件,编码长度为60帧。经编码完后统计,我们发现在CIF,480i,576i,720P上面,按第二种类型的视频序列,既具备随机访问功能的序列,进行编码,其编码码率要比按第一种类型进行编码的码率平均增加8.4%,12.8%,6.93%及10.42%。相关数据查阅本提案附录1~4。
由此可见当video_edit_code_extension=3时,由于该方案限制了作为随机切入点的I帧后面两个B帧及P帧参考方向及参考帧数,其编码性能有较大幅度降低。若采用当前的视频编辑码扩展方案以实现视频随机,其视频的编码效率会有较大幅度降低。并且,该实现方案与MPEG-2 closed-gop及H.264 IDR 做法类似,恐有专利冲突。
3 对视频编辑码扩展方案的建议
由前节所述我们可知:用目前视频编辑码扩展方案实现视频随机访问导致编码效率降低的根本原因在于限制了在编码顺序上紧跟在作为随机切入点的I帧后面的B帧的预测方向,故本提案在此提出相应的改进方法,方法如下:
我们定义当video_edit_code_extension=4时,将在编码顺序上紧跟带有VEC码的I帧后的第一个B帧(既前述B14帧)替换为紧做后向参考的一幅图象,该幅图象编码完毕后然其可作为编码顺序上该幅图像之后的B帧及P帧(既前述B15帧及P19帧)的参考图象;在解码端I16帧解码完毕后,紧跟该帧的下一幅图像被解码,并作为其后两帧的解码参考图像。经此操作之后,可以保证I16帧以后的图像编解码时无需参考I16帧以前的图像,既I16帧可作为随机切入点。同时,作为随机切入点的I16帧后紧跟以仅做后向参考的预测编码图象及可作双向参考的一幅B帧与可作前向两帧参考的P帧。由此,我们可以确信新方案的编码效率要高于前述方案的编码效率。图2为新方案的示意图,其中D代表用于替换紧跟带有VEC码的I帧后的第一个B帧的图像,其编码预测参考方向为后向参考。
图2:使用了本提案新方法的视频编码示意图
为验证我们的设想,我们在AVS 1.0参考软件平台rm52h上做了如下实验:
按照广播应用的要求我们定义了两种类型的视频序列,其中第一种类型的序列为不支持随机访问的序列,其I帧与P帧或P帧与P帧之间间隔2个B帧,I帧每隔15帧出现一次,既其编码结构为I1B2B3P4B5B6P7B8B9P10B11B12P13B14B15I16B17B18P19….;第二种类型的视频序列为支持随机访问的序列,其I帧与P帧或P帧与P帧之间间隔2个B帧,I帧每隔15帧出现一次,其编码结构亦为I1B2B3P4B5B6P7B8B9P10B11B12P13B14B15I16B17B18P19…,但在编码结构上使用本提案所阐述新方案,既当video_edit_code_extension=4时的操作。与前面的实验一样,我们选择22个视频序列按上述两种类型的视频序列进行了编码,其中包括8个CIF序列,4个480i序列,4个576i序列,6个720P序列,编码条件为通用测试条件,编码长度为60帧。经编码完后统计,我们的方案与不支持随机访问的视频编码序列相比,在CIF,480i,576,720P上编码码率分别增加了6.36%,6.35%,3.62%及7.57%。相关数据请参阅本提案附录。由此可见,我们的新方案与前节所述方案相比,在同样支持随机访问的情况下,我们在CIF,480i,576,720P这几种格式的序列上在编码码虑上节省了2.04%,6.45%,3.31%及2.85%。并且值得关注的是,该新方案在广播应用中广为使用的隔行序列格式480i及576i上能带来明显的码率节省2。相关实验数据请查阅本提案附录5~8。
由上可知,本提案所阐述新方法在实现视频随机访问的同时在码率上亦不会有太大开销。因此,我们建议将video_edit_code_extension定义扩展如下:
视频编辑码扩展
video_edit_code_extension |
含义 |
0 |
禁止 |
1 |
在比特流中,紧跟video_edit_code_extension的第一个I帧与这个I帧后续的第一个非B帧之间的B帧无法正确解码,解码器应丢弃这些B帧。 |
2 |
在比特流中,紧跟video_edit_code_extension的第一个I帧与这个I帧后续的第一个非B帧之间的B帧可能无法正确解码。 |
3 |
在比特流中,紧跟video_edit_code_extension的第一个I帧与这个I帧后续的第一个非B帧之间的B帧可正确解码。 |
4 |
在比特流中,紧跟video_edit_code_extension的第一个I帧与这个I帧后续的第一个非B帧之间的B帧可正确解码;在紧跟video_edit_code_extension的第一个I帧后的第一帧解码并让其作为其它图像的解码参考图像。 |
5 ~ 255 |
保留 |
4结论:
视频序列的随机访问功能是视频编解码标准中的一个重要部分,其决定了视频标准的可推广范围。因此,视频序列的随机访问功能必须要做到实时并且还要保证在编码码率上不会有太大的开销。而本提案所阐述新技术恰恰满足了这两点要求。因此,我们在这里建议AVS 工作组接纳此提案。
最近在研究H.264和AVS的区别,转码的问题,希望国家标准能取代H.264