(57)【特許請求の範囲】
【請求項１】
メディアデータを受信する方法であって、
メディアデータの第1のセグメントを受信するステップであって、前記第1のセグメントの前記メディアデータは、第1のストリームアクセスポイントを含む、ステップと、
メディアデータの第2のセグメントを受信するステップであって、前記第2のセグメントの前記メディアデータは、前記第2のセグメントの開始点においてストリームアクセスポイントを欠く、ステップと、
前記第2のセグメントを受信する前に、前記第1のセグメントの前記メディアデータを復号するステップと、
前記第1のストリームアクセスポイントを使用して前記第1のセグメントの前記メディアデータを復号した後、第2のストリームアクセスポイントを含むセグメントを受信する前に、前記第1のセグメントの前記メディアデータを参照して、前記第2のセグメントの前記メディアデータを復号するステップと
を含む方法。
【請求項２】
前記第2のセグメントはストリームアクセスポイントを欠く、請求項1に記載の方法。
【請求項３】
前記第1のセグメントのコード化データは再生持続時間に対応し、前記第2のセグメントのコード化データは同じ再生持続時間に対応する、請求項1に記載の方法。
【請求項４】
表現が、前記第1のセグメントおよび前記第2のセグメントを含む複数のセグメントを含み、前記複数のセグメントの各々は同じ再生持続時間を含む、請求項3に記載の方法。
【請求項５】
前記第1のセグメントのコード化データは再生時間の第1の持続時間に対応し、前記第2のセグメントのコード化データは、前記第1の再生持続時間とは異なる第2の再生持続時間に対応する、請求項1に記載の方法。
【請求項６】
前記ストリームアクセスポイントは、前記第1のセグメントの瞬間デコーダリフレッシュ(IDR)ピクチャを含む、請求項1に記載の方法。
【請求項７】
前記第1のセグメントは、第1の動的適応ストリーミングオーバーHTTP(DASH)セグメントを含み、前記第2のセグメントは、前記第1のDASHセグメントとは異なる第2のDASHセグメントを含む、請求項1に記載の方法。
【請求項８】
1つまたは複数のプロセッサを含む、メディアデータを受信するためのデバイスであって、
前記1つまたは複数のプロセッサは、メディアデータの第1のセグメントを受信するステップであって、前記第1のセグメントの前記メディアデータは、第1のストリームアクセスポイントを含む、ステップと、
メディアデータの第2のセグメントを受信するステップであって、前記第2のセグメントの前記メディアデータは、前記第2のセグメントの開始点においてストリームアクセスポイントを欠く、ステップと、
前記第2のセグメントを受信する前に、前記第1のセグメントの前記メディアデータを復号するステップと、
前記第1のストリームアクセスポイントを使用して前記第1のセグメントの前記メディアデータを復号した後、第2のストリームアクセスポイントを含むセグメントを受信する前に、前記第1のセグメントのデータを参照して、前記第2のセグメントの前記メディアデータを復号するステップと
を行うように構成される、デバイス。
【請求項９】
前記第2のセグメントはストリームアクセスポイントを欠く、請求項8に記載のデバイス。
【請求項１０】
前記第1のセグメントのコード化データは再生持続時間に対応し、前記第2のセグメントのコード化データは同じ再生持続時間に対応する、請求項8に記載のデバイス。
【請求項１１】
表現が、前記第1のセグメントおよび前記第2のセグメントを含む複数のセグメントを含み、前記複数のセグメントの各々は同じ再生持続時間を含む、請求項10に記載のデバイス。
【請求項１２】
前記第1のセグメントの前記メディアデータは、第1の再生時間を有するメディアデータに対応し、前記第2のセグメントの前記メディアデータは、前記第1の再生時間とは異なる第2の再生時間を有するメディアデータに対応する、請求項8に記載のデバイス。
【請求項１３】
前記第1のセグメントは、第1の動的適応ストリーミングオーバーHTTP(DASH)セグメントを含み、前記第2のセグメントは、前記第1のDASHセグメントとは異なる第2のDASHセグメントを含む、請求項8に記載のデバイス。
【請求項１４】
メディアデータを受信するためのデバイスであって、
メディアデータの第1のセグメントを受信するための手段であって、前記第1のセグメントは、第1のストリームアクセスポイントを含む、手段と、
メディアデータの第2のセグメントを受信するための手段であって、前記第2のセグメントの前記メディアデータは、前記第2のセグメントの開始点においてストリームアクセスポイントを欠く、手段と、
前記第2のセグメントを受信する前に、前記第1のセグメントの前記メディアデータを復号するための手段と、
前記第1のストリームアクセスポイントを使用して前記第1のセグメントの前記メディアデータを復号した後、第2のストリームアクセスポイントを含むセグメントを受信する前に、前記第1のセグメントの前記メディアデータを参照して、前記第2のセグメントの前記メディアデータを復号するための手段と
を含むデバイス。
【請求項１５】
前記第2のセグメントはストリームアクセスポイントを欠く、請求項14に記載のデバイス。
【請求項１６】
前記第1のセグメントのコード化データは再生持続時間に対応し、前記第2のセグメントのコード化データは同じ再生持続時間に対応する、請求項14に記載のデバイス。
【請求項１７】
前記第1のセグメントの前記メディアデータは、第1の再生時間を有するメディアデータに対応し、前記第2のセグメントの前記メディアデータは、前記第1の再生時間とは異なる第2の再生時間を有するメディアデータに対応する、請求項14に記載のデバイス。
【請求項１８】
前記第1のセグメントは、第1の動的適応ストリーミングオーバーHTTP(DASH)セグメントを含み、前記第2のセグメントは、前記第1のDASHセグメントとは異なる第2のDASHセグメントを含む、請求項14に記載のデバイス。
【請求項１９】
実行されると、プロセッサに、
メディアデータの第1のセグメントを受信するステップであって、前記第1のセグメントの前記メディアデータは、第1のストリームアクセスポイントを含む、ステップと、
メディアデータの第2のセグメントを受信するステップであって、前記第2のセグメントの前記メディアデータは、前記第2のセグメントの開始点においてストリームアクセスポイントを欠く、ステップと、
前記第2のセグメントを受信する前に、前記第1のセグメントの前記メディアデータを復号するステップと、
前記第1のストリームアクセスポイントを使用して前記第1のセグメントの前記メディアデータを復号した後、第2のストリームアクセスポイントを含むセグメントを受信する前に、前記第1のセグメントの前記メディアデータを参照して、前記第2のセグメントの前記メディアデータを復号するステップと
を行わせる命令を記憶したコンピュータ可読記憶媒体。
【請求項２０】
前記第2のセグメントはストリームアクセスポイントを欠く、請求項19に記載のコンピュータ可読記憶媒体。
【請求項２１】
前記第1のセグメントのコード化データは再生持続時間に対応し、前記第2のセグメントのコード化データは同じ再生持続時間に対応する、請求項19に記載のコンピュータ可読記憶媒体。
【請求項２２】
前記第1のセグメントの前記メディアデータは、第1の再生時間を有するメディアデータに対応し、前記第2のセグメントの前記メディアデータは、前記第1の再生時間とは異なる第2の再生時間を有するメディアデータに対応する、請求項19に記載のコンピュータ可読記憶媒体。
【請求項２３】
前記第1のセグメントは、第1の動的適応ストリーミングオーバーHTTP(DASH)セグメントを含み、前記第2のセグメントは、前記第1のDASHセグメントとは異なる第2のDASHセグメントを含む、請求項19に記載のコンピュータ可読記憶媒体。
【請求項２４】
メディアデータを送る方法であって、
メディアデータの第1のセグメントを取得するステップであって、前記第1のセグメントは、第1のストリームアクセスポイントを含む、ステップと、
前記第1のセグメントをクライアントデバイスに送るステップと、
メディアデータの第2のセグメントを取得するステップであって、前記第2のセグメントの前記メディアデータは、前記第2のセグメントの開始点においてストリームアクセスポイントを欠き、前記第2のセグメントの前記メディアデータは、前記第1のセグメントの前記メディアデータを参照してコード化される、ステップと、
前記第2のセグメントを送信する前に、前記第1のセグメントの前記メディアデータを符号化するステップと、
前記第1のストリームアクセスポイントを使用して前記第1のセグメントの前記メディアデータを符号化した後、第2のストリームアクセスポイントを含むセグメントを送信する前に、前記第2のセグメントを前記クライアントデバイスに送るステップと
を含む方法。
【請求項２５】
前記第2のセグメントはストリームアクセスポイントを欠く、請求項24に記載の方法。
【請求項２６】
前記第2のセグメントは、ストリームアクセスポイントが必要とされる時間的位置に対応すると判定するステップと、前記第2のセグメントの前記開始点以外の前記位置における前記ストリームアクセスポイントに対応するシーン変化瞬間デコーダリフレッシュ(IDR)ピクチャを、前記必要とされるストリームアクセスポイントとして扱うステップとをさらに含む、請求項24に記載の方法。
【請求項２７】
サービスの集合を形成するステップであって、前記サービスの各々はそれぞれの複数のセグメントを含み、前記サービスのうちの1つは、前記第1および第2のセグメントを含む複数のセグメントを含む、ステップをさらに含み、サービスの前記集合を形成するステップは、
第1のサービスを含むように前記サービスのうちの1つを形成するステップであって、前記第1のサービスの第1のセグメントの第1のSAPは、第1のプレゼンテーション時間を有し、前記第1のサービスの第2のセグメントの第2のSAPは、第2のプレゼンテーション時間を有し、前記第1のセグメントおよび前記第2のセグメントは、前記第1のサービスの中で連続している、ステップと、
前記第1のサービスとは別個の、それぞれの複数のサービスを含むように前記サービスのうちの1つまたは複数を形成するステップであって、それにより、前記第1のプレゼンテーション時間と前記第2のプレゼンテーション時間との間のプレゼンテーション時間において、前記複数のサービスは、前記第1のプレゼンテーション時間と、前記第1のプレゼンテーション時間とは異なり、かつ前記複数のサービスの他のサービスの他のSAPのプレゼンテーション時間とは異なる前記第2のプレゼンテーション時間との間にあるプレゼンテーション時間を有するSAPを含む、ステップと
を含む、請求項24に記載の方法。
【請求項２８】
前記第1のプレゼンテーション時間と前記第2のプレゼンテーション時間との間にある前記プレゼンテーション時間を有する前記SAPを含む前記複数のサービスのセグメントが、シーン変化瞬間デコーダリフレッシュ(IDR)ピクチャを含まないとき、第1のサービスを形成するステップは、前記複数のサービスの前記セグメントの長さの倍数である長さを有するように前記第1のセグメントを形成するステップを含み、前記倍数は1よりも大きい、請求項27に記載の方法。
【請求項２９】
前記倍数は、前記複数のサービスの数よりも大きいかまたはそれに等しい、請求項28に記載の方法。
【請求項３０】
前記複数のサービスのセグメントは第1の長さを有し、前記第1のサービスの前記第1のセグメントは、複数のサービスの数と前記第1の長さとの積に前記第1の長さを加えた値に等しい長さを有する、請求項27に記載の方法。
【請求項３１】
サービスの前記集合は、サービスの集合全体の第1のサブセットを含み、サービスの前記集合全体の第2のサブセットは、前記第1のサブセットの前記複数のサービスの前記プレゼンテーション時間のうちの少なくともいくつかのプレゼンテーション時間にSAPを含む複数のサービスを含む、請求項27に記載の方法。
【請求項３２】
サービスの前記集合は、サービスのしきい値数を超える数のサービスを含むかどうかを判定するステップと、
サービスの前記数がサービスの前記しきい値数を超えるときに、前記集合を2つ以上の別個のサービス集合に分割するステップと
をさらに含む、請求項27に記載の方法。
【請求項３３】
前記複数のサービスを形成するステップは、ラウンドロビン挿入に実質的に準拠する方法で前記SAPを挿入するステップと、前記複数のサービスの第1のサービスが、前記ラウンドロビン挿入に対応するプレゼンテーション時間以外のプレゼンテーション時間を有するシーン変化瞬間デコーダリフレッシュ(IDR)ピクチャを含むときに、前記複数のサービスの前記第1のサービスのために、前記ラウンドロビン挿入に対応する前記プレゼンテーション時間において前記複数のサービスの第2のサービスのSAPを挿入するステップとを含む、請求項27に記載の方法。
【請求項３４】
前記第1のセグメントを送るステップは、前記第2のセグメントを取得する前に前記第1のセグメントを送るステップを含む、請求項24に記載の方法。
【請求項３５】
動的適応ストリーミングオーバーHTTP(DASH)の低レイテンシライブプロファイルに準拠する表現を、前記表現が前記第1のセグメントおよび前記第2のセグメントを含むように形成するステップをさらに含む、請求項24に記載の方法。
【請求項３６】
前記第1のセグメントのコード化データは再生持続時間に対応し、前記第2のセグメントのコード化データは同じ再生持続時間に対応する、請求項24に記載の方法。
【請求項３７】
表現が、前記第1のセグメントおよび前記第2のセグメントを含む複数のセグメントを含む、請求項24に記載の方法。
【請求項３８】
前記第1のセグメントを取得するステップは、前記第1のセグメントをコンテンツ準備デバイスから受信するステップを含み、前記第2のセグメントを取得するステップは、前記第2のセグメントを前記コンテンツ準備デバイスから受信するステップを含む、請求項24に記載の方法。
【請求項３９】
前記第1のセグメントを取得するステップは、ライブ記録中にリアルタイムで前記第1のセグメントのためのメディアデータを受信するステップを含む、請求項24に記載の方法。
【請求項４０】
前記第1のセグメントを取得するステップは、前記第1のセグメントのためのメディアデータを符号化するステップを含み、前記第2のセグメントを取得するステップは、前記第2のセグメントのためのメディアデータを符号化するステップを含む、請求項24に記載の方法。
【請求項４１】
前記第2のセグメントのための前記メディアデータを符号化するステップは、前記第1のセグメントのためのデータに関連して、前記第2のセグメントのための前記メディアデータの少なくとも一部分を符号化するステップを含む、請求項40に記載の方法。
【請求項４２】
前記第1のセグメントは、第1の動的適応ストリーミングオーバーHTTP(DASH)セグメントを含み、前記第2のセグメントは、前記第1のDASHセグメントとは異なる第2のDASHセグメントを含む、請求項24に記載の方法。
【請求項４３】
1つまたは複数のプロセッサを含む、メディアデータを送るためのデバイスであって、前記1つまたは複数のプロセッサは、
メディアデータの第1のセグメントを取得するステップであって、前記第1のセグメントの前記メディアデータは、第1のストリームアクセスポイントを含む、ステップと、
前記第1のセグメントをクライアントデバイスに送るステップと、
メディアデータの第2のセグメントを取得するステップであって、前記第2のセグメントの前記メディアデータは、前記第2のセグメントの開始点においてストリームアクセスポイントを欠き、前記第2のセグメントの前記メディアデータは、前記第1のセグメントの前記メディアデータを参照してコード化される、ステップと、
前記第2のセグメントを送信する前に、前記第1のセグメントの前記メディアデータを符号化するステップと、
前記第1のストリームアクセスポイントを使用して前記第1のセグメントの前記メディアデータを符号化した後、第2のストリームアクセスポイントを含むセグメントを送信する前に、前記第2のセグメントを前記クライアントデバイスに送るステップと
を行うように構成される、デバイス。
【請求項４４】
前記第2のセグメントはストリームアクセスポイントを欠く、請求項43に記載のデバイス。
【請求項４５】
前記1つまたは複数のプロセッサは、前記第2のセグメントを取得する前に前記第1のセグメントを送るステップを行うように構成される、請求項43に記載のデバイス。
【請求項４６】
前記第1のセグメントのコード化データは再生持続時間に対応し、前記第2のセグメントのコード化データは同じ再生持続時間に対応する、請求項43に記載のデバイス。
【請求項４７】
表現が、前記第1のセグメントおよび前記第2のセグメントを含む複数のセグメントを含む、請求項43に記載のデバイス。
【請求項４８】
前記1つまたは複数のプロセッサは、前記第1のセグメントのためのメディアデータを符号化するステップと、前記第1のセグメントのためのデータに関連して、前記第2のセグメントのためのメディアデータを符号化するステップとを行うように構成される、請求項43に記載のデバイス。
【請求項４９】
前記第1のセグメントは、第1の動的適応ストリーミングオーバーHTTP(DASH)セグメントを含み、前記第2のセグメントは、前記第1のDASHセグメントとは異なる第2のDASHセグメントを含む、請求項43に記載のデバイス。
【請求項５０】
メディアデータを送るためのデバイスであって、
メディアデータの第1のセグメントを取得するための手段であって、前記第1のセグメントの前記メディアデータは第1のストリームアクセスポイントを含む、手段と、
前記第1のセグメントをクライアントデバイスに送るための手段と、
前記メディアデータの第2のセグメントを取得するための手段であって、前記第2のセグメントの前記メディアデータは、前記第2のセグメントの開始点においてストリームアクセスポイントを欠き、前記第2のセグメントの前記メディアデータは、前記第1のセグメントの前記メディアデータを参照してコード化される、手段と、
前記第2のセグメントを送信する前に、前記第1のセグメントの前記メディアデータを符号化する手段と、
前記第1のストリームアクセスポイントを使用して前記第1のセグメントの前記メディアデータを符号化した後、第2のストリームアクセスポイントを含むセグメントを送信する前に、前記第2のセグメントを前記クライアントデバイスに送るための手段と
を含むデバイス。
【請求項５１】
前記第2のセグメントはストリームアクセスポイントを欠く、請求項50に記載のデバイス。
【請求項５２】
前記第1のセグメントを送るための前記手段は、前記第2のセグメントを取得する前に前記第1のセグメントを送るための手段を含む、請求項50に記載のデバイス。
【請求項５３】
表現が、前記第1のセグメントおよび前記第2のセグメントを含む複数のセグメントを含む、請求項50に記載のデバイス。
【請求項５４】
前記第1のセグメントを取得するための前記手段は、前記第1のセグメントのためのメディアデータを符号化するための手段を含み、前記第2のセグメントを取得するための前記手段は、前記第1のセグメントのためのデータに関連して、前記第2のセグメントのためのメディアデータを符号化するための手段を含む、請求項50に記載のデバイス。
【請求項５５】
前記第1のセグメントは、第1の動的適応ストリーミングオーバーHTTP(DASH)セグメントを含み、前記第2のセグメントは、前記第1のDASHセグメントとは異なる第2のDASHセグメントを含む、請求項50に記載のデバイス。
【請求項５６】
実行されると、プロセッサに、
メディアデータの第1のセグメントを取得するステップであって、前記第1のセグメントの前記メディアデータは、ストリームアクセスポイントを含む、ステップと、
前記第1のセグメントをクライアントデバイスに送るステップと、
メディアデータの第2のセグメントを取得するステップであって、前記第2のセグメントの前記メディアデータは、前記第2のセグメントの開始点においてストリームアクセスポイントを欠き、前記第2のセグメントの前記メディアデータは、前記第1のセグメントの前記メディアデータを参照してコード化される、ステップと、
前記第2のセグメントを送信する前に、前記第1のセグメントの前記メディアデータをコード化するステップと、
前記第1のストリームアクセスポイントを使用して前記第1のセグメントの前記メディアデータをコード化した後、第2のストリームアクセスポイントを含むセグメントを送信する前に、前記第2のセグメントを前記クライアントデバイスに送るステップと
を行わせる命令を記憶したコンピュータ可読記憶媒体。
【請求項５７】
前記第2のセグメントはストリームアクセスポイントを欠く、請求項56に記載のコンピュータ可読記憶媒体。
【請求項５８】
前記プロセッサに、前記第1のセグメントを送るステップを行わせる前記命令は、前記プロセッサに、前記第2のセグメントを取得する前に前記第1のセグメントを送るステップを行わせる命令を含む、請求項56に記載のコンピュータ可読記憶媒体。
【請求項５９】
表現が、前記第1のセグメントおよび前記第2のセグメントを含む複数のセグメントを含む、請求項56に記載のコンピュータ可読記憶媒体。
【請求項６０】
前記プロセッサに、前記第1のセグメントを取得するステップ行わせる前記命令は、前記プロセッサに、前記第1のセグメントのためのメディアデータを符号化するステップを行わせる命令を含み、前記プロセッサに、前記第2のセグメントを取得するステップ行わせる前記命令は、前記プロセッサに、前記第1のセグメントのためのデータに関連して、前記第2のセグメントのためのメディアデータを符号化するステップを行わせる命令を含む、請求項56に記載のコンピュータ可読記憶媒体。
【請求項６１】
前記第1のセグメントは、第1の動的適応ストリーミングオーバーHTTP(DASH)セグメントを含み、前記第2のセグメントは、前記第1のDASHセグメントとは異なる第2のDASHセグメントを含む、請求項56に記載のコンピュータ可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、2011年10月5日に出願された米国仮出願第61/543,792号、および2012年9月19日に出願された米国仮出願第61/703,174号の利益を主張するものであり、これらの米国仮出願の各々の内容全体が参照によって本明細書に組み込まれている。
【０００２】
本開示は、符号化メディアデータの記憶および転送に関する。
【背景技術】
【０００３】
デジタルビデオ機能は、デジタルテレビ、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末(PDA)、ラップトップコンピュータまたはデスクトップコンピュータ、デジタルカメラ、デジタル記録デバイス、デジタルメディアプレーヤ、ビデオゲームデバイス、ビデオゲームコンソール、セルラーまたは衛星無線電話、ビデオ会議デバイスなどを含む、幅広いデバイスに組み込まれ得る。デジタルビデオデバイスは、MPEG-2、MPEG-4、ITU-T H.263またはITU-T H.264/MPEG-4、Part 10、Advanced Video Coding(AVC)、来るべきHigh Efficiency Video Coding(HEVC)規格、およびそのような規格の拡張によって定義される規格に記載されるような、ビデオ圧縮技法を実装して、デジタルビデオ情報をより効率的に送信および受信する。
【０００４】
ビデオ圧縮技法は、空間的予測および/または時間的予測を実行して、ビデオシーケンスに固有の冗長性を低減または除去する。ブロックベースのビデオコーディングの場合、ビデオフレームまたはスライスがブロックに区分され得る。各ブロックはさらに区分され得る。イントラコード化(I)フレームまたはスライスにおけるブロックは、近接ブロックに関する空間的予測を使用して符号化される。インターコード化(PまたはB)フレームまたはスライスにおけるブロックは、同じフレームもしくはスライスにおける近接ブロックに関する空間的予測または他の参照フレームに関する時間的予測を使用し得る。
【０００５】
ビデオデータが符号化された後、ビデオデータは送信または記憶のためにパケット化され得る。ビデオデータは、ITU-T H.264/AVCのような、国際標準化機構(ISO)によるメディアファイルのフォーマットおよびその拡張などの、種々の規格のいずれかに準拠するビデオファイルへと、組み立てられ得る。そのようなパケット化されたビデオデータは、ネットワークストリーミングを使用したコンピュータネットワークを介した送信のような、種々の方法で転送され得る。
【発明の概要】
【課題を解決するための手段】
【０００６】
一般に、本開示は、ネットワークを通じてメディアデータをストリーミングするための技法について説明する。より詳細には、本開示の態様は、たとえば、動的適応ストリーミングオーバーHTTP(DASH)に従って、ネットワークを通じてメディアデータをストリーミングすることに関連するレイテンシを低減することに関する。いくつかの例では、本開示の技法は、セグメントの開始点においてストリームアクセスポイント(SAP)を欠くメディアデータのセグメントを形成するステップを含む。たとえば、1つまたは複数のセグメントは、セグメント全体にわたってSAPを欠くこと、またはセグメントの開始点以外の位置においてSAPを含むことがある。一例として、セグメントの開始点以外の位置におけるSAPが、強制SAP、すなわち、該当する規格によって規定されているSAPの代わりに使用され得る。
【０００７】
一例では、方法が、メディアデータの第1のセグメントを受信するステップであって、第1のセグメントのメディアデータは、第1のストリームアクセスポイントを含む、ステップと、メディアデータの第2のセグメントを受信するステップであって、第2のセグメントのメディアデータは、第2のセグメントの開始点においてストリームアクセスポイントを欠く、ステップと、第1のストリームアクセスポイントの後、第2のストリームアクセスポイントが利用可能になる前に、第1のセグメントのメディアデータの少なくとも一部分に関連して、第2のセグメントのメディアデータの少なくとも一部分を復号するステップとを含む。
【０００８】
別の例では、デバイスが、メディアデータの第1のセグメントを受信するステップであって、第1のセグメントのメディアデータは、第1のストリームアクセスポイントを含む、ステップと、メディアデータの第2のセグメントを受信するステップであって、第2のセグメントのメディアデータは、第2のセグメントの開始点においてストリームアクセスポイントを欠く、ステップと、第1のストリームアクセスポイントの後、第2のストリームアクセスポイントが利用可能になる前に、第1のセグメントのメディアデータの少なくとも一部分に関連して、第2のセグメントのメディアデータの少なくとも一部分を復号するステップとを行うように構成される1つまたは複数のプロセッサを含む。
【０００９】
別の例では、デバイスが、メディアデータの第1のセグメントを受信するための手段であって、第1のセグメントのメディアデータは、第1のストリームアクセスポイントを含む、手段と、メディアデータの第2のセグメントを受信するための手段であって、第2のセグメントのメディアデータは、第2のセグメントの開始点においてストリームアクセスポイントを欠く、手段と、第1のストリームアクセスポイントの後、第2のストリームアクセスポイントが利用可能になる前に、第1のセグメントのメディアデータの少なくとも一部分に関連して、第2のセグメントのメディアデータの少なくとも一部分を復号するための手段とを含む。
【００１０】
別の例では、コンピュータ可読記憶媒体が、実行されると、プロセッサに、メディアデータの第1のセグメントを受信するステップであって、第1のセグメントのメディアデータは、第1のストリームアクセスポイントを含む、ステップと、メディアデータの第2のセグメントを受信するステップであって、第2のセグメントのメディアデータは、第2のセグメントの開始点においてストリームアクセスポイントを欠く、ステップと、第1のストリームアクセスポイントの後、第2のストリームアクセスポイントが利用可能になる前に、第1のセグメントのメディアデータの少なくとも一部分に関連して、第2のセグメントのメディアデータの少なくとも一部分を復号するステップとを行わせる命令を記憶している。
【００１１】
別の例では、方法が、メディアデータの第1のセグメントを取得するステップであって、第1のセグメントのメディアデータは、第1のストリームアクセスポイントを含む、ステップと、第1のセグメントをクライアントデバイスに送るステップと、メディアデータの第2のセグメントを取得するステップであって、第2のセグメントのメディアデータは、第2のセグメントの開始点においてストリームアクセスポイントを欠き、第2のセグメントのメディアデータの少なくとも一部分は、第1のセグメントのメディアデータの一部分に関連してコード化される、ステップと、第1のストリームアクセスポイントの後、第2のストリームアクセスポイントが利用可能になる前に、第2のセグメントをクライアントデバイスに送るステップとを含む。
【００１２】
別の例では、デバイスが、メディアデータの第1のセグメントを取得するステップであって、第1のセグメントのメディアデータは、第1のストリームアクセスポイントを含む、ステップと、第1のセグメントをクライアントデバイスに送るステップと、メディアデータの第2のセグメントを取得するステップであって、第2のセグメントのメディアデータは、第2のセグメントの開始点においてストリームアクセスポイントを欠き、第2のセグメントのメディアデータの少なくとも一部分は、第1のセグメントのメディアデータの一部分に関連してコード化される、ステップと、第1のストリームアクセスポイントの後、第2のストリームアクセスポイントが利用可能になる前に、第2のセグメントをクライアントデバイスに送るステップとを行うように構成される1つまたは複数のプロセッサを含む。
【００１３】
別の例では、デバイスが、メディアデータの第1のセグメントを取得するための手段であって、第1のセグメントのメディアデータは、第1のストリームアクセスポイントを含む、手段と、第1のセグメントをクライアントデバイスに送るための手段と、メディアデータの第2のセグメントを取得するための手段であって、第2のセグメントのメディアデータは、第2のセグメントの開始点においてストリームアクセスポイントを欠き、第2のセグメントのメディアデータの少なくとも一部分は、第1のセグメントのメディアデータの一部分に関連してコード化される、手段と、第1のストリームアクセスポイントの後、第2のストリームアクセスポイントが利用可能になる前に、第2のセグメントをクライアントデバイスに送るための手段とを含む。
【００１４】
別の例では、コンピュータ可読記憶媒体が、実行されると、プロセッサに、メディアデータの第1のセグメントを取得するステップであって、第1のセグメントのメディアデータは、第1のストリームアクセスポイントを含む、ステップと、第1のセグメントをクライアントデバイスに送るステップと、第2のセグメントを取得するステップであって、第2のセグメントのメディアデータは、第2のセグメントの開始点においてストリームアクセスポイントを欠き、第2のセグメントのメディアデータの少なくとも一部分は、第1のセグメントのメディアデータの一部分に関連してコード化される、ステップと、第1のストリームアクセスポイントの後、第2のストリームアクセスポイントが利用可能になる前に、第2のセグメントをクライアントデバイスに送るステップとを行わせる命令を記憶している。
【００１５】
1つまたは複数の例の詳細が、以下の添付の図面および説明において述べられる。他の特徴、目的、および利点は、説明、図面、および特許請求の範囲から明らかになるであろう。
【図面の簡単な説明】
【００１６】
【図１】ネットワークを通じてメディアデータをストリーミングするための技法を実施する、例示的なシステムを示すブロック図である。
【図２】本開示の態様による、例示的な取出しユニットを示すブロック図である。
【図３】例示的なマルチディアコンテンツの要素を示す概念図である。
【図４】本開示の態様による、ビデオデータの例示的なセグメントを示すブロック図である。
【図５】本開示の技法を実行するための例示的な方法を示すフローチャートである。
【図６】一連のコード化ビデオフレームおよびビデオフレームを含むセグメントを示す概念図である。
【図７】IDR間隔によって異なるエラー秒を示す実証的テスト結果を示すグラフである。
【図８】前方向誤り訂正(FEC)による実証的テスト結果の別の例を示すグラフである。
【図９】(プレゼンテーション時間における)様々なIDR間隔におけるセグメントのビットレートを示す実証的テスト結果を示すグラフである。
【図１０】様々なピーク信号対雑音比(PSNR)を平均オピニオン評点(MOS)に対して示す1組のグラフである。
【図１１】FECを伴う場合と伴わない場合の両方における様々なデータバースト間隔のエラー秒数を示す実証的テスト結果を示すグラフである。
【図１２】様々なセグメント持続時間のIDR間隔の様々な例を示す概念図である。
【図１３】ストリームアクセスポイント(SAP)を含まない表現の1つまたは複数のセグメントを送るための例示的な方法を示すフローチャートである。
【図１４】DASHライブおよび低レイテンシライブプロファイルのデータ構成の例を示す概念図である。
【図１５】物理層における例示的なDASHライブおよびDASH低レイテンシライブプロファイルのセグメント当たりビットレートを示す概念図である。
【図１６】低レイテンシライブセグメントのピークツーピークビットレート変動を最小化するための技法を示す概念図である。
【図１７】シーン変化IDRフレームが強制IDRフレームと同時に発生する、DASHライブおよびDASH低レイテンシライブプロファイルに対応する例示的な表現を示す概念図である。
【図１８】同時に発生しないシーン変化IDRフレームが存在する場合におけるピークツーピークビットレート変動を最小化するための技法を示す概念図である。
【図１９】シーン変化IDRフレームを考慮するほぼ最適な強制IDRピクチャシーケンスを示す概念図である。
【図２０】本開示のいくつかの技法による表現を形成するための別の例示的な方法を示すフローチャートである。
【発明を実施するための形態】
【００１７】
一般に、本開示は、ネットワークを通じて、オーディオデータおよびビデオデータのようなマルチメディアデータをストリーミングするための技法について説明する。本開示の技法は、動的適応ストリーミングオーバーHTTP(DASH)に関連して使用され得る。本開示は、ネットワークストリーミングに関連して実行され得る様々な技法について説明し、それらの技法のいずれかまたはすべては、単独で、または任意の組合せで実施され得る。以下でより詳しく説明されるように、ネットワークストリーミングを実行する様々なデバイスは、本開示の技法を実施するように構成され得る。
【００１８】
DASHとネットワークを通じてデータをストリーミングするための同様の技法とに従って、(テキスト重畳または他のデータも含み得る、動画または他のオーディオ/ビデオコンテンツなどの)マルチメディアコンテンツが、種々の方法で、かつ種々の特性とともに符号化され得る。コンテンツ準備デバイスは、同じマルチメディアコンテンツの複数の表現を形成し得る。各表現は、コーディング特性およびレンダリング特性のような、特性の特定のセットに対応して、様々なコーディング能力およびレンダリング能力を有する種々の異なるクライアントデバイスによって使用可能なデータを提供することができる。その上、様々なビットレートを有する表現は、帯域幅の適応を可能にし得る。すなわち、クライアントデバイスは、現在利用可能な帯域幅の量を判定し、利用可能な帯域幅の量とともにクライアントデバイスのコーディング能力およびレンダリング能力に基づいて、表現を選択することができる。
【００１９】
いくつかの例では、コンテンツ準備デバイスは、表現のセットが共通の特性のセットを有することを示すことができる。コンテンツ準備デバイスは次いで、セット中の表現が帯域幅の適応に使用され得るので、セット中の表現が適応セットを形成することを示すことができる。場合によっては、適応セットは「表現グループ」と呼ばれることもある。セット中の表現は、ビットレート、解像度、および/またはフレームレートが異なり得るが、それ以外は実質的に同じ特性を共有し得る。このようにして、クライアントデバイスは、マルチメディアコンテンツの適応セットに関する共通の特性の様々なセットを判定し、クライアントデバイスのコーディング能力およびレンダリング能力に基づいて、適応セットを選択することができる。次いで、クライアントデバイスは、帯域幅の利用可能性に基づいて、選択された適応セット中の複数の表現を適応的に切り替えることができる。
【００２０】
コンテンツ準備デバイスは、3GPP(Third Generation Partnership Project)によって規定されたフォーマットによるメディアプレゼンテーション記述(MPD)ファイルなどのマニフェストファイルの様々な部分に別個のネットワークロケーションを提供することもできる。すなわち、マニフェストファイルの様々な部分は、たとえば、ユニフォームリソースロケータ(URL)などの様々なユニフォームリソース識別子(URI)によって独立してアドレス可能であり得る。マニフェストファイルの最初の部分は、マニフェストファイルの別の部分のURI、URL、または他のロケーション識別子を含み得る。たとえば、マニフェストファイルの第1の部分は、上記で説明したように適応セットの共通の特性の説明を含み得る。
【００２１】
適応セットの各々は、それぞれの適応セットにおける表現のメディアデータのロケーションを示すデータを含み得る、マニフェストファイルのそれぞれの異なる部分に関連付けられ得る。このようにして、クライアントデバイスは、マニフェストファイルの第1の部分を受信し、適切な適応セットを選択し、選択された適応セットに関するマニフェストファイルの別の部分を取り出し、選択されたグループの表現を選択し、マニフェストファイルの他の部分を使用して、選択された表現のデータを取り出すことができる。さらに、クライアントデバイスは、マニフェストファイルの他の部分、すなわち、選択された適応セットに固有の部分を使用して、変化するネットワーク帯域幅に適応することができる。
【００２２】
DASHは、ライブコンテンツ、すなわち、たとえばスポーツ行事、報道価値のある出来事、または視聴者が実質的にリアルタイムで見たいと思う他の事象の最中に生で記録されるメディアコンテンツのストリーミングの文脈で使用されることもある。たとえば、Enhanced Multimedia Broadcast Multicast Service(eMBMS)が、実質的にリアルタイムで形成されるDASHセグメントをストリーミングするために使用され得る。できるだけリアルタイムに近い状態でコンテンツを見ることを視聴者が望むので、レイテンシ(すなわち、事象が発生してから視聴者が事象を見ることができるようになるまでの遅延)を低減する技法が大いに望ましい。本開示は、以下でより詳細に説明するように、レイテンシを低減するために使用され得る技法について説明する。
【００２３】
メディアコンテンツの表現のセグメントのようなビデオファイルは、ISOベースメディアファイルフォーマット、Scalable Video Coding(SVC)ファイルフォーマット、Advanced Video Coding(AVC)ファイルフォーマット、Third Generation Partnership Project(3GPP)ファイルフォーマット、および/またはMultiview Video Coding(MVC)ファイルフォーマット、または他の同様のビデオファイルフォーマットのうちのいずれかに従ってカプセル化されたビデオデータに準拠し得る。
【００２４】
ISOベースメディアファイルフォーマットは、メディアの交換、管理、編集、および提示を支援するフレキシブルで拡張可能なフォーマットで提示するための、時限のメディア情報を格納するように設計される。ISOベースメディアファイルフォーマット(ISO/IEC14496-12:2004)は、時間に基づくメディアファイルのための一般的な構造を定義する、MPEG-4 Part-12で規定される。ISOベースメディアファイルフォーマットは、H.264/MPEG-4 AVCビデオ圧縮のサポートを定義されるAVCファイルフォーマット(ISO/IEC14496-15)、3GPPファイルフォーマット、SVCファイルフォーマット、およびMVCファイルフォーマットのようなファミリ中の、他のファイルフォーマットの基礎として使用される。3GPPファイルフォーマットおよびMVCファイルフォーマットは、AVCファイルフォーマットの拡張である。ISOベースメディアファイルフォーマットは、オーディオビジュアル表現のような、メディアデータの時限のシーケンスの、タイミング、構造、およびメディア情報を含む。ファイル構造は、オブジェクト指向であってよい。ファイルは、非常に簡単に基本的なオブジェクトに分解することができ、オブジェクトの構造はオブジェクトのタイプから示唆される。
【００２５】
ISOベースメディアファイルフォーマット(およびその拡張)に準拠するファイルは、「ボックス」と呼ばれる一連のオブジェクトとして形成され得る。ISOベースメディアファイルフォーマットにおけるデータがボックスに格納され得るので、ファイル内に他のデータが格納される必要はなく、ファイル内のボックスの外側にデータがある必要はない。これは、特定のファイルフォーマットによって要求される任意の最初の特徴を含む。「ボックス」は、一意のタイプの識別子および長さによって定義されたオブジェクト指向のビルディングブロックであり得る。通常は、1つのプレゼンテーションが1つのファイルに格納され、メディアプレゼンテーションは自己完結型である。動画コンテナ(動画ボックス)は、メディアのメタデータを格納することができ、ビデオおよびオーディオフレームは、メディアデータコンテナに格納されてよく、他のファイル中にあってもよい。
【００２６】
表現(運動シーケンス)は、セグメントと呼ばれることがあるいくつかのファイルに格納され得る。タイミング情報およびフレーミング(位置およびサイズの)情報は一般に、ISOベースメディアファイル中にあり、補助ファイルは基本的にあらゆるフォーマットを使用することができる。このプレゼンテーションは、プレゼンテーションを格納するシステムに対して「ローカル」であってよく、またはネットワークもしくは他のストリーム配信機構を介して提供されてよい。
【００２７】
随意のメタデータトラックを使用して、各トラックが有する「興味深い特性」のタグを各トラックにつけることができ、興味深い特性に関する各トラックの値(たとえば、各トラックのビットレート、画面サイズ、または言語)は、グループの他のメンバーとは異なり得る。トラック内のいくつかのサンプルは、特別な特性を有し得るか、または個々に識別され得る。その特性の一例は、同期ポイントである(ビデオIフレームであることが多い)。これらのポイントは、各トラックにおける特別なテーブルによって識別され得る。より一般的には、トラックサンプル間の依存性も、メタデータを使用して文書化され得る。メタデータは、ビデオトラックのように一連のファイルフォーマットサンプルとして構造化され得る。そのようなトラックは、メタデータトラックと呼ばれることがある。各メタデータサンプルは、メタデータステートメントとして構造化され得る。対応するファイルフォーマットサンプルまたはその構成要素であるサンプルについて尋ねられる可能性のある様々な質問に対応する様々な種類のステートメントがある。
【００２８】
メディアがストリーミングプロトコルを通じて配信されるとき、メディアをファイル内での表現方法から変更する必要があり得る。このことの一例は、メディアがリアルタイムトランスポートプロトコル(RTP)を通じて送信される場合である。ファイルにおいて、たとえば、各ビデオフレームは、ファイルフォーマットサンプルとして連続して記憶される。RTPにおいて、これらのフレームをRTPパケットに配置するには、使用されるコーデックに固有のパケット化ルールに従わなければならない。実行時にそのようなパケット化を計算するように、ストリーミングサーバが構成され得る。ただし、ストリーミングサーバの支援のためのサポートがある。
【００２９】
本開示の技法は、たとえば、動的適応ストリーミングオーバーHTTP(DASH)による、HTTPストリーミングなどのネットワークストリーミングプロトコルに適用可能であり得る。HTTPストリーミングにおいて、頻繁に使用される動作には、GETおよび部分GETがある。GET動作は、所与のユニフォームリソースロケータ(URL)または他の識別子、たとえばURIに関連付けられるファイル全体(DASHの文脈ではセグメントと呼ばれることが多い)を取り出す。部分GET動作は、入力パラメータとしてバイト範囲を受信し、ファイルまたはセグメントのうちの、受信されたバイト範囲に対応する連続した数のバイトを取り出す。したがって、部分GET動作は、ファイルまたはセグメント内の1つまたは複数の個々の動画フラグメントを取得できるので、動画フラグメントはHTTPストリーミングのために提供され得る。動画フラグメントにおいて、異なるトラックのいくつかのトラックフラグメントが存在し得ることに留意されたい。HTTPストリーミングにおいて、メディア表現は、再生のためにクライアントにとってアクセス可能な関連マルチメディアコンテンツのタイムラインを表す1つまたは複数のファイルまたはセグメントを含むデータの構造化された集合体であり得る。クライアントは、メディアデータ情報を要求およびダウンロードして、ユーザにストリーミングサービスを提示することができる。代替的に、DASHセグメントは、ブロードキャストまたはマルチキャストプロトコル、たとえばeMBMSを使用して配信され得る。
【００３０】
HTTPストリーミングを使用して3GPPデータをストリーミングする例では、マルチメディアコンテンツのビデオデータおよび/またはオーディオデータに関して複数の表現が存在し得る。そのような表現のマニフェストは、メディアプレゼンテーション記述(MPD)データ構造において定義され得る。メディア表現は、HTTPストリーミングクライアントデバイスにとってアクセス可能なデータの構造化された集合体に相当し得る。HTTPストリーミングクライアントデバイスは、メディアデータ情報を要求およびダウンロードして、クライアントデバイスのユーザにストリーミングサービスを提示することができる。メディア表現は、MPDの更新を含み得るMPDデータ構造で記述され得る。
【００３１】
マルチメディアコンテンツは、1つまたは複数の期間のシーケンスを格納し得る。期間は、MPDにおいてPeriod要素によって画定され得る。各期間は、MPDにおいて属性startを有し得る。MPDは、期間ごとにstart属性およびavailableStartTime属性を含み得る。ライブサービスの場合、期間のstart属性とMPD属性availableStartTimeとの合計が、UTCフォーマットによる期間の利用可能時間、特に、対応する期間における各表現の第1のメディアセグメントを指定し得る。オンデマンドサービスの場合、第1の期間のstart属性は0であり得る。任意の他の期間では、start属性は、対応する期間の開始時間と第1の期間の開始時間との間の時間オフセットを指定し得る。各期間は、次の期間の開始まで、または最後の期間の場合にはメディアプレゼンテーションの終了まで及び得る。期間開始時間は、正確であり得る。期間開始時間は、すべての先行期間のメディアの再生から生じる実際のタイミングを反映することができる。
【００３２】
各期間は、同じメディアコンテンツのための1つまたは複数の表現を格納し得る。表現は、オーディオデータまたはビデオデータの、多数の符号化バージョンの選択肢の1つであり得る。表現は、符号化のタイプなどの様々な特性によって、たとえば、ビデオデータのビットレート、解像度、および/またはコーデック、ならびにオーディオデータのビットレート、言語、および/またはコーデックによって異なり得る。表現という用語は、マルチメディアコンテンツのある特定の期間に対応し、ある特定の方法で符号化された、符号化オーディオデータまたは符号化ビデオデータのあるセクションを指すために使用され得る。
【００３３】
特定の期間の表現が、MPDにおいてgroup属性または適応セット属性によって示され得るグループまたは適応セットに割り当てられ得る。同じ適応セット中の表現は一般に、互いに代替物であると考えられる。たとえば、ある特定の期間のビデオデータの各表現は、同じ適応セットに割り当てられ得るので、表現のうちのいずれもが、対応する期間のマルチメディアコンテンツのビデオデータを表示するための復号のために、選択され得る。いくつかの例では、1つの期間内のメディアコンテンツは、存在する場合には適応セット0からの1つの表現、または各々の非ゼロの適応セットからの最大でも1つの表現の組合せのいずれかによって表され得る。ある期間の各表現のタイミングデータは、期間の開始時間に対して表され得る。
【００３４】
表現は、1つまたは複数のセグメントを含み得る。各表現は、初期化セグメントを含んでよく、または表現の各セグメントは、自己初期化するものであってよい。初期化セグメントは、存在する場合、表現にアクセスするための初期化情報を格納し得る。一般に、初期化セグメントは、メディアデータを格納しない。セグメントは、ユニフォームリソースロケータ(URL)などの識別子によって一意に参照され得る。MPDは、セグメントごとに識別子を提供することができる。いくつかの例では、MPDはまた、URLまたはURIによってアクセス可能なファイル内のセグメントのためのデータに対応し得る、range属性の形式で、バイト範囲を提供することができる。
【００３５】
各表現はまた、1つまたは複数のメディア構成要素を含んでよく、各メディア構成要素は、オーディオ、ビデオ、および/または時限のテキスト(たとえば、クローズドキャプションのための)のような、1つの個々のメディアタイプの符号化バーションに相当し得る。メディア構成要素は、1つの表現内の連続的なメディアセグメントの境界にわたって、時間的に連続的であり得る。
【００３６】
典型的には、DASH規格に準拠するセグメントは一般に、(1)固定ヘッダ、(2)データユニットへのポインタのテーブル、および(3)データユニット自体を含む3つの部分を有する。一例では、セグメントは、下に示すTable 1(表1)に従って形成され得る。
【００３７】
【表１】
0005788101.tif 000002
【００３８】
セグメントを送信する役割を担うデバイス(たとえば、サーバデバイス)は一般に、デバイスがポインタのテーブルを適切に構築できるように、データユニットのすべてのサイズがわかるまでセグメントヘッダを送信することができない。したがって、サーバデバイスは一般に、データユニットおよびポインタを組み立て、ヘッダを生成し、単一のユニットとして完全に形成されたセグメントを送信する。代替として、部分GET要求に応答して、サーバは、セグメントの部分(たとえば、指定されたバイト範囲)を送信することができる。しかしながら、本開示の技法の範囲外では、サーバデバイスは、セグメントが完全に形成された後にのみ、たとえば、一般にセグメントの最後に配置されるメディアフラグメントランダムアクセス(MFRA)ボックスが構築された後、部分GET要求を受信する。すなわち、クライアントデバイスが部分GET要求を提出するためには、クライアントデバイスは、MFRAボックス、またはセグメントの特定の部分のロケーションのインジケータ、たとえば瞬時デコーダリフレッシュ(IDR:instantaneous decoder refresh)ピクチャなどの特定のタイプのネットワーク抽象化層(NAL)ユニットのバイトロケーションの指示を有する同様のデータ構造のデータにアクセスする必要がある。
【００３９】
さらに、メディアデータのセグメントを受信するデバイス(たとえば、クライアントデバイス)は一般に、セグメントヘッダおよびデータユニットのすべてが受信されるまでセグメントを処理することができない。したがって、クライアントデバイスは一般に、(たとえば、ヘッダ全体、ポインタのテーブル、およびデータユニットを備えた)完全に形成されたセグメントを、セグメントを復号し表示する前に受信する。あるいは、クライアントデバイスは、上記で説明したように、MFRAボックスのデータを使用して、セグメントの部分(たとえば、1つまたは複数の指定されたバイト範囲)を取り出すことができる。しかしながら、この場合も、本開示の技法の範囲外において、クライアントデバイスによってセグメントの特定のバイト範囲にアクセスすることは、セグメントが完全に形成された後にのみ実行される。
【００４０】
セグメント全体がネットワークを通じてセグメントを送信する前に形成される(また、復号する前に受信される)例では、セグメントの送信とセグメントの復号/再生との間にセグメント1個分のレイテンシがもたらされる。すなわち、サーバデバイスは、セグメント全体を完全に形成し、セグメントをクライアントデバイスに送信する。クライアントデバイスは、完全に形成されたセグメントを受信し、ヘッダデータおよびポインタを使用して、完全なセグメントを復号し表示する。したがって、サーバデバイスが完全なセグメントを形成し、クライアントデバイスが再生前に完全なセグメントを受信するので、完全なセグメント1個分のレイテンシがもたらされる。
【００４１】
一例では、説明のために、セグメントが再生時間においてビデオデータの1秒を含み得る。すなわち、サーバデバイスは、セグメントにビデオデータの丸々1秒(すなわち、復号され、再生されるときに、1秒の再生持続時間をもたらし得るデータ量)をパッケージ化(たとえば、符号化およびカプセル化)し、1秒の長さのセグメントをクライアントデバイスに送信することができる。次いでクライアントデバイスは、1秒の長さのセグメントのヘッダおよびデータユニットのすべてを受信し、セグメントを表示する前にセグメント全体を復号する。したがって、クライアントデバイスが、完全なセグメントが受信されるまで復号/再生を開始しないので、1秒のレイテンシがもたらされ得る。
【００４２】
本開示の態様は一般に、メディアデータの1つまたは複数のセグメントをストリーミングすることに関連するレイテンシを低減することを対象とする。一例では、本開示の技法は、メディアデータのセグメントの送信スケジュールを最適化することを含む。すなわち、本開示の態様によれば、ネットワークを通じてセグメントを送信する役割を担うデバイス(たとえば、以下で図1に関してより詳細に説明するサーバデバイス)が、メディアデータを、ネットワークを通じて送信するのに適した複数のセグメントに分割することができ、この場合にセグメントは必ずしも独立して復号可能であるとは限らない。
【００４３】
たとえば、セグメントは、瞬時デコーダリフレッシュ(IDR)ピクチャ、クリーンランダムアクセス(CRA)ピクチャ、またはランダムアクセスに関連する他のそのようなピクチャなどのストリームアクセスポイント(SAP)を含む必要がない。代わりに、セグメントのうちの1つは、SAPを含むことができ、他のセグメントは、SAPに関連して、たとえば直接SAPに関連して、またはSAPに関連してコード化された他のビデオデータに関連してコード化されるビデオデータを含むことができる。それによって、コンテンツ準備デバイスは、セグメントの各々にSAPを含めることなく、素早くセグメントを作って送ることができる。このようにして、SAPを含まないセグメントを送ることによって、これらの技法に従ってコード化される表現のビットレートは依然として、各セグメントがSAPを含む表現のビットレートと実質的に同じものであり得るが、本開示の技法によれば、セグメントは格段に短い再生持続時間を表し得るので、レイテンシが低減され得る。
【００４４】
代替的に、セグメントはストリームアクセスポイントを含むが、その場所はセグメントの開始点ではない場合がある。概して、関連プロファイルは、ランダムアクセスを許容するために、IDRピクチャが必要とされる時間を指定し得る。関連規格によって指定された時間に発生するIDRピクチャは、「強制IDR」ピクチャと考えられ得る。具体的には、従来では、そのような強制IDRピクチャは、セグメントのすべてのピクチャが適切に復号され得るように、(復号順序による)セグメントの開始点において発生する。しかしながら、本開示は、ときにはビデオコーディングデバイスが、たとえばシーン変化に順応するために、セグメントに非強制IDRピクチャを挿入する場合があることを認識している。すなわち、ビデオエンコーダは、シーン変化に対応するピクチャをイントラコーディングすることが、そのピクチャをインターコーディングすることよりも有益であると判定する場合がある。本開示は、そのようなシーン変化IDRピクチャを、強制IDRピクチャの代替または追加として使用することを提案する。
【００４５】
すなわち、セグメントが、セグメントの開始点でIDRピクチャが必要とされること(すなわち、「強制IDR」)を関連規格が本来指示する時間に対応するとき、本開示の技法によるデバイスは、セグメントがセグメントの他の場所にIDRピクチャ(たとえば、シーン変化IDR)を含むかどうかを判定することができる。含む場合、デバイスは、セグメントにシーン変化IDRのみを含めて、強制IDRを省略することができる。このようにして、セグメントのビット割振りは、より効率的になることができ、セグメントは依然として、関連規格に事実上適合することができ、その理由は、クライアントデバイスがセグメントのシーン変化IDRからデータを復号し始めることができることにある。さらに、(クライアントデバイスがシーン変化IDRから開始していると仮定すると)本来的に復号可能ではない場合があるシーン変化IDRピクチャに先行するセグメントのデータの取出しを回避するために、クライアントデバイスがシーン変化IDRからストリームを開始できるように、シーン変化IDRに到達するためのバイト範囲またはバイトオフセットを示すデータが提供され得る。
【００４６】
本開示の他の態様によれば、サブセグメントは、サブセグメントヘッダおよび1つまたは複数のデータユニットを含み得る。サブセグメントヘッダは、サブセグメントのデータユニットを指すポインタのテーブルを含み得る。しかしながら、上記のように、サブセグメントのデータユニットは、先行するサブセグメントまたは将来のサブセグメントを参照することがある。たとえば、サブセグメントのデータユニットは、先行するサブセグメントまたは将来のサブセグメントのフレーム(あるいはスライス)を参照するPまたはBフレーム(あるいはPまたはBスライス)を含み得る。
【００４７】
いくつかの例では、そのようなサブセグメントは、独立して復号可能ではないことがある。すなわち、あるサブセグメントは必ずしも、当該先行サブセグメントに続くサブセグメントに対応し得る別のサブセグメントに含まれる参照情報なしに復号可能であるとは限らない。言い換えれば、サブセグメントは将来のサブセグメントを参照することがある。しかしながら、サブセグメントは、独立して復号可能な一定の情報を含んでいることがある。たとえば、サブセグメントは、独立して復号可能なビデオデータの1つまたは複数のIフレームを含んでいることがある。
【００４８】
本開示の態様によれば、サブセグメントは、サブセグメントヘッダおよび1つまたは複数のデータユニットを含み得る。サブセグメントヘッダは、サブセグメントのデータユニットを指すポインタのテーブルを含み得る。しかしながら、上記のように、サブセグメントのデータユニットは、先行するサブセグメントまたは将来のサブセグメントを参照することがある。たとえば、サブセグメントのデータユニットは、先行するサブセグメントまたは将来のサブセグメントのフレーム(あるいはスライス)を参照するPまたはBフレーム(あるいはPまたはBスライス)を含み得る。
【００４９】
いくつかの例では、各サブセグメントは、サブセグメントヘッダを含み得る。たとえば、サブセグメントヘッダは、ビデオ/オーディオ符号化フォーマット、品質レベルなどのような「固定」部分を含み得る。場合によっては、セグメントのヘッダデータ、ならびにサブセグメントヘッダのデータは、セグメント間および/またはサブセグメント間で変化しないことがある。したがって、本開示のいくつかの態様では、ヘッダデータが変化しているかどうかを示すフラグの値を、サーバデバイスは設定することができ、クライアントデバイスは解釈することができる。たとえば、サーバデバイスは、セグメントまたはサブセグメントヘッダが先行セグメントまたは先行サブセグメントと実質的に同様のデータまたは同じデータを含むことを示す「0」にフラグを設定し得る。サーバデバイスは、セグメントまたはサブセグメントヘッダが変化していることを示す「1」にフラグを設定し得る。さらに、クライアントデバイスは、フラグを受信し、あるセグメントから別のセグメントにかけてヘッダデータが変化しているかどうかを解釈することができる。
【００５０】
ビデオデータの複数のサブセグメントを生成し、サブセグメントが形成/符号化されるとそれらをすぐに送信することにより、レイテンシ(たとえば、ストリーミング環境におけるメディアデータの送信、受信、復号、および/または表示に関連するレイテンシ)を低減することができる。たとえば、クライアントデバイスは、サブセグメントの少なくとも一部分を、サブセグメントを受信すると直ちに復号し始めることができる。すなわち、サブセグメントのいくつかのデータユニットは、まだ受信されていない他のサブセグメントのデータユニットを参照し得るが、クライアントデバイスは、データユニットのうちのいくつか(たとえば、サブセグメントに含まれるIフレーム)を直ちに復号し始めることができる。さらに、クライアントデバイスは、一般にサブセグメントに続いてセグメントに関するヘッダを受信すると、セグメント全体を復号し、プレイアウトする準備ができる。
【００５１】
いくつかの例では、本開示の態様に従って複数のサブセグメントを生成し、1つのサブセグメントが形成されるとそれをすぐに送信することは、単にセグメント持続時間全体を短縮するよりも効率的であり得る。すなわち、説明のために上記で提供した例では、セグメントはビデオデータの1秒を含むことができ、これは丸々1秒のレイテンシをもたらし得る。すなわち、セグメントが送信前に完全に形成され、セグメントが再生前に完全に受信され、復号される場合に、丸々1秒のレイテンシがもたらされ得る。レイテンシを低減する1つの方法として、セグメントの持続時間全体を減らすことが考えられる。すなわち、サーバデバイスは、1秒のセグメントを符号化し、送信するのではなく、500ミリ秒のセグメントを符号化し、送信することができる。したがって、この例では、エンドツーエンドレイテンシが1秒から500ミリ秒に低減され得る。
【００５２】
しかしながら、セグメント持続時間を短縮することによってレイテンシを低減すると、ビットストリームにおけるオーバーヘッドデータの割合が増大する(たとえば、それにより効率性が低下する)ことがある。たとえば、上記のように、各セグメントは、セグメント持続時間に生成されるビデオ/オーディオサンプルの数とともにサイズが拡大する部分のほか、固定部分を含むヘッダを含む。セグメント持続時間の減少に伴い、ヘッダの固定部分がもたらす、データを送信することに関連するオーバーヘッドの部分が(比例して)大きくなり始める。一定のビットレートを仮定すれば、オーバーヘッドが増大するのに伴って、実際のメディアデータに使用されるビットが少なくなり得るので、総合効率が低下する。
【００５３】
さらに、いくつかの例では、メディアデータのセグメントは、別のセグメントを参照するのを回避するように構築され得る。すなわち、マルチメディアコンテンツの各セグメントは、いくつかの例では、他のセグメントのデータを参照せず(たとえば、あるセグメントのPフレームまたはBフレームは、別のセグメントのフレームを参照しない)、したがって独立して復号可能であり得る。したがって、そのような例では、セグメント持続時間を短縮するとき、Iフレームの数が増加する一方で、PフレームおよびBフレームの数が減少する。Iフレームが比例的に増加しているビデオデータは、たとえば、Pフレームおよび/またはBフレームの割合が大きくなっているビデオデータほどには、時間的冗長性を利用しない。したがって、所与の平均レートでは、Iフレームの数と表示されるビデオデータの知覚品質との間には反比例関係があり得る。すなわち、可変ビットレートを使用してコード化されているビデオデータは、より固定的なビットレートを使用してコード化されているビデオデータの場合よりも、高い知覚品質を示し得る。
【００５４】
したがって、本開示の態様を使用して、(所与のレートを有する)所与のセグメントの持続時間を維持しつつ、レイテンシを低減することもできる。すなわち、上記の1秒のセグメント持続時間の例において、本開示の態様は、1秒のセグメント持続時間を維持しつつ、セグメントの送信および復号/表示に関連するレイテンシを1秒未満に低減することに関係する。このようにして、メディアデータの知覚品質を維持しつつ、レイテンシを低減することもできる。
【００５５】
本開示の技法は、ブロードキャストネットワーク送信を介したDASHまたは他のストリーミングネットワークプロトコルによるマルチメディアデータの送信に使用され得る。たとえば、サーバデバイスは、ブロードキャストを介した1つまたは複数のクライアントデバイスへの送信に向けて、複数のサブセグメントを有するセグメントを準備することができる。クライアントデバイスは、いくつかの例では、上記で説明したようにセグメントのサブセグメントを含むブロードキャストネットワーク送信を受信することができる。
【００５６】
本開示は、レイテンシを低減するための他の技法についても説明する。具体的には、いくつかの例では、本開示の技法は、(再生時間の点で)比較的短いセグメントを利用するが、セグメントのサブセットのみにおいてストリームアクセスポイント(SAP)を提供することを提案する。このようにして、セグメントが形成されるとすぐにセグメントを送信することができ、クライアントデバイスは、セグメントのデータの復号および表示を、SAPを含むセグメントを受信するとすぐに開始することができる。概して、SAPは、ITU-T H.264/AVC(Advanced Video Coding)における瞬時デコーダリフレッシュ(IDR)ピクチャなどのランダムアクセスポイント(RAP)に対応し得る。いくつかの例では、オープンデコーダリフレッシュ(ODR)ピクチャまたはクリーンランダムアクセス(CRA)ピクチャも、ストリームアクセスポイントおよびランダムアクセスポイントとして使用され得る。
【００５７】
クライアントデバイスはさらに、必ずしもSAPを含む必要はない後続セグメントを受信し、たとえば、参照のために先行セグメントのSAP(またはSAPに関連してコード化された他のフレーム)のデータを利用して、これらの後続セグメントのデータを復号し、表示することができる。セグメントは、必ずしもSAPを含むとは限らないが、従来型のセグメントヘッダを有する従来型のセグメントとして構造化され得る。代替的に、変更されたセグメントヘッダに関して本明細書で説明する技法(たとえば、ヘッダデータが変化したどうかを示すフラグ、ならびに固定部分および変動部分を有するヘッダの使用)と同様の技法を、SAPを含むこと、または含まないことがある表現中のセグメントに適用することもできる。その上、いくつかの例では、セグメントのデータは、後続セグメントのデータに関連してコード化され得る。
【００５８】
図1は、ネットワークを通じてメディアデータをストリーミングするための技法を実施する、例示的なシステム10を示すブロック図である。この例では、システム10は、コンテンツ準備デバイス20、サーバデバイス60、およびクライアントデバイス40を含む。クライアントデバイス40およびサーバデバイス60は、インターネットを含み得るネットワーク74によって通信可能に結合される。いくつかの例では、コンテンツ準備デバイス20およびサーバデバイス60も、ネットワーク74もしくは別のネットワークによって結合されてよく、または直接通信可能に結合されてよい。いくつかの例では、コンテンツ準備デバイス20およびサーバデバイス60は、同じデバイスを含み得る。
【００５９】
図1の例では、コンテンツ準備デバイス20は、オーディオソース22およびビデオソース24を含む。オーディオソース22は、たとえば、オーディオエンコーダ26によって符号化されるべきキャプチャされたオーディオデータを表す電気信号を生成する、マイクロフォンを含み得る。あるいは、オーディオソース22は、以前に記録されたオーディオデータを記憶する記憶媒体、コンピュータ化されたシンセサイザのようなオーディオデータ生成器、またはオーディオデータの任意の他のソースを含み得る。ビデオソース24は、ビデオエンコーダ28によって符号化されるべきビデオデータを生成するビデオカメラ、以前に記録されたビデオデータで符号化された記憶媒体、コンピュータグラフィックスソースのようなビデオデータ生成ユニット、またはビデオデータの任意の他のソースを含み得る。コンテンツ準備デバイス20は必ずしも、すべての例においてサーバデバイス60に通信可能に結合されるとは限らないが、サーバデバイス60によって読み取られる別個の媒体に、マルチメディアコンテンツを記憶することができる。
【００６０】
生のオーディオデータおよびビデオデータは、アナログデータまたはデジタルデータを含み得る。アナログデータは、オーディオエンコーダ26および/またはビデオエンコーダ28によって符号化される前にデジタル化され得る。オーディオソース22は、話している参加者から、その参加者が話している間オーディオデータを取得することができ、ビデオソース24は、話している参加者のビデオデータを同時に取得することができる。他の例では、オーディオソース22は、記憶されたオーディオデータを含むコンピュータ可読記憶媒体を含んでよく、ビデオソース24は、記憶されたビデオデータを含むコンピュータ可読記憶媒体を含み得る。このようにして、本開示で説明される技法は、生の、ストリーミングの、リアルタイムのオーディオデータおよびビデオデータに、または、保管された、以前に記録されたオーディオデータおよびビデオデータに、適用され得る。
【００６１】
ビデオフレームに対応するオーディオフレームは一般に、ビデオフレーム内に格納されたビデオソース24によってキャプチャされたビデオデータと同じときに、オーディオソース22によってキャプチャされたオーディオデータを格納する、オーディオフレームである。たとえば、話している参加者が一般に話すことによってオーディオデータを生成している間、オーディオソース22はオーディオデータをキャプチャし、ビデオソース24は同時に、すなわちオーディオソース22がオーディオデータをキャプチャしている間に、話している参加者のビデオデータをキャプチャする。したがって、オーディオフレームは、1つまたは複数の特定のビデオフレームに時間的に対応し得る。したがって、ビデオフレームに対応するオーディオフレームは一般に、オーディオデータおよびビデオデータが同時にキャプチャされた状況に対応し、その状況に対して、オーディオフレームおよびビデオフレームがそれぞれ、同時にキャプチャされたオーディオデータおよびビデオデータを含む。
【００６２】
いくつかの例では、オーディオエンコーダ26は、各符号化オーディオフレームにおいて、符号化オーディオフレームのオーディオデータが記録された時間を表すタイムスタンプを符号化することができ、同様に、ビデオエンコーダ28は、各符号化ビデオフレームにおいて、符号化ビデオフレームのビデオデータが記録された時間を表すタイムスタンプを符号化することができる。そのような例では、ビデオフレームに対応するオーディオフレームは、タイムスタンプを含むオーディオフレームおよび同じタイムスタンプを含むビデオフレームを含み得る。コンテンツ準備デバイス20は、オーディオエンコーダ26および/またはビデオエンコーダ28がタイムスタンプを生成する場合に依拠するか、またはオーディオソース22およびビデオソース24がそれぞれオーディオデータおよびビデオデータをタイムスタンプに関連付けるために使用し得る、内部クロックを含むことができる。
【００６３】
いくつかの例では、オーディオソース22は、オーディオデータが記録された時間に対応するデータをオーディオエンコーダ26に送ることができ、ビデオソース24は、ビデオデータが記録された時間に対応するデータをビデオエンコーダ28に送ることができる。いくつかの例では、オーディオエンコーダ26は、符号化オーディオデータにおいて、符号化オーディオデータの相対時間的順序を示すが、オーディオデータが記録された絶対時間を必ずしも示すとは限らないシーケンス識別子を符号化することができ、同様に、ビデオエンコーダ28も、符号化ビデオデータの相対時間的順序を示すシーケンス識別子を使用することができる。同様に、いくつかの例では、シーケンス識別子がタイムスタンプにマップされるか、あるいはタイムスタンプと相関することがある。
【００６４】
オーディオエンコーダ26は一般に、符号化オーディオデータのストリームを生成する一方、ビデオエンコーダ28は、符号化ビデオデータのストリームを生成する。データの各々の個別のストリーム(オーディオかビデオかにかかわらず)は、エレメンタリストリームと呼ばれ得る。エレメンタリストリームは、表現の、単一のデジタル的にコード化された(場合によっては圧縮された)構成要素である。たとえば、表現の符号化されたビデオまたはオーディオの部分は、エレメンタリストリームであり得る。エレメンタリストリームは、ビデオファイル内にカプセル化される前に、パケット化されたエレメンタリストリーム(PES:packetized elementary stream)に変換され得る。同じ表現内で、ストリームIDが、あるエレメンタリストリームに属するPESパケットを他のエレメンタリストリームに属するPESパケットと区別するために使用され得る。エレメンタリストリームのデータの基本単位は、パケット化されたエレメンタリストリーム(PES)パケットである。したがって、コード化ビデオデータは一般に、エレメンタリビデオストリームに対応する。同様に、オーディオデータは、1つまたは複数のそれぞれのエレメンタリストリームに対応する。
【００６５】
多くのビデオコーディング規格のように、H.264/AVCは、シンタックス、セマンティクス、エラーのないビットストリームのための復号処理を定義し、これらのいずれもが、あるプロファイルまたはレベルに準拠する。H.264/AVCはエンコーダを規定しないが、エンコーダは、生成されたビットストリームがデコーダのための規格に準拠するのを保証する役割を課される。ビデオコーディング規格の文脈では、「プロファイル」は、アルゴリズム、機能、またはツールのサブセット、およびこれらに適用される制約に相当する。H.264規格によって定義されるように、たとえば、「プロファイル」は、H.264規格によって規定される全体のビットストリームシンタックスのサブセットである。「レベル」は、たとえば、デコーダメモリおよび計算のような、デコーダのリソース消費の制限に相当し、これは、ピクチャの解像度、ビットレート、およびマクロブロック(MB)処理速度に関連する。プロファイルは、profile_idc(プロファイルインジケータ)値によってシグナリングされ得るが、レベルは、level_idc(レベルインジケータ)値によってシグナリングされ得る。
【００６６】
たとえば、所与のプロファイルのシンタックスによって課される範囲内で、復号されるピクチャの規定されるサイズのようなビットストリーム中のシンタックス要素のとる値に応じて、エンコーダおよびデコーダの性能に大きい変動を要求することが依然として可能であることを、H.264規格は認める。多くの用途において、ある特定のプロファイル内でのシンタックスのすべての仮想的な使用を扱うことが可能なデコーダを実装するのは、現実的でも経済的でもないことを、H.264規格はさらに認める。したがって、H.264規格は、ビットストリーム中のシンタックス要素の値に課される制約の規定されたセットとして、「レベル」を定義する。これらの制約は、値に対する単純な制限であり得る。あるいは、これらの制約は、値の算術的な組合せの制約の形式(たとえば、1秒当たりに復号されるピクチャの数と、ピクチャの高さと、ピクチャの幅との積)をとり得る。個々の実装形態が、サポートされる各プロファイルに対して異なるレベルをサポートできることを、H.264規格はさらに実現する。
【００６７】
プロファイルに準拠するデコーダは普通、プロファイル中で定義されるすべての機能をサポートする。たとえば、コーディング機能として、Bピクチャコーディングは、H.264/AVCのベースラインプロファイルではサポートされないが、H.264/AVCの他のプロファイルではサポートされる。あるレベルに準拠するデコーダは、レベル中で定義された制限を超えるリソースを要求しない、あらゆるビットストリームを符号化することが可能であるべきである。プロファイルおよびレベルの定義は、互換性のために有用であり得る。たとえば、ビデオ送信の間、プロファイルとレベルの定義のペアが、送信セッション全体に対して取り決められ合意され得る。より具体的には、H.264/AVCにおいて、レベルは、たとえば、処理される必要があるマクロブロックの数、復号されたピクチャバッファ(DPB:decoded picture buffer)のサイズ、コード化ピクチャバッファ(CPB:coded picture buffer)のサイズ、垂直方向の運動ベクトルの範囲、2つの連続するMBあたりの運動ベクトルの最大の数に対する制限、および、Bブロックが8×8ピクセルよりも小さいサブマクロブロック区画を有し得るかどうかを定義することができる。このようにして、デコーダは、デコーダが適切にビットストリームを復号できるかどうかを判定することができる。
【００６８】
ITU-T H.261、H.262、H.263、MPEG-1、MPEG-2、H.264/MPEG-4 part 10、および来るべきHigh Efficiency Video Coding(HEVC)規格のようなビデオ圧縮規格は、時間的冗長性を低減するために、運動が補われた時間的予測を利用する。ビデオエンコーダ28のようなエンコーダは、いくつかの以前に符号化されたピクチャ(本明細書ではフレームとも呼ばれる)からの運動が補われた予測を使用して、運動ベクトルに従って現在のコード化ピクチャを予測することができる。通常のビデオコーディングには、3つの主要なピクチャタイプがある。それらは、イントラコード化ピクチャ(「Iピクチャ」または「Iフレーム」)、予測されたピクチャ(「Pピクチャ」または「Pフレーム」)、および双方向予測されたピクチャ(「Bピクチャ」または「Bフレーム」)である。Pピクチャは、時間的順序で現在のピクチャの前にある参照ピクチャを使用することができる。Bピクチャでは、Bピクチャの各ブロックは、1つまたは2つの参照ピクチャから予測され得る。これらの参照ピクチャは、時間的順序で現在のピクチャの前または後に位置し得る。
【００６９】
パラメータセットは一般に、シーケンスパラメータセット(SPS)中にシーケンス層ヘッダ情報を含み、ピクチャパラメータセット(PPS)中に頻繁には変化しないピクチャ層ヘッダ情報を含む。パラメータセットがあれば、この頻繁には変化しない情報は、各シーケンスまたはピクチャに対して繰り返される必要がなく、したがってコーディング効率が向上し得る。さらに、パラメータセットの使用が、ヘッダ情報の帯域外送信を可能にでき、エラーの復元を達成するための冗長な送信の必要がなくなる。帯域外送信では、パラメータセットのNALユニットが、他のNALユニットとは異なるチャネルで送信される。
【００７０】
図1の例では、コンテンツ準備デバイス20のカプセル化ユニット30は、ビデオエンコーダ28からのコード化ビデオデータを含むエレメンタリストリームと、オーディオエンコーダ26からのコード化オーディオデータを含むエレメンタリストリームとを受信する。いくつかの例では、ビデオエンコーダ28およびオーディオエンコーダ26は各々、符号化データからPESパケットを形成するためのパケタイザを含み得る。他の例では、ビデオエンコーダ28およびオーディオエンコーダ26は各々、符号化データからPESパケットを形成するためのそれぞれのパケタイザとインターフェースをとり得る。さらに他の例では、カプセル化ユニット30は、符号化オーディオデータおよび符号化ビデオデータからPESパケットを形成するためのパケタイザを含み得る。
【００７１】
ビデオエンコーダ28は、種々の方法でマルチメディアコンテンツのビデオデータを符号化して、ピクセル解像度、フレームレート、様々なコーディング規格に対する準拠、様々なコーディング規格のための様々なプロファイルおよび/もしくはプロファイルのレベルに対する準拠、1つもしくは複数の表示を有する表現(たとえば、2次元または3次元の再生用)、または他のそのような特性のような、様々な特性を有する様々なビットレートのマルチメディアコンテンツの様々な表現を生成することができる。本開示で使用されるような表現は、オーディオデータとビデオデータとの組合せ、たとえば、1つまたは複数のオーディオエレメンタリストリームと1つまたは複数のビデオエレメンタリストリームとを含み得る。各PESパケットは、PESパケットが属するエレメンタリストリームを特定する、stream_idを含み得る。カプセル化ユニット30は、様々な表現のビデオファイルへとエレメンタリストリームを組み立てる役割を担う。
【００７２】
カプセル化ユニット30は、オーディオエンコーダ26およびビデオエンコーダ28からの表現のエレメンタリストリームのためのPESパケットを受信し、PESパケットから対応するネットワーク抽象化層(NAL)ユニットを形成する。H.264/AVC(Advanced Video Coding)の例では、コード化ビデオセグメントはNALユニットへと編成され、NALユニットは、ビデオ電話、記憶、ブロードキャスト、またはストリーミングのような、「ネットワークフレンドリ」なビデオ表現のアドレッシング適用(addressing application)を実現する。NALユニットは、ビデオコーディング層(VCL)NALユニットおよび非VCL NALユニットに分類され得る。VCLユニットは、コア圧縮エンジンを格納してよく、ブロック、マクロブロック、および/またはスライスレベルのデータを含んでよい。他のNALユニットは、非VCL NALユニットであり得る。いくつかの例では、1つの時間インスタンスにおけるコード化ピクチャは、通常は一次コード化ピクチャとして提示され、1つまたは複数のNALユニットを含み得るアクセスユニットに格納され得る。
【００７３】
非VCL NALユニットは特に、パラメータセットのNALユニットおよびSEI NALユニットを含み得る。パラメータセットは、(シーケンスパラメータセット(SPS)中に)シーケンスレベルヘッダ情報を含み、(ピクチャパラメータセット(PPS)中に)頻繁には変化しないピクチャレベルヘッダ情報を含み得る。パラメータセット(たとえば、PPSおよびSPS)があれば、この頻繁には変化しない情報は、各シーケンスまたはピクチャに対して繰り返される必要がなく、したがってコーディング効率が向上し得る。さらに、パラメータセットの使用が、重要なヘッダ情報の帯域外送信を可能にでき、エラーの復元のための冗長な送信の必要がなくなる。帯域外送信の例では、パラメータセットのNALユニットが、SEI NALユニットなどの他のNALユニットとは異なるチャネルで送信され得る。
【００７４】
補足エンハンスメント情報(SEI)は、VCL NALユニットからコード化ピクチャサンプルを復号するために必要ではない情報を含み得るが、復号、表示、エラーの復元、および他の目的に関係するプロセスを支援し得る。SEIメッセージは、非VCL NALユニットに含まれ得る。SEIメッセージは、いくつかの標準仕様の規範的部分(normative part)であり、したがって、規格に準拠するデコーダの実装において常に必須であるわけではない。SEIメッセージは、シーケンスレベルSEIメッセージまたはピクチャレベルSEIメッセージであり得る。いくつかのシーケンスレベル情報は、SVCの例におけるスケーラビリティ情報SEIメッセージおよびMVCにおける表示スケーラビリティ情報SEIメッセージなどのSEIメッセージに含まれ得る。これらの例示的なSEIメッセージは、たとえば動作点の抽出および動作点の特性に関する情報を伝達することができる。さらに、カプセル化ユニット30は、表現の特性を記述するメディアプレゼンテーション記述子(MPD)などのマニフェストファイルを形成することができる。カプセル化ユニット30は、拡張可能マークアップ言語(XML)に従ってMPDをフォーマットすることができる。
【００７５】
カプセル化ユニット30は、マニフェストファイル(たとえば、MPD)とともに、マルチメディアコンテンツの1つまたは複数の表現のためのデータを、出力インターフェース32に提供することができる。出力インターフェース32は、ユニバーサルシリアルバス(USB)インターフェースのような記憶媒体へ書き込むためのネットワークインターフェースもしくはインターフェース、CDもしくはDVDのライターもしくはバーナー、磁気記憶媒体もしくはフラッシュ記憶媒体へのインターフェース、または、メディアデータを記憶もしくは送信するための他のインターフェースを含み得る。カプセル化ユニット30は、マルチメディアコンテンツの表現の各々のデータを出力インターフェース32に提供することができ、出力インターフェース32は、ネットワーク送信または記憶媒体を介してデータをサーバデバイス60に送信することができる。図1の例では、サーバデバイス60は、各々がそれぞれのマニフェストファイル66および1つまたは複数の表現68A〜68N(表現68)を含む様々なマルチメディアコンテンツ64を記憶する、記憶媒体62を含む。いくつかの例では、出力インターフェース32はネットワーク74にデータを直接送ることもできる。
【００７６】
いくつかの例では、本開示のいくつかの技法によれば、表現68のうちの1つまたは複数は、DASH低レイテンシライブプロファイルに準拠することができる。すなわち、表現68のうちの1つまたは複数は、セグメントの開始点においてストリームアクセスポイントを欠くセグメントを含むことができる。たとえば、1つまたは複数のセグメントは、ストリームアクセスポイントを完全に欠くこと、すなわちストリームアクセスポイントをまったく含まないことがある。追加または代替として、1つまたは複数のセグメントは、(復号順序による)セグメントの開始点以外の位置においてストリームアクセスポイントを含み得る。以下でより詳細に説明するように、これによりセグメントを形成し、コンテンツ準備デバイス20および/またはサーバデバイス60からクライアントデバイス40に対し、レイテンシを低減して送ることができる。
【００７７】
その上、DASH低レイテンシライブプロファイルに準拠する表現のセグメントは、DASHライブプロファイルに準拠する表現のセグメントよりも比較的短くなり得る。すなわち、DASH低レイテンシライブプロファイルのセグメントは、DASHライブプロファイルのセグメントによって表される再生時間の期間よりも短い再生時間の期間を表すことができる。したがって、DASH低レイテンシライブプロファイルのセグメントを、DASHライブプロファイルのセグメントよりも速く形成して送ることができ、これによりDASHライブプロファイルに関するレイテンシを低減することができる。
【００７８】
いくつかの例では、本開示のいくつかの態様によれば、カプセル化ユニット30は、本明細書で説明する技法に従ってデータのサブセグメントを形成するように構成され得る。すなわち、たとえば、カプセル化ユニット30は、メディアデータのセグメントを複数のサブセグメントに分割するように構成され得る。カプセル化ユニット30はサブセグメントを、サブセグメントが形成されるとすぐに出力インターフェース32に提供することができる。次いで、出力インターフェース32はサブセグメントを、ネットワーク74を介してクライアントデバイス40に送ることができる。
【００７９】
そのような例では、カプセル化ユニット30は、独立して復号可能ではないサブセグメントを生成し得る。すなわち、カプセル化ユニット30は、サブセグメントであって、当該先行サブセグメントに続くサブセグメントに対応し得る別のサブセグメントに含まれる参照情報なしに復号できるとは限らないサブセグメントを生成し得る。言い換えれば、カプセル化ユニット30は、将来のサブセグメントを参照するサブセグメントを形成することができる。
【００８０】
カプセル化ユニット30は、セグメントのすべてのサブセグメントに適用されるセグメントヘッダ、ならびにセグメントに含まれるサブセグメントの各々に関するサブセグメントヘッダを生成することができる。以下でより詳細に説明するように、サブセグメントヘッダは、サブセグメント内におけるデータユニットのロケーションを識別するポインタのテーブルを含み得る。さらに、カプセル化ユニット30は、セグメントヘッダデータが変化しているかどうか(たとえば、セグメントヘッダデータが、以前生成されたセグメントと異なるかどうか)を示すフラグを設定することができる。
【００８１】
いくつかの例では、表現68は、適応セットへと分割され得る。上述したように、場合によっては、適応セットは「表現グループ」と呼ばれることもある。すなわち、表現68の様々なサブセットは、コーデック、プロファイルおよびレベル、解像度、表示の数、セグメントのファイルフォーマット、たとえば話者による、復号され提示されるべき表現および/またはオーディオデータとともに表示されるべきテキストの言語または他の特性を特定し得るテキストタイプ情報、カメラの角度または適応セット中の表現の風景の現実世界のカメラの視野を表し得るカメラ角度情報、特定の視聴者に対するコンテンツの適切性を表すレーティング情報のような、特性のそれぞれの共通のセットを含み得る。
【００８２】
マニフェストファイル66は、特定の適応セットに対応する表現68のサブセットを示すデータ、さらには、適応セットの共通の特性を含み得る。マニフェストファイル66はまた、適応セットの個々の表現のための、ビットレートのような個々の特性を表すデータを含み得る。このようにして、適応セットは、簡略化されたネットワーク帯域幅の適応を行うことができる。適応セット中の表現は、マニフェストファイル66の適応セット要素の子要素を使用して示され得る。
【００８３】
サーバデバイス60は、要求処理ユニット70およびネットワークインターフェース72を含む。いくつかの例では、サーバデバイス60は、複数のネットワークインターフェースを含み得る。さらに、サーバデバイス60の機能のいずれかまたはすべてが、ルータ、ブリッジ、プロキシデバイス、スイッチ、または他のデバイスのような、コンテンツ配信ネットワークの他のデバイス上で実装され得る。いくつかの例では、コンテンツ配信ネットワークの中間デバイスは、マルチメディアコンテンツ64のデータをキャッシュし、サーバデバイス60の構成要素に実質的に準拠する構成要素を含み得る。一般に、ネットワークインターフェース72は、ネットワーク74を介してデータを送信および受信するように構成される。
【００８４】
要求処理ユニット70は、記憶媒体62のデータに対するネットワーク要求を、クライアントデバイス40のようなクライアントデバイスから受信するように構成される。たとえば、要求処理ユニット70は、R. Fielding他による、RFC 2616、「Hypertext Transfer Protocol-HTTP/1.1」、Network Working Group、IETF、1999年6月で説明されるような、ハイパーテキスト転送プロトコル(HTTP)バージョン1.1を実装することができる。すなわち、要求処理ユニット70は、HTTP GET要求または部分GET要求を受信して、それらの要求に応答してマルチメディアコンテンツ64のデータを提供するように構成され得る。要求は、たとえば、セグメントのURLを使用して、表現68のうちの1つのセグメントを特定することができる。いくつかの例では、要求はまた、セグメントの1つまたは複数のバイト範囲を特定することができ、したがって、部分GET要求を含む。要求処理ユニット70はさらに、表現68のうちの1つのセグメントのヘッダデータを提供するために、HTTP HEAD要求に対応するように構成され得る。いずれの場合でも、要求処理ユニット70は、クライアントデバイス40のような要求デバイスに、要求されたデータを提供するために、要求を処理するように構成され得る。
【００８５】
追加または代替として、要求処理ユニット70は、ブロードキャストまたはマルチキャストプロトコル、たとえばeMBMSを介してメディアデータを配信するように構成され得る。コンテンツ準備デバイス20は、DASHセグメントおよび/またはサブセグメントを、説明したのと実質的に同じ方法で作成することができるが、サーバデバイス60は、これらのセグメントまたはサブセグメントを、eMBMSまたは別のブロードキャストもしくはマルチキャストネットワークトランスポートプロトコルを使用して配信することができる。たとえば、要求処理ユニット70は、クライアントデバイス40からマルチキャストグループ参加要求を受信するように構成され得る。すなわち、サーバデバイス60は、マルチキャストグループに関連するインターネットプロトコル(IP)アドレスを、クライアントデバイス40を含む、特定のマルチメディアコンテンツ(たとえば、生の事象のブロードキャスト)に関連するクライアントデバイスに通知することができる。次にクライアントデバイス40は、マルチキャストグループに参加することを求める要求を提出することができる。この要求は、ネットワーク74、たとえばネットワーク74を構成するルータを通じて伝搬され、それによりルータに、マルチキャストグループに関連するIPアドレス宛のトラフィックを、クライアントデバイス40などの加入側クライアントデバイスに向けさせることができる。
【００８６】
図1の例で示されるように、マルチメディアコンテンツ64は、メディアプレゼンテーション記述(MPD)に対応し得る、マニフェストファイル66を含む。マニフェストファイル66は、様々な代替的な表現68(たとえば、品質が異なるビデオサービス)の説明を格納してよく、この説明は、たとえば、コーデック情報、プロファイル値、レベル値、ビットレート、および表現68の他の説明のための特性を含み得る。クライアントデバイス40は、メディアプレゼンテーションのMPDを取り出して、表現68のセグメントにどのようにアクセスするかを決定することができる。
【００８７】
特に、取出しユニット52は、クライアントデバイス40の構成データ(図示せず)を取り出して、ビデオデコーダ48の復号能力およびビデオ出力44のレンダリング能力を判定することができる。構成データはまた、クライアントデバイス40のユーザによって選択される言語の選好、クライアントデバイス40のユーザによって設定される深さの選好に対応する1つもしくは複数のカメラ視野、および/または、クライアントデバイス40のユーザによって選択されるレーティングの選好のいずれかまたはすべてを含み得る。取出しユニット52は、たとえば、HTTP GET要求および部分GET要求を提出するように構成されたウェブブラウザまたはメディアクライアントを含み得る。取出しユニット52は、クライアントデバイス40の1つまたは複数のプロセッサまたは処理ユニット(図示せず)によって実行される、ソフトウェア命令に対応し得る。いくつかの例では、取出しユニット52に関して説明された機能のすべてまたは一部は、ハードウェア、ハードウェアの組合せ、ソフトウェア、および/またはファームウェアで実装されてよく、必須のハードウェアは、ソフトウェアまたはファームウェアのための命令を実行するために提供され得る。
【００８８】
取出しユニット52は、クライアントデバイス40の復号能力およびレンダリング能力を、マニフェストファイル66の情報によって示される表現68の特性と比較することができる。取出しユニット52は最初に、マニフェストファイル66の少なくとも一部分を取り出して、表現68の特性を判定することができる。たとえば、取出しユニット52は、本開示の技法に従って、1つまたは複数の適応セットの特性を説明する、マニフェストファイル66の一部分を要求することができる。取出しユニット52は、クライアントデバイス40のコーディング能力およびレンダリング能力によって満たされ得る特性を有する、表現68のサブセット(たとえば、適応セット)を選択することができる。取出しユニット52は次いで、適応セット中の表現に対するビットレートを判定し、ネットワーク帯域幅の現在利用可能な量を判定し、ネットワーク帯域幅によって満たされ得るビットレートを有する表現のうちの1つからセグメントを取り出すことができる。
【００８９】
一般に、表現のビットレートが高くなると、ビデオ再生の品質が高くなる一方、表現のビットレートが低くなると、利用可能なネットワーク帯域幅が縮小したときに、ビデオ再生の品質が十分なものになり得る。したがって、利用可能なネットワーク帯域幅が比較的高いときには、取出しユニット52は、ビットレートが比較的高い表現からデータを取り出すことができ、利用可能なネットワーク帯域幅が低いときには、取出しユニット52は、ビットレートが比較的低い表現からデータを取り出すことができる。このようにして、クライアントデバイス40は、ネットワーク74を通じてマルチメディアデータをストリーミングすることができる一方、ネットワーク74の変化するネットワーク帯域幅の利用可能性に適応することもできる。
【００９０】
追加または代替として、取出しユニット52は、ブロードキャストまたはマルチキャストネットワークプロトコル、たとえばeMBMSまたはIPマルチキャストに従ってデータを受信するように構成され得る。そのような例では、取出しユニット52は、特定のメディアコンテンツに関連するマルチキャストネットワークグループに参加することを求める要求を提出することができる。取出しユニット52はマルチキャストグループに参加した後、サーバデバイス60またはコンテンツ準備デバイス20にさらなる要求を出すことなしに、マルチキャストグループのデータを受信することができる。取出しユニット52は、マルチキャストグループのデータが必要ではなくなったときにマルチキャストグループを離れること、たとえば再生を止めること、または異なるマルチキャストグループにチャネルを変えることを求める要求を出すことができる。
【００９１】
ネットワークインターフェース54は、選択された表現のセグメントのデータを受信し、取出しユニット52に提供することができ、次に取出しユニット52は、セグメントをカプセル化解除ユニット50に提供することができる。カプセル化解除ユニット50は、ビデオファイルの要素を、構成要素であるPESストリームへとカプセル化解除し、PESストリームをパケット化解除して符号化データを取り出し、たとえば、ストリームのPESパケットヘッダによって示されるように、符号化データがオーディオストリームの一部かビデオストリームの一部かに応じて、符号化データをオーディオデコーダ46またはビデオデコーダ48のいずれかに送信することができる。オーディオデコーダ46は、符号化オーディオデータを復号し、復号されたオーディオデータをオーディオ出力42に送信し、一方でビデオデコーダ48は、符号化ビデオデータを復号し、ストリームの複数の表示を含み得る復号されたビデオデータを、ビデオ出力44に送信する。
【００９２】
ビデオエンコーダ28、ビデオデコーダ48、オーディオエンコーダ26、オーディオデコーダ46、カプセル化ユニット30、取出しユニット52、およびカプセル化解除ユニット50は各々、1つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、ディスクリート論理回路、ソフトウェア、ハードウェア、ファームウェア、またはこれらの任意の組合せのような、種々の適切な処理回路のいずれかとして、適宜実装され得る。ビデオエンコーダ28およびビデオデコーダ48の各々は、1つまたは複数のエンコーダまたはデコーダに含まれてよく、これらのいずれもが、結合されたビデオエンコーダ/デコーダ(コーデック)の一部として統合され得る。同様に、オーディオエンコーダ26およびオーディオデコーダ46の各々は、1つまたは複数のエンコーダまたはデコーダに含まれてよく、これらのいずれもが、結合されたコーデックの一部として統合され得る。ビデオエンコーダ28、ビデオデコーダ48、オーディオエンコーダ26、オーディオデコーダ46、カプセル化ユニット30、取出しユニット52、および/またはカプセル化解除ユニット50を含む装置は、集積回路、マイクロプロセッサ、および/または携帯電話のようなワイヤレス通信デバイスを含み得る。
【００９３】
本開示の態様は一般に、ネットワーク74を通じてサーバデバイス60からクライアントデバイス40にメディアデータの1つまたは複数のセグメントをストリーミングすることに関連するレイテンシを最小化することを対象とする。すなわち、本開示の態様によれば、サーバデバイス60は、メディアデータのセグメントを、ネットワーク74を通じた送信に適した複数のサブセグメントに分割することができる。この例では、サーバデバイス60はサブセグメントを、サブセグメントが形成されるとすぐに送信することができる。すなわち、サーバデバイス60は、サブセグメントを送信する前に、2つ以上のサブセグメントが形成されるのを待つ必要がない。さらに、サーバデバイス60は、サブセグメントを送信する前に、サブセグメントのすべてに関するヘッダデータが生成されるのを待つ必要がない。
【００９４】
サブセグメントの形成および/または送信など、サーバデバイス60に起因するいくつかの機能が、1つまたは複数の他の構成要素またはデバイスによって実行され得ることを理解されたい。すなわち、別の例では、コンテンツ準備デバイス20は、ネットワーク74を通じてサブセグメントを形成し、送る役割を担い得る。追加または代替として、いくつかの例によれば、コンテンツ準備デバイス20およびサーバデバイス60は、同じデバイスに高度に統合されるか、または組み込まれ得る。したがって、コンテンツ準備デバイス20、サーバデバイス60、またはそのようなデバイスの組合せはサブセグメントを準備し、サブセグメントが形成されるとそれらをすぐにクライアントデバイス40などのクライアントデバイスに送ることができる。さらに、そのようなデバイスは、ブロードキャストまたはマルチキャストネットワーク送信でサブセグメントを送ることができる。
【００９５】
クライアントデバイス40は、本開示の態様に従って形成されたサブセグメントを受信し、サブセグメントの少なくとも一部分を直ちに復号し始めるように構成され得る。すなわち、サブセグメントのいくつかのデータユニットは、まだ受信されていない他のサブセグメントのデータユニットを参照し得るが、クライアントデバイス40は、データユニットのうちのいくつか(たとえば、サブセグメントに含まれるIフレーム)を直ちに復号し始めることができる。さらに、クライアントデバイス40は、一般にサブセグメントに続いてセグメントに関するヘッダを受信すると、セグメント全体を復号し、プレイアウトする準備ができる。すなわち、クライアントデバイス40は一般に、セグメントに関するヘッダを受信する前に、セグメントのサブセグメントのすべてを受信する。
【００９６】
ビデオデータの複数のサブセグメントを生成し、サブセグメントが符号化されるとそれらをすぐに送信することで、サーバデバイス60によるセグメントの送信、ならびにクライアントデバイス40によるセグメントの受信、復号、および/または表示に関連するレイテンシを低減することができる。
【００９７】
同様に、他の例では、比較的短いセグメントを生成することで、セグメントの送信に関連するレイテンシを低減することもできる。これらのセグメントに対応するプレゼンテーション時間は、適応セット中の表現にわたって固定されてよいが、本明細書で説明するように、各セグメントは必ずしもSAPを含む必要はない。本開示のいくつかの技法によれば、コンテンツ準備デバイス20は、ライブメディアコンテンツを取得すること、すなわち、リアルタイムで発生している事象のオーディオコンテンツおよび/またはビデオコンテンツを記録すること、この記録されたコンテンツを符号化すること、記録されたコンテンツをネットワーク転送に向けて準備すること、ならびに記録されたコンテンツをサーバデバイス60に送ることができる。代替的に、コンテンツ準備デバイス20は、コンテンツをクライアントデバイス40に直接配信することができる。いずれの場合も、コンテンツ準備デバイス20は、少なくとも、SAPを含まないセグメントを形成することができる。
【００９８】
上記で説明したように、コンテンツ準備デバイス20は、従来型のセグメントよりも短い持続時間を有するセグメントを形成することによって、ブロードキャストまたはマルチキャストネットワーク送信に関連するレイテンシを低減するように構成され得る。たとえば、従来型のセグメントは、10秒の再生時間を表すビデオデータを含み得るが、コンテンツ準備デバイス20は、たった1秒の再生時間を表すセグメントを形成することができる。すなわち、これらのセグメント内に含まれるビデオデータは、復号され、対応するフレームレートで提示されるとき、1秒の再生に対応し得る。たとえば、対応するフレームレートが30フレーム毎秒である場合、コンテンツ準備デバイス20によって形成されるセグメントは、30フレームのビデオデータのためのデータ、ならびに対応する量のオーディオデータを含み得る。別の例として、対応するフレームレートが60フレーム毎秒である場合、コンテンツ準備デバイス20は、60フレームのビデオデータを表すコード化ビデオデータ、ならびに対応するオーディオデータを含むセグメントを形成することができる。これは、たとえば、10秒の再生を表すセグメントとは対照的であり、この場合、上述の例ではそれぞれ300フレームおよび600フレームのビデオデータを表すコード化データを含むことになる。
【００９９】
各セグメントによって表される再生持続時間を減らすことによって、コンテンツ準備デバイス20は完全に形成されたセグメントを、たとえばサーバデバイス60またはクライアントデバイス40に対し、特に生の事象を記録するときに、セグメントがより長い再生持続時間を表した場合よりも速く送ることができる。さらに、各セグメントはSAPを含む必要がないので、より短いセグメント(すなわち、比較的短い再生持続時間を表すセグメント)を含むビットストリームが、より長いセグメントを含むビットストリームと実質的に同様のビットレートを有し得る。このようにして、これらの技法は、レイテンシ、すなわち、コンテンツ準備デバイス20によって記録された事象の発生から、事象に対応する再生をクライアントデバイス40の視聴者が見ることができるようになる時間までの経過時間量を低減することに関係する利点を提供することができる。
【０１００】
このようにして、コンテンツ準備デバイス20およびサーバデバイス60は、マルチメディアデータを送るためのデバイスの一例を表し、このデバイスは、メディアデータの第1のセグメントを取得するステップであって、第1のセグメントのメディアデータは、第1のストリームアクセスポイントを含む、ステップと、第1のセグメントをクライアントデバイスに送るステップと、メディアデータの第2の後続セグメントを取得するステップであって、第2のセグメントのメディアデータは、第2のセグメントの開始点においてストリームアクセスポイントを欠き、第2のセグメントのメディアデータの少なくとも一部分は、第1のセグメントのメディアデータの一部分に関連してコード化される、ステップと、第1のストリームアクセスポイントの後、第2のストリームアクセスポイントが利用可能になる前に、第2のセグメントをクライアントデバイスに送るステップとを行うように構成される1つまたは複数のプロセッサを含む。
【０１０１】
同様に、クライアントデバイス40は、メディアデータを受信するためのデバイスの一例を表し、このデバイスは、メディアデータの第1のセグメントを受信するステップであって、第1のセグメントのメディアデータは、第1のストリームアクセスポイントを含む、ステップと、メディアデータの第2のセグメントを受信するステップであって、第2のセグメントのメディアデータは、第2のセグメントの開始点においてストリームアクセスポイントを欠く、ステップと、第1のストリームアクセスポイントの後、第2のストリームアクセスポイントが利用可能になる前に、第1のセグメントのメディアデータの少なくとも一部分に関連して、第2のセグメントのメディアデータの少なくとも一部分を復号するステップとを行うように構成される1つまたは複数のプロセッサを含む。
【０１０２】
第1のセグメントは、これらの例では、ストリームアクセスポイント、たとえば瞬間デコーダリフレッシュ(IDR)ピクチャ、クリーンランダムアクセス(CRA)ピクチャ、または他の同様のもの(たとえば、任意のイントラコード化ピクチャ(Iピクチャ))を含む完全に形成されたDASHセグメント(または他のメディアファイル)を含むことができる。第2のセグメントも、完全に形成されたDASHセグメントを含むことができるが、そのようなストリームアクセスポイントを含まなくてよい。このようにして、第2のセグメントの部分は、第1のセグメントの部分に関連してコード化(たとえば、符号化または復号)され得る。たとえば、第2のセグメントにおける1つまたは複数のピクチャは、第1のセグメントのピクチャ、たとえば、ストリームアクセスポイントまたはストリームアクセスポイントに関連してコード化されたピクチャに関連してインター予測モードコード化され得る。このようにして、第2のセグメントの1つまたは複数のピクチャは、第1のセグメントの1つまたは複数のピクチャを参照ピクチャとして使用することができる。
【０１０３】
このようにして、第2のセグメントはストリームアクセスポイントを含む必要がない。これは、第2のセグメントを(第1のセグメントの参照のために)独立して復号可能ではないものにするが、これにより、第1のセグメントを素早くコード化、カプセル化して送り、それによりレイテンシ(すなわち、事象が発生したときから、クライアントデバイス40のユーザが事象を見ることができるようになるまでの遅延)を低減することもできる。たとえば、コンテンツ準備デバイス20および/またはサーバデバイス60は、第2のセグメントに関する十分なデータを取得する前に、たとえば第2のセグメントのキャプチャ、符号化およびカプセル化の前に、第1のセグメントを送ることができる。
【０１０４】
上記で使用した「第1の」および「第2の」という用語は、名目的に言及するものであり、順序的に言及するものではないことを理解されたい。すなわち、「第1のセグメント」は、実際には、マルチメディアデータの順序的な第1のセグメントである必要はなく、代わりに、マルチメディアセグメントのストリームアクセスポイントを含む任意のセグメントであってよい。同様に、第2のセグメントは、第1のセグメントの直後にくる必要はなく、代わりに、第1のセグメントの部分に関連してコード化される部分を含む復号順序による第1のセグメントの後にくる任意のセグメントに対応してよい。第1のセグメントおよび第2のセグメントは、同じ再生持続時間、たとえば、約1秒の再生時間(プレゼンテーション時間とも呼ばれる)を表すことがあるが、表す必要はない。
【０１０５】
図2は、取出しユニット52に関連する例示的な構成要素を示すブロック図である。図2の取出しユニット52は、取出しユニット52(図1)に対応するか、または別の異なる取出しデバイスに含まれ得る。この例では、取出しユニット52は、ストリーム管理ユニット80およびソース構成要素90を含む。ソース構成要素90は、メディアファイル記憶処理ユニット92、MPDパーシングユニット94、メディアファイル逆多重化(demux)ユニット96および適応ユニット98およびHTTPコントローラ100を含む。
【０１０６】
一般に、取出しユニット52は、特定の通信プロトコルを使用して通信するか、または特定の物理媒体と対話するためのハードウェアおよび/またはソフトウェアを含むことができる。たとえば、取出しユニット52は、HTTPを実装し、HTTPスタックを使用してデータを受信することができ、このHTTPスタックは、TCP/IPならびにネットワークの他の層に関する他の通信プロトコルを含み得る。取出しユニット52は、たとえばサーバデバイス60に対しセグメント(またはセグメントの部分)を求めるHTTP GET要求または部分GET要求をさらに生成することができる。取出しユニット52はまた、ブロードキャストまたはマルチキャストネットワーク送信からデータを受信するために、ブロードキャストまたはマルチキャストプロトコル、たとえばeMBMSまたはIPマルチキャストを実装することができる。取出しユニット52は、送信のデータを取り出すために、ブロードキャストまたはマルチキャストネットワーク送信に加入するように構成され得る。
【０１０７】
ソース構成要素90は、1つまたは複数のソースからマルチメディアコンテンツのデータを受信することができる。最初に、ソース構成要素90は、MPDファイルなどのマニフェストファイルを受信することができる。MPDパーシングユニット94は、MPDファイルをパースして、マルチメディアコンテンツの利用可能な表現、ならびに共通の特性を備える表現のグループを含む適応セットおよび表現の特性を判定することができる。時々、ソース構成要素90は、現在のマルチメディアコンテンツに関する更新されたMPDを受信することがあり、この場合、MPDパーシングユニット94は、更新されたMPDをパースし、更新された情報をストリーム管理ユニット80に提供することができる。いくつかの例では、ソース構成要素90は、表現のうちの少なくとも1つを選択することができる一方、他の例では、ソース構成要素90は表現情報をストリーム管理ユニット80に提供することができる。そのような例では、ストリーム管理ユニット80は、表現のうちの少なくとも1つを選択することができる。いずれの場合も、ソース構成要素90はストリーム管理ユニット80に、マルチメディアコンテンツに関するデータを取り出すためのダウンロード情報を送るよう求める要求を送ることができる。
【０１０８】
ストリーム管理ユニット80は、選択された表現のデータの取出し元になるソースを選択するように構成され得る。ストリーム管理ユニット80は、いくつかの例では、ストリーム管理ユニット80がデータの取出し元になる特定のソースを選択することを示すいくつかの通知を受信することができる。たとえば、HTTP受信機およびスタックは、HTTP送信のためにストリーム管理ユニット80に利用可能なネットワーク帯域幅の推定量を提供し得る。ブロードキャスト受信機およびスタックは、選択された表現に対応するブロードキャスト送信のためのURLが利用可能であるかどうか、またブロードキャストがカバレージ内にあるかどうかの指示を提供することができる。ローカル記憶デバイスは、選択された表現に対応するローカルに記憶されたデータにURLが利用可能であるかどうかの指示を提供することができる。さらに、ストリーム管理ユニット80は、たとえば、ネットワークデータを受信するために、無線信号の強度を判定するために、クライアントデバイス40などのワイヤレスデバイスの1つまたは複数の無線から無線信号強度情報(RSSI)を受信することができる。
【０１０９】
ストリーム管理ユニット80は、受信されたソース通知を分析して、マルチメディアコンテンツに関するデータの取出し元になるソースのうちの1つまたは複数を選択することができる。いくつかの例では、ストリーム管理ユニット80は、マルチメディアコンテンツの表現も選択する。ストリーム管理ユニット80はソース構成要素90から、MPDファイルから抽出された表現特性および表現のセグメントに関するURLなどの情報を受信することができる。情報は、バッファ占有および/または利用可能なスペースの指示、ならびにマルチメディアコンテンツの現在の再生時間をさらに含むことができる。受信されたソース通知とともにこの情報を使用して、ストリーム管理ユニット80は、マルチメディアコンテンツに関するデータ、たとえば、現在選択された表現のデータの取出し元になるソースを選択することができる。ストリーム管理ユニット80は、同じマルチメディアコンテンツについて時間とともに、表現および/または表現に関するデータの取出し元になるソースを適応的に切り替えることができる。
【０１１０】
ストリーム管理ユニット80は、選択されたソース(および場合によっては、選択された表現)の指示をソース構成要素90に提供することができる。さらに、ストリーム管理ユニット80は、選択された表現のデータを選択されたソースから取り出すための情報を含むダウンロードコマンドを作成することができる。たとえば、ダウンロードコマンドは、ソースタイプの指示およびソース固有の情報を含み得る。たとえば、HTTP/1.1の場合、ダウンロードコマンドは、GETコマンドまたは部分GETコマンドに含まれる選択された表現のセグメントのURLの全経路を指定することができる。別の例として、ブロードキャストまたはマルチキャストネットワーク送信の場合、ダウンロードコマンドは、選択された表現のセグメントを受信するためにブロードキャストまたはマルチキャストグループのネットワークアドレスを指定することができる。このようにして、ストリーム管理ユニット80は、データの取出し元になる適切なソース、ならびに受信する表現の適切なセグメントを、ソース構成要素90から受信された情報および/または他の受信された情報に基づいて判定することができる。
【０１１１】
ソース構成要素90は、ストリーム管理ユニット80から受信されたダウンロードコマンド情報に基づいて、選択された表現のデータを選択されたソースから取り出すための適切なコマンドを作成することができる。たとえば、ソース構成要素90は、HTTP GET要求もしくは部分GET要求、ブロードキャストもしくはマルチキャストグループに参加することを求める要求、またはローカル記憶媒体のデータを取り出すことを求める要求を生成することができる。
【０１１２】
図2の例では、ソース構成要素90はメディアファイル逆多重化(demux)ユニット96を含み、これは受信されたデータを、たとえばそれぞれのオーディオストリームおよびビデオストリームに逆多重化することができる。メディアファイル記憶処理ユニット92は、受信されたデータを、取出しユニット52を含むデバイスのメモリ(図示せず)にバッファリングすることができる。メディアファイル記憶処理ユニット92は、逆多重化されたデータを、たとえば、オーディオデコーダ46およびビデオデコーダ48(図1)に提供することもできる。あるいは、メディアファイル記憶処理ユニット92は、取り出されたメディアデータを、データを逆多重化せずにクライアントデバイス40に提供することができる。
【０１１３】
したがって、取出しユニット52は、様々な通信プロトコルに従って動作するように構成され得る。たとえば、取出しユニット52は、伝送制御プロトコル/インターネットプロトコル(TCP/IP)に従って動作するように構成されたネットワークインターフェースを含み得る。同じネットワークインターフェース(たとえば、ネットワークインターフェースの異なる要素)、または異なるインターフェースは、IPマルチキャストもしくはeMBMS、または他のブロードキャストもしくはマルチキャストネットワークプロトコルに従ってデータを受信するように構成され得る。取出しユニット52の別のインターフェースは、物理媒体からデータを受信するように構成され得る。そのようなインターフェースは、ユニバーサルシリアルバス(USB)インターフェース、DVDリーダー、ブルーレイプレーヤ、または物理媒体からデータを取り出すための他のそのようなインターフェースを含み得る。
【０１１４】
取出しユニット52がHTTPに従ってデータを受信している例では、適応ユニット98がHTTPコントローラ100と通信して、帯域幅適応を実行することができる。たとえば、適応ユニット98は、HTTPコントローラ100と通信し、マルチメディアコンテンツに関するマニフェストファイルから、マルチメディアコンテンツのマルチメディアデータの取出し元になる表現を選択することができる。マニフェストファイルは、マルチメディアコンテンツの複数の表現を示す情報を含むことができ、複数の表現は、選択された表現を含むことができる。特に、マニフェストファイルは、表現のビットレートを記述している情報を含むことができ、それにより適応ユニット98は、ネットワーク帯域幅の現在利用可能な量を踏まえ、表現のビットレートに基づいて適切な表現を選択することができる。当然のこととして、上記で説明したように、ソース構成要素ではなくストリーム管理ユニットが表現を選択するように構成されてもよいことを理解されたい。さらに、いくつかの例では、ソース構成要素90およびストリーム管理ユニット80は機能的に統合され得る。
【０１１５】
本開示の技法によれば、ソース構成要素90は、ブロードキャストネットワークデータまたはマルチキャストネットワークデータを受信するように構成され得る。たとえば、ソース構成要素90は、ブロードキャストまたはマルチキャストに従って受信されたデータを、メディアファイル記憶処理ユニット92を介してメモリ(図示せず)にバッファリングすることができる。適応ユニット98は、後続セグメントの取出し元になるソースを、たとえば測定された帯域幅に基づいて決定し、バッファリングされたデータに対応するソースの帯域幅が事実上無限であると判定し、それにより、バッファからデータを取り出すことを決定することができる。ブロードキャストまたはマルチキャストを介して受信されたデータは、ストリームアクセスポイントを含むコード化ビデオデータを表す第1のセグメントおよび第2のセグメントの開始点においてストリームアクセスポイントを欠くコード化ビデオデータを表す第2のセグメントを含み得る。メディアファイルdemuxユニット96は、第1のセグメントおよび第2のセグメントを、対応するメディアストリーム、たとえば、オーディオおよびビデオのパケット化されたエレメンタリストリームに逆多重化し、これらのエレメンタリストリームのパケットを、それぞれオーディオデコーダ46およびビデオデコーダ48に提供することができる。
【０１１６】
図3は、例示的なマルチメディアコンテンツ102の要素を示す概念図である。マルチメディアコンテンツ102は、マルチメディアコンテンツ64(図1)、またはメモリ62に記憶された別のマルチメディアコンテンツに対応し得る。図3の例では、マルチメディアコンテンツ102は、メディアプレゼンテーション記述(MPD)104および複数の表現110〜120を含む。表現110は、任意選択のヘッダデータ112およびセグメント114A〜114N(セグメント114)を含み、一方で表現120は、任意選択のヘッダデータ122およびセグメント124A〜124N(セグメント124)を含む。文字Nが、便宜的に、表現110、120の各々の最後の動画フラグメントを指定するために使用される。いくつかの例では、表現110、120の間に、異なる数の動画フラグメントがあり得る。
【０１１７】
MPD104は、表現110〜120とは別個のデータ構造を含み得る。MPD104は、図1のマニフェストファイル66に対応し得る。同様に、表現110〜120は、図1の表現68に対応し得る。一般に、MPD104は、コーディングおよびレンダリングの特性、適応セット、MPD104が対応するプロファイル、テキストタイプ情報、カメラ角度情報、レーティング情報、トリックモード情報(たとえば、時間的なサブシーケンスを含む表現を示す情報)、および/または離れた期間を検索するための情報(たとえば、再生中のメディアコンテンツへの、ターゲットを定めた広告の挿入)のような、表現110〜120の特性を一般に表す、データを含み得る。
【０１１８】
ヘッダデータ112は、存在する場合、セグメント114の特性、たとえば、ランダムアクセスポイント(RAP、ストリームアクセスポイント(SAP)とも呼ばれる)の時間ロケーション、セグメント114のいずれがランダムアクセスポイントを含むか、セグメント114内のランダムアクセスポイントに対するバイトオフセット、セグメント114のユニフォームリソースロケータ(URL)、またはセグメント114の他の側面を表すことができる。ヘッダデータ122は、存在する場合、セグメント124の同様の特性を表すことができる。加えて、または代替的に、そのような特性はMPD104内に完全に含まれ得る。
【０１１９】
セグメント114、124は、1つまたは複数のコード化ビデオサンプルを含み、ビデオサンプルの各々が、ビデオデータのフレームまたはスライスを含み得る。セグメント114のコード化ビデオサンプルの各々は、同様の特性、たとえば、高さ、幅、および帯域幅要件を有し得る。そのような特性は、MPD104のデータによって表され得るが、そのようなデータは図3の例には示されていない。MPD104は、本開示で説明されるシグナリングされた情報のいずれかまたはすべてが加えられた、3GPP仕様によって表されるような特性を含み得る。
【０１２０】
セグメント114、124の各々は、固有のユニフォームリソースロケータ(URL)に関連付けられ得る。したがって、セグメント114、124の各々は、DASHのようなストリーミングネットワークプロトコルを使用して、独立して取出し可能であり得る。このようにして、クライアントデバイス40のような宛先デバイスは、HTTP GET要求を使用して、セグメント114または124を取り出すことができる。いくつかの例では、クライアントデバイス40は、HTTP部分GET要求を使用して、セグメント114または124の特定のバイト範囲を取り出すことができる。
【０１２１】
本開示のいくつかの態様によれば、セグメント114、124の各々は、図4に関して図示し説明するように、複数のサブセグメントにさらに分割され得る。マルチメディアコンテンツ102が完全に形成された後、ヘッダデータ112、122は、いくつかの例では、上記で説明したようにIDR NALユニットなどの特定のNALユニットへのポインタを含み得る。しかしながら、本開示の技法に従って、表現110、120のサブセグメントが準備され次第送信されるとき、ヘッダデータ112、122は、セグメント114、124が完全に形成されるまで利用できない場合があることを理解されたい。それでも、本開示で論じるように、セグメント114、124のサブセグメントのデータは、ヘッダデータ112、122が利用可能になる前に送信され得る。
【０１２２】
他の例では、セグメント114、124の各々は、サブセグメントに分割されることなく、従来型のセグメントヘッダを含むことができる。しかしながら、セグメント114、124のうちの1つまたは複数は必ずしも、ストリームアクセスポイント(SAP)とも呼ばれるランダムアクセスポイントを含む必要はない。(図1のクライアントデバイス40などの)クライアントデバイスは、SAPを含むセグメントにおいて表現110〜120のうちの1つのデータを受信し始めるように構成され得るが、表現の1つまたは複数の後続セグメントは必ずしもSAPを含む必要はない。たとえば、クライアントデバイスは、マルチキャストグループに参加することを求める要求を提出し、要求を提出した後、SAPを含むセグメント(たとえば、第1のセグメント)を受信することができる。クライアントデバイスはまた、第1のセグメントに続いてマルチキャストグループの別のセグメント(第2のセグメント)を受信することができるが、第2のセグメントは、SAPを含む必要はない。代わりに、第2のセグメントは、第1のセグメントに関連してコード化される少なくとも一部のデータを含み得る。
【０１２３】
たとえば、セグメント114AはSAPを含むが、セグメント114BはSAPを含まない(すなわち、欠く)と仮定する。具体的には、この例ではセグメント114Bは、SAPを完全に欠いている。クライアントデバイス40(図1)は、セグメント114Aにおいて表現110のデータを受信し始め、セグメント114AのSAPにおいてデータを復号し始めることができる。クライアントデバイス40はまた、たとえばセグメント114Aのデータを復号している間、セグメント114Bを取り出すことができる。そのような例において、表現のセグメントは、再生時間の比較的短い期間(たとえば、1秒の再生時間)を表すことができる。
【０１２４】
コンテンツ準備デバイス20は、適応セット内の表現110〜120にわたってSAPが位置調整されるように、表現110〜120を構築することができる。SAPは、必ずしも各適応セットにおいて同じ頻度で発生する必要はないが、位置調整され得る。たとえば、表現110は、1秒間隔でSAPを含むように構築されてよく、一方で表現120は、2秒間隔でSAPを含むように構築されてよく、この場合に時間間隔はプレゼンテーション時間に対応する。表現110および表現120が同じ適応セット内に含まれると仮定すると、セグメント114Aおよび124Aは、SAPで始まってよく、セグメント114BはSAPを含んでよく、セグメント124BはSAPを含む必要がない。セグメント114Bに続くセグメント(たとえば、図3に示されていないセグメント114C)もSAPを含んでよく、セグメント124Bに続くセグメント(たとえば、同じく図3に示されていないセグメント124C)はSAPを含んでよい。他の例では、同じ適応セットにおける表現のすべてのSAPは、SAPが同じ頻度で(すなわち、再生時間の点で同じ持続時間で)表現の各々において発生するように位置調整されてよく、かつ、SAPが同じ適応セットの表現の各々において同じプレゼンテーション時間に発生するようにフェーズ位置調整されてよい。
【０１２５】
同じ適応セットの表現を、SAPがこれらの表現にわたって位置調整されるように構築することは、いくつかの利点を提供することができる。たとえば、そのような表現は、シームレスかつ単純なレート適応能力を提供することができる。また、同じ適応セットの表現においてSAPを位置調整することで、ビデオ符号化品質の劣化を回避することができる。
【０１２６】
その上、コンテンツ準備デバイス20は、連続するSAP間の変動する時間を提供することができる。コンテンツ依存型のSAPの測位は、比較的高い品質のビデオをもたらすことができ、より優れた圧縮特性をもたらすことができる。コンテンツ準備デバイス20は、連続するSAP間の最大時間分離で構成され得る。その上、コンテンツ準備デバイス20は、連続するSAP間の最大時間を、たとえば、MPD104または表現ヘッダデータ、たとえばヘッダデータ112、122においてシグナリングすることができる。
【０１２７】
いくつかの例では、セグメント114、124の各々は固定持続時間を有し得る。そのような例では、セグメント114、124は必ずしもSAPで始まる必要はない。セグメント114、124の各々は、そのような例では同じ量のプレゼンテーション時間、たとえば1秒(または他の適切なプレゼンテーション時間)を表すことができる。これらの例も、いくつかの利点を提供することができる。たとえば、セグメントに関するURLが、再生時間に応じて自動的に生成され得ると仮定すると、セグメントURLを予測するための手順は比較的簡単であり得る。最終的には、必要とされるセグメントが少なくなり得る。一方、コンテンツ準備デバイス20は、適応セットの表現を切り替えるためのセグメントインデクシングを提供することができる。
【０１２８】
図4は、本開示の一態様による、例示的なセグメント200を示す概念図である。セグメント200は、図3に示すセグメント114および/または124に対応することができ、マルチメディアコンテンツ64(図1)、またはメモリ62に記憶された別のマルチメディアコンテンツの少なくとも一部分を含み得る。図4のいくつかの態様は、図1に示す構成要素に関して説明されることがあるが、セグメント200は、いくつかの異なる構成要素を有するいくつかの異なる環境で実装され得ることを理解されたい。
【０１２９】
図4の例では、セグメント200は、セグメントヘッダ202、サブセグメント204A、サブセグメント204B(まとめてサブセグメント204と呼ぶ)、ならびに(省略記号によって示される)潜在的にいくつかの追加のサブセグメントを含む。本開示の態様によれば、セグメントヘッダ202は、セグメント200のすべてのサブセグメント204に共通する情報を含むことができる。たとえば、セグメントヘッダ202は、クライアントデバイス40などのデバイスがセグメント200を復号および/またはレンダリングするのを支援する一定の情報を含むことができる。すなわち、セグメントヘッダ202は、セグメント200のオーディオデータに関する符号化フォーマット、セグメント200のビデオデータに関する符号化フォーマット、セグメント200に関するビットレート、セグメント200に関する品質レベル、セグメント200のビデオデータの解像度、セグメント200のビデオデータのフレームレートなどを示すデータを含むことができる。本開示のいくつかの態様によれば、そのようなデータの一部分は、後述のようにサブセグメントヘッダに含まれ得る。いくつかの例では、セグメントヘッダ202は、すべてのサブセグメント204が送信された後に送信される。他の例では、セグメントヘッダ202は、サブセグメント204が送信される前に送信される。
【０１３０】
いくつかの例では、本開示の態様によれば、セグメントヘッダ202は、セグメントヘッダ202のデータが変化しているかどうかを示すフラグを含み得る。すなわち、セグメントヘッダフラグは、セグメントヘッダ202のデータが以前受信され復号されたセグメントヘッダから変化しているかどうかを示すことができる。サーバデバイス60などのデバイスは、セグメントヘッダ202のデータが変化していないことを示す「0」にセグメントヘッダフラグを設定することができ、セグメントヘッダのデータが変化していることを示す「1」にセグメントヘッダフラグを設定することができる。ヘッダデータが変化していない場合(フラグ=0)、サーバデバイス60は、セグメントヘッダ202に追加情報を含めることを省略することができる。一方、ヘッダデータが変化している場合(フラグ=1)、サーバデバイス60は、セグメントヘッダフラグの後、ヘッダデータを含めることができる。
【０１３１】
図4に示す例では、サブセグメント204Aは、それぞれデータユニット210Aおよび210B(まとめてデータユニット210)の相対ロケーションを識別するデータユニットポインタ208Aおよび208B(まとめてデータユニットポインタ208)を有するサブセグメントヘッダ206を含む。いくつかの例では、サブセグメントヘッダ206は、セグメントヘッダ202に関して上述したデータの一部分を含み得る。ただし、(たとえば、符号化フォーマットなどの)頻繁には変化しないデータは通常、サブセグメントヘッダ206に含まれない。
【０１３２】
本開示のいくつかの態様によれば、サブセグメントヘッダ206は、サブセグメント204A内のデータユニット210の各々のオフセットを識別するデータユニットポインタ208のテーブルを含む。たとえば、オフセットは、サブセグメント204A内のデータユニットの相対位置を提供し得る。オフセットはまた、データユニットの復号されたデータを提示する際の適切な順序の指示を提供し得る(ただし、いくつかの例では、データユニットは、提示/表示順序では符号化されず、送信されないことがある)。
【０１３３】
データユニット210は一般に、非VCL NALユニットまたはVCL NALユニットを含み、これらは符号化メディアデータを含み得る。メディアデータがビデオデータである例では、データユニット210は、ビデオデータのフレームまたはスライスを含むことができる。本開示の態様によれば、サブセグメント204Aなどのサブセグメントは、独立して復号可能ではないことがある。たとえば、データユニット210のうちの1つまたは複数は、1つまたは複数の他のサブセグメントに含まれる1つまたは複数のデータユニット(たとえば、サブセグメント204Bのデータユニット216など)を参照し得る。すなわち、データユニット210がビデオデータを含む例では、データユニット210のうちの1つまたは複数は、1つまたは複数の他のサブセグメントに含まれる1つまたは複数のデータユニットのビデオデータを参照するPフレームまたはBフレームとして符号化され得る。したがって、いくつかの例では、データユニット210のうちの1つまたは複数は、将来のサブセグメント(たとえば、Bフレーム)を参照し得る。ただし、データユニット210は、(たとえば、他のサブセグメントを参照せずに)独立して復号可能な一定の情報を含むこともできる。たとえば、データユニット210のうちの1つまたは複数は、独立して復号可能なビデオデータのIフレームであり得る。
【０１３４】
図4に示す例では、サブセグメント204Bは、サブセグメント204Aと同様に構成される。すなわち、サブセグメント204Bは、データユニット216Aおよび216Bを識別するデータユニットポインタ214Aおよび214Bを有するサブセグメントヘッダ212を含む。いくつかの例では、本開示の態様によれば、上述のセグメントヘッダ202と同様に、サブセグメント204は、サブセグメントヘッダ206、212のデータが変化しているかどうかを示すフラグを含み得る。図4に示す例では、サブセグメントヘッダ212は、以前に受信されたサブセグメントヘッダ206のデータが変化しているかどうかを示すフラグ(たとえば、フラグ=0の場合、データは変化しておらず、フラグ=1の場合、データは変化している)を含むことができる。したがって、サブセグメントヘッダデータが変化しない例では、ヘッダデータによって消費されるビットの数が減少し得る。
【０１３５】
本明細書で説明する技法に従ってセグメント200を利用することで、(たとえば、複数のサブセグメントを含まないセグメントと比較して)レイテンシを低減することができる。すなわち、本開示の態様によれば、サーバデバイス60またはコンテンツ準備デバイス20など、ネットワークを通じてセグメントを送信する役割を担うデバイス(あるいはサーバデバイス60とコンテンツ準備デバイス20の両方の機能を実装しているデバイス)はサブセグメント204Aを、サブセグメント204Aが形成されるとすぐに(たとえば、サブセグメント204Aの最後のデータユニットが受信/符号化されるとすぐに)送信することができる。すなわち、サーバデバイス60は、サブセグメント204Aを送信する前に、複数のサブセグメントが形成されるのを待つ必要がない。さらに、サーバデバイス60は、サブセグメント204Aを送信する前に、セグメントヘッダ202が完成するのを待つ必要がない。
【０１３６】
サブセグメント204が形成/符号化されるとすぐにサブセグメント204を送信することで、クライアントデバイス40などのクライアントデバイスは、サブセグメント204を受信するとサブセグメント204の少なくとも一部分を直ちに復号し始めることができるので、レイテンシが低減され得る。すなわち、図4に示す例では、サブセグメント204Aのいくつかのデータユニット210は、サブセグメント204Bのデータユニット216のうちの1つまたは複数を参照することができる一方、クライアントデバイスはサブセグメント204Aのデータユニット210のうちのいくつか(たとえば、サブセグメント204Aに含まれるIフレーム)を直ちに復号し始めることができる。さらに、クライアントデバイス40は、一般にサブセグメント204A、204Bに続いてセグメント200に関するセグメントヘッダ202を受信すると、セグメント200全体を復号し、プレイアウトする準備ができる。すなわち、クライアントデバイス40は、サブセグメント204Aおよび204Bをすでに受信しており、セグメントヘッダ202を受信すると直ちに復号し始める準備ができる。
【０１３７】
本開示の技法によれば、一例では、セグメント200は、下に示すTable 2(表2)に従って構成され得る。
【０１３８】
【表２】
0005788101.tif 000003
【０１３９】
本開示のいくつかの態様によれば、セグメント200は、ブロードキャストネットワーク送信を介してDASHまたは他のストリーミングネットワークプロトコルに従ってマルチメディアデータを送信するように構成され得る。たとえば、サーバデバイス60は、ブロードキャストを介した1つまたは複数のクライアントデバイス40への送信に向けて、複数のサブセグメント204を有するセグメント200を準備することができる。クライアントデバイス40は、いくつかの例では、上記で説明したようにセグメント200のサブセグメント204を含むブロードキャストネットワーク送信を受信することができる。
【０１４０】
図4は、サブセグメント204Aおよび204Bが同様に構成されるものとして示しているが、いくつかの例では、表現のセグメントは同様に構成されたセグメントを含まない場合があることを理解されたい。たとえば、表現は、サブセグメントに分割されている1つまたは複数のセグメント、ならびに分割されない1つまたは複数のサブセグメントを含むことができる。
【０１４１】
図5は、本開示で説明する技法による、例示的な方法を示すフローチャートである。図5の方法は、コンテンツ準備デバイス20およびクライアントデバイス40(図1)に関して説明しているが、他のデバイスが図5の方法の技法と同様の技法を実施できることを理解されたい。たとえば、サーバデバイス60またはコンテンツ配信ネットワークの1つもしくは複数のネットワークデバイスは、サーバデバイス60に起因する機能の一部または全部を実行することができる。
【０１４２】
コンテンツ準備デバイス20(これは、クライアントデバイスにコンテンツを提供できるので、一般に「サーバデバイス」と呼ばれることがある)は最初に、マルチメディアコンテンツの表現に関するデータを取得する(260)ことができる。より具体的には、コンテンツ準備デバイス20は、マルチメディアコンテンツの所与の表現に関するメディアデータのセグメントを取得することができる。本開示のいくつかの態様によれば、コンテンツ準備デバイス20は、メディアデータのセグメントに関連するヘッダデータが変化しているかどうかを示すフラグを生成する(261)ことができる。すなわち、コンテンツ準備デバイス20は、セグメントのヘッダデータが以前に符号化されたセグメント(そのようなセグメントが存在する場合)のヘッダデータとは異なるかどうかを示すことができる。コンテンツ準備デバイス20は、ヘッダデータが変化していないことを示す「0」の値に、セグメントヘッダフラグを設定することができ、またはヘッダデータが異なる(たとえば、しかるべきヘッダデータが後に続く)ことを示す「1」の値に、セグメントヘッダフラグを設定することができる。
【０１４３】
次いでコンテンツ準備デバイス20は、第1のサブセグメントを形成する(262)ことができる。たとえば、コンテンツ準備デバイス20は、第1のサブセグメントに含まれる1つまたは複数のデータユニットを識別するデータユニットポインタを含むサブセグメントヘッダを有する、図4に示すサブセグメント204と同様のサブセグメントを形成することができる。さらに、上記のように、サブセグメントは独立して復号可能ではないことがある。すなわち、第1のサブセグメントは、1つまたは複数の他のサブセグメント(ならびに、後述する第2のサブセグメントなどの将来のサブセグメント)の1つまたは複数のデータユニットを参照する1つまたは複数のデータユニットを含むことができる。
【０１４４】
形成されると、コンテンツ準備デバイス20はクライアントデバイス40に第1のサブセグメントを送る(264)。本開示の態様によれば、コンテンツ準備デバイス20は、第1のサブセグメント(ならびに後続のサブセグメント)をブロードキャストすることができる。コンテンツ準備デバイス20が第1のサブセグメントを送信した後、クライアントデバイス40は、第1のサブセグメントを受信する(266)。いくつかの例では、クライアントデバイス40は、第1のサブセグメントを復号に向けて準備する(268)ことができる。たとえば、クライアントデバイス40は第1のサブセグメントを、セグメントヘッダデータを受信すると第1のセグメントが直ちに復号され得るように、復号に向けてバッファリングあるいは準備することができる。
【０１４５】
さらに、コンテンツ準備デバイス20は、第2のサブセグメントを形成する(272)。第2のサブセグメントは、上述の第1のサブセグメントと同様の方法で形成され得る。形成後、コンテンツ準備デバイス20は、第2のサブセグメントを(サブセグメントヘッダデータとともに)クライアントデバイス40に送る(274)ことができる。次いでクライアントデバイス40は、第2のサブセグメントを受信する(276)。いくつかの例では、クライアントデバイス40は第2のサブセグメントを、第1のサブセグメントに関して上述した方法と同様の方法による復号に向けて準備する(278)ことができる。
【０１４６】
第2のサブセグメントを形成し送信した後、コンテンツ準備デバイス20は、サブセグメントのすべて(たとえば、図5の例では、第1のサブセグメントおよび第2のサブセグメント)に適用可能なセグメントヘッダを形成する(280)ことができる。コンテンツ準備デバイス20はまた、クライアントデバイス40にセグメントヘッダを送る(282)ことができる。次いでクライアントデバイス40は、セグメントヘッダを受信し(284)、第1のサブセグメントおよび第2のサブセグメントを復号する(286)ことができる。すなわち、クライアントデバイス40は、以前に受信されたサブセグメントの各々を復号することができる。
【０１４７】
このようにして、図5の方法は、マルチメディアデータのセグメントの第1のサブセグメントを受信するステップであって、第1のサブセグメントは、1つまたは複数のデータユニットの第1のセットおよび第1のサブセグメント内のデータユニットのロケーションを示すデータを含む第1のヘッダを含み、データユニットのうちの少なくとも1つは、セグメントの第2のサブセグメントのデータユニットを参照する、ステップを含む方法の例を表す。本方法はまた、第1のサブセグメントを受信した後、第2のサブセグメントを受信するステップであって、第2のサブセグメントは、1つまたは複数のデータユニットの第2のセットおよび第2のサブセグメント内のデータユニットのロケーションを示すデータを含む第2のヘッダを含む、ステップと、第1のサブセグメントおよび第2のサブセグメントを受信した後、セグメントを処理するステップとを含む。
【０１４８】
さらに、図5の方法は、マルチメディアデータのセグメントの第1のサブセグメントを送るステップであって、第1のサブセグメントは、1つまたは複数のデータユニットの第1のセットおよび第1のサブセグメント内のデータユニットのロケーションを示すデータを含む第1のヘッダを含み、データユニットのうちの少なくとも1つは、セグメントの第2のサブセグメントのデータユニットを参照する、ステップを含む方法の例を表す。本方法はまた、第1のサブセグメントを送った後、第2のサブセグメントを送るステップであって、第2のサブセグメントは、1つまたは複数のデータユニットの第2のセットおよび第2のサブセグメント内のデータユニットのロケーションを示すデータを含む第2のヘッダを含む、ステップを含む。
【０１４９】
図5に関して図示し説明したステップは、単に一例として提供されていることも理解されたい。すなわち、図5の方法のステップは、必ずしも図5に示す順序で実行される必要はなく、より少ない、追加の、または代替的なステップが実行されてよい。一例では、図5に関して図示し説明した方法は、第1のサブセグメントおよび第2のサブセグメントを含む。ただし、他の例では、メディアデータの3つ以上のサブセグメントを、サーバデバイスは準備することができる(また、クライアントデバイスは受信することができる)。
【０１５０】
上記で説明したように、いくつかの例では、サブセグメントを使用してエンドツーエンドレイテンシを低減することができる。他の例では、すべてのセグメントを使用することができるが、1つまたは複数のセグメントはストリームアクセスポイント(SAP)を含む必要がない。SAPは一般に、クライアントデバイス40(図1)などのクライアントデバイスがビットストリームを取り出し始め、取り出されたデータを正常に復号し、レンダリングすることができる、ビットストリームにおけるポイントである。このようにして、SAPは、ISOベースメディアファイルフォーマットおよびその拡張に従ったファイルなどのファイルのランダムアクセスポイント(RAP)と同様のデータを含むことができる。SAPは、VCL層におけるIDRピクチャに関するデータを含むことができる。本開示の技法のいくつかの例によれば、表現の1つまたは複数のセグメントは、完全な従来型のセグメントヘッダを含み得るが、対応するSAPを含む必要はない。
【０１５１】
図6は、一連のコード化ビデオフレーム300〜332を示す概念図である。図6は、この例ではフレーム300〜316がセグメント334に含まれ、一方でフレーム318〜332がセグメント336に含まれることも示している。フレームは、階層予測構造内の相対位置を示すために、異なるように陰影が付けられている。たとえば、フレーム300、316、および332は、フレーム300、316、332が階層予測構造の最上部にあることを表すために黒の陰影が付けられている。フレーム300、316、332は、たとえば、イントラコード化フレーム、または単一方向における他のフレームから予測されるインターコード化フレーム(たとえば、Pフレーム)を含むことができる。イントラコード化されるとき、フレーム300、316、332は、同じフレーム内のデータからのみ予測される。インターコード化されるとき、たとえば、フレーム316は、フレーム316からフレーム300への破線矢印によって示されるように、フレーム300のデータに関連してコード化され得る。
【０１５２】
フレーム308、324は、フレーム300、316、および332に続く符号化階層における次であることを示すために、濃い陰影が付けられている。フレーム308、324は、双方向のインターモード予測符号化フレームを含むことができる。たとえば、フレーム308は、フレーム300および316のデータから予測されてよく、一方でフレーム324は、フレーム316および332のデータから予測されてよい。
【０１５３】
フレーム304、312、320、および328は、フレーム308および324に続く符号化階層における次であることを示すために、薄い陰影が付けられている。フレーム304、312、320、および328も、双方向のインターモード予測符号化フレームを含むことができる。概して、符号化階層において相対的に低いフレームを、符号化階層において相対的に高いフレームのいずれかに関連して符号化することが、フレームが依然として参照フレームバッファに記憶されている限り可能である。たとえば、フレーム304は、フレーム300および308から予測されてよく、フレーム312は、フレーム308および316から予測されてよく、フレーム320は、フレーム316および324から予測されてよく、フレーム328は、フレーム324および332から予測されてよい。さらに、フレーム304のブロックがフレーム300およびフレーム316から予測されてもよいことを理解されたい。同様に、フレーム312のブロックがフレーム300および316から予測されてよいことを理解されたい。
【０１５４】
フレーム302、306、310、314、318、322、326、および330は、これらのフレームが符号化階層において最低であることを示すために、白である。フレーム302、306、310、314、318、322、326、および330は、双方向のインターモード予測符号化フレームであり得る。フレーム302は、フレーム300および304から予測されてよく、フレーム306は、フレーム304および308から予測されてよく、フレーム310は、フレーム308および312から予測されてよく、フレーム314は、フレーム312および316から予測されてよく、フレーム318は、フレーム316および320から予測されてよく、フレーム322は、フレーム320および324から予測されてよく、フレーム326は、フレーム324および328から予測されてよく、フレーム330は、フレーム328および332から予測されてよい。
【０１５５】
フレーム300〜332は、表示順序で示されている。すなわち、復号に続いて、フレーム300はフレーム302の前に表示され、フレーム302はフレーム304の前に表示され、以下同様である。しかしながら、符号化階層により、フレーム300〜332は、異なる順序で復号され得る。フレーム308を適切に復号するために、たとえば、フレーム316が、フレーム308の参照フレームとして働くために最初に復号される必要があり得る。同様に、フレーム308は、フレーム302〜306および310〜314のうちのいずれの参照フレームとしても働くことができ、したがって、フレーム302〜306および310〜314の前に復号される必要があり得る。
【０１５６】
したがって、フレーム300〜332の符号化バージョンは、フレーム300〜332の符号化データを含むビットストリームにおいて相対復号順序で配置され得る。たとえば、フレーム300〜316は、次の順序でセグメント334内に配置され得る。300、316、328、304、312、302、306、310、314。同様に、フレーム318〜332は、次の順序でセグメント336内に配置され得る。332、324、320、328、318、322、326、330。他の順序による配置も可能である。
【０１５７】
フレームが表示される時間をプレゼンテーション時間または表示時間と呼ぶことができ、一方でフレームが復号される時間を復号時間と呼ぶことができる。プレゼンテーション/表示時間は一般に、同じシーケンスの他のフレームに関連する時間的順序の指示を提供する。ビデオエンコーダ20はフレームに対し、フレームの表示時間(またはプレゼンテーション時間)を表すピクチャ順序カウント(POC)値と呼ばれる値を割り当てることができる。したがって、ビデオデコーダ30は、フレームのPOC値を使用して、復号の後のフレームのプレゼンテーション順序を決定することができる。
【０１５８】
例として、フレーム300がイントラコード化されると仮定する。このようにすると、フレーム300は、ビットストリーム、たとえば、マルチメディアコンテンツの表現のSAPに対応し得る。本開示のいくつかの例によれば、セグメント334は、セグメント334がフレーム300〜316を含むように形成され得る。その上、いくつかの例では、フレーム318〜332を含むセグメント336が形成され得る。フレーム316は、フレーム300に関連してPフレームとしてコード化され得る。上記で説明したように、フレーム332は、たとえばフレーム316に関連してPフレームとしてインターコード化され得る。それでも、セグメント336は、セグメント336がフレーム318〜332を含むように形成され得る。フレーム332はインターコード化されるので、フレーム332がSAPではないと仮定すると、セグメント336は、SAPを欠くセグメントの一例を表す。
【０１５９】
SAPを欠くセグメント336などのセグメントを提供することは、たとえばライブストリーミング環境においていくつかの利点を提供することができる。セグメントは、ライブストリーミング環境において、セグメントが比較的短い再生時間(たとえば、1秒のプレゼンテーション時間)に対応するように、(たとえば、コンテンツ準備デバイス20によって)提供され得る。セグメントの各々は、コンテンツ準備デバイス20がセグメントを形成して、セグメントを提供可能にするとすぐに、クライアントデバイス40などのクライアントへの配信のために、サーバデバイス60などのコンテンツサーバにファイルとして提供可能になり得る。
【０１６０】
すべてのセグメントが必ずしもSAPを含む必要はない。コンテンツ準備デバイス20は、(たとえば、圧縮の点でビットストリームをより効率的にするために)コンテンツ主導の方法でビットストリームにSAPを置くように構成され得る。コンテンツ準備デバイス20はさらに、連続するSAP間の指定された最大プレゼンテーション時間差、たとえば(プレゼンテーション時間の点で)5秒で構成され得る。セグメントのシーケンスは、クライアントデバイス40などのクライアントデバイスが、任意のSAPで始まるビットストリームをプレイアウトし始めることができ、クライアントデバイスにおいて各セグメントに含まれるビデオの大部分を、セグメントがクライアントデバイスにおいて利用可能になるとすぐにプレイアウトすることができるという特性を有し得る。
【０１６１】
別の例として、(復号順序または送信順序による)ビデオフレームシーケンスは、I、P、B、B、P、B、B、P、B、B、P、B、B、Iなどであり得る。この例示的なシーケンスでは、第1のセグメントは、最初の4つのフレームを含んでよく、第2のセグメントは、次の3つのフレームを含んでよく、第3のセグメントは、次の3つのフレームを含んでよく、第4のセグメントは、次の3つのフレームを含んでよく、次いで第5のセグメントは、第2のIフレームで始まってよい。クライアントデバイスは、第1のセグメントの受信により、最初の4つのフレームを再生し始めることができ、引き続き、第2のセグメントの受信により、次の3つのフレームを再生することができ、第3のフラグメントの受信により、次の3つのフレームを再生することができ、第4のフラグメントの受信により、次の3つのフレームを再生することができる。
【０１６２】
したがって、この例でのエンドツーエンドレイテンシは、わずか4フレーム、すなわち、第1のセグメントに含まれるフレームであり、その理由は、第2のセグメントがエンコーダ側で形成され始めたばかりのときに、クライアントが第1のセグメントを潜在的にプレイアウトし始めることができることにある。さらに、クライアントデバイスが再生し始めると、ストリーミングは円滑に継続することができ、その理由は、各セグメントが、先行セグメント中のフレームが再生されているときに、遅れずに再生可能であり得ることにある。しかしながら、この例でのクライアントのための同調遅延は、4フレームを大きく超えることがあり、その理由は、ストリームに参加し、第1のIフレームのプレゼンテーション時間の後、ただし第2のIフレームの前のプレゼンテーション時間に開始したいと思うクライアントは通常、第5のセグメントを受信した後にのみ再生を開始することになることにある。
【０１６３】
図7は、IDR間隔によって異なるエラー秒を示す実証的テスト結果を示すグラフである。この例では、セグメントは固定持続時間を有しており、各セグメントはIDR(すなわち、IDRに対応するSAP)で始まっている。1990年代にMPEG2デジタルビデオが出現し、ビデオコーデックがエラーに対して特にロバストなわけではないことが急速にわかった。破損または欠落したデータのコーデックバッファ存続期間が長くなるほど、途絶が明白になる。破損したデータをコーデックバッファから外しておくことが、主観的影響において非常に優れていることが比較的急速にわかった。すなわち、フリーズは一般に、他のアーティファクトよりも(主観的観測において)良い。パケット誤り率(PER)要件が10〜7%から約1%のPERに低下してから1年くらいの間、LTEのブロック誤り率(BLER)は、MPEG2トランスポートのPERに類似している。改善は、デコーダの下の層に、破損のポイントから、H.264の次の独立データリフレッシュ(IDR)フレーム、またはMPEG2における新しいピクチャグループ(GOP)までのすべてのデータを破棄させることによって、達成された。
【０１６４】
これを達成する様々な方法があった。たとえば、MPEG2は、疑わしいパケットを識別したシグナリングビットを採用した。複数の専用モバイルマルチメディア物理層が出現し、エラーがある場合にモバイルビデオシステム性能を評価するための広く適用可能な方法が必要になった。採用された方式は、データ通信による昔から存在するメトリックであるエラー秒に基づいている。「エラー秒」は一般に、エラーを含む任意の秒全体である。この方法は、エラーにより失われたメディア秒のパーセンテージとなるように採用された。回復を宣言する前に受信される一定数の正しいパケットを必要とする方法の実装形態がある。この方法は、測定を行うために上位層シンタックスを理解する必要性を除去するが、概算である。例示的なメトリックは、5%の誤った時間(Erroneous Time)またはESR5である。
【０１６５】
上記で説明したように、DASHマルチメディアコンテンツは、複数のセグメントを含む。図7の分析では、セグメント持続時間は、(プレゼンテーション時間の点で)IDR間隔に等しく設定されている。図7のグラフは、平均BLERが1%に近いトレースの750MHzにおけるTU-6 3km/時の誤った時間に対するIDR間隔(したがってセグメント持続時間)の影響を表している。結果は、6km(3)、2km(5)、および1km(3)のセル半径における11、51秒トレースの1ミリ秒間隔でのトレースSNRを評価することによって生成された。PHYバースト間隔は250ミリ秒であり、データバースト持続時間は41ミリ秒である。これは、5MHz、95%カバレージ、6kmセル、750MHzの800kbpsにおけるMCS18に近くなる。エラーを有するいずれのセグメントも、誤った時間(たとえば、エラー秒)としてカウントされる。平均5%未満の誤った時間は、0.250ミリ秒のセグメントで合致する。
【０１６６】
図8は、前方向誤り訂正(FEC)による実証的テスト結果の別の例を示すグラフである。たとえば上記の図7の説明に関して、誤った時間の変動に対処するための様々な手法がある。一例では、リンクバジェットがセグメント持続時間に従って変更され得る。これは、0.25〜4秒のIDRレート/セグメント持続時間の範囲で必要C/Nの約0.4dBの変動をもたらし得る。
【０１６７】
別の例として、アプリケーション層FECが適用され得る。これは、4秒でリンクバジェットに比較的わずかな(差し引きゼロの(wash))結果をもたらし得る。したがって、C/N利得は、容量損失をほぼ相殺することができる。図8の例示的なグラフに示すように、誤った時間は、約7%のFECレートではほぼ一定である。トレースは、ドップラーが当てはまる(2Hz)が、運動による非相関はない。
【０１６８】
図9は、(プレゼンテーション時間における)様々なIDR間隔におけるセグメントのビットレートを示す実証的テスト結果を示すグラフである。図9に示す結果は、いくつかの典型的なコンテンツタイプ(たとえば、スポーツ、語り手の顔、動画など)にわたる平均35dBのピーク信号対雑音比(PSNR)のビデオに基づいている。この例に示すように、IDRの頻度が高いと、通常、対応するビットレートが上昇する。したがって、運動の多いシーケンスは、格段に高いビットレートを必要とし得る。
【０１６９】
図10は、様々なピーク信号対雑音比(PSNR)を平均オピニオン評点(MOS)に対して示すグラフのセットを示している。これらのグラフに示すように、コンテンツ選択およびIDR配置方法は、MOS対PSNRに著しく影響し得る。
【０１７０】
図11は、FECを伴う場合と伴わない場合の両方における様々なデータバースト間隔のエラー秒を示す実証的テスト結果を示すグラフである。図11のグラフに示すように、PHYにおけるデータバーストの頻度は、レイテンシと時間ダイバーシティの両方に影響を与え得る。ネットワークバッファ時間(バースト間の隔たり)は、エンドツーエンドレイテンシを線形的に増加させ得る。0.5秒を超えてインターバースト間隔が拡大すると、時間ダイバーシティが損なわれ得る。図11では、IDR間隔およびセグメント持続時間は、一定の5.12秒に設定されている。この例では、バースト間隔は、離散値0.32秒、0.640秒、1.28秒、2.56秒、5.12秒で評価される。この例では、5%のFECレートは、0.32秒のバースト期間で十分であり、それ以外は7%のレートが使用され得る。
【０１７１】
800kbpsの送信に必要な平均時間は、PHYでデータがバーストされるレートとは無関係である。バースト持続時間は、バーストレートに反比例する。物理層の電力消費量は、バースト持続時間に応じて変わる。各バーストに関連する約10ミリ秒のウォームアップ時間がある。50ミリ秒のバースト(MCS18、800 kbps、320ミリ秒のバースト間隔)の場合、無線が約60ミリ秒にわたってオンであることにより、PHYに起因する電力消費量が20%増加する。しかしながら、ビデオを見ているときに、無線は、全デバイス消費量の約10%消費しているだけである。バックライトは、デバイス電力消費量を左右する。潜在的に、5.12秒のデータバースト間隔に対し0.320秒で約2%のデバイス消費量の増加がある。これらの推定は、メディアフローに基づいており、修正されることがある。
【０１７２】
図12は、様々なセグメント持続時間のIDR間隔の様々な例を示す概念図である。図12に示すように、セグメント持続時間とIDR間隔(すなわち、SAP間隔)とは必ずしも等しくなければならないわけではない。図12の例は、2つの例示的な表現、たとえば、DASHの異なるプロファイルに対応する表現を示している。表現350は、本開示の技法のいくつかの例による例示的な表現に対応しており、SAP、たとえばIDRピクチャ、CRAピクチャ、または他のランダムアクセスポイントを含まないセグメントがある。すなわち、表現350は、それぞれSAP354、358を含むセグメント352A、352B(セグメント352)を含む。同様に、表現350は、SAPを含まないセグメント356A〜356D(セグメント356)を含む。一方、表現360は、DASHにおける従来型の表現の一例に対応しており、すべてのセグメントがSAPを含む。すなわち、表現360は、それぞれSAP364、366を含むセグメント362A、362B(セグメント362)を含む。
【０１７３】
一般に、表現350、360の水平軸は、プレゼンテーション時間、すなわち、時間的な再生時間に対応する。したがって、表現350および360におけるSAP間の再生時間はほぼ等しい。すなわち、表現350におけるSAP354とSAP358との間のプレゼンテーション時間差は、表現360におけるSAP364とSAP366との間のプレゼンテーション時間差にほぼ等しい。しかしながら、表現350のセグメント352、356は、表現360のセグメント362よりも、プレゼンテーション時間の比較的短い持続時間を表している。このようにして、コンテンツ準備デバイス20は、表現350のセグメント352Aを、表現360のセグメント362Aよりも速く構築して送ることができる。
【０１７４】
このようにして、表現350は、第1のストリームアクセスポイント(たとえば、SAP354)を含むメディアデータを含む第1のセグメント(たとえば、セグメント352A)およびストリームアクセスポイントを欠くメディアデータを含む第2のセグメント(たとえば、セグメント356A、356B)を含む表現の一例を表している。さらに、セグメント356Aおよび/または356Bのメディアデータは、セグメント352Aのメディアデータ、たとえばSAP354に関連してコード化され得る。たとえば、ビデオエンコーダまたはビデオデコーダは、SAP354、またはセグメント352Aの1つもしくは複数の他のピクチャを、セグメント356Aおよび/またはセグメント356Bの1つまたは複数のピクチャをコード化するときに参照ピクチャとして使用することができる。したがって、セグメント356A、356Bのメディアデータの少なくとも一部分は、セグメント352Aのメディアデータの少なくとも一部分に関連してコード化され得る。
【０１７５】
クライアントデバイス40(図1)などのクライアントデバイスによって実行されるFLUTEスタックは、完全なファイルを無視することができる。本開示の例によれば、各ファイル(セグメント)は、IDRを含むこと、または含まないことがある。セグメント持続時間とIDR間隔とが(たとえば、表現360のように表現350において)同じである場合、アプリケーションFECの時間ダイバーシティが最大化することがあるが、レイテンシが線形的に増大することもある。一方、セグメントがIDR間隔よりもはるかに短い場合、FECの時間ダイバーシティは低減され得るが、レイテンシも低減され得る。IDR間隔は、セグメント持続時間に関係なくチャネル変更時間に線形的に影響を与え得る。
【０１７６】
比較的小さい量のアプリケーションFEC(約7%)を追加すると、システムESR5パフォーマンス対セグメント持続時間が本質的に一定になり得る。リンクバジェットに対するアプリケーション層アウターコードの影響は、比較的ささいである。メディアフローの初期に、アウターコードのないストリーミングメディアの実行が積極的に検討されており、フィールドテストの後、この考えは、アウターFECを適用した場合の方が視覚的に優れたパフォーマンスとなるため、放棄された。ストリーミングメディアのアプリケーション層FECのオプションを維持することが有用であり得る。近接したIDR間隔は、急速なチャネル変更にとって有用であり得るが、それはレイテンシに直接影響しない。したがって、セグメントはIDR間隔よりも短く作られ得る。物理層データバースト間隔は、レイテンシおよび時間ダイバーシティに直接影響するので、コンテンツタイプごとのシステム動作がネットワーク内のすべてのロケーションで同じ場合、これは相応に指定され得る。MSP/CSA設定は、BVPSによって指定され得る。これらの例でのビットレートは、平均してまずまず(3.5〜4.0)のビデオ品質のコンテンツを反映している。スポーツの場合など、運動の多いビデオは、より高いビットレートを利用し得る。
【０１７７】
図13は、ストリームアクセスポイント(SAP)を含まない表現の1つまたは複数のセグメントを送るための例示的な方法を示すフローチャートである。初めに、サーバデバイス60などのサーバデバイスは、SAPを含む、マルチメディアデータの第1のセグメントを取得する(400)ことができる。この例では、サーバデバイス60は、コンテンツ準備デバイス20(図1)からマルチメディアデータの第1のセグメントを受信することができる。代替的に、サーバデバイス60は、コンテンツ準備デバイス20に起因する機能を実行するように構成されてよく、この場合にサーバデバイス60は、第1のセグメントのビデオデータを符号化することができる。いずれの場合も、この例では、第1のセグメントはSAPを含むことができる。
【０１７８】
図13の方法は、ストリーミングデータのライブブロードキャスト中に実行され得る。したがって、サーバデバイス60が第1のセグメントを取得するとすぐに、サーバデバイス60はクライアントデバイス40に第1のセグメントを送る(402)ことができる。サーバデバイス60はまた、SAPを欠く、マルチメディアデータの第2のセグメントを取得する(たとえば、受信するか、またはそのためのデータを符号化する)(408)ことができる。したがって、サーバデバイス60は、マルチメディアデータの第2の後続セグメントを取得する前に、クライアントデバイス60に第1のセグメントを送ることができる。第2のセグメントを取得した後、サーバデバイス60はクライアントデバイス40に第2のセグメントを送る(410)ことができる。
【０１７９】
クライアントデバイス40が第1のセグメントを受信した(404)後、クライアントデバイス40は第1のセグメントを復号する(406)ことができる。さらに、クライアントデバイス40は、第1のセグメントの復号されたピクチャを、ピクチャが復号された後に表示することができる。その上、クライアントデバイス40は、たとえば、第1のセグメントの少なくとも一部分を復号した後、第2のセグメントを受信する(412)ことができる。具体的には、クライアントデバイス40は、後続ストリームアクセスポイントを受信する前に、第2のセグメントを受信し、復号することができる。このようにして、クライアントデバイス40は、第1のストリームアクセスポイントの後、第2のストリームアクセスポイントが利用可能になる前に、第2のセグメントを受信する前に第1のセグメントのコード化ビデオデータの少なくとも一部分を復号することができる。第2のセグメントを受信した後、クライアントデバイス40は、後続ストリームアクセスポイントが利用可能になる前に、第1のセグメントのデータに関連して、第2のセグメントの少なくとも一部分を復号する(414)ことができる。たとえば、第2のセグメントの少なくとも1つのフレームは、第1のセグメントの1つまたは複数のフレームに関連してインター予測コード化され得る。クライアントデバイス40は、第1のセグメントの1つまたは複数のフレームに関連して、第2のセグメントのこのフレームを復号することができる。
【０１８０】
このようにして、図13の方法は、メディアデータの第1のセグメントを受信するステップであって、第1のセグメントのメディアデータは、第1のストリームアクセスポイントを含む、ステップと、メディアデータの第2のセグメントを受信するステップであって、第2のセグメントのメディアデータは、第2のセグメントの開始点においてストリームアクセスポイントを欠く、ステップと、第1のストリームアクセスポイントの後、第2のストリームアクセスポイントが利用可能になる前に、第1のセグメントのメディアデータの少なくとも一部分に関連して、第2のセグメントのメディアデータの少なくとも一部分を復号するステップとを含む方法の一例を表している。具体的には、この例では、第2のセグメントは、ストリームアクセスポイントを欠く、すなわち、ストリームアクセスポイントをまったく含まない。
【０１８１】
その上、図13の方法は、メディアデータの第1のセグメントを取得するステップであって、第1のセグメントのメディアデータは、第1のストリームアクセスポイントを含む、ステップと、第1のセグメントをクライアントデバイスに送るステップと、メディアデータの第2のセグメントを取得するステップであって、第2のセグメントのメディアデータは、第2のセグメントの開始点においてストリームアクセスポイントを欠き、第2のセグメントのメディアデータの少なくとも一部分は、第1のセグメントのメディアデータの一部分に関連してコード化される、ステップと、第1のストリームアクセスポイントの後、第2のストリームアクセスポイントが利用可能になる前に、第2のセグメントをクライアントデバイスに送るステップとを含む方法の一例も表している。
【０１８２】
図14は、DASHライブおよび低レイテンシライブプロファイルのデータ構成の例を示す概念図である。この例では、ライブプロファイルは、一例として、(黒の陰影が付けられた部分によって表される)メタデータ、(濃い陰影が付けられた部分によって表される)強制IDRピクチャ、および(薄い陰影が付けられた部分によって表される)0またはそれ以上のシーン変化IDRピクチャを含む5秒のセグメントを含む。すなわち、各セグメントは、復号され、予想フレームレートで再生されるとき、再生時間に相当する5秒に対応するのに十分なデータを含む。たとえば、通知されたフレームレートが60フレーム毎秒である場合、ライブプロファイルの各セグメントは、300フレームのデータを含み得る。図14の具体例では、ライブプロファイルは、1つのシーン変化IDRピクチャを含む第1のセグメントおよび2つのシーン変化IDRピクチャを含む第2のセグメントを含む。ライブプロファイルにおける各セグメントはまた、強制IDRピクチャで始まる。たとえば、対応するビデオコーディング規格は、再生時間に相当する5秒ごとにIDRピクチャが発生しなければならないことを規定し得る。
【０１８３】
図14はまた、DASHの低レイテンシライブプロファイルの例示的なデータセットを示している。この例では、低レイテンシライブプロファイルの各セグメントは、再生に相当する1つのセグメントを表している。たとえば、通知されたフレームレートが60フレーム毎秒である場合、各セグメントは、60フレームのデータを含み得る。本開示の技法によれば、低レイテンシライブプロファイルのセグメントのピクチャは、それぞれがIDRピクチャで始まる必要はない。代わりに、低レイテンシライブプロファイルのセグメントのピクチャは、先行セグメントのIDRピクチャに関連してコード化され得る。すなわち、セグメントの開始点においてIDRピクチャを含まないセグメントのピクチャは、IDRピクチャに関連して、IDRピクチャに基づいてコード化されたピクチャに関連して、または独立して(たとえば、Iフレームとして)コード化され得る。各セグメントのメタデータは、セグメントヘッダ情報を含むことができる。各セグメントはIDRピクチャを含む必要がないので、低レイテンシライブプロファイルのデータは、ライブプロファイルと比較してレイテンシを低減することができ、その理由は、低レイテンシライブプロファイルのセグメントが、ライブプロファイルの対応するセグメントの前に送られ得ることにある。
【０１８４】
一例では、DASHライブプロファイルを利用するように構成された(図1のクライアントデバイス40などの)クライアントデバイスは、クライアントデバイスがDASH低レイテンシライブプロファイルを利用するように構成されるときよりも多くのセグメント当たりビデオデータをバッファリングすることができる。たとえば、図14に示すように、DASHライブプロファイルはクライアントデバイスに対し、セグメント当たりビデオデータ5秒をバッファリングさせることができ、一方でDASH低レイテンシライブプロファイルはクライアントデバイスに対し、セグメント当たりビデオデータ1秒をバッファリングさせることができる。上記のように、バッファリングされる特定の時間量は、再生時間量に対応する。このようにして、DASH低レイテンシライブプロファイルは、同じストリームをより多くのセグメントに分割することができる。すなわち、図14に示すように、ライブプロファイルおよび低レイテンシライブプロファイルは、同じメディアコンテンツの異なる表現に対応し得る。さらに、本開示の技法によれば、DASHライブプロファイルは、各セグメントの開始点においてSAPまたはIDRピクチャを必要とし得る一方、DASH低レイテンシライブプロファイルは、そのような必要条件を省略することができる。すなわち、図14に示すように、DASH低レイテンシライブプロファイルに従って形成される表現は、1つまたは複数のセグメントの開始点においてIDRピクチャを欠いてよい。
【０１８５】
図15は、物理層における例示的なDASHライブおよびDASH低レイテンシライブプロファイルのセグメント当たりビットレートを示す概念図である。DASH低レイテンシライブプロファイルは、レイテンシを低減することがあるが、セグメント間のデータサイズの変動を増大させることもある。たとえば、図15に示すように、DASH低レイテンシライブプロファイルのセグメントは、各セグメントのレートがさほど平坦ではない場合があるので、DASHライブプロファイルのセグメントよりも大きいサイズを有し得る。図15において、例として、IDRフレームおよび他のフレームは、サイズが固定であると仮定され、その割合は、様々なコンテンツタイプの平均に基づいている。
【０１８６】
図16は、低レイテンシライブセグメントのピークツーピークビットレート変動を最小化するための技法を示す概念図である。一例では、複数のサービスが一緒に多重化され得る。総ビットレート変動はDASH低レイテンシライブプロファイルの場合、DASH低レイテンシライブプロファイルのセグメントロケーションに対して強制IDRピクチャのフェーズをずらすことによって最小化され得る。たとえば、図16に示すように、DASH低レイテンシライブプロファイルのセグメントごとに1つの強制IDRピクチャがずらされて挿入される。サービスが1つの集合にN個のストリームを有する場合、強制IDRピクチャのN個のフェーズが、DASHライブプロファイルのセグメント持続時間およびDASH低レイテンシライブプロファイルのセグメントの間の整数関係(integer relationship)に基づいて、ラウンドロビン式に挿入され得る。言い換えれば、図16では、DASHライブプロファイルのセグメントはDASH低レイテンシライブプロファイルのセグメントの長さの5倍であるので、5つの強制IDRピクチャがラウンドロビン式に挿入され得る。一構成では、DASHライブプロファイルのセグメントがあまりにも長くなるような多数のサービスがある場合、N個のサービスが複数のIDRピクチャのラウンドロビングループに分割され得る。さらに、強制IDRピクチャのラウンドロビンは厳密にNである必要はなく、強制IDRピクチャ間隔はNよりも大きくてよい。
【０１８７】
このようにして、ソースデバイス、たとえばコンテンツ準備デバイス20またはサーバデバイス60は、サービスの集合を形成するステップであって、サービスの各々はそれぞれの複数のセグメントを含み、サービスのうちの1つは、第1のセグメントおよび第2のセグメントを含む複数のセグメントを含む、ステップを行うように構成されてよく、サービスの集合を形成するステップは、動的適応ストリーミングオーバーHTTP(DASH)ライブプロファイルサービスを含むようにサービスのうちの1つを形成するステップであって、DASHライブプロファイルサービスの第1のセグメントの第1のSAPは、第1のプレゼンテーション時間を有し、DASHライブプロファイルの第2のセグメントの第2のSAPは、第2のプレゼンテーション時間を有し、第1のセグメントおよび第2のセグメントは、DASHライブプロファイルサービス内で連続している、ステップと、それぞれのDASH低レイテンシライブプロファイルサービスを含むようにサービスのうちの1つまたは複数を形成するステップであって、それにより、第1のプレゼンテーション時間と第2のプレゼンテーション時間との間のプレゼンテーション時間において、DASH低レイテンシライブプロファイルサービスは、第1のプレゼンテーション時間と、第1のプレゼンテーション時間とは異なり、かつDASH低レイテンシライブプロファイルサービスの他のサービスの他のSAPのプレゼンテーション時間とは異なる第2のプレゼンテーション時間との間にあるプレゼンテーション時間を有するSAPを含む、ステップとを含む。
【０１８８】
ソースデバイスはさらに、第1のプレゼンテーション時間と第2のプレゼンテーション時間との間にあるプレゼンテーション時間を有するSAPを含むDASH低レイテンシライブプロファイルサービスのセグメントが、シーン変化瞬間デコーダリフレッシュ(IDR)ピクチャを含まないとき、第1のセグメントが、DASH低レイテンシライブプロファイルサービスのセグメントの長さの倍数である長さを有するように、DASHライブプロファイルサービスを形成することができる。その上、ソースデバイスは、サービスの集合が、サービスのしきい値数を超える数のサービスを含むかどうかを判定することができ、サービスの数がサービスのしきい値数を超えるときに、集合を2つ以上の別個のサービス集合に分割することができる。
【０１８９】
DASH低レイテンシライブプロファイルサービスのセグメントは、第1の長さを有してよく、ソースデバイスは、DASH低レイテンシライブプロファイルサービスの数と第1の長さとの積に第1の長さを加えた値に等しい長さを有するように、DASHライブプロファイルサービスの第1のセグメントを構築することができる。すなわち、第1の長さがKであり、サービスの数がNである場合、DASHライブプロファイルサービスの第1のセグメントの長さは、K*N+K、または(N+1)*Kの長さを有し得る。代替的に、DASHライブプロファイルサービスの第1のセグメントの長さは、(N+J)*K(Jは正の整数)であり得る。
【０１９０】
サービスの集合が集合全体の第1のサブセットにすぎず、集合全体が比較的大きい場合、集合全体の第2のサブセットは、第1のサブセットのSAPのプレゼンテーション時間に対応するプレゼンテーション時間にSAPを含むことができる。このようにして、サービスの集合は、サービスの集合全体の第1のサブセットを含み、サービスの集合全体の第2のサブセットは、第1のサブセットのDASH低レイテンシライブプロファイルサービスのプレゼンテーション時間のうちの少なくともいくつかのプレゼンテーション時間にSAPを含むDASH低レイテンシライブプロファイルサービスを含む。すなわち、ソースデバイスは、サービスの集合が大きい場合に、セグメントごとのサービス集合当たりSAPの数を増大させ得る。
【０１９１】
図17は、シーン変化IDRフレームが強制IDRフレームと同時に発生する、DASHライブおよびDASH低レイテンシライブプロファイルに対応する例示的な表現を示す概念図である。DASH低レイテンシライブプロファイルでは、(SAPの一例を表す)強制IDRフレームは、シーン変化IDRフレームと同時に発生する(すなわち、強制IDRフレームとシーン変化IDRフレームとが同じセグメント内にある)ことがあり得る。ソースデバイス、たとえばコンテンツ準備デバイス20またはサーバデバイス60(図1)は、IDRピクチャが必要とされると関連コーディング規格が規定する(再生時間で測定される)時にセグメントが発生していると判定し得る。しかしながら、ソースデバイスはさらに、セグメントがシーン変化IDRピクチャなどのIDRピクチャを含むと判定し得る。
【０１９２】
したがって、強制IDRピクチャとシーン変化IDRピクチャの両方をセグメントに含めるのではなく、ソースデバイスは、シーン変化IDRピクチャを含めるだけであってよく、それにより、関連規格の要件に適合するとともに、セグメントのレート歪みメトリックを改善することができる。(復号順序による)セグメントのシーン変化IDRピクチャの前に発生したピクチャのデータは、先行セグメントのデータに関連してコード化され得る。ソースデバイスはさらに、シーン変化IDRピクチャに対するバイトオフセットなど、ランダムアクセスポイントとして、シーン変化IDRピクチャにアクセスするための情報を提供することができる。このようにして、クライアントデバイス40などのクライアントデバイスは、このデータを使用して、セグメントの開始点からではなく、シーン変化IDRピクチャからストリームを開始することができる。
【０１９３】
DASH低レイテンシライブプロファイルでは、シーン変化IDRは再配置できない。一例では、このセグメントにおいて、DASH低レイテンシライブプロファイルに必要な能力を変化させることなく、強制IDRフレームがドロップされ得る(すなわち、ドロップされた強制IDRフレームの機能は、シーン変化IDRピクチャによって提供され得る)。DASH低レイテンシライブプロファイルは、IDRフレームまたはSAPで始まらないセグメントをサポートすることができる。一方、DASHライブプロファイルは、強制IDRフレームを保持することができる。この動作により、DASH低レイテンシライブプロファイルは、DASHライブプロファイルとは異なるものとなり得るが、符号化は単一の機能に委ねられるので、専用場所内アプリケーション(dedicated in-venue application)の問題は生じ得ない。しかしながら、将来のセグメント中のビデオピクチャを参照するビデオピクチャが回避される必要があり得るか、またはレイテンシの増大があり得る。
【０１９４】
図18は、同時に発生しないシーン変化IDRフレームが存在する場合におけるピークツーピークビットレート変動を最小化するための技法を示す概念図である。一例として、シーン変化IDRピクチャは潜在的に、別のストリームの強制IDRフレームのラウンドロビン割当てと同時に発生し得る。一例では、強制IDRピクチャは、同じDASH低レイテンシライブプロファイルセグメント中の異なるストリーム上に2つのIDRピクチャが発生するのを防止するように、セグメント1個分だけ遅延し得る。この技法は、同じエンコーダによるDASHライブプロファイルおよびDASH低レイテンシライブプロファイルの基本的な同時生成に適合し得ない。別の例では、ラウンドロビングループにおけるサービスに2つ以上のシーン変化IDRピクチャがある場合、強制IDRピクチャ1つのみがドロップされること、または遅延することがある。前述のように強制IDRピクチャは、同じサービスにシーン変化IDRピクチャがある場合にドロップされてよく、または別のサービスの同じセグメントにシーン変化IDRピクチャがある場合に遅延してよい。
【０１９５】
このようにして、ソースデバイス、たとえばコンテンツ準備デバイス20またはサーバデバイス60は、複数の異なる表現のうちの1つのセグメントがストリームアクセスポイントを含むときに、複数の異なる表現の他の表現の時間的に同じ位置にあるセグメントがストリームアクセスポイントを欠くように、複数の異なる表現のために複数のセグメントを形成するように構成され得る。
【０１９６】
図19は、シーン変化IDRフレームを考慮するほぼ最適な強制IDRピクチャシーケンスを示す概念図である。DASH低レイテンシライブプロファイルサービスの集合におけるサービスの数を上回るケイデンス(cadence)でセグメントに強制IDRピクチャを挿入することにより、IDRピクチャを再配置する際の柔軟性を増大させることができる。一例では、セグメント当たりの所与のサービスにおけるIDRピクチャの見込み総数は、次式によって与えられ得る。
【０１９７】
【数１】
0005788101.tif 000004
【０１９８】
上式において、Cは、セグメントにおける強制IDRピクチャの挿入ケイデンス(insertion cadence)、Sは、セグメントにおけるシーン変化IDRピクチャ間の平均時間、Nは、集合におけるサービスの数である。レートを平坦にするための基本的な機構は、サービスの集合におけるセグメント当たり1つのIDRピクチャを実現することであるので、強制IDRピクチャ当たりセグメントの数を、サービスの数を上回るケイデンスまで増やすことで、セグメント当たり1つのIDRフレームという目標を達成できる確率が上昇し得る。しかしながら、目標は少なくともセグメント集合当たり1つのIDRピクチャを実現することであるので、この手法には限界があり得る。
【０１９９】
たとえば、図19に示すように、4つのサービスがあり、シーン変化IDRピクチャまでの平均時間がセグメント7個分である場合、強制IDRピクチャケイデンスの持続時間は、持続時間に8個のセグメントが最適であり得る。この例では、名目上、セグメント1つおきに、集合のすべてのサービスに1つの強制IDRピクチャがあり得る。上記で説明した技法を使用して、強制IDRピクチャは、シーン変化IDRピクチャと同時に発生するときにシフトし得る。
【０２００】
図19に示す例において、強制IDRフレームロケーションにシーン変化IDRピクチャがまったく発生しないが、これは不定で、かつ可能性が低いことがある。しかしながら、この構成は、集合のセグメント当たり1つのIDRピクチャという目標を達成する。サービスのコンテンツが密接に相関する場合、シーン変化も密接に相関することがあり、説明する方法はさほど効果的ではないことがある。さらに、サービスのグループが大きい場合、目標は、集合セグメント当たり2つ以上のIDRピクチャに調整され得る。これは、サービスのプールが増加し得るので、複数のグループを有するよりも効果的であり得る。その上、サービスの数とセグメント当たりシーン変化IDRピクチャの確率との積が1に近づくとき、強制IDRピクチャのケイデンスが非常に大きくなり得る。
【０２０１】
図20は、本開示のいくつかの技法による表現を形成するための別の例示的な方法を示すフローチャートである。この例では、サーバデバイス、たとえばコンテンツ準備デバイス20またはサーバデバイス60(図1)は、セグメントの開始点以外の位置においてSAPを含む少なくとも1つのセグメントを含む表現を形成する。具体的には、この例では、サーバデバイスは第1のセグメントのためのマルチメディアデータを受信する(450)。マルチメディアデータは、符号順序による第1のセグメントの開始点においてIDRピクチャを含み得る。代替的に、マルチメディアデータは、IDRピクチャを含まなくてよいが、サーバデバイスは、IDRピクチャとして第1のセグメントのためのピクチャをトランスコードし得る。したがって、サーバデバイスは、(符号順序による)第1のセグメントの開始点においてIDRピクチャを含むとともに、受信された残りのマルチメディアデータを含む第1のセグメントを作成する(452)ことができる。
【０２０２】
次いでサーバデバイスは引き続き、(図20に示されていない)他のセグメントをコード化することができる。他のセグメントをコード化している間、サーバデバイスは第1のセグメントのIDRピクチャからの時間的距離を追跡することができる。この追跡に基づいて、サーバデバイスは、関連コーディング規格によって示されるように、次のIDRピクチャまでの時間的距離がいつ経過しているかを判定する(454)ことができる。たとえば、サーバデバイスは、他のセグメントに含まれているピクチャの数、ならびにマルチメディアデータの再生のフレームレートを追跡し、フレームレートおよびピクチャの数に基づいて、時間的距離がいつ経過しているかを判定することができる。
【０２０３】
次いでサーバデバイスは、時間的距離をおいて第2のセグメントのためのマルチメディアデータを受信する(456)ことができる。1つまたは複数のセグメントは第1のセグメントを第2のセグメントから分離し得ること、ならびに図20の記述において「第1の」および「第2の」という用語は順序的にではなく名目的に使用されていることを理解されたい。サーバデバイスはさらに、第2のセグメントのマルチメディアデータがシーン変化IDRピクチャを含むと判定する(458)ことがある。その上、サーバデバイスは、マルチメディアデータが他のIDRピクチャ、たとえば、第2のセグメントのマルチメディアデータの開始点においてIDRピクチャをまったく含んでいないと判定することがある。
【０２０４】
従来では、第2のセグメントは、第2のセグメントの開始点においてIDRピクチャを含み得るが、本開示の技法によれば、サーバデバイスはシーン変化IDRピクチャを、関連コーディング規格に適合するIDRピクチャとして扱うことができる。すなわち、第2のセグメントのシーン変化IDRピクチャを、追加の「強制IDR」ピクチャの代わりに使用することができる。したがって、サーバデバイスは、関連規格の規定にもかかわらず、第2のセグメントの開始点において第2のセグメントがIDRピクチャを欠くように、マルチメディアデータを含む第2のセグメントを形成することができる。第2のセグメントのマルチメディアデータは、シーン変化IDRピクチャを含むので、このシーン変化IDRピクチャは、特定の時間的規則性を伴って発生するIDRピクチャの関連規格の規定に適合し得る。
【０２０５】
さらに、クライアントデバイス40(図1)などのクライアントデバイスは、第2のセグメントのデータを取り出す(462)ことができる。たとえば、クライアントデバイスは、シーン変化IDRピクチャにおいてネットワークストリーミングを開始することができる。したがってクライアントデバイスは、第2のセグメントの開始点においてネットワークストリーミングを開始するのではなく、代わりにシーン変化IDRピクチャにおいてネットワークストリーミングを開始することができる。サーバデバイスは、シーン変化IDRピクチャの開始点に対するバイト範囲オフセットを、たとえば、第1のセグメントおよび第2のセグメントに対応するマニフェストファイルにおいて通知することができる。したがって、クライアントデバイスは、バイトオフセットで始まる第2のセグメントのバイト範囲を指定して、部分GET要求を提出することができる。
【０２０６】
クライアントデバイスは、シーン変化IDRピクチャに先行する第2のセグメントのデータを取り出すことができるが、取り出す必要はない。しかしながら、クライアントデバイスが、第2のセグメントでストリーミングを開始するとき、(復号順序による)第2のセグメントにおけるシーン変化IDRピクチャに先行するそのようなデータは、復号可能でないことがある。クライアントデバイスは、復号順序によるシーン変化IDRピクチャで始まる形で、第2のセグメントの受信されたデータを復号する(464)ことができる。クライアントデバイスはまた、復号後に第2のセグメントのピクチャの順序を表示順序に並べ替え、復号されたピクチャを表示することができる。
【０２０７】
このようにして、図20の方法は、マルチメディアデータのセグメントを受信するステップであって、マルチメディアデータのセグメントのメディアデータは、第2のセグメントの開始点においてストリームアクセスポイントを欠く、ステップと、セグメントのメディアデータの少なくとも一部分を復号するステップとを含む方法の一例を表している。
【０２０８】
図20の方法は、第2のセグメントで始まるランダムアクセスをクライアントデバイスが実行する一例を表している。しかしながら、他の例では、クライアントデバイスは、第1のセグメントと第2のセグメントの両方を受信することができる。そのような例では、方法は、メディアデータの第1のセグメントを受信するステップであって、第1のセグメントのメディアデータは、第1のストリームアクセスポイントを含む、ステップと、メディアデータの第2のセグメントを受信するステップであって、第2のセグメントのメディアデータは、第2のセグメントの開始点においてストリームアクセスポイントを欠く、ステップと、第1のストリームアクセスポイントの後、第2のストリームアクセスポイントが利用可能になる前に、第1のセグメントのメディアデータの少なくとも一部分に関連して、第2のセグメントのメディアデータの少なくとも一部分を復号するステップとを含むことができる。具体的には、この例では、第2セグメントは、第1のストリームアクセスポイントと第2のストリームアクセスポイントの両方とは別個の第3のストリームアクセスポイントを含み、第3のストリームアクセスポイントは、第2のセグメントの開始点以外の位置において発生する。このようにして、第3のストリームアクセスポイントは、第1のストリームアクセスポイントの後であるが、第2のストリームアクセスポイントの前に発生する。第1のセグメントに関連して復号される第2のセグメントの部分は、復号順序によるシーン変化IDRに先行する1つまたは複数のピクチャに対応し得る。
【０２０９】
図20の方法は、メディアデータの第1のセグメントを取得するステップであって、第1のセグメントのメディアデータは、第1のストリームアクセスポイントを含む、ステップと、第1のセグメントをクライアントデバイスに送るステップと、メディアデータの第2のセグメントを取得するステップであって、第2のセグメントのメディアデータは、第2のセグメントの開始点においてストリームアクセスポイントを欠き、第2のセグメントのメディアデータの少なくとも一部分は、第1のセグメントのメディアデータの一部分に関連してコード化される、ステップと、第1のストリームアクセスポイントの後、第2のストリームアクセスポイントが利用可能になる前に、第2のセグメントをクライアントデバイスに送るステップとを含む方法の一例も表している。
【０２１０】
1つまたは複数の例では、本明細書で説明する機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。ソフトウェアで実装される場合、機能は、1つまたは複数の命令またはコードとしてコンピュータ可読媒体上に記憶され、あるいはコンピュータ可読媒体を介して送信されてよく、かつハードウェアに基づく処理ユニットによって実行されてよい。コンピュータ可読媒体は、データ記憶媒体のような有形媒体、または、たとえば通信プロトコルに従って、ある場所から別の場所へのコンピュータプログラムの転送を支援する任意の媒体を含む通信媒体に相当する、コンピュータ可読記憶媒体を含み得る。このようにして、コンピュータ可読媒体は一般に、(1)非一時的な有形コンピュータ可読記憶媒体または(2)信号波もしくは搬送波のような通信媒体に相当し得る。データ記憶媒体は、本開示で説明される技法を実装するための、命令、コード、および/またはデータ構造を取り出すために、1つもしくは複数のコンピュータまたは1つもしくは複数のプロセッサによってアクセスされ得る、任意の利用可能な媒体であってよい。コンピュータプログラム製品は、コンピュータ可読媒体を含み得る。
【０２１１】
限定ではなく例として、そのようなコンピュータ可読記憶媒体は、RAM、ROM、EEPROM、CD-ROMもしくは他の光ディスクストレージ、磁気ディスクストレージもしくは他の磁気ストレージデバイス、フラッシュメモリ、または、命令もしくはデータ構造の形態の所望のプログラムコードを記憶するために使用され、コンピュータによってアクセスされ得る任意の他の媒体を含み得る。また、いかなる接続もコンピュータ可読媒体と適切に呼ばれる。たとえば、命令が、同軸ケーブル、光ファイバケーブル、ツイストペア、デジタル加入者回線(DSL)、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用して、ウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバケーブル、ツイストペア、DSL、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。しかしながら、コンピュータ可読記憶媒体およびデータ記憶媒体は、接続、搬送波、信号、または他の一時的な媒体を含まず、代わりに非一時的な有形記憶媒体を指すことを理解されたい。本明細書で使われる場合、ディスク(disk)およびディスク(disc)は、コンパクトディスク(CD)、レーザーディスク（登録商標）、光ディスク、デジタル多用途ディスク(DVD)、フロッピー（登録商標）ディスク、およびブルーレイディスクを含み、ディスク(disk)は、通常、磁気的にデータを再生し、ディスク(disc)は、レーザーで光学的にデータを再生する。上記の組合せもコンピュータ可読媒体の範囲内に含めるべきである。
【０２１２】
命令は、1つまたは複数のデジタル信号プロセッサ(DSP)、汎用マイクロプロセッサ、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、または他の等価の集積論理回路もしくはディスクリート論理回路のような、1つまたは複数のプロセッサによって実行され得る。したがって、本明細書で使用される「プロセッサ」という用語は、前述の構造、または、本明細書で説明される技法の実装に適した任意の他の構造の、いずれをも指し得る。加えて、いくつかの態様では、本明細書で説明される機能は、符号化および復号のために構成された、専用のハードウェアモジュールおよび/またはソフトウェアモジュール内で提供されてよく、または、組み合わされたコーデックに組み込まれてよい。また、技法は、1つまたは複数の回路素子または論理素子において完全に実装されてもよい。
【０２１３】
本開示の技法は、ワイヤレスハンドセット、集積回路(IC)、またはICのセット(たとえば、チップセット)を含む、多様なデバイスまたは装置において実装され得る。様々な構成要素、モジュール、またはユニットが、開示される技法を実行するように構成されるデバイスの機能的な側面を強調するために、本開示において説明されるが、必ずしも異なるハードウェアユニットによる実現を必要としない。むしろ上で説明されたように、様々なユニットは、コーデックハードウェアユニットへと組み合わされてよく、または、適切なソフトウェアおよび/またはファームウェアとともに、上で説明されたような1つまたは複数のプロセッサを含む相互動作可能なハードウェアユニットの集合によって与えられてよい。
【０２１４】
様々な例が説明されてきた。これらの例および他の例は、以下の特許請求の範囲内にある。
【符号の説明】
【０２１５】
10  システム
20  コンテンツ準備デバイス
22  オーディオソース
24  ビデオソース
26  オーディオエンコーダ
28  ビデオエンコーダ
30  カプセル化ユニット
32  出力インターフェース
40  クライアントデバイス
42  オーディオ出力
44  ビデオ出力
46  オーディオデコーダ
48  ビデオデコーダ
50  カプセル化解除ユニット
52  取出しユニット
54  ネットワークインターフェース
60  サーバデバイス
62  記憶媒体、メモリ
64  マルチメディアコンテンツ
66  マニフェストファイル
68  表現
68A  表現
68N  表現
70  要求処理ユニット
72  ネットワークインターフェース
74  ネットワーク
80  ストリーム管理ユニット
90  ソース構成要素
92  メディアファイル記憶処理ユニット
94  MPDパーシングユニット
96  メディアファイル逆多重化(demux)ユニット
98  適応ユニット
【図１】
0005788101.tif 000005
【図２】
0005788101.tif 000006
【図３】
0005788101.tif 000007
【図４】
0005788101.tif 000008
【図５】
0005788101.tif 000009
【図６】
0005788101.tif 000010
【図１２】
0005788101.tif 000011
【図１３】
0005788101.tif 000012
【図１４】
0005788101.tif 000013
【図１５】
0005788101.tif 000014
【図１６】
0005788101.tif 000015
【図１７】
0005788101.tif 000016
【図１８】
0005788101.tif 000017
【図１９】
0005788101.tif 000018
【図２０】
0005788101.tif 000019
【図７】
0005788101.tif 000020
【図８】
0005788101.tif 000021
【図９】
0005788101.tif 000022
【図１０】
0005788101.tif 000023
【図１１】
0005788101.tif 000024