2000年2月,爱立信关于在H.26L中加入slice概念的提案-

2000年2月,爱立信关于在H.26L中加入slice概念的提案- -

                                      

 

TITLE: Proposal for slices in H26L
SOURCE: LM Ericsson Telefon AB
AUTHOR: Rickard Sjoberg

1. 介绍
当在分析讨论H.26L中的错误处理的时候,我们有这样的陈述:"编解码器的错误处理应该至少有错误恢复(比如,通过帧内预测来进行更新,或是通过在一个视频帧中使用一些同步点)".在q15i56号提案中有关于在码流中的位错误或包丢失的问题的讨论,可以明确的一定是,这两种情况下,同步标记是必需的,当然前提条件是一个图象可以被分到几个不同的包中.

在同步中需要两个重要部分:
1. 在码流中有slice头
2. 在不同的slice之间去掉运动向量跟帧内预测的模式.

在H.26L中引入slice的原因是建立一个为今后的测试和实验中进行错误处理时有一个共同的基础.以下的关于slice语法的提案可以被看作是这方面的一个起点.

2. 语法更改
为了在宏块级对码流进行重新同步,在编码端有一个33位的码字被加入到任一宏块的起始位置.一个33位的码字没有INFO部分的那16位.这些位的用法如下:

9b: MB_nr    |   5b: QP |   2b:  Future use

图象的起始码有31位长,这样将同步字定为33位可以很方便地从一个图象的起始码进行区分.注意这只是一个slice头的一个建议.

3. 语义改更
在不同slice之间的宏块与宏块之间的预测绝不对使用.这些改变有如下的两条规则:

1) INTRA块模式的预测
如果这个块是会被解码为一个INTRA块的话,那么在不同段的块在INTRA模式预测的时候,应该被认为成就像它们不在图象中一样.这一项对于亮度跟色度都是有效的.

2) 运动向量的预测
在不同段的块在计算运动向量的时候,应该被认为就像是在图象外一样.

这个提案开始了在H.264中对slice的设计.在引入了slice之后,在码流中出现错误不再像以前那么可怕,那么难以应付.但是当然因为有一些宏块之间的运动向量的预测被强制取消了,而且语法上更加复杂了,所以码长还是要长一些的.不过在与H.263已有的模式相比,还有H.263的segment比较,slice都体现了它在信噪比上很优秀的性能.回此在之后H.264的设计中,slice这个结构就被保留了下来,但是语法跟语义上还是跟这个提案的设计有差异,至于差异到底在哪里,差多少,回头再说.