(57)【要約】  本開示の技法は、ビットストリームの部分においてパラメータセットの更新が起こり得るかどうかの指示を可能にする。この指示は、ビデオデコーダに、記憶されたパラメータセットと、同じタイプであるとともに同じ識別値をもつ新たなパラメータセットとの間の内容比較を実行せずに、記憶されたパラメータセットの更新が起こり得るかどうか判断することを可能し得る。パラメータセットの更新は、同じタイプであるとともに同じ識別値を有する前のパラメータセットを置き換えるために、所与の識別値をもつ現在のパラメータセットを記憶することを含む。パラメータセットの更新が起こり得ないとき、ビデオデコーダは、ビットストリームの部分全体について、所与のタイプの単一のパラメータセットを記憶し、アクティブ化し得る。パラメータセットの更新が起こり得るとき、ビデオデコーダは、記憶されたパラメータセットを自動的に更新することができ、記憶されたパラメータを更新するかどうか判断し得る。
2015515239.tif 000002
【特許請求の範囲】
【請求項１】
ビデオデータを復号する方法であって、
ビットストリームの部分においてパラメータセットの更新が起こり得るかどうかを示すインジケータを復号することを備え、ここで、パラメータセットの更新が、特定のタイプの、かつ特定の識別値を有する現在のパラメータセットが、同じタイプの、かつ同じ識別値を有する前のパラメータセットの内容とは異なる内容を有する場合に起こる、方法。
【請求項２】
前記インジケータに基づいて、１つまたは複数のタイプのパラメータセットについて、前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得るかどうか判断することをさらに備える、請求項１に記載の方法。
【請求項３】
前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得ないことを示す前記インジケータに基づいて、
前記ビットストリームの前記部分全体に対して、特定の識別値をもつ特定のタイプの第１のパラメータセットをアクティブ化することと、
前記ビットストリームの前記部分全体についての前記第１のパラメータセットを更新しないために、前記ビットストリームの前記部分全体において、前記第１のパラメータセットと同じタイプの、かつ同じ識別値を有する他のパラメータセットを無視することと、前記第１のパラメータセットが、前記他のパラメータセットより前のものである、を備える、請求項１に記載の方法。
【請求項４】
前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得ることを示す前記インジケータに基づいて、
特定の識別値をもつ特定のタイプの第１のパラメータセットをアクティブ化することと、
前記第１のパラメータセットと同じタイプの、かつ同じ識別値を有する第２のパラメータセットを受信することと、前記第１のパラメータセットが、前記第２のパラメータセットより前のものである、
前記第２のパラメータセットを記憶して前記第１のパラメータセットを置き換えるための前記パラメータセットの更新を実行するかどうか判断することとをさらに備える、請求項１に記載の方法。
【請求項５】
前記パラメータセットの更新を実行するかどうか判断することが、
前記第２のパラメータセットの内容を前記第１のパラメータセットの内容と比較することと、
前記第２のパラメータセットの前記内容が前記第１のパラメータセットの前記内容とは異なることに基づいて、前記ビットストリームの前記部分について、前記第１のパラメータセットを非アクティブ化し、かつ前記第２のパラメータセットをアクティブ化するために、前記パラメータセットの更新を実行することとをさらに備える、請求項４に記載の方法。
【請求項６】
前記パラメータセットの更新を実行するかどうか判断することが、前記ビットストリームの前記部分について、前記第１のパラメータセットを非アクティブ化し、かつ前記第２のパラメータセットをアクティブ化するために、前記パラメータセットの更新を自動的に実行することをさらに備える、請求項４に記載の方法。
【請求項７】
前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得ないことを示す前記インジケータに基づいて、前記ビットストリームの前記部分の先頭において１つまたは複数のパラメータセットを受信することをさらに備える、請求項１に記載の方法。
【請求項８】
前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得ないことを示す前記インジケータに基づいて、前記ビットストリームのコード化ビデオシーケンスとは別個の、帯域外送信中の１つまたは複数のパラメータセットを受信することをさらに備える、請求項１に記載の方法。
【請求項９】
前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得ないことを示す前記インジケータに基づいて、前記第１のパラメータセットのどの反復送信についての内容も比較せずに、前記ビットストリームのコード化ビデオシーケンスとともに、帯域内送信中で１つまたは複数のパラメータセットを受信することをさらに備える、請求項１に記載の方法。
【請求項１０】
前記インジケータが、任意のタイプのパラメータセットについて、前記ビットストリームの前記部分においてパラメータセットの更新が起こり得るかどうかを示す、単一のシンタックス要素を備える、請求項１に記載の方法。
【請求項１１】
前記インジケータが、複数のシンタックス要素のうち１つを備え、ここで、前記複数のシンタックス要素の各々が、特定のタイプのパラメータセットについて、前記ビットストリームの前記部分においてパラメータセットの更新が起こり得るかどうかを示す、請求項１に記載の方法。
【請求項１２】
前記インジケータが、複数のシンタックス要素のうち１つを備え、ここで、前記複数のシンタックス要素のうち少なくとも１つが、２つ以上の異なるタイプのパラメータセットについて、前記ビットストリームの前記部分においてパラメータセットの更新が起こり得るかどうかを示す、請求項１に記載の方法。
【請求項１３】
前記インジケータが、前記ビットストリームの前記部分についての少なくとも１つのアクセスユニットの補足強調情報（ＳＥＩ）メッセージに含まれるシンタックス要素を備える、請求項１に記載の方法。
【請求項１４】
前記インジケータが、前記ビットストリームの前記部分の少なくとも１つのアクセスユニットに含まれるシーケンスパラメータセット（ＳＰＳ）ネットワークアブストラクションレイヤ（ＮＡＬ）ユニットに含まれるシンタックス要素を備える、請求項１に記載の方法。
【請求項１５】
前記インジケータが、前記ビットストリームに含まれるシンタックス要素、前記ビットストリームのコード化ビデオシーケンスに含まれるシンタックス要素、プロファイル定義中の要件、セッション記述プロトコルに含まれるメディアタイプパラメータ、またはハイパーテキスト転送プロトコル（ＨＴＴＰ）ストリーミング環境についてのメディアプレゼンテーション記述に含まれるストリームプロパティ、のうち１つを備える、請求項１に記載の方法。
【請求項１６】
前記ビットストリームの前記部分が、前記ビットストリームのコード化ビデオシーケンスまたは前記ビットストリームの前記コード化ビデオシーケンス中のピクチャグループ（ＧＯＰ）のうち１つを備える、請求項１に記載の方法。
【請求項１７】
ビデオデータを符号化する方法であって、
ビットストリームの部分においてパラメータセットの更新が起こり得るかどうかを示すインジケータを符号化することを備え、ここで、パラメータセットの更新が、特定のタイプの、かつ特定の識別値を有する現在のパラメータセットが、同じタイプの、かつ同じ識別値を有する前のパラメータセットの内容とは異なる内容を有する場合に起こる、方法。
【請求項１８】
前記インジケータが、１つまたは複数のタイプのパラメータセットについて、前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得るかどうかを示す、請求項１７に記載の方法。
【請求項１９】
特定の識別値をもつ特定のタイプの第１のパラメータセットを符号化することと、
前記第１のパラメータセットと同じタイプの、かつ同じ識別値を有する第２のパラメータセットを符号化することと、前記第１のパラメータセットが、前記第２のパラメータセットより前のものであり、ここで、前記インジケータが、前記第２のパラメータセットを記憶して前記第１のパラメータセットを置き換えるために、前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得るかどうかを示す、をさらに備える、請求項１７に記載の方法。
【請求項２０】
前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得ないことを示す前記インジケータに基づいて、前記ビットストリームの前記部分の先頭において１つまたは複数のパラメータセットを符号化することをさらに備える、請求項１７に記載の方法。
【請求項２１】
前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得ないことを示す前記インジケータに基づいて、前記ビットストリームのコード化ビデオシーケンスとは別個の、帯域外送信中の１つまたは複数のパラメータセットを符号化することをさらに備える、請求項１７に記載の方法。
【請求項２２】
前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得ないことを示す前記インジケータに基づいて、前記ビットストリームのコード化ビデオシーケンスとともに、帯域内送信中の前記第１のパラメータセットを符号化することをさらに備える、請求項１７に記載の方法。
【請求項２３】
前記インジケータが、任意のタイプのパラメータセットについて、前記ビットストリームの前記部分においてパラメータセットの更新が起こり得るかどうかを示す単一のシンタックス要素を備える、請求項１７に記載の方法。
【請求項２４】
前記インジケータが、複数のシンタックス要素のうち１つを備え、ここで、前記複数のシンタックス要素の各々が、特定のタイプのパラメータセットについて、前記ビットストリームの前記部分においてパラメータセットの更新が起こり得るかどうかを示す、請求項１７に記載の方法。
【請求項２５】
前記インジケータが、複数のシンタックス要素のうち１つを備え、ここで、前記複数のシンタックス要素のうち少なくとも１つが、２つ以上の異なるタイプのパラメータセットについて、前記ビットストリームの前記部分においてパラメータセットの更新が起こり得るかどうかを示す、請求項１７に記載の方法。
【請求項２６】
前記インジケータが、前記ビットストリームの前記部分についての少なくとも１つのアクセスユニットの補足強調情報（ＳＥＩ）メッセージに含まれるシンタックス要素を備える、請求項１７に記載の方法。
【請求項２７】
前記インジケータが、前記ビットストリームの前記部分の少なくとも１つのアクセスユニットに含まれるシーケンスパラメータセット（ＳＰＳ）・ネットワークアブストラクションレイヤ（ＮＡＬ）ユニットに含まれるシンタックス要素を備える、請求項１７に記載の方法。
【請求項２８】
前記インジケータが、前記ビットストリームに含まれるシンタックス要素、前記ビットストリームのコード化ビデオシーケンスに含まれるシンタックス要素、プロファイル定義中の要件、セッション記述プロトコルに含まれるメディアタイプパラメータ、またはハイパーテキスト転送プロトコル（ＨＴＴＰ）ストリーミング環境についてのメディアプレゼンテーション記述に含まれるストリームプロパティのうち１つを備える、請求項１７に記載の方法。
【請求項２９】
前記ビットストリームの前記部分が、前記ビットストリームのコード化ビデオシーケンスまたは前記ビットストリームの前記コード化ビデオシーケンス中のピクチャグループ（ＧＯＰ）のうち１つを備える、請求項１７に記載の方法。
【請求項３０】
ビデオデータをコーディングするためのビデオコーディングデバイスであって、
ビデオデータを記憶するように構成されたメモリと、
ビットストリームの部分においてパラメータセットの更新が起こり得るかどうかを示すインジケータをコーディングするように構成された１つまたは複数のプロセッサと、ここで、パラメータセットの更新が、特定のタイプの、かつ特定の識別値を有する現在のパラメータセットが、同じタイプの、かつ同じ識別値を有する前のパラメータセットの内容とは異なる内容を有する場合に起こる、
を備えるデバイス。
【請求項３１】
前記インジケータが、１つまたは複数のタイプのパラメータセットについて、前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得るかどうかを示す、請求項３０に記載のデバイス。
【請求項３２】
前記ビデオコーディングデバイスがビデオ復号デバイスを備え、ここで、前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得ないことを示す前記インジケータに基づいて、前記プロセッサが、
前記ビットストリームの前記部分全体に対して、特定の識別値をもつ特定のタイプの第１のパラメータセットをアクティブ化することと、
前記ビットストリームの前記部分全体についての前記第１のパラメータセットを更新しないように、前記ビットストリームの前記部分全体において、前記第１のパラメータセットと同じタイプの、かつ同じ識別値を有する他のパラメータセットを無視することと、前記第１のパラメータセットが、前記他のパラメータセットより前のものである、
を行うように構成される、請求項３０に記載のデバイス。
【請求項３３】
前記ビデオコーディングデバイスがビデオ復号デバイスを備え、ここで、前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得ることを示す前記インジケータに基づいて、前記プロセッサが、
特定の識別値をもつ特定のタイプの第１のパラメータセットをアクティブ化することと、
前記第１のパラメータセットと同じタイプの、かつ同じ識別値を有する第２のパラメータセットを受信することと、前記第１のパラメータセットが、前記第２のパラメータセットより前のものである、
前記第２のパラメータセットを記憶して前記第１のパラメータセットを置き換えるための前記パラメータセットの更新を実行するかどうか判断することと
を行うように構成される、請求項３０に記載のデバイス。
【請求項３４】
前記プロセッサが、
前記第２のパラメータセットの内容を前記第１のパラメータセットの内容と比較するように、
前記第２のパラメータセットの前記内容が前記第１のパラメータセットの前記内容とは異なることに基づいて、前記ビットストリームの前記部分について、前記第１のパラメータセットを非アクティブ化し、前記第２のパラメータセットをアクティブ化するために、前記パラメータセットの更新を実行するように、
構成される、請求項３３に記載のデバイス。
【請求項３５】
前記プロセッサが、前記ビットストリームの前記部分について、前記第１のパラメータセットを非アクティブ化し、前記第２のパラメータセットをアクティブ化するために、前記パラメータセットの更新を自動的に実行するように構成される、請求項３３に記載のデバイス。
【請求項３６】
前記ビデオコーディングデバイスがビデオ符号化デバイスを備え、ここで、前記プロセッサが、
特定の識別値をもつ特定のタイプの第１のパラメータセットを符号化することと、
前記第１のパラメータセットと同じタイプの、かつ同じ識別値を有する第２のパラメータセットを符号化することと、前記第１のパラメータセットが、前記第２のパラメータセットより前のものであり、ここで、前記インジケータが、前記第２のパラメータセットを記憶して前記第１のパラメータセットを置き換えるための、前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得るかどうかを示す、
を行うように構成される、請求項３０に記載のデバイス。
【請求項３７】
前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得ないことを示す前記インジケータに基づいて、前記プロセッサが、前記ビットストリームの前記部分の先頭において１つまたは複数のパラメータセットをコーディングするように構成される、請求項３０に記載のデバイス。
【請求項３８】
前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得ないことを示す前記インジケータに基づいて、前記プロセッサが、前記ビットストリームのコード化ビデオシーケンスとは別個の、帯域外送信において１つまたは複数のパラメータセットをコーディングするように構成される、請求項３０に記載のデバイス。
【請求項３９】
前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得ないことを示す前記インジケータに基づいて、前記プロセッサが、前記ビットストリームのコード化ビデオシーケンスとともに、帯域内送信において１つまたは複数のパラメータセットをコーディングするように構成される、請求項３０に記載のデバイス。
【請求項４０】
前記インジケータが、任意のタイプのパラメータセットについて、前記ビットストリームの前記部分においてパラメータセットの更新が起こり得るかどうかを示す単一のシンタックス要素を備える、請求項３０に記載のデバイス。
【請求項４１】
前記インジケータが、複数のシンタックス要素のうち１つを備え、ここで、前記複数のシンタックス要素の各々が、特定のタイプのパラメータセットについて、前記ビットストリームの前記部分においてパラメータセットの更新が起こり得るかどうかを示す、請求項３０に記載のデバイス。
【請求項４２】
前記インジケータが、複数のシンタックス要素のうち１つを備え、ここで、前記複数のシンタックス要素のうち少なくとも１つが、２つ以上の異なるタイプのパラメータセットについて、前記ビットストリームの前記部分においてパラメータセットの更新が起こり得るかどうかを示す、請求項３０に記載のデバイス。
【請求項４３】
前記インジケータが、前記ビットストリームの前記部分についての少なくとも１つのアクセスユニットの補足強調情報（ＳＥＩ）メッセージに含まれるシンタックス要素を備える、請求項３０に記載のデバイス。
【請求項４４】
前記インジケータが、前記ビットストリームの前記部分の少なくとも１つのアクセスユニットに含まれるシーケンスパラメータセット（ＳＰＳ）ネットワークアブストラクションレイヤ（ＮＡＬ）ユニットに含まれるシンタックス要素を備える、請求項３０に記載のデバイス。
【請求項４５】
前記インジケータが、前記ビットストリームに含まれるシンタックス要素、前記ビットストリームのコード化ビデオシーケンスに含まれるシンタックス要素、プロファイル定義中の要件、セッション記述プロトコルに含まれるメディアタイプパラメータ、またはハイパーテキスト転送プロトコル（ＨＴＴＰ）ストリーミング環境についてのメディアプレゼンテーション記述に含まれるストリームプロパティ、のうち１つを備える、請求項３０に記載のデバイス。
【請求項４６】
前記ビットストリームの前記部分が、前記ビットストリームのコード化ビデオシーケンスまたは前記ビットストリームの前記コード化ビデオシーケンス中のピクチャグループ（ＧＯＰ）のうち１つを備える、請求項３０に記載のデバイス。
【請求項４７】
ビデオデータをコーディングするためのビデオコーディングデバイスであって、
ビットストリームの部分においてパラメータセットの更新が起こり得るかどうかを示すインジケータをコーディングするための手段であって、パラメータセットの更新が、特定のタイプの、かつ特定の識別値を有する現在のパラメータセットが、同じタイプの、かつ同じ識別値を有する前のパラメータセットの内容とは異なる内容を有する場合に起こる、手段を備えるデバイス。
【請求項４８】
前記インジケータが、１つまたは複数のタイプのパラメータセットについて、前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得るかどうかを示す、請求項４７に記載のデバイス。
【請求項４９】
ビデオデータをコーディングするための命令を備えるコンピュータ可読媒体であって、前記命令が、実行されると、１つまたは複数のプロセッサに、
ビットストリームの部分においてパラメータセットの更新が起こり得るかどうかを示すインジケータをコーディングすることと、ここで、パラメータセットの更新が、同じタイプの、かつ同じ識別値を有する前のパラメータセットを置き換えるために現在のパラメータセットを記憶することを含む、
前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得ないことを示す前記インジケータに基づいて、前記ビットストリームの前記部分全体に対して、特定の識別値をもつ特定のタイプの第１のパラメータセットをアクティブ化することと
を行わせる、コンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願
[0001]  本出願は、その全体が参照により本明細書に組み込まれる、２０１２年４月２７日に出願された米国仮出願第６１／６３９，８２３号の利益を主張する。
【０００２】
[0002]  本開示は概して、ビデオデータの処理に関する。
【背景技術】
【０００３】
[0003]  デジタルビデオ機能は、デジタルテレビジョン、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末（ＰＤＡ）、ラップトップまたはデスクトップコンピュータ、デジタルカメラ、デジタル記録デバイス、デジタルメディアプレーヤ、ビデオゲームデバイス、ビデオゲームコンソール、携帯電話または衛星無線電話、ビデオ遠隔会議デバイスなどを含む、広範囲にわたるデバイスに組み込まれ得る。ビデオコーディング規格は、ＩＴＵ−Ｔ  Ｈ．２６１、ＩＳＯ／ＩＥＣ  ＭＰＥＧ−１  Ｖｉｓｕａｌと、ＩＴＵ−Ｔ  Ｈ．２６２またはＩＳＯ／ＩＥＣ  ＭＰＥＧ−２  Ｖｉｓｕａｌと、ＩＴＵ−Ｔ  Ｈ．２６３、ＩＳＯ／ＩＥＣ  ＭＰＥＧ−４  Ｖｉｓｕａｌと、スケーラブルビデオコーディング（ＳＶＣ）拡張およびマルチビュービデオコーディング（ＭＶＣ）拡張を含む（ＩＳＯ／ＩＥＣ  ＭＰＥＧ−４  ＡＶＣとしても知られる）ＩＴＵ−Ｔ  Ｈ．２６４とを含む。さらに、高効率ビデオコーディング（ＨＥＶＣ）は、ＩＴＵ−Ｔ  Ｖｉｄｅｏ  Ｃｏｄｉｎｇ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ（ＶＣＥＧ）およびＩＳＯ／ＩＥＣ  Ｍｏｔｉｏｎ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ（ＭＰＥＧ）のＪｏｉｎｔ  Ｃｏｌｌａｂｏｒａｔｉｏｎ  Ｔｅａｍ  ｏｎ  Ｖｉｄｅｏ  Ｃｏｄｉｎｇ（ＪＣＴ−ＶＣ）によって開発されているビデオコーディング規格である。ビデオデバイスは、そのようなビデオコーディング技法を実装することによって、デジタルビデオ情報をより効率的に送信、受信、符号化、復号、および／または記憶し得る。
【０００４】
[0004]  ビデオコーディング技法は、ビデオシーケンスに固有の冗長性を低減または除去するための空間的（イントラピクチャ）予測および／または時間的（インターピクチャ）予測を含む。ブロックベースの予測ビデオコーディングの場合、ビデオスライス（たとえば、ビデオフレームまたはビデオフレームの一部分）が、マクロブロック、ツリーブロック、コーディングユニット（ＣＵ：coding unit）および／またはコーディングノードと呼ばれることもあるビデオブロックに区分され得る。ピクチャのイントラコード化（Ｉ）スライス内のビデオブロックは、同じピクチャの中の隣接ブロック内の参照サンプルに対する空間的予測を使用して符号化される。ピクチャのインターコード化（ＰまたはＢ）スライス内のビデオブロックは、同じピクチャの中の隣接ブロック内の参照サンプルに対する空間的予測、または他の参照ピクチャの中の参照サンプルに対する時間的予測を使用することができる。ピクチャはフレームと呼ばれることがあり、参照ピクチャは参照フレームと呼ばれることがある。
【０００５】
[0005]  空間的予測または時間的予測は、コーディングされるべきブロックの予測ブロックを生じる。残差データは、コーディングされるべき元のブロックと、予測ブロックとの間のピクセル差分を表す。ピクセルは、画素、ペル、またはサンプルと呼ばれる場合もある。インターコード化ブロックは、予測ブロックを形成する参照サンプルのブロックを指す動きベクトルと、コード化ブロックと予測ブロックとの間の差分を示す残差データとに従って符号化される。イントラコード化ブロックは、イントラコーディングモードと残差データとに従って符号化される。さらなる圧縮のために、残差データは、ピクセル領域から変換領域に変換されて残差変換係数をもたらすことができ、その残差変換係数は、次いで量子化され得る。量子化変換係数は、最初に２次元アレイで構成され、変換係数の１次元ベクトルを生成するために走査することができ、なお一層の圧縮を達成するためにエントロピーコーディングを適用することができる。
【発明の概要】
【０００６】
[0006]  概して、本開示は、ビットストリームの部分（たとえば、コード化ビデオシーケンスまたはピクチャグループ（ＧＯＰ：group of pictures））においてパラメータセットの更新（parameter set update）が起こり得るかどうかの指示を与えるための技法について記載する。この指示により、ビデオデコーダは、記憶されたパラメータセットと、同じタイプであるとともに同じ識別値をもつ新たなパラメータセットとの間の内容比較を実行せずに、記憶されたパラメータセットの更新が起こり得るかどうか判断することが可能になり得る。特定のタイプであるとともに特定の識別値を有する現在のパラメータセットが、同じタイプであるとともに同じ識別値を有する前のパラメータセットの内容とは異なる内容を有する場合、パラメータセットの更新が起こる。パラメータセットの更新は、同じタイプであるとともに同じ識別値を有する前のパラメータセットを置き換えるために、所与の識別値をもつ現在のパラメータセットを記憶することを含む。パラメータセットの更新が起こり得ないとき、ビデオデコーダは、ビットストリームの部分全体について、所与のタイプの単一のパラメータセットを記憶し、アクティブ化すればよい。パラメータセットの更新が起こり得るとき、ビデオデコーダは、新たなパラメータセットを自動的にアクティブ化し、所与のタイプの記憶されたパラメータセットを非アクティブ化してもよく、たとえば、内容比較を実行することによって、記憶されたパラメータを更新するかどうか判断することができる。
【０００７】
[0007]  指示は、ビットストリームの部分に含まれるシンタックス要素など、ビットストリームレベルの指示を備え得る。たとえば、指示は、ビットストリーム中の補足強調情報（ＳＥＩ：supplemental enhancement information）ネットワークアブストラクションレイヤ（ＮＡＬ：network abstraction layer）ユニットに含まれるフラグを備え得る。別の例として、指示は、ビットストリーム中のシーケンスパラメータセット（ＳＰＳ：sequence parameter set）ＮＡＬユニットに含まれるフラグを備え得る。一例では、本技法は、ビットストリームの部分において、任意のパラメータセットが更新され得るかどうかを示すフラグを復号することを含む。この場合、ビデオパラメータセット（ＶＰＳ：video parameter set）、シーケンスパラメータセット（ＳＰＳ）、ピクチャパラメータセット（ＰＰＳ：picture parameter set）、および／または適応パラメータセット（ＡＰＳ：adaptive parameter set）を含むすべてのタイプのパラメータセットに対して、同じフラグが使われてよい。具体的には、単一のフラグが、ビットストリーム中のパラメータセットのうちいずれかが更新され得るかどうかを示すことができる。別の例では、本技法は、ビットストリームの部分において特定のタイプのパラメータセットが更新され得るかどうかを各々が示す、いくつかの異なるフラグを復号することを含む。
【０００８】
[0008]  一例では、本開示は、ビットストリームの部分においてパラメータセットの更新が起こり得るかどうかを示すインジケータを復号することを備える、ビデオデータを復号する方法を対象とし、パラメータセットの更新は、特定のタイプであるとともに特定の識別値を有する現在のパラメータセットが、同じタイプであるとともに同じ識別値を有する前のパラメータセットの内容とは異なる内容を有する場合に起こる。ビットストリームの部分においてパラメータセットの更新が起こり得ないことを示すインジケータに基づいて、この方法は、ビットストリームの部分全体に対して、特定の識別値をもつ特定のタイプの第１のパラメータセットをアクティブ化することをさらに備える。
【０００９】
[0009]  別の例では、本開示は、ビットストリームの部分においてパラメータセットの更新が起こり得るかどうかを示すインジケータを符号化することを備える、ビデオデータを符号化する方法を対象とし、パラメータセットの更新は、特定のタイプであるとともに特定の識別値を有する現在のパラメータセットが、同じタイプであるとともに同じ識別値を有する前のパラメータセットの内容とは異なる内容を有する場合に起こる。
【００１０】
[0010]  さらなる一例において、本開示は、ビデオデータをコーディングするためのビデオコーディングデバイスを対象とし、このデバイスは、ビデオデータを記憶するように構成されたメモリと、ビットストリームの部分においてパラメータセットの更新が起こり得るかどうかを示すインジケータをコーディングするように構成された１つまたは複数のプロセッサとを備え、パラメータセットの更新は、特定のタイプであるとともに特定の識別値を有する現在のパラメータセットが、同じタイプであるとともに同じ識別値を有する前のパラメータセットの内容とは異なる内容を有する場合に起こる。ビットストリームの部分においてパラメータセットの更新が起こり得ないことを示すインジケータに基づいて、デバイスのプロセッサは、ビットストリームの部分全体に対して、特定の識別値をもつ特定のタイプの第１のパラメータセットをアクティブ化するようにさらに構成される。
【００１１】
[0011]  別の例では、本開示は、ビデオデータをコーディングするためのビデオコーディングデバイスを対象とし、このデバイスは、ビットストリームの部分においてパラメータセットの更新が起こり得るかどうかを示すインジケータをコーディングするための手段を備え、パラメータセットの更新は、特定のタイプであるとともに特定の識別値を有する現在のパラメータセットが、同じタイプであるとともに同じ識別値を有する前のパラメータセットの内容とは異なる内容を有する場合に起こる。ビットストリームの部分においてパラメータセットの更新が起こり得ないことを示すインジケータに基づいて、このデバイスは、ビットストリームの部分全体に対して、特定の識別値をもつ特定のタイプの第１のパラメータセットをアクティブ化するための手段をさらに含む。
【００１２】
[0012]  追加の例において、本開示は、ビデオデータをコーディングするための命令を備えるコンピュータ可読媒体を対象とし、命令は、実行されると、１つまたは複数のプロセッサに、ビットストリームの部分においてパラメータセットの更新が起こり得るかどうかを示すインジケータをコーディングさせ、パラメータセットの更新は、特定のタイプであるとともに特定の識別値を有する現在のパラメータセットが、同じタイプであるとともに同じ識別値を有する前のパラメータセットの内容とは異なる内容を有する場合に起こる。ビットストリームの部分においてパラメータセットの更新が起こり得ないことを示すインジケータに基づいて、命令は、プロセッサに、ビットストリームの部分全体に対して、特定の識別値をもつ特定のタイプの第１のパラメータセットをアクティブ化させる。
【００１３】
[0013]  １つまたは複数の例の詳細を添付の図面および以下の説明に記載する。他の特徴、目的、および利点は、その説明および図面、ならびに特許請求の範囲から明らかになろう。
【図面の簡単な説明】
【００１４】
【図１】[0014]  本開示で説明する技法を利用し得る例示的なビデオ符号化および復号システムを示すブロック図。
【図２】[0015]  本開示で説明する技法を実装し得る例示的なビデオエンコーダを示すブロック図。
【図３】[0016]  本開示で説明する技法を実装し得る例示的なビデオデコーダを示すブロック図。
【図４】[0017]  予測ビデオコーディング技法に従ってコーディングされたビデオシーケンスを示す概念図。
【図５】[0018]  コード化ビデオシーケンスの一例を示す概念図。
【図６】[0019]  ビットストリームの部分においてパラメータセットの更新が起こり得るかどうか判断する動作を示すフローチャート。
【図７】[0020]  ＣＲＡアクセスユニットからのランダムアクセスが、前の利用不可能アクセスユニットからパラメータセットをフェッチする必要なしに実行され得るかどうか判断する動作を示すフローチャート。
【図８】[0021]  ネットワークの一部を形成する例示的なデバイスセットを示すブロック図。
【発明を実施するための形態】
【００１５】
[0022]  本開示の技法は、ビットストリームの部分においてパラメータセットの更新が起こり得るかどうかの指示を可能にする。ビットストリームの部分は、ビットストリームのコード化ビデオシーケンスであっても、ビットストリームのコード化ビデオシーケンス中のピクチャグループ（ＧＯＰ）であり得る。この指示により、ビデオデコーダは、記憶されたパラメータセットと、同じタイプであるとともに同じ識別値をもつ新たなパラメータセットとの間の内容比較を実行せずに、記憶されたパラメータセットの更新が起こり得るかどうか判断することが可能になり得る。特定のタイプであるとともに特定の識別値を有する現在のパラメータセットが、同じタイプであるとともに同じ識別値を有する前のパラメータセットの内容とは異なる内容を有する場合、パラメータセットの更新が起こる。パラメータセットの更新は、同じタイプであるとともに同じ識別値を有する前のパラメータセットを置き換えるために、所与の識別値をもつ現在のパラメータセットを記憶することを含む。パラメータセットの更新が起こり得ないとき、ビデオデコーダは、ビットストリームの部分全体について、所与のタイプの単一のパラメータセットを記憶し、アクティブ化すればよい。パラメータセットの更新が起こり得るとき、ビデオデコーダは、新たなパラメータセットを自動的にアクティブ化し、所与のタイプの記憶されたパラメータセットを非アクティブ化してもよく、たとえば、内容比較を実行することによって、記憶されたパラメータを更新するかどうか判断することができる。
【００１６】
[0023]  指示は、ビットストリームの部分に含まれるシンタックス要素など、ビットストリームレベルの指示を備え得る。たとえば、指示は、ビットストリーム中の補足強調情報（ＳＥＩ）ネットワークアブストラクションレイヤ（ＮＡＬ）ユニットに含まれるフラグを備え得る。別の例として、指示は、ビットストリーム中のシーケンスパラメータセット（ＳＰＳ）ＮＡＬユニットに含まれるフラグを備え得る。一例では、本技法は、ビットストリームの部分において、任意のパラメータセットが更新され得るかどうかを示すフラグを復号することを含む。この場合、ビデオパラメータセット（ＶＰＳ）、シーケンスパラメータセット（ＳＰＳ）、ピクチャパラメータセット（ＰＰＳ）、および／または適応パラメータセット（ＡＰＳ）を含むすべてのタイプのパラメータセットに対して、同じフラグが使われてよい。具体的には、単一のフラグが、ビットストリーム中のパラメータセットのうちいずれかが更新され得るかどうかを示すことができる。別の例では、本技法は、ビットストリームの部分において特定のタイプのパラメータセットが更新され得るかどうかを各々が示す、いくつかの異なるフラグを復号することを含む。
【００１７】
[0024]  ビットストリームの部分においてパラメータセットの更新が起こり得るケース、たとえば、接合点ピクチャの所でパラメータセットが更新される必要がある接合ビットストリームのケースでは、パラメータセットは、ビットストリームの部分の先頭において送信することはできず、ビットストリームの部分のコード化ビデオシーケンスとは別個に、帯域外では送信することができない。本技法によると、ビットストリームの部分においてパラメータセットの更新が起こり得るかどうかの指示は、どのようにしてパラメータセットが送信されるかを決定し得る。一例では、ビットストリームの部分においてパラメータセットの更新が起こり得ないことをインジケータが示す場合、ビデオデコーダは、帯域外送信、すなわち、ビットストリームのコード化ビデオシーケンスとは別個の送信において、１つまたは複数のパラメータセットを受信し得る。別の例では、ビットストリームの部分においてパラメータセットの更新が起こり得ないことをインジケータが示す場合、ビデオデコーダは、帯域内送信、すなわち、第１のパラメータセットがビットストリームの部分の先頭にある、ビットストリームの部分のコード化ビデオシーケンスをもつ送信において、１つまたは複数のパラメータセットを受信することができる。
【００１８】
[0025]  図１は、本開示で説明する技法を利用し得る例示的なビデオ符号化および復号システム１０を示すブロック図である。図１に示されるように、システム１０は、宛先デバイス１４によって後で復号されるべき符号化ビデオデータを与えるソースデバイス１２を含む。特に、ソースデバイス１２は、コンピュータ可読媒体１６を介してビデオデータを宛先デバイス１４に与える。ソースデバイス１２および宛先デバイス１４は、デスクトップコンピュータ、ノートブック（すなわち、ラップトップ）コンピュータ、タブレットコンピュータ、セットトップボックス、いわゆる「スマート」フォンなどの電話ハンドセット、いわゆる「スマート」パッド、テレビジョン、カメラ、ディスプレイデバイス、デジタルメディアプレーヤ、ビデオゲームコンソール、ビデオストリーミングデバイスなどを含む、広範囲にわたるデバイスのいずれかを備え得る。場合によっては、ソースデバイス１２および宛先デバイス１４は、ワイヤレス通信に対応し得る。
【００１９】
[0026]  宛先デバイス１４は、コンピュータ可読媒体１６を介して、復号されるべき符号化ビデオデータを受信することができる。コンピュータ可読媒体１６は、符号化ビデオデータをソースデバイス１２から宛先デバイス１４に移動することが可能な任意のタイプの媒体またはデバイスを備えることができる。一例では、コンピュータ可読媒体１６は、ソースデバイス１２が、符号化ビデオデータを宛先デバイス１４にリアルタイムで直接送信することを可能にするための通信媒体を備え得る。符号化ビデオデータは、ワイヤレス通信プロトコルなどの通信規格に従って変調され、宛先デバイス１４に送信され得る。通信媒体は、無線周波数（ＲＦ）スペクトルまたは１つまたは複数の物理伝送線路など、任意のワイヤレスまたはワイヤード通信媒体を備え得る。通信媒体は、ローカルエリアネットワーク、ワイドエリアネットワーク、またはインターネットなどのグローバルネットワークなど、パケットベースネットワークの一部を形成し得る。通信媒体は、ソースデバイス１２から宛先デバイス１４への通信を可能にするために有用であり得るルータ、スイッチ、基地局、または任意の他の機器を含み得る。
【００２０】
[0027]  いくつかの例では、符号化データは、出力インターフェース２２からストレージデバイスに出力され得る。同様に、符号化データは、入力インターフェースによってストレージデバイスからアクセスされ得る。ストレージデバイスは、ハードドライブ、ブルーレイ（登録商標）ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、フラッシュメモリ、揮発性または不揮発性メモリ、あるいは符号化ビデオデータを記憶するための任意の他の好適なデジタル記憶媒体など、様々な分散されたまたはローカルにアクセスされるデータ記憶媒体のいずれかを含み得る。さらなる一例では、ストレージデバイスは、ソースデバイス１２によって生成された符号化ビデオを記憶し得るファイルサーバまたは別の中間ストレージデバイスに対応し得る。宛先デバイス１４は、ストリーミングまたはダウンロードを介して、ストレージデバイスから記憶されたビデオデータにアクセスし得る。ファイルサーバは、符号化ビデオデータを記憶し、その符号化ビデオデータを宛先デバイス１４に送信することが可能な任意のタイプのサーバであり得る。例示的なファイルサーバは、（たとえば、ウェブサイトのための）ウェブサーバ、ＦＴＰサーバ、ネットワーク接続ストレージ（ＮＡＳ）デバイス、またはローカルディスクドライブを含む。宛先デバイス１４は、インターネット接続を含む、任意の標準的なデータ接続を通じて符号化ビデオデータにアクセスし得る。これは、ファイルサーバに記憶された符号化ビデオデータにアクセスするのに好適であるワイヤレスチャネル（たとえば、Ｗｉ−Ｆｉ（登録商標）接続）、ワイヤード接続（たとえば、ＤＳＬ、ケーブルモデムなど）、または両方の組合せを含み得る。ストレージデバイスからの符号化ビデオデータの送信は、ストリーミング送信、ダウンロード送信、またはそれらの組合せであり得る。
【００２１】
[0028]  本開示の技法は、必ずしもワイヤレスの適用例または設定に限定されるとは限らない。本技法は、オーバージエアテレビジョン放送、ケーブルテレビジョン送信、衛星テレビジョン送信、たとえば動的適応ストリーミングオーバーＨＴＴＰ（ＤＡＳＨ）としてのインターネットを介したストリーミングビデオ送信、データ記憶媒体に記憶するためのデジタルビデオの符号化、データ記憶媒体に記憶されたデジタルビデオの復号、または他の適用例など、種々のマルチメディア適用例のいずれかをサポートするビデオコーディングに適用され得る。いくつかの例では、システム１０は、ビデオストリーミング、ビデオ再生、ビデオブロードキャスティング、および／またはビデオテレフォニーなどの適用例をサポートするために、単方向または二方向のビデオ送信をサポートするように構成され得る。
【００２２】
[0029]  図１の例では、ソースデバイス１２は、ビデオソース１８と、ビデオエンコーダ２０と、出力インターフェース２２とを含む。宛先デバイス１４は、入力インターフェース２８と、ビデオデコーダ３０と、ディスプレイデバイス３２とを含む。他の例では、ソースデバイスおよび宛先デバイスは、他の構成要素または構成を含み得る。たとえば、ソースデバイス１２は、外部カメラなどの外部ビデオソース１８からビデオデータを受信し得る。同様に、宛先デバイス１４は、一体型ディスプレイデバイスを含むのではなく、外部ディスプレイデバイスとインターフェースし得る。
【００２３】
[0030]  図１の図示のシステム１０は一例にすぎない。本開示の技法は、任意のデジタルビデオ符号化および／または復号デバイスによって実行され得る。一般に、技法はビデオ符号化デバイスによって実行されるが、本技法は、通常「コーデック」と呼ばれるビデオエンコーダ／デコーダによっても実行され得る。さらに、本開示の技法は、ビデオプリプロセッサによって実行することもできる。ソースデバイス１２および宛先デバイス１４は、ソースデバイス１２が宛先デバイス１４に送信するためのコード化ビデオデータを生成するような、コーディングデバイスの例にすぎない。いくつかの例では、デバイス１２、１４の各々がビデオ符号化構成要素とビデオ復号構成要素とを含むように、デバイス１２、１４は、実質的に対称的に動作し得る。したがって、システム１０は、たとえば、ビデオストリーミング、ビデオ再生、ビデオブロードキャストまたはビデオ電話のための、ビデオデバイス１２とビデオデバイス１４との間の一方向または双方向のビデオ送信をサポートすることができる。
【００２４】
[0031]  ソースデバイス１２のビデオソース１８は、ビデオカメラなどのビデオキャプチャデバイス、以前にキャプチャされたビデオを含んでいるビデオアーカイブ、および／またはビデオコンテンツプロバイダからビデオを受信するためのビデオフィードインターフェースを含み得る。さらなる代替として、ビデオソース１８は、ソースビデオとしてのコンピュータグラフィックスベースのデータ、またはライブビデオとアーカイブされたビデオとコンピュータにより生成されたビデオとの組合せを生成し得る。場合によっては、ビデオソース１８がビデオカメラである場合、ソースデバイス１２および宛先デバイス１４は、いわゆるカメラ付き電話またはビデオ電話を形成することができる。ただし、上述のように、本開示で説明する技法は、一般にビデオコーディングに適用可能であり、ワイヤレスおよび／またはワイヤードアプリケーションに適用可能であり得る。各々の場合において、キャプチャされたビデオ、以前にキャプチャされたビデオ、またはコンピュータで生成されたビデオは、ビデオエンコーダ２０によって符号化され得る。符号化ビデオ情報は、次いで、出力インターフェース２２によってコンピュータ可読媒体１６上に出力され得る。
【００２５】
[0032]  コンピュータ可読媒体１６は、ワイヤレスブロードキャストまたはワイヤードネットワーク送信などの一時媒体、あるいはハードディスク、フラッシュドライブ、コンパクトディスク、デジタルビデオディスク、ブルーレイディスク、または他のコンピュータ可読媒体などの記憶媒体（すなわち、非一時的記憶媒体）を含み得る。いくつかの例では、ネットワークサーバ（図示せず）は、ソースデバイス１２から符号化ビデオデータを受信し、たとえば、ネットワーク送信を介して、その符号化ビデオデータを宛先デバイス１４に与え得る。同様に、ディスクスタンピング設備など、媒体製造設備のコンピューティングデバイスは、ソースデバイス１２から符号化ビデオデータを受信し、その符号化ビデオデータを含んでいるディスクを生成し得る。したがって、コンピュータ可読媒体１６は、様々な例において、様々な形態の１つまたは複数のコンピュータ可読媒体を含むことが理解されよう。
【００２６】
[0033]  宛先デバイス１４の入力インターフェース２８は、コンピュータ可読媒体１６から情報を受信する。コンピュータ可読媒体１６の情報は、ビデオエンコーダ２０によって定義され、またビデオデコーダ３０によって使用される、ブロックおよび他のコード化ユニット、たとえば、ＧＯＰの特性および／または処理を記述するシンタックス要素を含む、シンタックス情報を含み得る。ディスプレイデバイス３２は、復号されたビデオデータをユーザに対して表示し、陰極線管（ＣＲＴ）、液晶ディスプレイ（ＬＣＤ）、プラズマディスプレイ、有機発光ダイオード（ＯＬＥＤ）ディスプレイ、または別のタイプのディスプレイデバイスなど、様々なディスプレイデバイスのいずれかを備え得る。
【００２７】
[0034]  ビデオエンコーダ２０およびビデオデコーダ３０は、共同ビデオ部会（ＪＶＴ）として知られる共同パートナーシップの成果物として、ＩＴＵ−Ｔ  Ｖｉｄｅｏ  Ｃｏｄｉｎｇ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ（ＶＣＥＧ）とＩＳＯ／ＩＥＣ  Ｍｏｔｉｏｎ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ（ＭＰＥＧ）とのＪｏｉｎｔ  Ｃｏｌｌａｂｏｒａｔｉｏｎ  Ｔｅａｍ  ｏｎ  Ｖｉｄｅｏ  Ｃｏｄｉｎｇ（ＪＣＴ−ＶＣ）によって現在開発中のＨｉｇｈ  Ｅｆｆｉｃｉｅｎｃｙ  Ｖｉｄｅｏ  Ｃｏｄｉｎｇ（ＨＥＶＣ）規格などのビデオコーディング規格に従って動作することができる。ＨＥＶＣ規格は、ＨＥＶＣテストモデル（ＨＭ）に準拠し得る。「ＨＥＶＣ  Ｗｏｒｋｉｎｇ  Ｄｒａｆｔ  ６」または「ＷＤ６」と呼ばれる、ＨＥＶＣ規格の最新の草案は、ＪＣＴＶＣ−Ｈ１００３、Ｂｒｏｓｓら、「Ｈｉｇｈ  ｅｆｆｉｃｉｅｎｃｙ  ｖｉｄｅｏ  ｃｏｄｉｎｇ  （ＨＥＶＣ）  ｔｅｘｔ  ｓｐｅｃｉｆｉｃａｔｉｏｎ  ｄｒａｆｔ  ６」、ＩＴＵ−Ｔ  ＳＧ１６  ＷＰ３およびＩＳＯ／ＩＥＣ  ＪＴＣ１／ＳＣ２９／ＷＧ１１のＪｏｉｎｔ  Ｃｏｌｌａｂｏｒａｔｉｖｅ  Ｔｅａｍ  ｏｎ  Ｖｉｄｅｏ  Ｃｏｄｉｎｇ（ＪＣＴ−ＶＣ）、８ｔｈ  Ｍｅｅｔｉｎｇ：米国カリフォルニア州サンノゼ、２０１２年２月の文書に記載されている。
【００２８】
[0035]  ただし、本開示の技法は、いかなる特定のコーディング規格にも限定されない。図１には示されていないが、いくつかの態様では、ビデオエンコーダ２０およびビデオデコーダ３０は各々、オーディオエンコーダおよびオーディオデコーダと統合されてよく、適切なＭＵＸ−ＤＥＭＵＸユニット、または他のハードウェアとソフトウェアとを含んで、共通のデータストリームまたは別個のデータストリーム中のオーディオとビデオの両方の符号化を処理することができる。適用可能な場合、ＭＵＸ−ＤＥＭＵＸユニットはＩＴＵ  Ｈ．２２３マルチプレクサプロトコル、またはユーザデータグラムプロトコル（ＵＤＰ：user datagram protocol）などの他のプロトコルに準拠することができる。
【００２９】
[0036]  ビデオエンコーダ２０およびビデオデコーダ３０はそれぞれ、１つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ディスクリート論理、ソフトウェア、ハードウェア、ファームウェアなど、様々な好適なエンコーダ回路のいずれか、またはそれらの任意の組合せとして実装され得る。本技法がソフトウェアで部分的に実装されるとき、デバイスは、好適な非一時的コンピュータ可読媒体にソフトウェアの命令を記憶し、１つまたは複数のプロセッサを使用してその命令をハードウェアで実行して、本開示の技法を実行し得る。ビデオエンコーダ２０およびビデオデコーダ３０の各々は１つまたは複数のエンコーダまたはデコーダ中に含まれてよく、そのいずれも、それぞれのデバイスにおいて複合エンコーダ／デコーダ（コーデック）の一部として統合されてよい。
【００３０】
[0037]  ＪＣＴ−ＶＣは、ＨＥＶＣ規格の開発に取り組んでいる。ＨＥＶＣ規格化の取り組みは、ＨＥＶＣテストモデル（ＨＭ）と呼ばれるビデオコーディングデバイスの発展的モデルに基づく。ＨＭは、既存の規格に関して、いくつかの追加能力を仮定する。たとえば、Ｈ．２６４は９個のイントラ予測符号化モード（intra-prediction encoding mode）を提供するが、ＨＭは３３個ものイントラ予測符号化モードを提供し得る。
【００３１】
[0038]  概して、ＨＭは、ビデオフレームまたはピクチャが、ルーマサンプルとクロマサンプルの両方を含む一連のツリーブロックまたは最大コーディングユニット（ＬＣＵ：largest coding unit）に分割され得ることを記載している。ビットストリーム内のシンタックスデータは、ピクセルの数に関して最大コーディングユニットであるＬＣＵ用のサイズを確定することができる。スライスは、コーディング順序でいくつかの連続的なツリーブロックを含む。ビデオフレームまたはピクチャは、１つまたは複数のスライスに区分され得る。各ツリーブロックは、四分木によるコーディングユニット（ＣＵ：coding unit）に分けることができる。一般に、４分木データ構造はＣＵごとに１つのノードを含み、ルートノードはツリーブロックに対応する。ＣＵが４つのサブＣＵに分割された場合、ＣＵに対応するノードは４つのリーフノードを含み、リーフノードの各々はサブＣＵのうちの１つに対応する。
【００３２】
[0039]  ４分木データ構造の各ノードは、対応するＣＵにシンタックスデータを提供することができる。たとえば、４分木のノードは、そのノードに対応するＣＵがサブＣＵに分割されるかどうかを示す分割フラグを含み得る。ＣＵのシンタックス要素は、再帰的に定義されてよく、ＣＵがサブＣＵに分割されるかどうかに依存し得る。ＣＵがこれ以上分割されない場合、そのＣＵはリーフＣＵと呼ばれる。本開示では、元のリーフＣＵの明示的な分割が存在しない場合でも、リーフＣＵの４つのサブＣＵをリーフＣＵとも呼ぶ。たとえば、１６×１６サイズのＣＵがさらに分割されない場合、この１６×１６ＣＵが決して分割されなくても、４つの８×８サブＣＵをリーフＣＵとも呼ぶ。
【００３３】
[0040]  ＣＵは、ＣＵがサイズ差異を有しないことを除いて、Ｈ．２６４規格のマクロブロックと同様の目的を有する。たとえば、ツリーブロックは、４つの子ノード（サブＣＵとも呼ばれる）に分割されてよく、各子ノードは、今度は親ノードとなり、別の４つの子ノードに分割されてよい。４分木のリーフノードと呼ばれる、最後の分割されていない子ノードは、リーフＣＵとも呼ばれるコーディングノードを備える。コード化ビットストリームに関連するシンタックスデータは、最大ＣＵ深度と呼ばれる、ツリーブロックが分割され得る最大回数を定義し得、また、コーディングノードの最小サイズを定義し得る。それに応じて、ビットストリームは最小コーディングユニット（ＳＣＵ：smallest coding unit）も定義することができる。本開示は、ＨＥＶＣのコンテキストにおけるＣＵ、ＰＵ、もしくはＴＵ、または他の規格のコンテキストにおける同様のデータ構造（たとえば、Ｈ．２６４／ＡＶＣにおけるマクロブロックおよびそのサブブロック）のいずれかを指すために「ブロック」という用語を使用する。
【００３４】
[0041]  ＣＵは、コーディングノードと、コーディングノードに関連する予測ユニット（ＰＵ：prediction unit）および変換ユニット（ＴＵ：transform unit）とを含む。ＣＵのサイズは、コーディングノードのサイズに対応し、正方形でなければならない。ＣＵのサイズは、８×８ピクセルから最大６４×６４以上のピクセルをもつツリーブロックのサイズまでに及び得る。各ＣＵは、１つまたは複数のＰＵと、１つまたは複数のＴＵとを含んでいることがある。ＣＵに関連するシンタックスデータは、たとえば、ＣＵを１つまたは複数のＰＵに区分することを記述し得る。区分モード（partitioning mode）は、ＣＵが、スキップモードもしくはダイレクトモードで符号化されるか、イントラ予測モード（intra-prediction）で符号化されるか、またはインター予測モード（inter-prediction mode）で符号化されるかの間で異なる場合がある。ＰＵは、形状が非正方形になるように区分され得る。ＣＵに関連するシンタックスデータは、たとえば、４分木に従って、ＣＵを１つまたは複数のＴＵに区分することも記述し得る。ＴＵは、形状が正方形または非正方形（たとえば、矩形）であり得る。
【００３５】
[0042]  ＨＥＶＣ規格は、ＣＵごとに異なり得るＴＵに従った変換を可能にする。ＴＵは、一般に、区分されたＬＣＵについて定義された所与のＣＵ内のＰＵのサイズに基づいてサイズ決定されるが、常にそうであるとは限らない。ＴＵは、一般にＰＵと同じサイズであるかまたはＰＵよりも小さい。いくつかの例では、ＣＵに対応する残差サンプルは、残差４分木（ＲＱＴ：residual quadtree）として知られる４分木構造を使用してより小さいユニットに再分割され得る。ＲＱＴのリーフノードは変換ユニット（ＴＵ）と呼ばれ得る。ＴＵに関連するピクセル差分値は、変換係数を生成するように変換されてよく、その変換係数は量子化され得る。
【００３６】
[0043]  リーフＣＵは、１つまたは複数の予測ユニット（ＰＵ）を含み得る。概して、ＰＵは、対応するＣＵの全部または一部分に対応する空間的エリアを表し、そのＰＵの参照サンプルを取り出すためのデータを含み得る。その上、ＰＵは、予測に関係するデータを含む。たとえば、ＰＵがイントラモード符号化されるとき、ＰＵのデータは、ＰＵに対応するＴＵのイントラ予測モードを記述するデータを含み得る、残差４分木（ＲＱＴ）中に含まれ得る。別の例として、ＰＵがインターモード符号化されるとき、ＰＵは、ＰＵのための１つまたは複数の動きベクトルを定義するデータを含み得る。ＰＵについての動きベクトルを定義するデータは、たとえば、動きベクトルの水平成分、動きベクトルの垂直成分、動きベクトルの解像度（たとえば、１／４ピクセル精度または１／８ピクセル精度）、動きベクトルが指す参照ピクチャ、および／または動きベクトルの参照ピクチャリスト（たとえば、リスト０またはリスト１）を記述し得る。
【００３７】
[0044]  １つまたは複数のＰＵを有するリーフＣＵはまた、１つまたは複数の変換ユニット（ＴＵ）を含むことができる。変換ユニットは、上記で説明したように、（ＴＵ４分木構造とも呼ばれる）ＲＱＴを使用して指定され得る。たとえば、分割フラグは、リーフＣＵが４つの変換ユニットに分割されるかどうかを示し得る。次いで、各変換ユニットはさらに、さらなるサブＴＵに分割され得る。ＴＵがこれ以上分割されないとき、そのＴＵはリーフＴＵと呼ぶことができる。一般に、イントラコーディングの場合、リーフＣＵに属するすべてのリーフＴＵは同じイントラ予測モードを共有する。すなわち、一般に、リーフＣＵのすべてのＴＵの予測値を計算するために同じイントラ予測モードが適用される。イントラコーディングの場合、ビデオエンコーダは、イントラ予測モードを使用して各リーフＴＵの残差値を、ＴＵに対応するＣＵの一部と元のブロックとの間の差分として計算し得る。ＴＵは、必ずしもＰＵのサイズに制限されるとは限らない。したがって、ＴＵは、ＰＵよりも大きいことも小さいこともある。イントラコーディングの場合、ＰＵは、同じＣＵの対応するリーフＴＵとコロケートされ得る。いくつかの例では、リーフＴＵの最大サイズは、対応するリーフＣＵのサイズに該当する場合がある。
【００３８】
[0045]  その上、リーフＣＵのＴＵはまた、残差４分木（ＲＱＴ）と呼ばれる、それぞれの４分木データ構造に関連付けられ得る。すなわち、リーフＣＵは、リーフＣＵがどのようにＴＵに区分されるかを示す４分木を含み得る。ＴＵ４分木のルートノードは一般にリーフＣＵに対応し、ＣＵ４分木のルートノードは一般にツリーブロック（またはＬＣＵ）に対応する。分割されないＲＱＴのＴＵはリーフＴＵと呼ばれる。全般に、本開示では、別段明記されない限り、リーフＣＵおよびリーフＴＵに言及するためにそれぞれＣＵおよびＴＵという用語を使用する。
【００３９】
[0046]  ビデオシーケンスは通常、一連のビデオフレームまたはピクチャを含む。ピクチャグループ（ＧＯＰ）は、一般に、ビデオピクチャのうちの一連の１つまたは複数を備える。ＧＯＰは、ＧＯＰ中に含まれるいくつかのピクチャを記述するシンタックスデータを、ＧＯＰのヘッダ中、ピクチャのうちの１つまたは複数のヘッダ中、または他の場所に含み得る。ピクチャの各スライスは、それぞれのスライスのための符号化モードを記述するスライスシンタックスデータを含み得る。ビデオエンコーダ２０は、通常、ビデオデータを符号化するために、個々のビデオスライス内のビデオブロックに対して動作する。ビデオブロックは、ＣＵ内のコーディングノードに対応し得る。ビデオブロックは、サイズを固定することも変更することもでき、指定のコーディング規格に応じてサイズが異なることがある。
【００４０】
[0047]  一例として、ＨＭは、様々なＰＵサイズでの予測をサポートする。特定のＣＵのサイズが２Ｎ×２Ｎであると仮定すると、ＨＭは、２Ｎ×２ＮまたはＮ×ＮのＰＵサイズでのイントラ予測をサポートし、２Ｎ×２Ｎ、２Ｎ×Ｎ、Ｎ×２Ｎ、またはＮ×Ｎの対称的なＰＵサイズでのインター予測をサポートする。ＨＭはまた、２Ｎ×ｎＵ、２Ｎ×ｎＤ、ｎＬ×２Ｎ、およびｎＲ×２ＮのＰＵサイズでのインター予測のための非対称区分をサポートする。非対称区分では、ＣＵの一方向は区分されないが、他の方向は２５％と７５％とに区分される。２５％の区分に対応するＣＵの部分は、「ｎ」とその後ろに付く「Ｕｐ」、「Ｄｏｗｎ」、「Ｌｅｆｔ」、または「Ｒｉｇｈｔ」という表示によって示される。したがって、たとえば、「２Ｎ×ｎＵ」は、上部の２Ｎ×０．５Ｎ  ＰＵと下部の２Ｎ×１．５Ｎ  ＰＵとで水平方向に区分された２Ｎ×２Ｎ  ＣＵを指す。
【００４１】
[0048]  本開示では、「Ｎ×Ｎ（NxN）」および「Ｎ×Ｎ（N by N）」は、垂直寸法および水平寸法に関するビデオブロックのピクセル寸法、たとえば、１６×１６（16x16）ピクセルまたは１６×１６（16 by 16）ピクセルを指すために互換的に使用され得る。概して、１６×１６ブロックは、垂直方向に１６ピクセルを有し（ｙ＝１６）、水平方向に１６ピクセルを有する（ｘ＝１６）。同様に、Ｎ×Ｎブロックは、概して、垂直方向にＮピクセルを有し、水平方向にＮピクセルを有し、ここでＮは非負整数値を表す。ブロック中のピクセルは行と列に構成され得る。その上、ブロックは、必ずしも、水平方向において垂直方向と同じ数のピクセルを有する必要があるとは限らない。たとえば、ブロックはＮ×Ｍのピクセルを備える場合があり、ここで、Ｍは必ずしもＮに等しいとは限らない。
【００４２】
[0049]  ＣＵのＰＵを使用したイントラ予測コーディングまたはインター予測コーディングの後、ビデオエンコーダ２０は、ＣＵのＴＵのための残差データを計算し得る。ＰＵは、（ピクセル領域とも呼ばれる）空間領域において予測ピクセルデータを生成する方法またはモードを記述するシンタックスデータを備えてよく、ＴＵは、変換、たとえば、残差ビデオデータへの離散コサイン変換（ＤＣＴ）、整数変換、ウェーブレット変換、または概念的に同様の変換の適用後の、変換領域における係数を備え得る。残差データは、符号化されていないピクチャのピクセルと、ＰＵに対応する予測値との間のピクセル差分に対応し得る。ビデオエンコーダ２０は、ＣＵ用の残差データを含むＴＵを形成し、次いで、ＴＵを変換して、ＣＵ用の変換係数を生成することができる。
【００４３】
[0050]  変換係数を生成するための任意の変換の後に、ビデオエンコーダ２０は、変換係数の量子化を実行し得る。量子化は、概して、さらなる圧縮を提供する、係数を表すために使用されるデータの量をできるだけ低減するために変換係数を量子化するプロセスを指す。量子化プロセスは、係数の一部または全部に関連するビット深度（bit depth）を低減させることができる。たとえば、量子化中にｎビット値がｍビット値に切り捨てられてよく、ただし、ｎはｍよりも大きい。
【００４４】
[0051]  量子化の後に、ビデオエンコーダは、変換係数を走査して、量子化変換係数を含む２次元行列から１次元ベクトルを生成し得る。走査は、より高いエネルギー（したがってより低い周波数）の係数をアレイの前方に配置し、より低いエネルギー（したがってより高い周波数）の係数をアレイの後方に配置するように設計され得る。いくつかの例では、ビデオエンコーダ２０は、あらかじめ定義された走査順序を利用して、量子化された変換係数を走査し、エントロピー符号化され得る直列化されたベクトルを生成し得る。他の例では、ビデオエンコーダ２０は適応走査を実行し得る。量子化された変換係数を走査して１次元ベクトルを形成した後に、ビデオエンコーダ２０は、たとえば、コンテキスト適応可変長コーディング（ＣＡＶＬＣ：context-adaptive variable length coding）、コンテキスト適応バイナリ算術コーディング（ＣＡＢＡＣ：context-adaptive binary arithmetic coding）、シンタックスベースコンテキスト適応バイナリ算術コーディング（ＳＢＡＣ：syntax-based context-adaptive binary arithmetic coding）、確率間隔区分エントロピー（ＰＩＰＥ：Probability Interval Partitioning Entropy）コーディング、または別のエントロピー符号化方法に従って、１次元ベクトルをエントロピー符号化し得る。ビデオエンコーダ２０はまた、ビデオデータを復号する際にビデオデコーダ３０が使用するための、符号化ビデオデータに関連するシンタックス要素をエントロピー符号化し得る。
【００４５】
[0052]  ＣＡＢＡＣを実行するために、ビデオエンコーダ２０は、送信されるべきシンボルに、コンテキストモデル内のコンテキストを割り当て得る。コンテキストは、たとえば、シンボルの隣接値が非０であるか否かに関係し得る。ＣＡＶＬＣを実行するために、ビデオエンコーダ２０は、送信されるべきシンボルの可変長コードを選択し得る。ＶＬＣにおけるコードワードは、比較的短いコードが優勢シンボルに対応し、より長いコードが劣勢シンボルに対応するように構成され得る。このようにして、ＶＬＣの使用は、たとえば、送信されるべき各シンボルのために等長コードワードを使用するよりも、ビット節約を達成し得る。確率判断は、シンボルに割り当てられるコンテキストに基づき得る。
【００４６】
[0053]  ビデオエンコーダ２０は、さらに、ブロックベースのシンタックスデータ、フレームベースのシンタックスデータ、およびＧＯＰベースのシンタックスデータなどのシンタックスデータを、たとえば、フレームヘッダ、ブロックヘッダ、スライスヘッダ、またはＧＯＰヘッダ中でビデオデコーダ３０に送り得る。ＧＯＰシンタックスデータは、それぞれのＧＯＰ内のフレームの数を記述することができ、フレームシンタックスデータは、対応するフレームを符号化するために使用される符号化／予測モードを示すことができる。
【００４７】
[0054]  ビデオエンコーダ２０およびビデオデコーダ３０はそれぞれ、適用可能なとき、１つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ディスクリート論理回路、ソフトウェア、ハードウェア、ファームウェアなど、様々な好適なエンコーダまたはデコーダ回路のいずれか、あるいはそれらの任意の組合せとして実装され得る。ビデオエンコーダ２０およびビデオデコーダ３０の各々は１つまたは複数のエンコーダまたはデコーダ中に含まれ得、そのいずれも複合ビデオエンコーダ／デコーダ（コーデック）の一部として統合され得る。ビデオエンコーダ２０および／またはビデオデコーダ３０を含むデバイスは、集積回路、マイクロプロセッサ、および／またはセルラー電話などのワイヤレス通信デバイスを備え得る。
【００４８】
[0055]  ビデオエンコーダ２０およびビデオデコーダ３０は、本開示で説明される技法のうち１つまたは複数を実装するように構成され得る。一例として、ビデオエンコーダ２０は、ビットストリームの部分においてパラメータセットの更新が起こり得るかどうかの指示を符号化するように構成されてよい。ビデオデコーダ３０は、記憶されたパラメータセットと、同じタイプであるとともに同じ識別値をもつ新たなパラメータセットとの間の内容比較を実行せずに、記憶されたパラメータセットの更新が起こり得るかどうか判断するための指示を復号するように構成され得る。パラメータセットの更新が起こると、ビデオデコーダ３０は、同じタイプであるとともに同じ識別値を有する前のパラメータセットを置き換えるために、所与の識別値をもつ現在のパラメータセットを記憶する。指示が適用される、ビットストリームの部分は、ビットストリームのコード化ビデオシーケンスであっても、ビットストリームのコード化ビデオシーケンス中のＧＯＰであり得る。
【００４９】
[0056]  あるケースでは、指示は、ビットストリームの部分において任意のタイプの任意のパラメータセットが更新され得るかどうかを示す、ビットストリーム中の、フラグなどのシンタックス要素を備え得る。別のケースでは、指示は、ビットストリームの部分において特定のタイプのパラメータセットが更新され得るかどうかを各々が示す、いくつかの異なるフラグをビットストリーム中に備え得る。いずれのケースでも、パラメータセットの更新が起こり得ないことをフラグが示すとき、ビデオデコーダ３０は、ビットストリームの部分全体について、所与のタイプの単一のパラメータセットを記憶し、アクティブ化すればよい。初期パラメータセットと同じタイプであるとともに同じ識別値を有する後続のパラメータセットを受信すると、ビデオデコーダ３０は、後続のパラメータセットを無視することができる。逆に、パラメータセットの更新が起こり得ることをフラグが示すとき、ビデオデコーダ３０は、新たなパラメータセットを自動的にアクティブ化し、所与のタイプの記憶されたパラメータセットを非アクティブ化してもよく、たとえば、内容比較を実行することによって、記憶されたパラメータを更新するかどうか判断することができる。
【００５０】
[0057]  別の例として、ビデオエンコーダ２０は、ビットストリーム中の特定のＣＲＡアクセスユニットからのランダムアクセスの実行に、前のアクセスユニットからのパラメータセットのフェッチングが必要とされるかどうかの指示を符号化するように構成され得る。ビデオデコーダ３０は、指示を復号して、前のアクセスユニットに含まれるパラメータセットが、特定のＣＲＡピクチャからのランダムアクセスを実行するのに必要とされるかどうか判断するように構成され得る。いくつかのケースでは、指示は、ビットストリーム中の、各ＣＲＡピクチャ用のアクセスユニットに含まれるＮＡＬユニットペイロードに含まれる、フラグなどのシンタックス要素を備え得る。
【００５１】
[0058]  ＣＲＡアクセスユニットは、コード化ビデオシーケンス内のどのポイントで生じてもよく、ＤＰＢをクリーン（clean）にしないので、コーディング効率の低下なしで、ビットストリームへのランダムアクセスのためのより多くの選択肢を提供する。ＣＲＡピクチャからのランダムアクセスのケースでは、出力または復号順序でＣＲＡピクチャに先行するすべてのピクチャは、復号されず、参照ピクチャとしての使用に対応不可能である。ＣＲＡピクチャまたは任意の、出力または復号順序が後のピクチャを復号するために、ビデオデコーダは、利用不可能な前のピクチャについての１つについてのアクセスユニットに含まれる１つまたは複数のパラメータセットをフェッチする必要がある場合があるが、これは面倒な動作である。本開示の技法のいくつかによると、前のアクセスユニットからのどのパラメータセットも、特定のＣＲＡピクチャからのランダムアクセスには必要とされないことをフラグが示すとき、ビデオデコーダ３０は、フェッチング動作が要求されないので、そのピクチャからのランダムアクセスを実行すると決定することができる。逆に、前のアクセスユニットからのパラメータセットが、特定のＣＲＡピクチャからのランダムアクセスに必要とされることをフラグが示すとき、ビデオデコーダ３０は、フェッチング動作を避けるために、そのピクチャからのランダムアクセスを実行しないと決定することができる。主にＣＲＡピクチャを参照して記載するが、本技法は、ＩＤＲピクチャおよび漸進的復号リフレッシュ（ＧＤＲ）ピクチャを含む、他のタイプのＲＡＰピクチャにも同様に使うことができる。
【００５２】
[0059]  図２は、本開示で説明する技法を実装し得るビデオエンコーダ２０の例を示すブロック図である。ビデオエンコーダ２０は、ビデオスライス内のビデオブロックのイントラコーディングおよびインターコーディングを実行し得る。イントラコーディングは、空間的予測を利用して、所与のビデオフレームまたはピクチャ内のビデオの空間的冗長性を低減または除去する。インターコーディングは、時間的予測を利用して、ビデオシーケンスの隣接フレームまたはピクチャ内のビデオの時間的冗長性を低減または除去する。イントラモード（Ｉモード）は、いくつかの空間ベースのコーディングモードのいずれかを指し得る。単方向予測（Ｐモード）または双方向予測（Ｂモード）などのインターモードは、いくつかの時間ベースのコーディングモードのいずれかを指し得る。
【００５３】
[0060]  図２に示すように、ビデオエンコーダ２０は、符号化されるべきビデオフレーム内の現在ビデオブロックを受信する。図２の例では、ビデオエンコーダ２０は、モード選択ユニット４０と、参照ピクチャメモリ６４と、加算器５０と、変換処理ユニット５２と、量子化ユニット５４と、エントロピー符号化ユニット５６とを含む。モード選択ユニット４０は、動き補償ユニット４４と、動き推定ユニット４２と、イントラ予測処理ユニット４６と、区分ユニット４８とを含む。ビデオブロックの再構成のために、ビデオエンコーダ２０はまた、逆量子化ユニット５８と、逆変換処理ユニット６０と、加算器６２とを含む。
【００５４】
[0061]  符号化プロセス中に、ビデオエンコーダ２０はコーディングされるべきビデオフレームまたはスライスを受信する。フレームまたはスライスは、複数のビデオブロックに分割され得る。動き推定ユニット４２および動き補償ユニット４４は、時間的予測を行うために、１つまたは複数の参照フレーム中の１つまたは複数のブロックに対して、受信されたビデオブロックのインター予測コーディングを実行する。イントラ予測処理ユニット４６は、代替的に、空間的予測を行うために、コーディングされるべきブロックと同じフレームまたはスライス中の１つまたは複数の隣接ブロックに対して受信されたビデオブロックのイントラ予測コーディングを実行し得る。ビデオエンコーダ２０は、たとえば、ビデオデータの各ブロックのための適切なコーディングモードを選択するために、複数のコーディングパスを実行し得る。
【００５５】
[0062]  その上、区分ユニット４８は、以前のコーディングパスにおける以前の区分方式の評価に基づいて、ビデオデータのブロックをサブブロックに区分し得る。たとえば、区分ユニット４８は、初めにフレームまたはスライスをＬＣＵに区分し、レートひずみ分析（たとえば、レートひずみ最適化）に基づいてＬＣＵの各々をサブＣＵに区分し得る。モード選択ユニット４０は、ＬＣＵをサブＣＵに区分することを示す４分木データ構造をさらに生成し得る。４分木のリーフノードＣＵは、１つまたは複数のＰＵと、１つまたは複数のＴＵとを含む場合がある。
【００５６】
[0063]  モード選択ユニット４０は、たとえば、誤差結果に基づいてコーディングモード、すなわち、イントラまたはインターのうちの１つを選択し、残差ブロックデータを生成するために、得られたイントラコード化ブロックまたはインターコード化ブロックを加算器５０に与え、参照フレームとして使用するための符号化ブロックを再構成するために、得られたイントラコード化ブロックまたはインターコード化ブロックを加算器６２に与え得る。モード選択ユニット４０はまた、動きベクトル、イントラモードインジケータ、パーティション情報、および他のそのようなシンタックス情報などのシンタックス要素をエントロピー符号化ユニット５６に与える。
【００５７】
[0064]  動き推定ユニット４２と動き補償ユニット４４とは、高度に統合され得るが、概念的な目的のために別々に示してある。動き推定ユニット４２によって実行される動き推定は、ビデオブロックの動きを推定する動きベクトルを生成するプロセスである。動きベクトルは、たとえば、現在のフレーム（または他のコード化ユニット）内でコーディングされている現在のブロックに対する参照フレーム（または他のコード化ユニット）内の予測ブロックに対して現在のビデオフレームまたはピクチャ内のビデオブロックのＰＵの変位を示し得る。予測ブロックは、絶対値差分和（ＳＡＤ：sum of absolute difference）、２乗差分和（ＳＳＤ：sum of square difference）、または他の差分尺度によって決定され得るピクセル差分に関して、コーディングされるブロックに精密に一致することがわかっているブロックである。いくつかの例では、ビデオエンコーダ２０は、復号ピクチャバッファ（ＤＰＢ：decoded picture buffer）と呼ばれることもある参照ピクチャメモリ６４に記憶された参照ピクチャのサブ整数ピクセル位置の値を計算し得る。たとえば、ビデオエンコーダ２０は、参照ピクチャの１／４ピクセル位置、１／８ピクセル位置、または他の分数ピクセル位置の値を補間することができる。したがって、動き推定ユニット４２は、フルピクセル位置と分数ピクセル位置とに対する動き探索を実行し、分数ピクセル精度で動きベクトルを出力し得る。
【００５８】
[0065]  動き推定ユニット４２は、ＰＵの位置を参照ピクチャの予測ブロックの位置と比較することによって、インターコード化スライス中のビデオブロックのＰＵについての動きベクトルを計算する。参照ピクチャは、第１の参照ピクチャリスト（リスト０）または第２の参照ピクチャリスト（リスト１）から選択されてよく、それらの参照ピクチャリストの各々は、参照ピクチャメモリ６４に記憶された１つまたは複数の参照ピクチャを識別する。動き推定ユニット４２は、計算された動きベクトルをエントロピー符号化ユニット５６と動き補償ユニット４４とに送る。
【００５９】
[0066]  動き補償ユニット４４によって実行される動き補償は、動き推定ユニット４２によって判断された動きベクトルに基づいて予測ブロックをフェッチまたは生成することに関与し得る。この場合も、いくつかの例では、動き推定ユニット４２と動き補償ユニット４４とは機能的に統合され得る。現在のビデオブロックのＰＵのための動きベクトルを受信すると、動き補償ユニット４４は、動きベクトルが参照ピクチャリストのうちの１つにおいて指す予測ブロックの位置を特定し得る。加算器５０は、以下で説明するように、コーディングされている現在のビデオブロックのピクセル値から予測ブロックのピクセル値を減算し、ピクセル差分値を形成することによって、残差ビデオブロックを形成する。概して、動き推定ユニット４２はルーマ成分に対して動き推定を実行し、動き補償ユニット４４は、クロマ成分とルーマ成分の両方のためにルーマ成分に基づいて計算された動きベクトルを使用する。モード選択ユニット４０はまた、ビデオスライスのビデオブロックを復号する際にビデオデコーダ３０が使用するためのビデオブロックとビデオスライスとに関連するシンタックス要素を生成し得る。
【００６０】
[0067]  イントラ予測処理ユニット４６は、上に記述したように、動き推定ユニット４２および動き補償ユニット４４によって実行されたインター予測の代替として、現在のブロックをイントラ予測することができる。特に、イントラ予測処理ユニット４６は、現在のブロックを符号化するために使用するためにイントラ予測モードを決定することができる。いくつかの例では、イントラ予測処理ユニット４６は、たとえば、別個の符号化パス中に、様々なイントラ予測モードを使用して現在ブロックを符号化し得、イントラ予測処理ユニット４６（または、いくつかの例では、モード選択ユニット４０）は、テストされたモードから使用するのに適切なイントラ予測モードを選択し得る。
【００６１】
[0068]  たとえば、イントラ予測処理ユニット４６は、様々なテストされたイントラ予測モードのためのレートひずみ分析を使用してレートひずみ値を計算し、テストされたモードの中で最良のレートひずみ特性を有するイントラ予測モードを選択し得る。レートひずみ分析は、一般に、符号化ブロックと、符号化ブロックを生成するために符号化された元の符号化されていないブロックとの間のひずみ（または誤差）の量、ならびに符号化ブロックを生成するために使用されるビットレート（すなわち、ビット数）を決定する。イントラ予測処理ユニット４６は、どのイントラ予測モードがブロックについて最良のレートひずみ値を呈するかを判断するために、様々な符号化ブロックのひずみおよびレートから比を計算し得る。
【００６２】
[0069]  ブロックのイントラ予測モードを選択した後、イントラ予測処理ユニット４６は、ブロックのために選択されたイントラ予測モードを示す情報を、エントロピー符号化ユニット５６に提供することができる。エントロピー符号化ユニット５６は、選択されたイントラ予測モードを示す情報を符号化することができる。ビデオエンコーダ２０は、送信ビットストリーム中に、複数のイントラ予測モードインデックステーブルおよび複数の修正されたイントラ予測モードインデックステーブル（コードワードマッピングテーブルとも呼ばれる）と、様々なブロックの符号化コンテキストの定義と、コンテキストの各々に対して使用すべき、最確イントラ予測モード、イントラ予測モードインデックステーブル、および修正されたイントラ予測モードインデックステーブルの指示とを含み得る、構成データを含み得る。
【００６３】
[0070]  ビデオエンコーダ２０は、コーディングされている元のビデオブロックから、モード選択ユニット４０からの予測データを減算することによって、残差ビデオブロックを形成する。加算器５０は、この減算演算を実行する１つまたは複数の構成要素を表す。変換処理ユニット５２は、離散コサイン変換（ＤＣＴ：discrete cosine transform）または概念的に同様の変換など、変換を残差ブロックに適用し、残差変換係数値を備えるビデオブロックを生成する。変換処理ユニット５２は、ＤＣＴと概念的に同様である他の変換を実行することができる。ウェーブレット変換、整数変換、サブバンド変換または他のタイプの変換も使用され得る。いずれの場合も、変換処理ユニット５２は、変換を残差ブロックに適用し、残差変換係数のブロックを生成する。変換は、残差情報をピクセル値領域から、周波数領域などの変換領域に変換することができる。変換処理ユニット５２は、得られた変換係数を量子化ユニット５４に送り得る。量子化ユニット５４は、ビットレートをさらに低減するために変換係数を量子化する。量子化プロセスは、係数の一部または全部に関連するビット深度を低減させることができる。量子化の程度は、量子化パラメータを調整することによって変更され得る。いくつかの例では、量子化ユニット５４は、次いで、量子化変換係数を含む行列の走査を実行し得る。代替的に、エントロピー符号化ユニット５６が走査を実行し得る。
【００６４】
[0071]  量子化の後、エントロピー符号化ユニット５６は、量子化変換係数をエントロピーコーディングする。たとえば、エントロピー符号化ユニット５６は、コンテキスト適応型可変長コーディング（ＣＡＶＬＣ）、コンテキスト適応型バイナリ算術コーディング（ＣＡＢＡＣ）、シンタックスベースコンテキスト適応型バイナリ算術コーディング（ＳＢＡＣ）、確率間隔区分エントロピー（ＰＩＰＥ）コーディングまたは別のエントロピーコーディング技法を実行することができる。コンテキストベースエントロピーコーディングの場合、コンテキストは隣接ブロックに基づき得る。エントロピー符号化ユニット５６によるエントロピーコーディングの後、符号化ビットストリームは、別のデバイス（たとえば、ビデオデコーダ３０）に送信されてよく、または後で送信するかもしくは取り出すために保管され得る。
【００６５】
[0072]  逆量子化ユニット５８および逆変換処理ユニット６０は、それぞれ逆量子化および逆変換を適用して、たとえば、参照ブロックとして後で使用するために、ピクセル領域中で残差ブロックを再構成する。動き補償ユニット４４は、残差ブロックを参照ピクチャメモリ６４のフレームのうちの１つの予測ブロックに加算することによって参照ブロックを計算し得る。動き補償ユニット４４はまた、再構成された残差ブロックに１つまたは複数の補間フィルタを適用して、動き推定において使用するためのサブ整数ピクセル値を計算し得る。加算器６２は、再構成された残差ブロックを、動き補償ユニット４４によって生成された動き補償予測ブロックに加算して、参照ピクチャメモリ６４に記憶するための再構成されたビデオブロックを生成する。
【００６６】
[0073]  図２のビデオエンコーダ２０は、本開示で説明される技法のうち１つまたは複数を実装するように構成されたビデオエンコーダの例を表す。本技法の一例において、ビデオエンコーダ２０は、ビットストリームの部分においてパラメータセットの更新が起こり得るかどうかの指示を符号化するように構成されてよい。指示は、記憶されたパラメータセットの更新が起こり得るかどうかをビデオデコーダに通知するために、ビデオエンコーダ２０によって生成することができる。このように、指示に基づいて、ビデオデコーダは最初に、たとえば、記憶されたアクティブパラメータセットと、同じタイプであるとともに同じ識別値をもつ新たなパラメータセットとの間の内容比較を実行することによって、ビットストリームの部分においてパラメータセットの更新が許可されるものなのかどうか判断してから、更新を実際に実行するかどうか判断する。
【００６７】
[0074]  いくつかのケースでは、指示は、ビットストリームの部分、たとえば、コード化ビデオシーケンスまたはＧＯＰについてのパラメータセットのいずれかが、更新され得るかどうかの単一の指示を備え得る。この場合、ビデオパラメータセット（ＶＰＳ）、シーケンスパラメータセット（ＳＰＳ）、ピクチャパラメータセット（ＰＰＳ）、および／または適応パラメータセット（ＡＰＳ）を含むすべてのタイプのパラメータセットに対して、同じ指示が使われてよい。他のケースでは、指示は、ビットストリームの部分において特定のタイプのパラメータセットが更新され得るかどうかを各々が示す、いくつかの異なる指示を備え得る。指示は、ビットストリームの部分に含まれるシンタックス要素など、ビットストリームレベルの指示であってよい。たとえば、指示は、ビットストリーム中の補足強調情報（ＳＥＩ）ネットワークアブストラクションレイヤ（ＮＡＬ）ユニットに含まれるフラグなどのシンタックス要素であってよい。別の例として、指示は、ビットストリーム中のシーケンスパラメータセット（ＳＰＳ）ＮＡＬユニットに含まれるフラグなどのシンタックス要素であってよい。
【００６８】
[0075]  他の例では、指示は、プロファイル定義中の要件であってよい。追加の例では、ビデオビットストリームが、メディアデータ移送にリアルタイムトランスポートプロトコル（ＲＴＰ：real-time transport protocol）を使うストリーミングやマルチキャストなど、ＲＴＰに基づく送信環境において使われるとき、指示は、メディアタイプパラメータとして定義され、セッション記述プロトコル（ＳＤＰ：session description protocol）に含まれ得る。この場合、指示は、能力交換としても知られるセッション否定フェーズにおいて使われ得る。さらに他の例では、指示は、ＤＡＳＨなどのハイパーテキスト転送プロトコル（ＨＴＴＰ：hypertext transfer protocol）ストリーミング環境におけるメディアプレゼンテーション記述（ＭＰＤ：media presentation description）に含まれるストリームプロパティとして定義され得る。
【００６９】
[0076]  本技法の別の例では、ビデオエンコーダ２０は、ＣＲＡアクセスユニットからのビットストリームへのランダムアクセスの実行に、前のアクセスユニットからのパラメータセットのフェッチングが要求されるかどうかという、各ＣＲＡピクチャについての指示を符号化するように構成され得る。指示は、前のアクセスユニットに含まれるパラメータセットが、特定のＣＲＡアクセスユニットからのランダムアクセスを実行するのに必要とされるかどうかをビデオデコーダに通知するために、ビデオエンコーダ２０によって生成され得る。このように、指示に基づいて、ビデオデコーダは最初に、特定のＣＲＡアクセスユニットからのランダムアクセス復号にフェッチング動作が要求されるかどうか判断し、ランダムアクセスをそこから実行するための異なるＲＡＰピクチャを選択することによってフェッチング動作を実行するのを避けることができる。指示は、ＨＥＶＣ規格において採り入れられているＣＲＡアクセスユニットに特に有用であり、というのは、ＣＲＡピクチャが、コード化ビデオシーケンス内のどのポイントに配置されてもよく、ＤＰＢをクリーン（clean）にしないからであり、このことは、コーディング効率を低下することなく、ビットストリームへのランダムアクセスのためのより多くの選択肢を提供する。
【００７０】
[0077]  いくつかのケースでは、指示は、ビットストリーム中の各ＣＲＡピクチャ用のアクセスユニットに含まれる特定のタイプのＮＡＬユニット、たとえば、特定のタイプのＳＰＳ、ＳＥＩまたはアクセスユニットデリミタＮＡＬユニットを備え得る。他のケースでは、指示は、ＮＡＬユニットペイロード、たとえば、ＳＰＳ、ＳＥＩもしくはアクセスユニットデリミタＮＡＬユニットペイロード、またはビットストリーム中の各ＣＲＡピクチャ用のアクセスユニットに含まれるＮＡＬユニットヘッダに含まれる、フラグなどのシンタックス要素を備え得る。一例では、指示は、ＣＲＡピクチャ用のアクセスユニット中のＳＥＩ  ＮＡＬユニットに含まれるフラグを備え得る。主にＣＲＡピクチャを参照して記載するが、ビデオエンコーダ２０は、ＩＤＲピクチャおよび漸進的復号リフレッシュ（ＧＤＲ）ピクチャを含む、他のタイプのＲＡＰピクチャについての同様の指示を符号化することができる。
【００７１】
[0078]  図３は、符号化ビデオシーケンスを復号するビデオデコーダ３０の一例を示すブロック図である。図３の例では、ビデオデコーダ３０は、エントロピー復号ユニット７０と、動き補償ユニット７２と、イントラ予測処理ユニット７４と、逆量子化ユニット７６と、逆変換処理ユニット７８と、加算器８０と、参照ピクチャメモリ８２とを含む。ビデオデコーダ３０は、いくつかの例では、ビデオエンコーダ２０（図２）に関して説明された符号化パスとは全般に逆の復号パスを実行し得る。
【００７２】
[0079]  復号プロセス中に、ビデオデコーダ３０は、ビデオエンコーダ２０から、符号化ビデオスライスのビデオブロックと、関連するシンタックス要素とを表す符号化ビデオビットストリームを受信する。ビデオデコーダ３０は、ネットワークエンティティ２９から符号化ビデオビットストリームを受信することができる。ネットワークエンティティ２９は、たとえば、ストリーミングサーバ、メディアアウェアネットワーク要素（ＭＡＮＥ）、ビデオエディタ／スプライサ、中間ネットワーク要素、または上述した技法のうち１つもしくは複数を実装するように構成された他のそのようなデバイスであってよい。ネットワークエンティティ２９は、本開示の技法のうちいくつかを実行するように構成された外部手段を含み得る。本開示に記載する技法のうちいくつかは、ネットワークエンティティ２９が符号化ビデオビットストリームをビデオデコーダ３０に送信するのに先立って、ネットワークエンティティ２９によって実装され得る。いくつかのビデオ復号システムでは、ネットワークエンティティ２９およびビデオデコーダ３０は、別個のデバイスの部品であってよく、他の事例では、ネットワークエンティティ２９を参照して記載した機能性は、ビデオデコーダ３０を備える同じデバイスによって実行することができる。
【００７３】
[0080]  ビデオデコーダ３０のエントロピー復号ユニット７０は、量子化係数、動きベクトルまたはイントラ予測モードインジケータ、および他のシンタックス要素を生成するためにビットストリームをエントロピー復号する。エントロピー復号ユニット７０は、動きベクトルと他の予測シンタックス要素とを動き補償ユニット７２に転送する。ビデオデコーダ３０は、ビデオスライスレベルおよび／またはビデオブロックレベルでシンタックス要素を受信し得る。
【００７４】
[0081]  ビデオスライスがイントラコード化（Ｉ）スライスとしてコーディングされるとき、イントラ予測処理ユニット７４は、シグナリングされたイントラ予測モードと、現在のフレームまたはピクチャの、前に復号されたブロックからのデータとに基づいて、現在のビデオスライスのビデオブロックのための予測データを生成し得る。ビデオフレームがインターコード化（すなわち、ＢまたはＰ）スライスとしてコーディングされるとき、動き補償ユニット７２は、エントロピー復号ユニット７０から受信された動きベクトルと他のシンタックス要素とに基づいて、現在のビデオスライスのビデオブロックのための予測ブロックを生成する。予測ブロックは、参照ピクチャリストの１つの中の参照ピクチャの１つから生成され得る。ビデオデコーダ３０は、復号ピクチャバッファ（ＤＰＢ）と呼ばれ得る参照フレームメモリ８２に記憶された参照ピクチャに基づいて、参照フレームリスト、すなわちリスト０およびリスト１を構築し得る。
【００７５】
[0082]  動き補償ユニット７２は、動きベクトルと他のシンタックス要素とを解析することによって現在ビデオスライスのビデオブロックについての予測情報を判断し、予測情報を使用して、復号されている現在ビデオブロックのための予測ブロックを生成する。たとえば、動き補償ユニット７２は、ビデオスライスのビデオブロックをコーディングするために使用される予測モード（たとえば、イントラまたはインター予測）と、インター予測スライスタイプ（たとえば、ＢスライスまたはＰスライス）と、スライスの参照ピクチャリストのうちの１つまたは複数についての構成情報と、スライスの各インター符号化ビデオブロックについての動きベクトルと、スライスの各インターコード化ビデオブロックについてのインター予測ステータスと、現在ビデオスライス中のビデオブロックを復号するための他の情報とを判断するために、受信されたシンタックス要素のいくつかを使用する。
【００７６】
[0083]  動き補償ユニット７２はまた、補間フィルタに基づいて補間を実行し得る。動き補償ユニット７２は、ビデオブロックの符号化中にビデオエンコーダ２０によって使用された補間フィルタを使用して、参照ブロックのサブ整数ピクセルのための補間された値を計算し得る。この場合、動き補償ユニット７２は、受信されたシンタックス要素からビデオエンコーダ２０によって使用された補間フィルタを判断し、その補間フィルタを使用して予測ブロックを生成し得る。
【００７７】
[0084]  逆量子化ユニット７６は、ビットストリーム中で与えられ、エントロピー復号ユニット７０によって復号された、量子化変換係数を逆量子化（inverse quantize）、すなわち、逆量子化（de-quantize）する。逆量子化プロセスは、量子化の程度を判断し、同様に、適用されるべき逆量子化の程度を判断するための、ビデオスライス中のビデオブロックごとにビデオエンコーダ３０によって計算される量子化パラメータＱＰYの使用を含み得る。逆変換処理ユニット７８は、ピクセル領域において残差ブロックを生成するために、逆変換、たとえば、逆ＤＣＴ、逆整数変換、または概念的に同様の逆変換プロセスを変換係数に適用する。
【００７８】
[0085]  動き補償ユニット７２が、動きベクトルおよび他のシンタックス要素に基づいて現在のビデオブロックのための予測ブロックを生成した後、ビデオデコーダ３０は、逆変換ユニット７８からの残差ブロックを動き補償ユニット７２によって生成された対応する予測ブロックと加算することによって、復号ビデオブロックを形成する。加算器８０は、この加算演算を実行する１つまたは複数の構成要素を表す。所望される場合、ブロッキネスアーティファクトを除去するために、復号ブロックをフィルタリングするためのデブロッキングフィルタも適用され得る。ピクセル遷移を平滑化するか、またはさもなければビデオ品質を改善するために、（コーディングループ内またはコーディングループ後の）他のループフィルタも使用され得る。所与のフレームまたはピクチャ中の復号ビデオブロックは、次いで、その後の動き補償のために使用される参照ピクチャを記憶する参照ピクチャメモリ８２に記憶される。参照フレームメモリ８２はまた、図１のディスプレイデバイス３２などのディスプレイデバイス上に後で表示するために、復号ビデオを記憶する。
【００７９】
[0086]  図３のビデオデコーダ３０は、本開示で説明される技法のうち１つまたは複数を実装するように構成されたビデオデコーダの例を表す。本技法の一例では、ビデオデコーダ３０は、ビットストリームの部分においてパラメータセットの更新が起こり得るかどうかの指示を復号するように構成され得る。ビットストリームの部分においてパラメータセットの更新が起こり得ないことを指示が示すとき、ビデオデコーダ３０は、ビットストリームの部分全体について、所与のタイプの初期パラメータセットをアクティブ化する。この場合、初期パラメータセットと同じタイプであるとともに同じ識別値を有する後続のパラメータセットを受信すると、ビデオデコーダ３０は、コード化ビデオシーケンスについての初期パラメータセットを更新するかどうか判断する必要はなく、後続のパラメータセットを無視することができる。
【００８０】
[0087]  ＨＥＶＣ  ＨＭは、パラメータセットの概念を含む。パラメータセットとは、ビデオデコーダがコード化ビデオを再構成することを可能にする情報を示すように構成されたシンタックス要素を含むシンタックス構造である。シンタックス要素は、シンタックス要素によって示された情報と、シンタックス要素がビットストリーム中で変わることが予想される頻度とに基づく、特定のタイプのパラメータセットに含まれ得る。たとえば、ビデオパラメータセット（ＶＰＳ）は、時間的副層の間の依存を含む、コード化ビデオシーケンスの全体的特性を記述するシンタックス要素を含む。シーケンスパラメータセット（ＳＰＳ）は、ピクチャシーケンス内のピクチャに対して不変のままであると予想されるシンタックス要素（たとえば、ピクチャ順序、参照ピクチャの数、およびピクチャサイズ）を含む。ピクチャパラメータセット（ＰＰＳ）は、シーケンス内のピクチャごとに変わり得るシンタックス要素（たとえば、エントロピーコーディングモード、量子化パラメータ、およびビット深度）を含む。適応パラメータセット（ＡＰＳ）は、シーケンスのピクチャ内で変わると予想されるシンタックス要素（たとえば、ブロックサイズ、およびデブロックフィルタリング）を含む。
【００８１】
[0088]  パラメータセットの概念は、コード化ビデオデータの送信から、まれに変化する情報の送信を分離する。いくつかの例では、パラメータセットは、「帯域外（out-of-band）」で伝えられ得る（すなわち、コード化ビデオデータを含むユニットと一緒には移送されない）。帯域外送信は通常、データチャネル内の「帯域内（in-band）」送信よりも信頼できるので、パラメータセットを帯域外で送信することが望ましい場合がある。ＨＥＶＣ  ＨＭにおいて、各ＶＰＳはＶＰＳ識別（ＩＤ）値を含み、各ＳＰＳは、ＳＰＳ  ＩＤを含み、ＶＰＳ  ＩＤを使ってＶＰＳを参照し、各ＰＰＳは、ＰＰＳ  ＩＤを含み、ＳＰＳ  ＩＤを使ってＳＰＳを参照する。さらに、各スライスヘッダは、ＰＰＳ  ＩＤを使ってＰＰＳを参照する。
【００８２】
[0089]  ビットストリーム中で、特定のパラメータセットＩＤ値をもつ特定のタイプのパラメータセットが、同じタイプであるとともに同じＩＤ値をもつ（ビットストリーム順序または復号順序で）前のパラメータセットとは異なる内容を有するとき、その特定のＩＤ値をもつ特定のタイプのパラメータセットが更新されてよい。パラメータセットの更新が起こると、ビデオデコーダ３０は、同じタイプであるとともに同じＩＤ値を有する前のパラメータセットを置き換えるために、所与のＩＤ値をもつ現在のパラメータセットを記憶する。
【００８３】
[0090]  特定のタイプの新たなパラメータセットが必要とされるが、可能なＩＤ値すべてが使われてしまっているとき、パラメータセットの更新が起こり得る。パラメータセットの更新は、パラメータセットＩＤ値スペースがすべて使用されているわけではないときであっても、接合ビットストリーム中でも起こり得る。ビットストリーム接合とは、２つ以上のビットストリームまたはビットストリームの複数の部分の組合せを指す。第１のビットストリームに、可能性としてはビットストリームの一方または両方をいくつか修正して、第２のビットストリームが付加されて、接合ビットストリームを生成することができる。第２のビットストリーム中の第１のコード化ピクチャは、接合点とも呼ばれる。接合ビットストリーム中の接合点にあるピクチャは、第２のビットストリームから生じたものであり、接合ビットストリーム中の接合点の直前のピクチャは、第１のビットストリームから生じたものである。
【００８４】
[0091]  ビットストリームは通常、各タイプの数個のパラメータセット、たとえば、数個のＳＰＳと数個のＰＰＳとを使い、時には、各タイプのただ１つのパラメータセットを使う。さらに、ビットストリームの各々は通常、異なるタイプのパラメータセットの各々について、最小パラメータセットＩＤ値０で始まる。このように、２つのビットストリームが接合された場合、特定のタイプのパラメータセットについての同じＩＤ値、たとえば、ＩＤ値０をもつＳＰＳが、接合点と、接合点ピクチャの直前のピクチャの両方によって参照されるが、２つのパラメータセットは異なる内容を含む可能性が高い。接合点に先行するピクチャによって参照されるパラメータセットは、したがって、接合点ピクチャによって参照される、同じＩＤ値をもつ同じタイプのパラメータセットで更新される必要がある。この場合、接合ビットストリームのパラメータセットは、接合ビットストリームの先頭において送信することはできず、したがって、ビットストリームのコード化ビデオシーケンスから帯域外で送信することはできない。
【００８５】
[0092]  従来、特定のＩＤ値をもつ、任意のタイプの現在のパラメータセットが、同じＩＤ値をもつ、前のパラメータセットを更新するためにアクティブ化されるべきかどうか判断するために、ビデオデコーダは、現在のパラメータセットの内容を前のパラメータセットの内容と比較して、内容が異なるかどうか判断する。現在のパラメータセットの内容が前のパラメータセットとは異なるとき、ビデオデコーダは、ビットストリームについての現在のパラメータセットをアクティブ化し、前のパラメータセットを非アクティブ化する。ビデオデコーダは、より早く受信されたパラメータセットと同じである特定のＩＤ値を有する特定のタイプの新たなパラメータセットを受信するたびに、この内容比較を実行する。パラメータセットが帯域内で、すなわち、ビットストリームのコード化ビデオシーケンスとともに送信されるとき、ビデオデコーダは、エラー耐性向上のために、パラメータセットの反復送信を受信し得る。ビデオデコーダは次いで、各反復パラメータセットに対して内容比較を実行する。この内容比較は不必要であり、ビデオデコーダに対して計算上の負担を課す。
【００８６】
[0093]  本開示に記載する技法は、ビットストリームの部分（たとえば、コード化ビデオシーケンスまたはコード化ビデオシーケンス中のＧＯＰ）においてパラメータセットの更新が起こり得るかどうかを示すように構成されたインジケータを提供する。ビットストリームの部分においてパラメータセットの更新が起こり得ないことをインジケータが示すとき、ビデオデコーダ３０は、ビットストリームの部分全体に対して、特定のＩＤ値をもつ第１のパラメータセットのみを記憶し、アクティブ化する。さらに、パラメータセットの更新が起こり得ないことをインジケータが示すとき、ビデオデコーダ３０は、いかなるパラメータセットの更新も実行せず、したがって、第１のパラメータセットの内容を、同じＩＤ値をもつ、同じタイプの第２のパラメータセットの内容と比較する必要はない。このように、ビデオデコーダ３０は、第１のパラメータセットの内容が、同じＩＤ値を有する、同じタイプの他のどのパラメータセットにも含まれる内容と同一であるかのように動作することができる。
【００８７】
[0094]  ビットストリームの部分においてパラメータセットの更新が起こり得ることをインジケータが示すとき、ビデオデコーダ３０は、特定のＩＤ値をもつ第１のパラメータセットを記憶し、アクティブ化するが、同じＩＤ値をもつ、同じタイプの第２のパラメータセットを使って、記憶された第１のパラメータセットを更新して、記憶された第１のパラメータセットを置き換えることができる。いくつかのケースでは、ビデオデコーダ３０は、ビットストリームの部分についての第２のパラメータセットを自動的にアクティブ化し、第１のパラメータセットを非アクティブ化することができる。他のケースでは、ビデオデコーダ３０は、第１のパラメータセットの内容を第２のパラメータセットの内容と比較することができる。第２のパラメータセットの内容が第１のパラメータセットの内容と異なるとき、ビデオデコーダ３０は、ビットストリームの部分に対して第２のパラメータセットをアクティブ化し、第１のパラメータセットを非アクティブ化する。
【００８８】
[0095]  上述したように、インジケータに基づいて、ビデオデコーダ３０は、１つまたは複数のタイプのパラメータセットについて、ビットストリームの部分においてパラメータセットの更新が起こり得るかどうか判断する。指示は、ビットストリームに含まれる、フラグなど、ビットストリームレベルのシンタックス要素を備え得る。たとえば、指示は、ビットストリーム中のコード化ビデオシーケンスに関連付けられた１つまたは複数の補足強調情報（ＳＥＩ）ネットワークアブストラクションレイヤ（ＮＡＬ）ユニットに含まれるフラグを備え得る。別の例として、指示は、ビットストリーム中のコード化ビデオシーケンスについての１つまたは複数のシーケンスパラメータセット（ＳＰＳ）ＮＡＬユニットに含まれるフラグを備え得る。
【００８９】
[0096]  一例では、フラグは、ビットストリームの部分において任意のパラメータセットが更新され得るかどうかを示し得る。したがって、異なるタイプのパラメータセットについての更新状況を示すのに、単一のフラグが使われ得る。この場合、ＶＰＳ、ＳＰＳ、ＰＰＳ、および／またはＡＰＳを含むすべてのタイプのパラメータセットに、同じフラグが使われてよい。フラグが１に等しいとき、パラメータセットが更新されてよい。フラグが０に等しいとき、どのパラメータセットも更新されてはならず、ビデオデコーダ３０は、同じタイプであるとともに同じパラメータセットＩＤ値をもつパラメータセットの間の内容比較を実行しない。フラグが０に等しいとき、ビデオデコーダ３０は、同じＩＤ値をもつ、同じタイプのパラメータセットが同じ内容を有するかのように動作し得るので、内容比較は必要ない。
【００９０】
[0097]  別の例では、フラグは、ビットストリームの部分において特定のタイプのパラメータセットが更新され得るかどうかを示し得る。この場合、ＶＰＳ、ＳＰＳ、ＰＰＳ、および／またはＡＰＳを含む異なるタイプのパラメータセットの各々に、異なるフラグが使われ得る。したがって、各タイプのパラメータセットが、実際には、更新され得るかどうかを示すための独自のフラグを有し得る。フラグが１に等しいとき、特定のタイプのパラメータセットが更新され得る。フラグが０に等しいとき、特定にタイプのどのパラメータセットも更新されてはならず、ビデオデコーダ３０は、特定のタイプであるとともに同じパラメータセットＩＤ値をもつパラメータセットの間の内容比較を実行しない。フラグが０に等しいとき、ビデオデコーダ３０は、同じＩＤ値をもつ、特定のタイプのパラメータセットが同じ内容を有するかのように動作し得るので、内容比較は必要ない。
【００９１】
[0098]  さらなる一例において、フラグは、ビットストリームの部分において異なるタイプの２つ以上のパラメータセットが更新され得るかどうかを示し得る。この場合、異なるタイプのパラメータセットのうち２つ以上、たとえば、ＳＰＳおよびＰＰＳに対して、１つのフラグが使われればよく、異なるタイプのパラメータのセットのうち１つまたは複数、たとえば、ＶＰＳに対して、別のフラグが使われてよい。したがって、いくつかのタイプのパラメータセットは、共同更新状況を示すためのフラグを共有することができ、他のタイプのパラメータセットは、個々の更新状況を示すための個々のフラグを有し得る。さらに、いくつかのケースでは、指示は、複数のビットをもつ単一のシンタックス要素であるビットマスクまたはコードワードを備えることができ、各ビットは、パラメータセットのうち１つもしくは複数の更新状況に対応し、またはコードワードは、異なるパラメータセットについての更新状況の異なる組合せを示すための特定の値を有する。
【００９２】
[0099]  いくつかの場合には、ビットストリームの部分においてパラメータセットの更新が起こり得るかどうかの指示は、どのようにしてパラメータセットがビデオデコーダ３０に送信されるかを決定し得る。たとえば、ビットストリームの部分においてパラメータセットの更新が起こり得るとき、更新は、ビットストリームの異なる部分に対して、たとえば、接合ビットストリームの接合点ピクチャの所で起こり得るので、パラメータセットは、ビットストリームのコード化ビデオシーケンスから帯域外で送信することはできない。
【００９３】
[0100]  本技法によると、一例では、ビットストリームの部分においてパラメータセットの更新が起こり得ないことをインジケータが示すとき、ビデオデコーダ３０は、帯域外送信、すなわち、ビットストリームのコード化ビデオシーケンスとは別個の送信において、第１のパラメータセットを受信し得る。この場合、第１のパラメータセットは、ビットストリーム全体に対してアクティブ化される唯一のパラメータセットであるので、ビデオエンコーダ２０などのビデオエンコーダは、第１のパラメータセットがコード化ビデオシーケンスデータとは別個となるように、第１のパラメータセットを帯域外で符号化すればよい。別の例では、ビットストリームの部分においてパラメータセットの更新が起こり得ないことをインジケータが示すとき、ビデオデコーダ３０は、第１のパラメータセットのどの反復送信についての内容も比較することなく、帯域内送信、すなわち、ビットストリームのコード化ビデオシーケンスをもつ送信において、第１のパラメータセットを受信することができる。さらに、第１のパラメータセットは、ビットストリームの部分の先頭において送信することができる。この場合、ビデオエンコーダ２０などのビデオエンコーダが、エラー耐性向上ために第１のパラメータセットの反復送信を符号化すると、ビデオデコーダ３０は、反復パラメータセットについての内容比較を実行しない。指示に従って、ビデオデコーダ３０は、同じＩＤ値をもつ、同じタイプのパラメータセットが同じ内容を有するかのように動作し得るので、内容比較は必要ない。
【００９４】
[0101]  いくつかの例では、指示は、ビットストリームに、たとえば、ＶＰＳ、ＳＰＳ、ＰＰＳまたはＡＰＳに含まれる、フラグなどのシンタックス要素（syntax element）であり得る。一例として、指示は、コード化ビデオシーケンスに含まれるシンタックス要素であり得る。別の例として、指示は、プロファイル定義における要件であってよい。他の例では、ビデオビットストリームが、メディアデータ移送にＲＴＰを使うストリーミングやマルチキャストなど、リアルタイムトランスポートプロトコル（ＲＴＰ）に基づく送信環境において使われるとき、指示は、メディアタイプパラメータとして定義され、セッション記述プロトコル（ＳＤＰ）に含まれ得る。この場合、指示は、能力交換としても知られるセッション否定フェーズにおいて使われ得る。さらに他の例では、指示は、ＤＡＳＨなどのハイパーテキスト転送プロトコル（ＨＴＴＰ）ストリーミング環境におけるメディアプレゼンテーション記述（ＭＰＤ）に含まれるストリームプロパティとして定義され得る。
【００９５】
[0102]  本技法の別の例では、ビデオデコーダ３０は、ＣＲＡアクセスユニットからのビットストリームへのランダムアクセスの実行に、前のアクセスユニットからのパラメータセットのフェッチングが要求されるかどうかという、各ＣＲＡピクチャについての指示を復号するように構成され得る。指示は、ＨＥＶＣ規格において採り入れられているＣＲＡアクセスユニットに特に有用であり、というのは、ＣＲＡピクチャが、コード化ビデオシーケンス内のどのポイントに配置されてもよく、ＤＰＢをクリーンにしないからであり、このことは、コーディング効率を低下することなく、ビットストリームへのランダムアクセスのためのより多くの選択肢を提供する。
【００９６】
[0103]  前のアクセスユニットからのどのパラメータセットも、特定のＣＲＡピクチャからのランダムアクセスに必要とされないことを指示が示すとき、ビデオデコーダ３０は、フェッチング動作なしで、そのＣＲＡピクチャからのランダムアクセスを実行すると決定することができる。前のアクセスユニットからのパラメータセットが、特定のＣＲＡピクチャからのランダムアクセスに必要とされることを指示が示すとき、ビデオデコーダ３０は、フェッチング動作を避けるために、そのピクチャからのランダムアクセスを実行しないと決定することができる。いくつかのケースでは、ビデオデコーダ３０は、パラメータセットフェッチング動作を実行せずに、ランダムアクセスがそこから実行され得るアクセスユニットを識別するために、ビットストリームのある部分、たとえば、コード化ビデオシーケンス内のいくつかの異なるＣＲＡピクチャについての指示を復号することができる。このように、ビデオデコーダ３０は、ランダムアクセスをそこから実行するための異なるＣＲＡピクチャを選択することによって、フェッチング動作の実行を避けることができる。
【００９７】
[0104]  ランダムアクセスとは、ビデオビットストリームを、ビットストリーム内の第１のコード化ピクチャではないコード化ピクチャから復号することを指す。ビットストリームへのランダムアクセスは、たとえば、ユーザが、異なるチャネルの間を切り替えるため、ビデオの特定の部分にジャンプするため、異なるビットストリームの接合のため、またはビットレート、フレームレート、空間解像度などのストリーム適応のために異なるビットストリームに切り替えるために、ブロードキャストおよびストリーミングなど、多くのビデオアプリケーションにおいて必要とされる。この特徴は、ビデオビットストリームにランダムアクセスピクチャまたはランダムアクセスポイントを規則的な間隔で挿入することによって有効にされる。ランダムアクセスのために、瞬時デコーダリフレッシュ（ＩＤＲ：instantaneous decoder refresh）ピクチャが使われ得る。ＩＤＲピクチャは、コード化ビデオビデオシーケンスを開始させ、復号されたピクチャバッファ（ＤＰＢ）を常にクリーン（clean）にするので、復号順序でＩＤＲピクチャに続くピクチャは、ＩＤＲピクチャの前に復号されたピクチャを参照に使用できない。その結果、ランダムアクセスに対するＩＤＲピクチャに依存するビットストリームは、著しく低いコーディング効率を有することがある。
【００９８】
[0105]  コーディング効率を向上させるために、ＨＥＶＣ  ＨＭにおいてクリーンランダムアクセス（ＣＲＡ：clean random access）ピクチャの概念が導入されている。ＩＤＲピクチャとは異なり、ＣＲＡピクチャは、コード化ビデオシーケンス内のどのポイントに配置されてもよく、ＤＰＢをクリーンにしないので、コーディング効率の低下なしで、ビットストリームへのランダムアクセスのためのより多くの選択肢を提供する。ＣＲＡピクチャはＤＰＢをクリーンにしないので、ＣＲＡピクチャに復号順序で続くが出力順序で先行するピクチャは、参照用のＣＲＡピクチャの前に復号されたピクチャを使うことを許可される。ＣＲＡピクチャに復号順序で続くがＣＲＡピクチャに出力順序で先行するピクチャは、ＣＲＡピクチャの先行ピクチャと呼ばれる。ＣＲＡピクチャの先行ピクチャは、現在のＣＲＡピクチャに先行するＩＤＲまたはＣＲＡピクチャから復号が始まる場合は正しく復号され得る。ＣＲＡピクチャの先行ピクチャは、ただし、ランダムアクセスが現在のＣＲＡピクチャから起きたときは正しく復号することができない。先行ピクチャは、したがって、通常、ランダムアクセス復号中にＤＰＢから破棄される。復号がどこで始まるかによっては利用可能でない場合がある参照ピクチャからのエラー伝播を防止するために、復号順序と出力順序の両方でＣＲＡピクチャに続くすべてのピクチャは、復号順序または出力順序のいずれかでＣＲＡピクチャに先行するどのピクチャ（先行ピクチャを含む）も参照として使わないように制限され得る。
【００９９】
[0106]  同様のランダムアクセス機能性が、回復ポイントＳＥＩメッセージをもつＨ．２６４／ＡＶＣ規格においてサポートされる。Ｈ．２６４／ＡＶＣデコーダの実施態様は、回復ポイントＳＥＩメッセージ機能性をサポートしてもしなくてもよい。ＨＥＶＣ規格において、ＣＲＡピクチャによって開始するビットストリームは、適合ビットストリームと見なされる。ビットストリームがＣＲＡピクチャによって開始するとき、ＣＲＡピクチャの先行ピクチャは利用不能参照ピクチャを指し、したがって復号可能でない。ＨＥＶＣ規格は、開始ＣＲＡピクチャの先行ピクチャが出力されないと規定する。ただし、ビットストリーム適合性を確立するために、ＨＥＶＣ規格は、非出力先行ピクチャを復号するために利用不能参照ピクチャを生成するための復号プロセスを指定する。適合デコーダ実装形態は、復号プロセスがコード化ビデオシーケンスの先頭から実行されるときと比較して、同一の出力が生成され得る限り、その復号プロセスに従わなくてよい。
【０１００】
[0107]  その上、ＨＥＶＣ規格における適合ビットストリームは、ＩＤＲピクチャをまったく含まず、したがってコード化ビデオシーケンスのサブセットまたは不完全なコード化ビデオシーケンスを含み得る。ＨＥＶＣ規格において、コード化ビデオシーケンスは、復号順序で、ＩＤＲアクセスユニットと、それに続く、任意の後続のＩＤＲアクセスユニットまでだがそれを含まないすべての後続のアクセスユニットを含むゼロ個以上の非ＩＤＲアクセスユニットとを含むアクセスユニットシーケンスとして定義される。コード化ビデオシーケンスに含まれるアクセスユニットは、ビデオシーケンスのピクチャに対応する。アクセスユニットの各々は、１つまたは複数のネットワークアブストラクションレイヤ（ＮＡＬ）ユニットを含む。ＨＥＶＣ規格は、ビデオコード化レイヤ（ＶＣＬ：video coded layer）ＮＡＬユニットと非ＶＣＬ  ＮＡＬユニットとを定義する。ＶＣＬ  ＮＡＬユニットは、ピクチャについてのビデオデータのスライスを含む。非ＶＣＬ  ＮＡＬユニットは、ビデオデータのスライス以外の情報を含む。たとえば、非ＶＣＬ  ＮＡＬユニットは、デリミタデータまたはＶＰＳ、ＳＰＳもしくはＰＰＳなどのパラメータセットを含み得る。非ＶＣＬ  ＮＡＬユニットの別の例は、ビットストリームを復号するときにビデオデコーダによって使われるピクチャタイミングメッセージを含み得るＳＥＩ  ＮＡＬユニットである。
【０１０１】
[0108]  ビデオデコーダ３０が、ビットストリームに含まれるＣＲＡピクチャからのランダムアクセスを実行するとき、出力または復号順序でＣＲＡピクチャに先行するすべてのピクチャは、復号されず、参照ピクチャとしての使用に対応不可能である。この場合、ＣＲＡピクチャまたは任意の、出力または復号順序が後のピクチャを復号するために、ビデオデコーダ３０は、利用不可能な前のピクチャについての１つについてのアクセスユニットに含まれる１つまたは複数のパラメータセットをフェッチする必要がある場合があるが、これは面倒な動作である。
【０１０２】
[0109]  一例として、ＳＰＳは、ビットストリームの第１のＣＲＡピクチャ向けのアクセスユニットに含まれてよく、どのＳＰＳも、ビットストリームの後続の第２のＣＲＡピクチャに含めることはできない。この場合、ランダムアクセスが第２のＣＲＡピクチャから実行され、第１のＣＲＡピクチャを含むすべての前のピクチャが利用不可能である場合、ＳＰＳも、第２のＣＲＡピクチャと、ビットストリーム中の任意の後続のピクチャとを復号するのに利用可能でない。ランダムアクセスを第２のＣＲＡピクチャから実行するために、ビデオデコーダ３０は、利用不可能な第１のＣＲＡピクチャからＳＰＳをフェッチする必要がある。
【０１０３】
[0110]  従来、フェッチング動作を避けるために、ビデオデコーダは、受信したビットストリームを通して検査を実行して、ビットストリームの異なる部分に対してどのパラメータセットが使われるかと、ランダムアクセスがビットストリーム中のＲＡＰピクチャから利用可能であるかどうかとを判断することができる。フェッチング動作とビットストリーム検査動作の両方が、ビデオデコーダにとってプロセッサ集約的な、面倒な動作である場合があり、これらの動作を避けることが望ましいであろう。
【０１０４】
[0111]  本開示の技法は、ビットストリーム中の特定のＣＲＡアクセスユニットからのランダムアクセスの実行に、前のアクセスユニットからのパラメータセットのフェッチングが要求されるかどうかの指示を可能にする。どの前のパラメータセットも、特定のＣＲＡアクセスユニットからのランダムアクセスに必要とされないとき、ビデオデコーダ３０は、その特定のＣＲＡアクセスユニットからのランダムアクセスを、フェッチング動作なしで実行することができる。逆に、前のパラメータセットが、特定のＣＲＡアクセスユニットからのランダムアクセスに必要とされるとき、ビデオデコーダ３０は、フェッチング動作を避けるために、その特定のＣＲＡアクセスユニットからのランダムアクセスを実行しなくてよい。いくつかの例では、前のパラメータセットが、特定のＣＲＡアクセスユニットからのランダムアクセスに必要とされるとき、ビデオデコーダ３０は、そのＣＲＡアクセスユニットからのランダムアクセスを、前のアクセスユニットからパラメータのセットをフェッチした後で実行すればよい。
【０１０５】
[0112]  本開示に記載する技法によると、指示は、出力または復号順序で前のアクセスユニットに含まれるパラメータセットが、ＣＲＡアクセスユニットと、出力または復号順序ですべての後続のアクセスユニットとを復号するのに必要とされるかどうかを各ＣＲＡアクセスユニットが示すためのビットストリームに含まれ得る。どの前のパラメータセットも、あるＣＲＡアクセスユニットからのランダムアクセスに必要とされない場合、ビデオデコーダ３０は、前のアクセスユニットに含まれるどのパラメータセットＮＡＬユニットにも依拠せずに、そのアクセスユニットからビットストリームへのランダムアクセスを実行することができる。このように、すべてのより早期のＮＡＬユニットは、単にスキップまたは無視されてよい。
【０１０６】
[0113]  上で説明した例でのように、ＳＰＳ  ＮＡＬユニットは、ビデオシーケンスの第１のＣＲＡピクチャ向けのアクセスユニットに含まれてよく、どのＳＰＳ  ＮＡＬユニットも、ビデオシーケンスの後続の第２のＣＲＡピクチャに含まれてはならない。本開示に記載する技法によると、出力または復号順序で前のアクセスユニットからのどのパラメータセットも、第１のＣＲＡピクチャまたは出力または復号順序で後続する任意のピクチャを復号するのに必要とされないことを示すための指示が、第１のＣＲＡピクチャ向けのアクセスユニットに含まれ得る。さらに、出力または復号順序で前のアクセスユニットからのパラメータセット（すなわち、第１のＣＲＡピクチャ向けのアクセスユニット中のＳＰＳ）が、第２のＣＲＡピクチャまたは出力または復号順序で後続する任意のピクチャを復号するのに必要とされることを示すための指示が、第２のＣＲＡピクチャ向けのアクセスユニットに含まれ得る。この例では、指示に基づいて、ビデオデコーダ３０は、第１のＣＲＡピクチャからのランダムアクセスは実行するが、フェッチング動作を避けるために、第２のＣＲＡピクチャからのランダムアクセスは実行しないと決定することができる。
【０１０７】
[0114]  主にＣＲＡピクチャを参照して記載するが、本開示の技法は、ＩＤＲピクチャおよび漸進的復号リフレッシュ（ＧＤＲ）ピクチャを含む、他のタイプのＲＡＰピクチャにも同様に使うことができる。いくつかのケースでは、指示は、コード化ビデオシーケンス中の各ＩＤＲまたはＣＲＡピクチャ向けのアクセスユニットに含まれる特定のタイプのネットワークアブストラクションレイヤ（ＮＡＬ）ユニットを備え得る。他のケースでは、指示は、コード化ビデオシーケンス中の、各ＩＤＲまたはＣＲＡピクチャ用のアクセスユニットに含まれるＮＡＬユニットペイロードに含まれる、フラグなどのシンタックス要素を備え得る。一例では、指示は、ＣＲＡピクチャ用のアクセスユニット中の補足強調情報（ＳＥＩ）ＮＡＬユニットに含まれるフラグを備え得る。
【０１０８】
[0115]  さらに、たとえば、所与のピクチャについての指示は、固有のＮＡＬユニットタイプをもつ特定のタイプのＳＰＳを使ってシグナリングすることができる。この例では、特定のタイプのＳＰＳは、ピクチャ向けのアクセスユニット中の第１のＮＡＬユニット、またはアクセスユニットデリミタＮＡＬユニット（存在する場合）の後の第１のＮＡＬユニットに含まれることが要求され得る。別の例では、所与のピクチャについての指示は、固有のＮＡＬユニットタイプをもつ特定のタイプのアクセスユニットデリミタ、またはピクチャ向けのアクセスユニット中のアクセスユニットデリミタＮＡＬユニットのペイロードに含まれるフラグを使ってシグナリングすることができる。さらなる一例において、所与のピクチャについての指示は、ピクチャ向けのアクセスユニット中のＮＡＬユニットヘッダに含まれるフラグを使ってシグナリングすることができる。さらに、所与のピクチャについての指示は、特定のタイプのＳＥＩメッセージまたはＳＥＩメッセージ中のフラグを使ってシグナリングすることができる。ＨＥＶＣ  ＨＭにおいて、ＳＥＩメッセージは、ピクチャ向けのアクセスユニット中のＳＥＩ  ＮＡＬユニットに含めることができる。
【０１０９】
[0116]  図４は、予測ビデオコーディング技法に従ってコーディングされたビデオシーケンス１００を示す概念図である。図４に示すように、ビデオシーケンス１００は、ピクチャＰｉｃ1〜Ｐｉｃ10を含む。ピクチャＰｉｃ1〜Ｐｉｃ10は、表示されることになる順序に従って並べられ、連番を振られる。後でより詳しく説明するように、出力または表示順序は、必ずしも復号順序に対応するわけではない。図４に示すように、ビデオシーケンス１００はＧＯＰ1とＧＯＰ2とを含み、ここでピクチャＰｉｃ1〜Ｐｉｃ5はＧＯＰ1に含まれ、ピクチャＰｉｃ6〜Ｐｉｃ10はＧＯＰ2に含まれる。図４はさらに、Ｐｉｃ5を、ｓｌｉｃｅ1およびｓｌｉｃｅ2に区分されるように示し、ここでｓｌｉｃｅ1およびｓｌｉｃｅ2の各々は、左から右、上から下のラスター走査により、連続するＬＣＵを含む。さらに、Ｐｉｃ5中の最後のＬＣＵは、４分木に従って、複数のＣＵにさらに分割されるように示されている。図示していないが、図４に示す他のピクチャは、同様に１つまたは複数のスライスに区分され得る。
【０１１０】
[0117]  後でより詳しく説明するように、ＨＥＶＣ  ＨＭは、２つのタイプのスライス区分方式、すなわち標準スライスとエントロピースライスとを含む。さらに、スライス区分方式に加え、ＨＭは、タイルおよび波面並列処理（ＷＰＰ：Wavefront Parallel Processing）区分方式も含む。区分方式は、最大伝送単位（ＭＴＵ：maximum transmission unit）サイズマッチングおよび／または並列処理に基づいて選択し、適用することができる。Ｐｉｃ5、または他のピクチャのうち任意のもののｓｌｉｃｅ1およびｓｌｉｃｅ2は、標準スライスであってもエントロピースライスであり得る。さらに、他の例では、Ｐｉｃ1〜Ｐｉｃ10の各々は、タイルまたはＷＰＰを使って区分することができる。
【０１１１】
[0118]  さらに、図４は、ビデオシーケンス１００のＧＯＰ2に関して、Ｉスライス、Ｐスライス、およびＢスライスの概念を示す。ＧＯＰ2中のＰｉｃ6〜Ｐｉｃ10の各々に関連付けられた矢印は、矢印によって示される、参照されるピクチャに基づいて、ピクチャがＩスライス、Ｐスライス、またはＢスライスを含むかどうかを示す。ビデオシーケンス１００中で、Ｐｉｃ6およびＰｉｃ9は、Ｉスライス（すなわち、ピクチャ自体の中の参照に基づく、イントラ予測されたスライス）を含むピクチャを表し、ピクチャＰｉｃ7およびＰｉｃ10は、Ｐスライス（すなわち、前のピクチャ中の参照に基づく、インター予測されたスライス）を含むピクチャを表し、Ｐｉｃ8は、Ｂスライス（すなわち、前のピクチャと後続のピクチャの両方における参照に基づく、インター予測されたスライス）を含むピクチャを表す。
【０１１２】
[0119]  図５は、図４に示すＧＯＰ2に対応するコード化ビデオシーケンス１２０の例を示す概念図である。ＨＥＶＣ  ＨＭは、コード化ビデオシーケンスを、復号順序で、瞬時復号リフレッシュ（ＩＤＲ）アクセスユニットと、それに続く、任意の後続のＩＤＲアクセスユニットまでだがそれを含まないすべての後続のアクセスユニットを含むゼロ個以上の非ＩＤＲアクセスユニットとからなるアクセスユニットシーケンスとして定義する。コード化ピクチャとは、ピクチャのすべてのツリーブロックを含む、ピクチャのコード化表現である。アクセスユニットは、復号順序が連続しており、１つのコード化ピクチャを表す、ネットワークアブストラクションレイヤ（ＮＡＬ）ユニットのセットである。アクセスユニットは、コード化ピクチャのコード化スライスを表すビデオコーディングレイヤ（ＶＣＬ）ＮＡＬユニットと、デリミタデータ、パラメータセット、および補足強調情報（ＳＥＩ）メッセージを含む非ＶＣＬ  ＮＡＬユニットとを含み得る。
【０１１３】
[0120]  図５に示すように、コード化ビデオシーケンス１２０は、Ｐｉｃ6〜Ｐｉｃ10の各々に対応するアクセスユニットを含む。ビデオデータストリーム１２０のアクセスユニットは、復号順序に従って、連続して並べられる。Ｐｉｃ9に対応するアクセスユニットは、Ｐｉｃ8に対応するアクセスユニットの前に置かれることに留意されたい。したがって、復号順序は、図４に示す出力順序には対応しない。この例では、出力順序と復号順序との間の違いは、Ｐｉｃ8がＰｉｃ9を参照するという事実による。したがって、Ｐｉｃ9は、Ｐｉｃ8が復号され得る前に復号されなければならない。
【０１１４】
[0121]  図５に示すように、Ｐｉｃ9に対応するアクセスユニットは、アクセスユニット（ＡＵ）デリミタＮＡＬユニット１２２と、ピクチャパラメータセット（ＰＰＳ）ＮＡＬユニット１２４と、ｓｌｉｃｅ1  ＮＡＬユニット１２６と、ｓｌｉｃｅ2  ＮＡＬユニット１２８とを含む。ｓｌｉｃｅ1  ＮＡＬユニット１２６およびｓｌｉｃｅ2  ＮＡＬユニット１２８は各々、ビデオデータのスライスを含み、ＶＣＬ  ＮＡＬユニットの例である。図４を参照して上述したように、Ｐｉｃ9は、Ｉスライスを含むピクチャを表す。図５の例では、したがって、Ｐｉｃ9に対応するアクセスユニットのｓｌｉｃｅ1  ＮＡＬユニット１２６、およびｓｌｉｃｅ2  ＮＡＬユニット１２８の各々は、Ｉスライスを表し得る。
【０１１５】
[0122]  非ＶＣＬ  ＮＡＬユニットは、ビデオデータのスライス以外の情報を含む。たとえば、非ＶＣＬは、デリミタデータ、パラメータセット、またはＳＥＩメッセージを含み得る。図５に示す例において、ＡＵデリミタＮＡＬユニット１２２は、Ｐｉｃ9に対応するアクセスユニットを、Ｐｉｃ7に対応するアクセスユニットから区切るための情報を含む。さらに、ＰＰＳ  ＮＡＬユニット１２４は、ピクチャパラメータセットを含む。ＡＵデリミタＮＡＬユニット１２２およびＰＰＳ  ＮＡＬユニット１２４は、非ＶＣＬ  ＮＡＬユニットの例である。非ＶＣＬ  ＮＡＬユニットの別の例は、ＳＥＩ  ＮＡＬユニットである。ＳＥＩ  ＮＡＬユニットは、ビットストリームを復号するときにビデオデコーダによって使われる、ピクチャタイミングＳＥＩメッセージまたはバッファリング期間ＳＥＩメッセージを含み得る。ピクチャタイミングＳＥＩメッセージは、ビデオデコーダがいつＶＣＬ  ＮＡＬユニットを復号し始めるべきかを示す情報を含み得る。バッファリング期間ＳＥＩメッセージは、ビデオデコーダが、オーバーフローを避けるために、いつＣＰＢからピクチャを除去するべきかを示すコード化ピクチャバッファ（ＣＰＢ）除去遅延情報を含み得る。
【０１１６】
[0123]  ＨＥＶＣ  ＨＭにおいて、ビデオシーケンス、ＧＯＰ、ピクチャ、スライス、ＣＵ、ＰＵおよびＴＵの各々は、そのビデオデータ構造についてのビデオコーディングプロパティを示すように定義されたシンタックス要素に関連付けられ得る。ＨＭは、パラメータセット概念をさらに利用する。パラメータセットとは、パラメータセットを指すどのビデオデータ構造にも適用されるビデオコーディングプロパティを示すように定義されたシンタックス要素を含むシンタックス構造である。ＨＭは、階層パラメータセット機構を利用し、この機構では、シンタックス要素は、ビデオコーディングプロパティが変わることが予想される頻度に基づいて、あるタイプのパラメータセットに含まれる。パラメータセットの機構は、したがって、コード化ブロックデータの送信から、まれに変化する情報の送信を分離する。いくつかのアプリケーションでは、帯域外送信は通常、帯域内送信よりも信頼できるので、パラメータセットは「帯域外」で伝えられ、すなわち、コード化ビデオデータと一緒に移送することはできない。
【０１１７】
[0124]  ＨＭは、ビデオパラメータセット（ＶＰＳ）、シーケンスパラメータセット（ＳＰＳ）、ピクチャパラメータセット（ＰＰＳ）、および適応パラメータセット（ＡＰＳ）のうち１つまたは複数を含む、いくつかの異なるタイプのパラメータのセットを定義する。ビットストリームは、各タイプの、いくつかの異なるパラメータのセットを含み得る。特定のパラメータセットは、パラメータセット識別子（ＩＤ）を使って識別される。各ＶＰＳはＶＰＳ  ＩＤを含み、各ＳＰＳは、ＳＰＳ  ＩＤを含み、ＶＰＳ  ＩＤを参照することができ、各ＰＰＳは、ＰＰＳ  ＩＤを含み、ＳＰＳ  ＩＤを参照し、各スライスヘッダは、ＰＰＳ  ＩＤと、可能性としてはＡＰＳ  ＩＤとを参照する。さらに、各バッファリング期間補足強調情報（ＳＥＩ）メッセージも、ＳＰＳ  ＩＤと、可能性としてはＶＰＳ  ＩＤとを参照する。これらの例の各々において、パラメータセットＩＤは、可変長符号なし整数指数ゴロム（variable length unsigned integer exp-Golomb）（ｕｅ（ｖ））コーディング方法を使って、シンタックス要素としてコーディングされ得る。
【０１１８】
[0125]  ＶＰＳとは、０個以上のコード化ビデオシーケンス全体に当てはまるシンタックス要素を含むシンタックス構造である。より具体的には、ＶＰＳは、プロファイルと、ティアと、レベル情報および時間的サブレイヤの間での依存とを含む、コード化ビデオシーケンスの全体的特性を記述するシンタックス要素を含む。特定のＶＰＳは、ＳＰＳまたはＳＥＩメッセージ中のシンタックス要素として符号化された特定のＶＰＳ  ＩＤを使って識別される。ＳＰＳとは、０個以上のコード化ビデオシーケンス全体に当てはまるシンタックス要素を含むシンタックス構造である。より具体的には、ＳＰＳは、フレームシーケンスに対して不変のままであると予想されるビデオコーディングプロパティ（たとえば、ピクチャ順序、参照フレームの数、およびピクチャサイズ）を示すように定義されたシンタックス要素を含む。特定のＳＰＳは、ＰＰＳまたはＳＥＩメッセージ中のシンタックス要素として符号化された特定のＳＰＳ  ＩＤを使って識別される。
【０１１９】
[0126]  ＰＰＳとは、０個以上のコード化ピクチャ全体に当てはまるシンタックス要素を含むシンタックス構造である。より具体的には、ＰＰＳは、シーケンス内でピクチャごとに変わり得るビデオコーディングプロパティ（たとえば、エントロピーコーディングモード、量子化パラメータ、およびビット深度）を示すように定義されたシンタックス要素を含む。特定のＰＰＳは、スライスヘッダ中のシンタックス要素として符号化された特定のＰＰＳ  ＩＤを使って識別される。ＡＰＳとは、０個以上のコード化ピクチャ全体に当てはまるシンタックス要素を含むシンタックス構造である。ＡＰＳは、コーディングされた場合、ＰＰＳ中に示される他のプロパティよりも頻繁に変化するビデオコーディングプロパティを示すように定義されたシンタックス要素を含み得る。特定のＡＰＳは、スライスヘッダ中のシンタックス要素として符号化されたＡＰＳ  ＩＤを使って識別される。
【０１２０】
[0127]  ビットストリーム接合とは、２つ以上のビットストリームまたはビットストリームの複数の部分の連結または組合せを指す。たとえば、第１のビットストリームに、可能性としてはビットストリームの一方または両方をいくつか修正して、第２のビットストリームが付加されて、接合ビットストリームを生成することができる。第２のビットストリーム中の第１のコード化ピクチャは、接合点とも呼ばれる。したがって、接合ビットストリーム中の接合点の後のピクチャは、第２のビットストリームから生じられたものであり、接合ビットストリーム中の接合点に先行するピクチャは、第１のビットストリームから生じられたものである。いくつかのケースでは、ビットストリームスプライサが、ビットストリームの接合（bitstream splicing）を実行し得る。ビットストリームスプライサは、軽量であり、ビデオエンコーダよりも知的でなくてよい。たとえば、ビットストリームスプライサは、エントロピー復号およびエントロピー符号化能力を装備しなくてよい。ビットストリーム接合は、スケーラビリティアプリケーションにとって（たとえば、ビットレート、フレームレート、または空間解像度スケーラビリティにとって）有用であり得る。
【０１２１】
[0128]  上述したように、ビットストリームは、各タイプの、１つまたは複数の異なるパラメータのセット、たとえば、ＳＰＳとＰＰＳとを含み得る。特定のタイプのパラメータセットは、パラメータセット識別子（ＩＤ）を使って識別される。いくつかのケースでは、ビデオデコーダは、同じパラメータセットＩＤをもつ同じタイプの、（ビットストリームまたは復号順序で）前のパラメータセットとは異なる内容を有する、特定のパラメータセットＩＤをもつ特定のタイプのパラメータセットを受信することができる。この場合、特定のパラメータセットＩＤをもつ、特定のタイプのパラメータセット（たとえば、ＳＰＳ０）が更新される。パラメータセットの更新は、特定のパラメータセットＩＤをもつ、受信したパラメータセットの内容を記憶して、同じタイプであるとともに同じパラメータセットＩＤ値を有する前のパラメータセットを置き換えることを含む。
【０１２２】
[0129]  特定のタイプの新たなパラメータセットが必要とされるが、パラメータセットＩＤのすべての可能な値が使われてしまっているとき、パラメータセットの更新が起こり得る。パラメータセットの更新は、パラメータセットＩＤ値スペース全部が使用されているわけではないときであっても、接合ビットストリーム中でも起こり得る。ビットストリームはしばしば、数個のＳＰＳおよび数個のＰＰＳ、さらにはわずか１つのＳＰＳおよび１つのＰＰＳのみを使い、最小ＳＰＳ  ＩＤ値と最小ＰＰＳ  ＩＤ値（すなわち、０）とを使う。したがって、２つのビットストリームまたはビットストリームの複数の部分が接合されたとき、同じＳＰＳ  ＩＤまたはＰＰＳ  ＩＤが、元々は第２のビットストリームからのものである接合点によって、および元々は第１のビットストリームからのものである接合点ピクチャの直前のピクチャによって参照される可能性がある。この場合、接合点ピクチャによって参照されるＳＰＳまたはＰＰＳの内容および接合点ピクチャの直前のＳＰＳまたはＰＰＳ参照ピクチャの内容は異なる可能性がある。
【０１２３】
[0130]  特定のケースのＳＰＳパラメータセットでは、接合点ピクチャによって、および接合点の直前のピクチャによって、同じＳＰＳ  ＩＤが参照され、実際に２つの異なるＳＰＳが使われるとき、接合ビットストリーム中で、接合点の直前のピクチャによって参照される、特定のＳＰＳ  ＩＤをもつＳＰＳは、接合点ピクチャによって参照されるＳＰＳによって有効に更新される。この場合、接合ビットストリームのＳＰＳは、接合ビットストリームの先頭に入れることはできない。ＳＰＳを参照して上述したが、同じことが、ＶＰＳ、ＰＰＳ、およびＡＰＳに当てはまる。ビットストリーム接合および関連パラメータセットの更新について、接合ビットストリームにはただ１つの接合点があるという仮定に基づいて記載した。ただし、ビットストリームは、複数の接合点を含む場合があり、本明細書に記載する技法は、接合点の各々に個別に適用することができる。
【０１２４】
[0131]  ランダムアクセスとは、ビデオビットストリームを、ビットストリーム内の先頭コード化ピクチャではないコード化ピクチャから復号することを指す。ビットストリームへのランダムアクセスは、ブロードキャストおよびストリーミングなど、多くのビデオアプリケーションにおいて有用である。たとえば、ランダムアクセスは、ユーザが、異なるチャネルの間を切り替え、ビデオの特定の部分にジャンプし、またはストリーム適応のために（たとえば、ビットレート、フレームレート、または空間解像度スケーラビリティのために）異なるビットストリームに切り替えるのに有用である。ランダムアクセスは、ランダムアクセスポイント（ＲＡＰ）ピクチャまたはアクセスユニットを規則的な間隔で何度もビデオビットストリームに挿入することによって有効にされる。
【０１２５】
[0132]  ビットストリームへのランダムアクセスのために、瞬時復号リフレッシュ（ＩＤＲ）ピクチャが使われ得る。ＩＤＲピクチャは、コード化ビデオシーケンスを開始し、イントラ予測されたスライス（すなわち、Ｉスライス）のみを含む。さらに、ＩＤＲピクチャは、復号ピクチャバッファ（ＤＰＢ）を常にクリーンにする。したがって、復号順序でＩＤＲの後のピクチャは、ＩＤＲピクチャに先立って復号されたピクチャを参照として使うことができない。その結果、ランダムアクセスに対するＩＤＲピクチャに依存するビットストリームは、著しく低いコーディング効率を有することがある。
【０１２６】
[0133]  コーディング効率を向上させるために、ＨＥＶＣ  ＨＭにおいてクリーンランダムアクセス（ＣＲＡ：Clean Random Acces）ピクチャの概念が導入された。ＣＲＡピクチャは、ＩＤＲピクチャのように、イントラ予測されたスライス、すなわち、Ｉスライスのみを含む。ＣＲＡピクチャは、そのＣＲＡピクチャが、ＤＰＢをクリーンにせず、コード化ビデオシーケンス内のどの位置に置かれ得るという点で、ＩＤＲピクチャとは異なる。したがって、ＣＲＡピクチャに復号順序で続くが、ＣＲＡピクチャに出力順序で先行するピクチャは、ＣＲＡピクチャの前に復号されたピクチャを参照として使うことを可能にされる。ＣＲＡピクチャに復号順序で続くがＣＲＡピクチャに出力順序で先行するピクチャは、ＣＲＡピクチャに関連付けられた先行ピクチャ（またはＣＲＡピクチャの先行ピクチャ）と呼ばれる。
【０１２７】
[0134]  ＣＲＡピクチャの先行ピクチャは、現在のＣＲＡピクチャの前のＩＤＲまたはＣＲＡピクチャから復号が始まる場合は正しく復号可能である。ＣＲＡピクチャの先行ピクチャは、ただし、ランダムアクセスが現在のＣＲＡピクチャから始まったときは正しく復号可能でない場合がある。したがって、先行ピクチャは通常、現在のＣＲＡピクチャからのランダムアクセス復号中に破棄される。図４および図５に示す例を参照すると、ｐｉｃ9はＣＲＡピクチャであってよく、ｐｉｃ8はｐｉｃ9の先行ピクチャであってよい。Ｐｉｃ8は、ＧＯＰ2がｐｉｃ6の所でアクセスされる場合は正しく復号可能であるが、ＧＯＰ2がＰｉｃ9の所でアクセスされる場合は正しく復号可能でない場合がある。これは、ｐｉｃ7が、ＧＯＰ2がＰｉｃ9としてアクセスされる場合は利用可能でない場合があるという事実による。復号がどこで始まるかによっては利用可能でない場合がある参照ピクチャからのエラー伝播を防止するために、復号順序と出力順序の両方でＣＲＡピクチャに続くすべてのピクチャは、復号順序または出力順序のいずれかでＣＲＡピクチャに先行するどのピクチャ（先行ピクチャを含む）も参照として使わないように制限され得る。
【０１２８】
[0135]  ＨＥＶＣ  ＨＭにおいて、ＣＲＡピクチャによって開始するビットストリームは、適合ビットストリームと見なされる。ビットストリームがＣＲＡピクチャによって開始するとき、ＣＲＡピクチャの先行ピクチャは利用不能参照ピクチャを指し、したがって正しく復号されることが可能でない場合がある。ただし、ＨＭは、開始するＣＲＡピクチャの先行ピクチャは出力せず、したがって「クリーンランダムアクセス（clean random access）」という名称であることを明記している。図４および図５に示す例において、ビットストリームがＰｉｃ9の所で始まる場合、Ｐｉｃ8は出力されない。ビットストリーム適合性要件を確立するために、ＨＭは、非出力先行ピクチャを復号するために利用不可能な参照ピクチャを生成するための復号プロセスを指定する。ただし、適合デコーダ実装形態は、適合デコーダが、復号プロセスがコード化ビデオシーケンスの先頭から実行されるときと比較して、同一の出力を生成することができる限り、その復号プロセスに従う必要はない。
【０１２９】
[0136]  ＨＥＶＣ  ＨＭにおけるものと同様のランダムアクセス機能性が、回復ポイントＳＥＩメッセージをもつＨ．２６４／ＡＶＣにおいてサポートされることに留意されたい。Ｈ．２６４／ＡＶＣデコーダの実施態様は、ランダムアクセス機能性をサポートしてもしなくてもよい。ＨＥＶＣ  ＨＭにおいて、適合ビットストリームは、ＩＤＲピクチャをまったく含まなくてよいことにさらに留意されたい。ＨＭは、コード化ビデオシーケンスを、復号順序で、ＩＤＲアクセスユニットと、それに続く、任意の後続のＩＤＲアクセスユニットまでだがそれを含まないすべての後続のアクセスユニットを含むゼロ個以上の非ＩＤＲアクセスユニットとからなるアクセスユニットシーケンスとして定義する。ＩＤＲピクチャを含まない適合ビットストリームは、したがってコード化ビデオシーケンスのサブセットまたは不完全なコード化ビデオシーケンスを含み得る。
【０１３０】
[0137]  ビットストリーム中のパラメータセットの更新に関連した問題および提案される技法について、ここで記載する。従来、パラメータセットの更新を実行するかどうか判断するために、デコーダは、同じタイプのより早く受信されたパラメータセットと同じパラメータセットＩＤを有する、特定のパラメータセットＩＤをもつ特定のタイプの新たなパラメータセットが受信されるたびに、パラメータセット内容を比較する。パラメータセット比較は、パラメータセットが、同じ内容それとも異なる内容を含むかを検証するために実行される。パラメータセットが同じ内容を有するかどうかに基づいて、デコーダは、現在受信されているパラメータセットをアクティブ化し、以前アクティブだったパラメータセットを非アクティブ化するかどうか判断する。パラメータセットがコード化ビデオデータとともに帯域内で送信されるケースでは、パラメータセットは、エラー耐性の向上のために、繰り返し送信され得る。この場合、デコーダは、各反復パラメータセットに対して、パラメータセット内容の比較を行えばよい。反復パラメータのセットの比較を行うと、不必要な負担がデコーダに課され得る。
【０１３１】
[0138]  本開示は、特にパラメータセットの更新のケースにおいて、復号処理リソースのより効率的な使用を可能にする技法について記載する。一例では、本開示は、ビットストリームの部分においてパラメータセットが更新され得るかどうか判断するためのビットストリームレベルインジケータを使うように構成されたビデオ処理デバイスについて記載する。いくつかのケースでは、ビットストリームレベルの指示は、パラメータセットが更新され得るかどうかを示すのに使うことができる。指示は、ビットストリーム、たとえば、ＳＰＳに含まれるフラグであってよく、フラグは、すべてのＳＰＳ中で同一であり得る。フラグが１に等しいとき、パラメータセットが更新されてよい。フラグが０に等しいとき、どのパラメータセットも更新することはできない。この場合、ビデオデコーダは、同じタイプであるとともに同じパラメータセットＩＤ値をもつ２つのパラメータセットの内容を比較して、パラメータセットが同じ内容を有するかどうか判断する必要はなく、というのは、フラグが０に等しいとき、パラメータセットの更新は起こり得ず、ビデオデコーダは、２つのパラメータセットが同じ内容を有するかのように動作するからである。
【０１３２】
[0139]  他のケースでは、ビットストリームレベルの指示は、特定のタイプのパラメータセット（たとえば、ＶＰＳ、ＳＰＳ、ＰＰＳ、またはＡＰＳ）が更新され得るかどうかを示すのに使うことができる。指示は、ビットストリーム、たとえば、ＳＰＳに含まれるフラグであってよく、フラグは、すべてのＳＰＳ中で同一であり得る。フラグが１に等しいとき、特定のタイプのパラメータセットが更新され得る。フラグが０に等しいとき、特定のタイプのどのパラメータセットも更新することはできない。この場合、ビデオデコーダは、特定のタイプであるとともに同じパラメータセットＩＤ値をもつ２つのパラメータセットの内容を比較して、パラメータセットが同じ内容を有するかどうか判断する必要はなく、というのは、フラグが０に等しいとき、パラメータセットの更新は起こり得ず、ビデオデコーダは、２つのパラメータセットが同じ内容を有するかのように動作するからである。３タイプのパラメータセット、たとえば、ＳＰＳ、ＰＰＳおよびＡＰＳがあるとき、３つのそのような指示が、各タイプのパラメータセットに１つずつ使われる。
【０１３３】
[0140]  上述した例において、指示は、ビットストリームレベルではパラメータセットに含まれる。別の例では、指示は、ＳＥＩメッセージに含まれてよい。さらに別の例では、指示は、要件としてプロファイルの定義に含まれてよい。いくつかの例では、指示は、ビットストリームレベルではなくコード化ビデオシーケンスレベルで含まれてよい。他の例では、指示は、ビットストリームに含まれなくてよく、代わりに、リアルタイムトランスポートプロトコル（ＲＴＰ）に基づく送信環境、たとえば、セッション交渉または能力交換フェーズ中のメディアデータ移送のためにＲＴＰを使うストリーミングやマルチキャストにおいてビデオビットストリームが使われるとき、指示は、メディアタイプパラメータとして定義され、セッション記述プロトコル（ＳＤＰ）に含まれてよい。追加の例として、ＨＴＴＰストリーミング環境、たとえば、動的適応ストリーミングオーバーＨＴＴＰ（ＤＡＳＨ）において、指示は、メディアプレゼンテーション記述（ＭＰＤ）に含まれるストリームプロパティとして定義され得る。
【０１３４】
[0141]  ＩＤＲピクチャにおける新たなパラメータセットのアクティブ化に関連した問題および提案される技法について、ここで記載する。上述したように、多くのケースにおいて、ビットストリーム接合点ピクチャはＩＤＲピクチャである。接合点ピクチャは通常、接合ビットストリーム中の接合点の直前のピクチャとは異なるビデオ特性を有する。したがって、一般に接合点の所では、各タイプの異なるパラメータセットが必要とされるので、接合点ピクチャに関連付けられたパラメータセットの内容が、前のピクチャに関連付けられたパラメータセットと同一であるかどうかを比較するのは、復号処理リソースの無駄であろう。この場合、パラメータセット内容を比較せずに、接合点ピクチャに関連付けられた各タイプの新たなパラメータセットをアクティブ化することが、より効率的であり得る。さらに、ＩＤＲピクチャが接合点ピクチャであるとき、ＤＰＢオーバーフローを避けるために、ＩＤＲピクチャを復号するときに、ＩＤＲピクチャの前のどのピクチャもまだ出力されていないとしても、それらのピクチャを出力しないことが必要な場合がある。
【０１３５】
[0142]  本開示は、特にビットストリーム接合点にあるパラメータセットの更新のケースにおいて、復号処理リソースのより効率的な使用を可能にする技法について記載する。一例では、本開示は、接合ビットストリームの接合点ピクチャに関連付けられた各タイプの新たなパラメータセットを自動的にアクティブ化するように構成されたビデオ処理デバイスについて記載する。具体的には、多くのケースにおいて、ビットストリーム接合点ピクチャはＩＤＲピクチャである。本技法によると、各ＩＤＲピクチャにおいて、ビデオデコーダは、新たにアクティブ化されたパラメータセットが、パラメータセットＩＤ値と内容とを含む、以前アクティブだったパラメータセットとまったく同じになり得るとしても、各タイプのパラメータセットをアクティブ化する（したがって、以前アクティブだったパラメータセットを非アクティブ化する）ことができる。各ＩＤＲピクチャにおいて新たなパラメータセットをアクティブ化することの、１つの可能な短所は、いくつかの不必要なパラメータセットアクティブ化が実行され得ることである。
【０１３６】
[0143]  別の例では、ＩＤＲピクチャが接合ＩＤＲ（ＳＩＤＲ：splicing IDR）ピクチャであるかどうかを示すための指示が、各ＩＤＲピクチャ用のビットストリームに含まれ得る。この例では、ＳＩＤＲピクチャが指示されるとき、ビデオデコーダは、新たにアクティブ化されたパラメータセットが、パラメータセットＩＤ値と内容とを含む、以前アクティブだったパラメータセットとまったく同じになり得るとしても、各タイプのパラメータセットをアクティブ化する（したがって、以前アクティブだったパラメータセットを非アクティブ化する）ことができる。各ＩＤＲピクチャではなく、ＳＩＤＲピクチャにおいて新たなパラメータセットをアクティブ化するだけで、不必要なパラメータセットアクティブ化が削減され得る。さらに、ＳＩＤＲピクチャが指示されるとき、ピクチャ出力挙動は、ＳＩＤＲピクチャに先行するどのピクチャも出力されないことを示す、ｎｏ＿ｏｕｔｐｕｔ＿ｏｆ＿ｐｒｉｏｒ＿ｐｉｃｓ＿ｆｌａｇが存在し、１に等しかった場合と同じになり得る。ｎｏ＿ｏｕｔｐｕｔ＿ｏｆ＿ｐｒｉｏｒ＿ｐｉｃｓ＿ｆｌａｇは、たとえば、スライスヘッダに存在してもしなくてもよい。いくつかのケースでは、指示は、特殊な固有ＮＡＬユニットタイプであってよい。他のケースでは、指示は、スライスヘッダ、ＰＰＳまたはＡＰＳ中のピクチャレベルのフラグであってよい。
【０１３７】
[0144]  ＲＡＰアクセスユニットからビットストリームへのフルランダムアクセスに関連した問題および提案される技法について、ここで記載する。パラメータセットが、コード化ビデオデータとともに、すなわち、コード化ビデオビットストリーム中で帯域内で移送されるとき、ＩＤＲピクチャまたはＣＲＡピクチャ向けのアクセスユニットからのビットストリームへのランダムアクセスは、復号順序でＩＤＲまたはＣＲＡアクセスユニットよりも早期のアクセスユニットからパラメータセットをフェッチすることを必要とする場合がある。復号順序でＩＤＲまたはＣＲＡアクセスユニットよりも早期のアクセスユニットからパラメータセットをフェッチする必要がないとき、不必要なフェッチング動作を避けるために、ビデオデコーダに通知をすることが有利であろう。
【０１３８】
[0145]  本開示は、特にランダムアクセスのケースにおいて、復号処理リソースのより効率的な使用を可能にするために使われ得る技法について記載する。一例では、本開示は、ビットストリーム中の指示を使って、ＩＤＲまたはＣＲＡアクセスユニットに先行するアクセスユニット中のパラメータセットＮＡＬユニットが、ＩＤＲまたはＣＲＡアクセスユニットを復号するのに必要とされるかどうか判断するように構成されたビデオ処理デバイスについて記載する。具体的には、ビットストリームは、（ビットストリームまたは復号順序で）ＩＤＲまたはＣＲＡアクセスユニットに先行するパラメータセットＮＡＬユニットが、ＩＤＲまたはＣＲＡアクセスユニットと、任意の（ビットストリームまたは復号順序で）後続のアクセスユニットとを復号するのに必要とされるかどうかを示すための、各ＩＤＲまたはＣＲＡアクセスユニットについての指示を含み得る。
【０１３９】
[0146]  指示が、１つのＩＤＲまたはＣＲＡアクセスユニットに当てはまる場合、ビデオデコーダは、ＩＤＲまたはＣＲＡアクセスユニットに先行するどのパラメータセットＮＡＬユニットにも依拠せずに、ＩＤＲまたはＣＲＡアクセスユニットから、ビットストリームにランダムアクセスすることができる。このケースでは、すべてのより早期のＮＡＬユニットは、単にスキップまたは無視されてよい。一例では、ＩＤＲピクチャまたはＣＲＡピクチャについての指示は、（たとえば、固有のＮＡＬユニットタイプをもつ）特定のタイプのＳＰＳを使ってシグナリングすることができ、ここでＳＰＳは、アクセスユニットに存在する場合、アクセスユニットの第１のＮＡＬユニットでも、アクセスユニットデリミタＮＡＬユニットの後の第１のＮＡＬユニットでもよい。別の例では、指示は、固有のアクセスユニットデリミタＮＡＬユニットタイプとともに、またはアクセスユニットデリミタＮＡＬユニットのＮＡＬユニットペイロードの中のフラグとともに、特定のタイプのアクセスユニットデリミタを使ってシグナリングすることができる。さらに別の例では、指示は、アクセスユニット中のＮＡＬユニットヘッダ中のフラグを使ってシグナリングすることができる。さらに別の例では、指示は、アクセスユニット中のＮＡＬユニットヘッダ中のフラグを使ってシグナリングすることができる。
【０１４０】
[0147]  ビットストリーム中のＣＲＡピクチャの先行ピクチャに関連した問題および提案される技法について、ここで記載する。ビットストリームがＣＲＡピクチャから始まり、ＣＲＡピクチャに関連付けられた先行ピクチャがビデオデコーダにおいて存在しないとき、コード化ピクチャバッファ（ＣＰＢ：coded picture buffer）はオーバーフローし得る。したがって、バッファオーバーフローを避けるために、異なるセットの仮定参照デコーダ（ＨＲＤ：hypothetical reference decoder）パラメータが適用される必要があり得る。Ｓ．Ｄｅｓｈｐａｎｄｅら、「Ｓｉｇｎａｌｉｎｇ  ｏｆ  ＣＲＡ  Ｐｉｃｔｕｒｅｓ」、９ｔｈ  Ｍｅｅｔｉｎｇ、Ｇｅｎｅｖａ、ＣＨ、２０１２年４月２７日〜５月７日、Ｄｏｃ．、ＪＣＴＶＣ−Ｉ０２７８（これ以降、「Ｄｅｓｈｐａｎｄｅ」）は、ビデオデコーダが、どのＨＲＤパラメータセットを適用するか判断することができるような、関連先行ピクチャが存在するかどうかを示すための、ＣＲＡピクチャについての指示（たとえば、新たなＮＡＬユニットタイプまたはスライスヘッダ中のフラグ）について記載している。ただし、Ｄｅｓｈｐａｎｄｅによって記載されている指示は、ＣＲＡピクチャのＮＡＬユニットヘッダまたはスライスヘッダに対する変更を行うための外部ネットワークエンティティ（たとえば、ストリーミングサーバまたはメディアアウェアネットワーク要素（ＭＡＮＥ））を要求し、これは、外部ネットワークエンティティにとって面倒または不可能な場合がある。
【０１４１】
[0148]  本開示は、起こり得るバッファオーバーフローを避けるために使うことができる技法について記載する。一例では、本開示は、指示を使って、ビットストリームを開始するＣＲＡピクチャに関連付けられた先行ピクチャが存在するかどうか判断するように構成されたビデオ処理デバイスについて記載する。具体的には、一例では、ビットストリームを開始するＣＲＡピクチャの先行ピクチャが存在しないとき、外部ネットワークエンティティが、ＮＡＬユニットタイプを、ＣＲＡピクチャをＩＤＲピクチャとして示すように変えてよい。別の例では、外部ネットワークエンティティは、ビットストリームを開始するＣＲＡピクチャに関連付けられた先行ピクチャの有無をビデオデコーダに通知することができる。
【０１４２】
[0149]  外部ネットワークエンティティは、ＲＴＳＰに基づくストリーミングシステム用の、リアルタイムストリーミングプロトコル（ＲＴＳＰ）メッセージ、またはＲＴＳＰに基づくストリーミングとセッション告知プロトコル（ＳＡＰ）に基づくブロードキャスト／マルチキャストの両方についてのセッション交渉中に送られるセッション記述プロトコル（ＳＤＰ）パラメータを、静的構成として生成することができる。ＨＴＴＰストリーミング、たとえば、動的適応ストリーミングオーバー（dynamic adaptive streaming over）ＨＴＴＰ（ＤＡＳＨ）において、指示は、異なるユニフォームリソースロケータ（ＵＲＬuniform resource locator）を割り振り、またはＣＲＡピクチャおよび先行ピクチャについての異なるバイトオフセットをもつＵＲＬを割り振ることによって実現され得る。この場合、先行ピクチャをリクエストするかどうか判断するのはビデオデコーダなので、ビデオデコーダは、ＣＲＡピクチャの先行ピクチャが存在するかどうか、自力で判断すればよい。
【０１４３】
[0150]  時間的動きベクトル予測に関連した問題および提案される技法について、ここで記載する。図４を再度参照すると、Ｐｉｃ6、Ｐｉｃ7、およびＰｉｃ9の各々は参照ピクチャとして使われる。上述したように、動き情報シンタックス要素は、現在のピクチャ中のビデオブロックのインター予測のために、参照ピクチャ中の予測ビデオブロックの場所を識別することができる。動き予測は、あらかじめコーディングされたビデオブロックについての動き情報に関連した、所与のビデオブロックについての動き情報（たとえば、動きベクトルおよび参照ピクチャインデックス）を定義するプロセスを参照すればよい。たとえば、動き予測は、あらかじめコーディングされたＣＵの動き情報を使って、コーディングされる現在のＣＵについての動き情報を生成することを伴い得る。動き予測は、現在のＣＵの動きベクトルを通信するのに必要とされるデータの量を削減するのに適用され得る。
【０１４４】
[0151]  動き予測の一例は、マージモード動き予測である。マージモード動き予測において、現在のＣＵについての動き情報は、あらかじめコーディングされた隣接するビデオブロックから継承される。動き予測技法は、インデックス値を使って、現在のビデオブロックがその動き情報をそこから導出する、隣接するビデオブロックを識別することができる。可能な隣接するビデオブロックは、たとえば、現在のＣＵの隣（たとえば、上、下、左、または右）にある、現在のピクチャ中のビデオブロックを含み得る。さらに、可能な隣接するビデオブロックは、現在のピクチャ以外のピクチャ中に配置されたビデオブロック（たとえば、時間的に隣のピクチャからコロケートされたビデオブロック）も含み得る。可能な隣接するビデオブロックが、現在のピクチャ以外のピクチャ中に配置されているとき、時間的動きベクトル予測（ＴＭＶＰ：temporal motion vector prediction）と呼ばれる。たとえば、図４に示す例において、Ｐｉｃ8がＰｉｃ7から動きベクトルを継承する場合、これがＴＭＶＰである。いくつかの事例では、いくつかのピクチャ、スライス、およびＣＵが、ＴＭＶＰを使うのを認め、それ以外はＴＭＶＰを使うのを認めないことが有利な場合がある。
【０１４５】
[0152]  ＨＥＶＣ  ＨＭは、ＴＭＶＰを、ピクチャ単位で有効または無効にさせ、ＰＰＳ中のフラグｅｎａｂｌｅ＿ｔｅｍｐｏｒａｌ＿ｍｖｐ＿ｆｌａｇを使って、ＴＭＰＶの有効化をシグナリングすることができる。上述したように、各スライスヘッダは、特定のＰＰＳ  ＩＤを使って特定のＰＰＳを参照し、特定のＰＰＳ中のフラグ値に基づいて、ＴＭＶＰがピクチャについて有効にされるかどうか判断する。たとえば、スライスが、０に等しいｅｎａｂｌｅ＿ｔｅｍｐｏｒａｌ＿ｍｖｐ＿ｆｌａｇ値をもつＰＰＳを指し、０に等しいｔｅｍｐｏｒａｌ＿ｉｄを有するとき、ＤＰＢ内の参照ピクチャのマーキングプロセスが呼び出される。つまり、復号ピクチャバッファ（ＤＰＢ）中のすべてのピクチャが、「時間的動きベクトル予測に使われていない」としてマーキングされ、より早期の参照ピクチャからのＴＭＶＰは許可されない。
【０１４６】
[0153]  ｅｎａｂｌｅ＿ｔｅｍｐｏｒａｌ＿ｍｖｐ＿ｆｌａｇをＰＰＳに含めることの代替として、Ｌｉｍ、Ｃｈｏｎｇ  Ｓｏｏｎら「Ｈｉｇｈ−ｌｅｖｅｌ  Ｓｙｎｔａｘ：Ｐｒｏｐｏｓｅｄ  ｆｉｘ  ｏｎ  ｓｉｇｎａｌｉｎｇ  ｏｆ  ＴＭＶＰ  ｄｉｓａｂｌｉｎｇ  ｆｌａｇ」９ｔｈ  Ｍｅｅｔｉｎｇ、Ｇｅｎｅｖａ、ＣＨ、２０１２年４月２７日〜５月７日、Ｄｏｃ．、ＪＣＴＶＣ−Ｉ０４２０、（これ以降、「Ｌｉｍ」）には、ｅｎａｂｌｅ＿ｔｅｍｐｏｒａｌ＿ｍｖｐ＿ｆｌａｇをすべてのＰおよびＢスライスヘッダにおいて明示的にシグナリングすることが記載されている。Ｌｉｍに記載されている技法は、マーキングプロセスの必要をなくし、ピクチャ単位の更新に依拠するのではなく依存せずにＴＭＶＰピクチャを判断するが、Ｌｉｍに記載されている技法は、コード化ビデオシーケンス中の多くのピクチャまたはすべてのピクチャがＴＭＶＰを使わないときは効率的でない。Ｌｉｍに記載されている技法では、ピクチャまたはシーケンス内のすべてのＰおよびＢスライスのスライスヘッダが、スライスのうちどれもＴＭＶＰを使わない場合であっても、ｅｎａｂｌｅ＿ｔｅｍｐｏｒａｌ＿ｍｖｐ＿ｆｌａｇを含むことになる。
【０１４７】
[0154]  本開示は、すべてのＰおよびＢスライスヘッダについてのｅｎａｂｌｅ＿ｔｅｍｐｏｒａｌ＿ｍｖｐ＿ｆｌａｇのシグナリングを削減するために使うことができる技法について記載する。一例では、本開示は、ＳＰＳ中のフラグを識別して、時間的動きベクトル予測が有効にされているかどうか判断するように構成されたビデオ処理デバイスについて記載する。具体的には、いくつかの例では、フラグ（たとえば、ｅｎａｂｌｅ＿ｔｅｍｐｏｒａｌ＿ｍｖｐ＿ｐｓ＿ｆｌａｇ）が、ＳＰＳまたはＰＰＳに追加され得る。このフラグが、特定のＳＰＳまたはＰＰＳ中で０に等しいとき、ｅｎａｂｌｅ＿ｔｅｍｐｏｒａｌ＿ｍｖｐ＿ｆｌａｇは、特定のＳＰＳまたはＰＰＳを参照するどのスライスヘッダにも存在しない。このフラグが、特定のＳＰＳまたはＰＰＳ中で１に等しいとき、ｅｎａｂｌｅ＿ｔｅｍｐｏｒａｌ＿ｍｖｐ＿ｆｌａｇは、特定のＳＰＳまたはＰＰＳを参照する各スライスヘッダに存在する。スライスヘッダ中のｅｎａｂｌｅ＿ｔｅｍｐｏｒａｌ＿ｍｖｐ＿ｆｌａｇのセマンティクスは、Ｌｉｍの提案と同じでよい。
【０１４８】
[0155]  ビットストリーム中のコード化ピクチャのための参照ピクチャセットシグナリングに関連した問題および提案される技法について、ここで記載する。上述したように、動きベクトルに加え、動き情報シンタックス要素は、参照ピクチャインデックスも含み得る。ＨＥＶＣ  ＨＭは、参照ピクチャを管理するのに、参照ピクチャセット（ＲＰＳ）に基づく機構を使う。ＲＰＳは、関連ピクチャまたは復号順序で関連ピクチャに続く任意のピクチャのインター予測のために使用され得る、復号順序で関連ピクチャに先行するすべての参照ピクチャからなる、あるピクチャと関連付けられた参照ピクチャのセットを指す。ＨＭでは、各コード化ピクチャのＲＰＳが直接シグナリングされる。ＲＰＳをシグナリングするためのシンタックス要素は、ＳＰＳとスライスヘッダの両方に含まれる。特定のコード化ピクチャでは、ＲＰＳは、スライスヘッダ中のフラグによって示されるようなＳＰＳに含まれる可能なピクチャセット、または、スライスヘッダ中で直接シグナリングされるもののうちの、１つであり得る。
【０１４９】
[0156]  各ピクチャのＲＰＳは、５個のＲＰＳサブセットとも呼ばれる参照ピクチャの５個の異なるリストを備える。５個のＲＰＳサブセットは、ＲｅｆＰｉｃＳｅｔＳｔＣｕｒｒＢｅｆｏｒｅと、ＲｅｆＰｉｃＳｅｔＳｔＣｕｒｒＡｆｔｅｒと、ＲｅｆＰｉｃＳｅｔＳｔＦｏｌｌと、ＲｅｆＰｉｃＳｅｔＬｔＣｕｒｒと、ＲｅｆＰｉｃＳｅｔＬｔＦｏｌｌとを含む。ＲｅｆＰｉｃＳｅｔＳｔＣｕｒｒＢｅｆｏｒｅは、復号順序と出力順序の両方で現在のピクチャに先立ち、現在のピクチャのインター予測において使用され得る、すべての短期間参照ピクチャ（ＳＴＲＰ：short-term reference picture）を含む。ＲｅｆＰｉｃＳｅｔＳｔＣｕｒｒＡｆｔｅｒは、復号順序では現在のピクチャに先立ち、出力順序では現在のピクチャの後に続き、現在のピクチャのインター予測において使用され得る、すべての短期間参照ピクチャからなる。ＲｅｆＰｉｃＳｅｔＳｔＦｏｌｌは、復号順序で現在のピクチャの後にあるピクチャの１つまたは複数のインター予測のために使用されてよく、現在のピクチャのインター予測において使用されない、すべての短期間参照ピクチャからなる。ＲｅｆＰｉｃＳｅｔＬｔＣｕｒｒは、現在のピクチャのインター予測において使うことができるすべての長期参照ピクチャ（ＬＴＲＰ：long-term reference picture）からなる。ＲｅｆＰｉｃＳｅｔＬｔＦｏｌｌは、復号順序で現在のピクチャの後にあるピクチャの１つまたは複数のインター予測のために使用されてよく、現在のピクチャのインター予測において使用されない、すべての長期間参照ピクチャからなる。
【０１５０】
[0157]  Ｋ．Ｓｕｅｈｒｉｎｇら「Ｌｏｎｇ−ｔｅｒｍ  Ｐｉｃｔｕｒｅ  Ｓｉｇｎａｌｉｎｇ  ｆｏｒ  ｅｒｒｏｒ−ｆｒｅｅ  ｅｎｖｉｒｏｎｍｅｎｔｓ」９ｔｈ  Ｍｅｅｔｉｎｇ、Ｇｅｎｅｖａ、ＣＨ、２０１２年４月２７日〜５月７日、Ｄｏｃ．、ＪＣＴＶＣ−Ｉ０１１２（これ以降、「Ｓｕｅｈｒｉｎｇ」）には、１）「参照に使われている」とマーキングされており、２）短期参照ピクチャセットに含まれていない、復号ピクチャバッファ（ＤＰＢ）中の参照ピクチャのピクチャ順序カウント（ＰＯＣ：picture order count）順位リストへのインデックスでＬＴＲＰを識別することが記載されている。Ｓｕｅｈｒｉｎｇは、エラーのない環境では、ＬＴＲＰのそのようなシグナリングが効率的であると主張している。ただし、エラーのない環境では、ＳＴＲＰは、ＤＰＢ中の参照ピクチャのＰＯＣ順位リストへのインデックスによっても識別することができる。
【０１５１】
[0158]  本開示は、ＳＴＲＰを識別するために使うことができる技法について記載する。一例では、本開示は、ＤＰＢ中の参照ピクチャのＰＯＣ順位リストへのインデックスでＳＴＲＰを識別するように構成されたビデオ処理デバイスについて記載する。具体的には、いくつかの例では、各ＳＴＲＰは、ＤＰＢ中の参照ピクチャのＰＯＣ順位リストへのインデックスで識別することができる。いくつかのケースでは、順序は、ＰＯＣ値の昇順であってよい。他のケースでは、順序は、ＰＯＣ値の降順であってよい。最初に指示されたＳＴＲＰについて、インデックスは、たとえば、符号なし整数指数ゴロム（ｕｅ（ｖ））コーディング、切捨て整数指数ゴロム（truncated integer exp-Golomb）（ｔｅ（ｖ））コーディング、または符号なし整数（ｕ（ｖ））コーディングのうち１つを使って、直接コーディングされる。ｕ（ｖ）コーディングの場合、インデックスの、ビットでの長さはＣｅｉｌ（ｌｏｇ２（Ｎ））であり、ここでＮは、ＤＰＢ中の参照ピクチャの数である。他の指示されたＳＴＲＰについては、現在のＳＴＲＰのインデックスと、前のＳＴＲＰのインデックスとの間の違いがシグナリングされる。あるいは、ＤＰＢ中の参照ピクチャは、２つのリストに分割されてよい。この例では、リストのうち１つが、現在のピクチャのＰＯＣ未満のＰＯＣをもつ参照ピクチャを含み、ＰＯＣ値の降順で並べられ得る。リストのうち他の１つは、現在のピクチャのＰＯＣ値よりも大きいＰＯＣ値をもつ参照ピクチャを含み、ＰＯＣ値の昇順で並べられ得る。次いで、短期参照ピクチャセットに含まれるべき各ＳＴＲＰが、リスト（すなわち、２つのリストのうち１つ）およびそのリストへのインデックスで識別され得る。
【０１５２】
[0159]  タイルおよび波面並列処理（ＷＰＰ）のためのピクチャ区分方式のためのカテゴリ前置データバッチングに関連した問題および提案される技法について、ここで記載する。上述したように、ＨＥＶＣ  ＨＭは、４つの異なるピクチャ区分方式、すなわち標準スライスと、エントロピースライスと、タイルと、ＷＰＰとを含む。標準スライスは、Ｈ．２６４／ＡＶＣのものと同様である。各標準スライスは、それ自体のＮＡＬユニット中にカプセル化され、ピクチャ内予測（たとえば、イントラサンプル予測、動き情報予測、コーディングモード予測）およびスライス境界にわたるエントロピーコーディング依存が無効にされる。したがって、標準スライスは、同じピクチャ内の他の標準スライスに依存せずに再構成することができる（ただし、ループフィルタリング動作により、依然として相互依存は存在し得る）。ＨＥＶＣにおける基本ユニット、すなわち、ツリーブロックは、比較的大きいサイズであり得る（たとえば、ツリーブロックは６４×６４であり得る）ので、ツリーブロック内のスライス境界を通してのＭＴＵサイズマッチングを認めるために、特別な形の標準スライスとして、「細粒度スライス（fine granularity slice）」の概念がＨＭには含まれる。スライス粒度は、ピクチャパラメータセット中でシグナリングされ、細粒度スライスのアドレスは依然として、スライスヘッダ中でシグナリングされる。
【０１５３】
[0160]  エントロピースライスは、標準スライスのように、エントロピー復号依存を断ち切るが、ピクチャ内予測（およびフィルタリング）がエントロピースライス境界を横断することは可能にする。エントロピースライスは、したがって、他の復号ステップに影響を与えずに、エントロピー復号を並列化するための軽量機構として使うことができる。各エントロピースライスは、それ自体のＮＡＬユニット中にカプセル化されるが、スライスヘッダシンタックス要素のほとんどは存在せず、先行するフルスライスヘッダから継承されなければならないので、標準スライスと比較して、はるかに短いスライスヘッダを有する。ピクチャ内の隣接し合うエントロピースライスの間でのピクチャ内予測が認められることにより、ピクチャ内予測を可能にするための、要求されるインタープロセッサ／インターコア通信は、相当なものになり得る。エントロピースライスは、エラーを起こしやすい環境でのＭＴＵサイズマッチングに使われることを推奨されず、それは、ピクチャ内予測により、１つのエントロピースライスの損失が、復号順序で次のエントロピースライスの復号の失敗も引き起こすからである。エントロピースライスは、マルチコアまたはマルチＣＰＵアーキテクチャ上でエントロピー復号プロセスを実行するが、それ以外の復号機能性は専用の信号処理ハードウェア上で実行するシステムアーキテクチャへの使用に限定されると思われる。
【０１５４】
[0161]  ＷＰＰにおいて、ピクチャは、ツリーブロックの行に区分される。エントロピー復号および予測は、他の区分におけるツリーブロックからのデータを使うことが認められる。ツリーブロックの行の並列復号を通して並列処理が可能であり、ここである行の復号の開始は、対象ツリーブロックの上および右のツリーブロックに関連したデータが、対象ツリーブロックが復号される前に確実に利用可能になるように、２つのツリーブロック分だけ遅延される。この時差のある開始（グラフィックに表されると、波面のように見える）を使うと、最大で、ピクチャが含むツリーブロック行と同じ数のプロセッサ／コアを用いた並列化が可能である。ＨＥＶＣ  ＨＭは、特定の数の並列プロセッサ／コアにとって有益であるように、異なるツリーブロック行からなるコード化ビットを編成するための機構を含む。たとえば、偶数のツリーブロック行（ツリーブロック行０、２、４、．．．）のコード化ビットはすべて、奇数のツリーブロック行（ツリーブロック行１、３、５、．．．）のコード化ビットの前に来ることが可能であり、それにより、ビットストリームは、２つの並列プロセッサ／コアによって復号可能であるが、より早く来るツリーブロック行（たとえば、ツリーブロック行２）の復号は、後で来るツリーブロック行（たとえば、ツリーブロック行１）を参照する。エントロピースライスと同様、ピクチャ内の隣接し合うツリーブロック行の間でのピクチャ内予測が認められることにより、ピクチャ内予測を可能にするための、要求されるインタープロセッサ／インターコア通信は、相当なものになり得る。ＷＰＰ区分は、適用されないときと比較して、より多くのＮＡＬユニットを生じるわけではなく、したがって、ＷＰＰはＭＴＵサイズマッチングに使うことはできない。
【０１５５】
[0162]  タイルは、ピクチャをタイル列および行に区分する水平および垂直境界を定義する。ツリーブロックの走査順序は、ピクチャのタイルラスター走査の順序で次のタイルの左上ツリーブロックを復号する前に、タイル内で局地的であるように（タイルのツリーブロックラスター走査の順序で）変えられる。標準スライスと同様、タイルは、ピクチャ内予測依存ならびにエントロピー復号依存を断ち切る。ただし、タイルは、個々のＮＡＬユニットに含まれる必要はなく（この点ではＷＰＰと同じ）、したがって、ＭＴＵサイズマッチングに使うことはできない。各タイルは、１つのプロセッサ／コアによって処理することができ、隣接し合うタイルを復号する処理ユニットの間の、ピクチャ内予測のために要求されるインタープロセッサ／インターコア通信は、スライスが２つ以上のタイルにまたがっているケースでは、共有されるスライスヘッダを伝えること、ならびに再構成されたサンプルおよびメタデータのループフィルタリング関連共有に制限される。したがって、タイルは、２つの隣接し合う区分の間のピクチャ内非依存により、ＷＰＰと比較して、メモリ帯域幅においては比較的厳しくない。
【０１５６】
[0163]  ＨＥＶＣ  ＨＭにおいて、標準スライスは、Ｈ．２６４／ＡＶＣにおいてもほぼ同一の形で利用可能である並列化に使うことができる唯一のツールである。標準スライスに基づく並列化は、あまり多くのインタープロセッサまたはインターコア通信は要求しない（通常、ピクチャ内予測により、インタープロセッサまたはインターコアデータ共有よりもはるかに重い、予測符号化ピクチャを復号するときの動き補償のためのインタープロセッサまたはインターコアデータ共有は除く）。ただし、同じ理由で、標準スライスは、ある程度のコーディングオーバーヘッドを要求し得る。さらに、標準スライスは（上で言及した他の区分方式のうちいくつかとは対照的に）、標準スライスのピクチャ内非依存と、各標準スライスがそれ自体のＮＡＬユニットにカプセル化されることとにより、ビットストリーム区分が、ＭＴＵサイズ要件と合致するための主要な機構としても働く。多くのケースにおいて、並列化の目標およびＭＴＵサイズマッチングの目標は、矛盾する要望をピクチャ中のスライスレイアウトに対して突きつけ得る。
【０１５７】
[0164]  簡単のために、４つの異なるピクチャ区分方式の制約が、ＨＭにおいて規定されている。たとえば、ＨＭでは、エントロピースライス、タイル、およびＷＰＰのうち任意の２つからなるどの組合せも、同時に適用することはできない。さらに、ＨＭでは、各スライスおよびタイルについて、以下の条件のいずれかまたは両方が満たされなければならない。すなわち、１）スライス中のすべてのコード化ツリーブロックが、同じタイルに属す、および２）タイル中のすべてのコード化ツリーブロックが、同じスライスに属す。
【０１５８】
[0165]  両方の入口点シグナリング方法を比較的有用でなくする、タイルおよびＷＰＰについての交互データ順序が、Ｓ．Ｋａｎｕｍｕｒｉら「Ｃａｔｅｇｏｒｙ−ｐｒｅｆｉｘｅｄ  ｄａｔａ  ｂａｔｃｈｉｎｇ  ｆｏｒ  ｔｉｌｅｓ  ａｎｄ  ｗａｖｅｆｒｏｎｔｓ」９ｔｈ  Ｍｅｅｔｉｎｇ、Ｇｅｎｅｖａ、ＣＨ、２０１２年４月２７日〜５月７日、Ｄｏｃ．、ＪＣＴＶＣ−Ｉ０４２７（これ以降、「Ｋａｎｕｍｕｒｉ」）に記載されている。Ｋａｎｕｍｕｒｉにおける提案される手法に関連付けられた１つの問題は、サポートされるカテゴリの最大数が３２であることである。ただし、３２よりも多いＷＰＰサブストリーム（たとえば、各ツリーブロック行がサブストリームであり、３２よりも多いツリーブロック行があるとき）または３２よりも多いタイルがある場合があり、各ＷＰＰサブストリームまたはタイル入口点が、たとえば、シングルコアデコーダによる、ピクチャのツリーブロックラスター走査においてツリーブロックを処理する（解析と復号の両方）ために既知であることが要求される。さらに、Ｋａｎｕｍｕｒｉにおける提案される手法は、処理順序によっては、交互配置されたデータをマージするためのマージプロセスまたはＮＡＬユニットのビットストリーム中での前後へのジャンプが必要とされるので、シングルコア復号に負担を課す。
【０１５９】
[0166]  本開示は、カテゴリ前置データバッチングが適用されるかどうかを示すのに使うことができる技法について記載する。一例では、本開示は、インジケータを用いて、カテゴリ前置データバッチングが適用されるかどうかを識別するように構成されたビデオ処理デバイスについて記載する。具体的には、いくつかの例において、カテゴリ前置データバッチングが適用されるかどうかを示すための指示が、ＳＰＳまたはＰＰＳ中で追加されてよい。カテゴリ前置データバッチング（category-prefixed data batching）が適用されないことが示される場合、従来のタイルの扱い方が適用されてよい。他の例では、カテゴリの最大数が変わってよく、カテゴリの最大数の値が、ＳＰＳまたはＰＰＳ中でシグナリングされ得る。さらなる例では、タイルまたはＷＰＰサブストリームからカテゴリへのマッピング（すなわち、どのタイルまたはＷＰＰサブストリームが各カテゴリに属すか）が、たとえば、ＳＰＳまたはＰＰＳ中でシグナリングされ得る。
【０１６０】
[0167]  図６は、ビットストリームの部分においてパラメータセットの更新が起こり得るかどうか判断する動作を示すフローチャートである。図示する動作は、図２のビデオエンコーダ２０に生成された指示に基づいて、図３のビデオデコーダ３０によって実行されるものとして記載されている。
【０１６１】
[0168]  ビデオデコーダ３０は、コード化ビデオスライスとコード化パラメータセットとを表す複数のアクセスユニットを含む１つまたは複数のコード化ビデオシーケンスとともに、ビデオエンコーダ２０からビットストリームを受信することができる。ビデオデコーダ３０は、コード化ビデオシーケンスのうち１つなど、ビットストリームの部分においてパラメータセットの更新が起こり得るかどうかを示すように定義されたフラグを復号する（１３０）。一例では、フラグは、コード化ビデオシーケンスの少なくとも１つのアクセスユニットに含まれるＳＥＩ  ＮＡＬユニットに含まれ得る。別の例では、フラグは、コード化ビデオシーケンスの少なくとも１つのアクセスユニットに含まれるＳＰＳ  ＮＡＬユニットに含まれ得る。
【０１６２】
[0169]  フラグに基づいて、ビデオデコーダ３０は、１つまたは複数のタイプのパラメータセットについて、ビットストリームの部分においてパラメータセットの更新が起こり得るかどうか判断することができる。いくつかのケースでは、フラグは、コード化ビデオシーケンスにおいて、任意のタイプのパラメータセットが更新され得るかどうかを示すことができ、それにより、すべてのタイプのパラメータセットに対してただ１つのフラグが使われ得る。他のケースでは、フラグは、コード化ビデオシーケンスにおいて、特定のタイプのパラメータセットが更新され得るかどうかを示すことができ、それにより、各タイプのパラメータセットに対して異なるフラグが使われ得る。さらに他のケースでは、フラグは、コード化ビデオシーケンスにおいて、２つ以上のタイプのパラメータセットが更新され得るかどうかを示すことができ、それにより、２つ以上のタイプのパラメータセットについての更新状況を示すのに、１つのフラグが使われればよく、追加タイプのパラメータセットについての更新状況を示すのに、別のフラグが使われればよい。
【０１６３】
[0170]  ビデオデコーダ３０は次いで、コード化ビデオシーケンスのアクセスユニットのうち１つに含まれるパラメータセットＮＡＬユニットからの特定のＩＤ値をもつ特定のタイプの第１のパラメータセットを復号する（１３２）。特定のタイプのパラメータセットについて、コード化ビデオシーケンスにおいてパラメータセットの更新が起こり得ないことをフラグが示すとき（１３４の「ＮＯ」分岐）、ビデオデコーダ３０は、ビットストリームの部分全体、すなわち、この例ではコード化ビデオシーケンスについての第１のパラメータセットをアクティブ化する（１３６）。この場合、第１のパラメータセットと同じタイプであるとともに同じ識別値を有する後続のパラメータセットを復号すると、ビデオデコーダ３０は、コード化ビデオシーケンスについての第１のパラメータセットを更新するかどうか判断する必要はなく、後続のパラメータセットを無視することができる。したがって、ビデオデコーダ３０は、第１のパラメータセットの内容が、同じＩＤ値を有する、同じタイプの他のどのパラメータセットにも含まれる内容と同一であるかのように動作することができる。
【０１６４】
[0171]  特定のタイプのパラメータセットについて、コード化ビデオシーケンスにおいてパラメータセットの更新が起こり得ることをフラグが示すとき（１３４の「ＹＥＳ」分岐）、ビデオデコーダ３０は、第１のパラメータセットをアクティブ化する（１３８）。ビデオデコーダ３０は次いで、コード化ビデオシーケンスのアクセスユニットのうち１つに含まれるパラメータセットＮＡＬユニットからの第１のパラメータセットと同じタイプであるとともに同じＩＤ値をもつ第２のパラメータセットを復号する（１４０）。この場合、パラメータセットの更新が起こり得るので、ビデオデコーダ３０は、第２のパラメータセットを記憶して、第１のパラメータセットを置き換えるかどうか判断する（１４２）。
【０１６５】
[0172]  いくつかのケースでは、ビデオデコーダ３０は、コード化ビデオシーケンスについての第２のパラメータセットを自動的にアクティブ化し、第１のパラメータセットを非アクティブ化することができる。他のケースでは、ビデオデコーダ３０は、第１のパラメータセットの内容を第２のパラメータセットの内容と比較することができる。第２のパラメータセットの内容が第１のパラメータセットの内容と異なるとき、ビデオデコーダ３０は、コード化ビデオシーケンスに対して第２のパラメータセットをアクティブ化し、第１のパラメータセットを非アクティブ化する。
【０１６６】
[0173]  図７は、ＣＲＡアクセスユニットからのランダムアクセスが、以前の利用不可能アクセスユニットからパラメータセットをフェッチする必要なしに実行され得るかどうか判断する動作を示すフローチャートである。図示する動作は、図２のビデオエンコーダ２０に生成された指示に基づいて、図３のビデオデコーダ３０によって実行されるものとして記載されている。
【０１６７】
[0174]  ＨＥＶＣ  ＨＭは、ＩＤＲピクチャの場合に起こるようなコーディング効率の低下なしでビットストリームへのランダムアクセスのためのより多くの選択肢を与えるために、ＣＲＡピクチャを導入している。ＣＲＡアクセスユニットは、コード化ビデオシーケンス内のどのポイントに配置されてもよく、復号ピクチャバッファ（ＤＰＢ）をクリーンにしないので、所与のＣＲＡアクセスユニットの先行ピクチャ（すなわち、復号順序でＣＲＡアクセスユニットに続くが、出力順序でＣＲＡアクセスユニットに先行するピクチャ）は、ＣＲＡアクセスユニットの前に復号されるピクチャを参照ピクチャとして使うことができる。ただし、ランダムアクセスが、所与のＣＲＡアクセスユニットの前に復号されるＲＡＰピクチャから始まるとき、先行ピクチャは、正しく復号されるだけでよい。ランダムアクセスが特定のＣＲＡピクチャから始まるケースでは、出力または復号順序でＣＲＡピクチャに先行するすべてのピクチャは、復号されず、参照ピクチャとしての使用に対応不可能である。ＣＲＡピクチャまたは任意の、出力または復号順序において後続のアクセスユニットを復号するために、ビデオデコーダ３０は、利用不可能な以前のピクチャのうち１つについてのアクセスユニットに含まれる１つまたは複数のパラメータセットをフェッチする必要がある場合があるが、これは面倒な動作である。
【０１６８】
[0175]  ビデオデコーダ３０は、コード化ビデオスライスとコード化パラメータセットとを表す複数のアクセスユニットを含む１つまたは複数のコード化ビデオシーケンスとともに、ビデオエンコーダ２０からビットストリームを受信することができる。ビデオデコーダ３０は、ビットストリームのコード化ビデオシーケンスからの１つまたは複数のＣＲＡアクセスユニットを復号する（１５０）。ビデオデコーダ３０は、特定のＣＲＡアクセスユニットからビットストリームへのランダムアクセスが、前の、利用不可能アクセスユニットからのパラメータセットを必要とするかどうかを示すように定義されたフラグも復号する（１５２）。一例では、フラグは、ビットストリームのコード化ビデオシーケンス中の特定のＣＲＡアクセスユニットに含まれるＳＥＩ  ＮＡＬユニットに含まれ得る。
【０１６９】
[0176]  前のアクセスユニットからのどのパラメータセットも、特定のＣＲＡアクセスユニットからのランダムアクセスのためにフェッチされる必要がない（すなわち、フェッチングが必要とされない）ことをフラグが示すとき（１５４の「ＮＯ」分岐）、ビデオデコーダ３０は、フェッチング動作を実行せずに、特定のＣＲＡアクセスユニットからビットストリームへのランダムアクセスを実行（perform）する（１５６）。逆に、特定のＣＲＡピクチャからのランダムアクセスのために、前のアクセスユニットからのパラメータセットが、フェッチされる必要がある（すなわち、フェッチングが必要とされる）ことをフラグが示すとき（１５４の「ＹＥＳ」分岐）、ビデオデコーダ３０は、特定のＣＲＡアクセスユニットからのビットストリームへのランダムアクセスを順序通り実行するかどうか判断する（１５８）。いくつかのケースでは、ビデオデコーダ３０は、ビットストリームへのランダムアクセスが、フェッチング動作を実行せずに別のＲＡＰピクチャから利用可能であると判断し、前のアクセスユニットからパラメータセットをフェッチするのを避けるために、特定のＣＲＡアクセスユニットからのビットストリームへのランダムアクセスを実行しないとさらに判断することができる。他のケースでは、ビデオデコーダ３０は、別のＲＡＰピクチャからビットストリームへのランダムアクセスが利用可能でないと判断し、前のアクセスユニットからパラメータセットをフェッチした後、特定のＣＲＡアクセスユニットからビットストリームへのランダムアクセスを実行するとさらに判断することができる。
【０１７０】
[0177]  このように、フラグに基づいて、ビデオデコーダ３０は最初に、特定のＣＲＡアクセスユニットからのランダムアクセス復号にフェッチング動作が要求されるかどうか判断し、ランダムアクセスをそこから実行するための異なるＲＡＰピクチャを選択することによってフェッチング動作を実行するのを避けることができる。指示は、ＣＲＡアクセスユニットに特に有用であり、というのは、ＣＲＡアクセスユニットが、コード化ビデオシーケンス内のどのポイントに配置されてもよく、ＤＰＢをクリーンにしないからであり、このことは、コーディング効率の低下なしで、ビットストリームへのランダムアクセスのためのより多くの選択肢を提供する。
【０１７１】
[0178]  図８は、ネットワーク３００の一部を形成するデバイスの例示的なセットを示すブロック図である。この例では、ネットワーク３００は、ルーティングデバイス３０４Ａ、３０４Ｂ（まとめて「ルーティングデバイス３０４」と呼ばれる）とトランスコーディングデバイス３０６とを含む。ルーティングデバイス３０４およびトランスコーディングデバイス３０６は、ネットワーク３００の一部を形成し得る少数のデバイスを表すことが意図される。スイッチ、ハブ、ゲートウェイ、ファイアウォール、ブリッジ、および他のそのようなデバイスなどの他のネットワークデバイスも、ネットワーク３００内に含まれ得る。その上、サーバデバイス３０２とクライアントデバイス３０８との間にネットワーク経路に沿って追加のネットワークデバイスが提供され得る。いくつかの例では、サーバデバイス３０２は、図１のソースデバイス１２に対応してよく、クライアントデバイス３０８は、図１の宛先デバイス１４に対応することができる。
【０１７２】
[0179]  概して、ルーティングデバイス３０４は、ネットワーク３００を介してネットワークデータを交換するための１つまたは複数のルーティングプロトコルを実装する。いくつかの例では、ルーティングデバイス３０４は、プロキシまたはキャッシュ動作を実行するように構成され得る。したがって、いくつかの例では、ルーティングデバイス３０４もプロキシデバイスと呼ばれ得る。概して、ルーティングデバイス３０４は、ネットワーク３００を介したルートを発見するためにルーティングプロトコルを実行する。そのようなルーティングプロトコルを実行することによって、ルーティングデバイス３０４Ｂは、それ自体からルーティングデバイス３０４Ａを介してサーバデバイス３０２へ至るネットワークルートを発見することができる。
【０１７３】
[0180]  本開示の技法は、ルーティングデバイス３０４およびトランスコーディングデバイス３０６などのネットワークデバイスによって実装され得るが、クライアントデバイス３０８によっても実装され得る。このように、ルーティングデバイス３０４、トランスコーディングデバイス３０６、およびクライアントデバイス３０８は、本開示に記載する技法のうち１つまたは複数を実装するように構成されたデバイスの例を表す。
【０１７４】
[0181]  １つまたは複数の例では、説明された機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。ソフトウェアで実装される場合、機能は、１つまたは複数の命令またはコードとしてコンピュータ可読媒体上に記憶されてよく、あるいは、コンピュータ可読媒体を介して送信され、ハードウェアベースの処理ユニットによって実行されてよい。コンピュータ可読媒体は、たとえば、通信プロトコルに従って、ある場所から別の場所へのコンピュータプログラムの転送を支援する任意の媒体を含む、データ記憶媒体または通信媒体などの有形媒体に対応するコンピュータ可読記憶媒体を含み得る。このようにして、コンピュータ可読媒体は、一般に、（１）非一時的である有形コンピュータ可読記憶媒体、あるいは（２）信号または搬送波などの通信媒体に対応し得る。データ記憶媒体は、本開示で説明された技法の実装のための命令、コードおよび／またはデータ構造を取り出すために、１つまたは複数のコンピュータあるいは１つまたは複数のプロセッサによってアクセスされ得る任意の利用可能な媒体であり得る。コンピュータプログラム製品はコンピュータ可読媒体を含み得る。
【０１７５】
[0182]  限定ではなく例として、そのようなコンピュータ可読記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ（登録商標）、ＣＤ−ＲＯＭまたは他の光ディスクストレージ、磁気ディスクストレージ、または他の磁気ストレージデバイス、フラッシュメモリ、あるいは、命令またはデータ構造の形態の所望のプログラムコードを記憶するために使用されコンピュータによってアクセスされ得る、任意の他の媒体を備え得る。また、いかなる接続もコンピュータ可読媒体と適切に呼ばれる。たとえば、命令が、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者回線（ＤＳＬ）、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用して、ウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、ＤＳＬ、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。しかしながら、コンピュータ可読記憶媒体およびデータ記憶媒体は、接続、搬送波、信号、または他の一時的媒体を含まないが、代わりに非一時的な有形記憶媒体を対象とすることを理解されたい。本明細書で使用する場合、ディスク（disk）およびディスク（disc）は、コンパクトディスク（ＣＤ）、レーザーディスク（登録商標）、光ディスク、デジタル多用途ディスク（ＤＶＤ）、フロッピー（登録商標）ディスク、およびブルーレイディスクを含み、ディスク（disk）は、通常、磁気的にデータを再生し、ディスク（disc）は、レーザーで光学的にデータを再生する。上記の組合せもコンピュータ可読媒体の範囲内に含めるべきである。
【０１７６】
[0183]  命令は、１つまたは複数のデジタル信号プロセッサ（ＤＳＰ）などの１つまたは複数のプロセッサ、汎用マイクロプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブル論理アレイ（ＦＰＧＡ）、または他の等価な集積回路もしくはディスクリート論理回路によって実行され得る。したがって、本明細書で使用する「プロセッサ」という用語は、前述の構造、または本明細書で説明する技法の実装に好適な他の構造のいずれかを指す。さらに、いくつかの態様では、本明細書で説明した機能は、符号化および復号のために構成された専用のハードウェアおよび／もしくはソフトウェアモジュール内に与えられ得、または複合コーデックに組み込まれ得る。また、本技法は、１つまたは複数の回路または論理要素中に十分に実装され得る。
【０１７７】
[0184]  本開示の技法は、ワイヤレスハンドセット、集積回路（ＩＣ）またはＩＣのセット（たとえば、チップセット）を含む、多種多様なデバイスまたは装置において実装され得る。本開示では、開示する技法を実行するように構成されたデバイスの機能的態様を強調するために様々な構成要素、モジュール、またはユニットについて説明したが、それらの構成要素、モジュール、またはユニットを、必ずしも異なるハードウェアユニットによって実現する必要はない。むしろ、上記で説明したように、様々なユニットが、好適なソフトウェアおよび／またはファームウェアとともに、上記で説明した１つまたは複数のプロセッサを含めて、コーデックハードウェアユニットにおいて組み合わせられるか、または相互動作ハードウェアユニットの集合によって与えられ得る。
【０１７８】
[0185]  様々な例について説明してきた。これらおよび他の例は、以下の特許請求の範囲内である。
【図１】
2015515239.tif 000003
【図２】
2015515239.tif 000004
【図３】
2015515239.tif 000005
【図４】
2015515239.tif 000006
【図５】
2015515239.tif 000007
【図６】
2015515239.tif 000008
【図７】
2015515239.tif 000009
【図８】
2015515239.tif 000010
【手続補正書】
【提出日】平成27年3月16日(2015.3.16)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ビデオデータを復号する方法であって、
ビットストリームの部分においてパラメータセットの更新が起こり得るかどうかを示すインジケータを復号することと、
前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得ることを示す前記インジケータに基づいて、特定のタイプの、かつ特定の識別値を有する現在のパラメータセットが、同じ特定のタイプの、かつ同じ特定の識別値を有する前のパラメータセットの内容とは異なる内容を有することに基づいて、前記パラメータセットの更新を実行すること、または
前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得ないことを示す前記インジケータに基づいて、前記前のパラメータセットと同じ特定のタイプの、かつ同じ特定の識別値を有する前記現在のパラメータセットに基づいて、前記パラメータセットの更新を実行するのを控えることと、
を備える、方法。
【請求項２】
前記インジケータに基づいて、１つまたは複数のタイプのパラメータセットについて、前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得るかどうか判断することをさらに備える、請求項１に記載の方法。
【請求項３】
前記パラメータセットの更新を実行することが、
前記現在のパラメータセットの前記内容を前記前のパラメータセットの前記内容と比較することと、
前記現在のパラメータセットの前記内容が前記前のパラメータセットの前記内容とは異なることに基づいて、前記ビットストリームの前記部分について、前記前のパラメータセットを非アクティブ化し、かつ前記現在のパラメータセットをアクティブ化するために、前記パラメータセットの更新を実行することと
をさらに備える、請求項１に記載の方法。
【請求項４】
前記パラメータセットの更新を実行することが、前記ビットストリームの前記部分について、前記前のパラメータセットを非アクティブ化し、かつ前記現在のパラメータセットをアクティブ化するために、前記パラメータセットの更新を自動的に実行することをさらに備える、請求項１に記載の方法。
【請求項５】
前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得ないことを示す前記インジケータに基づいて、前記ビットストリームの前記部分の先頭において１つまたは複数のパラメータセットを受信することをさらに備える、請求項１に記載の方法。
【請求項６】
前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得ないことを示す前記インジケータに基づいて、前記ビットストリームのコード化ビデオシーケンスとは別個の、帯域外送信中の１つまたは複数のパラメータセットを受信することをさらに備える、請求項１に記載の方法。
【請求項７】
前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得ないことを示す前記インジケータに基づいて、前記第１のパラメータセットのどの反復送信についての内容も比較せずに、前記ビットストリームのコード化ビデオシーケンスとともに、帯域内送信中で１つまたは複数のパラメータセットを受信することをさらに備える、請求項１に記載の方法。
【請求項８】
前記インジケータが、任意のタイプのパラメータセットについて、前記ビットストリームの前記部分においてパラメータセットの更新が起こり得るかどうかを示す、単一のシンタックス要素を備える、請求項１に記載の方法。
【請求項９】
前記インジケータが、複数のシンタックス要素のうち１つを備え、ここで、前記複数のシンタックス要素の各々が、特定のタイプのパラメータセットについて、前記ビットストリームの前記部分においてパラメータセットの更新が起こり得るかどうかを示す、請求項１に記載の方法。
【請求項１０】
前記インジケータが、複数のシンタックス要素のうち１つを備え、ここで、前記複数のシンタックス要素のうち少なくとも１つが、２つ以上の異なるタイプのパラメータセットについて、前記ビットストリームの前記部分においてパラメータセットの更新が起こり得るかどうかを示す、請求項１に記載の方法。
【請求項１１】
前記インジケータが、前記ビットストリームの前記部分についての少なくとも１つのアクセスユニットの補足強調情報（ＳＥＩ）メッセージに含まれるシンタックス要素を備える、請求項１に記載の方法。
【請求項１２】
前記インジケータが、前記ビットストリームの前記部分の少なくとも１つのアクセスユニットに含まれるシーケンスパラメータセット（ＳＰＳ）ネットワークアブストラクションレイヤ（ＮＡＬ）ユニットに含まれるシンタックス要素を備える、請求項１に記載の方法。
【請求項１３】
前記インジケータが、前記ビットストリームに含まれるシンタックス要素、前記ビットストリームのコード化ビデオシーケンスに含まれるシンタックス要素、プロファイル定義中の要件、セッション記述プロトコルに含まれるメディアタイプパラメータ、またはハイパーテキスト転送プロトコル（ＨＴＴＰ）ストリーミング環境についてのメディアプレゼンテーション記述に含まれるストリームプロパティ、のうち１つを備える、請求項１に記載の方法。
【請求項１４】
前記ビットストリームの前記部分が、前記ビットストリームのコード化ビデオシーケンスまたは前記ビットストリームの前記コード化ビデオシーケンス中のピクチャグループ（ＧＯＰ）のうち１つを備える、請求項１に記載の方法。
【請求項１５】
ビデオデータを符号化する方法であって、
ビットストリームの部分においてパラメータセットの更新が起こり得るかどうかを示すインジケータを符号化することを備え、
前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得ることを示す前記インジケータに基づいて、前記インジケータが、ビデオデコーダに、特定のタイプの、かつ特定の識別値を有する現在のパラメータセットが、同じ特定のタイプの、かつ同じ特定の識別値を有する前のパラメータセットの内容とは異なる内容を有することに基づいて、前記パラメータセットの更新を実行するよう通知し、または
前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得ないことを示す前記インジケータに基づいて、前記インジケータが、前記ビデオデコーダに、前記前のパラメータセットと同じ特定のタイプの、かつ同じ特定の識別値を有する前記現在のパラメータセットに基づいて、前記パラメータセットの更新を実行するのを控えるように通知する、方法。
【請求項１６】
前記インジケータが、１つまたは複数のタイプのパラメータセットについて、前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得るかどうかを示す、請求項１５に記載の方法。
【請求項１７】
前記特定の識別値をもつ前記特定のタイプの前記前のパラメータセットを符号化することと、
前記前のパラメータセットと同じタイプの、かつ同じ識別値を有する前記現在のパラメータセットを符号化することと、ここで、前記インジケータが、前記ビットストリームの前記部分について、前記前のパラメータセットを非アクティブ化し、かつ前記現在のパラメータセットをアクティブ化するために、前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得るかどうかを示す、
をさらに備える、請求項１５に記載の方法。
【請求項１８】
前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得ないことを示す前記インジケータに基づいて、前記ビットストリームの前記部分の先頭において１つまたは複数のパラメータセットを符号化することをさらに備える、請求項１５に記載の方法。
【請求項１９】
前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得ないことを示す前記インジケータに基づいて、前記ビットストリームのコード化ビデオシーケンスとは別個の、帯域外送信中の１つまたは複数のパラメータセットを符号化することをさらに備える、請求項１５に記載の方法。
【請求項２０】
前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得ないことを示す前記インジケータに基づいて、前記ビットストリームのコード化ビデオシーケンスとともに、帯域内送信中の前記第１のパラメータセットを符号化することをさらに備える、請求項１５に記載の方法。
【請求項２１】
前記インジケータが、任意のタイプのパラメータセットについて、前記ビットストリームの前記部分においてパラメータセットの更新が起こり得るかどうかを示す単一のシンタックス要素を備える、請求項１５に記載の方法。
【請求項２２】
前記インジケータが、複数のシンタックス要素のうち１つを備え、ここで、前記複数のシンタックス要素の各々が、特定のタイプのパラメータセットについて、前記ビットストリームの前記部分においてパラメータセットの更新が起こり得るかどうかを示す、請求項１５に記載の方法。
【請求項２３】
前記インジケータが、複数のシンタックス要素のうち１つを備え、ここで、前記複数のシンタックス要素のうち少なくとも１つが、２つ以上の異なるタイプのパラメータセットについて、前記ビットストリームの前記部分においてパラメータセットの更新が起こり得るかどうかを示す、請求項１５に記載の方法。
【請求項２４】
前記インジケータが、前記ビットストリームの前記部分についての少なくとも１つのアクセスユニットの補足強調情報（ＳＥＩ）メッセージに含まれるシンタックス要素を備える、請求項１５に記載の方法。
【請求項２５】
前記インジケータが、前記ビットストリームの前記部分の少なくとも１つのアクセスユニットに含まれるシーケンスパラメータセット（ＳＰＳ）ネットワークアブストラクションレイヤ（ＮＡＬ）ユニットに含まれるシンタックス要素を備える、請求項１５に記載の方法。
【請求項２６】
前記インジケータが、前記ビットストリームに含まれるシンタックス要素、前記ビットストリームのコード化ビデオシーケンスに含まれるシンタックス要素、プロファイル定義中の要件、セッション記述プロトコルに含まれるメディアタイプパラメータ、またはハイパーテキスト転送プロトコル（ＨＴＴＰ）ストリーミング環境についてのメディアプレゼンテーション記述に含まれるストリームプロパティのうち１つを備える、請求項１５に記載の方法。
【請求項２７】
前記ビットストリームの前記部分が、前記ビットストリームのコード化ビデオシーケンスまたは前記ビットストリームの前記コード化ビデオシーケンス中のピクチャグループ（ＧＯＰ）のうち１つを備える、請求項１５に記載の方法。
【請求項２８】
ビデオデータをコーディングするためのビデオコーディングデバイスであって、
ビデオデータを記憶するように構成されたメモリと、
ビットストリームの部分においてパラメータセットの更新が起こり得るかどうかを示すインジケータをコーディングすることと、
前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得ることを示す前記インジケータに基づいて、特定のタイプの、かつ特定の識別値を有する現在のパラメータセットが、同じ特定のタイプの、かつ同じ特定の識別値を有する前のパラメータセットの内容とは異なる内容を有することに基づいて、前記パラメータセットの更新を実行すること、または
前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得ないことを示す前記インジケータに基づいて、前記前のパラメータセットと同じ特定のタイプの、かつ同じ特定の識別値を有する前記現在のパラメータセットに基づいて、前記パラメータセットの更新を実行するのを控えることと、
を行うように構成された１つまたは複数のプロセッサと、
を備えるデバイス。
【請求項２９】
前記インジケータが、１つまたは複数のタイプのパラメータセットについて、前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得るかどうかを示す、請求項２８に記載のデバイス。
【請求項３０】
前記プロセッサが、
前記現在のパラメータセットの内容を前記前のパラメータセットの内容と比較するように、および
前記現在のパラメータセットの前記内容が前記前のパラメータセットの前記内容とは異なることに基づいて、前記ビットストリームの前記部分について、前記前のパラメータセットを非アクティブ化し、前記現在のパラメータセットをアクティブ化するために、前記パラメータセットの更新を実行するように、構成される、請求項２８に記載のデバイス。
【請求項３１】
前記プロセッサが、前記ビットストリームの前記部分について、前記前のパラメータセットを非アクティブ化し、前記現在のパラメータセットをアクティブ化するために、前記パラメータセットの更新を自動的に実行するように構成される、請求項２８に記載のデバイス。
【請求項３２】
前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得ないことを示す前記インジケータに基づいて、前記プロセッサが、前記ビットストリームの前記部分の先頭において１つまたは複数のパラメータセットをコーディングするように構成される、請求項２８に記載のデバイス。
【請求項３３】
前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得ないことを示す前記インジケータに基づいて、前記プロセッサが、前記ビットストリームのコード化ビデオシーケンスとは別個の、帯域外送信において１つまたは複数のパラメータセットをコーディングするように構成される、請求項２８に記載のデバイス。
【請求項３４】
前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得ないことを示す前記インジケータに基づいて、前記プロセッサが、前記ビットストリームのコード化ビデオシーケンスとともに、帯域内送信において１つまたは複数のパラメータセットをコーディングするように構成される、請求項２８に記載のデバイス。
【請求項３５】
前記インジケータが、任意のタイプのパラメータセットについて、前記ビットストリームの前記部分においてパラメータセットの更新が起こり得るかどうかを示す単一のシンタックス要素を備える、請求項２８に記載のデバイス。
【請求項３６】
前記インジケータが、複数のシンタックス要素のうち１つを備え、ここで、前記複数のシンタックス要素の各々が、特定のタイプのパラメータセットについて、前記ビットストリームの前記部分においてパラメータセットの更新が起こり得るかどうかを示す、請求項２８に記載のデバイス。
【請求項３７】
前記インジケータが、複数のシンタックス要素のうち１つを備え、ここで、前記複数のシンタックス要素のうち少なくとも１つが、２つ以上の異なるタイプのパラメータセットについて、前記ビットストリームの前記部分においてパラメータセットの更新が起こり得るかどうかを示す、請求項２８に記載のデバイス。
【請求項３８】
前記インジケータが、前記ビットストリームの前記部分についての少なくとも１つのアクセスユニットの補足強調情報（ＳＥＩ）メッセージに含まれるシンタックス要素を備える、請求項２８に記載のデバイス。
【請求項３９】
前記インジケータが、前記ビットストリームの前記部分の少なくとも１つのアクセスユニットに含まれるシーケンスパラメータセット（ＳＰＳ）ネットワークアブストラクションレイヤ（ＮＡＬ）ユニットに含まれるシンタックス要素を備える、請求項２８に記載のデバイス。
【請求項４０】
前記インジケータが、前記ビットストリームに含まれるシンタックス要素、前記ビットストリームのコード化ビデオシーケンスに含まれるシンタックス要素、プロファイル定義中の要件、セッション記述プロトコルに含まれるメディアタイプパラメータ、またはハイパーテキスト転送プロトコル（ＨＴＴＰ）ストリーミング環境についてのメディアプレゼンテーション記述に含まれるストリームプロパティ、のうち１つを備える、請求項２８に記載のデバイス。
【請求項４１】
前記ビットストリームの前記部分が、前記ビットストリームのコード化ビデオシーケンスまたは前記ビットストリームの前記コード化ビデオシーケンス中のピクチャグループ（ＧＯＰ）のうち１つを備える、請求項２８に記載のデバイス。
【請求項４２】
ビデオデータをコーディングするためのビデオコーディングデバイスであって、
ビットストリームの部分においてパラメータセットの更新が起こり得るかどうかを示すインジケータをコーディングするための手段と、
前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得ることを示す前記インジケータに基づいて、特定のタイプの、かつ特定の識別値を有する現在のパラメータセットが、同じ特定のタイプの、かつ同じ特定の識別値を有する前のパラメータセットの内容とは異なる内容を有することに基づいて、前記パラメータセットの更新を実行するための手段、または
前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得ないことを示す前記インジケータに基づいて、前記前のパラメータセットと同じ特定のタイプの、かつ同じ特定の識別値を有する前記現在のパラメータセットに基づいて、前記パラメータセットの更新を実行するのを控えるための手段と、
を備えるデバイス。
【請求項４３】
前記インジケータが、１つまたは複数のタイプのパラメータセットについて、前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得るかどうかを示す、請求項４２に記載のデバイス。
【請求項４４】
ビデオデータをコーディングするための命令を備えるコンピュータ可読媒体であって、前記命令が、実行されると、１つまたは複数のプロセッサに、
ビットストリームの部分においてパラメータセットの更新が起こり得るかどうかを示すインジケータをコーディングすることと、
前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得ることを示す前記インジケータに基づいて、特定のタイプの、かつ特定の識別値を有する現在のパラメータセットが、同じ特定のタイプの、かつ同じ特定の識別値を有する前のパラメータセットの内容とは異なる内容を有することに基づいて、前記パラメータセットの更新を実行すること、または
前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得ないことを示す前記インジケータに基づいて、前記前のパラメータセットと同じ特定のタイプの、かつ同じ特定の識別値を有する前記現在のパラメータセットに基づいて、前記パラメータセットの更新を実行するのを控えることと、
を行わせる、コンピュータ可読媒体。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】０１７８
【補正方法】変更
【補正の内容】
【０１７８】
[0185]  様々な例について説明してきた。これらおよび他の例は、以下の特許請求の範囲内である。
以下に、本願出願の当初の特許請求の範囲に記載された発明を付記する。
［Ｃ１］  ビデオデータを復号する方法であって、
ビットストリームの部分においてパラメータセットの更新が起こり得るかどうかを示すインジケータを復号することを備え、ここで、パラメータセットの更新が、特定のタイプの、かつ特定の識別値を有する現在のパラメータセットが、同じタイプの、かつ同じ識別値を有する前のパラメータセットの内容とは異なる内容を有する場合に起こる、方法。
［Ｃ２］  前記インジケータに基づいて、１つまたは複数のタイプのパラメータセットについて、前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得るかどうか判断することをさらに備える、Ｃ１に記載の方法。
［Ｃ３］  前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得ないことを示す前記インジケータに基づいて、
前記ビットストリームの前記部分全体に対して、特定の識別値をもつ特定のタイプの第１のパラメータセットをアクティブ化することと、
前記ビットストリームの前記部分全体についての前記第１のパラメータセットを更新しないために、前記ビットストリームの前記部分全体において、前記第１のパラメータセットと同じタイプの、かつ同じ識別値を有する他のパラメータセットを無視することと、前記第１のパラメータセットが、前記他のパラメータセットより前のものである、を備える、Ｃ１に記載の方法。
［Ｃ４］  前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得ることを示す前記インジケータに基づいて、
特定の識別値をもつ特定のタイプの第１のパラメータセットをアクティブ化することと、
前記第１のパラメータセットと同じタイプの、かつ同じ識別値を有する第２のパラメータセットを受信することと、前記第１のパラメータセットが、前記第２のパラメータセットより前のものである、
前記第２のパラメータセットを記憶して前記第１のパラメータセットを置き換えるための前記パラメータセットの更新を実行するかどうか判断することとをさらに備える、Ｃ１に記載の方法。
［Ｃ５］  前記パラメータセットの更新を実行するかどうか判断することが、
前記第２のパラメータセットの内容を前記第１のパラメータセットの内容と比較することと、
前記第２のパラメータセットの前記内容が前記第１のパラメータセットの前記内容とは異なることに基づいて、前記ビットストリームの前記部分について、前記第１のパラメータセットを非アクティブ化し、かつ前記第２のパラメータセットをアクティブ化するために、前記パラメータセットの更新を実行することとをさらに備える、Ｃ４に記載の方法。
［Ｃ６］  前記パラメータセットの更新を実行するかどうか判断することが、前記ビットストリームの前記部分について、前記第１のパラメータセットを非アクティブ化し、かつ前記第２のパラメータセットをアクティブ化するために、前記パラメータセットの更新を自動的に実行することをさらに備える、Ｃ４に記載の方法。
［Ｃ７］  前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得ないことを示す前記インジケータに基づいて、前記ビットストリームの前記部分の先頭において１つまたは複数のパラメータセットを受信することをさらに備える、Ｃ１に記載の方法。
［Ｃ８］  前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得ないことを示す前記インジケータに基づいて、前記ビットストリームのコード化ビデオシーケンスとは別個の、帯域外送信中の１つまたは複数のパラメータセットを受信することをさらに備える、Ｃ１に記載の方法。
［Ｃ９］  前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得ないことを示す前記インジケータに基づいて、前記第１のパラメータセットのどの反復送信についての内容も比較せずに、前記ビットストリームのコード化ビデオシーケンスとともに、帯域内送信中で１つまたは複数のパラメータセットを受信することをさらに備える、Ｃ１に記載の方法。
［Ｃ１０］  前記インジケータが、任意のタイプのパラメータセットについて、前記ビットストリームの前記部分においてパラメータセットの更新が起こり得るかどうかを示す、単一のシンタックス要素を備える、Ｃ１に記載の方法。
［Ｃ１１］  前記インジケータが、複数のシンタックス要素のうち１つを備え、ここで、前記複数のシンタックス要素の各々が、特定のタイプのパラメータセットについて、前記ビットストリームの前記部分においてパラメータセットの更新が起こり得るかどうかを示す、Ｃ１に記載の方法。
［Ｃ１２］  前記インジケータが、複数のシンタックス要素のうち１つを備え、ここで、前記複数のシンタックス要素のうち少なくとも１つが、２つ以上の異なるタイプのパラメータセットについて、前記ビットストリームの前記部分においてパラメータセットの更新が起こり得るかどうかを示す、Ｃ１に記載の方法。
［Ｃ１３］  前記インジケータが、前記ビットストリームの前記部分についての少なくとも１つのアクセスユニットの補足強調情報（ＳＥＩ）メッセージに含まれるシンタックス要素を備える、Ｃ１に記載の方法。
［Ｃ１４］  前記インジケータが、前記ビットストリームの前記部分の少なくとも１つのアクセスユニットに含まれるシーケンスパラメータセット（ＳＰＳ）ネットワークアブストラクションレイヤ（ＮＡＬ）ユニットに含まれるシンタックス要素を備える、Ｃ１に記載の方法。
［Ｃ１５］  前記インジケータが、前記ビットストリームに含まれるシンタックス要素、前記ビットストリームのコード化ビデオシーケンスに含まれるシンタックス要素、プロファイル定義中の要件、セッション記述プロトコルに含まれるメディアタイプパラメータ、またはハイパーテキスト転送プロトコル（ＨＴＴＰ）ストリーミング環境についてのメディアプレゼンテーション記述に含まれるストリームプロパティ、のうち１つを備える、Ｃ１に記載の方法。
［Ｃ１６］  前記ビットストリームの前記部分が、前記ビットストリームのコード化ビデオシーケンスまたは前記ビットストリームの前記コード化ビデオシーケンス中のピクチャグループ（ＧＯＰ）のうち１つを備える、Ｃ１に記載の方法。
［Ｃ１７］  ビデオデータを符号化する方法であって、
ビットストリームの部分においてパラメータセットの更新が起こり得るかどうかを示すインジケータを符号化することを備え、ここで、パラメータセットの更新が、特定のタイプの、かつ特定の識別値を有する現在のパラメータセットが、同じタイプの、かつ同じ識別値を有する前のパラメータセットの内容とは異なる内容を有する場合に起こる、方法。
［Ｃ１８］  前記インジケータが、１つまたは複数のタイプのパラメータセットについて、前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得るかどうかを示す、Ｃ１７に記載の方法。
［Ｃ１９］  特定の識別値をもつ特定のタイプの第１のパラメータセットを符号化することと、
前記第１のパラメータセットと同じタイプの、かつ同じ識別値を有する第２のパラメータセットを符号化することと、前記第１のパラメータセットが、前記第２のパラメータセットより前のものであり、ここで、前記インジケータが、前記第２のパラメータセットを記憶して前記第１のパラメータセットを置き換えるために、前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得るかどうかを示す、をさらに備える、Ｃ１７に記載の方法。
［Ｃ２０］  前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得ないことを示す前記インジケータに基づいて、前記ビットストリームの前記部分の先頭において１つまたは複数のパラメータセットを符号化することをさらに備える、Ｃ１７に記載の方法。
［Ｃ２１］  前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得ないことを示す前記インジケータに基づいて、前記ビットストリームのコード化ビデオシーケンスとは別個の、帯域外送信中の１つまたは複数のパラメータセットを符号化することをさらに備える、Ｃ１７に記載の方法。
［Ｃ２２］  前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得ないことを示す前記インジケータに基づいて、前記ビットストリームのコード化ビデオシーケンスとともに、帯域内送信中の前記第１のパラメータセットを符号化することをさらに備える、Ｃ１７に記載の方法。
［Ｃ２３］  前記インジケータが、任意のタイプのパラメータセットについて、前記ビットストリームの前記部分においてパラメータセットの更新が起こり得るかどうかを示す単一のシンタックス要素を備える、Ｃ１７に記載の方法。
［Ｃ２４］  前記インジケータが、複数のシンタックス要素のうち１つを備え、ここで、前記複数のシンタックス要素の各々が、特定のタイプのパラメータセットについて、前記ビットストリームの前記部分においてパラメータセットの更新が起こり得るかどうかを示す、Ｃ１７に記載の方法。
［Ｃ２５］  前記インジケータが、複数のシンタックス要素のうち１つを備え、ここで、前記複数のシンタックス要素のうち少なくとも１つが、２つ以上の異なるタイプのパラメータセットについて、前記ビットストリームの前記部分においてパラメータセットの更新が起こり得るかどうかを示す、Ｃ１７に記載の方法。
［Ｃ２６］  前記インジケータが、前記ビットストリームの前記部分についての少なくとも１つのアクセスユニットの補足強調情報（ＳＥＩ）メッセージに含まれるシンタックス要素を備える、Ｃ１７に記載の方法。
［Ｃ２７］  前記インジケータが、前記ビットストリームの前記部分の少なくとも１つのアクセスユニットに含まれるシーケンスパラメータセット（ＳＰＳ）・ネットワークアブストラクションレイヤ（ＮＡＬ）ユニットに含まれるシンタックス要素を備える、Ｃ１７に記載の方法。
［Ｃ２８］  前記インジケータが、前記ビットストリームに含まれるシンタックス要素、前記ビットストリームのコード化ビデオシーケンスに含まれるシンタックス要素、プロファイル定義中の要件、セッション記述プロトコルに含まれるメディアタイプパラメータ、またはハイパーテキスト転送プロトコル（ＨＴＴＰ）ストリーミング環境についてのメディアプレゼンテーション記述に含まれるストリームプロパティのうち１つを備える、Ｃ１７に記載の方法。
［Ｃ２９］  前記ビットストリームの前記部分が、前記ビットストリームのコード化ビデオシーケンスまたは前記ビットストリームの前記コード化ビデオシーケンス中のピクチャグループ（ＧＯＰ）のうち１つを備える、Ｃ１７に記載の方法。
［Ｃ３０］  ビデオデータをコーディングするためのビデオコーディングデバイスであって、
ビデオデータを記憶するように構成されたメモリと、
ビットストリームの部分においてパラメータセットの更新が起こり得るかどうかを示すインジケータをコーディングするように構成された１つまたは複数のプロセッサと、ここで、パラメータセットの更新が、特定のタイプの、かつ特定の識別値を有する現在のパラメータセットが、同じタイプの、かつ同じ識別値を有する前のパラメータセットの内容とは異なる内容を有する場合に起こる、
を備えるデバイス。
［Ｃ３１］  前記インジケータが、１つまたは複数のタイプのパラメータセットについて、前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得るかどうかを示す、Ｃ３０に記載のデバイス。
［Ｃ３２］  前記ビデオコーディングデバイスがビデオ復号デバイスを備え、ここで、前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得ないことを示す前記インジケータに基づいて、前記プロセッサが、
前記ビットストリームの前記部分全体に対して、特定の識別値をもつ特定のタイプの第１のパラメータセットをアクティブ化することと、
前記ビットストリームの前記部分全体についての前記第１のパラメータセットを更新しないように、前記ビットストリームの前記部分全体において、前記第１のパラメータセットと同じタイプの、かつ同じ識別値を有する他のパラメータセットを無視することと、前記第１のパラメータセットが、前記他のパラメータセットより前のものである、
を行うように構成される、Ｃ３０に記載のデバイス。
［Ｃ３３］  前記ビデオコーディングデバイスがビデオ復号デバイスを備え、ここで、前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得ることを示す前記インジケータに基づいて、前記プロセッサが、
特定の識別値をもつ特定のタイプの第１のパラメータセットをアクティブ化することと、
前記第１のパラメータセットと同じタイプの、かつ同じ識別値を有する第２のパラメータセットを受信することと、前記第１のパラメータセットが、前記第２のパラメータセットより前のものである、
前記第２のパラメータセットを記憶して前記第１のパラメータセットを置き換えるための前記パラメータセットの更新を実行するかどうか判断することと
を行うように構成される、Ｃ３０に記載のデバイス。
［Ｃ３４］  前記プロセッサが、
前記第２のパラメータセットの内容を前記第１のパラメータセットの内容と比較するように、
前記第２のパラメータセットの前記内容が前記第１のパラメータセットの前記内容とは異なることに基づいて、前記ビットストリームの前記部分について、前記第１のパラメータセットを非アクティブ化し、前記第２のパラメータセットをアクティブ化するために、前記パラメータセットの更新を実行するように、
構成される、Ｃ３３に記載のデバイス。
［Ｃ３５］  前記プロセッサが、前記ビットストリームの前記部分について、前記第１のパラメータセットを非アクティブ化し、前記第２のパラメータセットをアクティブ化するために、前記パラメータセットの更新を自動的に実行するように構成される、Ｃ３３に記載のデバイス。
［Ｃ３６］  前記ビデオコーディングデバイスがビデオ符号化デバイスを備え、ここで、前記プロセッサが、
特定の識別値をもつ特定のタイプの第１のパラメータセットを符号化することと、
前記第１のパラメータセットと同じタイプの、かつ同じ識別値を有する第２のパラメータセットを符号化することと、前記第１のパラメータセットが、前記第２のパラメータセットより前のものであり、ここで、前記インジケータが、前記第２のパラメータセットを記憶して前記第１のパラメータセットを置き換えるための、前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得るかどうかを示す、
を行うように構成される、Ｃ３０に記載のデバイス。
［Ｃ３７］  前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得ないことを示す前記インジケータに基づいて、前記プロセッサが、前記ビットストリームの前記部分の先頭において１つまたは複数のパラメータセットをコーディングするように構成される、Ｃ３０に記載のデバイス。
［Ｃ３８］  前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得ないことを示す前記インジケータに基づいて、前記プロセッサが、前記ビットストリームのコード化ビデオシーケンスとは別個の、帯域外送信において１つまたは複数のパラメータセットをコーディングするように構成される、Ｃ３０に記載のデバイス。
［Ｃ３９］  前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得ないことを示す前記インジケータに基づいて、前記プロセッサが、前記ビットストリームのコード化ビデオシーケンスとともに、帯域内送信において１つまたは複数のパラメータセットをコーディングするように構成される、Ｃ３０に記載のデバイス。
［Ｃ４０］  前記インジケータが、任意のタイプのパラメータセットについて、前記ビットストリームの前記部分においてパラメータセットの更新が起こり得るかどうかを示す単一のシンタックス要素を備える、Ｃ３０に記載のデバイス。
［Ｃ４１］  前記インジケータが、複数のシンタックス要素のうち１つを備え、ここで、前記複数のシンタックス要素の各々が、特定のタイプのパラメータセットについて、前記ビットストリームの前記部分においてパラメータセットの更新が起こり得るかどうかを示す、Ｃ３０に記載のデバイス。
［Ｃ４２］  前記インジケータが、複数のシンタックス要素のうち１つを備え、ここで、前記複数のシンタックス要素のうち少なくとも１つが、２つ以上の異なるタイプのパラメータセットについて、前記ビットストリームの前記部分においてパラメータセットの更新が起こり得るかどうかを示す、Ｃ３０に記載のデバイス。
［Ｃ４３］  前記インジケータが、前記ビットストリームの前記部分についての少なくとも１つのアクセスユニットの補足強調情報（ＳＥＩ）メッセージに含まれるシンタックス要素を備える、Ｃ３０に記載のデバイス。
［Ｃ４４］  前記インジケータが、前記ビットストリームの前記部分の少なくとも１つのアクセスユニットに含まれるシーケンスパラメータセット（ＳＰＳ）ネットワークアブストラクションレイヤ（ＮＡＬ）ユニットに含まれるシンタックス要素を備える、Ｃ３０に記載のデバイス。
［Ｃ４５］  前記インジケータが、前記ビットストリームに含まれるシンタックス要素、前記ビットストリームのコード化ビデオシーケンスに含まれるシンタックス要素、プロファイル定義中の要件、セッション記述プロトコルに含まれるメディアタイプパラメータ、またはハイパーテキスト転送プロトコル（ＨＴＴＰ）ストリーミング環境についてのメディアプレゼンテーション記述に含まれるストリームプロパティ、のうち１つを備える、Ｃ３０に記載のデバイス。
［Ｃ４６］  前記ビットストリームの前記部分が、前記ビットストリームのコード化ビデオシーケンスまたは前記ビットストリームの前記コード化ビデオシーケンス中のピクチャグループ（ＧＯＰ）のうち１つを備える、Ｃ３０に記載のデバイス。
［Ｃ４７］  ビデオデータをコーディングするためのビデオコーディングデバイスであって、
ビットストリームの部分においてパラメータセットの更新が起こり得るかどうかを示すインジケータをコーディングするための手段であって、パラメータセットの更新が、特定のタイプの、かつ特定の識別値を有する現在のパラメータセットが、同じタイプの、かつ同じ識別値を有する前のパラメータセットの内容とは異なる内容を有する場合に起こる、手段を備えるデバイス。
［Ｃ４８］  前記インジケータが、１つまたは複数のタイプのパラメータセットについて、前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得るかどうかを示す、Ｃ４７に記載のデバイス。
［Ｃ４９］  ビデオデータをコーディングするための命令を備えるコンピュータ可読媒体であって、前記命令が、実行されると、１つまたは複数のプロセッサに、
ビットストリームの部分においてパラメータセットの更新が起こり得るかどうかを示すインジケータをコーディングすることと、ここで、パラメータセットの更新が、同じタイプの、かつ同じ識別値を有する前のパラメータセットを置き換えるために現在のパラメータセットを記憶することを含む、
前記ビットストリームの前記部分において前記パラメータセットの更新が起こり得ないことを示す前記インジケータに基づいて、前記ビットストリームの前記部分全体に対して、特定の識別値をもつ特定のタイプの第１のパラメータセットをアクティブ化することと
を行わせる、コンピュータ可読媒体。
【国際調査報告】
2015515239.tif 000011
2015515239.tif 000012
2015515239.tif 000013
2015515239.tif 000014