JP7139517B2 - デコーダが実行するメディアの復号方法、メディア復号化のためのデバイス、及びコンピュータプログラム - Google Patents

デコーダが実行するメディアの復号方法、メディア復号化のためのデバイス、及びコンピュータプログラム Download PDF

Info

Publication number
JP7139517B2
JP7139517B2 JP2021512373A JP2021512373A JP7139517B2 JP 7139517 B2 JP7139517 B2 JP 7139517B2 JP 2021512373 A JP2021512373 A JP 2021512373A JP 2021512373 A JP2021512373 A JP 2021512373A JP 7139517 B2 JP7139517 B2 JP 7139517B2
Authority
JP
Japan
Prior art keywords
video sequence
indication
encoded video
sub
decoder
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2021512373A
Other languages
English (en)
Other versions
JP2021521756A (ja
Inventor
ウェンジャー,ステファン
リィウ,シャン
Original Assignee
テンセント・アメリカ・エルエルシー
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by テンセント・アメリカ・エルエルシー filed Critical テンセント・アメリカ・エルエルシー
Publication of JP2021521756A publication Critical patent/JP2021521756A/ja
Application granted granted Critical
Publication of JP7139517B2 publication Critical patent/JP7139517B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80Responding to QoS
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/61Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/70Media network packetisation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/2866Architectures; Arrangements
    • H04L67/30Profiles
    • H04L67/303Terminal profiles
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/132Sampling, masking or truncation of coding units, e.g. adaptive resampling, frame skipping, frame interpolation or high-frequency transform coefficient masking
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/156Availability of hardware or computational resources, e.g. encoding based on power-saving criteria
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/162User input
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/184Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being bits, e.g. of the compressed video stream
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/44Decoders specially adapted therefor, e.g. video decoders which are asymmetric with respect to the encoder
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/46Embedding additional information in the video signal during the compression process
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/70Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by syntax aspects related to video coding, e.g. related to compression standards
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/90Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using coding techniques not provided for in groups H04N19/10-H04N19/85, e.g. fractals
    • H04N19/91Entropy coding, e.g. variable length coding [VLC] or arithmetic coding
    • HELECTRICITY
    • H03ELECTRONIC CIRCUITRY
    • H03MCODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M7/00Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
    • H03M7/30Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
    • H03M7/40Conversion to or from variable length codes, e.g. Shannon-Fano code, Huffman code, Morse code
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/12Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)

Description

開示されている対象は、メディア符号化及び復号化に、より具体的には、ビットストリーム内のプロファイル、サブプロファイル、ティア、又はレベルなどの複数のコンフォーマンスポイントの表現に関係がある。
動き補償を伴ったインターピクチャ予測を用いるビデオ符号化及び復号化は、数十年にわたって知られている。無圧縮デジタルビデオは、ピクチャの連続から成ることができ、各ピクチャは、例えば、1920×1080の輝度サンプル及び関連する色度サンプルの空間次元を有している。ピクチャの連続は、例えば、毎秒60ピクチャ、すなわち60Hzの固定又は可変のピクチャレート(俗に、フレームレートとして知られる)を有することができる。無圧縮ビデオは、重要なビットレート要件を有している。例えば、8ビット/サンプルでの1080p60 4:2:0ビデオ(60Hzフレームレートでの1920×1080輝度サンプル解像度)は、1.5Gbit/sバンド幅に近い必要がある。そのようなビデオの1時間は、60GBよりも大きい記憶空間を必要とする。
ビデオ符号化及び復号化の1つの目的は、圧縮による入力ビデオ信号の冗長性の低減であることができる。圧縮は、いくつかの場合に2桁以上、上記のバンド幅又は記憶空間要件を低減することを助け得る。可逆及び不可逆の両方の圧縮並びにそれらの組み合わせが用いられ得る。可逆圧縮は、原信号の正確なコピーが、圧縮された原信号から再構成され得る技術を指す。不可逆圧縮を使用する場合に、再構成された信号は、原信号と同一でないことがあるが、原信号と再構成された信号との間の歪みは、再構成された信号を意図された用途にとって有用なものとするほど十分に小さい。ビデオの場合には、不可逆圧縮が広く用いられている。受け入れられる歪みの量は用途に依存する。例えば、特定の消費者ストリーミング用途のユーザは、テレビジョン投稿用途のユーザよりも高い歪みを許容し得る。達成可能な圧縮比は、より高い許容可能な/受け入れ可能な歪みがより高い圧縮比をもたらし得ることを反映することができる。
ビデオエンコーダ及びデコーダは、例えば、動き補償、変換、量子化、及びエントロピ符号化を含むいくつかの広いカテゴリからの技術を利用することができる。それらの技術のうちのいくつかは、以下で紹介される。
デコーダ又は基礎をなすシステムが、所与の符号化されたメディアビットストリームが復号可能であるかどうかを判定することを助けるために、更には、ケイパビリティネゴシエーション(capability negotiation)などのタスクを支援するために、コンフォーマンスポイント(conformance points)が導入されている。例えば、MPEG及び同様の標準規格において、プロファイルは、ビットストリームに存在する可能性があるツールの集合の中の定義されたサブセットを示し得る。例えば、H.264において、ベースラインプロファイルは、インターレース符号化に関連したツールを含まず、一方で、メインプロファイルは、そのようなツールを含む。同様に、レベルは、ビットストリームの複雑さの上限を示し得る。同様に、ティアは、所与の標準規格のビットストリームの複雑さ(所与の時間-空間分解能についての最大ビットレート)を示し得る。
2003年頃までに、標準規格は、オニオン形(onion-shaped)をしたプロファイルをしばしば導入した。レベル及びティアは、今日でさえオニオン形として定義されている。ここで、オニオン形は、“より低い”プロファイル(なお、通常は、数値的により低いプロファイルインジケータ値によって常には示されない)のために定義された全てのツールがより高いプロファイルに含まれたことを暗示する。図1を参照すると、ベースラインプロファイル(101)は、小さい円として示されており、メインプロファイル(102)を示すより大きい円によって完全に囲まれている。この図は、ベースラインプロファイル(101)の全てのツールがやはりメインプロファイル(102)に含まれていることを表す。ベースラインプロファイルは、0のプロファイルIDによって表され、メインプロファイルは、1のプロファイルIDによって表されるとする。結果として、ビデオビットストリームにおいて符号化されているプロファイルIDの単一値を、デコーダ又は基礎をなすシステムが復号化することができるプロファイルIDと比較することは、プロファイル視点から所与のビットストリームが復号可能であるかどうか否かを定めるのに十分であった。例えば、デコーダがメインプロファイル(ID=1を有する)を復号することができた場合に、次いで、ID=0を有するベースラインプロファイルにさらされるとき、デコーダは、ビットストリームを復号することができる。レベルは、処理要件(例えば、サンプル/秒)及びメモリ要件(例えば、ピクチャ内の最大サンプル数、ビット深さ、など)の組み合わせにおいてしばしば測定される、ビットストリームの複雑さの更なる次元を提供する。MPEG標準規格におけるレベルは、一般に、オニオン形である。所与のビットストリームを復号するために、ビットストリームのプロファイル及びレベルの両方が、デコーダのプロファイル及びレベル以下である必要がある。
2003年のH.264の最終決定によれば、オニオン形でないプロファイルが導入された。例えば、H.264の(制約なし)ベースラインは、フレキシブル・マクロブロック・オーダリング(Flexible Macroblock Ordering,FMO)(202)として知られているツールを含み、一方、メインプロファイル(203)はそのツールを含まない。同様に、メインプロファイルは、インターレース符号化をサポートするためのツールを含むが、そのツールはベースラインプロファイルには含まれていない。多数の他のツールは、両方のプロファイルに共通である(205)。H.264は、ビットストリームがベースライン及びメインの両方のプロファイルと互換性があることを示すことを可能にしたメカニズムを当初含んでいなかった。これは、ベースラインプロファイル及びメインプロファイルの両方のアプリケーション空間が別種と見なされるということで、問題と考えられなかった。
H.265では、おおよそ2013年頃に、非重複プロファイルが作られた。ここで、しかしながら、標準委員会は、複数のプロファイルとの互換性の指示が望ましいと決定した。実装された解決法は、とり得るプロファイルの有限かつ小さい番号空間(H.265の場合に32)に依存する。好ましいプロファイルは、5ビット整数によって示される。残りの31個のプロファイルとの互換性は、32ビットマスクにより示され得る。その場合に、各ビットは、そのように番号付けされたプロファイルとの互換性を示す。
バーサタイル・ビデオ・コーディング(Versatile Video Coding)、すなわちVVCとして一応知られている新しいビデオ符号化標準が検討中である。VVCは、特定の市場実態を反映するようにユーザ定義のプロファイル又はサブプロファイルをサポートすることが見込まれている。いくつのプロファイル及びサブプロファイルをユーザが作る可能性があるかは、はじめから明らかではないので、数百、数千、又はそれ以上のプロファイル及び/又はサブプロファイルをサポートする必要性が存在し得る。更に、ユーザ定義のプロファイルのための軽快な登録メカニズムが望ましいということで、ユーザ定義のプロファイル及び/又はサブプロファイルのための広い番号空間も望ましい。そのため、ビットマスクによる複数のプロファイル互換性の表現は実際的ではない。同様の考えは、レベル又はティアなどの他のコンフォーマンスポイントにも当てはまり得る。更に、特定の環境で、プロファイル及びサブプロファイルなどの、同じビットストリーム内の異なるカテゴリの複数のコンフォーマンスポイントとの互換性を表すことが必要であることがある。
本開示の態様に従って、デコーダによるメディア復号化のための方法は、符号化されたビデオシーケンスの第1コンフォーマンスポイントを示す第1指示を復号するステップと、符号化されたビデオシーケンスの第2コンフォーマンスポイントを示す第2指示を復号するステップと、第1コンフォーマンスポイント及び第2コンフォーマンスポイントのうちの少なくとも1つに基づいて、符号化されたビデオシーケンスがデコーダによって復号可能であるかどうかを判定するステップと、符号化されたビデオシーケンスがデコーダによって復号可能であるかどうかの判定に基づいて、符号化されたビデオシーケンスを選択的に復号するステップとを含む。
本開示の態様に従って、メディア復号化のためのデバイスは、プログラムコードを記憶するよう構成される少なくとも1つのメモリと、プログラムコードを読み出し、プログラムコードによって指示されるように動作するよう構成される少なくとも1つのプロセッサとを含み、プログラムコードは、少なくとも1つのプロセッサに、符号化されたビデオシーケンスの第1コンフォーマンスポイントを示す第1指示を復号させ、符号化されたビデオシーケンスの第2コンフォーマンスポイントを示す第2指示を復号させるよう構成される復号化コードと、少なくとも1つのプロセッサに、第1指示及び第2指示のうちの少なくとも1つに基づいて、符号化されたビデオシーケンスがデコーダによって復号可能であるかどうかを判定させるよう構成される判定コードと、少なくとも1つのプロセッサに、符号化されたビデオシーケンスがデコーダによって復号可能であるかどうかの判定に基づいて、符号化されたビデオシーケンスを選択的に復号させるよう構成される選択的復号化コードとを含む。
本開示の態様に従って、非一時的なコンピュータ可読媒体は命令を含み、命令は、デバイスの1つ以上のプロセッサによって実行されるときに、1つ以上のプロセッサに、符号化されたビデオシーケンスの第1コンフォーマンスポイントを示す第1指示を復号するステップと、符号化されたビデオシーケンスの第2コンフォーマンスポイントを示す第2指示を復号するステップと、第1指示及び第2指示のうちの少なくとも1つに基づいて、符号化されたビデオシーケンスがデバイスによって復号可能であるかどうかを判定するステップと、符号化されたビデオシーケンスがデバイスによって復号可能であるかどうかの判定に基づいて、符号化されたビデオシーケンスを選択的に復号するステップとを実行させる1つ以上の命令を含む。
開示されている対象の更なる特徴、性質、及び様々な利点は、以下の詳細な説明及び添付の図面から更に明らかになる。
関連する技術に従うプロファイルの概略図である。 実施形態に従う通信システムの略ブロック図の概略図である。 実施形態に従う通信システムの略ブロック図の概略図である。 実施形態に従うデコーダの略ブロック図の概略図である。 実施形態に従うエンコーダの略ブロック図の概略図である。 複数のコンフォーマンスポイントをサポートするシンタックスのシンタックス図である。 実施形態に従うプロセスの例のフローチャートである。 実施形態に従うコンピュータシステムの概略図である。
少なくともVVCサブプロファイルは、数十億とは言わないまでも数百万の選択を可能にし、UUID(長さが16バイトであり、従って、最大2(8×16)までのサブプロファイルを可能にする)、URI(実際には無限な長さの文字列であるが、通常は10から100文字範囲内であり、100文字とすれば2(8×100)のサブプロファイルを可能にする)、又はT.35ストリングス(実際上、224のサブプロファイルに沿って長さが少なくとも3つのオクテットであるべきである)などのメカニズムを通じてサブプロファイルの自己登録(self-registration)ならば更に可能にすると現在予想されている。これらのオプションの最小値であるT.35でさえ、224サイズのビットマスクが必要になるため、メディア符号化にとって実用的ではない。従って、1よりも多いプロファイル又はサブプロファイルとのビットストリーム互換性を示すには、新しいメカニズムが必要である。
図2は、本開示の実施形態に従う通信システム(200)の略ブロック図を表す。システム(200)は、ネットワーク(250)を介して相互接続されている少なくとも2つの端末(210~220)を含んでよい。データの一方向伝送のために、第1端末(210)は、ネットワーク(250)を介した他の端末(220)への伝送のためにその場でビデオデータを符号化してよい。第2端末(220)は、ネットワーク(250)から他の端末の符号化されたビデオデータを受信し、符号化されたデータを復号し、回復されたビデオデータを表示してよい。一方向データ伝送は、メディアサービングアプリケーションなどにおいて一般的であり得る。
図2は、例えば、ビデオ会議中に行われ得る符号化されたビデオの双方向伝送をサポートするために設けられた端末(230、240)の第2の対を表す。データの双方向伝送のために、各端末(230、240)は、その場で捕捉されたビデオデータを、ネットワーク(250)を介した他の端末への伝送のために符号化してよい。各端末(230、240)はまた、他の端末によって送信された符号化されたビデオデータを受信し、符号化されたデータを復号し、回復されたビデオデータをローカルの表示デバイスで表示してよい。
図2において、端末(210~240)は、サーバ、パーソナルコンピュータ、及びスマートフォンとして表され得るが、本開示の原理は、そのように限定され得ない。本開示の実施形態は、ラップトップコンピュータ、タブレットコンピュータ、メディアプレイヤー、及び/又は専用のビデオ会議装置により用途を見出す。ネットワーク(250)は、例えば、有線及び/又は無線通信ネットワークを含む、端末(210~240)の間で符号化されたビデオデータを伝達する任意数のネットワークを表す。通信ネットワーク(250)は、回路交換及び/又はパケット交換チャネルにおいてデータを交換し得る。代表的なネットワークには、電気通信網、ローカルエリアネットワーク、ワイドエリアネットワーク及び/又はインターネットがある。本議論のために、ネットワーク(250)のアーキテクチャ及びトポロジは、以降で説明されない限りは本開示の動作に無関係であり得る。
図3は、開示されている対象の応用例として、ストリーミング環境におけるビデオエンコーダ及びデコーダの配置を表す。開示されている対象は、例えば、ビデオ会議、デジタルTV、CD、DVD、メモリスティックなどを含むデジタル媒体上での圧縮されたビデオの記憶、などを含む他のビデオ対応用途に同様に適用可能であることができる。
ストリーミングシステムは、例えば無圧縮ビデオサンプルストリーム(302)を生成するビデオソース(301)、例えばデジタルカメラ、を含むことができる捕捉サブシステム(313)を含んでよい。そのサンプルストリーム(302)は、符号化されたビデオビットストリームと比較して高いデータボリュームを強調するために太線で表されており、カメラ(301)へ結合されたエンコーダ(303)によって処理され得る。エンコーダ(303)は、以下で更に詳細に記載されるように、開示されている対象の態様を可能に又は実装するためのハードウェア、ソフトウェア、又はそれらの組み合わせを含むことができる。符号化されたビデオビットストリーム(304)は、サンプルストリームと比較して低いデータボリュームを強調するために細線で表されており、将来の使用のためにストリーミングサーバ(305)に記憶され得る。1以上のストリーミングクライアント(306、308)は、符号化されたビデオビットストリーム(304)のコピー(307、309)を読み出すためにストリーミングサーバ(305)にアクセスすることができる。クライアント(306)は、ビデオデコーダ(310)を含むことができる。ビデオデコーダ(310)は、符号化されたビデオビットストリーム(307)の入来するコピーを復号し、ディスプレイ(312)又は他のレンダリングデバイス(図示せず。)にレンダリングされ得る送出ビデオサンプルストリーム(311)を生成する。いくつかのストリーミングシステムにおいて、ビデオビットストリーム(304、307、309)は、特定のビデオコーディング/圧縮標準規格に従って符号化され得る。そのような標準規格の例には、ITU-T推奨H.265がある。バーサタイル・ビデオ・コーディング又はVVCとして俗に知られているビデオ符号化標準が開発中である。開示されている対象は、VVCに関連して使用されてよい。
図4は、本発明の実施形態に従うビデオデコーダ(310)の機能ブロック図であり得る。
受信器(410)は、デコーダ(310)によって復号されるべき1つ以上の符号化されたビデオシーケンスを、同じ又は他の実施形態では、一度に1つの符号化されたビデオシーケンスを受信してよい。ここで、夫々の符号化されたビデオシーケンスの復号化は、他の符号化されたビデオシーケンスから独立している。符号化されたビデオシーケンスは、チャネル(412)から受信されてよい。チャネルは、符号化されたビデオデータを記憶している記憶デバイスへのハードウェア/ソフトウェアリンクであってよい。受信器(410)は、符号化されたビデオデータを、他のデータ、例えば、符号化されたオーディオデータ及び/又は付随的なデータストリームとともに受信してよく、それらは、それらの各々の使用エンティティ(図示せず。)へ転送されてよい。受信器(410)は、符号化されたビデオシーケンスを他のデータから分離してよい。ネットワークジッタに対抗するために、バッファメモリ(415)が受信器(410)とエントロピデコーダ/パーサ(420)(以降「パーサ」)との間に結合されてよい。受信器(410)が十分なバンド幅及び可制御性の記憶/転送デバイスから、又はアイソクロナス(isosychronous/isochronous)ネットワークからデータを受信しているときに、バッファ(415)は必要とされなくてもよく、あるいは、小さくてよい。インターネットなどのベストエフォートのパケットネットワークでの使用のために、バッファ(415)は、比較的に大きく、有利なことには適応サイズであることができる。
ビデオデコーダ(310)は、エントロピ符号化されたビデオシーケンスからシンボル(421)を再構成するためのパーサ(420)を含んでよい。それらのシンボルのカテゴリは、デコーダ(310)の動作を管理するために使用される情報と、潜在的に、デコーダの必須部分でないが図3に示されたようにそれへ結合され得るディスプレイ(312)などのレンダリングデバイスを制御するための情報とを含む。レンダリングデバイスのための制御情報は、SEI(Supplementary Enhancement Information)メッセージ又はVUI(Video Usability Information)パラメータセットフラグメント(図示せず。)の形をとってよい。パーサ(420)は、受信された符号化されたビデオシーケンスをパース/エントロピ復号してよい。符号化されたビデオシーケンスの符号化は、ビデオ符号化技術又は標準規格に従うことができ、可変長符号化、ハフマン符号化、文脈依存による又はよらない算術符号化、などを含む、当業者によく知られている原理に従うことができる。パーサ(420)は、符号化されたビデオシーケンスから、グループに対応する少なくとも1つのパラメータに基づいて、ビデオデコーダにおけるピクセルのサブグループのうちの少なくとも1つについてのサブグループパラメータの組を取り出してよい。サブグループは、グループ・オブ・ピクチャ(Groups of Pictures,GOP)、ピクチャ、タイル、スライス、マクロブロック、符号化単位(Coding Units,CU)、ブロック、変換単位(Transform Units,TU)、予測単位(Prediction Units,PU)、などを含むことができる。エントロピデコーダ/パーサはまた、変換係数などの符号化されたビデオシーケンスの情報から、量子化パラメータ値、動きベクトル、なども取り出してよい。
パーサ(420)は、シンボル(421)を生成するために、バッファ(415)から受信されたビデオシーケンスに対してエントロピ復号化/パーシング動作を実行してよい。
シンボル(421)の再構成は、符号化されたビデオピクチャ又はその部分のタイプ(例えば、インター及びイントラピクチャ、インター及びイントラブロック)並びに他の因子に依存して多種多様なユニットを有することができる。どのユニットがどのように含まれるかは、符号化されたビデオシーケンスからパーサ(420)によってパースされたサブグループ制御情報によって制御され得る。パーサ(420)と以下の複数のユニットとの間のそのようなサブグループ制御情報のフローは、明りょうさのために表されていない。
既に述べられた機能ブロックを超えて、デコーダ310は、概念的に、以下で記載されるように多数の機能ユニットに細分され得る。商業上の制約の下で動作する実際の実施では、それらのユニットの多くが互いに密に相互作用し、少なくとも部分的に互いに組み込まれ得る。なお、開示されている対象を説明するために、以下、機能ユニットへの概念的細分は適切である。
第1ユニットは、スケーラ/逆変換ユニット(451)である。スケーラ/逆変換ユニット(451)は、パーサ(420)からシンボル(421)として、量子化された変換係数とともに、使用するために変換するもの、ブロックサイズ、量子化係数、量子化スケーリングマトリクスなどを含む制御情報を受信する。パーサ(420)は、サンプル値を含むブロックを出力することができ、これはアグリゲータ(455)へ入力され得る。
いくつかの場合に、スケーラ/逆変換器(451)の出力サンプルは、イントラ符号化されたブロック、すなわち、前に再構成されたピクチャからの予測情報を使用しておらず、現在のピクチャの前の再構成された部分からの予測情報を使用することができるブロックに関係することができる。そのような予測情報は、イントラピクチャ予測ユニット(452)によって供給され得る。いくつかの場合に、イントラピクチャ予測ユニット(452)は、現在の(部分的に再構成された)ピクチャ(456)からフェッチされた周囲の既に再構成された情報を用いて、再構成中のブロックの同じサイズ及び形状のブロックを生成する。アグリゲータ(455)は、いくつかの場合に、サンプルごとに、イントラ予測ユニット(452)が生成した予測情報を、スケーラ/逆変換ユニット(451)によって供給される出力サンプル情報に加える。
他の場合に、スケーラ/逆変換ユニット(451)の出力サンプルは、インター符号化された、そして潜在的に動き補償されたブロックに関係することができる。そのような場合に、動き補償予測ユニット(453)は、予測のために使用されるサンプルをフェッチするために参照ピクチャメモリ(457)にアクセスすることができる。ブロックに関係するシンボル(421)に従ってフェッチされたサンプルを動き補償した後、それらのサンプルは、出力サンプル情報を生成するために、アグリゲータ(455)によってスケーラ/逆変換ユニットの出力(この場合に、残差サンプル又は残差信号と呼ばれる)に加えられる得る。動き補償ユニットが予測サンプルをフェッチする参照ピクチャメモリ内のアドレスは、例えば、X、Y及び参照ピクチャコンポーネントを有することができるシンボル(421)の形で動き補償ユニットが利用することができる動きベクトルによって制御され得る。動き補償はまた、サブサンプルの正確な動きベクトルが使用されているときに参照ピクチャメモリからフェッチされるサンプル値の補間、動きベクトル予測メカニズムなどを含むことができる。
アグリゲータ(455)の出力サンプルは、ループフィルタユニット(456)において様々なループフィルタリング技術を受けることができる。ビデオ圧縮技術は、インループフィルタリング技術を含むことができる。この技術は、符号化されたビデオビットストリームに含まれており、パーサ(420)からのシンボルとしてループフィルタユニット(456)に利用可能にされたパラメータによって制御されるが、符号化されたピクチャ又は符号化されたビデオシーケンスの(復号化順序において)前の部分の復号化の間に得られたメタ情報にも応答することができ、更には、前に構成されたループフィルタ処理されたサンプル値に応答することができる。
ループフィルタフィルタ(456)の出力は、レンダリングデバイス(312)へ出力され、更には、将来のインターピクチャ予測における使用のために参照ピクチャメモリ(456)に記憶され得るサンプルストリームであることができる。
特定の符号化されたピクチャは、完全に再構成されると、将来の予測のための参照ピクチャとして使用され得る。符号化されたピクチャが完全に再構成され、符号化されたピクチャが(例えば、パーサ(420)によって)参照ピクチャとして識別されると、現在の参照ピクチャ(456)は、参照ピクチャバッファの部分になることができ、新しい現在ピクチャメモリが、後続の符号化されたピクチャの再構成を開始する前に再割当てされ得る。
ビデオデコーダ420は、ITU-T推奨H.265などの標準規格において文書化され得る所定のビデオ圧縮技術に従って復号化動作を実行してよい。符号化されたビデオシーケンスは、それが、ビデオ圧縮技術文書又は標準規格において、具体的にその中のプロファイル文書において規定されているビデオ圧縮技術又は標準規格のシンタックスに従うという意味で、使用中のビデオ圧縮技術又は標準規格によって規定されたシンタックスに従い得る。また、符号化されたビデオシーケンスの複雑さは、ビデオ圧縮技術又は標準規格のレベルによって定義された境界内にあることが、順守のために必要である。いくつかの場合に、レベルは、最大ピクチャサイズ、最大フレームレート、最大再構成サンプルレート(例えば、メガサンプル/秒で測定される)、最大参照ピクチャサイズ、などを制限する。レベルによって設定される制限は、いくつかの場合に、ハイポセティカル・リファレンス・デコーダ(Hypothetical Reference Decoder,HRD)仕様及び符号化されたビデオシーケンスにおいて示されたHRDバッファ管理のためのメタデータを通じて更に制限され得る。
実施形態において、受信器(410)は、符号化されたビデオとともに、追加の(冗長の)データを受信してもよい。追加のデータは、符号化されたビデオシーケンスの部分としても含まれてもよい。追加のデータは、ビデオデコーダ(420)によって、データを適切に復号するために及び/又は原ビデオデータをより正確に再構成するために使用されてよい。追加のデータは、例えば、時間、空間、又はSNRエンハンスメントレイヤ、冗長スライス、冗長ピクチャ、前方誤り訂正符号、などの形をとることができる。
図5は、本開示の実施形態に従うビデオエンコーダ(303)の機能ブロック図であり得る。
エンコーダ(303)は、エンコーダ(303)によって符号化されるべきビデオ画像を捕捉し得るビデオソース(301)(エンコーダの部分ではない)からビデオサンプルを受信してよい。
ビデオソース(301)は、任意の適切なビット深さ(例えば、8ビット、10ビット、12ビットなど)、任意の色空間(例えば、BT.601 U CrCB、RGBなど)、及び任意の適切なサンプリング構造(例えば、Y CrCb 4:2:0、Y CrCb 4:4:4)であることができるデジタルビデオサンプルストリームの形で、エンコーダ(303)によって符号化されるべきソースビデオシーケンスを供給してよい。メディアサービングシステムでは、ビデオソース(301)は、前にパースされたビデオを記憶している記憶デバイスであってよい。ビデオ会議システムでは、ビデオソース(301)は、ローカル画像情報をビデオシーケンスとして捕捉するカメラであってよい。ビデオデータは、順に見られる場合に動きを授ける複数の個別ピクチャとして供給されてもよい。ピクチャ自体は、ピクセルの空間アレイとして編成されてよく、各ピクセルは、使用中にサンプリング構造、色空間、などに依存する1つ以上のサンプルを有することができる。当業者であれば、ピクセルとサンプルとの間の関係を容易に理解することができる。本明細書は、以下、サンプルに焦点を当てる。
実施形態に従って、エンコーダ(303)は、実時間において又は用途によって必要とされる任意の他の時間制約の下で、ソースビデオシーケンスを、符号化されたビデオシーケンス(543)へと符号化及び圧縮してよい。適切な符号化速度を強いることは、コントローラ(550)の一機能である。コントローラは、以下で記載されるように他の機能ユニットを制御し、それらのユニットへ機能上結合される。結合は明りょうさのために表されていない。コントローラによってセットされるパラメータには、レート制御に関連したパラメータ(ピクチャスキップ、量子化器、レート歪み最適化技術のラムダ値、など)、ピクチャサイズ、グループ・オブ・ピクチャ(GOP)レイアウト、最大動きベクトル探索範囲、などが含まれ得る。当業者であれば、コントローラ(550)の他の機能を、それらが特定のシステム設計のために最適化されたビデオエンコーダ(303)に関係し得るということで、容易に識別することができる。
いくつかのビデオエンコーダは、当業者が「符号化ループ」として容易に認識するものにおいて動作する。過度に単純化された記載として、符号化ループは、(符号化されるべき入力ピクチャと、参照ピクチャとに基づいて、シンボルを生成することに関与する)エンコーダの符号化部分(530)(以降「ソースコーダ」)と、(遠隔の)デコーダも生成することになる(シンボルと符号化されたビデオビットストリームとの間の如何なる圧縮も、開示されている対象で考えられているビデオ圧縮技術において可逆である場合)サンプルデータを生成するようにシンボルを再構成する、エンコーダ(303)に埋め込まれた(ローカルの)デコーダ(533)とからなることができる。その再構成されたサンプルストリームは、参照ピクチャメモリ(534)へ入力される。シンボルストリームの復号化は、デコーダの場所(ローカル又は遠隔)に依存しないビットパーフェクト(bit-exact)な結果をもたらすので、参照ピクチャバッファコンテンツも、ローカルのエンコーダと遠隔のエンコーダとの間でビットパーフェクトである。すなわち、エンコーダの予測部分は、デコーダが復号化の間に予測を使用するときに“見る”ことになるのとまさに同じサンプル値を参照ピクチャサンプルとして“見る”。参照ピクチャのシンクロニシティ(及び、例えば、チャネルエラーのために、シンクロニシティが維持され得ない場合に、結果として生じるドリフト)のこの基本原理は、当業者によく知られている。
“ローカル”のデコーダ(533)の動作は、図4とともに先に詳細に既に説明されている“遠隔”のデコーダ(310)のそれと同じであることができる。一時的に同じく図4を参照すると、しかしながら、シンボルは利用可能であり、エントロピコーダ(545)及びパーサ(420)による符号化されたビデオシーケンスへのシンボルの符号化/復号化は可逆であることができるので、チャネル(412)、受信器(410)、バッファ(415)、及びパーサ(420)を含むデコーダ(310)のエントロピ復号化部分は、ローカルのデコーダ(533)において完全には実施されなくてよい。
この時点で行われ得る観察は、デコーダに存在するパーシング/エントロピデコーダを除く如何なるデコーダ技術も、対応するエンコーダにおいて、実質的に同じ機能形態で、必ずしも存在する必要がないことである。この理由のために、開示されている対象は、デコーダの動作に焦点を当てる。符号化技術の説明は、それらが包括的に記載される復号化技術の逆であるということで、省略され得る。特定の範囲においてのみ、より詳細な説明が必要とされ、以下で与えられている。
その動作の部分として、ソースコーダ(530)は、動き補償された予測符号化を実行してよい。これは、「参照フレーム」として指定されたビデオシーケンスからの1つ以上の前に符号化されたフレームを参照して予測的に入力フレームを符号化する。このようにして、符号化エンジン(732)は、入力フレームに対する予測参照として選択され得る参照フレームのピクセルブロックと入力フレームのピクセルブロックとの間の差を符号化する。
ローカルのビデオデコーダ(533)は、ソースコーダ(530)によって生成されたシンボルに基づいて、参照フレームとして指定され得るフレームの符号化されたビデオデータを復号してよい。符号化エンジン(732)は、有利なことに、不可逆プロセスであってよい。符号化されたビデオデータがビデオデコーダ(図5には図示せず。)で復号化され得るとき、再構成されたビデオシーケンスは、通常は、いくらかのエラーを伴ったソースビデオシーケンスの複製であり得る。ローカルのビデオデコーダ(533)は、参照フレームに対してビデオデコーダによって実行され得る復号化プロセスを再現し、再構成された参照フレームを参照ピクチャキャッシュ(534)に格納されるようにしてよい。このように、エンコーダ(303)は、(伝送エラーなしで)遠端のビデオデコーダによって取得されることになる再構成された参照フレームと共通の内容を有している再構成された参照フレームのコピーをローカルで記憶し得る。
予測器(535)は、符号化エンジン(732)の予測探索を実行してよい。すなわち、新しいフレームが符号化されるために、予測器(535)は、新しいピクチャのための適切な予測基準となり得る参照ピクチャ動きベクトル、ブロック形状、などの特定のメタデータ又は(候補参照ピクセルブロックとしての)サンプルデータを参照ピクチャメモリ(534)から探してよい。予測器(535)は、適切な予測基準を見つけるためにサンプルブロック・バイ・ピクセルブロックベース(sample block-by-pixel block basis)で動作してよい。いくつかの場合に、予測器(535)によって取得された探索結果によって決定されるように、入力ピクチャは、参照ピクチャメモリ(534)に記憶されている複数の参照ピクチャから引き出された予測基準を有してよい。
コントローラ(550)は、例えば、ビデオデータを符号化するために使用されるパラメータ及びサブグループパラメータの設定を含め、ビデオコーダ(530)の符号化動作を管理してよい。
上記の全ての機能ユニットの出力は、エントロピコーダ(545)においてエントロピ符号化を受けてよい。エントロピコーダは、例えば、ハフマン符号化、可変長符号化、算術符号化などとして当業者に知られている技術に従ってシンボルを可逆圧縮することによって、様々な機能ユニットによって生成されたシンボルを、符号化されたビデオシーケンスへと変換する。
送信器(540)は、エントロピコーダ(545)によって生成された符号化されたビデオシーケンスを、それを通信チャネル(560)を介した伝送のために準備するようにバッファに入れてよい。通信チャネル(560)は、符号化されたビデオデータを記憶する記憶デバイスへのハードウェア/ソフトウェアリンクであってよい。送信器(540)は、ビデオコーダ(530)からの符号化されたビデオデータを、送信されるべき他のデータ、例えば、符号化されたオーディオデータ及び/又は付随的なデータストリーム(ソースは図示せず)とマージしてもよい。
コントローラ(550)は、エンコーダ(303)の動作を管理してよい。符号化の間、コントローラ(550)は、各々のピクチャに適用され得る符号化技術に影響を及ぼす可能性がある特定の符号化されたピクチャタイプを夫々の符号化されたピクチャに割り当ててよい。例えば、ピクチャはしばしば、次のフレームタイプのうちの1つとして割り当てられてよい。
イントラピクチャ(Intra Picture)(Iピクチャ)は、予測のソースとしてシーケンス内の如何なる他のフレームも使用せずに符号化及び復号化され得るピクチャであってよい。いくつかのビデオコーデックは、例えば、独立したデコーダリフレッシュピクチャ(Independent Decoder Refresh Pictures)を含む種々のタイプのイントラピクチャを許容する。当業者であれば、Iピクチャのそのような変形並びにそれらの各々の応用及び特徴に気づく。
予測ピクチャ(Predictive Picture)(Pピクチャ)は、各ブロックのサンプル値を予測するために多くても1つの動きベクトル及び参照インデックスを用いてイントラ予測又はインター予測により符号化及び復号化され得るピクチャであってよい。
双方向予測ピクチャ(Bi-directionally Predictive Picture)(Bピクチャ)は、各ブロックのサンプル値を予測するために多くても2つの動きベクトル及び参照インデックスを用いてイントラ予測又はインター予測により符号化及び復号化され得るピクチャであってよい。同様に、多重予測ピクチャは、単一のブロックの再構成のために2よりも多い参照ピクチャ及び関連するメタデータを使用することができる。
ソースピクチャは、一般に、複数のサンプルブロック(例えば、夫々、4×4、8×8、4×8、又は16×16のサンプルのブロック)に空間的に細分され、ブロックごとに符号化されてよい。ブロックは、ブロックの各々のピクチャに適用されている符号化割り当てによって決定される他の(既に符号化された)ブロックを参照して予測的に符号化されてよい。例えば、Iピクチャのブロックは、非予測的に符号化されてよく、あるいは、それらは、同じピクチャの既に符号化されたブロックを参照して予測的に符号化されてもよい(空間予測又はイントラ予測)。Pピクチャのピクセルブロックは、非予測的に、あるいは、1つの前に符号化された参照ピクチャを参照して空間予測により又は時間予測により、符号化されてよい。Bピクチャのブロックは、非予測的に、あるいは、1つ又は2つの前に符号化された参照ピクチャを参照して空間予測により又は時間予測により、符号化されてよい。
ビデオエンコーダ(303)は、ITU-T推奨H.265のような所定のビデオ符号化技術又は標準規格に従って符号化動作を実行してよい。その動作中に、ビデオエンコーダ(303)は、入力ビデオシーケンスにおける時間及び空間冗長性を利用する予測符号化動作を含む様々な圧縮動作を実行してよい。従って、符号化されたビデオデータは、使用されているビデオ符号化技術又は標準規格によって定められているシンタックスに従い得る。
実施形態において、送信器(540)は、符号化されたビデオとともに追加のデータを送信してもよい。ビデオコーダ(530)は、符号化されたビデオシーケンスの部分としてそのようなデータを含めてよい。追加のデータは、時間/空間/SNRエンハンスメント、冗長ピクチャ及びスライスのような他の形式の冗長データ、SEI(Supplementary Enhancement Information)メッセージ又はVUI(Video Usability Information)パラメータセットフラグメント、などを有してよい。
以下では、より古いビデオ符号化標準規格及び技術で一般的な8ビットのビット列によるプロファイル表現、並びにT.35文字列によるサブプロファイル表現が考えられる。ITU-T推奨T.35は、最低限2つのオクテットから構成される登録フォーマットを規定する。第1オクテットは、国際連合加盟国の国名コードを運ぶ。登録を得るために、エンティティ(例えば、ビジネス、又はいくつかの国では、個人)は、現地の規制当局に働きかけ、第2オクテットにおいて符号化されている256のコードポイントのうちの1つを要求することができる。組織内で、第3、第4、第5などのオクテットが割り当てられ得る。T.35文字列におけるそれら2つ以上のオクテットの内容は登録され得る。更なるオクテットが必要に応じてT.35文字列に加えられてよく、たとえ番号空間の管理が第1及び第2オクテットにより識別されるビジネス又は個人に付与されているとしても、その番号空間の増大を可能にする。
開示されている対象は、T.35文字列によるプロファイル又はサブプロファイル表現に限られない。他のオプションには、ユニフォーム・リソース・アイデンティファイア(URI,IANAを通じて登録され得る文字列)、ユニバーサリー・ユニーク・アイデンティファイア(UUID,一意性のためにハッシュ関数及び膨大な番号空間に依存して自己登録される128ビット長の識別子)などがある。本願で開示されているプロファイル及びサブプロファイル識別と、MPEG及び他のメディア標準規格で使用される従来のプロファイルIDとの間の相違を区別することは、プロファイル若しくはサブプロファイル又はそれら2つの組み合わせの番号空間がビットマスクによって合理的に表現されるには大きすぎることである。すなわち、番号空間は、ビットマスク符号化が、多くのメディア符号化標準規格の目標、すなわち圧縮を否定し得るほどに大きい可能性がある。
以下では、一例としてプロファイル及びサブプロファイルを使用する複数のコンフォーマンスポイントのシグナリングについて記載する。なお、開示されている対象は、他の非オニオン形コンフォーマンスポイントのために同様に使用され得る。考えられるところでは、レベルは、オニオン形でなくてもよく、例えば、特定の4:3アスペクト比ビデオ画像のみをカバーするレベルと、特定の9:16アスペクト比ビデオ画像のみをカバーする他のレベルとを考える。更に別のものは、レベルが現在H.265にあるということで、アスペクト比に対して不可知的である。そのようなレベル定義はMPEGの歴史では珍しいかもしれないが、一方で、それらは、特定のアプリケーション標準規格で使用中である。
図6を参照すると、実施形態に従って、T.35文字列、UUID、URI、又は長さが少なくとも24ビットの同様の表現によって表される1つ以上のサブプロファイルは、文字列のリスト(604)の形をとるビットストリームへと符号化され得る。各文字列は、終端記号を用いながら一定の所定の長さ又は可変長さを有することを有する。例えば、開示されている対象において使用されているT.35文字列は、例えば、3、4、5などのオクテットの所定長さを有することができる。UUIDは、定義によって、128ビット又は16オクテットの長さを有する。URIは、ゼロ終端文字列として形成され得る。このとき、ゼロの値を有しているオクテットは、文字列の終わりをマークし、文字列は、可変な長さを有することができる。T.35文字列の4オクテット表現を前提とするシンタックス図が以下で示される。
図6を参照すると、同じ又は他の実施形態で、リストは、シンタックス図(601)において、一定数の繰り返しを有するループ(603)の形で容易に表現され得る。シンタックス要素“num_sub_profiles”(602)は、表されるべきサブプロファイルの数を示すことができる。そのシンタックス要素(602)は、固定長バイナリ符号化されても、可変長符号化されても、あるいは、何らかの他の適切な符号化スキームに従ってもよい。ue(v)によって示されるように、可変長符号化されたシンタックス要素が示されている。
サブプロファイリングメカニズムが任意である環境では、シンタックス要素は、H.264又はH.265のue(v)定義を用いて可変長符号化され得る。シングルビット表現は、サブプロファイルリストに含まれるべきゼロサブプロファイルの数を示す。プロファイルのために使用されるとき、少なくとも1つのプロファイルを伝達することが有利であることができ、従って、ue(v)符号化スキームのシングルビット値を1つのプロファイルの符号化に割り当てることができ、シンタックス違反なしで最低限必要とされるものにする。
サブプロファイルインジケータ(604)は、如何なる適切なエントロピ符号化フォーマットでも表現され得る。ここでは、b(32)によって表される32ビットのビット列が示されている。このビット列は、サブプロファイルIDの4オクテットT.35表現を符号化するのに十分である。他の長さのサブプロファイルインジケータ(604)も可能である。特に、T.35符号化サブプロファイルインジケータの最低限の検知可能な長さは。24ビット、すなわち、国名コード用の8ビット、ターミナルプロバイダコード用の8ビット、及びその国においてそのターミナルプロバイダによって定義されるサブプロファイルコード用の8ビット、であることができる。
シンタックス構造(601)は、例えば、デコーダパラメータセット、ビデオパラメータセット(H.265で定義されるVPS)、シーケンスパラメータセット(H.264及びH.265で定義されるSPS)などの高位パラメータセットにおいて、並びにシーケンスヘッダ、GOPヘッダ、又はMPEG-2若しくはMPEG-4で定義されるピクチャヘッダなどの高位ヘッダ構造において含まれ得る。シンタックス構造はまた、例えば、ケイパビリティアナウンス又は交換のためのプロトコルで使用されるメタデータの形で、ビットストリームの外で利用可能であってよい。その中で、それは、例えば、ASN.1、SDP、XML、などのようなシンタックスにおいて、符号化され得る。
ビットストリームコンフォーマンスポイントはまた、本願で記載されるように複数のコンフォーマンスポイントの組み合わせとして定義されてもよい。例えば、ビットストリームコンフォーマンスポイントは、例えば、8ビット固定長さコードワードによって表現され得るプロファイルIDと、T.35文字列によって表現され得るサブプロファイルIDとの組み合わせとして定義されてよい。その場合に、T.35文字列は、プロファイルIDによって識別されるサブプロファイルを識別し得る。結果として、同じサブプロファイルIDは、プロファイルに応じて、異なるビットストリームコンフォーマンスポイントを識別し得る。
ビットストリームにおいて、又は上記のメカニズム若しくはそれと実質的に類似したメカニズムに従うメタデータの形で、複数のコンフォーマンスポイントの存在のための多数の可能な使用が存在する。
一例として、夫々がおそらくは互いにわずかに異なる複数のデコーダエコシステムの存在を考える。そのようなエコシステムは、特定の国家標準(例えば、米国におけるATSC、欧州におけるDVB、日本におけるARIB)であってよく、それらの夫々は、国又は地域の好み又はニーズに従って“メイン”プロファイルをサブプロファイリングすることを必要とする。また、デコーダ要件が夫々わずかに異なっている複数の“ウォールド・ガーデン”(walled garden)エコシステムを考える。例えば、テンセント、Netflix(登録商標)、Hulu(登録商標)、及びYouTube(登録商標)を考える。
これより、複数のエンコーダを実行せずに複数のエコシステムへコンテンツを提供したいと望むコンテンツプロバイダを考える。そうすることには、多くの商業上の利点がある。コンテンツプロバイダは、それがサービスを提供したいと望む全てのエコシステムの詳細な要件を、それらのサブプロファイリングT.35文字列とともに、よく知っていることがある。エコシステム間の要件が矛盾しない限りは、コンテンツプロバイダは、一方では条件下で任意の圧縮性能を可能にするが、他方では全ての対象とされるエコシステムのデコーダによる復号化を依然として可能にする最大ツールセットを識別するために、最小公分母アプローチを使用することができる。
コンテンツプロバイダは、その最小公分母アプローチに従ってソース素材を符号化し、“メインプロファイル”をプロファイルとして示し、全ての例えばATSC、DVB、及びARIBのためのサブプロファイルを示す。夫々のATSC、DVB、及びARIBは、それらの関連するサブプロファイルIDを適切な登録機関に、T.35の場合に、例えば、ITU-Tに及び/又は関連する現地の規制当局によって定められた現地の登録機関に登録していることがある。例えば、ATSCは、その関連するサブプロファイルを米国の規制当局に登録し、181(米国の国名コード)に等しいオクテットから始まって、例えば、残り3つのオクテットの値が01、02及び03である4オクテットT.35文字列を受理していることがある。同様に、DVBは、66、04、05、06に等しい4オクテット文字列を受理し、ARIBは、00 07 08 09に等しい文字列を受理していてよい。結果として得られるサブプロファイルテーブルは、次のとおりである:

num_sub_profile = 2
sub_profile_t35_string[0] = 181 01 02 03
sub_profile_t35_string[1] = 66 04 05 06
sub_profile_t35_string[2] = 00 07 08 09
目下、エコシステムデコーダは、所与のプロファイルID、しばしばメイン、しかし、所与のエコシステムによって必要とされる他の制約の無言の順守を広く期待する。そのような適合性は、サブプロファイルIDにおいて示され得る。コンテンツプロバイダからビットストリームを取得したコンテンツサーバを考える。コンテンツサーバは、所与のビットストリームがエコシステムと互換性があるかどうかを確認するためにサブプロファイルIDをパースし、互換性がある場合にのみそれを差し出しかつそれを提供することができる。
上記の例では、ロシアにあるサードパーティプロバイダからビットストリームを受信した、日本にあってARIB標準に従うコンテンツサーバを考える。ビットストリームは、メインプロファイルを示し得る。その情報だけでは、開示されている対象を欠くために、コンテンツサーバは、ARIB標準に従って作動する日本国内のデコーダが、ARIB仕様互換性を確かめるためにビットストリーム全体をパースすることを少なくともなしとせずに、ロシアのビットストリームを有意義に受信及び復号することができるかどうかを知らない。しかし、ビットストリームが上述されたようにマークされる場合には、コンテンツサーバは、サブプロファイル文字列を期待することができる高位シンタックス構造をパースすることができる。ARIB指示を含むサブプロファイル指示を見つけると、それは、ビットストリームがARIB標準の要件を順守しながら符号化されたと考え、躊躇なくそれを(ARIB対応)デコーダへ提供することができる。同様に、ドイツに位置し、DVB対応コンテンツを期待するコンテンツサーバ、又は米国に位置し、ATSC対応コンテンツを期待するコンテンツサーバは、それらの各々のデコーダへビットストリームを同じく提供することができる。
代替案として、特定のエコシステムデコーダは、適切なサブプロファイルIDが、復号化を試みる前でさえ、ビットストリームに存在することを求めてもよい。
図7は、実施形態に従うプロセスの例のフローチャートである。
図7に示されるように、プロセス700は、符号化されたビデオシーケンスの第1コンフォーマンスポイントを示す第1指示を復号すること(ブロック710)を含んでよい。
図7に更に示されるように、プロセス700は、符号化されたビデオシーケンスの第2コンフォーマンスポイントを示す第2指示を復号すること(ブロック720)を含んでよい。
図7に更に示されるように、プロセス700は、第1指示及び第2指示に基づいて、結合されたコンフォーマンスポイントを識別すること(ブロック730)を含んでよい。
図7に更に示されるように、プロセス700は、符号化されたビデオシーケンスがデコーダによって復号可能であるかどうかを判定すること(ブロック740)を含んでよい。
図7に更に示されるように、プロセス700は、符号化されたビデオシーケンスがデコーダによって復号可能であるかどうかの判定に基づいて、符号化されたビデオシーケンスを選択的に復号することを含んでよい。例えば、符号化されたビデオシーケンスがデコーダによって復号可能でない場合(ブロック740-いいえ)、次いで、プロセス700は、符号化されたビデオシーケンスの復号化を阻止すること(ブロック750)を含んでよい。代替的に、符号化されたビデオシーケンスがデコーダによって復号可能である場合(ブロック740-はい)、次いで、プロセス700は、符号化されたビデオシーケンスを復号すること(ブロック760)を含んでよい。
追加的に、又は代替的に、プロセス700は、符号化されたビデオシーケンスの第1コンフォーマンスポイントを示す第1指示を復号することを含んでよい。更に、プロセス700は、符号化されたビデオシーケンスの第2コンフォーマンスポイントを示す第2指示を復号することを含んでよい。更に、プロセス700は、第1コンフォーマンスポイント及び第2コンフォーマンスポイントのうちの少なくとも1つに基づいて、符号化されたビデオシーケンスがデコーダによって復号可能であるかどうかを判定することを含んでよい。また更には、プロセス700は、符号化されたビデオシーケンスがデコーダによって復号可能であるかどうかの判定に基づいて、符号化されたビデオシーケンスを選択的に復号することを含んでよい。
いくつかの場合に、第1指示は、ITU-T推奨T.35に従って符号化される。追加的に、又は代替的に、第1指示は、第1高位シンタックス構造に存在する複数の第1指示のうちの1つであり、第1高位シンタックス構造は、少なくとも符号化されたビデオシーケンスに関係がある。追加的に、又は代替的に、複数の第1指示は、第1指示のリストとしてまとめられ、リスト内の第1指示の数は、可変長さの符号なしコードワードとして第1高位シンタックス構造において符号化される。
いくつかの場合に、第1指示は、第1高位シンタックス構造に存在し、第2指示は、第2高位シンタックス構造に存在し、第1高位シンタックス構造は、第2高位シンタックス構造とは異なる。
いくつかの場合に、第1指示は、長さが少なくとも3つのオクテットのオクテット列に符号化され、第1指示は、第2指示のサブプロファイルである。
いくつかの場合に、プロセス700は、第1指示及び第2指示を結合することと、第1指示及び第2指示を結合したことに基づいて、結合されたコンフォーマンスポイントを識別することとを含む。追加的に、又は代替的に、プロセス700は、結合されたコンフォーマンスポイントとデコーダのケイパビリティ(capability information)とを比較することと、結合されたコンフォーマンスポイントとデコーダのケイパビリティ情報との比較に基づいて、符号化されたビデオシーケンスがデコーダによって復号可能であるかどうかを判定することとを含む。
いくつかの場合に、メディアビットストリームは、第1コンフォーマンスポイント及び第2コンフォーマンスポイントの両方に対応する。
メディア符号化において複数のコンフォーマンスポイントを伝達するための上記の技術は、コンピュータ読み出し可能な命令を使用しかつ1つ以上のコンピュータ可読媒体に物理的に記憶されているコンピュータソフトウェアとして、実装され得る。例えば、図8は、開示されている対象の特定の実施形態を実装することに適したコンピュータシステム800を示す。
コンピュータソフトウェアは、中央演算処理装置(CPU)、グラフィクス処理ユニット(GPU)などによって直接に又は解釈、マイクロコード実行などを通じて実行され得る命令を含むコードを生成するようにアセンブリ、コンパイル、リンキングなどを受け得る如何なる適切な機械コード又はコンピュータ言語によっても符号化され得る。
命令は、例えば、パーソナルコンピュータ、タブレットコンピュータ、サーバ、スマートフォン、ゲーム機、モノのインターネット(Internet of Things)のためのデバイス、などを含む様々なタイプのコンピュータ又はその構成要素で実行され得る。
コンピュータシステム800に関して図8に示される構成要素は、本質的に例示であり、本開示の実施形態を実装するコンピュータソフトウェアの使用又は機能の範囲に関して如何なる制限も示唆することを意図しない。構成要素の構成は、コンピュータシステム800の例となる実施形態に表されている構成要素のうちのいずれか1つ又は組み合わせに関して何らかの依存又は要件も有するものとして解釈されるべきではない。
コンピュータシステム800は、特定のヒューマンインターフェイス入力デバイスを含んでよい。そのようなヒューマンインターフェイス入力デバイスは、例えば、触覚入力(例えば、キーボード、スワイプ、データグロープ動作)、音声入力(例えば、声、拍手)、視覚入力(例えば、ジェスチャ)、嗅覚入力(図示せず。)を通じた一人以上のユーザによる入力に関与してよい。ヒューマンインターフェイスデバイスはまた、音声(例えば、発話、音楽、周囲音)、画像(例えば、スキャンされた画像、静止画カメラから取得された写真画像)、映像(例えば、二次元映像、立体視映像を含む三次元映像)など、人による意識的な入力に必ずしも直接には関係しない特定のメディアを捕捉するためにも使用され得る。
入力ヒューマンインターフェイスデバイスは、キーボード801、マウス802、トラックパッド803、タッチスクリーン810、データグローブ804、ジョイスティック805、マイク806、スキャナ807、カメラ808のうちの1つ以上(夫々表されているもののうちの1つのみ)を含んでよい。
コンピュータシステム800は、特定のヒューマンインターフェイス出力デバイスも含んでよい。そのようなヒューマンインターフェイス出力デバイスは、例えば、触覚出力、音響、光、及び匂い/味を通じて一人以上のユーザの感覚を刺激し得る。そのようなヒューマンインターフェイス出力デバイスは、触覚出力デバイス(例えば、タッチスクリーン810、データグローブ804、又はジョイスティック805による触覚フィードバック、しかし、入力デバイスとして機能しない触覚フィードバックデバイスも存在し得る)、音声出力デバイス(例えば、スピーカ809、ヘッドホン(図示せず))、視覚出力デバイス(例えば、タッチスクリーン入力機能の有無によらず、触覚フィードバック機能の有無によらず、CRTスクリーン、LCDスクリーン、プラズマスクリーン、OLEDスクリーンを含み、それらのいくつかは、立体視出力、仮想現実メガネ(図示せず)、ホログラフィックディスプレイ及びスモークタンク(図示せず)などの手段により二次元視覚出力又は三次元よりも多い次元の出力を出力する機能がある、スクリーン810)、及びプリンタ(図示せず。)を含んでよい。
コンピュータシステム800は、人がアクセス可能な記憶デバイス及びそれらの関連する媒体、例えば、CD/DVD又は同様の媒体821を伴ったCD/DVD ROM/RW820、サムドライブ822、リムーバブルハードディスク又はソリッドステートドライブ823、レガシー磁気媒体、例えば、テープ及びフロッピー(登録商標)ディスク(図示せず)、専用のROM/ASIC/PLDベースデバイス、例えば、セキュリティドングル(図示せず)、なども含むことができる。
当業者であれば、目下開示されている対象に関連して使用されている語「コンピュータ可読媒体」が、伝送媒体、搬送波、又は他の一時的な信号を含まないことも理解するはずである。
コンピュータシステム800は、1つ以上の通信ネットワークへのインターフェイスも含むことができる。ネットワークは、例えば、無線、有線、光であることができる。ネットワークは更に、ローカル、ワイドエリア、メトロポリタン、車両及び工業、実時間、遅延耐性、などであることができる。ネットワークの例には、イーサネット(登録商標)などのローカルエリアネットワーク、ワイヤレスLAN、GSM、3G、4G、5G、LTEなどを含むセルラーネットワーク、ケーブルTV、衛生TV、及び地上放送TVを含むTV有線又は無線ワイドエリアデジタルネットワーク、CANバスを含む車載及び工場ネットワーク、などがある。特定のネットワークは、一般に、コンピュータシステム800の例えばUSBポートなどの特定の汎用デジタルポート又はペリフェラルバス(849)に取り付けられた外付けネットワークインターフェイスアダプタを必要とする。他は、一般に、後述されるようにシステムバスへの取り付け(例えば、PCコンピュータシステムへのイーサネットネットワーク、又はスマートフォンコンピュータシステムへのセルラーネットワークインターフェイス)によってコンピュータシステム800のコアに組み込まれる。それらのネットワークのいずれかを使用して、コンピュータシステム800は他のエンティティと通信することができる。そのような通信は、単方向の受信専用(例えば、ブロードキャストTV)、単方向の送信専用(例えば、特定のCANバスデバイスへのCANバス)、又は例えば、ローカル若しくはワイドエリアデジタルネットワークを用いて他のコンピュータシステムに対して双方向であることができる。特定のプロトコル又はプロトコルスタックが、上述されたネットワーク及びネットワークインターフェイスの夫々で使用可能である。
上記のヒューマンインターフェイスデバイス、人がアクセス記憶デバイス、及びネットワークインターフェイスは、コンピュータシステム800のコア840へ取り付けられ得る。
コア840は、1つ以上の中央演算処理装置(CPU)841、グラフィクス処理ユニット(GPU)842、フィールドプログラマブルゲートアレイ(FPGA)843の形をとる専用のプログラム可能処理ユニット、特定のタスクのためのハードウェアアクセラレータ844、などを含むことができる。それらのデバイスは、リードオンリーメモリ(ROM)845、ランダムアクセスメモリ(RAM)846、内部のユーザアクセス不能ハードドライブなどの内蔵大容量記憶装置、SSD、など847とともに、システムバス848を通じて接続されてよい。いくつかのコンピュータシステムでは、システムバス848は、更なるCPU、GPUなどによって拡張を可能にするように、1つ以上の物理プラグの形でアクセス可能であることができる。コアのシステムバス848へ直接似又はペリフェラルバス849を通じて、周辺機器が取り付けられ得る。ペリフェラルバスのためのアーキテクチャには、PCI、USBなどがある。
CPU841、GPU842、FPGA843、及びアクセラレータ844は、組み合わせて上記のコンピュータコードを構成することができる特定の命令を実行することができる。そのコンピュータコードは、ROM845又はRAM846に記憶され得る。一時データもRAM846に記憶可能であり、一方、永続データは、例えば、内蔵大容量記憶装置847に記憶可能である。メモリデバイスのいずれかへの高速な格納及び読み出しは、キャッシュメモリの使用により可能にされ得る。キャッシュメモリは、1つ以上のCPU841、GPU842、大容量記憶装置847、ROM845、RAM846などと密接に関連し得る。
コンピュータ可読媒体は、様々なコンピュータ実装動作を実行するためのコンピュータコードを有することができる。媒体及びコンピュータコードは、本開示の目的のために特別に設計及び構成されたものであることができ、あるいは、それらは、コンピュータソフトウェア技術で通常の知識を有するものによく知られており利用可能である種類のものであることができる。
例として、制限なしに、アーキテクチャ800、具体的にはコア840を有するコンピュータシステムは、1つ以上の有形なコンピュータ可読媒体において具現されているソフトウェアを実行するプロセッサ(CPU、GPU、FPGA、アクセラレータ、などを含む)の結果として機能を提供することができる。そのようなコンピュータ可読媒体は、コア内蔵大容量記憶装置847又はROM845などの非一時的な性質であるコア840の特定の記憶装置に加えて、先に紹介されたユーザアクセス可能な大容量記憶装置に関連した媒体であることができる。本開示の様々な実施形態を実装するソフトウェアは、そのようなデバイスに記憶され、コア840によって実行され得る。コンピュータ可読媒体には、特定のニーズに従って、1つ以上のメモリデバイス又はチップが含まれ得る。ソフトウェアは、コア840、具体的にはその中のプロセッサ(CPU、GPU、FPGAなどを含む)に、RAM846に記憶されているデータ構造を定義し、ソフトウェアによって定義されたプロセスに従ってそのようなデータ構造を変更することを含め、本願で記載される特定のプロセス又は特定のプロセスの特定の部分を実行させることができる。加えて、又は代替案として、コンピュータシステムは、本願で記載される特定のプロセス又は特定のプロセスの特定の部分を実行するようにソフトウェアの代わりに又はそれとともに動作することができる、回路内でハードウェアにより実現されるか又は別なふうに具現されるロジックの結果として、機能を提供することができる。ソフトウェアへの言及は、必要に応じて、ロジックを包含することができ、その逆も同様である。コンピュータ可読媒体への言及は、必要に応じて、実行のためのソフトウェアを記憶している回路(例えば、集積回路(IC))、実行のためのロジックを具現する回路、又は両方を包含することができる。本開示は、ハードウェア及びソフトウェアの如何なる適切な組み合わせも包含する。
本開示は、いくつかの例となる実施形態について記載してきたが、本開示の範囲内にある代替、交換、及び様々な置換均等物が存在する。よって、明らかなように、当業者であれば、たとえ本願で明示的に図示又は記載されていなくても、本開示の原理を具現し、よって、その主旨及び適用範囲の中にある多数のシステム及び方法に想到可能である。
[関連出願の相互参照]
本願は、米国特許商標庁において、2018年10月23日付けで出願された米国特許仮出願第62/749283号及び2019年7月8日付けで出願された米国特許出願第16/504443号に対して、35 U.S.C第119条の下で、優先権を主張する。なお、これら米国特許出願の開示は、その全文を参照により本願に援用される。

Claims (20)

  1. デコーダが実行するメディアの復号方法であって、
    第1サブプロファイルに従う符号化されたビデオシーケンスを生成するようビデオシーケンスを符号化するためにエンコーダによって使用可能であり、かつ、前記第1サブプロファイルに従う前記符号化されたビデオシーケンスを復号するために前記デコーダによって使用可能であるツールの第1の定義された組を識別する前記第1サブプロファイルを示す第1指示をシンタックス構造から復号するステップと、
    第2サブプロファイルに従う前記符号化されたビデオシーケンスを生成するよう前記ビデオシーケンスを符号化するために前記エンコーダによって使用可能であり、かつ、前記第2サブプロファイルに従う前記符号化されたビデオシーケンスを復号するために前記デコーダによって使用可能であるツールの第2の定義された組を識別する前記第2サブプロファイルを示す第2指示を前記シンタックス構造から復号するステップと、
    前記第1指示及び前記第2指示のうちの少なくとも1つに基づいて、前記符号化されたビデオシーケンスが前記デコーダによって復号可能であるかどうかを判定するステップと、
    前記符号化されたビデオシーケンスが前記デコーダによって復号可能であるかどうかの判定に基づいて、前記符号化されたビデオシーケンスを選択的に復号するステップと
    を有し、
    前記シンタックス構造は、サブプロファイルの数を示すシンタックス要素を含み、該サブプロファイルのリストを、固定回数の繰り返しを有するループの形で含む、方法。
  2. 前記第1指示は、ITU-T推奨T.35に従って符号化される、
    請求項1に記載の方法。
  3. 前記第1指示は、第1高位シンタックス構造に存在する複数の第1指示のうちの1つであり、
    前記第1高位シンタックス構造は、少なくとも前記符号化されたビデオシーケンスに関係がある、
    請求項2に記載の方法。
  4. 前記複数の第1指示は、第1指示のリストとしてまとめられ、該リスト内の第1指示の数は、可変長さの符号なしコードワードとして前記第1高位シンタックス構造において符号化される、
    請求項3に記載の方法。
  5. 前記第1指示は、第1高位シンタックス構造に存在し、前記第2指示は、第2高位シンタックス構造に存在し、前記第1高位シンタックス構造は、前記第2高位シンタックス構造とは異なる、
    請求項1に記載の方法。
  6. 前記第1指示は、長さが少なくとも3つのオクテットのオクテット列として符号化され、
    前記第1指示は、前記第2指示のサブプロファイルである、
    請求項1に記載の方法。
  7. 前記第1指示及び前記第2指示を結合するステップと、
    前記第1指示及び前記第2指示を結合したことに基づいて、結合されたコンフォーマンスポイントを識別するステップと
    を更に有する、請求項1に記載の方法。
  8. 結合されたコンフォーマンスポイントと前記デコーダのケイパビリティ情報とを比較するステップを更に有し、
    前記符号化されたビデオシーケンスが前記デコーダによって復号可能であるかどうかを判定するステップは、
    前記結合されたコンフォーマンスポイントと前記デコーダの前記ケイパビリティ情報との比較に基づいて、前記符号化されたビデオシーケンスが前記デコーダによって復号可能であるかどうかを判定するステップを有する、
    請求項1に記載の方法。
  9. メディアビットストリームは、前記第1指示及び前記第2指示の両方に対応する、
    請求項1に記載の方法。
  10. 前記符号化されたビデオシーケンスが前記デコーダによって復号可能であると決定するステップを更に有し、
    前記符号化されたビデオシーケンスを選択的に復号するステップは、
    前記符号化されたビデオシーケンスが前記デコーダによって復号可能である決定に基づいて、前記符号化されたビデオシーケンスを復号するステップを有する、
    請求項1に記載の方法。
  11. メディア復号化のためのデバイスであって、
    プログラムコードを記憶するよう構成される少なくとも1つのメモリと、
    前記プログラムコードを読み出し、該プログラムコードによって指示されるように動作するよう構成される少なくとも1つのプロセッサと
    を有し、
    前記プログラムコードは、
    前記少なくとも1つのプロセッサに、
    第1サブプロファイルに従う符号化されたビデオシーケンスを生成するようビデオシーケンスを符号化するためにエンコーダによって使用可能であり、かつ、前記第1サブプロファイルに従う前記符号化されたビデオシーケンスを復号するためにデコーダによって使用可能であるツールの第1の定義された組を識別する前記第1サブプロファイルを示す第1指示をシンタックス構造から復号させ、
    第2サブプロファイルに従う前記符号化されたビデオシーケンスを生成するよう前記ビデオシーケンスを符号化するために前記エンコーダによって使用可能であり、かつ、前記第2サブプロファイルに従う前記符号化されたビデオシーケンスを復号するために前記デコーダによって使用可能であるツールの第2の定義された組を識別する前記第2サブプロファイルを示す第2指示前記シンタックス構造から復号させるよう構成される復号化コードと、
    前記少なくとも1つのプロセッサに、前記第1指示及び前記第2指示のうちの少なくとも1つに基づいて、前記符号化されたビデオシーケンスが前記デコーダとしての当該デバイスによって復号可能であるかどうかを判定させるよう構成される判定コードと、
    前記少なくとも1つのプロセッサに、前記符号化されたビデオシーケンスが当該デバイスによって復号可能であるかどうかの判定に基づいて、前記符号化されたビデオシーケンスを選択的に復号させるよう構成される選択的復号化コードと
    を含み、
    前記シンタックス構造は、サブプロファイルの数を示すシンタックス要素を含み、該サブプロファイルのリストを、固定回数の繰り返しを有するループの形で含む、
    デバイス。
  12. 前記第1指示は、ITU-T推奨T.35に従って符号化される、
    請求項11に記載のデバイス。
  13. 前記第1指示は、第1高位シンタックス構造に存在する複数の第1指示のうちの1つであり、
    前記第1高位シンタックス構造は、少なくとも前記符号化されたビデオシーケンスに関係がある、
    請求項12に記載のデバイス。
  14. 前記複数の第1指示は、第1指示のリストとしてまとめられ、該リスト内の第1指示の数は、可変長さの符号なしコードワードとして前記第1高位シンタックス構造において符号化される、
    請求項13に記載のデバイス。
  15. 前記第1指示は、第1高位シンタックス構造に存在し、前記第2指示は、第2高位シンタックス構造に存在し、前記第1高位シンタックス構造は、前記第2高位シンタックス構造とは異なる、
    請求項11に記載のデバイス。
  16. 前記第1指示は、長さが少なくとも3つのオクテットのオクテット列に符号化され、
    前記第1指示は、前記第2指示のサブプロファイルである、
    請求項11に記載のデバイス。
  17. 前記プログラムコードは、
    前記少なくとも1つのプロセッサに、前記第1指示及び前記第2指示を結合させるよう構成される結合コードと、
    前記少なくとも1つのプロセッサに、前記第1指示及び前記第2指示を結合したことに基づいて、結合されたコンフォーマンスポイントを識別させるよう構成される識別コードと
    を更に含む、
    請求項11に記載のデバイス。
  18. 前記プログラムコードは、前記少なくとも1つのプロセッサに、結合されたコンフォーマンスポイントと当該デバイスのケイパビリティ情報とを比較させるよう構成される比較コードを更に含み、
    前記判定コードは、前記少なくとも1つのプロセッサに、前記結合されたコンフォーマンスポイントと当該デバイスの前記ケイパビリティ情報との比較に基づいて、前記符号化されたビデオシーケンスが当該デバイスによって復号可能であるかどうかを判定させるよう更に構成される、
    請求項11に記載のデバイス。
  19. メディアビットストリームは、前記第1指示及び前記第2指示の両方に対応する、
    請求項11に記載のデバイス。
  20. コンピュータに、請求項1乃至10の何れか一項に記載の方法を実行させるコンピュータプログラム。
JP2021512373A 2018-10-23 2019-10-16 デコーダが実行するメディアの復号方法、メディア復号化のためのデバイス、及びコンピュータプログラム Active JP7139517B2 (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201862749283P 2018-10-23 2018-10-23
US62/749,283 2018-10-23
US16/504,443 US11165847B2 (en) 2018-10-23 2019-07-08 Techniques for multiple conformance points in media coding
US16/504,443 2019-07-08
PCT/US2019/056459 WO2020086347A1 (en) 2018-10-23 2019-10-16 Techniques for multiple conformance points in media coding

Publications (2)

Publication Number Publication Date
JP2021521756A JP2021521756A (ja) 2021-08-26
JP7139517B2 true JP7139517B2 (ja) 2022-09-20

Family

ID=70279887

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2021512373A Active JP7139517B2 (ja) 2018-10-23 2019-10-16 デコーダが実行するメディアの復号方法、メディア復号化のためのデバイス、及びコンピュータプログラム

Country Status (6)

Country Link
US (3) US11165847B2 (ja)
EP (1) EP3777094A4 (ja)
JP (1) JP7139517B2 (ja)
KR (1) KR102635339B1 (ja)
CN (2) CN113273152B (ja)
WO (1) WO2020086347A1 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020122574A1 (ko) 2018-12-13 2020-06-18 에스케이텔레콤 주식회사 코딩 툴 설정 방법 및 영상 복호화 장치
US11556376B2 (en) * 2020-06-24 2023-01-17 Tencent America LLC Signaling timeout and complete data inputs in cloud workflows

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014050059A1 (en) 2012-09-28 2014-04-03 Sharp Kabushiki Kaisha Electronic device for signaling a sub-picture buffer parameter
WO2014055753A1 (en) 2012-10-03 2014-04-10 The Arizona Board Of Regents For And On Behalf Of Arizona State University Systems and mehtods for tendon-driven robotic mechanisms

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5719632A (en) * 1996-01-25 1998-02-17 Ibm Corporation Motion video compression system with buffer empty/fill look-ahead bit allocation
US7149247B2 (en) * 2002-01-22 2006-12-12 Microsoft Corporation Methods and systems for encoding and decoding video data to enable random access and splicing
KR100983832B1 (ko) * 2002-04-26 2010-09-27 소니 주식회사 부호화 장치 및 방법, 그리고 기록 매체
US20070189732A1 (en) * 2006-02-10 2007-08-16 Sai Pothana System and method for reconstructing MPEG-2 start codes from AVC data
JP2008199587A (ja) * 2007-01-18 2008-08-28 Matsushita Electric Ind Co Ltd 画像符号化装置、画像復号化装置および方法
US8358331B2 (en) * 2008-12-02 2013-01-22 Lg Electronics Inc. 3D caption display method and 3D display apparatus for implementing the same
US9197676B2 (en) * 2010-01-14 2015-11-24 Blackberry Limited System and method for reducing message signaling
CN103314591B (zh) * 2011-01-14 2017-02-08 维德约股份有限公司 时间可缩放性的高层句法
US9787979B2 (en) * 2012-04-06 2017-10-10 Vidyo, Inc. Level signaling for layered video coding
US20140098851A1 (en) * 2012-10-04 2014-04-10 Qualcomm Incorporated Indication of video properties
KR102186012B1 (ko) * 2014-02-05 2020-12-04 애플 인크. 제어기와 액세서리 사이의 통신을 위한 균일한 통신 프로토콜
US9712837B2 (en) * 2014-03-17 2017-07-18 Qualcomm Incorporated Level definitions for multi-layer video codecs
US10070130B2 (en) * 2015-01-30 2018-09-04 Qualcomm Incorporated Flexible partitioning of prediction units
US10440401B2 (en) * 2016-04-07 2019-10-08 Dolby Laboratories Licensing Corporation Backward-compatible HDR codecs with temporal scalability
US10904574B2 (en) * 2018-09-13 2021-01-26 Tencent America LLC Method and device using an out of band end of stream NAL unit in decoding
US11778215B2 (en) * 2020-02-28 2023-10-03 Qualcomm Incorporated Coding output layer set data and conformance window data of high level syntax for video coding

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014050059A1 (en) 2012-09-28 2014-04-03 Sharp Kabushiki Kaisha Electronic device for signaling a sub-picture buffer parameter
WO2014055753A1 (en) 2012-10-03 2014-04-10 The Arizona Board Of Regents For And On Behalf Of Arizona State University Systems and mehtods for tendon-driven robotic mechanisms

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
Jill Boyce, Xavier Ducloux, Arianne Hinds, and Stephan Wenger,Interoperability point signaling for VVC,Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11,JVET-K0311v1,11th Meeting: Ljubljana, SI,2018年07月,pp.1-4
Jill Boyce, Zhipin Deng, Sam Wong, and Lidong Xu,AHG15: Proposed interoperability point syntax,Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11,JVET-L0044-v1,12th Meeting: Macao, CN,2018年09月,pp.1-6

Also Published As

Publication number Publication date
JP2021521756A (ja) 2021-08-26
KR102635339B1 (ko) 2024-02-08
US20210400105A1 (en) 2021-12-23
EP3777094A4 (en) 2021-12-15
US11165847B2 (en) 2021-11-02
US20200128062A1 (en) 2020-04-23
CN113273152B (zh) 2022-04-05
KR20200140857A (ko) 2020-12-16
EP3777094A1 (en) 2021-02-17
CN114827103A (zh) 2022-07-29
US20230023702A1 (en) 2023-01-26
CN114827103B (zh) 2024-05-17
US11522940B2 (en) 2022-12-06
WO2020086347A1 (en) 2020-04-30
CN113273152A (zh) 2021-08-17

Similar Documents

Publication Publication Date Title
KR20210102451A (ko) 랜덤 액세스 포인트 및 픽처 유형의 식별 방법
JP7434499B2 (ja) ネットワーク抽象化ユニットヘッダからのタイルの識別化
US20230023702A1 (en) Techniques for multiple conformance points in media coding
JP7288081B2 (ja) ビデオビットストリームを復号する方法、装置、及びプログラム
JP7278681B2 (ja) 可逆圧縮及び準可逆圧縮用量子化器
JP2022510325A (ja) 符号化ビデオストリームを復号するための方法、システム、及びコンピュータプログラム
JP2023088998A (ja) ビデオ符号化のための復号されたピクチャバッファ管理
JP7254188B2 (ja) 点群符号化のためのパラメータセット設計の方法並びにその装置及びプログラム
US20230075516A1 (en) System and method for decoding including network abstraction layer unit structure with picture header
JP7342125B2 (ja) ネットワーク抽象化レイヤユニットヘッダ
CN113491128B (zh) 已解码图片存储器管理的方法和相关装置
JP2024516010A (ja) Dashにおけるvvcサブピクチャに注釈を付ける方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20201104

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20211215

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20220104

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20220323

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20220419

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20220714

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

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20220809

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20220907

R150 Certificate of patent or registration of utility model

Ref document number: 7139517

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150