IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ テンセント・アメリカ・エルエルシーの特許一覧

特許7016428帯域外エンドオブストリームNALユニットを復号化に使用する方法、装置、及びコンピュータプログラム
<>
  • 特許-帯域外エンドオブストリームNALユニットを復号化に使用する方法、装置、及びコンピュータプログラム 図1
  • 特許-帯域外エンドオブストリームNALユニットを復号化に使用する方法、装置、及びコンピュータプログラム 図2
  • 特許-帯域外エンドオブストリームNALユニットを復号化に使用する方法、装置、及びコンピュータプログラム 図3
  • 特許-帯域外エンドオブストリームNALユニットを復号化に使用する方法、装置、及びコンピュータプログラム 図4
  • 特許-帯域外エンドオブストリームNALユニットを復号化に使用する方法、装置、及びコンピュータプログラム 図5
  • 特許-帯域外エンドオブストリームNALユニットを復号化に使用する方法、装置、及びコンピュータプログラム 図6
  • 特許-帯域外エンドオブストリームNALユニットを復号化に使用する方法、装置、及びコンピュータプログラム 図7
  • 特許-帯域外エンドオブストリームNALユニットを復号化に使用する方法、装置、及びコンピュータプログラム 図8
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-01-27
(45)【発行日】2022-02-04
(54)【発明の名称】帯域外エンドオブストリームNALユニットを復号化に使用する方法、装置、及びコンピュータプログラム
(51)【国際特許分類】
   H04N 19/70 20140101AFI20220128BHJP
【FI】
H04N19/70
【請求項の数】 10
(21)【出願番号】P 2020551303
(86)(22)【出願日】2019-08-28
(65)【公表番号】
(43)【公表日】2021-07-15
(86)【国際出願番号】 US2019048538
(87)【国際公開番号】W WO2020055589
(87)【国際公開日】2020-03-19
【審査請求日】2020-09-23
(31)【優先権主張番号】62/730,885
(32)【優先日】2018-09-13
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】16/232,677
(32)【優先日】2018-12-26
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】520353802
【氏名又は名称】テンセント・アメリカ・エルエルシー
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【弁理士】
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100135079
【弁理士】
【氏名又は名称】宮崎 修
(72)【発明者】
【氏名】ウェンジャー,ステファン
(72)【発明者】
【氏名】リィウ,シャン
【審査官】岩井 健二
(56)【参考文献】
【文献】国際公開第2018/033661(WO,A1)
【文献】国際公開第2015/196028(WO,A1)
【文献】国際公開第2014/098703(WO,A1)
【文献】米国特許出願公開第2016/0212439(US,A1)
【文献】米国特許出願公開第2016/0191931(US,A1)
【文献】米国特許出願公開第2015/0102928(US,A1)
【文献】米国特許出願公開第2014/0003489(US,A1)
【文献】米国特許出願公開第2005/0123055(US,A1)
【文献】Stephan Wenger et al.,On VVC HLS architecture and bitstream structure,Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11,JVET-L0110-v1,12th Meeting: Macao, CN,2018年09月,pp.1-3
(58)【調査した分野】(Int.Cl.,DB名)
H04N 19/00 - 19/98
(57)【特許請求の範囲】
【請求項1】
少なくとも1つのビデオストリームを復号するための方法であって、前記少なくとも1つのビデオストリームにおける各ビデオストリームは、それぞれの復号器パラメータセットに関連付けられており、前記方法は、
復号器が、前記少なくとも1つのビデオストリームにおける第1のビデオストリームの復号器パラメータセットをアクティブ化するステップと、
前記復号器が、前記第1のビデオストリームの外部にあって前記復号器に利用可能なエンドオブストリームNALユニットを処理するステップと、
前記復号器が、前記エンドオブストリームNALユニットを処理することに応答して、前記復号器が、前記第1のビデオストリームの復号器パラメータセットを非アクティブ化するステップと、を含み、
前記第1のビデオストリームの復号器パラメータセットをアクティブ化する前記ステップは、
前記第1のビデオストリームの復号器パラメータセットのパラメータに基づき、前記第1のビデオストリームを復号化するステップ、を含み、
前記復号器は、前記第1のビデオストリームに関連付けられる少なくとも1つのピクチャパラメータセット(PPS)及び少なくとも1つのピクチャヘッダーを使用して前記第1のビデオストリームを復号化し、前記少なくとも1つのピクチャヘッダー及び前記少なくとも1つのPPSは、前記第1のビデオストリームの前記復号器パラメータセットよりも低い構文レベルにある、
方法。
【請求項2】
前記第1のビデオストリームの復号器パラメータセットをアクティブ化した後、前記復号器が前記エンドオブストリームNALユニットを処理するまで、前記第1のビデオストリームの復号器パラメータセットはアクティブ化されたままである請求項1に記載の方法。
【請求項3】
前記第1のビデオストリームの復号器パラメータセットを非アクティブ化した後に、前記復号器が前記少なくとも1つのビデオストリームにおける第2のビデオストリームの復号器パラメータセットをアクティブ化するステップ、をさらに含む請求項1または2に記載の方法。
【請求項4】
前記第2のビデオストリームの復号器パラメータセットは、前記第1のビデオストリームの復号器パラメータセットと異なるコンテンツを有する請求項3に記載の方法。
【請求項5】
前記復号器が前記エンドオブストリームNALユニットを処理する前に、前記復号器が前記第2のビデオストリームの復号器パラメータセットを受信するステップ、をさらに含む請求項3に記載の方法。
【請求項6】
前記復号器が前記エンドオブストリームNALユニットを処理した後に、前記復号器が前記第2のビデオストリームの復号器パラメータセットを受信するステップ、をさらに含む請求項3に記載の方法。
【請求項7】
前記第1のビデオストリームの前記復号器パラメータセットを非アクティブ化する前記ステップは、
前記復号器のバッファをフラッシュするステップと、
前記復号器によって復号化された前記第1のビデオストリームのピクチャの出力を停止するステップと、
を含む請求項1乃至6のうちいずれか1項に記載の方法。
【請求項8】
前記少なくとも1つのピクチャヘッダー及び前記少なくとも1つのPPSは、同じ構文レベルにある請求項に記載の方法。
【請求項9】
請求項1ないし8のうちいずれか一項に記載の方法を実行するように構成された復号装置。
【請求項10】
請求項1乃至のいずれか1項に記載の方法をコンピュータに実行させるコンピュータプログラム。

【発明の詳細な説明】
【技術分野】
【0001】
本出願は、2018年9月13日にて提出された、出願番号が62/730,885である米国仮出願、及び2018年12月26日にて提出された、出願番号が16/232,677である米国仮出願に基づく優先権を主張し、その全内容を参照により本出願に援用する。
【0002】
実施例と一致する方法及び装置は、ビデオの符号化及び復号化に関し、より具体的に、高水準構文アーキテクチャを使用して符号化及び復号化を行い、帯域外で受信されるエンドオブストリームNALユニットを使用して復号化する方法及び装置に関する。
【背景技術】
【0003】
現在、動き補償を伴うインターピクチャ予測を使用してビデオの符号化及び復号化を実行している。非圧縮のデジタルビデオは一連のピクチャを含んでもよく、各ピクチャの空間次元は、例えば1920×1080の輝度サンプル及び関連するクロミナンスサンプルである。当該一連のピクチャは、例えば、1秒あたり60のピクチャ又は60Hzの固定又は可変のピクチャレート(非正式にはフレームレートとも呼ばれる)を有してもよい。非圧縮のビデオは、高いビットレート要件を有する。例えば、サンプルあたりの8ビットの1080p60 4:2:0ビデオ(60Hzのフレームレートで、1920×1080の輝度サンプル解像度)は、1.5Gbit/sに近い帯域幅が必要である。このような1時間のビデオは、600GBを超えるストレージスペースが必要である。
【0004】
ビデオ符号化及び復号化は、圧縮によって入力ビデオ信号の冗長少させることを1つの目的とする。圧縮は、上記の帯域幅又はストレージスペースの要件を、場合によって2桁以上削減することに寄与する。可逆圧縮、非可逆圧縮、及びそれらの組み合わせを利用し得る。可逆圧縮は、圧縮された元の信号から元の信号の正確なコピーを再構築する技術を指す。非可逆圧縮を利用する場合、再構築された信号は元の信号と異なるかもしれないが、元の信号と再構築された信号との間の歪みは十分に小さいから、再構築された信号は意図された用途に役立つ。ビデオの場合、非可逆圧縮は広く応用される。許容される歪み量はアプリケーションに依存し、例えば、特定のコンシューマストリームアプリケーションのユーザーは、テレビ投稿アプリケーションのユーザーよりも高い歪みを許容できる。実現可能な圧縮比は、許可/許容可能な歪みが高いほど、圧縮比が高くなることを反映することができる。
【0005】
ビデオ符号器及び復号器は、動き補償、変換、量子化、エントロピー符号化などを含むいくつかの幅広いカテゴリの技術を利用することができる。これらの技術の一部を以下に紹介する。
【0006】
H.264より前の一部のビデオコーデック(例えばMPEG-2 Visual)は、一時的ヘッダーの階層構造を使用し、当該一時的ヘッダーは、シーケンスヘッダー、ピクチャグループ(GOP)ヘッダー、ピクチャヘッダー、スライスヘッダーを含む。各ヘッダーに含まれる構文要素は、全ての下位レベルの構文構造に関する。例えば、シーケンスヘッダーの構文要素は、シーケンスに含まれるの全てのGOP、これらのGOPに含まれる全てのピクチャ、及びこれらのピクチャに含まれる全てのスライスに関す。GOPヘッダーの構文要素は、GOPに含まれる全てのピクチャ、及びこれらのピクチャにおける全てのスライスに関する。このような階層構造は効率的な符号化につながることができるが、最適でない誤り耐性を有する。例えば、シーケンスヘッダーの重要な情報が伝送中に失われた場合、シーケンスのGOP、ピクチャ、又はスライスを復号化することができない。
【0007】
2003年以降、一部のITU及びMPEGビデオコーデック、即ち、H.264及びH.265は、スライスヘッダーの上に一時的ヘッダーを使用せず、パラメータセットに依存する。例えば、シーケンスレベル又はピクチャレベルなどの各構文レベルにおいて、復号器又は外部の装置によりビットストリームから1つ又は複数のパラメータセットを受信することができる。これらの(場合によって多数の)同じタイプのパラメータセットのどれを使用して所定のシーケンス又はピクチャを復号化するかは、例えばスライスヘッダー(ピクチャパラメータセットPPSの場合)又はPPS(シーケンスパラメータセットSPSの場合)に符号化される参照に依存する。このアーキテクチャは以下の利点を有することができる:ビットストリーム自体が非可逆チャネルを介して送信されても、関連するパラメータセットを確実に送信できる。又は、可能性としては初めてパラメータセットを使用するよりも十分前に、冗長コピーを送信することでパラメータセットが受信される可能性を高めることができ一つの欠点は以下のものである:パラメータセットの送信は、MPEG-2タイプのヘッダーの送信よりも、同じ数とタイプの構文要素に必要なビット数の点が多くなる可能性がある。また、ピクチャの間で頻繁に変化するが所定のピクチャ内では一定のままであるある種の構文要素が、このアーキテクチャでは、各スライスヘッダーに複数の冗長コピーの形で含まれる可能性がある。そうすることで、(少なくとも解析の依存性とエントロピー復号化の観点から)スライスを独立して復号化可能にすることができるが、より多いビットを占有することがある。
【0008】
H.264の設計中、スライスの独立した復号化可能性は、誤り耐性特性の理由から、主要な設計目標と考えられ。しかしながら、2003年以降、失われたスライスの隠蔽効果がますます弱くなるにつれて、符号化されたビデオを伝送するネットワークアーキテクチャの改善と予測メカニズムの進歩により、スライスの独立した復号化可能性の魅力著しく低減た。
【発明の概要】
【発明が解決しようとする課題】
【0009】
要求されるものがスライスの独立した復号化可能性ではなくなった結果、少なくとも所定のピクチャの損失が復号器で合理的に隠蔽できると仮定のもとで良好な誤り耐性特性を維持するとともに、符号化効率の点でMPEG-2タイプのヘッダー構造の利点を利用する、新しい高レベル構文アーキテクチャが必要である。本発明のいくつかの実施例は、良好な誤り耐性特性及び符号化効率を維持するこのような高レベル構文アーキテクチャを提供する。
【課題を解決するための手段】
【0010】
本出願で開示された一態様によれば、少なくとも1つのビデオストリームを復号化するための方法であって、当該少なくとも1つのビデオストリームのそれぞれは、それぞれの復号器パラメータセットに関連付けられる。当該方法は、復号器が少なくとも1つのビデオストリームにおける第1のビデオストリームの復号器パラメータセットをアクティブ化することを含むことができる。当該方法は、復号器が第1のビデオストリームの外部の復号器で利用可能なエンドオブストリームNALユニットを処理することをさらに含むことができる。当該方法は、復号器がエンドオブストリームNALユニットを処理することに応答して、第1のビデオストリームの復号器パラメータセットを非アクティブ化することをさらに含むことができる。
【0011】
本出願で開示された他の態様によれば、少なくとも1つのビデオストリームを復号化するための装置を提供し、当該少なくとも1つのビデオストリームのそれぞれは、それぞれの復号器パラメータセットに関連付けられる。当該装置は復号器を含むことができ、当該復号器は、少なくとも1つのビデオストリームにおける第1のビデオストリームの復号器パラメータセットをアクティブ化するために用いられる。当該復号器は、さらに、第1のビデオストリームの外部の復号器で利用可能なエンドオブストリームNALユニットを処理するために用いられることができる。当該復号器は、さらに、エンドオブストリームNALユニットを処理することに応答して、第1のビデオストリームの復号器パラメータセットを非アクティブ化するために用いられることができる。
本出願で開示されるさらに他の態様によれば、命令を記憶する非一時的コンピュータ可読媒体を使用することができる。当該命令は1つ又は複数の命令を含み、デバイスの1つ又は複数のプロセッサによって実行される場合に、当該1つ又は複数の命令は、当該1つ又は複数のプロセッサに、少なくとも1つのビデオストリームを復号化させ、当該少なくとも1つのビデオストリームのそれぞれは、それぞれの復号器パラメータセットに関連付けられており、前記1つ又は複数のプロセッサは、少なくとも1つのビデオストリームにおける第1のビデオストリームの復号器パラメータセットをアクティブ化し、第1のビデオストリームの外部の復号器で利用可能なエンドオブストリームNALユニットを処理し、エンドオブストリームNALユニットを処理することに応答して、第1のビデオストリームの復号器パラメータセットを非アクティブ化するという動作により、少なくとも1つのビデオストリームを復号化する。
【図面の簡単な説明】
【0012】
開示された主題の他の特徴、性質及び様々な利点は以下の詳しい記載及び図面から、より明確になる。図面において、
【0013】
図1】一実施例による通信システムの簡略化ブロック図の模式図である。
【0014】
図2】一実施例によるストリーミングシステムの簡略化ブロック図の模式図である。
【0015】
図3】一実施例によるビデオ復号器及びディスプレイの簡略化ブロック図の模式図である。
【0016】
図4】一実施例によるビデオ符号器及びビデオソースの簡略化ブロック図の模式図である。
【0017】
図5】一実施例による高レベル構文アーキテクチャにおける構文階層の模式図である。
【0018】
図6】一実施例によるピクチャヘッダー及びピクチャパラメータセットの模式図である。
【0019】
図7】一実施例による帯域外でエンドオブストリームを受信する場合に復号器パラメータセットを変更するフローの模式図である。
【0020】
図8】一実施例によるコンピュータシステムの模式図である。
【発明を実施するための形態】
【0021】
図1は、本出願の一実施例における通信システム(100)の簡略化ブロック図を示す。通信システム(100)は、ネットワーク(150)を介して相互接続された少なくとも2つの端末(110、120)を含み得る。データの一方向伝送の場合、第1の端末(110)は、ローカル位置でビデオデータを符号化して、ネットワーク(150)を介して他の端末(120)に伝送することができる。第2の端末(120)は、ネットワーク(150)から他の端末の符号化されたビデオデータを受信し、符号化されたデータを復号化し、復元されたビデオデータを表示することができる。データの一方向伝送は、メディアサービスアプリケーションなどでは一般的である。
【0022】
図1は、例えば、ビデオ会議中に発生する可能性がある符号化されたビデオの双方向伝送をサポートするために提供される第2対の端末(130、140)を示す。データの双方向伝送の場合、各端末(130、140)は、ローカル位置でキャプチャされたビデオデータを符号化して、ネットワーク(150)を介して他方の端末に伝送することができる。各端末(130、140)は、また、他方の端末によって伝送された符号化されたビデオデータを受信し、符号化されたデータを復号化し、復元されたビデオデータをローカル表示デバイスに表示してもよい。
【0023】
図1において、端末(110~140)は、例えば、サーバ、パーソナルコンピュータ、スマートフォン、及び/又は他のタイプの端末であってもよい。例えば、端末(110~140)は、ラップトップコンピュータ、タブレットコンピュータ、メディアプレイヤー及び/又は専用のビデオ会議機器であってもよい。ネットワーク(150)は端末(110~140)の間で符号化されたビデオデータを伝送する任意の数のネットワークを示し、例えば、有線(ワイヤード)及び/又は無線通信ネットワークを含む。通信ネットワーク(150)は、回線交換及び/又はパケット交換チャネルにおいてデータを交換することができる。当該ネットワークは、電気通信ネットワーク、ローカルエリアネットワーク、ワイドエリアネットワーク及び/又はインターネットを含むことができる。本出願の検討の目的のために、ネットワーク(150)のアーキテクチャとトポロジーは、以下に本明細書で説明されない限り、本出願で開示される動作にとって重要ではないかもしれない。
【0024】
本出願で開示された主題の一実施例として、図2は、ストリーミング環境におけるビデオ符号器と復号器の配置形態を示し、本出願で開示された主題は、等価的に、例えば、ビデオ会議、デジタルTVを含む、ビデオをサポートする他のアプリケーションに適用され、CD、DVD、メモリースティックなどを含むデジタルメデイアに圧縮ビデオなどを記憶してもよい。
【0025】
図2に示すように、ストリーミングシステム(200)は、キャプチャサブシステム(213)を含むことができ、当該キャプチャサブシステムは、ビデオソース(201)と符号器(203)を含む。当該ストリーミングシステム(200)は、少なくとも1つのストリーミングサーバ(205)と少なくとも1つのストリーミングクライアント(206)を含んでもよい。
【0026】
ビデオソース(201)は、例えば、非圧縮のビデオサンプルストリーム(202)を作成することができる。ビデオソース(201)は例えばデジタル撮影装置であってもよい。サンプリングストリーム(202)は、ビデオカメラ(201)に連結された符号器(203)によって処理されることができ、符号化されたビデオビットストリームと比較して多いデータ量を強調するために太線として描かれる。符号器(203)は、以下でより詳細に説明する本出願で開示された主題の各態様を実現又は実施するために、ハードウェア、ソフトウェア、又はそれらの組み合わせを含むことができる。符号器(203)は、符号化されたビデオビットストリーム(204)をさらに生成することができる。ビデオビットストリーム(204)は、将来の使用のために、ストリーミングサーバ(205)に記憶され得、非圧縮のサンプルストリーム(202)と比較して少ないデータ量を強調するために細い線として描かれる。1つ以上のストリーミングクライアント(206)は、ストリーミングサーバ(205)にアクセスして、ビデオビットストリーム(209)を検索することができ、当該ビデオビットストリーム(209)は符号化されたビデオビットストリーム(204)のコピーであってもよい。
【0027】
スクリーミングクライアント(206)は、ビデオ復号器(210)とディスプレイ(212)を含むことができる。ビデオ復号器(210)は、例えば、ビデオビットストリーム(209)を復号化することができ、当該ビデオビットストリームは符号化されたビデオビットストリーム(204)の入力コピーであり、さらに、ビデオ復号器(210)はディスプレイ(212)又は他のレンダリングデバイス(図示せず)でレンダリングできる出力ビデオサンプルストリーム(211)を作成することができる。一部のストリーミングシステムでは、ビデオビットストリーム(204、209)を、特定のビデオ符号化/圧縮規格に従って符号化できる。これらの規格の例には、ITU-T H.265勧告書を含むがそれに限定されない。非公式に多用途ビデオ符号化(VVC)と呼ばれるビデオ符号化規格が開発中である。本出願で開示された主題は、VVCの環境で使用することができる。
【0028】
図3は、本出願の一実施例によるディスプレイ(212)に接続されたビデオ復号器(210)の例示的な機能ブロック図を示す。
【0029】
ビデオ復号器(210)は、チャネル(312)、受信機(310)、バッファメモリ(315)、エントロピー復号器/パーサ(320)、スケーラ/逆変換ユニット(351)、イントラ予測ユニット(352)、動き補償予測ユニット(353)、アグリゲータ(355)、ループフィルタユニット(356)、参照ピクチャメモリ(357)、及び現在ピクチャメモリ(358)を含むことができる。少なくとも1つの実施例において、ビデオ復号器(210)は、集積回路、一連の集積回路、及び/又は他の電子回路を含み得る。ビデオ復号器(210)は、また、関連するメモリを備えた1つ以上のCPU上で実行されるソフトウェアとして部分的又は全体的に実現され得る。
【0030】
本実施例及び他の実施例において、受信機(310)は、復号器(210)によって復号化される1つ以上の符号化されたビデオシーケンスを1つずつ受信することができ、各符号化されたビデオシーケンスの復号化は他の符号化されたビデオシーケンスから独立している。チャネル(312)から符号化されたビデオシーケンスを受信することができ、当該チャネルは、当該符号化されたビデオデータを記憶するストレージデバイスに接続されたハードウェア/ソフトウェアリンクであってもよい。受信機(310)は、符号化されたビデオデータ及び他のデータ、例えば、それぞれの使用エンティティ(図示せず)に転送され得る符号化されたオーディオデータ及び/又は補助データストリームを受信してもよい。受信機(310)は、符号化されたビデオシーケンスを他のデータから分離することができる。ネットワークジッタを防止するために、バッファメモリ(315)は、受信機(310)とエントロピー復号器/パーサ(320)(以降、「パーサ」と呼ばれる)との間に結合され得る。受信機(310)が十分な帯域幅と制御性を有する記憶/転送デバイス、又は等時性リアルタイムネットワークからデータを受信する場合に、バッファメモリ(315)を必要としない場合があり、又は、小さい容量のバッファメモリ(315)を使用してもよい。例えばインターネットのベストパケットネットワークで使用するために、バッファメモリ(315)が必要となる場合があり、当該バッファメモリは、比較的大きくすることができ、自己適応サイズを有することができる。
【0031】
ビデオ復号器(210)は、エントロピー符号化されたビデオシーケンスに基づきシンボル(321)を再構成するために、パーサ(320)を含み得る。これらのシンボルのカテゴリは、例えば、復号器(210)の動作を管理するための情報を含み、例えば、ディスプレイ(212)のレンダリングデバイスを制御するための情報を含む可能性があり、当該レンダリングデバイスが図2に示す復号器に結合され得る。1つ以上のレンダリングデバイスのための制御情報は、補助拡張情報(SEIメッセージ)又はビデオユーザビリティ情報(VUI)パラメータセットフラグメント(図示せず)の形であってよい。パーサ(320)は、受信された符号化されたビデオシーケンスを解析/エントロピー復号化することができる。符号化されたビデオシーケンスの符号化は、ビデオ符号化技術又は規格に準拠することができ、当業者に周知の原理に従うこともでき、可変長符号化、ハフマン符号化(Huffman coding)、文脈依存の有無にかかわらず算術符号化などを含む。パーサ(320)は、グループに対応する少なくとも1つのパラメータに基づいて、符号化されたビデオシーケンスから、ビデオ復号器における少なくとも1つの画素のサブグループのサブグループパラメータセットを抽出することができる。サブグループは、ピクチャのグループ(GOP)、ピクチャ、タイル、スライス、マクロブロック、符号化ユニット(CU)、ブロック、変換ユニット(TU)、予測ユニット(PU)などを含んでもよい。パーサ(320)は、また、符号化されたビデオシーケンス情報から、例えば、変換係数、量子化器パラメータ値、動きベクトルなどの情報を抽出してもよい。
【0032】
パーサ(320)はバッファメモリ(315)から受信したビデオシーケンスに対してエントロピー復号化/解析操作を実行することで、シンボル(321)を作成することができる。
【0033】
シンボル(321)の再構築は、符号化されたビデオピクチャ又はその一部(例えば、インターピクチャ及びイントラピクチャ、インターブロック及びイントラブロック)のタイプ、及びその他の要因に依存し、複数の異なるユニットに関することができる。関与するユニット及び関与形態について、パーサ(320)によって符号化されたビデオシーケンスから解析されたサブグループ制御情報によって制御されることができる。簡潔のために、ここで、パーサ(320)と以下で説明する複数のユニットとの間のサブグループ制御情報の流れは説明されない。
【0034】
既に言及された機能ブロック以外、ビデオ復号器(210)は概念的に、後述する若干の機能ユニットに細分することができる。商業制約の下で実行する実際の実現方式において、これらのユニットにおける複数のユニットは互いに密接にインタラクトするとともに、少なくとも部分的に互いに集積されてもよい。しかしながら、開示された主題を説明するという目的のために、概念的に以下の機能ユニットに細分されることは適切である。
【0035】
一つのユニットはスケーラ/逆変換ユニット(351)であってもよい。スケーラ/逆変換ユニット(351)は、パーサ(320)から(1つ以上の)シンボル(321)としての量子化変換係数及び制御情報を受信し、使用する変換方法、ブロックサイズ、量子化係数、量子化スケーリングマトリックスなどを含む。スケーラ/逆変換ユニット(351)は、サンプル値を含むブロックを出力することができ、当該ブロックはアグリゲータ(355)に入力することができる。
【0036】
いくつかの場合に、スケーラ/逆変換ユニット(351)の出力サンプルは、イントラ符号化ブロック、即ち、以前に再構築されたピクチャからの予測情報を使用しないが、現在のピクチャの以前に再構築された部分からの予測情報を使用するブロックに関してもよい。これらの予測情報は、イントラピクチャ予測ユニット(352)によって提供することができる。いくつかの場合に、イントラピクチャ予測ユニット(352)は、現在の(部分的に再構築された)ピクチャ(356)から抽出された、周囲が既に再構築された情報を使用して、再構築中のブロックと同じサイズ及び形状のブロックを生成する。いくつかの場合に、アグリゲータ(355)は、各サンプルに基づいて、イントラ予測ユニット(352)によって生成される予測情報を、スケーラ/逆変換ユニット(351)から提供される出力サンプル情報に追加する。
【0037】
他の場合には、スケーラ/逆変換ユニット(351)の出力サンプルは、インター符号化ブロックに関することができ、当該ブロックは動き補償が行わた可能性がある。このような場合に、動き補償予測ユニット(353)は、参照ピクチャメモリ(357)にアクセスして、予測のためのサンプルを抽出してもよい。当該ブロックに関するシンボル(321)に基づき、抽出されたサンプルに対して動き補償を行った後に、アグリゲータ(355)は、これらのサンプルをスケーラ/逆変換ユニットの出力(この場合に、残差サンプル又は残差信号と呼ばれる)に追加することで、出力サンプル情報を生成することができる。動き補償ユニット(353)は参照ピクチャメモリ(357)におけるアドレスから予測サンプルを取得し、当該アドレスは動きベクトルによって制御されることができる。動きベクトルはシンボル(321)の形で動き補償ユニットによって使用されることができ、当該シンボルは、例えば、X、Y、及び参照ピクチャ成分を有してもよい。動き補償には、サブサンプルの正確な動きベクトルが使用されている際に参照ピクチャメモリ(357)から抽出されたサンプル値の補間、動きベクトル予測メカニズムなどを含んでもよい。
【0038】
ループフィルタ(356)において、アグリゲータ(355)の出力サンプルに対して、様々なループフィルタリング技術を採用できる。ビデオ圧縮技術は、ループ内フィルタ技術を含んでもよく、ループ内フィルタ技術は、符号化されたビデオビットストリームに含まれ且つパーサ(320)からのシンボル(321)としてループフィルタユニット(356)に使用可能なパラメータによって制御され、しかしながら、ビデオ圧縮技術は、符号化されたピクチャ又は符号化されたビデオシーケンスの(復号化順序で)前の部分を復号化する期間に得られたメタ情報に応答してもよいし、以前に再構築されループフィルター処理されたサンプル値に応答してもよい。
【0039】
ループフィルタ(356)の出力はサンプルストリームであってもよく、当該サンプルストリームは、将来のインターピクチャ予測で使用されるために、ディスプレイ(212)のレンダリングデバイスに出力され、参照ピクチャメモリ(356)に記憶されてもよい。
【0040】
一部の符号化されたピクチャは、完全に再構成されると、将来の予測のために参照ピクチャとして使用されることができる。符号化されたピクチャは完全に再構成され、且つ(例えば、パーサ(320)によって)参照ピクチャとして識別されると、現在ピクチャメモリ(358)に記憶されている現在の参照ピクチャは参照ピクチャメモリ(357)の一部になることができ、そして、その後の符号化されたピクチャの再構築を開始する前に、新しい現在ピクチャメモリを再割り当てることができる。
【0041】
ビデオ復号器(210)は、例えばITU-TH.265勧告書の規格に記録されている所定のビデオ圧縮技術に従って、復号化動作を実行してもよい。符号化されたビデオシーケンスがビデオ圧縮技術又は規格の構文に準拠する場合、符号化されたビデオシーケンスは、使用されているビデオ圧縮技術又は規格によって指定される構文、例えば、ビデオ圧縮技術ドキュメント又は規格によって指定される構文、特にその中のプロファイルドキュメントによって指定される構文に準拠することができる。ビデオ圧縮技術又は規格に準拠するために、符号化されたビデオシーケンスの複雑さはビデオ圧縮技術又は規格のレベルで限定されている範囲内にあることができる。いくつかの場合に、レベルは、最大ピクチャのサイズ、最大フレームレート、最大再構成サンプルレート(例えば1秒あたりのメガサンプルを単位として測定する)、最大参照ピクチャサイズなどを制限する。いくつかの場合に、レベルによって設定される制限は、仮想参照復号器(HRD)の仕様及び符号化されたビデオシーケンスにおいて信号で示されるHRDバッファ管理のためのメタデータによってさらに制限されてもよい。
【0042】
一実施例において、受信機(310)は、追加の(冗長な)データと符号化されたビデオビデオを受信してもよい。当該追加のデータは符号化されたビデオシーケンス一部として含まれてもよい。ビデオ復号器(210)は、当該追加のデータを使用してデータを正確に復号化する、及び/又は、元のビデオデータをより正確に再構築してもよい。追加のデータは、例えば、時間拡張層、空間拡張層、又はSNR拡張層、冗長スライス、冗長ピクチャ、前方誤り訂正符号などの形であってもよい。
【0043】
図4は、本出願の一実施例によるビデオソース(201)と関連するビデオ符号器(203)の例示的な機能ブロック図を示す。
【0044】
ビデオ符号器(203)は、例えば、ソース符号器(430)である符号器、符号化エンジン(432)、(ローカル)復号器(433)、参照ピクチャメモリ(434)、予測器(435)、送信機(440)、エントロピー符号器(445)、コントローラ(450)及びチャネル(460)を含むことができる。
【0045】
符号器(203)は、ビデオソース(201)(符号器の一部ではない)からビデオサンプルを受信してもよく、当該ビデオソースは符号器(203)によって符号化される(1つ以上の)ビデオ画像をキャプチャすることができる。
【0046】
ビデオソース(201)は、符号器(203)によって符号化されるソースビデオシーケンスをデジタルビデオサンプルストリームの形で提供してもよく、当該デジタルビデオサンプルストリームは、任意の適切なビット深度(例えば、8ビット、10ビット、12ビット…)、任意の色空間(例えば、BT.601 Y CrCB、RGB…)及び任意の適切なサンプリング構成(例えば、Y CrCb 4:2:0、Y CrCb 4:4:4)を有してもよい。メディアサービスシステムでは、ビデオソース(201)は、以前に準備されたビデオを記憶するストレージデバイスであってもよい。ビデオ会議システムでは、ビデオソース(201)は、ローカルイメージ情報をビデオシーケンスとしてキャプチャする撮影装置であってもよい。ビデオデータは、順番に見る際に動きが形成される複数の個別のピクチャとして提供されてもよい。これらのピクチャ自体は空間画素アレイとして構成されてもよく、なお、各画素は、使用されるサンプリング構成、色空間などによって、1つ以上のサンプルを含んでもよい。当業者は、画素とサンプルとの間の関係を容易に理解することができる。以下の説明では、サンプルを中心に説明する。
【0047】
一実施例において、符号器(203)は、リアルタイムで、又はアプリケーションによって要求される他の任意の時間制約の下で、ソースビデオシーケンスのピクチャを符号化して圧縮することで、符号化されたビデオシーケンスを得ることができる。コントローラ(450)は、適切な符号化速度を強制的に採用する機能を有することができる。コントローラ(450)は、以下に説明する他の機能ユニットを制御し、これらのユニットに機能的に結合されてもよい。簡略化のために、当該結合は描かれていない。コントローラ(450)によって設置されるパラメータは、レート制御関連パラメータ(ピクチャスキップ、量子化器、レート歪み最適化技術のλ値…)、ピクチャサイズ、ピクチャグループ(GOP)レイアウト、最大動きベクトル検索範囲などを含んでもよい。コントローラ(450)の他の機能は、特定のシステム設計に対して最適化されたビデオ符号器(203)に属する可能性があるため、当業者は、これらの機能を容易に認識することができる。
【0048】
一部のビデオ符号器は、当業者が「符号化ループ」として容易に認識する形態で実行される。非常に簡略化した説明として、符号化ループは、ソース符号器(430)の符号化部分(符号化される入力ピクチャ及び(1つ以上の)参照ピクチャに基づいてシンボルを作成することを担当する)、符号器(203)に埋め込まれる(ローカルの)復号器(433)を含んでもよい。一部のビデオ圧縮技術におけるシンボルと符号化されたビデオビットストリームとの間は可逆圧縮である場合に、当該復号器はシンボルを再構築して(リモート)復号器によっても作成されたサンプルデータを作成する。当該再構築されたサンプルストリームは参照ピクチャメモリ(434)に入力されてもよい。シンボルストリームの復号化によって、復号器の位置(ローカル又はリモート)に関係がないビットが正確である結果が得られるため、参照ピクチャメモリ(434)のコンテンツもローカル符号器とリモート符号器との間においてビットで正確に対応する。つまり、符号器の予測部分が「見る」参照ピクチャサンプルと、復号器が復号化中に予測を使用する際に「見る」サンプル値とは全く同じである。参照ピクチャの同期性という基本的な原理(及び、例えば、チャネル誤差のため、同期性を維持できない場合に生じるドリフト)は、当業者に周知のものである。
【0049】
「ローカル」復号器(433)の動作は、以上で図4に基づいて詳細に説明されたビデオ復号器(210)の「リモート」復号器と同じであってもよい。しかしながら、また、図3を簡単に参照し、シンボルが利用可能であり、且つ、エントロピー符号器(445)及びパーサ(320)が無損失でシンボルを、符号化されたビデオシーケンスに符号化/復号化できる場合に、チャネル(312)、受信機(310)、バッファメモリ(315)及びパーサ(320)を含むビデオ復号器(210)のエントロピー復号化部分はローカル復号器(433)で完全に実現されない場合がある。
【0050】
この場合、復号器に存在する解析/エントロピー復号化に加えて、任意の復号器技術も、必然的に基本的に同じ機能形式で対応する符号器に存在することが観察される。そのため、本出願は復号器動作に焦点を合わせている。符号器技術と完全に説明された復号器技術とは相互に逆であるため、符号器技術の説明を簡略化できる。より詳しい説明は、特定の領域のみで必要であり、以下で提供される。
【0051】
動作の一部として、ソース符号器(430)は動き補償予測符号化を実行してもよく、ビデオシーケンスからの「参照ピクチャ」として指定された1つ以上の以前に符号化されたピクチャを参照し、前記動き補償予測符号化は入力ピクチャを予測的に符号化する。このようにして、符号化エンジン(432)は入力ピクチャの画素ブロックと、前記入力フレームの予測参照として選択され得る参照ピクチャの画素ブロックとの間の差異を符号化してもよい。
【0052】
ローカルビデオ復号器(433)は、ソース符号器(430)によって作成されたシンボルに基づいて、参照フレームとして指定され得るフレームの符号化されたビデオデータを復号化してもよい。符号化エンジン(432)の動作は、非可逆処理であり得る。符号化されたビデオデータがビデオ復号器(図4、図示せず)で復号化され得る場合、再構築されたビデオシーケンスは、通常、多少の誤差を有するソースビデオシーケンスのコピーであり得る。ローカルビデオ復号器(433)は、参照フレームに対してビデオ復号器によって実行され得る復号化処理を複製し、再構成された参照フレームを参照ピクチャバッファ(434)に記憶してもよい。このようにして、ビデオ符号器(203)は、再構成された参照フレームのコピーをローカルに記憶することができ、当該コピーは、リモートビデオ復号器によって得られる再構成された参照フレームと共通のコンテンツを有する(伝送誤差がない)。
【0053】
予測器(435)は、符号化エンジン(432)に対して予測検索を実行することができる。つまり、符号化される新しいフレームについて、予測器(435)は、参照ピクチャメモリ(434)において、前記新しいピクチャの適切な予測参照として使用し得るサンプルデータ(候補参照画素ブロックとする)、又は例えば参照ピクチャの動きベクトル、ブロック形状などの特定のメタデータを検索してもよい。予測器(435)は、適切な予測参照を見つけるために、サンプルブロックに基づいて、画素ブロックごとに動作することができる。いくつかの場合に、例えば、予測器(435)によって得られた検索結果に基づき、入力ピクチャが、参照ピクチャメモリ(434)に記憶された複数の参照ピクチャから取得された予測参照を有し得ると決定することができる。
【0054】
コントローラ(450)は、例えば、ビデオデータを符号化するためのパラメータとサブグループパラメータの設置を含む、ビデオ符号器(430)の符号化動作を管理することができる。
【0055】
エントロピー符号器(445)において、上記の全ての機能ユニットの出力に対してエントロピー符号化を行ってもよい。エントロピー符号器(445)は、例えばハフマン符号化、可変長符号化、算術符号化などの技術に従って、各機能ユニットによって生成されたシンボルに対して可逆圧縮を行うことにより、前記シンボルを、符号化されたビデオシーケンスに変換する。
【0056】
送信機(440)は、通信チャネル(460)を介した伝送の準備をするように、エントロピー符号器(445)によって作成された符号化されたビデオシーケンスをバッファリングすることができ、前記通信チャネルは、符号化されたビデオデータを記憶するストレージデバイスへのハードウェア/ソフトウェアリンクであってもよい。送信機(440)は、ソース符号器(430)からの符号化されたビデオデータを、伝送しようとする他のデータ、例えば、符号化されたオーディオデータ及び/又は補助データストリーム(ソースは図示せず)とともにマージしてもよい。
【0057】
コントローラ(450)は、符号器(203)の動作を管理することができる。コントローラ(450)は、符号化中に、各符号化されたピクチャに特定の符号化されたピクチャタイプを割り当ることができ、しかしながら、これは、対応するピクチャに適用し得る符号化技術に影響を与える可能性がある。例えば、通常、ピクチャは、イントラピクチャ(Iピクチャ)、予測ピクチャ(Pピクチャ)、又は双方向予測ピクチャ(Bピクチャ)として割り当てられ得る。
【0058】
イントラピクチャ(Iピクチャ)は、シーケンス内の任意の他のフレームを予測のソースとして使用せずに符号化及び復号化されるピクチャであってもよい。一部のビデオビデオコーデックは、例えば、独立復号器リフレッシュピクチャ(Independent Decoder Refresh、「IDR」)を含む異なるタイプのイントラピクチャを許容する。当業者は、Iピクチャの変形及びその対応する用途と特徴を知っている
【0059】
予測ピクチャ(Pピクチャ)は、イントラ予測又はインター予測を使用して符号化及び復号化を行うピクチャであってもよく、前記イントラ予測又はインター予測は多くとも1つの動きベクトル及び参照インデックスを使用して各ブロックのサンプル値を予測する。
【0060】
双方向予測ピクチャ(Bピクチャ)は、イントラ予測又はインター予測を使用して符号化及び復号化を行うピクチャであってもよく、当該イントラ予測又はインター予測は多くとも2つの動きベクトルと参照インデックスを使用して各ブロックのサンプル値を予測する。同様に、複数の予測ピクチャは、2つを超える参照画像及び関連するメタデータを単一のブロックの再構成に使用できる。
【0061】
ソースピクチャは一般的に、空間的に、複数のサンプルブロック(例えば、それぞれ4×4、8×8、4×8又は16×16サンプルのブロック)に細分化され、ブロックごとに符号化してもよい。これらのブロックは、他の(符号化された)ブロックを参照して予測的に符号化してもよく、ブロックに適用される対応するピクチャ符号化割り当てによって前記他のブロックを決定する。例えば、Iピクチャのブロックを非予測的に符号化してもよいし、前記ブロックは同じピクチャの符号化されたブロックを参照して予測的(空間的予測又はイントラ予測)に符号化してもよい。Pピクチャの画素ブロックは1つの以前に符号化された参照ピクチャを参照して空間的予測又は時間的予測を介して予測的に符号化してもよい。Bピクチャのブロックは1つ又は2つの以前に符号化された参照ピクチャを参照して、空間的予測又は時間的予測を介して予測的に符号化してもよい。
【0062】
ビデオ符号器(203)は、例えばITU-T H.265勧告書などの所定のビデオ符号化技術又は規格に基づき、符号化動作を実行することができる。ビデオ符号器(203)は、動作中に、ビデオ符号器(203)は、入力されたビデオシーケンスにおける時間的及び空間的冗長性による予測符号化動作を含む様々な圧縮動作を実行することができる。従って、符号化されたビデオデータは、使用されているビデオ符号化技術又は規格によって指定された構文に準拠し得る。
【0063】
いくつかの実施例では、送信機(440)は、符号化されたビデオとともに追加のデータを送信することができる。ソース符号器(430)は、そのようなデータを符号化されたビデオシーケンスの一部としてもよい。追加のデータには、時間的/空間的/SNR拡張層、冗長ピクチャ、スライスなどの他の形式の冗長データ、SEメッセージ、VUIパラメータセットセグメントなどを含んでもよい。
【0064】
以下、本出願で開示されたいくつかの実施例の態様を説明し、例えば、多用途ビデオ符号化(VVC)などのビデオコーデック技術又は規格では実現される高レベル構文アーキテクチャを含む。
【0065】
H.264のNALユニットの概念が有用であることが証明され、且つ少なくとも一部のシステム仕様(特定のファイルフォーマットを含む)が当該概念に依存するので、高レベル構文アーキテクチャはこの概念を含むことができる。
【0066】
任意選択で、高レベル構文アーキテクチャは(独立した、通常の)スライスの概念を含まなくてもよい。2003年(H.264バージョン1の発行日)以降、イントラ予測メカニズムの数及び効率がますます高まっているため、ビデオ符号化の進歩により、多くの場合、スライスによるエラー隠蔽は実際には不可能になる。同時に、符号化効率の観点から、これらの予測メカニズムは、場合によっては、スライスの使用が非常に多いリソースを占有してしまう。その結果、最近、スライスを使用して本来の目的(MTUサイズのマッチング)を実現するこはほとんどない。しかしながら、基本的に、低遅延、誤り耐性を必要とするすべてのアプリケーションは、例えば、イントラリフレッシュ、オープンGOP、不均一なベースレイヤー保護を有するスケーラビリティなどの、ピクチャに基づく誤り耐性ツールに依存している。
【0067】
スライスが削除される場合、エントロピーレベルで独立して復号化可能な(つまり、解析関連性がない)高レベルの構文アーキテクチャの最小のVCL構文ユニットは、例えば、タイル又は符号化されたピクチャであってもよい。
【0068】
タイルの独立した復号化は、特定のアプリケーションシナリオに有用であり得る。例えば、立方体マップを考える。空間の特定の視点から、不透明な立方体の3つの表面のみが同時に見える。したがって、所与の視点による表示ために、立方体マップを構成するコードピクチャのおそらくは6つある正方形タイルのうち3つだけを復号化すればよい。そのため、少なくとも独立したタイルを必要とするアプリケーションについて高レベル構文アーキテクチャでは、独立したタイルが基本的に独立したスライスを置き換えることができる。つまり、H.263+付属書Kにおけるいわゆる長方形スライスがスキャン順スライスを置き換える。動き制約タイルセットも、当該高レベル構文アーキテクチャの要件とすることもできる。
【0069】
ピクチャ内予測解メカニズムの一般的な概念は、仕様空間と実施空間の両方におけるパッチワークである。一実施例において、高レベル構文アーキテクチャは個別のフラグを含むことができる。予測メカニズムについて1つのフラグがあり、当該フラグは所定のタイルに対するデータの予測インポートを管理し、タイルヘッダー又はパラメータセット内に置かれる。従って、当該実現方式は、より優れた、より簡潔、より柔軟な解決であり得る。
【0070】
高レベル構文アーキテクチャを使用する一実施例において、使用されるプロファイルに基づいてタイリングを可能にする。例えば、ストレートな並列化をサポートする非常に基本的なタイリングメカニズムは、全てのプロファイルの一部としてもよい。また、特定のプロファイルに対してのみより高レベルの技術を指定できる。例えば、立方体マップを使用する360°プロファイルは、当該アプリケーションのためにカスタマイズされた動き制約付きの独立したタイル、即ち、例えば、3×2配置やクロス配置などの特定の方法で配置できる6つのタイルを使用することを許可することができる。他のプロファイルは、他の投影フォーマットに適用することができる。例えば、二十面体のタイプの投影はより多くのタイル、又は投影の形状に理想的に対応する他の類似する予測解メカニズムを必要とする可能性がある。
【0071】
特別なアプリケーションによって引き起こされる上記の要件に加えて、符号化されたピクチャは予測を分解する最小ユニットとなる。符号化されたピクチャが予測を分解する最小ユニットである場合、全てのピクチャ内予測メカニズムは分解されず、ピクチャ間予測メカニズムのみ分解される。例えば、特定の古いビデオ符号化規格の特定のメタデータの動き補償及びピクチャ間予測は分解される可能性がある。スライス/タイルがない符号化されたピクチャを効率的にサポートするために、一実施例における高レベル構文アーキテクチャは、構文要素を担持するピクチャヘッダーを含むことができ、当該構文要素はH.264/H.265においてスライスヘッダーに配置されるが、ピクチャ全体に関連する。一つのそのような構文要素は、ピクチャパラメータセット(PPS)への参照であってもよい。以前にスライスヘッダーで提供されたように、ピクチャヘッダーは、それに関するピクチャのみに関連、その後のピクチャに関連ない。言い換えれば、ピクチャヘッダーのコンテンツは一時的なものであり、また、ピクチャヘッダー間予測が存在しない(さもなければ、ピクチャに基づく誤り耐性であっても機能しない)。
【0072】
誤り耐性の側面を無視し、ピクチャヘッダーは、ピクチャの最初の(又は、唯一の)タイルに含まれるか、又はそ自体のVCLのNALユニット含まれることができる。前者はより効率的であり、後者は構造がより簡潔である。
【0073】
一実施例において、高レベル構文アーキテクチャは、構文(個々のNALユニット)、及び機能と持続性の範囲の両方について従来のアーキテクチャで提供されるようなピクチャパラメータセット(PPS)及びシーケンスパラメータセット(SPS)を含んでもよい。
【0074】
SPSの上に、高レベル構文アーキテクチャは、フラグ、サブプロファイルなどを含めるために、復号器パラメータセット(DPS)を含むことができる。エンドオブストリームNALユニットが受信されるまで、ビデオストリームの存続期間中、DPSのコンテンツが一定でること確保されることができる。
【0075】
高レベル構文アーキテクチャを使用する一実施例において、エンドオブストリームNALユニットが外部に含まれることを許可する必要があり得る。例えば、SIPのre-inviteがストリームの基本パラメータを変更した(そして復号システムによって確認された)場合、異なるDPSが現れることを復号システムの復号器に通知する必要がある。当該情報を復号器に提供する唯一の方法が、それをビットストリームに入れることであると、スタートコードのエミュレーション防止などによって、欠陥を引き起こす。また、特定のタイムアウトシナリオにおいて、ビットストリームに当該情報を入れても実際に機能しない。
【0076】
多くの場合、パケットネットワーク上で符号化されたピクチャを伝送する場合に、符号化されたピクチャは、最大伝送ユニット(MTU)のサイズよりも大きい。不必要な予測分解〔ブレーク〕を導入すると符号化効率が低下するため(なにしろ、完全にスライスをなくしたのはまさに符号化効率のためであった)、タイルに依存しないことが好ましい。タイルに依存することが好ましくないまたの理由は、タイルが、並列化及びアプリケーション固有のタイリングという2つの潜在的に矛盾する機能を有するためである。仕様空間のビデオコーデックの内部にフラグメンテーションメカニズムが必要かどうかは、どちらの側面でも正当化できる。ビデオコーデックにフラグメンテーションメカニズムが必要な場合、高レベル構文アーキテクチャのある実施例は、例えば、まさにそのものであるH.265の「依存スライス」を使用すればよい。又は、高レベル構文アーキテクチャにおける上位層でフラグメンテーションを提供してもよい。なお、H.26xビデオの多くのRTPペイロードフォーマットは、符号器によるMTUサイズマッチング(ゲートウェイがコード変換を行わないゲートウェイシナリオで使用される)のためスライスへの依存に加えて、ある形式のフラグメンテーションが確実に含まれる。
【0077】
図5を参照して、以上の説明を考慮して、一実施例において、高レベル構文アーキテクチャの構文階層(501)は、基本的に次のようになる。
【0078】
構文階層は、セッションの存続期間中に不変のままである復号器パラメータセット(DPS)(502)を含むことができる。
【0079】
いくつかの実施例において、構文階層は、スケーラブルな層を連結するためのビデオパラメータセット(VPS)(503)を含むことができ、当該ビデオパラメータセットは層の境界を横切るIDRで中断する。
【0080】
構文階層は、機能が実質的にH.265に類似しているシーケンスパラメータセット(SPS)(504)を含むことができ、範囲は符号化されたビデオシーケンスである。
【0081】
構文階層は、同じセマンティック層にあり且つ類似する範囲を有するピクチャパラメータセット(PPS)(505)、及びピクチャヘッダー(PH)(506)を含むことができる。つまり、ピクチャパラメータセット(505)及びピクチャヘッダー(506)は全ての符号化されたピクチャをカバーしてもよいし、符号化されたピクチャの間で変化してもよい。機能の点で、ピクチャパラメータセット(505)はH.265に基本的に類似してもよく、その範囲は符号化されたピクチャである。ピクチャヘッダー(506)は、ピクチャの間で変化する可能性のあるピクチャ定数データを含んでもよく、さらに、ピクチャパラメータセット(505)への参照を含んでもよい。
【0082】
いくつかの実施例において、タイルを必要とする適用シナリオの場合、構文階層はタイルヘッダー(507)を含むことができる。
【0083】
いくつかの実施例において、構文階層は、例えば、依存スライスヘッダーであり得る断片化〔フラグメンテーション〕ユニットヘッダー(508)を含むことができる。
【0084】
構文階層は、符号化ユニット(CU)データを含む符号化されたピクチャのVCLデータ(509)を含むことができる。
【0085】
上記の様々な構文要素及び構文レベルのインタラクションの各態様について、より詳細に以下に説明する。
【0086】
ピクチャヘッダー/ピクチャパラメータセットのインタラクション
【0087】
図6を参照し、本出願の実施例に関連して、ピクチャヘッダー(Picture Header、PH)(601)及びピクチャパラメータセット(Picture Parameter Set、PPS)(602)のインタラクションを以下に説明する。ここで、ピクチャヘッダー(601)とピクチャパラメータセット(602)の両方は、シンタックスにおける同じ構文レベルにあり、例えば符号化されたピクチャのVCLデータ(509)である。
【0088】
図6を参照して、PH(601)及びPPS(602)の両方は、特定の名前付き構文要素を含むことができる。図6に示すように、一実施例において、PH(601)及びPPS(602)を含むことができ、その両方はいずれも4つの構文要素を含む。しかしながら、PH(601)及びPPS(602)は、例えば、任意のサイズを有し得、異なるサイズを有し得、任意の要素を含み得るなどと理解され得る。これらの構文要素の1つはPH_pps_id(603)であり、それがPH(601)のうちPPS(602)への参照であってもよい。当該構文要素のセマンティックは、古いビデオ符号化規格のスライスヘッダーにおけるpps_idのセマンティックに相当し、即ち、状況に応じて、PPS、及び、例えばSPS、VPS、DPSなどの任意のダウンストリームの上位層のパラメータセットをアクティブ化する。PPS(602)において、PPS_pps_id(604)は、自己参照であってもよいし、受信するときにPPSのID識別であってもよい。ピクチャパラメータセットの識別は構文要素の例であり、その中、いくつかの場合に、PH(601)及びPPS(602)の対応する構文要素の値は、適用する各ビットストリームについて同じでなければならない。
【0089】
ある構文要素は、PH(601)のみに存在するがPPS(602)に存在しない場合がある。少なくともいくつかの場合、これらの構文要素は、PH(601)に当該構文要素が含まれるピクチャに属してもよく、これらの構文要素は、ピクチャの間で変化する可能性がある。基本的に、新しいピクチャを復号化するたびに、新しいPPS(602)をアクティブ化する必要があるので、これらの構文要素をパラメータセット、例えばPPS(602)に入れることで、効率が低下する可能性がある。これらの構文要素の一例は、現在に処理されているピクチャの識別情報、例えば、時間参照、ピクチャ順序番号などであってもよい。例えば、PH(601)はPOC(605)を含んでもよい。PPS(602)における対応するエントリは、ピクチャタイプに使用されるpic_type(606)とマークされ、それはPPS(602)のみに存在するがPH(601)に存在しない構文要素の例である。従って、PPS(602)がアクティブ化されたピクチャのすべてについて、pic_type(606)の値を使用する。
【0090】
ある構文要素は、PPS(602)のみに存在するが、PH(601)に存在しない場合がある。このようなカテゴリには、より大きい構文要素のほとんどがあり得、これらの構文要素は、複数の符号化されたピクチャに関連付けられるが符号化されたビデオシーケンスの全体に適用しない可能性があるか、可能性が高いことが理解される。このような構文要素はピクチャ間で変化する可能性が低いため、異なるPPS(602)をアクティブ化すると負担にならない場合、このような構文要素はPPS(602)に存在するがPH(601)に存在しない場合もある。例えば、スケーリングマトリックスなどの、複雑で潜在的に大きなデータセットを考慮すると、当該データセットは、いくつかの(全部でもよい)変換係数が量子化パラメータを個別に選択することを許可することができる。そのようなデータは、所定のピクチャタイプ(例えばIピクチャ、Pピクチャ及びBピクチャ)内の典型的なピクチャグループ(GOP)の過程で変化することはほとんどない。スケーリングリスト情報をPHに配置すると、PHが本質的に一時的なものであるので、各符号化されたピクチャで同じスケーリングリストを繰り返して伝送する必要があるという欠点がある。
【0091】
しかしながら、第3種類の構文要素が存在し得る。このような構文要素は、例えばpps_foo(608)及びph_foo(607)などの、類似する名前を有してもよく、且つ、PPS(602)及びPH(601)にはこのような構文要素が存在し得る。これらの構文要素の間の関係は、ビデオ技術又は規格では構文要素の性質によって定義されてもよいし、構文要素によって異なってもよい。
【0092】
例えば、同一又は別の実施例では、いくつかの他の場合に、例えばph_foo(607)の値などのPH(601)における構文要素の値は、PPS(602)における、名前が類似し且つセマンティックが結合された構文要素の値、例えばpps_foo(608)の値を上書きすることができる。
【0093】
同一又は別の実施例では、いくつかの他の場合に、例えばph_bar(609)などの、PH(601)における別の構文要素の値は、PPS(602)における、名前(ここで、「bar」)が類似し且つセマンティックが結合された構文要素、例えばpps_bar(610)を、ある形式の予測値として使用する。例えば、いくつかの場合に、PHに基づく構文要素ph_bar(609)を、PPS(602)における名前が類似し且つセマンティックが結合された構文要素pps_bar(610)に重畳することができ、前記PPS(602)における名前が類似し且つセマンティックが結合された構文要素pps_bar(610)からPHに基づく構文要素ph_bar(609)などを減算することができる。
【0094】
復号器パラメータセット及びビットストリーム終止
【0095】
復号器パラメータセット(DPS)(502)は、MPEG-2のシーケンスヘッダーに非常に類似するが、パラメータセットである。そのため、DPS(502)は、MPEG-2シーケンスヘッダーと異なり、本質的に一時的なものではない。アクティブ化時間は、それぞれパラメータセット又はヘッダーの復号化時間と異なる場合があるため、あるアクティブ化ルールは、例えば、MPEG-2シーケンスヘッダーと異なるパラメータセットなどの、ヘッダーと異なるパラメータセットに適用されることができる。この重要な違いを考慮すると、SPSは、MPEG-2のGOPヘッダーに類似し、DPSは、MPEG-2のシーケンスヘッダーに類似してもよい。
【0096】
DPS(502)の範囲は、H.265におけるいわゆるビデオビットストリームであってもよい。ビデオビットストリームは、多くの復号化されたビデオシーケンス(CVS)を含んでもよい。H.264及びH.265には、範囲が所定のCVSを超える特定の要素が存在し、その中に、最初にHRDパラメータである。仕様空間において、H.264及びH.265は、CVSレベルを超えるパラメータをSPSに配置し、各符号化されたビデオシーケンスにおいてアクティブ化されたSPS間で関連情報を一定に保つことを要求することにより、これらのパラメータを処理する。本出願の実施例のDPSは、これらの構文要素を多くのCVSに対して既知で一定であり得る構造に蓄積する。
【0097】
これまで説明されない1つの態様は、所定の時点で異なるDPSを必要とするパラメータセットを受信する準備ができていなければならないように復号器に信号で通知する方法である。当該パラメータセットは、例えば、定数パラメータを変更する必要のあるDPS又はSPSであってもよい。
【0098】
H.264とH.265の両方はエンドオブストリーム(EOS)NALユニットを含むが、NALユニットは、少なくとも部分的には、後述する構造上の欠点のため、頻繁に使用されない可能性がある。
【0099】
H.264及びH.265において、EOSは、パラメータセットなどの他のいくつかのNALユニットタイプと異なり、符号化されたビデオビットストリームで伝送される必要があり、その位置は、明確に限定される制約を有する。例えば、H.264又はH.265において、EOSは、符号化されたピクチャのVCLのNALユニット内に配置されることができない。実際に、符号化されたビデオビットストリームにおける適切な位置にEOS NALユニットを挿入するために、符号器の協力、又は(少なくとも)ビデオ符号化規格の高レベル構文制約を知る別のエンティティの協力が必要である。少なくともいくつかのシナリオにおいて、このような協力は不実用である。例えば、図1の通信システムを参照し、受信端末がネットワークカバーからドロップし、且つ当該端末が符号化されたピクチャに属するNALユニットを受信している最中であると仮定すると、符号器は、復号器に接続されていないため、復号器にEOS NALユニットを提供できない。符号化されたピクチャのNALユニットを受信している際に接続が切断され、EOS NALユニットのステッチングも受信機で実行できないため、EOSを符号化されたピクチャのNALユニットの間に配置することができない。実際の応用では、受信端末は、その復号器を既知の新しい状態にリセットすることができるが、当該動作には数秒かかる場合がある。これは、提示されたシナリオにとって許容できるかもしれいが、復号器のより速くより明確な反応が必要になる可能性がある他のシナリオが存在する可能性がある。
【0100】
本出願で開示された同一又は別の実施例では、EOSは、(例えば、H.264/H.265のように)ビデオストリームの一部として受信されるか、又は帯域外で受信されることができる。
【0101】
図7を参照して、同一又は別の実施例では、EOS(701)を帯域外で受信してEOSを処理する場合に、復号器は、ビデオストリームのアクティブ化された復号器パラメータセットを非アクティブ化することができる。アクティブ化された復号器パラメータセット(DPS)の非アクティブ化は、構文の競合なしに別の異なるDPSをアクティブ化することができることを意味し、当該異なるDPSの少なくとも1つの値は、以前にアクティブ化されたDPSと異なる。
【0102】
例えば、アクティブ化されたDPSを非アクティブ化することは、復号器がすぐそのバッファ(702)をフラッシュして、再構築されるピクチャ(703)の出力を停止することを含むことができる。以前にアクティブ化されたDPSを非アクティブ化した後に、復号器は、新しいビデオストリームを受信する準備をすることができ(704)、ここで、新しいビデオストリームは、以前のDPSよりも異なるDPSコンテンツを有してもよい。そして、復号器は、以前のDPS又は新しいDPSをアクティブ化(任意選択で、復号化及びアクティブ化)することで、新しいビデオストリームの復号化を開始し(705)、新しいDPSは以前のDPSと異ってもよい。いつでも、帯域外でEOSを受信する前でも、新しいDPSを受信及び復号化することができる。例えば、パラメータセットの場合と同様に、パラメータセットがアクティブ化される際に存在する限り、パラメータセットを受信及び復号化する時間は、復号化のプロセスとは無関係である。次に、新しいDPSに基づき新しいCVSを復号化することを開始することができる(706)。
【0103】
上記の技術はコンピュータ可読命令を使用してコンピュータソフトウェアとして実現され、1つ以上のコンピュータ可読媒体に物理的に記憶されてもよい。例えば、図8は、本出願で開示された主題のいくつかの実施例を実現するのに適したコンピュータシステム(800)を示す。
【0104】
コンピュータソフトウェアは、任意の適切なマシンコード又はコンピュータ言語によって符号化することができ、任意の適切なマシンコード又はコンピュータ言語に対して、アセンブル、コンパイル、リンクなどのメカニズムを実行することで、コンピュータ中央処理ユニット(CPU)、グラフィック処理ユニット(GPU)などによって直接的に実行されるか、又は解釈、マイクロコードなどによって実行される命令を含むコードを作成することができる。
【0105】
命令は、例えばパーソナルコンピュータ、タブレットコンピュータ、サーバ、スマートフォン、ゲーム機器、モノのインターネット機器などを含む、様々なタイプのコンピュータ又はそれらのコンポーネントで実行されることができる。
【0106】
図8に示すコンピュータシステム(800)のコンポーネントは、本質的に例示であり、本開示の実施形態を実現するためのコンピュータソフトウェアの使用範囲又は機能に制限を加えることを意図するものではない。コンポーネントの配置は、コンピュータシステム(800)の例示的な実施形態に示めされたるコンポーネントのいずれか、又はそれらの組み合わせに関連する依存性又は要件を有するものとして解釈されるべきではない。
【0107】
コンピュータシステム(800)はいくつかのヒューマンマシンインターフェス入力機器を含んでもよい。このようなヒューマンマシンインターフェス入力機器は、例えば触覚入力(例えば:キーストローク、スライド、データグローブ移動)、オーディオ入力(例えば:声手をたたく音)、視覚入力(例えば:姿勢)、嗅覚入力(図示せず)などの1つ又は複数の人間ユーザによる入力に応答することができる。ヒューマンマシンインタフェース機器はさらに、例えば、オーディオ(例えば、音声、音楽、環境音)、画像(例えば、スキャンした画像、静的画像撮影装置から取得された写真画像)、ビデオ(例えば2次元ビデオ、ステレオビデオが含まれる3次元ビデオ)などの、人間の意識的な入力に必ずしも直接関連しない特定のメディアをキャプチャするために使用されることもできる。
【0108】
入力ヒューマンマシンインタフェース機器は、キーボード(801)、マウス(802)、タッチパッド(803)、タッチパネル(810)、データグローブ(図示せず)、ジョイスティック(805)、マイク(806)、スキャナ(807)、撮影装置(808)のうちの1つ又は複数を含んでもよい(それぞれが1つのみ図示される)。
【0109】
コンピュータシステム(800)はさらにヒューマンマシンインタフェース出力機器を含んでもよい。このようなヒューマンマシンインタフェース出力機器は、例えば触覚出力、音、光及び匂い/味を介して1つ又は複数の人間ユーザの感覚を刺激することができる。当該ヒューマンマシンインタフェース出力機器は、触出力機器(例えば、タッチパネル(810)、データグローブ(図示せず)又はジョイスティック(805)による触覚フィードバックを使用するが、入力機器として機能しない触覚フィードバック機器を使用してもよい)、オーディオ出力機器(例えば、スピーカー(809)、ヘッドフォン(図示せず))、視覚出力機器(例えば、スクリーン(810)、CRTスクリーン、LCDスクリーン、プラズマスクリーン、OLEDスクリーンを含み、各スクリーンはタッチパネル入力能力、触覚フィードバック能力を有してもよく、有しなくてもよく、そのうちのいくつかは、立体画像出力のような手段で、2次元の視覚出力又は3次元以上の出力を出力し、バーチャルリアリティ眼鏡(図示せず)、ホログラフィックディスプレイ及びスモークタンク(図示せず)がある)、プリンター(図示せず)を含む。
【0110】
コンピュータシステム(800)はさらに人間がアクセスし得る記憶機器及びその関連する媒体を含んでもよく、例えば、CD/DVDなどの媒体(821)を有するCD/DVD ROM/RW(820)などの光学媒体、サムドライブ(822)、取り外し可能なハードドライブ又はソリッドステートドライブ(823)、磁気テープとフロッピーディスク(図示せず)のような従来の磁気媒体、例えばドングル(図示せず)などの、専用ROM/ASIC/PLDに基づく機器を含む。
【0111】
当業者は、本出願で開示された主題に関連して使用される用語「コンピュータ可読媒体」には伝送媒体、搬送波又は他の瞬間信号が含まれないことを理解できる。
【0112】
コンピュータシステム(800)はさらに、1つ又は複数の通信ネットワークへのインタフェースを含んでもよい。ネットワークは、例えば無線、有線接続、光学的ネットワークであってもよい。ネットワークは、ローカルエリアネットワーク、広域ネットワーク、メトロポリタンネットワーク、車両工業ネットワーク、リアルタイムネットワーク、遅延耐性ネットワークなどであってもよい。ネットワークの例は、イーサネットのようなローカルエリアネットワーク、無線LAN、GSM、3G、4G、5G、LTEなどが含まれるセルラーネットワーク、有線テレビ、衛星テレビ及び地上波テレビが含まれるテレビ有線又は無線広域デジタルネットワーク、CANBusが含まれる車両工業ネットワークなどを含む。一部のネットワークは一般的に、ある汎用データポート又は周辺バス(849)(例えば、コンピュータシステム(800)のUSBポート)に接続される外部ネットワークインタフェースアダプタを必要とし、他のネットワークは一般的に、下記の形式でシステムバスに接続されて、コンピュータシステム(800)のコアに集積される(例えば、イーサネットインタフェースを介してPCコンピュータシステムに集積されるか、又はセルラーネットワークインタフェースを介してスマートフォンコンピュータシステムに集積される)。コンピュータシステム(800)は、これらのネットワークのいずれかを介して、他のエンティティと通信することができる。このような通信は、一方向受信のみ(例えば、放送テレビ)、一方向送信のみ(例えば、CANバスからあるCANbus機器へ)、又は双方向(例えば、ローカルエリア又は広域デジタルネットワークを介して他のコンピュータシステムへ)である。上記の各ネットワーク及びネットワークインタフェースに、特定のプロトコル及びプロトコルスタックを利用することができる。
【0113】
上記のヒューマンマシンインタフェース機器、人間がアクセスし得る記憶機器及びネットワークインタフェースは、コンピュータシステム(800)のコア(840)に接続されることができる。
【0114】
コア(840)は、1つ又は複数の中央処理ユニット(CPU)(841)、グラフィック処理ユニット(GPU)(842)、フィールドプログラム可能なゲートアレイ(FPGA)(843)という形式の専用のプログラム可能な処理ユニット、あるタスクのためのハードウェアアクセラレータ(844)などを含んでもよい。これらの機器は、読み取り専用メモリ(ROM)(845)、ランダムアクセスメモリ(846)、内部のユーザがアクセスできないハードディスクドライブ、SSDなどのような内部大容量記憶装置(847)とともに、システムバス(848)を介して接続されてもよい。あるコンピュータシステムにおいて、1つ又は複数の物理プラグという形式で、システムバス(848)にアクセスすることで、別のCPU、GPUなどによって拡張を実現することができる。周囲機器は直接的又は周辺バス(849)を介してコアのシステムバス(848)に接続される。周辺バスのアーキテクチャはPCI、USBなどを含む。
【0115】
CPU(841)、GPU(842)、FPGA(843)及びアクセラレータ(844)はいくつかの命令を実行することができ、これらの命令を組み合わせると、以上に言及されたコンピュータコードを構成することができる。当該コンピュータコードはROM(845)又はRAM(846)に記憶される。一時的なデータはRAM(846)に記憶されてもよく、永久データは、例えば内部大容量記憶装置(847)に記憶されてもよい。キャッシュメモリを使用することによって、記憶装置のいずれかへの高速ストレージ及び検索が可能になり、当該キャッシュメモリは1つ又は複数のCPU(841)、GPU(842)、大容量記憶装置(847)、ROM(845)、RAM(846)などに密接に関連することができる。
【0116】
コンピュータ可読媒体は、コンピュータが実現する様々な操作を実行するためのコンピュータコードを有する。媒体とコンピュータコードは、本出願の開示の目的のために、特別に設計及び構築される媒体とコンピュータコードであってもよいし、又は、コンピュータソフトウェアの当業者にとって周知であり、使用可能なタイプのものであってもよい。
【0117】
限定ではなく例示として、(1つ又は複数)プロセッサ(CPU、GPU、FPGA、アクセラレータなどを含む)が1つ又は複数の有形コンピュータ可読媒体に含まれるソフトウェアを実行することで、アーキテクチャ(800)を有するコンピュータシステム、特にコア(840)は、機能を提供することができる。このようなコンピュータ可読媒体は、以上に紹介された、ユーザがアクセスし得る大容量記憶装置に関連する媒体、及びコア内部大容量記憶装置(847)又はROM(845)のような非一時的な性質であるコア(840)の特定の記憶装置であってもよい。本出願で開示された各実施例を実現するためのソフトウェアはこのような機器に記憶され、コア(840)によって実行される。特定のニーズに応じて、コンピュータ可読媒体には1つ又は複数の記憶機器又はチップが含まれてもよい。ソフトウェアはコア(840)、特にそのうちのプロセッサ(CPU、GPU、FPGAなどが含まれる)に、本明細書で説明される特定のプロセス又は特定のプロセスの特定部分を実行させ、RAM(846)に記憶されるデータ構成を定義することと、ソフトウェアによって定義されるプロセスに基づき、このようなデータ構成を修正することとが含まれる。また或いは代わりとして、コンピュータシステムは、ロジックハードワイヤード又は他の形式で回路(例えば、アクセラレータ(844))に実装されることで機能を提供し、当該回路は、ソフトウェアの代わりとして、又はソフトウェアとともに動作することで、本明細書で説明される特定のプロセス又は特定のプロセスの特定部分を実行することができる。適切な場合、言及されたソフトウェアにはロジックが含まれ、逆に、言及されたロジックにはソフトウェアが含まれてもよい。適切な場合、言及されたコンピュータ可読媒体には、実行されるソフトウェアが記憶される回路(例えば、集積回路(IC))、実行されるロジックを含む回路、或いはその両方が含まれてもよい。本出願の開示にはハードウェアとソフトウェアの任意の適切な組み合わせが含まれる。
【0118】
本出願は、いくつかの例示的な実施例を既に説明したが、本出願で開示された範囲内にある変更、置き換え及び様々代替の均等物が存在する。従って、当業者は、様々なシステム及び方法を思い付くことができ、これらのシステム及び方法は、本明細書では明示的に示されていないか又は記載されていないが、本出願で開示された原理を具体化したので、その精神及び範囲内にあることは理解できる。
図1
図2
図3
図4
図5
図6
図7
図8