KR101615967B1 - 멀티뷰 비디오 코딩을 위한 가설의 참조 디코더 - Google Patents

Abstract

MVC(Multiview Video Coding)를 위한 HRD(Hypothetical Reference Decoder)를 정의하기 위한 방법 및 장치는 각각의 가능한 상호 운용성 포인트에 관한 제약을 정의한다. M개의 뷰들의 각각의 조합은 상호 운용성 포인트를 나타낸다. 본 발명의 원리들은 또한 상호 운용 가능한 포인트들의 한 세트에 관한 제약이 정의되는 것을 허용하고, 다른 세트들은 정의된 세트로부터 유도된다. 이 방법은 또한 비트스트림 구문에서 정보로부터 유도될 상호 운용성 포인트들의 규칙들을 허용한다.

Description

멀티뷰 비디오 코딩을 위한 가설의 참조 디코더{HYPOTHETICAL REFERENCE DECODER FOR MULTIVIEW VIDEO CODING}

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

본 출원은 2007년 4월 17일에 출원된 미국 가 출원 일련 번호 60/923,800호의 이익을 청구하며, 이는 그것의 전체 내용이 본 명세서에 참고용으로 병합되어 있다.

기술 분야

본 출원은 압축된 비디오 시스템들에서 멀티뷰 비디오 코딩을 위한 가설의 참조 디코더에 관한 것이다.

가설의 참조 디코더(HRD: Hypothetical Reference Decoder)는 압축된 비디오 시스템들에서 귀중한데, 이는 그것이 표준에 대한 준수를 위하여 인코딩된 비트스트림을 유효하게 하는 역할을 하기 때문이다. H.264/AVC와 같은 코딩 표준에서는, 표준의 MVC(Multiview Video Coding) 특징 내의 다수의 상호 운용성(interoperability) 포인트들이 존재한다. MVC는 디코더가 하나 이상의 뷰를 동시에 디코딩하는 것을 허용하고, 하나의 뷰(view)를 디코딩하는 것은 다른 뷰들로 부터의 정보를 필요로 할 수 있다. H.264/AVC 표준은 HRD를 정의하는 규칙들{요구사항, 제약, 또는 운용 스펙(specificaions)이라고도 한다}을 가진다. HRD 일치(conformance)는 H.264/MPEG-4 AVC 표준의 규범(normative) 부분이다. 임의의 AVC 비트스트림은 그 규칙들에 따라 구축된 HRD에 순응해야 한다. 현재에는, MVC HRD에 관해 정의된 어떠한 규칙도 없다. 이전의 HRD들은 그것들이 AVC에서 MVC의 것들과 같이 비트스트림들을 유효하게 하는 것을 허용하는 충분한 규칙들을 가지고 있지 않다.

많은 경우에, 압축된 비트스트림의 비트-속도(bit-rate) 변화는 인코더와 디코더에서의 버퍼링(buffering) 메커니즘들을 사용하여 매끄럽게 될 필요가 있다. 물리적인 버퍼들의 크기들은 유한하고, 따라서 인코더는 비트-속도 변화를 버퍼 한계 내에 맞추도록 강요한다. 비디오 코딩 표준들은 특정 인코더 또는 디코더 버퍼링 메커니즘들을 명령하지 않지만, 그러한 비디오 코딩 표준들은, 주어진 버퍼 크기의 HRD{또는 VBV(Virtual Buffer Verifier)}가 버퍼 오버플로우(overflow) 또는 언더플로우(underflow)를 겪지 않고 비디오 비트 스트림을 디코딩하도록, 인코더들이 비트-속도 변동을 제어할 것을 요구한다.

HRD는 이상화된 디코더 모델에 기초한다. HRD의 목적은 코딩된 스트림에서 시간에 걸쳐 비트-속도의 변화에 대해 기본적인 버퍼링 제약을 두는 것이다. 이들 제약을 또한 더 높은 층들이 스트림을 다중화하는 것을 가능하게 하고, 비용면에서 효율적인 디코더들이 실시간으로 스트림을 디코딩하는 것을 가능하게 한다. 후속 논의에서, H.264/AVC가 일 예로서 사용된다. 하지만, 본 발명은 다른 비디오 코딩 모델들 또는 표준들로 확장될 수 있다.

본 발명은 MVC를 위한 HRD를 정의하기 위한 몇 가지 방법들을 제안한다.

현재의 MVC의 H.264/MPEG-4 AVC 기반의 구현예에서는, 참조 소프트웨어가 단일 인코더로 각각의 뷰를 인코딩하고, 크로스-뷰(cross-view) 참조를 고려함으로써, 멀티뷰 예측을 달성한다. 각각의 뷰는 그것의 본래의 해상도로 인코더에 의해 개별 비트스트림으로서 코딩되고, 나중에 모든 비트스트림이 결합되어 단일 비트스트림을 형성한다. 디코더에서는 사용자가 그것의 애플리케이션에 기초하여 하나 이상의 뷰를 디코딩할 수 있다. 본 명세서에서는, 어떠한 HRD 규칙도 MVC를 위해 정의되지 않는다.

MVC에서는, 총 N개의 코딩된 뷰가 존재한다고 가정한다. 디코더는 임의의 M(1 ≤M ≤N)개의 뷰를 동시에 디코딩하기 위한 유연성(flexibility)을 가질 수 있다. M개의 뷰들의 각각의 조합은 IOP(interoperability point)를 나타낸다. 이 카테고리에서 최상의 유연성을 허용하기 위해, 본 발명은 MVC HRD가 각각의 IOP에 관한 HRD 제약을 정의하는 것을 제안한다. 이러한 해결책의 문제점은 (2^N-1)개까지의 너무 많은 조합이 존재한다는 것이다. 심지어 M ≤32와 같이 M에 대한 제한이 추가되는 경우에도, 조합들의 총 개수는 여전히 크다. 본 발명은 각각의 상호 운용 가능한 포인트에 관해 규칙들이 특정되는 MVC를 위한 가설의 참조 디코더에 관한 규칙들을 제공하는 방법들을 설명한다.

도 1은 단일 뷰들의 HRD 파라미터들에 의해 유도되는 뷰 조합들의 HRD 파라미터들을 도시하는 도면.

도 2는 멀티뷰 비디오 코딩 인코더를 도시하는 도면.

도 3은 멀티뷰 비디오 코딩 디코더를 도시하는 도면.

도 4는 카테고리(1)의 MVC 인코딩 프로세스를 위한 비디오 유용성 정보를 도시하는 도면.

도 5는 카테고리(1)의 MVC 디코딩 프로세스를 위한 비디오 유용성 정보를 도시하는 도면.

도 6은 카테고리(1)의 멀티뷰 내포(nesting) SEI 인코딩 프로세스를 도시하는 도면.

도 7은 카테고리(1)의 멀티뷰 내포 SEI 디코딩 프로세스를 도시하는 도면.

도 8은 카테고리(2)의 MVC 인코딩 프로세스를 위한 비디오 유용성 정보를 도시하는 도면.

도 9는 카테고리(2)의 MVC 디코딩 프로세스를 위한 비디오 유용성 정보를 도시하는 도면.

도 10은 카테고리(2,3)의 멀티뷰 내포 SEI 인코딩 프로세스를 도시하는 도면.

도 11은 카테고리(2,3)의 멀티뷰 내포 SEI 디코딩 프로세스를 도시하는 도면.

도 12는 카테고리(3)의 MVC 인코딩 프로세스를 위한 비디오 유용성 정보를 도시하는 도면.

도 13은 카테고리(3)의 MVC 디코딩 프로세스를 위한 비디오 유용성 정보를 도시하는 도면.

현재의 H.264/MPEG-4 AVC 참조 구현예에서는, HRD 관련 파라미터들이 SPS(sequence parameter set)와 SEI 메시지들에 놓인다.

SPS는 표 1에 예시된 것과 같이, 구문 구조 VUI 파라미터들을 포함한다.

구문 요소들(num_units_in_tick, time_scale, fixed_frame_rate_flag와 low_delay_hrd_flag)과 구문 구조 HRD 파라미터들은 표 2에 도시된 것과 같은 구문 구조 VUI 파라미터들에 놓인다.

구문 요소인 HRD_파라미터들은 버퍼 크기와 비트 속도 등을 특정하기 위한 구문을 포함한다.

버퍼 기간 SEI와 화상 타이밍 SEI는 각 화상의 타이밍을 유도하기 위해 화상과 파라미터들을 디코딩하기 전에 초기 코딩된 화상 버퍼 제거 지연을 특정하였다.

현재의 AVC 구현예와, SPS에 놓인 HRD 관련 파라미터들에 기초하고, 버퍼링 기간 SEI와 화상 시간 SEI에 놓인 파라미터들과 결합하여, HRD 제약의 한 세트가 H.264/MPEG-4 AVC 비트스트림에 관해 정의된다.

하지만, 현재의 AVC 구현예는 HRD 파라미터들의 한 세트만을 지원하고, 이는 MVC 비트스트림에 포함된 다수의 IOP에 맞지 않는다.

MVC의 현재의 H.264/MPEG-4 AVC 기반의 구현예에서는, 단일 인코더로 각 뷰를 인코딩하고, 크로스-뷰(cross-view) 참조들을 고려함으로써, 참조 소프트웨어가 멀티-뷰 예측을 달성한다. 각 뷰는 그것의 본래의 해상도에서 인코더에 의해 별도의 비트스트림으로 코딩되고, 나중에 모든 비트스트림이 단일 비트스트림을 형성하기 위해 조합된다. 디코더에서, 사용자는 그것의 애플리케이션에 기초하여 하나 이상의 뷰를 디코딩할 수 있다. MVC 인코더와 디코더 도면은 각각 도 2와 도 3에 도시되어 있다.

현재의 스펙에서는 MVC에 관해 어떠한 HRD 규칙들도 정의되지 않는다.

많은 설명된 실시예들에서 MVC의 H.264/MPEG-4 AVC 기반의 구현예의 프레임워크를 사용한다. 유사한 개념이 다른 비디오 코딩 표준들에 적용될 수 있다. 예컨대, 하나 이상의 운용 포인트들(상호 운용성 포인트와 같은)에 관한 특별한 파라미터들을 특정하는 특징은 H.264/MPEG-4 AVC 표준 외의 표준들에 적용될 수 있다.

구현예들의 3가지 별개의 부류들이 설명된다.

A. MVC에서 각각의 상호 운용 가능한 포인트에 관한 HRD 규칙들을 특정한다.

MVC에서는, 총 N개의 코딩된 뷰들이 존재한다고 가정한다. 디코더는 임의의 M(1 ≤M ≤N)개의 뷰를 동시에 디코딩하는 유연성을 가질 수 있다. M개의 뷰의 각각의 조합은 IOP를 나타낸다. 이 카테고리에서 최상의 유연성을 허용하기 위해, 본 발명은 MVC HRD가 각각의 IOP에 관한 HRD 제약을 정의하는 것을 제안한다. 이 해결책의 문제점은 (2^N-1)개까지의 너무 많은 조합이 존재한다는 것이다. 심지어 M ≤32인 M에 대한 제한이 추가되는 경우에도, 조합들의 총 개수는 여전히 크다.

이 해결책의 실시예가 아래에 제시된다.

뷰들의 모든 조합이 AVC HRD 규칙들에 대한 후속하는 수정예에서 조합된다. 표 3은 AVC 표준으로부터 취해지고, AVC-HRD에 관련된다. AVC 표준 표들에 대한 추가 사항은 이탤릭체를 사용하여 도시되어 있다. 새로운 SEI 메시지인 멀티뷰 내포 SEI가 표 4에 소개된다. VUI 인코딩 및 디코딩 프로세스들의 흐름도가 각각 도 4와 도 5에 도시된다. 그리고 멀티뷰 내포 SEI 인코딩 프로세스와 디코딩 프로세스의 흐름도가 각각 도 6과 도 7에 도시된다.

1. VUI 파라미터들: 볼 수 있듯이 표 3은 AVC 표준에서 VUI 파라미터의 구문이 변수인 "profile_idc"를 테스트하는 "if-then" 문장을 도입함으로써 수정되었음을 보여준다. "profile_idc"가 "MVC"와 같다면, 하나 이상의 포인트(즉, IOP들)를 테스트하기 위해 한 번 이상 루프가 수행된다. "profile_idc"가 "MVC"와 같지 않다면, "AVC"가 관련 표준인 것으로 추정되고, "else"가 AVC 순응(기존의 AVC-HRD 규칙들을 사용하여)에 관한 하나의 포인트를 테스트하기 위해 실행된다. 라인(30-60)은 "profile_idc"가 MVC라면 실행되고, 그렇지 않을 경우 라인(63-88)이 실행된다. 변수인 "num_view_combinations_minus1"{라인(30)}은 루프에서 IOP들의 개수를 제공한다. 메인(main) 루프 내에서, 각각의 IOP에 관한 서브-루프{라인(33-34)}가 IOP와 연관된 view_ids를 제공한다. 각각의 서브-루프에 관해, "num_view_minus1[i]"{라인(32)}이 i번째 IOP와 관련된 뷰의 개수를 제공하고, "view_id[i][j]"{라인(34)}는 i번째 IOP의 j번째 뷰의 view_id를 제공한다. 라인(35-59)은 i번째 IOP에 관한 구문들을 제공한다. MVC 비트스트림에 관해 (2^N-1)개까지의 IOP들이 존재할 수 있다. 이는 AVC 비트스트림에 관한 단일 체킹(checking) 포인트와 비교된다.

2. 새로운 SEI 메시지인 멀티뷰 내포 SEI가 표 4에서 정의된다. 멀티뷰 내포 SEI 메시지는 액세스 유닛에 관계된다. 멀티뷰 내포 SEI 메시지는 하나의 유일한 SEI 메시지를 포함하고, 이는 내포된 SEI 메시지로서 부른다. 내포된 SEI 메시지가 적용되는 범주는 라인(2-10)으로부터의 구문들에 의해 표시된다.

"num_view_combinations_minus1", "num_views_minus1[i]" 및 "view_id[i][j]"는 VUI 파라미터들에서의 것과 동일한 의미론(semantics)을 공유한다.

3. 버퍼링 기간 SEI 메시지와 화상 타이밍 SEI 메시지(AVC의 부분인)는 멀티뷰 내포 SEI 메시지에 삽입된 SEI 메시지 페이로드(payload)로서 구현될 수 있다. 버퍼링 기간 SEI와 화상 타이밍 SEI의 구문은 AVC에서와 동일하게 남아 있다. AVC 호환 뷰에 관한 버퍼링 기간 SEI 메시지와 화상 타이밍 SEI 메시지는 멀티뷰 내포 SEI에서 내포되지 않게 된다. 이는 AVC 호환성을 허용한다.

num_view_combinations_minus1 plus 1은 이러한 hrd_parameters()를 포함하는 SPS에서 동일한 seq_parameter_set_id를 가리키는 비트스트림에 의해 지원된 뷰 조합들의 개수를 표시한다.

num_views_minus[i]는 i번째 IOP와 연관된 뷰들의 개수를 나타낸다.

view_id[i][j]는 i번째 IOP의 j번째 뷰의 view_id를 나타낸다.

timing_info_present_flag[i]는 i번째 IOP의 timing_info_present_flag를 특정한다.

num_units_in_tick[i]는 i번째 IOP의 num_units_in_tick을 특정한다.

time_scale[i]은 i번째 IOP의 time_scale 값을 특정한다.

fixed_frame_rate_flag[i]는 i번째 IOP의 fixed_frame_rate_flag를 특정한다.

nal_hrd_parameters_present_flag[i]는 i번째 IOP의 nal_hrd_parameters_present_flag 값을 특정한다.

vcl_hrd_parameters_present_flag[i]는 i번째 IOP의vcl_hrd_parameters_present_flag 값을 특정한다.

low_delay_hrd_flag[i]는 i번째 IOP의 low_delay_hrd_flag 값을 특정한다.

pic_struct_present_flag[i]는 i번째 IOP의 pic_struct_present_flag 값을 특정한다.

timing_info_present_flag, num_units_in_tick, time_scale, nal_hrd_parameters_present_flag, vcl_hrd_parameters_present_flag, low_delay_hrd_flag 및 pic_struct_present_flag는 AVC에서와 동일한 의미론을 가진다.

all_view_combinations_in_au_flag가 1과 같다는 것은, 내포 SEI 메시지가 액세스 유닛의 모든 뷰 조합들에 적용됨을 나타낸다.

all_view_combinations_in_au_flag가 0과 같다는 것은, 내포 SEI 메시지의 적용 가능한 범주가 구문 요소들(num_views_combinations_minus1, num_views_minus1[i], view_id[i][j])에 의해 시그널링됨을 나타낸다.

num_view_combinations_minus1 plus 1은 비트스트림에 의해 지원된 뷰 조합들의 개수를 나타낸다.

num_view_minus1[i]는 i번째 IOP과 연관된 뷰들의 개수를 나타낸다.

view_id[i][j]는 i번째 IOP의 j번째 뷰의 view_id를 나타낸다.

B. IOP들의 세트에 관해서만 HRD 규칙들을 특정한다.

이 카테고리에서는, IOP들의 세트에 관해서 MVC HRD를 정의하는 것과 이 세트로부터 IOP들의 다른 세트들을 유도하는 것이 제안된다. 일 실시예에서는, MVC HRD이 가능한 단일 뷰 각각을 디코딩하기 위한 HRD 제약들만을 정의하고, 2개 이상의 뷰를 디코딩하기 위한 HRD 파라미터들이 관련된 단일 뷰 파라미터들로부터 유도된다. 이러한 접근은 제 1 접근보다 적은 수의 파라미터를 보내는 것을 허용하지만, 유도를 위해 더 많은 복잡성을 추가한다.

이러한 해결책의 일 실시예가 아래에 제시된다.

HRD는 각각의 뷰에 관해 정의된다. HRD 파라미터들을 보내는 것의 세트들의 최대 개수는 M이고, 여기서 M=1...N이다. 따라서, N개의 뷰가 존재한다면, 이 실시예는 HRD 파라미터들의 N개의 세트들을 보내게 된다. VUI 인코딩 프로세스와 디코딩 프로세스의 흐름도가 각각 도 8과 도 9에 도시되어 있다. 그리고, 멀티뷰 내포 SEI 인코딩 프로세스와 디코딩 프로세스의 흐름도가 각각 도 10과 도 11에 도시되어 있다.

1. VUI 파라미터들은 볼 수 있는 것처럼, AVC 표준에서의 VUI 파라미터의 구문이 변수인 "profile_idc"를 테스트하는 "if-then" 문장을 도입함으로써 수정되었음을 보여준다. "profile_idc"가 "MVC"와 같다면, 하나 이상의 포인트를 테스트하기 위해 한번 이상 루프가 수행된다. "profile_idc"가 "MVC"와 같지 않다면, "AVC"가 관련 표준이라고 추정되고, "else"가 AVC 순응(기존의 AVC-HRD 규칙들을 사용하여)에 관한 하나의 포인트를 테스트하기 위해 실행된다. "profile_idc"가 MVC라면 라인(30-58)이 실행되고, 그렇지 않을 경우 라인(61-85)이 실행된다. 변수인 "num_views_minus1"{라인(30)}은 루프에서 뷰들의 개수를 제공한다. "view_id[i]"{라인(32)}는 i번째 뷰의 view_id를 제공한다. 라인(33-58)은 i번째 뷰에 관한 구문들을 제공한다. MVC 비트스트림에서는 M개(M=1...N)까지의 뷰가 있을 수 있다. 이는 AVC 비트스트림에 관한 단일 체킹 포인트와 비교된다.

2. 새로운 SEI 메시지인 멀티뷰 내포 SEI가 표 6에서 정의된다. 멀티뷰 내포 SEI 메시지는 액세스 유닛에 관련된다. 멀티뷰 내포 SEI 메시지는 하나의 그리고 유일한 SEI 메시지를 포함하는데, 이는 내포 SEI 메시지라고 부른다. 내포 SEI 메시지가 적용되는 범주는 라인(2-7)으로부터의 구문에 의해 표시된다. "num_views_minus1"과 "view_id[i]"는 VUI 파라미터들에서의 것과 동일한 의미론을 공유한다.

3. 버퍼링 기간 SEI 메시지와 화상 타이밍 SEI 메시지는 멀티뷰 내포 SEI 메시지에서 삽입된 SEI 메시지 페이로드일 수 있다. 버퍼링 기간 SEI와 화상 타이밍 SEI의 구문은 AVC에서와 동일하게 남아 있는다. AVC 호환 뷰에 관한 버퍼링 기간 SEI 메시지와 화상 타이밍 SEI 메시지는 멀티뷰 내포 SEI에서 내포되지 않게 된다.

각각의 IOP의 HRD 파라미터들(뷰 조합)은 IOP와 연관된 뷰들의 HRD 파라미터들에 의해 유도된다. 일 예가 도 1에 주어진다.

num_views_minus1은 비트스트림에서의 뷰들의 총 개수를 나타낸다.

view_id[i]는 i번째 뷰의 view_id를 나타낸다.

timing_info_present_flag[i]는 i번째 뷰의 timing_info_present_flag 값을 특정한다.

num_units_in_tick[i]는 i번째 뷰의 num_units_in_tick 값을 특정한다.

time_scale[i]은 i번째 IOP의 time_scale 값을 특정한다.

fixed_frame_rate_flag[i]는 i번째 뷰의 fixed_frame_rate_flag 값을 특정한다.

nal_hrd_parameters_present_flag[i]는 i번째 뷰의nal_hrd_parameters_present_flag 값을 특정한다.

vcl_hrd_parameters_present_flag[i]는 i번째 뷰의vcl_hrd_parameters_present_flag 값을 특정한다.

low_delay_hrd_flag[i]는 i번째 뷰의 low_delay_hrd_flag 값을 특정한다.

pic_struct_present_flag[i]는 i번째 뷰의 pic_struct_present_flag 값을 특정한다.

timing_info_present_flag, num_units_in_tick, time_scale, nal_hrd_parameters_present_flag, vcl_hrd_parameters_present_flag, low_delay_hrd_flag 및 pic_struct_present_flag는 AVC에서와 동일한 의미론을 가진다.

all_views_in_au_flag가 1과 같다는 것은 액세스 유닛의 모든 뷰에 내포 SEI 메시지가 적용된다는 것을 나타낸다. all_views_in_au_flag가 0과 같다는 것은 내포 SEI 메시지의 적용 가능한 범주가 구문 요소들(num_views_minus1과 view_id[i])에 의해 시그널링됨을 나타낸다.

num_views_minus1 plus 1은 비트스트림에 의해 지원된 뷰들의 개수를 나타낸다.

view_id[i]는 i번째 뷰의 view_id를 나타낸다.

C. 최악의 경우를 위한 HRD 규칙들을 특정한다

이 카테고리에서는, MVC HRD가 오직 M(M=1,...,N)개의 뷰를 디코딩하는 최악의 경우에 관한 HRD 제약을 정의하는 것이 제안된다. 최악의 경우는, 예컨대 가장 큰 버퍼 크기, 가장 긴 지연, 가장 높은 비트 속도, 임의의 M개의 뷰를 송신하는 가장 큰 비트 소비 등을 요구하는 경우로서 정의될 수 있다. 따라서, 각각의 M개의 뷰를 디코딩하기 위해 HRD 파라미터들의 1개의 세트만을 정의할 수 있다. 즉, 최악의 경우의 단일 뷰에 관한 HRD 파라미터들의 한 세트, 최악의 경우의 2-뷰 조합 등에 관한 HRD 파라미터들의 세트로부터 최악의 경우의 N-1-뷰 조합에 관한 HRD 파라미터들의 세트, 및 (최악의 경우) N-뷰 조합에 관한 HRD 파라미터들의 세트를 정의한다. 전부, 오직 HRD 파라미터들의 N개의 세트를 정의하고, 이들은 1,2,...N개의 뷰들에 관한 HRD 일치를 테스트하기 위해 사용된다. 이러한 접근의 단점은 하나의 특별한 경우가 필요로 할 수 있는 것보다 높은 제약들을 보내는 것을 요구한다는 점이다. 하지만 모든 HRD 파라미터들을 보내기 위해 비트들을 절약할 수 있고, 임의의 파라미터들을 유도하지 않는다.

이 해결책의 일 실시예가 아래에 제시된다.

HRD 파라미터들을 보내는 세트들의 최대 개수는 M(M=1..N)이다. VUI 인코딩 프로세스와 디코딩 프로세스의 흐름도가 각각 도 12와 도 13에 도시되어 있다.

1. VUI 파라미터들: 볼 수 있는 것처럼, 표 7은 AVC 표준에서 VUI 파라미터의 구문이 변수인 "profile_idc"를 테스트하는 "if-then" 문장을 도입함으로써 수정되었음을 보여준다. "profile_idc"가 "MVC"와 같다면, 하나 이상의 포인트를 테스트하기 위해 한 번 이상 루프가 수행된다. "profile_idc"가 "MVC"와 같지 않다면, "AVC"가 관련 표준인 것으로 추정되고, AVC 순응(기존의 AVC-HRD 규칙들을 사용하여)에 관한 하나의 포인트를 테스트하기 위해 "else"가 실행된다. "profile_idc"가 MVC라면, 라인(30-57)이 실행되고, 그렇지 않을 경우 라인(60-84)이 실행된다. 변수인 "num_views_minus1"{라인(30)}은 비트스트림에서의 뷰들의 개수를 제공한다. 라인(32-56)은 (num_views_minus1+1) 뷰들의 임의의 i 뷰들을 디코딩하는 가장 높은 HRD 제약과 연관된 HRD 관련 파라미터들에 관한 구문들을 제공한다.

표 7은 표 5와 다름을 주목하라. 예컨대, "view_id[i]"를 재인용하는, 표 5의 라인(32)을 보라.

2. 버퍼링 기간 SEI 메시지와 화상 타이밍 SEI 메시지는 멀티뷰 내포 SEI 메시지에서 삽입된 SEI 메시지 페이로드일 수 있다. 멀티뷰 내포 SEI 메시지의 구문은 표 6에서 정의된 것을 공유할 수 있다. 내포 버퍼링 기간과 화상 타이밍 SEI 메시지는 비트스트림에서 보내는 뷰들의 총 개수의 임의의 (num_views_minus1+1) 뷰들을 디코딩하는 가장 높은 HRD 제약들과 연관된다. 버퍼링 기간 SEI와 화상 타이밍 SEI의 구문은 AVC에서와 동일하게 남아 있는다. AVC 호환 뷰에 관한 버퍼링 기간 SEI 메시지와 화상 타이밍 SEI 메시지는 멀티뷰 내포 SEI에서 내포되지 않게 된다.

num_views_minus1은 비트스트림에서의 뷰들의 총 개수를 나타낸다.

timing_info_present_flag[i]는 i개의 뷰를 디코딩하기 위한 timing_info_present_flag 값을 특정한다.

num_units_in_tick[i]는 i개의 뷰를 디코딩하기 위한 num_units_in_tick 값을 특정한다.

time_scale[i]은 i개의 뷰를 디코딩하기 위한 time_scale 값을 특정한다.

fixed_frame_rate_flag[i]는 i개의 뷰를 디코딩하기 위한 fixed_frame_rate_flag 값을 특정한다.

nal_hrd_parameters_present_flag[i]는 i개의 뷰를 디코딩하기 위한 nal_hrd_parameters_present_flag 값을 특정한다.

vcl_hrd_parameters_present_flag[i]는 i개의 뷰를 디코딩하기 위한 vcl_hrd_parameters_present_flag 값을 특정한다.

low_delay_hrd_flag[i]는 i개의 뷰를 디코딩하기 위한 low_delay_hrd_flag 값을 특정한다.

pic_struct_present_flag[i]는 i개의 뷰를 디코딩하기 위한 pic_struct_present_flag 값을 특정한다.

파라미터들(timing_info_present_flag, num_units_in_tick, time_scale, nal_hrd_parameters_present_flag, vcl_hrd_parameters_present_flag, low_delay_hrd_flag 및 pic_struct_present_flag)은 AVC에서와 동일한 의미론을 가진다.

도 4 내지 도 13은 식별되는 특별한 구문을 쓰거나 읽기 위한 다양한 흐름도를 보여준다.

예컨대, MVC에 관한 HRD의 설명을 쓰고/쓰거나 읽기 위한 규칙들을 제공하는 여러 구현예들이 본 명세서에서 설명된다. 이는 HRD가 MVC에서 정의되고 사용되는 것을 허용한다.

하지만, 설명된 구현예들의 특징과 양상은 또한 다른 구현예들을 위해 적응될 수 있다. 예컨대, 위에서 나타난 바와 같이, 다른 표준들을 위해 위 특징들을 사용하는 HRD가 제공될 수 있다. 게다가, 위에서 설명된 실시예들의 변형예들을 사용하는 HRD가 MVC를 위해 제공될 수 있다. 그러한 변형예들에는, 예컨대 다른 높은 레벨의 구문을 사용하고, 높은 레벨이 아닌 구문을 사용하며, 다른 IOP들에 관한 HRD 파라미터들을 제공하는 구현예들이 포함될 수 있다. 따라서, 비록 위에서 설명된 구현예들이 본 명세서에서 설명된 3가지 주요 구현예들 중 하나를 구현하는 H.264에 관한 높은 레벨의 구문의 상황에서 설명될 수 있지만, 그러한 설명은 그 특징들과 개념들을 그러한 구현예나 상황에 국한시키는 것으로 해석되어서는 안 된다.

본 명세서에서 설명된 구현예들은, 예컨대 방법 또는 프로세스, 장치 또는 소프트웨어 프로그램으로 구현될 수 있다. 심지어 단일 형태의 구현예(예컨대, 오직 방법으로서 논의된)의 상황에서 논의되더라도, 논의된 구현예 또는 특징들은 또한 다른 형태(예컨대, 장치 또는 프로그램)로 구현될 수 있다. 장치는, 예컨대 적합한 하드웨어, 소프트웨어, 및 펌웨어로 구현될 수 있다. 그 방법들은, 예컨대 컴퓨터 또는 다른 처리 디바이스와 같은 장치에서 구현될 수 있다. 게다가, 그 방법들은 처리 디바이스나 다른 장치에 의해 수행되는 명령어들로 구현될 수 있고, 그러한 명령어들은, 예컨대 CD와 같은 컴퓨터 판독 가능한 매체 또는 다른 컴퓨터 판독 가능한 저장 디바이스 또는 집적 회로에 저장될 수 있다.

당업자에게 분명하게 되는 것처럼, 구현예들은 또한 예컨대 저장되거나 송신될 수 있는 정보를 운반하도록 포맷팅된 신호를 만들어낼 수 있다. 그러한 정보는, 예컨대 설명된 구현예들 중 하나에 의해 만들어진 데이터나, 방법을 수행하기 위한 명령어들을 포함할 수 있다. 예컨대, 설명된 실시예의 구문을 쓰거나 읽기 위한 규칙들을 데이터로서 운반하거나, 설명된 실시예에 의해 쓰여진 실제 구문을 데이터로서 운반하도록 신호가 포맷팅될 수 있다.

게다가, 많은 구현예들은 인코더나 디코더 또는 인코더와 디코더로 구현될 수 있다.

또한, 본 발명에 의해 다른 구현예들이 고려된다. 예컨대, 개시된 구현예들의 다양한 특징들을 조합, 삭제, 수정, 또는 보충함으로써 또 다른 구현예들이 생성될 수 있다.

앞의 설명은 다양한 구현예들의 일부를 제공한다. 총망라하도록 의도하지는 않고, 다만 많은 가능한 구현예 중 적은 수의 구현예의 짧은 설명을 제공할 뿐이다.

전술한 바와 같이, 본 발명은 압축된 비디오 시스템들에서 멀티뷰 비디오 코딩을 위한 가설의 참조 디코더 분야에 이용 가능하다.

Claims (22)

1. 삭제
2. 삭제
3. 삭제
4. 삭제
5. 삭제
6. 삭제
7. 삭제
8. 삭제
9. 삭제
10. 삭제
11. 비트스트림으로부터 멀티뷰 비디오를 디코딩하는 방법으로서,

    상기 비트스트림으로부터 멀티뷰 비디오 코딩에서의 상호운용가능한 포인트와 연관된 복수의 뷰들의 뷰 정보를 읽는 단계 - 상기 뷰 정보는 상기 상호운용가능한 포인트와 연관된 뷰들의 수 및 상기 복수의 뷰들 각각의 뷰 식별자를 나타내고, 상기 상호운용가능한 포인트는 상기 복수의 뷰들에 대응함 -; 및

    상기 비트스트림으로부터 각각의 상호운용가능한 포인트에 대한 가설 참조 디코더(hypothetical reference decoder; HRD) 파라미터들을 읽는 단계 - 상기 HRD 파라미터들은 적어도 상기 상호운용가능한 포인트에 대한 버퍼 크기, 비트 속도, 초기 코딩된 화상 버퍼 제거 지연, 및 각 화상의 타이밍을 나타내는 파라미터들을 포함함 -

    를 포함하는, 멀티뷰 비디오 디코딩 방법.
12. 삭제
13. 삭제
14. 삭제
15. 삭제
16. 삭제
17. 삭제
18. 삭제
19. 삭제
20. 삭제
21. 삭제
22. 삭제

Images