特許 5778339 ビデオコーディングにおける内部ビット深度増加

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5778339

(24)【登録日】2015年7月17日

(45)【発行日】2015年9月16日

(54)【発明の名称】ビデオコーディングにおける内部ビット深度増加

(51)【国際特許分類】

   H04N 19/159 20140101AFI20150827BHJP

   H04N 19/172 20140101ALI20150827BHJP

   H04N 19/426 20140101ALI20150827BHJP

【ＦＩ】

   H04N19/159

   H04N19/172

   H04N19/426

【請求項の数】38

【全頁数】44

(21)【出願番号】特願2014-514885(P2014-514885)

(86)(22)【出願日】2012年6月8日

(65)【公表番号】特表2014-517631(P2014-517631A)

(43)【公表日】2014年7月17日

(86)【国際出願番号】US2012041575

(87)【国際公開番号】WO2012170833

(87)【国際公開日】20121213

【審査請求日】2014年1月29日

(31)【優先権主張番号】61/495,333

(32)【優先日】2011年6月9日

(33)【優先権主張国】US

(31)【優先権主張番号】61/552,876

(32)【優先日】2011年10月28日

(33)【優先権主張国】US

(31)【優先権主張番号】61/556,002

(32)【優先日】2011年11月4日

(33)【優先権主張国】US

(31)【優先権主張番号】13/491,227

(32)【優先日】2012年6月7日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】595020643

【氏名又は名称】クゥアルコム・インコーポレイテッド

【氏名又は名称原語表記】ＱＵＡＬＣＯＭＭ ＩＮＣＯＲＰＯＲＡＴＥＤ

(74)【代理人】

【識別番号】100108855

【弁理士】

【氏名又は名称】蔵田 昌俊

(74)【代理人】

【識別番号】100109830

【弁理士】

【氏名又は名称】福原 淑弘

(74)【代理人】

【識別番号】100103034

【弁理士】

【氏名又は名称】野河 信久

(74)【代理人】

【識別番号】100075672

【弁理士】

【氏名又は名称】峰 隆司

(74)【代理人】

【識別番号】100153051

【弁理士】

【氏名又は名称】河野 直樹

(74)【代理人】

【識別番号】100140176

【弁理士】

【氏名又は名称】砂川 克

(74)【代理人】

【識別番号】100158805

【弁理士】

【氏名又は名称】井関 守三

(74)【代理人】

【識別番号】100172580

【弁理士】

【氏名又は名称】赤穂 隆雄

(74)【代理人】

【識別番号】100179062

【弁理士】

【氏名又は名称】井上 正

(74)【代理人】

【識別番号】100124394

【弁理士】

【氏名又は名称】佐藤 立志

(74)【代理人】

【識別番号】100112807

【弁理士】

【氏名又は名称】岡田 貴志

(74)【代理人】

【識別番号】100111073

【弁理士】

【氏名又は名称】堀内 美保子

(72)【発明者】

【氏名】チェン、イン

(72)【発明者】

【氏名】チェン、ペイソン

(72)【発明者】

【氏名】カークゼウィックズ、マルタ

【審査官】 久保 光宏

(56)【参考文献】

【文献】 特開平１０−２７１５１６（ＪＰ，Ａ）

【文献】 国際公開第２００７／１１４３６８（ＷＯ，Ａ１）

【文献】 米国特許第６０９７８４３（ＵＳ，Ａ）

【文献】 米国特許出願公開第２００９／００８７１１１（ＵＳ，Ａ１）

【文献】 Dzung Hoang，"Unified scaling with adaptive offset for reference frame compression with IBDI"，[online]，Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG16 WP3 and ISO/IEC JTC1/SC29/WG11，２０１１年 １月２１日，Document: JCTVC-D035_r2， [平成26年12月2日検索], インターネット，ＵＲＬ，http://phenix.int-evry.fr/jct/doc_end_user/documents/4_Daegu/wg11/JCTVC-D035-v3.zip

【文献】 大久保榮監修，「インプレス標準教科書シリーズ 改訂三版H.264/AVC教科書」，日本，株式会社インプレスＲ＆Ｄ，２００９年 １月 １日，第１版，第１６９〜１８０頁，ISBN:978-4-8443-2664-9

【文献】 内藤整（外２名），「超高精細映像メディアの配信技術に関わる最新動向」，映像情報メディア学会技術報告，日本，（社）映像情報メディア学会，２００７年１２月１３日，Vol.31, No.63，第８９〜９４頁，ISSN:1342-6893

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｎ１９／００−１９／９８，

ＣＳＤＢ（日本国特許庁），

ＩＥＥＥＸｐｌｏｒｅ（ＩＥＥＥ）

(57)【特許請求の範囲】

【請求項1】

装置が実行する、ビデオデータをコーディングする方法であって、
前記ビデオデータをコーディングするための第２のビット深度よりも小さい第１のビット深度で前記ビデオデータを出力すべきかどうかを決定することと、
前記ビデオデータが他のビデオデータをコーディングするときに参照データとして使用されるかどうかを決定することと、
前記ビデオデータが前記第１のビット深度で出力されるべきであり、かつ前記ビデオデータが参照データとして使用されないときに、前記ビデオデータを記憶する前に、前記ビデオデータを前記第２のビット深度から前記第１のビット深度に減少させることと、
前記第１のビット深度および前記第２のビット深度のうちの１つで前記ビデオデータを記憶することと
を備える方法。

【請求項2】

前記ビデオデータを前記第２のビット深度から前記第１のビット深度へ減少させることが、前記第２のビット深度を前記第１のビット深度に変換するためにビットシフト演算を前記ビデオデータに対して実行することを含む、請求項１に記載の方法。

【請求項3】

前記ビデオデータが復号ピクチャを備え、前記ビデオデータを記憶することが、前記復号ピクチャを復号ピクチャバッファに記憶することを含む、請求項１に記載の方法。

【請求項4】

前記第１のビット深度で前記ビデオデータを受信することと、内部ビット深度増加（ＩＢＤＩ）プロセス中に、前記ビデオデータをコーディングするより前に前記第１のビット深度を前記第２のビット深度まで増加させることとをさらに備える、請求項１に記載の方法。

【請求項5】

前記第１のビット深度が８ビットであり、前記第２のビット深度が１０ビットに等しいかまたはそれよりも大きい、請求項１に記載の方法。

【請求項6】

前記第１のビット深度および前記第２のビット深度のうちのいずれにおいて前記ビデオデータを表示すべきかの指示をコーディングすることをさらに備える、請求項１に記載の方法。

【請求項7】

前記指示をコーディングすることが、シーケンスパラメータセット（ＳＰＳ）および補足エンハンスメント情報（ＳＥＩ）メッセージのうちの１つにおいてデータをコーディングすることを含む、請求項６に記載の方法。

【請求項8】

ファイルフォーマットおよび記述子のうちの１つにおいて出力ビット深度が前記第２のビット深度に等しいかどうかの指示をコーディングすることをさらに備える、請求項１に記載の方法。

【請求項9】

前記指示が出力ビット深度の指示を含む、請求項８に記載の方法。

【請求項10】

前記ファイルフォーマットが、ＩＳＯベースメディアファイルフォーマットおよびトランスポートストリームフォーマットのうちの１つを含む、請求項８に記載の方法。

【請求項11】

前記記述子が、ＨＴＴＰベース動的適応ストリーミング（ＤＡＳＨ）メディアプレゼンテーション記述（ＭＰＤ）記述子を含む、請求項８に記載の方法。

【請求項12】

前記指示をコーディングすることが、前記指示を含んでいる前記ファイルフォーマットを復号することと、前記第１のビット深度および前記第２のビット深度のうちのいずれにおいて前記ビデオデータを表示すべきかを決定することとを含む、請求項８に記載の方法。

【請求項13】

前記指示をコーディングすることが、前記指示を含んでいる前記記述子を復号することと、前記第１のビット深度および前記第２のビット深度のうちのいずれにおいて前記ビデオデータを表示すべきかを決定することとを含む、請求項８に記載の方法。

【請求項14】

前記指示をコーディングすることが、前記指示を含んでいるメディアプレゼンテーション記述（ＭＰＤ）を復号することと、前記第１のビット深度および前記第２のビット深度のうちのいずれにおいて前記ビデオデータを表示すべきかを決定することとを含む、請求項８に記載の方法。

【請求項15】

ディスプレイデバイスの構成に基づいて、出力ビット深度が前記第１のビット深度を含むのか前記第２のビット深度を含むのかを決定することをさらに備える、請求項１に記載の方法。

【請求項16】

ビデオデータをコーディングするための装置であって、
前記ビデオデータをコーディングするための第２のビット深度よりも小さい第１のビット深度で前記ビデオデータを出力すべきかどうかを決定することと、
前記ビデオデータが他のビデオデータをコーディングするときに参照データとして使用されるかどうかを決定することと、
前記ビデオデータが前記第１のビット深度で出力されるべきであり、かつ前記ビデオデータが参照データとして使用されないときに、前記ビデオデータを記憶する前に、前記ビデオデータを前記第２のビット深度から前記第１のビット深度に減少させることと、
前記第１のビット深度および前記第２のビット深度のうちの１つで前記ビデオデータを記憶することと
を行うように構成された１つまたは複数のプロセッサを備える、装置。

【請求項17】

前記ビデオデータを前記第２のビット深度から前記第１のビット深度へ減少させるために、前記１つまたは複数のプロセッサが、前記第２のビット深度を前記第１のビット深度に変換するためにビットシフト演算を前記ビデオデータに対して実行するように構成された、請求項１６に記載の装置。

【請求項18】

前記ビデオデータが復号ピクチャを含み、前記ビデオデータを記憶するために、前記１つまたは複数のプロセッサが、前記復号ピクチャを復号ピクチャバッファに記憶するように構成された、請求項１６に記載の装置。

【請求項19】

前記１つまたは複数のプロセッサが、前記第１のビット深度で前記ビデオデータを受信することと、内部ビット深度増加（ＩＢＤＩ）プロセス中に、前記ビデオデータをコーディングするより前に前記第１のビット深度を前記第２のビット深度まで増加させることとを行うように構成された、請求項１６に記載の装置。

【請求項20】

前記第１のビット深度が８ビットであり、前記第２のビット深度が１０ビットに等しいかまたはそれよりも大きい、請求項１６に記載の装置。

【請求項21】

前記１つまたは複数のプロセッサが、前記第１のビット深度および前記第２のビット深度のうちのいずれにおいて前記ビデオデータを表示すべきかの指示をコーディングするようにさらに構成された、請求項１６に記載の装置。

【請求項22】

前記指示をコーディングするために、前記１つまたは複数のプロセッサが、ビデオデータの符号化ビットストリーム中のシーケンスパラメータセット（ＳＰＳ）および補足エンハンスメント情報（ＳＥＩ）メッセージのうちの１つのデータをコーディングするように構成された、請求項２１に記載の装置。

【請求項23】

前記１つまたは複数のプロセッサは、ファイルフォーマットおよび記述子のうちの１つにおいて出力ビット深度が前記第２のビット深度に等しいかどうかの指示をコーディングするようにさらに構成された、請求項１６に記載の装置。

【請求項24】

前記指示が出力ビット深度の指示を含む、請求項２３に記載の装置。

【請求項25】

前記ファイルフォーマットが、ＩＳＯベースメディアファイルフォーマットおよびトランスポートストリームフォーマットのうちの１つを含む、請求項２３に記載の装置。

【請求項26】

前記記述子が、ＨＴＴＰベース動的適応ストリーミング（ＤＡＳＨ）メディアプレゼンテーション記述（ＭＰＤ）記述子を含む、請求項２３に記載の装置。

【請求項27】

前記指示をコーディングするために、前記１つまたは複数のプロセッサが、前記指示を含んでいる前記ファイルフォーマットを復号することと、前記第１のビット深度および前記第２のビット深度のうちのいずれにおいて前記ビデオデータを表示すべきかを決定することとを行うように構成された、請求項２３に記載の装置。

【請求項28】

前記指示をコーディングするために、前記１つまたは複数のプロセッサが、前記指示を含んでいる前記記述子を復号することと、前記第１のビット深度および前記第２のビット深度のうちのいずれにおいて前記ビデオデータを表示すべきかを決定することとを行うように構成された、請求項２３に記載の装置。

【請求項29】

前記指示をコーディングするために、前記１つまたは複数のプロセッサが、前記指示を含んでいるメディアプレゼンテーション記述（ＭＰＤ）を復号することと、前記第１のビット深度および前記第２のビット深度のうちのいずれにおいて前記ビデオデータを表示すべきかを決定することとを行うように構成された、請求項２３に記載の装置。

【請求項30】

前記１つまたは複数のプロセッサは、ディスプレイデバイスの構成に基づいて、出力ビット深度が前記第１のビット深度を含むのか前記第２のビット深度を含むのかを決定するようにさらに構成された、請求項１６に記載の装置。

【請求項31】

ビデオデータをコーディングするための装置であって、
前記ビデオデータをコーディングするための第２のビット深度よりも小さい第１のビット深度で前記ビデオデータを出力すべきかどうかを決定するための手段と、
前記ビデオデータが他のビデオデータをコーディングするときに参照データとして使用されるかどうかを決定するための手段と、
前記ビデオデータが前記第１のビット深度で出力されるべきであり、かつ前記ビデオデータが参照データとして使用されないときに、前記ビデオデータを記憶する前に、前記ビデオデータを前記第２のビット深度から前記第１のビット深度に減少させるための手段と、
前記第１のビット深度および前記第２のビット深度のうちの１つで前記ビデオデータを記憶するための手段と
を備える装置。

【請求項32】

前記ビデオデータを前記第２のビット深度から前記第１のビット深度へ減少させるための手段が、前記第２のビット深度を前記第１のビット深度に変換するためにビットシフト演算を前記ビデオデータに対して実行するための手段を含む、請求項３１に記載の装置。

【請求項33】

前記第１のビット深度および前記第２のビット深度のうちのいずれにおいて前記ビデオデータを表示すべきかの指示をコーディングするための手段をさらに備える、請求項３１に記載の装置。

【請求項34】

ファイルフォーマットおよび記述子のうちの１つにおいて出力ビット深度が前記第２のビット深度に等しいかどうかの指示をコーディングするための手段をさらに備える、請求項３１に記載の装置。

【請求項35】

実行されたとき、１つまたは複数のプロセッサに、
ビデオデータをコーディングするための第２のビット深度よりも小さい第１のビット深度で前記ビデオデータを出力すべきかどうかを決定することと、
前記ビデオデータが他のビデオデータをコーディングするときに参照データとして使用されるかどうかを決定することと、
前記ビデオデータが前記第１のビット深度で出力されるべきであり、かつ前記ビデオデータが参照データとして使用されないときに、前記ビデオデータを記憶する前に、前記ビデオデータを前記第２のビット深度から前記第１のビット深度に減少させることと、
前記第１のビット深度および前記第２のビット深度のうちの１つで前記ビデオデータを記憶することと
を行わせる命令を記憶した、コンピュータ可読記憶媒体。

【請求項36】

前記ビデオデータを前記第２のビット深度から前記第１のビット深度へ減少させるために、前記命令が、前記１つまたは複数のプロセッサに、前記第２のビット深度を前記第１のビット深度に変換するためにビットシフト演算を前記ビデオデータに対して実行させる、請求項３５に記載のコンピュータ可読記憶媒体。

【請求項37】

実行されたとき、前記１つまたは複数のプロセッサに、前記第１のビット深度および前記第２のビット深度のうちのいずれにおいて前記ビデオデータを表示すべきかの指示をコーディングさせる命令をさらに備える、請求項３５に記載のコンピュータ可読記憶媒体。

【請求項38】

実行されたとき、前記１つまたは複数のプロセッサに、ファイルフォーマットおよび記述子のうちの１つにおいて出力ビット深度が前記第２のビット深度に等しいかどうかの指示をコーディングさせる命令をさらに備える、請求項３５に記載のコンピュータ可読記憶媒体。

【発明の詳細な説明】

【優先権の主張】

【0001】

本出願は、それらのすべての内容全体が参照により本明細書に組み込まれる、２０１１年６月９日に出願された米国仮特許出願第６１／４９５，３３３号、２０１１年１０月２８日に出願された米国仮特許出願第６１／５５２，８７６号、および２０１１年１１月４日に出願された米国仮特許出願第６１／５５６，００２号の利益を主張する。

【技術分野】

【0002】

本開示は、ビデオコーディング技法に関する。

【背景技術】

【0003】

デジタルビデオ機能は、デジタルテレビジョン、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末（ＰＤＡ）、ラップトップまたはデスクトップコンピュータ、タブレットコンピュータ、電子ブックリーダー、デジタルカメラ、デジタル記録デバイス、デジタルメディアプレーヤ、ビデオゲームデバイス、ビデオゲームコンソール、セルラーまたは衛星無線電話、いわゆる「スマートフォン」、ビデオ遠隔会議デバイス、ビデオストリーミングデバイスなどを含む、広範囲にわたるデバイスに組み込まれ得る。デジタルビデオデバイスは、ＭＰＥＧ−２、ＭＰＥＧ−４、ＩＴＵ−Ｔ Ｈ．２６３、ＩＴＵ−Ｔ Ｈ．２６４／ＭＰＥＧ−４，Ｐａｒｔ１０，Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＡＶＣ）、現在開発中のＨｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＨＥＶＣ）規格によって定義される規格、およびそのような規格の拡張に記載されているビデオ圧縮技法などの、ビデオ圧縮技法を実装する。ビデオデバイスは、そのようなビデオ圧縮技法を実装することによって、デジタルビデオ情報をより効率的に送信、受信、符号化、復号、および／または記憶し得る。

【0004】

ビデオ圧縮技法は、ビデオシーケンスに固有の冗長性を低減または除去するために空間的（イントラピクチャ）予測および／または時間的（インターピクチャ）予測を実行する。ブロックベースのビデオコーディングでは、ビデオスライス（すなわち、ビデオフレームまたはビデオフレームの一部分）は、ツリーブロック、コーディングユニット（ＣＵ）および／またはコーディングノードと呼ばれることもある、ビデオブロックに区分され得る。ピクチャのイントラコード化（Ｉ）スライス中のビデオブロックは、同じピクチャ中の隣接ブロックにおける参照サンプルに対する空間的予測を使用して符号化される。ピクチャのインターコード化（ＰまたはＢ）スライス中のビデオブロックは、同じピクチャ中の隣接ブロック中の参照サンプルに対する空間的予測、または他の参照ピクチャ中の参照サンプルに対する時間的予測を使用し得る。ピクチャはフレームと呼ばれることがあり、参照ピクチャは参照フレームと呼ばれることがある。

【0005】

空間的予測または時間的予測は、コーディングされるべきブロックのための予測ブロックを生じる。残差データは、コーディングされるべき元のブロックと予測ブロックとの間のピクセル差分を表す。インターコード化ブロックは、予測ブロックを形成する参照サンプルのブロックを指す動きベクトルと、コード化ブロックと予測ブロックとの間の差分を示す残差データとに従って符号化される。イントラコード化ブロックは、イントラコーディングモードと残差データとに従って符号化される。さらなる圧縮のために、残差データは、ピクセル領域から変換領域に変換されて、残差変換係数を結果として生じ、次いでそれが量子化され得る。最初に２次元アレイに配列された量子化変換係数は、変換係数の１次元ベクトルを生成するために走査され得、さらなる圧縮を達成するためにエントロピーコーディングが適用され得る。

【発明の概要】

【0006】

概して、本開示の技法は、ビデオコーディングおよびビデオコーディングにおける内部ビット深度増加（ＩＢＤＩ：internal bit depth increase）に関する。たとえば、ビデオコーダは、内部計算における丸め誤差を低減するために、ＩＢＤＩを使用して、コーディングされているサンプルのビット深度を増加させ得る。本開示の技法は、概して、ＩＢＤＩを使用するときのメモリ利用を管理すること、ならびに出力ビット深度を決定することに関する。すなわち、たとえば、本開示の技法は、いくつかの例では、ビデオデータが参照ビデオデータとして使用されない場合、ビデオデータを復号ピクチャバッファに記憶するより前に、ビデオデータをより高いビット深度からより低いビット深度に丸めること（rounding）を含む。別の例では、本開示の技法は、ＩＢＤＩ（たとえば、増加した）ビット深度においてビデオデータを出力すべきかどうかを決定することに関する。

【0007】

一例では、本開示の態様は、概して、ビデオデータを出力するための第１のビット深度と、ビデオデータをコーディングするための第２のビット深度とを決定することであって、第１のビット深度が第２のビット深度よりも小さい、決定することを含む、ビデオデータをコーディングする方法に関する。該方法は、また、ビデオデータが、他のビデオデータをコーディングするときに参照データとして使用されるかどうかを決定することを含む。該方法は、また、決定に基づいて、ビデオデータが参照データとして使用されないときには第１のビット深度でビデオデータを記憶し、ビデオデータが参照データとして使用されるときには第２のビット深度でビデオデータを記憶することを含む。

【0008】

別の例では、本開示の態様は、概して、ビデオデータを出力するための第１のビット深度と、ビデオデータをコーディングするための第２のビット深度とを決定することであって、第１のビット深度が第２のビット深度よりも小さい、決定することと、ビデオデータが、他のビデオデータをコーディングするときに参照データとして使用されるかどうかを決定することと、決定に基づいて、ビデオデータが参照データとして使用されないときには第１のビット深度でビデオデータを記憶し、ビデオデータが参照データとして使用されるときには第２のビット深度でビデオデータを記憶することとを行うように構成された１つまたは複数のプロセッサを含む、ビデオデータをコーディングするための装置に関する。

【0009】

別の例では、本開示の態様は、概して、ビデオデータを出力するための第１のビット深度と、ビデオデータをコーディングするための第２のビット深度とを決定するための手段であって、第１のビット深度が第２のビット深度よりも小さい、決定するための手段と、ビデオデータが、他のビデオデータをコーディングするときに参照データとして使用されるかどうかを決定するための手段と、決定に基づいて、ビデオデータが参照データとして使用されないときには第１のビット深度でビデオデータを記憶し、ビデオデータが参照データとして使用されるときには第２のビット深度でビデオデータを記憶するための手段とを含む、ビデオデータをコーディングするための装置に関する。

【0010】

別の例では、本開示の態様は、概して、実行されたときに、１つまたは複数のプロセッサに、ビデオデータを出力するための第１のビット深度と、ビデオデータをコーディングするための第２のビット深度とを決定することであって、第１のビット深度が第２のビット深度よりも小さい、決定することと、ビデオデータが、他のビデオデータをコーディングするときに参照データとして使用されるかどうかを決定することと、決定に基づいて、ビデオデータが参照データとして使用されないときには第１のビット深度でビデオデータを記憶し、ビデオデータが参照データとして使用されるときには第２のビット深度でビデオデータを記憶することとを行わせる命令を記憶したコンピュータ可読記憶媒体に関する。

【0011】

本開示の１つまたは複数の態様の詳細を添付の図面および以下の説明に記載する。本開示で説明する技法の他の特徴、目的、および利点は、これらの説明および図面、ならびに特許請求の範囲から明らかになろう。

【図面の簡単な説明】

【0012】

【図1】本開示の技法を利用し得る例示的なビデオ符号化および復号システムを示すブロック図。

【図2】ビデオコーディングにおける例示的な内部ビット深度増加（ＩＢＤＩ）動作を示すブロック図。

【図3】本開示の技法のいずれかまたはすべてを実装し得るビデオエンコーダの一例を示すブロック図。

【図4】本開示の技法のいずれかまたはすべてを実装し得るビデオデコーダの一例を示すブロック図。

【図5】ビデオコーディングにおけるＩＢＤＩ関連動作を実行する例示的な方法を示すフローチャート。

【発明を実施するための形態】

【0013】

概して、本開示の技法は、ビデオコーディングに関する。たとえば、ビデオコーダは、内部計算における丸め誤差を低減するために、内部ビット深度増加（ＩＢＤＩ）動作を使用して、コーディングされているサンプルのビット深度を増加させ得る。本開示の技法は、概して、ＩＢＤＩを使用するときのメモリ利用を管理すること、ならびに出力ビット深度を決定することに関する。すなわち、たとえば、本開示の技法は、いくつかの例では、ビデオデータが参照ビデオデータとして使用されない場合、ビデオデータを復号ピクチャバッファに記憶するより前に、ビデオデータをより高いビット深度からより低いビット深度に丸めることを含む。別の例では、本開示の技法は、増加したビット深度においてビデオデータを出力すべきかどうかを決定することに関する。

【0014】

たとえば、ビット深度は、概して、ビデオデータの所与のサンプルについての情報（たとえば、ピクセルのルーマ値および／またはクロマ値）のビット数を指し得る。ＩＢＤＩを実行するときには、ビデオコーダは、コーディングされているサンプルのビット深度を第１のビット数（たとえば、「Ｍ」ビット）から第２の増加したビット数（たとえば、「Ｎ」ビット）に拡張し得る。より大きいビット深度は、内部計算における丸め誤差を低減することを目的とする。たとえば、内部計算を実行するときに算術精度を高めることは、理想的な結果を達成するのを助け得る。増加したビット深度から恩恵を受け得る例示的なプロセスは、特に、動き補償、補間フィルタリング、デブロッキングフィルタリング、および重み付け予測を含み得る。

【0015】

ビデオコーダは、（たとえば、予測コーディングのための参照データとして使用するために）コーディング中に復号ビデオデータを復号ピクチャバッファに記憶し得る。ビデオコーダはまた、出力（たとえば、表示）するより前に復号ビデオデータを復号ピクチャバッファに記憶し得る。（たとえば、ＩＢＤＩを使用して）増加したビット深度で内部計算を実行するときには、ビデオコーダは、増加したビット深度でビデオデータを記憶し得る。したがって、ビデオコーダは、表示のために復号ピクチャバッファからビデオデータを出力するより前に丸めを実行し得る。

【0016】

増加したビット深度でビデオデータを記憶することは、比較的大量のメモリを消費し得る。しかしながら、復号ピクチャバッファに記憶されたビデオデータ（たとえば、ビデオピクチャ）の一部は、参照データ（たとえば、参照ピクチャ）として使用されないことがある。すなわち、ビデオデータのいくつかのピクチャは、参照データとして使用されないが、それでもなお、（たとえば、表示のために）出力されるより前に復号ピクチャバッファに記憶され得る。さらに、復号ピクチャバッファに記憶されたいくつかのビデオピクチャは、コーディングプロセス中に「参照のために使用されない」としてビデオコーダによってマークされ得る。本開示では、概して、「ピクチャ」、「ビデオピクチャ」、および「参照ピクチャ」に言及するが、本開示の技法は、他のサイズ／構成のビデオデータ（たとえば、ビデオブロック、スライス、タイルなど）に適用可能であることを理解されたい。

【0017】

本開示の態様は、概して、表示のために使用されるビット深度よりも高くなり得る内部ビット深度をビデオコーダにおいて使用するときのメモリ利用を管理することに関する。たとえば、本開示の技法は、ビデオデータが参照データとして使用されるときには第１の増加したビット深度でビデオデータを記憶することと、復号ビデオピクチャが参照ピクチャとして使用されないときには減少したビット深度でビデオデータを記憶することとを含む。すなわち、本開示の技法は、概して、ビデオデータが参照ビデオデータとして使用されないときに、ビデオデータを復号ピクチャバッファに記憶するより前に、ビデオデータを増加したビット深度からより低いビット深度に丸めることに関する。たとえば、本開示の技法は、増加したビット深度をもつ復号化ビデオピクチャを、増加したビット深度に対してより低いビット深度をもつ復号化ビデオピクチャに変換することを含む。

【0018】

概して、より低いビット深度は、ビデオデータが受信された元のビット深度に等しくなり得る。しかしながら、より低いビット深度はまた、（たとえば、出力ビット深度が、増加したビット深度よりも小さい例では）ビデオデータが出力されるビット深度に等しいか、または増加したビット深度よりも低い何らかの他のビット深度に等しくなり得る。さらに、本開示の態様は、ビット深度を低下させるためにビデオデータを丸めることに関して説明するが、本開示の技法は、より一般的に、丸めによるのか、（丸めなしの）切り捨てによるのか、ビット深度を減少させる何らかの他のプロセスによるのかにかかわらず、ビデオデータのサンプルのビット深度を低減することに適用可能であることを理解されたい。

【0019】

本開示の態様はまた、増加したビット深度においてビデオデータを出力すべきなのか、減少したビット深度（たとえば、元のビット深度）においてビデオデータを出力すべきなのかを決定することに関する。いくつかの例では、そのような決定は、（たとえば、ビデオデコーダによって出力される）ビデオデータが出力されるべきビット深度に関連するシグナリングに従って行われ得る。そのようなシグナリングは、たとえば、ビデオデコーダによって復号され得る符号化ビデオデータビットストリーム中に含まれ得る。すなわち、本開示の技法は、ビデオデコーダが、たとえば、（「元の」ビット深度と呼ばれる）ビデオデータが受信されたビット深度に等しい、減少したビット深度でビデオデータを出力すべきなのか、または増加したビット深度（たとえば、ＩＢＤＩビット深度）でビデオデータを出力すべきなのかをビデオデコーダにシグナリングすることを含む。別の例では、出力ビット深度は、復号ビデオビットストリームの一部としては存在しないが、ビデオデコーダからの復号ビデオデータを提示しているディスプレイの構成によってなど、ビデオデコーダの外部にあるソースから導出される。

【0020】

ビデオコーダは、いくつかの例では、出力ビット深度を決定することを対象とする、本開示のメモリ管理技法を実装し得る。ビデオコーダが元の（より低い）ビット深度においてビデオデータを出力すべきである例では、ビデオコーダは、復号ピクチャが参照ピクチャとして使用されるべきであるときにのみ、復号ピクチャが、増加した（ＩＢＤＩ）ビット深度において記憶され得るように、上記で説明したメモリ管理技法を実装し得る。

【0021】

本開示の態様は、ビデオデータを符号化および／または復号することに関連するメモリ要件を低減し得る。たとえば、内部コーディング演算のために、ビデオデータのビット深度を増加させるためのＩＢＤＩ技法が使用されるが、ビデオデータは参照のために使用されない例では、本開示の技法は、より少数のビットのデータが記憶されることを可能にする。さらに、本技法は、メモリ帯域幅消費量を低減し得る。たとえば、複数のモジュールが、コーディング中にメモリにアクセスするためにメモリバスを共用し得る。そのような例では、本開示の技法による、より少数のビットをバッファに記憶することは、バッファとビデオコーディングデバイスとの間で転送されるデータの量を減少させ得る。

【0022】

いくつかの例では、メモリ帯域幅を低減することは、モバイル適用例において（たとえば、ビデオコーダがモバイルデバイスに組み込まれる適用例において）有用であり得る。たとえば、上述のように、メモリに対する読取りおよび書込みは、モバイル適用例では比較的限られていることがあるメモリバス帯域幅を消費し得る。その上、メモリに対する読取りおよび書込みは、（たとえば、読取りおよび書込みが、メモリバスおよびメモリに電力供給することをそれぞれ必要とすることを考慮すると）モバイルデバイスによって消費される電力量を増加させ得る。したがって、本開示の技法は、モバイルデバイス、ラップトップコンピュータ、および一定の専用電力供給を有しない他のタイプのデバイスなど、電力制限のあるデバイスにおいて展開され得る。

【0023】

図１は、ビデオコーダにおいてＩＢＤＩを使用するときのメモリ利用を管理するための、本開示で説明する技法を利用するように構成され得る、例示的なビデオ符号化および復号システム１０を示すブロック図である。図１の例に示すように、システム１０は、宛先デバイス１４によって復号するための符号化ビデオを生成するソースデバイス１２を含む。ソースデバイス１２は、符号化ビデオが必要に応じて宛先デバイス１４によってアクセスされ得るように、通信チャネル１６を介して符号化ビデオを宛先デバイス１４に送信し得るか、あるいは符号化ビデオを記憶媒体３４またはファイルサーバ３６に記憶し得る。ソースデバイス１２および宛先デバイス１４は、デスクトップコンピュータ、ノートブック（すなわち、ラップトップ）コンピュータ、タブレットコンピュータ、セットトップボックス、いわゆるスマートフォンなどの電話ハンドセット、テレビジョン、カメラ、ディスプレイデバイス、デジタルメディアプレーヤ、ビデオゲームコンソールなどを含む、多種多様なデバイスのいずれかを備え得る。

【0024】

多くの場合、そのようなデバイスはワイヤレス通信が可能であり得る。したがって、通信チャネル１６は、符号化ビデオデータの送信に好適なワイヤレスチャネル、ワイヤードチャネル、またはワイヤレスチャネルとワイヤードチャネルとの組合せを備え得る。たとえば、通信チャネル１６は、無線周波数（ＲＦ）スペクトルまたは１つもしくは複数の物理伝送線路など、任意のワイヤレスまたはワイヤード通信媒体、あるいはワイヤレス媒体とワイヤード媒体との任意の組合せを備え得る。通信チャネル１６は、ローカルエリアネットワーク、ワイドエリアネットワーク、またはインターネットなどのグローバルネットワークなど、パケットベースネットワークの一部を形成し得る。通信チャネル１６は、概して、ワイヤード媒体またはワイヤレス媒体の任意の好適な組合せを含む、ビデオデータをソースデバイス１２から宛先デバイス１４に送信するのに好適な任意の通信媒体、または様々な通信媒体の集合体を表す。通信チャネル１６は、ソースデバイス１２から宛先デバイス１４への通信を可能にするのに有用であり得るルータ、スイッチ、基地局、または任意の他の機器を含み得る。

【0025】

本開示の例による、ビデオコーダにおいてＩＢＤＩを使用するときのメモリ利用を管理するための、本開示で説明する技法は、オーバージエアテレビジョン放送、ケーブルテレビジョン送信、衛星テレビジョン送信、たとえばインターネットを介したストリーミングビデオ送信、データ記憶媒体に記憶するためのデジタルビデオの符号化、データ記憶媒体に記憶されたデジタルビデオの復号、または他の適用例など、様々なマルチメディア適用例のいずれかをサポートするビデオコーディングに適用され得る。いくつかの例では、システム１０は、ビデオストリーミング、ビデオ再生、ビデオブロードキャスティング、および／またはビデオテレフォニーなどの適用例をサポートするために、一方向または双方向のビデオ送信をサポートするように構成され得る。

【0026】

図１の例にさらに示すように、ソースデバイス１２は、ビデオソース１８と、ビデオエンコーダ２０と、変調器／復調器（モデム）２２と、送信機２４とを含む。ソースデバイス１２において、ビデオソース１８はビデオキャプチャデバイスなどのソースを含み得る。ビデオキャプチャデバイスは、例として、ビデオカメラ、以前にキャプチャされたビデオを含んでいるビデオアーカイブ、ビデオコンテンツプロバイダからビデオを受信するためのビデオフィードインターフェース、および／またはソースビデオとしてコンピュータグラフィックスデータを生成するためのコンピュータグラフィックスシステムのうちの１つまたは複数を含み得る。一例として、ビデオソース１８がビデオカメラである場合、ソースデバイス１２および宛先デバイス１４は、いわゆるカメラフォンまたはビデオフォンを形成し得る。ただし、本開示の技法は、必ずしもワイヤレス適用例または設定に限定されるとは限らず、ビデオ符号化および／または復号機能を含む非ワイヤレスデバイスに適用され得る。ソースデバイス１２および宛先デバイス１４は、本明細書で説明する技法をサポートすることができるコーディングデバイスの例にすぎない。

【0027】

キャプチャされたビデオ、プリキャプチャされたビデオ、またはコンピュータ生成されたビデオは、ビデオエンコーダ２０によって符号化され得る。符号化ビデオ情報は、ワイヤレス通信プロトコルなどの通信規格に従ってモデム２２によって変調され、送信機２４を介して宛先デバイス１４に送信され得る。モデム２２は、信号変調のために設計された様々なミキサ、フィルタ、増幅器または他の構成要素を含み得る。送信機２４は、増幅器、フィルタ、および１つまたは複数のアンテナを含む、データを送信するために設計された回路を含み得る。

【0028】

ビデオエンコーダ２０によって符号化された、キャプチャされたビデオ、プリキャプチャされたビデオ、またはコンピュータ生成されたビデオはまた、後で消費するために記憶媒体３４またはファイルサーバ３６に記憶され得る。記憶媒体３４は、ブルーレイ（登録商標）ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、フラッシュメモリ、または符号化ビデオを記憶するための任意の他の好適なデジタル記憶媒体を含み得る。記憶媒体３４に記憶された符号化ビデオは、次いで、復号および再生のために宛先デバイス１４によってアクセスされ得る。

【0029】

ファイルサーバ３６は、符号化ビデオを記憶することと、その符号化ビデオを宛先デバイス１４に送信することとが可能な任意のタイプのサーバであり得る。例示的なファイルサーバは、（たとえば、ウェブサイトのための）ウェブサーバ、ＦＴＰサーバ、ネットワーク接続ストレージ（ＮＡＳ）デバイス、ローカルディスクドライブ、または符号化ビデオデータを記憶することと、それを宛先デバイスに送信することとが可能な他のタイプのデバイスを含む。ファイルサーバ３６は、インターネット接続を含む任意の標準データ接続を通じて宛先デバイス１４によってアクセスされ得る。これは、ファイルサーバに記憶された符号化ビデオデータにアクセスするのに好適である、ワイヤレスチャネル（たとえば、Ｗｉ−Ｆｉ接続）、ワイヤード接続（たとえば、ＤＳＬ、ケーブルモデムなど）、またはその両方の組合せを含み得る。ファイルサーバ３６からの符号化ビデオデータの送信は、ストリーミング送信、ダウンロード送信、またはその両方の組合せであり得る。

【0030】

本開示では、概して、ビデオエンコーダ２０が、ある情報をビデオデコーダ３０などの別のデバイスに「シグナリング」することに言及し得る。ただし、ビデオエンコーダ２０は、いくつかのシンタックス要素をビデオデータの様々な符号化部分に関連付けることによって情報をシグナリングし得ることを理解されたい。すなわち、ビデオエンコーダ２０は、いくつかのシンタックス要素を、ビデオデータの様々な符号化された部分のヘッダに記憶することによって、出力ビット深度などのデータを「シグナリング」し得る。場合によっては、そのようなシンタックス要素は、ビデオデコーダ３０によって受信され、復号されるより前に、符号化され、記憶され得る（たとえば、記憶媒体３４またはファイルサーバ３６に記憶され得る）。したがって、「シグナリング」という用語は、そのような通信が、リアルタイムまたはほぼリアルタイムで行われるのか、符号化時にシンタックス要素を媒体に記憶し、次いで、この媒体に記憶された後の任意の時間にそのシンタックス要素が復号デバイスによって取り出され得るときに行われ得るなど、ある時間期間にわたって行われるのかにかかわらず、概して、圧縮ビデオデータを復号するためのシンタックスまたは他のデータの通信を指すことがある。

【0031】

宛先デバイス１４は、図１の例では、受信機２６と、モデム２８と、ビデオデコーダ３０と、ディスプレイデバイス３２とを含む。宛先デバイス１４の受信機２６はチャネル１６を介して情報を受信し、モデム２８は、その情報を復調して、ビデオデコーダ３０のための復調されたビットストリームを生成する。チャネル１６を介して通信される情報は、ビデオデータを復号する際にビデオデコーダ３０が使用する、ビデオエンコーダ２０によって生成された様々なシンタックス情報を含み得る。そのようなシンタックスはまた、記憶媒体３４またはファイルサーバ３６に記憶された符号化ビデオデータとともに含まれ得る。ビデオエンコーダ２０およびビデオデコーダ３０の各々は、ビデオデータを符号化または復号することが可能であるそれぞれのエンコーダデコーダ（コーデック）の一部を形成し得る。

【0032】

ディスプレイデバイス３２は、宛先デバイス１４と一体化されるかまたはその外部にあり得る。いくつかの例では、宛先デバイス１４は、一体型ディスプレイデバイスを含み、また、外部ディスプレイデバイスとインターフェースするように構成され得る。他の例では、宛先デバイス１４はディスプレイデバイスであり得る。概して、ディスプレイデバイス３２は、復号されたビデオデータをユーザに対して表示し、液晶ディスプレイ（ＬＣＤ）、プラズマディスプレイ、有機発光ダイオード（ＯＬＥＤ）ディスプレイ、または別のタイプのディスプレイデバイスなど、様々なディスプレイデバイスのいずれかを備え得る。

【0033】

ビデオエンコーダ２０およびビデオデコーダ３０は、現在開発中のＨｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＨＥＶＣ）規格などのビデオ圧縮規格に従って動作し得、ＨＥＶＣテストモデル（ＨＭ）に準拠し得る。代替的に、ビデオエンコーダ２０およびビデオデコーダ３０は、代替的にＭＰＥＧ−４，Ｐａｒｔ１０，Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＡＶＣ）と呼ばれるＩＴＵ−Ｔ Ｈ．２６４規格など、他のプロプライエタリ規格または業界規格、あるいはそのような規格の拡張に従って動作し得る。ただし、本開示の技法は、いかなる特定のコーディング規格にも限定されない。他の例には、ＭＰＥＧ−２およびＩＴＵ−Ｔ Ｈ．２６３がある。

【0034】

ＨＥＶＣ規格では、ビデオデータのブロックをコーディングユニット（ＣＵ）と呼ぶ。概して、ＣＵは、ＣＵがサイズ差異を有しないことを除いて、Ｈ．２６４に従ってコーディングされたマクロブロックと同様の目的を有する。したがって、ＣＵはサブＣＵに分割され得る。概して、本開示におけるＣＵへの言及は、ピクチャの最大コーディングユニット（ＬＣＵ）またはＬＣＵのサブＣＵを指すことがある。たとえば、ビットストリーム内のシンタックスデータが、ピクセルの数に関して最大のコーディングユニットであるＬＣＵを定義し得る。ＬＣＵはサブＣＵに分割され得、各サブＣＵはサブＣＵに分割され得る。ビットストリームのシンタックスデータは、最大ＣＵ深さと呼ばれる、ＬＣＵが分割され得る最大回数を定義し得る。それに応じて、ビットストリームは最小コーディングユニット（ＳＣＵ）をも定義し得る。

【0035】

ＬＣＵは階層４分木データ構造に関連付けられ得る。概して、４分木データ構造はＣＵごとに１つのノードを含み、ルートノードはＬＣＵに対応する。ＣＵが４つのサブＣＵに分割された場合、ＣＵに対応するノードは４つのリーフノードを含み、リーフノードの各々はサブＣＵのうちの１つに対応する。４分木データ構造の各ノードは、対応するＣＵのシンタックスデータを与え得る。たとえば、４分木のノードは、そのノードに対応するＣＵがサブＣＵに分割されるかどうかを示す分割フラグを含み得る。ＣＵのシンタックス要素は、再帰的に定義され得、ＣＵがサブＣＵに分割されるかどうかに依存し得る。

【0036】

分割されないＣＵは、１つまたは複数の予測ユニット（ＰＵ）を含み得る。概して、ＰＵは、対応するＣＵの全部または一部分を表し、そのＰＵの参照サンプルを取り出すためのデータを含む。たとえば、ＰＵがイントラモード符号化されるとき、ＰＵは、ＰＵのイントラ予測モードを記述するデータを含み得る。別の例として、ＰＵがインターモード符号化されるとき、ＰＵは、ＰＵの動きベクトルを定義するデータを含み得る。動きベクトルを定義するデータは、たとえば、動きベクトルの水平成分、動きベクトルの垂直成分、動きベクトルの解像度（たとえば、１／４ピクセル精度または１／８ピクセル精度）、動きベクトルが指す参照フレーム、および／または動きベクトルの参照リスト（たとえば、リスト０またはリスト１）を記述し得る。（１つまたは複数の）ＰＵを定義するＣＵのデータはまた、たとえば、ＣＵを１つまたは複数のＰＵに区分することを記述し得る。区分モードは、ＣＵがコーディングされないか、イントラ予測モード符号化されるか、またはインター予測モード符号化されるかの間で異なり得る。

【0037】

１つまたは複数のＰＵを有するＣＵはまた、１つまたは複数の変換ユニット（ＴＵ）を含み得る。ＰＵを使用した予測の後に、ビデオエンコーダは、ＰＵに対応するＣＵの部分の残差値を計算し得る。残差値は変換され、量子化され、走査され得る。ＴＵは、必ずしもＰＵのサイズに制限されない。したがって、ＴＵは、同じＣＵの対応するＰＵよりも大きいことも小さいこともある。いくつかの例では、ＴＵの最大サイズは、対応するＣＵのサイズであり得る。本開示ではまた、ＣＵ、ＰＵ、またはＴＵのいずれかを指すために「ブロック」という用語を使用する。

【0038】

概して、符号化ビデオデータは予測データと残差データとを含み得る。ビデオエンコーダ２０は、イントラ予測モードまたはインター予測モード中に予測データを生成し得る。イントラ予測は、概して、あるピクチャのブロック中のピクセル値を、（フレームと呼ばれることもある）同じピクチャの隣接する、前にコーディングされたブロック中の参照サンプルに対して予測することを伴う。インター予測は、概して、あるピクチャのブロック中のピクセル値、たとえば、ルーマおよびクロマ値を、前にコーディングされたピクチャのデータに対して予測することを伴う。

【0039】

イントラ予測またはインター予測の後に、ビデオエンコーダ２０はブロックの残差ピクセル値を計算し得る。残差値は、概して、ブロックの予測ピクセル値データと、ブロックの真のピクセル値データとの間の差分に対応する。たとえば、残差値は、コード化ピクセルと予測ピクセルとの間の差分を示すピクセル差分値を含み得る。いくつかの例では、コード化ピクセルは、コーディングされるべきピクセルのブロックに関連し得、予測ピクセルは、コード化ブロックを予測するために使用されるピクセルの１つまたは複数のブロックに関連し得る。

【0040】

ブロックの残差値をさらに圧縮するために、残差値は、（「エネルギー」とも呼ばれる）できるだけ多くのデータをできるだけ少数の係数に構成する変換係数のセットに変換され得る。変換技法は、離散コサイン変換（ＤＣＴ）プロセスまたは概念的に同様のプロセス、整数変換、ウェーブレット変換、あるいは他のタイプの変換を備え得る。その変換は、ピクセルの残差値を空間領域から変換領域に変換する。変換係数は、元のブロックと通常同じサイズである係数の２次元行列に対応する。言い換えれば、残差データの元のブロック中のピクセルとちょうど同数の変換係数がある。ただし、変換により、変換係数の多くは、０に等しい値を有し得る。

【0041】

ビデオエンコーダ２０は、次いで、ビデオデータをさらに圧縮するために変換係数のレベルを量子化し得る。量子化は、概して、相対的に大きい範囲内の値を相対的に小さい範囲中の値にマッピングし、それによって、量子化変換係数を表すために必要とされるデータの量を低減することを伴う。より詳細には、量子化は、量子化中に変換係数に適用される量子化器ステップサイズにインデックス付けされ得る量子化パラメータ（ＱＰ）に従って適用され得る。ビデオエンコーダ２０は、ＱＰを調整することによって、量子化の程度（たとえば、量子化器ステップサイズ）を変更し得る。

【0042】

量子化の後に、ビデオエンコーダ２０は、変換係数を走査して、量子化変換係数を含む２次元行列から１次元ベクトルを生成し得る。ビデオエンコーダ２０は、次いで、データをなお一層圧縮するために、得られたアレイをエントロピー符号化し得る。概して、エントロピーコーディングは、量子化変換係数のシーケンスおよび／または他のシンタックス情報をまとめて圧縮する、１つまたは複数のプロセスを備える。また、たとえば、ΔＱＰ、予測ベクトル、コーディングモード、フィルタ、オフセット、または他の情報など、シンタックス要素は、エントロピーコード化ビットストリーム中に含まれ得る。走査された係数は、次いで、たとえば、コンテンツ適応型可変長コーディング（ＣＡＶＬＣ：content adaptive variable length coding）、コンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ：context adaptive binary arithmetic coding）、または別のエントロピーコーディングプロセスによって、シンタックス情報とともにエントロピーコーディングされる。

【0043】

ＣＡＢＡＣを実行するために、ビデオエンコーダ２０は、送信されるべきシンボルを符号化するために、あるコンテキストに適用すべきコンテキストモデルを選択し得る。コンテキストは、たとえば、隣接値が非０であるか否かに関係し得る。ビデオエンコーダ２０はまた、適応走査を実行するときに生成される有効係数フラグおよび最後係数フラグなど、シンタックス要素をエントロピー符号化し得る。

【0044】

ビデオデコーダ３０によって実行されるビデオ復号プロセスは、概して、ビデオエンコーダ２０によって実行される符号化技法とは逆の技法を含み得る。概して逆であるが、ビデオデコーダ３０は、場合によっては、ビデオエンコーダ２０によって実行される技法と同様の技法を実行し得る。言い換えれば、ビデオデコーダ３０は、ビデオエンコーダ２０によって実行されるプロセスと実質的に同様のプロセスを実行し得る。ビデオデコーダ３０はまた、ビデオエンコーダ２０に関して説明したデータを含む受信したビットストリーム中に含まれているシンタックス要素または他のデータに依拠し得る。

【0045】

いくつかの例では、ビデオエンコーダ２０は、ビデオデータを復号するときに使用され得るいくつかのパラメータセットを生成し得、ビデオデコーダ３０はそれらのパラメータセットを受信し得る。たとえば、Ｈ．２６４／ＡＶＣ（Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）規格では、コード化ビデオセグメントは、ビデオテレフォニー、ストレージ、ブロードキャスト、またはストリーミングなどの適用例に対処する「ネットワークフレンドリーな」ビデオ表現を与えるＮＡＬユニットに編成される。ＮＡＬユニットは、ビデオコーディングレイヤ（ＶＣＬ）ＮＡＬユニットと非ＶＣＬ ＮＡＬユニットとにカテゴリー分類され得る。ＶＣＬユニットは、コア圧縮エンジンを含み得、ブロック、マクロブロック、および／またはスライスレベルのデータを含み得る。他のＮＡＬユニットは非ＶＣＬ ＮＡＬユニットであり得る。いくつかの例では、通常は１次コード化ピクチャとして提示される、１つの時間インスタンス中のコード化ピクチャは、１つまたは複数のＮＡＬユニットを含み得るアクセスユニット中に含まれ得る。

【0046】

非ＶＣＬ ＮＡＬユニットは、特に、パラメータセットＮＡＬユニットおよびＳＥＩ ＮＡＬユニットを含み得る。パラメータセットは、（シーケンスパラメータセット（ＳＰＳ）中の）シーケンスレベルヘッダ情報と、（ピクチャパラメータセット（ＰＰＳ）中の）まれに変化するピクチャレベルヘッダ情報とを含んでいることがある。パラメータセット（たとえば、ＰＰＳおよびＳＰＳ）がある場合、まれに変化する情報をシーケンスごとまたはピクチャごとに繰り返す必要はなく、したがってコーディング効率が改善され得る。さらに、パラメータセットの使用は重要なヘッダ情報の帯域外送信を可能にし、誤り耐性のための冗長送信の必要を回避し得る。帯域外送信の例では、ＳＥＩ ＮＡＬユニットなど、他のＮＡＬユニットとは異なるチャネル上でパラメータセットＮＡＬユニットが送信され得る。

【0047】

補足エンハンスメント情報（ＳＥＩ）は、ＶＣＬ ＮＡＬユニットからのコード化ピクチャサンプルを復号するためには必要でないが、復号、表示、誤り耐性、および他の目的に関係するプロセスを支援し得る情報を含んでいることがある。ＳＥＩメッセージは、非ＶＣＬ ＮＡＬユニット中に含まれていることがある。ＳＥＩメッセージは、一部の標準規格の規範的部分であり、したがって、常に標準準拠デコーダ実装のために必須であるとは限らない。ＳＥＩメッセージは、シーケンスレベルのＳＥＩメッセージまたはピクチャレベルのＳＥＩメッセージであり得る。ＳＶＣの例ではスケーラビリティ情報ＳＥＩメッセージ、ＭＶＣではビュースケーラビリティ情報ＳＥＩメッセージなど、ＳＥＩメッセージ中に何らかのシーケンスレベル情報が含まれていることがある。

【0048】

さらに、ビデオデコーダ３０は、いくつかの例では、あるメディアフォーマットを実装する規格に準拠し得る。たとえば、ＩＳＯベースメディアファイルフォーマットは、メディアの交換、管理、編集、およびプレゼンテーションを可能にする、フレキシブルで拡張可能なフォーマットにおけるプレゼンテーションのための時限メディア情報を含んでいるように設計される。ＩＳＯベースメディアファイルフォーマット（ＩＳＯ／ＩＥＣ１４４９６−１２：２００４）は、時間ベースメディアファイルのための一般的な構造を定義するＭＰＥＧ−４ Ｐａｒｔ１２において規定されている。ベースフォーマットは、Ｈ．２６４／ＭＰＥＧ−４ ＡＶＣビデオ圧縮をサポートするために定義されたＡｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＡＶＣ）ファイルフォーマット（ＩＳＯ／ＩＥＣ１４４９６−１５）、ＡＶＣファイルフォーマットの拡張である３ＧＰＰファイルフォーマット、ＳＶＣファイルフォーマット、およびＭＶＣファイルフォーマットなど、ファミリー中の他のファイルフォーマットに対する基準として使用され得る。

【0049】

概して、ＩＳＯベースメディアファイルフォーマットは、オーディオビジュアルプレゼンテーションなどのメディアデータの時限シーケンスのためのタイミング、構造、およびメディア情報を含んでいる。ファイル構造はオブジェクト指向であり得る。すなわち、ファイルは、極めて簡単に基本オブジェクトに分解され得、オブジェクトの構造はそれらのタイプから暗示され得る。ＩＳＯベースメディアファイルフォーマットに準拠するファイルは、「ボックス」と呼ばれる一連のオブジェクトとして形成され得る。データは、概してボックス中に含まれており、一般に、ファイル内に他のデータはない。したがって、「ボックス」は、一意のタイプ識別子と長さとによって定義されるオブジェクト指向ビルディングブロックである。

【0050】

別の例では、ＭＰＥＧ−４ ｐａｒｔ１５としても知られるＡＶＣファイルフォーマットは、ＩＳＯベースメディアファイルフォーマットの拡張である。ＡＶＣファイルフォーマットでは、ビデオサンプルは、AVCDecoderConfigurationRecordならびに同じアクセスユニットのＮＡＬユニットを含んでいる「AVCSample」中に含まれている。AVCDecoderConfigurationRecordはまた、パラメータセットのみを含んでいる「AVCParameterSample」中に含まれていることがある。AVCDecoderConfigurationRecordのシンタックスは以下を含み得る。

【数1】

【0051】

上記の例では、AVCDecoderConfigurationRecordは、いくつかのプロファイルおよびレベル関係の要素を含んでいる。多くのビデオコーディング規格の場合と同様に、Ｈ．２６４／ＡＶＣは、誤りのないビットストリームのシンタックスと、セマンティクスと、復号プロセスとを定義し、そのいずれかは特定のプロファイルまたはレベルに準拠する。Ｈ．２６４／ＡＶＣはエンコーダを指定しないが、エンコーダは、生成されたビットストリームがデコーダの規格に準拠することを保証することを課される。ビデオコーディング規格のコンテキストでは、「プロファイル」は、アルゴリズム、機能、またはツール、およびそれらに適用される制約のサブセットに対応する。たとえば、Ｈ．２６４規格によって定義される「プロファイル」は、Ｈ．２６４規格によって指定されたビットストリームシンタックス全体のサブセットである。「レベル」は、たとえば、ピクチャの解像度、ビットレート、およびマクロブロック（ＭＢ）処理レートに関係するデコーダメモリおよび計算など、デコーダリソース消費の制限に対応する。プロファイルはprofile_idc（プロファイルインジケータ）値でシグナリングされ得、レベルはlevel_idc（レベルインジケータ）値でシグナリングされ得る。

【0052】

Ｈ．２６４／ＡＶＣ規格は、たとえば、所与のプロファイルのシンタックスによって課される限界内で、復号されたピクチャの指定されたサイズなど、ビットストリーム中のシンタックス要素がとる値に応じて、エンコーダおよびデコーダのパフォーマンスの大きい変動を必要とする可能性が依然としてあることを認識している。Ｈ．２６４／ＡＶＣ規格は、多くの適用例において、特定のプロファイル内でシンタックスのすべての仮定的使用を処理することが可能なデコーダを実装することが実際的でもなく、経済的でもないことをさらに認識している。したがって、Ｈ．２６４／ＡＶＣ規格は、ビットストリーム中のシンタックス要素の値に課された制約の指定されたセットとして「レベル」を定義している。これらの制約は、値に関する単純な限界であり得る。代替的に、これらの制約は、値の演算の組合せ（たとえば、ピクチャの幅×ピクチャの高さ×毎秒復号されるピクチャの数）に関する制約の形態をとり得る。Ｈ．２６４／ＡＶＣ規格は、個々の実装形態が、サポートされるプロファイルごとに異なるレベルをサポートし得ることをさらに規定している。

【0053】

いくつかの例では、ビデオエンコーダ２０および／またはビデオデコーダ３０はまた、ＭＰＥＧ−２規格などの他のプロプライエタリ規格または業界規格に従って動作し得る。ＭＰＥＧ−２システム仕様には、デジタル送信または記憶に好適な単一のデータストリームを形成するために、圧縮マルチメディアデータストリーム（たとえば、ビデオおよびオーディオストリーム）が他のデータとともにどのように多重化され得るかが記載されている。ＭＰＥＧ−２システムの最新仕様は、「Information Technology - Generic Coding of Moving Pictures and Associated Audio: Systems, Recommendation H.222.0; International Organization for Standardization, ISO/IEC JTC1/SC29/WG11; Coding of Moving Pictures and Associated Audio」（２００６年５月）において規定されている。

【0054】

背景として、ＭＰＥＧ−２によれば、エレメンタリストリームは、プログラムの単一のデジタル的にコード化された（場合によってはＭＰＥＧ圧縮された）構成要素である。たとえば、プログラムのコード化ビデオまたはオーディオ部分はエレメンタリストリームであり得る。エレメンタリストリームは、プログラムストリームまたはトランスポートストリームに多重化される前に、パケット化エレメンタリストリーム（ＰＥＳ）に変換され得る。同じプログラム内では、１つのエレメンタリストリームに属するＰＥＳパケットを他のものと区別するためにstream_idが使用され得る。

【0055】

プログラムストリームは、概して、１つまたは複数の関連するエレメンタリストリームを含んでおり、一般に、可変長のパケットを含んでいる。さらに、プログラムストリームは、概して、寄与しているエレメンタリストリームから導出され、いわゆる「パック」に編成される、ＰＥＳパケットを含む。パックは、パックヘッダと、オプションのシステムヘッダと、寄与しているエレメンタリストリームのいずれかから取られる任意の数のＰＥＳパケットとを任意の順序で含む。システムヘッダは、含まれるとき、最大データレート、寄与しているビデオおよびオーディオエレメンタリストリームの数、ならびにタイミング情報など、プログラムストリームの特性の概要を含んでいることがある。ビデオデコーダ３０などのデコーダは、デコーダがプログラムストリームを復号することが可能であるかどうかを決定するために、システムヘッダ中に含まれている情報を使用し得る。

【0056】

トランスポートストリームは、潜在的に誤りを起こしやすいチャネルを介したいくつかのプログラムの同時配信を目的とする。トランスポートストリームは、誤りに対する感受性を低減する、比較的短いトランスポートパケットの連続を備える。トランスポートストリームは、誤り耐性と、多くの同時プログラムを搬送する能力とを与えるが、それはまた、プログラムストリームよりも高度なマルチプレクスを含み得、作成することおよびデマルチプレクスすることがより困難であり得る。

【0057】

１つのエレメンタリストリームのデータを含んでいるトランスポートパケットを、他のエレメンタリストリームのデータを搬送しているものと区別するために、１３ビットパケット識別子（ＰＩＤ）フィールドが使用され得る。プログラム固有情報は、プログラムと構成要素エレメンタリストリームとの間の関係を指定し得る。基本プログラムマップテーブル（ＰＭＴ）は、ＭＰＥＧ−２システム仕様内で指定されている多くの記述子のうちのいくつかで装飾され得る。例として、ＰＭＴが、ＰＩＤ３３をもつビデオと、ＰＩＤ５７をもつ英語のオーディオと、ＰＩＤ６０をもつ中国語のオーディオとを含んでいる、番号３をもつプログラムを含むと仮定する。ＰＭＴは、２つ以上のプログラムを含み得る。

【0058】

ＰＭＴに関連する記述子は、一般に、プログラムまたはそれの構成要素エレメンタリストリームに関するさらなる情報を搬送する。記述子は、ビデオ符号化パラメータ、オーディオ符号化パラメータ、言語識別情報、パンアンドスキャン情報、限定アクセス詳細、著作権情報などを含む。放送事業者または他のユーザは、必要な場合、追加のプライベート記述子を定義し得る。

【0059】

プログラムストリームマップ（ＰＳＭ）は、プログラムストリーム中のエレメンタリストリーム、および互いとのそれらの関係の説明を与え得る。トランスポートストリームにおいて搬送されるとき、ＰＳＭは変更されないことがある。ＰＳＭは、stream_id値が０ｘＢＣであるときにＰＥＳパケットとして存在する。プログラム関連付けテーブル（ＰＡＴ）は、それのプログラムマップテーブル（ＰＭＴ）を含んでいるトランスポートパケットのＰＩＤ値とともに、トランスポートストリーム中で利用可能なすべてのプログラムの完全なリストを与える。上述の同じ例を使用して、プログラム番号３のエレメンタリストリームを指定するＰＭＴはＰＩＤ１００１を有し得、別のＰＭＴは別のＰＩＤ１００２を有し得る。

【0060】

ＡＶＣ（たとえば、ＩＴＵ−Ｔ Ｒｅｃ．Ｈ．２６４｜ＩＳＯ／ＩＥＣ１４４９６−１０）ビデオストリームでは、ＡＶＣビデオ記述子は、ＡＶＣビデオストリームのＳＰＳ中に含まれるプロファイルおよびレベルパラメータに関するなど、関連するＡＶＣビデオストリームのコーディングパラメータを識別するための基本情報を与える。

【0061】

たとえば、ＡＶＣビデオ記述子は、ＡＶＣビデオストリーム中のＡＶＣ静止ピクチャの存在とＡＶＣ２４時間ピクチャの存在とをシグナリングし得る。そのような記述子がＰＭＴまたはＰＳＭ（存在する場合）中に含まれていない場合、ＡＶＣビデオストリームは、ＡＶＣ静止ピクチャとＡＶＣ２４時間ピクチャとを含んでいないことがある。例示的なＡＶＣビデオ記述子は、以下の例示的な表１中に含まれている。

【表1】

【0062】

ビデオエンコーダ２０および／またはビデオデコーダ３０はまた、ＭＰＥＧ指定のＨＴＴＰベース動的適応ストリーミング（ＤＡＳＨ：Dynamic Adaptive Streaming based on HTTP）に準拠し得る。ＤＡＳＨでは、マニフェストファイル、すなわち、サービスの表現を記述するＭＰＤ（メディアプレゼンテーション記述子）がある。たとえば、ＭＰＤは、コーディング特性およびレンダリング特性、適応セット、ＭＰＤが対応するプロファイル、テキストタイプ情報、カメラアングル情報、レーティング情報、トリックモード情報（たとえば、時間サブシーケンスを含む表現を示す情報）、および／または（たとえば、再生中のメディアコンテンツ中へのターゲット広告挿入のための）リモート期間を取り出すための情報など、含まれた表現の特性を全体的に記述するデータを含み得る。

【0063】

各表現は、ヘッダデータと、メディアデータの１つまたは複数のセグメントとを含み得る。ヘッダデータは、存在するとき、セグメントの特性、たとえば、ランダムアクセスポイントの時間ロケーション、セグメント内のランダムアクセスポイントへのバイトオフセット、セグメントのユニフォームリソースロケータ（ＵＲＬ）、またはセグメントの他の態様を記述し得る。追加または代替として、そのような特性はＭＰＤ内に完全に含まれ得る。各セグメントは１つまたは複数のコード化ビデオサンプルを含み得、コード化ビデオサンプルの各々はビデオデータのピクチャまたはスライスを含み得る。セグメントのコード化ビデオサンプルの各々は、同様の特性、たとえば、高さ、幅、および帯域幅要件を有し得る。セグメントの各々は、一意のユニフォームリソース識別子（ＵＲＩ）、たとえば、ユニフォームリソースロケータ（ＵＲＬ）に関連し得る。したがって、セグメントの各々は、ＤＡＳＨなどのストリーミングネットワークプロトコルを使用して独立に取出し可能であり得る。このようにして、（ビデオデコーダ３０などのビデオデコーダを含み得る）宛先デバイスは、ＨＴＴＰ Ｇｅｔ要求を使用してセグメントを取り出し得る。

【0064】

図１には示されていないが、いくつかの態様では、ビデオエンコーダ２０およびビデオデコーダ３０は、それぞれオーディオエンコーダおよびオーディオデコーダと統合され得、また、共通のデータストリームまたは別個のデータストリーム中のオーディオとビデオの両方の符号化を処理するための適切なＭＵＸ−ＤＥＭＵＸユニット、または他のハードウェアおよびソフトウェアを含み得る。適用可能な場合、いくつかの例では、ＭＵＸ−ＤＥＭＵＸユニットはＩＴＵ Ｈ．２２３マルチプレクサプロトコル、またはユーザデータグラムプロトコル（ＵＤＰ）などの他のプロトコルに準拠し得る。

【0065】

ビデオエンコーダ２０およびビデオデコーダ３０はそれぞれ、１つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ディスクリート論理、ソフトウェア、ハードウェア、ファームウェアなど、様々な好適なエンコーダ回路のいずれか、またはそれらの任意の組合せとして実装され得る。本技法が部分的にソフトウェアで実装されるとき、デバイスは、好適な非一時的コンピュータ可読媒体にソフトウェアの命令を記憶し、１つまたは複数のプロセッサを使用してその命令をハードウェアで実行して、本開示の技法を実行し得る。ビデオエンコーダ２０およびビデオデコーダ３０の各々は１つまたは複数のエンコーダまたはデコーダ中に含まれ得、そのいずれも、それぞれのデバイスにおいて複合エンコーダ／デコーダ（コーデック）の一部として統合され得る。

【0066】

本開示の態様によれば、以下の図３および図４に関してより詳細に説明するように、ビデオエンコーダ２０および／またはビデオデコーダ３０は、出力ビット深度よりも高い内部ビット深度を使用するときにメモリ利用管理を実行し得る。すなわち、内部ビット深度は、概して、ビデオエンコーダ２０および／またはビデオデコーダ３０の内部の計算のために使用されるビット深度を指す。例示的な内部計算は、特に、動き補償、補間フィルタリング、デブロッキングフィルタリング、および重み付け予測を含む。出力ビット深度は、概して、ビデオエンコーダ２０および／またはビデオデコーダ３０から送信されるビット深度を指す。たとえば、ビデオデコーダ３０に関して、出力ビット深度は、提示のためにディスプレイデバイス３２に送られるサンプル（たとえば、ピクセルのルーマ値および／またはクロマ値）のビット深度である。

【0067】

たとえば、ビデオエンコーダ２０および／またはビデオデコーダ３０は、復号ピクチャが参照ピクチャとして使用されるとき、第１の増加したビット深度でビデオデータを記憶し得る。ビデオエンコーダ２０および／またはビデオデコーダ３０は、復号ピクチャが参照ピクチャとして使用されないとき、減少したビット深度（たとえば、元のビット深度）で復号ピクチャを記憶し得る。すなわち、ビデオエンコーダ２０および／またはビデオデコーダ３０は、復号ピクチャが参照ピクチャとして使用されない場合、ビデオデータを復号ピクチャバッファに記憶するより前に、ビデオデータを増加したビット深度からより低いビット深度に丸め得る。

【0068】

さらに、本開示の態様によれば、ビデオエンコーダ２０は、出力フォーマットに関するいくつかの指示（たとえば、シンタックス要素など）をビデオデコーダ３０に与え得、ビデオデコーダ３０は、それらの指示を復号し得る。たとえば、本開示の態様はまた、ビデオデータがビデオデコーダ３０によって出力されるべきビット深度に関連するシグナリングに関する。たとえば、ビデオエンコーダ２０は、ビデオデコーダ３０が、ビデオエンコーダ２０またはビデオデコーダ３０によってビデオデータが受信された元のビット深度でピクチャを出力すべきなのか、増加したビット深度（たとえば、ＩＢＤＩビット深度）でピクチャを出力すべきなのかを示すシンタックス要素を符号化し得、ビデオデコーダ３０は、それらのシンタックス要素を復号し得る。

【0069】

そのようなシグナリングは、たとえば、ＳＰＳ、ＰＰＳ、または他のパラメータセット、あるいは１つまたは複数のＳＥＩメッセージ中で与えられ得る。別の例では、そのようなシグナリングは、（たとえば、ＩＳＯベースメディアファイルフォーマットの拡張として）ファイルフォーマット中で与えられるか、またはプロファイルおよびレベル情報を含んでいるサンプル中で与えられ得る。別の例では、ＭＰＥＧ−２システムにおいて、そのようなシグナリングは記述子中で与えられ得る。別の例では、動的適応ストリーミングオーバーＨＴＴＰ（ＤＡＳＨ：Dynamic Adaptive Streaming over HTTP）環境において、そのようなシグナリングはメディアプレゼンテーション記述（ＭＰＤ）ファイル中で与えられ得る。別の例では、そのようなシグナリングは、たとえば、遠隔制御を通して出力ビット深度を決定するディスプレイデバイスによって使用され得る。

【0070】

図２は、ビデオコーディングにおける例示的なＩＢＤＩ動作を示すブロック図である。図２に関して説明する動作について、概して、ビデオコーダ３８によって実行されるものとして説明するが、そのような動作は、以下でより詳細に説明するように、ビデオエンコーダ２０および／またはビデオデコーダ３０によって実行され得ることを理解されたい。

【0071】

図２の例では、ビデオコーダ３８はＭビットソースデータ３３を受信する。ソースデータ３３は、たとえば、深度が「Ｍ」ビットのサンプル（たとえば、ピクセル値）を有するピクチャを含み得、「Ｍ」は正値である。一例では、ソースデータ３３は、８ビット深度をもつサンプルを有するピクチャを含み得るが、他のビット深度も使用され得る。

【0072】

ソースデータ３３を受信すると、ビデオコーダ３８はソースデータ３３のビット深度を増加させ得る。たとえば、図２の例に示すように、ビデオコーダ３８は、ソースデータ３３のビット深度をＮ−Ｍビットだけ増加させるために、ソースデータ２２に対して右シフト演算（＜＜）を実行し得、「Ｎ」は「Ｍ」よりも大きい（３４）。Ｍが８ビットであり、Ｎが１０のビットである例では、ビデオコーダ３８は、ソースデータ３３を２ビットだけ拡張するために右シフト演算を実行し得る。

【0073】

ソースデータ３３のビット深度を増加させた後に、ビデオコーダ３８はＮビットコーディング演算を実行し得る（３５）。たとえば、ビデオコーダ３８は、増加したビット深度を使用して、イントラピクチャ予測を実行するか、１つまたは複数の補間フィルタを適用するか、１つまたは複数のデブロッキングフィルタを適用するか、１つまたは複数の空間変換を適用するか、または他のプロセスを実行し得る。（たとえば、ビデオコーダ３８の内部の）内部計算のために比較的より高い（増加した）ビット深度を使用することは、高精度内部プロセス（ＨＡＩＰ：High Accuracy Internal Process）と呼ばれることもある。ＨＡＩＰを適用することによって、内部プロセスの精度はＮ−Ｍビットだけ増加される。より大きいビット深度は、内部計算における丸め誤差を低減するのを助け得る。たとえば、内部計算（たとえば、デジタルフィルタリングなど）を実行するときに算術精度を高めることは、理想的な結果を達成するのを助け得る。いくつかの例では、ビデオコーダ３８は、元のＭビットソースデータ３３を使用していくつかの演算を実行し、Ｎビットのビット増加したデータを使用して他の演算を実行するように構成され得る。

【0074】

ビデオコーダ３８は、次いで、データを出力するより前に、得られたデータに対して丸め演算（切り捨て）を実行し得る。たとえば、ビデオコーダ３８は、ビット増加したデータを元のＭビット深度まで丸め得る（３６）。したがって、ビデオコーダ３８はＭビット出力データ３７を出力し得る。出力データ３７は、（たとえば、出力データ３７がビデオエンコーダからのものであるときには）符号化ビットストリームであり得るか、または（たとえば、出力データ３７がビデオデコーダからのものであるときには）復号ピクチャであり得る。

【0075】

図３は、ビデオコーダにおいてＩＢＤＩを使用するときのメモリ利用を管理するための技法を実装し得るビデオエンコーダ２０の一例を示すブロック図である。図３のいくつかの構成要素は、概念的な目的のために単一の構成要素に関して図示および説明されることがあるが、１つまたは複数の機能ユニットを含み得ることを理解されたい。さらに、図３のいくつかの構成要素は、単一の構成要素に関して図示および説明されることがあるが、そのような構成要素は、物理的に１つまたは２つ以上の個別および／または一体型ユニットから構成され得る。

【0076】

図３に示すように、ビデオエンコーダ２０は、符号化されるべきビデオピクチャ内の現在ビデオブロックを受信する。図３の例では、ビデオエンコーダ２０は、モード選択ユニット４０と、ＩＢＤＩモジュール４１Ａ、４１Ｂ、および４１Ｃ（総称して、ＩＢＤＩモジュール４１）と、動き推定ユニット４２と、動き補償ユニット４４と、参照ピクチャメモリ６４と、加算器５０と、変換ユニット５２と、量子化ユニット５４と、エントロピーコーディングユニット５６とを含む。ビデオブロック再構成のために、ビデオエンコーダ２０はまた、逆量子化ユニット５８と、逆変換ユニット６０と、加算器６２とを含む。再構成されたビデオからブロッキネスアーティファクトを除去するためにブロック境界をフィルタリングするデブロッキングフィルタ（図３に図示せず）も含まれ得る。所望される場合、デブロッキングフィルタは、一般に、加算器６２の出力をフィルタリングすることになる。

【0077】

符号化プロセス中に、ビデオエンコーダ２０は、コーディングされるべきビデオピクチャまたはスライスを受信する。ピクチャまたはスライスは複数のビデオブロックに分割され得る。いくつかの例では、ＩＢＤＩモジュール４１Ａは、コーディングされるべき受信したビデオピクチャまたはスライスの受信したサンプル（たとえば、ピクセル）のビット深度を増加させ得る。たとえば、図２に関して上記で説明したように、ＩＢＤＩモジュール４１Ａは、受信したサンプルのビット深度を増加させるために右シフト演算を実行し得る。一例では、説明のために、受信したビデオデータがビット深度８を有する（たとえば、ビデオデータの各サンプルが８ビットのデータを含む）と仮定する。この例では、ＩＢＤＩモジュール４１Ａは、（たとえば、ビデオデータの各サンプルが１０ビットのデータを含むように）サンプルのビット深度を１０まで増加させるために右シフト演算を実行し得る。別の例では、ＩＢＤＩモジュール４１Ａは、サンプルのビット深度を１２まで増加させるために右シフト演算を実行し得る。他の変形形態も可能である。

【0078】

図３に示した例では、ＩＢＤＩモジュール４１Ａは、ビデオエンコーダ２０のすべての演算がビット深度増加されるように、ビデオエンコーダ２０の相対入力に配置される。ただし、いくつかの例では、ＩＢＤＩは、ビデオエンコーダ２０に関連する演算のサブセットのみに適用され得ることを理解されたい。たとえば、ＩＢＤＩモジュール４１Ａは、ビデオエンコーダ２０内の演算（たとえば、動き推定ユニット４２、動き補償ユニット４４、イントラ予測ユニット４６、変換ユニット５２、量子化ユニット５４、逆量子化ユニット５８、逆変換ユニット６０、デブロッキングフィルタまたは他のフィルタ（図示せず）、あるいはビデオエンコーダ２０の他のユニットに関連する演算）のすべてまたはいずれかのサブセットのためにＩＢＤＩを実行し得る。

【0079】

動き推定ユニット４２および動き補償ユニット４４は、１つまたは複数の参照ピクチャ中の１つまたは複数のブロックに対する受信したビデオブロックのインター予測コーディングを実行する。すなわち、動き推定ユニット４２は、異なる時間インスタンスの１つまたは複数の参照ピクチャ中の１つまたは複数のブロックに対する受信したビデオブロックのインター予測コーディング、たとえば、同じビューの１つまたは複数の参照ピクチャを使用した動き推定を実行し得る。さらに、動き推定ユニット４２は、同じ時間インスタンスの１つまたは複数の参照ピクチャ中の１つまたは複数のブロックに対する受信したビデオブロックのインター予測コーディング、たとえば、異なるビューの１つまたは複数の参照ピクチャを使用した動き視差を実行し得る。

【0080】

イントラ予測ユニット４６は、空間圧縮を行うために、コーディングされるべきブロックと同じピクチャまたはスライス中の１つまたは複数の隣接ブロックに対する受信したビデオブロックのイントラ予測コーディングを実行し得る。モード選択ユニット４０は、たとえば、誤差結果に基づいてコーディングモード、すなわち、イントラまたはインターのうちの１つを選択し得、残差ブロックデータを生成するために、得られたイントラコード化ブロックまたはインターコード化ブロックを加算器５０に与え、参照ピクチャ中で使用するための符号化ブロックを再構成するために、得られたイントラコード化ブロックまたはインターコード化ブロックを加算器６２に与える。

【0081】

動き推定ユニット４２と動き補償ユニット４４とは、高度に統合され得るが、概念的な目的のために別々に示してある。動き推定は、ビデオブロックの動きを推定する動きベクトルを生成するプロセスである。動きベクトルは、たとえば、現在ピクチャ（または他のコード化ユニット）内でコーディングされている現在ブロックに対する予測参照ピクチャ（または他のコード化ユニット）内の予測ブロックの変位を示し得る。予測ブロックは、絶対値差分和（ＳＡＤ：sum of absolute difference）、２乗差分和（ＳＳＤ：sum of square difference）、または他の差分メトリックによって決定され得るピクセル差分に関して、コーディングされるべきブロックにぴったり一致することがわかるブロックである。動きベクトルはまた、マクロブロックのパーティションの変位を示し得る。動き補償は、動き推定ユニット４２によって決定された動きベクトル（または変位ベクトル）に基づいて予測ブロックをフェッチまたは生成することを伴い得る。この場合も、いくつかの例では、動き推定ユニット４２と動き補償ユニット４４とは機能的に統合され得る。

【0082】

動き推定ユニット４２は、ビデオブロックを参照ピクチャメモリ６４中の参照ピクチャのビデオブロックと比較することによってインターコード化ピクチャのビデオブロックの動きベクトルを計算し得る。動き補償ユニット４４はまた、参照ピクチャ、たとえば、ＩフレームまたはＰフレームのサブ整数ピクセルを補間し得る。ＩＴＵ−Ｔ Ｈ．２６４規格では、参照ピクチャの「リスト」、たとえば、リスト０およびリスト１に言及している。リスト０は、現在ピクチャよりも前の表示順序を有する参照ピクチャを含むが、リスト１は、現在ピクチャよりも後の表示順序を有する参照ピクチャを含む。他のコーディング方式では、単一のリストが維持され得る。

【0083】

動き推定ユニット４２は、参照ピクチャメモリ６４からの１つまたは複数の参照ピクチャのブロックを現在ピクチャ、たとえば、ＰピクチャまたはＢピクチャの符号化されるべきブロックと比較する。参照ピクチャメモリ６４中の参照ピクチャがサブ整数ピクセルの値を含むとき、動き推定ユニット４２によって計算される動きベクトルは参照ピクチャのサブ整数ピクセルロケーションに対応するサンプルを参照し得る。動き推定ユニット４２は、計算された動きベクトルをエントロピーコーディングユニット５６と動き補償ユニット４４とに送る。動きベクトルによって識別される参照ピクチャブロックは予測ブロックと呼ばれることがある。動き補償ユニット４４は、参照ピクチャの予測ブロックの残差誤差値を計算する。

【0084】

変換ユニット５２は、離散コサイン変換（ＤＣＴ）、整数変換、または概念的に同様の変換などの変換を残差ブロックに適用し、残差変換係数値を備えるビデオブロックを生成する。変換ユニット５２は、概念的にＤＣＴと同様である、Ｈ．２６４規格によって定義される変換など、他の変換を実行し得る。ウェーブレット変換、整数変換、サブバンド変換または他のタイプの変換も使用され得る。いずれの場合も、変換ユニット５２は、変換を残差ブロックに適用し、残差変換係数のブロックを生成する。変換ユニット５２は、残差情報をピクセル値領域から周波数領域などの変換領域に変換し得る。

【0085】

量子化ユニット５４は、ビットレートをさらに低減するために残差変換係数を量子化する。量子化プロセスは、係数の一部または全部に関連するビット深度を低減し得る。量子化の程度は、量子化パラメータを調整することによって変更され得る。たとえば、量子化は、概して、相対的に大きい範囲内の値を相対的に小さい範囲中の値にマッピングし、それによって、量子化変換係数を表すために必要とされるデータの量を低減することを伴う。ビデオエンコーダは、あらかじめ定義されたアルゴリズムに従って量子化パラメータ（ＱＰ）を適用することによって変換係数を量子化し得る。ビデオエンコーダは、ＱＰを調整することによって、変換係数値に適用される量子化の程度を変更し得る。

【0086】

量子化の後、エントロピーコーディングユニット５６が量子化変換係数をエントロピーコーディングする。たとえば、エントロピーコーディングユニット５６は、コンテンツ適応型可変長コーディング（ＣＡＶＬＣ）、コンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ）、または別のエントロピーコーディング技法を実行し得る。エントロピーコーディングユニット５６によるエントロピーコーディングの後、符号化ビデオは、別のデバイスに送信されるか、あるいは後で送信するかまたは取り出すためにアーカイブされ得る。コンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ）の場合、コンテキストは隣接マクロブロックに基づき得る。

【0087】

場合によっては、エントロピーコーディングユニット５６またはビデオエンコーダ２０の別のユニットは、エントロピーコーディングに加えて他のコーディング機能を実行するように構成され得る。たとえば、エントロピーコーディングユニット５６はマクロブロックおよびパーティションのＣＢＰ値を決定するように構成され得る。また、場合によっては、エントロピーコーディングユニット５６は、マクロブロックまたはそれのパーティション中の係数のランレングスコーディングを実行し得る。特に、エントロピーコーディングユニット５６は、マクロブロックまたはパーティション中の変換係数を走査するためにジグザグ走査または他の走査パターンを適用し、さらなる圧縮のためにゼロのランを符号化し得る。エントロピーコーディングユニット５６はまた、符号化ビデオビットストリーム中での送信のために適切なシンタックス要素を用いてヘッダ情報を構成し得る。

【0088】

エントロピーコーディングより前に、ＩＢＤＩモジュール４１Ｂは、サンプル値を（たとえば、ＩＢＤＩモジュール４１Ａによって増加された）増加したビット深度から元のビット深度に丸め得る。すなわち、増加したビット深度を使用して内部演算を実行した後に、ＩＢＤＩモジュール４１Ｂは、ビデオデータがビデオエンコーダ２０から出力されるより前に、ビデオデータを元のビット深度（すなわち、データがビデオエンコーダ２０によって受信されたビット深度）、または何らかの他の比較的より低いビット深度に戻し得る。

【0089】

逆量子化ユニット５８および逆変換ユニット６０は、それぞれ逆量子化および逆変換を適用して、たとえば参照ブロックとして後で使用するために、ピクセル領域中で残差ブロックを再構成する。動き補償ユニット４４は、残差ブロックを参照ピクチャメモリ６４のピクチャのうちの１つの予測ブロックに加算することによって参照ブロックを計算し得る。動き補償ユニット４４はまた、再構成された残差ブロックに１つまたは複数の補間フィルタを適用して、動き推定において使用するサブ整数ピクセル値を計算し得る。加算器６２は、再構成された残差ブロックを、動き補償ユニット４４によって生成された動き補償予測ブロックに加算して、参照ピクチャメモリ６４に記憶するための再構成されたビデオブロックを生成する。再構成されたビデオブロックは、後続のビデオピクチャ中のブロックをインターコーディングするために動き推定ユニット４２および動き補償ユニット４４によって参照ブロックとして使用され得る。

【0090】

いくつかの例では、本開示の態様によれば、ＩＢＤＩモジュール４１Ｃは、ＩＢＤＩを使用するときのメモリ利用を管理するのを助け得る。たとえば、再構成されたブロックを参照ピクチャメモリ６４に記憶するより前に、ＩＢＤＩモジュール４１Ｃは、データが参照データとして実際に使用されるかどうかを決定し得る。本開示の態様によれば、ＩＢＤＩモジュール４１Ｃは、参照データとして使用されるビデオデータを改変しないことがある。そうではなく、再構成されたピクチャは、ＩＢＤＩ（増加した）ビット深度で参照ピクチャメモリ６４に記憶され得る。対照的に、ＩＢＤＩモジュール４１Ｃは、参照ピクチャとして使用されないピクチャのサンプルを丸め得る。すなわち、ＩＢＤＩモジュール４１Ｃは、復号ピクチャを参照ピクチャメモリ６４に記憶するより前に、復号ピクチャのビット深度を減少させ得る。このようにして、参照ピクチャメモリ６４に記憶されたデータの少なくとも一部が、低減されたビット深度で記憶され得るので、ビデオエンコーダ２０は、ＩＢＤＩを使用するとき、いくらかのメモリ消費量節約を達成し得る。

【0091】

さらに、本開示のいくつかの態様によれば、ビデオエンコーダ２０は、以下で説明するビデオデコーダ３０などのビデオデコーダに、出力フォーマットに関するいくつかの指示を与え得る。たとえば、ビデオエンコーダ２０は、ビデオデコーダが、ビデオデータが受信されたビット深度で復号ピクチャを出力すべきなのか、増加したビット深度（たとえば、ＩＢＤＩビット深度）で復号ピクチャを出力すべきなのかを示すシンタックス要素を符号化し得る。そのようなシグナリングは、たとえば、ＳＰＳ、ＰＰＳ、または他のパラメータセット、あるいはＳＥＩメッセージ中で与えられ得る。別の例では、そのようなシグナリングは、（たとえば、ＩＳＯベースメディアファイルフォーマットの拡張として）ファイルフォーマット中で与えられるか、またはプロファイルおよびレベル情報を含んでいるサンプル中で与えられ得る。別の例では、ＭＰＥＧ−２システムにおいて、そのようなシグナリングは記述子中で与えられ得る。別の例では、動的適応ストリーミングオーバーＨＴＴＰ（ＤＡＳＨ）環境において、そのようなシグナリングはメディアプレゼンテーション記述（ＭＰＤ）ファイル中で与えられ得る。

【0092】

ＩＢＤＩモジュール４１は、ビット深度を増加させることを担当するモジュール４１Ａと、出力するより前にビット深度を切り捨てることを担当するモジュール４１Ｂと、参照ピクチャメモリ６３に記憶するより前にビット深度を切り捨てることを担当するモジュール４１Ｃとがある別々のモジュールとして示されているが、そのようなＩＢＤＩモジュール４１は、高度に統合され、および／または単一のモジュールに組み込まれ得ることを理解されたい。さらに、説明のために個別モジュールとして示されているが、ＩＢＤＩモジュール４１は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得ることを理解されたい。

【0093】

図４は、本開示の技法を実行し得るビデオデコーダ３０の一例を示すブロック図である。図４の例では、ビデオデコーダ３０は、エントロピー復号ユニット１３０と、ＩＢＤＩモジュール１３１Ａおよび１３１Ｂ（総称的に、ＩＢＤＩモジュール１３１）と、動き補償ユニット１３２と、イントラ予測ユニット１３４と、逆量子化ユニット１３６と、逆変換ユニット１３８と、参照ピクチャメモリ１４２と、加算器１４０とを含む。

【0094】

エントロピー復号ユニット１３０は、受信したビットストリームをエントロピー復号し得る。たとえば、エントロピー復号ユニット１３０は、直列化された変換係数を受信し、変換係数を逆走査して変換係数の２次元アレイを生成し得る。

【0095】

ＩＢＤＩモジュール１３１Ａは、エントロピー復号されたサンプルのビット深度を増加させ得る。たとえば、図２および図３に関して上記で説明したように、ＩＢＤＩモジュール１３１Ａは、受信したサンプルのビット深度を増加させるために右シフト演算を実行し得る。一例では、説明のために、受信したビデオデータ（符号化ビットストリームからの変換係数、動きベクトルなど）がビット深度８を有する（たとえば、ビデオデータの各サンプルが８ビットのデータを含む）と仮定する。この例では、ＩＢＤＩモジュール１３１Ａは、サンプルのビット深度を１０まで増加させるために右シフト演算を実行し得る。別の例では、ＩＢＤＩモジュール１３１Ａは、サンプルのビット深度を１２まで増加させるために右シフト演算を実行し得る。他の変形形態も可能である。

【0096】

動き補償ユニット１３２は、エントロピー復号ユニット１３０から受信した動きベクトルに基づいて予測データを生成し得る。動き補償ユニット１３２は、ビットストリーム中で受信した動きベクトルを使用して、参照ピクチャメモリ１４２中の参照ピクチャ中の予測ブロックを識別し得る。イントラ予測ユニット１３４は、ビットストリーム中で受信したイントラ予測モードを使用して、空間的に隣接するブロックから予測ブロックを形成し得る。逆量子化ユニット１３６は、ビットストリーム中で与えられ、エントロピー復号ユニット１３０によって復号された量子化ブロック係数を逆量子化（inverse quantize）、すなわち、逆量子化（de-quantize）する。

【0097】

逆変換ユニット１５８は、逆変換、たとえば、逆ＤＣＴ、逆整数変換、または概念的に同様の逆変換プロセスを変換係数に適用して、ピクセル領域において残差ブロックを生成する。動き補償ユニット１３２は動き補償ブロックを生成し、場合によっては、補間フィルタに基づいて補間を実行する。サブピクセル精度をもつ動き推定に使用されるべき補間フィルタの識別子は、シンタックス要素中に含まれ得る。動き補償ユニット１３２は、ビデオブロックの符号化中にビデオエンコーダ２０によって使用された補間フィルタを使用して、参照ブロックのサブ整数ピクセルのための補間値を計算し得る。動き補償ユニット１３２は、受信したシンタックス情報に従って、ビデオエンコーダ２０によって使用された補間フィルタを決定し、その補間フィルタを使用して予測ブロックを生成し得る。

【0098】

動き補償ユニット１３２は、シンタックス情報のいくつかを使用して、符号化ビデオシーケンスの（１つまたは複数の）ピクチャを符号化するために使用されるマクロブロックのサイズと、符号化ビデオシーケンスのピクチャの各マクロブロックがどのように区分されるのかを記述するパーティション情報と、各パーティションがどのように符号化されるのかを示すモードと、各インター符号化マクロブロックまたはパーティションのための１つまたは複数の参照ピクチャ（またはリスト）と、符号化ビデオシーケンスを復号するための他の情報とを決定する。

【0099】

加算器１４０は、残差ブロックを、動き補償ユニット１３２またはイントラ予測ユニットによって生成される対応する予測ブロックと加算して、復号ブロックを形成する。所望される場合、ブロッキネスアーティファクトを除去するために、復号ブロックをフィルタリングするためにデブロッキングフィルタも適用され得る。復号されたビデオブロックは、次いで、参照ピクチャメモリ１４２に記憶され、参照ピクチャメモリ１４２は、参照ブロックを後続の動き補償に与え、また、（図１のディスプレイデバイス３２などの）ディスプレイデバイス上での提示のために復号ビデオを生成する。

【0100】

本開示の態様によれば、ＩＢＤＩモジュール１３１Ｂは、ＩＢＤＩを使用するときのメモリ利用を管理するのを助け得る。たとえば、復号ピクチャを参照ピクチャメモリ１４２に記憶するより前に、ビデオデコーダ３０は、ピクチャが、たとえば、他の予測されたピクセル値を復号するための参照ピクチャとして使用されるかどうかを決定し得る。本開示の態様によれば、ＩＢＤＩモジュール１３１Ｂは、参照ピクチャとして使用されるピクチャを改変しないことがある。そうではなく、ビデオデコーダ３０は、ＩＢＤＩ（増加した）ビット深度で復号ピクチャを参照ピクチャメモリ１４２に記憶し得る。すなわち、上記の図２で図示および説明したＩＢＤＩ例に関して、ビデオデコーダ３０は、「Ｎ」ビット深度を用いて復号ピクチャを参照ピクチャメモリ１４２に記憶し得る。

【0101】

対照的に、ＩＢＤＩモジュール１３１Ｂは、参照ピクチャとして使用されない復号ピクチャのサンプルを丸め得る。たとえば、いくつかのピクチャ（たとえば、いくつかのＢフレームなど）は参照ピクチャとして使用されないことがある。その上、いくつかの事例では、ビデオデコーダ３０は、いくつかのピクチャを「参照のために使用されない」とマークし得る。たとえば、ピクチャが復号されたが、まだ表示されておらず、参照ピクチャとして使用されない場合、そのピクチャは、参照のために使用されないとマークされ得る。したがって、ピクチャが参照データとして使用されないとき、ＩＢＤＩモジュール１３１Ｂは、復号ピクチャを参照ピクチャメモリ１４２に記憶するより前に、復号ピクチャのビット深度を減少させ得る。すなわち、ＩＢＤＩモジュール１３１Ｂは、参照ピクチャとして使用されない復号ピクチャを、増加したビット深度から元のより低いビット深度に変換し得る。たとえば、ＩＢＤＩモジュール１３１Ｂは、初めに、参照ピクチャとして使用されない復号ピクチャをより低いビット深度において参照ピクチャメモリ１４２に記憶し得る。ＩＢＤＩモジュールはまた、増加したビット深度で最初に記憶されたが、もはや参照ピクチャとして使用されない復号ピクチャをより低いビット深度に変換し得る。このようにして、参照ピクチャメモリ１４２に記憶されたデータの少なくとも一部が、増加したビット深度に対してより低いビット深度で記憶され得るので、ビデオデコーダ３０は、ＩＢＤＩを使用するとき、いくらかのメモリ消費量節約を達成し得る。

【0102】

本開示のいくつかの態様によれば、ビデオデコーダ３０は、ピクチャが参照ピクチャとして使用されるかどうかにかかわらず、元のビット深度（たとえば、非ＩＢＤＩビット深度）でピクチャを維持し得る。この変更ＩＢＤＩプロセスによれば、ビデオデコーダ３０は、ピクチャが、動き補償など、いくつかのプロセスのために使用されるときにビット深度を増加させ得る。すなわち、たとえば、ビデオデコーダ３０は、サブピクセル補間、逆量子化、逆変換、および最終再構成など、内部復号プロセスにおいて比較的より高精度の計算を実行し得る。しかしながら、ＩＢＤＩモジュール１３１Ｂは、次いで、メモリ帯域幅消費量を低減するために、復号ピクチャを参照ピクチャメモリ１４２に記憶するより前に、（参照ピクチャとして使用されるピクチャを含む）すべての復号ピクチャのビット深度を減少させ得る。

【0103】

いくつかの事例では、ビデオデコーダ３０は、データ（たとえば、受信した符号化ビットストリーム）が受信されたビット深度に対して、増加したビット深度で復号ピクチャを出力し得る。増加したビット深度データを出力することは、そのようなより高いビット深度データを扱うことが可能であるデコーダおよびディスプレイに比較的より良いビデオ品質および／またはオーディオ品質を与え得る。

【0104】

本開示の態様によれば、ビデオデコーダ３０は、受信した出力ビット深度インジケータに基づいて、増加したビット深度（たとえば、ＩＢＤＩビット深度）で復号ピクチャを出力すべきなのか、元のビット深度（たとえば、符号化ビットストリームが受信されたビット深度）で復号ピクチャを出力すべきなのかを決定し得る。たとえば、ビデオデコーダ３０は、出力ビット深度を示すいくつかのシンタックス要素を受信し、復号し、復号されたシンタックス要素に従って（たとえば、参照ピクチャメモリ１４２からの）復号ピクチャを出力し得る。

【0105】

一例では、出力ビット深度インジケータは、ＳＰＳ、ＰＰＳ、または他のパラメータセット、ＳＥＩメッセージ、および／または他のメッセージ中に含まれ得る。たとえば、ビデオデコーダ３０は、ＳＰＳまたはＳＥＩメッセージ中で、元のビット深度（たとえば、コード化ビデオデータが受信されたビット深度）で復号ピクチャを出力すべきなのか、増加したビット深度（たとえば、ＩＢＤＩビット深度）で復号ピクチャを出力すべきなのかを示すフラグ（たとえば、display_IBDI_depth_flag）を受信し得る。ディスプレイビット深度フラグが０に設定された場合、ビデオデコーダ３０は元のビット深度で復号ピクチャを出力し得、ディスプレイフラグが１に設定された場合、ビデオデコーダ３０は増加したビット深度で復号ピクチャを出力し得る（またはその逆も同様である）。いくつかの例では、ディスプレイビット深度フラグは、ＩＢＤＩプロセスが有効である（たとえば、bitDepthIncreasedシンタックス要素が０よりも大きく、ＩＢＤＩが有効であることを示す）ときにのみ設定され得る。

【0106】

本開示の態様によれば、ビデオデコーダ３０は、様々なファクタに基づいて、ディスプレイビット深度フラグを変更するための軽量トランスコーディング技法を実装し得る。たとえば、（図１に示したディスプレイデバイス３２などの）ディスプレイが、元のビット深度（たとえば、８ビット深度）を有するピクチャのみを表示することが可能である場合、ビデオデコーダ３０は、ディスプレイビット深度フラグの元の値にかかわらず、ディスプレイビット深度フラグを０に再設定し得る。すなわち、ビデオデコーダ３０は、ディスプレイが、増加したビット深度で復号ピクチャを提示することが可能でない場合、ディスプレイビット深度フラグを値１から値０に再設定し得る。

【0107】

他の例では、フラグがパラメータセットまたは他のメッセージ中に含まれるのではなく、フラグは、特定のコーディング規格に関連する設定可能なパラメータであり得る。たとえば、新生ＨＥＶＣ規格に関して、displayIBDIDepthFlagパラメータが復号プロセスにおいて使用され得る。この例では、パラメータは、ディスプレイビット深度フラグがパラメータセット（たとえば、ＳＰＳまたはＰＰＳ）中に含まれるのか、他のメッセージ（たとえば、ＳＥＩメッセージ）中に含まれるのかにかかわらず、システム仕様においてシグナリングされ得る。

【0108】

他の例では、出力ビット深度インジケータは、（たとえば、ＩＳＯベースメディアファイルフォーマットの拡張として）ファイルフォーマット中に含まれ得る。たとえば、出力ビット深度インジケータは、プロファイルおよびレベル情報を含んでいるサンプル中に含まれ得る。一例では、説明のために、出力ビット深度インジケータは、図１に関して上記で説明したＡＶＣファイルフォーマットと同じAVCDecoderConfigurationRecordを共用し得る。しかしながら、本開示の態様によれば、ファイルフォーマットは、以下のフォーマットに従って変更され得る。

【数2】

【0109】

この例では、ゼロ（０）に等しいdisplayIBDIDepthは、ＩＢＤＩがビットストリーム中で使用されないこと、または出力信号（たとえば、ビデオデコーダ３０からの復号ピクチャ）が、より低い非ＩＢＤＩビット深度（たとえば、Ｍビット）を使用することのいずれかを示す。代替的に、１に等しいdisplayIBDIDepthは、ＩＢＤＩが使用されること、および出力信号が、増加したビット深度を用いて表示されるべきであることを示し得る。本開示のいくつかの態様によれば、ディスプレイビット深度フラグ（たとえば、display_IBDI_depth_flag）がＳＰＳ（または、いくつかの例では、ＳＥＩメッセージ）中に存在するとき、displayIBDIDepthはdisplay_IBDI_depth_flagに等しく設定される。上記に示した例では、IBDI_bit_depth_luma_minus8plus8は、表示のために使用されるべきビット深度（Ｎ）を示し得る。すなわち、IBDI_bit_depth_luma_minus8+8は（Ｎ）に等しくなり、（Ｎ）は、bitDepthIncreasedと組み合わせられたビット深度（Ｍ）に等しくなり得る。

【0110】

上記の例は、説明のために与えたものにすぎず、他の例も可能であることを理解されたい。たとえば、上記で説明したAVCDecoderConfigurationRecordは、HEVCDecoderConfigurationRecordにリネームされ得るが、新生ＨＥＶＣファイルフォーマットにおいて、ＡＶＣファイルフォーマットにおけるAVCDecoderConfigurationRecordと同じ役割を果たし得る。

【0111】

別の例では、出力ビット深度インジケータは、ＭＰＥＧ−２記述子などの記述子中に含まれ得る。たとえば、ＨＥＶＣ ＭＰＥＧ−２システム設計は、上記で説明したように、ＡＶＣのシステム設計と同様であり得る。すなわち、ＨＥＶＣ ＭＰＥＧ−２は、以下の表２に示す変更を用いて、ＨＥＶＣビットストリームを記述するためにＡＶＣビデオ記述子を再利用し得る。

【表2】

【0112】

表２の例では、０に等しいdisplay_IBDI_depthは、ＩＢＤＩがビットストリーム中で使用されないこと、または表示されるべき出力信号（たとえば、ビデオデコーダ３０からの復号ピクチャ）が、より低い非ＩＢＤＩビット深度（たとえば、Ｍビット）を使用することのいずれかを示し得る。代替的に、１に等しいdisplay_IBDI_depthは、ＩＢＤＩが使用されること、および出力信号が、増加したビット深度（たとえば、Ｎビット、ただし、ＮはＭよりも大きい）を用いて表示されるべきであることを示し得る。display_IBDI_depth_flagがＳＰＳ中に存在するとき、display_IBDI_depthはdisplay_IBDI_depth_flagに等しく設定され得る。さらに、上記に示した例では、IBDI_bit_depth_minus8plus8は、表示のために使用されるべきビット深度（Ｎ）を示し得る。すなわち、IBDI_bit_depth_minus8+8は（Ｎ）に等しくなり、（Ｎ）は、bitDepthIncreasedと組み合わせられたビット深度（Ｍ）に等しくなり得る。表２に示す例は説明のために与えたものにすぎないことを理解されたい。すなわち、別の例では、記述子は、同様のシンタックス要素を有するＨＥＶＣ記述子（または別のコーディング規格に対応する記述子）と呼ばれることもある。

【0113】

さらに別の例では、出力ビット深度インジケータは、（たとえば、ＤＡＳＨ環境において）ＭＰＤファイル中に含まれ得る。たとえば、上述のように、ＭＰＤは、復号されるべき利用可能なビデオデータの様々な表現を記述し得る。たとえば、ＭＰＤは、上述のように、コーディング特性およびレンダリング特性、適応セット、ＭＰＤが対応するプロファイル、ならびに様々な他の情報など、含まれた表現の特性を全体に記述するデータを含み得る。

【0114】

本開示の態様によれば、出力ビット深度は、カプセル化（たとえば、ビデオデコーダ３０への送信のためのパッケージング）のときにコンテンツを与えることを担当するサーバによって決定され得る。すなわち、たとえば、サービスプロバイダは、あるコンテンツの表示のために追加のビット深度は必要でないと決定し得る。そのような場合、サービスプロバイダは、（たとえば、ＭＰＤ中に）表現がＩＢＤＩビット深度で表示されるべきでないことを示すＩＢＤＩフラグを設定し得る。代替的に、サービスプロバイダは、追加のビット深度が、特定の表現のデータを表示するために使用され得ることを決定し得、それに応じて、ディスプレイビット深度インジケータを設定し得る。例示的なＭＰＤを以下の表３に示す。

【表3-1】

【表3-2】

【表3-3】

【0115】

上述のように、@IBDIDepth要素が存在するとき、その要素は、ＨＥＶＣ表現（または別のコーディング規格の表現）がIBDIDepthの増加したビット深度（Ｎビット）を用いて表示されるべきであることを示すために使用され得る。その要素が存在しないとき、表現は、通常のビット深度（Ｍビット）を用いて表示されるべきである。@IBDIDepthの値は、ビットストリームのＳＰＳ（またはＳＥＩメッセージ）中で示されているように、Ｍビット深度＋bitDepthIncreasedに等しくなり得る。

【0116】

いくつかの例では、上述のように、復号ピクチャが参照ピクチャとして使用されるかどうかにかかわらず、参照ピクチャメモリ１４２に記憶されているすべての復号ピクチャの丸めを含む変更ＩＢＤＩプロセスが使用され得る。そのような例では、第１のＩＢＤＩプロセスを使用すべきなのか、第２の変更ＩＢＤＩプロセスを使用すべきなのかを示すための追加のインジケータ（たとえば、フラグ）が実装され得る。そのようなインジケータは、上記で説明したように、ＳＰＳ、ＳＥＩメッセージなど中に与えられ得る。たとえば、インジケータが真である場合、変更ＩＢＤＩプロセスが一連のピクチャのために使用され得る。代替的に、インジケータが偽である場合、現在ＩＢＤＩプロセスが一連のピクチャのために使用され得る。

【0117】

上記で説明した出力ビット深度インジケータについて、概して、ビデオデコーダ３０に関して説明するが、そのようなインジケータは、１つまたは複数のデバイスによって生成および／または送信され得ることを理解されたい。たとえば、上記で説明したディスプレイビット深度インジケータは、ビデオエンコーダ２０（図１および図２）、（上記のＤＡＳＨ例に関して説明したように）コンテンツを与えるためのサーバまたは他の構成要素、他のプロセッサ、処理ユニット、エンコーダ／デコーダ（コーデック）などのハードウェアベースのコーディングユニットなどを含む、様々なビデオコーダによって生成され得る。

【0118】

本開示の態様によれば、ビデオデコーダ３０は、出力ビット深度インジケータを受信し、受信した出力ビット深度インジケータに基づいて、増加したビット深度で復号ピクチャを出力すべきなのか、元のビット深度で復号ピクチャを出力すべきなのかを決定し得る。ビデオデコーダ３０が、増加したビット深度において復号ピクチャを出力する例では、ＩＢＤＩモジュール１３１Ｂは、復号ピクチャを参照ピクチャメモリ１４２に記憶するより前に、復号ピクチャを改変しないことがある。すなわち、上述のように、ＩＢＤＩが実装されるとき、ＩＢＤＩモジュール１３１Ａは、いくつかの内部コーディング演算を実行するより前に、ビデオデータのビット深度を増加させ得る。ビデオデコーダ３０が、増加したビット深度において復号ピクチャを出力するとき、ＩＢＤＩモジュール１３１Ｂは、復号ピクチャを参照ピクチャメモリ１４２に記憶するより前に、ビデオデータのビット深度を丸めないことがある。したがって、ビデオデコーダ３０は、増加したビット深度において（たとえば、ディスプレイデバイス３２（図１）などのディスプレイにおける提示のために）参照ピクチャメモリ１４２からの復号ピクチャを出力し得る。

【0119】

代替的に、ビデオデコーダ３０が非ＩＢＤＩビット深度において復号ピクチャを出力する例では、ＩＢＤＩモジュール１３１Ｂは、復号ピクチャを参照ピクチャメモリ１４２に記憶するときに、本開示で説明する技法を実装し得る。すなわち、いくつかの例では、ＩＢＤＩモジュール１３１Ｂは、参照ピクチャとして使用されるピクチャのサンプルを改変しないことがある。そうではなく、ビデオデコーダ３０は、ＩＢＤＩ（増加した）ビット深度で復号ピクチャを参照ピクチャメモリ１４２に記憶し得る。対照的に、本開示の態様によれば、ＩＢＤＩモジュール１３１Ｂは、参照ピクチャとして使用されないピクチャのサンプルを丸め得る。

【0120】

ＩＢＤＩモジュール１３１は別々のモジュールとして示されているが、そのようなＩＢＤＩモジュール１３１は、高度に統合され、および／または単一のモジュールに組み込まれ得ることを理解されたい。さらに、説明のために個別モジュールとして示されているが、ＩＢＤＩモジュール１３１は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得ることを理解されたい。

【0121】

図５は、ビデオコーディングに関連する動作を実行するときにビット深度を増加させることを示すブロック図である。図５に示す例について、概して、ビデオコーダによって実行されるものとして説明する。いくつかの例では、図５の技法は、上記で説明したビデオエンコーダ２０（図１および図２）またはビデオデコーダ３０（図１および図３）によって行われ得ることを理解されたい。他の例では、図５の技法は、様々な他のプロセッサ、処理ユニット、エンコーダ／デコーダ（コーデック）などのハードウェアベースのコーディングユニットなどによって実行され得る。

【0122】

図５に示す例では、ビデオコーダは、上記で説明したものなどのＩＢＤＩプロセスを使用して、増加したビット深度でビデオデータに対して１つまたは複数のビデオコーディング演算を実行する（１６０）。たとえば、ビデオコーダは、ビット深度８を有するビデオデータの１つまたは複数のサンプルを受信し得、ビット深度を８から１０、１２、または別のより高いビット深度に増加させ得る。ビデオコーダは、フレーム内予測を実行すること、（サブピクセル補間を含む）１つまたは複数の補間フィルタを適用すること、１つまたは複数のデブロッキングフィルタを適用すること、１つまたは複数の空間変換（または逆変換）を適用すること、量子化を実行すること、または他のプロセスを実行することなど、増加したビット深度を使用してビデオデータに対して演算を実行し得る。

【0123】

ビデオコーダはまた、増加したビット深度でビデオデータ、すなわち、復号ピクチャを出力すべきかどうかを決定する（１６２）。本開示の態様によれば、ビデオコーダは、たとえば、受信した出力ビット深度インジケータに基づいて、そのような決定を行い得る。上記で説明したように、インジケータは、ＳＰＳ、ＳＥＩメッセージなど中に含まれている出力ディスプレイビット深度フラグを含み得る。他の例では、インジケータは、（たとえば、ＩＳＯベースメディアファイルフォーマットの拡張として）ファイルフォーマット、プロファイルおよびレベル情報を含んでいるサンプル中で与えられる１つまたは複数のシンタックス要素、記述子（たとえば、ＭＰＥＧ−２記述子）、または（たとえば、ＤＡＳＨ環境において）ＭＰＤファイル中で与えられ得る。さらに他の例では、ディスプレイデバイス（たとえば、図１に示したディスプレイデバイス３２）など、ビデオコーダの外部にあるデバイスは、たとえば、遠隔制御を通して出力ビット深度を決定し得る。

【0124】

図５に示す例では、ビデオコーダが、増加したビット深度でビデオデータを出力すべきである場合（たとえば、ステップ１６２のＹＥＳブランチ）、ビデオコーダは、増加したビット深度でビデオデータを（たとえば、復号ピクチャバッファに）記憶する（１６４）。ビデオコーダが、増加したビット深度でビデオデータを出力すべきでない場合（たとえば、ステップ１６２のＮＯブランチ）、ビデオコーダは、ビデオデータが参照データとして使用されるかどうかを決定する（１６６）。本開示の態様によれば、ビデオデータが参照データとして使用される場合（たとえば、１６６のＹＥＳブランチ）、ビデオコーダは、増加したビット深度でビデオデータを記憶する（１６４）。

【0125】

ビデオデータが参照データとして使用されない場合（たとえば、１６６のＮＯブランチ）、ビデオコーダは、ビデオデータのビット深度を低減する（１６８）。たとえば、いくつかのピクチャ（たとえば、いくつかのＢフレームなど）は参照ピクチャとして使用されないことがある。その上、いくつかの事例では、ビデオコーダは、あるビデオデータを「参照のために使用されない」とマークし得る。そのような例では、ビデオコーダは、ビット深度をＩＢＩＤ動作のために使用される増加したビット深度から元のビット深度に低減し得る。ビデオコーダは、次いで、減少したビット深度でビデオデータを記憶する（１７０）。

【0126】

図５に示す例は、ビデオデータを符号化および／または復号することに関連するメモリ要件を低減し得る。たとえば、図５の例に示す技法は、より少数のビットのデータが記憶されることを可能にし得、これは、メモリ要件ならびにメモリ帯域幅消費量を低減し得る。

【0127】

図５に示すステップは一例として与えたものにすぎないことを理解されたい。すなわち、本開示のいくつかの態様によれば、ビデオコーダは、ビデオデータが参照として使用されるかどうかにかかわらず、元のビット深度（たとえば、非ＩＢＤＩビット深度）でビデオデータを維持し得る。この変更ＩＢＤＩプロセスによれば、ビデオコーダは、ビデオデータがいくつかのプロセス（たとえば、動き補償、サブピクセル補間、量子化、変換、および再構成に関連する内部コーディングプロセス）のために使用されるときにビット深度を増加させ得るが、次いで、メモリ帯域幅消費量を低減するために、ビデオデータを記憶するより前に、すべての復号ビデオデータのビット深度を減少させ得る。

【0128】

さらに、図５の方法のステップは、必ずしも図５に示す順序で実行される必要があるとは限らず、より少数の、追加の、または代替のステップが実行され得る。たとえば、メモリ利用管理を対象とする本開示の態様（たとえば、ステップ１６６〜１６８）は、上記で説明したように、出力ビット深度を決定することを対象とする本開示の態様（たとえば、ステップ１６２）とは無関係に実行され得る。

【0129】

その上、例によっては、本明細書で説明した技法のうちのいずれかの、いくつかの行為またはイベントは、異なるシーケンスで実行され得、追加、マージ、または完全に除外され得る（たとえば、すべての説明した行為またはイベントが、本方法の実施のために必要であるとは限らない）ことをも理解されたい。さらに、いくつかの例では、行為またはイベントは、連続的にではなく、たとえば、マルチスレッド処理、割込み処理、または複数のプロセッサを通して、同時に実行され得る。

【0130】

１つまたは複数の例では、説明した機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。ソフトウェアで実装される場合、機能は、１つまたは複数の命令またはコードとしてコンピュータ可読媒体上に記憶されるか、あるいはコンピュータ可読媒体を介して送信され、ハードウェアベースの処理ユニットによって実行され得る。コンピュータ可読媒体は、たとえば、通信プロトコルに従って、ある場所から別の場所へのコンピュータプログラムの転送を可能にする任意の媒体を含むデータ記憶媒体または通信媒体などの有形媒体に対応するコンピュータ可読記憶媒体を含み得る。

【0131】

このようにして、コンピュータ可読媒体は、概して、（１）非一時的である有形コンピュータ可読記憶媒体、あるいは（２）信号または搬送波などの通信媒体に対応し得る。データ記憶媒体は、本開示で説明した技法の実装のための命令、コードおよび／またはデータ構造を取り出すために１つまたは複数のコンピュータあるいは１つまたは複数のプロセッサによってアクセスされ得る任意の利用可能な媒体であり得る。コンピュータプログラム製品はコンピュータ可読媒体を含み得る。

【0132】

限定ではなく例として、そのようなコンピュータ可読記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭまたは他の光ディスクストレージ、磁気ディスクストレージ、または他の磁気ストレージデバイス、フラッシュメモリ、あるいは命令またはデータ構造の形態の所望のプログラムコードを記憶するために使用され得、コンピュータによってアクセスされ得る、任意の他の媒体を備えることができる。また、いかなる接続もコンピュータ可読媒体と適切に呼ばれる。たとえば、命令が、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者回線（ＤＳＬ）、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用して、ウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、ＤＳＬ、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。

【0133】

ただし、コンピュータ可読記憶媒体およびデータ記憶媒体は、接続、搬送波、信号、または他の一時媒体を含まないが、代わりに非一時的有形記憶媒体を対象とすることを理解されたい。本明細書で使用するディスク（disk）およびディスク（disc）は、コンパクトディスク（disc）（ＣＤ）、レーザーディスク（登録商標）（disc）、光ディスク（disc）、デジタル多用途ディスク（disc）（ＤＶＤ）、フロッピー（登録商標）ディスク（disk）およびブルーレイディスク（disc）を含み、ディスク（disk）は、通常、データを磁気的に再生し、ディスク（disc）は、データをレーザーで光学的に再生する。上記の組合せもコンピュータ可読媒体の範囲内に含めるべきである。

【0134】

命令は、１つまたは複数のデジタル信号プロセッサ（ＤＳＰ）などの１つまたは複数のプロセッサ、汎用マイクロプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブル論理アレイ（ＦＰＧＡ）、あるいは他の等価な集積回路またはディスクリート論理回路によって実行され得る。したがって、本明細書で使用する「プロセッサ」という用語は、前述の構造、または本明細書で説明した技法の実装に好適な他の構造のいずれかを指すことがある。さらに、いくつかの態様では、本明細書で説明した機能は、符号化および復号のために構成された専用のハードウェアおよび／またはソフトウェアモジュール内に与えられ得、あるいは複合コーデックに組み込まれ得る。また、本技法は、１つまたは複数の回路または論理要素中に十分に実装され得る。

【0135】

本開示の技法は、ワイヤレスハンドセット、集積回路（ＩＣ）またはＩＣのセット（たとえば、チップセット）を含む、多種多様なデバイスまたは装置において実装され得る。本開示では、開示する技法を実行するように構成されたデバイスの機能的態様を強調するために様々な構成要素、モジュール、またはユニットについて説明したが、それらの構成要素、モジュール、またはユニットを、必ずしも異なるハードウェアユニットによって実現する必要があるとは限らない。むしろ、上記で説明したように、様々なユニットが、好適なソフトウェアおよび／またはファームウェアとともに、上記で説明した１つまたは複数のプロセッサを含めて、コーデックハードウェアユニットにおいて組み合わせられるか、または相互動作ハードウェアユニットの集合によって与えられ得る。

【0136】

本開示の様々な態様について説明した。これらおよび他の態様は以下の特許請求の範囲内に入る。
以下に、本願の出願当初請求項に記載された発明を付記する。
［Ｃ１］
ビデオデータをコーディングする方法であって、
ビデオデータを出力するための第１のビット深度と、前記ビデオデータをコーディングするための第２のビット深度とを決定することであって、前記第１のビット深度が前記第２のビット深度よりも小さい、決定することと、
前記ビデオデータが、他のビデオデータをコーディングするときに参照データとして使用されるかどうかを決定することと、
前記決定に基づいて、前記ビデオデータが参照データとして使用されないときには前記第１のビット深度で前記ビデオデータを記憶し、前記ビデオデータが参照データとして使用されるときには前記第２のビット深度で前記ビデオデータを記憶することと
を備える方法。
［Ｃ２］
記憶することは、前記ビデオデータが参照データとして使用されないときに前記ビデオデータを前記第２のビット深度から前記第１のビット深度に変換することを含む、上記Ｃ１に記載の方法。
［Ｃ３］
前記ビデオデータを変換することが、前記第２のビット深度を前記第１のビット深度に変換するためにビットシフト演算を前記ビデオデータに対して実行することを含む、上記Ｃ２に記載の方法。
［Ｃ４］
前記ビデオデータが復号ピクチャを備え、前記ビデオデータを記憶することが、前記復号ピクチャを復号ピクチャバッファに記憶することを含む、上記Ｃ１に記載の方法。
［Ｃ５］
前記第１のビット深度で前記ビデオデータを受信することと、内部ビット深度増加（ＩＢＤＩ）プロセス中に、前記ビデオデータをコーディングするより前に前記第１のビット深度を前記第２のビット深度まで増加させることとをさらに備える、上記Ｃ１に記載の方法。
［Ｃ６］
前記ビデオデータをコーディングすることが、前記ビデオデータに対して高精度内部プロセス（ＨＡＩＰ）を実行することを含む、上記Ｃ１に記載の方法。
［Ｃ７］
前記第１のビット深度が８ビットであり、前記第２のビット深度が１０ビットに等しいかまたはそれよりも大きい、上記Ｃ１に記載の方法。
［Ｃ８］
前記第１のビット深度および前記第２のビット深度のうちのいずれにおいて前記ビデオデータを表示すべきかの指示を符号化することをさらに備える、上記Ｃ１に記載の方法。
［Ｃ９］
前記指示を符号化することが、ビデオデータの符号化ビットストリーム中のシーケンスパラメータセット（ＳＰＳ）および補足エンハンスメント情報（ＳＥＩ）メッセージのうちの１つ中に前記指示を含めることを含む、上記Ｃ８に記載の方法。
［Ｃ１０］
出力ビット深度が前記第２のビット深度に等しいかどうかの、ファイルフォーマットおよび記述子のうちの１つ中の指示をコーディングすることをさらに備える、上記Ｃ１に記載の方法。
［Ｃ１１］
前記指示が出力ビット深度の指示を含む、上記Ｃ１０に記載の方法。
［Ｃ１２］
前記ファイルフォーマットが、ＩＳＯベースメディアファイルフォーマットおよびトランスポートストリームフォーマットのうちの１つを含む、上記Ｃ１０に記載の方法。
［Ｃ１３］
前記記述子が、ＨＴＴＰベース動的適応ストリーミング（ＤＡＳＨ）メディアプレゼンテーション記述（ＭＰＤ）記述子を含む、上記Ｃ１０に記載の方法。
［Ｃ１４］
前記指示をコーディングすることが、前記指示を含んでいる前記ファイルフォーマットを復号することと、前記第１のビット深度および前記第２のビット深度のうちのいずれにおいて前記ビデオデータを表示すべきかを決定することとを含む、上記Ｃ１０に記載の方法。
［Ｃ１５］
前記指示をコーディングすることが、前記指示を含んでいる前記記述子を復号することと、前記第１のビット深度および前記第２のビット深度のうちのいずれにおいて前記ビデオデータを表示すべきかを決定することとを含む、上記Ｃ１０に記載の方法。
［Ｃ１６］
前記指示をコーディングすることが、前記指示を含んでいるメディアプレゼンテーション記述（ＭＰＤ）を復号することと、前記第１のビット深度および前記第２のビット深度のうちのいずれにおいて前記ビデオデータを表示すべきかを決定することとを含む、上記Ｃ１０に記載の方法。
［Ｃ１７］
ディスプレイデバイスの構成に基づいて、出力ビット深度が前記第１のビット深度を含むのか前記第２のビット深度を含むのかを決定することをさらに備える、上記Ｃ１に記載の方法。
［Ｃ１８］
ビデオデータをコーディングするための装置であって、
ビデオデータを出力するための第１のビット深度と、前記ビデオデータをコーディングするための第２のビット深度とを決定することであって、前記第１のビット深度が前記第２のビット深度よりも小さい、決定することと、
前記ビデオデータが、他のビデオデータをコーディングするときに参照データとして使用されるかどうかを決定することと、
前記決定に基づいて、前記ビデオデータが参照データとして使用されないときには前記第１のビット深度で前記ビデオデータを記憶し、前記ビデオデータが参照データとして使用されるときには前記第２のビット深度で前記ビデオデータを記憶することと
を行うように構成された１つまたは複数のプロセッサを備える、装置。
［Ｃ１９］
前記ビデオデータを記憶するために、前記１つまたは複数のプロセッサは、前記ビデオデータが参照データとして使用されないときに前記ビデオデータを前記第２のビット深度から前記第１のビット深度に変換するように構成された、上記Ｃ１８に記載の装置。
［Ｃ２０］
前記ビデオデータを変換するために、前記１つまたは複数のプロセッサが、前記第２のビット深度を前記第１のビット深度に変換するためにビットシフト演算を前記ビデオデータに対して実行するように構成された、上記Ｃ１９に記載の装置。
［Ｃ２１］
前記ビデオデータが復号ピクチャを含み、前記ビデオデータを記憶するために、前記１つまたは複数のプロセッサが、前記復号ピクチャを復号ピクチャバッファに記憶するように構成された、上記Ｃ１８に記載の装置。
［Ｃ２２］
前記１つまたは複数のプロセッサが、前記第１のビット深度で前記ビデオデータを受信することと、内部ビット深度増加（ＩＢＤＩ）プロセス中に、前記ビデオデータをコーディングするより前に前記第１のビット深度を前記第２のビット深度まで増加させることとを行うように構成された、上記Ｃ１８に記載の装置。
［Ｃ２３］
前記ビデオデータをコーディングするために、前記１つまたは複数のプロセッサが、前記ビデオデータに対して高精度内部プロセス（ＨＡＩＰ）を実行するように構成された、上記Ｃ１８に記載の装置。
［Ｃ２４］
前記第１のビット深度が８ビットであり、前記第２のビット深度が１０ビットに等しいかまたはそれよりも大きい、上記Ｃ１８に記載の装置。
［Ｃ２５］
前記１つまたは複数のプロセッサが、前記第１のビット深度および前記第２のビット深度のうちのいずれにおいて前記ビデオデータを表示すべきかの指示を符号化するようにさらに構成された、上記Ｃ１８に記載の装置。
［Ｃ２６］
前記指示を符号化するために、前記１つまたは複数のプロセッサが、ビデオデータの符号化ビットストリーム中のシーケンスパラメータセット（ＳＰＳ）および補足エンハンスメント情報（ＳＥＩ）メッセージのうちの１つ中に前記指示を含めるように構成された、上記Ｃ２５に記載の装置。
［Ｃ２７］
前記１つまたは複数のプロセッサは、出力ビット深度が前記第２のビット深度に等しいかどうかの、ファイルフォーマットおよび記述子のうちの１つ中の指示をコーディングするようにさらに構成された、上記Ｃ１８に記載の装置。
［Ｃ２８］
前記指示が出力ビット深度の指示を含む、上記Ｃ２７に記載の装置。
［Ｃ２９］
前記ファイルフォーマットが、ＩＳＯベースメディアファイルフォーマットおよびトランスポートストリームフォーマットのうちの１つを含む、上記Ｃ２７に記載の装置。
［Ｃ３０］
前記記述子が、ＨＴＴＰベース動的適応ストリーミング（ＤＡＳＨ）メディアプレゼンテーション記述（ＭＰＤ）記述子を含む、上記Ｃ２７に記載の装置。
［Ｃ３１］
前記指示をコーディングするために、前記１つまたは複数のプロセッサが、前記指示を含んでいる前記ファイルフォーマットを復号することと、前記第１のビット深度および前記第２のビット深度のうちのいずれにおいて前記ビデオデータを表示すべきかを決定することとを行うように構成された、上記Ｃ２７に記載の装置。
［Ｃ３２］
前記指示をコーディングするために、前記１つまたは複数のプロセッサが、前記指示を含んでいる前記記述子を復号することと、前記第１のビット深度および前記第２のビット深度のうちのいずれにおいて前記ビデオデータを表示すべきかを決定することとを行うように構成された、上記Ｃ２７に記載の装置。
［Ｃ３３］
前記指示をコーディングするために、前記１つまたは複数のプロセッサが、前記指示を含んでいるメディアプレゼンテーション記述（ＭＰＤ）を復号することと、前記第１のビット深度および前記第２のビット深度のうちのいずれにおいて前記ビデオデータを表示すべきかを決定することとを行うように構成された、上記Ｃ２７に記載の装置。
［Ｃ３４］
前記１つまたは複数のプロセッサは、ディスプレイデバイスの構成に基づいて、出力ビット深度が前記第１のビット深度を含むのか前記第２のビット深度を含むのかを決定するようにさらに構成された、上記Ｃ１８に記載の装置。
［Ｃ３５］
ビデオデータをコーディングするための装置であって、
ビデオデータを出力するための第１のビット深度と、前記ビデオデータをコーディングするための第２のビット深度とを決定するための手段であって、前記第１のビット深度が前記第２のビット深度よりも小さい、決定するための手段と、
前記ビデオデータが、他のビデオデータをコーディングするときに参照データとして使用されるかどうかを決定するための手段と、
前記決定に基づいて、前記ビデオデータが参照データとして使用されないときには前記第１のビット深度で前記ビデオデータを記憶し、前記ビデオデータが参照データとして使用されるときには前記第２のビット深度で前記ビデオデータを記憶するための手段と
を備える装置。
［Ｃ３６］
記憶するための手段は、前記ビデオデータが参照データとして使用されないときに前記ビデオデータを前記第２のビット深度から前記第１のビット深度に変換するための手段を含む、上記Ｃ３５に記載の装置。
［Ｃ３７］
前記ビデオデータを変換するための手段が、前記第２のビット深度を前記第１のビット深度に変換するためにビットシフト演算を前記ビデオデータに対して実行するための手段を含む、上記Ｃ３６に記載の装置。
［Ｃ３８］
前記第１のビット深度および前記第２のビット深度のうちのいずれにおいて前記ビデオデータを表示すべきかの指示を前記ビデオデータの符号化ビットストリーム中に含めるための手段をさらに備える、上記Ｃ３５に記載の装置。
［Ｃ３９］
出力ビット深度が前記第２のビット深度に等しいかどうかの、ファイルフォーマットおよび記述子のうちの１つ中の指示をコーディングするための手段をさらに備える、上記Ｃ３５に記載の装置。
［Ｃ４０］
実行されたとき、１つまたは複数のプロセッサに、
ビデオデータを出力するための第１のビット深度と、前記ビデオデータをコーディングするための第２のビット深度とを決定することであって、前記第１のビット深度が前記第２のビット深度よりも小さい、決定することと、
前記ビデオデータが、他のビデオデータをコーディングするときに参照データとして使用されるかどうかを決定することと、
前記決定に基づいて、前記ビデオデータが参照データとして使用されないときには前記第１のビット深度で前記ビデオデータを記憶し、前記ビデオデータが参照データとして使用されるときには前記第２のビット深度で前記ビデオデータを記憶することと
を行わせる命令を記憶した、コンピュータ可読記憶媒体。
［Ｃ４１］
前記ビデオデータを記憶するために、前記命令は、前記１つまたは複数のプロセッサに、前記ビデオデータが参照データとして使用されないときに前記ビデオデータを前記第２のビット深度から前記第１のビット深度に変換させる、上記Ｃ４０に記載のコンピュータ可読記憶媒体。
［Ｃ４２］
前記ビデオデータを変換するために、前記命令が、前記１つまたは複数のプロセッサに、前記第２のビット深度を前記第１のビット深度に変換するためにビットシフト演算を前記ビデオデータに対して実行させる、上記Ｃ４１に記載のコンピュータ可読記憶媒体。
［Ｃ４３］
実行されたとき、前記１つまたは複数のプロセッサに、前記第１のビット深度および前記第２のビット深度のうちのいずれにおいて前記ビデオデータを表示すべきかの指示を前記ビデオデータの符号化ビットストリーム中に含めさせる命令をさらに備える、上記Ｃ４０に記載のコンピュータ可読記憶媒体。
［Ｃ４４］
実行されたとき、前記１つまたは複数のプロセッサに、出力ビット深度が前記第２のビット深度に等しいかどうかの、ファイルフォーマットおよび記述子のうちの１つ中の指示をコーディングさせる命令をさらに備える、上記Ｃ４０に記載のコンピュータ可読記憶媒体。

【図1】

【図2】

【図3】

【図4】

【図5】