JP6649404B2 - 画像コーディング・デコーディングのための装置、方法およびコンピュータ・プログラム - Google Patents

画像コーディング・デコーディングのための装置、方法およびコンピュータ・プログラム Download PDF

Info

Publication number
JP6649404B2
JP6649404B2 JP2017559922A JP2017559922A JP6649404B2 JP 6649404 B2 JP6649404 B2 JP 6649404B2 JP 2017559922 A JP2017559922 A JP 2017559922A JP 2017559922 A JP2017559922 A JP 2017559922A JP 6649404 B2 JP6649404 B2 JP 6649404B2
Authority
JP
Japan
Prior art keywords
image
file
derived
picture
coded
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2017559922A
Other languages
English (en)
Other versions
JP2018510595A (ja
Inventor
ミスカ　ハンヌクセラ
ハンヌクセラ ミスカ
クマール マラマル バダキタル バイノッド
クマール マラマル バダキタル バイノッド
ライネマ ヤニ
ライネマ ヤニ
Original Assignee
ノキア テクノロジーズ オサケユイチア
ノキア テクノロジーズ オサケユイチア
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ノキア テクノロジーズ オサケユイチア, ノキア テクノロジーズ オサケユイチア filed Critical ノキア テクノロジーズ オサケユイチア
Publication of JP2018510595A publication Critical patent/JP2018510595A/ja
Application granted granted Critical
Publication of JP6649404B2 publication Critical patent/JP6649404B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H04N21/2353—Processing of additional data, e.g. scrambling of additional data or processing content descriptors specifically adapted to content descriptors, e.g. coding, compressing or processing of metadata
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/06—Message adaptation to terminal or network requirements
    • H04L51/063—Content adaptation, e.g. replacement of unsuitable content
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/07—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail characterised by the inclusion of specific contents
    • H04L51/10—Multimedia information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/30—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using hierarchical techniques, e.g. scalability
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/60—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding
    • H04N19/61—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding in combination with predictive coding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/23614—Multiplexing of additional data and video streams

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Library & Information Science (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Transfer Between Computers (AREA)

Description

本発明は、画像コーディング・デコーディングのための装置、方法およびコンピュータ・プログラムに関する。
ＩＳＯベース・メディア・ファイル・フォーマット（ＩＳＯＢＭＦＦ）は、音響、映像およびテレテキストなどのタイムド・メディアの記憶および転送のための包括的構造を規定する。近年、静止画像のハンドリングと同様画像シーケンスのハンドリングをも可能にするためにＩＳＯＢＭＦＦの能力を拡張することに向けて、研究作業が開始された。画像シーケンスの記憶および転送を可能にするため、ＭＰＥＧ−Ｈ Ｐａｒｔ１２としても知られるＩＳＯ／ＩＥＣ／２３００８−１２の中で、画像ファイル・フォーマットが定義されており、この定義はＩＳＯベース・メディア・ファイル・フォーマットに基づいている。
他の特性の中でも、画像ファイル・フォーマットは、派生画像をサポートする。アイテムは、それが別のアイテムに対する「ｄｉｍｇ」アイテム・リファレンスを含む場合、派生画像である。派生画像は、特定入力画像に対し回転などの特定動作を行うことによって、取得される。派生画像を取得するために行われる動作は、アイテムのｉｔｅｍ＿ｔｙｐｅによって識別される。派生画像に対する入力として使用される画像アイテムは、コード化された画像であることができ、あるいは他の派生画像アイテムであることができる。
多目的インターネット・メール拡張（ＭＩＭＥ）は、映像および音響、画像、ソフトウェアなどの異なる種類のデータ・ファイルをインターネット上で伝送し受信することを可能にするＥメール・プロトコルに対する拡張である。１つのインターネット・メディア・タイプは、ファイルが格納するデータのタイプを標示するためにインターネット上で使用される識別子である。このようなインターネット・メディア・タイプは、コンテンツ・タイプとも呼ぶことができる。異なるメディア・フォーマットを格納できるいくつかのＭＩＭＥタイプ／サブタイプの組合せが存在する。コンテンツ・タイプ情報を、メディア伝送の始めにＭＩＭＥヘッダー内に伝送用エンティティによって含めることができる。こうして、受信エンティティは、利用可能なコーデック・セットがあると仮定して特定のエレメントがレンダリングされ得るか否かを決定するために、このようなメディア・コンテンツの詳細を検査する必要がある場合がある。ここで説明されるパラメータが欠如している場合には、コーデックまたは、コンテンツをレンダリングするために必要とされる他のフィーチャを検査する目的で、各メディア・エレメントを検査することが必要である。
画像ファイル・フォーマットは、２つのＭＩＭＥタイプ、すなわち、画像および画像コレクション用のものと、画像シーケンス用のものを規定する。コーデック・パラメータのフォーマットは、これらのＭＩＭＥタイプについて規定される。しかしながら、この仕様には派生画像についての考慮が欠けており、動作を行う前に派生画像を編成する能力を有するか否かを評価するためにプレーヤが時間を費やすことなどのさまざまな問題が発生する可能性がある。
次に、上述の問題を少なくとも緩和するために、派生画像を編成する能力を評価するための方法が、本明細書中で提示される。
第１の態様に係る方法は、
第１のファイルの第１の記述を受信するステップであって、第１の記述は、少なくとも第１のファイルの中に含まれているかまたはこの第１のファイルによって参照されている派生画像の特性を含んでいる、ステップと、
派生画像の特性に基づいて、派生画像を取得すべきか否かを決定するステップと、
派生画像を取得するとの決定に応答して、派生画像を含む第１のファイルを取得するステップと、
を含む。
一実施形態によると、該方法は、
派生画像により表現されているもののような対応する画像コンテンツの表現を含む第２のファイルの第２の記述を受信するステップと、
派生画像の特性および第２の記述に基づいて、第１のファイルまたは第２のファイルを取得すべきか否かを決定するステップと、
をさらに含む。
一実施形態によると、第１の記述は、ＭＩＭＥタイプを含む。
一実施形態によると、ＭＩＭＥタイプなどの第１の記述は、少なくとも１つの派生画像についての、
− 少なくとも１つの派生画像のために使用される命令セットの第１の識別、
− 少なくとも１つの派生画像のためのコード化された入力画像のコーデック・プロファイルおよびコーデックの第２の識別、
− 少なくとも１つの派生画像の構築のために必要とされるリソースを表わすリソース・カウント、
という情報のうちの１つ以上を含む。
一実施形態によると、該方法は、第１のファイルから、派生ピクチャを編成するための、必要とされるリソースを標示する少なくとも１つの値をパースするステップと、
少なくとも１つの値に基づいて、派生画像が編成され得るか否かを決定するステップと、
をさらに含む。
第２の態様は、
少なくとも１つのプロセッサおよび少なくとも１つのメモリを含む装置において、前記少なくとも１つのメモリ上にはコードが記憶されており、このコードは、前記少なくとも１つのプロセッサによって実行された場合に、装置に、少なくとも、
第１のファイルの第１の記述を受信するステップであって、第１の記述は、少なくとも第１のファイルの中に含まれているかまたはこの第１のファイルによって参照されている派生画像の特性を含んでいるステップと、
派生画像の特性に基づいて、派生画像を取得すべきか否かを決定するステップと、
派生画像を取得するとの決定に応答して、派生画像を含む第１のファイルを取得するステップと、
を行わせる装置に関する。
第３の態様によると、
１つ以上の入力画像を取得するステップと、
派生画像を取得するために少なくとも１つの入力端上で行われるべき少なくとも１つの動作を決定するステップと、
第１のファイルの第１の記述を、メディア・コンテンツ記述内に含めるステップであって、第１の記述は、少なくとも第１のファイル内に含まれているかまたは第１のファイルにより参照されている派生画像の特性を含んでいるステップと、
を含む方法が提供されている。
一実施形態によると、
該方法は、派生画像により表現されているもののような対応する画像コンテンツの表現を含む第２のファイルの第２の記述を含めるステップをさらに含む。
一実施形態によると、第１の記述は、多目的インターネット・メール拡張（ＭＩＭＥ）タイプを含む。
一実施形態によると、ＭＩＭＥタイプなどの第１の記述は、少なくとも１つの派生画像についての、
− 少なくとも１つの派生画像のために使用される命令セットの第１の識別、
− 少なくとも１つの派生画像のためのコード化された入力画像のコーデック・プロファイルおよびコーデックの第２の識別、
− 少なくとも１つの派生画像の構築のために必要とされるリソースを表わすリソース・カウント、
という情報のうちの１つ以上を含む。
一実施形態によると、該方法は、
第１のファイル内に、派生画像を表現するデータ構造を含めるステップと、
第１のファイル内に、派生ピクチャを編成するための必要とされるリソースを標示する少なくとも１つの値を含めるステップと、
をさらに含む。
一実施形態によると、必要とされるリソースを標示する値は、
− 派生ピクチャを編成する任意の段階において必要とされる最大の画素、サンプルおよび／またはバイト・カウント以上の値、
− 派生ピクチャを編成するのに必要とされる任意のピクチャのために必要とされる最大の画素、サンプルおよび／またはバイト・カウント以上の値であって、派生ピクチャを編成するのに必要とされるピクチャが、派生ピクチャを編成するための中間動作の出力ピクチャを含んでいる値、
− 派生ピクチャを編成する上で使用できる動作タイプのセットを識別するための識別子であって、その一方で動作タイプ・セットに含まれていない動作タイプは、派生ピクチャの編成で使用されない識別子、
のうちの１つ以上を含む。
第４の態様は、
少なくとも１つのプロセッサおよび少なくとも１つのメモリを含む装置において、前記少なくとも１つのメモリ上にはコードが記憶されており、このコードは、前記少なくとも１つのプロセッサによって実行された場合に、装置に、少なくとも、
１つ以上の入力画像を取得するステップと、
派生画像を取得するために少なくとも１つの入力端上で行われるべき少なくとも１つの動作を決定するステップと、
第１のファイルの第１の記述を、メディア・コンテンツ記述内に含めるステップであって、第１の記述は、少なくとも第１のファイル内に含まれているかまたは第１のファイルにより参照されている派生画像の特性を含んでいるステップと、
を行わせる、装置に関する。
本発明をより良く理解するために、ここで、一例として、添付図面が参照される。
本発明の実施形態を利用する電子デバイスを概略的に示す。 本発明の実施形態を利用するために好適なユーザー機器を概略的に示す。 さらに、無線および有線ネットワーク接続を用いて接続された本発明の実施形態を利用する電子デバイスを概略的に示す。 本発明の実施形態を実装するために好適なエンコーダを概略的に示す。 ＩＳＯＢＭＦＦボックス構造の一例を示す。 本発明の一実施形態に係るメディア・プレーヤーの動作フローチャートを示す。 本発明の一実施形態に係るファイル・クリエータの動作フローチャートを示す。 本発明の実施形態を実装するために好適なデコーダの概略図を示す。
以下では、視点切替えを開始するための好適な装置および考えられるメカニズムについて詳細に説明する。この点において、まず、図１および２が参照され、ここで図１は、本発明の一実施形態に係るコーデックを組込むことのできる例示的装置または電子デバイス５０の概略的ブロック図として、一例示的実施形態に係るビデオ・コーディング・システムのブロック図を示す。図２は、一例示的実施形態に係る装置のレイアウトを示す。図１および２のエレメントについて、次に説明する。
電子デバイス５０は例えば、移動体端末または無線通信システムのユーザー機器であることができる。しかしながら、本発明の実施形態は、ビデオ画像のエンコーディングとデコーディングまたはエンコーディングまたはデコーディングを必要とする可能性のある任意の電子デバイスまたは装置内で実装可能であるということが認識されると思われる。
装置５０は、デバイスを組込み、保護するためのハウジング３０を備えることができる。装置５０はさらに、液晶ディスプレイの形をしたディスプレイ３２をさらに備えることができる。本発明の他の実施形態において、ディスプレイは、画像または映像を表示するのに好適である任意の好適なディスプレイ技術であることができる。装置５０はさらに、キーパッド３４を含むことができる。本発明の他の実施形態においては、任意の好適なデータまたはユーザー・インターフェース・メカニズムを利用することができる。例えば、ユーザー・インターフェースを、タッチ・センサー式ディスプレイの一部として仮想キーパッドまたはデータ・エントリー・システムとして実装することができる。
装置は、マイクロホン３６または、デジタルまたはアナログ信号入力端であることのできる任意の好適な音響入力端を備えることができる。装置５０はさらに、本発明の実施形態においてはイヤーピース３８、スピーカーまたはアナログ音響出力またはデジタル音響出力接続のうちのいずれか１つであることのできる音響出力デバイスを備えることができる。装置５０は同様に、バッテリ４０を備えることもできる（または、本発明の他の実施形態において、デバイスは、太陽電池などの任意の好適な移動体エネルギー・デバイスによる動力を受けることができる）。装置はさらに、画像および／または映像を記録および／または捕捉する能力を有するカメラ４２を備えることができる。装置５０はさらに、他のデバイスに対する短距離見通し通信のための赤外線ポートを備えることができる。他の実施形態において、装置５０はさらに、例えばＢｌｕｅｔｏｏｔｈ無線接続またはＵＳＢ／ファイアーワイヤ有線接続などの任意の好適な短距離通信ソリューションを備えることができる。
装置５０は、装置５０を制御するためのコントローラ５６またはプロセッサを備えることができる。コントローラ５６は、本発明の実施形態においては画像および音響データの形をした両方のデータを記憶でき、および／または同様にコントローラ５６上での実施のための命令も記憶できるメモリ５８に接続されることができる。コントローラ５６はさらに、音響および／または映像データのコーディングおよびデコーディングを実施するため、またはコントローラによって行われるコーディングおよびデコーディングを補助するために好適であるコーデック回路５４に接続されることができる。
装置５０は、さらに、ユーザー情報を提供しネットワークにおけるユーザーの認証および承認のための認証情報を提供するために好適であるために、例えばＵＩＣＣおよびＵＩＣＣ読取り機などのカード読取り機４８およびスマート・カード４６を備えることができる。
装置５０は、例えばセルラー通信ネットワーク、無線通信システムまたは無線ローカル・エリア・ネットワークとの通信のために無線通信信号を生成するのに好適である、コントローラに接続された無線インターフェース回路５２を備えることができる。装置５０はさらに、他の装置に対して無線インターフェース回路５２で生成された無線周波数信号を伝送し、他の装置からの無線周波数信号を受信するため、無線インターフェース回路５２に接続されたアンテナ４４を備えることができる。
装置５０は、後に処理のためコーデック５４またはコントローラに渡される個別のフレームを記録または検出する能力を有するカメラを備えることができる。装置は、伝送および／または記憶に先立ち別のデバイスから処理のためのビデオ画像データを受信することができる。装置５０は同様に、無線または有線接続のいずれかにより、コーディング／デコーディングのための画像を受信することができる。
図３に関しては、本発明の実施形態を内部で利用できるシステムの一例が示されている。システム１０は、１つ以上のネットワークを通して通信できる多数の通信デバイスを備えている。システム１０は、無線セル方式電話ネットワーク（例えばＧＳＭ（登録商標）、ＵＭＴＳ、ＣＤＭＡネットワークなど）、ＩＥＥＥ８０２．Ｘ規格のいずれかによって定義されているものなどの無線ローカル・エリア・ネットワーク（ＷＬＡＮ）、Ｂｌｕｅｔｏｏｔｈ（登録商標）パーソナル・エリア・ネットワーク、イーサネット（登録商標）・ローカル・エリア・ネットワーク、トークン・リング・ローカル・エリア・ネットワーク、広域ネットワークおよびインターネットを非限定的に含む無線または有線ネットワークの任意の組合せを備えることができる。
システム１０は、本発明の実施形態を実装するために好適である有線および無線の両方の通信デバイスおよび／または装置５０を含むことができる。
例えば、図３に示されているシステムは、携帯電話ネットワーク１１およびインターネット２８の一表現を示す。インターネット２８に対する接続性は、長距離無線接続、短距離無線接続および非限定的に電話ライン、ケーブル・ライン、電力ラインおよび類似の通信経路を含めたさまざまな有線接続を含むことができるが、これらに限定されない。
システム１０に示された例示的通信デバイスは、電子デバイスまたは装置５０、携帯情報端末（ＰＤＡ）と携帯電話１４の組合せ、ＰＤＡ１６、結合メッセージング・デバイス（ＩＭＤ）１８、デスクトップ・コンピュータ２０、ノート型コンピュータ２２を含むことができるが、これらに限定されない。装置５０は、固定型または移動中の個人により持ち運ばれている場合の移動型であることができる。装置５０は同様に、車、トラック、タクシー、バス、列車、船舶、飛行機、自転車、オートバイまたは任意の類似の好適な輸送様式を非限定的に含めた輸送様式内に位置設定されることもできる。
実施形態は同様に、セット・トップ・ボックスすなわち、ディスプレイまたは無線能力を有するかまたは有していない可能性のあるデジタルＴＶ受信機内、ハードウェアまたはソフトウェアまたはエンコーダ／デコーダ実装の組合せを有するタブレットまたは（ラップトップ）パーソナル・コンピュータ（ＰＣ）内、さまざまなオペレーティング・システム内、およびハードウェア／ソフトウェアベースのコーディングを提供するチップセット、プロセッサ、ＤＳＰおよび／または埋込み型システム内でも、実装されることができる。
いくつかのまたはさらなる装置は、呼出しおよびメッセージを送信および受信し、基地局２４に対する無線接続２５を通してサービス・プロバイダと通信することができる。基地局２４は、携帯電話ネットワーク１１とインターネット２８の間の通信を可能にするネットワーク・サーバー２６に接続されることができる。システムは、追加の通信デバイスおよびさまざまなタイプの通信デバイスを含むことができる。
通信デバイスは、符号分割多元接続（ＣＤＭＡ）、汎欧州デジタル移動電話方式（ＧＳＭ）、ユニバーサル移動体通信システム（ＵＭＴＳ）、時分割多元接続（ＴＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、伝送制御プロトコル−インターネット・プロトコル（ＴＣＰ−ＩＰ）、ショート・メッセージング・サービス（ＳＭＳ）、マルチメディア・メッセージング・サービス（ＭＭＳ）、Ｅメール、インスタント・メッセージング・サービス（ＩＭＳ）、ブルートゥース（登録商標）、ＩＥＥＥ８０２．１１および任意の類似の無線通信テクノロジーを非限定的に含むさまざまな伝送技術を用いて通信することができる。本発明のさまざまな実施形態の実装に関与する通信デバイスは、無線、赤外線、レーザー、ケーブル接続、および任意の好適な接続を非限定的に含むさまざまな媒体を用いて通信することができる。
電気通信およびデータネットワークにおいて、チャネルは、物理チャネルまたは論理チャネルのいずれかを意味することができる。物理チャネルは、ワイヤなどの物理的伝送媒体を意味することができ、一方論理チャネルは、複数の論理チャネルを搬送する能力を有する多重化された媒体上の論理的接続を意味する。チャネルは、例えばビットストリームなどの情報信号を１つ以上の送信者（または送信機）から１つ以上の受信機まで搬送するために使用可能である。
実時間転送プロトコル（ＲＴＰ）は、音響および映像などのタイムド・メディアの実時間転送のために広く使用されている。ＲＴＰは、ユーザー・データグラム・プロトコル（ＵＤＰ）上で動作でき、ＵＤＰはそれ自体インターネット・プロトコル（ＩＰ）上で動作できる。ＲＴＰは、ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ３５５０．ｔｘｔから入手可能であるインターネット・エンジニアリング・タスク・フォース（ＩＥＴＦ）リクエスト・フォー・コメント（ＲＦＣ）３５５０中で規定されている。ＲＴＰ転送では、メディア・データは、ＲＴＰパケット内にカプセル化される。典型的に、各メディア・タイプまたはメディア・コーディング・フォーマットは、専用ＲＴＰペイロード・フォーマットを有する。
ＲＴＰセッションは、ＲＴＰと通信する参加者グループの間のつながりである。それは、一定数のＲＴＰストリームを潜在的に運ぶことのできるグループ通信チャネルである。ＲＴＰストリームは、メディア・データを含むＰＴＰパケットのストリームである。ＲＴＰストリームは、特定のＲＴＰセッションに属するＳＳＲＣによって識別される。ＳＳＲＣは、ＲＴＰパケット・ヘッダー内の３２ビットのＳＳＲＣフィールドである同期化ソースまたは同期化ソース識別子のいずれかを意味する。同期化ソースは、同期化ソースからの全てのパケットが同じタイミングおよびシーケンス番号空間の一部を成し、したがって受信機は、再生のために同期化ソースによりパケットをグループ化することができることを特徴とする。同期化ソースの例としては、マイクロホンまたはカメラ、またはＰＴＰミキサーなどの信号源から派生したパケット・ストリームの送信者が含まれる。各々のＲＴＰストリームは、ＲＴＰセッション内で一意的であるＳＳＲＣによって識別される。ＲＴＰストリームは、論理チャネルとみなすことができる。
ＩＳＯ／ＩＥＣ１３８１８−１内または、同等にＩＴＵ−Ｔ勧告Ｈ．２２２．０内に規定されているＭＰＥＧ−２転送ストリーム（ＴＳ）が、多重化されたストリーム内で音響、映像および他の媒体ならびにプログラム・メタデータまたは他のメタデータを運ぶためのフォーマットである。ＴＳ内で基本ストリーム（パケット化された基本ストリームとしても知られている）を識別するためには、パケット識別子（ＰＩＤ）が使用される。したがって、ＭＰＥＧ−２ＴＳ内の論理チャネルを、特定のＰＩＤ値に対応するものとみなすことができる。
映像コーデックは、入力映像を、記憶／伝送のために好適である圧縮された表現に変換するエンコーダおよび、圧縮された映像表現をビューイングできる形態に戻るよう展開することのできるデコーダからなる。映像エンコーダおよび／または映像デコーダは、同様に、互いに分離したものであることもできる。すなわちコーデックを形成する必要はない。典型的には、エンコーダは、映像をよりコンパクトな形で、（すなわちより低いビットレートで）表現するために、原初の映像シーケンス内のいくつかの情報を破棄する。後続して定義するように、画像シーケンスをエンコードするために、映像エンコーダを使用することができ、コード化された画像シーケンスをデコードするために、映像デコーダを使用することができる。映像エンコーダまたは映像エンコーダのイントラ・コーディング部分または画像エンコーダを、画像をエンコードするために使用することができ、コード化された画像をデコードするためには、映像デコーダまたは映像デコーダのインター・デコーディング部分または画像デコーダを使用することができる。
典型的なハイブリッド映像エンコーダ、例えばＩＴＵ−ＴＨ．２６３およびＨ．２６４の多くのエンコーダ実装は、２段階で映像情報をエンコードする。第１に、一部のピクチャ・エリア（または「ブロック」）内の画素値が、例えば、（先にコード化された映像フレームの１つの中で、コーディング中のブロックに密に対応するもののエリアを発見し標示する）動き補償手段によってか、あるいは（規定された方法でコーディングすべきブロックの周りの画素値を使用する）空間的手段によって、予測される。第２に、予測エラー、すなわち予測された画素ブロックと原初の画素ブロックの間の差は、コーディングされる。これは典型的には、規定された変換（例えば離散的コサイン変換（ＤＣＴ）またはその変形形態）を使用して画素値の差を変換し、係数を量子化し、量子化係数をエントロピー・コーディングすることによって行われる。量子化プロセスの忠実度を変動させることにより、エンコーダは、画素表現の精度（ピクチャ品質）と結果としてのコーデッド映像表現のサイズ（ファイル・サイズまたは伝送ビットレート）との間のバランスを制御することができる。
時間予測、動き補償または動き補償予測とも呼ぶことのできるインター予測は、時間冗長性を低減させる。インター予測において、予測ソースは、先にデコード化されたピクチャである。イントラ予測は、同じピクチャ内の隣接する画素が相関される確率が高いという事実を利用する。イントラ予測は、空間または変換ドメイン内で行われる可能性がある。すなわち、サンプル値または変換係数のいずれかが予測され得る。イントラ予測は、典型的には、いかなるインター予測も適用されないイントラ・コーディング内で運用される。
コーディング・プロシージャの１つの成果は、例えば動きベクトルおよび量子化変換係数などのコーディング・パラメータのセットである。最初に空間的または時間的に隣接するパラメータから予測されている場合、多くのパラメータをより効率良くエントロピー・コーディングすることができる。例えば、動きベクトルを、空間的に近接する動きベクトルから予測することができ、動きベクトル予測との関係における差のみをコーディングすることができる。コーディング・パラメータの予測およびイントラ予測を、集合的にイン・ピクチャ予測と呼ぶことができる。
図４は、本発明の実施形態を利用するのに好適である映像エンコーダのブロック図を示す。図４は、２つのレイヤのためのエンコーダを提示しているが、提示されたエンコーダは同様に、１レイヤのみをエンコードするように単純化されるかまたは３つ以上のレイヤをエンコードするように拡張されることも可能であるということが認識されると思われる。図４は、ベース・レイヤ用の第１のエンコーダ・セクション５００および強化レイヤ用の第２のエンコーダ・セクションを含む映像エンコーダの一実施形態を例示する。第１のエンコーダ・セクション５００および第２のエンコーダ・セクション５０２の各々は、入来するピクチャをエンコードするための類似のエレメントを備えることができる。エンコーダ・セクション５００、５０２は、画素予測子３０２、４０２、予測エラーエンコーダ３０３、４０３および予測エラーデコーダ３０４、４０４を含むことができる。図４は同様に、インター予測子３０６、４０６、イントラ予測子３０８、４０８、モード・セレクタ３１０、４１０、フィルター３１６、４１６および参照フレーム・メモリ３１８、４１８を含むものとして、画素予測子３０２、４０２の一実施形態を示している。第１のエンコーダ・セクション５００の画素予測子３０２は、インター予測子３０６（画像と動き補償参照フレーム３１８との間の差を決定する）およびイントラ予測子３０８（現行フレームまたはピクチャのすでに処理された部分のみに基づいて画像についての予測を決定する）の両方におけるエンコードされるべき映像ストリームのベース・レイヤ画像を受信する３００。インター予測子およびイントラ予測子の両方の出力は、モード・セレクタ３１０に渡される。イントラ予測子３０８は、２つ以上のイントラ予測モードを有することができる。したがって、各モードは、イントラ予測を行ない、予測された信号をモード・セレクタ３１０に提供することができる。モード・セレクタ３１０は同様に、ベース・レイヤ・ピクチャのコピーも受信する３００。対応して、第２のエンコーダ・セクション５０２の画素予測子４０２は、インター予測子４０６（画像と動き補償参照フレーム４１８の間の差を決定する）およびイントラ予測子４０８（現行フレームまたはピクチャのすでに処理された部分にのみ基づいて画像ブロックについての予測を決定する）の両方においてエンコードされるべき映像ストリームの強化レイヤ画像を受信する４００。インター予測子およびイントラ予測子の両方の出力は、モード・セレクタ４１０に渡される。イントラ予測子４０８は、２つ以上のイントラ予測モードを有することができる。したがって、各モードは、イントラ予測を行ない、モード・セレクタに対して予測された信号を提供することができる。モード・セレクタ４１０は同様に、強化レイヤピクチャ４００のコピーも受信する。
現行ブロックをエンコードするためにどのエンコーディング・モードが選択されるかに応じて、インター予測子３０６、４０６の出力または、任意のイントラ予測子モードの１つの出力、またはモード・セレクタ内の表面エンコーダの出力は、モード・セレクタ３１０、４１０の出力端に渡される。モード・セレクタの出力は、第１の加算デバイス３２１、４２１に渡される。第１の加算デバイスは、予測エラーエンコーダ３０３、４０３に対して入力される第１の予測エラー信号３２０、４２０を生成するために、画素予測子３０２、４０２の出力をベース・レイヤ・ピクチャ３００／強化レイヤピクチャ４００から減算することができる。
画素予測子３０２、４０２はさらに、予備再構成器３３９、４３９から、画像ブロック３１２、４１２の予測表現と予測エラーデコーダ３０４、４０４の出力３３８、４３８との組合せを受信する。予備再構成された画像３１４、４１４は、イントラ予測子３０８、４０８およびフィルター３１６、４１６に渡されることができる。予備表現を受信したフィルター３１６、４１６は、予備表現をフィルタリングし、参照フレーム・メモリ３１８、４１８内にセーブすることのできる最終的な再構築画像３４０、４４０を出力することができる。参照フレーム・メモリ３１８は、将来のベース・レイヤ・ピクチャ３００がインター予測動作において比較される参照画像として使用されるために、インター予測子３０６に接続されることができる。いくつかの実施形態に係る強化レイヤのインター・レイヤサンプル予測および／またはインター・レイヤ動き情報予測のためのソースとなるようにベース・レイヤが選択され標示されることを受けて、参照フレーム・メモリ３１８は同様に、将来の強化レイヤピクチャ４００がインター予測動作において比較される参照画像として使用されるためにインター予測子４０６に接続されることができる。その上、参照フレーム・メモリ４１８は、将来の強化レイヤピクチャ４００がインター予測動作において比較される参照画像として使用されるためにインター予測子４０６に接続されることができる。
第１のエンコーダ・セクション５００のフィルター３１６からのフィルタリング・パラメータは、いくつかの実施形態に係る強化レイヤのフィルタリング・パラメータを予測するためのソースとなるようにベース・レイヤが選択され標示されることを受けて、第２のエンコーダ・セクション５０２に対して提供されることができる。
予測エラーエンコーダ３０３、４０３は、変換ユニット３４２、４４２および量子化器３４４、４４４を含む。変換ユニット３４２、４４２は、第１の予測エラー信号３２０、４２０を変換ドメインへと変換する。変換は、例えばＤＣＴ変換である。量子化器３４４、４４４は、量子化係数を形成するために、変換ドメイン信号、例えばＤＣＴ係数を量子化する。
予測エラーデコーダ３０４、４０４は、予測エラーエンコーダ３０３、４０３からの出力を受信し、第２の加算デバイス３３９、４３９における画像ブロック３１２、４１２の予測表現と組合わされた時点で予備再構成された画像３１４、４１４を生成するデコーデッド予測エラー信号３３８、４３８を生成するために、予測エラーエンコーダ３０３、４０３の反対のプロセスを行う。予測エラーデコーダは、変換信号を再構築するために、例えばＤＣＴ係数などの量子化係数値を脱量子化する脱量子化器３６１、４６１および、再構築された変換信号に対する逆変換を行う逆変換ユニット３６３、４６３を備えるものとみなされることができ、ここで逆変換ユニット３６３、４６３の出力は、再構築されたブロックを格納している。予測エラーデコーダは、同様に、さらなるデコーデッド情報およびフィルターパラメータにしたがって再構築ブロックをフィルタリングすることのできるブロック・フィルタをも含むことができる。
エントロピー・エンコーダ３３０、４３０は、予測エラーエンコーダ３０３、４０３の出力を受信し、エラー検出および補正能力を提供するために、信号に対し好適なエントロピー・エンコーディング／可変長エンコーディングを行うことができる。エントロピー・エンコーダ３３０、４３０の出力を、例えばマルチプレクサ５０８によって、ビットストリーム内に挿入することができる。
Ｈ．２６４／ＡＶＣ規格は、国際電気通信連合の電気通信標準化部門（ＩＴＵ−Ｔ）の映像コーディング専門家グループ（ＶＣＥＧ）と、国際標準化機構（ＩＳＯ）／国際電気技術委員会（ＩＥＣ）の動画専門家グループ（ＭＰＥＧ）の合同映像チーム（ＪＶＴ）によって開発された。Ｈ．２６４／ＡＶＣ規格は、両方の親標準化機構によって公開されており、ＩＴＵ−Ｔ勧告Ｈ．２６４および、ＭＰＥＧ−４Ｐａｒｔ１０アドバンスト映像コーディング（ＡＶＣ）としても知られるＩＳＯ／ＩＥＣ国際規格１４４９６−１０と呼ばれている。仕様に対して新たな拡張または特徴を統合する、Ｈ．２６４／ＡＶＣ規格の多数のバージョンが存在してきた。これらの拡張には、スケーラブル映像コーディング（ＳＶＣ）およびマルチビュー映像コーディング（ＭＶＣ）が含まれる。
高効率映像コーディング（ＨＥＶＣとしても知られるＨ．２６５／ＨＥＶＣ）規格のバージョン１は、ＶＣＥＧとＭＰＥＧの合同協力チーム−映像コーディング（ＪＣＴ−ＶＣ）によって開発された。規格は、両方の親標準化機構によって公開されており、ＩＴＵ−Ｔ勧告Ｈ．２６５および、ＭＰＥＧ−ＨＰａｒｔ２高効率映像コーディング（ＨＥＶＣ）としても知られるＩＳＯ／ＩＥＣ国際規格２３００８−２と呼ばれている。Ｈ．２６５／ＨＥＶＣのバージョン２は、それぞれＳＨＶＣ、ＭＶ−ＨＥＶＣ、およびＲＥＸＴと省略できる、スケーラブル、マルチビュー、および忠実度範囲拡張を含んでいた。Ｈ．２６５／ＨＥＶＣのバージョン２は、ＩＴＵ−Ｔ勧告Ｈ．２６５（１０／２０１４）として予め公開されたものであり、２０１５年にＩＳＯ／ＩＥＣ２３００８−２の第２版として公開される見込みである。現在、それぞれ３Ｄ−ＨＥＶＣおよびＳＣＣと省略できる３次元およびスクリーン・コンテンツ・コーディング拡張を含めた、Ｈ．２６５／ＨＥＶＣに対するさらなる拡張を開発するための進行中の標準化プロジェクトが存在している。
ＳＨＶＣ、ＭＶ−ＨＥＶＣおよび３Ｄ−ＨＥＶＣは、ＨＥＶＣ規格のバージョン２の付録Ｆ中に規定された、共通基準仕様を使用する。この共通基準は、例えば、インター・レイヤ依存性などの、ビットストリームのレイヤの特性のいくつかならびにデコーディング・プロセス、例えばマルチ・レイヤ・ビットストリームについてのインター・レイヤ参照ピクチャおよびピクチャ・オーダー・カウントの導出を含めた参照ピクチャ・リスト構築を規定する、ハイレベル・シンタックスおよびセマンティクスを含む。付録Ｆは、同様に、ＨＥＶＣの潜在的な後続マルチ・レイヤ拡張において使用可能である。以下では、ＳＨＳＣおよび／またはＭＶ−ＨＥＶＣなどの特定の拡張を参照して、映像エンコーダ、映像デコーダ、エンコーディング方法、デコーディング方法、ビットストリーム構造および／または実施形態を説明することができるものの、これらは、概してＨＥＶＣのあらゆるマルチ・レイヤ拡張に対して適用可能であり、さらに一般に、任意のマルチ・レイヤ映像コーディングスキームに対して適用可能である、ということを理解すべきである。
Ｈ．２６４／ＡＶＣおよびＨＥＶＣのいくつかの主要な定義、ビットストリームおよびコーディング構造および概念は、該実施形態を実装することのできる、映像エンコーダ、デコーダ、エンコーディング方法、デコーディング方法およびビットストリーム構造の一例として、本節において説明されている。Ｈ．２６４／ＡＶＣの主要な定義、ビットストリームおよびコーディング構造および概念のいくつかは、ＨＥＶＣの場合と同じであり、したがって、これらは以下で合同で説明される。本発明の態様は、Ｈ．２６４／ＡＶＣまたはＨＥＶＣに限定されず、むしろ説明は、その上に本発明を部分的または完全に実現することのできる１つの考えられる基礎について提供されている。
初期の多くの映像コーディング規格と同様に、エラーのないビットストリームのためのビットストリーム・シンタックスおよびセマンティクスならびにデコーディング・プロセスは、Ｈ．２６４／ＡＶＣおよびＨＥＶＣ内で規定されている。エンコーディングプロセスは規定されていないが、エンコーダは、適合ビットストリームを生成しなければならない。ビットストリームおよびデコーダ適合性は、仮想参照デコーダ（ＨＲＤ）を用いて確認可能である。規格は、伝送エラーおよび損失に対処する上で一助となるコーディング・ツールを含むが、エンコーディングにおけるツールの使用は任意であり、誤ったビットストリームについては、いかなるデコーディング・プロセスも規定されていない。
既存の規格の説明内ならびに例示的実施形態の説明内において、シンタックス・エレメントは、ビットストリームで表現されたデータ・エレメントとして定義することができる。シンタックス構造は、規定の順序でビットストリーム内に共存するゼロまたはそれ以上のシンタックス・エレメントとして定義することができる。既存の規格の説明内ならびに例示的実施形態の説明内においては、「外部手段によって」または「外部手段を通して」なる言い回しを使用することができる。例えば、デコーディング・プロセス中で使用されるシンタックス構造または変数の値などのエンティティは、「外部手段によって」デコーディング・プロセスに提供されることができる。「外部手段によって」なる言い回しは、そのエンティティが、エンコーダによって作成されたビットストリーム内に含まれず、むしろ例えば制御プロトコルを用いてビットストリームから外部的に搬送される、ということを標示することができる。それは、代替的にまたは付加的に、エンティティがエンコーダによって作成されず、むしろ例えばプレーヤ内またはデコーダを使用しているデコーディング制御論理またはそれに類するものの中で作成され得ることを意味することができる。デコーダは、可変値などの外部手段を入力するためのインターフェースを有することができる。
プロファイルとは、デコーディング／コーディング規格または仕様によって規定される全ビットストリーム・シンタックスのサブセットと定義することができる。所与のプロファイルのシンタックスによって課せられた限界の内部では、デコーデッド・ピクチャの規定サイズなどのビットストリーム内のシンタックス・エレメントがとる値に応じて、エンコーダおよびデコーダの性能に非常に大きな変動を求めることがなおも可能である。多くの利用分野において、特定のプロファイル内のシンタックスの全ての仮説的使用を取り扱う能力を有するデコーダを実装することは、実用的でも経済的でもない可能性がある。この問題に対処するために、レベルを使用することができる。レベルは、デコーディング／コーディング規格または仕様において規定された変数およびビットストリーム内のシンタックス・エレメントの値に課せられる制約の規定されたセットとして定義することができる。これらの制約は、値に対する単なる限界であることができる。代替的にまたは付加的には、これらは、値の算術的組合せ（例えば、ピクチャの幅×ピクチャの高さ×毎秒デコーディングされるピクチャの数）に対する制約の形をとることができる。レベルのための制約を規定する他の手段も、使用することができる。１つのレベル内で規定される制約のいくつかは、例えば、最大ピクチャサイズ、最大ビットレートおよび、１秒などの時間あたりのマイクロブロックなどのコーディング・ユニットの観点から見た最大データ・レートに関するものであることができる。同じレベル・セットを、全てのプロファイルについて定義することができる。例えば、異なるプロファイルを実装する端末のインターオペラビリティを増大させるために、各レベルの定義の大部分または全ての側面が異なるプロファイルを横断して共通であることができることが好ましい場合がある。ティアとは、ビットストリーム内のシンタックス・エレメントの値に対して課せられるレベル制約の規定のカテゴリとして定義でき、ここでレベル制約は１つのティア内でネスティングされ、一定のティアおよびレベルに適合するデコーダが、そのレベルまたはそれより下位の任意のレベルの同じティアまたはより低いティアに適合する全てのビットストリームをデコーディングする能力を有するものと考えられる。
いくつかの事例において、適合性ポイントは、特定のプロファイルと特定のレベルの組合せ、または特定のプロファイル、特定のティアおよび特定のレベルの組合せとして定義することができる。適合性ポイントを代替的な方法で定義することもできるが、ビットストリームの特性および限界および／またはデコーダの特性および（最大）リソースを規定するというその意図は変更なく保つことができるという点を理解する必要がある。
それぞれＨ．２６４／ＡＶＣまたはＨＥＶＣエンコーダに対する入力およびＨ．２６４／ＡＶＣまたはＨＥＶＣデコーダの出力のための基本ユニットはピクチャである。エンコーダに対する入力として提供されたピクチャは、ソース・ピクチャとも呼ぶことができ、デコーダによりデコードされたピクチャは、デコーデッド・ピクチャと呼ぶことができる。
ソース・ピクチャおよびデコーデッド・ピクチャは、各々、以下のサンプル・アレイ・セットの１つなどの１つ以上のサンプル・アレイで構成される。
− ルマ（Ｙ）のみ（モノクロ）、
− ルマおよび２つのクロマ（ＹＣｂＣｒまたはＹＣｇＣｏ）、
− 緑、青および赤（ＧＢＲ、ＲＧＢとしても知られる）、
− 他の未規定モノクロまたは三刺激カラー・サンプリングを表わすアレイ（例えばＹＺＸ、ＸＹＺとしても知られる）。
以下では、これらのアレイは、ルマ（またはＬまたはＹ）およびクロマと呼ぶことができ、ここで、使用されている実際の色表現方法とは無関係に、２つのクロマ・アレイをＣｂおよびＣｒと呼ぶことができる。使用されている実際の色表現方法は、例えばＨ．２６４／ＡＶＣおよび／またはＨＥＶＣ．ＡのＶｉｄｅｏ Ｕｓａｂｉｌｉｔｙ Ｉｎｆｏｒｍａｔｉｏｎ（ＶＵＩ）シンタックスを用いて、コーデッド・ビットストリーム内などで標示可能である。一構成要素を、３つのサンプル・アレイ（ルマと２つのクロマ）のうちの１つのアレイまたはこのアレイの単一のサンプルまたは、モノクロ・フォーマットのピクチャを編成するアレイまたはこのアレイの単一のサンプルとして定義することができる。
Ｈ．２６４／ＡＶＣおよびＨＥＶＣにおいて、ピクチャは、フレームまたはフィールドのいずれかであることができる。フレームは、ルマ・サンプルおよび場合によっては対応するクロマ・サンプルのマトリクスを含む。フィールドは、フレームの交互のサンプル行のセットであり、ソース信号がインターレースされている場合、エンコーダ入力として使用できる。クロマ・サンプル・アレイは不在であることができ（したがってモノクロ・サンプリングが使用中であり得る）、あるいはルマ・サンプル・アレイに比較される場合、クロマ・サンプル・アレイをサブサンプリングすることができる。クロマ・フォーマットを以下のように要約することができる。
− モノクロ・サンプリングにおいては、１つのサンプル・アレイのみが存在し、これを名目上ルマ・アレイとみなすことができる。
− ４：２：０サンプリングにおいては、２つのクロマ・アレイの各々は、ルマ・アレイの半分の高さと半分の幅を有する。
− ４：２：２サンプリングにおいては、２つのクロマ・アレイの各々が、ルマ・アレイと同じ高さと半分の幅を有する。
− ４：４：４サンプリングでは、別個の色平面が使用されていない場合、２つのクロマ・アレイの各々が、ルマ・アレイと同じ高さと幅を有する。
Ｈ．２６４／ＡＶＣおよびＨＥＶＣにおいて、サンプル・アレイを別個の色平面としてビットストリーム内にコーディングし、このビットストリームからそれぞれ別個にコード化された色平面をデコードすることが可能である。別個の色平面が使用されている場合、その各々が、モノクロ・サンプリングを用いて１つのピクチャとして（デコーダおよび／またはデコーダによって）別個に処理される。
パーティショニングは、セットの各エレメントがサブセットのうちの正確に１つの中にあるように、１つのセットをサブセットに分割することとして定義される。
Ｈ．２６４／ＡＶＣにおいて、マクロブロックは、ルマ・サンプルの１６×１６ブロックと、クロマ・サンプルの対応するブロックである。例えば、４：２：０のサンプリング・パターンでは、マクロブロックは、各クロマ構成要素あたり１つのクロマ・サンプルの８×８ブロックを格納する。Ｈ．２６４／ＡＶＣにおいて、ピクチャは、１つ以上のスライス・グループにパーティショニングされ、スライス・グループは、１つ以上のスライスを格納する。Ｈ．２６４／ＡＶＣにおいて、スライスは、特定のスライス・グループ内でのラスター走査内で連続して順序づけされた整数のマクロブロックからなる。
ＨＥＶＣエンコーディングおよび／またはデコーディングの動作を説明するとき、以下の用語を使用することができる。コーディング・ブロックは、コーディング・ブロックへのコーディング・ツリー・ブロックの分割が１パーティショニングとなるような、何らかのＮの値についてのサンプルのＮ×Ｎブロックとして定義することができる。コーディング・ツリー・ブロック（ＣＴＢ）は、コーディング・ツリー・ブロックへの一構成要素の分割が１パーティショニングとなるような、何らかのＮの値についてのサンプルのＮ×Ｎブロックとして定義することができる。コーディング・ツリー・ユニット（ＣＴＵ）は、ルマ・サンプルの１コーディング・ツリー・ブロック、３つのサンプル・アレイを有するピクチャのクロマ・サンプルの２つの対応するコーディング・ツリー・ブロック、または、サンプルをコーディングするために使用される３つの別個の色平面およびシンタックス構造を用いてコーディングされるピクチャまたはモノクロ・ピクチャのサンプルのコーディング・ツリー・ブロックとして定義することができる。コーディング・ユニット（ＣＵ）は、ルマ・サンプルの１つのコーディング・ブロック、３つのサンプル・アレイを有するピクチャのクロマ・サンプルの２つの対応するコーディング・ブロック、または、サンプルをコーディングするために使用される３つの別個の色平面およびシンタックス構造を用いてコーディングされるピクチャまたはモノクロ・ピクチャのサンプルのコーディング・ブロックとして定義することができる。
高効率映像コーディング（ＨＥＶＣ）コーデックなどのいくつかの映像コーデックにおいて、映像ピクチャは、ピクチャのエリアをカバーするコーディング・ユニット（ＣＵ）に分割される。ＣＵは、ＣＵ内のサンプルのための予測プロセスを定義する１つ以上の予測ユニット（ＰＵ）と、前記ＣＵ内のサンプルのための予測エラーコーディング・プロセスを定義する１つ以上の変換ユニット（ＴＵ）とで構成される。典型的には、ＣＵは、考えられるＣＵサイズの既定のセットから選択可能な１つのサイズを有する方形のサンプル・ブロックで構成される。許容された最大サイズを有するＣＵを、ＬＣＵ（最大コーディング・ユニット）またはコーディング・ツリー・ユニット（ＣＴＵ）と名付けることができ、映像ピクチャは、非重複ＬＣＵへと分割される。ＬＣＵはさらに、例えばＬＣＵおよび結果としてのＣＵの再帰的スプリッティングによって、より小さいＣＵの組合せへとさらにスプリットされ得る。結果としてのＣＵは各々、典型的に少なくとも１つのＰＵとそれに結び付けられた少なくとも１つのＴＵとを有する。各ＰＵおよびＴＵは、さらに、それぞれ予測および予測エラーコーディング・プロセスの粒度を増大させるためにより小さいＰＵおよびＴＵへとスプリットされ得る。各ＰＵは、そのＰＵ内の画素についてどの種類の予測を適用すべきかを定義する、このＰＵに結び付けられた情報を有する（例えば、インター予測されたＰＵについては動きベクトル情報および、イントラ予測されたＰＵについてはイントラ予測方向性情報）。
各ＴＵは、前記ＴＵ内のサンプルのための予測エラーデコーディング・プロセスを記述する情報（例えばＤＣＴ係数情報を含む）と結び付けられ得る。典型的には、ＣＵレベルにおいて、予測エラー・コーディングが各ＣＵについて適用されるか否かがシグナリングされる。ＣＵに付随する予測エラー剰余が全く存在しない場合には、前記ＣＵのためのＴＵが全くないとみなすことができる。ＣＵへの画像の分割およびＰＵおよびＴＵへのＣＵの分割は、典型的に、ビットストリーム内でシグナリングされ、これらのユニットの意図された構造をデコーダが再現できるようにする。
ＨＥＶＣでは、ピクチャを、矩形で整数のＬＣＵを格納するタイルの形にパーティショニングすることができ、タイルへのパーティショニングは正規グリッドを形成し、ここではタイルの高さおよび幅は互いに最大で１ＬＣＵしか異ならない。ＨＥＶＣでは、スライスは、１つの独立したスライス・セグメントおよび同じアクセス・ユニット内部の次の独立したスライス・セグメント（あれば）に先行する全ての後続する従属スライス・セグメント（あれば）内に格納された整数のコーディング・ツリー・ユニットとして定義される。ＨＥＶＣでは、スライス・セグメントは、タイル走査において連続して順序づけされ単一のＮＡＬユニット内に格納された整数のコーディング・ツリー・ユニットであるものとして定義される。各ピクチャのスライス・セグメントへの分割は、パーティショニングである。ＨＥＶＣでは、独立スライス・セグメントは、スライス・セグメント・ヘッダーのシンタックス・エレメントの値を先行するスライス・セグメントについての値から推論できないスライス・セグメントとして定義づけされ、従属スライス・セグメントは、先行する独立スライス・セグメントについての値からデコーディング順でスライス・セグメント・ヘッダーのいくつかのシンタックス・エレメントの値が推論されるスライス・セグメントとして定義される。ＨＥＶＣでは、スライス・ヘッダーは、現行スライス・セグメントであるかまたは現行従属スライス・セグメントに先行する独立スライス・セグメントである独立スライス・セグメントのスライス・セグメント・ヘッダーとして定義され、スライス・セグメント・ヘッダーは、スライス・セグメント内で表現される第１のおよび全てのコーディング・ツリー・ユニットに関係するデータ・エレメントを格納するコーデッド・スライス・セグメントの一部分として定義される。ＣＵは、タイル内またはタイルが使用されていない場合はピクチャ内でのＬＣＵのラスター走査順で走査される。ＬＣＵ内で、ＣＵは特定の走査順序を有する。
デコーダは、（エンコーダにより作成され圧縮表現で記憶された動きまたは空間情報を用いて）画素ブロックの予測された表現を形成するためにエンコーダに類似する予測手段を適用することによって、および予測エラー・デコーディング（空間画素ドメイン内で量子化予測エラー信号を回復する予測エラー・コーディングの逆動作）を適用することによって、出力映像を再構築する。予測および予測エラー・デコーディング手段を適用した後、デコーダは、予測および予測エラー信号（画素値）を総計して、出力映像フレームを形成する。デコーダ（およびエンコーダ）は、同様に、表示のため渡すおよび／または映像シーケンス内の次回のフレームのための予測参照としてそれを記憶する前に、出力映像の品質を向上させるための追加のフィルタリング手段を適用することもできる。
フィルタリングは、例えば、デブロッキング、サンプル・アダプティブ・オフセット（ＳＡＯ）および／またはアダプティブ・ループ・フィルタリング（ＡＬＦ）のうちの１つ以上を含むことができる。Ｈ．２６４／ＡＶＣは、デブロッキングを含み、一方ＨＥＶＣは、デブロッキングおよびＳＡＯの両方を含む。
典型的な映像コーデックにおいて、動き情報は、予測ユニットなど、各々の動き補償された画像ブロックと結び付けられた動きベクトルと共に標示される。これらの動きベクトルの各々は、コーディング（エンコーダ側）またはデコーディング（デコーダ側）すべきピクチャ内の画像ブロックおよび先にコーディングまたはデコード化されたピクチャの１つの中の予測ソース・ブロックの変位を表現する。動きベクトルを効率良く表現するために、これらのベクトルは、ブロック特定的な予測された動きベクトルとの関係において差分コーディングされる。典型的な映像コーデックにおいて、予測された動きベクトルは、例えば隣接ブロックのエンコーデッドまたはコーデッド動きベクトルの中央値を計算することなど、既定の方法で作成される。動きベクトル予測を作成する別の方法は、時間的参照ピクチャ内の隣接ブロックおよび／またはコロケートされたブロックから候補予測リストを生成し、選択された候補を動きベクトル予測子としてシグナリングすることにある。動きベクトル値を予測することに加えて、動き補償された予測のためにどの参照ピクチャが使用されるかが予測され得、この予測情報は、先にコーディング／デコード化されたピクチャの基準指標などにより表現されることができる。参照指標は、典型的には、時間的参照ピクチャ内の隣接ブロックおよび／またはコロケートされたブロックから予測される。その上、典型的な高効率映像コーデックは、多くの場合マージング／マージ・モードと呼ばれる追加の動き情報コーディング／デコーディング・メカニズムを利用し、ここで、各々の利用可能な参照ピクチャ・リストについての動きベクトルおよび対応する参照ピクチャ指標を含む全ての動きフィールド情報が予測され、いかなる修正／補正もなく使用される。同様にして、動きフィールド情報の予測は、時間的参照ピクチャ内の隣接ブロックおよび／またはコロケートされたブロックの動きフィールド情報を用いて実施され、利用可能な隣接／コロケートされたブロックの動きフィールド情報が記入された動きフィールド候補リストの中で、使用済み動きフィールド情報はシグナリングされる。
典型的な映像コーデックは、（デ）コーディングされつつあるブロックのために単一の予測ブロックが使用される単方向予測の使用を有効化し、（デ）コーディングされつつあるブロックのための予測を形成するために２つの予測ブロックが組合わされる双方向予測の使用を有効化する。いくつかの映像コーデックは、残留情報を追加する前に予測ブロックのサンプル値が重み付けされる重み付き予測を有効化する。例えば、乗法重み付け係数および加法オフセットを適用することができる。いくつかの映像コーデックによって有効化される明示的重み付き予測においては、重み付け係数およびオフセットを、例えば各々の許容可能な参照ピクチャ指標についてスライス・ヘッダー内でコーディングすることができる。いくつかの映像コーデックにより有効化される黙示的重み付き予測においては、重み付け係数および／またはオフセットはコーディングされず、例えば、参照ピクチャの相対的ピクチャ・オーダー・カウント（ＰＯＣ）距離に基づいて導出される。
典型的映像コーデックにおいて、動き補償後の予測剰余は、まず変換カーネル（ＤＣＴなど）を用いて変換され、次にコーディングされる。その理由は、剰余の中に幾分かの相関関係がなおも存在する場合が多く、変換が、多くの場合において、この相関関係の削除を助け、より効率の良いコーディングを提供するという点にある。
典型的な映像エンコーダは、最適なコーディング・モード、例えば所望されるマクロブロック・モードおよび結び付けられた動きベクトルを見出すためにラグランジュ・コスト関数を使用する。この種のコスト関数は、ロッシー・コーディング方法に起因する（正確なまたは推定された）画像歪みおよび、画像エリア内で画素値を表現するのに必要とされる（正確なまたは推定された）情報量を結び付けるために、重み付け係数λを使用する。
Ｃ＝Ｄ＋λＲ （１）
式中、Ｃは最小化すべきラグランジュ・コストであり、Ｄは、モードおよび動きベクトルを考慮した画像歪み（例えば平均２乗エラー）であり、Ｒは、（候補動きベクトルを表現するためのデータの量を含む）デコーダ内で画像ブロックを再構築するための所要データを表現するのに必要とされるビット数である。
映像コーディング規格および仕様は、エンコーダがコーデッド・ピクチャをコーデッド・スライスまたはそれに類するものに分割することを許可し得る。こうして、スプライスは、コーデッド・ピクチャを独立してデコーディング可能なピースにスプリットする方法とみなされ得る。Ｈ．２６４／ＡＶＣおよびＨＥＶＣにおいては、イン・ピクチャ予測を、スライス境界を横断して無効化することができる。こうして、スライスは、コーデッド・ピクチャを独立してデコーディング可能なピースにスプリットする方法とみなされ得、したがって、スライスは、伝送のための基本ユニットとみなされることが多い。多くの場合において、エンコーダは、スライス境界を横断してどのタイプのイン・ピクチャ予測がオフ切換えされるかをビットストリーム内で標示することができ、デコーダの動作は、例えばどの予測ソースが利用可能であるかを結論づける場合に、この情報を考慮に入れる。例えば、隣接するマクロブロックまたはＣＵからのサンプルは、この隣接するマクロブロックまたはＣＵが異なるスライス内に存在する場合、イントラ予測には利用不可能とみなされる可能性がある。
Ｈ．２６４／ＡＶＣまたはＨＥＶＣエンコーダの出力およびＨ．２６４／ＡＶＣまたはＨＥＶＣデコーダの入力それぞれのための基本ユニットは、ネットワーク抽象化レイヤ（ＮＡＬ）ユニットである。パケット指向ネットワーク上での転送または構造化されたファイル内への記憶のためには、ＮＡＬユニットを、パケットまたは類似の構造の中にカプセル化することができる。フレーミング構造を提供しない伝送または記憶環境のために、Ｈ．２６４／ＡＶＣおよびＨＥＶＣにおいては、バイトストリーム・フォーマットが規定された。バイトストリーム・フォーマットは、各ＮＡＬユニットの前に開始コードを付着させることによって、ＮＡＬユニットを互いに分離させる。ＮＡＬユニット境界の誤検出を回避するため、エンコーダは、開始コードが他の形で発生した場合でもＮＡＬユニット・ペイロードに対してエミュレーション防止バイトを追加する、バイト指向開始コード・エミュレーション防止アルゴリズムを実行する。パケット指向およびストリーム指向のシステム間での直接的なゲートウェイ動作を可能にするために、バイトストリーム・フォーマットが使用されているか否かに関わらず、開始コード・エミュレーション防止をつねに行うことができる。ＮＡＬユニットは、必要な場合にはエミュレーション防止バイトが散在させられたＲＢＳＰの形で後続するデータのタイプおよびこのデータを格納するバイトの標示を格納するシンタックス構造として定義することができる。ロー・バイト・シーケンス・ペイロード（ＲＢＳＰ）は、ＮＡＬユニットの中にカプセル化された整数のバイトを格納するシンタックス構造として定義することができる。ＲＢＳＰは空であるか、または、シンタックス・エレメントを格納するデータ・ビットとそれに続くＲＢＳＰ停止ビットおよびそれに続くゼロ以上の０に等しい後続ビットのストリングの形態を有するかのいずれかである。
ＮＡＬユニットは、ヘッダーとペイロードで構成される。Ｈ．２６４／ＡＶＣおよびＨＥＶＣにおいて、ＮＡＬユニット・ヘッダーはＮＡＬユニットのタイプを標示する。
Ｈ．２６４／ＡＶＣＮＡＬユニット・ヘッダーは、０に等しい場合ＮＡＬユニット内に格納されたコーデッド・スライスが非参照ピクチャの一部であることを標示し、０より大きい場合ＮＡＬユニット内に格納されたコーデッド・スライスが参照ピクチャの一部であることを標示する、２ビットのｎａｌ＿ｒｅｆ＿ｉｄｃシンタックス・エレメントを含む。ＳＶＣおよびＭＶＣ ＮＡＬユニットのためのヘッダーは、さらに、スケーラビリティおよびマルチビュー階層に関連するさまざまな標示を格納することができる。
ＨＥＶＣでは、規定された全てのＮＡＬユニットタイプのために、２バイトＮＡＬユニット・ヘッダーが使用される。ＮＡＬユニット・ヘッダーは、１つの予約されたビット、６ビットのＮＡＬユニットタイプ標示、（１以上であることが求められる場合のある）時間的レベルについての３ビットのｎｕｈ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｐｌｕｓ１標示、および６ビットのｎｕｈ＿ｌａｙｅｒ＿ｉｄシンタックス・エレメントを格納する。ｔｅｍｐｏｒａｌ＿ｉｄ＿ｐｌｕｓ１シンタックス・エレメントは、ＮＡＬユニットのための時間的識別子とみなされることができ、ゼロベースのＴｅｍｐｏｒａｌＩｄ変数を、以下のように導出することができる。ＴｅｍｐｏｒａｌＩｄ＝ｔｅｍｐｏｒａｌ＿ｉｄ＿ｐｌｕｓ１−１。０に等しいＴｅｍｐｏｒａｌＩｄは、最低の時間的レベルに対応する。ｔｅｍｐｏｒａｌ＿ｉｄ＿ｐｌｕｓ１の値は、２つのＮＡＬユニット・ヘッダー・バイトが関与する開始コード・エミュレーションを回避するために、非ゼロであることが求められる。選択された値以上のＴｅｍｐｏｒａｌＩｄを有する全てのＶＣＬ ＮＡＬユニットを除外し、他の全てのＶＣＬ ＮＡＬユニットを内含することによって作成されたビットストリームは、適合するものであり続ける。その結果、ＴＩＤに等しいＴｅｍｐｏｒａｌＩｄを有するピクチャは、インター予測参照としてＴＩＤより大きいＴｅｍｐｏｒａｌＩｄを有するいずれのピクチャも使用しない。サブレイヤまたは時間的サブレイヤは、ＴｅｍｐｏｒａｌＩｄ変数の特定の値を伴うＶＣＬ ＮＡＬユニットおよび結び付けられた非ＶＣＬ ＮＡＬユニットで構成される時間的スケーラブル・ビットストリームの時間的スケーラブル・レイヤとして定義されることができる。ｎｕｈ＿ｌａｙｅｒ＿ｉｄは、スケーラビリティ・レイヤ識別子として理解されることができる。
ＮＡＬユニットは、映像コーディングレイヤ（ＶＣＬ）ＮＡＬユニットと非ＶＣＬ ＮＡＬユニットに分類可能である。ＶＣＬ ＮＡＬユニットは、典型的には、コーデッド・スライスＮＡＬユニットである。Ｈ．２６４／ＡＶＣにおいて、コーデッド・スライスＮＡＬユニットは、各々が非圧縮ピクチャ内のサンプル・ブロックに対応する１つ以上のコーデッド・マクロブロックを表現するシンタックス・エレメントを格納する。ＨＥＶＣでは、ＶＣＬ ＮＡＬユニットは、１つ以上のＣＵを表現するシンタックス・エレメントを格納する。
Ｈ．２６４／ＡＶＣでは、コーデッド・スライスＮＡＬユニットが、瞬間デコーディング・リフレッシュ（ＩＤＲ）ピクチャ内のコーデッド・スライスまたは非ＩＤＲピクチャ内のコーデッド・スライスであるものとして標示され得る。
ＨＥＶＣでは、コーデッド・スライスＮＡＬユニットは、以下のタイプの１つであるものと標示され得る。
Figure 0006649404
ＨＥＶＣでは、ピクチャタイプについての略称は以下のように定義することができる。トレーリング（ＴＲＡＩＬ）ピクチャ、時間的サブレイヤ・アクセス（ＴＳＡ）、ステップワイズ時間的サブレイヤ・アクセス（ＳＴＳＡ）、ランダム・アクセス・デコーダブル・リーディング（ＲＡＤＬ）ピクチャ、ランダム・アクセス・スキップド・リーディング（ＲＡＳＬ）ピクチャ、破壊リンク・アクセス（ＢＬＡ）ピクチャ、瞬間デコーディング・リフレッシュ（ＩＤＲ）ピクチャ、クリーン・ランダム・アクセス（ＣＲＡ）ピクチャ。
イントラ・ランダム・アクセス・ポイント（ＩＲＡＰ）ピクチャとも呼ぶことのできるランダム・アクセス・ポイント（ＲＡＰ）ピクチャは、各スライスまたはスライス・セグメントが、１６〜２３の範囲（１６、２３を含む）内のｎａｌ＿ｕｎｉｔ＿ｔｙｐｅを有するピクチャである。独立レイヤ内のＩＲＡＰピクチャは、イントラ・コーデッド・スライスのみを格納する。ｎｕｈ＿ｌａｙｅｒ＿ｉｄ値ｃｕｒｒＬａｙｅｒＩｄを伴う予測されたレイヤに属するＩＲＡＰピクチャは、Ｐ、ＢおよびＩスライスを格納し、ｃｕｒｒＬａｙｅｒＩｄに等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄを伴う他のピクチャからのインター予測を使用できず、その直接参照レイヤからのインター・レイヤ予測を使用することができる。ＨＥＶＣの現在のバージョンでは、ＩＲＡＰピクチャは、ＢＬＡピクチャ、ＣＲＡピクチャまたはＩＤＲピクチャであることができる。ベース・レイヤを格納するビットストリーム内の最初のピクチャは、ベース・レイヤにあるＩＲＡＰピクチャである。必要なパラメータ・セットをアクティブにする必要がある場合に、これらのパラメータ・セットが利用可能であることを条件として、独立レイヤにある１つのＩＲＡＰピクチャおよびデコーディング順で独立レイヤにある全ての後続する非ＲＡＳＬピクチャは、デコーディング順でＩＲＡＰピクチャに先行するいずれかのピクチャのデコーディング・プロセスを行うことなく、適正にデコードされ得る。ｎｕｈ＿ｌａｙｅｒ＿ｉｄ値ｃｕｒｒＬａｙｅｒＩｄを伴う予測されたレイヤに属するＩＲＡＰピクチャおよびデコーディング順でｃｕｒｒＬａｙｅｒＩｄに等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄを伴う全ての後続する非ＲＡＳＬピクチャは、必要なパラメータ・セットをアクティブにする必要があるときにこれらのパラメータ・セットが利用可能である場合、およびｃｕｒｒＬａｙｅｒＩｄに等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄを伴うレイヤの各々の直接参照レイヤのデコーディングが初期化された場合（すなわち、ＬａｙｅｒＩｎｉｔｉａｌｉｚｅｄ Ｆｌａｇ［ｒｅｆＬａｙｅｒＩｄ］が、ｃｕｒｒＬａｙｅｒＩｄに等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄを伴うレイヤの直接参照レイヤの全てのｎｕｈ＿ｌａｙｅｒ＿ｉｄ値に等しいｒｅｆＬａｙｅｒＩｄについて１に等しい場合）、デコーディング順でＩＲＡＰピクチャに先行するｃｕｒｒＬａｙｅｒＩｄに等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄを伴ういずれかのピクチャのデコーディング・プロセスを行うことなく、適正にデコードされ得る。ビットストリーム内には、ＩＲＡＰピクチャでないイントラ・コーデッド・スライスのみを格納するピクチャが存在する場合がある。
ＨＥＶＣでは、ＣＲＡピクチャは、デコーディング順でビットストリーム内の最初のピクチャであることができ、あるいは、ビットストリーム内で後で出現することもできる。ＨＥＶＣにおけるＣＲＡピクチャは、デコーディング順でＣＲＡピクチャに後続するものの出力順ではそれより先行するいわゆるリーディング・ピクチャを許容する。いわゆるＲＡＳＬピクチャである、リーディング・ピクチャのいくつかは、基準としてＣＲＡピクチャの前にデコードされたピクチャを使用する。デコーディング順および出力順の両方においてＣＲＡピクチャに後続するピクチャは、ＣＲＡピクチャにおいてランダム・アクセスが行われる場合、デコーディング可能であり、したがって、クリーン・ランダム・アクセスは、ＩＤＲピクチャのクリーン・ランダム・アクセス機能性と類似の要領で達成される。
ＣＲＡピクチャは、結び付けられたＲＡＤＬまたはＲＡＳＬピクチャを有することができる。ＣＲＡピクチャがビットストリーム中においてデコーディング順で最初のピクチャである場合、ＣＲＡピクチャは、デコーディング順でコーデッド映像シーケンスの最初のピクチャであり、いずれの結び付けられたＲＡＳＬピクチャも、該ビットストリーム中に存在しないピクチャに対する参照を格納し得ることから、デコーダにより出力されず、デコーディングできない可能性がある。
リーディング・ピクチャは、出力順で、結び付けられたＲＡＰピクチャに先行するピクチャである。結び付けられたＲＡＰピクチャは、（存在する場合）デコーディング順で先行するＲＡＰピクチャである。リーディング・ピクチャは、ＲＡＤＬピクチャまたはＲＡＳＬピクチャのいずれかである。
全てのＲＡＳＬピクチャは、結び付けられたＢＬＡまたはＣＲＡピクチャのリーディング・ピクチャである。結び付けられたＲＡＰピクチャがＢＬＡピクチャであるかまたはビットストリーム内の最初のコーデッド・ピクチャである場合、ＲＡＳＬピクチャは、ビットストリーム内に存在しないピクチャに対する参照を格納し得ることから、出力されず、適正にデコーディングできない可能性がある。しかしながら、ＲＡＳＬピクチャは、ＲＡＳＬピクチャのデコーディング・プロセスの前にＲＡＰピクチャからデコーディングが開始した場合、適正にデコードされ得る。ＲＡＳＬピクチャは、非ＲＡＳＬピクチャのデコーディング・プロセスのための参照ピクチャとして使用されない。存在する場合、全てのＲＡＳＬピクチャは、デコーディング順で、同じ結び付けられたＲＡＰピクチャの全てのトレーリング・ピクチャに先行する。ＨＥＶＣ規格のいくつかの草案において、ＲＡＳＬピクチャは、タッグド・フォー・ディスカード（ＴＦＤ）ピクチャと呼ばれていた。
全てのＲＡＤＬピクチャは、リーディング・ピクチャである。ＲＡＤＬピクチャは、同じ結び付けられたＲＡＰピクチャのトレーリング・ピクチャのデコーディング・プロセスのための参照ピクチャとして使用されない。存在する場合、全てのＲＡＤＬピクチャは、デコーディング順で、同じ結び付けられたＲＡＰピクチャの全てのトレーリング・ピクチャに先行する。ＲＡＤＬピクチャは、デコーディング順で結び付けられたＲＡＰピクチャに先行するいずれのピクチャも参照せず、したがって、結び付けられたＲＡＰピクチャからデコーディングが開始した場合、適正にデコードされ得る。ＨＥＶＣ規格のいくつかの草案において、ＲＡＤＬピクチャは、デコーダブル・リーディング・ピクチャ（ＤＬＰ）と呼ばれていた。
ＣＲＡピクチャから始まるビットストリームの一部が別のビットストリーム内に内含される場合、ＣＲＡピクチャに結び付けられたＲＡＳＬピクチャは、組合わされたビットストリーム内にその参照ピクチャのいくつかが存在しないことが考えられることから、適切にデコーディング可能でない場合があると思われる。このようなスプライシング動作を単純なものにするため、ＢＬＡピクチャであることを標示するように、ＣＲＡピクチャのＮＡＬユニットタイプを変更することができる。ＢＬＡピクチャと結び付けられたＲＡＳＬピクチャは、出力／表示されないことから、適切にデコーディングできない場合がある。さらに、ＢＬＡピクチャと結び付けられたＲＡＳＬピクチャを、デコーディングから削除することができる。
ＢＬＡピクチャは、デコーディング順でビットストリーム内の最初のピクチャであることができ、または、ビットストリーム中で後に出現することができる。各ＢＬＡピクチャは、新しいコーデッド映像シーケンスを開始し、デコーディング・プロセスに対してＩＤＲピクチャと類似の効果を有する。しかしながら、ＢＬＡピクチャは、空でない参照ピクチャ・セットを規定するシンタックス・エレメントを格納する。ＢＬＡピクチャがＢＬＡ＿Ｗ＿ＬＰに等しいｎａｌ＿ｕｎｉｔ＿ｔｙｐｅを有する場合、このピクチャは、ビットストリーム内に存在しないピクチャに対する参照を格納し得ることからデコーダによって出力されずデコーディングできない可能性のある結び付けられたＲＡＳＬピクチャを有することができる。ＢＬＡピクチャが、ＢＬＡ＿Ｗ＿ＬＰに等しいｎａｌ＿ｕｎｉｔ＿ｔｙｐｅを有する場合、それは同様に、デコーディングされるように規定されている結び付けられたＲＡＤＬピクチャも有することができる。ＢＬＡピクチャがＢＬＡ＿Ｗ＿ＤＬＰに等しいｎａｌ＿ｕｎｉｔ＿ｔｙｐｅを有する場合、それは、結び付けられたＲＡＳＬピクチャを有さないが、デコーディングされるように規定されている結び付けられたＲＡＤＬピクチャを有することができる。ＢＬＡピクチャが、ＢＬＡ＿Ｎ＿ＬＰに等しいｎａｌ＿ｕｎｉｔ＿ｔｙｐｅを有する場合、それは結び付けられたいかなるリーディング・ピクチャも有していない。
ＩＤＲ＿Ｎ＿ＬＰに等しいｎａｌ＿ｕｎｉｔ＿ｔｙｐｅを有するＩＤＲピクチャは、ビットストリーム内に存在する結び付けられたリーディング・ピクチャを有さない。ＩＤＲ＿Ｗ＿ＬＰに等しいｎａｌ＿ｕｎｉｔ＿ｔｙｐｅを有するＩＤＲピクチャは、ビットストリーム内に存在する結び付けられたＲＡＳＬピクチャを有していないが、ビットストリーム内に結び付けられたＲＡＤＬピクチャを有することができる。
ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅの値がＴＲＡＩＬ＿Ｎ、ＴＳＡ＿Ｎ、ＳＴＳＡ＿Ｎ、ＲＡＤＬ＿Ｎ、ＲＡＳＬ＿Ｎ、ＲＳＶ＿ＶＣＬ＿Ｎ１０、ＲＳＶ＿ＶＣＬ＿Ｎ１２、またはＲＳＶ＿ＶＣＬ＿Ｎ１４に等しい場合、デコーデッド・ピクチャは、同じ時間的サブレイヤの他のいずれのピクチャのための参照としても使用されない。すなわち、ＨＥＶＣにおいて、ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅの値がＴＲＡＩＬ＿Ｎ、ＴＳＡ＿Ｎ、ＳＴＳＡ＿Ｎ、ＲＡＤＬ＿Ｎ、ＲＡＳＬ＿Ｎ、ＲＳＶ＿ＶＣＬ＿Ｎ１０、ＲＳＶ＿ＶＣＬ＿Ｎ１２、またはＲＳＶ＿ＶＣＬ＿Ｎ１４に等しい場合、デコーデッド・ピクチャは、ＴｅｍｐｏｒａｌＩｄの同じ値を伴ういずれかのピクチャのＲｅｆＰｉｃＳｅｔＳｔＣｕｒｒＢｅｆｏｒｅ、ＲｅｆＰｉｃＳｅｔＳｔＣｕｒｒＡｆｔｅｒおよびＲｅｆＰｉｃＳｅｔＬｔＣｕｒｒのいずれか中にも含まれない。ＴＲＡＩＬ＿Ｎ、ＴＳＡ＿Ｎ、ＳＴＳＡ＿Ｎ、ＲＡＤＬ＿Ｎ、ＲＡＳＬ＿Ｎ、ＲＳＶ＿ＶＣＬ＿Ｎ１０、ＲＳＶ＿ＶＣＬ＿Ｎ１２、またはＲＳＶ＿ＶＣＬ＿Ｎ１４に等しいｎａｌ＿ｕｎｉｔ＿ｔｙｐｅを伴うコーデッド・ピクチャは、同じＴｅｍｐｏｒａｌＩｄ値を伴う他のピクチャのデコーダビリティに影響を及ぼすことなく、廃棄されることができる。
トレーリング・ピクチャは、出力順で、結び付けられたＲＡＰピクチャに後続するピクチャとして定義できる。トレーリング・ピクチャであるピクチャはいずれもＲＡＤＬ＿Ｎ、ＲＡＤＬ＿Ｒ、ＲＡＳＬ＿ＮまたはＲＡＳＬ＿Ｒに等しいｎａｌ＿ｕｎｉｔ＿ｔｙｐｅを有さない。リーディング・ピクチャであるピクチャはいずれも、同じＲＡＰピクチャと結び付けられた全てのトレーリング・ピクチャに、デコーディング順で先行するように抑制される可能性がある。ＢＬＡ＿Ｗ＿ＤＬＰまたはＢＬＡ＿Ｎ＿ＬＰに等しいｎａｌ＿ｕｎｉｔ＿ｔｙｐｅを有するＢＬＡピクチャと結び付けられたビットストリーム内にいかなるＲＡＤＬピクチャも存在しない。ＢＬＡ＿Ｎ＿ＬＰに等しいｎａｌ＿ｕｎｉｔ＿ｔｙｐｅを有するＢＬＡピクチャと結び付けられたまたはＩＤＲ＿Ｎ＿ＬＰに等しいｎａｌ＿ｕｎｉｔ＿ｔｙｐｅと結び付けられたいかなるＲＡＤＬピクチャもビットストリーム内に存在しない。ＣＲＡまたはＢＬＡピクチャと結び付けられたいずれのＲＡＳＬピクチャも、出力順でＣＲＡまたはＢＬＡピクチャと結び付けられたいずれかのＲＡＤＬピクチャに先行するように抑制される可能性がある。ＣＲＡピクチャと結び付けられたられたＲＡＳＬピクチャはいずれも、デコーディング順でＣＲＡピクチャに先行する他のいずれのＲＡＰピクチャにも出力順で後続するように抑制される可能性がある。
ＨＥＶＣでは、２つのピクチャタイプ、すなわち時間的サブレイヤ・スイッチング・ポイントを標示するために使用できるＴＳＡおよびＳＴＳＡピクチャタイプが存在する。最高ＮのＴｅｍｐｏｒａｌＩｄを伴う時間的サブレイヤが、ＴＳＡまたはＳＴＳＡピクチャ（排他的）までデコードされており、ＴＳＡまたはＳＴＳＡピクチャがＮ＋１に等しいＴｅｍｐｏｒａｌＩｄを有する場合、ＴＳＡまたはＳＴＳＡピクチャは、Ｎ＋１に等しいＴｅｍｐｏｒａｌＩｄを有する（デコーディング順で）全ての後続するピクチャのデコーディングを有効化する。ＴＳＡピクチャタイプは、ＴＳＡピクチャ自体およびデコーディング順でＴＳＡピクチャに後続する同じサブレイヤ内の全てのピクチャに対して制約条件を課すことができる。これらのピクチャのいずれも、デコーディング順でＴＳＡピクチャに先行する同じサブレイヤ内の任意のピクチャからのインター予測を使用することを許されていない。ＴＳＡ定義はさらに、デコーディング順でＴＳＡピクチャに後続するより上位のサブレイヤ内のピクチャに対する制約条件を課すことができる。これらのピクチャのいずれも、そのピクチャがＴＳＡピクチャと同じかまたは上位のサブレイヤに属する場合に、デコーディング順でＴＳＡピクチャに先行するピクチャを参照することを許されない。ＴＳＡピクチャは、０より大きいＴｅｍｐｏｒａｌＩｄを有する。ＳＴＳＡはＴＳＡピクチャと類似しているが、デコーディング順でＳＴＳＡピクチャに後続し、したがってＳＴＳＡピクチャが存在するサブレイヤへのアップ・スイッチングのみを有効化する上位のサブレイヤ内のピクチャに対し制約条件を課さない。
非ＶＣＬ ＮＡＬユニットは、例えば、以下のタイプのうちの１つであることができる。シーケンス・パラメータ・セット、ピクチャ・パラメータ・セット、補足的強化情報（ＳＥＩ）ＮＡＬユニット、アクセス・ユニット・デリミタ―、エンド・オブ・シーケンスＮＡＬユニット、エンド・オブ・ビットストリームＮＡＬユニットまたは、フィラー・データＮＡＬユニット。パラメータ・セットは、デコーデッド・ピクチャの再構築のために必要とされ得、一方、他の非ＶＣＬ ＮＡＬユニットの多くは、デコーデッド・サンプル値の再構築のために必要でない。
コーデッド映像シーケンスを通して不変のままであるパラメータを、シーケンス・パラメータ内に内含することができる。デコーディング・プロセスが必要とする可能性のあるパラメータに加えて、シーケンス・パラメータ・セットは、任意には、バッファリング、ピクチャ出力タイミング、レンダリングおよびリソース予約にとって重要であり得るパラメータを含む映像ユーザビリティ情報（ＶＵＩ）を含むことができる。シーケンス・パラメータ・セットを運ぶ３つのＮＡＬユニット、すなわち、シーケンス内のＨ．２６４／ＡＶＣＶＣＬ ＮＡＬユニットについての全てのデータを格納するシーケンス・パラメータ・セットＮＡＬユニット、補助コーデッド・ピクチャについてのデータを格納するシーケンス・パラメータ・セット拡張ＮＡＬユニット、およびＭＶＣおよびＳＶＣ ＶＣＬ ＮＡＬユニットのためのサブセット・シーケンス・パラメータ・セットが、Ｈ．２６４／ＡＶＣ中に規定されている。ＨＥＶＣでは、シーケンス・パラメータ・セットＲＢＳＰは、１つ以上のピクチャ・パラメータ・セットＲＢＳＰまたはバッファリング周期ＳＥＩメッセージを格納する１つ以上のＳＥＩ ＮＡＬユニットにより参照され得るパラメータを含む。ピクチャ・パラメータ・セットは、複数のコーデッド・ピクチャ内で不変である確率の高いパラメータを格納する。ピクチャ・パラメータ・セットＲＢＳＰは、１つ以上のコーデッド・ピクチャのコーデッド・スライスＮＡＬユニットにより参照され得るパラメータを含むことができる。
ＨＥＶＣでは、映像パラメータ・セット（ＶＰＳ）は、各スライス・セグメント・ヘッダー内に見出されるシンタックス・エレメントにより参照されるＰＰＳ内に見出されるシンタックス・エレメントにより参照されるＳＰＳ内に見出されるシンタックスのコンテンツによって決定されるような、ゼロ以上の全コーデッド映像シーケンスにあてはまるシンタックス・エレメントを格納するシンタックス構造として定義することができる。
映像パラメータ・セットＲＢＳＰは、１つ以上のシーケンス・パラメータ・セットＲＢＳＰにより参照され得るパラメータを含むことができる。
映像パラメータ・セット（ＶＰＳ）、シーケンス・パラメータ・セット（ＳＰＳ）、およびピクチャ・パラメータ・セット（ＰＰＳ）の間の関係および階層は、以下のように説明することができる。ＶＰＳは、パラメータ・セット階層内でＳＰＳより１レベル上方で、スケーラビリティおよび／または３Ｄ映像のコンテキスト内に存在する。ＶＰＳは、全コーデット映像シーケンス内の全ての（スケーラビリティまたはビュー）レイヤを横断して、全てのスライスについて共通であるパラメータを含むことができる。ＳＰＳは、全コーデッド映像シーケンス内の特定の（スケーラビリティまたはビュー）レイヤ内の全てのスライスについて共通であるパラメータを含み、多数の（スケーラビリティまたはビュー）レイヤにより共用されることができる。ＰＰＳは、特定のレイヤ表現（１アクセス・ユニット内の１つのスケーラビリティまたはビューレイヤの表現）内の全てのスライスについて共通であるパラメータを含み、多数のレイヤ表現の中で全てのスライスにより共用される確率が高い。
ＶＰＳは、ビットストリーム中のレイヤの依存関係についての情報、ならびに全コーデッド映像シーケンス内の全ての（スケーラビリティまたはビュー）レイヤを横断して全てのスライスに対して適用可能である他の多くの情報を提供することができる。ＶＰＳは、２つの部分、すなわちベースＶＳＰおよびＶＳＰ拡張を含むものとみなすことができ、ここでＶＰＳ拡張は、任意に存在することができる。ＨＥＶＣでは、ベースＶＰＳは、ｖｐｓ＿ｅｘｔｅｎｓｉｏｎ（）シンタックス構造無しでｖｉｄｅｏ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｒｂｓｐ（）シンタックス構造を含むものとみなされることができる。ｖｉｄｅｏ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｒｂｓｐ（）シンタックス構造は、そもそもすでにＨＥＶＣバージョン１のために規定されたものであり、ベース・レイヤデコーディングのために有用であり得るシンタックス・エレメントを含む。ＨＥＶＣでは、ＶＰＳ拡張を、ｖｐｓ＿ｅｘｔｅｎｓｉｏｎ（）シンタックス構造を含むものとみなすことができる。ｖｐｓ＿ｅｘｔｅｎｓｉｏｎ（）シンタックス構造は、そもそもマルチ・レイヤ拡張のためにＨＥＶＣバージョン２内で規定されていたものであり、レイヤ依存関係を標示するシンタックス・エレメントなどの１つ以上の非ベース・レイヤのデコーディングのために有用であり得るシンタックス・エレメントを含む。
Ｈ．２６４／ＡＶＣおよびＨＥＶＣシンタックスは、多くのパラメータ・セット・インスタンスを許容し、各インスタンスは、一意的識別子で識別される。パラメータ・セットに必要とされるメモリ使用量を制限するためにパラメータ・セット識別子についての値範囲は制限されてきた。Ｈ．２６４／ＡＶＣおよびＨＥＶＣにおいて、各スライス・ヘッダーは、スライスを格納するピクチャのデコーディングのためにアクティブであるピクチャ・パラメータ・セットの識別子を含み、各々のピクチャ・パラメータ・セットは、アクティブ・シーケンス・パラメータ・セットの識別子を格納する。その結果として、ピクチャおよびシーケンス・パラメータ・セットの伝送が、スライスの伝送と正確に同期化されている必要はない。その代り、アクティブ・シーケンスおよびピクチャ・パラメータ・セットは、参照される前の任意の瞬間において受信されるだけで充分であり、こうして、スライス・データのために使用されたプロトコルに比べてより信頼性の高い伝送メカニズムを用いて「アウト・オブ・バンド」でのパラメータ・セットの伝送が可能になる。例えば、パラメータ・セットを、実時間転送プロトコル（ＲＴＰ）セッションのためのセッション記述内に１パラメータとして内含することができる。パラメータ・セットが帯域内で伝送される場合、エラーロバスト性を改善するため、それらを反復することができる。
アクセスの容易さまたはセッション・ネゴシエーションなど、伝送エラーに対する許容エラー以外の目的のために、アウト・オブ・バンド伝送、シグナリングまたは記憶を、付加的にまたは代替的に使用することができる。例えば、ＩＳＯベース・メディア・ファイル・フォーマットに適合するファイル内のトラックのサンプル・エントリは、パラメータ・セットを含むことができ、一方、ビットストリーム内のコーデッド・データはファイル内または別のファイル内の他の場所に記憶される。（例えば「ビットストリームに沿って標示する」などの）「ビットストリームに沿って」とのフレーズは、アウト・オブ・バンド・データがビットストリームと結び付けられるような形でのアウト・オブ・バンド伝送、シグナリングまたは記憶を意味するものとして、クレーム中および説明された実施形態の中で使用されることができる。「ビットストリームに沿ったデコーディング」とのフレーズなどは、ビットストリームに結び付けられて（アウト・オブ・バンド伝送、シグナリングまたはストレージから得ることのできる）述べられたアウト・オブ・バンドデータのデコーディングを意味することができる。
スライスからまたは別のアクティブ・パラメータ・セットから、またはいくつかの事例においては、バッファリング周期ＳＥＩメッセージなどの別のシンタックス構造からの参照によって、パラメータ・セットをアクティブにすることができる。
ＳＥＩ ＮＡＬユニットは、出力ピクチャのデコーディングのためには必要とされないものの、ピクチャ出力タイミング、レンダリング、エラー検出、エラー隠蔽およびリソース予約などの関連プロセスを補助することのできる１つ以上のＳＥＩメッセージを格納することができる。Ｈ．２６４／ＡＶＣおよびＨＥＶＣにおいては、複数のＳＥＩメッセージが、規定されており、ユーザー・データＳＥＩメッセージは、組織および会社が独自に使用するためのＳＥＩメッセージを規定することを可能にする。Ｈ．２６４／ＡＶＣおよびＨＥＶＣは、規定されたＳＥＩメッセージのためのシンタックスおよびセマンティクスを含んでいるが、受信者におけるメッセージのハンドリングのためのプロセスは全く定義されていない。その結果として、エンコーダは、ＳＥＩメッセージを作成するときＨ．２６４／ＡＶＣ規格またはＨＥＶＣ規格に従うことが求められ、Ｈ．２６４／ＡＶＣ規格またはＨＥＶＣ規格に適合するデコーダは、それぞれ出力順序の適合性のためにＳＥＩメッセージを処理することを求められない。Ｈ．２６４／ＡＶＣおよびＨＥＶＣ内にＳＥＩメッセージのシンタックスおよびセマンティクスを内含させる理由の１つは、異なるシステム仕様が、補足情報をあらゆる点で等しく解釈し、したがって相互運用できるようにすることにある。システム仕様は、エンコーディング端部およびデコーディング端部の両方における特定のＳＥＩメッセージの使用を求めることができ、さらに受信者において特定のＳＥＩメッセージをハンドリングするためのプロセスを規定することが可能である、ということが意図されている。
ＨＥＶＣでは、互いに異なるｎａｌ＿ｕｎｉｔ＿ｔｙｐｅ値を有する、２つのタイプのＳＥＩ ＮＡＬユニット、すなわちサフィックスＳＥＩ ＮＡＬユニットおよびプリフィックスＳＥＩ ＮＡＬが存在する。サフィックスＳＥＩ ＮＡＬユニット内に格納されたＳＥＩメッセージは、デコーディング順でサフィックスＳＥＩ ＮＡＬユニットに先行するＶＣＬ ＮＡＬユニットと結び付けられる。プリフィックスＳＥＩ ＮＡＬユニット内に格納されたＳＥＩメッセージは、デコーディング順でプリフィックスＳＥＩ ＮＡＬユニットに後続するＶＣＬ ＮＡＬユニットと結び付けられる。
コーデッド・ピクチャは、ピクチャのコード化された表現である。Ｈ．２６４／ＡＶＣ内のコーデッド・ピクチャは、ピクチャのデコーディングのために必要とされるＶＣＬ ＮＡＬユニットを含む。Ｈ．２６４／ＡＶＣにおいて、コーデッド・ピクチャは、一次コーデッド・ピクチャまたは冗長コーデッド・ピクチャであり得る。一次コーデッド・ピクチャは、有効なビットストリームのデコーディング・プロセスの中で使用され、一方冗長コーデッド・ピクチャは、一次コーデッド・ピクチャが首尾良くデコードされ得ない場合にのみデコードされるべき冗長表現である。ＨＥＶＣでは、冗長コーデッド・ピクチャは全く規定されなかった。
Ｈ．２６４／ＡＶＣでは、アクセス・ユニット（ＡＵ）は、一次コーデッド・ピクチャおよびそれに結び付けられたＮＡＬユニットを含む。Ｈ．２６４／ＡＶＣでは、アクセス・ユニット内のＮＡＬユニットの出現順序は、以下のように抑制される。任意のアクセス・ユニット・デリミタ−ＮＡＬユニットが、アクセス・ユニットの開始を標示することができる。それにはゼロ以上のＳＥＩ ＮＡＬユニットが後続する。一次コーデッド・ピクチャのコーデッド・スライスが次に出現する。Ｈ．２６４／ＡＶＣでは、一次コーデッド・ピクチャのコーデッド・スライスには、ゼロ以上の冗長コーデッド・ピクチャのためのコーデッド・スライスが後続することができる。冗長コーデッド・ピクチャは、ピクチャまたはピクチャの一部のコード化された表現である。冗長コーデッド・ピクチャは、例えば伝送中の損失または物理記憶媒体内の破損に起因して一次コーデッド・ピクチャがデコーダによって受信されない場合にデコードされることができる。
Ｈ．２６４／ＡＶＣでは、アクセス・ユニットは同様に、一次コーデッド・ピクチャを補足し例えば表示プロセスにおいて使用可能なピクチャである、補助コーデッド・ピクチャを含むことができる。補助コーデッド・ピクチャは、例えば、デコーデッド・ピクチャ内のサンプルの透明性レベルを規定するアルファ・チャネルまたはアルファ・プレーンとして使用されることができる。アルファ・チャネルまたはプレーンは、互いの上で少なくとも部分的に透明であるピクチャを重ね合わせることによって出力ピクチャが形成される、レイヤ状の編成またはレンダリング・システムの中で使用可能である。補助コーデッド・ピクチャは、モノクロ冗長コーデッド・ピクチャと同じシンタックスおよびセマンティクス上の制約を有する。Ｈ．２６４／ＡＶＣでは、
ＨＥＶＣでは、コーデッド・ピクチャは、ピクチャの全てのコーディング・ツリー・ユニットを格納するピクチャのコード化された表現として定義することができる。ＨＥＶＣでは、アクセス・ユニット（ＡＵ）は、規定の分類規則にしたがって互いに結び付けられ、デコーディング順で連続しており、ｎｕｈ＿ｌａｙｅｒ＿ｉｄの任意の特定の値をもつ最大１つのピクチャを格納するＮＡＬユニットのセットとして定義することができる。コーデッド・ピクチャのＶＣＬ ＮＡＬユニットを格納することに加えて、アクセス・ユニットは同様に非ＶＣＬ ＮＡＬユニットも格納することができる。
コーデッド・ピクチャがアクセス・ユニット内で一定の順序で出現することが求められる場合がある。例えば、ｎｕｈＬａｙｅｒＩｄＡに等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄを伴うコーデッド・ピクチャは、デコーディング順で、同じアクセス・ユニット内のｎｕｈＬａｙｅｒＩｄＡより大きいｎｕｈ＿ｌａｙｅｒ＿ｉｄを伴う全てのコーデッド・ピクチャに先行することが求められる可能性がある。
ＨＥＶＣでは、ピクチャユニットは、コーデッド・ピクチャの全てのＶＣＬ ＮＡＬユニットおよびその結び付けられた非ＶＣＬ ＮＡＬユニットを格納するＮＡＬユニットのセットとして定義することができる。非ＶＣＬ ＮＡＬユニットのための結び付けられたＶＣＬ ＮＡＬユニットは、一定のタイプの非ＶＣＬ ＮＡＬユニットについてはデコーディング順で非ＶＣＬ ＮＡＬユニットに先行するＶＣＬ ＮＡＬユニット、および他のタイプの非ＶＣＬ ＮＡＬユニットについてはデコーディング順で非ＶＣＬ ＮＡＬユニットの次のＶＣＬ ＮＡＬユニットとして定義することができる。ＶＣＬ ＮＡＬユニットのための結び付けられた非ＶＣＬ ＮＡＬユニットは、ＶＣＬ ＮＡＬユニットが結び付けられたＶＣＬ ＮＡＬユニットである非ＶＣＬ ＮＡＬユニットとして定義することができる。例えば、ＨＥＶＣでは、結び付けられたＶＣＬ ＮＡＬユニットは、ＥＯＳ＿ＮＵＴ、ＥＯＢ＿ＮＵＴ、ＦＤ＿ＮＵＴ、またはＳＵＦＦＩＸ＿ＳＥＩ＿ＮＵＴに等しいかまたはＲＳＶ＿ＮＶＣＬ４５．．ＲＳＶ＿ＮＶＣＬ４７またはＵＮＳＰＥＣ５６．．ＵＮＳＰＥＣ６３の範囲内のｎａｌ＿ｕｎｉｔ＿ｔｙｐｅを伴う非ＶＣＬ ＮＡＬユニットについてはデコーディング順で先行するＶＣＬ ＮＡＬユニットとして、そうでなければデコーディング順で次のＶＣＬ ＮＡＬユニットとして定義することができる。
ビットストリームは、コーデッド・ピクチャおよび１つ以上のコーデッド映像シーケンスを形成する結び付けられたデータの表現を形成するＮＡＬユニット・ストリームまたはバイト・ストリームの形をしたビット・シーケンスとして定義することができる。第１のビットストリームには、通信プロトコルの同じ接続内または同じファイル内など、同じ論理チャネル内の第２のビットストリームが後続することができる。基本ストリーム（映像コーディングに関連して）は、１つ以上のビットストリームのシーケンスとして定義することができる。第１のビットストリームの終りは、エンド・オブ・ビットストリーム（ＥＯＢ）ＮＡＬユニットと呼ぶことができビットストリームの最後のＮＡＬユニットである特定のＮＡＬユニットによって標示されることができる。ＨＥＶＣおよびその現行草案の拡張において、ＥＯＢ ＮＡＬユニットは０に等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄを有することが求められる。
Ｈ．２６４／ＡＶＣでは、コーデッド映像シーケンスは、デコーディング順で、ＩＤＲアクセス・ユニット（これを含めて）から排他的に次のＩＤＲアクセス・ユニット（これを含めずに）まで、またはビットストリームの終りまで、のいずれか早く出現するものに至るまでの連続するアクセス・ユニットのシーケンスとして定義される。
ＨＥＶＣでは、コーデッド映像シーケンス（ＣＶＳ）は、例えば、デコーディング順で、１に等しいＮｏＲａｓ１ＯｕｔｐｕｔＦｌａｇを伴うＩＲＡＰアクセス・ユニットと、それに続く、１に等しいＮｏＲａｓｌＯｕｔｐｕｔＦｌａｇを伴うＩＲＡＰアクセス・ユニットである任意の後続するアクセス・ユニットを含まずこのアクセス・ユニットに至るまでの全ての後続するアクセス・ユニットを含めた、１に等しいＮｏＲａｓｌＯｕｔｐｕｔＦｌａｇを伴うＩＲＡＰアクセス・ユニットでないゼロ以上のアクセス・ユニットとで構成されるアクセス・ユニットのシーケンスとして定義することができる。ＩＲＡＰアクセス・ユニットは、ベース・レイヤ・ピクチャがＩＲＡＰピクチャであるアクセス・ユニットとして定義することができる。ＮｏＲａｓｌＯｕｔｐｕｔＦｌａｇの値は、各ＩＤＲピクチャ、各ＢＬＡピクチャおよび、デコーディング順でビットストリーム内の特定のレイヤが、デコーディング順で同じｎｕｈ＿ｌａｙｅｒ＿ｉｄ値を有するエンド・オブ・シーケンスＮＡＬユニットに後続する第１のＩＲＡＰピクチャであるという点において第１のピクチャである各ＩＲＡＰピクチャについて、１に等しい。マルチ・レイヤＨＥＶＣでは、ＮｏＲａｓｌＯｕｔｐｕｔＦｌａｇの値は、各ＩＲＡＰピクチャについて、そのｎｕｈ＿ｌａｙｅｒ＿ｉｄが、ＬａｙｅｒＩｎｉｔｉａｌｉｚｅｄＦｌａｇ［ｎｕｈ＿ｌａｙｅｒ＿ｉｄ］が０に等しく、ＬａｙｅｒＩｎｉｔｉａｌｉｚｅｄＦｌａｇ［ｒｅｆＬａｙｅｒＩｄ］がＩｄＤｉｒｅｃｔＲｅｆＬａｙｅｒ［ｎｕｈ＿ｌａｙｅｒ＿ｉｄ］［ｊ］に等しい全てのｒｅｆＬａｙｅｒＩｄについて１に等しく、ここでｊは０からＮｕｍＤｉｒｅｃｔＲｅｆＬａｙｅｒｓ［ｎｕｈ＿ｌａｙｅｒ＿ｉｄ］−１まで（これを含む）の範囲内にあるようなものである場合に、１に等しい。そうでなければ、ＮｏＲａｓｌＯｕｔｐｕｔＦｌａｇの値は、ＨａｎｄｌｅＣｒａＡｓＢｌａＦｌａｇに等しい。１に等しいＮｏＲａｓｌＯｕｔｐｕｔＦｌａｇは、ＮｏＲａｓｌＯｕｔｐｕｔＦｌａｇが設定されているＩＲＡＰピクチャと結び付けられたＲＡＳＬピクチャがデコーダによって出されないという影響をもたらす。デコーダを制御できるプレーヤまたは受信機などの外部エンティティからデコーダに対してＨａｎｄｌｅＣｒａＡｓＢｌａＦｌａｇの値を提供するための手段が存在する場合がある。ＨａｎｄｌｅＣｒａＡｓＢｌａＦｌａｇは、例えば、ビットストリーム内で新しい位置まで進むかまたはブロードキャストに同調しデコーディングを開始し次にＣＲＡピクチャからのデコーディングを開始するプレーヤによって、１に設定可能である。ＣＲＡピクチャについて、ＨａｎｄｌｅＣｒａＡｓＢｌａＦｌａｇが１に等しい場合、ＣＲＡピクチャは、あたかもＢＬＡピクチャであるかのように、ハンドリングされデコーディングされる。
ＨＥＶＣでは、コーデッド映像シーケンスは、エンド・オブ・シーケンス（ＥＯＳ）ＮＡＬユニットと呼ぶことのできる特定のＮＡＬユニットがビットストリーム内に現われ、０に等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄを有する場合、終了するように（以上で仕様に対し）付加的または代替的に規定されることができる。
ＨＥＶＣでは、コーデッド映像シーケンス・グループ（ＣＶＳＧ）は、例えば、すでにアクティブでなかったＶＰＳ ＲＢＳＰ ｆｉｒｓｔＶｐｓＲｂｓｐをアクティブにするＩＲＡＰアクセス・ユニットと、それに続いて、ビットストリームの終りまでまたはｆｉｒｓｔＶｐｓＲｂｓｐと異なるＶＰＳ ＲＢＳＰをアクティブにするアクセス・ユニットを除いてこのアクセス・ユニットまでのうちデコーディング順で早い方に至るまでｆｉｒｓｔＶｐｓＲｂｓｐがアクティブＶＰＳ ＲＢＳＰである、デコーディング順で後続する全てのアクセス・ユニットとで集合的に構成される、デコーディング順で１つ以上の連続するＣＶＳ、として定義することができる。
ピクチャ構造（ＳＯＰ）は、デコーディング順で最初のコーデッド・ピクチャが最下位の時間的サブレイヤにおける参照ピクチャであり、潜在的にデコーディング順で最初のコーデッド・ピクチャを除いたいかなるコーデッド・ピクチャも、ＲＡＰピクチャではない、デコーディング順で連続する１つ以上のコーデッド・ピクチャとして定義することができる。前のＳＯＰ内の全てのピクチャは、デコーディング順で現ＳＯＰ内の全てのピクチャに先行し、次のＳＯＰ内の全てのピクチャは、デコーディング順で、現ＳＯＰ内の全てのピクチャに後続する。ＳＯＰは、階層的および反復的インター予測構造を表わすことができる。ピクチャ・グループ（ＧＯＰ）なる用語は、時として、ＳＯＰなる用語と互換的に、およびＳＯＰのセマンティクスと同じセマンティクスを有して使用される場合がある。
Ｈ．２６４／ＡＶＣおよびＨＥＶＣのビットストリーム・シンタックスは、特定のピクチャが他の任意のピクチャのインター予測のための参照ピクチャであるか否かを標示する。任意のコーディングタイプ（Ｉ、Ｐ、Ｂ）のピクチャが、Ｈ．２６４／ＡＶＣおよびＨＥＶＣにおいて参照ピクチャまたは非参照ピクチャであり得る。
統一リソース識別子（ＵＲＩ）は、リソースの名前を識別するために使用される文字列として定義できる。このような識別は、特定のプロトコルを用いた、ネットワーク上のリソースの表現とのインタラクションを可能にする。ＵＲＩは、ＵＲＩのための具体的なシンタックスおよび結び付けられたプロトコルを規定するスキームを通して定義される。統一リソース・ロケータ（ＵＲＬ）および統一リソース名（ＵＲＮ）は、ＵＲＩの形態である。ＵＲＬは、ウェブ・リソースを識別し、その主要なアクセス・メカニズムとネットワーク・ロケーションの両方を規定する、リソースの表現に対し作用するかこの表現を取得する手段を規定するＵＲＩとして定義することができる。ＵＲＮは、特定の名前空間内で名前によってリソースを識別するＵＲＩとして定義することができる。ＵＲＮは、そのロケーションまたはアクセス方法を暗示することなく、リソースを識別するために使用することができる。
ＩＳＯ／ＩＥＣ国際規格２３００９−１は、ＨＴＴＰ上の動的アダプティブ・ストリーミング（ＤＡＳＨ）を規定する。実施形態を実装することのできる映像ストリーミング・システムの一例として、以下でＭＰＥＧ−ＤＡＳＨのいくつかの概念、フォーマットおよび動作が説明される。本発明の態様は、ＭＰＥＧ−ＤＡＳＨに限定されず、むしろ、この説明は、本発明を部分的または完全に実施できる１つの考えられる基礎として提供されるものである。
ＨＴＴＰ上の動的アダプティブ・ストリーミング（ＤＡＳＨ）においては、マルチメディア・コンテンツをＨＴＴＰサーバー上で捕捉し記憶することができ、ＨＴＴＰを用いて配信することができる。コンテンツは、サーバー上で、２つの部分すなわち、利用可能なコンテンツ、そのさまざまな代替案、それらのＵＲＬアドレスおよび他の特徴のマニフェストを記述するメディア・プレゼンテーションの説明（ＭＰＤ）；および単一または多数のファイル内でチャンクの形で実際のマルチメディア・ビットストリームを格納するセグメントの中に記憶することができる。コンテンツを再生するためには、ＤＡＳＨクライアントは、例えばＨＴＴＰ、Ｅメール、サム・ドライブ、ブロードキャストまたは他の転送方法を使用して、ＭＰＤを取得できる。ＭＰＤをパースすることにより、ＤＡＳＨクライアントは、プログラム・タイミング、メディア・コンテンツの利用可能性、メディア・タイプ、解像度、最小および最大帯域幅、およびマルチメディア構成要素のさまざまなエンコードされた代替案、アクセス可能性特徴および所要デジタル著作権管理（ＤＲＭ）の存在、ネットワーク上のメディア構成要素のロケーション、および他のコンテンツ特性を知ることができる。この情報を用いて、ＤＡＳＨクライアントは、適切なエンコードされた代替案を選択し、例えばＨＴＴＰ ＧＥＴリクエストを用いて、セグメントをフェッチすることによってコンテンツのストリーミングを開始することができる。ネットワークスループット変動を許容するための適切なバッファリングの後、クライアントは、後続するセグメントのフェッチングを継続すると同時に、ネットワーク帯域幅の変動を監視することもできる。クライアントは、適切なバッファを維持するために、（より低いまたは高いビットレートで）異なる代替案のセグメントをフェッチすることによって、利用可能な帯域幅に対しいかに適応するか決定することができる。
メディア・プレゼンテーション説明（ＭＰＤ）は、ＨＴＴＰ上の動的アダプティブ・ストリーミングを確立するため、クライアントの情報を提供することができる。ＭＰＤは、ＧＥＴセグメント・リクエストを行うため、各セグメントのＨＴＴＰ−統一リソース・ロケータ（ＵＲＬ）などのメディア・プレゼンテーションを説明する情報を格納することができる。ＤＡＳＨでは、図６に示されているように、メディア・プレゼンテーションを構造化するために、階層データ・モデルを使用することができる。メディア・プレゼンテーションは、１つ以上の「周期（Ｐｅｒｉｏｄ）」のシーケンスを含むことができ、各「周期」は１つ以上の「グループ（Ｇｒｏｕｐ）」を格納することができ、各グループは、１つ以上の「適応セット（Ａｄａｐｔａｔｉｏｎ ｓｅｔｓ）」を格納でき、各「適応セット」は１つ以上の「表現（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）」を格納でき、各「表現」は１つ以上の「セグメント（Ｓｅｇｍｅｎｔ）」を含むことができる。「表現」は、エンコーディングの選択肢、例えばビットレート、解像度、言語、コーデックなどが異なる可能性のあるメディア・コンテンツまたはそのサブセットの代替的選択肢の１つである。「セグメント」は、一定の長さのメディア・データ、および、含まれているメディア・コンテンツをデコードし提示するためのメタデータを格納することができる。「セグメント」は、統一リソース・インジケータ（ＵＲＩ）によって識別されることができ、ＨＴＴＰ ＧＥＴリクエストによって要求され得る。「セグメント」は、ＨＴＴＰ−ＵＲＬ、および任意にはＭＰＤによって規定されるバイト範囲と結び付けられたデータのユニットとして定義されることができる。
ＭＰＥＧ−ＤＡＳＨに類似するストリーミング・システムは、例えば、ＩＥＴＦインターネット草案ｄｒａｆｔ−ｐａｎｔｏｓ−ｈｔｔｐ−ｌｉｖｅ−ｓｔｒｅａｍｉｎｇ−１３（および同じインターネット草案の他のバージョン）内で規定された、ＨＴＴＰライブ・ストリーミング（ＨＬＳとも呼ばれる）を含む。ＭＰＤに対応するマニフェスト・フォーマットとして、ＨＬＳは、拡張Ｍ３Ｕフォーマットを使用する。Ｍ３Ｕは、当初音響ファイルのために開発されたマルチメディアプレイリストのためのファイル・フォーマットである。Ｍ３Ｕプレイリストは、個別のラインからなるテキスト・ファイルであり、各ラインはＵＲＩ、ブランクであり、タグまたはコメントを標示する文字「＃」で始まる。ＵＲＩラインは、メディア・セグメントまたはプレイリストファイルを識別する。タグは＃ＥＸＴで始まる。ＨＬＳ仕様は、キー値対とみなすことのできる一定数のタグを規定する。タグの値部分は、属性値をシンタックスＡｔｔｒｉｂｕｔｅＮａｍｅ＝ＡｔｔｒｉｂｕｔｅＶａｌｕｅを有するものとみなすことのできる、属性−値対のカンマ区切りリストである属性リストを含むことができる。したがって、ＨＬＳ Ｍ３Ｕ８ファイルのタグは、ＭＰＤまたはＸＭＬ内の「エレメント」に類似するものとみなすことができ、ＨＬＳ Ｍ３Ｕ８ファイルの属性は、ＭＰＤまたはＸＭＬ内の「属性」に類似するものとみなすことができる。ＨＬＳ内のメディア・セグメントは、ＭＰＥＧ−２トランスポート・ストリームにしたがってフォーマットされ、単一のＭＰＥＧ−２プログラムを格納する。各メディア・セグメントは、「プログラム・アソシエーション・テーブル（ＰＡＴ）」および「プログラム・マップ・テーブル（ＰＭＴ）」で始まることが推奨される。
コンテナ・ファイルは、メディア・データなどのコンテンツおよびコンテンツに関連するメタデータを格納することができる。コンテナ・ファイルは、異なるデータ・テープを識別し、インターリーブするために使用されることができる。マルチメディア・コンテナ・ファイルは、例えば、音響、映像および画像を格納することができる。マルチメディア・コンテナ・ファイルは、マルチメディア・コンテンツ製作、マニピュレーション、伝送および消費という連鎖の中で使用される一エレメントとして使用することができる。コーディング・フォーマット（基本ストリーム・フォーマットまたはビットストリーム・フォーマットとしても知られる）とコンテナ・ファイル・フォーマットの間には実質的な差異が存在することができる。コーディング・フォーマットは、コンテンツ情報をビットストリームにコーディングする特定のコーディングまたは圧縮アルゴリズムのアクションに関係することができる。（メディア・ファイル・フォーマットとも呼ぶことのできる）コンテナ・ファイル・フォーマットは、全てさまざまな記憶および転送アーキテクチャを用いて、例えばローカル・デコーディングおよび再生のためにアクセスし、ファイルとして転送するかまたはストリーミングできるように、生成されたビットストリームを組織するためのシンタックスおよびセマンティクスを規定することができる。さらに、ファイル・フォーマットは、メディアの変換および編集、ならびに受信した実時間ストリームのファイルへの記録を容易にすることができる。
利用可能なメディア・ファイル・フォーマット規格としては、ＩＳＯベース・メディア・ファイル・フォーマット（ＩＳＯＢＭＦＦと略することのできるＩＳＯ／ＩＥＣ１４４９６−１２）ならびにＩＳＯＢＭＦＦから派生した規格、例えばＭＰＥＧ−４ファイル・フォーマット（ＭＰ４フォーマットとしても知られているＩＳＯ／ＩＥＣ１４４９６−１４）、ＮＡＬユニット構造化映像用のファイル−フォーマット（ＩＳＯ／ＩＥＣ１４４９６−１５）および３ＧＰＰファイル・フォーマット（３ＧＰフォーマットとしても知られている３ＧＰＰ ＴＳ２６．２４４）が含まれる。ＩＳＯ／ＩＥＣ１４４９６−１５は、ＩＳＯＢＭＦＦ対応ファイル内へのＨ．２６４／ＡＶＣおよび／またはＨＥＶＣおよび／またはそれらの拡張のビットストリームの記憶を規定している。言及されたファイル・フォーマット（ＩＳＯファイル・フォーマット自体を含む）ならびにＩＳＯＢＭＦＦから派生した他のファイル・フォーマットは、ＩＳＯファミリーのファイル・フォーマットと呼ぶことができる。
ＩＳＯＢＭＦＦのいくつかの概念、構造および仕様が、以下で、コンテナ・ファイル・フォーマットの一例として説明されており、これに基づいて、実施形態を実装することができる。本発明の態様はＩＳＯＢＭＦＦに限定されず、むしろ、説明は、それに基づいて本発明を部分的または完全に実施することのできる１つの考えられる基礎として提供される。
ＩＳＯベース・メディア・ファイル・フォーマット内の１つの基本的構築ブロックは、ボックスと呼ばれる。各ボックスは、ヘッダーとペイロードを有する。ボックス・ヘッダーは、そのボックスのタイプおよびバイト単位のボックスのサイズを標示する。ボックスは、他のボックスを包み込むことができ、ＩＳＯファイル・フォーマットは、一定のタイプのボックスの内部にどのボックス・タイプが許容されるかを規定する。さらに、いくつかのボックスの存在は、各ファイル内で義務的であり得、一方で、他のボックスの存在は任意であることができる。さらに、いくつかのボックス・タイプについて、２つ以上のボックスが１つのファイル内にあることが許容可能である場合もある。こうして、ＩＳＯベース・メディア・ファイル・フォーマットを、ボックスの階層構造を規定するものとみなすことができる。
ＩＳＯファミリーのファイル・フォーマットによると、ファイルは、ボックス内にカプセル化されるメディア・データおよびメタデータを含む。各ボックスは、４文字コード（４ＣＣ、ｆｏｕｒＣＣ）により識別することができる。４文字コードを、（８ビット値への或る文字変換、或るビット・エンディアンネスおよび或るバイト・エンディアンネスを仮定することにより）、３２ビットの符号無し整数によって、互換的に表現することができる。ヘッダーは、ボックスのタイプおよびサイズに関する情報を提供することができる。ＩＳＯＢＭＦＦボックス構造の例示的格納階層が、図５に示されている。
ＩＳＯファミリーのファイル・フォーマットによると、ファイルは、別個のボックス内に包み込むことのできるメディア・データおよびメタデータを含むことができる。一例示的実施形態において、メディア・データは、メディア・データ（ｍｄａｔ）ボックスに入れて提供でき、ムービー（ｍｏｏｖ）ボックスはメタデータを包み込むために使用することができる。いくつかの事例において、ファイルが動作可能になるためには、ｍｄａｔとｍｏｏｖの両方のボックスが存在しなければならない。ムービー（ｍｏｏｖ）ボックスは、１つ以上のトラックを含むことができ、各トラックは、１つの対応するトラック（ｔｒａｋ）ボックス内に存在することができる。各トラックのためのデータを、論理チャネルと考えることができる。各トラックは、トラック・タイプを規定する４文字コードにより識別されるハンドラと結び付けられる。映像、音響および画像シーケンス・トラックを、集合的にメディア・トラックと呼ぶことができ、これらのトラックは、基本的メディア・ストリームを格納する。他のトラック・タイプは、ヒント・トラックおよびタイムド・メタデータ・トラックを含む。トラックは、音響または映像フレームなどのサンプルを含む。メディア・トラックは、メディア圧縮フォーマットにしたがってフォーマティングされた（メディア・サンプルとも呼ぶことのできる）サンプル（およびＩＳＯベース・メディア・ファイル・フォーマットに対するそのカプセル化）を意味する。ヒント・トラックは、標示された通信プロトコル上での伝送のためのパケットを構築するためのクックブック命令を格納するヒント・サンプルを意味する。クックブック命令は、パケット・ヘッダー構築のためのガイダンスを含むことができ、パケット・ペイロード構築を含むことができる。パケット・ペイロード構築においては、他のトラックまたはアイテム内に存在するデータを参照することができる。こうして、例えば、パケット構築プロセス中にパケット内に特定のトラックまたはアイテム内のどのデータ・ピースをコピーするように命令するかに関する言及により、他のトラックまたはアイテム内に存在するデータを標示することができる。タイムド・メディア・トラックは、参照されたメディアおよび／またはヒント・サンプルを記述するサンプルを意味することができる。１つのメディア・タイプのプレゼンテーションのためには、１つのメディア・トラックを選択することができる。トラックのサンプルを、例えば標示されたサンプル・デコーディング順序で１だけ増分され得るサンプル番号と黙示的に結び付けることができる。トラック内の最初のサンプルは、サンプル番号と結び付けることができる。
ＩＳＯベース・メディア・ファイル・フォーマットにしたがった単純化されたファイル構造の一実施例について、以下で説明することができる。ファイルは、「ｍｏｏｖ」ボックスおよび「ｍｄａｔ」ボックスを含むことができ、「ｍｏｏｖ」ボックスは、それぞれ映像および音響に対応する１つ以上のトラックを含むことができる。
ＩＳＯベース・メディア・ファイル・フォーマットにしたがってフォーマティングされた多くのファイルが、ｆｔｙｐボックスとも呼ばれるファイル・タイプ・ボックスで始まる。ｆｔｙｐボックスは、ファイルをラベリングするブランドの情報を格納する。ｆｔｙｐボックスは、１つの主要なブランド標示および互換性あるブランドのリストを含む。主要ブランドは、ファイルをパースするために使用されるべき最も好適なファイル・フォーマット仕様を識別する。互換性あるブランドはそのファイルが適合するファイル・フォーマット仕様および／または適合性ポイントを標示する。ファイルが多数の仕様に適合していることが可能である。これらの仕様に対する適合性を示す全てのブランドをリストアップして、互換性あるブランドのサブセットを理解するだけのリーダーが、そのファイルがパースされ得ることの標示を得ることができるようにしなければならない。互換性あるブランドは同様に、特定のファイル・フォーマット仕様のファイル・パーサーが、ｆｔｙｐボックス内の同じ特定のファイル・フォーマット・ブランドを格納するファイルを処理する許可も与える。ファイル・プレーヤーは、ファイルのｆｔｙｐボックスが、自らサポートするブランドを含むか否かをチェックすることができ、ファイル・プレーヤーがサポートするいずれかのファイル・フォーマット仕様が互換性あるブランド中にリストアップされている場合にのみ、ファイルをパースし再生することができる。
ＩＳＯＢＭＦＦに適合するファイルは、メタ・ボックス（ｆｏｕｒＣＣ：「ｍｅｔａ」）内に、アイテム、メタ・アイテム、またはメタタデータ・アイテムと呼ばれる任意の非タイムド・オブジェクトを格納することができる。メタ・ボックスの名前はメタデータを意味するものの、アイテムは概してメタデータまたはメディア・データを格納することができる。メタ・ボックスは、ムービー・ボックス（ｆｏｕｒＣＣ：「ｍｏｏｖ」）内およびトラック・ボックス（ｆｏｕｒＣＣ：「ｔｒａｋ」）内でファイルのトップ・レベルに存在することができるが、多くとも１つのメタ・ボックスは、ファイル・レベル、ムービー・レベルまたはトラック・レベルの各々に発生することができる。メタ・ボックスは、「メタ」・ボックス・コンテンツの構造またはフォーマットを標示する「ｈｄｌｒ」ボックスを格納するよう求められる場合がある。メタ・ボックスは、参照され得る任意の数のアイテムをリストアップし、特徴づけすることができ、その各々を１つのファイル名と結び付けることができ、整数であるアイテム識別子（ｉｔｅｍ＿ｉｄ）によってファイルと共に一意的に識別される。メタデータ・アイテムは、例えば、メタ・ボックスの「ｉｄａｔ」ボックス内または「ｍｄａｔ」ボックス内に記憶されるかまたは別個のファイル内に存在することができる。メタデータがファイルの外部に位置設定される場合には、そのロケーションをＤａｔａＩｎｆｏｒｍａｔｉｏｎＢｏｘ（ｆｏｕｒＣＣ：「ｄｉｎｆ」）により宣言することができる。メタデータがＸＭＬシンタックスを用いてフォーマティングされＭｅｔａＢｏｘ内に直接記憶される必要がある特定の事例においては、メタデータをＸＭＩＢｏｘ（ｆｏｕｒＣＣ：「ｘｍｌ」）またはＢｉｎａｒｙＸＭＬＢｏｘ（ｆｏｒｃｃ：「ｂｘｍｌ」）内にカプセル化することができる。アイテムを、隣接バイト・レンジとして記憶することができ、またはそれを、各々が１つの隣接バイト・レンジである複数のエクステント内に記憶することもできる。換言すると、例えばインターリービングを有効化するために、エクステントにフラグメント化された状態で、アイテムを記憶することができる。エクステントは、リソースのバイトの隣接サブセットであり、リソースは、エクステントを連結することによって形成可能である。
２つ以上のメタ・ボックスを階層の任意のレベル（ファイル、ムービーまたはトラック）でサポートするためには、ＩＳＯベース・メディア・ファイル・フォーマットとして、メタ・ボックス・コンテナ・ボックス（「ｍｅｃｏ」）を使用することができる。メタ・ボックス・コンテナ・ボックスは、階層の任意のレベル（ファイル、ムービーまたはトラック）に任意の数の追加のメタ・ボックスを持つことができる。これにより、例えば同じメタデータが２つの異なる代替的なメタ・データ・システム内で提示されていることが許容されることになる。メタ・ボックス・リレーション・ボックス（「ｍｅｒｅ」）は、異なるメタ・ボックスが互いにどのように関連し合っているか、例えばそれらが正に同じメタデータ（ただし異なるスキームで記述されている）を格納しているか否か、または一方がもう一方のスーパーセットを代表しているか否かなどを記述することを可能にすることができる。
ＩＳＯベース・メディア・ファイル・フォーマットは、１つのファイル内に格納されるべきプレゼンテーションを制限しない。こうして、１つのプレゼンテーションが複数のファイル内に含まれることができる。一例として、１つのファイルは、全プレゼンテーションのためのメタデータを含むことができ、こうして、プレゼンテーションを自己格納させるために、全てのメディア・データを含むことができる。他のファイルが使用される場合、これらのファイルはＩＳＯベース・メディア・ファイル・フォーマットにしたがってフォーマティングされるよう求められない可能性があり、メディア・データを含めるために使用されることができ、同様に、未使用のメディア・データまたは他の情報も含むことができる。ＩＳＯベース・メディア・ファイル・フォーマットは、プレゼンテーション・ファイルのみの構造に関する。メディア・データ・ファイルのフォーマットは、メディア・ファイル内のメディア・データがＩＳＯベース・メディア・ファイル・フォーマットまたはその派生フォーマット内に規定されているようにフォーマティングされるという点においてのみ、ＩＳＯベース・メディア・ファイル・フォーマットまたはその派生フォーマットによって抑制され得る。
外部ファイルを参照できる能力は、データ参照を通して実現することができる。いくつかの実施例において、各トラック内に含まれたサンプル記述「ｓｔｓｄ」ボックスは、使用されたコーディング・タイプについての詳細な情報およびそのコーディングに必要な任意の初期化情報を各々提供するサンプル・エントリ・リストを提供することができる。チャンクの全てのサンプルおよびトラック・フラグメントの全てのサンプルは、同じサンプル・エントリを使用することができる。チャンクは、１トラックのための隣接するサンプル・セットとして定義することができる。同様に各トラック内に含められたＤａｔａ Ｒｅｆｅｒｅｎｃｅ「ｄｒｅｆ」ボックスは、統一リソース・ロケータ（ＵＲＬ）、統一リソース名（ＵＲＮ）および／またはメタデータを格納するファイルに対する自己参照の指標付きリストを定義することができる。サンプル・エントリが、Ｄａｔａ Ｒｅｆｅｒｅｎｃｅボックスの１つの指標をポイントして、それぞれのチャンクまたはトラック・フラグメントのサンプルを格納するファイルを標示することができる。
記録アプリケーションがクラッシュする、メモリ空間が無くなるまたは他の何らかの出来事が発生した場合にデータを失うことを回避するために、コンテンツをＩＳＯファイルに記録するときに、ムービー・フラグメントを使用することができる。ムービー・フラグメントがなければ、ファイル・フォーマットは、ムービー・ボックスなどの全てのメタデータがファイルの１つの隣接エリア内に書き込まれることを典型的に求める可能性があるため、データ損失が発生し得る。さらに、ファイルを記録する場合、利用可能な記憶のサイズに対しムービー・ボックスをバッファリングするための充分な量のメモリ空間（例えばＲＡＭ）が存在しない場合があり、ムービーが閉じられた場合のムービー・ボックスのコンテンツの再計算は、過度に低速である可能性がある。その上、ムービー・フラグメントは、正規のＩＳＯファイル・パーサーを用いたファイルの記録および再生を可能にすることができる。最終的に、ムービー・フラグメントが使用され、同じメディア・コンテンツを伴うもののムービー・フラグメント無しで組織されたファイルに比べて初期ムービー・ボックスが小さい場合、例えばファイルの同時受信再生などの漸進的ダウンローディングに求められる初期バッファリング持続時間は、より短いものであることができる。
ムービー・フラグメント・フィーチャは、従来ムービー・ボックス内に存在すると考えられるメタデータを多数のピースにスプリットすることを可能にすることができる。各ピースは、１トラックのための一定の時間に対応することができる。換言すると、ムービー・フラグメント・フィーチャは、ファイル・メタデータおよびメディア・データのインターリービングを可能にすることができる。その結果、ムービー・ボックスのサイズを制限し、上述の使用事例を実現することができる。
いくつかの実施例において、ムービー・フラグメントのためのメディア・サンプルは、それらがｍｏｏｖボックスと同じファイル内にある場合、通常通り、ｍｄａｔボックス内に存在することができる。しかしながら、ムービー・フラグメントのメタデータについては、ｍｏｏｆボックスを提供することができる。ｍｏｏｆボックスは、以前にｍｏｏｖボックス内にあったと考えられる一定の再生時間についての情報を含むことができる。ｍｏｏｖボックスは、それでもなお、そのままでも有効なムービーを表現できるが、さらに、ムービー・フラグメントが同じファイル内で後続することを標示するｍｖｅｘボックスを含むことができる。ムービー・フラグメントは、時間的にｍｏｏｖボックスに結び付けられているプレゼンテーションを拡張することができる。
ムービー・フラグメント内には、１トラックあたりゼロないし複数のいずれかの数を含めた、トラック・フラグメントのセットが存在することができる。トラック・フラグメントはそれ自体、ゼロないし複数のいずれかの数のトラック・ランを含むことができ、このドキュメントの各々が、このトラックのための隣接するサンプル・ランである。これらの構造の内部では、多くのフィールドが任意であり、デフォルトにされ得る。ｍｏｏｆボックス内に含めることのできるメタデータは、ｍｏｏｖボックス内に含めることができ、いくつかの事例において異なる形でコーディングすることのできるメタデータのサブセットに限定されることができる。ｍｏｏｆボックス内に含めることのできるボックスに関する詳細は、ＩＳＯベース・メディア・ファイル・フォーマット仕様から見出すことができる。
ＩＳＯベース・メディア・ファイル・フォーマットおよびその派生物、例えばＡＶＣファイル・フォーマットおよびＳＶＣファイル・フォーマットでのサンプルのグループ化は、グループ化基準に基づいた、１サンプル・グループのメンバーとしてのトラック内の各サンプルの割当てとして定義することができる。サンプルのグループ化におけるサンプル・グループは、隣接するサンプルであることに限定されず、非近接サンプルを格納することができる。１つのトラック内のサンプルについて２つ以上のサンプルのグループ化が存在できることから、各々のサンプルのグループ化は、グループ化のタイプを標示するためのタイプ・フィールドを有する。サンプルのグループ化は、２つのリンクされたデータ構造によって表現される。すなわち、（１）ＳａｍｐｌｅＴｏＧｒｏｕｐボックス（ｓｂｇｐボックス）は、サンプル・グループへのサンプルの割当てを表わし、（２）ＳａｍｐｌｅＧｒｏｕｐＤｅｓｃｒｉｐｔｉｏｎボックス（ｓｇｐｄボックス）は、グループの特性を記述する各サンプル・グループのためのサンプル・グループ・エントリを格納する。異なるグループ化基準に基づいてＳａｍｐｌｅＴｏＧｒｏｕｐおよびＳａｍｐｌｅＧｒｏｕｐＤｅｓｃｒｉｐｔｉｏｎボックスの多数のインスタンスが存在することができる。これらは、グループ化のタイプを標示するために使用されるタイプ・フィールドによって区別される。
サンプル・グループ・ボックス（ＳａｍｐｌｅＧｒｏｕｐＤｅｓｃｒｉｐｔｉｏｎボックスおよびＳａｍｐｌｅＴｏＧｒｏｕｐボックス）は、ムービー（ｍｏｏｖ）ボックス内でメディア情報（ｍｉｎｆ）、メディア（ｍｄｉａ）およびトラック（ｔｒａｋ）ボックス（この順序）の中に包み込まれているサンプル・テーブル（ｓｔｂｌ）ボックスの内部に存在する。ＳａｍｐｌｅＴｏＧｒｏｕｐボックスは、ムービー・フラグメント内に存在することが許されている。したがって、サンプルのグループ化は、フラグメント毎に行われることができる。
（ＵＲＬ形態としても言及され得る）ＵＲＬフラグメント識別子は、（フラグメント識別子無しで）ＵＲＬのベース部分により標示されるファイルなどのリソースの一部分をアクセスするため、特定のコンテンツ・タイプについて規定されることができる。ＵＲＬフラグメント識別子は、ＵＲＬ内で例えばハッシュ（「＃」）文字により識別されることができる。ＩＳＯＢＭＦＦについては、ＵＲＬフラグメント「＃Ｘ」は、Ｘに等しいｔｒａｃｋ＿ＩＤを伴うトラックを意味し、「＃ｉｔｅｍ＿ＩＤ＝」および「＃ｉｔｅｍ＿ｎａｍｅ＝」はファイル・レベル・メタ・ボックスを意味し、「＃／ｉｔｅｍ＿ＩＤ＝」および「＃／ｉｔｅｍ＿ｎａｍｅ＝」は、ムービー・ボックス内のメタ・ボックスを意味し、「＃ｔｒａｃｋ＿ＩＤ＝Ｘ／ｉｔｅｍ＿ＩＤ＝」および「＃トラック＿ＩＤ＝Ｘ／ｉｔｅｍ＿ｎａｍｅ＝」は、ムービー・フラグメント内に潜在的に見出されるメタ・ボックスを含む、Ｘに等しいｔｒａｃｋ＿ＩＤを伴うトラック内のメタ・ボックスを意味する。
マトロスカ・ファイル・フォーマットは、１つのファイル内に映像、音響、ピクチャまたはサブタイトル・トラックのいずれかを記憶する（ただしこれに限定されない）能力を有する。マトロスカは、ＷｅｂＭなどの派生ファイル・フォーマット用の基本フォーマットとして使用されることができる。マトロスカは、基礎として拡張可能なバイナリ・メタ言語（ＥＢＭＬ）を使用する。ＥＢＭＬは、ＸＭＬの原理からヒントを得たバイナリおよびオクテット（バイト）整列フォーマットを規定する。ＥＢＭＬ自体は、バイナリ・マークアップ技術の一般化された記述である。マトロスカ・ファイルは、ＥＢＭＬ「ドキュメント」を作り上げるエレメントからなる。エレメントは、エレメントＩＤ、エレメントのサイズについての記述子、およびバイナリ・データ自体を包含する。エレメントは、ネスティングされ得る。マトロスカのセグメント・エレメントは、他のトップレベル（レベル１）のエレメントである。マトロスカ・ファイルは、１つのセグメントを含む（ただし１つのセグメントで構成されることに限定されない）。マトロスカ・ファイル内のマルチメディア・データは、各々数秒のマルチメディア・データを典型的に格納するクラスタ（またはクラスタ・エレメント）の形で組織されている。クラスタは、ＢｌｏｃｋＧｒｏｕｐエレメントを含み、このエレメントはそれ自体ブロック・エレメントを含む。キュー・エレメントは、ランダム・アクセスまたはシーキングを補助できシーク・ポイントのためのファイル・ポインタまたはそれぞれのタイムスタンプを含むことのできるメタデータを含む。
画像バーストとも呼ぶことのできる画像シーケンスは、さまざまな手段を用いて取得でき、あるいは、以下のものの１つ以上を非限定的に含むさまざまな目的で使用することができる。
− 画像シーケンスは、例えばバースト写真などを使用して、逐次的に捕捉されたピクチャを表現できる。
− 画像シーケンスは、カメラをほぼ静止状態に保たれるものとみなすことができ捕捉パラメータが画像シーケンスのピクチャ間で異なっていた場合、焦点スタック、露光スタックなどを表現できる。
− 画像シーケンスは、カメラがパン（など）され時間的および／または並進運動的にほぼ等しい距離のピクチャがカメラの運動中に撮影されているパノラマを表現することができる。
− 画像シーケンスは、アニメーションまたはシネマグラフを表現できる。シネマグラフは、小さい反復的運動が起こるスチール・ピクチャとして定義することができる。
画像シーケンスは、空間的予測手段でコード化されたスチール・ピクチャまたは空間および時間的予測手段でピクチャされたインター・ピクチャのいずれかのシーケンスとして圧縮され得る。個別のピクチャを編集するためのサポートおよびランダム・アクセスを伴う画像シーケンスは、従来、独立してコード化された一連のイントラ・ピクチャとしてシーケンスを表現することによって有効化されてきた。このようなフォーマットには例えば、モーションＪＰＥＧ、アニメ−テッドＧＩＦ、およびＨ．２６４のイントラ・プロファイルが含まれる。
画像シーケンスが一連のスチール・ピクチャとして表現される場合、コーディング効率は典型的に低く、高解像度シーケンスのためのファイル・サイズ要件は圧倒的なものとなり得る。シーケンスが時間的予測を伴う映像としてコーディングされる場合、シーケンスがいかにデコーディングされる必要があるか、シーケンスをいかに再生できるか、そしてシーケンス内の画像のいくつかの編集をユーザーが望む場合の問題に関する厳しい制限が存在する。
ＭＰＥＧ−Ｈ画像ファイル・フォーマット（ＩＳＯ／ＩＥＣ２３００８−１２）は、ＩＳＯベース・メディア・ファイル・フォーマット（ＩＳＯＢＭＦＦ）の派生仕様である。本特許出願を作成している時点で、ＩＳＯ／ＩＥＣ２３００８−１２は、草案規格であり、したがって、規格の名称および／または通称は規格の最終版において変わる可能性がある、ということを理解する必要がある。ＩＳＯ画像ファイル・フォーマット（ＩＳＯＩＦＦ）およびＭＰＥＧ画像ファイル・フォーマットなどの名称が、考慮されてきた。標準仕様自体の中では（またそうでなければコンテキストが明確である場合）、「画像ファイル・フォーマット」という名前を用いて、ＩＳＯ／ＩＥＣ２３００８−１２に言及することができる。
以下では、実施形態を実装する基となるコンテナ・ファイル・フォーマットの一例として、ＭＰＥＧ−Ｈ画像ファイル・フォーマットのいくつかの概念、構造および仕様が説明される。本発明の態様は、ＭＰＥＧ−Ｈ画像ファイル・フォーマットに限定されず、むしろ、本発明を部分的または全体的に実現できる１つの考えられる基礎についての説明が提供されている。
ＩＳＯ／ＩＥＣ２３００８−１２に定義されているフォーマットは、高効率映像コーディング（ＨＥＶＣ）または任意の他の画像または映像コーデックを用いてコード化された画像の交換、編集および表示、およびこれらの画像と結び付けられたメタデータの伝達を可能にする。画像ファイル・フォーマットは、単一の画像、画像コレクションおよび画像シーケンスのための相互運用可能な記憶フォーマットを定義するために、ＩＳＯベース・メディア・ファイル・フォーマット内で定義されたツールを足場としている。画像ファイル・フォーマットは、ファイル内に記憶された画像をコーディングするために使用されるコーデックを抑制しない構造的ブランドおよびコード化された画像のためのＨＥＶＣの使用を必要とするＨＥＶＣベースのブランドを含む。
スチール画像をエンコードするためのＨＥＶＣの使用は、単一の画像および独立してコード化された画像の記憶、ならびにプレーヤおよび／またはデコーダにおいて任意に使用されるタイミングを伴い画像が他の画像に依存したものであり得る画像シーケンスの記憶をカバーするため、画像ファイル・フォーマットによってサポートされる。
画像ファイル・フォーマットに適合するファイルは、さまざまなニーズ（例えば印刷用の単一画像およびこの画像を合成するのに使用された画像バーストの記録など）を満たすように単一のファイルを構築できるようにする、スチール画像および画像シーケンスの両方を含むことができる。一般に、タイミングまたはインター・ピクチャ・コーディング依存性のいずれも求められない場合などの事例については、スチール画像サポートが使用される。トラックのために利用可能なＩＳＯベース・メディア・ファイル・フォーマットからのタイミングまたは他のツールが必要とされる場合（例えば単純な動画）、またはピクチャがインター・ピクチャ・コーディング依存性を伴ってコード化された場合には、トラックとして記憶された画像シーケンスを使用することができる。
ＩＳＯＢＭＦＦに類似する画像ファイル・フォーマットは、オブジェクト指向のメカニズムを使用し、ここで各オブジェクトはボックスと呼ばれる。全てのメディア・データおよびその関係するメタデータは、ボックス内にカプセル化される。各ボックスは、４文字コード（４ＣＣ）によって識別され、ボックスのタイプおよびサイズについて知らせるヘッダーで始まる。
ＭＰＥＧ−Ｈ画像ファイル・フォーマットによると、スチール画像がアイテムとして記憶される。コード化された画像を格納する画像アイテムが独立してコーディングされ、それらのデコーディングにおいて他のいずれのアイテムにも依存しないことが求められる可能性がある。
ＭＰＥＧ−Ｈ画像ファイル・フォーマットのコンテキストにおいては、後続するボックスは、ルート・レベルの「メタ」ボックス内に格納されることができ、以下で説明するように使用されることができる。ＭＰＥＧ−Ｈ画像ファイル・フォーマットにおいては、「メタ」ボックスのハンドラ・ボックスのハンドラ値は、「ｐｉｃｔ」である。コーデッド・メディア・データを格納するリソース（同じファイル内にあるか、統一リソース識別子により識別された外部ファイル内にあるかに関わらず）は、データ情報（「ｄｉｎｆ」）ボックスを通して分解され、一方アイテム・ロケーション（「ｉｌｏｃ」）ボックスは、参照されたファイル内の全てのアイテムの位置およびサイズを記憶する。アイテム参照（「ｉｒｅｆ」）ボックスは、型付き参照を用いてアイテム間の関係を文書化する。他のものと比べて何らかの形で最重要とみなされるべき、アイテムコレクション中の１アイテムが存在する場合には、このアイテムは、一次アイテム（「ｐｉｔｍ」）ボックスによってシグナリングされる。ここで記載されたボックスとは別に、「ｍｅｔａ」ボックスは、同様に、アイテムを記述するのに必要であり得る他のボックスを含むように融通性も有する。
「メタ」ボックス・アプローチを用いることによってコレクション画像が記憶されたと仮定すると、時として、画像間の一定の関係を指定することが不可欠である。このような関係の例としては、コレクションのためのカバー画像を標示すること、コレクション内のいくつかまたは全ての画像のためのサムネイル画像を提供すること、およびアルファ・プレーンなどの補助画像とコレクション中のいくつかまたは全ての画像を結び付けること、が含まれる。画像コレクション中のカバー画像が、「ｐｉｔｍ」ボックスを用いて標示される。サムネイル画像または補助画像が、それぞれ「ｔｈｍｂ」または「ａｕｘｌ」タイプのアイテム・リファレンスを用いて、一次画像アイテムにリンクされる。
画像ファイル・フォーマットは、派生画像をサポートする。アイテムは、それが別のアイテムに対する「ｄｉｍｇ」アイテム参照を含む場合、派生画像である。派生画像は、規定の入力画像に対して回転などの規定の動作（画像動作としても知られる）を行うことによって、取得される。派生画像を取得するために行われる動作は、アイテムのｉｔｅｍ＿ｔｙｐｅによって識別される。派生画像に対する入力として使用される画像アイテムは、例えばアイテム・タイプ「ｈｖｃ１」を伴うコード化された画像であることができ、または、他の派生画像アイテムであることもできる。
画像ファイル・フォーマット仕様には、クリーン・アパーチャ（すなわちクロッピング）動作（「ｃｌａｐ」に等しいｉｔｅｍ＿ｔｙｐｅ、９０度の倍数回転のための回転動作（「ｉｒｏｔ」に等しいｉｔｅｍ＿ｔｙｐｅ）および画像重複動作（「ｉｏｖｌ」に等しいｉｔｅｍ＿ｔｙｐｅ）の仕様が含まれる。画像重複「ｉｏｖｌ」派生画像は、より大きいキャンバス内で所与のレイヤ化の順序で１つ以上の入力画像を位置設定する。
画像ファイル・フォーマットの派生画像フィーチャは、画像ファイル・フォーマット自体の外部仕様ならびに後のバージョンが新しい動作を規定できるように、拡張可能である。
例えばＭＰＥＧ−Ｈ画像ファイル・フォーマットまたは類似のファイル・フォーマットのコンテキスト内で、以下の定義を使用することができる。コード化された画像は、１つの画像のコード化された表現として定義することができる。派生画像は、示された画像に対する示された動作によりファイル内に表現され、示された画像に対して示された動作を行うことによって取得可能な画像として定義することができる。画像は、画像なる用語が使用されるコンテキストに応じて、コード化された画像、派生画像または異なる色構成要素の画素の１つ以上のアレイとして定義できる。画像コレクションは、ＭＰＥＧ−Ｈ画像ファイル・フォーマット（またはそれに類するもの）にしたがって単一のファイルのアイテムとして記憶された１組の画像として定義できる。補助画像は、表示される意図のないものであり得るもののそれぞれの一次画像を補完する透明性データなどの補足的情報を提供する画像として定義することができる。カバー画像は、画像コレクションまたは画像シーケンスを代表する画像として定義することができ、画像コレクションまたは画像シーケンスの好ましい表示方法についての他の情報が利用可能でない場合に表示されなければならない。予め計算された派生画像は、１つ以上の他の画像から導出されたコード化された画像として定義することができる。一次画像は、アイテムとして記憶され、補助画像またはサムネイル画像ではない画像として定義することができる。サムネイル画像は、一次画像のより解像度の低い表現として定義することができる。
画像シーケンスは、アドバイザリ・タイミングと結び付けることができ、その中で画像をインター予測することのできる画像シーケンスとして定義することができる。ＭＰＥＧ−Ｈ画像ファイル・フォーマットでは、画像シーケンスは、ＩＳＯＢＭＦＦのトラック・メカニズムにしたがって記憶される。画像間にコーディング依存性が存在する場合、または画像の再生がタイミングされる場合に、画像シーケンス・トラックが使用される。画像シーケンス・トラック内のタイミングは、プレーヤのためのアドバイザリであるとして定義することができる。画像シーケンスとモーション・ビデオを区別するために、ＭＰＥＧ−Ｈ画像ファイル・フォーマット内には新しいハンドラ―・タイプ「ｐｉｃｔ」が導入された。
ＭＰＥＧ−Ｈ画像ファイル・フォーマットは、（包含および／または参照により）ＨＥＶＣコーデッド・スチール画像および画像シーケンスを、ＭＰＥＧ−Ｈ画像ファイル・フォーマットに適合するファイルへとカプセル化するための仕様を含む。他のコーディング・フォーマットでコード化された画像および画像シーケンスの、ＭＰＥＧ−Ｈ画像ファイル・フォーマットに適合するファイルへのカプセル化を規定することが可能である。
多目的インターネット・メール拡張（ＭＩＭＥ）は、例えば映像および音響、画像、ソフトウェアなどのインターネット上の異なる種類のデータ・ファイルを伝送し受信することを可能にするＥメール・プロトコルに対する拡張である。インターネット・メディア・タイプは、ファイルが格納するデータのタイプを標示するためにインターネット上で使用される識別子である。このようなインターネット・メディア・タイプは、同様に、コンテンツ・タイプと呼ぶこともできる。異なるメディア・フォーマットを格納できる複数のＭＩＭＥタイプ／サブタイプの組合せが存在する。コンテンツ・タイプ情報は、メディア伝送の始めにあるＭＩＭＥヘッダー内に、伝送エンティティによって包含されることができる。こうして受信エンティティは、利用可能なコーデック・セットを考慮して、特定のエレメントをレンダリングできるか否かを決定するために、このようなメディア・コンテンツの詳細を検査する必要がある場合がある。特に、エンド・システムのリソースが制限されている場合、またはエンド・システムに対する接続の帯域幅が制限されている場合、コンテンツ・タイプだけから、そのコンテンツをレンダリングできるか否かを知ることが有用である可能性がある。
ＲＦＣ６３８１は、内部に格納されたメディア・フォーマットによって利用されるコーデックまたは全体的コンテナ・フォーマットのプロファイルの一義的な仕様を可能にするため、さまざまなＭＩＭＥタイプまたはサブタイプの組合せと共に使用される２つのパラメータ「ｃｏｄｅｃｓ」と「ｐｒｏｆｉｌｅｓ」を規定している。
格納されたメディアをレンダリングするように標示された特定のコーデックをコンテンツにラベリングすることによって、受信システムは、コーデックがエンド・システムによってサポートされているか否かを決定し、されていない場合は、適切なアクション（例えばコンテンツを拒絶する、状況の通知を送る、サポートされたタイプへとコンテンツをトランスコーディングする、求められたコーデックをフェッチしインストールする、標示されたコーデックのサブセットをサポートするのに充分であるか否かを決定するためのさらなるインスペクションなど）をとることができる。
ＩＳＯＢＭＦＦから導出されたファイル・フォーマットについては、ＲＦＣ６３８１の中で規定されたコーデック・パラメータは、以下で説明する正規の表現シンタックスにしたがって以下の構造を有するものとみなされることができる。ＬｉｓｔＩｔｅｍ１（，ＬｉｓｔＩｔｅｍＮ）＊。
同様にして、ＲＦＣ６３８１に規定されたプロファイル・パラメータは、受信機に対して、コンテンツが適合している仕様の全体的標示を提供することができる。これは、いくつかの仕様に対するコンテナ・フォーマットおよびそのコンテンツの整合性の標示である。受信機は、それが宣言されたプロファイルのうちのどれをサポートしそれらのプロファイルが何を意味しているかを知るために検査することによって、コンテンツをどの程度までハンドリングしレンダリングできるかを解明できる可能性がある。
ＭＩＭＥに対する原初の動機づけの１つは、メッセージ部分の特定のメディア・タイプを識別する能力にある。しかしながら、さまざまな要因に起因して、ＭＩＭＥタイプおよびサブタイプを調べることから、ボディ部分内にどの特定的メディア・フォーマットが格納されるかまたはコンテンツをレンダリングするためにどのコーデックが標示されるか、を知ることは、必ずしも可能ではない。
１セットから選択されたコーデックを格納する複数のメディア・タイプ／サブタイプ（現在登録されているかまたは登録ペンディングを伴って展開されている）が存在する。ここで説明されるパラメータが存在しない場合には、コンテンツをレンダリングするために必要とされるコーデックまたは他のフィーチャを決定する目的で、各メディア・エレメントを検査することが必要である。
画像ファイル・フォーマットは、２つのＭＩＭＥタイプを規定し、一方は画像および画像コレクション用、他方は画像シーケンス用である。コーデック・パラメータのフォーマットは、これらのＭＩＭＥタイプのために規定される。例えば、ＲＦＣ６３８１にしたがったコーデック・パラメータの包括的シンタックス内の各ＬｉｓｔＩｔｅｍは、画像ファイル・フォーマットで以下のようにフォーマティングされるものとみなすことができる。（ｔｒａｋ．ＨａｎｄｌｅｒＴｙｐｅ｜ｉｔｅｍ）．ＳａｍｐｌｅＥｎｔｒｙＴｙｐｅ．ＰｒｏｆｉｌｅＴｉｅｒＬｅｖｅｌ（ここで｜は、二者択一関係を表わす）。コーデック文字列は、ファイル内に含まれたトラックおよびアイテムを区別するために識別子「ｔｒａｋ」または「ｉｔｅｍ」を含む。画像シーケンス・トラックおよび映像トラックの間の区別をサポートするため、コーデック文字列内には、ハンドラ・タイプＨａｎｄｌｅｒＴｙｐｅが含まれている。ＡＶＣおよびＨＥＶＣベースのコーデックについては、サンプル・エントリ・タイプＳａｍｐｌｅＥｎｔｒｙＴｙｐｅ（または、等価としてアイテム・タイプ）およびプロファイル・ティア・レベル情報ＰｒｏｆｉｌｅＴｉｅｒＬｅｖｅｌを含む文字列は、ＩＳＯ／ＩＥＣ１４４９６−１５内で規定されているものと同一である。
例えば、ＰｒｏｆｉｌｅＴｉｅｒＬｅｖｅｌは、ＨＥＶＣについては、以下のように規定される。すなわちＰｒｏｆｉｌｅＴｉｅｒＬｅｖｅｌのエレメントは、例えばピリオド文字（「．」）で分離されたＨＥＶＣデコーダ構成記録からの一連の値である。全ての数値エンコーディングにおいて、先行ゼロは省略することができる。ＰｒｏｆｉｌｅＴｉｅｒＬｅｖｅｌは、以下のエレメントを含む。
− １０進数としてエンコードされるｇｅｎｅｒａｌ＿ｐｒｏｆｉｌｅ＿ｉｄｃが続く、文字無し（ｇｅｎｅｒａｌ＿ｐｒｏｆｉｌｅ＿ｓｐａｃｅ＝＝０）としてエンコードされるｇｅｎｅｒａｌ＿ｐｒｏｆｉｌｅ＿ｓｐａｃｅまたはｇｅｎｅｒａｌ＿ｐｒｏｆｉｌｅ＿ｓｐａｃｅ１、２、３としての「Ａ」、「Ｂ」、「Ｃ」、
− １６進数としてエンコードされるｇｅｎｅｒａｌ＿ｐｒｏｆｉｌｅ＿ｃｏｍｐａｔｉｂｉｌｉｔｙ＿ｆｌａｇｓ（先行ゼロは省かれる）、
− １０進数としてエンコードされるｇｅｎｅｒａｌ＿ｌｅｖｅｌ＿ｉｄｃが続く、「Ｌ」（ｇｅｎｅｒａｌ＿ｔｉｅｒ＿ｆｌａｇ＝＝０）または「Ｈ」（ｇｅｎｅｒａｌ＿ｔｉｅｒ＿ｆｌａｇ＝＝１）としてエンコードされるｇｅｎｅｒａｌ＿ｔｉｅｒ＿ｆｌａｇ；
− 各々１６進数としてエンコードされ、各バイトのエンコーディングは１ピリオドで分離されている、ｇｅｎｅｒａｌ＿ｐｒｏｇｒｅｓｓｉｖｅ＿ｓｏｕｒｃｅ＿ｆｌａｇを格納するバイトから始まる抑制フラグの６バイトの各々、ゼロである末尾バイトは省略できる。
しかしながら、画像ファイル・フォーマットのためのコーデック・パラメータの仕様には、派生画像に関する考慮が欠如している。
これは、さまざまな問題に導く可能性があり、そのうちのいくつかは、ＨＴＭＬ５．１コードの後続するピースの例と共に、本明細書中に例示されている。同じ画像の２つのコーデッド表現、すなわち第１のファイルｐｒｅｆｅｒｒｅｄ＿ｉｍａｇｅ．ｈｅｖｃおよび第２のファイルｆａｌｌｂａｃｋ＿ｉｍｇ．ｊｐｇが存在する。ファイルｐｒｅｆｅｒｒｅｄ＿ｉｍａｇｅ．ｈｅｖｃは、画像ファイル・フォーマットに適合し、その一次アイテムとして派生画像を有する。その結果、コーデックＭＩＭＥパラメータは、本草案ＩＳＯ／ＩＥＣ２３００８−１２によっては充分に規定されていない。ファイルｐｒｅｆｅｒｒｅｄ＿ｉｍａｇｅ．ｈｅｖｃは、画像のデコーディングがサポートされていることを条件として、ウェブ・ブラウザがダウンロードする好ましい画像（例えば、それぞれのＪＰＥＧ画像に比較してそのサイズがより小さいものであることに起因して）である。しかしながら、以上にリストアップした情報が欠如していることに起因して、ウェブ・ブラウザは、それがｐｒｅｆｅｒｒｅｄ＿ｉｍａｇｅ．ｈｅｖｃを処理できるか否かの決断を下すことができず、ファイルｆａｌｌｂａｃｋ＿ｉｍｇ．ｊｐｇをダウンロードすると考えられる。一切の画像またはいずれのフォーマットもサポートしないブラウザは、ａｌｔ属性と共に標示されたフォールバック記述テキストをダウンロードする。
＜ｐｉｃｔｕｒｅ＞
＜ｓｏｕｒｃｅ ｔｙｐｅ＝’’ｉｍａｇｅ／ｍｐｅｇ−ｈ； ｃｏｄｅｃｓ＝ｉｔｅｍ．ｕｎｓｐｅｃｉｆｉｅｄ＿ａｔ＿ｔｈｅ＿ｍｏｍｅｎｔ’’ｓｒｃ＝’’ｐｒｅｆｅｒｒｅｄ＿ｉｍｇ．ｈｅｖｃ’’／＞
＜ｉｍｇ ｓｒｃ＝’’ｆａｌｌｂａｃｋ＿ｉｍｇ．ｊｐｇ’’ａｌｔ＝’’Ｆａｌｌｂａｃｋ ｄｅｓｃｒｉｐｔｉｖｅ ｔｅｘｔ’’／＞
＜／ｐｉｃｔｕｒｅ＞
画像プレーヤー（例えばブラウザ内）が派生画像の表現を再生することを意図する場合、それは、派生画像の表現の中で文書化された動作を用いて、原画像から派生画像を編成する必要がある。プレーヤは、動作自体を行う前に派生画像を編成する能力を自らが有するか否かを評価する必要がある可能性があるが、これは、そうでなければ、プレーヤが派生画像の編成に失敗し、単に（ダウンロードおよびプロセッシングにおける）時間および計算リソースを浪費する可能性があるからである。プレーヤが、派生画像を編成するために必要とされる全てのリソースを有するか否かの評価には、以下の課題のうちの１つ以上が含まれる可能性がある。
− プレーヤは、それが、派生画像の表現において使用される全てのタイプの動作を行う能力があるか否かを評価する必要がある。
− プレーヤは、派生画像の構築のための入力画像として使用されるコード化された画像を自らがデコードできるか否かを評価する必要がある。これには、以下のことが関与する可能性がある。
○ コーデック（例えば、ＨＥＶＣ）およびコーディングプロファイル（例えば主要プロファイル）がサポートされているか否かを決定すること。同様に、任意には、入力画像のティアおよびレベルがサポートされているか否か。
○ 動作を行うために必要とされる利用可能なメモリ・リソースをプレーヤが有しているか否かを評価すること。
その結果として、プレーヤが派生画像を編成する能力を有するか否かを評価するための単純化された方法に対するニーズが存在する。
次に、上述の問題を少なくとも軽減するために、以下では、派生画像を編成する能力を評価するための方法が提示される。
図６に開示されている評価方法において、プレーヤは、第１のファイルの第１の記述を受信し（６００）、この第１の記述は、第１のファイル内に含まれているかまたは第１のファイルが参照している少なくとも１つの派生画像の特性を含む。プレーヤは、派生画像の特性に基づいて、派生画像を取得すべきか否かを決定し（６０２）、派生画像を取得するとの決定に応えて、派生画像を含む第１のファイルを取得する（６０４）。
一実施形態によると、プレーヤは、派生画像により表現されたもののような対応する画像コンテンツの表現を含む第２のファイルの第２の記述をさらに受信し（６０６）、派生画像の特性および第２の記述に基づいて、第１のファイルまたは第２のファイルを取得すべきか否かを決定する（６０８）ことができる。次に、プレーヤは、第１のファイルまたは第２のファイルのいずれかを取得する（６１０）。
こうして、プレーヤは、派生画像の再構築が可能であるか否かを決定することができる。したがって、ファイル内の派生画像が受信機のプレーヤ、ウェブ・ブラウザなどにより再構築され得ない場合に、ファイルの不必要なダウンローディングを回避するために、標示された特性を使用することができる。一実施形態によると、利用可能な同じコンテンツを伴う複数の代替的画像ファイルが存在する可能性があり、プレーヤは、記述に基づいて前記代替案のどの画像ファイルがダウンロードされ再構築されるかを選択することができる。
一実施形態によると、第１の記述は、ＭＩＭＥタイプを含む。
一実施形態によると、ＭＩＭＥタイプなどの第１の記述は、少なくとも１つの派生画像について以下の情報のうちの１つ以上を含む。
− ファイルの派生画像の中で使用される命令セットを規定するＵＲＩのリストを含む第１の任意のＭＩＭＥパラメータなどの命令セットの識別リストと、命令の識別リストのリスト・エレメントをポイントする、少なくとも１つの派生画像に特定的な指標とを含むことのできる、少なくとも１つの派生画像のために使用される命令セットの第１の識別。
− 例えばコーデック・パラメータと名付けることのできる第２の任意のＭＩＭＥパラメータの中に格納されることのできる、少なくとも１つの派生画像のための、コーデッド入力画像のコーデッド・プロファイルおよびコーデックの第２の識別、
− 少なくとも１つの派生画像を構築するために使用される任意の単一画像動作の入力および出力画像のために求められる累積画素数などの、少なくとも１つの派生画像の構築のために必要とされるリソースを表わすリソース・カウント。
派生画像のための命令セットは、派生画像タイプ・セットまたは画像動作タイプ・セットとして定義することができる。特定の命令セットは、命令セットにより定義された動作を用いて派生画像を構築できる場合、派生画像のために使用されるものとみなすことができる。
第１の任意のＭＩＭＥパラメータは、例えばｄｉｍｇ−ｉｎｓｔｒ−ｓｅｔと呼ぶことができ、それは、特定の派生画像および、特定の派生画像のための入力として直接的または間接的に使用される任意の派生画像のために用いられる１つ以上の命令セットを定義することができる。例えば、ＩＳＯ／ＩＥＣ２３００８−１２中に規定された画像動作（クリーン・アパーチャ、ローテーション、およびオーバーレイ）を、命令セットとみなすことができる。
コーデックＭＩＭＥパラメータは、特定の派生画像のための入力として直接的または間接的に使用されるコード化された画像のために用いられるコーデック（例えばＨＥＶＣ）およびプロファイル（例えば主要プロファイル）を定義することができる。ティアおよびレベルも含むことができるが、概して個別の画像のデコーディングに関与する実時間処理要件は全く存在しないことから、絶対的に必要ではない。
（最大サンプル・アレイ内の）累積的画素数を用いて、画像に必要とされるメモリ・リソースを特徴づけすることができる（一方、深度およびクロマ・フォーマットなどの他の因子を、コーデック・プロファイルおよび派生画像命令セットから結論づけることができる）。特定の派生画像または直接的または間接的入力画像のいずれかのために、複数の入力画像が必要になり得ることから、画像の累積的画素カウントが提供される。このことは、特定の派生画像のための入力として直接的または間接的に使用される全ての中間画像をプレーヤのメモリ限界内で保つことができることを保証する上で、助けとなる。
次に、正規の表現シンタックスが使用される、ＭＩＭＥタイプの実装に関するさまざまな実施形態が開示され、ここでイタリック体のキーワードは、キーワードをそれらの値で置換することによって分解される変数とみなされ、（）は１つ以上の文字の文字列を表わし、＊は、０以上の回数だけ先行するカッコ内に包み込まれている文字列の内含を表わし、？は、０または１回だけ先行するカッコ内に包み込まれた文字列の包含を表わし、英数字はそのまま内含される。少なくとも１つの派生画像のための第１の識別、第２の識別およびリソース・カウントのうちの１つ以上を標示するために正規の表現シンタックス以外のシンタックス規則および／またはシンタックスの他の変形形態を用いて、類似の実施形態を形成できるということを理解する必要がある。
画像ファイル・フォーマットに適合するファイルのためのコーデック・パラメータは、以下の構造を有する。
ＬｉｓｔＩｔｅｍ１（，ＬｉｓｔＩｔｅｍＮ）＊
ここで、各ＬｉｓｔＩｔｅｍは、ＳａｍｐｌｅＥｎｔｒｙＴｙｐｅがコーディング・フォーマットを標示する場合、以下の構造を有することが提案されている。
（ｔｒａｋ．ＨａｎｄｌｅｒＴｙｐｅ｜ｉｔｅｍ）．ＳａｍｐｌｅＥｎｔｒｙＴｙｐｅ．ＰｒｏｆｉｌｅＴｉｅｒＬｅｖｅｌ
一実施形態によると、画像ファイル・フォーマットに適合するファイル／リソースのＭＩＭＥタイプについて、以下の追加の仕様が作成される：
ｄｉｍｇ−ｉｎｓｔｒ−ｓｅｔの任意のＭＩＭＥパラメータは、以下のものを格納するように規定される。
＜ｕｒｉ１＞（＜ｕｒｉＮ＞）＊
ここで、各ｕｒｉＮはＵＲＩであり、各ｕｒｉＮは山カッコ内に包み込まれている。ｄｉｍｇ−ｉｎｓｔｒ−ｓｅｔは不在であるものの、コーデック・パラメータによって参照されており、ｄｉｍｇ−ｉｎｓｔｒ−ｓｅｔは、例えば画像ファイル・フォーマット内で規定された派生画像の命令セットまたはアイテム・タイプを意味することのできる値ｕｒｎ：ｍｐｅｇ：ｉｓｏｉｆｆ：２０１５などの既定のデフォルト値のみを伴うｕｒｉｌから成るものと推論される。
例えば、ＵＲＩｕｒｎ：ｍｐｅｇ：ｉｓｏｉｆｆ：２０１５は、クリーン・アパーチャ、ローテーションおよびオーバーレイ動作から成る派生画像命令セットを標示するために規定されることができる。別の実施例においては、ＵＲＩｕｒｎ：ｍｐｅｇ：ｉｓｏｉｆｆ：２０１５：ｂａｓｅｌｉｎｅを、クリーン・アパーチャおよびローテンション派生画像から成る派生画像命令セットを標示するように規定することができ、クリーン・アパーチャ、ローテーションおよびオーバーレイ派生画像をから成る派生画像命令セットを標示するように、ＵＲＩｕｒｎ：ｍｐｅｇ：ｉｓｏｉｆｆ：２０１５：ｅｘｔｅｎｄｅｄを規定することができる。
一実施形態によると、画像ファイル・フォーマットのＭＩＭＥタイプのコーデック・パラメータ・シンタックス内のＬｉｓｔＩｔｅｍについての以下の仕様が作成される。派生画像のためには、ｄｉｍｇに等しいＳａｍｐｌｅＥｎｔｒｙＴｙｐｅがＬｉｓｔＩｔｅｍのシンタックス内で使用され、ＬｉｓｔＩｔｅｍは、以下の構造を有する。
ｄｉｍｇ（．ＩｎｓｔｒＩｄｘ（．ＰｉｘｅｌＣｏｕｎｔ．ＣｏｄｅｃＩｎｆｏ）？）？
ここで、
ＩｎｓｔｒＩｄｘは、派生画像のために使用された命令セットを識別するＵＲＩｕｒｉＬの指標Ｌを表わす。ＩｎｓｔｒＩｄｘが存在しない場合、ＩｎｓｔｒＩｄｘは１に等しいものと推論される；
ＰｉｘｅｌＣｏｕｎｔは、派生画像を構築するために使用される任意の単一の画像動作の入力および出力画像に必要とされる最大画素数を標示する正の１０進整数である；
ＣｏｄｅｃＩｎｆｏは、以下の構造を有する：
ＮｕｍＣｏｄｅｄＩｍｇ．（ＩｔｅｍＴｙｐｅ．ＰｒｏｆｉｌｅＴｉｅｒＬｅｖｅｌ）＊、ここでＮｕｍＣｏｄｅｄＩｍｇは、ＩｔｅｍＴｙｐｅ．ＰｒｏｆｉｌｅＴｉｅｒＬｅｖｅｌ対の異なる値を有することのできるコーデッド入力画像の正の整数であり、対ＩｔｅｍＴｙｐｅ．ＰｒｏｆｉｌｅＴｉｅｒＬｅｖｅｌの数はＮｕｍＣｏｄｅｄＩｍｇに等しい。ＩｔｅｍＴｙｐｅは、派生画像のために入力されたコーデッド画像の４文字アイテム・タイプであり、ＰｒｏｆｉｌｅＴｉｅｒＬｅｖｅｌは、ＲＦＣ６３８１内のＩＳＯベース・メディア・ファイル・フォーマット名前空間のコーデック・パラメータのために規定されたプロファイル・レベル情報である。ＡＶＣおよびＨＥＶＣベースのコーデックについて、ＰｒｏｆｉｌｅＴｉｅｒＬｅｖｅｌのフォーマットは、ＩＳＯ／ＩＥＣ１４４９６−１５内に規定されている。
ＣｏｄｅｃＩｎｆｏは、終りから切り取ることができるように、ＬｉｓｔＩｔｅｍの最後の部分となるように選択される。例えば、ほとんどの場合、全ＨＥＶＣＰｒｏｆｉｌｅＴｉｅｒＬｅｖｅｌ文字列は、内含される必要のない末尾のゼロを格納する。
実施形態のシンタックスの例としては、以下のものが含まれる。
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：ｉｍａｇｅ／ｍｐｅｇ−ｈ；ｃｏｄｅｃｓ＝ｉｔｅｍ．ｄｉｍｇ
ファイルの一次アイテムが画像ファイル・フォーマット内で規定された命令セットを用いた派生画像である画像ファイル。
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：ｉｍａｇｅ／ｍｐｅｇ−ｈ；ｃｏｄｅｃｓ＝ｉｔｅｍ．ｄｉｍｇ．１．２９９５２００．ｈｖｃ１．Ａ１．８０．Ｌ９３．Ｂ０
ファイルの一次アイテムが、画像ファイル・フォーマット内で規定され、一方が１９２０×１０８０のサイズで、他方が１２８０×７２０のサイズのものという最高２つの画像の記憶を必要とする命令セットを用いた派生画像であり、メイン・ティア、レベル３．１で１つの漸進的でフレーム・パッキングされていないＨＥＶＣ主要プロファイル画像のデコーディングを必要とする画像ファイル。
一実施形態によると、画像ファイル・フォーマットのＭＩＭＥタイプのコーデック・パラメータ・シンタックス内のＬｉｓｔＩｔｅｍについての以下の仕様が作成される。派生画像のためには、ｄｉｍｇに等しいＳａｍｐｌｅＥｎｔｒｙＴｙｐｅがＬｉｓｔＩｔｅｍのシンタックス内で使用されるものとし、ＬｉｓｔＩｔｅｍは、以下の構造を有する：
ｄｉｍｇ（．ＩｎｓｔｒＩｄｘ（．ＷｉｄｔｈＨｅｉｇｈｔ（．ＣｏｄｅｃＩｎｆｏ）？）？）？
ここで、
ＩｎｓｔｒＩｄｘは、派生画像のために使用された命令セットを識別するＵＲＩｕｒｉＬの指標Ｌを表わす。ＩｎｓｔｒＩｄｘが存在しない場合、ＩｎｓｔｒＩｄｘは１に等しいものと推論される。
ＷｉｄｔｈＨｅｉｇｈｔは以下の構造を有する。ＮｕｍＩｍｇ．（ＷｉｄｔｈＩｍｇＮ．ＨｅｉｇｈｔＩｍｇＮ）＊、ここでＮｕｍＩｍｇは、最大メモリ量を必要とする単一画像動作のために求められる画像数を表わす正の１０進整数であり、対ＷｉｄｔｈＩｍｇＮ．ＨｅｉｇｈｔＩｍｇＮの数は、ＮｕｍＩｍｇに等しい。ＷｉｄｔｈＩｍｇＮおよびＨｅｉｇｈｔＩｍｇＮは、この特定の単一画像動作に必要とされるデコード化された画像または派生画像のそれぞれ幅および高さを表わす正の１０進整数である。
ＣｏｄｅｃＩｎｆｏは、以下の構造を有する。
ＮｕｍＣｏｄｅｄＩｍｇ．（ＩｔｅｍＴｙｐｅ．ＰｒｏｆｉｌｅＴｉｅｒＬｅｖｅｌ）＊、ここでＮｕｍＣｏｄｅｄＩｍｇは、ＩｔｅｍＴｙｐｅ．ＰｒｏｆｉｌｅＴｉｅｒＬｅｖｅｌ対の異なる値を有することのできるコーデッド入力画像の正の整数であり、対ＩｔｅｍＴｙｐｅ．ＰｒｏｆｉｌｅＴｉｅｒＬｅｖｅｌの数はＮｕｍＣｏｄｅｄＩｍｇに等しい。Ｉｔｅｍ Ｔｙｐｅは、派生画像のために入力されたコード化された画像の４文字アイテム・タイプであり、ＰｒｏｆｉｌｅＴｉｅｒＬｅｖｅｌは、ＲＦＣ６３８１内のＩＳＯベース・メディア・ファイル・フォーマット名前空間のコーデック・パラメータのために規定されたプロファイル・レベル情報である。ＡＶＣおよびＨＥＶＣベースのコーデックについては、ＰｒｏｆｉｌｅＴｉｅｒＬｅｖｅｌのフォーマットは、ＩＳＯ／ＩＥＣ１４４９６−１５内に規定されている。
上述の実施形態のいくつかは、ＨＴＭＬ５．１内の画像ファイル選択の一例によりさらに例示することができ、ここで以下のシンタックスが使用される。
＜ｐｉｃｔｕｒｅ＞
＜ｓｏｕｒｃｅ ｔｙｐｅ＝’’ｉｍａｇｅ／ｍｐｅｇ−ｈ；ｃｏｄｅｃｓ＝ｉｔｅｍ．ｄｉｍｇ．１．１８４３２００．ｈｖｃ１．Ａ１．８０．Ｌ９３．Ｂ０’’ｓｒｃ＝’’ｐｒｅｆｅｒｒｅｄ＿ｉｍｇ．ｈｅｖｃ’’／＞
＜ｉｍｇ ｓｒｃ＝’’ｆａｌｌｂａｃｋ＿ｉｍｇ．ｊｐｇ’’ａｌｔ＝’’Ｆａｌｌｂａｃｋ ｄｅｓｃｒｉｐｔｉｖｅ ｔｅｘｔ’’／＞
＜／ｐｉｃｔｕｒｅ＞
この例においては、同じ画像の２つのコード化された表現、すなわち、第１のファイルｐｒｅｆｅｒｒｅｄ＿ｉｍａｇｅ．ｈｅｖｃおよび第２のファイルｆａｌｌｂａｃｋ＿ｉｍｇ．ｊｐｇが存在する。ファイルｐｒｅｆｅｒｒｅｄ＿ｉｍａｇｅ．ｈｅｖｃは、画像ファイル・フォーマットに適合し、その一次アイテムとして、派生画像を有する。この画像ファイル・フォーマット内で規定される命令セットは、派生画像を構築するために必要とされる。派生画像を構築するために必要とされる累積画素カウントは、２＊１２８０＊７２０であり、これは、例えば１２８０×７２０画素のデコード化された画像が回転させられて派生画像を形成することを標示し得ると考えられる。その上、派生画像は、メイン・ティア、レベル３．１において１つの漸進的なフレーム・パッキングされていないＨＥＶＣ主要プロファイル画像のデコーディングを必要とする。ウェブ・ブラウザは、それが記述された派生画像を構築するための能力およびリソースを有することを条件として、ｐｒｅｆｅｒｒｅｄ＿ｉｍａｇｅ．ｈｅｖｃをダウンロードする。そうでなければ、ウェブ・ブラウザは、ファイルｆａｌｌｂａｃｋ＿ｉｍｇ．ｊｐｇまたは前述のようなｆａｌｌｂａｃｋ ｄｅｓｃｒｉｔｉｖｅ ｔｅｘｔをダウンロードする。
メディア・コンテンツ記述は、（潜在的にＭＩＭＥタイプの任意のパラメータを含む）ＭＩＭＥタイプ；上述のようなＨＴＭＬ５．１のピクチャ・エレメントなどの、埋込み型メディア・コンテンツを記述するエレメントを含むＨＴＭＬページまたはそれに類するもの；先に説明したような、ＭＰＥＧ−ＤＡＳＨのＭＰＤまたはＨＬＳの拡張型Ｍ３Ｕフォーマットなどの、ストリーミング・コンテンツのマニフェスト；および、例えばＲＴＰセッションを確立するために使用できるセッション記述プロトコル（ＳＤＰ）にしたがった記述を非限定的に含めた、メディア・コンテンツのあらゆる記述のための用語として定義することができる。
ファイル・クリエータの動作は、図７に例示されている。この中で、ファイル・クリエータは、１つ以上の入力画像を取得し（７００）、派生画像を取得するために少なくとも１つの入力について行うべき少なくとも１つの動作を決定する（７０２）。ファイル・クリエータは、メディア・コンテンツ記述の中に第１のファイルの第１の記述を内含し（７０４）、ここでこの第１の記述は、少なくとも第１のファイル内に含まれるかまたは第１のファイルによって参照された派生画像の特性を含む。
同様にして、ファイル・クリエータは、派生画像により表現されたもののような対応する画像コンテンツの表現を含む第２のファイルの第２の記述も含むことができる。
上述の実施形態においては、派生画像の構築に必要とされるリソースを表わすリソース・カウントについての実施例が示されていた。しかしながら、一実施形態によると、いかなるリソース・カウント（例えば以上で規定されたＰｉｘｅｌＣｏｕｎｔまたは以上で規定されたＷｉｄｔｈＨｅｉｇｈｔ）も、他のタイプのリソース・カウントにより置換されるかまたは追加で補完されることができる。リソース・カウントについての例示的実施形態が、以下で、ファイル・クリエータおよびファイル内で標示されているリソース・カウントに関連して提供される。しかしながら、コンテンツ・プロバイダなどの他のエンティティおよび／またはファイル内でのリソース・カウントの標示ではなくまたはこの標示に加えてファイルの記述と共にリソース・カウントを標示することと関連しても同様に実施形態を記述することができるということを理解する必要がある。
一実施形態によると、画像ファイルの記述内に派生画像の特性を内含することに加えておよび／またはその代りに、画像ファイル・クリエータは、画像ファイル内に、派生画像を表現するデータ構造を内含し、画像ファイル内に派生画像を編成するために必要なリソースを標示する少なくとも１つの値を内含することができる。
一実施形態において、ファイル内で少なくとも１つの派生画像を編成するために必要なリソースを表わす任意のパラメータを伴うＭＩＭＥタイプが、タイプ内に内含される。必要なリソースを標示するための任意のＭＩＭＥパラメータの実施例は、他の実施形態で先に説明されている。例えば、ＭＩＭＥタイプの文字列を伝達するためにファイル・レベル・ボックスを使用することができる。別の実施例においては、トラック（「ｔｒａｋ」ボックス）および／またはアイテムメタデータには、ＭＩＭＥタイプのそれらのそれぞれの部分を付加することができる。コーデック・パラメータのＬｉｓｔＩｔｅｍを「ｔｒａｋ」ボックス階層内でボックス内に内含させることができる。コーデック・パラメータのＬｉｓｔＩｔｅｍを１つ以上のアイテムについて「メタ」ボックス内に、例えばアイテム情報の付加または新たなボックスの導入により内含させることができる。
必要なリソースを表わす値は、以下のもののうちの１つ以上を含むことができるが、これらに限定されるわけではない。
− 任意の派生画像編成段階において必要とされる最大画素、サンプルおよび／またはバイト・カウント以上の値。
− 派生画像を編成するのに必要とされる任意のピクチャのために必要な最大画素、サンプルおよび／またはバイト・カウント以上の値。ここで、派生画像を編成するのに必要とされるピクチャには派生画像を編成するための中間動作の出力ピクチャが含まれる。
− 派生画像を編成する上で使用することのできる動作タイプ・セットを識別するための識別子。一方、動作タイプ・セット内に含まれていない動作タイプは派生画像の編成において使用されない。
一実施形態によると、ファイル・クリエータは、以下の１つ以上のステップを用いて動作できる。
− ファイル・クリエータは、ファイル内に派生画像を編成するための画像動作の順序を標示する。
− （派生画像を編成するための）各画像動作について、ファイル・クリエータは、どの入力ピクチャおよび（先の画像動作の結果として得られた）どの中間ピクチャがこの画像動作または後続する任意の画像動作のために必要とされるかを決定する。ファイル・クリエータは、メモリ内にこれらの所要ピクチャを記憶または保持するのに必要な一定のリソース・タイプの累積的リソース・カウントを決定する。リソース・タイプは、例えば、画素数、サンプル数またはバイト数であることができる。
− ファイル・クリエータは、（派生画像を編成するための）全ての画像動作の累積的リソース・カウントの最大値を選択する。最大値以上の１つの値を、派生画像を編成するために必要なリソースの標示値として、ファイル内に内含させることができる。
一実施形態によると、ファイル・クリエータは、以下の１つ以上のステップを用いて動作することができる。
（０から画像動作のＮｕｍＯｐｅｒａｔｉｏｎｓの数マイナス−１以下までの範囲内のｉの各値について）画像動作Ｏｐｅｒａｔｉｏｎ［ｉ］は、公称処理順でファイル・クリエータにより、画像動作Ｏｐｅｒａｔｉｏｎ［ｉ］がｉの昇順で処理されるように順序付けされ、動作［ｊ］は、ｉ＞ｊとなるような何らかの動作Ｏｐｅｒａｔｉｏｎ［ｉ］に依存するものではない。ファイル・クリエータは、例えば派生画像のデータ構造内でｉの昇順で画像動作Ｏｐｅｒａｔｉｏｎ［ｉ］を内含することによって、ファイル内に画像動作の順序を標示する。公称処理順序以外の順序で画像動作を処理することも可能である場合があるが、リソース・カウントは公称順序を用いて導出されるということが指摘される。
入力画像ＩｎｐｕｔＩｍａｇｅ［ｊ］を、０から入力画像数ＮｕｍＩｎｐｕｔＩｍａｇｅｓマイナス１（これを含む）までの範囲内のｊの全ての値について画像動作に「外部的に」提供される（すなわち画像動作により作成されたのでない）入力画像であるとする。
中間画像ＩｎｔｅｒｍｅｄｉａｔｅＩｍａｇｅ［ｉ］［ｊ］を、０から出力動作Ｏｐｅｒａｔｉｏｎ［ｉ］の出力画像数ＮｕｍＯｐｅｒＯｕｔｐｕｔＩｍａｇｅｓ［ｉ］マイナス１（これを含む）までの範囲内のｊの全ての値についての画像動作Ｏｐｅｒａｔｉｏｎ［ｉ］の出力であるとする。
リソース・カウントＩｎｔｅｒｍｅｄｉａｔｅＩｍａｇｅＲｅｓｏｕｒｃｅＣｏｕｎｔ［ｉ］［ｊ］は、０から出力画像数ＮｕｍＯｐｅｒＯｕｔｐｕｔＩｍａｇｅｓ［ｉ］−１（これを含む）までの範囲内のｊの全ての値について０からＮｕｍＯｐｅｒａｔｉｏｎ−１（これを含む）までの範囲内のｉの各値についての各インターメディア画像ＩｎｔｅｒｍｅｄｉａｔｅＩｍａｇｅ［ｉ］［ｊ］について、別個に導出することができる。
同様にして、リソース・カウントＩｎｐｕｔＩｍａｇｅＲｅｓｏｕｒｃｅＣｏｕｎｔ［ｊ］は、０からＮｕｍＩｎｐｕｔＩｍａｇｅｓ−１（これを含む）までの範囲内のｊの各値について、導出することができる。
画像のアクティブ・ピクチャ・セットＡｃｔｉｖｅＳｅｔ［ｉ］が以下の画像から成るものとする。
ｉからＮｕｍＯｐｅｒａｔｉｏｎｓ−１（これを含む）までの範囲内のｋの任意の値について任意の画像動作Ｏｐｅｒａｔｉｏｎ［ｋ］に対する入力としてＩｎｐｕｔＩｍａｇｅ［ｍ］が使用されるような、０からＮｕｍＩｎｐｕｔＩｍａｇｅｓ−１（これを含む）までの範囲内のｍの任意の値についての入力画像ＩｎｐｕｔＩｍａｇｅ［ｍ］。
ｉからＮｕｍＯｐｅｒａｔｉｏｎｓ−１（これを含む）までの範囲内のｋの任意の値についての任意の画像動作Ｏｐｅｒａｔｉｏｎｓ［ｋ］に対する入力としてＩｎｔｅｒｍｅｄｉａｔｅＩｍａｇｅ［ｍ］［ｎ］が使用されるような、０からｉ−１（これを含む）までの範囲内のｍの任意の値について、および０からＮｕｍＯｐｅｒＯｕｔｐｕｔＩｍａｇｅｓ［ｍ］−１（これを含む）までの範囲内のｎの任意の値についての、中間画像ＩｎｔｅｒｍｅｄｉａｔｅＩｍａｇｅ［ｍ］［ｎ］。
０からＮｕｍＯｐｅｒＯｕｔｐｕｔＩｍａｇｅｓ［ｉ］−１（これを含む）までの範囲内のｎの任意の値についての中間画像ＩｎｔｅｒｍｅｄｉａｔｅＩｍａｇｅ［ｉ］［ｊ］。
リソース・カウントＡｃｔｉｖｅＳｅｔＲｅｓｏｕｒｃｅＣｏｕｎｔ［ｉ］は、アクティブ・ビクチャ・セットＡｃｔｉｖｅＳｅｔ［ｉ］内のピクチャのリソース・カウントの合計として、０からＮｕｍＯｐｅｒａｔｉｏｎｓ−１（これを含む）までの範囲内のｉについて各々のアクティブ・ビクチャ・セットＡｃｔｉｖｅＳｅｔ［ｉ］のために導出することができる。
最大累積リソース・カウントＭａｘＣｕｍｕｌａｔｉｖｅＲｅｓｏｕｒｃｅＣｏｕｎｔは、０からＮｕｍＯｐｅｒａｔｉｏｎｓ−１（これを含む）までの範囲内のｉについてのＡｃｔｉｖｅＳｅｔＲｅｓｏｕｒｃｅＣｏｕｎｔ［ｉ］の最大値に等しく設定することができる。
一実施形態によると、最大個別リソース・カウントＭａｘＲｅｓｏｕｒｃｅＣｏｕｎｔは、０からＮｕｍＩｎｐｕｔＩｍａｇｅｓ−１（これを含む）までの範囲内のｋの任意の値についてＩｎｐｕｔＩｍａｇｅＲｅｓｏｕｒｃｅＣｏｕｎｔ［ｋ］の最大値に等しく、または、０からＮｕｍＯｐｅｒａｔｉｏｎｓ−１（これを含む）までの範囲内の任意の値および０から出力画像数ＮｕｍＯｐｅｒＯｕｔｐｕｔＩｍａｇｅｓ［ｉ］−１（これを含む）までの範囲内のｊの任意の値について、ＩｎｔｅｒｍｅｄｉａｔｅＩｍａｇｅＲｅｓｏｕｒｃｅＣｏｕｎｔ［ｉ］［ｊ］の最大値に等しく設定することができる。代替的実施形態においては、最大個別リソース・カウントＭａｘＲｅｓｏｕｒｃｅＣｏｕｎｔは、０からＮｕｍＯｐｅｒａｔｉｏｎｓ−１（これを含む）までの範囲内のｉの任意の値について、および０から出力画像数ＮｕｍＯｐｅｒＯｕｔｐｕｔＩｍａｇｅｓ［ｉ］−１（これを含む）までの範囲内のｊの任意の値について、ＩｎｔｅｒｍｅｄｉａｔｅＩｍａｇｅＲｅｓｏｕｒｃｅＣｏｕｎｔ［ｉ］［ｊ］の最大値に等しく設定することができる。
一実施形態によると、ファイル・クリエータは、
− ＭａｘＣｕｍｕｌａｔｉｖｅＲｅｓｏｕｒｃｅＣｏｕｎｔ以上となるべき、必要なリソースを標示する第１の値、
− ＭａｘＲｅｓｏｕｒｃｅＣｏｕｎｔ以上となるべき、必要なリソースを標示する第２の値、
のうちの少なくとも１つを設定することができる。
必要なリソースを標示する値を提供することのできるリソース・タイプには１つ以上のタイプが存在する可能性がある。異なるリソース・タイプについてリソース・カウントＲｅｓｏｕｒｃｅＣｏｕｎｔを導出するいくつかの非限定的な例が以下で提供されており、ここでＲｅｓｏｕｒｃｅＣｏｕｎｔは、単一の画像から（したがって、実際にＩｎｐｕｔＩｍａｇｅＲｅｓｏｕｒｃｅＣｏｕｎｔ［］またはＩｎｔｅｒｍｅｄｉａｔｅＩｍａｇｅＲｅｓｏｕｒｃｅＣｏｕｎｔ［］［］のうちの一方であり得ると考えられる）または画像セットから（したがって実際にＡｃｔｉｖｅＳｅｔＲｅｓｏｕｒｃｅＣｏｕｎｔ［］であり得ると考えられる）導出することができる。
− 画素数、すなわち画像または画像セットの全てのサンプル・アレイのうちの最高のサンプル・カウントのサンプル・アレイ内のサンプルの数。
− サンプル数、すなわち画像または画像セットの全てのサンプル・アレイ内のサンプルの数。
− メモリ・ユニットの数、例えば画像または画像セットを記憶するために必要とされるバイト数。メモリ・ユニットの数は、ファイル内に必要とされるメモリ・ユニットの値に沿って標示されるか、または予め定義されることのできる、サンプル・アレイ配置との関係において標示することができる。サンプル・アレイ配置は、以下のもののうちの１つであることができるが、これに限定されない。
○ サンプルは別個のバイト中に記憶される。サンプルのビット深度が８の倍数でない場合、サンプルは、次に大きい整数のバイトを占めるものと仮定される。例えば、サンプルのビット深度が１０である場合、サンプルは２バイトを占有するものと仮定される。異なる色構成要素のビット深度は異なる可能性があることが指摘される。例えば、ルマ構成要素は１０ビットのビット深さを有することができ、一方クロマ構成要素は８ビットのビット深度を有することができる。
○ 異なる色構成要素のコロケートされたサンプルが、整数のバイトにパッキングされる。例えば、サンプルのビット深度が１０であり、クロマ・フォーマットが４：４：４である場合、コロケートされたＹ、ＵおよびＶサンプルの各セットは、４つのバイトにパッキングされた３０ビットを割り振るものと仮定される。
一実施形態によると、ファイル・クリエータは、次のもののうちの少なくとも１つを設定することができる。
− ＭａｘＣｕｍｕｌａｔｉｖｅＲｅｓｏｕｒｃｅＣｏｕｎｔ以上であるべき必要とされるリソースを標示する第１の値セット。ここでこのセット内の各エレメントは異なるリソース・タイプに対応する。エレメント・タイプは、例えばファイル・フォーマット規格内に予め定義されることができ、またはファイル内に標示されることができる。
− ＭａｘＲｅｓｏｕｒｃｅＣｏｕｎｔ以上であるべき必要とされるリソースを標示する第２の値。ここで、このセット内の各エレメントは異なるリソース・タイプに対応する。エレメント・タイプは、例えばファイル・フォーマット規格内に予め定義されることができ、またはファイル内に標示されることができる。
リソース・カウントについての例示的実施形態が、以下に、ファイル・プレーヤーおよびファイルからパースされつつあるリソース・カウントとの関係において提供される。ただし、ウェブ・ブラウザなどの他のエンティティおよび／またはファイルの記述からのリソース・カウントのパースとの関係において同様に実施形態を記述することができるということを理解する必要がある。
一実施形態によると、画像ファイルの記述から派生画像の特性をパースすることに加えて、またはその代りに、画像ファイル・プレーヤーは、画像ファイルから、派生ピクチャを編成するための必要なリソースを標示する少なくとも１つの値をパースし、少なくとも１つの値に基づいて、派生ピクチャを編成できるか否かを決定する。
一実施形態によると、ファイル・プレーヤーは、以下のステップの１つ以上を行うことができる。
− ファイル・プレーヤーは、派生画像を編成するために、必要とされるリソースをパースする。
− ファイル・プレーヤーは、少なくとも１つの値に基づいて、自らが派生画像を編成する能力を有するか否かを決定する。
ファイル・プレーヤーは、派生画像を編成する能力を有することを決定した場合、派生画像を表現するデータ構造をパースし、このデータ構造は少なくとも１つの動作の有向非巡回グラフを定義し；ファイル・プレーヤーは少なくとも１つの動作の有向非巡回グラフを実行することによって派生画像を編成する。
さらに、ファイル・プレーヤーは以下のステップを行うことができる。
− ファイル・プレーヤーは、ファイルから、派生画像を編成するための画像動作の実行順序をパースする。
− 画像動作毎の実行順序で画像動作を実行する場合、各画像動作について、
○ ファイル・プレーヤーは、少なくとも１つの動作の入力および出力および実行順序に基づいて、この実行順序内の後続する動作のためにどのピクチャが必要とされるかを決定する。
○ ファイル・プレーヤーは、実行順序内の後続する動作内でもはや必要とされないピクチャを記憶するためにリソースを解放する（例えばピクチャを記憶するためにメモリを割振り解除する）。
以上の実施形態に加えて、イン・プレース画像動作に関する補完的実施形態を行うことができる。一実施形態によると、リソース・カウントにイン・プレース動作を考慮することができる。イン−プレース画像動作は、動作の入力画像および動作の出力画像のために、同じメモリを使用することのできるような画像動作として定義することができる。イン−プレース動作においては、１つ以上の入力画像の１つの画素または画素ブロックなどの非重複入力ウィンドウが、１つ以上の入力画像のそれぞれのウィンドウの出力を生成するために処理される、とみなすことができる。したがって、一定の出力ウィンドウの画素が（ワーキング・メモリ内で）生成されると直ちに、入力ウィンドウ内のそれぞれの画素は、出力ウィンドウのものによって置換され得る。出力ウィンドウの画素が書き重ねられた画素は、処理順序内で後続するウィンドウの処理に影響を及ぼさない。例えば、トーン・マッピング画像動作はイン・プレース画像動作であり得ると考えられる。
例えば既定のイン・プレース画像動作のセットを、ファイル・フォーマット規格の中で定義することができる。
代替的に、または付加的に、ファイル・クリエータは、１つの画像動作がイン・プレース画像動作であるとみなされるか否かを、ファイル内で標示することができる。
リソース・カウントを導出する場合には、ファイル・クリエータは、画像動作の入力画像およびそれぞれの出力画像を表現するために単一画像のみがリソース・カウントの導出において考慮されるように、イン−プレース画像動作を処理することができる。より一般的には、画像動作が多数の入力および出力を有する場合、ファイル・クリエータは、入力画像とそれぞれの出力画像の各対を表現するために１つの単一画像のみがリソース・カウントの導出において考慮されるように、イン・プレース画像動作を処理することができる。いくつかの実施形態において、ファイル・クリエータは、画像動作の入力画像が実行順序内で後続する任意の画像動作として使用されない場合にのみ、イン・プレース画像動作として１つの画像動作を処理する。
画像動作がイン・プレース画像動作であるものとして（ファイル内で）標示されるかまたは予め定義される場合、ファイル・プレーヤーは、相応して、画像動作をイン・プレース画像動作として実行することができる。いくつかの実施形態において、画像動作の入力画像が実行順序内の任意の後続する画像動作に対する入力画像として使用されない場合にのみ、イン・プレース画像動作として１つの画像動作を処理する。
図８は、本発明の実施形態を利用するために好適である映像デコーダのブロック図を示す。図８は、２レイヤ・デコーダの構造を描いているが、デコーディング動作を同様にしてシングル・レイヤ・デコーダ内で利用することもできる、ということが認識されると考えられる。
映像デコーダ５５０は、ベース・ビュー構成要素のための第１のデコーダ・セクション５５２と、非ベース・ビュー構成要素のための第２のデコーダ・セクション５５４とを含む。ブロック５５６は、第１のデコーダ・セクション５５２に対してベース・ビュー構成要素に関する情報を送出するため、および第２のデコーダ・セクション５５４に対して非ベース・ビュー構成要素に関する情報を送出するためのデマルチプレクサを例示する。参照記号Ｐ’ｎは、画像ブロックの予測された表現を表わす。参照記号Ｄ’ｎは、再構築された予測エラー信号を表わす。ブロック７０４、８０４は、予備的再構築画像（Ｉ’ｎ）を例示する。参照記号Ｒ’ｎは、最終的再構築画像を意味する。ブロック７０３、８０３は、逆変換（Ｔ−１）を例示する。ブロック７０２、８０２は、逆量子化（Ｑ−１）を例示する。ブロック７０１、８０１は、エントロピー・デコーディング（Ｅ−１）を例示する。ブロック７０５、８０５は、参照フレーム・メモリ（ＲＦＭ）を例示する。ブロック７０６、８０６は、予測（Ｐ）（インター予測またはイントラ予測のいずれか）を例示する。ブロック７０７、８０７は、フィルタリング（Ｆ）を例示する。ブロック７０８、８０８は、予備的再構築画像（Ｉ’ｎ）を取得するために予測されたベース・ビュー／非ベース・ビュー構成要素とデコーデッド予測エラー情報とを組合わせるために使用することができる。予備的再構築およびフィルタリング済みベース・ビュー画像は、第１のデコーダ・セクション５５２から出力されることができ７０９、予備的な再構築およびフィルタリング済みベース・ビュー画像は、第１のデコーダ・セクション５５４から出力されることができる８０９。
本明細書において、デコーダは、プレーヤ、受信機、ゲートウェイ、デマルチプレクサおよび／またはデコーダなど、デコーディング動作を実施する能力を有するあらゆる動作可能的ユニットをカバーするように解釈されるべきである。
以上では、ＭＩＭＥタイプおよび任意のＭＩＭＥパラメータに関連していくつかの実施形態が説明されてきた。任意のＭＩＭＥパラメータよりむしろ、または任意のＭＩＭＥパラメータに加えて、例えばＭＰＥＧ−ＤＡＳＨのＭＰＤなどのＸＭＬ記述、または他のメディア・コンテンツ記述内の属性といった他のシグナリングを使用することもできる、ということを理解する必要がある。
以上では、ＩＳＯＢＭＦＦに関連していくつかの実施形態を説明してきた。マトロスカなどの他の任意のフォーマットを用いて、ＩＳＯＢＭＦＦ中のものと類似の能力および／または構造を伴って同じ様に実施形態を実現できるということを理解する必要がある。
以上では、プレーヤに関連して、いくつかの実施形態を説明してきた。リーダー、パーサー、ユーザー・エージェント、またはクライアントなど、他の用語を互換的に使用することができるということを理解する必要がある。プレーヤが、独立型アプリケーションであり得るものの必ずそうである必要はない、ということを理解する必要がある。プレーヤを、例えば、ウェブ・ブラウザ内に埋め込むことが可能である。
以上では、プレーヤに関連していくつかの実施形態を説明してきた。画像ファイルが再生または表示されず他の目的で取出される場合に、実施形態を同じ様に実現できる、ということを理解する必要がある。一実施形態においては、プロキシ・キャッシュが第１のファイルの第１の記述を受信し、この第１の記述は、第１のファイル内に内含されるかまたはこの第１のファイルにより参照された少なくとも１つの派生画像の特性を含む。プロキシ・キャッシュは、派生画像の特性および１つ以上のクライアントの能力についての知識に基づいて、派生画像を取得すべきか否かを決定し、派生画像を取得するとの決定に応答して、派生画像を含む第１のファイルを取得する。一実施形態によると、プロキシ・キャッシュはさらに、派生画像により表現されているもののような対応する画像コンテンツの表現を含む第２のファイルの第２の記述をさらに受信することができ；派生画像および第２の記述の特性ならびに１つ以上のクライアントの能力についての知識に基づいて、第１のファイルまたは第２のファイルを取得すべきか否かを決定することができる。次に、プレーヤは、第１のファイルまたは第２のファイルのいずれかを取得する。
以上では、ファイル・クリエータに関連していくつかの実施形態を説明してきた。ライター、ファイル・ジェネレーターまたはコンテンツ・プロバイダなど、他の用語を互換的に使用することができるということを理解する必要がある。クリエーターが、独立型アプリケーションであり得るものの必ずしもそうである必要はないということを理解する必要がある。クリエーターは、例えばスクリプトを用いて、ウェブ・サーバー内に埋込むことができる。
以上では、例示的実施形態がエンコーダに関連して説明されている場合、結果として得られるビットストリームおよびデコーダがその内部に対応するエレメントを有することができるということを理解する必要がある。同様に、例示的実施形態がデコーダに関連して説明されている場合、エンコーダは、デコーダによってデコーディングされるべきビットストリームを生成するための構造および／またはコンピュータ・プログラムを有することができるということを理解する必要がある。
以上で説明した本発明の実施形態は、関与するプロセスの理解を助ける目的で別個のエンコーダとデコーダ装置の観点からコーデックを説明している。しかしながら、装置、構造および動作を単一のエンコーダ・デコーダ装置／構造／動作として実装することもできるということが認識されると考えられる。さらに、コーダーおよびデコーダがいくつかのまたは全ての共通エレメントを共有できることも可能である。
上述の実施例は、電子デバイス内部のコーデック内で動作する本発明の実施形態を説明しているものの、クレーム中に定義された本発明を任意の映像コーデックの一部として実装することができる。したがって、例えば、本発明の実施形態を、固定のまたは有線の通信経路上で映像コーディングを実施できる映像コーデックの形で実装することができる。
こうして、ユーザー機器は、上述の発明の実施形態内に説明されたものなどの映像コーデックを備えることができる。ユーザー機器なる用語は、携帯電話、ポータブル・データ処理デバイスまたはポータブル・ウェブ・ブラウザなどの任意の好適なタイプの無線ユーザー機器をカバーするよう意図されているということが認識されるものである。
さらに、地上波公共移動通信ネットワーク（ＰＬＭＮ）のエレメントも同様に、上述のような映像コーデックを備えることができる。
一般に、本発明のさまざまな実施形態は、ハードウェアまたは専用回路、ソフトウェア、論理またはそれらの任意の組合せの形で実装することができる。例えば、いくつかの態様をハードウェアで実装し、一方他の態様を、コントローラ、マイクロプロセッサまたは他の計算用デバイスによって実行できるファームウェアまたはソフトウェアの形で実装することができるが、本発明はそれらに限定されない。本発明のさまざまな態様をブロック図、流れ図として、またはいくつかの他の絵画的表現を用いて例示および説明することができるものの、本明細書中に記載のこれらのブロック、装置、システム、技術または方法は、非限定的な例として、ハードウェア、ソフトウェア、ファームウェア、専用回路または論理、汎用ハードウェアまたはコントローラまたは他の計算用デバイスまたはそれらの組合せの形で実装できるものである、ということは充分理解されている。
本発明の実施形態は、プロセッサ・エンティティ内などの移動体デバイスのデータ・プロセッサによって実行可能なコンピュータ・ソフトウェアによって、またはハードウェアによって、あるいはソフトウェアとハードウェアの組合せによって実装可能である。さらに、この点に関して、図中にあるような倫理の流れのブロックはいずれも、プログラム・ステップ、または相互接続された論理回路、ブロックおよび機能、またはプログラム・ステップおよび論理回路、ブロックおよび機能の組合せを表わすことができるということを指摘しておかなければならない。ソフトウェアは、メモリ・チップまたはプロセッサ内に実装されたメモリ・ブロックなどの物理的媒体、ハード・ディスクまたはフロッピー・ディスクなどの磁気媒体、および例えばＤＶＤおよびそのデータ改良型であるＣＤなどの光学媒体上に記憶することができる。
メモリは、現地の技術的環境に好適な任意のタイプのものであることができ、半導体ベースのメモリ・デバイス、磁気メモリ・デバイスおよびシステム、光学メモリ・デバイスおよびシステム、固定メモリおよび着脱式メモリなどの、任意の好適な記憶技術を用いて実装可能である。データ・プロセッサは、現地の技術的環境に好適な任意のタイプのものであることができ、非限定的な例として汎用コンピュータ、専用コンピュータ、マイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）およびマルチコア・プロセッサ・アーキテクチャに基づくプロセッサなどの１つ以上を含むことができる。
本発明の実施形態は、集積回路モジュールなどのさまざまな構成要素の形で実施することができる。集積回路の設計は、概して高度に自動化されたプロセスである。論理レベルの設計を、半導体基板上に直ちにエッチングし形成できる状態の半導体回路設計へと変換するために複雑かつ強力なソフトウェア・ツールが利用可能である。
カリフォルニア州マウンテン・ヴューのＳｙｎｏｐｓｙｓ，Ｉｎｃ．およびカリフォルニア州サン・ホセのＣａｄｅｎｃｅ Ｄｅｓｉｇｎ社により提供されているソフトウェア・ツールなどのプログラムが、確立した設計ルールならびに予め記憶された設計モジュールのライブラリを用いて、導体を配線し半導体チップ上に構成要素を配置する。半導体回路用の設計がひとたび完了した時点で、半導体製造施設つまり「Ｆａｂｒｉｃａｔｉｏｎ（製造）」を略して「ｆａｂ」に対して、規格化された電子フォーマット（例えばＯｐｕｓ、ＧＤＳＩＩ、など）の形で、結果として得られた設計を伝送することができる。
上の記載は、例示的な非限定的例によって、本発明の例示的実施形態の完全かつ有益な記述を提供している。しかしながら、当業者には、添付図面および添付のクレームと併せて以上の説明を読んで考慮すると、種々の修正および適応が明らかとなる可能性がある。しかしながら、本発明の教示についてのこのようなおよび類似の修正は、依然として本発明の範囲内に入るものである。

Claims (16)

  1. 第１のファイルの第１の記述であって、前記第１の記述は、前記第１のファイル内に含まれる、派生画像の特性を含む、第１の記述を受信し、
    ここで、前記派生画像は、少なくとも１つの指示されたコード化画像の上で実行される少なくとも１つの動作によって定義され、
    前記派生画像の特性を含む前記第１の記述は、
    前記派生画像に対して、前記少なくとも１つの指示されたコード化画像の上で実行される前記少なくとも１つの動作を特定する命令セットの識別、
    前記派生画像に対する前記少なくとも１つの指示されたコード化画像のコーデックおよびコーデック・プロファイルの識別、および、
    前記派生画像の構築のために必要なリソースを表わすリソース・カウント、
    のうちの少なくとも１つを含み、
    前記派生画像の前記特性を含む前記第１の記述に基づいて、前記派生画像を取得すべきか否かを決定する
    ように構成される装置であって、
    前記装置が、前記派生画像を取得すると決定するように構成されることに応答して、前記装置は、前記派生画像を含む前記第１のファイルを取得するように更に構成される、装置。
  2. 前記第１の記述は、多目的インターネット・メール拡張（ＭＩＭＥ）タイプを含む、請求項１に記載の装置。
  3. 前記第１のファイルから、派生画像を編成するための、前記必要なリソースを標示する少なくとも１つの値をパースし、
    少なくとも１つの値に基づいて、前記派生画像が編成され得るか否かを決定するように更に構成される、請求項１に記載の装置。
  4. １つ以上のコード化画像を取得し、
    派生画像を取得するために少なくとも１つのコード化画像上で行われるべき少なくとも１つの動作を決定し、
    第１のファイルの第１の記述を、メディア・コンテンツ記述内に含めるように構成される装置であって、
    前記第１の記述は、前記第１のファイル内に含まれる、少なくとも前記派生画像の特性を含み、
    ここで、前記派生画像は、少なくとも１つの指示されたコード化画像の上で実行される少なくとも１つの動作によって定義され、
    前記派生画像の特性を含む前記第１の記述は、
    前記派生画像に対して、前記少なくとも１つの指示されたコード化画像の上で実行される前記少なくとも１つの動作を特定する命令セットの識別、
    前記派生画像に対する前記少なくとも１つの指示されたコード化画像のコーデックおよびコーデック・プロファイルの識別、および、
    前記派生画像の構築のために必要なリソースを表わすリソース・カウント、
    のうちの少なくとも１つを含む、
    装置。
  5. 前記第１の記述は、多目的インターネット・メール拡張（ＭＩＭＥ）タイプを含む、請求項４に記載の装置。
  6. 前記第１のファイルに、前記派生画像を表現するデータ構造を含め、
    前記第１のファイルに、前記派生画像を編成するための、前記必要なリソースを標示する少なくとも１つの値を含めるように更に構成される、請求項４に記載の装置。
  7. 前記必要なリソースを標示する値は、
    前記派生画像を編成する任意の段階において必要な、最大の画素、サンプルおよび／またはバイト・カウント以上の値、
    前記派生画像を編成するのに必要な任意の画像のために必要な最大の画素、サンプルおよび／またはバイト・カウント以上の値であって、前記派生画像を編成するのに必要な画像が、前記派生画像を編成するための中間動作の出力画像を含む、値、
    前記派生画像を編成するのに使用できる動作タイプのセットを識別するための識別子であって、その一方で、前記動作タイプ・セットに含まれていない動作タイプは、前記派生画像の編成で使用されない、識別子、
    のうちの１つ以上を含む、請求項６に記載の装置。
  8. 第１のファイルの第１の記述を受信するステップであって、該第１の記述は、前記第１のファイル内に含まれる派生画像の特性を含み、
    ここで、前記派生画像は、少なくとも１つの指示されたコード化画像の上で実行される少なくとも１つの動作によって定義され、
    前記派生画像の特性を含む前記第１の記述は、
    前記派生画像に対して、前記少なくとも１つの指示されたコード化画像の上で実行される前記少なくとも１つの動作を特定する命令セットの識別、
    前記派生画像に対する前記少なくとも１つの指示されたコード化画像のコーデックおよびコーデック・プロファイルの識別、および、
    前記派生画像の構築のために必要なリソースを表わすリソース・カウント、
    のうちの少なくとも１つを含む、ステップと、
    前記派生画像の前記特性を含む前記第１の記述に基づいて、前記派生画像を取得すべきか否かを決定するステップと、
    前記派生画像を取得するとの決定に応答して、前記派生画像を含む前記第１のファイルを取得するステップと、を含む方法。
  9. 前記第１の記述は、多目的インターネット・メール拡張（ＭＩＭＥ）タイプを含む、請求項８に記載の方法。
  10. 前記第１のファイルから、派生画像を編成するための、必要なリソースを標示する少なくとも１つの値をパースするステップと、
    少なくとも１つの値に基づいて、前記派生画像が編成され得るか否かを決定するステップと、を更に含む請求項８に記載の方法。
  11. １つ以上のコード化入力画像を取得するステップと、
    派生画像を取得するために少なくとも１つのコード化入力画像上で行われるべき少なくとも１つの動作を決定するステップと、
    第１のファイルの第１の記述を、メディア・コンテンツ記述内に含めるステップであって、前記第１の記述は、前記第１のファイル内に含まれる、少なくとも前記派生画像の特性を含み、
    ここで、前記派生画像は、少なくとも１つの指示されたコード化画像の上で実行される少なくとも１つの動作によって定義され、
    前記派生画像の特性を含む前記第１の記述は、
    前記派生画像に対して、前記少なくとも１つの指示されたコード化画像の上で実行される前記少なくとも１つの動作を特定する命令セットの識別、
    前記派生画像に対する前記少なくとも１つの指示されたコード化画像のコーデックおよびコーデック・プロファイルの識別、および、
    前記派生画像の構築のために必要なリソースを表わすリソース・カウント、
    のうちの少なくとも１つを含む、ステップと、
    を含む方法。
  12. 前記第１の記述は、多目的インターネット・メール拡張（ＭＩＭＥ）タイプを含む、請求項１１に記載の方法。
  13. 前記第１のファイルに、派生画像を表現するデータ構造を含めるステップと、
    前記第１のファイルに、派生画像を編成するための、前記必要なリソースを標示する少なくとも１つの値を含めるステップと、
    をさらに含む、請求項１１に記載の方法。
  14. 前記必要なリソースを標示する値は、
    前記派生画像を編成する任意の段階において必要な、最大の画素、サンプルおよび／またはバイト・カウント以上の値、
    前記派生画像を編成するのに必要な任意の画像のために必要な最大の画素、サンプルおよび／またはバイト・カウント以上の値であって、前記派生画像を編成するのに必要な画像が、前記派生画像を編成するための中間動作の出力画像を含む、値、
    前記派生画像を編成するのに使用できる動作タイプのセットを識別するための識別子であって、その一方で、前記動作タイプ・セットに含まれていない動作タイプは、前記派生画像の編成で使用されない、識別子、
    のうちの１つ以上を含む、
    請求項１３に記載の方法。
  15. 装置による使用のためにコンピュータ・コードを備えるコンピュータ・プログラムであって、該コンピュータ・コードは、プロセッサによって実行された場合に、該装置に、請求項８ないし１０のいずれか１項に記載の方法を実行させる、コンピュータ・プログラム。
  16. 装置による使用のためにコンピュータ・コードを備えるコンピュータ・プログラムであって、該コンピュータ・コードは、プロセッサによって実行された場合に、該装置に、請求項１１ないし１４のいずれか１項に記載の方法を実行させる、コンピュータ・プログラム。
JP2017559922A 2015-02-09 2016-02-02 画像コーディング・デコーディングのための装置、方法およびコンピュータ・プログラム Active JP6649404B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US14/617,266 2015-02-09
US14/617,266 US10291561B2 (en) 2015-02-09 2015-02-09 Apparatus, a method and a computer program for image coding and decoding
PCT/FI2016/050063 WO2016128612A1 (en) 2015-02-09 2016-02-02 An apparatus, a method and a computer program for image coding and decoding

Publications (2)

Publication Number Publication Date
JP2018510595A JP2018510595A (ja) 2018-04-12
JP6649404B2 true JP6649404B2 (ja) 2020-02-19

Family

ID=56567195

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2017559922A Active JP6649404B2 (ja) 2015-02-09 2016-02-02 画像コーディング・デコーディングのための装置、方法およびコンピュータ・プログラム

Country Status (7)

Country Link
US (1) US10291561B2 (ja)
EP (1) EP3257244B1 (ja)
JP (1) JP6649404B2 (ja)
KR (1) KR101949071B1 (ja)
CN (1) CN107431810B (ja)
WO (1) WO2016128612A1 (ja)
ZA (1) ZA201705953B (ja)

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016015009A (ja) * 2014-07-02 2016-01-28 ソニー株式会社 情報処理システム、情報処理端末、および情報処理方法
US20160277767A1 (en) * 2015-03-16 2016-09-22 Thomson Licensing Methods, systems and apparatus for determining prediction adjustment factors
GB2538997A (en) * 2015-06-03 2016-12-07 Nokia Technologies Oy A method, an apparatus, a computer program for video coding
WO2016204712A1 (en) * 2015-06-16 2016-12-22 Intel IP Corporation Adaptive video content for cellular communication
WO2018041244A1 (en) * 2016-09-02 2018-03-08 Mediatek Inc. Incremental quality delivery and compositing processing
US10652553B2 (en) * 2016-12-07 2020-05-12 Qualcomm Incorporated Systems and methods of signaling of regions of interest
GB2560921B (en) 2017-03-27 2020-04-08 Canon Kk Method and apparatus for encoding media data comprising generated content
US10924822B2 (en) 2017-04-04 2021-02-16 Qualcomm Incorporated Segment types as delimiters and addressable resource identifiers
US10560726B2 (en) * 2017-07-26 2020-02-11 CodeShop BV System and method for delivery and caching of personalized media streaming content
CN110545456B (zh) * 2018-05-29 2022-04-01 北京字节跳动网络技术有限公司 媒体文件的同步播放方法、装置及存储介质
CN108876882A (zh) * 2018-06-26 2018-11-23 史艳艳 一种画面非循环的gif文件播放方法及系统
JP2022501891A (ja) * 2018-09-20 2022-01-06 ノキア テクノロジーズ オーユー 人工知能についての装置及び方法
JP7303625B2 (ja) * 2018-12-18 2023-07-05 キヤノン株式会社 画像ファイル生成装置、画像ファイル生成方法、及びプログラム
GB2585052B (en) * 2019-06-26 2023-07-26 Canon Kk Method and apparatus for encapsulating panorama images in a file
CN114072847A (zh) * 2019-07-01 2022-02-18 佳能株式会社 图像文件创建设备、图像文件创建方法和程序
US11172232B2 (en) * 2019-09-06 2021-11-09 Sharp Kabushiki Kaisha Systems and methods for signaling level information in video coding
WO2021140274A1 (en) * 2020-01-07 2021-07-15 Nokia Technologies Oy A method, an apparatus and a computer program product for video encoding and video decoding
US11671627B2 (en) * 2020-09-17 2023-06-06 Lemon Inc. Operating point entity group signaling in coded video

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004235739A (ja) 2003-01-28 2004-08-19 Sony Corp 情報処理装置、および情報処理方法、並びにコンピュータ・プログラム
CN1939060B (zh) * 2004-02-10 2010-09-29 汤姆逊许可公司 一种用于促进视频信息的流式传输的方法和设备
CN1812583A (zh) * 2005-09-22 2006-08-02 上海广电（集团）有限公司中央研究院 块组编码结构及基于该结构的自适应分阶段预测编码方法
US8949737B2 (en) * 2009-10-28 2015-02-03 Red Hat, Inc. Centralized application package distribution
KR101404251B1 (ko) 2010-09-10 2014-06-09 한국전자통신연구원 컨텐츠의 부가서비스 정보를 보조 단말기에 표시하는 시스템 및 방법
EP2696578A4 (en) 2011-03-25 2014-08-20 Nec Corp VIDEO PROCESSING SYSTEM, VIDEO PROCESSING METHOD, VIDEO PROCESSING DEVICE, CONTROL PROCESS AND MEMORY FOR STORING A CONTROL PROGRAM
EP2987326B1 (en) 2013-04-17 2020-09-02 Nokia Technologies Oy An apparatus, a method and a computer program for video coding and decoding

Also Published As

Publication number Publication date
EP3257244A4 (en) 2018-10-17
ZA201705953B (en) 2019-09-25
EP3257244A1 (en) 2017-12-20
JP2018510595A (ja) 2018-04-12
CN107431810B (zh) 2020-06-05
KR20170116089A (ko) 2017-10-18
KR101949071B1 (ko) 2019-02-15
US20160234144A1 (en) 2016-08-11
CN107431810A (zh) 2017-12-01
US10291561B2 (en) 2019-05-14
WO2016128612A1 (en) 2016-08-18
EP3257244B1 (en) 2022-07-27

Similar Documents

Publication Publication Date Title
JP6649404B2 (ja) 画像コーディング・デコーディングのための装置、方法およびコンピュータ・プログラム
US11962793B2 (en) Apparatus, a method and a computer program for video coding and decoding
KR102089457B1 (ko) 비디오 코딩 및 디코딩을 위한 장치, 방법 및 컴퓨터 프로그램
KR102613593B1 (ko) 필수 및 비필수 비디오 보충 정보의 시그널링
CN112673638B (zh) 处理媒体数据的方法和装置
KR20220087577A (ko) 비디오 코딩 및 디코딩을 위한 장치, 방법 및 컴퓨터 프로그램
US10575010B2 (en) Apparatus, a method and a computer program for image sequence coding and decoding
WO2017140946A1 (en) An apparatus, a method and a computer program for video coding and decoding
US20240040131A1 (en) A method, an apparatus and a computer program product for video encoding and video decoding
EP4266690A1 (en) An apparatus, a method and a computer program for video coding and decoding

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20171006

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20171006

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20180626

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20180925

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20181119

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20190205

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20190425

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20190705

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20191217

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20200116

R150 Certificate of patent or registration of utility model

Ref document number: 6649404

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250