特許 7493533 アクセスユニット境界を識別するための方法、デバイスおよびコンピュータプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-05-23

(45)【発行日】2024-05-31

(54)【発明の名称】アクセスユニット境界を識別するための方法、デバイスおよびコンピュータプログラム

(51)【国際特許分類】

   H04N 21/4385 20110101AFI20240524BHJP

   H04N 19/70 20140101ALI20240524BHJP

【ＦＩ】

H04N21/4385

H04N19/70

【請求項の数】 5

(21)【出願番号】P 2021561992

(86)(22)【出願日】2020-10-05

(65)【公表番号】

(43)【公表日】2022-06-21

(86)【国際出願番号】 US2020054246

(87)【国際公開番号】W WO2021173190

(87)【国際公開日】2021-09-02

【審査請求日】2021-10-18

(31)【優先権主張番号】62/980,659

(32)【優先日】2020-02-24

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】17/026,781

(32)【優先日】2020-09-21

(33)【優先権主張国・地域又は機関】US

【前置審査】

(73)【特許権者】

【識別番号】520353802

【氏名又は名称】テンセント・アメリカ・エルエルシー

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広 信哉

(74)【代理人】

【識別番号】100150197

【弁理士】

【氏名又は名称】松尾 直樹

(72)【発明者】

【氏名】ビョンドゥ・チェ

(72)【発明者】

【氏名】ステファン・ヴェンガー

(72)【発明者】

【氏名】シュアイ・ジャオ

【審査官】醍醐 一貴

(56)【参考文献】

【文献】特開２００６－２９５５６８（ＪＰ，Ａ）

【文献】特開２００９－１７１２９４（ＪＰ，Ａ）

【文献】改訂三版Ｈ．２６４／ＡＶＣ教科書，第1版，株式会社インプレスＲ＆Ｄ，2009年01月01日，P.100-101

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｎ ２１／００－２１／８５８

Ｈ０４Ｎ １９／００－１９／９８

(57)【特許請求の範囲】

【請求項1】

プロセッサが、符号化ビデオビットストリームにおけるアクセスユニット（AU）境界を識別する方法であって、
少なくとも2つのネットワーク抽象化レイヤ（NAL）ユニットの各々からの少なくとも1つのフィールドからの情報を取得するステップであって、前記少なくとも2つのNALユニットは、nalXユニットおよびnalYユニットを含む、ステップと、
前記nalYユニットのNALユニットタイプの値がピクチャヘッダタイプを示し、かつ、
前記nalXユニットと前記nalYユニットとの間のすべてのNALユニットがパラメータセットまたはSEIのNALタイプであるか否か
を判定するステップと、
前記nalYユニットのNALユニットタイプの値がピクチャヘッダタイプを示し、かつ、前記nalXユニットと前記nalYユニットとの間のすべてのNALユニットがパラメータセットまたはSEIのNALタイプである場合、前記nalXユニットが現在AUの最後のNALユニットであると判定するステップと
を含む方法。

【請求項2】

前記nalYユニットのNALユニットタイプの値がピクチャヘッダタイプを示し、かつ、前記nalXユニットと前記nalYユニットとの間のすべてのNALユニットがパラメータセットまたはSEIのNALタイプであるか否かを判定するステップの前に、
前記nalYユニットのNALユニットタイプの値がAUD＿NUTを示すか否かを判定するステップと、
前記nalYユニットのNALユニットタイプの値がAUD＿NUTを示すと判定される場合、前記nalXユニットが現在AUの最後のNALユニットであると判定するステップと
をさらに含む、請求項1に記載の方法。

【請求項3】

前記nalYユニットのNALユニットタイプの値がAUD＿NUTを示すか否かを判定するステップの前に、
前記nalXユニットが前記符号化ビデオビットストリームにおける最後のNALユニットであるか否かを判定するステップと、
前記nalXユニットが前記符号化ビデオビットストリームにおける最後のNALユニットであると判定される場合、前記nalXユニットが現在AUの最後のNALユニットであると判定するステップと
をさらに含む、請求項2に記載の方法。

【請求項4】

符号化ビデオビットストリームにおけるアクセスユニット（AU）境界を識別するためのデバイスであって、
プログラムコードを記憶するように構成された少なくとも1つのメモリと、
前記プログラムコードを読み出し、前記プログラムコードによって命令されるように動作するよう構成された少なくとも1つのプロセッサであって、前記プログラムコードは、請求項1～3のいずれか一項に記載の方法を実行させるためのコードを含む、少なくとも1つのプロセッサと
を備えるデバイス。

【請求項5】

少なくとも1つのプロセッサに、請求項1～3のいずれか一項に記載の方法を実行させるためのコンピュータプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

関連出願の相互参照
本出願は、2020年2月24日に出願された米国仮特許出願第62／980，659号および2020年9月21日に出願された米国特許出願第17／026，781号の優先権を主張し、それらの全体は本明細書に組み込まれる。

【0002】

開示されている主題は、IPネットワークを介してビデオを配信するためのネットワークプロトコルに関し、より具体的には、ビデオペイロードフォーマットのフレームの個別のアクセスをサポートするためのアクセスユニット（フレーム）境界情報のシグナリングに関する。

【背景技術】

【0003】

図1を参照すると、ネットワーク接続システムは、声、ビデオ、および／または他のメディアなどのリアルタイムメディアを使用して、インターネットなどのIPネットワーク（104）を介して互いに通信する1つ以上のエンドポイント（101、102、103）を備えうる。システムは、例えばエンドポイントによって送信されたメディアを、別のエンドポイントに転送する前に操作するように構成された1つ以上のメディア認識ネットワーク要素（105）をさらに備えうる。

【0004】

特定のそのようなシステム設計では、エンドポイントおよび／またはモバイルアドホックネットワークエミュレータ（MANE：Mobile Ad－hoc Network Emulator）は、例えば別のエンドポイントまたはMANEに配置されたリアルタイムトランスポートプロトコル（RTP：Real－time Transport Protocol）受信機にネットワークを介してRTPパケットを送信するRTPパケット化器を備えうる。場合によっては、送信エンドポイントは、ビデオエンコーダに機能的に結合されたビデオカメラを損なう可能性があり、そしてまたビデオエンコーダは、パケット化器に結合されえ、その結果、ビデオカメラによってキャプチャされたビデオは、RTPパケットを使用して送信エンドポイント、例えばエンドポイント（101）からネットワーク（104）を介して受信エンドポイント、例えば102）に転送されうる。

【0005】

場合によっては、送信エンドポイントはビデオエンコーダを含まなくてもよい。代わりに、ビデオは、エンドポイント（101）に結合されたハードドライブなど（106）に記憶されたファイルから取得されてもよい。

【0006】

インターネットおよび他のIPネットワークを介したビデオのための特定のリアルタイム通信技術は、RFC3550に規定されているリアルタイムトランスポートプロトコル（RTP）に依拠しうる。場合によっては、RTPパケットは、IPを介してユーザデータグラムプロトコル（UDP：User Datagram Protocol）を介してあるエンドポイントまたはMANEから別のエンドポイントまたはMANEに転送されてもよい。図2を参照すると、RFC3550に規定されているRTPヘッダ構造が示されている。ここで、各RTPパケットは、RTPパケットヘッダから始まりうる。図2は、RFC3550に規定されているRTPヘッダのフォーマットを示している。

【0007】

図2に示されているように、バージョン（V）フィールド（201）は、RTPのバージョンを識別しえ、2に等しくありうる。パディング（P）フィールド（202）は、パケットが最後に1つ以上の追加のパディングオクテットを含むかどうかを指定しうる。拡張（X）フィールド（203）は、固定ヘッダの後に正確に1つのヘッダ拡張が続くかどうかを示しうる。CSRCカウント（CC）フィールド（204）は、固定ヘッダの後に続くCSRC識別子の数を含みうる。マーカ（M）フィールド（205）は、パケットストリームにおけるAU境界などの重要なイベントのマーキングを可能にしうる。ペイロードタイプ（PT：Payload Type）フィールドは、ペイロードタイプ（206）、つまり、RFC3984パラメータの特定のセットと共にRTPペイロードフォーマットRFC6184を使用してITU－T勧告H．264に従って符号化されたビデオなどの使用中のメディアのタイプを示しうる。PTは、多くの場合、呼制御プロトコルによって選択されうる。RTPシーケンス番号（207）は、ラップアラウンドまで送信されるRTPパケットごとに1ずつ大きくなりうる。RTPタイムスタンプ（208）は、パケットの最初のサンプルがサンプリングされた時刻（キャプチャ時間）を示しえ、一般にプレゼンテーション時間として使用されうる。少なくとも一部のビデオコーデックのタイムスタンプは90kHzでありうるが、多くの音声コーデックでは、タイムスタンプは8kHz、44．1kHz、または48 kHzなどのサンプリングレートに等しくありうる。同期ソース（209）および貢献ソース（210）は以下で導入される。

【0008】

RTPは、アプリケーションレイヤフレーミングの一般的な手法に従ってもよく、したがって、特定のビデオ符号化規格に従って指定された符号化ビデオフォーマットなどの特定のペイロードへの適応は、RTPペイロードフォーマットとして知られる主なRTP仕様外の補助仕様によって指定されうる。特定のRTPペイロードフォーマットは、H．264またはH．265などの特定のビデオ符号化規格に存在するようなネットワーク抽象化ヘッダのビットをそれらのペイロードヘッダとして再利用しうる。そのようなRTPペイロードフォーマットおよびビデオ符号化規格では、ネットワーク抽象化レイヤユニット（NALユニットまたはNALU）は、1つの符号化ピクチャまたはその明確に定義された部分、例えばスライス、タイル、およびGOBなどを含む有限サイズのビットストリームでありうる。

【0009】

ビットストリームは、その始めに、含まれるビットストリームのタイプに関連する最小限の情報および一部のシナリオではレイヤリング情報を含む、例えば8または16ビット長の比較的短いデータ構造を含みうる。

【0010】

少なくとも一部のビデオ符号化規格は、アクセスユニット（AU：Access Unit）の概念を認めている。単一レイヤの場合、アクセスユニットは、単一の符号化ピクチャから構成されうる。他の場合、特にレイヤ符号化およびマルチビュー符号化に関連する場合、AUは、例えば同じプレゼンテーション時間を有する特定のタイミング情報を共有する複数の符号化ピクチャを含みうる。

【0011】

RTPヘッダは、いわゆる「マーカ」ビット（Mビット）（205）を含みうる。慣例により、AUの概念を認めている実質的にすべてのRTPペイロードフォーマットにおいて、Mビットは、AUの最後のビットストリームを搬送するRTPパケットに対しては、1に等しいと指定されており、そうでなければ0に設定されうる。受信機は、Mビットが設定されたRTPパケットを受信すると、通常、このRTPパケットがAUの最後のパケットであることを認識し、それに応じてそれを処理しうる。そのような処理のいくつかの詳細は、RTP仕様に見出されうる。

【0012】

再び図1を簡単に参照すると、送信エンドポイント（101）が記憶デバイス／ハードドライブ（106）からその送信ビデオビットストリームを取得すると仮定すると、そのようなファイルは、例えばビットストリームが、例えば一般に「Annex Bのビットストリーム」として知られるフォーマットで記憶されうるため、アクセスユニット境界に関する容易にアクセス可能なメタ情報を含まない場合がある。そのようなシナリオでは、ビットストリームのビットストリームがAUの最終ビットストリームであることをシグナリングする利用可能な、エンコーダからRTPパケット化器へのアプリケーションプログラマインターフェース（API：Application Programmer’s Interface）情報が存在しない場合がある。代わりに、RTPパケット化器は、エンコーダによって通常取得可能なサイド情報なしでAUの最後を含むビットストリームを識別しなければならない場合がある。

【発明の概要】

【課題を解決するための手段】

【0013】

ビデオRTPペイロードフォーマットにおけるアクセスユニット境界のシグナリングおよび識別のための技術が開示される。

【0014】

開示されている主題のさらなる特徴、性質、および様々な利点は、以下の詳細な説明および添付の図面からより明らかになる。

【図面の簡単な説明】

【0015】

【図1】RTPを使用するメディア送信システムの概略図である。

【図2】RTPヘッダの概略図である。

【図3】ビット境界の実施形態を有するVVCのNALユニットヘッダの概略図である。

【図4】簡略化されたブロック図のアクセスユニット境界検出の概略図である。

【図5】一実施形態によるコンピュータシステムの概略図である。

【発明を実施するための形態】

【0016】

解決すべき課題
リアルタイムトランスポートプロトコル（RTP）は、ストリーミングメディアを利用する通信システムで使用されうる。Joint Video Experts Team（JVET）によって開発された、どちらも多用途ビデオ符号化（VVC：Versatile Video Coding）としても知られる符号化規格ITU－T勧告［H．266］およびISO／IEC国際規格［ISO23090－3］に準拠したビデオデータを搬送するためのRTPペイロードフォーマットが近年注目されている。RTPペイロードフォーマットは、各RTPパケットペイロード内の1つ以上のネットワーク抽象化レイヤ（NAL：Network Abstraction Layer）ユニットのパケット化、および複数のRTPパケットへのNALユニットの断片化を可能にする。VVCビデオ符号化は、開始コードを越えるフレーミング情報なしで、1つの長いビットストリームとしてファイルに格納されうる。このバイストリームの実質的にすべての詳細を解析しないと、RTPパケット化器は、RTPおよびRTPペイロード仕様によって要求されるようにMビットを正しく設定することができない。

【0017】

一実施形態では、マーカビットが1に等しく設定されるとき、それは、現在のパケットが現在のRTPストリーム内のアクセスユニット（AU）の最後のパケットでありうることを示しうる。マーカビットが0に等しく設定されるとき、それは、現在のパケットがアクセスユニットの最後のパケットではありえないことを示しうる。マーカビットのそのような使用は、ビデオ用の実質的にすべての現在指定されているRTPペイロードフォーマットにおけるマーカビットの一般的な使用と一致する。

【0018】

図3を参照すると、同じまたは別の実施形態において、VVC NALユニットヘッダは、2バイト（16ビット）から構成されうる。ここで、5ビットは、NALユニットタイプ（304）を表す。結果として、最大で32個のタイプのNALユニットが存在しうる。ビデオ符号化レイヤ（VCL：Video Coding Layer）NALユニットは、0から12の数値範囲内のタイプを有しえ、非VCL NALユニットは、13から31の範囲内のタイプを有しうる。forbidden＿zero＿bit（Fビット、301）は、開始コードエミュレーションを防止するために0に設定される必要がありうる。nuh－reserved－bit（Zビット、302）は、0に設定され、ITUおよびISO／IECによる将来の拡張のために予約される必要がありうる。nuh－layer－id（レイヤID、303）は、空間スケーラブルレイヤまたは品質スケーラブルレイヤなど、NALユニットが属するレイヤを識別するために使用されうる。nal－unit－type（タイプ、304）フィールドは、VVC仕様に基づいてNALタイプおよびセマンティクスを指定しうる。最後のnuh－temporal－id－plus1（TID、305）フィールドは、0のTID値が不正でありうるため、TemporalIdに1を加えた値でありうる。これは、1つのNALがコードエミュレーションのために少なくとも1ビットでなければならないことを保証することである。

【0019】

同じまたは別の実施形態において、NALユニットのコンテンツは、少なくとも、場合によっては多くの他のNALユニットを解析することなく、NALユニットが復号順でAUの最後のNALユニットであるかどうかを知らせえない。したがって、サイド情報なしでは、パケット化器は、ビデオビットストリームからその情報を単独で簡単に取得しえない例えばリアルタイム符号化の文脈では、RTP送信器の実施態様は、例えばAPIを介してビデオエンコーダまたは他のシステム要素からこの情報を取得しうる。しかしながら、Annex Bのビットストリームがストリーミング前にハードドローブに記憶される上記で言及したシナリオを含めて、そのようなAPIも利用できないシナリオがありうる。この情報がエンコーダまたは他のシステム要素から明示的に取得されえない場合、送信器の実施態様は、NALユニットがアクセスユニットの最後のNALユニットであるかどうかを判定するために、復号においてNALユニットヘッダ（および場合によってはNALユニットのペイロードデータも）を解釈する必要がありうる。そのような情報を取得するために使用されるこのおよび他の新規な技術が以下に説明される。

【0020】

アクセスユニット境界をシグナリングおよび識別するための技術が、図4に示されている。図4を参照すると、同じまたは別の実施形態において、NALユニットは、それがビットストリームの最後のNALユニットである場合、AUの最後のNALユニットであると判定されうる。

【0021】

また、図4を参照すると、NALユニットがAUの最後のNALユニットであるかどうかを判定するための実施形態が示されている。ここで、プロセスは、復号キュー（402）に2つのNALユニット、すなわちnalXユニットおよびnalYユニットが存在するときに開始されうる（401）。ここで、目標は、nalXがAUの最後のビットストリームであるかどうか、またはnalYが次のAUの先頭であるかどうかを判断することである。nalXユニットがこのビットストリームの最後のNALユニットである場合（～d03）、nalXは現在のAUの最後のNALユニットであるという結論が下されうる（407）。しかしながら、そうでない場合、以下のプロセスが続けられうる。

【0022】

具体的には、NALユニットタイプ値が20であり、nalYがAUD＿NUTのタイプである場合（404）、nalXが現在のAUの最後のNALユニットであることは確実である。nalYがAUD＿NUTのNALタイプではなく、nalYがピクチャヘッダタイプユニットを有し、さらにnalXとnalYとの間のすべてのNALユニットがパラメータセットまたはSEIのNALタイプである場合、nalXは現在のAUの最後のNALユニットであると判定され、そうでない場合、nalXは最後のNALユニットではないと判定される（406）。

【0023】

以下の条件の両方が真である場合、すなわち、1）復号順序における次のVCL NALユニットnaluYが、1に等しい、そのNALユニットヘッダの後の最初のバイトの上位ビットを有するか、またはnal＿unit＿type（304）が19に等しい、および2）存在するとき、naluXとnaluYとの間のすべてのNALユニットが、13から17の範囲（両端を含む）内の、20に等しい、23に等しい、または26に等しいnal＿unit＿type（304）を有する、の両方が真である場合に、NALユニットnaluXはまた、AUの最後のNALユニットであると判定されうる。

【0024】

同じまたは異なる実施形態において、以下の条件の両方が真である場合、すなわち、1）復号順序における次のVCL NALユニットnaluYが、スライスセグメントヘッダ内に1に等しいpicture＿header＿in＿slice＿header＿flagを有するか、またはnal＿unit＿typeがPH＿NUTに等しく設定されている、および2）存在するとき、naluXとnaluYとの間のすべてのNALユニットが、DCI＿NUT、VPS＿NUT、SPS＿NUT、PPS＿NUT、PREFIX＿APS＿NUT、AUD＿NUT、PREFIX＿SEI＿NUTに等しく設定されたnal＿unit＿typeを有する、の両方が真である場合に、NALユニットnaluXはまた、アクセスユニットの最後のNALユニットであると判定されうる。

【0025】

同じまたは別の実施形態において、NALユニットnaluXはまた、復号順序における次のVCL NALユニットnaluYがAUD＿NUTに等しいnal＿unit＿typeを有する場合に、アクセスユニットの最後のNALユニットであると判定されうる。

【0026】

上記で説明した、符号化ビデオビットストリームにおけるアクセスユニット（AU）境界を識別するための技術は、コンピュータ可読命令を使用してコンピュータソフトウェアとして実施されえ、1つ以上のコンピュータ可読媒体に物理的に記憶されうる。例えば、図5は、開示されている主題の特定の実施形態を実施するのに適したコンピュータシステム500を示している。

【0027】

コンピュータソフトウェアは、任意の適切なマシンコードまたはコンピュータ言語を使用してコード化されえ、それらは、コンピュータ中央処理装置（CPU：central processing unit）およびグラフィック処理装置（GPU：Graphics Processing Unit）などによって、解釈およびマイクロコード実行などを介してまたは直接実行されうる命令を含むコードを作成するためにアセンブル、コンパイル、またはリンクなどのメカニズムを受けうる。

【0028】

命令は、例えばパーソナルコンピュータ、タブレットコンピュータ、サーバ、スマートフォン、ゲーミングデバイス、およびモノのインターネットデバイスなどを含む様々なタイプのコンピュータまたはそのコンポーネント上で実行されうる。

【0029】

コンピュータソフトウェアは、任意の適切なマシンコードまたはコンピュータ言語を使用してコード化されえ、それらは、コンピュータ中央処理装置（CPU：central processing unit）およびグラフィック処理装置（GPU：Graphics Processing Unit）などによって、解釈およびマイクロコード実行などを介してまたは直接実行されうる命令を含むコードを作成するためにアセンブル、コンパイル、またはリンクなどのメカニズムを受けうる。

【0030】

命令は、例えばパーソナルコンピュータ、タブレットコンピュータ、サーバ、スマートフォン、ゲーミングデバイス、およびモノのインターネットデバイスなどを含む様々なタイプのコンピュータまたはそのコンポーネント上で実行されうる。

【0031】

コンピュータシステム～～500に関して図5に示されているコンポーネントは、本質的に例示であり、本開示の実施形態を実施するコンピュータソフトウェアの使用または機能の範囲に関する制限を示唆することを意図していない。コンポーネントの構成も、コンピュータシステム500の例示的な実施形態に示されているコンポーネントのいずれか1つまたは組み合わせに関する依存性または要件を有すると解釈されるべきではない。

【0032】

コンピュータシステム500は、特定のヒューマンインターフェース入力デバイスを含みうる。そのようなヒューマンインターフェース入力デバイスは、例えば触覚入力（キーストローク、スワイプ、データグローブの動きなど）、音声入力（声、拍手など）、視覚入力（ジェスチャなど）、嗅覚入力（図示せず）を用いた1人以上の人間のユーザによる入力に応答しうる。ヒューマンインターフェースデバイスは、音声（会話、音楽、環境音など）、画像（スキャン画像、静止画像カメラから取得される写真画像など）、ビデオ（2次元ビデオ、立体ビデオを含む3次元ビデオなど）など、必ずしも人間による意識的な入力に直接関連しない特定のメディアをキャプチャするためにも使用されうる。

【0033】

入力ヒューマンインターフェースデバイスは、キーボード501、マウス502、トラックパッド503、タッチスクリーン510、データグローブ504、ジョイスティック505、マイクロフォン506、スキャナ507、カメラ508（それぞれ示されているのは1つのみである）のうちの1種類以上を含みうる。

【0034】

コンピュータシステム500はまた、特定のヒューマンインターフェース出力デバイスを含みうる。そのようなヒューマンインターフェース出力デバイスは、例えば触覚出力、音、光、および臭い／味によって1人以上の人間のユーザの感覚を刺激しうる。そのようなヒューマンインターフェース出力デバイスは、触覚出力デバイス（例えば、タッチスクリーン510、データグローブ504、またはジョイスティック505による触覚フィードバックであるが、入力デバイスとして機能しない触覚フィードバックデバイスも存在しうる）、音声出力デバイス（スピーカ509、ヘッドホン（図示せず）など）、視覚出力デバイス（CRTスクリーン、LCDスクリーン、プラズマスクリーン、OLEDスクリーン（それぞれタッチスクリーン入力機能を有するかまたは有さず、それぞれ触覚フィードバック機能を有するかまたは有さず、これらのうちのいくつかは、2次元視覚出力、または立体出力などの手段による3次元以上の出力を出力することができうる）を含むスクリーン510、仮想現実メガネ（図示せず）、ホログラフィックディスプレイ、およびスモークタンク（図示せず）など）、ならびにプリンタ（図示せず）を含みうる。

【0035】

コンピュータシステム500はまた、CD／DVDなどの媒体521を伴うCD／DVD ROM／RW520を含む光学媒体、サムドライブ522、リムーバブルハードドライブまたはソリッドステートドライブ523、テープおよびフロッピーディスクなどのレガシー磁気媒体（図示せず）、ならびにセキュリティドングルなどの専用ROM／ASIC／PLDベースのデバイス（図示せず）など、人間がアクセス可能な記憶デバイスおよびそれらの関連媒体を含みうる。

【0036】

当業者はまた、本開示の主題に関連して使用される「コンピュータ可読媒体」という用語が、送信媒体、搬送波、または他の一時的信号を必ずしも包含しないことを理解すべきである。

【0037】

コンピュータシステム500はまた、1つ以上の通信ネットワークへのインターフェースを含みうる。ネットワークは、例えば無線、有線、光ネットワークでありうる。ネットワークはさらに、ローカル、広域、メトロポリタン、車両および産業、リアルタイム、ならびに遅延耐性ネットワークなどでありうる。ネットワークの例は、イーサネット、無線LANなどのローカルエリアネットワーク、GSM、3G、4G、5G、およびLTEなどを含むセルラーネットワーク、ケーブルTV、衛星TV、および地上波放送TVを含むTV有線または無線広域デジタルネットワーク、ならびにCANBusを含む車両および産業用などを含む。特定のネットワークは、一般に、特定の汎用データポートまたは周辺バス（549）（例えば、コンピュータシステム500のUSBポートなどに取り付けられた外部ネットワークインターフェースアダプタを必要とし、他は、一般に、以下に説明されるようにシステムバスへの取り付けによってコンピュータシステム500のコアに一体化される（例えば、PCコンピュータシステムへのイーサネットインターフェースまたはスマートフォンコンピュータシステムへのセルラーネットワークインターフェース）。これらのネットワークのいずれかを使用して、コンピュータシステム500は他のエンティティと通信しうる。そのような通信は、例えば、ローカルエリアデジタルネットワークまたは広域デジタルネットワークを使用する、他のコンピュータシステムに対する、単方向、受信のみ（例えば、放送TV）、単方向送信のみ（例えば、特定のCANbusデバイスへのCANbus）、または双方向の通信でありうる。特定のプロトコルおよびプロトコルスタックは、上記で説明したように、それらのネットワークおよびネットワークインターフェースの各々で使用されうる。

【0038】

前述のヒューマンインターフェースデバイス、人間がアクセス可能な記憶デバイス、およびネットワークインターフェースは、コンピュータシステム500のコア540に取り付けられうる。

【0039】

コア540は、1つ以上の中央処理装置（CPU）541、グラフィック処理装置（GPU）542、フィールドプログラマブルゲートエリア（FPGA：Field Programmable Gate Area）543の形態の専用プログラマブル処理装置、および特定のタスク用のハードウェアアクセラレータ544などを含みうる。これらのデバイスは、読み出し専用メモリ（ROM：Read－only memory）545、ランダムアクセスメモリ546、非ユーザアクセス可能内部ハードドライブおよびSSDなどの内部大容量ストレージ547と共に、システムバス548を介して接続されうる。一部のコンピュータシステムでは、システムバス548は、追加のCPUおよびGPUなどによる拡張を可能にするために、1つ以上の物理プラグの形態でアクセス可能でありうる。周辺デバイスは、コアのシステムバス548に直接取り付けられうるし、または周辺バス549を介して取り付けられうる。周辺バスのアーキテクチャは、PCIおよびUSBなどを含む。

【0040】

CPU541、GPU542、FPGA543、およびアクセラレータ544は、組み合わさって前述のコンピュータコードを構成しうる特定の命令を実行しうる。そのコンピュータコードは、ROM545またはRAM546に記憶されうる。一時データもまた、RAM546に記憶されえ、一方、永久データは、例えば内部大容量ストレージ547に記憶されうる。メモリデバイスのいずれかへの高速記憶および検索は、1つ以上のCPU541、GPU542、大容量ストレージ547、ROM545、およびRAM546などに密接に関連付けられうるキャッシュメモリの使用によって可能になりうる。

【0041】

コンピュータ可読媒体は、様々なコンピュータ実施動作を実行するためのコンピュータコードを有しうる。媒体およびコンピュータコードは、本開示の目的のために特別に設計および構成されたものであってもよいし、またはそれらは、コンピュータソフトウェア技術の当業者に周知の利用可能な種類のものであってもよい。

【0042】

限定としてではなく、一例として、コンピュータシステム500およびコア540は、1つ以上の有形のコンピュータ可読媒体で具体化されたソフトウェアを実行するプロセッサ（CPU、GPU、FPGA、およびアクセラレータなどを含む）の結果として機能を提供しうる。そのようなコンピュータ可読媒体は、コア内部の大容量ストレージ547またはROM545などの、上記で導入したようなユーザアクセス可能な大容量ストレージ、および非一時的な性質の、コア540の特定のストレージに関連付けられる媒体でありうる。本開示の様々な実施形態を実施するソフトウェアは、そのようなデバイスに記憶され、コア540によって実行されうる。コンピュータ可読媒体は、特定の必要性に応じて、1つ以上のメモリデバイスまたはチップを含みうる。ソフトウェアは、コア540、特にその中のプロセッサ（CPU、GPU、およびFPGAなどを含む）に、RAM546に記憶されたデータ構造を定義すること、およびソフトウェアによって定義されたプロセスに従ってそのようなデータ構造を修正することを含む、本明細書で説明されている特定のプロセスまたは特定のプロセスの特定の部分を実行させうる。加えてまたは代替として、コンピュータシステムは、本明細書で説明されている特定のプロセスまたは特定のプロセスの特定の部分を実行するためにソフトウェアの代わりに、またはソフトウェアと共に動作しうる、回路内のハードワイヤード論理または他の方法で具体化された論理（例えば、アクセラレータ544）の結果として機能を提供しうる。ソフトウェアへの言及は、適切な場合には、論理を包含しえ、逆もまた同様である。コンピュータ可読媒体への言及は、適切な場合には、実行のためのソフトウェアを記憶する回路（集積回路（IC：integrated circuit）など）、実行のための論理を具体化した回路、またはその両方を包含しうる。本開示は、ハードウェアとソフトウェアとの任意の適切な組み合わせを包含する。

【0043】

本開示はいくつかの例示的な実施形態を説明してきたが、本開示の範囲内にある変更例、置換例、および様々な代替の均等例が存在する。したがって、当業者が、本明細書に明示的に図示または説明されていないが、本開示の原理を具体化し、したがってその精神および範囲内にある多数のシステムおよび方法を考案することができることが理解されよう。

【符号の説明】

【0044】

101 エンドポイント
102 エンドポイント
103 エンドポイント
104 IPネットワーク
105 メディア認識ネットワーク要素
106 ハードドライブ
201 バージョン（V）フィールド
202 パディング（P）フィールド
203 拡張（X）フィールド
204 CSRCカウント（CC）フィールド
205 マーカ（M）フィールド
206 ペイロードタイプ
207 RTPシーケンス番号
208 RTPタイムスタンプ
209 同期ソース
210 貢献ソース
301 Fビット
302 Zビット
303 レイヤID
304 NALユニットタイプ
305 TID
500 コンピュータシステム
501 キーボード
502 マウス
503 トラックパッド
504 データグローブ
505 ジョイスティック
506 マイクロフォン
507 スキャナ
508 カメラ
509 スピーカ
510 スクリーン／タッチスクリーン
520 CD／DVD ROM／RW
521 媒体
522 サムドライブ
523 リムーバブルハードドライブまたはソリッドステートドライブ
540 コア
541 CPU
542 GPU
543 FPGA
544 アクセラレータ／ハードウェアアクセラレータ
545 ROM
546 ランダムアクセスメモリ
547 内部大容量ストレージ
548 システムバス
549 周辺バス
550 グラフィックアダプタ
554 ネットワークインターフェース

【図1】

【図2】

【図3】

【図4】

【図5】