(57)【要約】  様々な実装形態では、ISOベースメディアファイルの中でのEOB NALユニットのロケーションに関係する問題を解決するための技法が、本明細書で説明される。様々な実装形態では、これらの技法は、ファイルが1つのEOB NALユニットしか含まないという要件を緩和することを含む。これらの技法は、ビットストリームを再構成するときに最上位レイヤからのEOB NALユニットを提供することをさらに含む。このEOB NALユニットは、再構成ビットストリームの中で最終アクセスユニットに追加され得る。最上位レイヤからのEOB NALユニットが存在しないとき、下位のレイヤからのEOB NALユニットが代わりに提供され得る。
2019506096.tif 000002
【特許請求の範囲】
【請求項１】
符号化ビデオデータを処理するための方法であって、
符号化ビデオデータに関連するファイルを受信するステップであって、前記符号化ビデオデータが、ファイルフォーマットに従って前記ファイルの中に記憶され、前記符号化ビデオデータが、2つ以上のレイヤを含み、前記2つ以上のレイヤが、前記ファイルの中の2つ以上のトラックの中に記憶される、ステップと、
前記2つ以上のレイヤの中から第1のレイヤを決定するステップであって、前記第1のレイヤが、前記2つ以上のレイヤのうちの、ビットストリーム終了インジケータを含む最上位レイヤであると決定される、ステップと、
前記第1のレイヤからの前記ビットストリーム終了インジケータが第1のビットストリーム終了インジケータであると決定するステップと、
前記2つ以上のレイヤの中からレイヤのセットを識別するステップと、
前記第1のビットストリーム終了インジケータおよび複数のアクセスユニットに基づいて、再構成ビットストリームを生成するステップであって、前記複数のアクセスユニットが、レイヤの前記セットからの1つまたは複数のサンプルを含み、前記再構成ビットストリームの中の最終アクセスユニットが、前記第1のビットストリーム終了インジケータを含む、ステップと
を備える方法。
【請求項２】
前記複数のアクセスユニットからアクセスユニットを決定するステップであって、前記アクセスユニットが、前記複数のアクセスユニットの中で最後であり、前記アクセスユニットが、ビットストリーム終了インジケータを含まない、ステップと、
前記第1のビットストリーム終了インジケータを前記アクセスユニットに追加するステップと
をさらに備える、請求項1に記載の方法。
【請求項３】
レイヤの前記セットの中から第2のレイヤを識別するステップであって、前記第2のレイヤが、レイヤの前記セットの中から最上位レイヤとして識別される、ステップと、
前記第1のレイヤが前記第2のレイヤよりも上位のレイヤであると決定するステップと、
前記複数のアクセスユニットからアクセスユニットを決定するステップであって、前記アクセスユニットが、前記複数のアクセスユニットの中で最後である、ステップと、
前記第1のビットストリーム終了インジケータを前記アクセスユニットに追加するステップと
をさらに備える、請求項1に記載の方法。
【請求項４】
レイヤの前記セットの中から第2のレイヤを識別するステップであって、前記第2のレイヤが、レイヤの前記セットの中から最上位レイヤとして識別される、ステップと、
前記第2のレイヤが前記第1のレイヤよりも上位のレイヤであると決定するステップと、
前記複数のアクセスユニットからアクセスユニットを決定するステップであって、前記アクセスユニットが、前記複数のアクセスユニットの中で最後である、ステップと、
前記第1のビットストリーム終了インジケータを前記アクセスユニットに移動させるステップと
をさらに備える、請求項1に記載の方法。
【請求項５】
前記再構成ビットストリームの中の前記最終アクセスユニットが2つ以上のビットストリーム終了インジケータを含むと決定するステップであって、前記2つ以上のビットストリーム終了インジケータが、前記第1のビットストリーム終了インジケータを含む、ステップと、
前記第1のビットストリーム終了インジケータ以外の1つのビットストリーム終了インジケータを前記最終アクセスユニットから除去するステップと
をさらに備える、請求項1に記載の方法。
【請求項６】
前記2つ以上のレイヤの中から少なくとも2つのレイヤが各々、ビットストリーム終了インジケータを含む、請求項1に記載の方法。
【請求項７】
レイヤの前記セットが、レイヤの前記セットの中のレイヤからの前記サンプルが表示用に選択されることに基づいて選択されることを識別するステップ
をさらに備える、請求項1に記載の方法。
【請求項８】
前記ファイルフォーマットが、国際標準化機構(ISO)ベースメディアファイルフォーマットから導出される、請求項1に記載の方法。
【請求項９】
符号化ビデオを処理するための装置であって、
ファイルを記憶するように構成されたメモリであって、前記ファイルが、符号化ビデオデータを含み、前記符号化ビデオデータが、ファイルフォーマットに従って前記ファイルの中に記憶され、前記符号化ビデオデータが、2つ以上のレイヤを含み、前記2つ以上のレイヤが、前記ファイルの中の2つ以上のトラックの中に記憶される、メモリと、
プロセッサとを備え、前記プロセッサが、
前記2つ以上のレイヤの中から第1のレイヤを決定することであって、前記第1のレイヤが、前記2つ以上のレイヤのうちの、ビットストリーム終了インジケータを含む最上位レイヤであると決定される、決定することと、
前記第1のレイヤからの前記ビットストリーム終了インジケータが第1のビットストリーム終了インジケータであると決定することと、
前記2つ以上のレイヤの中からレイヤのセットを識別することと、
前記第1のビットストリーム終了インジケータおよび複数のアクセスユニットに基づいて、再構成ビットストリームを生成することであって、前記複数のアクセスユニットが、レイヤの前記セットからの1つまたは複数のサンプルを含み、前記再構成ビットストリームの中の最終アクセスユニットが、前記第1のビットストリーム終了インジケータを含む、生成することと
を行うように構成される、装置。
【請求項１０】
前記プロセッサが、
前記複数のアクセスユニットからアクセスユニットを決定することであって、前記アクセスユニットが、前記複数のアクセスユニットの中で最後であり、前記アクセスユニットが、ビットストリーム終了インジケータを含まない、決定することと、
前記第1のビットストリーム終了インジケータを前記複数のアクセスユニットの中の最終アクセスユニットに追加することと
を行うようにさらに構成される、請求項9に記載の装置。
【請求項１１】
前記プロセッサが、
レイヤの前記セットの中から第2のレイヤを識別することであって、前記第2のレイヤが、レイヤの前記セットの中から最上位レイヤとして識別される、識別することと、
前記第1のレイヤが前記第2のレイヤよりも上位のレイヤであると決定することと、
前記複数のアクセスユニットからアクセスユニットを決定することであって、前記アクセスユニットが、前記複数のアクセスユニットの中で最後である、決定することと、
前記第1のビットストリーム終了インジケータを前記アクセスユニットに追加することと
を行うようにさらに構成される、請求項9に記載の装置。
【請求項１２】
前記プロセッサが、
レイヤの前記セットの中から第2のレイヤを識別することであって、前記第2のレイヤが、レイヤの前記セットの中から最上位レイヤとして識別される、識別することと、
前記第2のレイヤが前記第1のレイヤよりも上位のレイヤであると決定することと、
前記複数のアクセスユニットからアクセスユニットを決定することであって、前記アクセスユニットが、前記複数のアクセスユニットの中で最後である、決定することと、
前記第1のビットストリーム終了インジケータを前記複数のアクセスユニットの中の最終アクセスユニットに移動させることと
を行うようにさらに構成される、請求項9に記載の装置。
【請求項１３】
前記プロセッサが、
前記再構成ビットストリームの中の前記最終アクセスユニットが2つ以上のビットストリーム終了インジケータを含むと決定することであって、前記2つ以上のビットストリーム終了インジケータが、前記第1のビットストリーム終了インジケータを含む、決定することと、
前記第1のビットストリーム終了インジケータ以外の1つのビットストリーム終了インジケータを前記最終アクセスユニットから除去することと
を行うようにさらに構成される、請求項9に記載の装置。
【請求項１４】
前記2つ以上のレイヤの中から少なくとも2つのレイヤが各々、ビットストリーム終了インジケータを含む、請求項9に記載の装置。
【請求項１５】
レイヤの前記セットが、レイヤの前記セットの中のレイヤからの前記サンプルが表示用に選択されることに基づいて選択される、請求項9に記載の装置。
【請求項１６】
前記ファイルフォーマットが、ISOベースメディアファイルフォーマットから導出される、請求項9に記載の装置。
【請求項１７】
命令を記憶したコンピュータ可読記憶媒体であって、前記命令が、1つまたは複数のプロセッサによって実行されたとき、前記1つまたは複数のプロセッサに、
符号化ビデオデータに関連するファイルを受信することであって、前記符号化ビデオデータが、ファイルフォーマットに従って前記ファイルの中に記憶され、前記符号化ビデオデータが、2つ以上のレイヤを含み、前記2つ以上のレイヤが、前記ファイルの中の2つ以上のトラックの中に記憶される、受信することと、
前記2つ以上のレイヤの中から第1のレイヤを決定することであって、前記第1のレイヤが、前記2つ以上のレイヤのうちの、ビットストリーム終了インジケータを含む最上位レイヤであると決定される、決定することと、
前記第1のレイヤからの前記ビットストリーム終了インジケータが第1のビットストリーム終了インジケータであると決定することと、
前記2つ以上のレイヤの中からレイヤのセットを識別することと、
前記第1のビットストリーム終了インジケータおよび複数のアクセスユニットに基づいて、再構成ビットストリームを生成することであって、前記複数のアクセスユニットが、レイヤの前記セットからの1つまたは複数のサンプルを含み、前記再構成ビットストリームの中の最終アクセスユニットが、前記第1のビットストリーム終了インジケータを含む、生成することと
を行わせる、コンピュータ可読記憶媒体。
【請求項１８】
前記1つまたは複数のプロセッサによって実行されたとき、前記1つまたは複数のプロセッサに、
前記複数のアクセスユニットからアクセスユニットを決定することであって、前記アクセスユニットが、前記複数のアクセスユニットの中で最後であり、前記アクセスユニットが、ビットストリーム終了インジケータを含まない、決定することと、
前記第1のビットストリーム終了インジケータを前記アクセスユニットに追加することと
を行わせる命令をさらに備える、請求項17に記載のコンピュータ可読記憶媒体。
【請求項１９】
前記1つまたは複数のプロセッサによって実行されたとき、前記1つまたは複数のプロセッサに、
レイヤの前記セットの中から第2のレイヤを識別することであって、前記第2のレイヤが、レイヤの前記セットの中から最上位レイヤとして識別される、識別することと、
前記第1のレイヤが前記第2のレイヤよりも上位のレイヤであると決定することと、
前記複数のアクセスユニットからアクセスユニットを決定することであって、前記アクセスユニットが、前記複数のアクセスユニットの中で最後である、決定することと、
前記第1のビットストリーム終了インジケータを前記アクセスユニットに追加することと
を行わせる命令をさらに備える、請求項17に記載のコンピュータ可読記憶媒体。
【請求項２０】
前記1つまたは複数のプロセッサによって実行されたとき、前記1つまたは複数のプロセッサに、
レイヤの前記セットの中から第2のレイヤを識別することであって、前記第2のレイヤが、レイヤの前記セットの中から最上位レイヤとして識別される、識別することと、
前記第2のレイヤが前記第1のレイヤよりも上位のレイヤであると決定することと、
前記複数のアクセスユニットからアクセスユニットを決定することであって、前記アクセスユニットが、前記複数のアクセスユニットの中で最後である、決定することと、
前記第1のビットストリーム終了インジケータを前記アクセスユニットに移動させることと
を行わせる命令をさらに備える、請求項17に記載のコンピュータ可読記憶媒体。
【請求項２１】
前記1つまたは複数のプロセッサによって実行されたとき、前記1つまたは複数のプロセッサに、
前記再構成ビットストリームの中の前記最終アクセスユニットが2つ以上のビットストリーム終了インジケータを含むと決定することであって、前記2つ以上のビットストリーム終了インジケータが、前記第1のビットストリーム終了インジケータを含む、決定することと、
前記第1のビットストリーム終了インジケータ以外の1つのビットストリーム終了インジケータを前記最終アクセスユニットから除去することと
を行わせる命令をさらに備える、請求項17に記載のコンピュータ可読記憶媒体。
【請求項２２】
前記2つ以上のレイヤの中から少なくとも2つのレイヤが各々、ビットストリーム終了インジケータを含む、請求項17に記載のコンピュータ可読記憶媒体。
【請求項２３】
レイヤの前記セットが、レイヤの前記セットの中のレイヤからの前記サンプルが表示用に選択されることに基づいて選択される、請求項17に記載のコンピュータ可読記憶媒体。
【請求項２４】
前記ファイルフォーマットが、ISOベースメディアファイルフォーマットから導出される、請求項17に記載のコンピュータ可読記憶媒体。
【請求項２５】
符号化ビデオデータを処理するための装置であって、
符号化ビデオデータに関連するファイルを受信するための手段であって、前記符号化ビデオデータが、ファイルフォーマットに従って前記ファイルの中に記憶され、前記符号化ビデオデータが、2つ以上のレイヤを含み、前記2つ以上のレイヤが、前記ファイルの中の2つ以上のトラックの中に記憶される、手段と、
前記2つ以上のレイヤの中から第1のレイヤを決定するための手段であって、前記第1のレイヤが、前記2つ以上のレイヤのうちの、ビットストリーム終了インジケータを含む最上位レイヤであると決定される、手段と、
前記第1のレイヤからの前記ビットストリーム終了インジケータが第1のビットストリーム終了インジケータであると決定するための手段と、
前記2つ以上のレイヤの中からレイヤのセットを識別するための手段と、
前記第1のビットストリーム終了インジケータおよび複数のアクセスユニットに基づいて、再構成ビットストリームを生成するための手段であって、前記複数のアクセスユニットが、レイヤの前記セットからの1つまたは複数のサンプルを含み、前記再構成ビットストリームの中の最終アクセスユニットが、前記第1のビットストリーム終了インジケータを含む、手段と
を備える装置。
【請求項２６】
前記複数のアクセスユニットからアクセスユニットを決定するための手段であって、前記アクセスユニットが、前記複数のアクセスユニットの中で最後であり、前記アクセスユニットが、ビットストリーム終了インジケータを含まない、手段と、
前記第1のビットストリーム終了インジケータを前記アクセスユニットに追加するための手段と
をさらに備える、請求項25に記載の装置。
【請求項２７】
レイヤの前記セットの中から第2のレイヤを識別するための手段であって、前記第2のレイヤが、レイヤの前記セットの中から最上位レイヤとして識別される、手段と、
前記第1のレイヤが前記第2のレイヤよりも上位のレイヤであると決定するための手段と、
前記複数のアクセスユニットからアクセスユニットを決定するための手段であって、前記アクセスユニットが、前記複数のアクセスユニットの中で最後である、手段と、
前記第1のビットストリーム終了インジケータを前記アクセスユニットに追加するための手段と
をさらに備える、請求項25に記載の装置。
【請求項２８】
レイヤの前記セットの中から第2のレイヤを識別するための手段であって、前記第2のレイヤが、レイヤの前記セットの中から最上位レイヤとして識別される、手段と、
前記第2のレイヤが前記第1のレイヤよりも上位のレイヤであると決定するための手段と、
前記複数のアクセスユニットからアクセスユニットを決定するための手段であって、前記アクセスユニットが、前記複数のアクセスユニットの中で最後である、手段と、
前記第1のビットストリーム終了インジケータを前記アクセスユニットに移動させるための手段と
をさらに備える、請求項25に記載の装置。
【請求項２９】
前記再構成ビットストリームの中の前記最終アクセスユニットが2つ以上のビットストリーム終了インジケータを含むと決定するための手段であって、前記2つ以上のビットストリーム終了インジケータが、前記第1のビットストリーム終了インジケータを含む、手段と、
前記第1のビットストリーム終了インジケータ以外の1つのビットストリーム終了インジケータを前記最終アクセスユニットから除去するための手段と
をさらに備える、請求項25に記載の装置。
【請求項３０】
前記2つ以上のレイヤの中から少なくとも2つのレイヤが各々、ビットストリーム終了インジケータを含む、請求項25に記載の装置。
【請求項３１】
レイヤの前記セットが、レイヤの前記セットの中のレイヤからの前記サンプルが表示用に選択されることに基づいて選択されることを識別するための手段
をさらに備える、請求項25に記載の装置。
【請求項３２】
前記ファイルフォーマットが、国際標準化機構(ISO)ベースメディアファイルフォーマットから導出される、請求項25に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、階層化高効率ビデオコーディング(LHEVCとも呼ばれる、L-HEVC)ビットストリームがファイルの中に記憶される(たとえば、そこに書き込まれる)ときの、ビットストリーム終了(EOB:end of bitstream)ネットワークアブストラクションレイヤ(NAL:Network Abstraction Layer)ユニットの処理に関する。さらに、本出願はまた、特に、HEVCおよびL-HEVCタイルトラックにおける循環参照を回避するための方法、ならびに完全なピクチャのビデオを含む対応するトラックに対する、タイルトラックの相対位置をシグナリングするための方法を含む、HEVCおよびL-HEVCタイルトラックの改善を説明する。
【背景技術】
【０００２】
ビデオコーディング規格は、ITU-T H.261、ISO/IEC MPEG-1 Visual、ITU-T H.262またはISO/IEC MPEG-2 Visual、ITU-T H.263、ISO/IEC MPEG-4 Visual、そのスケーラブルビデオコーディング(SVC:Scalable Video Coding)およびマルチビュービデオコーディング(MVC:Multiview Video Coding)拡張を含むITU-T H.264またはISO/IEC MPEG-4 AVC、ならびにそのスケーラブルコーディング拡張(すなわち、スケーラブル高効率ビデオコーディング、SHVC)およびマルチビュー拡張(すなわち、マルチビュー高効率ビデオコーディング、MV-HEVC)を含みITU-T H.265およびISO/IEC23008-2とも呼ばれる高効率ビデオコーディング(HEVC:High-Efficiency Video Coding)を含む。
【先行技術文献】
【非特許文献】
【０００３】
【非特許文献１】ISO/IEC14496-12のための最新版ドラフトテキスト、http://phenix.int-evry.fr/mpeg/doc_end_user/documents/111_Geneva/wg11/w15177-v6-w15177.zip
【非特許文献２】ISO/IEC14496-15のための最新版ドラフトテキスト、http://phenix.int-evry.fr/mpeg/doc_end_user/documents/112_Warsaw/wg11/w15479-v2-w15479.zip
【発明の概要】
【課題を解決するための手段】
【０００４】
いくつかの実施形態では、階層化高効率ビデオコーディング(L-HEVC)がファイルに書き込まれるときにビットストリーム終了(EOB)ネットワークアクセスレイヤ(NAL)ユニットを提供するための、ならびにそのようなファイルを読み取るための、技法が説明される。
【０００５】
少なくとも一例によれば、符号化ビデオデータに関連するファイルを受信することを含む、符号化ビデオデータを処理するための方法が提供される。符号化ビデオデータは、ファイルフォーマットに従ってファイルの中に記憶され得る。符号化ビデオデータは、2つ以上のレイヤを含むことができる。2つ以上のレイヤは、ファイルの中の2つ以上のトラックの中に記憶され得る。方法は、2つ以上のレイヤの中から第1のレイヤを決定することをさらに含む。第1のレイヤは、2つ以上のレイヤのうちの、ビットストリーム終了インジケータを含む最上位レイヤであると決定され得る。方法は、第1のビットストリーム終了インジケータを決定することをさらに含む。第1のビットストリーム終了インジケータは、第1のレイヤからのビットストリーム終了インジケータであり得る。方法は、2つ以上のレイヤの中からレイヤのセットを選択することをさらに含む。方法は、一連のアクセスユニットを生成することをさらに含む。一連のアクセスユニットは、レイヤのセットからのサンプルを含むことができる。方法は、一連のアクセスユニットおよび第1のビットストリーム終了インジケータを使用して再構成ビットストリームを生成することをさらに含む。再構成ビットストリームの中の最終アクセスユニットは、第1のビットストリーム終了インジケータを含むことができる。
【０００６】
別の例では、ビデオデータを記憶するように構成されたメモリとプロセッサとを含む装置が提供される。プロセッサは、符号化ビデオデータに関連するファイルを受信するように構成されるとともに、それを行うことができる。符号化ビデオデータは、ファイルフォーマットに従ってファイルの中に記憶され得る。符号化ビデオデータは、2つ以上のレイヤを含むことができる。2つ以上のレイヤは、ファイルの中の2つ以上のトラックの中に記憶され得る。プロセッサは、2つ以上のレイヤの中から第1のレイヤを決定するように構成されるとともに、それを行うことができる。第1のレイヤは、2つ以上のレイヤのうちの、ビットストリーム終了インジケータを含む最上位レイヤであると決定され得る。プロセッサは、第1のビットストリーム終了インジケータを決定するように構成されるとともに、それを行うことができる。第1のビットストリーム終了インジケータは、第1のレイヤからのビットストリーム終了インジケータであり得る。プロセッサは、2つ以上のレイヤの中からレイヤのセットを選択するように構成されるとともに、それを行うことができる。プロセッサは、一連のアクセスユニットを生成するように構成されるとともに、それを行うことができる。一連のアクセスユニットは、レイヤのセットからのサンプルを含むことができる。プロセッサは、一連のアクセスユニットおよび第1のビットストリーム終了インジケータを使用して再構成ビットストリームを生成するように構成されるとともに、それを行うことができる。再構成ビットストリームの中の最終アクセスユニットは、第1のビットストリーム終了インジケータを含むことができる。
【０００７】
別の例では、プロセッサによって実行されたとき、方法を実行する命令を記憶したコンピュータ可読媒体が提供され、方法は、符号化ビデオデータに関連するファイルを受信することを含む。符号化ビデオデータは、ファイルフォーマットに従ってファイルの中に記憶され得る。符号化ビデオデータは、2つ以上のレイヤを含むことができる。2つ以上のレイヤは、ファイルの中の2つ以上のトラックの中に記憶され得る。方法は、2つ以上のレイヤの中から第1のレイヤを決定することをさらに含む。第1のレイヤは、2つ以上のレイヤのうちの、ビットストリーム終了インジケータを含む最上位レイヤであると決定され得る。方法は、第1のビットストリーム終了インジケータを決定することをさらに含む。第1のビットストリーム終了インジケータは、第1のレイヤからのビットストリーム終了インジケータであり得る。方法は、2つ以上のレイヤの中からレイヤのセットを選択することをさらに含む。方法は、一連のアクセスユニットを生成することをさらに含む。一連のアクセスユニットは、レイヤのセットからのサンプルを含むことができる。方法は、一連のアクセスユニットおよび第1のビットストリーム終了インジケータを使用して再構成ビットストリームを生成することをさらに含む。再構成ビットストリームの中の最終アクセスユニットは、第1のビットストリーム終了インジケータを含むことができる。
【０００８】
別の例では、符号化ビデオデータに関連するファイルを受信するための手段を含む装置が提供される。符号化ビデオデータは、ファイルフォーマットに従ってファイルの中に記憶され得る。符号化ビデオデータは、2つ以上のレイヤを含むことができる。2つ以上のレイヤは、ファイルの中の2つ以上のトラックの中に記憶され得る。装置は、2つ以上のレイヤの中から第1のレイヤを決定するための手段をさらに備える。第1のレイヤは、2つ以上のレイヤのうちの、ビットストリーム終了インジケータを含む最上位レイヤであると決定され得る。装置は、第1のビットストリーム終了インジケータを決定するための手段をさらに備える。第1のビットストリーム終了インジケータは、第1のレイヤからのビットストリーム終了インジケータであり得る。装置は、2つ以上のレイヤの中からレイヤのセットを選択するための手段をさらに含む。装置は、一連のアクセスユニットを生成するための手段をさらに含む。一連のアクセスユニットは、レイヤのセットからのサンプルを含むことができる。装置は、一連のアクセスユニットおよび第1のビットストリーム終了インジケータを使用して再構成ビットストリームを生成するための手段をさらに含む。再構成ビットストリームの中の最終アクセスユニットは、第1のビットストリーム終了インジケータを含むことができる。
【０００９】
いくつかの態様では、上記で説明した方法、装置、およびコンピュータ可読媒体は、一連のアクセスユニットからの最終アクセスユニットがビットストリーム終了インジケータを含まないと決定することをさらに備える。これらの態様は、第1のビットストリーム終了インジケータを一連のアクセスユニットの中の最終アクセスユニットに追加することをさらに含む。
【００１０】
いくつかの態様では、上記で説明した方法、装置、およびコンピュータ可読媒体は、レイヤのセットの中から第2のレイヤを識別することをさらに備え、第2のレイヤは、レイヤのセットの中から最上位レイヤとして識別される。これらの態様は、第1のレイヤが第2のレイヤよりも上位のレイヤであると決定することをさらに含む。これらの態様は、第1のビットストリーム終了インジケータを一連のアクセスユニットの中の最終アクセスユニットに追加することをさらに含む。
【００１１】
いくつかの態様では、上記で説明した方法、装置、およびコンピュータ可読媒体は、レイヤのセットの中から第2のレイヤを識別することをさらに備え、第2のレイヤは、レイヤのセットの中から最上位レイヤとして識別される。これらの態様は、第2のレイヤが第1のレイヤよりも上位のレイヤであると決定することをさらに含む。これらの態様は、第1のビットストリーム終了インジケータを一連のアクセスユニットの中の最終アクセスユニットに移動させることをさらに含む。
【００１２】
いくつかの態様では、上記で説明した方法、装置、およびコンピュータ可読媒体は、再構成ビットストリームの中の最終アクセスユニットが2つ以上のビットストリーム終了インジケータを含むと決定することをさらに備える。これらの態様では、2つ以上のビットストリーム終了インジケータは、第1のビットストリーム終了インジケータを含む。これらの態様は、第1のビットストリーム終了インジケータ以外の2つ以上のビットストリーム終了インジケータのすべてを最終アクセスユニットから除去することをさらに含む。
【００１３】
いくつかの態様では、2つ以上のレイヤの中から少なくとも2つのレイヤは、ビットストリーム終了インジケータを含む。いくつかの態様では、レイヤのセットは、レイヤのセットの中のレイヤからのサンプルが表示用に選択されることに基づいて選択される。いくつかの態様では、ファイルフォーマットは、ISOベースメディアファイルフォーマットから導出される。
【００１４】
本概要は、特許請求される主題の主要または不可欠な特徴を識別するものでなく、特許請求される主題の範囲を決定するために独立して使用されるものでもない。主題は、本特許の明細書全体、いずれかまたはすべての図面、および各請求項の適切な部分への参照によって理解されるべきである。
【００１５】
上記のことは、他の特徴および実施形態とともに、以下の明細書、特許請求の範囲、および添付図面を参照するとより明らかになろう。
【００１６】
本発明の例示的な実施形態が、以下の図面を参照しながら以下で詳細に説明される。
【図面の簡単な説明】
【００１７】
【図１】符号化デバイスおよび復号デバイスを含むシステムの一例を示すブロック図である。
【図２】階層化HEVCビットストリームの簡略化された例を示す図である。
【図３】ISOBMFFに従ってフォーマットされた、ビデオプレゼンテーションのためのデータおよびメタデータを含むISOベースメディアファイルの一例を示す図である。
【図４】2つのレイヤを含む、ビデオプレゼンテーションのためのISOベースメディアファイルの一例を示す図である。
【図５Ａ】マルチレイヤビットストリームが記憶されているISOベースメディアファイルの一例を示す図である。
【図５Ｂ】図5Aに示すISOベースメディアファイルが異なるデコーダデバイスによって読み取られるときに生じることがある、ビットストリームの例を示す図である。
【図５Ｃ】図5Aに示すISOベースメディアファイルが異なるデコーダデバイスによって読み取られるときに生じることがある、ビットストリームの例を示す図である。
【図６Ａ】マルチ階層化ビットストリームが記憶されているISOベースメディアファイルの別の例を示す図である。
【図６Ｂ】図6Aに示すISOベースメディアファイルを読み取ることから生じることがある、ビットストリームの例を示す図である。
【図６Ｃ】図6Aに示すISOベースメディアファイルを読み取ることから生じることがある、ビットストリームの例を示す図である。
【図７】マルチ階層化ビットストリームが記憶されているISOベースメディアファイルの別の例を示す図である。
【図８Ａ】これらの技法に従って生成されたISOベースメディアファイルの一例を示す図である。
【図８Ｂ】図8Aに示すファイルから構成され得るビットストリームの例を示す図である。
【図８Ｃ】図8Aに示すファイルから構成され得るビットストリームの例を示す図である。
【図８Ｄ】図8Aに示すファイルから構成され得るビットストリームの追加の例を示す図である。
【図８Ｅ】図8Aに示すファイルから構成され得るビットストリームの追加の例を示す図である。
【図９】ISOベースメディアファイルの中に含まれ得るメディアボックスおよびメディアデータボックスの一例を示す図である。
【図１０】符号化ビデオデータを含むファイルが2つ以上のEOB NALユニットを有し得る、符号化ビデオデータを処理するためのプロセスの一例を示す図である。
【図１１】例示的な符号化デバイスを示すブロック図である。
【図１２】例示的な復号デバイスを示すブロック図である。
【発明を実施するための形態】
【００１８】
本開示のいくつかの態様および実施形態が以下に提供される。当業者に明らかになるように、これらの態様および実施形態のうちのいくつかは独立に適用されてよく、それらのうちのいくつかは組み合わせて適用されてよい。以下の説明では、説明の目的で、本開示の実施形態の完全な理解をもたらすように具体的な詳細が説明される。しかしながら、様々な実施形態がこれらの具体的な詳細なしに実践され得ることは明らかであろう。図および説明は限定的であることを意図しない。
【００１９】
以下の説明は、例示的な実施形態のみを提供し、本開示の範囲、適用性、または構成を限定することを意図しない。むしろ、例示的な実施形態の以下の説明は、例示的な実施形態を実施することを可能にする説明を当業者に提供する。添付の特許請求の範囲に記載したような本開示の趣旨および範囲から逸脱することなく、様々な変更が要素の機能および構成に加えられ得ることを理解されたい。
【００２０】
本実施形態の十分な理解をもたらすために、以下の説明において具体的な詳細が与えられる。しかしながら、本実施形態がこれらの具体的な詳細なしに実践され得ることが当業者によって理解されよう。たとえば、不必要な詳細で本実施形態を不明瞭にしないように、回路、システム、ネットワーク、プロセス、および他の構成要素はブロック図の形態で構成要素として示されることがある。他の事例では、本実施形態を不明瞭にすることを避けるために、よく知られている回路、プロセス、アルゴリズム、構造、および技法は、不必要な詳細なしに示されることがある。
【００２１】
また、個々の実施形態がフローチャート、フロー図、データフロー図、構造図、またはブロック図として示されるプロセスとして説明され得ることに留意されたい。フローチャートは逐次プロセスとして動作を説明することがあるが、動作の多くは並列または同時に実行され得る。加えて、動作の順序は並べ替えられてよい。プロセスは、その動作が完了するときに終了するが、図に含まれない追加のステップを有することができる。プロセスは、方法、機能、プロシージャ、サブルーチン、サブプログラムなどに相当し得る。プロセスが関数に相当するとき、その終了は、その関数が呼出し関数またはメイン関数に戻ることに相当し得る。
【００２２】
「コンピュータ可読媒体」という用語は、限定はしないが、ポータブルまたは非ポータブルの記憶デバイス、光記憶デバイス、ならびに命令および/またはデータを記憶、包含、または搬送することができる様々な他の媒体を含む。コンピュータ可読媒体は、データがそこに記憶され得るとともに、ワイヤレスに、または有線接続を介して伝搬する搬送波および/または一時的な電子信号を含まない、非一時的媒体を含み得る。非一時的媒体の例は、限定はしないが、磁気ディスクもしくは磁気テープ、コンパクトディスク(CD)もしくはデジタル多用途ディスク(DVD)などの光記憶媒体、フラッシュメモリ、メモリ、またはメモリデバイスを含み得る。コンピュータ可読媒体は、プロシージャ、関数、サブプログラム、プログラム、ルーチン、サブルーチン、モジュール、ソフトウェアパッケージ、クラス、または命令、データ構造、もしくはプログラムステートメントの任意の組合せを表し得る、その上に記憶されたコードおよび/または機械実行可能命令を有し得る。コードセグメントは、情報、データ、引数、パラメータ、またはメモリ内容を渡すことおよび/または受けることによって、別のコードセグメントまたはハードウェア回路に結合され得る。情報、引数、パラメータ、データなどは、メモリ共有、メッセージパッシング、トークンパッシング、ネットワーク送信などを含む、任意の適切な手段を介して渡されてよく、転送されてよく、または送信されてよい。
【００２３】
さらに、実施形態は、ハードウェア、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語、またはこれらの任意の組合せによって実装されてよい。ソフトウェア、ファームウェア、ミドルウェア、またはマイクロコードで実装されるとき、必要なタスクを実行するためのプログラムコードまたはコードセグメント(たとえば、コンピュータプログラム製品)は、コンピュータ可読媒体または機械可読媒体に記憶され得る。プロセッサは、必要なタスクを実行し得る。
【００２４】
ファイルフォーマット規格は、ビデオデータを(また、場合によってはオーディオデータも)パックまたはアンパックして1つまたは複数のファイルにするための、フォーマットを定義することができる。ファイルフォーマット規格は、国際標準化機構(ISO)ベースメディアファイルフォーマット(ISO/IEC14496-12において定義される、ISOBMFF)、ならびにモーションピクチャエキスパートグループ(MPEG)MPEG-4ファイルフォーマット(ISO/IEC14496-15において定義される)、第3世代パートナーシッププロジェクト(3GPP)ファイルフォーマット(3GPP TS26.244において定義される)、およびアドバンストビデオコーディング(AVC)ファイルフォーマット(ISO/IEC14496-15において定義される)を含む、ISOBMFFから導出される他のファイルフォーマットを含む。ISO/IEC14496-12および14496-15のための最新版のドラフトテキストは、それぞれ、http://phenix.int-evry.fr/mpeg/doc_end_user/documents/111_Geneva/wg11/w15177-v6-w15177.zipおよびhttp://phenix.int-evry.fr/mpeg/doc_end_user/documents/112_Warsaw/wg11/w15479-v2-w15479.zipにおいて入手可能である。
【００２５】
ISOBMFFは、多くのコーデックカプセル化フォーマット(たとえば、AVCファイルフォーマットまたは任意の他の好適なコーデックカプセル化フォーマット)のための、かつ多くのマルチメディアコンテナフォーマット(たとえば、MPEG-4ファイルフォーマット、3GPPファイルフォーマット(3GP)、DVBファイルフォーマット、または任意の他の好適なマルチメディアコンテナフォーマット)のための、基礎として使用される。ISOBMFFベースファイルフォーマットは、ストリーミングメディアとも呼ばれる連続メディアのために使用され得る。
【００２６】
連続メディア(たとえば、オーディオおよびビデオ)に加えて、静的メディア(たとえば、画像)およびメタデータが、ISOBMFFに準拠するファイルの中に記憶され得る。ISOBMFFに従って構造化されたファイルは、ローカルメディアファイル再生、リモートファイルのプログレッシブダウンロード、動的適応ストリーミングオーバーHTTP(DASH)用のセグメントとして、コンテンツがストリーミングされるためのコンテナとして(その場合、コンテナはパケット化命令を含む)、受信されたリアルタイムメディアストリームの記録のため、または他の使用を含む、多くの目的のために使用され得る。
【００２７】
HEVCまたはHEVCの拡張を使用して符号化されるビットストリームは、概して、ビットストリームの末尾においてインジケータを含み、インジケータは、ビットストリームの末尾に到達していることをデコーダに示すことができる。インジケータは、ビットストリーム終了(EOB)ネットワークアブストラクションレイヤ(NAL)ユニットの形態をとることができる。
【００２８】
ビットストリームが複数のレイヤを含むとき、やはりEOB NALユニットはビットストリームの末尾に配置されるが、EOB NALユニットがどこに配置されビットストリームがいつファイルに書き込まれるのかは異なることがあり、デコーダデバイスにとって問題を引き起こすことがある。たとえば、EOB NALユニットが最上位レイヤの中にあり、デコーダデバイスがベースレイヤしか読み取らないとき、EOB NALユニットは失われることがある。別の例として、EOB NALユニットがベースレイヤの中にあり、デコーダデバイスが上位レイヤをレンダリングするように構成されるとき、EOB NALユニットは、再構成ビットストリームの末尾以外のロケーションにおいて、再構成ビットストリームの中に配置され得る。別の例として、ベースレイヤがHEVC以外(たとえば、AVC)のコーデックを使用して符号化され同様にEOB NALユニットを含むとき、EOB NALユニットは、非HEVC NALユニットとして符号化されている。この例では、デコーダデバイスが上位レイヤからのHEVCサンプルをレンダリングするように構成されるとき、デコーダデバイスは、HEVC NALユニットでないEOB NALユニットを受信し得る。
【００２９】
様々な実装形態では、ISOベースメディアファイルの中でのEOB NALユニットのロケーション(たとえば、位置)に関係する問題を解決するための技法が、本明細書で説明される。様々な実装形態では、これらの技法は、ファイルが1つのEOB NALユニットしか含まないという要件を緩和することを含む。これらの技法は、ビットストリームを再構成するときに最上位レイヤからのEOB NALユニットを提供することをさらに含む。最上位レイヤからのEOB NALユニットが存在しないとき、下位のレイヤからのEOB NALユニットが代わりに提供され得る。
【００３０】
ISOベースメディアファイルがタイルトラックを含むとき、様々な問題が起こることがある。たとえば、循環エクストラクタ参照、エクストラクタに起因する重複データ、不要エクストラクタ、タイルトラックのビデオ部分のみが必要とされるときにビットストリームを再構成することに関する仕様がないこと、タイルトラック用のオフセット情報がないこと、および他の問題が発生することがある。これらの問題の様々な解決策が以下で説明される。
【００３１】
図1は、符号化デバイス104および復号デバイス112を含むシステム100の一例を示すブロック図である。符号化デバイス104はソースデバイスの一部であってよく、復号デバイス112は受信デバイスの一部であってよい。ソースデバイスおよび/または受信デバイスは、モバイルもしくは固定の電話ハンドセット(たとえば、スマートフォン、セルラー電話など)、デスクトップコンピュータ、ラップトップもしくはノートブックコンピュータ、タブレットコンピュータ、セットトップボックス、テレビジョン、カメラ、ディスプレイデバイス、デジタルメディアプレーヤ、ビデオゲームコンソール、ビデオストリーミングデバイス、または任意の他の適切な電子デバイスなどの、電子デバイスを含み得る。いくつかの例では、ソースデバイスおよび受信デバイスは、ワイヤレス通信用の1つまたは複数のワイヤレストランシーバを含み得る。本明細書で説明するコーディング技法は、(たとえば、インターネットを介した)ストリーミングビデオ送信、テレビジョン放送もしくは送信、データ記憶媒体に記憶するためのデジタルビデオの符号化、データ記憶媒体に記憶されたデジタルビデオの復号、または他の適用例を含む、様々なマルチメディア用途におけるビデオコーディングに適用可能である。いくつかの例では、システム100は、ビデオ会議、ビデオストリーミング、ビデオ再生、ビデオブロードキャスティング、ゲーミング、および/またはビデオ電話などの適用例をサポートするために、一方向または双方向のビデオ送信をサポートすることができる。
【００３２】
符号化デバイス104(すなわち、エンコーダ)は、符号化ビデオビットストリームを生成するためのビデオコーディング規格またはビデオコーディングプロトコルを使用して、仮想現実ビデオデータを含むビデオデータを符号化するために使用され得る。ビデオコーディング規格は、ITU-T H.261、ISO/IEC MPEG-1 Visual、ITU-T H.262またはISO/IEC MPEG-2 Visual、ITU-T H.263、それぞれ、SVCおよびMVCと呼ばれるそのスケーラブルビデオコーディングおよびマルチビュービデオコーディング拡張を含むISO/IEC MPEG-4 VisualおよびITU-T H.264(ISO/IEC MPEG-4 AVCとも呼ばれる)を含む。より最近のビデオコーディング規格、すなわち高効率ビデオコーディング(HEVC)が、ITU-Tビデオコーディングエキスパートグループ(VCEG:Video Coding Experts Group)とISO/IECムービングピクチャエキスパートグループ(MPEG)とのビデオコーディング共同研究部会(JCT-VC)によって確定された。MV-HEVCと呼ばれるHEVCのマルチビュー拡張、およびSHVCと呼ばれるHEVCのスケーラブル拡張、または任意の他の適切なコーディングプロトコルを含むHEVCの様々な拡張が、マルチレイヤビデオコーディングを扱い、同様にJCT-VCによって開発されている。
【００３３】
本明細書で説明する実装形態は、HEVC規格またはそれの拡張を使用する例を説明する。しかしながら、本明細書で説明する技法およびシステムはまた、AVC、MPEG、それらの拡張、あるいはすでに利用可能であるかまたはまだ利用可能もしくは開発済みでない他の適切なコーディング規格などの、他のコーディング規格に適用可能であり得る。したがって、本明細書で説明する技法およびシステムは特定のビデオコーディング規格を参照しながら説明され得るが、説明がその特定の規格だけに適用されるものと解釈されるべきでないことを当業者なら諒解されよう。
【００３４】
ビデオソース102は、符号化デバイス104にビデオデータを提供し得る。ビデオソース102は、ソースデバイスの一部であってよく、またはソースデバイス以外のデバイスの一部であってもよい。ビデオソース102は、ビデオキャプチャデバイス(たとえば、ビデオカメラ、カメラ付き携帯電話、ビデオ付き携帯電話など)、記憶されたビデオを含むビデオアーカイブ、ビデオデータを提供するビデオサーバもしくはコンテンツプロバイダ、ビデオサーバもしくはコンテンツプロバイダからビデオを受信するビデオフィードインターフェース、コンピュータグラフィックスビデオデータを生成するためのコンピュータグラフィックスシステム、そのようなソースの組合せ、または任意の他の適切なビデオソースを含み得る。ビデオソース102の一例は、インターネットプロトコルカメラ(IPカメラ)を含むことができる。IPカメラは、監視、ホームセキュリティ、または他の好適な適用例のために使用され得るタイプのデジタルビデオカメラである。アナログ閉回路テレビジョン(CCTV:closed circuit television)カメラとは異なり、IPカメラは、コンピュータネットワークおよびインターネットを経由してデータを送ることができ、または受信することができる。
【００３５】
ビデオソース102からのビデオデータは、1つまたは複数の入力ピクチャまたは入力フレームを含み得る。ピクチャまたはフレームは、ビデオの一部である静止画像である。符号化デバイス104のエンコーダエンジン106(または、エンコーダ)は、ビデオデータを符号化して符号化ビデオビットストリームを生成する。いくつかの例では、符号化ビデオビットストリーム(または、「ビデオビットストリーム」もしくは「ビットストリーム」)は、一連の1つまたは複数のコード化ビデオシーケンスである。コード化ビデオシーケンス(CVS:coded video sequence)は、ベースレイヤの中でいくつかの特性を伴うランダムアクセスポイントピクチャを有するアクセスユニット(AU:access unit)で開始し、ベースレイヤの中でいくつかの特性を伴うランダムアクセスポイントピクチャを有する次のAUの直前までの、一連のAUを含む。たとえば、CVSを開始するランダムアクセスポイントピクチャのいくつかの特性は、1に等しいRASLフラグ(たとえば、NoRaslOutputFlag)を含み得る。そうでない場合、ランダムアクセスポイントピクチャ(0に等しいRASLフラグを有する)はCVSを開始しない。アクセスユニット(AU)は、1つまたは複数のコード化ピクチャ、および同じ出力時間を共有するコード化ピクチャに対応する制御情報を含む。ピクチャのコード化スライスは、ビットストリームレベルで、ネットワークアブストラクションレイヤ(NAL:network abstraction layer)ユニットと呼ばれるデータ単位の中にカプセル化される。たとえば、HEVCビデオビットストリームは、NALユニットを含む1つまたは複数のCVSを含み得る。ビデオコーディングレイヤ(VCL)NALユニットおよび非VCL NALユニットを含む、NALユニットの2つのクラスがHEVC規格に存在する。VCL NALユニットは、コード化ピクチャデータの1つのスライスまたはスライスセグメント(以下で説明する)を含み、非VCL NALユニットは、1つまたは複数のコード化ピクチャに関係する制御情報を含む。
【００３６】
NALユニットは、ビデオの中のピクチャのコード化表現などの、ビデオデータのコード化表現(たとえば、符号化ビデオビットストリーム、ビットストリームのCVSなど)を形成するビットのシーケンスを含み得る。エンコーダエンジン106は、各ピクチャを複数のスライスに区分することによって、ピクチャのコード化表現を生成する。スライスは、次いで、ルーマサンプルおよびクロマサンプルのコーディングツリーブロック(CTB:coding tree block)に区分される。ルーマサンプルのCTB、およびクロマサンプルの1つまたは複数のCTBは、サンプル用のシンタックスとともにコーディングツリーユニット(CTU:coding tree unit)と呼ばれる。CTUは、HEVC符号化のための基本処理ユニットである。CTUは、様々なサイズの複数のコーディングユニット(CU:coding unit)に分割され得る。CUは、コーディングブロック(CB:coding block)と呼ばれるルーマサンプルアレイおよびクロマサンプルアレイを含む。
【００３７】
ルーマCBおよびクロマCBは、予測ブロック(PB:prediction block)にさらに分割され得る。PBは、インター予測のために同じ動きパラメータを使用するルーマまたはクロマ成分のサンプルのブロックである。ルーマPBおよび1つまたは複数のクロマPBは、関連するシンタックスとともに予測ユニット(PU:prediction unit)を形成する。動きパラメータのセットは、PUごとにビットストリームの中でシグナリングされ、ルーマPBおよび1つまたは複数のクロマPBのインター予測のために使用される。CBはまた、1つまたは複数の変換ブロック(TB:transform block)に区分され得る。TBは、予測残差信号をコーディングするために同じ2次元変換がそこに適用される、色成分のサンプルの正方形ブロックを表す。変換ユニット(TU:transform unit)は、ルーマサンプルおよびクロマサンプルのTB、ならびに対応するシンタックス要素を表す。
【００３８】
CUのサイズは、コーディングノードのサイズに対応し、形状が正方形であり得る。たとえば、CUのサイズは、8×8サンプル、16×16サンプル、32×32サンプル、64×64サンプル、または対応するCTUのサイズまでの任意の他の適切なサイズであってよい。本明細書では、「N×N」という句は、垂直寸法および水平寸法に関してビデオブロックのピクセル寸法(たとえば、8ピクセル×8ピクセル)を指すために使用される。ブロックの中のピクセルは、行および列をなして配置されてよい。いくつかの実施形態では、ブロックは、水平方向において垂直方向と同じ数のピクセルを有しなくてよい。CUに関連するシンタックスデータは、たとえば、1つまたは複数のPUへのCUの区分を記述し得る。区分モードは、CUがイントラ予測モード符号化されるのか、それともインター予測モード符号化されるのかの間で異なり得る。PUは、形状が非正方形であるように区分されてよい。CUに関連するシンタックスデータはまた、たとえば、CTUによる1つまたは複数のTUへのCUの区分を記述し得る。TUは、形状が正方形または非正方形であってよい。
【００３９】
HEVC規格によれば、変換は、変換ユニット(TU)を使用して実行され得る。TUは、異なるCUに対して異なってよい。TUは、所与のCU内のPUのサイズに基づいてサイズ決定され得る。TUは、同じサイズであってよく、またはPUより小さくてよい。いくつかの例では、CUに対応する残差サンプルは、残差4分木(RQT:residual quad tree)と呼ばれる4分木構造を使用して、より小さいユニットに再分割され得る。RQTのリーフノードは、TUに対応し得る。TUに関連するピクセル差分値は、変換係数を生成するように変換され得る。変換係数は、次いで、エンコーダエンジン106によって量子化され得る。
【００４０】
ビデオデータのピクチャがCUに区分されると、エンコーダエンジン106は、予測モードを使用して各PUを予測する。予測は、次いで、残差(以下で説明する)を得るために元のビデオデータから減算される。CUごとに、予測モードが、シンタックスデータを使用してビットストリームの内部でシグナリングされ得る。予測モードは、イントラ予測(または、イントラピクチャ予測)またはインター予測(または、インターピクチャ予測)を含み得る。イントラ予測を使用すると、たとえば、PUにとっての平均値を見つけるためのDC予測、平坦面をPUに適合させるための平面予測、隣接データから外挿するための方向予測、または任意の他の適切なタイプの予測を使用して、同じピクチャの中の隣接画像データから各PUが予測される。インター予測を使用すると、1つまたは複数の(出力順序において現在ピクチャの前または後の)参照ピクチャの中の画像データからの動き補償予測を使用して、各PUが予測される。ピクチャエリアを、インターピクチャ予測を使用してコーディングすべきか、それともイントラピクチャ予測を使用してコーディングすべきかという決定は、たとえば、CUレベルにおいて行われ得る。いくつかの例では、ピクチャの1つまたは複数のスライスは、スライスタイプが割り当てられる。スライスタイプは、Iスライス、Pスライス、およびBスライスを含む。Iスライス(独立に復号可能なイントラフレーム)は、イントラ予測のみによってコーディングされているピクチャのスライスであり、したがって、Iスライスがスライスの任意のブロックを予測するのにフレーム内のデータしか必要としないので、独立に復号可能である。Pスライス(単方向予測フレーム)は、イントラ予測および単方向インター予測を用いてコーディングされ得るピクチャのスライスである。Pスライス内の各ブロックは、イントラ予測またはインター予測のいずれかを用いてコーディングされる。インター予測が適用されるとき、ブロックは、1つの参照ピクチャのみによって予測され、したがって、参照サンプルは、1つのフレームの1つの参照領域だけからのものである。Bスライス(双方向予測フレーム)は、イントラ予測およびインター予測を用いてコーディングされ得るピクチャのスライスである。Bスライスのブロックは、2つの参照ピクチャから双方向に予測され得、ここで、各ピクチャは1つの参照領域に寄与し、2つの参照領域のサンプルセットが重み付けられて(たとえば、等しい重みを用いて)、双方向予測ブロックの予測信号を生成する。上述のように、1つのピクチャのスライスは、独立にコーディングされる。場合によっては、ピクチャは、ただ1つのスライスとしてコーディングされ得る。
【００４１】
PUは、予測プロセスに関係するデータを含み得る。たとえば、PUがイントラ予測を使用して符号化されるとき、PUは、PU用のイントラ予測モードを記述するデータを含み得る。別の例として、PUがインター予測を使用して符号化されるとき、PUは、PU用の動きベクトルを規定するデータを含み得る。PU用の動きベクトルを規定するデータは、たとえば、動きベクトルの水平成分、動きベクトルの垂直成分、動きベクトルに対する分解能(たとえば、1/4ピクセル精度、または1/8ピクセル精度)、動きベクトルが指す参照ピクチャ、および/または動きベクトル用の参照ピクチャリスト(たとえば、リスト0、リスト1、またはリストC)を記述し得る。
【００４２】
符号化デバイス104は、次いで、変換および量子化を実行し得る。たとえば、予測に続いて、エンコーダエンジン106は、PUに対応する残差値を計算し得る。残差値は、ピクセル差分値を備え得る。予測が実行された後に残ることがある任意の残差データは、ブロック変換を使用して変換され、ブロック変換は、離散コサイン変換、離散サイン変換、整数変換、ウェーブレット変換、または他の適切な変換関数に基づき得る。場合によっては、1つまたは複数のブロック変換(たとえば、サイズ32×32、16×16、8×8、4×4など)が、各CUにおける残差データに適用され得る。いくつかの実施形態では、エンコーダエンジン106によって実施される変換プロセスおよび量子化プロセスのためにTUが使用されてよい。1つまたは複数のPUを有する所与のCUはまた、1つまたは複数のTUを含み得る。以下でさらに詳細に説明するように、残差値は、ブロック変換を使用して変換係数に変換され得、次いで、エントロピーコーディングのためのシリアル化変換係数を生成するために、TUを使用して量子化および走査され得る。
【００４３】
いくつかの実施形態では、CUのPUを使用するイントラ予測コーディングまたはインター予測コーディングに続いて、エンコーダエンジン106は、CUのTUに対する残差データを計算し得る。PUは、空間領域(すなわち、ピクセル領域)におけるピクセルデータを備え得る。TUは、ブロック変換を適用した後の、変換領域における係数を備え得る。前記のように、残差データは、符号化されていないピクチャのピクセルとPUに対応する予測値との間のピクセル差分値に相当し得る。エンコーダエンジン106は、CUに対する残差データを含むTUを形成し得、次いで、TUを変換してCUに対する変換係数を生成し得る。
【００４４】
エンコーダエンジン106は、変換係数の量子化を実行し得る。量子化は、変換係数を量子化することによってさらなる圧縮をもたらして、係数を表すために使用されるデータの量を低減する。たとえば、量子化は、係数の一部または全部に関連するビット深度を低減し得る。一例では、nビット値を有する係数は、量子化の間にmビット値に切り捨てられてよく、nはmよりも大きい。
【００４５】
量子化が実行されると、コード化ビデオビットストリームは、量子化変換係数、予測情報(たとえば、予測モード、動きベクトルなど)、区分情報、および他のシンタックスデータなどの任意の他の適切なデータを含む。コード化ビデオビットストリームの様々な要素が、次いで、エンコーダエンジン106によってエントロピー符号化され得る。いくつかの例では、エンコーダエンジン106は、既定の走査順序を利用して量子化変換係数を走査して、エントロピー符号化され得るシリアル化ベクトルを生成し得る。いくつかの例では、エンコーダエンジン106は適応走査を実行し得る。量子化変換係数を走査してベクトル(たとえば、1次元ベクトル)を形成した後、エンコーダエンジン106は、ベクトルをエントロピー符号化し得る。たとえば、エンコーダエンジン106は、コンテキスト適応型可変長コーディング、コンテキスト適応型バイナリ算術コーディング、シンタックスベースコンテキスト適応型バイナリ算術コーディング、確率間隔区分エントロピーコーディング、または別の適切なエントロピー符号化技法を使用してよい。
【００４６】
符号化デバイス104の出力部110は、符号化ビデオビットストリームデータを構成するNALユニットを、通信リンク120を介して受信デバイスの復号デバイス112へ送り得る。復号デバイス112の入力部114は、NALユニットを受信し得る。通信リンク120は、ワイヤレスネットワーク、有線ネットワーク、または有線ネットワークとワイヤレスネットワークとの組合せによって設けられる、チャネルを含み得る。ワイヤレスネットワークは、任意のワイヤレスインターフェースまたはワイヤレスインターフェースの組合せを含んでよく、任意の適切なワイヤレスネットワーク(たとえば、インターネットまたは他のワイドエリアネットワーク、パケットベースネットワーク、WiFi(商標)、無線周波数(RF)、UWB、WiFi-Direct、セルラー、ロングタームエボリューション(LTE)、WiMax(商標)など)を含んでよい。有線ネットワークは、任意の有線インターフェース(たとえば、ファイバ、イーサネット(登録商標)、電力線イーサネット(登録商標)、同軸ケーブルを介したイーサネット(登録商標)、デジタル信号ライン(DSL)など)を含んでよい。有線ネットワークおよび/またはワイヤレスネットワークは、基地局、ルータ、アクセスポイント、ブリッジ、ゲートウェイ、スイッチなどの様々な機器を使用して実装され得る。符号化ビデオビットストリームデータは、ワイヤレス通信プロトコルなどの通信規格に従って変調されてよく、受信デバイスへ送信されてよい。
【００４７】
いくつかの例では、符号化デバイス104は、符号化ビデオビットストリームデータをストレージ108に記憶し得る。出力部110は、エンコーダエンジン106から、またはストレージ108から、符号化ビデオビットストリームデータを取り出し得る。ストレージ108は、分散されるかまたは局所的にアクセスされる様々なデータ記憶媒体のうちのいずれかを含み得る。たとえば、ストレージ108は、ハードドライブ、ストレージディスク、フラッシュメモリ、揮発性メモリもしくは不揮発性メモリ、または符号化ビデオデータを記憶するための任意の他の適切なデジタル記憶媒体を含み得る。
【００４８】
復号デバイス112の入力部114は、符号化ビデオビットストリームデータを受信し、デコーダエンジン116に、またはデコーダエンジン116によって後で使用できるようにストレージ118に、ビデオビットストリームデータを提供し得る。デコーダエンジン116は、エントロピー復号すること(たとえば、エントロピーデコーダを使用して)、および符号化ビデオデータを構成する1つまたは複数のコード化ビデオシーケンスの要素を抽出することによって、符号化ビデオビットストリームデータを復号し得る。デコーダエンジン116は、次いで、符号化ビデオビットストリームデータを再スケーリングし得、符号化ビデオビットストリームデータにおいて逆変換を実行し得る。残差データが、次いで、デコーダエンジン116の予測ステージに渡される。デコーダエンジン116は、次いで、ピクセルのブロック(たとえば、PU)を予測する。いくつかの例では、逆変換の出力(残差データ)に予測が加算される。
【００４９】
復号デバイス112は、復号ビデオをビデオ宛先デバイス122に出力し得、ビデオ宛先デバイス122は、復号ビデオデータをコンテンツの消費者に表示するためのディスプレイまたは他の出力デバイスを含み得る。いくつかの態様では、ビデオ宛先デバイス122は、復号デバイス112を含む受信デバイスの一部であってよい。いくつかの態様では、ビデオ宛先デバイス122は、受信デバイス以外の別個のデバイスの一部であってよい。
【００５０】
補足エンハンスメント情報(SEI:Supplemental Enhancement information)メッセージが、ビデオビットストリームの中に含まれ得る。たとえば、SEIメッセージは、復号デバイス112によってビットストリームを復号するために必須でない情報(たとえば、メタデータ)を搬送するために使用され得る。この情報は、復号された出力の表示または処理を改善する際に有用である(たとえば、そのような情報は、コンテンツの視認性を改善するためにデコーダ側エンティティによって使用され得る)。
【００５１】
いくつかの実施形態では、ビデオ符号化デバイス104および/またはビデオ復号デバイス112は、それぞれ、オーディオ符号化デバイスおよびオーディオ復号デバイスと統合されてよい。ビデオ符号化デバイス104および/またはビデオ復号デバイス112はまた、1つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、個別論理、ソフトウェア、ハードウェア、ファームウェア、またはそれらの任意の組合せなどの、上記で説明したコーディング技法を実施するために必要な他のハードウェアまたはソフトウェアを含んでよい。ビデオ符号化デバイス104およびビデオ復号デバイス112は、複合エンコーダ/デコーダ(コーデック)の一部としてそれぞれのデバイスの中に統合されてよい。
【００５２】
HEVC規格の拡張は、MV-HEVCと呼ばれるマルチビュービデオコーディング拡張、およびSHVCと呼ばれるスケーラブルビデオコーディング拡張を含む。MV-HEVC拡張およびSHVC拡張は階層化コーディングの概念を共有し、異なるレイヤが符号化ビデオビットストリームの中に含まれる。コード化ビデオシーケンスの中の各レイヤは、固有のレイヤ識別子(ID)によってアドレス指定される。レイヤIDは、NALユニットが関連付けられているレイヤを識別するために、NALユニットのヘッダの中に存在し得る。MV-HEVCでは、異なるレイヤは、ビデオビットストリームの中で同じシーンの異なるビューを表すことができる。SHVCでは、異なる空間解像度(すなわち、ピクチャ解像度)で、または異なる再構成忠実度でビデオビットストリームを表す、異なるスケーラブルレイヤが提供される。スケーラブルレイヤは、(レイヤID=0である)ベースレイヤ、および(レイヤID=1、2、...nである)1つまたは複数のエンハンスメントレイヤを含み得る。ベースレイヤは、HEVCの第1のバージョンのプロファイルに準拠し得、ビットストリームの中の最低利用可能レイヤを表す。エンハンスメントレイヤは、ベースレイヤと比較して増大した空間解像度、時間分解能もしくはフレームレート、および/または再構成忠実度(すなわち、品質)を有する。エンハンスメントレイヤは、階層的に編成され、下位レイヤに依存することがある(または、依存しないこともある)。いくつかの例では、異なるレイヤは、単一標準コーデックを使用してコーディングされ得る(たとえば、すべてのレイヤが、HEVC、SHVC、または他のコーディング規格を使用して符号化される)。いくつかの例では、異なるレイヤは、多標準コーデックを使用してコーディングされ得る。たとえば、ベースレイヤがAVCを使用してコーディングされてよく、1つまたは複数のエンハンスメントレイヤがHEVC規格に対するSHVC拡張および/またはMV-HEVC拡張を使用してコーディングされてよい。概して、レイヤは、VCL NALユニットのセット、および非VCL NALユニットの対応するセットを含む。NALユニットは、特定のレイヤID値が割り当てられる。レイヤが下位レイヤに依存することがあるという意味で、レイヤは階層的であり得る。
【００５３】
概して、レイヤは、VCL NALユニットのセット、および非VCL NALユニットの対応するセットを含む。NALユニットは、特定のレイヤID値が割り当てられる。レイヤが下位レイヤに依存することがあるという意味で、レイヤは階層的であり得る。レイヤセットは、自蔵式であるビットストリーム内で表されるレイヤのセットを参照し、自蔵式とは、レイヤセット内のレイヤが、復号プロセスにおいてレイヤセットの中の他のレイヤに依存し得るが、いかなる他のレイヤにも復号のために依存しないことを意味する。したがって、レイヤセットの中のレイヤは、ビデオコンテンツを表すことができる独立したビットストリームを形成することができる。レイヤセットの中のレイヤのセットは、サブビットストリーム抽出プロセスの動作によって別のビットストリームから取得され得る。レイヤセットは、いくつかのパラメータに従って動作することをデコーダが望むときに復号されるべきレイヤのセットに相当し得る。
【００５４】
図2は、階層化HEVCビットストリーム200の簡略化された例を示す。ビットストリーム200は、MV-HEVCビットストリームおよび/またはSHVCビットストリームであり得る。図示の例では、ビットストリームは、ベースレイヤ202ならびに2つのエンハンスメントレイヤ、すなわち、レイヤ1 212およびレイヤ2 222を含む。ベースレイヤ202は、現在のバージョンよりも前などの特定のバージョンのHEVCに従って符号化され得る。代替として、ベースレイヤ202は、AVCなどの別のコーデックを使用して符号化され得る。これらおよび他の例では、HEVCの最新バージョン以外のコーデックを使用してベースレイヤ202を符号化することは、HEVCの最新バージョンをサポートしない復号デバイス、またはHEVCをサポートしない復号デバイス(たとえば、AVCしかサポートしないデバイス)にとって、後方互換性をもたらすことができる。エンハンスメントレイヤを追加することによって、既存のビットストリームは、別のコーデックのために再符号化される必要がない。
【００５５】
図2の例では、第1のエンハンスメントレイヤ、すなわち、レイヤ1 212は、ベースレイヤ202の中で提供されるものと同じビデオを、ただしもっと高い解像度で提供する。場合によっては、レイヤ1 212の中のピクチャ214は、ベースレイヤ202の中のピクチャ204からのデータを使用して符号化され得る。場合によっては、レイヤ1 212の中のピクチャ214は、独立に符号化され得る。したがって、もっと高い解像度をサポートする復号デバイスは、ベースレイヤ202またはレイヤ1 212をレンダリングすることを選ぶことができる。他の例では、レイヤ1 212は、ベースレイヤ202と同じピクチャ214を、ただし異なるコーデックを使用して提供し得る。
【００５６】
レイヤ2 222は、図示の例において、エンハンスメントレイヤの別の例として提供される。この例では、レイヤ2 222は、レイヤ1 212の中で提供されるものと同じビデオを、ただしもっと高いフレームレートで提供する。したがって、レイヤ2 222は、レイヤ1 212の中に含まれるよりも多くのピクチャ224を含む。場合によっては、レイヤ2 222の中のピクチャ224は、レイヤ1 212の中のピクチャ214および/またはベースレイヤ202の中のピクチャ204を使用して符号化され得る。場合によっては、レイヤ2 222の中のピクチャ224は、独立に符号化され得る。場合によっては、レイヤ2 222の中のいくつかのピクチャ224は他のレイヤからのデータを使用して符号化され得るが、他のピクチャ224は独立に符号化される。
【００５７】
図2に示すもの以外の例では、ビットストリーム200の中のレイヤは、たとえば、1つのビデオに対する異なるビュー、1つのピクチャにタイル化(tiled)され得る異なるビデオ、異なるビットレート、異なるフレームレート、異なる解像度で符号化されたピクチャなどを提供し得る。
【００５８】
複数のレイヤを含むビットストリームでは、アクセスユニットは、特定の時間インスタンスに関するピクチャのすべてを含むことができる。たとえば、図2に示す例を参照すると、1つのアクセスユニットは、ベースレイヤ202からのピクチャ、および各々、ベースレイヤ202からのピクチャと同じ時間的瞬間についてエンハンスメントレイヤ212、222に関する、対応するピクチャを含むことができる。場合によっては、アクセスユニットは、一部のレイヤのみからのピクチャを有し得る。たとえば、レイヤ2 222の中のピクチャ224がもっと高いフレームレートで符号化されたので、レイヤ2 222からのいくつかのピクチャ224は、それら自体のアクセスユニットの中に存在し得る。場合によっては、ベースレイヤ202の中のピクチャ204は、エンハンスメントレイヤ212、222の中に対応するピクチャを有しないことがあり、したがって、これらのピクチャ204を含むアクセスユニットは、いかなる他のピクチャも含まないことがある。
【００５９】
前に説明したように、HEVCビットストリームは、VCL NALユニットおよび非VCL NALユニットを含むNALユニットのグループを含む。非VCL NALユニットは、他の情報に加えて、符号化ビデオビットストリームに関係する高レベル情報を有するパラメータセットを含み得る。たとえば、パラメータセットは、ビデオパラメータセット(VPS:video parameter set)、シーケンスパラメータセット(SPS:sequence parameter set)、およびピクチャパラメータセット(PPS:picture parameter set)を含み得る。パラメータセットの目的の例は、ビットレート効率、エラーレジリエンシー、およびシステムレイヤインターフェースを提供することを含む。各スライスは、スライスを復号するために復号デバイス112が使用し得る情報にアクセスするために、単一のアクティブなPPS、SPS、およびVPSを参照する。識別子(ID)は、パラメータセットごとにコーディングされてよく、VPS ID、SPS ID、およびPPS IDを含む。SPSは、SPS IDおよびVPS IDを含む。PPSは、PPS IDおよびSPS IDを含む。各スライスヘッダは、PPS IDを含む。IDを使用して、アクティブなパラメータセットが所与のスライスに対して識別され得る。
【００６０】
VCL NALユニットは、コード化ビデオビットストリームを形成するコード化ピクチャデータを含む。様々なタイプのVCL NALユニットが、HEVC規格において定義される。単一レイヤビットストリームでは、最初のHEVC規格において定義されるように、AUの中に含まれるVCL NALユニットは同じNALユニットタイプ値を有し、NALユニットタイプ値は、AUのタイプおよびAU内のコード化ピクチャのタイプを定義する。たとえば、特定のAUのVCL NALユニットは、瞬時復号リフレッシュ(IDR:instantaneous decoding refresh)NALユニット(値19)を含み得、AUをIDR AUにし、AUのコード化ピクチャをIDRピクチャにする。所与のタイプのVCL NALユニットは、VCL NALユニットの中に含まれるピクチャまたはピクチャの部分(たとえば、VCL NALユニットの中のピクチャのスライスまたはスライスセグメント)に関係する。リーディングピクチャ、トレーリングピクチャ、およびイントラランダムアクセス(IRAP)ピクチャ(「ランダムアクセスピクチャ」とも呼ばれる)を含む、3つのクラスのピクチャが、HEVC規格において定義される。マルチレイヤビットストリームでは、AU内のピクチャのVCL NALユニットは、同じNALユニットタイプ値、および同じタイプのコード化ピクチャを有する。たとえば、タイプIDRのVCL NALユニットを含むピクチャは、AUにおけるIDRピクチャであると言われる。別の例では、ベースレイヤ(レイヤIDが0に等しい)におけるIRAPピクチャであるピクチャをAUが含むとき、AUはIRAP AUである。
【００６１】
HEVCビットストリームは、ビットストリーム終了(EOB)NALユニットをさらに含むことができる。EOB NALユニットは、ビットストリームの末尾に到達していることを示す。エンコーダは、一般に、EOB NALユニットを生成し、HEVCビットストリームにとって、EOB NALユニットはビットストリームの最終AUの中の最終NALユニットである。
【００６２】
上記で説明したように符号化されたビデオビットストリームは、符号化デバイス104から復号デバイス112へビットストリームを転送するために、1つまたは複数のファイルの中に書き込まれ得るか、またはパックされ得る。たとえば、出力部110は、ビットストリームを含む1つまたは複数のファイルを生成するように構成されたファイル書込みエンジンを含み得る。出力部110は、通信リンク120を介して1つまたは複数のファイルを復号デバイス112へ送信することができる。代替または追加として、1つまたは複数のファイルは、後で復号デバイス112へ送信できるように記憶媒体(たとえば、テープ、磁気ディスク、もしくはハードドライブ、またはいくつかの他の媒体)上に記憶され得る。
【００６３】
復号デバイス112は、たとえば、入力部114の中に、ファイルパーシングエンジンを含むことができる。ファイルパーシングエンジンは、通信リンク120を介してまたは記憶媒体から受信されたファイルを読み取ることができる。ファイルパーシングエンジンは、さらにファイルからサンプルを抽出でき、デコーダエンジン116による復号のためにビットストリームを再構成することができる。場合によっては、再構成ビットストリームは、エンコーダエンジン106によって生成されたビットストリームと同じであり得る。場合によっては、エンコーダエンジン106は、ビットストリームを復号するためのいくつかの可能なオプションを用いてビットストリームを生成していることがあり、その場合、再構成ビットストリームは、ただ1つの、または全部よりも少ない可能なオプションを含み得る。
【００６４】
上記で説明したように符号化されたビットストリームは、ISOBMFF、ISOBMFFから導出されるファイルフォーマット、いくつかの他のファイルフォーマット、および/またはISOBMFFを含むファイルフォーマットの組合せを使用して、ファイルに書き込まれ得る。上述のように、ファイルに書き込まれるとき、ビットストリームは、復号デバイスに記憶および/または送信され得、復号デバイスは、ビットストリームのコンテンツをレンダリングおよび表示することができる。
【００６５】
図3は、ISOBMFFに従ってフォーマットされた、ビデオプレゼンテーションのためのデータおよびメタデータを含むISOベースメディアファイル300の一例を示す。ISOBMFFは、メディアの交換、管理、編集、および提示を容易にするフレキシブルかつ拡張可能なフォーマットの中に、時限メディア情報を含めるように設計されている。メディアの提示は、プレゼンテーションを含むシステムに対して「ローカル」であってよく、または提示はネットワークもしくは他のストリーム配信メカニズムを介してよい。
【００６６】
ISOBMFF仕様によって定義されるような「プレゼンテーション」は、しばしば、ビデオキャプチャデバイスによって連続的にキャプチャされていることによって関連するか、またはいくつかの他の理由のために関連する、ピクチャのシーケンスである。本明細書では、プレゼンテーションは、ムービープレゼンテーションまたはビデオプレゼンテーションと呼ばれることもある。プレゼンテーションは、オーディオを含んでよい。単一のプレゼンテーションが1つまたは複数のファイルの中に含まれてよく、1つのファイルが、全体のプレゼンテーションのためのメタデータを含む。メタデータは、タイミングおよびデータのフレーミングなどの情報、デスクリプタ、ポインタ、パラメータ、ならびにプレゼンテーションを記述する他の情報を含む。メタデータは、ビデオおよび/またはオーディオデータ自体を含まない。メタデータを含むファイル以外のファイルは、ISOBMFFに従ってフォーマットされる必要がなく、これらのファイルがメタデータによって参照され得るようにフォーマットされるだけでよい。
【００６７】
ISOベースメディアファイルのファイル構造はオブジェクト指向であり、ファイルの中の個々のオブジェクトの構造はオブジェクトのタイプから直接推定され得る。ISOベースメディアファイルの中のオブジェクトは、ISOBMFF仕様によって「ボックス」と呼ばれる。ISOベースメディアファイルは、他のボックスを含むことができる、ボックスのシーケンスとして構造化される。ボックスは、概して、ボックスにとってのサイズおよびタイプを提供するヘッダを含む。サイズは、ヘッダ、フィールド、およびボックス内に含まれるすべてのボックスを含む、ボックスのサイズ全体を記述する。プレーヤデバイスによって認識されないタイプを有するボックスは、通常、無視およびスキップされる。
【００６８】
図3の例によって示すように、ファイルのトップレベルにおいて、ISOベースメディアファイル300は、ファイルタイプボックス310、ムービーボックス320、および1つまたは複数のムービーフラグメント330a、330nを含むことができる。このレベルにおいて含まれ得るがこの例では表されない他のボックスは、特にフリースペースボックス、メタデータボックス、およびメディアデータボックスを含む。
【００６９】
ISOベースメディアファイルは、ボックスタイプ「ftyp」によって識別されるファイルタイプボックス310を含むことができる。ファイルタイプボックス310は、ファイルを構文解析するのに最も好適なISOBMFF仕様を識別する。この事例における「最も」とは、ISOベースメディアファイル300が、特定のISOBMFF仕様に従ってフォーマットされていることがあるが、仕様の他の反復と互換性がありそうであることを意味する。この最も好適な仕様は、メジャーブランド(major brand)と呼ばれる。プレーヤデバイスは、デバイスがファイルのコンテンツを復号および表示することが可能であるかどうかを決定するために、メジャーブランドを使用することができる。ファイルタイプボックス310はまた、ISOBMFF仕様のバージョンを示すために使用され得るバージョン番号を含むことができる。ファイルタイプボックス310はまた、ファイルがそれと互換性がある他のブランドのリストを含む、互換ブランドのリストを含むことができる。ISOベースメディアファイルは、2つ以上のメジャーブランドと互換性があってよい。
【００７０】
ISOベースメディアファイル300がファイルタイプボックス310を含むとき、ただ1つのファイルタイプボックスがある。ISOベースメディアファイル300は、もっと古いプレーヤデバイスと互換性があるようにファイルタイプボックス310を省略してよい。ISOベースメディアファイル300がファイルタイプボックス310を含まないとき、プレーヤデバイスは、デフォルトのメジャーブランド(たとえば、「mp41」)、マイナーバージョン(たとえば、「0」)、および互換ブランド(たとえば、「mp41」)を想定することができる。ファイルタイプボックス310は、通常、ISOベースメディアファイル300の中でできるだけ早く配置される。
【００７１】
ISOベースメディアファイルは、プレゼンテーションのためのメタデータを含むムービーボックス320をさらに含むことができる。ムービーボックス320は、ボックスタイプ「moov」によって識別される。ISO/IEC14496-12は、プレゼンテーションが、1つのファイルの中に含まれるのか、それとも複数のファイルの中に含まれるのかにかかわらず、ただ1つのムービーボックス320を含むことができると規定する。しばしば、ムービーボックス320は、ISOベースメディアファイルの冒頭の近くにある。ムービーボックス320は、ムービーヘッダボックス322を含み、1つまたは複数のトラックボックス324ならびに他のボックスを含むことができる。
【００７２】
ボックスタイプ「mvhd」によって識別されるムービーヘッダボックス322は、メディア独立型であり全体としてプレゼンテーションに関連する情報を含むことができる。たとえば、ムービーヘッダボックス322は、特にプレゼンテーションにとっての作成時刻、変更時刻、タイムスケール、および/または持続時間などの情報を含むことができる。ムービーヘッダボックス322はまた、プレゼンテーションにおける次のトラックを識別する識別子を含むことができる。たとえば、識別子は、図示の例においてムービーボックス320によって含められるトラックボックス324を指すことができる。
【００７３】
ボックスタイプ「trak」によって識別されるトラックボックス324は、プレゼンテーションに対するトラックのための情報を含むことができる。プレゼンテーションは、1つまたは複数のトラックを含むことができ、ここで、各トラックは、プレゼンテーションの中の他のトラックに依存しない。各トラックは、トラックの中のコンテンツに特有の時間情報および空間情報を含むことができ、各トラックは、メディアボックスに関連し得る。トラックの中のデータはメディアデータであり得、その場合、トラックはメディアトラックであるか、またはデータはストリーミングプロトコル用のパケット化情報であり得、その場合、トラックはヒントトラックである。メディアデータは、たとえば、ビデオデータおよびオーディオデータを含む。図示の例では、例示的なトラックボックス324は、トラックヘッダボックス324aおよびメディアボックス324bを含む。トラックボックスは、トラック参照ボックス、トラックグループボックス、編集ボックス、ユーザデータボックス、メタボックスなどの、他のボックスを含むことができる。
【００７４】
ボックスタイプ「tkhd」によって識別されるトラックヘッダボックス324aは、トラックボックス324の中に含まれるトラックの特性を指定することができる。たとえば、トラックヘッダボックス324aは、特にトラックの作成時刻、変更時刻、持続時間、トラック識別子、レイヤ識別子、グループ識別子、ボリューム、幅、および/または高さを含むことができる。メディアトラックの場合、トラックヘッダボックス324aは、特に、トラックが有効にされているかどうか、トラックがプレゼンテーションの一部として再生されるべきかどうか、またはトラックがプレゼンテーションをプレビューするために使用され得るかどうかをさらに識別することができる。トラックのプレゼンテーションは、概して、プレゼンテーションの冒頭にあると想定される。トラックボックス324は、明示的なタイムラインマップを含むことができる、ここで図示しない編集リストボックスを含むことができる。タイムラインマップは、特に、トラックに対するオフセット時間を指定でき、ここで、オフセットは、トラックに対して、プレゼンテーションの冒頭の後の開始時刻を示す。
【００７５】
図示の例では、トラックボックス324はまた、ボックスタイプ「mdia」によって識別されるメディアボックス324bを含む。メディアボックス324bは、オブジェクト、およびトラックの中のメディアデータについての情報を含むことができる。たとえば、メディアボックス324bは、ハンドラ参照ボックスを含むことができ、ハンドラ参照ボックスは、トラックのメディアタイプ、およびトラックの中のメディアがそれによって提示されるプロセスを識別することができる。別の例として、メディアボックス324bは、メディア情報ボックスを含むことができ、メディア情報ボックスは、トラックの中のメディアの特性を指定することができる。メディア情報ボックスは、サンプルのテーブルをさらに含むことができ、ここで、各サンプルは、たとえば、サンプルに対するデータのロケーションを含む、メディアデータ(たとえば、ビデオデータまたはオーディオデータ)のチャンクを記述する。サンプルに対するデータは、以下でさらに説明するメディアデータボックスの中に記憶される。ほとんどの他のボックスと同様に、メディアボックス324bもメディアヘッダボックスを含むことができる。
【００７６】
図示の例では、例示的なISOベースメディアファイル300はまた、プレゼンテーションの複数のフラグメント330a、330b、330c、330nを含む。フラグメント330a、330b、330c、330nは、ISOBMFFボックスでなく、むしろムービーフラグメントボックス332、およびムービーフラグメントボックス332によって参照されるメディアデータボックス338を記述する。ムービーフラグメントボックス332およびメディアデータボックス338はトップレベルボックスであるが、ここではムービーフラグメントボックス332とメディアデータボックス338との間の関係を示すようにグループ化されている。
【００７７】
ボックスタイプ「moof」によって識別されるムービーフラグメントボックス332は、本来ならムービーボックス320の中に記憶されることになる追加の情報を含めることによって、プレゼンテーションを拡張することができる。ムービーフラグメントボックス332を使用して、プレゼンテーションは増分的に構築され得る。ムービーフラグメントボックス332は、ムービーフラグメントヘッダボックス334およびトラックフラグメントボックス336、ならびにここで図示しない他のボックスを含むことができる。
【００７８】
ボックスタイプ「mfhd」によって識別されるムービーフラグメントヘッダボックス334は、シーケンス番号を含むことができる。プレーヤデバイスは、シーケンス番号を使用して、フラグメント330aがプレゼンテーションのためのデータの次の断片を含むことを確認することができる。場合によっては、ファイルのコンテンツまたはプレゼンテーションのためのファイルは、順序が狂ってプレーヤデバイスに提供されることがある。たとえば、ネットワークパケットは、しばしば、パケットが最初に送信された順序以外の順序で到着することがある。これらの場合、シーケンス番号は、フラグメントにとって正しい順序を決定する際に、プレーヤデバイスを支援することができる。
【００７９】
ムービーフラグメントボックス332はまた、ボックスタイプ「traf」によって識別される1つまたは複数のトラックフラグメントボックス336を含むことができる。ムービーフラグメントボックス332は、トラックフラグメントのセットをトラック当り0個以上含むことができる。トラックフラグメントは、0個以上のトラックランを含むことができ、その各々は、トラックに対するサンプルの連続するランを記述する。トラックフラグメントは、サンプルをトラックに追加することに加えて、空の時間をトラックに追加するために使用され得る。
【００８０】
ボックスタイプ「mdat」によって識別されるメディアデータボックス338は、メディアデータを含む。ビデオトラックの中では、メディアデータボックス338はビデオフレームを含むことになる。メディアデータボックスは、代替または追加として、オーディオデータを含むことができる。プレゼンテーションは、1つまたは複数の個々のファイルの中に含まれる、0個以上のメディアデータボックスを含むことができる。メディアデータは、メタデータによって記述される。図示の例では、メディアデータボックス338の中のメディアデータは、トラックフラグメントボックス336の中に含まれるメタデータによって記述され得る。他の例では、メディアデータボックスの中のメディアデータは、ムービーボックス320の中のメタデータによって記述され得る。メタデータは、メディアデータボックス338内のメディアデータヘッダおよび/またはフリースペースがスキップされ得るような、ファイル300内の絶対オフセットによって、特定のメディアデータを参照することができる。
【００８１】
ISOベースメディアファイル300の中の他のフラグメント330b、330c、330nは、最初のフラグメント330aに対して図示したものと類似のボックスを含むことができ、かつ/または他のボックスを含むことができる。
【００８２】
ISOBMFFは、メディアのローカル再生をサポートすることに加えて、ネットワークを介してメディアデータをストリーミングするためのサポートを含む。1つのムービープレゼンテーションを含む1つまたは複数のファイルは、ヒントトラックと呼ばれる追加のトラックを含むことができ、ヒントトラックは、1つまたは複数のファイルをパケットとして形成および送信する際にストリーミングサーバを支援できる命令を含む。これらの命令は、たとえば、サーバが送るべきデータ(たとえば、ヘッダ情報)またはメディアデータのセグメントへの参照を含むことができる。ファイルは、異なるストリーミングプロトコルに対して別個のヒントトラックを含むことができる。ヒントトラックはまた、ファイルを再フォーマットする必要なくファイルに追加され得る。
【００８３】
メディアデータをストリーミングするための1つの方法は、動的適応ストリーミングオーバーハイパーテキスト転送プロトコル(HTTP)、すなわち、DASH(ISO/IEC33009-1:2014において定義される)である。DASHは、MPEG-DASHとも呼ばれ、従来のHTTPウェブサーバを使用してメディアコンテンツの高品質ストリーミングを可能にする適応ビットレートストリーミング技法である。DASHは、メディアコンテンツを小さいHTTPベースファイルセグメントのシーケンスに分割することによって動作し、ここで、各セグメントは、コンテンツの短い時間区間を含む。DASHを使用すると、サーバは、様々なビットレートでメディアコンテンツを提供することができる。メディアを再生しているクライアントデバイスは、次のセグメントをダウンロードするときに代替のビットレートの中で選択することができ、したがって、変化するネットワーク条件に適応することができる。DASHは、インターネットのHTTPウェブサーバインフラストラクチャを使用して、ワールドワイドウェブを介してコンテンツを配信する。DASHは、メディアコンテンツを符号化および復号するために使用されるコーデックに依存せず、したがって、特にH.264やHEVCなどのコーデックとともに動作する。
【００８４】
ISOBMFF仕様は、DASHとともに使用するために6つのタイプのストリームアクセスポイント(SAP:Stream Access Point)を指定する。最初の2つのSAPタイプ(タイプ1および2)は、H.264/AVCおよびHEVCにおける瞬時復号リフレッシュ(IDR)ピクチャに対応する。たとえば、IDRピクチャは、デコーダにおける復号プロセスを完全にリフレッシュまたは再初期化するとともに新たなコード化ビデオシーケンスを開始するイントラピクチャ(Iピクチャ)である。いくつかの例では、IDRピクチャ、および復号順序においてIDRピクチャに後続する任意のピクチャは、復号順序においてIDRピクチャの前に来るいかなるピクチャにも依存し得ない。
【００８５】
第3のSAPタイプ(タイプ3)は、オープンGOP(ピクチャグループ)ランダムアクセスポイント、したがって、HEVCにおけるブロークンリンクアクセス(BLA:broken link access)ピクチャまたはクリーンランダムアクセス(CRA:clean random access)ピクチャに対応する。たとえば、CRAピクチャもIピクチャである。CRAピクチャは、デコーダをリフレッシュしなくてよく、新たなCVSを開始しなくてよく、CRAピクチャのリーディングピクチャが、復号順序においてCRAピクチャの前に来るピクチャに依存することを可能にする。CRAピクチャ、復号順序においてCRAピクチャの前に来るいかなるピクチャにも依存しないCRAピクチャに関連するリーディングピクチャ、および復号順序と出力順序の両方においてCRAに後続するすべての関連するピクチャを復号することによって、CRAピクチャにおいてランダムアクセスが行われ得る。場合によっては、CRAピクチャは、関連するリーディングピクチャを有しないことがある。いくつかの実施形態では、マルチレイヤの場合、レイヤIDが0よりも大きいレイヤに属するIDRピクチャまたはCRAピクチャは、PピクチャまたはBピクチャであってよいが、これらのピクチャは、IDRピクチャまたはCRAピクチャと同じアクセスユニットに属するとともにIDRピクチャまたはCRAピクチャを含むレイヤよりもレイヤIDが小さい他のピクチャからのレイヤ間予測しか使用することができない。
【００８６】
第4のSAPタイプ(タイプ4)は、漸進的復号リフレッシュ(GDR:gradual decoding refresh)ランダムアクセスポイントに対応する。
【００８７】
図4は、2つのレイヤを含む、ビデオプレゼンテーションのためのISOベースメディアファイル400の一例を示す。上記で説明したように、ビデオプレゼンテーションは、ベースレイヤおよび1つまたは複数のエンハンスメントレイヤを含む、複数のレイヤを含むことができる。図4の例では、ビデオは、レイヤ0の中にベースレイヤ、およびレイヤ1の中にエンハンスメントレイヤを含む。他の例では、ビデオは、2つ以上のエンハンスメントレイヤを含むことができる。
【００８８】
ファイル400のトップレベルにおいて、ISOベースメディアファイル400は、ファイルタイプボックス410、ムービーボックス420、およびレイヤ0およびレイヤ1に対するサンプルに対して2つのメディアデータボックス430a、430bを各々1つ含む。ファイルタイプボックス410は、ファイル400を読み取るのに最も好適なブランド(たとえば、ISOBMFF仕様の反復または導出)を識別することができる。ファイルタイプボックス410はまた、互換ブランドのリスト、すなわち、ファイル400を読み取るのに好適な他のブランドを識別することができる。
【００８９】
ムービーボックス420は、ビデオプレゼンテーションのためのメタデータを含むことができる。ムービーボックス420は、全体としてプレゼンテーションについての情報を含むことができるムービーヘッダボックス422を含むことができる。ムービーボックス420はまた、1つまたは複数のトラックボックスを含むことができる。図示の例では、ムービーボックス420は、レイヤ0に対するメタデータおよびレイヤ1に対するメタデータに対して2つのトラックボックス424a、424bを各々1つ含む。他の例では、レイヤ0とレイヤ1の両方に対するメタデータは、1つのトラックボックスの中に含まれ得る。プレゼンテーションが3つ以上のレイヤを含む例では、レイヤのすべては1つのトラックの中に含まれ得、またはいくつかのトラックはただ1つのレイヤを有することができ、他のトラックは2つ以上のレイヤを有する。
【００９０】
トラックボックス424a、424bの各々は、トラックヘッダボックス426a、426bを含む。トラックヘッダボックス426a、426bは、それぞれのトラックボックス424a、424bによって参照されるトラックの特性を記述することができる。たとえば、トラックヘッダボックス426a、426bは、トラックの中のピクチャに対して、特に幅、高さ、およびレイヤIDを含むことができる。
【００９１】
トラックボックス424a、424bの各々は、各々メディアデータボックス428a、428bをさらに含むことができる。メディアデータボックス428a、428bは、各それぞれのトラックの中に含まれるレイヤの中のサンプルの記述を含む。サンプルのための記述は、たとえば、特に、ファイル400内での(または、別のファイル内での)サンプルのロケーション、時間的にコロケートされたサンプルの記述、および/または参照サンプルの記述を含むことができる。
【００９２】
メディアデータボックス430a、430bは、2つのレイヤに対するサンプルを含む。サンプルは、ISOベースメディアファイル400の中に含まれるメディアに対するデータを含む。図示の例では、サンプルは、ビデオデータおよびオーディオデータを含むことができる。この例では、レイヤ0に対するサンプルは、1つのメディアデータボックス430aの中に位置し、レイヤ1に対するサンプルは、第2のメディアデータボックス430bの中に位置する。他の例では、両方のレイヤに対するサンプルは、同じメディアデータボックスの中に含まれ得る。他の例では、1つのレイヤに対するサンプルは、複数のメディアデータボックスの中に含まれ得る。他の例では、サンプルは、他のファイルの中に含まれ得る。
【００９３】
上記で説明したように、HEVCビットストリームは、ビットストリームの最終アクセスユニットの中の最終NALユニットとして、ビットストリーム終了(EOB)NALユニットを含むことができる。EOB NALユニットは、ビットストリームの末尾に到達していることをデコーダにシグナリングすることができる。ビットストリームがマルチレイヤビットストリームであるとき、エンコーダは、最終アクセスユニットの中のEOB NALユニットをビットストリームの中に適切に配置する。しかしながら、その後にビットストリームがファイルに書き込まれるとき(たとえば、そこに記憶またはその中に記憶されるとき)、EOB NALユニットのロケーションに関係する問題が起こることがある。
【００９４】
図5Aは、マルチレイヤビットストリームが記憶されているISOベースメディアファイル500の一例を示す。図示の例では、ビットストリームは、レイヤ0の中にベースレイヤ、およびレイヤ1の中にエンハンスメントレイヤを含む。例示的なファイル500は、ファイルタイプボックス510をさらに含み、ファイルタイプボックス510は、ファイル500がそれと互換性があるブランド、すなわちISOBMFFの特定の反復またはISOBMFFの導出を指定することができる。ファイル500はまた、ムービーボックス520を含むことができ、ムービーボックス520は、ビットストリームのためのメタデータを含むことができる。例示的なファイル500はまた、メディアデータボックス530a、530bを含み、メディアデータボックス530a、530bは、ビットストリームに対するサンプルを含むことができる。
【００９５】
ムービーボックス520は、この例では、ムービーヘッダボックス522、ならびにトラック0およびトラック1に対する2つのトラックボックス524a、524bを含む。ムービーヘッダボックス522は、全体としてプレゼンテーションを記述する情報を含むことができる。この例では、レイヤ0はトラック0の中にあり、したがって、第1のトラックボックス524aはレイヤ0に対するメタデータを含む。さらに、レイヤ1はトラック1の中にあり、したがって、第2のトラックボックス524bはレイヤ1に対するメタデータを含む。他の例では、両方のレイヤに対するメタデータは、1つのトラックボックスの中にあり得る。他の例では、ビットストリームは、3つ以上のレイヤを含むことができる。これらの例では、いくつかのトラックは、1つのレイヤを含むことができ、かつ/またはいくつかのトラックは、2つ以上のレイヤを含むことができる。
【００９６】
各トラックボックス524a、524bは、この例では、トラックヘッダボックス526a、526b、およびメディアボックス528a、528bを含む。トラックヘッダボックス526a、526bは、トラックを記述することができ、メディアボックス528a、528bは、トラックの中のサンプルの記述を含むことができる。
【００９７】
上記で説明したように、ファイル500の中に記憶されるビットストリームは、EOB NALユニット540を有することができる。図示の例では、エンコーダは、エンハンスメントレイヤ、すなわち、レイヤ1の中のデータの末尾において、EOB NALユニット540を配置した。したがって、この例では、EOB NALユニット540は、トラック1の中に見つけられ得る。
【００９８】
場合によっては、トラック1の中でのEOB NALユニット540の配置は、復号デバイスのファイルパーシングエンジンにとって問題になることがある。図5Bおよび図5Cは、図5Aに示すISOベースメディアファイル500が異なるデコーダデバイスによって読み取られるときに生じることがある、ビットストリーム550、552の例を示す。図5Bにおいて、復号デバイスはトラック0しか読み取らない。したがって、ファイル500から抽出されるビットストリーム550は、各々がベースレイヤからのベースピクチャ564a、564b、564c、564nを含む、一連のアクセスユニット562a、562b、562c、562nを含む。しかしながら、図5Aの例では、EOB NALユニット540はトラック1の中にあったので、EOB NALユニット540は再構成ビットストリーム550の中に含まれない。
【００９９】
図5Bの例では、たとえば、復号デバイスがベースレイヤのみを再生するように構成された(たとえば、エンハンスメントレイヤは表示用に選択されなかった)ので、復号デバイスは、トラック0のみを読み取っていることがある。代替または追加として、復号デバイスは、ベースレイヤしか再生できていないことがある(たとえば、復号デバイスがAVC互換のみであり、ベースレイヤが、AVCを用いて符号化されたビットストリームを含んだ)。復号デバイスは、他の理由のために、場合によってはトラック0のみを読み取っていることがある。
【０１００】
図5Cの例では、復号デバイスは、ファイル500からベースレイヤとエンハンスメントレイヤの両方を抽出した。したがって、得られたビットストリーム552は、各々がベースレイヤからのベースピクチャ564a、564b、564c、564n、およびエンハンスメントレイヤからの拡張ピクチャ566a、566b、566c、566nを含む、一連のアクセスユニット562a、562b、562c、562nを含む。この例では、EOB NALユニット540がエンハンスメントレイヤの中にあったので、エンハンスメントレイヤがファイルから抽出されると、EOB NALユニット540も抽出され、最終アクセスユニット562nの中に適切に配置される。
【０１０１】
図5Cの例では、たとえば、エンハンスメントレイヤが表示用に選択されたが、エンハンスメントレイヤがベースレイヤからのデータを必要としたので、復号デバイスは、トラック0とトラック1の両方を読み取っていることがある。復号デバイスは、他の理由のために、場合によっては両方のトラックを読み取っていることがある。
【０１０２】
図6Aは、マルチ階層化ビットストリームが記憶されているISOベースメディアファイル600の別の例を示す。図示の例では、ビットストリームは、レイヤ0の中にベースレイヤ、およびレイヤ1の中にエンハンスメントレイヤを含む。例示的なファイル600は、ファイルタイプボックス610をさらに含み、ファイルタイプボックス610は、ファイル600がそれと互換性があるブランド、すなわちISOBMFFの特定の反復またはISOBMFFの導出を指定することができる。ファイル600はまた、ムービーボックス620を含むことができ、ムービーボックス620は、ビットストリームのためのメタデータを含むことができる。例示的なファイル600はまた、メディアデータボックス630a、630bを含み、メディアデータボックス630a、630bは、ビットストリームに対するサンプルを含むことができる。
【０１０３】
ムービーボックス620は、この例では、ムービーヘッダボックス622、ならびにトラック0およびトラック1に対する2つのトラックボックス624a、624bを含む。ムービーヘッダボックス622は、全体としてプレゼンテーションを記述する情報を含むことができる。この例では、レイヤ0はトラック0の中にあり、したがって、第1のトラックボックス624aはレイヤ0に対するメタデータを含む。さらに、レイヤ1はトラック1の中にあり、したがって、第2のトラックボックス624bはレイヤ1に対するメタデータを含む。他の例では、両方のレイヤに対するメタデータは、1つのトラックボックスの中にあり得る。他の例では、ビットストリームは、3つ以上のレイヤを含むことができる。これらの例では、いくつかのトラックは、1つのレイヤを含むことができ、かつ/またはいくつかのトラックは、2つ以上のレイヤを含むことができる。
【０１０４】
各トラックボックス624a、624bは、この例では、トラックヘッダボックス626a、626b、およびメディアボックス628a、628bを含む。トラックヘッダボックス626a、626bは、トラックを記述することができ、メディアボックス628a、628bは、トラックの中のサンプルの記述を含むことができる。
【０１０５】
上記で説明したように、ファイル600の中に記憶されるビットストリームは、EOB NALユニット640を有することができる。図示の例では、エンコーダデバイスは、EOB NALユニット640をベースレイヤの中に配置しており、したがって、EOB NALユニット640は、トラック0の中に見つけられ得る。様々な実装形態では、エンコーダデバイスは、符号化制約に起因してEOB NALユニット640をベースレイヤの中に配置することを必要とされていることがある。場合によっては、エンコーダは、別の理由のためにEOB NALユニット640をベースレイヤの中に配置していることがある。たとえば、ビットストリームの中の最終アクセスユニットは、ベースレイヤの中のピクチャのみを含んでいることがある。
【０１０６】
EOB NALユニット640がベースレイヤの中にあるとき、デコーダデバイスにとって問題が生み出されることがある。図6Bおよび図6Cは、図6Aに示すISOベースメディアファイル600を読み取ることから生じることがある、ビットストリーム650、652の例を示す。図6Bにおいて、復号デバイスは、ビットストリームのベースレイヤのみを必要としたので、トラック0のみを読み取るようにファイルパーシングエンジンに命令した。したがって、得られたビットストリーム650は、各々がトラック0から読み取られたベースピクチャ664a、664b、664c、664nを含む、一連のアクセスユニット662a、662b、662c、662nを含む。この例では、ベースレイヤは、EOB NALユニット640を含んだので、図6Bに示すビットストリーム650は、最終アクセスユニット662nの中にEOB NALユニット640を含む。
【０１０７】
図6Cの例では、復号デバイスのファイルパーシングエンジンは、ファイル600からベースレイヤとエンハンスメントレイヤの両方を読み取る。したがって、得られたビットストリーム652は、各々がトラック0から読み取られたベースピクチャ664a、664b、664c、664n、およびトラック1から読み取られた拡張ピクチャ666a、666b、666c、666nを含む、一連のアクセスユニット662a、662b、662c、662nを含む。この例では、各アクセスユニットは、最初にベースレイヤからのNALユニットで、次いでエンハンスメントレイヤからのNALユニットで満たされた。EOB NALユニット640が例示的なファイル600におけるベースレイヤの中にあったので、例示的なビットストリーム652では、EOB NALユニット640は、最終アクセスユニットの中の最終NALユニットでない。したがって、ビットストリーム652は、正しく復号されないことがある。
【０１０８】
図7は、マルチ階層化ビットストリームが記憶されているISOベースメディアファイル700の別の例を示す。図示の例では、ビットストリームは、レイヤ0の中にAVCベースレイヤ、およびHEVCバージョンのAVCベースレイヤを含むレイヤ1の中にエンハンスメントレイヤを含む。ビットストリームが、HEVCに対して再符号化されなかったレガシービットストリームであるので、またはビットストリームが、もっと古いデコーダエンジンを有するデコーダデバイスと互換性があるように作られたので、あるいはいくつかの他の理由のために、ベースレイヤは、AVCを使用して符号化されていることがある。同じビットストリームが、HEVCをサポートするデコーダデバイスを用いて見られ得るように、エンハンスメントレイヤがさらに提供されていることがある。他の例では、ベースレイヤがHEVCコーデックを使用して符号化されなかったサンプルを含むように、ベースレイヤは、AVC以外のコーデックを使用して符号化されていることがある。
【０１０９】
例示的なファイル700は、ファイルタイプボックス710を含み、ファイルタイプボックス710は、ファイル700がそれと互換性があるブランド、すなわちISOBMFFの特定の反復またはISOBMFFの導出を指定することができる。ファイル700はまた、ムービーボックス720を含むことができ、ムービーボックス720は、ビットストリームのためのメタデータを含むことができる。例示的なファイル700はまた、メディアデータボックス730a、730bを含み、メディアデータボックス730a、730bは、ビットストリームに対するサンプルを含むことができる。
【０１１０】
ムービーボックス720は、この例では、ムービーヘッダボックス722、ならびにトラック0およびトラック1に対する2つのトラックボックス724a、724bを含む。ムービーヘッダボックス722は、全体としてプレゼンテーションを記述する情報を含むことができる。この例では、レイヤ0はトラック0の中にあり、したがって、第1のトラックボックス724aはレイヤ0に対するメタデータを含む。さらに、レイヤ1はトラック1の中にあり、したがって、第2のトラックボックス724bはレイヤ1に対するメタデータを含む。他の例では、両方のレイヤに対するメタデータは、1つのトラックボックスの中にあり得る。他の例では、ビットストリームは、3つ以上のレイヤを含むことができる。これらの例では、いくつかのトラックは、1つのレイヤを含むことができ、かつ/またはいくつかのトラックは、2つ以上のレイヤを含むことができる。
【０１１１】
各トラックボックス724a、724bは、この例では、トラックヘッダボックス726a、726b、およびメディアボックス728a、728bを含む。トラックヘッダボックス726a、726bは、トラックを記述することができ、メディアボックス728a、728bは、トラックの中のサンプルの記述を含むことができる。たとえば、トラック0に対するボックス724aの中のトラックヘッダボックス726aおよび/またはメディアボックス728aは、トラック0に対するサンプルがAVCを使用して符号化されたことを示すことができる。同様に、トラック1に対するボックス724bの中のトラックヘッダボックス726bおよび/またはメディアボックス728bは、トラック1に対するサンプルがHEVCを使用して符号化されたことを示すことができる。
【０１１２】
上記で説明したように、ファイル700の中に記憶されるビットストリームは、EOB NALユニット740を有することができる。図示の例では、エンコーダデバイスは、EOB NALユニット740がトラック0の中に見つけられ得るように、EOB NALユニット740をベースレイヤの中に配置している。様々な実装形態では、エンコーダデバイスは、符号化制約に起因してEOB NALユニット740をベースレイヤの中に配置することを必要とされていることがある。場合によっては、エンコーダは、別の理由のためにEOB NALユニット740をベースレイヤの中に配置していることがある。たとえば、ビットストリームの中の最終アクセスユニットは、ベースレイヤの中のピクチャのみを含んでいることがある。これらおよび他の例では、EOB NALユニット740は、AVCコーデックに従って生成されている。
【０１１３】
この例では、デコーダデバイスにとって問題が生み出されることがある。たとえば、デコーダデバイスがHEVC互換であるとき、デコーダデバイスは、ファイル700からベースレイヤとエンハンスメントレイヤの両方を読み取るようにファイルパーシングエンジンに命令し得る。しかしながら、EOB NALユニット740は、ベースレイヤの中にあることに起因して、AVCを使用して生成されたEOB NALユニットである。したがって、ファイル700から読み取られ、得られたビットストリームの末尾において配置されても、得られたビットストリームは、完全にHEVC互換であるとは限らないことがあり、HEVCデコーダデバイスによって適切に処理されないことがある。
【０１１４】
様々な実装形態では、EOB NALユニットに関して上記で説明した問題を克服するために、様々な技法が使用され得る。図8Aは、本開示の技法に従って生成されたISOベースメディアファイル800の一例を示す。図示の例では、ビットストリームは、レイヤ0の中にベースレイヤ、およびレイヤ1の中にエンハンスメントレイヤを含む。例示的なファイル800は、ファイルタイプボックス810をさらに含み、ファイルタイプボックス810は、ファイル800がそれと互換性があるブランド、すなわちISOBMFFの特定の反復またはISOBMFFの導出を指定することができる。ファイル800はまた、ムービーボックス820を含むことができ、ムービーボックス820は、ビットストリームのためのメタデータを含むことができる。例示的なファイル800はまた、メディアデータボックス830a、830bを含み、メディアデータボックス830a、830bは、ビットストリームに対するサンプルを含むことができる。
【０１１５】
ムービーボックス820は、この例では、ムービーヘッダボックス822、ならびにトラック0およびトラック1に対する2つのトラックボックス824a、824bを含む。ムービーヘッダボックス822は、全体としてプレゼンテーションを記述する情報を含むことができる。この例では、レイヤ0はトラック0の中にあり、したがって、第1のトラックボックス824aはレイヤ0に対するメタデータを含む。さらに、レイヤ1はトラック1の中にあり、したがって、第2のトラックボックス824bはレイヤ1に対するメタデータを含む。他の例では、両方のレイヤに対するメタデータは、1つのトラックボックスの中にあり得る。他の例では、ビットストリームは、3つ以上のレイヤを含むことができる。これらの例では、いくつかのトラックは、1つのレイヤを含むことができ、かつ/またはいくつかのトラックは、2つ以上のレイヤを含むことができる。
【０１１６】
各トラックボックス824a、824bは、この例では、トラックヘッダボックス826a、826b、およびメディアボックス828a、828bを含む。トラックヘッダボックス826a、826bは、トラックを記述することができ、メディアボックス828a、828bは、トラックの中のサンプルの記述を含むことができる。
【０１１７】
本開示の様々な実装形態では、ファイル800の中でのEOB NALユニットの配置に関係する問題を克服するための技法は、EOB NALユニット840a、840bが1つまたは複数のトラックの中に存在し得るように、ファイルの中でのEOB NALユニットの存在を緩和することを含む。したがって、図8に示すように、トラック0は、EOB NALユニット840aを含んでも含まなくてもよい。同様に、トラック1も、EOB NALユニット840bを含んでも含まなくてもよい。場合によっては、EOB NALユニット840a、840bは類似であってよい。場合によっては、トラック0の中のEOB NALユニット840aは、トラック1の中のEOB NALユニット840bとは異なってよい。たとえば、トラック0の中のEOB NALユニットは、HEVC以外のコーデックを使用して符号化されていることがあるが、トラック1の中のEOB NALユニットは、HEVCコーデックを使用して符号化された。
【０１１８】
図8Bおよび図8Cは、図8Aに示すファイル800から構成され得るビットストリーム850、852の例を示す。図8Bと図8Cの両方において、デコーダデバイスは、ベースレイヤのみを必要としたので、トラック0のみを読み取るようにファイルパーシングエンジンに命令した。したがって、例示的な各ビットストリーム850、852は、各々がベースレイヤからのベースピクチャ864a、864b、864c、864nを含む、一連のアクセスユニット862a、862b、862c、862nを含む。
【０１１９】
図8Bの例では、トラック0は、ベースレイヤに対するEOB NALユニット840aを含んだが、トラック1は、エンハンスメントレイヤに対するEOB NALユニット840bを含まなかった。この例では、デコーダデバイスのファイルパーシングエンジンは、ベースレイヤがEOB NALユニットを含む最上位レイヤであると決定することができ、そのことは、別のレイヤ(この例では、ベースレイヤ)よりも大きい(たとえば、「より上位の」)レイヤID値に関連する他の「上位」レイヤ(たとえば、エンハンスメントレイヤ)がEOB NALユニットを含まないことを意味する。したがって、ファイルパーシングエンジンは、ベースレイヤからのEOB NALユニット840aを、再構成ビットストリーム850の最終アクセスユニット862nの中に含めてよい。したがって、得られたビットストリーム850は、EOB NALユニット840aに関係するいかなるエラーもなく復号され得る。
【０１２０】
図8Bに示す技法は、トラック0のみがファイル800から読み取られるときに、EOB NALユニット840aが再構成ビットストリーム650の中に含まれることを確実にすることができる。この例では、他のレイヤが考慮されるとはいえ、ファイルパーシングエンジンは、ベースレイヤからのEOB NALユニット840aがビットストリーム650の中で使用するのに適切であると決定することができる。
【０１２１】
図8Cの例では、トラック0はEOB NALユニットを含まなかったがトラック1の中のエンハンスメントレイヤがEOB NALユニット840bを含んだかもしれない。この例では、デコーダデバイスのファイルパーシングエンジンがファイル800を読み取るとき、パーシングエンジンは、ベースレイヤがEOB NALユニットを含まないことを検出するように構成され得る。ファイルパーシングエンジンは、トラックの中のレイヤがEOB NALユニットを含むかどうかを決定するために、最上位レイヤに対するトラック(この例では、トラック1)を読み取る(たとえば、処理する)ようにさらに構成され得る。様々な実装形態では、最上位レイヤトラックがEOB NALユニットを含まないとき、ファイルパーシングエンジンは、EOB NALユニットが位置を特定されるか、またはファイル800がEOB NALユニットを含まないとファイルパーシングエンジンが決定するまで、次の最上位レイヤなどに対するトラックを試みるなどしてよい。図示の例では、トラック1の中にEOB NALユニットを見つけると、ファイルパーシングエンジンは、このEOB NALユニット840bを再構成ビットストリーム852の最終アクセスユニット862nに(たとえば、その中に)配置する(たとえば、含める)ことができる。したがって、得られたビットストリーム852は、EOB NALユニットに関係するいかなるエラーもなく復号され得る。
【０１２２】
代替として、図8Cの例では、トラック0とトラック1の両方がEOB NALユニット840a、840bを含むかもしれない。この場合、いくつかの実装形態では、ファイルパーシングエンジンは、最上位レイヤ(たとえば、この例では、エンハンスメントレイヤ)の中でEOB NALユニット840bの位置を特定し、このEOB NALユニット840bを再構成ビットストリーム852の最終アクセスユニット862nの中に配置するように構成され得る。ベースレイヤからのEOB NALユニット840aを含むいかなる他のEOB NALユニットも廃棄され得る。
【０１２３】
図8Cに示す技法は、デコーダデバイスが、EOB NALユニットを含まないか、または潜在的にデコーダデバイスのデコーダエンジンとの互換性がないEOB NALユニットを含むかのいずれかであるベースレイヤしか必要としないときに生み出され得る問題を回避することができる。たとえば、例示的なファイル800がベースレイヤの中にEOB NALユニットを含まないとき、上位レイヤからのEOB NALユニットが代わりに提供され得る。別の例として、ベースレイヤの中のEOB NALユニットがAVCを使用して符号化されたが、デコーダデバイスがHEVCデコーダエンジンを含むとき、上位レイヤからのHEVC EOB NALユニットが、ベースレイヤの中のEOB NALユニットと置き換えられ得る。
【０１２４】
図8Dおよび図8Eは、図8Aに示すファイル800から構成され得るビットストリーム854、856の追加の例を示す。図8Dと図8Eの両方において、デコーダデバイスは、ベースレイヤとエンハンスメントレイヤの両方を必要としたので、トラック0とトラック1の両方を読み取るようにファイルパーシングエンジンに命令した。したがって、例示的な各ビットストリーム850、852は、各々がベースレイヤからのベースピクチャ864a、864b、864c、864n、およびエンハンスメントレイヤからの拡張ピクチャ868a、868b、868c、868nを含む、一連のアクセスユニット862a、862b、862c、862nを含む。
【０１２５】
図8Dの例では、ベースレイヤとエンハンスメントレイヤの両方が、EOB NALユニット840a、840bを含んだ。この例では、様々な実装形態では、デコーダデバイスのファイルパーシングエンジンは、最上位レイヤ(この例では、エンハンスメントレイヤ)からのEOB NALユニット840bのみを含めるとともに、いかなる他のEOB NALユニット(たとえば、ベースレイヤからのEOB NALユニット840a)も廃棄するように構成され得る。したがって、再構成ファイル854は、エンハンスメントレイヤ(たとえば、最上位レイヤ)からのEOB NALユニット840bのみを含む。
【０１２６】
図8Dに示す技法は、2つ以上のEOB NALユニットを含むか、またはベースレイヤからのEOB NALユニットしか含まないビットストリームを作成することを回避することができる。たとえば、本来ならファイルがベースレイヤの中のEOB NALユニットしか有しないことになるとき、エンハンスメントレイヤの中のEOB NALユニットが許容され、その結果、両方のレイヤを含む再構成ビットストリームは、ベースレイヤからのEOB NALユニットのみを不適切に最終アクセスユニットの中央に位置させない。デコーダデバイスのファイルパーシングエンジンは、ビットストリームが2つ以上のEOB NALユニットを有しないことをさらに確実にすることができる。
【０１２７】
図8Eの例では、ベースレイヤはEOB NALユニット840aを含むが、エンハンスメントレイヤはEOB NALユニットを含まない。この例では、様々な実装形態では、デコーダデバイスのファイルパーシングエンジンは、最上位レイヤ(この例では、ベースレイヤ)の中にあるEOB NALユニットを識別し、最上位レイヤからのEOB NALユニットが最終アクセスユニット862nの末尾に移動されるように、ファイルから読み取られたNALユニットを並べ替える。いかなる他のEOB NALユニットも廃棄され得る。
【０１２８】
図8Eに示す技法は、最終アクセスユニットの末尾にないEOB NALユニットを有するビットストリームを作成することを回避することができる。たとえば、ベースレイヤはEOB NALユニットを含むがエンハンスメントレイヤが含まないとき、図示した技法を用いないと、EOB NALユニットは、末尾でなく最終アクセスユニット862nの中央におけるどこかに配置されることになる。
【０１２９】
したがって、上記で説明した様々な技法は、ビットストリームがファイルに書き込まれる(たとえば、記憶される)ときにEOB NALユニットの配置の周囲に生み出されることがある問題を解決することができる。より一般的に言えば、上記の技法は、EOB NALユニットが最上位レイヤからでないピクチャの一部であるとき、最上位レイヤの中のピクチャの一部として存在するEOB NALユニットがない限り、EOB NALユニットがビットストリームの再構成の間に最終アクセスユニットの末尾に配置されなければならないと規定する。後者の場合、最上位レイヤからのEOB NALユニットが、最終アクセスユニットの中に含まれなければならない。代替または追加として、2つ以上のEOB NALユニットがアクセスユニットの中に存在するとき、最上位レイヤID値を有するピクチャの一部であるEOB NALユニットが使用されなければならず、いかなる他のEOB NALユニットも廃棄されなければならない。
【０１３０】
図9は、ISOベースメディアファイルの中に含まれ得るメディアボックス940およびメディアデータボックス938a、938bの一例を示す。上記で説明したように、メディアボックスは、トラックボックスの中に含まれてよく、オブジェクト、およびトラックの中のメディアデータを記述する情報を含むことができる。図示の例では、メディアボックス940は、メディア情報ボックス942を含む。メディアボックス940はまた、ここで図示しない他のボックスを含むことができる。
【０１３１】
メディア情報ボックス942は、トラックの中のメディアについての特性情報を記述するオブジェクトを含むことができる。たとえば、メディア情報ボックス942は、データ情報ボックスを含むことができ、データ情報ボックスは、トラックの中でのメディア情報のロケーションを記述する。別の例として、メディア情報ボックス942は、トラックがビデオデータを含むとき、ビデオメディアヘッダを含むことができる。ビデオメディアヘッダは、ビデオメディアのコーディングに依存しない汎用プレゼンテーション情報を含むことができる。メディア情報ボックス942はまた、トラックがオーディオデータを含むとき、サウンドメディアヘッダを含むことができる。
【０１３２】
メディア情報ボックス942はまた、図示の例において提供されるように、サンプルテーブルボックス944を含むことができる。ボックスタイプ「stbl」によって識別されるサンプルテーブルボックス944は、トラックの中でのメディアサンプルに対するロケーション(たとえば、ファイルを伴うロケーション)、ならびにサンプルに対する時間情報を提供することができる。サンプルテーブルボックス944によって提供された情報を使用して、プレーヤデバイスは、正しい時間順序でサンプルの位置を特定でき、サンプルのタイプを決定でき、かつ/または特にコンテナ内のサンプルのサイズ、コンテナ、およびオフセットを決定することができる。
【０１３３】
サンプルテーブルボックス944は、ボックスタイプ「stsd」によって識別されるサンプル記述ボックス946を含むことができる。サンプル記述ボックス946は、たとえば、サンプルのために使用されたコーディングタイプについての詳細情報、およびそのコーディングタイプにとって必要な任意の初期化情報を提供することができる。サンプル記述ボックスの中に記憶される情報は、サンプルを含むトラックのタイプに特有であり得る。たとえば、トラックがビデオトラックであるとき、あるフォーマットがサンプル記述のために使用されてよく、トラックがヒントトラックであるとき、異なるフォーマットが使用されてよい。さらなる例として、サンプル記述用のフォーマットはまた、ヒントトラックのフォーマットに応じて変わってよい。
【０１３４】
サンプル記述ボックス946は、1つまたは複数のサンプルエントリ948a、948b、948cを含むことができる。サンプルエントリタイプは抽象クラスであり、したがって、通常、サンプル記述ボックス946は、他の例の中でもビデオデータ用のビジュアルサンプルエントリまたはオーディオサンプル用のオーディオサンプルエントリなどの、特定のサンプルエントリを含む。サンプルエントリボックスは、特定のサンプルのためのパラメータを記憶することができる。たとえば、ビデオサンプルの場合、サンプルエントリボックスは、特にビデオサンプルに対する幅、高さ、水平解像度、垂直解像度、フレームカウント、および/または深度を含むことができる。別の例として、オーディオサンプルの場合、サンプルエントリは、特にチャネルカウント、チャネルレイアウト、および/またはサンプリングレートを含むことができる。
【０１３５】
サンプルエントリ948a、948b、948cによって記述されるサンプル970a、970b、970cは、メディアデータボックス938a、938bの中に記憶される。メディアデータボックス938a、938bは、ファイルのトップレベルに含まれ得る。サンプル記述ボックス946において参照されるサンプルは、異なるメディアデータボックス938a、938bの中に含まれ得るか、または1つのメディアデータボックスの中に含まれ得る。メディアデータボックス938a、938bは、メディアボックス940と同じファイルの中にあり得、かつ/または他のファイルの中にあり得る。
【０１３６】
上記で説明した問題に加えて、ISOBMFFまたはISOBMFFから導出されるフォーマットに従ってフォーマットされたファイルへのタイルトラックの書込みに関して、様々な問題が起こる。
【０１３７】
HEVC規格のいくつかのバージョンは、タイルと呼ばれる矩形領域のコーディングのためのサポートを提供する。これらの領域は、前にコーディングされたピクチャからの他のタイルとのコーディング依存関係を有し得るか、または独立に復号され得る。タイルは、フレームの中の1つまたは複数のスライスに対応する単一の矩形領域として記述され得る。タイルは、単一のスライスの中でコーディングされたいくつかのタイルに相当するタイルセットにグループ化され得る。タイルセットは、タイル間の依存関係を記述するために、かつ/またはいくつかのタイルにわたる対象領域を記述するために使用され得る。
【０１３８】
タイルに対するサンプルを含むISOベースメディアファイルの中のトラックは、通常、タイルトラックと呼ばれる。タイルトラックは、これらのトラックを他のトラックと区別する要件を有し得る。ISO/IEC14496-15の第10.6.1節からの以下の抜粋は、これらの要件のいくつかの例を提供する。
【０１３９】
「HEVC(それぞれ、LHEVC)タイルトラックとは、タイルが属する関連するHEVCレイヤのNALUを搬送するHEVC(それぞれ、LHEVC)トラックへの「tbas」参照があるビデオトラックである。HEVCタイルトラック用のサンプル記述タイプは、「hvt1」でなければならない。LHEVCタイルトラック用のサンプル記述タイプは、「lht1」でなければならない。」
【０１４０】
「タイルトラックの中のサンプルも、サンプル記述ボックスも、VPS、SPS、またはPPS NALユニットを含んではならず、これらのNALユニットは、トラック参照によって識別されるように、関連するレイヤを含むトラックのサンプルまたはサンプル記述ボックスの中になければならない。「tbas」トラック参照によって示されるような、HEVC/LHEVCタイルトラックと、関連するレイヤを含むトラックの両方は、元のビットストリームがどのように再構成されるのかを示すために、付属書類Bにおいて定義されるようなエクストラクタを使用し得、これらのトラックの中にエクストラクタが存在することが、いくつかのアプリケーション領域において強制され得る。」
【０１４１】
上記では、タイルトラックが属するレイヤを含むトラックは、タイルトラックの「tbas」参照によって参照され、ベーストラックと呼ばれることがある。
【０１４２】
上記の抜粋において述べたように、エクストラクタは、タイル化ビットストリームを再構成するために使用され得る。エクストラクタは、エクストラクタを含むトラック以外のトラックからのNALユニットの抽出を可能にする、ISOベースメディアファイルの中の構造である。詳細には、エクストラクタは、エクストラクタが存在するトラックにリンクされている別のトラックからデータを抽出するための命令を含む。ISO/IEC14496-15の第10.6.4節は、タイルトラックに関してエクストラクタの使用を次のように記載している。
【０１４３】
「タイルトラックを使用するHEVCまたはL-HEVCトラックは、そのタイルトラックからのデータを参照するためにエクストラクタを使用し得、その場合、トラックは、タイルトラックへの「scal」トラック参照を有しなければならない。」
【０１４４】
場合によっては、ISOベースメディアファイルがHEVCおよびL-HEVCタイルトラックを含むとき、循環エクストラクタ参照が行われ得ることが可能であり得る。たとえば、上述のように、パラメータセット(たとえば、VPS、SPS、またはPPS NALユニット)は、タイルトラックの中に記憶されず、代わりに、タイルトラック(たとえば、ベーストラック)に関連するレイヤを含むトラックのサンプル記述ボックスまたはサンプルの中に見つけ出され得る。したがって、タイルトラックの中のサンプルは、パラメータセットを参照するためにエクストラクタを使用する。しかしながら、場合によっては、ベーストラックはそれ自体、第10.6.4節からの上記の引用によって提供されるように、タイルトラックの中のNALユニットを参照するためにエクストラクタを使用し得る。したがって、タイルトラックのサンプルとベーストラックの中のサンプルとの間での循環参照が生み出され得る。
【０１４５】
タイルトラックの中での循環エクストラクタ参照を克服するために様々な技法が使用されてよく、そのような参照は行われるはずである。たとえば、トラックがタイルトラックへの「scal」トラック参照を含むとき、参照されるタイルトラックがエクストラクタを含んではならないような制約が定義され得る。この例では、パラメータセットは、サンプルエントリの中にのみ存在しなければならず、「tbas」トラック参照によって参照されるベーストラックのサンプルの中にあってはならない。
【０１４６】
場合によっては、ISOベースメディアファイルからの1つまたは複数のタイル化アクセスユニットの再構成も、問題に遭遇することがある。タイル化アクセスユニットの再構成は、IOS/IEC14496-14の第10.6.4節において記載されており、次のように要約され得る。すなわち、暗黙的再構成の場合、タイルトラックを使用するHEVCまたはL-HEVCトラックは、タイルトラックへの「sabt」トラック参照を使用してタイル順序を示さなければならず、HEVCまたはLHEVCトラックのサンプルは、このトラックの「sabt」トラック参照において示されるすべてのトラックの中で、トラック参照の順序で、同じ復号時間を有するサンプルの中に含まれるNALユニットをサンプルデータに添付することによって(たとえば、編集リストを考慮することなく時間対サンプルテーブルのみを使用して)再構成される。
【０１４７】
HEVCまたはLHEVCタイルトラックが(たとえば、HEVCまたはLHEVCトラックサンプルの中に含まれるパラメータセットNALユニットを参照するために)エクストラクタを使用するとき、上記の再構成方法を用いると問題が発生することがある。場合によっては、エクストラクタによって参照されるデータが、最後に再構成されるタイル化アクセスユニットの中で重複する。
【０１４８】
タイル化アクセスユニットの中でのデータの重複を回避するために、様々な技法が使用され得る。たとえば、HEVCまたはL-HEVCタイルトラックがタイルトラックの「tbas」トラックを参照するためにエクストラクタを使用してはならないような制約が適用され得る。別の例として、タイルアクセスユニットの再構成において、暗黙的再構成が使用されるとき、「tbas」トラックへのエクストラクタは無視されなければならない。さらなる例として、タイル化アクセスユニットの暗黙的再構成に対して、タイルトラックの中のエクストラクタが、存在する場合、無視されなければならないような制約が適用され得る。
【０１４９】
上記で引用されたISO/IEC14496-15の第10.6.1節からの抜粋によって提供されるように、HEVCおよびL-HEVCタイルトラックはエクストラクタを使用することができる。たとえば、タイルトラックは、タイルトラックの「tbas」参照によって参照されるトラック(たとえば、ベーストラック)からサンプルを抽出し得る。したがって、タイルトラックの復号および/または再生は、ベーストラックの存在を必要とする。エクストラクタの1つの目的が、トラックのよりコンパクトな形成をもたらすことであるので、タイルトラックにエクストラクタを使用させることは、この目的に反するように思われる。
【０１５０】
そのような使用から利益が得られない、タイルトラックの中でのエクストラクタの使用を回避するために、様々な技法が使用され得る。たとえば、様々な実装形態では、いかなるタイルトラックの中でのエクストラクタの使用も禁止され得る。
【０１５１】
タイルトラックに関係し起こり得る別の問題は、HEVCまたはL-HEVCタイルトラックからのビデオ部分しか必要とされないときに起こる。この状況において、ISO/IEC14496-15仕様は、誤ったパーサがデコーダエンジンのために生成すべきデータを指定しない。
【０１５２】
HEVCまたはL-HEVCタイルトラックのビデオ部分しか必要とされないとき、ISO/IEC14496-15においてストリームまたはアクセスユニット構成に関する仕様が欠落していることを克服するために、様々な技法が使用され得る。たとえば、以下のプロセスが使用され得る。すなわち、最初に、サンプルエントリの中に含まれるパラメータセットおよび補足エンハンスメント情報(SEI)NALユニットが出力され得る。次に、他のNALユニットは、以下の順序で、すなわち、VCL NALユニットの前に存在しなければならない(たとえば、パラメータセットNALユニット、プレフィックスSEI NALユニットなど)、(「tbas」トラック参照によって示されるような)ベーストラックの中の第1のサンプル(以下で「firstSampleInBaseTrack」と呼ばれる)の中のNALユニット、タイルトラックの中のfirstSampleInBaseTrackの対応するサンプルの中のNALユニット、VLC NALユニットの後に存在しなければならない(たとえば、EOS NALユニット、EOB NALユニット)、firstSampleInBaseTrackの中のNALユニット、VLC NALユニットの前に存在しなければならない、ベーストラックの中の第2のサンプル(以下で「secondSampleInBaseTrack」と呼ばれる)の中のNALユニット、タイルトラックの中のsecondSampleInBaseTrackの対応するサンプルの中のNALユニット、VLC NALユニットの後に存在しなければならない、secondSampleInBaseTrackの対応するサンプルの中のNALユニットなどの順序で、出力され得る。
【０１５３】
上記のプロセスにおいて、ベーストラックおよびタイルトラックの中のサンプルは、復号時間によって同期されている。言い換えれば、ベーストラックの中のサンプル、およびタイルトラックの中のその対応するサンプルは、同じ復号時間を有する。
【０１５４】
HEVCおよびL-HEVCタイルトラックのための1つの使用事例は、ピクチャ全体を復号することではなく、ピクチャ内の対象領域(ROI:region of interest)の復号である。そのような場合、タイルトラックの中に記憶されるピクチャの一部が復号され得る。そうするために、ピクチャ内でのタイルの相対位置が知られている必要があり得る。
【０１５５】
ピクチャ内でのタイルの位置をシグナリングするために、様々な技法が使用され得る。たとえば、HEVCまたはL-HEVCタイルトラックのサンプルエントリの中にオフセット情報が含められてよい。オフセット情報は、水平オフセットおよび/または垂直オフセットを含むことができる。オフセットは、ピクセル単位、パイカ単位、センチメートル単位、分数インチ単位、マクロブロック単位、またはいくつかの他の測定単位で与えられ得る。
【０１５６】
タイルトラック用のオフセット情報を提供するために、ISO/IEC14496-15の第10.6.2.2節および第10.6.3.2節への修正が提案される。これらの節のテキストが以下に提供され、これらの節に追加されるテキストは下線付きのテキストを使用して示す(追加テキストの例)。
【０１５７】
10.6.2.2  シンタックス
【０１５８】
class HEVCTileConfigurationBox extends Box('hvtC') {
unsigned int(16) horizontal_offset;
unsigned int(16) vertical_offset;
HEVCTileTierLevelConfigurationRecord() HEVCTileTierLevelConfig;
}
【０１５９】
horizontal_offsetおよびvertical_offsetは、「tbas」参照トラックによって表されるピクチャの左上ルーマサンプルに対して、このトラックによって表されるタイルによって表される矩形領域の左上ルーマサンプルの水平オフセットおよび垂直オフセットを、ルーマサンプル単位で与える。
【０１６０】
10.6.3.2  シンタックス
【０１６１】
class LHEVCTileSampleEntry() extends VisualSampleEntry ('lht1'){
unsigned int(16) min_horizontal_offset;
unsigned int(16) min_vertical_offset;
unsigned int(16) max_horizontal_offset;
unsigned int(16) max_vertical_offset;
MPEG4BitRateBox (); //オプショナル
Box extra_boxes[]; //オプショナル
}
【０１６２】
min_horizontal_offsetおよびmin_vertical_offsetは、それぞれ、「tbas」参照トラックによって表される最下位レイヤのピクチャの左上ルーマサンプルに対して、最下位レイヤの、このトラックによって表されるタイルによって表される矩形領域の左上ルーマサンプルの水平オフセットおよび垂直オフセットを、ルーマサンプル単位で与える。
【０１６３】
max_horizontal_offsetおよびmax_vertical_offsetは、それぞれ、「tbas」参照トラックによって表される最下位レイヤのピクチャの左上ルーマサンプルに対して、最上位レイヤの、このトラックによって表されるタイルによって表される矩形領域の左上ルーマサンプルの水平オフセットおよび垂直オフセットを、ルーマサンプル単位で与える。
【０１６４】
図10は、符号化ビデオデータを含むファイルが2つ以上のEOB NALユニットを有し得る、符号化ビデオデータを処理するためのプロセス1000の一例を示す。1002において、プロセス1000は、符号化ビデオデータに関連するファイルを受信することを含み、符号化ビデオデータは、ファイルフォーマットに従ってファイルの中に記憶され、符号化ビデオデータは、2つ以上のレイヤを含み、2つ以上のレイヤは、ファイルの中の2つ以上のトラックの中に記憶される。場合によっては、ファイルの中の少なくとも2つのレイヤは各々、EOB NALユニットを有することができる。場合によっては、ベースレイヤのみがEOB NALユニットを含む。場合によっては、1つまたは複数のエンハンスメントレイヤは各々、EOB NALユニットを有し得る。
【０１６５】
1004において、プロセス1000は、2つ以上のレイヤの中から第1のレイヤを決定することを含み、第1のレイヤは、2つ以上のレイヤのうちの、ビットストリーム終了インジケータを含む最上位レイヤ(たとえば、最上位レイヤID値を有するレイヤ)であると決定される。すなわち、ファイルが、EOBインジケータを有する2つ以上のレイヤを含むとき、ステップ1004において、EOBインジケータを有する最上位レイヤが識別される(たとえば、決定される)。場合によっては、さらに上位のレイヤ(たとえば、EOBインジケータを有する上述の最上位レイヤよりも大きいレイヤID値に関連するレイヤ)がファイルの中にあり得るが、これらの上位レイヤはEOBを含まない。
【０１６６】
1006において、プロセス1000は、第1のビットストリーム終了インジケータを決定することを含み、第1のビットストリーム終了インジケータは、第1のレイヤからのビットストリーム終了インジケータである。
【０１６７】
1008において、プロセス1000は、2つ以上のレイヤの中からレイヤのセットを選択すること(たとえば、識別すること)を含む。様々な実装形態では、レイヤのセットは、レイヤの中のサンプルが表示用に選択されることに基づいて選択され得る。場合によっては、レイヤのセットは、ファイルの中のレイヤの数よりも少数を含み得る。場合によっては、レイヤのセットは、ただ1つのレイヤを含み得る。
【０１６８】
1010において、プロセス1000は、一連のアクセスユニットを生成することを含み、一連のアクセスユニットは、レイヤのセットからのサンプルを含む。
【０１６９】
1012において、プロセス1000は、一連のアクセスユニットおよび第1のビットストリーム終了インジケータを使用して再構成ビットストリームを生成することを含み、再構成ビットストリームの中の最終アクセスユニットは、第1のビットストリーム終了インジケータを含む。たとえば、場合によっては、上記で説明したように、一連のアクセスユニットの中の最終アクセスユニットは、ビットストリーム終了インジケータを含まないことがある。これらの場合、第1のビットストリーム終了インジケータが、一連のアクセスユニットの中の最終アクセスユニットに追加され得る。様々な実装形態では、第1のビットストリーム終了インジケータが、ビットストリームの再構成の間に、一連のアクセスユニットの中の最終アクセスユニットに追加され得る。一連のアクセスユニットの中の最終アクセスユニットは、次いで、再構成ビットストリームの中の最終アクセスユニットになり得る。
【０１７０】
場合によっては、再構成ビットストリームからのレイヤのセットは、ステップ1004において決定される第1のレイヤを含まないことがある。言い換えれば、再構成ビットストリームに関連するレイヤのセットは、ビットストリーム終了インジケータも含む最大レイヤID値に関連するレイヤを含まないことがある。これらの場合、第1のレイヤは、ステップ1008において選択または識別されるレイヤのセットの中に存在する、最上位レイヤよりも大きいレイヤID値に関連するレイヤであり得る。そうであるとき、第1のレイヤ内に含まれる第1のビットストリーム終了インジケータは、レイヤのセットの中の任意のレイヤがこの最終アクセスユニットへのビットストリーム終了インジケータに寄与したかどうかにかかわらず、一連のアクセスユニットの中の最終アクセスユニットに追加されてよい(たとえば、含められてよい)。
【０１７１】
場合によっては、ステップ1004において決定される第1のレイヤは、ステップ1008において決定されるレイヤのセットの中の最上位レイヤよりも下位のレイヤであってよい。これらの場合、第1のレイヤからの第1のビットストリーム終了インジケータは、一連のアクセスユニットの中の最終アクセスユニットに移動され得る。第1のレイヤは、レイヤのセットの中にあってもなくてもよい。
【０１７２】
場合によっては、再構成ビットストリームの中の最終アクセスユニットが生成されると、この最終アクセスユニットが2つ以上のビットストリーム終了インジケータを有することがある。そうであるとき、第1のレイヤからの第1のビットストリーム終了インジケータ以外のビットストリーム終了インジケータの各々は、除去され得る。その結果、再構成ビットストリームの中の最終アクセスユニットは、第1のビットストリーム終了インジケータのみを含む。
【０１７３】
いくつかの例では、プロセス1000は、システム100などのコンピューティングデバイスまたは装置によって実行され得る。たとえば、プロセス1000は、図1に示すシステム100および/またはストレージ108もしくは出力部110によって実行され得る。場合によっては、コンピューティングデバイスまたは装置は、プロセス1000のステップを実行するように構成されているデバイスのプロセッサ、マイクロプロセッサ、マイクロコンピュータ、または他の構成要素を含み得る。いくつかの例では、コンピューティングデバイスまたは装置は、ビデオフレームを含むビデオデータ(たとえば、ビデオシーケンス)をキャプチャするように構成されたカメラを含み得る。たとえば、コンピューティングデバイスは、ビデオコーデックを含み得るカメラデバイス(たとえば、IPカメラまたは他のタイプのカメラデバイス)を含み得る。いくつかの例では、ビデオデータをキャプチャするカメラまたは他のキャプチャデバイスは、コンピューティングデバイスとは別個であり、その場合、コンピューティングデバイスは、キャプチャされたビデオデータを受信する。コンピューティングデバイスは、ビデオデータを通信するように構成されたネットワークインターフェースをさらに含み得る。ネットワークインターフェースは、インターネットプロトコル(IP)ベースのデータを通信するように構成され得る。
【０１７４】
プロセス1000は、論理フロー図として図示され、その動作は、ハードウェア、コンピュータ命令、またはそれらの組合せで実施され得る動作のシーケンスを表す。コンピュータ命令のコンテキストでは、動作は、1つまたは複数のプロセッサによって実行されたとき、説明する動作を実行する1つまたは複数のコンピュータ可読記憶媒体に記憶されたコンピュータ実行可能命令を表す。概して、コンピュータ実行可能命令は、特定の機能を実行し、または特定のデータタイプを実装する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。動作が説明される順序は、限定として解釈されることを意図せず、説明される任意の数の動作は、プロセスを実施するために任意の順序で、かつ/または並列に組み合わせられてよい。
【０１７５】
追加として、プロセス1000は、実行可能命令とともに構成された1つまたは複数のコンピュータシステムの制御下で実行されてよく、ハードウェアまたはその組合せによって1つまたは複数のプロセッサ上で集合的に実行するコード(たとえば、実行可能命令、1つもしくは複数のコンピュータプログラム、または1つもしくは複数のアプリケーション)として実装されてよい。上述のように、コードは、たとえば、1つまたは複数のプロセッサによって実行可能な複数の命令を備えるコンピュータプログラムの形態で、コンピュータ可読記憶媒体または機械可読記憶媒体に記憶され得る。コンピュータ可読記憶媒体または機械可読記憶媒体は非一時的であってよい。
【０１７６】
符号化デバイス1104および復号デバイス1212の具体的な詳細が、それぞれ、図11および図12に示される。図11は、本開示で説明する技法のうちの1つまたは複数を実施し得る例示的な符号化デバイス1104を示すブロック図である。符号化デバイス1104は、たとえば、本明細書で説明するシンタックス構造(たとえば、VPS、SPS、PPS、または他のシンタックス要素のシンタックス構造)を生成し得る。符号化デバイス1104は、ビデオスライス内のビデオブロックのイントラ予測コーディングおよびインター予測コーディングを実行し得る。前に説明したように、イントラコーディングは、所与のビデオフレーム内またはピクチャ内の空間的冗長性を低減または除去するために、空間予測に少なくとも部分的に依拠する。インターコーディングは、ビデオシーケンスの隣接するまたは取り囲むフレーム内の時間的冗長性を低減または除去するために、時間予測に少なくとも部分的に依拠する。イントラモード(Iモード)は、いくつかの空間ベースの圧縮モードのうちのいずれかを指し得る。単方向予測(Pモード)または双方向予測(Bモード)などのインターモードは、いくつかの時間ベースの圧縮モードのうちのいずれかを指し得る。
【０１７７】
符号化デバイス1104は、区分ユニット35、予測処理ユニット41、フィルタユニット63、ピクチャメモリ64、加算器50、変換処理ユニット52、量子化ユニット54、およびエントロピー符号化ユニット56を含む。予測処理ユニット41は、動き推定ユニット42、動き補償ユニット44、およびイントラ予測処理ユニット46を含む。ビデオブロック再構成のために、符号化デバイス1104はまた、逆量子化ユニット58、逆変換処理ユニット60、および加算器62を含む。フィルタユニット63は、デブロッキングフィルタ、適応ループフィルタ(ALF:adaptive loop filter)、およびサンプル適応オフセット(SAO)フィルタなどの、1つまたは複数のループフィルタを表すことを意図する。フィルタユニット63がループ内フィルタであるものとして図11に示されるが、他の構成では、フィルタユニット63はループ後フィルタとして実装されてよい。後処理デバイス57は、符号化デバイス1104によって生成された符号化ビデオデータに、さらなる処理を実行し得る。本開示の技法は、いくつかの事例では、符号化デバイス1104によって実施され得る。しかしながら、他の事例では、本開示の技法のうちの1つまたは複数は、後処理デバイス57によって実施されてよい。
【０１７８】
図11に示すように、符号化デバイス1104はビデオデータを受信し、区分ユニット35はデータをビデオブロックに区分する。区分することはまた、スライス、スライスセグメント、タイル、または他のもっと大きいユニットに区分すること、ならびに、たとえば、LCUおよびCUの4分木構造によるビデオブロック区分を含み得る。符号化デバイス1104は、概して、符号化されるべきビデオスライス内のビデオブロックを符号化する構成要素を示す。スライスは、複数のビデオブロックに(また場合によっては、タイルと呼ばれるビデオブロックのセットに)分割され得る。予測処理ユニット41は、エラー結果(たとえば、コーディングレート、およびひずみのレベルなど)に基づいて、現在ビデオブロックに対して、複数のイントラ予測コーディングモードのうちの1つ、または複数のインター予測コーディングモードのうちの1つなどの、複数の可能なコーディングモードのうちの1つを選択し得る。予測処理ユニット41は、残差ブロックデータを生成するために加算器50に、また参照ピクチャとして使用するための符号化ブロックを再構成するために加算器62に、得られたイントラまたはインターコード化ブロックを提供し得る。
【０１７９】
予測処理ユニット41内のイントラ予測処理ユニット46は、空間的な圧縮を行うために、コーディングされるべき現在ブロックと同じフレームまたはスライスの中の1つまたは複数の隣接ブロックに対する現在ビデオブロックのイントラ予測コーディングを実行し得る。予測処理ユニット41内の動き推定ユニット42および動き補償ユニット44は、時間的な圧縮を行うために、1つまたは複数の参照ピクチャの中の1つまたは複数の予測ブロックに対する現在ビデオブロックのインター予測コーディングを実行する。
【０１８０】
動き推定ユニット42は、ビデオシーケンスにとっての所定のパターンに従って、ビデオスライス用のインター予測モードを決定するように構成され得る。所定のパターンは、シーケンスの中のビデオスライスを、Pスライス、Bスライス、またはGPBスライスとして指定し得る。動き推定ユニット42および動き補償ユニット44は高集積され得るが、概念的な目的のために別個に図示される。動き推定ユニット42によって実行される動き推定は、ビデオブロックにとっての動きを推定する動きベクトルを生成するプロセスである。動きベクトルは、たとえば、現在ビデオフレーム内または現在ピクチャ内のビデオブロックの予測ユニット(PU)の、参照ピクチャ内の予測ブロックに対する変位を示し得る。
【０１８１】
予測ブロックは、絶対差分和(SAD:sum of absolute difference)、2乗差分和(SSD:sum of square difference)、または他の差分メトリックによって決定され得るピクセル差分の観点で、コーディングされるべきビデオブロックのPUと密接に整合するように見出されたブロックである。いくつかの例では、符号化デバイス1104は、ピクチャメモリ64に記憶された参照ピクチャのサブ整数ピクセル位置に対する値を計算し得る。たとえば、符号化デバイス1104は、参照ピクチャの1/4ピクセル位置、1/8ピクセル位置、または他の分数ピクセル位置の値を補間し得る。したがって、動き推定ユニット42は、フルピクセル位置および分数ピクセル位置に対する動き探索を実行し得、分数ピクセル精度を有する動きベクトルを出力し得る。
【０１８２】
動き推定ユニット42は、PUの位置を参照ピクチャの予測ブロックの位置と比較することによって、インターコード化スライスの中のビデオブロックのPU用の動きベクトルを計算する。参照ピクチャは、第1の参照ピクチャリスト(リスト0)または第2の参照ピクチャリスト(リスト1)から選択されてよく、その各々はピクチャメモリ64に記憶された1つまたは複数の参照ピクチャを識別する。動き推定ユニット42は、計算された動きベクトルをエントロピー符号化ユニット56および動き補償ユニット44へ送る。
【０１８３】
動き補償ユニット44によって実行される動き補償は、場合によっては、サブピクセル精度への補間を実行する動き推定によって決定される動きベクトルに基づいて、予測ブロックをフェッチまたは生成することを伴い得る。現在ビデオブロックのPU用の動きベクトルを受信すると、動き補償ユニット44は、参照ピクチャリストの中で動きベクトルが指す予測ブロックの位置を特定し得る。符号化デバイス1104は、コーディングされている現在ビデオブロックのピクセル値から予測ブロックのピクセル値を減算し、ピクセル差分値を形成することによって、残差ビデオブロックを形成する。ピクセル差分値は、ブロックに対する残差データを形成し、ルーマ差分成分とクロマ差分成分の両方を含み得る。加算器50は、この減算演算を実行する1つまたは複数の構成要素を表す。動き補償ユニット44はまた、ビデオスライスのビデオブロックを復号する際の復号デバイス1212による使用のために、ビデオブロックおよびビデオスライスに関連付けられたシンタックス要素を生成し得る。
【０１８４】
イントラ予測処理ユニット46は、上記で説明したように、動き推定ユニット42および動き補償ユニット44によって実行されるインター予測の代替として、現在ブロックをイントラ予測し得る。具体的には、イントラ予測処理ユニット46は、現在ブロックを符号化するために使用すべきイントラ予測モードを決定し得る。いくつかの例では、イントラ予測処理ユニット46は、たとえば、別個の符号化パスの間、様々なイントラ予測モードを使用して現在ブロックを符号化し得、イントラ予測処理ユニット46(または、いくつかの例では、モード選択ユニット40)は、テストされたモードから使用すべき適切なイントラ予測モードを選択し得る。たとえば、イントラ予測処理ユニット46は、テストされた様々なイントラ予測モードに対してレートひずみ分析を使用してレートひずみ値を計算し得、テストされたモードの中から最良のレートひずみ特性を有するイントラ予測モードを選択し得る。レートひずみ分析は、概して、符号化ブロックと、符号化ブロックを生成するために符号化された、符号化されていない元のブロックとの間のひずみ(すなわち、エラー)の量、ならびに符号化ブロックを生成するために使用されるビットレート(すなわち、ビット数)を決定する。イントラ予測処理ユニット46は、どのイントラ予測モードがブロックにとって最良のレートひずみ値を示すのかを決定するために、様々な符号化ブロックに対するひずみおよびレートから比を計算し得る。
【０１８５】
いずれの場合も、ブロック用のイントラ予測モードを選択した後、イントラ予測処理ユニット46は、ブロック用の選択されたイントラ予測モードを示す情報をエントロピー符号化ユニット56に提供し得る。エントロピー符号化ユニット56は、選択されたイントラ予測モードを示す情報を符号化し得る。符号化デバイス1104は、様々なブロック用の符号化コンテキストの構成データ定義、ならびに最確のイントラ予測モード、イントラ予測モードインデックステーブル、およびコンテキストの各々に対して使用すべき修正されたイントラ予測モードインデックステーブルの表示を、送信されるビットストリームの中に含め得る。ビットストリーム構成データは、複数のイントラ予測モードインデックステーブルおよび修正された複数のイントラ予測モードインデックステーブル(コードワードマッピングテーブルとも呼ばれる)を含み得る。
【０１８６】
予測処理ユニット41がインター予測またはイントラ予測のいずれかを介して現在ビデオブロックに対する予測ブロックを生成した後、符号化デバイス1104は、現在ビデオブロックから予測ブロックを減算することによって残差ビデオブロックを形成する。残差ブロックの中の残差ビデオデータは、1つまたは複数のTUの中に含められてよく、変換処理ユニット52に適用され得る。変換処理ユニット52は、離散コサイン変換(DCT)または概念的に類似の変換などの変換を使用して、残差ビデオデータを残差変換係数に変換する。変換処理ユニット52は、ピクセル領域から周波数領域などの変換領域に、残差ビデオデータを変換し得る。
【０１８７】
変換処理ユニット52は、得られた変換係数を量子化ユニット54へ送り得る。量子化ユニット54は、ビットレートをさらに低減するために変換係数を量子化する。量子化プロセスは、係数の一部または全部に関連するビット深度を低減し得る。量子化の程度は、量子化パラメータを調整することによって変更され得る。いくつかの例では、量子化ユニット54は、次いで、量子化変換係数を含む行列の走査を実行し得る。代替として、エントロピー符号化ユニット56が走査を実行してもよい。
【０１８８】
量子化に続いて、エントロピー符号化ユニット56は、量子化変換係数をエントロピー符号化する。たとえば、エントロピー符号化ユニット56は、コンテキスト適応型可変長コーディング(CAVLC:context adaptive variable length coding)、コンテキスト適応型バイナリ算術コーディング(CABAC:context adaptive binary arithmetic coding)、シンタックスベースコンテキスト適応型バイナリ算術コーディング(SBAC:syntax-based context-adaptive binary arithmetic coding)、確率間隔区分エントロピー(PIPE:probability interval partitioning entropy)コーディング、または別のエントロピー符号化技法を実行し得る。エントロピー符号化ユニット56によるエントロピー符号化に続いて、符号化ビットストリームは、復号デバイス1212へ送信されてよく、または復号デバイス1212によって後で送信もしくは取出しができるようにアーカイブされてもよい。エントロピー符号化ユニット56はまた、コーディングされている現在ビデオスライス用の動きベクトルおよび他のシンタックス要素をエントロピー符号化し得る。
【０１８９】
逆量子化ユニット58および逆変換処理ユニット60は、参照ピクチャの参照ブロックとして後で使用できるようにピクセル領域における残差ブロックを再構成するために、それぞれ、逆量子化および逆変換を適用する。動き補償ユニット44は、参照ピクチャリスト内の参照ピクチャのうちの1つの予測ブロックに残差ブロックを加算することによって、参照ブロックを計算し得る。動き補償ユニット44はまた、動き推定において使用するためのサブ整数ピクセル値を計算するために、1つまたは複数の補間フィルタを再構成残差ブロックに適用し得る。加算器62は、ピクチャメモリ64に記憶するための参照ブロックを生成するために、動き補償ユニット44によって生成された動き補償された予測ブロックに再構成残差ブロックを加算する。参照ブロックは、後続のビデオフレームまたはピクチャの中のブロックをインター予測するための参照ブロックとして、動き推定ユニット42および動き補償ユニット44によって使用され得る。
【０１９０】
このようにして、図11の符号化デバイス1104は、符号化ビデオビットストリームのためのシンタックスを生成するように構成されたビデオエンコーダの一例を表す。符号化デバイス1104は、たとえば、上記で説明したように、VPS、SPS、およびPPSパラメータセットを生成し得る。符号化デバイス1104は、図11および図12に関して上記で説明したプロセスを含む、本明細書で説明する技法のうちのいずれかを実行し得る。本開示の技法が、概して、符号化デバイス1104に関して説明されたが、上述のように、本開示の技法のいくつかはまた、後処理デバイス57によって実施されてよい。
【０１９１】
図12は、例示的な復号デバイス1212を示すブロック図である。復号デバイス1212は、エントロピー復号ユニット80、予測処理ユニット81、逆量子化ユニット86、逆変換処理ユニット88、加算器90、フィルタユニット91、およびピクチャメモリ92を含む。予測処理ユニット81は、動き補償ユニット82およびイントラ予測処理ユニット84を含む。復号デバイス1212は、いくつかの例では、図11からの符号化デバイス1104に関して説明した符号化パスと概して相反の復号パスを実行し得る。
【０１９２】
復号プロセスの間、復号デバイス1212は、符号化デバイス1104によって送られた符号化ビデオスライスのビデオブロックおよび関連するシンタックス要素を表す符号化ビデオビットストリームを受信する。いくつかの実施形態では、復号デバイス1212は、符号化デバイス1104から符号化ビデオビットストリームを受信し得る。いくつかの実施形態では、復号デバイス1212は、サーバ、メディアアウェアネットワーク要素(MANE:media-aware network element)、ビデオエディタ/スプライサ、または上記で説明した技法のうちの1つもしくは複数を実施するように構成されたそのような他のデバイスなどのネットワークエンティティ79から、符号化ビデオビットストリームを受信し得る。ネットワークエンティティ79は、符号化デバイス1104を含んでよく、または含まなくてもよい。本開示で説明する技法のうちのいくつかは、ネットワークエンティティ79が符号化ビデオビットストリームを復号デバイス1212へ送信する前に、ネットワークエンティティ79によって実施され得る。いくつかのビデオ復号システムでは、ネットワークエンティティ79および復号デバイス1212は、別個のデバイスの一部であってよく、他の事例では、ネットワークエンティティ79に関して説明する機能は、復号デバイス1212を備える同じデバイスによって実行されてよい。
【０１９３】
復号デバイス1212のエントロピー復号ユニット80は、量子化係数、動きベクトル、および他のシンタックス要素を生成するために、ビットストリームをエントロピー復号する。エントロピー復号ユニット80は、動きベクトルおよび他のシンタックス要素を予測処理ユニット81に転送する。復号デバイス1212は、ビデオスライスレベルおよび/またはビデオブロックレベルにおいてシンタックス要素を受信し得る。エントロピー復号ユニット80は、VPSセット、SPSセット、およびPPSセットなどの1つまたは複数のパラメータセットの中の、固定長シンタックス要素と可変長シンタックス要素の両方を処理および構文解析し得る。
【０１９４】
ビデオスライスがイントラコード化(I)スライスとしてコーディングされるとき、予測処理ユニット81のイントラ予測処理ユニット84は、シグナリングされたイントラ予測モード、および現在フレームまたは現在ピクチャの、前に復号されたブロックからのデータに基づいて、現在ビデオスライスのビデオブロックに対する予測データを生成し得る。ビデオフレームがインターコード化(すなわち、B、P、またはGPB)スライスとしてコーディングされるとき、予測処理ユニット81の動き補償ユニット82は、エントロピー復号ユニット80から受信された動きベクトルおよび他のシンタックス要素に基づいて、現在ビデオスライスのビデオブロックに対する予測ブロックを生成する。予測ブロックは、参照ピクチャリスト内の参照ピクチャのうちの1つから生成され得る。復号デバイス1212は、ピクチャメモリ92に記憶された参照ピクチャに基づいて、デフォルトの構成技法を使用して、参照フレームリスト、すなわち、リスト0およびリスト1を構成し得る。
【０１９５】
動き補償ユニット82は、動きベクトルおよび他のシンタックス要素を構文解析することによって、現在ビデオスライスのビデオブロックに対する予測情報を決定し、予測情報を使用して、復号されている現在ビデオブロックに対する予測ブロックを生成する。たとえば、動き補償ユニット82は、パラメータセットの中の1つまたは複数のシンタックス要素を使用して、ビデオスライスのビデオブロックをコーディングするために使用された予測モード(たとえば、イントラ予測またはインター予測)、インター予測スライスタイプ(たとえば、Bスライス、Pスライス、またはGPBスライス)、スライスのための1つまたは複数の参照ピクチャリストに対する構成情報、スライスのインター符号化ビデオブロックごとの動きベクトル、スライスのインターコード化ビデオブロックごとのインター予測ステータス、および現在ビデオスライスの中のビデオブロックを復号するための他の情報を決定し得る。
【０１９６】
動き補償ユニット82はまた、補間フィルタに基づいて補間を実行し得る。動き補償ユニット82は、参照ブロックのサブ整数ピクセルに対する補間値を計算するために、ビデオブロックの符号化の間に符号化デバイス1104によって使用されたような補間フィルタを使用し得る。この場合、動き補償ユニット82は、符号化デバイス1104によって使用された補間フィルタを、受信されたシンタックス要素から決定し得、予測ブロックを生成するためにその補間フィルタを使用し得る。
【０１９７】
逆量子化ユニット86は、ビットストリームの中で提供されるとともにエントロピー復号ユニット80によって復号された量子化変換係数を逆量子化(inverse quantize)または逆量子化(de-quantize)する。逆量子化プロセスは、量子化の程度を決定し、同様に、適用されるべき逆量子化の程度を決定するために、ビデオスライスの中のビデオブロックごとに符号化デバイス1104によって計算された量子化パラメータを使用することを含み得る。逆変換処理ユニット88は、ピクセル領域における残差ブロックを生成するために、変換係数に逆変換(たとえば、逆DCTまたは他の適切な逆変換)、逆整数変換、または概念的に類似の逆変換プロセスを適用する。
【０１９８】
動き補償ユニット82が動きベクトルおよび他のシンタックス要素に基づいて現在ビデオブロックに対する予測ブロックを生成した後、復号デバイス1212は、逆変換処理ユニット88からの残差ブロックを、動き補償ユニット82によって生成された対応する予測ブロックと加算することによって、復号ビデオブロックを形成する。加算器90は、この加算演算を実行する1つまたは複数の構成要素を表す。所望される場合、(コーディングループ中またはコーディングループ後のいずれかの)ループフィルタも、ピクセル遷移を平滑化するために、または別の方法でビデオ品質を改善するために使用され得る。フィルタユニット91は、デブロッキングフィルタ、適応ループフィルタ(ALF)、およびサンプル適応オフセット(SAO)フィルタなどの、1つまたは複数のループフィルタを表すことを意図する。フィルタユニット91がループ内フィルタであるものとして図12に示されるが、他の構成では、フィルタユニット91はループ後フィルタとして実装されてよい。所与のフレームまたはピクチャの中の復号ビデオブロックは、次いで、ピクチャメモリ92に記憶され、ピクチャメモリ92は、後続の動き補償のために使用される参照ピクチャを記憶する。ピクチャメモリ92はまた、図1に示すビデオ宛先デバイス122などのディスプレイデバイス上で後で提示できるように、復号ビデオを記憶する。
【０１９９】
上記の説明では、本出願の態様は、その特定の実施形態を参照しながら説明されたが、本開示がそれらに限定されないことを当業者は認識されよう。したがって、本出願の例示的な実施形態が本明細書で詳細に説明されたが、本発明の概念が別の方法で様々に具現化または採用されてよく、従来技術による限定を除いて、添付の特許請求の範囲がそのような変形形態を含むものと解釈されることを意図することを理解されたい。上記で説明した開示の様々な特徴および態様は、個別または一緒に使用され得る。さらに、実施形態は、本明細書の広い趣旨および範囲から逸脱することなく、本明細書で説明したものを越えた任意の数の環境および適用例において利用され得る。したがって、本明細書および図面は、限定ではなく例示であると見なされるべきである。例示のために、方法は特定の順序で説明された。代替実施形態では、説明した順序とは異なる順序で方法が実行され得ることを諒解されたい。
【０２００】
構成要素がいくつかの動作を実行する「ように構成」されているものとして説明される場合、そのような構成は、たとえば、動作を実行するための電子回路もしくはハードウェアを設計することによって、動作を実行するためのプログラマブル電子回路(たとえば、マイクロプロセッサ、または他の適切な電子回路)をプログラムすることによって、またはそれらの任意の組合せで達成され得る。
【０２０１】
本明細書で開示する実施形態に関して説明した様々な例示的な論理ブロック、モジュール、回路、およびアルゴリズムステップは、電子ハードウェア、コンピュータソフトウェア、または両方の組合せとして実装され得る。ハードウェアとソフトウェアとのこの互換性を明確に示すために、様々な例示的な構成要素、ブロック、モジュール、回路、およびステップが、概して、それらの機能に関して上記で説明された。そのような機能がハードウェアとして実装されるのか、それともソフトウェアとして実装されるのかは、特定の適用例および全体的なシステムに課された設計制約によって決まる。当業者は説明した機能を特定の適用例ごとに様々な方法で実装し得るが、そのような実装決定は本開示の範囲からの逸脱を引き起こすものと解釈されるべきではない。
【０２０２】
本明細書で説明した技術は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。そのような技法は、汎用コンピュータ、ワイヤレス通信デバイスハンドセット、またはワイヤレス通信デバイスハンドセットおよび他のデバイスにおける適用例を含む複数の用途を有する集積回路デバイスなどの、様々なデバイスのいずれかにおいて実装され得る。モジュールまたは構成要素として説明した任意の特徴が、集積論理デバイスの中で一緒に、または個別であるが相互動作可能な論理デバイスとして別個に実装され得る。ソフトウェアで実装される場合、技法は、実行されたとき、上記で説明した方法の1つまたは複数を実行する命令を含むプログラムコードを備えるコンピュータ可読データ記憶媒体によって、少なくとも部分的に実現され得る。コンピュータ可読データ記憶媒体は、パッケージング材料を含み得るコンピュータプログラム製品の一部を形成し得る。コンピュータ可読媒体は、同期型ダイナミックランダムアクセスメモリ(SDRAM)などのランダムアクセスメモリ(RAM)、読取り専用メモリ(ROM)、不揮発性ランダムアクセスメモリ(NVRAM)、電気消去可能プログラマブル読取り専用メモリ(EEPROM)、フラッシュメモリ、磁気または光学データ記憶媒体などの、メモリまたはデータ記憶媒体を備え得る。技法は、追加または代替として、伝搬される信号または波などの、命令またはデータ構造の形態でプログラムコードを搬送または通信するとともに、コンピュータによってアクセスされ、読み取られ、かつ/または実行され得る、コンピュータ可読通信媒体によって少なくとも部分的に実現され得る。
【０２０３】
プログラムコードは、1つまたは複数のデジタル信号プロセッサ(DSP)、汎用マイクロプロセッサ、特定用途向け集積回路(ASIC)、フィールドプログラマブル論理アレイ(FPGA)、または他の等価な集積論理回路もしくは個別論理回路などの、1つまたは複数のプロセッサを含み得るプロセッサによって実行され得る。そのようなプロセッサは、本開示で説明した技法のうちのいずれかを実行するように構成され得る。汎用プロセッサはマイクロプロセッサであってもよいが、代替として、プロセッサは任意の従来のプロセッサ、コントローラ、マイクロコントローラ、またはステートマシンであってもよい。プロセッサはまた、コンピューティングデバイスの組合せ、たとえば、DSPとマイクロプロセッサとの組合せ、複数のマイクロプロセッサ、DSPコアと連携した1つもしくは複数のマイクロプロセッサ、または任意の他のそのような構成として実装され得る。したがって、本明細書で使用した「プロセッサ」という用語は、上記の構造、上記の構造の任意の組合せ、または本明細書で説明した技法の実装にとって適した任意の他の構造もしくは装置のいずれかを指し得る。加えて、いくつかの態様では、本明細書で説明した機能は、符号化および復号のために構成された専用のソフトウェアモジュール内もしくはハードウェアモジュール内で提供されてよく、または複合ビデオエンコーダデコーダ(コーデック)に組み込まれてよい。
【０２０４】
本明細書で説明したコーディング技法は、例示的なビデオ符号化および復号システムにおいて具現化され得る。システムは、宛先デバイスによって後で復号されるべき符号化ビデオデータを提供するソースデバイスを含む。具体的には、ソースデバイスは、コンピュータ可読媒体を介して宛先デバイスにビデオデータを提供する。ソースデバイスおよび宛先デバイスは、デスクトップコンピュータ、ノートブック(すなわち、ラップトップ)コンピュータ、タブレットコンピュータ、セットトップボックス、いわゆる「スマート」フォンなどの電話ハンドセット、いわゆる「スマート」パッド、テレビジョン、カメラ、ディスプレイデバイス、デジタルメディアプレーヤ、ビデオゲームコンソール、ビデオストリーミングデバイスなどを含む、幅広いデバイスのいずれかを備え得る。場合によっては、ソースデバイスおよび宛先デバイスは、ワイヤレス通信のために装備され得る。
【０２０５】
宛先デバイスは、復号されるべき符号化ビデオデータを、コンピュータ可読媒体を介して受信し得る。コンピュータ可読媒体は、ソースデバイスから宛先デバイスへ符号化ビデオデータを移動することが可能な任意のタイプの媒体またはデバイスを備え得る。一例では、コンピュータ可読媒体は、ソースデバイスが符号化ビデオデータをリアルタイムで宛先デバイスに直接送信することを可能にするための通信媒体を備え得る。符号化ビデオデータは、ワイヤレス通信プロトコルなどの通信規格に従って変調され得、宛先デバイスへ送信され得る。通信媒体は、無線周波数(RF)スペクトルまたは1つもしくは複数の物理伝送線路などの、任意のワイヤレス通信媒体または有線通信媒体を備え得る。通信媒体は、ローカルエリアネットワーク、ワイドエリアネットワーク、またはインターネットなどのグローバルネットワークなどの、パケットベースネットワークの一部を形成し得る。通信媒体は、ルータ、スイッチ、基地局、またはソースデバイスから宛先デバイスへの通信を容易にするために有用であり得る任意の他の機器を含み得る。
【０２０６】
いくつかの例では、符号化データは、出力インターフェースから記憶デバイスに出力され得る。同様に、符号化データは、入力インターフェースによって記憶デバイスからアクセスされ得る。記憶デバイスは、ハードドライブ、Blu-ray(登録商標)ディスク、DVD、CD-ROM、フラッシュメモリ、揮発性メモリもしくは不揮発性メモリ、または符号化ビデオデータを記憶するための任意の他の適切なデジタル記憶媒体などの、分散されるかまたは局所的にアクセスされる様々なデータ記憶媒体のいずれかを含み得る。さらなる一例では、記憶デバイスは、ソースデバイスによって生成された符号化ビデオを記憶し得るファイルサーバまたは別の中間記憶デバイスに相当し得る。宛先デバイスは、記憶デバイスからの記憶されたビデオデータに、ストリーミングまたはダウンロードを介してアクセスし得る。ファイルサーバは、符号化ビデオデータを記憶するとともにその符号化ビデオデータを宛先デバイスへ送信することが可能な、任意のタイプのサーバであってよい。例示的なファイルサーバは、ウェブサーバ(たとえば、ウェブサイト用の)、FTPサーバ、ネットワーク接続ストレージ(NAS)デバイス、またはローカルディスクドライブを含む。宛先デバイスは、インターネット接続を含む任意の標準的なデータ接続を通じて符号化ビデオデータにアクセスし得る。これは、ワイヤレスチャネル(たとえば、Wi-Fi接続)、有線接続(たとえば、DSL、ケーブルモデムなど)、またはファイルサーバに記憶された符号化ビデオデータにアクセスするのに適した、その両方の組合せを含み得る。記憶デバイスからの符号化ビデオデータの送信は、ストリーミング送信、ダウンロード送信、またはそれらの組合せであり得る。
【０２０７】
本開示の技法は、必ずしもワイヤレスの適用例または設定に限定されるとは限らない。技法は、オーバージエアテレビジョン放送、ケーブルテレビジョン送信、衛星テレビジョン送信、動的適応ストリーミングオーバーHTTP(DASH:dynamic adaptive streaming over HTTP)などのインターネットストリーミングビデオ送信、データ記憶媒体上に符号化されているデジタルビデオ、データ記憶媒体上に記憶されたデジタルビデオの復号、または他の適用例などの、様々なマルチメディア用途のいずれかのサポートの際にビデオコーディングに適用され得る。いくつかの例では、システムは、ビデオストリーミング、ビデオ再生、ビデオブロードキャスティング、および/またはビデオ電話などの適用例をサポートするために、一方向または双方向のビデオ送信をサポートするように構成され得る。
【０２０８】
一例では、ソースデバイスは、ビデオソース、ビデオエンコーダ、および出力インターフェースを含む。宛先デバイスは、入力インターフェース、ビデオデコーダ、およびディスプレイデバイスを含み得る。ソースデバイスのビデオエンコーダは、本明細書で開示する技法を適用するように構成され得る。他の例では、ソースデバイスおよび宛先デバイスは、他の構成要素または構成を含み得る。たとえば、ソースデバイスは、外部カメラなどの外部ビデオソースからビデオデータを受信してよい。同様に、宛先デバイスは、一体型ディスプレイデバイスを含むのではなく、外部のディスプレイデバイスとインターフェースしてよい。
【０２０９】
上記の例示的なシステムは一例にすぎない。ビデオデータを並行して処理するための技法は、任意のデジタルビデオ符号化および/または復号デバイスによって実行されてよい。概して、本開示の技法はビデオ符号化デバイスによって実行されるが、技法はまた、通常は「コーデック」と呼ばれるビデオエンコーダ/デコーダによって実行されてよい。その上、本開示の技法はまた、ビデオプロセッサによって実行されてよい。ソースデバイスおよび宛先デバイスはそのようなコーディングデバイスの例にすぎず、ソースデバイスは、宛先デバイスへの送信のためにコード化ビデオデータを生成する。いくつかの例では、ソースデバイスおよび宛先デバイスは、デバイスの各々がビデオ符号化および復号構成要素を含むように、実質的に対称的に動作し得る。したがって、例示的なシステムは、たとえば、ビデオストリーミング、ビデオ再生、ビデオブロードキャスティング、またはビデオ電話のために、ビデオデバイス間での一方向または双方向のビデオ送信をサポートし得る。
【０２１０】
ビデオソースは、ビデオカメラ、前にキャプチャされたビデオを含むビデオアーカイブ、および/またはビデオコンテンツプロバイダからビデオを受信するためのビデオフィードインターフェースなどの、ビデオキャプチャデバイスを含み得る。さらなる代替として、ビデオソースは、ソースビデオとしてのコンピュータグラフィックスベースデータ、またはライブビデオ、アーカイブされたビデオ、およびコンピュータ生成されたビデオの組合せを生成し得る。場合によっては、ビデオソースがビデオカメラである場合、ソースデバイスおよび宛先デバイスは、いわゆるカメラフォンまたはビデオフォンを形成し得る。しかしながら、上述のように、本開示で説明する技法は、一般に、ビデオコーディングに適用可能であり得、ワイヤレスおよび/または有線の用途に適用され得る。各事例において、キャプチャされたビデオ、プリキャプチャされたビデオ、またはコンピュータ生成されたビデオは、ビデオエンコーダによって符号化され得る。符号化されたビデオ情報は、次いで、出力インターフェースによってコンピュータ可読媒体上に出力され得る。
【０２１１】
述べたように、コンピュータ可読媒体は、ワイヤレスブロードキャストもしくは有線ネットワーク送信などの一時的媒体、またはハードディスク、フラッシュドライブ、コンパクトディスク、デジタルビデオディスク、Blu-ray(登録商標)ディスク、もしくは他のコンピュータ可読媒体などの記憶媒体(すなわち、非一時的記憶媒体)を含み得る。いくつかの例では、ネットワークサーバ(図示せず)が、ソースデバイスから符号化ビデオデータを受信し得、たとえば、ネットワーク送信を介して、宛先デバイスに符号化ビデオデータを提供し得る。同様に、ディスクスタンピング施設などの媒体生産施設のコンピューティングデバイスが、ソースデバイスから符号化ビデオデータを受信し得、符号化ビデオデータを含むディスクを生産し得る。したがって、コンピュータ可読媒体は、様々な例において、様々な形式の1つまたは複数のコンピュータ可読媒体を含むものと理解され得る。
【０２１２】
宛先デバイスの入力インターフェースは、コンピュータ可読媒体から情報を受信する。コンピュータ可読媒体の情報は、ビデオエンコーダによって規定されるシンタックス情報を含み得、シンタックス情報はまた、ビデオデコーダによって使用され、ブロックの特性および/または処理ならびに他のコード化ユニット、たとえば、ピクチャグループ(GOP:group of pictures)を記述する、シンタックス要素を含む。ディスプレイデバイスは、復号ビデオデータをユーザに表示し、陰極線管(CRT)、液晶ディスプレイ(LCD)、プラズマディスプレイ、有機発光ダイオード(OLED)ディスプレイ、または別のタイプのディスプレイデバイスなどの、様々なディスプレイデバイスのいずれかを備え得る。本発明の様々な実施形態が説明された。
【符号の説明】
【０２１３】
35  区分ユニット
41  予測処理ユニット
42  動き推定ユニット
44  動き補償ユニット
46  イントラ予測処理ユニット
50  加算器
52  変換処理ユニット
54  量子化ユニット
56  エントロピー符号化ユニット
57  後処理デバイス
58  逆量子化ユニット
60  逆変換処理ユニット
62  加算器
63  フィルタユニット
64  ピクチャメモリ
79  ネットワークエンティティ
80  エントロピー復号ユニット
81  予測処理ユニット
82  動き補償ユニット
84  イントラ予測処理ユニット
86  逆量子化ユニット
88  逆変換処理ユニット
90  加算器
91  フィルタユニット
92  ピクチャメモリ
100  システム
102  ビデオソース
106  エンコーダエンジン
108  ストレージ
110  出力部
114  入力部
116  デコーダエンジン
118  ストレージ
120  通信リンク
122  ビデオ宛先デバイス
200  階層化HEVCビットストリーム
202  ベースレイヤ
204  ピクチャ
212  第1のエンハンスメントレイヤ、レイヤ1
214  ピクチャ
222  エンハンスメントレイヤ、レイヤ2
224  ピクチャ
300  ISOベースメディアファイル
310  ファイルタイプボックス、ファイルタイプ
320  ムービーボックス、ムービー
322  ムービーヘッダボックス、ムービーヘッダ
324  トラックボックス、トラック
324a  トラックヘッダボックス、トラックヘッダ
324b  メディアボックス、メディア
330a、330n  ムービーフラグメント、フラグメント
330b、330c  フラグメント
332  ムービーフラグメントボックス
334  ムービーフラグメントヘッダボックス、ムービーフラグメントヘッダ
336  トラックフラグメントボックス、トラックフラグメント
338  メディアデータボックス、メディアデータ
400  ISOベースメディアファイル
410  ファイルタイプボックス、ファイルタイプ
420  ムービーボックス、ムービー
422  ムービーヘッダボックス、ムービーヘッダ
424a  トラックボックス、トラック(レイヤ0)
424b  トラックボックス、トラック(レイヤ1)
426a、426b  トラックヘッダボックス、トラックヘッダ
428a、428b  メディアデータボックス、メディア
430a  メディアデータボックス、メディアデータ(レイヤ0)
430b  メディアデータボックス、メディアデータ(レイヤ1)
500  ISOベースメディアファイル
510  ファイルタイプボックス
520  ムービーボックス
522  ムービーヘッダボックス
524a、524b  トラックボックス
526a、526b  トラックヘッダボックス
528a、528b  メディアボックス
530a、530b  メディアデータボックス
540  EOB NALユニット
550  ビットストリーム、再構成ビットストリーム
552  ビットストリーム
562a  アクセスユニット、アクセスユニット0
562b  アクセスユニット、アクセスユニット1
562c  アクセスユニット、アクセスユニット2
562n  アクセスユニット、アクセスユニットN
564a  ベースピクチャ、ベースピクチャ0
564b  ベースピクチャ、ベースピクチャ1
564c  ベースピクチャ、ベースピクチャ2
564n  ベースピクチャ、ベースピクチャN
566a  拡張ピクチャ、拡張ピクチャ0
566b  拡張ピクチャ、拡張ピクチャ1
566c  拡張ピクチャ、拡張ピクチャ2
566n  拡張ピクチャ、拡張ピクチャN
600  ISOベースメディアファイル、ファイル
610  ファイルタイプボックス
620  ムービーボックス
622  ムービーヘッダボックス
624a  第1のトラックボックス
624b  第2のトラックボックス
626a、626b  トラックヘッダボックス
628a、628b  メディアボックス
630a、630b  メディアデータボックス
640  EOB NALユニット
650  ビットストリーム、再構成ビットストリーム
652  ビットストリーム
662a、662b、662c、662n  アクセスユニット
664a、664b、664c、664n  ベースピクチャ
666a、666b、666c、666n  拡張ピクチャ
700  ISOベースメディアファイル、ファイル
710  ファイルタイプボックス
720  ムービーボックス
722  ムービーヘッダボックス
724a  第1のトラックボックス
724b  第2のトラックボックス
726a、726b  トラックヘッダボックス
728a、728b  メディアボックス
730a、730b  メディアデータボックス
740  EOB NALユニット
800  ISOベースメディアファイル、ファイル
810  ファイルタイプボックス
820  ムービーボックス
822  ムービーヘッダボックス
824a  第1のトラックボックス
824b  第2のトラックボックス
826a、826b  トラックヘッダボックス
828a、828b  メディアボックス
830a、830b  メディアデータボックス
840a、840b  EOB NALユニット
850、852、856  ビットストリーム、再構成ビットストリーム
854  ビットストリーム、再構成ファイル
856  ビットストリーム
862a、862b、862c、862n  アクセスユニット
864a、864b、864c、864n  ベースピクチャ
868a、868b、868c、868n  拡張ピクチャ
938a、938b  メディアデータボックス、メディアデータ
940  メディアボックス、メディア
942  メディア情報ボックス、メディア情報
944  サンプルテーブルボックス、サンプルテーブル
946  サンプル記述ボックス、サンプル記述
948a、948b、948c  サンプルエントリ
970a、970b、970c  サンプル
1104  符号化デバイス
1212  復号デバイス
【図１】
2019506096.tif 000003
【図２】
2019506096.tif 000004
【図３】
2019506096.tif 000005
【図４】
2019506096.tif 000006
【図５Ａ】
2019506096.tif 000007
【図５Ｂ】
2019506096.tif 000008
【図５Ｃ】
2019506096.tif 000009
【図６Ａ】
2019506096.tif 000010
【図６Ｂ】
2019506096.tif 000011
【図６Ｃ】
2019506096.tif 000012
【図７】
2019506096.tif 000013
【図８Ａ】
2019506096.tif 000014
【図８Ｂ】
2019506096.tif 000015
【図８Ｃ】
2019506096.tif 000016
【図８Ｄ】
2019506096.tif 000017
【図８Ｅ】
2019506096.tif 000018
【図９】
2019506096.tif 000019
【図１０】
2019506096.tif 000020
【図１１】
2019506096.tif 000021
【図１２】
2019506096.tif 000022
【手続補正書】
【提出日】平成30年8月20日(2018.8.20)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
符号化ビデオデータを処理するための方法であって、
符号化ビデオデータに関連するファイルを受信するステップであって、前記符号化ビデオデータが、ファイルフォーマットに従って前記ファイルの中に記憶され、前記符号化ビデオデータが、2つ以上のレイヤを含み、前記2つ以上のレイヤが、前記ファイルの中の2つ以上のトラックの中に記憶される、ステップと、
前記2つ以上のレイヤの中から第1のレイヤを決定するステップであって、前記第1のレイヤが、第1のビットストリーム終了インジケータを含み、前記第1のレイヤが、前記2つ以上のレイヤのうちの、ビットストリーム終了インジケータを含む最上位レイヤであると決定される、ステップと、
前記2つ以上のレイヤの中からレイヤのセットを識別するステップであって、レイヤの前記セットが、再構成ビットストリームの中に含めるために選択された1つまたは複数のレイヤを含む、ステップと、
前記再構成ビットストリームを生成するステップであって、前記再構成ビットストリームを生成するステップが、複数のアクセスユニットを生成するステップを含み、前記複数のアクセスユニットが、レイヤの前記セットからの1つまたは複数のサンプルを含み、前記再構成ビットストリームの中の最終アクセスユニットが、前記第1のビットストリーム終了インジケータを含む、ステップと
を備える方法。
【請求項２】
前記複数のアクセスユニットが生成されるとき、前記再構成ビットストリームの中の前記最終アクセスユニットがビットストリーム終了インジケータを含まないと決定するステップと、
前記第1のビットストリーム終了インジケータを前記再構成ビットストリームの中の前記最終アクセスユニットに追加するステップと
をさらに備える、請求項1に記載の方法。
【請求項３】
レイヤの前記セットの中から第2のレイヤを識別するステップであって、前記第2のレイヤが、レイヤの前記セットの中から最上位レイヤとして識別され、前記第2のレイヤが、前記第1のレイヤとは異なり、レイヤの前記セットが、前記第1のレイヤを含まない、ステップと、
前記第1のレイヤが前記第2のレイヤよりも上位のレイヤであると決定するステップと、
前記第1のレイヤが前記第2のレイヤよりも上位のレイヤであることに基づいて、前記第1のビットストリーム終了インジケータを前記再構成ビットストリームの中の前記最終アクセスユニットに追加するステップと
をさらに備える、請求項1に記載の方法。
【請求項４】
レイヤの前記セットの中から第2のレイヤを識別するステップであって、前記第2のレイヤが、レイヤの前記セットの中から最上位レイヤとして識別され、前記第2のレイヤが、前記第1のレイヤとは異なり、レイヤの前記セットが、前記第1のレイヤを含む、ステップと、
前記第2のレイヤが前記第1のレイヤよりも上位のレイヤであると決定するステップと、
前記第2のレイヤが前記第1のレイヤよりも上位のレイヤであることに基づいて、前記第1のビットストリーム終了インジケータを前記再構成ビットストリームの中の前記最終アクセスユニットに移動させるステップと
をさらに備える、請求項1に記載の方法。
【請求項５】
前記再構成ビットストリームの中の前記最終アクセスユニットが2つ以上のビットストリーム終了インジケータを含むと決定するステップであって、前記2つ以上のビットストリーム終了インジケータが、前記第1のビットストリーム終了インジケータを含む、ステップと、
前記第1のビットストリーム終了インジケータ以外の各ビットストリーム終了インジケータを前記最終アクセスユニットから除去するステップと
をさらに備える、請求項1に記載の方法。
【請求項６】
前記2つ以上のレイヤの中から少なくとも2つのレイヤが各々、ビットストリーム終了インジケータを含む、請求項1に記載の方法。
【請求項７】
レイヤの前記セットが、レイヤの前記セットの中のレイヤからの前記サンプルが表示用に選択されることに基づいて選択されることを識別するステップ
をさらに備える、請求項1に記載の方法。
【請求項８】
前記ファイルフォーマットが、国際標準化機構(ISO)ベースメディアファイルフォーマットから導出される、請求項1に記載の方法。
【請求項９】
符号化ビデオを処理するための装置であって、
ファイルを記憶するように構成されたメモリであって、前記ファイルが、符号化ビデオデータを含み、前記符号化ビデオデータが、ファイルフォーマットに従って前記ファイルの中に記憶され、前記符号化ビデオデータが、2つ以上のレイヤを含み、前記2つ以上のレイヤが、前記ファイルの中の2つ以上のトラックの中に記憶される、メモリと、
プロセッサとを備え、前記プロセッサが、
前記2つ以上のレイヤの中から第1のレイヤを決定することであって、前記第1のレイヤが、第1のビットストリーム終了インジケータを含み、前記第1のレイヤが、前記2つ以上のレイヤのうちの、ビットストリーム終了インジケータを含む最上位レイヤであると決定される、決定することと、
前記2つ以上のレイヤの中からレイヤのセットを識別することであって、レイヤの前記セットが、再構成ビットストリームの中に含めるために選択された1つまたは複数のレイヤを含む、決定することと、
前記再構成ビットストリームを生成することであって、前記再構成ビットストリームを生成することが、複数のアクセスユニットを生成することを含み、前記複数のアクセスユニットが、レイヤの前記セットからの1つまたは複数のサンプルを含み、前記再構成ビットストリームの中の最終アクセスユニットが、前記第1のビットストリーム終了インジケータを含む、生成することと
を行うように構成される、装置。
【請求項１０】
前記プロセッサが、
前記複数のアクセスユニットが生成されるとき、前記再構成ビットストリームの中の前記最終アクセスユニットがビットストリーム終了インジケータを含まないと決定することと、
前記第1のビットストリーム終了インジケータを前記再構成ビットストリームの中の前記最終アクセスユニットに追加することと
を行うようにさらに構成される、請求項9に記載の装置。
【請求項１１】
前記プロセッサが、
レイヤの前記セットの中から第2のレイヤを識別することであって、前記第2のレイヤが、レイヤの前記セットの中から最上位レイヤとして識別され、前記第2のレイヤが、前記第1のレイヤとは異なり、レイヤの前記セットが、前記第1のレイヤを含まない、識別することと、
前記第1のレイヤが前記第2のレイヤよりも上位のレイヤであると決定することと、
前記第1のレイヤが前記第2のレイヤよりも上位のレイヤであることに基づいて、前記第1のビットストリーム終了インジケータを前記再構成ビットストリームの中の前記最終アクセスユニットに追加することと
を行うようにさらに構成される、請求項9に記載の装置。
【請求項１２】
前記プロセッサが、
レイヤの前記セットの中から第2のレイヤを識別することであって、前記第2のレイヤが、レイヤの前記セットの中から最上位レイヤとして識別され、前記第2のレイヤが、前記第1のレイヤとは異なり、レイヤの前記セットが、前記第1のレイヤを含む、識別することと、
前記第2のレイヤが前記第1のレイヤよりも上位のレイヤであると決定することと、
前記第2のレイヤが前記第1のレイヤよりも上位のレイヤであることに基づいて、前記第1のビットストリーム終了インジケータを前記再構成ビットストリームの中の前記最終アクセスユニットに移動させることと
を行うようにさらに構成される、請求項9に記載の装置。
【請求項１３】
前記プロセッサが、
前記再構成ビットストリームの中の前記最終アクセスユニットが2つ以上のビットストリーム終了インジケータを含むと決定することであって、前記2つ以上のビットストリーム終了インジケータが、前記第1のビットストリーム終了インジケータを含む、決定することと、
前記第1のビットストリーム終了インジケータ以外の各ビットストリーム終了インジケータを前記最終アクセスユニットから除去することと
を行うようにさらに構成される、請求項9に記載の装置。
【請求項１４】
前記2つ以上のレイヤの中から少なくとも2つのレイヤが各々、ビットストリーム終了インジケータを含む、請求項9に記載の装置。
【請求項１５】
レイヤの前記セットが、レイヤの前記セットの中のレイヤからの前記サンプルが表示用に選択されることに基づいて選択される、請求項9に記載の装置。
【請求項１６】
前記ファイルフォーマットが、ISOベースメディアファイルフォーマットから導出される、請求項9に記載の装置。
【請求項１７】
命令を記憶したコンピュータ可読記憶媒体であって、前記命令が、1つまたは複数のプロセッサによって実行されたとき、前記1つまたは複数のプロセッサに、
符号化ビデオデータに関連するファイルを受信することであって、前記符号化ビデオデータが、ファイルフォーマットに従って前記ファイルの中に記憶され、前記符号化ビデオデータが、2つ以上のレイヤを含み、前記2つ以上のレイヤが、前記ファイルの中の2つ以上のトラックの中に記憶される、受信することと、
前記2つ以上のレイヤの中から第1のレイヤを決定することであって、前記第1のレイヤが、第1のビットストリーム終了インジケータを含み、前記第1のレイヤが、前記2つ以上のレイヤのうちの、ビットストリーム終了インジケータを含む最上位レイヤであると決定される、決定することと、
前記2つ以上のレイヤの中からレイヤのセットを識別することであって、レイヤの前記セットが、再構成ビットストリームの中に含めるために選択された1つまたは複数のレイヤを含む、識別することと、
前記再構成ビットストリームを生成することであって、前記再構成ビットストリームを生成することが、複数のアクセスユニットを生成することを含み、前記複数のアクセスユニットが、レイヤの前記セットからの1つまたは複数のサンプルを含み、前記再構成ビットストリームの中の最終アクセスユニットが、前記第1のビットストリーム終了インジケータを含む、生成することと
を行わせる、コンピュータ可読記憶媒体。
【請求項１８】
前記1つまたは複数のプロセッサによって実行されたとき、前記1つまたは複数のプロセッサに、
前記複数のアクセスユニットが生成されるとき、前記再構成ビットストリームの中の前記最終アクセスユニットがビットストリーム終了インジケータを含まないと決定することと、
前記第1のビットストリーム終了インジケータを前記再構成ビットストリームの中の前記最終アクセスユニットに追加することと
を行わせる命令をさらに備える、請求項17に記載のコンピュータ可読記憶媒体。
【請求項１９】
前記1つまたは複数のプロセッサによって実行されたとき、前記1つまたは複数のプロセッサに、
レイヤの前記セットの中から第2のレイヤを識別することであって、前記第2のレイヤが、レイヤの前記セットの中から最上位レイヤとして識別され、前記第2のレイヤが、前記第1のレイヤとは異なり、レイヤの前記セットが、前記第1のレイヤを含まない、識別することと、
前記第1のレイヤが前記第2のレイヤよりも上位のレイヤであると決定することと、
前記第1のレイヤが前記第2のレイヤよりも上位のレイヤであることに基づいて、前記第1のビットストリーム終了インジケータを前記再構成ビットストリームの中の前記最終アクセスユニットに追加することと
を行わせる命令をさらに備える、請求項17に記載のコンピュータ可読記憶媒体。
【請求項２０】
前記1つまたは複数のプロセッサによって実行されたとき、前記1つまたは複数のプロセッサに、
レイヤの前記セットの中から第2のレイヤを識別することであって、前記第2のレイヤが、レイヤの前記セットの中から最上位レイヤとして識別され、前記第2のレイヤが、前記第1のレイヤとは異なり、レイヤの前記セットが、前記第1のレイヤを含む、識別することと、
前記第2のレイヤが前記第1のレイヤよりも上位のレイヤであると決定することと、
前記第2のレイヤが前記第1のレイヤよりも上位のレイヤであることに基づいて、前記第1のビットストリーム終了インジケータを前記再構成ビットストリームの中の前記最終アクセスユニットに移動させることと
を行わせる命令をさらに備える、請求項17に記載のコンピュータ可読記憶媒体。
【請求項２１】
前記1つまたは複数のプロセッサによって実行されたとき、前記1つまたは複数のプロセッサに、
前記再構成ビットストリームの中の前記最終アクセスユニットが2つ以上のビットストリーム終了インジケータを含むと決定することであって、前記2つ以上のビットストリーム終了インジケータが、前記第1のビットストリーム終了インジケータを含む、決定することと、
前記第1のビットストリーム終了インジケータ以外の各ビットストリーム終了インジケータを前記最終アクセスユニットから除去することと
を行わせる命令をさらに備える、請求項17に記載のコンピュータ可読記憶媒体。
【請求項２２】
前記2つ以上のレイヤの中から少なくとも2つのレイヤが各々、ビットストリーム終了インジケータを含む、請求項17に記載のコンピュータ可読記憶媒体。
【請求項２３】
レイヤの前記セットが、レイヤの前記セットの中のレイヤからの前記サンプルが表示用に選択されることに基づいて選択される、請求項17に記載のコンピュータ可読記憶媒体。
【請求項２４】
前記ファイルフォーマットが、ISOベースメディアファイルフォーマットから導出される、請求項17に記載のコンピュータ可読記憶媒体。
【請求項２５】
符号化ビデオデータを処理するための装置であって、
符号化ビデオデータに関連するファイルを受信するための手段であって、前記符号化ビデオデータが、ファイルフォーマットに従って前記ファイルの中に記憶され、前記符号化ビデオデータが、2つ以上のレイヤを含み、前記2つ以上のレイヤが、前記ファイルの中の2つ以上のトラックの中に記憶される、手段と、
前記2つ以上のレイヤの中から第1のレイヤを決定するための手段であって、前記第1のレイヤが、第1のビットストリーム終了インジケータを含み、前記第1のレイヤが、前記2つ以上のレイヤのうちの、ビットストリーム終了インジケータを含む最上位レイヤであると決定される、手段と、
前記2つ以上のレイヤの中からレイヤのセットを識別するための手段であって、レイヤの前記セットが、再構成ビットストリームの中に含めるために選択された1つまたは複数のレイヤを含む、手段と、
再構成ビットストリームを生成するための手段であって、前記再構成ビットストリームを生成することが、複数のアクセスユニットを生成することを含み、前記複数のアクセスユニットが、レイヤの前記セットからの1つまたは複数のサンプルを含み、前記再構成ビットストリームの中の最終アクセスユニットが、前記第1のビットストリーム終了インジケータを含む、手段と
を備える装置。
【請求項２６】
前記複数のアクセスユニットが生成されるとき、前記再構成ビットストリームの中の前記最終アクセスユニットがビットストリーム終了インジケータを含まないと決定するための手段と、
前記第1のビットストリーム終了インジケータを前記再構成ビットストリームの中の前記最終アクセスユニットに追加するための手段と
をさらに備える、請求項25に記載の装置。
【請求項２７】
レイヤの前記セットの中から第2のレイヤを識別するための手段であって、前記第2のレイヤが、レイヤの前記セットの中から最上位レイヤとして識別され、前記第2のレイヤが、前記第1のレイヤとは異なり、レイヤの前記セットが、前記第1のレイヤを含まない、手段と、
前記第1のレイヤが前記第2のレイヤよりも上位のレイヤであると決定するための手段と、
前記第1のレイヤが前記第2のレイヤよりも上位のレイヤであることに基づいて、前記第1のビットストリーム終了インジケータを前記再構成ビットストリームの中の前記最終アクセスユニットに追加するための手段と
をさらに備える、請求項25に記載の装置。
【請求項２８】
レイヤの前記セットの中から第2のレイヤを識別するための手段であって、前記第2のレイヤが、レイヤの前記セットの中から最上位レイヤとして識別され、前記第2のレイヤが、前記第1のレイヤとは異なり、レイヤの前記セットが、前記第1のレイヤを含む、手段と、
前記第2のレイヤが前記第1のレイヤよりも上位のレイヤであると決定するための手段と、
前記第2のレイヤが前記第1のレイヤよりも上位のレイヤであることに基づいて、前記第1のビットストリーム終了インジケータを前記再構成ビットストリームの中の前記最終アクセスユニットに移動させるための手段と
をさらに備える、請求項25に記載の装置。
【請求項２９】
前記再構成ビットストリームの中の前記最終アクセスユニットが2つ以上のビットストリーム終了インジケータを含むと決定するための手段であって、前記2つ以上のビットストリーム終了インジケータが、前記第1のビットストリーム終了インジケータを含む、手段と、
前記第1のビットストリーム終了インジケータ以外の各ビットストリーム終了インジケータを前記最終アクセスユニットから除去するための手段と
をさらに備える、請求項25に記載の装置。
【請求項３０】
前記2つ以上のレイヤの中から少なくとも2つのレイヤが各々、ビットストリーム終了インジケータを含む、請求項25に記載の装置。
【請求項３１】
レイヤの前記セットが、レイヤの前記セットの中のレイヤからの前記サンプルが表示用に選択されることに基づいて選択されることを識別するための手段
をさらに備える、請求項25に記載の装置。
【請求項３２】
前記ファイルフォーマットが、国際標準化機構(ISO)ベースメディアファイルフォーマットから導出される、請求項25に記載の装置。
【国際調査報告】
2019506096.tif 000023
2019506096.tif 000024