KR20090077907A

KR20090077907A - 멀티뷰 비디오 코딩을 위한 참조 화상 목록 관리 구문

Info

Publication number: KR20090077907A
Application number: KR1020097007128A
Authority: KR
Inventors: 퍼빈 비브하스 팬디트; 예핑 수; 펭 인
Original assignee: 톰슨 라이센싱
Priority date: 2006-10-13
Filing date: 2007-10-12
Publication date: 2009-07-16
Also published as: JP2013102504A; US20190182506A1; JP2013038808A; WO2008048499A2; CN102761744B; KR101368493B1; EP2090110A2; JP2015029316A; US20090262804A1; JP5184713B2; JP5619923B2; JP2010507275A; BRPI0716957A2; JP2017126999A; WO2008048499A3; CN102761744A; JP5184539B2; US20160191950A1; US8948256B2; JP6164742B2

Abstract

동화상을 코딩하기 위한 멀티뷰 코더를 위한 화상 참조 목록 순서화 프로세스가 정의되고, 이 경우 그러한 화상 목록은 코딩될 화상이 뷰와 연관되는지(715)에 대한 관계에서 특정된 화상을 코딩하기 위해 사용된 참조 화상들의 코딩 순서를 가진다. 그러므로 화상 목록의 순서화는 참조 화상들이 코딩될 화상과 가지는 시간적인 관계(720)와, 참조 화상과 연관된 뷰들(715)에 따라 화상 참조 목록에서의 참조 화상들의 코딩 순서를 변경하게 된다(725).

Description

멀티뷰 비디오 코딩을 위한 참조 화상 목록 관리 구문{REFERENCE PICTURE LIST MANAGEMENT SYNTAX FOR MULTIPLE VIEW VIDEO CODING}

관련 출원에 대한 상호-참조

본 출원은, 본 명세서에 2006년 10월 13일 출원된 미국 가출원 일련 번호 60/851,863호와 2006년 10월 13일 출원된 미국 가출원 일련 번호 60/851,521호의 이익을 주장하고, 이들 모두 그 전문이 본 명세서에 참조로 통합되어 있다.

본 출원은 일반적으로 동화상 분야에 관한 것으로, 특히 비디오 화상을 코딩하기 위해 사용될 때 참조 화상들의 순서화의 이슈에 관한 것이다.

많은 인터프레임 인코딩 시스템들은 참조 화상들을 사용하고, 그러한 참조 화상들의 사용은 인코딩된 비트 스트림의 크기를 감소시키는 것에 도움이 된다. 이러한 타입의 결과는 인코딩 효율이 단지 인트라 프레임 인코딩 기술들을 단독으로 사용하는 것보다 더 양호하다는 것이다. 그러므로, 많은 인코딩 표준들은 일련의 동영상으로부터 비트스트림을 인코딩하기 위해, 인트라 프레임과 인터 프레임 인코딩 기술 모두를 통합한다. 관련 분야에 공지된 것처럼, 인코딩 표준을 위해 오직 화상 자체 내로부터의 요소들을 사용하여 인코딩되는 "I" 화상(인트라프레임), 화상 자체 내로부터의 요소들을 사용하여 인코딩되는 "B" 화상 및/또는 2개의 이전 참조 화상들로부터의 요소들(인터프레임), 및 화상 자체로부터의 요소들 및/또는 하나의 이전 참조 화상으로부터의 요소들(인터프레임)을 사용하여 인코딩되는 "P" 화상과 같은 상이한 타입의 참조 화상들이 인코딩 표준들을 위해 사용된다.

"B" 또는 "P" 화상들이 인코딩되고/인코딩되거나 디코딩될 때, 그러한 화상들은 다른 참조 프레임들에 의존하게 되어, 그러한 화상들은 디코딩 동작 동안 적당하게 인코딩되거나 구성될 수 있다. 인코딩/디코딩 시스템은 참조 화상이 저장될 수 있도록 일부 타입의 메모리 위치를 제공해야 하지만, 다른 화상들은 그러한 참조 화상들을 고려하여 인코딩되거나 디코딩된다. 이러한 타입의 화상들은 서로 간에 시간적인 관계를 가진다.

이러한 상황은 상이한 비디오 화상들 사이의 다수의 뷰가 고려되어야 하는 비디오 표준을 고려할 때 더 복잡해진다. 예컨대, 도 1은 멀티뷰 비디오 코딩 시스템에서 사용된 참조 화상 구조의 예시적인 실시예를 나타낸다. 특히, 제공된 구조는 2006년 7월 오스트리아 클라겐푸르트(Klagenfurt)에서의 JVT-T208.doc에 A.Vetro, Y. Su, H.Kimata, A. Smolic에 의해 "Joint Multiview Video Model(JMVM) 1.0"에서 제안된 멀티뷰 인코딩(MVC) 구조에 따라 시간(T0 내지 T100) 동안 8개의 상이한 뷰(S0 내지 S7)의 사용에 관한 것이다. 이러한 멀티뷰 인코딩 표준은 AVC(Advanced Video Coding) 표준(2004년 10월 18일부터 22일까지 스페인 Palma de Mallorca에서 G.Sullivan, T.Wiegand, A.Luthra에 의한, "Draft of Version 4 of H.264/AVC{ITU-T 권고안 H.264와 ISO/IEC 14496-10(MPEG-4 part 10) Advanced Video coding}"에서의 코딩에 기초한다. 양 기준의 큰 차이점은 AVC가 멀티뷰 화상의 코딩을 다루지 않는데 비해 MVC는 멀티뷰 화상의 코딩을 다룬다는 것이다.

다시 도 1을 참조하면, 예컨대 T1에서 뷰(S1)와 연관된 화상을 코딩할 때 코딩될 화상이 동일한 뷰(T0에서의 S1과 T2에서의 S1)로부터의 화상들(참조 화상들)과 관련되고, 코딩될 화상이 상이한 뷰(T1에서의 S0과 T1에서의 S2)로부터의 화상들로부터의 화상들에 관련된다는 점을 볼 수 있다. 따라서, S1, T1과 연관된 화상을 코딩할 때, 버퍼, 레지스터, RAM 등과 같은 메모리 디바이스에 참조 화상들(T0에서 S1, T2에서 S1, T1에서 S0, T1에서 S2)을 유지하는 것이 이치에 맞다.

AVC 비디오 표준에서 사용된 것과 같은 참조 화상들을 저장하는 메모리 디바이스와 코더에 관한 동작을 위한 일반화된 구현예가 도 2에 도시되어 있다. 특히, 블록도(200)에서 코더(205), 코딩 버퍼(210), 및 디코딩된 화상 버퍼(DPB)(215)가 개시된다. 코딩 동작(인코딩이나 디코딩) 동안, 코더에 의해 현재 코딩되는 화상이 코딩 버퍼(210)에 존재하는데 반해, 이전에 코딩된 참조 화상들은 디코딩된 화상 버퍼(215)에 저장된다.

하지만, 2개보다 많은 참조 화상의 사용을 요구하는 화상을, 그러한 화상들이 DPB(215)에 저장될 때, 코딩해야할 때 문제가 생긴다. 즉, DPB(215)는 그러한 참조 화상을 코딩 동작 동안 코더(205)에 이용 가능하게 하기 위해, 그러한 참조 화상들에 일부 타입의 조직체를 제공해야 한다. 또한 상이한 참조 화상들이 제 2 화상을 코딩할 때, DPB(215)를 통해 코더(205)에 의해 액세스되어야 할 수 있다는 것을 알아야 한다. 시간적인 경우(AVC와 같은), 이러한 문제는 충분히 복잡하지만, MVC와 같은 비디오 표준에서 화상을 코딩할 때, 상이한 뷰들(도 1에 도시된 것과 같은)로부터 참조 화상들을 고려해야 할 때, 참조 화상들을 이용 가능하게 하는 문제는 확대된다.

종래 기술의 이들 및 다른 결점 및 단점은, 본 발명의 원리에 의해 다루어지고, 이러한 본 발명의 원리는 비디오 인코딩을 위한 움직임 추정 예측기와 같은 이용 가능한 움직임 정보를 재사용하기 위한 방법 및 장치에 관한 것이다.

본 발명의 원리들의 일 양상에 따르면, 디코더에 의해 디코딩되는 화상으로부터의 정보를 고려하여 메모리 디바이스에 저장된 참조 화상에 대해 메모리 관리 동작을 수행하는 코더(coder)가 제공되고, 이러한 경우 그러한 정보는 참조 화상과 연관된 뷰 정보와 관련된다.

본 발명의 원리들의 이들 및 다른 양상, 특징 및 장점은 첨부 도면과 연계하여 읽어질 예시적인 실시예들의 후속하는 상세한 설명으로부터 분명해진다.

본 발명은 후속하는 예시적인 도면에 따라 더 잘 이해될 수 있다.

도 1은 비디오 화상들이 도면 1에 나타난 방식대로 참조 화상들을 사용하여 코딩되는, 상이한 시각에서의 비디오 화상 뷰들을 멀티뷰 코딩하는 예시적인 실시 예를 도시하는 도면.

도 2는 본 발명의 원리들에 따른 비디오 코더의 예시적인 실시예를 도시하는 도면.

도 3은 본 발명의 원리들에 따라 사용된 구문 요소인 ref_pic_list_reordering()을 위한 의사 코드의 일 실시예를 도시하는 도면.

도 4는 본 발명의 원리들에 따라 사용된 구문 요소인 slice_shead_mvc_extension()을 위한 의사 코드의 일 실시예를 도시하는 도면.

도 5는 본 발명의 원리들에 따라 사용된 구문 요소인 ref_pic_list_reordering_mvc_extension()을 위한 의사 코드의 일 실시예를 도시하는 도면.

도 6은 본 발명의 원리들에 따라 사용된 구문 요소인 ref_pic_list_reordering_mvc_extension()을 위한 의사 코드의 일 실시예를 도시하는 도면.

도 7은 본 발명의 원리들에 따른 화상 참조 목록 재순서화(reordering) 방법의 일 실시예의 블록도.

본 발명의 원리들은 임의의 인트라-프레임 및 인터-프레임 기반의 인코딩 표준에 적용될 수 있다. 본 명세서 전반에 걸쳐 사용되는 "화상(picture)"이라는 용어는 "화상"이라는 용어 자체뿐만 아니라 "프레임", "필드", 및 "슬라이스"로서 관 련 분야에 알려질 수 있는 비디오 이미지 정보의 다양한 형태를 설명하기 위한 일반적인 용어로서 사용된다. 비록 화상이라는 용어가 다양한 요소들의 비디오 정보를 나타내기 위해 사용되지만, AVC는 그러한 참조 화상들이 "참조 화상"과 동일한 화상으로부터의 슬라이스들을 사용할 수 있는 슬라이스들의 사용을 가리키고, 화상들이 어떻게 하위분할되는지에 관계없이, 본 발명의 원리들이 적용된다.

또 본 발명의 설명부에서는, C 언어 타입의 포맷팅을 사용하는 다양한 명령들(구문 요소들)이 그러한 명령들에서 설명자들을 위한 후속하는 명명법을 사용하는 도면에서 열거되고 있다.

u(n): n개의 비트를 사용하는 부호 없는 정수. n이 구문 표에서 "v"이라면, 비트들의 개수는 다른 구문 요소들의 값에 의존하는 방식으로 변한다.

이 설명자를 위한 구문 분석 과정은 최상위 비트가 먼저 기입되는 방식의 부호가 없는 정수의 2진 표현으로서 해석된 함수인 read_bits(n)의 반환값에 의해 특정된다.

ue(v): 좌측 비트가 먼저인 부호가 없는 정수인 Exp_Golomb-coded 구문 요소.

se(v): 좌측 비트가 먼저인 부호가 있는 정수인 Exp_Golomb-coded 구문 요소.

C: 구문 요소가 적용될 카테고리, 즉 무슨 레벨에 특별한 필드가 적용되어야 하는지를 나타낸다.

본 설명은 본 발명의 원리를 예시한다. 그러므로, 비록 본 명세서에서 명백 히 설명되거나 도시되지 않을지라도, 당업자라면 본 발명의 원리를 구현하고 본 발명의 취지와 범주 내에 포함되는 다양한 장치를 고안할 수 있다는 것을 알게 된다.

본 명세서에서 인용된 모든 예와 조건부 언어는 읽는 사람으로 하여금 본 발명자(들)가 관련 분야를 발전시키는 데 기여할 본 발명의 원리와 개념을 이해하는데 도움을 주기 위해 교육학적인 목적을 위해 의도되며, 그러한 특별히 인용된 예와 조건들에 제한되지 않은 것으로 여겨져야 한다.

더욱이, 본 명세서에서 본 발명의 원리, 양상, 및 실시예를 인용하는 모든 진술들은, 그것들의 특정 예와 더불어, 그것들의 구조상 및 기능상 등가물 모두를 포함하는 것으로 의도된다. 게다가, 그러한 등가물은 앞으로 개발될 등가물, 즉 구조에 관계없이 동일한 기능을 수행하는 발전된 임의의 요소뿐만 아니라 현재 알려진 등가물 모두를 포함하는 것으로 의도된다.

도 2를 다시 참조하면, 코더(205)(AVC와 MVC 하의)가 동화상이 인코딩되는 인코딩 동작을 수행할 때, 인코딩된 화상은 몇몇 상이한 값과 연관되고, 이 경우 그러한 값은 코더(205)에 의해 화상 헤더(예컨대, 슬라이스 헤더)에 놓인다. pic_num(화상 번호)라고 부르는 제 1 값은 코딩된 비디오 화상들의 시퀀스에서 코딩될 때 화상의 순서를 표시한다. 예컨대, 그 시퀀스에서의 제 1 화상은 "1"의 값을 가지는데 반해, 코딩되는 제 4 값은 "4"의 값을 가지게 된다.

화상은 또한 코딩된 화상이 마지막으로 디코딩될 때 디스플레이되어야 하는 순서를 결정하는 화상 순서 카운트(POC: picture order count)라고 부르는 값을 가지게 된다. 이는 그 화상과 연관된 POC 번호와는 상이한 프레임 번호를 코딩된 화 상이 가지는 것이 가능하다는 것을 의미한다.

멀티-뷰 비디오 코딩은 한 화상과 관련하여 사용될 수 있는 제 3 값을 도입한다. view_id(view id) 값은 화상이 대응하는 뷰를 표시한다. 예컨대, 뷰(S3)와 연관되는 화상은 "3"과 같은 view_id를 가지고, 뷰(S5)에 대응하는 화상은 "5"와 같은 view_id를 가진다. view_id 번호는 또한 그러한 값의 사용이 코더로 하여금 동일한 pic_num 및/또는 POC를 지닌 참조 화상들을 저장하기 위해 DPB(215)를 제공하는, 상이한 뷰들 사이의 POC와 pic_num을 분리시키는 것을 허용하기 때문에 도움이 된다. 그러므로 그러한 화상들(동일한 POC 또는 pic_num을 가짐)은 view_id 값을 사용함으로써 서로 구별된다.

위에서 설명된 값들이 상이한 방식{다른 번호들, 다양한 이름들, 해시(hash) 테이블 등}으로 구현될 수 있음을 알아야 한다.

DPB(215)에 참조 화상들을 저장할 때(http://www.rgu.ac.uk/files/avc_picmanagement_draft1.pdf에 위치한 lain G Richardson에 의한 "Frame and Picture Management"에서 설명된 것과 같이), 그러한 화상들에는 단기 참조 화상(PicNum이나 PicOrderCount에 의한 참조인)이나 장기 참조 화상(LongTermPic 인덱스에서의 번호를 나타내는 LongTermPicNum에 의한 참조인)으로서 참조 화상을 마킹하는 메모리 상태가 할당된다. 참조 화상의 상태는 장기, 단기, 또는 심지어 참조 화상이 종국에는 DPB(215)로부터 제거되는 "참조가 아님(not a reference)"이라고 알려진 상태 사이에서 변경(예컨대, AVC에서 알려진 것과 같이, 메모리 관리 명령 오퍼레이터의 사용에 의해)될 수 있다는 것이 이해되 어야 한다.

참조 화상들의 조직화는 화상(슬라이스)을 코딩하기 전에 사용되는 1개 또는 2개의 목록으로 순서화된다. P 화상을 위한 참조는 화상들의 단일 목록(list0)을 사용하는데 반해, B 화상은 2개의 목록(list0,list1)을 사용하게 된다. 화상 목록에서의 화상의 디폴트 조직화(default organization)는, 코딩되는 현재 화상이 P 화상일 때에는 디코딩 순서(PicNum)에, 코딩되는 현재 화상이 B 화상일 때에는 디스플레이 순서에 의존한다. 장기 참조 화상들로 지정되는 참조 화상들은 통상적으로 LongTermPicNum이 할당되고, 한 위치에서의 참조 목록에 놓여, 그 화상은 단기 화상보다 긴 시간 동안 남아 있게 된다.

AVC는 화상 슬라이스를 코딩할 때, 코더(205)로 하여금 list0{와, B 화상들(슬라이스들)을 위한 list1}에서의 참조 화상들의 디폴트 순서를 변경하는 것을 허용한다. 즉, 코더는 1개의 참조 화상(목록에서의)이 참조 목록에서 표시된 것보다 나은 참조 화상일 수 있다는 것을 인식할 수 있다. 이는 또한 참조 화상을 코딩될 현재 화상에 더 상관되게 만들어, 코딩될 화상에 덜 관련되는 참조 화상보다 인덱스들에서 더 낮은(더 가까운) 참조 목록 상의 위치를 점유함으로써 코딩 효율 면에서 도움이 되게 한다. 따라서, RPLS(Reference Picture List Reordering) 명령들이라고 알려진 명령들이 그러한 참조 화상들의 순서를 이동시키는데 사용되고, 도 3에 도시되어 있다.

도 3은 AVC 구문 요소인 ref_pic_list_reordering(비록 위에서 설명한 바와 같이, 그러한 개념들이 화상들에 관해 수행될 수 있다고 알아야 하지만, 슬라이스 들에 관련해 설명되는)이 화상 목록을 재순서화하기 위해 사용된 AVC 명령들을 제공하고, 그것들의 의미가 AVC 참조로 설명되는 것을 도시한다.

MVC의 상황 내에서 참조 화상 목록들을 사용하는 것을 고려할 때, 실제로는 시간적인 참조들만을 고려하는 AVC와는 반대로, 시간적인 참조들과 크로스-뷰(cross-view) 참조들이 존재하는 고려할 참조들의 2개의 세트가 존재하게 된다.

따라서, 종래 기술에서는 모든 비디오 시퀀스들을 단일 시퀀스 내로 인터리브(interleave)한 다음, AVC 가능한(capable) 코더에 의해 코딩될 수 있으며, 적합한 비트 스트림을 만들어낼 수 있는 단일 인터리브된 시퀀스를 구성하는 것이, 2006년 1월 태국, 방콕의 m12945에서 K.Muller, P.Merkle, A.Smolic, T.Wiegand에 의한 "Multiview Coding using AVC"라는 제목의 논문에 개시된 것과 같은 원리들에 제안되었다. 그러나, 다시 한번, 비록 이러한 제안된 AVC 구현예의 다운사이드(downside)는 임의의 화상이 어느 뷰에 속하는지를 식별하는 방법은 없다는 것이며, 이는 pic_num과 POC에 관한 고유한 값들이 그것들이 AVC에서 현재 존재할 때, RPLP 명령들을 구현하기 위해 코딩되는 각 화상에 할당되어야 하기 때문이다.

MVC의 현재 구현예에 관해서는, 크로스 뷰 참조들을 시그널링하기 위해, SPS(Sequence Parameter Set)에 추가되는 추가 구문을 통합하는 것이 제안되었다. 아래에 도시된 것처럼, 이러한 구문 요소는 앵커(anchor)와 비-앵커(non-anchor) 화상들을 위해 사용될 크로스-뷰 참조들을 표시하기 위해 사용된다.

현재 뷰와는 상이한 뷰로부터의 참조 화상들을 참조 예측 목록들에 놓기 위해, 다음 절차가 행해진다.

- 0부터 num_multiview_ref_for_listX-1까지의 i의 각 값에 관해,

- 현재 화상과 시간적으로 정렬되는 view reference_view_for_list_X[i]로부터의 재구성된 화상이 얻어지고, 디코딩된 예측 버퍼(DPB: decoded prediction buffer)로 삽입된다.

- 그러한 화상에 대한 인덱스가 RefPicListX에서의 다음 빈 슬롯 내로 삽입된다.

하지만 이러한 구현예는 변경될 수 없는 참조 화상 목록을 초기화하는(그리고 구성하는) 고정된 방식이 존재한다는 문제점을 가진다. 즉, 시간적이고 크로스-뷰 화상들의 순서에 있어 유연성이 존재하지 않는다. 또한, 각 앵커(I)와 비-앵커 화상(B,P)에 관해 지정된 참조 화상들의 개수가 동일하다.

그러므로, 본 발명은 멀티뷰 화상들을 고려하는 참조 화상 목록을 어떻게 재순서화해야할 지에 관한 프레임워크를 제안한다. 비록 본 발명의 실시예들이 AVC와 MVC 환경들의 상황 내에서 개시된다는 점이 이해되어야 하지만, 본 발명의 원리들이 또한 다른 비디오 코딩 표준들에 적용된다는 점이 이해되어야 한다.

본 발명은 화상 헤더(슬라이스 헤더)에서 존재하는 바와 같은 도 4에서 새로운 요소 구문인 ref_pic_list_reordering_mvc_extension()을 제안한다.

첫 번째로는, 본 발명이 AVC 적합한 구문 요소들인 num_ref_idx_I0_active_minus1과 num _ ref _ idx _ I1 _ active _ minus1이, 그것들이 시간적인 의미에서 활성화하는 참조 화상들의 개수만을 표시한다는 사실을 반영하기 위해 재정의되어야 한다는 점을 제안한다.

num _ ref _ idx _ I0 _ active _ minus1은 슬라이스를 디코딩하기 위해 사용될 시간적인 참조 화상 목록0에 관한 최대 참조 인덱스를 특정한다. num_ref_idx_I0_active_minus1의 범위는 다음과 같이 특정된다.

- field_pic_flag가 0과 같다면, num_ref_idx_I0_active_minus1이 0과 15 사이의 범위에 있게 된다. MbaffFrameFlag가 1과 같을 때에는, num_ref_idx_I0_active_minus1은 프레임 매크로블록들의 디코딩을 위한 최대 인덱스 값이고, 2*num_ref_idx_I0_active_minus1+1은 필드 매크로블록들의 디코딩을 위한 최대 인덱스 값이다.

- 그렇지 않으면(field_pic_flag가 1과 같다면), num_ref_idx_I0_active_minus1이 0과 31 사이의 범위에 있게 된다.

num _ ref _ idx _ I1 _ active _ minus1은 I0과 list0이 각각 I1과 list1로 대체된 num_ref_idx_I0_active_minus1과 동일한 의미를 가진다.

두 번째로는, 크로스-뷰 의미가 될 활성화하는 참조 화상들의 개수를 표시하는 2개의 새로운 구문 요소들이 제안된다.

num _ ref _ idx _ I0 _ active _ view _ minus1은 슬라이스를 디코딩하기 위해 사용되는 크로스-뷰 참조 화상 목록0에 관한 최대 참조 인덱스를 특정한다. num_ref_idx_I0_active_view_minus1의 범위는 다음과 같이 특정된다.

- field_pic_flag가 0과 같다면, num_ref_idx_I0_active_view_minus1이 0과 15 사이의 범위에 있게 된다. MbaffFrameFlag가 1과 같을 때에는, num_ref_idx_I0_active_minus1은 프레임 매크로블록들의 디코딩을 위한 최대 인덱 스 값이고, 2*num_ref_idx_I0_active_view_minus1+1은 필드 매크로블록들의 디코딩을 위한 최대 인덱스 값이다.

- 그렇지 않으면(field_pic_flag가 1과 같다면), num_ref_idx_I0_active_view_minus1이 0과 31 사이의 범위에 있게 된다.

num _ ref _ idx _ I1 _ active _ view _ minus1(나머지 제안된 구문 요소)은 I0과 list0이 각각 I1과 list1로 대체된 num_ref_idx_I0_active_view_minus1과 동일한 의미를 가진다.

이들 2개의 구문은 그것들이 다음 식들을 만족하도록 하는 값들을 가진다.

num_ref_idx_I0_active_minus1+num_ref_idx_I0_active_view_minus1<=num_ref_frames

및

num_ref_idx_I1_active_minus1+num_ref_idx_I1_active_view_minus1<=num_ref_frames.

전술한 바와 같이, MVC 시스템에 관한 디폴트 초기화 프로세스가 정의될 필요가 있다. 따라서, 몇몇 상이한 실시예들이 그러한 프로세스를 위해 제안된다.

본 발명의 원리들의 제 1 실시예는 MPEG-4 AVC 사양(specification)에서 정의된 것과 같이 초기화되는 현재 뷰의 시간적인 화상들 전부를 가진다. 이러한 초기화된 목록은 이후 각각 LIST_0과 LIST_1에 관한 num_ref_idx_I0_active_minus1과 num_ref_idx_I1_active_minus1에서 특정된 값에 의해 끝이 잘린다.

이들 화상 다음에는, MVC 사양의 SPS에서 특정된 크로스-뷰 참조 화상들이 삽입되고, 각각 LIST_0과 LIST_1에 관한 num_ref_idx_I0_active_view_minus1과 num_ref_idx_I1_active_view_minus1에서 특정된 값에 의해 끝이 잘린다.

현재 MVC 사양에서 특정된 것과 같은 참조 화상 목록 재순서화 명령들이 올바르게 기능하는 것을 허용하기 위해, 이들 명령이 시간적 참조 화상들에만 작용할 수 있는 제한을 둔다. RPLR 프로세스는 시간적 화상들의 초기화 직후와 크로스-뷰 참조의 초기화 전에 따라올 수 있고, 또는 시간적 및 크로스 뷰 참조 모두가 그들의 디폴트 위치로 초기화된 이후에 올 수 있으며, 나중의 경우에는 시간적인 참조 화상들만이 재순서화된다.

이러한 제 1 제안된 실시예에 대한 한 가지 결점은, 크로스 뷰 참조 화상들이 재순서화될 수 없다는 점이다.

MVC 사양의 SPS에서 특정된 크로스-뷰 참조 화상들이 삽입되고, 각각 LIST_0과 LIST_1에 관한 num_ref_idx_I0_active_view_minus1과 num_ref_idx_I1_active_view_minus1에서 특정된 값에 의해 끝이 잘리는 제 2 실시예가 제안된다.

이들 화상 다음에는, 현재 뷰의 모든 시간적인 화상이 MPEG-4 AVC 사양에서 정의된 것과 같이 초기화된다. 이는 이후 각각 LIST_0과 LIST_1에 관한 num_ref_idx_I0_active_minus1과 num_ref_idx_I1_active_minus1에서 특정된 값에 의해 끝이 잘린다.

전술한 제 1 실시예가 지닌 문제점을 다루기 위해 제 3 실시예가 제안된다. 특히, 2006년 10월 13일에 출원된 미국 가출원 일련 번호 60/851,522호와, 2006년 10월 13일에 출원된 미국 가출원 일련 번호 60/851,589호로부터 우선권을 주장하는 2007년 10월 12일에 출원된 PCT 출원을 참조하면[일련 번호는 결정 예정임], 구문 요소인 long _ term _ frame _ idx가 장기 인덱스(값)를 현재 코딩되는 화상과 연관된 뷰와는 상이한 view_id를 지닌 화상에 할당하기 위해 사용된다. 장기 인덱스를 크로스-뷰 화상들에 할당함으로써, 그러한 화상들은 그것들이 장기 화상들에 적용된 것과 같은 RPLR 명령들의 사용을 허용하는 AVC 화상들로서 사용되는 것처럼 취급될 수 있다. 따라서, 크로스-뷰 화상들은 AVC를 사용하여 효율적으로 재순서화될 수 있다.

새로운 RPLP 명령들이 제안되는 제 4 실시예가 또한 제안된다. 이들 명령들은 DPB(215)를 제어하기 위해 사용되는 메모리 관리 명령들 동작과 유사하지만, 이들 새로운 명령들은 현재 동작되는 화상과 연관된 뷰 외의 뷰들에서의 화상에 대해 동작하도록 사용된다. 이들 새로운 구문 요소들은 제안된 MVC 참조 화상 목록 재순서화 구문을 보여주는 도 5에 나타난다.

이 실시예에 관한 디폴트 초기화는 먼저 H.264/MPEG-4 AVC 사양에서 정의된 것과 같이 참조 목록 초기화에서 특정된 대로 시간적 참조 전부를 순서화한 다음, H.264/MPEG-4 AVC의 MVC 확장의 SPS에서 특정되는 크로스-뷰 화상들을 지닌 이들 화상 다음에 오는 것일 수 있다.

이러한 실시예의 동작 부분은 구문 요소들이 ref_pic_list_reordering_mvc_extension 사이에서 분리되는 것이고, 호출된 구문 요소인 ref_pic_list_reordering을 가질 수 있다. 즉, 호출의 조직화는 MVC 환경에 서 처리된 멀티뷰 기반의 화상들을 가질 수 있고, 그러한 프로세스의 결과들이 AVC 환경에서 처리된 멀티뷰 참조 기반의 화상들을 가질 수 있다.

인덱스인 mvc_reordering_of_pic_nums_idc와 관련하여 사용된 다양한 상태들이 아래 표 1에 개시되어 있다.

mvc_reordering_of_pic_nums_idc	특정된 재순서화
0	abs_diff_pic_num_minus1이 존재하고, 화상 번호 예측값으로부터 빼기 위한 차(difference)에 대응한다.
1	abs_diff_pic_num_minus1이 존재하고, 화상 번호 예측값에 더하기 위한 차(difference)에 대응한다.
2	long_term_pic_num이 존재하고, 참조 화상에 관한 장기 화상 번호를 특정한다.
3	초기 참조 화상 목록의 재순서화에 관한 루프를 종료한다.

또한, 구문 요소들인 mvc_reordering_of_pic_nums_idc, abs_diff_pic_num_minus1, 및 long_term_pic_num이 초기 참조 화상 목록들로부터 슬라이스를 디코딩하기 위해 사용될 참조 화상 목록들로의 변경을 특정한다.

1과 같은 mvc _ ref _ pic _ list _ reordering _ flag _ I0은 참조 화상 목록0을 특정하기 위해, 구문 요소인 mvc_reordering_of_pic_nums_idc가 존재한다는 것을 특정한다. 0과 같은 mvc_ref_pic_list_reordering_flag_I0은 이러한 구문 요소가 존재하지 않는다는 것을 특정한다.

mvc_ref_pic_list_reordering_flag_I0이 1과 같을 때에는, mvc_ref_pic_list_reordering_flag_I0 다음에 오는, mvc_reordering_of_pic_nums_idc가 3과 같지 않은 경우의 개수는 num_ref_idx_I0_active_minus1+1을 초과하지 않게 된다.

H.264/MPEG-4 AVC 사양에서 특정된 것처럼 만들어진 초기 참조 화상 목록에서의 RefPicList0[num_ref_idx_I0_active_minus1]이 "참조 화상 없음"과 같을 때에는, mvc_ref_pic_list_reordering_flag_I0이 1과 같게 되고, H.264/MPEG-4 AVC 사양에서 특정된 것처럼 만들어진 재순서화된 목록에서의 RefPicList0[num_ref_idx_I0_active_minus1]이 "참조 화상 없음"과 같지 않을 때까지, mvc_reordering_of_pic_nums_idc는 3과 같지 않게 된다.

1과 같은 mvc _ ref _ pic _ list _ reordering _ flag _ I1은 구문 요소인 mvc_reordering_of_pic_nums_idc가 참조 화상 목록1을 특정하기 위해 존재함을 특정한다. 0과 같은 mvc_ref_pic_list_reordering_flag_I1은 이러한 구문 요소가 존재하지 않음을 특정한다.

mvc_ref_pic_list_reordering_flag_I1이 1과 같을 때에는, mvc_ref_pic_list_reordering_flag_I1 다음에 오는, mvc_reordering_of_pic_nums_idc가 3과 같지 않은 경우의 개수는 num_ref_idx_I1_active_minus1+1을 초과하지 않게 된다.

H.264/MPEG-4 AVC 사양에서 특정된 것처럼 만들어진 초기 참조 화상 목록에서의 RefPicList1[num_ref_idx_I1_active_minus1]과 B 슬라이스를 디코딩하는 것이 "참조 화상 없음"과 같을 때에는, mvc_ref_pic_list_reordering_flag_I1이 1과 같게 되고, H.264/MPEG-4 AVC 사양에서 특정된 것처럼 만들어진 재순서화된 목록에서의 RefPicList1[num_ref_idx_I1_active_minus1]이 "참조 화상 없음"과 같지 않을 때까지 mvc_reordering_of_pic_nums_idc는 3과 같이 않게 된다.

mvc _ reordering _ of _ pic _ nums _ idc는 difference_of_view_id, abs_diff_pic_num_minus1 또는 long_term_pic_num과 함께, 참조 화상 중 어느 것이 다시 맵핑되는지를 특정한다. mvc_reordering_of_pic_nums_idc의 값들은 H.264/MPEG-4 AVC 사양에서 특정된다. mvc_ref_pic_list_reordering_flag_I0 또는 mvc_ref_pic_list_reordering_flag_I1 직후 나오는 제 1 mvc_reordering_of_pic_nums_idc의 값들은 3과 같지 않게 된다.

abs _ diff _ pic _ num _ minus1 plus 1은 목록에서의 현재의 인덱스로 이동되는 화상의 화상 번호와 화상 번호 예측 값 사이의 절대차(absolute difference)를 특정한다. abs_diff_pic_num_minus1은 0 내지 MaxPicNum-1의 범위에 있게 된다. 이동되는 화상은 현재 화상의 view_id와는 상이한 view_id를 가져야 한다.

long _ term _ pic _ num은 목록에서의 현재 인덱스로 이동되는 화상의 장기 화상 번호를 특정한다. 코딩된 프레임을 디코딩할 때, long_term_pic_num은 "장기 참조를 위해 사용됨"이라고 마킹되는 보충 참조 필드 쌍들이나 참조 프레임들 중 하나에 할당된 LongTermPicNum과 같게 된다. 코딩된 필드를 디코딩할 때, long_term_pic_num은 "장기 참조를 위해 사용됨"으로 마킹된 참조 필드들 중 하나에 할당된 LongTermPicNum과 같게 된다. 이동되는 화상은 현재 화상의 view_id와는 상이한 view_id를 가져야 한다.

difference _ of _ view _ id는 목록에서의 현재 인덱스로 이동되는 화상의 view_id와 view_id 예측값 사이의 차이를 특정한다.

참조 화상들의 재순서화를 수행하기 위한 프로세스는, 디폴트 목록에 기초하고 아래와 같이 설명될 수 있다.

mvc_ref_pic_list_reordering_flag_I0이 1과 같을 때에는, 다음 내용이 적용된다.

- refldxL0을 참조 화상 목록인 RefPicList0으로의 인덱스로 한다. 그것은 처음에 0과 같도록 설정된다.

- 대응하는 구문 요소인 mvc_reordering_of_pic_nums_idc는 그것들이 비트스트림에서 발생하는 순서대로 처리된다. 이들 구문 요소들 각각에 관해, 다음 내용이 적용된다.

1) mvc_reordering_of_pic_nums_idc가 0과 같거나 1과 같다면, 아래의 Ⅰ에 특정된 프로세스는 입력으로서 refldxL0으로 불러 내어지고, 그 출력에는 refldxL0이 할당된다.

2) 그렇지 않고, mvc_reordering_of_pic_nums_idc가 2와 같다면, 아래의 Ⅱ에 특정된 프로세스는 입력으로서 refldxL0으로 불러 내어지고, 그 출력에는 refldxL0이 할당된다.

3) 이 외에는(mvc_reordering_of_pic_nums_idc가 3과 같다면), 참조 화상 목록인 RefPicList0에 관한 재순서화 프로세스가 종료된다.

mvc_ref_pic_list_reordering_flag_I1이 1과 같을 때에는, 다음 내용이 적용된다.

- refldxL1을 참조 화상 목록인 RefPicList1로의 인덱스로 한다. 그것은 처음에 0과 같도록 설정된다.

4) mvc_reordering_of_pic_nums_idc가 0과 같거나 1과 같다면, 아래의 Ⅰ에 특정된 프로세스는 입력으로서 refldxL1로 불러 내어지고, 그 출력에는 refldxL1이 할당된다.

5) 그렇지 않고, mvc_reordering_of_pic_nums_idc가 2와 같다면, 아래의 Ⅱ에 특정된 프로세스는 입력으로서 refldxL1로 불러 내어지고, 그 출력에는 refldxL1이 할당된다.

6) 이 외에는(mvc_reordering_of_pic_nums_idc가 3과 같다면), 참조 화상 목록인 RefPicList1에 관한 재순서화 프로세스가 종료된다.

현재 코딩되는 화상의 view_id와는 상이한 view_id를 지닌 단기 참조 화상들에 관한 참조 화상 목록들을 재순서화하기 위해, 다음 내용이 제안된다.

이러한 프로세스에는 인덱스인 refldxLX(X는 0이거나 1인)가 입력된다.

이러한 프로세스의 출력은 증가된(incremented) 인덱스인 refldxLX이다.

viewldLX = viewldLXPred + difference_of_view_id

변수인 picNumLXNoWrap은 다음과 같이 유도된다.

- If mvc_reordering_of_pic_nums_idc is equal to 0

if(picNumLXPred-(abs_diff_pic_num_minus1+1)<0)

picNumLXNoWrap = picNumLXPred-(abs_diff_pic_num_minus1+1)+

MaxPicNum

else

picNumLXNoWrap = picNumLXPred-(abs_diff_pic_num_minus1+1)

- Otherwise(mvc_reordering_of_pic_nums_idc is equal to 1),

if(picNumLXPred+(abs_diff_pic_num_minus1+1)>=MaxPicNum)

picNumLXNoWrap = picNumLXPred+(abs_diff_pic_num_minus1+1)

MaxPicNum

else

picNumLXNoWrap = picNumLXPred+(abs_diff_pic_num_minus1+1).

viewldLXPred는 변수인 viewldLX에 관한 예측 값이다. 이 부절(subclause)에 특정된 프로세스가 슬라이스에 관해 처음으로 불러 내어질 때{즉, ref_pic_list_reordering() 구문에서 처음으로 발생하는 mvc_reordering_of_pic_nums_idc가 0 또는 1과 같을 때}, viewldL0Pred와 viewldL1Pred는 처음에 CurrViewld와 같게 설정된다. viewldLX의 각 할당 후, viewldLX의 값이 viewldLXPred에 할당된다.

picNumLXPred는 변수인 picNumLXNoWrap에 관한 예측 값이다. 이 부절에 특정된 프로세스는 슬라이스에 관해 처음으로 불러 내어질 때{즉, ref_pic_list_reordering() 구문에서 처음으로 발생하는 mvc_reordering_of_pic_nums_idc가 0 또는 1과 같을 때}, picNumL0Pred와 picNumL1Pred는 처음에 CurrPicNum과 같게 설정된다. picNumLXNoWrap의 각 할당 후, picNumLXNoWrap의 값이 PicNumldLXPred에 할당된다.

변수인 picNumLX는 다음과 같이 유도된다.

if(picNumLXNoWrap > CurrPicNum)

picNumLX = picNumLXNoWrap - MaxPicNum

else

picNumLX = picNumLXNoWrap

picNumLX와 viewldLX는 "단기 참조를 위해 사용됨"이라고 마킹되는 참조 화상의 PicNum과 viewld와 같게 되고, "존재하지 않음"이라고 마킹되는 단기 참조 화상의 PicNum과 같지 않게 된다.

다음 절차들, 즉 viewldLX와 같은 view_id를 지닌 단기 화상 번호인 picNumLX를 지닌 화상을 인덱스 위치인 refldxLX에 놓고, 임의의 다른 나머지 화상들의 위치를 목록에서의 더 나중으로 이동시키며, refldxLX의 값을 증가시키는 것이 행해진다.

이 경우, 함수인 PicNumF(RefPicListX[cldx])가 다음과 같이 유도된다.

- 화상인 RefPicListX[cldx]가 "단기 참조를 위해 사용됨"으로 마킹되면, PicNumF(RefPicListX[cldx])는 화상인 RefPicListX[cldx]의 PicNum이다.

- 그렇지 않으면{화상인 RefPicListX[cldx]가 "단기 참조를 위해 사용됨"이라고 마킹되지 않는다}, PicNumF(RefPicListX[cldx])는 MaxPicNum과 같다.

MaxPicNum의 값은 결코 picNumLX와 같을 수 없다는 점이 주목된다.

이 경우 함수인 ViewldF(RefPicListX[cldx])는 다음과 같이 유도된다.

- ViewldF(RefPicListX[cldx])는 화상인 RefPicListX[cldx]의 viewld이다.

또한, 이러한 의사 코드 절차 내에서는, 목록 RefPicListX의 길이가 최종 목록에 관해 필요로 한 길이보다 한 요소만큼 더 길게 시간적으로 만들어진다는 것을 주목하라. 이러한 절차를 실행한 후, 목록에서 0부터 num_ref_idx_IX_active_minus1까지의 요소만이 남아 있을 필요가 있다.

장기 참조 화상들을 포함하는 참조 화상 목록들의 재순서화를 위해, 다음 내용이 제안된다.

이러한 프로세스의 입력은 인덱스 refldxLX(X는 0 또는 1)이다.

이러한 프로세스의 출력은 증가된 인덱스 refldxLX이다.

다음 절차들, 즉 위에서 유도된 바와 같은 viewldLX에 의해 표시된 뷰에 존재하는 장기 화상 번호인 long_term_pic_num을 지닌 화상을 인덱스 위치인 refldxLX에 놓고, 임의의 다른 나머지 화상들의 위치를 목록에서의 더 나중으로 이동시키며, refldxLX의 값을 증가시키는 것이 행해진다.

이 경우, 함수인 LongTermPicNumF(RefPicListX[cldx])가 다음과 같이 유도된다.

- 화상인 RefPicListX[cldx]가 "장기 참조를 위해 사용됨"으로 마킹되면, LongTermPicNumF(RefPicListX[cldx])는 화상인 RefPicListX[cldx]의 LongTermPicNum이다.

- 그렇지 않으면{화상인 RefPicListX[cldx]가 "장기 참조를 위해 사용됨"이라고 마킹되지 않는다}, LongTermPicNumF(RefPicListX[cldx]는 2*(MaxLongTermFrameldx+1)과 같다.

2*(MaxLongTermFrameldx+1)의 값은 결코 long_term_pic_num과 같을 수 없다는 점이 주목된다.

- 화상인 RefPicListX[cldx]가 "단기 참조를 위해 사용됨"이라고 마킹되면, ViewldF(RefPicListX[cldx])는 화상인 RefPicListX[cldx]의 viewld이다.

- 그렇지 않으면{화상인 RefPicListX[cldx]가 "단기 참조를 위해 사용됨"이라고 마킹되지 않는다}, PicNumF(RefPicListX[cldx]는 MaxPicNum과 같다.

또한 MaxPicNum의 값이 결코 picNumLX와 같을 수 없다는 것이 주목되고, 이러한 의사-코드 절차 내에서 목록인 RefPicListX의 길이는 최종 목록을 위해 필요로 하는 길이보다 한 요소만큼 길게 시간적으로 만들어진다. 이러한 절차를 실행한 후, 목록의 0부터 num_ref_idx_IX_active_minus1까지의 요소만이 남아 있을 필요가 있다.

본 발명의 원리들을 위한 추가 프레임워크가, 도 6에 도시된 구문 요소인 ref_pic_reordering_mvc_extension()에 관해 아래에 개시되고 설명된다. 이러한 구문 요소의 동작과 도 5에 관해 설명된 구문 요소 사이의 한 가지 차이점은, 재순서화 목록들이, 임의의 뷰에 관해 행해질 수 있으며 별도의 ref_pic_list_reordering 명령(도 3에 도시된 것과 같은)을 호출해야 하는 대신, 그러한 재순서화가 오직 하나의 호출을 사용함으로써, 행해지도록 된다.

이러한 대안적인 프레임워크 하의 제 1 실시예에 관해, 변수인 num_ref_idx_IO_active_minus1과 num _ ref _ idx _ I1 _ active _ minus1이 시간적인 의미에서 활성화하는 참조 화상들의 개수를 나타내기 위해, 다시 재정의된다(이들 변수를 설명하는 이전 섹션들을 보라).

이러한 실시예는 변수인 num _ ref _ idx _ IO _ active _ view와 num_ref_idx_I1_active_view를 정의하고, 이들은 크로스 뷰에서 활성화하는 화상들의 개수를 표시하기 위해 사용된다.

num _ ref _ idx _ IO _ active _ view는 슬라이스를 디코딩하기 위해 사용될 크로스-뷰 참조 화상 목록0에 관한 최대 참조 인덱스를 특정한다. num_ref_idx_IO_active의 범위는 다음과 같이 특정된다.

- field_pic_flag가 0과 같다면, num_ref_idx_IO_active_view는 0과 16 사이의 범위에 있게 된다. MbaffFrameFlag가 1과 같게 되면, num_ref_idx_IO_active_view는 프레임 매크로블록들의 디코딩을 위한 최대 인덱스 값이고, 2*num_ref_idx_IO_active_view는 필드 매크로블록들의 디코딩을 위한 최대 인덱스값이다.

- 그렇지 않으면(field_pic_flag가 1과 같다), num_ref_idx_IO_active_view는 0과 32 사이의 범위에 있게 된다.

num_ref_idx_I1_active_view는 I1과 목록1로 각각 대체된 I0과 목록0을 지닌 num_ref_idx_IO_active_view와 동일한 의미를 가진다.

이들 구문은 다음 식을 만족하도록 하는 값을 가진다.

num_ref_idx_IO_active_minus1+num_ref_idx_IO_active_view<=num_ref_frames

및

num_ref_idx_I1_active_minus1+num_ref_idx_I1_active_view<=num_ref_frames

앞에서 언급했던 것처럼, MVC 시스템을 위한 디폴트 초기화 프로세스는 명확히 정의될 필요가 있다.

첫 번째로는, 현재 뷰의 모든 시간적 화상들이 MPEG-4 AVC 사양에서 정의된 것과 같이 초기화된다. 이는 단기 참조와 장기 참조를 포함한다. 이 목록은 각각 LIST_0과 LIST_1에 관한 num_ref_idx_IO_active_minus1과, num_ref_idx_I1_active_minus1에 특정된 값에 의해 끝이 잘린다.

이들 화상 다음에는 MVC 사양의 SPS에서 특정된 크로스-뷰 참조 화상들이 삽입되고, 각각 LIST_0과 LIST1에 관한 num_ref_idx_IO_active_view와, num_ref_idx_I1_active_view에 특정된 값에 의해 끝이 잘린다.

기존의 H.264/MPEG-4 AVC RPLR 명령들과 유사한 새로운 RPLR 명령들이 도입된다. 이들 명령은 기존의 H.264/MPEG-4 AVC에서의 RPLR 명령을 대체한다(도 6 참조).

새로운 RPLR 명령은 다음 의미를 가진다. 재순서화 명령들이 존재하는지를 표시하기 위한 명령은 위 표 1에 도시된다.

구문 요소인 mvc _ reordering _ of _ pic _ nums _ idc, abs _ diff _ pic _ num _ minus1, 및 long_term_pic_num은, 화상 정보(슬라이스와 같은)를 디코딩하기 위해, 초기 참조 화상 목록들로부터 사용될 참조 화상 목록들로의 변경을 특정한다.

1과 같은 mvc _ ref _ pic _ list _ reordering _ flag _ I0은 구문 요소인 mvc_reordering_of_pic_nums_idc가 참조 화상 목록0을 특정하기 위해 존재한다는 점을 특정한다. 0과 같은 mvc_ref_pic_list_reordering_flag_I0은 이러한 구문 요소가 존재하지 않는다는 점을 특정한다.

mvc _ ref _ pic _ list _ reordering _ flag _ I0이 1과 같을 때에는, mvc_ref_pic_list_reordering_flag_I0 다음에 오는, mvc_reordering_of_pic_nums_idc가 3과 같지 않은 경우의 개수는 num_ref_idx_I0_active_minus1+1+num_ref_idx_I0_active_view를 초과하지 않게 된다.

H.264/MPEG-4 AVC 사양에서 특정된 것처럼 만들어진 초기 참조 화상 목록에서의 RefPicList0[num_ref_idx_I0_active_minus1+1+num_ref_idx_I0_active_view]가 "참조 화상이 없음"과 같을 때에는, mvc_ref_pic_list_reordering_flag_I0이 1과 같게 되고, H.264/MPEG-4 AVC 사양에서 특정된 것처럼 만들어진 재순서화된 목록에서의 RefPicList0[num_ref_idx_I0_active_minus1+1+num_ref_idx_I0_active_view]가 "참조 화상 없음"과 같지 않을 때까지, mvc_reordering_of_pic_nums_idc는 3과 같지 않게 된다.

1과 같은 mvc_ref_pic_list_reordering_flag_I1은 구문 요소인 mvc_reordering_of_pic_nums_idc가 참조 화상 목록1을 특정하기 위해 존재한다는 점을 특정한다.

0과 같은 mvc_ref_pic_list_reordering_flag_I1은 이러한 구문 요소가 존재하지 않는다는 점을 특정한다.

mvc_ref_pic_list_reordering_flag_I1가 1과 같을 때에는, mvc_ref_pic_list_reordering_flag_I1 다음에 오는, mvc_reordering_of_pic_nums_idc가 3과 같지 않은 경우의 개수가 num_ref_idx_I1_active_minus1+1+num_ref_idx_I1_active_view를 초과하지 않게 된다.

B 슬라이스를 디코딩하고, H.264/MPEG-4 AVC 사양에서 특정된 것처럼 만들어진 초기 참조 화상 목록에서의 RefPicList1[num_ref_idx_I1_active_minus1+num_ref_idx_I1_active_view]가 "참조 화상 없음"과 같을 때에는 mvc_ref_pic_list_reordering_flag_I1이 1과 같게 되고, mvc_reordering_of_pic_nums_idc는 H.264/MPEG-4 AVC 사양에서 특정된 것처럼 만들어진 재순서화된 목록에서의 RefPicList1[num_ref_idx_I1_active_minus1+num_ref_idx_I1_active_view]가 "참조 화상 없음"과 같지 않을 때까지 3과 같지 않게 된다.

difference_of_view_id 및 abs_diff_pic_num_minus1 또는 long_term_pic_num과 함께, mvc _ reordering _ of _ pic _ nums _ idc는 어느 참조 화상이 다시 맵핑되는지를 특정한다. mvc_reordering_of_pic_nums_idc의 값들은 H.264/MPEG-4 AVC 사양에서 특정된다. mvc_ref_pic_list_reordering_flag_I0 또는 mvc_ref_pic_list_reordering_flag_I1 직후에 오는 제 1 mvc_reordering_of_pic_nums_idc의 값은 3과 같지 않게 된다.

abs _ diff _ pic _ num _ minus1 plus 1은 목록에서의 현재 인덱스로 이동하는 화상의 화상 번호와 화상 번호 예측 값 사이의 절대차를 특정한다. abs_diff_pic_num_minus1은 0과 MaxPicNum-1의 범위에 있게 된다.

long _ term _ pic _ num은 목록에서 현재 인덱스로 이동되는 화상의 장기 화상 번호를 특정한다. 코딩된 프레임을 디코딩할 때, long_term_pic_num은 "장기 참조를 위해 사용됨"으로 마킹된 보충 참조 필드 쌍들이나 참조 프레임들 중 하나에 할당된 LongTermPicNum과 같게 된다. 코딩된 필드를 디코딩할 때, long_term_pic_num은 "장기 참조를 위해 사용됨"이라고 마킹된 참조 필드들 중 하나에 할당된 LongTermPicNum과 같게 된다.

difference_of_view_id는 목록에서 현재 인덱스로 이동되는 화상의 view_id와 view_id 예측 값 사이의 차이를 특정한다.

참조 화상들의 재순서화를 수행하기 위한 프로세스는 디폴트 목록에 기초하고 다음과 같이 설명될 수 있다.

mvc_ref_pic_list_reordering_flag_I0이 1과 같을 때, 다음 내용이 적용된다.

- refldxL0을 참조 화상 목록인 RefPicList0으로의 인덱스라고 한다. 그것은 처음에는 0으로 설정된다.

- 대응하는 구문 요소들인 mvc_reordering_of_pic_nums_idc는 그 비트스트림에서 발생하는 순서대로 처리된다. 이들 구문 요소 각각에 관해, 다음 내용이 적용된다.

1) mvc_reordering_of_pic_nums_idc가 0과 같거나 1과 같다면, 아래 Ⅰ에 특정된 프로세스가 입력으로서 refldxL0으로 불러 내어지고, 그 출력에는 refldxL0이 할당된다.

2) 그렇지 않을 경우, mvc_reordering_of_pic_nums_idc가 2와 같다면, 아래 Ⅱ에서 특정된 프로세스는 입력으로서 refldxL0으로 불러 내어지되고, 그 출력에는 refldxL0이 할당된다.

3) 그렇지 않을 경우(mvc_reordering_of_pic_nums_idc가 3과 같은)에는, 참조 화상 목록인 RefPicLIst0에 관한 재순서화 프로세스가 종료된다.

mvc_ref_pic_list_reordering_flag_I1이 1과 같을 때, 다음 내용이 적용된다.

4) mvc_reordering_of_pic_nums_idc가 0과 같거나 1과 같다면, 아래 Ⅰ에 특정된 프로세스가 입력으로서 refldxL1로 불러 내어지고, 그 출력에는 refldxL1이 할당된다.

5) 그렇지 않을 경우, mvc_reordering_of_pic_nums_idc가 2와 같다면, 아래 Ⅱ에서 특정된 프로세스는 입력으로서 refldxL1로 불러 내어지고, 그 출력에는 refldxL1이 할당된다.

6) 그렇지 않을 경우(mvc_reordering_of_pic_nums_idc가 3과 같은)에는, 참조 화상 목록인 RefPicLIst1에 관한 재순서화 프로세스가 종료된다.

단기 참조 화상들에 관한 참조 화상 목록들을 재순서화하기 위한 구조가 아래에서 설명된다.

이 프로세스로의 입력은 index refldxLX이다(X는 0 또는 1).

이 프로세스의 출력은 증가된 index refldxLX이다.

viewldLXPred는 변수인 viewldLx에 관한 예측 값이다. 이 부절에서 특정된 프로세스가 슬라이스에 관해 처음으로 불러 내어질 때{즉, ref_pic_list_reordering() 구문에서 처음으로 발생하는 mvc_reordering_of_pic_nums_idc가 0 또는 1과 같은}, viewldL0Pred와 viewldL1Pred는 처음에 CurrViewld와 같게 설정된다. viewldLX의 각 할당 후, viewldLX의 값이 viewldLXPred에 할당된다.

picNumLXPred는 변수인 picNumLXNoWrap에 관한 예측 값이다. 이 부절에 특정된 프로세스는 슬라이스에 관해 처음으로 불러 내어지고{즉, ref_pic_list_reordering() 구문에서 처음으로 발생하는 mvc_reordering_of_pic_nums_idc가 0 또는 1과 같은}, picNumL0Pred와 picNumL1Pred는 처음에 CurrPicNum과 같게 설정된다. picNumLXNoWrap의 각 할당 후, picNumLXNoWrap의 값이 PicNumldLXPred에 할당된다.

picNumLX는 다음과 같이 유도된다.

함수인 PicNumF(RefPicListX[cldx])가 다음과 같이 유도된다.

화상인 RefPicListX[cldx]가 "단기 참조를 위해 사용됨"으로 마킹되면, PicNumF(RefPicListX[cldx])는 화상인 RefPicListX[cldx]의 PicNum이다.

그렇지 않으면{화상인 RefPicListX[cldx]가 "단기 참조를 위해 사용됨"이라고 마킹되지 않는다}, PicNumF(RefPicListX[cldx])는 MaxPicNum과 같다.

함수인 ViewldF(RefPicListX[cldx])는 다음과 같이 유도된다.

- ViewldF(RefPicListX[cldx])는 화상인 RefPicListX[cldx]의 viewld이다.

이러한 의사-코드 절차 내에서, 목록인 RefPicListX의 길이는 최종 목록을 위해 필요로 하는 길이보다 한 요소만큼 길게 시간적으로 만들어진다. 이러한 절차를 실행한 후, 목록의 0부터 num_ref_idx_IX_active_minus1까지의 요소만이 남아 있을 필요가 있다.

장기 참조 화상들에 관한 참조 화상 목록들을 재순서화하기 위한 구조가 아래에 설명된다.

이러한 프로세스로의 입력은 index refldxLX이다(X는 0 또는 1).

이 프로세스의 출력은 증가된 index refldxLX이다.

다음 절차들, 즉 위에서 유도된 것과 같은 viewldLX에 의해 표시된 view에 존재하는 장기 화상 번호인 long_term_pic_num을 지닌 화상을 인덱스 위치인 refldxLX에 놓고, 임의의 다른 나머지 화상들의 위치를 목록에서의 더 나중으로 이동시키며, refldxLX의 값을 증가시키는 것이 행해진다.

함수인 LongTermPicNumF(RefPicListX[cldx])는 다음과 같이 유도된다.

- 화상인 RefPicListX[cldx]가 "장기 참조를 위해 사용됨"이라고 마킹되면, LongTermPicNumF(RefPicListX[cldx])는 화상인 RefPicListX[cldx]의 LongTermPicNum이다.

- 그렇지 않으면(화상인 RefPicListX[cldx]가 "장기 참조를 위해 사용됨"이라고 마킹되지 않는다), LongTermPicNumF(RefPicListX[cldx])는 2*(MaxLongTermFrameldx+1)과 같다.

주목 1 - 2*(MaxLongTermFrameldx+1)의 값은 결코 long_term_pic_num과 같을 수 없다.

함수인 ViewldF(RefPicListX[cldx])는 다음과 같이 유도된다.

- 그렇지 않으면(화상인 RefPicListX[cldx]가 "단기 참조를 위해 사용됨"이라고 마킹되지 않는다), PicNumF(RefPicListX[cldx])는 MaxPicNum과 같다.

MaxPicNum의 값은 결코 PicNumLX와 같을 수 없다.

이러한 의사 코드 절차 내에서, 목록인 RefPicListX의 길이는 최종 목록을 위해 필요로 하는 길이보다 한 요소만큼 길게 시간적으로 만들어진다는 것을 주목하라. 이러한 절차를 실행한 후, 목록의 0부터 num_ref_idx_IX_active_minus1까지의 요소만이 남아 있을 필요가 있다.

본 발명의 제 2 실시예에서, 이러한 대안적인 프레임워크 하에서는 크로스-뷰 화상의 재순서화가 시간적으로 정렬된 화상들에 관해 가장 흔하게 일어난다고 간주하고, 이는 화상 번호 차이가 0이 될 것이라는 점을 의미한다. 따라서, 이 실시예는 위에서 설명한 것보다 더 효율적인 크로스-뷰 화상들을 재순서화하는 이러한 양상에 초점을 맞추고 있다.

이러한 실시예는 변수인 abs _ diff _ pic _ num _ minus1을 abs _ diff _ pic _ num으로 변경하고, 다음과 같이 변수를 정의한다.

abs _ diff _ pic _ num은 목록에서 현재 인덱스로 이동되는 화상의 화상 번호와 화상 번호 예측 값 사이의 절대차를 특정한다.

abs_diff_pic_num의 범위는 다음과 같이 특정된다.

- reordering_of_pic_nums_idc가 0과 같다면, abs_diff_pic_num은 0부터 MaxPicNum/2의 범위에 있게 된다.

- 그렇지 않으면(reordering_of_pic_nums_idc가 1과 같다), abs_diff_pic_num_minus1은 0부터 MaxPicNum/2-1의 범위에 있게 된다.

이렇게 함으로써, abs_diff_pic_num이 크로스-뷰 재순서화에 관해 가장 흔한 경우가 되는 0의 값을 취하는 것을 허용한다.

대안적인 프레임워크 하에서 제 3 실시예가 제안되고, 이는 또한 크로스-뷰 화상들의 재순서화가 시간적으로 정렬된 화상들에 관해 가장 흔하게 일어난다고 간주하기 위해 사용되고, 이는 화상 번호 차가 0이 될 것이라는 것을 의미한다.

이전 방법들에서는, abs _ diff _ pic _ num이 부호가 없는 Exp-Golomb 코드로서 코딩되고 따라서 mvc_reordering_of_pic_nums_idc로서 도 6에 도시된 것처럼, 이러한 차가 양 또는 음을 나타내는지를 표시하기 위한 추가 구문이 보내질 필요가 있다.

이 실시예는 표 2에 도시된 것처럼 이러한 구문 요소가 취할 수 있고 RPPL ref_pic_list-reordering_mvc_extension에 관해 개정된 정의를 개시하는 도 7에 도시된 것처럼, diff_pic_num으로서 화상 번호의 차이에 관한 부호가 있는 Exp-Golomb 코드를 송신할 수 있는 값들을 감소시킨다.

mvc_reordering_of_pic_nums_idc	특정된 재순서화
0	diff_pic_num이 존재하고, 화상 번호 예측 값으로부터 빼는 차에 대응한다
1	long_term_pic_num이 존재하고, 참조 화상에 관한 장기 화상 번호를 특정한다
2	초기 참조 화상 목록의 재순서화에 관한 루프를 종료한다

diff_pic_num의 의미는 다음과 같이 정의될 수 있다.

diff _ pic _ num은 목록에서 현재 인덱스로 이동되는 화상의 화상 번호와 화상 번호 예측 값 사이의 차를 특정한다. diff_pic_num의 범위는 다음과 같이 특정된다.

- MaxPicNum/2 - 1 to MaxPicNum/2

picNumLXNoWrap은 다음과 같이 유도된다.

picNumLXNoWrap = picNumLXPred + diff_pic_num.

도 7은 멀티뷰 코딩 환경에 관한 참조 화상들의 재순서화에 적용될 때의 본 발명의 원리들을 나타내는 블록도(700)를 나타낸다. 이 흐름도의 동작 목적상, 참조 화상들이 이미 DPB(215)에 존재한다고 가정된다. 하지만 참조 화상들은 상이한 뷰들에 관한 것일 수 있다.

단계(705)에서는, 방법이 코딩될 현재 화상이 멀티뷰 화상들(MVC,AVC)이 사용되는 환경 내에 있는지 또는 코딩 환경이 단순히 시간적인지(즉, AVC)를 고려한다.

현재 화상의 코딩에 관해 사용된 참조 화상들이 멀티뷰 코딩과 관련이 없다면, 단계(710)가 참조 화상 목록들을 재순서화하기 위해 AVC와 같은 코딩 표준과 연관되어 알려진 원리들을 적용하도록 동작한다. 하지만 코딩될 화상이 멀티뷰 화상과 관련된다면, 이 경우 화상들 사이의 크로스-뷰 관계가 고려되어야 할 수 있다는 것이 가능하고, 단계(715)가 선택된다.

전술한 바와 같이, 화상들의 재순서화를 실제로 어떻게 수행해야 하는지에 관한 몇 가지 상이한 응용예가 존재한다. 위에서 제시된 일부 실시예들{단계(715)에 관해 적용된 것과 같은}은 코딩된 현재 화상이 참조 화상들과 임의의 크로스-뷰 관계를 가지는지를 고려하기 위한 비교가 이루어지는 환경을 설명한다. 일부 실시예들에서, 화상 목록들의 재순서화는 임의의 뷰와 연관된 참조 화상들을 재순서화하게 된다. 다른 실시예들에서는, 먼저 모든 크로스 뷰에 관해서 참조 화상들을 재순서화하는 것이 행해지고, 그 다음 코딩되는 화상들과 동일한 뷰를 지닌 참조 화상들에 대해 행해진다.

단계(720)는 코딩될 화상이 참조 화상들에 대한 시간적인 관계를 가지는지를 고려한다. 전술한 바와 같이, P 화상들이 하나의 참조 목록을 사용할 때, "B" 화상은 2개의 참조 목록들의 사용을 요구할 수 있다. 따라서, 목록들이 재순서화되는 방식(본 발명의 다양한 실시예들에서 설명된 것과 같은)은 그러한 시간적인 관계들에 의존한다.

단계(725)는 참조 화상 목록들의 실제 재순서화이다. 그러한 동작들을 수행하기 위한 다양한 방식들은, 재차 단계(715,720)의 결과들에 의존하고, 전술한 원리들 및 실시예들과 관련하여 적용되어야 한다.

그러므로, 예컨대 당업자라면 본 명세서에서 나타난 블록도가 본 발명의 원리를 구현하는 예시적인 회로의 개념도를 나타낸다는 것을 알게 된다. 유사하게, 임의의 흐름 차트, 흐름도, 상태 전이도, 의사코드 등이 컴퓨터 판독 가능한 매체에서 사실상 나타나고, 컴퓨터나 프로세서에 의해 그렇게 실행될 수 있는 다양한 프로세스들을 나타낸다는 것을 알게 되며, 이러한 경우 그러한 컴퓨터나 프로세서가 명백히 도시되는지 여부는 문제가 되지 않는다.

도면에 도시된 다양한 요소들의 기능들은 적절한 소프트웨어와 연관된 소프트웨어를 실행할 수 있는 하드웨어뿐만 아니라, 전용 하드웨어의 사용을 통해 제공될 수 있다. 프로세서에 의해 제공될 때, 그 기능들은 단일 전용 프로세서, 단일 공유된 프로세서, 또는 일부가 공유될 수 있는 복수의 개별 프로세서에 의해 제공될 수 있다. 더욱이, "프로세서"나 "제어기"와 같은 용어의 명백한 사용은 소프트웨어를 실행할 수 있는 하드웨어만을 가리키는 것으로 여겨져서는 안 되고, 제한 없이 디지털 신호 처리기(DSP) 하드웨어, 소프트웨어를 저장하기 위한 읽기-전용 메모리(ROM), 랜덤 액세스 메모리(RAM), 및 비휘발성 저장기를 은연중에 포함할 수 있다.

종래의 및/또는 주문형인 다른 하드웨어가 또한 포함될 수 있다. 유사하게, 도면에 도시된 임의의 스위치들은 단지 개념적인 것이다. 그것들의 기능은 프로그램 로직의 동작을 통해, 전용 로직을 통해, 프로그램 제어 및 전용 로직의 상호작용을 통해, 또는 심지어 수동으로 실행될 수 있고, 상황으로부터 더 특별하게 이해되는 바와 같이 특별한 기술은 구현자가 선택 가능하다.

청구항에서, 특정된 기능을 수행하기 위한 수단으로서 표현된 임의의 요소는, 예컨대 a) 그러한 기능을 수행하는 회로 요소들의 결합 또는 b) 따라서 그러한 기능을 수행하기 위한 소프트웨어를 실행하기 위한 적절한 회로와 결합된 펌웨어, 마이크로코드(microcode) 등을 포함하는 임의의 형태의 소프트웨어를 포함하여 그러한 기능을 수행하는 임의의 방식을 포함하는 것으로 의도된다. 그러한 청구항에 의해 한정되는 본 발명의 원리는, 다양한 인용된 수단에 의해 제공된 기능성들이 결합되고 청구항이 주장하는 방식으로 모아진다는 사실에 그 성질이 있다. 그러므로 이들 기능성을 제공할 수 있는 임의의 수단은 본 명세서에 도시된 것과 등가인 것으로 간주된다.

본 명세서에서 본 발명의 원리의 "일 실시예" 또는 "실시예"라는 것은 본 발명의 원리의 적어도 하나의 실시예에 실시예와 함께 설명된 특별한 특성, 구조, 특징 등이 포함된다는 것을 의미하는 것이다. 그러므로, 본 명세서 전반에 걸쳐 다양한 곳에 등장하는 "일 실시예에서" 또는 "실시예에서"라는 어구의 등장은 반드시 모두 동일한 실시예를 가리키는 것은 아니다.

본 발명의 원리의 이들 및 다른 특징과 장점은, 당업자가 본 명세서의 가르침에 기초하여 쉽게 확인할 수 있다. 본 발명의 원리의 가르침은 다양한 형태의 하드웨어, 소프트웨어, 펌웨어, 특별한 목적의 프로세서, 또는 이들의 결합으로 구현될 수 있음이 이해되어야 한다.

가장 바람직하게는, 본 발명의 원리의 가르침은 하드웨어와 소프트웨어의 결합으로서 구현된다. 게다가, 그러한 소프트웨어는 프로그램 저장 유닛 상에 확실하게 구현된 응용 프로그램으로서 구현될 수 있다. 이 응용 프로그램은 임의의 적합한 아키텍처를 포함하는 기계에 업로드되어 그러한 기계에 의해 실행될 수 있다. 바람직하게, 그러한 기계는 하나 이상의 중앙 처리 장치(CPU), 랜덤 액세스 메모리(RAM), 입/출력(I/O) 인터페이스들과 같은 하드웨어를 가지는 컴퓨터 플랫폼에서 구현된다. 이 컴퓨터 플랫폼은 또한 운영 체제와 마이크로인스트럭션 코드를 포함할 수 있다. 본 명세서에서 설명된 다양한 프로세스들과 함수들은 마이크로인스트럭션 코드의 부분이거나 응용 프로그램의 부분, 또는 이들의 결합일 수 있고, 이들은 CPU에 의해 실행될 수 있다. 또한, 추가 데이터 저장 유닛 및 프린팅 유닛과 같은 다양한 다른 주변 유닛이 컴퓨터 플랫폼에 연결될 수 있다.

첨부 도면에 도시된 시스템 구성 성분과 방법의 일부가 바람직하게는 소프트웨어로 구현되기 때문에, 시스템 구성 성분들 또는 프로세스 함수 블록들 사이의 실제 연결은 본 발명의 원리가 프로그래밍되는 방식에 따라 상이할 수 있다는 점이 또한 이해되어야 한다. 본 명세서에서의 가르침으로, 당업자라면 본 발명의 원리의 이들 및 유사한 구현예 또는 구성예를 예측할 수 있다.

비록, 예시적인 실시예가 첨부 도면을 참조하여 본 명세서에서 설명되었지만, 본 발명의 원리는 이들 정밀한 실시예에 제한되지 않고, 다양한 변경예와 수정예가 본 발명의 원리의 범주와 취지로부터 벗어나지 않으면서 당업자에 의해 실행될 수 있음이 이해되어야 한다. 모든 그러한 변경예와 수정예는 첨부된 청구항에서 전개된 본 발명의 원리들의 범주 내에 포함되는 것으로 의도된다.

전술한 바와 같이, 본 발명은 동화상 분야, 특히 비디오 화상을 코딩하기 위해 사용될 때 참조 화상들을 순서화하는 것에 이용 가능하다.

Claims

화상에 관한 코딩 동작을 위해 참조 화상 목록의 순서화를 위한 방법으로서,

코딩될 화상이 뷰(view)와 연관되는지를 결정하는 단계(715)와,

코딩될 상기 화상이 뷰를 고려하기 위해, 적어도 하나의 저장된 참조 화상의 코딩 순서를 참조 화상 목록에 순서화하는 단계(725)를

포함하는, 참조 화상 목록의 순서화를 위한 방법.
제 1항에 있어서,

상기 순서화 단계는 코딩될 상기 화상의 뷰가 상기 적어도 하나의 참조 화상과 연관된 뷰와 동일한 뷰인지를 고려하는, 참조 화상 목록의 순서화를 위한 방법.
제 2항에 있어서,

상기 순서화 단계는 코딩될 상기 화상의 뷰와는 상이한 뷰를 지닌 참조 화상들의 재순서화와는 상이한 시간에 코딩될 상기 화상과 동일한 뷰를 지닌 참조 화상들을 순서화하는, 참조 화상 목록의 순서화를 위한 방법.
제 2항에 있어서,

상기 순서화 단계는 임의의 뷰의 참조 화상들을 순서화하는, 참조 화상 목록의 순서화를 위한 방법.
제 1항 내지 제 4항 중 어느 한 항에 있어서,

상기 순서화 단계는 상기 적어도 하나의 저장된 참조 화상으로부터 상기 적어도 2개의 화상의 코딩 순서를 재순서화하는 것으로, 상기 코딩 순서는 상기 화상을 코딩하기 위해 사용되는, 참조 화상 목록의 순서화를 위한 방법.
제 1항 내지 제 5항 중 어느 한 항에 있어서,

코딩될 상기 화상이 "P" 화상이라면 하나의 참조 화상 목록이 사용되고, 코딩될 상기 화상이 "B" 화상이라면 2개의 참조 화상 목록이 사용되는, 참조 화상 목록의 순서화를 위한 방법.
제 1항 내지 제 5항 중 어느 한 항에 있어서,

코딩될 상기 화상은, 상기 목록에서 특정된 참조 화상들의 순서를 사용하여 코딩되는, 참조 화상 목록의 순서화를 위한 방법.