JP2010507275A

JP2010507275A - 多視点ビデオ符号化のための参照ピクチャ・リスト管理方法

Info

Publication number: JP2010507275A
Application number: JP2009532434A
Authority: JP
Inventors: ビブハスパンデイツト，パービン; スー，イエピン; イン，ペン
Original assignee: Thomson Licensing SAS
Current assignee: Thomson Licensing SAS
Priority date: 2006-10-13
Filing date: 2007-10-12
Publication date: 2010-03-04
Anticipated expiration: 2027-10-12
Also published as: US20090262804A1; WO2008048499A3; WO2008048499A2; US20160191950A1; EP2090110A2; BRPI0716957A2; JP5184539B2; JP6164742B2; KR101368493B1; JP2015029316A; CN102761744B; CN102761744A; JP5184713B2; US8948256B2; KR20090077907A; US20190182506A1; JP5619923B2; JP2017126999A; JP2013102504A; JP2013038808A

Abstract

ピクチャ参照リスト順序づけプロセスが、動画像をコーディングするための多視点コーダ用に定義され、ピクチャ・リストは、コーディングされるピクチャがビューに関連するかどうか（７１５）に関係して規定される、ピクチャをコーディングするために使用される、参照ピクチャのコーディング順序を有する。したがって、ピクチャ・リストの順序づけは、参照ピクチャがコーディングされるピクチャに対して有する時間的関係（７２０）および参照ピクチャと関連するビュー（７１５）に応じて、ピクチャ参照リスト内の参照ピクチャのコーディング順序を変更する（７２５）。

Description

（関連出願の相互参照）
本出願は、参照によりその全体が本明細書に組み込まれる、２００６年１０月１３日に出願された、米国仮出願第６０／８５１，８６３号、および同様に参照によりその全体が本明細書に組み込まれる、２００６年１０月１３日に出願された、米国仮出願第６０／８５１，５２１号の利益を主張する。

本発明は、動画像の分野に関し、特に、ビデオ・ピクチャをコーディングするために使用される場合の、参照ピクチャの順序づけの問題に関する。

多くのフレーム間符号化システムは、参照ピクチャを使用し、そのような参照ピクチャの使用は、符号化されたビット・ストリームのサイズを縮小するのに役立つ。このタイプの結果は、符号化効率が、フレーム内符号化技法を単独で単に使用するよりも良好になることである。したがって、多くの符号化規格は、一連の動画像からのビット・ストリームを符号化するために、フレーム内およびフレーム間符号化技法の両方を含む。当技術分野で知られているように、異なるタイプの参照ピクチャが、符号化規格のために使用される。例えば、ピクチャそれ自体の内部の要素（イントラ・フレーム）だけを使用することによって符号化されるＩピクチャ、ピクチャそれ自体の内部からの要素および／または２つの先行する参照ピクチャからの要素（インター・フレーム）を使用することによって符号化されるＢピクチャ、ならびにピクチャそれ自体の内部からの要素および／または１つの先行する参照ピクチャからの要素（インター・フレーム）を使用することによって符号化されるＰピクチャなどがある。

したがって、ＢピクチャまたはＰピクチャが、符号化されて生成される場合や復号される場合、そのようなピクチャが、適切に符号化され、または復号動作中に構成され得るように、そのようなピクチャは、他の参照フレームに依存する。符号化／復号システムは、他のピクチャが参照ピクチャを考慮して符号化または復号されている間、そのような参照ピクチャを保存できるように、何らかのタイプのメモリ・ロケーションを提供すべきである。これらのタイプのピクチャは、互いの間に時間的関係を有する。

この状況は、異なるビデオ・ピクチャの間の複数のビューが考慮されるビデオ規格について検討する場合、より複雑になる。例えば、図１は、多視点ビデオ符号化システム（ＭｕｌｔｉｖｉｅｗＶｉｄｅｏＣｏｄｉｎｇｓｙｓｔｅｍ）において使用される、参照ピクチャ構造の例示的な一実施形態を表している。具体的には、提示された構造は、Ａ．Ｖｅｔｒｏ、Ｙ．Ｓｕ、Ｈ．Ｋｉｍａｔａ、Ａ．Ｓｍｏｌｉｃ、「ＪｏｉｎｔＭｕｌｔｉｖｉｅｗＶｉｄｅｏＭｏｄｅｌ（ＪＭＶＭ）１．０」、ＪＶＴ−Ｔ２０８．ｄｏｃ、Ｋｌａｇｅｎｆｕｒｔ、Ａｕｓｔｒｉａ、２００６年７月において提案された多視点符号化（ＭＶＣ）スキームによる、８つの異なるビュー（Ｓ０〜Ｓ７）の多時点（Ｔ０〜Ｔ１００）にわたる使用に関する。この多視点符号化規格は、ＡＶＣ（ＡｄｖａｎｃｅｄＶｉｄｅｏＣｏｄｉｎｇ）規格（Ｇ．Ｓｕｌｌｉｖａｎ、Ｔ．Ｗｉｅｇａｎｄ、Ａ．Ｌｕｔｈｒａ、「ＤｒａｆｔｏｆＶｅｒｓｉｏｎ４ｏｆＨ．２６４／ＡＶＣ（ＩＴＵ−ＴＲｅｃｏｍｍｅｎｄａｔｉｏｎＨ．２６４ａｎｄＩＳＯ／ＩＥＣ１４４９６−１０（ＭＰＥＧ−４ｐａｒｔ１０）ＡｄｖａｎｃｅｄＶｉｄｅｏＣｏｄｉｎｇ）」、ＰａｌｍａｄｅＭａｌｌｏｒｃａ、ＥＳ１８−２２、２００４年１０月）における符号化に基づいている。両規格の大きな相違は、ＡＶＣは多視点ピクチャのコーディングに対処しないが、ＭＶＣは対処することである。

図１を参照すると、例えば、Ｔ１におけるビュー（ｖｉｅｗ）Ｓ１に関連するピクチャをコーディングする場合、コーディングされるピクチャは、同じビュー（Ｔ０におけるＳ１およびＴ２におけるＳ１）からのピクチャ（参照ピクチャ）に関係し、またコーディングされるピクチャは、異なるビュー（Ｔ１におけるＳ０およびＴ１におけるＳ２）からのピクチャに関係することが分かる。したがって、Ｓ１、Ｔ１に関連するピクチャをコーディングする場合、参照ピクチャ（Ｔ０におけるＳ１、Ｔ２におけるＳ１、Ｔ１におけるＳ０、およびＴ１におけるＳ２）を、バッファ、レジスタ、およびＲＡＭなどの、メモリ・デバイスに保持することは理に適っている。

ＡＶＣビデオ規格で使用されるような、コーダと、参照ピクチャを保存するメモリ・デバイスの動作の一般化された実施が、図２に示されている。具体的には、ブロック図２００において、コーダ２０５と、コーディング・バッファ２１０と、復号済ピクチャ・バッファ（ＤＰＢ：ｄｅｃｏｄｅｄｐｉｃｔｕｒｅｂｕｆｆｅｒ）２１５とが、開示されている。コーディング動作（符号化または復号）の最中、コーダによって現在コーディングされているピクチャは、コーディング・バッファ２１０内に存在するが、先にコーディングされた参照ピクチャは、復号済ピクチャ・バッファ２１５内に保存されている。

しかし、２つ以上の参照ピクチャの使用を必要とするピクチャをコーディングしなければならない場合に、そのような参照ピクチャがＤＰＢ２１５内に保存されるときに、問題が生じる。すなわち、ＤＰＢ２１５は、コーディング動作中にそのような参照ピクチャをコーダ２０５から利用可能にする何らかのタイプの機構を、そのような参照ピクチャに提供しなければならない。第２のピクチャをコーディングする場合に、異なる参照ピクチャがＤＰＢ２１５を介してコーダ２０５によってアクセスされなければならないことがあることも理解されたい。（ＡＶＣなど）時間的な場合には、この問題は十分に複雑であるが、ＭＶＣなどのビデオ規格でピクチャをコーディングする場合など、（図１に示されるような）異なるビューからの参照ピクチャを考慮しなければならない場合、参照ピクチャを利用可能にする問題は拡大されるようになる。

Ａ．Ｖｅｔｒｏ、Ｙ．Ｓｕ、Ｈ．Ｋｉｍａｔａ、Ａ．Ｓｍｏｌｉｃ、「ＪｏｉｎｔＭｕｌｔｉｖｉｅｗＶｉｄｅｏＭｏｄｅｌ（ＪＭＶＭ）１．０」、ＪＶＴ−Ｔ２０８．ｄｏｃ、Ｋｌａｇｅｎｆｕｒｔ、Ａｕｓｔｒｉａ、２００６年７月Ｇ．Ｓｕｌｌｉｖａｎ、Ｔ．Ｗｉｅｇａｎｄ、Ａ．Ｌｕｔｈｒａ、「ＤｒａｆｔｏｆＶｅｒｓｉｏｎ４ｏｆＨ．２６４／ＡＶＣ（ＩＴＵ−ＴＲｅｃｏｍｍｅｎｄａｔｉｏｎＨ．２６４ａｎｄＩＳＯ／ＩＥＣ１４４９６−１０（ＭＰＥＧ−４ｐａｒｔ１０）ＡｄｖａｎｃｅｄＶｉｄｅｏＣｏｄｉｎｇ）」、ＰａｌｍａｄｅＭａｌｌｏｒｃａ、ＥＳ１８−２２、２００４年１０月ＩａｉｎＧＲｉｃｈａｒｄｓｏｎ、「ＦｒａｍｅａｎｄＰｉｃｔｕｒｅＭａｎａｇｅｍｅｎｔ」、ｈｔｔｐ：／／ｗｗｗ．ｒｇｕ．ａｃ．ｕｋ／ｆｉｌｅｓ／ａｖｃ＿ｐｉｃｍａｎａｇｅｍｅｎｔ＿ｄｒａｆｔ１．ｐｄｆＫ．Ｍｕｌｌｅｒ、Ｐ．Ｍｅｒｋｌｅ、Ａ．Ｓｍｏｌｉｃ、Ｔ．Ｗｉｅｇａｎｄ、「ＭｕｌｔｉｖｉｅｗＣｏｄｉｎｇｕｓｉｎｇＡＶＣ」、ｍ１２９４５、Ｂａｎｇｋｏｋ、Ｔｈａｉｌａｎｄ、２００６年１月

本発明の原理は、従来技術の上記および他の難点および不都合に対処するものであり、ビデオ符号化のための動き推定予測器として利用可能な動き情報を再使用するための方法および装置に関する。

本原理の一態様によれば、復号器によって復号されるピクチャからの情報を考慮して、メモリ・デバイス内に保存された参照ピクチャに対してメモリ管理操作を実行する、コーダが提供され、そのような情報は、その参照ピクチャに関連するビュー情報に関係する。

本原理の上記および他の態様、特徴、および利点は、添付の図面と関連させて読まれる、例示的な実施形態の以下の詳細な説明から明らかになろう。

本原理は、以下の例示的な図面によって、より良く理解することができよう。

異なる時点におけるビデオ・ピクチャ・ビューの多視点符号化の例示的な一実施形態であって、そのようなビデオ・ピクチャが、図に示された方法で参照ピクチャを使用してコーディングされる、一実施形態を示す図である。本発明の原理による、ビデオ・コーダの例示的な一実施形態を示す図である。本発明の原理に従って使用される、シンタックス要素ｒｅｆ＿ｐｉｃ＿ｌｉｓｔ＿ｒｅｏｒｄｅｒｉｎｇ（）の疑似コードの一実施形態を示す図である。本発明の原理に従って使用される、シンタックス要素ｓｌｉｃｅ＿ｓｈｅａｄ＿ｍｖｃ＿ｅｘｔｅｎｓｉｏｎ（）の疑似コードの一実施形態を示す図である。本発明の原理に従って使用される、シンタックス要素ｒｅｆ＿ｐｉｃ＿ｌｉｓｔ＿ｒｅｏｒｄｅｒｉｎｇ＿ｍｖｃ＿ｅｘｔｅｎｓｉｏｎ（）の疑似コードの一実施形態を示す図である。本発明の原理に従って使用される、シンタックス要素ｒｅｆ＿ｐｉｃ＿ｌｉｓｔ＿ｒｅｏｒｄｅｒｉｎｇ＿ｍｖｃ＿ｅｘｔｅｎｓｉｏｎ（）の疑似コードの一実施形態を示す図である。本発明の原理による、ピクチャ参照リスト並べ替え方法の一実施形態のブロック図である。

本発明の原理は、任意のフレーム内およびフレーム間ベースの符号化規格に適用することができる。本明細書の全体で使用される「ピクチャ」という用語は、当技術分野において、「フレーム」、「フィールド」、および「スライス」として、ならびに「ピクチャ」という用語自体でも知られ得る、様々な形態のビデオ画像情報を説明するための総称的用語として使用される。ピクチャという用語は、様々な要素ビデオ情報を表すために使用されるが、そのような参照ピクチャが同じピクチャからのスライスを「参照ピクチャ」として使用できる場合、ＡＶＣはスライスという用語を使用するようにしており、またピクチャがどのように細分できるかに関わらず、本発明の原理が適用されることに留意されたい。

また、本発明の説明では、Ｃ言語タイプの書式を使用する様々なコマンド（シンタックス要素）が、そのようなコマンド中のディスクリプタについて以下の用語法を使用する図において詳述される。
ｕ（ｎ）：ｎビットを使用する符号なし整数。シンタックス表内でｎが「ｖ」である場合、ビットの数は、他のシンタックス要素の値に依存する方法で変化する。このディスクリプタのための構文解析プロセスは、最上位ビットが最初に書かれる、符号なし整数のバイナリ表現として解釈される、関数ｒｅａｄ＿ｂｉｔｓ（ｎ）の戻り値によって規定される。
ｕｅ（ｖ）：左ビットが最初の、符号なし整数の指数ゴロム符号化（Ｅｘｐ−Ｇｏｌｏｍｂ−ｃｏｄｅｄ）シンタックス要素である。
ｓｅ（ｖ）：左ビットが最初の、符号付き整数の指数ゴロム符号化シンタックス要素である。
Ｃ：シンタックス要素が適用されるカテゴリを、すなわち、特定のフィールドがどのレベルに適用されるべきかを表す。

本説明は、本原理を説明する。したがって、本明細書で明示的に説明または図示されていなくても、本原理を実施し、その主旨および範囲内に含まれる様々な構成を、当業者であれば考案できることが理解されよう。

本明細書で述べられるすべての例および条件付きの言葉は、教示を目的とするもので、本原理と当技術分野を発展させるために発明者（ら）が寄与した概念とを読者が理解する助けとなるように意図されており、そのような具体的に述べられた例および条件に限定されると解釈されるべきではない。

さらに、本原理の原理、態様、および実施形態を述べるすべての言表は、それらの具体的な例と同様に、それらの構造的均等物および機能的均等物の両方を包含することが意図されている。加えて、そのような均等物は、現在知られている均等物ばかりでなく、将来開発される均等物も含むことが、すなわち、構造に関わらず同一機能を実行する、開発されたいかなる要素をも含むことが意図されている。

図２をまた参照すると、コーダ２０５が（ＡＶＣおよびＭＶＣの下で）、動画像が符号化される符号化動作を実行する場合、符号化されたピクチャは、いくつかの異なる値に関連づけられ、そのような値は、コーダ２０５によってピクチャ・ヘッダ（例えば、スライス・ヘッダ）内に配置される。ｐｉｃ＿ｎｕｍ（ピクチャ番号）と呼ばれる第１の値は、コーディングされたビデオ・ピクチャの系列内における、コーディングされた際の、ピクチャの順序を示す。例えば、系列内の第１のピクチャは、「１」の値を有し、コーディングされた第４のピクチャは、「４」の値を有する。

ピクチャは、コーディングされたピクチャが最終的に復号される場合に、それが表示される順序を決定する、ピクチャ順序カウント（ＰＯＣ：ｐｉｃｔｕｒｅｏｒｄｅｒｃｏｕｎｔ）と呼ばれる値も有する。これは、コーディングされたピクチャが、そのピクチャに関連づけられたＰＯＣ番号とは異なるフレーム番号を有することが可能であることを意味する。

多視点ビデオ符号化は、ピクチャのために併せて使用できる、第３の値を導入する。ｖｉｅｗ＿ｉｄ値は、ピクチャが対応するビューを示す。例えば、ビューＳ３に関連するピクチャは、「３」に等しいｖｉｅｗ＿ｉｄを有し、一方、ビューＳ５に対応するピクチャは、「５」に等しいｖｉｅｗ＿ｉｄを有する。そのような値の使用は、コーダがｐｉｃ＿ｎｕｍおよびＰＯＣを異なるビュー間で分離することを可能にし、そのことが、同じｐｉｃ＿ｎｕｍおよび／またはＰＯＣを有する参照ピクチャを保存するＤＰＢ２１５を提供するので、そのことからも、ｖｉｅｗ＿ｉｄ番号は有用である。したがって、（同じＰＯＣまたはｐｉｃ＿ｎｕｍを有する）そのようなピクチャは、ｖｉｅｗ＿ｉｄ値を使用することによって、互いに区別される。

上述された値は、（他の番号、変数名、およびハッシュ・テーブルなどを使用する）異なる方法で実施されてよいことを理解されたい。

（ｈｔｔｐ：／／ｗｗｗ．ｒｇｕ．ａｃ．ｕｋ／ｆｉｌｅｓ／ａｖｃ＿ｐｉｃｍａｎａｇｅｍｅｎｔ＿ｄｒａｆｔ１．ｐｄｆにおいて見出される、ＩａｉｎＧＲｉｃｈａｒｄｓｏｎによる「ＦｒａｍｅａｎｄＰｉｃｔｕｒｅＭａｎａｇｅｍｅｎｔ」において説明されるように）参照ピクチャをＤＰＢ２１５に保存する場合、そのようなピクチャは、メモリ・ステータスを割り当てられ、メモリ・ステータスは、参照ピクチャを、（ＰｉｃＮｕｍまたはＰｉｃＯｒｄｅｒＣｏｕｎｔによって参照される）短期参照ピクチャとして、または（ＬｏｎｇＴｅｒｍＰｉｃインデックスにおける番号を表すＬｏｎｇＴｅｒｍＰｉｃＮｕｍによって参照される）長期参照ピクチャとして標識づける。参照ピクチャのステータスは、（例えば、ＡＶＣにおいて知られるような、メモリ管理コマンド演算子の使用によって）短期と長期の間で変更でき、または参照ピクチャが最終的にＤＰＢ２１５から取り去られる「ｎｏｔａｒｅｆｅｒｅｎｃｅ」として知られるステータスにさえも変更できることを理解されたい。

参照ピクチャの編成は、１つまたは２つのリストの中に順序よく配置され、それらのリストは、ピクチャ（スライス）をコーディングする前に使用される。Ｐピクチャのための参照は、ピクチャのリストを１つ（リスト０）使用し、一方、Ｂピクチャは、リストを２つ（リスト０およびリスト１）使用する。ピクチャ・リスト内のピクチャのデフォルト編成は、コーディングされる現ピクチャがＰピクチャである場合は復号順序（ＰｉｃＮｕｍ）に依存し、コーディングされる現ピクチャがＢピクチャである場合は表示順序に依存する。長期参照ピクチャとして指示された参照ピクチャは一般に、ＬｏｎｇＴｅｒｍＰｉｃＮｕｍを割り当てられ、短期ピクチャよりも長い時間にわたってピクチャが保持されるように、参照リスト内のある位置に配置される。

ＡＶＣは、コーダ２０５が、ピクチャ・スライスをコーディングする場合に、リスト０（およびＢピクチャ（スライス）についてはリスト１）内の参照ピクチャのデフォルト順序を変更することを可能にする。すなわち、コーダは、（リスト内の）１つの参照ピクチャが、参照リスト内で指示された参照ピクチャよりも良好な参照ピクチャとなり得ることを認識することができる。これは、コーディングされる現ピクチャとの相関性がより高い参照ピクチャに、コーディングされるピクチャとの相関性がより低い参照ピクチャよりもインデックスが小さい（より近い）参照リスト上の位置を占めさせることによって、コーディング効率上の助けとなる。したがって、参照ピクチャ・リスト並べ替え（ＲＰＬＲ：ＲｅｆｅｒｅｎｃｅＰｉｃｔｕｒｅＬｉｓｔＲｅｏｒｄｅｒｉｎｇ）コマンドとして知られるコマンドが、そのような参照ピクチャの順序を動かすために使用され、図３に示されている。

図３は、ピクチャ・リストを並べ替えるために使用されるＡＶＣコマンドを提供する、ｒｅｆ＿ｐｉｃ＿ｌｉｓｔ＿ｒｅｏｒｄｅｒｉｎｇというＡＶＣシンタックス要素を示しており（スライスとの関連で説明されるが、上で説明されたように、そのような概念はピクチャに対しても実行できることを理解されたい）、ＡＶＣコマンドの意味は、ＡＶＣリファレンスによって説明される。

ＭＶＣの文脈内で参照ピクチャ・リストの使用を考える場合、時間参照だけを考慮するＡＶＣとは対照的に、時間参照およびクロスビュー参照という、考慮すべき２組の参照が実際には存在する。

したがって、従来技術では、Ｋ．Ｍｕｌｌｅｒ、Ｐ．Ｍｅｒｋｌｅ、Ａ．Ｓｍｏｌｉｃ、Ｔ．Ｗｉｅｇａｎｄ、「ＭｕｌｔｉｖｉｅｗＣｏｄｉｎｇｕｓｉｎｇＡＶＣ」、ｍ１２９４５、Ｂａｎｇｋｏｋ、Ｔｈａｉｌａｎｄ、２００６年１月において開示されたような原理において、すべてのビデオ系列を単一の系列にインタリーブする、単一のインタリーブ系列の構成が提案されており、その系列は、その後、ＡＶＣ対応コーダによってコーディングでき、互換性のあるビット・ストリームを生成する。しかし、この提案されたＡＶＣ実施の不都合は、ＲＰＬＰコマンドをそれらが現在ＡＶＣに存在するように実施するために、ｐｉｃ＿ｎｕｍおよびＰＯＣの一意の値がコーディングされる各ピクチャに割り当てられなければならないので、どのピクチャがどのビューに属するかを識別する方法が存在しないことである。

ＭＶＣの現行の実施に戻ると、クロスビュー参照を通知するために、シーケンス・パラメータ・セット（ＳＰＳ：ＳｅｑｕｅｎｃｅＰａｒａｍｅｔｅｒＳｅｔ）に追加される、追加のシンタックスを含むことが提案されている。このシンタックス要素は、以下で示されるように、アンカ・ピクチャ（ａｎｃｈｏｒｐｉｃｔｕｒｅ）および非アンカ・ピクチャ（ｎｏｎ−ａｎｃｈｏｒｐｉｃｔｕｒｅ）のために使用される、クロスビュー参照を示すために使用される。

以下の手順は、現ビューとは異なるビューからの参照ピクチャを参照予測リスト内に配置するために実行される。
− ０からｎｕｍ＿ｍｕｌｔｉｖｉｅｗ＿ｒｅｆ＿ｆｏｒ＿ｌｉｓｔＸ−１までの、ｉの各値について、
− 現ピクチャと時間的に整列しているビューｒｅｆｅｒｅｎｃｅ＿ｖｉｅｗ＿ｆｏｒ＿ｌｉｓｔ＿Ｘ［ｉ］からの再構成ピクチャが取得され、復号予測バッファ（ＤＰＢ）内に挿入される。
− そのピクチャのインデックスが、ＲｅｆＰｉｃＬｉｓｔＸの次の空スロット内に挿入される。

しかし、この実施は、参照ピクチャ・リストを初期化（および構成）する方法が固定され、変更できないという点で、問題を有する。すなわち、時間的ピクチャおよびクロスビュー・ピクチャの順序に柔軟性がない。加えて、各アンカ・ピクチャ（Ｉ）ならびに非アンカ・ピクチャ（ＢおよびＰ）について指示される参照ピクチャの数は同じである。

したがって、本発明は、多視点ピクチャを考慮して、参照ピクチャ・リストをどのように並べ替えるかについての、フレームワークを提案する。本発明の実施形態は、ＡＶＣおよびＭＶＣ環境の文脈内で開示されるが、本発明の原理は、他のビデオ・コーディング規格にも同様に適用されることを理解されたい。

本発明は、ピクチャ・ヘッダ（スライス・ヘッダ）内に存在する、図４の新しい要素シンタックスｒｅｆ＿ｐｉｃ＿ｌｉｓｔ＿ｒｅｏｒｄｅｒｉｎｇ＿ｍｖｃ＿ｅｘｔｅｎｓｉｏｎ（）を提案する。

第１に、本発明は、ＡＶＣ互換シンタックス要素ｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ０＿ａｃｔｉｖｅ＿ｍｉｎｕｓ１およびｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ１＿ａｃｔｉｖｅ＿ｍｉｎｕｓ１が、時間的な意味でアクティブな参照ピクチャの数を示すに過ぎないという事実を反映して、再定義されるべきことを提案する。

ｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ０＿ａｃｔｉｖｅ＿ｍｉｎｕｓ１は、スライスを復号するために使用される、時間参照ピクチャ・リスト０の最大参照インデックスを規定する。ｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ０＿ａｃｔｉｖｅ＿ｍｉｎｕｓ１の範囲は、以下のように規定される。
− ｆｉｅｌｄ＿ｐｉｃ＿ｆｌａｇが０に等しい場合、ｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ０＿ａｃｔｉｖｅ＿ｍｉｎｕｓ１は、０以上１５以下の範囲内にある。ＭｂａｆｆＦｒａｍｅＦｌａｇが１に等しい場合、ｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ０＿ａｃｔｉｖｅ＿ｍｉｎｕｓ１は、フレーム・マクロブロックの復号のための最大インデックス値であり、２×ｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ０＿ａｃｔｉｖｅ＿ｍｉｎｕｓ１＋１は、フィールド・マクロブロックの復号のための最大インデックス値である。
− それ以外の（ｆｉｅｌｄ＿ｐｉｃ＿ｆｌａｇが１に等しい）場合、ｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ０＿ａｃｔｉｖｅ＿ｍｉｎｕｓ１は、０以上３１以下の範囲内にある。

ｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ１＿ａｃｔｉｖｅ＿ｍｉｎｕｓ１は、ｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ０＿ａｃｔｉｖｅ＿ｍｉｎｕｓ１と同じセマンティクスを有するが、ｌ０およびリスト０は、それぞれｌ１およびリスト１によって置き換えられる。

第２に、クロスビュー的意味においてアクティブな参照ピクチャの数を示す、２つの新しいシンタックス要素が提案される。

ｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ０＿ａｃｔｉｖｅ＿ｖｉｅｗ＿ｍｉｎｕｓ１は、スライスを復号するために使用される、クロスビュー参照ピクチャ・リスト０の最大参照インデックスを規定する。ｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ０＿ａｃｔｉｖｅ＿ｖｉｅｗ＿ｍｉｎｕｓ１の範囲は、以下のように規定される。
− ｆｉｅｌｄ＿ｐｉｃ＿ｆｌａｇが０に等しい場合、ｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ０＿ａｃｔｉｖｅ＿ｖｉｅｗ＿ｍｉｎｕｓ１は、０以上１５以下の範囲内にある。ＭｂａｆｆＦｒａｍｅＦｌａｇが１に等しい場合、ｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ０＿ａｃｔｉｖｅ＿ｖｉｅｗ＿ｍｉｎｕｓ１は、フレーム・マクロブロックの復号のための最大インデックス値であり、２×ｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ０＿ａｃｔｉｖｅ＿ｖｉｅｗ＿ｍｉｎｕｓ１＋１は、フィールド・マクロブロックの復号のための最大インデックス値である。
− そうでない（ｆｉｅｌｄ＿ｐｉｃ＿ｆｌａｇが１に等しい）場合、ｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ０＿ａｃｔｉｖｅ＿ｖｉｅｗ＿ｍｉｎｕｓ１は、０以上３１以下の範囲内にある。

ｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ１＿ａｃｔｉｖｅ＿ｖｉｅｗ＿ｍｉｎｕｓ１（他方の提案されたシンタックス要素）は、ｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ０＿ａｃｔｉｖｅ＿ｖｉｅｗ＿ｍｉｎｕｓ１と同じセマンティクスを有するが、ｌ０およびリスト０は、それぞれｌ１およびリスト１によって置き換えられる。

これら２つのシンタックスは、以下の式を満足するような値を有する。
ｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ０＿ａｃｔｉｖｅ＿ｍｉｎｕｓ１＋ｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ０＿ａｃｔｉｖｅ＿ｖｉｅｗ＿ｍｉｎｕｓ１＜＝ｎｕｍ＿ｒｅｆ＿ｆｒａｍｅｓ
かつ
ｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ１＿ａｃｔｉｖｅ＿ｍｉｎｕｓ１＋ｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ１＿ａｃｔｉｖｅ＿ｖｉｅｗ＿ｍｉｎｕｓ１＜＝ｎｕｍ＿ｒｅｆ＿ｆｒａｍｅｓ

先に説明されたように、ＭＶＣシステムのためのデフォルト初期化プロセスが定義される必要がある。したがって、そのようなプロセスについて、いくつかの異なる実施形態が提案される。

本発明の原理の第１の実施形態は、ＭＰＥＧ−４ＡＶＣ仕様において定義されるように、現ビューの時間的ピクチャのすべてが初期化されるようにする。この初期化リストは、その後、ＬＩＳＴ＿０およびＬＩＳＴ＿１のために、それぞれｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ０＿ａｃｔｉｖｅ＿ｍｉｎｕｓ１およびｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ１＿ａｃｔｉｖｅ＿ｍｉｎｕｓ１で規定される値によって切り詰められる。

これらのピクチャに続いて、ＭＶＣ仕様のＳＰＳにおいて規定されるクロスビュー参照ピクチャが挿入され、ＬＩＳＴ＿０およびＬＩＳＴ＿１のために、それぞれｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ０＿ａｃｔｉｖｅ＿ｖｉｅｗ＿ｍｉｎｕｓ１およびｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ１＿ａｃｔｉｖｅ＿ｖｉｅｗ＿ｍｉｎｕｓ１で規定される値によって切り詰められる。

現行のＭＶＣ仕様において規定されるような参照ピクチャ・リスト並べ替えコマンドが正しく機能することを可能にするため、これらのコマンドが時間参照ピクチャ上だけで作動できるという制約を課す。ＲＰＬＲプロセスは、時間的ピクチャの初期化後直ちに、クロスビュー参照の初期化前に生じること、または時間およびクロスビュー参照の両方がそれらのデフォルト位置に初期化された後に生じることができるが、後者の場合も、時間参照ピクチャだけが並べ替えられる。

この第１の提案された実施形態についての１つの難点は、クロスビュー参照ピクチャが並べ替えできないことである。

ＭＶＣ仕様のＳＰＳにおいて規定されるクロスビュー参照ピクチャが挿入され、ＬＩＳＴ＿０およびＬＩＳＴ＿１のために、それぞれｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ０＿ａｃｔｉｖｅ＿ｖｉｅｗ＿ｍｉｎｕｓ１およびｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ１＿ａｃｔｉｖｅ＿ｖｉｅｗ＿ｍｉｎｕｓ１で規定される値によって切り詰められる、第２の実施形態が提案される。

これらのピクチャに続いて、ＭＰＥＧ−４ＡＶＣ仕様において定義されるように、現ビューのすべての時間的ピクチャが初期化される。これは、その後、ＬＩＳＴ＿０およびＬＩＳＴ＿１のために、それぞれｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ０＿ａｃｔｉｖｅ＿ｍｉｎｕｓ１およびｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ１＿ａｃｔｉｖｅ＿ｍｉｎｕｓ１で規定される値によって切り詰められるリストである。

第３の実施形態が、上述された第１の実施形態に伴う問題に対処するために提供される。具体的には、２００６年１０月１３日に出願された米国仮出願第６０／８５１，５２２号、および２００６年１０月１３日に出願された米国仮出願第６０／８５１，５８９号からの優先権を主張する、２００７年１０月１２日に出願されたＰＣＴ出願を参照すると、現在コーディングされているピクチャに関連するビューとは異なるｖｉｅｗ＿ｉｄ値を有するピクチャに、長期インデックス（値）を割り当てるために、シンタックス要素ｌｏｎｇ＿ｔｅｒｍ＿ｆｒａｍｅ＿ｉｄｘが使用される。長期インデックスをクロスビュー・ピクチャに割り当てることによって、その後、そのようなピクチャは、ＡＶＣピクチャとして使用されているかのように扱うことができ、それが、長期ピクチャに適用されるような、ＲＰＬＲコマンドの使用を可能にする。したがって、クロスビュー・ピクチャは、ＡＶＣを使用して、効果的に並べ替えることができる。

新しいＲＰＬＲコマンドが提案される、第４の実施形態も提案される。これらのコマンドは、ＤＰＢ２１５を制御するために使用される、メモリ管理コマンド操作と類似しているが、これらの新しいコマンドは、現在操作されているピクチャに関連するビュー以外のビューにおけるピクチャを操作するために使用される。これらの新しいシンタックス要素は、提案されたＭＶＣ参照ピクチャ・リスト並べ替えシンタックスを示す、図５に提示されている。

これらの実施形態のためのデフォルト初期化は、最初に、Ｈ．２６４／ＭＰＥＧ−４ＡＶＣ仕様で定義される参照リスト初期化で規定されるように、すべての時間参照に対するものとすることができ、次に、これらのピクチャの後に、Ｈ．２６４／ＭＰＥＧ−４ＡＶＣのＭＶＣ拡張のＳＰＳで規定されるクロスビュー・ピクチャが続くことができる。

この実施形態の動作の部分は、シンタックス要素を、ｒｅｆ＿ｐｉｃ＿ｌｉｓｔ＿ｒｅｏｒｄｅｒｉｎｇ＿ｍｖｃ＿ｅｘｔｅｎｓｉｏｎと、それから呼び出せるシンタックス要素ｒｅｆ＿ｐｉｃ＿ｌｉｓｔ＿ｒｅｏｒｄｅｒｉｎｇとに分割することである。すなわち、呼び出しの機構が、ＭＶＣ環境において処理される多視点ベースのピクチャを有することができ、その後、そのようなプロセスの結果が、ＡＶＣ環境において処理される多視点参照ベースのピクチャを有することができる。

インデックスｍｖｃ＿ｒｅｏｒｄｅｒｉｎｇ＿ｏｆ＿ｐｉｃ＿ｎｕｍｓ＿ｉｄｃと関連して使用される様々な状態が、以下の表１に開示されている。

加えて、シンタックス要素ｍｖｃ＿ｒｅｏｒｄｅｒｉｎｇ＿ｏｆ＿ｐｉｃ＿ｎｕｍｓ＿ｉｄｃ、ａｂｓ＿ｄｉｆｆ＿ｐｉｃ＿ｎｕｍ＿ｍｉｎｕｓ１、およびｌｏｎｇ＿ｔｅｒｍ＿ｐｉｃ＿ｎｕｍは、初期参照ピクチャ・リストから、スライスを復号するために使用される参照ピクチャ・リストへの変更も指定する。

１に等しいｍｖｃ＿ｒｅｆ＿ｐｉｃ＿ｌｉｓｔ＿ｒｅｏｒｄｅｒｉｎｇ＿ｆｌａｇ＿ｌ０は、シンタックス要素ｍｖｃ＿ｒｅｏｒｄｅｒｉｎｇ＿ｏｆ＿ｐｉｃ＿ｎｕｍｓ＿ｉｄｃが、参照ピクチャ・リスト０を指定するために存在することを指定する。０に等しいｍｖｃ＿ｒｅｆ＿ｐｉｃ＿ｌｉｓｔ＿ｒｅｏｒｄｅｒｉｎｇ＿ｆｌａｇ＿ｌ０は、このシンタックス要素が存在しないことを指定する。

ｍｖｃ＿ｒｅｆ＿ｐｉｃ＿ｌｉｓｔ＿ｒｅｏｒｄｅｒｉｎｇ＿ｆｌａｇ＿ｌ０が１に等しい場合、ｍｖｃ＿ｒｅｆ＿ｐｉｃ＿ｌｉｓｔ＿ｒｅｏｒｄｅｒｉｎｇ＿ｆｌａｇ＿ｌ０の後に続いて、ｍｖｃ＿ｒｅｏｒｄｅｒｉｎｇ＿ｏｆ＿ｐｉｃ＿ｎｕｍｓ＿ｉｄｃが３に等しくない回数は、ｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ０＿ａｃｔｉｖｅ＿ｍｉｎｕｓ１＋１を超えない。

Ｈ．２６４／ＭＰＥＧ−４ＡＶＣ仕様で規定されるように生成された初期参照ピクチャ・リスト内のＲｅｆＰｉｃＬｉｓｔ０［ｎｕｍ＿ｒｅｆｉｄｘ＿ｌ０＿ａｃｔｉｖｅ＿ｍｉｎｕｓ１］が「ｎｏｒｅｆｅｒｅｎｃｅｐｉｃｔｕｒｅ」に等しい場合、Ｈ．２６４／ＭＰＥＧ−４ＡＶＣ仕様で規定されるように生成された並べ替えリスト内のＲｅｆＰｉｃＬｉｓｔ０［ｎｕｍ＿ｒｅｆｉｄｘ＿ｌ０＿ａｃｔｉｖｅ＿ｍｉｎｕｓ１］が「ｎｏｒｅｆｅｒｅｎｃｅｐｉｃｔｕｒｅ」に等しくなくなるまで、ｍｖｃ＿ｒｅｆ＿ｐｉｃ＿ｌｉｓｔ＿ｒｅｏｒｄｅｒｉｎｇ＿ｆｌａｇ＿ｌ０は１に等しく、ｍｖｃ＿ｒｅｏｒｄｅｒｉｎｇ＿ｏｆ＿ｐｉｃ＿ｎｕｍｓ＿ｉｄｃは３に等しくない。

１に等しいｍｖｃ＿ｒｅｆ＿ｐｉｃ＿ｌｉｓｔ＿ｒｅｏｒｄｅｒｉｎｇ＿ｆｌａｇ＿ｌ１は、シンタックス要素ｍｖｃ＿ｒｅｏｒｄｅｒｉｎｇ＿ｏｆ＿ｐｉｃ＿ｎｕｍｓ＿ｉｄｃが、参照ピクチャ・リスト１を指定するために存在することを指定する。０に等しいｍｖｃ＿ｒｅｆ＿ｐｉｃ＿ｌｉｓｔ＿ｒｅｏｒｄｅｒｉｎｇ＿ｆｌａｇ＿ｌ１は、このシンタックス要素が存在しないことを指定する。

ｍｖｃ＿ｒｅｆ＿ｐｉｃ＿ｌｉｓｔ＿ｒｅｏｒｄｅｒｉｎｇ＿ｆｌａｇ＿ｌ１が１に等しい場合、ｍｖｃ＿ｒｅｆ＿ｐｉｃ＿ｌｉｓｔ＿ｒｅｏｒｄｅｒｉｎｇ＿ｆｌａｇ＿ｌ１の後に続いて、ｍｖｃ＿ｒｅｏｒｄｅｒｉｎｇ＿ｏｆ＿ｐｉｃ＿ｎｕｍｓ＿ｉｄｃが３に等しくない回数は、ｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ１＿ａｃｔｉｖｅ＿ｍｉｎｕｓ１＋１を超えない。

Ｂスライスを復号する際、Ｈ．２６４／ＭＰＥＧ−４ＡＶＣ仕様で規定されるように生成された初期参照ピクチャ・リスト内のＲｅｆＰｉｃＬｉｓｔ１［ｎｕｍ＿ｒｅｆｉｄｘ＿ｌ１＿ａｃｔｉｖｅ＿ｍｉｎｕｓ１］が「ｎｏｒｅｆｅｒｅｎｃｅｐｉｃｔｕｒｅ」に等しい場合、Ｈ．２６４／ＭＰＥＧ−４ＡＶＣ仕様で規定されるように生成された並べ替えリスト内のＲｅｆＰｉｃＬｉｓｔ１［ｎｕｍ＿ｒｅｆｉｄｘ＿ｌ１＿ａｃｔｉｖｅ＿ｍｉｎｕｓ１］が「ｎｏｒｅｆｅｒｅｎｃｅｐｉｃｔｕｒｅ」に等しくなくなるまで、ｍｖｃ＿ｒｅｆ＿ｐｉｃ＿ｌｉｓｔ＿ｒｅｏｒｄｅｒｉｎｇ＿ｆｌａｇ＿ｌ１は１に等しく、ｍｖｃ＿ｒｅｏｒｄｅｒｉｎｇ＿ｏｆ＿ｐｉｃ＿ｎｕｍｓ＿ｉｄｃは３に等しくない。

ｍｖｃ＿ｒｅｏｒｄｅｒｉｎｇ＿ｏｆ＿ｐｉｃ＿ｎｕｍｓ＿ｉｄｃは、ｄｉｆｆｅｒｅｎｃｅ＿ｏｆ＿ｖｉｅｗ＿ｉｄおよびａｂｓ＿ｄｉｆｆ＿ｐｉｃ＿ｎｕｍ＿ｍｉｎｕｓ１またはｌｏｎｇ＿ｔｅｒｍ＿ｐｉｃ＿ｎｕｍと一緒に、参照ピクチャのどれが再マッピングされるかを指定する。ｍｖｃ＿ｒｅｏｒｄｅｒｉｎｇ＿ｏｆ＿ｐｉｃ＿ｎｕｍｓ＿ｉｄｃの値は、Ｈ．２６４／ＭＰＥＧ−４ＡＶＣ仕様で規定される。ｍｖｃ＿ｒｅｆ＿ｐｉｃ＿ｌｉｓｔ＿ｒｅｏｒｄｅｒｉｎｇ＿ｆｌａｇ＿ｌ０またはｍｖｃ＿ｒｅｆ＿ｐｉｃ＿ｌｉｓｔ＿ｒｅｏｒｄｅｒｉｎｇ＿ｆｌａｇ＿ｌ１の直後に続く、第１のｍｖｃ＿ｒｅｏｒｄｅｒｉｎｇ＿ｏｆ＿ｐｉｃ＿ｎｕｍｓ＿ｉｄｃの値は、３に等しくない。

ａｂｓ＿ｄｉｆｆ＿ｐｉｃ＿ｎｕｍ＿ｍｉｎｕｓ１プラス１は、リスト内の現インデックスに移動されるピクチャのピクチャ番号とピクチャ番号予測値の間の絶対差を指定する。ａｂｓ＿ｄｉｆｆ＿ｐｉｃ＿ｎｕｍ＿ｍｉｎｕｓ１は、０からＭａｘＰｉｃＮｕｍ−１までの範囲内にある。移動されるピクチャは、現ピクチャのｖｉｅｗ＿ｉｄと異なるｖｉｅｗ＿ｉｄを有しなければならない。

ｌｏｎｇ＿ｔｅｒｍ＿ｐｉｃ＿ｎｕｍは、リスト内の現インデックスに移動されるピクチャの長期ピクチャ番号を指定する。コーディング・フレームを復号する場合、ｌｏｎｇ＿ｔｅｒｍ＿ｐｉｃ＿ｎｕｍは、参照フレームの１つまたは「ｕｓｅｄｆｏｒｌｏｎｇ−ｔｅｒｍｒｅｆｅｒｅｎｃｅ（長期参照に使用される）」として標識づけされた相補的参照フィールド対の１つに割り当てられたＬｏｎｇＴｅｒｍＰｉｃＮｕｍに等しい。コーディング・フィールドを復号する場合、ｌｏｎｇ＿ｔｅｒｍ＿ｐｉｃ＿ｎｕｍは、「ｕｓｅｄｆｏｒｌｏｎｇ−ｔｅｒｍｒｅｆｅｒｅｎｃｅ」として標識づけされた参照フィールドの１つに割り当てられたＬｏｎｇＴｅｒｍＰｉｃＮｕｍに等しい。移動されるピクチャは、現ピクチャのｖｉｅｗ＿ｉｄと異なるｖｉｅｗ＿ｉｄを有しなければならない。

ｄｉｆｆｅｒｅｎｃｅ＿ｏｆ＿ｖｉｅｗ＿ｉｄは、リスト内の現インデックスに移動されるピクチャのｖｉｅｗ＿ｉｄとｖｉｅｗ＿ｉｄ予測値の間の差を指定する。

参照ピクチャの並べ替えを実行するプロセスは、デフォルト・リストに基づいており、以下のように説明することができる。
ｍｖｃ＿ｒｅｆ＿ｐｉｃ＿ｌｉｓｔ＿ｒｅｏｒｄｅｒｉｎｇ＿ｆｌａｇ＿ｌ０が１に等しい場合、以下が適用される。
− ｒｅｆＩｄｘＬ０を参照ピクチャ・リストＲｅｆＰｉｃＬｉｓｔ０に対するインデックスとする。これは最初、０に等しく設定される。
− 対応するシンタックス要素ｍｖｃ＿ｒｅｏｒｄｅｒｉｎｇ＿ｏｆ＿ｐｉｃ＿ｎｕｍｓ＿ｉｄｃが、ビット・ストリーム内でそれらが生じる順序で処理される。これらのシンタックス要素の各々について、以下が適用される。
１）ｍｖｃ＿ｒｅｏｒｄｅｒｉｎｇ＿ｏｆ＿ｐｉｃ＿ｎｕｍｓ＿ｉｄｃが０に等しい場合、または１に等しい場合、以下のＩで規定されるプロセスが、ｒｅｆＩｄｘＬ０を入力として起動され、その出力が、ｒｅｆＩｄｘＬ０に割り当てられる。
２）そうではなく、ｍｖｃ＿ｒｅｏｒｄｅｒｉｎｇ＿ｏｆ＿ｐｉｃ＿ｎｕｍｓ＿ｉｄｃが２に等しい場合、以下のＩＩで規定されるプロセスが、ｒｅｆＩｄｘＬ０を入力として起動され、その出力が、ｒｅｆＩｄｘＬ０に割り当てられる。
３）それ以外の（ｍｖｃ＿ｒｅｏｒｄｅｒｉｎｇ＿ｏｆ＿ｐｉｃ＿ｎｕｍｓ＿ｉｄｃが３に等しい）場合、参照ピクチャ・リストＲｅｆＰｉｃＬｉｓｔ０に対する並べ替えプロセスが終了する。
ｍｖｃ＿ｒｅｆ＿ｐｉｃ＿ｌｉｓｔ＿ｒｅｏｒｄｅｒｉｎｇ＿ｆｌａｇ＿ｌ１が１に等しい場合、以下が適用される。
− ｒｅｆＩｄｘＬ１を参照ピクチャ・リストＲｅｆＰｉｃＬｉｓｔ１に対するインデックスとする。これは最初、０に等しく設定される。
− 対応するシンタックス要素ｍｖｃ＿ｒｅｏｒｄｅｒｉｎｇ＿ｏｆ＿ｐｉｃ＿ｎｕｍｓ＿ｉｄｃが、ビット・ストリーム内でそれらが生じる順序で処理される。これらのシンタックス要素の各々について、以下が適用される。
４）ｍｖｃ＿ｒｅｏｒｄｅｒｉｎｇ＿ｏｆ＿ｐｉｃ＿ｎｕｍｓ＿ｉｄｃが０に等しい場合、または１に等しい場合、以下のＩで規定されるプロセスが、ｒｅｆＩｄｘＬ１を入力として起動され、その出力が、ｒｅｆＩｄｘＬ１に割り当てられる。
５）そうではなく、ｍｖｃ＿ｒｅｏｒｄｅｒｉｎｇ＿ｏｆ＿ｐｉｃ＿ｎｕｍｓ＿ｉｄｃが２に等しい場合、以下のＩＩで規定されるプロセスが、ｒｅｆＩｄｘＬ１を入力として起動され、その出力が、ｒｅｆＩｄｘＬ１に割り当てられる。
６）それ以外の（ｍｖｃ＿ｒｅｏｒｄｅｒｉｎｇ＿ｏｆ＿ｐｉｃ＿ｎｕｍｓ＿ｉｄｃが３に等しい）場合、参照ピクチャ・リストＲｅｆＰｉｃＬｉｓｔ１に対する並べ替えプロセスが終了する。

現在コーディングされているピクチャのｖｉｅｗ＿ｉｄと異なるｖｉｅｗ＿ｉｄを有する短期参照ピクチャ用の参照ピクチャ・リストを並べ替えるため、以下が提案される。
このプロセスへの入力は、インデックスｒｅｆＩｄｘＬＸ（Ｘは０または１）である。
このプロセスの出力は、インクリメントされたインデックスｒｅｆＩｄｘＬＸである。
ｖｉｅｗＩｄＬＸ＝ｖｉｅｗＩｄＬＸＰｒｅｄ＋ｄｉｆｆｅｒｅｎｃｅ＿ｏｆ＿ｖｉｅｗ＿ｉｄ

変数ｐｉｃＮｕｍＬＸＮｏＷｒａｐは、以下のようにして導き出される。
− ｍｖｃ＿ｒｅｏｒｄｅｒｉｎｇ＿ｏｆ＿ｐｉｃ＿ｎｕｍｓ＿ｉｄｃが０に等しい場合、
ｉｆ（ｐｉｃＮｕｍＬＸＰｒｅｄ−（ａｂｓ＿ｄｉｆｆ＿ｐｉｃ＿ｎｕｍ＿ｍｉｎｕｓ１＋１）＜０）
ｐｉｃＮｕｍＬＸＮｏＷｒａｐ＝ｐｉｃＮｕｍＬＸＰｒｅｄ−（ａｂｓ＿ｄｉｆｆ＿ｐｉｃ＿ｎｕｍ＿ｍｉｎｕｓ１＋１）＋ＭａｘＰｉｃＮｕｍ
ｅｌｓｅ
ｐｉｃＮｕｍＬＸＮｏＷｒａｐ＝ｐｉｃＮｕｍＬＸＰｒｅｄ−（ａｂｓ＿ｄｉｆｆ＿ｐｉｃ＿ｎｕｍ＿ｍｉｎｕｓ１＋１）
− それ以外の（ｍｖｃ＿ｒｅｏｒｄｅｒｉｎｇ＿ｏｆ＿ｐｉｃ＿ｎｕｍｓ＿ｉｄｃが１に等しい）場合、
ｉｆ（ｐｉｃＮｕｍＬＸＰｒｅｄ＋（ａｂｓ＿ｄｉｆｆ＿ｐｉｃ＿ｎｕｍ＿ｍｉｎｕｓ１＋１）＞＝ＭａｘＰｉｃＮｕｍ）
ｐｉｃＮｕｍＬＸＮｏＷｒａｐ＝ｐｉｃＮｕｍＬＸＰｒｅｄ＋（ａｂｓ＿ｄｉｆｆ＿ｐｉｃ＿ｎｕｍ＿ｍｉｎｕｓ１＋１）−ＭａｘＰｉｃＮｕｍ
ｅｌｓｅ
ｐｉｃＮｕｍＬＸＮｏＷｒａｐ＝ｐｉｃＮｕｍＬＸＰｒｅｄ＋（ａｂｓ＿ｄｉｆｆ＿ｐｉｃ＿ｎｕｍ＿ｍｉｎｕｓ１＋１）

ｖｉｅｗＩｄＬＸＰｒｅｄは、変数ｖｉｅｗＩｄＬＸについての予測値である。この従属節で規定されるプロセスが、スライスのために最初に（すなわち、ｒｅｆ＿ｐｉｃ＿ｌｉｓｔ＿ｒｅｏｒｄｅｒｉｎｇ（）シンタックスにおける、０または１に等しいｍｖｃ＿ｒｅｏｒｄｅｒｉｎｇ＿ｏｆ＿ｐｉｃ＿ｎｕｍｓ＿ｉｄｃの最初の発生のために）起動される場合、ｖｉｅｗＩｄＬ０ＰｒｅｄおよびｖｉｅｗＩｄＬ１Ｐｒｅｄは最初、ＣｕｒｒＶｉｅｗＩｄに等しく設定される。ｖｉｅｗＩｄＬＸの各割り当ての後、ｖｉｅｗＩｄＬＸの値が、ｖｉｅｗＩｄＬＸＰｒｅｄに割り当てられる。

ｐｉｃＮｕｍＬＸＰｒｅｄは、変数ｐｉｃＮｕｍＬＸＮｏＷｒａｐについての予測値である。この従属節で規定されるプロセスが、スライスのために最初に（すなわち、ｒｅｆ＿ｐｉｃ＿ｌｉｓｔ＿ｒｅｏｒｄｅｒｉｎｇ（）シンタックスにおける、０または１に等しいｍｖｃ＿ｒｅｏｒｄｅｒｉｎｇ＿ｏｆ＿ｐｉｃ＿ｎｕｍｓ＿ｉｄｃの最初の発生のために）起動される場合、ｐｉｃＮｕｍＬ０ＰｒｅｄおよびｐｉｃＮｕｍＬ１Ｐｒｅｄは最初、ＣｕｒｒＶｉｅｗＩｄに等しく設定される。ｐｉｃＮｕｍＬＸＮｏＷｒａｐの各割り当ての後、ｐｉｃＮｕｍＬＸＮｏＷｒａｐの値が、ｐｉｃＮｕｍＬＸＰｒｅｄに割り当てられる。

変数ｐｉｃＮｕｍＬＸは、以下のようにして導き出される。
ｉｆ（ｐｉｃＮｕｍＬＸＮｏＷｒａｐ＞ＣｕｒｒＰｉｃＮｕｍ）
ｐｉｃＮｕｍＬＸ＝ｐｉｃＮｕｍＬＸＮｏＷｒａｐ−ＭａｘＰｉｃＮｕｍ
ｅｌｓｅ
ｐｉｃＮｕｍＬＸ＝ｐｉｃＮｕｍＬＸＮｏＷｒａｐ

ｐｉｃＮｕｍＬＸおよびｖｉｅｗＩｄＬＸは、「ｕｓｅｄｆｏｒｓｈｏｒｔ−ｔｅｒｍｒｅｆｅｒｅｎｃｅ（短期参照に使用される）」として標識づけされた参照ピクチャのＰｉｃＮｕｍおよびｖｉｅｗＩｄに等しく、「ｎｏｎ−ｅｘｉｓｔｉｎｇ（存在しない）」として標識づけされた短期参照ピクチャのＰｉｃＮｕｍには等しくない。

以下の手順は、ｖｉｅｗＩｄＬＸに等しいｖｉｅｗ＿ｉｄを有し、短期ピクチャ番号ｐｉｃＮｕｍＬＸを有するピクチャを、インデックス位置ｒｅｆＩｄｘＬＸに配置し、他の残りのピクチャの位置をリストの後方にシフトし、ｒｅｆＩｄｘＬＸの値をインクリメントするために実行される。
ｆｏｒ（ｃＩｄｘ＝ｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌＸ＿ａｃｔｉｖｅ＿ｍｉｎｕｓ１＋１；ｃＩｄｘ＞ｒｅｆＩｄｘＬＸ；ｃＩｄｘ−−）
ＲｅｆＰｉｃＬｉｓｔＸ［ｃＩｄｘ］＝ＲｅｆＰｉｃＬｉｓｔＸ［ｃＩｄｘ−１］
ＲｅｆＰｉｃＬｉｓｔＸ［ｒｅｆＩｄｘＬＸ＋＋］＝ＰｉｃＮｕｍがｐｉｃＮｕｍＬＸに等しく、ｖｉｅｗ＿ｉｄがｒｅｆＩｄｘＬＸに等しい、短期参照ピクチャ
ｎＩｄｘ＝ｒｅｆＩｄｘＬＸ
ｆｏｒ（ｃＩｄｘ＝ｒｅｆＩｄｘＬＸ；ｃＩｄｘ＜＝ｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌＸ＿ａｃｔｉｖｅ＿ｍｉｎｕｓ１＋１；ｃＩｄｘ＋＋）
ｉｆ（（ＰｉｃＮｕｍＦ（ＲｅｆＰｉｃＬｉｓｔＸ［ｃＩｄｘ］）！＝ｐｉｃＮｕｍＬＸ）＆＆ＶｉｅｗＩｄＦ（ＲｅｆＰｉｃＬｉｓｔＸ［ｃＩｄｘ］）！＝ｖｉｅｗＩｄＬＸ）
ＲｅｆＰｉｃＬｉｓｔＸ［ｎＩｄｘ＋＋］＝ＲｅｆＰｉｃＬｉｓｔＸ［ｃＩｄｘ］

関数ＰｉｃＮｕｍＦ（ＲｅｆＰｉｃＬｉｓｔＸ［ｃＩｄｘ］）は、以下のようにして導き出される。
− ピクチャＲｅｆＰｉｃＬｉｓｔＸ［ｃＩｄｘ］が「ｕｓｅｄｆｏｒｓｈｏｒｔ−ｔｅｒｍｒｅｆｅｒｅｎｃｅ（短期参照に使用される）」として標識づけされている場合、ＰｉｃＮｕｍＦ（ＲｅｆＰｉｃＬｉｓｔＸ［ｃＩｄｘ］）は、ピクチャＲｅｆＰｉｃＬｉｓｔＸ［ｃＩｄｘ］のＰｉｃＮｕｍである。
− それ以外の（ピクチャＲｅｆＰｉｃＬｉｓｔＸ［ｃＩｄｘ］が「ｕｓｅｄｆｏｒｓｈｏｒｔ−ｔｅｒｍｒｅｆｅｒｅｎｃｅ」として標識づけされていない）場合、ＰｉｃＮｕｍＦ（ＲｅｆＰｉｃＬｉｓｔＸ［ｃＩｄｘ］）は、ＭａｘＰｉｃＮｕｍに等しい。

ＭａｘＰｉｃＮｕｍの値は、決してｐｉｃＮｕｍＬＸに等しくなり得ないことに留意されたい。

関数ＶｉｅｗＩｄＦ（ＲｅｆＰｉｃＬｉｓｔＸ［ｃＩｄｘ］）は、以下のようにして導き出される。
− ＶｉｅｗＩｄＦ（ＲｅｆＰｉｃＬｉｓｔＸ［ｃＩｄｘ］）は、ピクチャＲｅｆＰｉｃＬｉｓｔＸ［ｃＩｄｘ］のＶｉｅｗＩｄである。

この疑似コード手順内では、リストＲｅｆＰｉｃＬｉｓｔＸの長さは一時的に、最終リストのために必要とされる長さよりも１要素分だけ長くされていることにも留意されたい。この手順の実行後は、リストの要素０からｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌＸ＿ａｃｔｉｖｅ＿ｍｉｎｕｓ１までだけが、保持される必要がある。

長期参照ピクチャを含む参照ピクチャ・リストの並べ替えのため、以下が提案される。
このプロセスへの入力は、インデックスｒｅｆＩｄｘＬＸ（Ｘは０または１）である。
このプロセスの出力は、インクリメントされたインデックスｒｅｆＩｄｘＬＸである。

以下の手順は、上で導き出されたｖｉｅｗＩｄＬＸによって指示されるビュー内に存在する、長期ピクチャ番号ｌｏｎｇ＿ｔｅｒｍ＿ｐｉｃ＿ｎｕｍを有するピクチャを、インデックス位置ｒｅｆＩｄｘＬＸに配置し、他の残りのピクチャの位置をリストの後方にシフトし、ｒｅｆＩｄｘＬＸの値をインクリメントするために実行される。
ｆｏｒ（ｃＩｄｘ＝ｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌＸ＿ａｃｔｉｖｅ＿ｍｉｎｕｓ１＋１；ｃＩｄｘ＞ｒｅｆＩｄｘＬＸ；ｃＩｄｘ−−）
ＲｅｆＰｉｃＬｉｓｔＸ［ｃＩｄｘ］＝ＲｅｆＰｉｃＬｉｓｔＸ［ｃＩｄｘ−１］
ＲｅｆＰｉｃＬｉｓｔＸ［ｒｅｆＩｄｘＬＸ＋＋］＝ＬｏｎｇＴｅｒｍＰｉｃＮｕｍがｌｏｎｇ＿ｔｅｒｍ＿ｐｉｃ＿ｎｕｍに等しく、ｖｉｅｗＩｄがｒｅｆＩｄｘＬＸに等しい、長期参照ピクチャ
ｎＩｄｘ＝ｒｅｆＩｄｘＬＸ
ｆｏｒ（ｃＩｄｘ＝ｒｅｆＩｄｘＬＸ；ｃＩｄｘ＜＝ｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌＸ＿ａｃｔｉｖｅ＿ｍｉｎｕｓ１＋１；ｃＩｄｘ＋＋）
ｉｆ（（ＬｏｎｇＴｅｒｍＰｉｃＮｕｍＦ（ＲｅｆＰｉｃＬｉｓｔＸ［ｃＩｄｘ］）！＝ｌｏｎｇ＿ｔｅｒｍ＿ｐｉｃ＿ｎｕｍ）＆＆ＶｉｅｗＩｄＦ（ＲｅｆＰｉｃＬｉｓｔＸ［ｃＩｄｘ］）！＝ｖｉｅｗＩｄＬＸ）
ＲｅｆＰｉｃＬｉｓｔＸ［ｎＩｄｘ＋＋］＝ＲｅｆＰｉｃＬｉｓｔＸ［ｃＩｄｘ］

関数ＬｏｎｇＴｅｒｍＰｉｃＮｕｍＦ（ＲｅｆＰｉｃＬｉｓｔＸ［ｃＩｄｘ］）は、以下のようにして導き出される。
− ピクチャＲｅｆＰｉｃＬｉｓｔＸ［ｃＩｄｘ］が「ｕｓｅｄｆｏｒｌｏｎｇ−ｔｅｒｍｒｅｆｅｒｅｎｃｅ」として標識づけされている場合、ＬｏｎｇＴｅｒｍＰｉｃＮｕｍＦ（ＲｅｆＰｉｃＬｉｓｔＸ［ｃＩｄｘ］）は、ピクチャＲｅｆＰｉｃＬｉｓｔＸ［ｃＩｄｘ］のＬｏｎｇＴｅｒｍＰｉｃＮｕｍである。
− それ以外の（ピクチャＲｅｆＰｉｃＬｉｓｔＸ［ｃＩｄｘ］が「ｕｓｅｄｆｏｒｌｏｎｇ−ｔｅｒｍｒｅｆｅｒｅｎｃｅ」として標識づけされていない）場合、ＬｏｎｇＴｅｒｍＰｉｃＮｕｍＦ（ＲｅｆＰｉｃＬｉｓｔＸ［ｃＩｄｘ］）は、２×（ＭａｘＬｏｎｇＴｅｒｍＦｒａｍｅＩｄｘ＋１）に等しい。

２×（ＭａｘＬｏｎｇＴｅｒｍＦｒａｍｅＩｄｘ＋１）の値は、決してｌｏｎｇ＿ｔｅｒｍ＿ｐｉｃ＿ｎｕｍに等しくなり得ないことに留意されたい。

関数ＶｉｅｗＩｄＦ（ＲｅｆＰｉｃＬｉｓｔＸ［ｃＩｄｘ］）は、以下のようにして導き出される。
− ピクチャＲｅｆＰｉｃＬｉｓｔＸ［ｃＩｄｘ］が「ｕｓｅｄｆｏｒｓｈｏｒｔ−ｔｅｒｍｒｅｆｅｒｅｎｃｅ」として標識づけされている場合、ＶｉｅｗＩｄＦ（ＲｅｆＰｉｃＬｉｓｔＸ［ｃＩｄｘ］）は、ピクチャＲｅｆＰｉｃＬｉｓｔＸ［ｃＩｄｘ］のＶｉｅｗＩｄである。
− それ以外の（ピクチャＲｅｆＰｉｃＬｉｓｔＸ［ｃＩｄｘ］が「ｕｓｅｄｆｏｒｓｈｏｒｔ−ｔｅｒｍｒｅｆｅｒｅｎｃｅ」として標識づけされていない）場合、ＰｉｃＮｕｍＦ（ＲｅｆＰｉｃＬｉｓｔＸ［ｃＩｄｘ］）は、ＭａｘＰｉｃＮｕｍに等しい。

ＭａｘＰｉｃＮｕｍの値は、決してｐｉｃＮｕｍＬＸに等しくなり得ないこと、および
この疑似コード手順内では、リストＲｅｆＰｉｃＬｉｓｔＸの長さは一時的に、最終リストのために必要とされる長さよりも１要素分だけ長くされていることにも留意されたい。この手順の実行後は、リストの要素０からｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌＸ＿ａｃｔｉｖｅ＿ｍｉｎｕｓ１までだけが、保持される必要がある。

本発明の原理のための追加のフレームワークが、図６に示されるシンタックス要素ｒｅｆ＿ｐｉｃ＿ｒｅｏｒｄｅｒｉｎｇ＿ｍｖｃ＿ｅｘｔｅｎｓｉｏｎ（）のため、以下で開示され、説明される。このシンタックス要素の動作と図５に関して説明されたシンタックス要素の間の１つの相違は、並べ替えリストが、どのビューについても完成され得ること、およびそのような並べ替えが、（図３に示されるような）別個のｒｅｆ＿ｐｉｃ＿ｌｉｓｔ＿ｒｅｏｒｄｅｒｉｎｇコマンドを呼び出さなければならない代わりに、ただ１つの呼び出しを使用することによって実行されることである。

この代替フレームワーク下の第１の実施形態のため、変数ｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ０＿ａｃｔｉｖｅ＿ｍｉｎｕｓ１およびｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ１＿ａｃｔｉｖｅ＿ｍｉｎｕｓ１が、時間的な意味でアクティブな参照ピクチャの数を表すために、再び再定義される（これらの変数について説明している先のセクションを参照されたい）。

この実施形態は、クロスビューにおけるアクティブなピクチャの数を示すために使用される、変数ｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ０＿ａｃｔｉｖｅ＿ｖｉｅｗおよびｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ１＿ａｃｔｉｖｅ＿ｖｉｅｗを定義する。

ｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ０＿ａｃｔｉｖｅ＿ｖｉｅｗは、スライスを復号するために使用される、クロスビュー参照ピクチャ・リスト０の最大参照インデックスを規定する。ｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ０＿ａｃｔｉｖｅ＿ｖｉｅｗの範囲は、以下のように規定される。
− ｆｉｅｌｄ＿ｐｉｃ＿ｆｌａｇが０に等しい場合、ｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ０＿ａｃｔｉｖｅ＿ｖｉｅｗは、０以上１６以下の範囲内にある。ＭｂａｆｆＦｒａｍｅＦｌａｇが１に等しい場合、ｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ０＿ａｃｔｉｖｅ＿ｖｉｅｗは、フレーム・マクロブロックの復号のための最大インデックス値であり、２×ｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ０＿ａｃｔｉｖｅ＿ｖｉｅｗは、フィールド・マクロブロックの復号のための最大インデックス値である。
− それ以外の（ｆｉｅｌｄ＿ｐｉｃ＿ｆｌａｇが１に等しい）場合、ｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ０＿ａｃｔｉｖｅ＿ｖｉｅｗは、０以上３２以下の範囲内にある。

ｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ１＿ａｃｔｉｖｅ＿ｖｉｅｗは、ｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ０＿ａｃｔｉｖｅ＿ｖｉｅｗと同じセマンティクスを有するが、ｌ０およびリスト０は、それぞれｌ１およびリスト１によって置き換えられる。

これらのシンタックスは、以下の式を満足するような値を有する。
ｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ０＿ａｃｔｉｖｅ＿ｍｉｎｕｓ１＋ｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ０＿ａｃｔｉｖｅ＿ｖｉｅｗ＜＝ｎｕｍ＿ｒｅｆ＿ｆｒａｍｅｓ
かつ
ｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ１＿ａｃｔｉｖｅ＿ｍｉｎｕｓ１＋ｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ１＿ａｃｔｉｖｅ＿ｖｉｅｗ＜＝ｎｕｍ＿ｒｅｆ＿ｆｒａｍｅｓ

以下で言及されるように、ＭＶＣシステムのためのデフォルト初期化プロセスが明確に定義される必要がある。

第１に、現ビューのすべての時間的ピクチャが、ＭＰＥＧ−４ＡＶＣ仕様において定義されるように初期化される。これは、短期および長期参照を含む。このリストは、その後、ＬＩＳＴ＿０およびＬＩＳＴ＿１のために、それぞれｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ０＿ａｃｔｉｖｅ＿ｍｉｎｕｓ１およびｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ１＿ａｃｔｉｖｅ＿ｍｉｎｕｓ１で規定される値によって切り詰められる。

これらのピクチャに続いて、ＭＶＣ仕様のＳＰＳにおいて規定されるクロスビュー参照ピクチャが挿入され、ＬＩＳＴ＿０およびＬＩＳＴ＿１のために、それぞれｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ０＿ａｃｔｉｖｅ＿ｖｉｅｗおよびｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ１＿ａｃｔｉｖｅ＿ｖｉｅｗで規定される値によって切り詰められる。

既存のＨ．２６４／ＭＰＥＧ−４ＡＶＣＲＰＬＲコマンドに類似した、新しいＲＰＬＲコマンドが導入される。これらのコマンドは、Ｈ．２６４／ＭＰＥＧ−４ＡＶＣの既存のＲＰＬＲコマンドに取って代わる（図６を参照）。

新しいＲＰＬＲコマンドは、以下のセマンティクスを有する。並べ替えコマンドが存在するか、それとも存在しないかを示すコマンドが、上掲の表１に示されている。

シンタックス要素ｍｖｃ＿ｒｅｏｒｄｅｒｉｎｇ＿ｏｆ＿ｐｉｃ＿ｎｕｍｓ＿ｉｄｃ、ａｂｓ＿ｄｉｆｆ＿ｐｉｃ＿ｎｕｍ＿ｍｉｎｕｓ１、およびｌｏｎｇ＿ｔｅｒｍ＿ｐｉｃ＿ｎｕｍは、初期参照ピクチャ・リストから、（スライスなど）ピクチャ情報を復号するために使用される参照ピクチャ・リストへの変更を指定する。

ｍｖｃ＿ｒｅｆ＿ｐｉｃ＿ｌｉｓｔ＿ｒｅｏｒｄｅｒｉｎｇ＿ｆｌａｇ＿ｌ０が１に等しい場合、ｍｖｃ＿ｒｅｆ＿ｐｉｃ＿ｌｉｓｔ＿ｒｅｏｒｄｅｒｉｎｇ＿ｆｌａｇ＿ｌ０の後に続いて、ｍｖｃ＿ｒｅｏｒｄｅｒｉｎｇ＿ｏｆ＿ｐｉｃ＿ｎｕｍｓ＿ｉｄｃが３に等しくない回数は、ｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ０＿ａｃｔｉｖｅ＿ｍｉｎｕｓ１＋１＋ｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ０＿ａｃｔｉｖｅ＿ｖｉｅｗを超えない。

Ｈ．２６４／ＭＰＥＧ−４ＡＶＣ仕様で規定されるように生成された初期参照ピクチャ・リスト内のＲｅｆＰｉｃＬｉｓｔ０［ｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ０＿ａｃｔｉｖｅ＿ｍｉｎｕｓ１＋ｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ０＿ａｃｔｉｖｅ＿ｖｉｅｗ］が「ｎｏｒｅｆｅｒｅｎｃｅｐｉｃｔｕｒｅ」に等しい場合、Ｈ．２６４／ＭＰＥＧ−４ＡＶＣ仕様で規定されるように生成された並べ替えリスト内のＲｅｆＰｉｃＬｉｓｔ０［ｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ０＿ａｃｔｉｖｅ＿ｍｉｎｕｓ１＋ｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ０＿ａｃｔｉｖｅ＿ｖｉｅｗ］が「ｎｏｒｅｆｅｒｅｎｃｅｐｉｃｔｕｒｅ」に等しくなくなるまで、ｍｖｃ＿ｒｅｆ＿ｐｉｃ＿ｌｉｓｔ＿ｒｅｏｒｄｅｒｉｎｇ＿ｆｌａｇ＿ｌ０は１に等しく、ｍｖｃ＿ｒｅｏｒｄｅｒｉｎｇ＿ｏｆ＿ｐｉｃ＿ｎｕｍｓ＿ｉｄｃは３に等しくない。

１に等しいｍｖｃ＿ｒｅｆ＿ｐｉｃ＿ｌｉｓｔ＿ｒｅｏｒｄｅｒｉｎｇ＿ｆｌａｇ＿ｌ１は、シンタックス要素ｍｖｃ＿ｒｅｏｒｄｅｒｉｎｇ＿ｏｆ＿ｐｉｃ＿ｎｕｍｓ＿ｉｄｃが、参照ピクチャ・リスト１を指定するために存在することを指定する。

０に等しいｍｖｃ＿ｒｅｆ＿ｐｉｃ＿ｌｉｓｔ＿ｒｅｏｒｄｅｒｉｎｇ＿ｆｌａｇ＿ｌ１は、このシンタックス要素が存在しないことを指定する。

ｍｖｃ＿ｒｅｆ＿ｐｉｃ＿ｌｉｓｔ＿ｒｅｏｒｄｅｒｉｎｇ＿ｆｌａｇ＿ｌ１が１に等しい場合、ｍｖｃ＿ｒｅｆ＿ｐｉｃ＿ｌｉｓｔ＿ｒｅｏｒｄｅｒｉｎｇ＿ｆｌａｇ＿ｌ１の後に続いて、ｍｖｃ＿ｒｅｏｒｄｅｒｉｎｇ＿ｏｆ＿ｐｉｃ＿ｎｕｍｓ＿ｉｄｃが３に等しくない回数は、ｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ１＿ａｃｔｉｖｅ＿ｍｉｎｕｓ１＋１＋ｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ１＿ａｃｔｉｖｅ＿ｖｉｅｗを超えない。

Ｂスライスを復号する際、Ｈ．２６４／ＭＰＥＧ−４ＡＶＣ仕様で規定されるように生成された初期参照ピクチャ・リスト内のＲｅｆＰｉｃＬｉｓｔ１［ｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ１＿ａｃｔｉｖｅ＿ｍｉｎｕｓ１＋ｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ１＿ａｃｔｉｖｅ＿ｖｉｅｗ］が「ｎｏｒｅｆｅｒｅｎｃｅｐｉｃｔｕｒｅ」に等しい場合、Ｈ．２６４／ＭＰＥＧ−４ＡＶＣ仕様で規定されるように生成された並べ替えリスト内のＲｅｆＰｉｃＬｉｓｔ１［ｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ１＿ａｃｔｉｖｅ＿ｍｉｎｕｓ１＋ｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌ１＿ａｃｔｉｖｅ＿ｖｉｅｗ］が「ｎｏｒｅｆｅｒｅｎｃｅｐｉｃｔｕｒｅ」に等しくなくなるまで、ｍｖｃ＿ｒｅｆ＿ｐｉｃ＿ｌｉｓｔ＿ｒｅｏｒｄｅｒｉｎｇ＿ｆｌａｇ＿ｌ１は１に等しく、ｍｖｃ＿ｒｅｏｒｄｅｒｉｎｇ＿ｏｆ＿ｐｉｃ＿ｎｕｍｓ＿ｉｄｃは３に等しくない。

ａｂｓ＿ｄｉｆｆ＿ｐｉｃ＿ｎｕｍ＿ｍｉｎｕｓ１プラス１は、リスト内の現インデックスに移動されるピクチャのピクチャ番号とピクチャ番号予測値の間の絶対差を指定する。ａｂｓ＿ｄｉｆｆ＿ｐｉｃ＿ｎｕｍ＿ｍｉｎｕｓ１は、０からＭａｘＰｉｃＮｕｍ−１までの範囲内にある。

ｌｏｎｇ＿ｔｅｒｍ＿ｐｉｃ＿ｎｕｍは、リスト内の現インデックスに移動されるピクチャの長期ピクチャ番号を指定する。コーディング・フレームを復号する場合、ｌｏｎｇ＿ｔｅｒｍ＿ｐｉｃ＿ｎｕｍは、参照フレームの１つまたは「ｕｓｅｄｆｏｒｌｏｎｇ−ｔｅｒｍｒｅｆｅｒｅｎｃｅ」として標識づけされた相補的参照フィールド対の１つに割り当てられたＬｏｎｇＴｅｒｍＰｉｃＮｕｍに等しい。コーディング・フィールドを復号する場合、ｌｏｎｇ＿ｔｅｒｍ＿ｐｉｃ＿ｎｕｍは、「ｕｓｅｄｆｏｒｌｏｎｇ−ｔｅｒｍｒｅｆｅｒｅｎｃｅ」として標識づけされた参照フィールドの１つに割り当てられたＬｏｎｇＴｅｒｍＰｉｃＮｕｍに等しい。

短期参照ピクチャ用の参照ピクチャ・リストを並べ替えるためのスキームが以下で説明される。
このプロセスへの入力は、インデックスｒｅｆＩｄｘＬＸ（Ｘは０または１）である。
このプロセスの出力は、インクリメントされたインデックスｒｅｆＩｄｘＬＸである。
ｖｉｅｗＩｄＬＸ＝ｖｉｅｗＩｄＬＸＰｒｅｄ＋ｄｉｆｆｅｒｅｎｃｅ＿ｏｆ＿ｖｉｅｗ＿ｉｄ

ｐｉｃＮｕｍＬＸＮｏＷｒａｐは、以下のようにして導き出される。
ｍｖｃ＿ｒｅｏｒｄｅｒｉｎｇ＿ｏｆ＿ｐｉｃ＿ｎｕｍｓ＿ｉｄｃが０に等しい場合、
ｉｆ（ｐｉｃＮｕｍＬＸＰｒｅｄ−（ａｂｓ＿ｄｉｆｆ＿ｐｉｃ＿ｎｕｍ＿ｍｉｎｕｓ１＋１）＜０）
ｐｉｃＮｕｍＬＸＮｏＷｒａｐ＝ｐｉｃＮｕｍＬＸＰｒｅｄ−（ａｂｓ＿ｄｉｆｆ＿ｐｉｃ＿ｎｕｍ＿ｍｉｎｕｓ１＋１）＋ＭａｘＰｉｃＮｕｍ
ｅｌｓｅ
ｐｉｃＮｕｍＬＸＮｏＷｒａｐ＝ｐｉｃＮｕｍＬＸＰｒｅｄ−（ａｂｓ＿ｄｉｆｆ＿ｐｉｃ＿ｎｕｍ＿ｍｉｎｕｓ１＋１）
それ以外の（ｍｖｃ＿ｒｅｏｒｄｅｒｉｎｇ＿ｏｆ＿ｐｉｃ＿ｎｕｍｓ＿ｉｄｃが１に等しい）場合、
ｉｆ（ｐｉｃＮｕｍＬＸＰｒｅｄ＋（ａｂｓ＿ｄｉｆｆ＿ｐｉｃ＿ｎｕｍ＿ｍｉｎｕｓ１＋１）＞＝ＭａｘＰｉｃＮｕｍ）
ｐｉｃＮｕｍＬＸＮｏＷｒａｐ＝ｐｉｃＮｕｍＬＸＰｒｅｄ＋（ａｂｓ＿ｄｉｆｆ＿ｐｉｃ＿ｎｕｍ＿ｍｉｎｕｓ１＋１）−ＭａｘＰｉｃＮｕｍ
ｅｌｓｅ
ｐｉｃＮｕｍＬＸＮｏＷｒａｐ＝ｐｉｃＮｕｍＬＸＰｒｅｄ＋（ａｂｓ＿ｄｉｆｆ＿ｐｉｃ＿ｎｕｍ＿ｍｉｎｕｓ１＋１）

ｐｉｃＮｕｍＬＸは、以下のようにして導き出される。
ｉｆ（ｐｉｃＮｕｍＬＸＮｏＷｒａｐ＞ＣｕｒｒＰｉｃＮｕｍ）
ｐｉｃＮｕｍＬＸ＝ｐｉｃＮｕｍＬＸＮｏＷｒａｐ−ＭａｘＰｉｃＮｕｍ
ｅｌｓｅ
ｐｉｃＮｕｍＬＸ＝ｐｉｃＮｕｍＬＸＮｏＷｒａｐ

ｐｉｃＮｕｍＬＸおよびｖｉｅｗＩｄＬＸは、「ｕｓｅｄｆｏｒｓｈｏｒｔ−ｔｅｒｍｒｅｆｅｒｅｎｃｅ」として標識づけされた参照ピクチャのＰｉｃＮｕｍおよびｖｉｅｗＩｄに等しく、「ｎｏｎ−ｅｘｉｓｔｉｎｇ」として標識づけされた短期参照ピクチャのＰｉｃＮｕｍには等しくない。

以下の手順は、ｖｉｅｗＩｄＬＸに等しいｖｉｅｗ＿ｉｄを有し、短期ピクチャ番号ｐｉｃＮｕｍＬＸを有するピクチャを、インデックス位置ｒｅｆＩｄｘＬＸに配置し、他の残りのピクチャの位置をリストの後方にシフトし、ｒｅｆＩｄｘＬＸの値をインクリメントするために実行される。
ｆｏｒ（ｃＩｄｘ＝ｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌＸ＿ａｃｔｉｖｅ＿ｍｉｎｕｓ１＋１；ｃＩｄｘ＞ｒｅｆＩｄｘＬＸ；ｃＩｄｘ−−）
ＲｅｆＰｉｃＬｉｓｔＸ［ｃＩｄｘ］＝ＲｅｆＰｉｃＬｉｓｔＸ［ｃＩｄｘ−１］
ＲｅｆＰｉｃＬｉｓｔＸ［ｒｅｆＩｄｘＬＸ＋＋］＝ＰｉｃＮｕｍがｐｉｃＮｕｍＬＸに等しく、ｖｉｅｗ＿ｉｄがｖｉｅｗＩｄｘＬＸに等しい、短期参照ピクチャ
ｎＩｄｘ＝ｒｅｆＩｄｘＬＸ
ｆｏｒ（ｃＩｄｘ＝ｒｅｆＩｄｘＬＸ；ｃＩｄｘ＜＝ｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌＸ＿ａｃｔｉｖｅ＿ｍｉｎｕｓ１＋１；ｃＩｄｘ＋＋）
ｉｆ（（ＰｉｃＮｕｍＦ（ＲｅｆＰｉｃＬｉｓｔＸ［ｃＩｄｘ］）！＝ｐｉｃＮｕｍＬＸ）＆＆ＶｉｅｗＩｄＦ（ＲｅｆＰｉｃＬｉｓｔＸ［ｃＩｄｘ］）！＝ｖｉｅｗＩｄＬＸ）
ＲｅｆＰｉｃＬｉｓｔＸ［ｎＩｄｘ＋＋］＝ＲｅｆＰｉｃＬｉｓｔＸ［ｃＩｄｘ］

関数ＰｉｃＮｕｍＦ（ＲｅｆＰｉｃＬｉｓｔＸ［ｃＩｄｘ］）は、以下のようにして導き出される。
ピクチャＲｅｆＰｉｃＬｉｓｔＸ［ｃＩｄｘ］が「ｕｓｅｄｆｏｒｓｈｏｒｔ−ｔｅｒｍｒｅｆｅｒｅｎｃｅ」として標識づけされている場合、ＰｉｃＮｕｍＦ（ＲｅｆＰｉｃＬｉｓｔＸ［ｃＩｄｘ］）は、ピクチャＲｅｆＰｉｃＬｉｓｔＸ［ｃＩｄｘ］のＰｉｃＮｕｍである。
それ以外の（ピクチャＲｅｆＰｉｃＬｉｓｔＸ［ｃＩｄｘ］が「ｕｓｅｄｆｏｒｓｈｏｒｔ−ｔｅｒｍｒｅｆｅｒｅｎｃｅ」として標識づけされていない）場合、ＰｉｃＮｕｍＦ（ＲｅｆＰｉｃＬｉｓｔＸ［ｃＩｄｘ］）は、ＭａｘＰｉｃＮｕｍに等しい。

関数ＶｉｅｗＩｄＦ（ＲｅｆＰｉｃＬｉｓｔＸ［ｃＩｄｘ］）は、以下のようにして導き出される。
ＶｉｅｗＩｄＦ（ＲｅｆＰｉｃＬｉｓｔＸ［ｃＩｄｘ］）は、ピクチャＲｅｆＰｉｃＬｉｓｔＸ［ｃＩｄｘ］のｖｉｅｗＩｄである。

この疑似コード手順内では、リストＲｅｆＰｉｃＬｉｓｔＸの長さは一時的に、最終リストのために必要とされる長さよりも１要素分だけ長くされている。この手順の実行後は、リストの要素０からｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌＸ＿ａｃｔｉｖｅ＿ｍｉｎｕｓ１までだけが、保持される必要がある。

長期参照ピクチャ用の参照ピクチャ・リストを並べ替えるためのスキームが以下で説明される。
このプロセスへの入力は、インデックスｒｅｆＩｄｘＬＸ（Ｘは０または１）である。
このプロセスの出力は、インクリメントされたインデックスｒｅｆＩｄｘＬＸである。

注１２×（ＭａｘＬｏｎｇＴｅｒｍＦｒａｍｅＩｄｘ＋１）の値は、決してｌｏｎｇ＿ｔｅｒｍ＿ｐｉｃ＿ｎｕｍに等しくなり得ない。

ＭａｘＰｉｃＮｕｍの値は、決してｐｉｃＮｕｍＬＸに等しくなり得ない。

この疑似コード手順内では、リストＲｅｆＰｉｃＬｉｓｔＸの長さは一時的に、最終リストのために必要とされる長さよりも１要素分だけ長くされていることに留意されたい。この手順の実行後は、リストの要素０からｎｕｍ＿ｒｅｆ＿ｉｄｘ＿ｌＸ＿ａｃｔｉｖｅ＿ｍｉｎｕｓ１までだけが、保持される必要がある。

この代替フレームワーク下の本発明の第２の実施形態では、クロスビュー・ピクチャの並べ替えはほとんどの場合、ピクチャ番号の差がゼロであることを意味する、時間的に整列したピクチャに対して生じることを考慮する。したがって、この実施形態は、上述されたものよりも効率的な、クロスビュー・ピクチャを並べ替えるこの態様に焦点を絞る。

この実施形態は、変数ａｂｓ＿ｄｉｆｆ＿ｐｉｃ＿ｎｕｍ＿ｍｉｎｕｓ１をａｂｓ＿ｄｉｆｆ＿ｐｉｃ＿ｎｕｍに変更し、この変数を以下のように定義する。
ａｂｓ＿ｄｉｆｆ＿ｐｉｃ＿ｎｕｍは、リスト内の現インデックスに移動されるピクチャのピクチャ番号とピクチャ番号予測値の間の絶対差を指定する。

ａｂｓ＿ｄｉｆｆ＿ｐｉｃ＿ｎｕｍの範囲は、以下のように指定される。
− ｒｅｏｒｄｅｒｉｎｇ＿ｏｆｐｉｃ＿ｎｕｍｓ＿ｉｄｃが０に等しい場合、ａｂｓ＿ｄｉｆｆ＿ｐｉｃ＿ｎｕｍは、０からＭａｘＰｉｃＮｕｍ／２までの範囲内にある。
− それ以外の（ｒｅｏｒｄｅｒｉｎｇ＿ｏｆｐｉｃ＿ｎｕｍｓ＿ｉｄｃが１に等しい）場合、ａｂｓ＿ｄｉｆｆ＿ｐｉｃ＿ｎｕｍは、０からＭａｘＰｉｃＮｕｍ／２−１までの範囲内にある。

これを行うことによって、ａｂｓ＿ｄｉｆｆ＿ｐｉｃ＿ｎｕｍが、クロスビュー並べ替えのほとんどの場合の値である０を取ることを可能にする。

代替フレームワーク下で第３の実施形態も提案され、それも、クロスビュー・ピクチャの並べ替えはほとんどの場合、ピクチャ番号の差がゼロであることを意味する、時間的に整列したピクチャに対して生じることを考慮するために使用される。

先の方法では、ａｂｓ＿ｄｉｆｆ＿ｐｉｃ＿ｎｕｍは、符号なし指数ゴロム符号としてコーディングされ、したがって、この差が正の差を表すのか、それとも負の差を表すのかを示す追加のシンタックスが、図６に示されるように、ｍｖｃ＿ｒｅｏｒｄｅｒｉｎｇ＿ｏｆ＿ｐｉｃ＿ｎｕｍｓ＿ｉｄｃとして送られる必要がある。

この実施形態は、このシンタックス要素が取り得る値を、表２に示されるように削減し、ＲＰＬＲｒｅｆ＿ｐｉｃ＿ｌｉｓｔ＿ｒｅｏｒｄｅｒｉｎｇ＿ｍｖｃ＿ｅｘｔｅｎｓｉｏｎのための考案された定義を開示する図７に示されるように、ピクチャ番号の差の符号付き指数ゴロム符号を、ｄｉｆｆ＿ｐｉｃ＿ｎｕｍとして送信する。

ｄｉｆｆ＿ｐｉｃ＿ｎｕｍのセマンティクスは、次のように定義される。
ｄｉｆｆ＿ｐｉｃ＿ｎｕｍは、リスト内の現インデックスに移動されるピクチャのピクチャ番号とピクチャ番号予測値の間の差を指定する。

ｄｉｆｆ＿ｐｉｃ＿ｎｕｍの範囲は、以下のように指定される。
− ＭａｘＰｉｃＮｕｍ／２−１からＭａｘＰｉｃＮｕｍ／２

その後、ｐｉｃＮｕｍＬＸＮｏＷｒａｐが、以下のように導き出される。
ｐｉｃＮｕｍＬＸＮｏＷｒａｐ＝ｐｉｃＮｕｍＬＸＰｒｅｄ＋ｄｉｆｆ＿ｐｉｃ＿ｎｕｍ

図７は、多視点コーディング環境のための参照ピクチャの並べ替えに適用されるような、本発明の原理を表す、ブロック図７００を提示している。このフローチャートの動作のためには、参照ピクチャがすでにＤＰＢ２１５内に存在することが仮定される。しかし、参照ピクチャは、異なるビュー用のものでもよい。

ステップ７０５において、方法は、コーディングされる現ピクチャが、多視点ピクチャ（ＭＶＣおよびＡＶＣ）が使用される環境内にあるかどうか、それともコーディング環境が、単に時間的なもの（すなわちＡＶＣ）であるかどうかについて検討する。

現ピクチャのコーディングに関連して使用される参照ピクチャが多視点コーディングとは関係がない場合、ステップ７１０は、ＡＶＣなどのコーディング規格に関連して知られた原理を適用して、参照ピクチャ・リストを並べ替えるように動作する。しかし、コーディングされるピクチャが多視点ピクチャと関係があり、ピクチャ間のクロスビューが考慮されなければならないこともあり得る場合、ステップ７１５が選択される。

上述されたように、ピクチャの並べ替えを実際にどのように実行するかに関して、いくつかの異なる応用が存在する。（ステップ７１５に適用される）上で提示されたいくつかの実施形態は、コーディングされる現ピクチャが参照ピクチャと何らかのクロスビュー関係を有するかどうかについて検討するために比較が行われる、環境について説明する。いくつかの実施形態では、ピクチャ・リストの並べ替えは、すべてのビューに関連する参照ピクチャを並べ替える。他の実施形態では、参照ピクチャの並べ替えは、最初にすべてのクロスビューについて実行され、次に、コーディングされるピクチャと同じビューを有する参照ピクチャについて実行される。

ステップ７２０は、コーディングされるピクチャが、参照ピクチャと時間的関係を有するかどうかについて検討する。上述されたように、Ｐピクチャは、参照リストを１つ使用するが、Ｂピクチャは、２つの参照リストの使用を必要とすることがある。したがって、（本発明の様々な実施形態において説明される）リストが並べ替えられる方法は、そのような時間的関係に依存する。

ステップ７２５は、参照ピクチャ・リストの実際の並べ替えである。そのような操作を実行する様々な方法は、またしても、ステップ７１５およびステップ７２０の結果に依存し、上述された原理および実施形態と併せて適用される。

したがって、例えば、本明細書で提示されるブロック図は、本原理を実施する説明的な回路の概念図を表すことが、当業者であれば理解されよう。同様に、いかなるフローチャート、フロー図、状態遷移図、および疑似コードなども、実際にはコンピュータ可読媒体内で提示され、そのため、コンピュータまたはプロセッサが明示的に示されているかどうかに関わらず、そのようなコンピュータまたはプロセッサによって実行され得る、様々なプロセスを表すことが理解されよう。

図面に示された様々な要素の機能は、専用ハードウェアの使用を通してだけなく、適切なソフトウェアと関連する、ソフトウェアを実行可能なハードウェアの使用を通しても提供することができる。プロセッサによって提供される場合、機能は、単一の専用プロセッサによって、単一の共用プロセッサによって、またはその中のいくつかは共用されてよい複数の個別プロセッサによって提供することができる。さらに、「プロセッサ」または「コントローラ」という用語の明示的な使用は、ソフトウェアを実行可能なハードウェアを排他的に指示すると解釈されるべきではなく、デジタル信号プロセッサ（「ＤＳＰ」）ハードウェア、ソフトウェアを保存するためのリード・オンリ・メモリ（「ＲＯＭ」）、ランダム・アクセス・メモリ（「ＲＡＭ」）、および不揮発性ストレージを、これらに限定することなく、暗黙的に含むことができる。

他の従来のハードウェアおよび／またはカスタム・ハードウェアも含むことができる。同様に、図面に示されたスイッチはいずれも、概念的なものに過ぎない。それらの機能は、プログラム・ロジックの動作を通して、専用ロジックを通して、またはプログラム制御と専用ロジックとの相互作用を通して実施することができ、具体的な技法は、文脈からより具体的に理解されるように、実施者によって選択可能である。

本願の特許請求の範囲では、指定された機能を実行する手段として表された要素はいずれも、例えば、ａ）その機能を実行する回路要素の組合せ、またはｂ）任意の形態のソフトウェアであって、したがって、ファームウェアまたはマイクロコードなどを含み、そのソフトウェアを実行するための適切な回路と組み合わされて当該機能を実行するソフトウェアを含む、その機能を実行する任意の方法を包含することが意図されている。そのような特許請求の範囲によって確定される本原理は、列挙された様々な手段によって提供される機能が、特許請求の範囲が要請する方法で組み合わされ、一緒にされるという事実に存している。したがって、それらの機能を提供できる手段はいずれも、本明細書で示される手段と等価であると見なされる。

本明細書における本原理の「一実施形態」または「実施形態」に対する言及は、その実施形態に関連して説明された特定の機能、構造、および特徴などが、本原理の少なくとも１つの実施形態に含まれることを意味する。したがって、本明細書の様々な場所で見られる「一実施形態では」または「実施形態では」という句の出現は、必ずしもすべてが同一の実施形態に言及しているわけではない。

本原理の上記および他の特徴および利点は、本明細書の教示に基づいて、当業者によって容易に確認できよう。本原理の教示は、ハードウェア、ソフトウェア、ファームウェア、専用プロセッサ、またはそれらの組合せといった様々な形態で実施できることを理解されたい。

最も好ましくは、本原理の教示は、ハードウェアとソフトウェアの組合せとして実施される。さらに、ソフトウェアは、プログラム記憶ユニット上で有形に実施されるアプリケーション・プログラムとして実施されてよい。アプリケーション・プログラムは、任意の適切なアーキテクチャを備えるマシンによって、アップロードされ、実行されてよい。好ましくは、マシンは、１つまたは複数の中央処理装置（「ＣＰＵ」）、ランダム・アクセス・メモリ（「ＲＡＭ」）、および入出力（「Ｉ／Ｏ」）インタフェースなどのハードウェアを有する、コンピュータ・プラットフォーム上で実施される。コンピュータ・プラットフォームは、オペレーティング・システムおよびマイクロ命令コードも含んでよい。本明細書で説明された様々なプロセスおよび関数は、ＣＰＵによって実行され得る、マイクロ命令コードの部分もしくはアプリケーション・プログラムの部分、またはそれらの任意の組合せとすることができる。加えて、追加のデータ記憶ユニットおよび印刷ユニットなど、他の様々な周辺ユニットが、コンピュータ・プラットフォームに接続されてよい。

添付の図面に示される構成要素システム・コンポーネントおよび方法のいくつかは、好ましくはソフトウェアで実施されるので、システム・コンポーネントまたはプロセス機能ブロックの間の実際の接続は、本原理がプログラムされる方法に応じて異なり得ることをさらに理解されたい。本明細書の教示を与えれば、当業者は、本原理の上記および類似の実施または構成を企図することができる。

説明的な実施形態が、添付の図面を参照しながら本明細書で説明されたが、本原理は、それらの実施形態そのままに限定されず、本原理の範囲または主旨から逸脱することなく、当業者によって、それらの実施形態に様々な変更および修正が施され得ることを理解されたい。そのような変更および修正のすべては、添付の特許請求の範囲において説明される本原理の範囲内に含まれることが意図されている。

Claims

ピクチャに対するコーディング操作のための参照ピクチャ・リストの順序づけのための方法であって、
コーディングされるピクチャがビューに関連するかどうかを判定するステップ（７１５）と、
コーディングされる前記ピクチャのビューを考慮して、参照ピクチャ・リスト内の少なくとも１つの保存参照ピクチャのコーディング順序を順序づけるステップ（７２５）と、
を含む、前記方法。
前記順序づけるステップが、コーディングされる前記ピクチャの前記ビューが、前記少なくとも１つの参照ピクチャに関連するビューと同じビューであるかどうかについて考慮する、請求項１に記載の方法。
前記順序づけるステップが、コーディングされる前記ピクチャの前記ビューと異なるビューを有する参照ピクチャの並べ替えとは異なる時間に、コーディングされる前記ピクチャと同じビューを有する参照ピクチャを順序づける、請求項２に記載の方法。
前記順序づけるステップが、どのビューの参照ピクチャも順序づける、請求項２に記載の方法。
前記順序づけるステップが、前記少なくとも１つの保存参照ピクチャからの前記少なくとも２つのピクチャのコーディング順序の並べ替えであり、前記コーディング順序が、前記ピクチャをコーディングするために使用される、請求項１〜４のいずれか一項に記載の方法。
コーディングされる前記ピクチャがＰピクチャである場合は、１つの参照ピクチャ・リストが使用され、コーディングされる前記ピクチャがＢピクチャである場合は、２つの参照ピクチャ・リストが使用される、請求項１〜５のいずれか一項に記載の方法。
コーディングされる前記ピクチャが、前記リストで規定される参照ピクチャの順序を使用することによってコーディングされる、請求項１〜５のいずれか一項に記載の方法。