マルチフォーマットビデオ処理のためのコンフィギュレーションバッファ割当
【課題】異なるビデオコーデックフォーマットに関連する少なくとも２つのビデオリードストリームの処理をサポートするよう共有バッファを動的に構成することを含むシステム及び方法が開示される。
【解決手段】本方法は、一方のリードストリームに関連するメモリリクエストに応答して、共有バッファ内のバッファライトアドレスを決定するステップと、他方のリードストリームに関連するメモリリクエストに応答して、共有バッファ内の異なるバッファライトアドレスを決定するステップとを有する。
【解決手段】本方法は、一方のリードストリームに関連するメモリリクエストに応答して、共有バッファ内のバッファライトアドレスを決定するステップと、他方のリードストリームに関連するメモリリクエストに応答して、共有バッファ内の異なるバッファライトアドレスを決定するステップとを有する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マルチフォーマットビデオ処理に関する。
【背景技術】
【０００２】
ビデオ画像を圧縮とするための各種ビデオコーデックが利用可能である。一般に、ビデオコーデックは、画像データを圧縮又は伸長する際にメモリリソースを頻繁に利用する。ＡＶＣ（Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）コーデック又はＳＭＰＴＥ（Ｓｏｃｉｅｔｙ ｏｆ Ｍｏｔｉｏｎ Ｐｉｃｔｕｒｅ ａｎｄ Ｔｅｌｅｖｉｓｉｏｎ Ｅｎｇｉｎｅｅｒｓ）コーデックスなどの異なるビデオコーデックは、ビットストリーム、ビットプレーンサーファス、バイトストリームデコーダ（ＢＳＤ）ローストア、ピクセルデータリクエストなどの異なる及び／又は特有のタイプのメモリリード又はライトリクエストをしばしば有する。従来のビデオデコーダの設計は、複数の固定サイズのバッファメモリを利用して、特定のタイプのビデオコーデックにより生成されるビデオコーデックリードストリームの処理をサポートする。例えば、ＡＶＣデコーダの設計は、リードストリーム処理のため３つの別々の同様のサイズのローストアバッファを必要とし、他方、ＳＭＴＰＥ ＶＣ−１デコーダの設計は、１つの最小サイズのローストアバッファ、１つの大きなＤＭＶ（Ｄｉｆｆｅｒｅｎｔｉａｌ Ｍｏｔｉｏｎ Ｖｅｃｔｏｒ）バッファ及び１つの小さなビットプレーンバッファを必要とする。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
従来のビデオデコーダの設計は、典型的には、大きな内部キャッシュ及び／又はリードストリーム毎に別々の所定の固定サイズのバッファを利用する。しかしながら、このようなアプローチは、極めてエリアコスト高であり、及び／又は高い電力消費となりうる。さらに、大部分の従来のビデオハードウェアアクセラレーションデコーダの設計は、一時的なデータを格納するため大きな内部キャッシュを有するのに十分なエリアを有していない。従って、大部分の設計は、プリフェッチロジックと複数の小さなバッファとを利用して、外部メモリからのリードリクエストの長いメモリ遅延を隠蔽している。
【０００４】
上記問題点に鑑み、本発明の一課題は、効果的なマルチフォーマットビデオ処理のためのコンフィギュレーションバッファ割当のための技術を提供することである。
【課題を解決するための手段】
【０００５】
上記課題を解決するため、本発明の一特徴は、コンピュータにより実現される方法であって、第１ビデオコーデックフォーマットに関連する第１リードストリームと、前記第１ビデオコーデックフォーマットと異なる第２ビデオコーデックフォーマットに関連する第２リードストリームとの処理をサポートするよう共有バッファを構成するステップと、前記第１リードストリームに関連するメモリリクエストに応答して、前記共有バッファ内の第１バッファライトアドレスを決定するステップと、前記第２リードストリームに関連するメモリリクエストに応答して前記共有バッファ内の前記第１バッファライトアドレスと異なる第２バッファライトアドレスを決定するステップとを有する方法に関する。
【０００６】
本発明の他の特徴は、第１ビデオコーデックフォーマットに関連する第１リードストリームの処理をサポートするよう共有バッファを構成するステップと、前記第１リードストリームに関連するメモリリクエストに応答して、前記共有バッファ内の第１バッファライトアドレスを決定するステップと、第２ビデオコーデックフォーマットに関連する第２リードストリームの処理をサポートするよう前記共有バッファを再構成するステップと、前記第２リードストリームに関連するメモリリクエストに応答して、前記共有バッファ内の第２バッファライトアドレスを決定するステップとをプロセッサが実行する方法に関する。
【０００７】
本発明の他の特徴は、プロセッサと、前記プロセッサに接続されるメモリとを有するシステムであって、前記プロセッサは、内部メモリを有し、前記メモリの命令は、第１ビデオコーデックフォーマットに関連する第１リードストリームの処理をサポートするよう前記内部メモリ内の共有バッファを構成し、前記第１リードストリームに関連するメモリリクエストに応答して、前記共有バッファ内の第１バッファライトアドレスを決定し、第２ビデオコーデックフォーマットに関連する第２リードストリームの処理をサポートするよう前記共有バッファを再構成し、前記第２リードストリームに関連するメモリリクエストに応答して、前記共有バッファ内の第２バッファライトアドレスを決定するよう前記プロセッサを設定するシステムに関する。
【発明の効果】
【０００８】
本発明によると、効果的なマルチフォーマットビデオ処理のためのコンフィギュレーションバッファ割当のための技術を提供することができる。
【図面の簡単な説明】
【０００９】
【図１】図１は、一例となるシステムを示す図である。
【図２】図２は、一例となる処理を示す。
【図３】図３は、一例となる共有バッファコンフィギュレーションを示す。
【図４】図４は、メモリリクエストに関する図１の一例となるシステムを示す。
【図５】図５は、メモリからのデータリターンに関する図１の一例となるシステムを示す。
【図６】図６は、データリードに関する図１の一例となるシステムを示す。
【図７】図７は、図２の一例となる処理の追加的な部分を示す。
【図８】図８は、追加的な一例となる共有バッファコンフィギュレーションを示す。
【図９】図９は、一例となるシステムを示す。
【図１０】図１０は、本開示の少なくともいくつかの実施例により構成される一例となるシステムを示す。
【発明を実施するための形態】
【００１０】
添付した図面を参照して、１以上の実施例が開示される。特定のコンフィギュレーション及び構成が開示されるが、これは単なる例示のためにすぎないことが理解されるべきである。当業者は、本開示の趣旨及び範囲から逸脱することなく他のコンフィギュレーション及び構成が利用されてもよいことを当業者は認識するであろう。ここに開示される技術及び／又は構成はまたここに開示される以外の他の各種システム及びアプリケーションにおいて利用されてもよいことは、当業者に明らかであろう。
【００１１】
以下の説明は、ＳｏＣ（Ｓｙｓｔｅｍ−ｏｎ−ａ−Ｃｈｉｐ）アーキテクチャなどのアーキテクチャに明らかにされるような各種実現形態を提供するが、ここに開示される技術及び／又は構成の実現形態は、特定のアーキテクチャ及び／又は計算システムに限定されず、同様の目的のため何れかのアーキテクチャ及び／又は計算システムにより実現されてもよい。例えば、複数の集積回路（ＩＣ）チップ及び／又はパッケージなどを利用した各種アーキテクチャ、及び／又はセットトップボックス、スマートフォンなどの各種計算装置及び／又は家電機器（ＣＥ）は、ここに開示された技術及び／又は構成を実現してもよい。さらに、以下の説明はロジック実現形態、システムコンポーネントのタイプ及び相関関係、ロジック分割／統合選択などの多数の特定の詳細を提供するが、請求される主題は、このような具体的詳細なしに実現されてもよい。他の例では、制御構造やフルソフトウェア命令シーケンスなどのいくつかの題材は、ここに開示される題材を不明瞭にしないように詳細には示されない。
【００１２】
ここに開示される題材は、ハードウェア、ファームウェア、ソフトウェア又はこれらの何れかの組み合わせにより実現されてもよい。ここに開示される題材はまた、１以上のプロセッサにより読み及び実行されてもよいマシーン可読媒体に格納されている命令として実現されてもよい。マシーン可読媒体は、マシーン（計算装置など）により可読な形態で情報を格納又は送信するための何れかの媒体及び／又は機構を含むものであってもよい。例えば、マシーン可読媒体は、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、磁気ディスク記憶媒体、光記憶媒体、フラッシュメモリ装置、電子、光、音響若しくは他の形態の伝搬信号（搬送波、赤外線信号、デジタル信号など）を含むものであってもよい。
【００１３】
“一実現形態”、“ある実現形態”、“一例となる実現形態”などの明細書の表現は、開示された実現形態が特定の特徴、構成又は特性を含むことを示すが、すべての実現形態が必ずしも当該特徴、構成又は特性を含む必要はないことを示す。さらに、このような表現は、同一の実現形態を必ずしも参照しているとは限らない。さらに、特定の特徴、構成又は特性が実現形態に関して開示されるが、ここに明示的に開示されるか否かに関係なく、他の実現形態に関して当該特徴、構成又は特性を実行することは当業者の知識の範囲内であることが主張される。
【００１４】
図１は、本開示による一例となるシステム１００を示す。一例となるシステム１００などの本開示による装置及び／又はシステムは、異なるビデオコーデック処理ニーズを満たすため、メディアパイプラインにおけるプリフェッチバッファリソース割当を動的に変更してもよい。システム１００は、ドライバレジスタ１０２、対応するマルチプレクサ１０４、制御レジスタ１０６、対応するマルチプレクサ１０８、ハードウェアリード／ライト（Ｒ／Ｗ）インタフェース１１０、加算ロジック１１２，１１４，イネーブルロジック１１６，１１８、共有バッファメモリ１２０、関連するマルチプレクサ１２２、及びメモリリクエスト遅延ＦＩＦＯ（Ｆｉｒｓｔ−Ｉｎ−Ｆｉｒｓｔ−Ｏｕｔ）１２４を有する。Ｒ／Ｗインタフェース１１０は、システム１００の外部のハードウェアから各種信号１２６を受信し、以下で詳細に説明されるように、システム１００の各種コンポーネントにこれらの信号を提供する。さらに、システム１００は、以下に詳細に説明されるように、システム１００の外部のメモリ（図示せず）に接続されるメモリインタフェース（図示せず）との間で提供及び／又は受信される各種信号１２８を有してもよい。さらに、システム１００は、以下に詳細に説明されるように、システム１００の外部のハードウェアに提供される各種信号１３０を有してもよい。
【００１５】
本開示によると、共有バッファ１２０は、ビデオデコーダリソース割当をサポートするため、ダイナミックベースにより複数のバッファ領域１３２に論理分割可能なプリフェッチバッファであってもよい。バッファ１２０の分割を指定するため、ドライバレジスタ１０２は、共有バッファ１２０内の各領域１３２のスタート位置を含むコンフィギュレーションデータを格納する。何れか特定のバッファ領域１３２のサイズ又は程度は、現在のバッファ領域から次のバッファ領域のスタート位置を差し引くことによって決定されてもよい。レジスタ１０２に格納されるコンフィギュレーションデータは、領域１３２のダイナミック再割当を提供するのに必要とされるように更新又は変更される。この結果、同様の相対サイズの７つの領域１３２を有するものとして図１に示されるが、領域１３２の個数及び／又は相対サイズは、以下に詳細に説明されるように、本開示により動的に設定される。
【００１６】
各種実現形態では、低レベルオンチップキャッシュメモリの少なくとも一部は、共有バッファ１２０を実現する。例えば、共有バッファ１２０は、キャッシュメモリのトータルのメモリアドレス又は位置などに関して表現されるバッファ１２０の全体のサイズが、必要に応じて、またレジスタ１０２のコンテンツにより指定されるように動的に変更可能な低レベルキャッシュメモリの一部により提供されてもよい。一般に共有バッファ１２０は、ＳＲＡＭ（Ｓｔａｔｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、フラッシュメモリなどを含む何れかのタイプのメモリにより実現されてもよい。
【００１７】
制御レジスタ１０６は、システム１００の内部レジスタすべてを格納する。各種実施例では、制御レジスタ１０６は、各バッファ領域１３２のスタート位置に関するリード及びライトオフセットを保持する。リード及び／又はライトオフセットは、ゼロの値からスタートし、リードリクエスト又はライトリクエストに応答してインクリメントされてもよい。共有バッファ１２０は、循環的なストレージとして扱われてもよく、リード及び／又はライトオフセットは、それらが対応する領域１３２のエンドに到達すると、ゼロにラップバック（ｗｒａｐ ｂａｃｋ）する（図１に図示されないラップアラウンドロジックを用いて）。共有バッファ１２０は、ビデオ処理に用いられるメモリデータのためのメインプリフェッチストレージとして機能するようにしてもよい。ＦＩＦＯ１２４は、システム１００の外部のメモリに発行されたリクエストを格納するのに利用されてもよい。
【００１８】
本開示によると、ビデオデコーダアーキテクチャは、システム１００などの単一の制御機構を用いて、共有バッファメモリとの間でビデオデータを読み及び／又は書き込む。さらに、ドライバレジスタ１０２を介しシステム１００とインタフェースをとるソフトウェアドライバは、使用モデルに従ってバッファ１２０のサイズ及び／又は領域１３２の個数及びサイズを調整することが可能とされてもよい。さらに、共有バッファ１２０は、ストリーム毎の異なるメモリ遅延を補償するよう再構成されてもよい。
【００１９】
本開示によると、ソフトウェアドライバは、バッファ領域１３２の個数及び／又はサイズを初期的にプログラムするのに利用されてもよい。共有バッファ１２０のプログラムされたコンフィギュレーションは、発行されたすべてのメモリリクエストが処理されるまで維持されてもよい。さらに、ハードウェアは、メモリリクエストを実行し、各バッファ領域１３２からデータを独立に読むことが可能とされてもよい。
【００２０】
システム１００の各種コンポーネントは、ソフトウェア、ファームウェア、ハードウェア及び／又はこれらの何れかの組み合わせにより実現されてもよい。例えば、システム１００の各種コンポーネントは、少なくとも家電（ＣＥ）システムにあるようなコンピューティングＳｏＣ（Ｓｙｓｔｅｍ−ｏｎ−ａ−Ｃｈｉｐ）のハードウェアにより提供されてもよい。例えば、非限定的な一例では、システム１００は、セットトップボックスなどのＣＥ装置により実現されてもよい。
【００２１】
図２は、本開示の各種実現形態によるメモリリクエスト処理のための一例となる処理２００のフロー図を示す。処理２００は、図２のブロック２０２，２０４，２０６，２０８，２１０，２１２，２１４，２１６の１以上により示されるような１以上の処理、機能又はアクションを含む物であってもよい。非限定的な一例によると、処理２００は、図１の一例となるシステム１００を参照して説明される。処理２００は、ブロック２０２から開始される。
【００２２】
ブロック２０２において、共有バッファが設定される。各種実現形態では、例えば、共有バッファ１２０は、コンフィギュレーションデータが異なるデコーダ処理に関するドライバにより提供されるレジスタ１０２に保持されるコンフィギュレーションデータに応答して、バッファ１２０をバッファ領域１３２に論理分割することによって構成されてもよい。本開示によると、ブロック２０２は、マルチフォーマットビデオ処理を可能にするため、共有バッファを異なる領域に分割することを含む。
【００２３】
図３は、ブロック２０２において６つのバッファ領域３０２〜３１２に構成される共有バッファ１２０の一例となる構成３００を示す。上述されるように、共有バッファ１２０の全体のサイズは、ドライバレジスタ１０２に保持されるコンフィギュレーションデータにより指定されるような領域１３２の個数及びサイズに依存して動的に決定される。
【００２４】
一例となる構成３００では、レジスタ１０２に保持されるコンフィギュレーションデータは、バッファ領域が１つのビデオフォーマット又は規格に従ってビデオ処理に利用可能となるようにバッファ領域３０２，３０４，３０６のサイズを指定する一方、これらの領域が他のビデオフォーマット又は規格に従ってビデオ処理に利用されるようにバッファ領域３０８，３１０，３１２のサイズを指定する。例えば、一例となる構成３００は、ローストア（ｒｏｗｓｔｏｒｅ）演算を実行するときにＡＶＣデコーダによる利用のためにこれら別々のバッファ３０２，３０４，３０６を備える一方、構成３００はまた、ＶＣ−１デコーダ処理による利用のためにローストアバッファ３０８、ＤＭＶ（Ｄｉｆｆｅｒｅｎｔｉａｌ Ｍｏｔｉｏｎ Ｖｅｃｔｏｒ）バッファ３１０及びビットプレーンバッファ３１２を備えるようにしてもよい。
【００２５】
ここに開示される構成３００は、異なる２つのビデオ処理規格に整合する処理により利用される異なるバッファ領域を備えるが、本開示による共有バッファは、何れかの個数のビデオ処理フォーマット又は規格により利用される何れかの個数及び／又は相対的なサイズのバッファ領域を備えるよう構成されてもよい。さらに、構成３００ほぼ等しいサイズのバッファ領域３０２〜３１２を示すが、構成３００は単なる一例であり、領域１３２の相対的なサイズ及び個数は各種実現形態では異なって構成されてもよいことを当業者は認識するであろう。例えば、ローストア処理中にＡＶＣデコーダにより利用されるよう構成されるバッファ３０２，３０４，３０６はほぼ等しいサイズを有してもよいが、ＤＭＶバッファ３１０は、バッファ３０２，３０４又は３０６の何れかより大きく、ビットプレーンバッファ３１２は、バッファ３０２，３０４又は３０６の何れかより小さくてもよい。
【００２６】
さらに、各種実現形態では、ブロック２０２は、１以上のビデオピクチャ又はフレームに対応するビットストリームデータを処理するため、又はビデオピクチャスライスなどのビデオフレームの一部のために共有バッファを構成することに関する。例えば、ブロック２０２は、外部メモリに格納されるビデオのフレームのスライスなどの少なくとも一部に対応するリードデータストリームを処理するために共有バッファ１２０を構成することに関し、後述されるように、処理２００がフレームデータの異なる部分をバッファ１２０に書き込むための外部メモリへのアクセスを要求する連続的なインスタンスに関する。ブロック２０４において、第１リードストリームに対するメモリリクエストが受信される。
【００２７】
図４は、本開示の各種実現形態によりブロック２０４のメモリリクエスト処理に関する一例となるシステム１００を示す。図４に示されるように、Ｒ／Ｗインタフェース１１０は、メモリからピクセル値などのデータを読むため、外部メモリへのアクセスを求めるメモリリクエスト４００を受信する。例えば、ＡＶＣデコーダは、ブロック２０２においてメモリリクエストを提供し、メモリリクエスト４００は、外部メモリからピクセルデータを読むことを求めるリードストリーム処理の一部であってもよい。例えば、ブロック２０４は、ＡＶＣデコーダ処理により実行されるローストア処理中に実行されてもよい。ここで用いられるピクセルデータとは、限定することなく、マクロブロック、ブロック及び／又はサブブロックデータ値（ピクセルＹＵＶ値など）、動きベクトルデータ値（Ｘ及びＹオフセットなど）、イントラブロック及び／又はインターブロックデータ値（量子化されたＡＣ及び／又は量子化されたＤＣ係数など）など、ビデオデコーダ処理に用いられる何れかの形態のデータを表す。
【００２８】
図１及び４に示されるような一例となるシステム１００を再び参照して、ブロック２０４において受信されるメモリリクエスト４００は、Ｍｅｍｏｒｙ Ｒｅｑｕｅｓｔ（Ｍｅｍ＿Ｒｅｑ）、Ｍｅｍｏｒｙ Ｂｕｆｆｅｒ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ（Ｍｅｍ＿Ｂｕｆｆｅｒ＿ＩＤ）、及びＭｅｍｏｒｙ Ａｄｄｒｅｓｓ（Ｍｅｍ＿Ａｄｄｒ）の各信号を含む。インタフェース１１０は、Ｍｅｍ＿Ｒｅｑ信号をＦＩＦＯ１２４とイネーブルロジック１１６との双方に提供する。Ｍｅｍ＿Ａｄｄｒ信号は、メモリリクエストが送付先である外部メモリのアドレスを指定し、ＦＩＦＯ１２４に提供される。Ｍｅｍ＿Ｂｕｆｆｅｒ＿ＩＤ信号は、メモリリクエストに応答して何れのバッファ領域１３２が使用されるべきか指定し、ドライバレジスタ１０２及び制御レジスタ１０６のそれぞれに関連するマルチプレクサ１０４，１０８にＲ／Ｗインタフェース１１０によって提供される。各種実現形態では、ブロック２０４においてメモリリクエスト４００を発行したハードウェアはまず、信号１３０の１つとして提供されるＲｅａｄ＿Ｄｏｎｅ信号を確認する。
【００２９】
ブロック２０６において、バッファライトアドレスが決定される。図４に示されるように、ブロック２０４においてマルチプレクサ１０４，１０８に提供されるＭｅｍ＿Ｂｕｆｆｅｒ＿ＩＤ信号は、各自のレジスタ１０２，１０６に格納されるデータと共に、Ｗｒｉｔｅ Ｂｕｆｆｅｒ Ｏｆｆｓｅｔ（ＷＢＯ）信号とＢｕｆｆｅｒ Ｂａｓｅ Ａｄｄｒｅｓｓ（ＢＢＡ）信号とを選択するのに利用される。ＷＢＯ及びＢＢＡ信号は、Ｓｔｏｒａｇｅ Ｗｒｉｔｅ Ａｄｄｒｅｓｓ（ＳＷＡ）信号を構成するためＷＢＯ及びＢＢＡ信号を論理合成する加算ロジック１１２に提供される。ＳＷＡ信号とＭｅｍ＿Ｒｅｑ信号との双方に応答して、イネーブルロジック１１６は、共有バッファ１２０にライトイネーブル（ＷＥ）信号を提供する。
【００３０】
ＷＥ信号は、ブロック２０４において受信したメモリリクエストにより求められるピクセルデータを一時的に格納するため指定されたバッファ１２０の特定の領域１３２内の位置又はアドレスを指定する。例えば、デコーダがブロック２０４においてリードリクエストの第１インスタンスを実行するとき、ＳＷＡ信号は、領域１３２内の開始又はスタートアドレスを示す。従って、ＷＢＯ信号は、ゼロ（０）の初期値を有してもよい。例えば、図３を参照して、ＡＶＣデコーダは、メモリリクエストのターゲットバッファとしてローストアバッファ３０２などを指定するＭｅｍ＿Ｂｕｆｆｅｒ＿ＩＤと共に、ブロック２０４においてリードリクエストを提供するようにしてもよい。ＳＷＡ信号は、バッファ３０２の正確な位置がＷＢＯ信号の値に依存するローストアバッファ３０２内の位置又はアドレスを指定する。
【００３１】
ＷＥ信号の受信に応答して、共有バッファ１２０は、システム１００がメモリリクエストｗｐ受信し、応答を開始したことを示すＷＲＰ（Ｗｒｉｔｅ Ｒｅｑｕｅｓｔ ｉｎ Ｐｒｏｇｒｅｓｓ）信号をアサートする。さらに、ブロック２０４においてメモリリクエストを受信することに応答して、システム１００は、後述されるように、データがメモリから返されるとき、ＳＷＡ信号により示される領域１３２内のライト位置又はアドレスを決定するのに利用可能なＭｅｍ＿Ｔａｇ信号を構成するため、ＷＢＯ及びＢＢＡ信号を合成する。Ｍｅｍ＿Ｔａｇ，Ｍｅｍ＿Ｒｅｑ及びＭｅｍ＿Ａｄｄｒの各信号は、ＦＩＦＯ１２４に格納され、以降にメモリインタフェースに提供される。ブロック２０８において、第１リードストリームのピクセルデータは、共有バッファに書き込まれてもよい。
【００３２】
図５は、本開示の各種実現形態によるブロック２０８におけるデータリターン処理に関してシステム１００を示す。図２及び５を参照して、各種実現形態では、ブロック２０８は、外部メモリがＭｅｍ＿Ａｄｄｒ信号を用いて読み込み対象のピクセルデータを決定することに関する。例えば、Ｍｅｍ＿Ａｄｄｒ信号は、外部メモリに格納されるピクセル値のローを示す。
【００３３】
外部メモリは、その後にシステム１００のメモリインタフェースを介し、Ｍｅｍ＿Ｄａｔａ信号としてピクセルデータを共有バッファ１２０に提供する。外部メモリにより提供されるＭｅｍ＿Ｔａｇ信号のＢＢＡ及びＷＢＯコンポーネントが、イネーブルロジック１１６にＳＷＡ信号を提供するため、ロジック１１２により加えられる。ロジック１１６は、その後に、Ｍｅｍｏｒｙ Ｒｅｑｕｅｓｔ Ｒｅｔｕｒｎ（Ｍｅｍ＿Ｒｅｑ＿Ｒｅｔｕｒｎ）に応答して、ＳＷＡ信号により示される部分１３２内の特定のアドレスにピクセルデータ（Ｍｅｍ＿Ｄａｔａ信号などに対応する）をバッファ１２０に格納させるＷＥ信号をバッファ１２０に提供する。上述した例に続いて、ＳＷＡ信号はローストアバッファ３０２内のアドレスを指定する場合、ブロック２０８は、ＡＶＣデコーダ処理によるローストア処理中にピクセルデータを当該位置に格納する。例えば、ピクセルデータのローは、ＳＷＡ信号により指定される位置から始まって格納される。
【００３４】
ピクセルデータが共有バッファに書き込まれると、システム１００は、要求されたピクセルデータがバッファ１２０から読み出されるのに利用可能であることをハードウェアに示すＤａｔａ Ａｖａｉｌａｂｌｅ（Ｄａｔａ＿Ａｖａｉｌ）信号をアサートする。さらに、ブロック２０８においてリードデータを書き込むとき、システム１００はまた、以降のメモリリクエストがバッファ１２０の特定の領域１３２内の次の位置にデータを書き込むように、ＷＢＯ値をインクリメントする。処理２００は、ブロック２１０において共有バッファから第１リードストリームピクセルデータを読み続ける。
【００３５】
図６は、本開示の各種実現形態によるブロック２１０におけるリードリクエスト処理に関する一例となるシステム１００を示す。図６に示されるように、ブロック２１０は、ブロック２０８の結果として共有バッファに格納されているピクセルデータにアクセスするため、Ｒ／Ｗインタフェース１１０がリードリクエスト６００を受信することを含む。例えば、ＡＶＣ復号化処理は、ローストア処理の実行中にブロック２１０においてリードリクエスト６００を提供する。
【００３６】
リードリクエスト６００は、Ｒｅａｄ Ｂｕｆｆｅｒ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ（Ｒｅａｄ＿Ｂｕｆｆｅｒ＿ＩＤ）信号、Ｒｅａｄ Ｒｅｑｕｅｓｔ（Ｒｅａｄ＿Ｒｅｑ）信号及びＲｅａｄ＿Ｂｕｆｆｅｒ＿Ｅｖｉｃｔ信号を含む。Ｒｅａｄ＿Ｂｕｆｆｅｒ＿ＩＤ信号は、対応するＢＢＡ信号を提供するためマルチプレクサ１０４と、Ｒｅａｄ Ｂｕｆｆｅｒ Ｏｆｆｓｅｔ（ＲＢＯ）信号を提供するためマルチプレクサ１０８に提供される。ロジック１１４は、その後にブロック２１０において読み出されるピクセルデータを格納するバッファ１２０の特定の領域１３２内の特定の位置を示すＳｔｏｒａｇｅ Ｒｅａｄ Ａｄｄｒｅｓｓ（ＳＲＡ）信号を生成するため、ＲＢＯ信号をＢＢＡ信号に加える。上述した例に続いて、ＳＲＡ信号が、ブロック２０８においてピクセルデータが書き込まれたローストアバッファ３０２内のアドレスを指定する場合、ブロック２１０において、当該ピクセルデータがＡＶＣデコーダによるローストア処理中に当該位置から読まれる。例えば、ブロック２１０は、ピクセル値のローが共有バッファ１２０から読まれることに関する。
【００３７】
いくつかの実現形態では、ブロック２１０は、ハードウェアがＳＲＡ信号により示される位置の状態を確認できるように、Ｒｅａｄ＿Ｒｅｑ信号を設定している間にはＲｅａｄ＿Ｂｕｆｆｅｒ＿Ｅｖｉｃｔ信号を設定しないことに関する。その実行中に、ハードウェアが、当該位置においてデータが読み出しに利用可能であることを示すＲｅａｄ＿Ｄａｔａ信号が設定されていることを検出する場合、ハードウェアは、Ｒｅａｄ＿Ｄａｔａ信号にアクセスすることによって、共有バッファ１２０からデータを読むため、Ｒｅａｄ＿Ｒｅｑ信号とＲｅａｄ＿Ｂｕｆｆｅｒ＿Ｅｖｉｃｔとの双方を設定することによって、ブロック２１０の実現を継続してもよい。
【００３８】
イネーブルロジック１１８は、Ｒｅａｄ Ｅｎａｂｌｅ（ＲＥ）信号をバッファ１２０に提供することによって、ＳＲＡ信号、Ｒｅａｄ＿Ｒｅｑ信号及びＲｅａｄ＿Ｂｕｆｆｅｒ＿Ｅｖｉｃｔ信号に応答する。ＲＥ信号に関連して、ＳＲＡはマルチプレクサ１２２に提供され、格納されているデータはＲｅａｄ＿Ｄａｔａ信号として現れる。さらに、ブロック２１０においてリードデータを提供するとき、システム１００は、データがさらに利用されないことを示すＲｅａｄ＿Ｄｏｎｅ信号を設定し、以降のリードリクエストがバッファ１２０の特定の領域１３２内の次の位置にあるように、レジスタ１０６に格納されているＲＢＯ値をインクリメントしてもよい。
【００３９】
図２に戻って、処理２００は、ブロック２１２に続き、第１リードストリームの処理が続けられるべきか判断される。例えば、各種実現形態では、ビデオデコーダは、リードストリーム処理のためピクセルデータを取得する初期的な処理として、ブロック２０４〜２１０の最初の繰り返しを実行する。ビデオデコーダは、その後に、リードストリーム処理のピクセルデータの追加的な部分を取得するため、ブロック２０４〜２１０の１以上のさらなる繰り返しを実行する。従って、ブロック２１２において、第１リードストリームのさらなる処理が続けられるべきであると判断された場合、デコーダは、ブロック２０４〜２１２のもう１回の繰り返しを実行する前に、ブロック２１４においてメモリアドレスを修正するよう動作する（例えば、Ｍｅｍ＿Ａｄｄｒ信号値をインクリメントすることによって）。各種実現形態では、ビデオデコーダの処理は、ブロック２１２の最後のインスタンスにおいて、第１リードストリームの処理が終了したとデコーダが判断するまで、ブロック２０４〜２１４のロープ処理を継続する。例えば、処理２００を実行するＡＶＣデコーダは、ブロック２１２の最後のインスタンスにおいて、例えば、第１リードストリームの処理に対応するローストア処理が外部メモリから所望量のピクセルデータを取得したとき、第１リードストリームの処理が終了したと判断してもよい。他方、ブロック２１２において、第１リードストリームの処理が継続されるべきでないと判断された場合、処理２００は、さらなる処理、機能又はアクションによりブロック２１６において続けられる。
【００４０】
図７は、本開示の各種実現形態により示されるメモリリクエスト処理のための一例となる処理２００のさらなる部分を示す。処理２００は、ブロック２１８，２２０，２２２，２２４，２２６，２２８，２３０，２３２の１以上により示されるような１以上のさらなる処理、機能又はアクションを含む。非限定的な例により、図７に示されるような処理２００は、図１の一例となるシステム１００を参照して再び開示される。処理２００は、ブロック２１８において続けられる。
【００４１】
ブロック２１８において、共有バッファが再構成されるべきか判断される。各種実現形態では、ブロック２１８は、共有バッファ１２０が他のビデオ処理リードストリームなどの新たな又は第２のリードストリームの処理を実行するよう再構成される必要があるか判断することに関する。例えば、ＡＶＣデコーダにより生成されるリードストリームなどの第１ビデオフォーマット又は規格に準拠する第１リードストリームのリードストリーム処理が、図２のブロック２０４〜２１４において実行される間、ブロック２１８は、ＶＣ−１デコーダなどにより実行可能な他のビデオフォーマット又は規格に関する第２リードストリームの処理を実行するため共有バッファ１２０が再構成される必要があるか判断することに関する。
【００４２】
ブロック２１８において、共有バッファが再構成されるべきでないと判断された場合、処理２００は、第２リードストリームに対するメモリリクエストの受信（ブロック２２２）、当該メモリリクエストのバッファライトアドレスの決定（ブロック２２４）、当該第２リードストリームのピクセルデータの共有バッファへの書き込み（ブロック２２６）、及びブロック２２８における共有バッファからの当該ピクセルデータの読み込みに続く。ブロック２２２，２２４，２２６，２２８はそれぞれ、図２のブロック２０４，２０６，２０８，２１０について上述したのと同様に実行される。
【００４３】
各種実現形態では、図７のブロック２２２〜２２８において第２リードストリームの処理を可能にする方法により共有バッファがブロック２０２（図２）において構成されたとき、再構成がブロック２１８において実行されるべきでないと判断される。例えば、図３の一例となる構成３００を参照すると、第２リードストリームがＶＣ−１デコーダのリードストリームである場合、ブロック２０２におけるＶＣ−１デコーダの処理に適するよう構成された領域３０８，３１０，３１２を含む共有バッファ１２０は、再構成することなく図７のブロック２２２〜２２８において第２リードストリームの処理を実行するのに適するよう構成される。
【００４４】
他方、ブロック２１８において再構成が実行されるべきであると判断された場合、処理２００は、共有バッファを再構成することによってブロック２２０に続く。例えば、ブロック２１８において、共有バッファ１２０が第２リードストリームの処理を実現する方法により構成されていないと判断される可能性がある。各種実現形態では、ブロック２２０は、１以上のビデオデコーダの処理に関するソフトウェアドライバによってコンフィギュレーションデータがレジスタ１０２に配置されることに応答して実行される。例えば、第２リードストリームの処理を実行するＶＣ−１デコーダの処理に関するソフトウェアドライバは、コンフィギュレーションデータをレジスタ１０２に提供する。その後、システム１００は、第２リードストリームに関するコンフィギュレーションデータを利用して、共有バッファ１２０を再構成する。例えば、共有バッファ１２０は、図２のブロック２０４〜２１４において処理されたビデオビットストリームのフォーマットと異なるフォーマットに従って符号化されたビデオビットストリームを復号化するためシステム１００が呼び出されることに応答して、ブロック２２０において動的に再構成されてもよい。
【００４５】
図８は、図２のブロック２０２において実行された共有バッファ１２０の一例となる初期的な構成８００と、図７のブロック２２０において実行される共有バッファ１２０の一例となる再構成８１０とを示す。図８の例では、ブロック２０２（図２）において、共有バッファ１２０は、ローストア処理を実現するＡＶＣデコーダに準拠するよう構成される３つの同様のサイズのローストアバッファ８０２，８０４，８０６を有するよう構成されてもよい。この非限定的な例では、バッファ８０２，８０４，８０６を備えるよう構成されるとき、共有バッファ１２０がブロック２０２において具体的にフォーマット化又は設定されなかったさらなる領域を含むように、共有バッファ１２０は所定の全体サイズを有する。
【００４６】
図８の例では、ブロック２２０は、もはやバッファ８０２，８０４，８０６を含まず、対応するリードストリーム処理を実現するＶＣ−１デコーダに適したローストアバッファ８１２、ＤＭＶバッファ８１４及びビットプレーンバッファ８１６に適した領域に対応する新たに構成された領域を含むよう共有バッファ１２０を動的に再構成することに関する。ブロック２２０における再構成後、具体的にフォーマット化されなかった領域８０８が以前として存在するが、新たに構成されたバッファ８１２，８１４，８１６のサイズに依存して構成８００にあるものと異なるサイズを有してもよい。
【００４７】
図７に戻って、ブロック２２０における再構成後、処理２００は、第２リードストリームに対するメモリリクエストの受信（ブロック２２２）、当該メモリリクエストのバッファライトアドレスの決定（ブロック２２４）、第２リードストリームのピクセルデータの共有バッファへの書き込み（ブロック２２６）、及びブロック２２８における共有バッファからピクセルデータの読み出しに続く。ブロック２２２，２２４，２２６，２２８はそれぞれ、図２のブロック２０４，２０６，２０８，２１０について上述したのと同様の方法により実行されてもよい。
【００４８】
処理２００は、ブロック２３０に続き、第２リードストリームの処理が継続されるべきか決定される。例えば、各種実現形態では、ビデオデコーダは、リードストリーム処理のピクセルデータを取得する最初の部分としてブロック２２２〜２２８の最初の繰り返しを実行した。その後、ビデオデコーダは、リードストリームの処理のためピクセルデータのさらなる部分を取得するために、ブロック２２２〜２２８の１以上のさらなる繰り返しを実行する。従って、ブロック２３０において、第１リードストリームの処理が継続されるべきであるとデコーダが判断した場合、デコーダは、ブロック２２２〜２３０のもう１回の繰り返しを実行する前に、ブロック２３２においてメモリアドレスを修正するよう動作する（例えば、Ｍｅｍ＿Ａｄｄｒ信号値をインクリメントすることによって）。各種実現形態では、ビデオデコーダの処理は、ブロック２３０の最後のインスタンスにおいて、第２リードストリームの処理が終了したとデコーダが判断するまで、ブロック２２２〜２３２のループを継続する。例えば、図７に示されるような処理２００を実行するＶＣ−１デコーダは、ブロック２３０の最後のインスタンスにおいて、第２リードストリームの処理が継続されるべきでなく、処理２００が終了されるべきであると判断する。
【００４９】
図２及び７に示されるように、一例となる処理３００の実現は図示された順序によりブロック２０２〜２３２のすべてを実行することを含むが、請求される主題はこれに限定されず、各種具体例では、処理２００の実現は、図示された以外の順序により及び／又はブロック２０２〜２３２の一部のみを実行することを含むものであってもよい。
【００５０】
図２及び７の処理及び／又はブロックの何れか１以上は、１以上のコンピュータプログラムにより提供される命令に応答して実行されてもよい。このようなプログラムは、例えば、１以上のプロセッサコアにより実行されると、図１〜８に関して上述された機能を提供する命令を提供する媒体を担持する信号を含むものであってもよい。コンピュータプログラムは、何れかの形態のコンピュータ可読記憶媒体により提供されてもよい。例えば、１以上のプロセッサコアを含むプロセッサは、コンピュータ可読記憶媒体によりプロセッサに搬送される命令に応答して、図２及び７に示されるブロックの１以上を実行してもよい。
【００５１】
図９は、本開示による一例となるシステム９００を示す。システム９００は、ここに開示される各種機能の一部又はすべてを実行するのに利用され、本開示の各種実現形態に従ってマルチフォーマットビデオ処理のための設定可能なバッファ割当てを提供可能な何れかの装置又は装置群を含むものであってもよい。システム９００は、ＶＬＳＩ（Ｖｅｒｙ Ｌａｒｇｅ Ｓｃａｌｅ Ｉｎｔｅｇｒａｔｉｏｎ） ＳｏＣ ＩＣ（Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）９０２と、ＩＣ９０２に通信及び／又は動作接続する外部メモリ９０４とを有する。ＩＣ９０２は、１以上のプロセッサコア（図示せず）を有し、限定することなく、ＣＩＳＣ（Ｃｏｍｐｌｅｘ Ｉｎｓｔｒｕｃｔｉｏｎ Ｓｅｔ Ｃｏｍｐｕｔｅｒ）、ＲＩＳＣ（Ｒｅｄｕｃｅｄ Ｉｎｓｔｒｕｃｔｉｏｎ Ｓｅｔ Ｃｏｍｐｕｔｉｎｇ）マイクロプロセッサコア、ＶＬＩＷ（Ｖｅｒｙ Ｌｏｎｇ Ｉｎｓｔｒｕｃｔｉｏｎ Ｗｏｒｄ）マイクロプロセッサコア、何れかの命令セットの組み合わせを実現する１以上のプロセッサコア、又はデジタル信号プロセッサ若しくはマイクロコントローラなどの他の何れかのプロセッサ装置など、１以上のプロセッサコアを含む何れかのタイプのプロセッサベースシステムであってもよい。例えば、ＩＣ９０２は、複数のプロセッサコアを有し、モバイルコンピューティング装置（スマートフォン、タブレットコンピュータなど）などの家電（ＣＥ）装置により実現されてもよい。メモリ９０４は、限定することなく、ＤＲＡＭメモリ、ＳＲＡＭメモリ、フラッシュメモリなどを含む何れかのタイプのメモリであってもよい。
【００５２】
ＩＣ９０２は、キャッシュメモリなどの内部メモリ９０６を有し、ここに開示される各種構成、処理、機能及び／又はアクションを備える及び／又は実行するよう構成されるロジックを有するビデオハードウェアアクセラレーションエンジン（ＨＡＥ）９０８を備える及び／又はサポートするものであってもよい。ビデオＨＡＥ９０８は、ここに開示されるような動的に構成可能な共有バッファ９１０と共にこれを実行する。上述され、図９に示されるように、バッファ９１０は、内部メモリ９０６の少なくとも一部から構成されてもよい。各種実現形態では、図１のシステム１００は、少なくとも部分的にビデオＨＡＥ９０８及び共有バッファ９１０により提供される。さらに、共有バッファ９１０と共にビデオＨＡＥ９０８は、ＩＣ９０２に提供されるビデオデータの異なってフォーマット化されたストリームＡ及びＢに応答して、ここに開示される図２及び７のブロックの何れかを実行するようにしてもよい。ビデオＨＡＥ９０８は、コーデックモードの処理及び／又はあるタイプのビデオストリームが現在処理されていることに応答して、プリフェッチバッファサイズを調整してもよい。
【００５３】
図１０は、本開示による一例となるシステム１０００を示す。システム１０００は、ここに開示される各種機能の一部又はすべてを実行するのに利用され、本開示の各種実現形態によるマルチフォーマットビデオ処理のための設定可能なバッファ割当てを実行可能な何れかの装置又は装置群を含む。例えば、システム１０００は、本開示がこれに限定されるものでないが、デスクトップ、モバイル若しくはタブレットコンピュータ、スマートフォン、セットトップボックスなどの計算プラットフォーム又は装置の選択されたコンポーネントを有してもよい。いくつかの実現形態では、システム１０００は、ＣＥ装置のためのＩｎｔｅｌ（登録商標）アーキテクチャ（ＩＡ）に基づき計算プラットフォーム又はＳｏＣであってもよい。ここに開示される実現形態は本開示の範囲から逸脱することなく他の処理システムと共に利用可能であることは、当業者に容易に理解されるであろう。
【００５４】
システム１０００は、１以上のプロセッサコア１００４を有するプロセッサ１００２を有する。プロセッサコア１００４は、少なくとも部分的にソフトウェアを実行し、及び／又はデータ信号を処理可能な何れかのタイプのプロセッサロジックであってもよい。各種具体例では、プロセッサコア１００４は、ＣＩＳＣプロセッサコア、ＲＩＳＣマイクロプロセッサコア、ＶＬＩＷマイクロプロセッサコア及び／又は何れかの命令セットの組み合わせを実現する任意数のプロセッサコア又はデジタル信号プロセッサやマイクロコントローラなどの他の何れかのプロセッサ装置を有してもよい。
【００５５】
プロセッサ１００２はまた、ディスプレイプロセッサ１００８及び／又はグラフィックプロセッサ１０１０などにより受信される命令を制御信号及び／又はマイクロコードエントリポイントに復号化するのに利用可能なデコーダ１００６を有する。コア１００４と別々のコンポーネントとしてシステム１０００に示されるが、当業者は、１以上のコア１００４がデコーダ１００６、ディスプレイプロセッサ１００８及び／又はグラフィックプロセッサ１０１０を実現可能であることを理解するであろう。いくつかの実現形態では、デコーダ１００６は、図１〜９に関して説明される一例となる処理を含む、ここに開示される処理の何れかを実行するよう構成されるビデオデコーダであってもよい。さらに、制御信号及び／又はマイクロコードエントリポイントに応答して、ディスプレイプロセッサ１００８及び／又はグラフィックプロセッサ１０１０は、対応する処理を実行する。
【００５６】
プロセッサコア１００４、デコーダ１００６、ディスプレイプロセッサ１００８及び／又はグラフィックプロセッサ１０１０は、限定することなく、例えば、メモリコントローラ１０１４、オーディオコントローラ１０１８及び／又は周辺装置１０２０を含む他の各種システム装置と、及び／又は互いにシステムインターコネクト１０１６を介し通信及び／又は動作接続される。周辺装置１０２０は、例えば、ＵＳＢ（Ｕｎｉｆｉｅｄ Ｓｅｒｉａｌ Ｂｕｓ）ホストポート、ＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ）Ｅｘｐｒｅｓｓポート、ＳＰＩ（Ｓｅｒｉａｌ Ｐｅｒｉｐｈｅｒａｌ Ｉｎｔｅｒｆａｃｅ）インタフェース、拡張バス及び／又は他の周辺装置などを含む。図１０はインターコネクト１０１６によりデコーダ１００６及びプロセッサ１００８，１０１０に接続されるものとしてメモリコントローラ１０１６を示しているが、各種実現形態では、メモリコントローラ１０１４は、デコーダ１００６、ディスプレイプロセッサ１００８及び／又はグラフィックプロセッサ１０１０に直接接続されてもよい。
【００５７】
いくつかの実現形態では、システム１０００は、Ｉ／Ｏバス（図示せず）を介し図１０に図示されない各種Ｉ／Ｏ装置と通信する。このようなＩ／Ｏ装置は、限定することなく、例えば、ＵＡＲＴ（Ｕｎｉｖｅｒｓａｌ Ａｓｙｎｃｈｒｏｎｏｕｓ Ｒｅｃｅｉｖｅｒ／Ｔｒａｎｓｍｉｔｔｅｒ）装置、ＵＳＢ装置、Ｉ／Ｏ拡張インタフェース又は他のＩ／Ｏ装置を含む。各種実現形態では、システム１０００は、モバイル、ネットワーク及び／又は無線通信を実行するためのシステムの少なくとも一部を表す。
【００５８】
システム１０００はさらに、メモリ１０１２を有する。メモリ１０１２は、ＤＲＡＭ装置、ＳＲＡＭ装置、フラッシュメモリ装置、又は他のメモリ装置などの１以上のメモリコンポーネントであってもよい。図１０は、プロセッサ１００２の外部のものとしてメモリ１０１２を示しているが、各種実現形態では、メモリ１０１２はプロセッサ１００２の内部にあってもよい。メモリ１０１２は、プロセッサ１００２により実行可能なデータ信号により表される命令及び／又はデータを格納する。いくつかの実現形態では、メモリ１０１２は、システムメモリ部とディスプレイメモリ部とを含むものであってもよい。
【００５９】
上述されたシステムと、それにより実行されるここに開示された処理とは、ハードウェア、ファームウェア、ソフトウェア又はこれらの何れかの組み合わせにより実現されてもよい。さらに、ここに開示される１以上の特徴は、個別及び一体化された回路ロジック、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）ロジック及びマイクロコントローラを含む、ハードウェア、ソフトウェア、ファームウェア及びこれらの組み合わせにより実現されてもよく、ドメイン固有のＩＣパッケージ又はＩＣパッケージの組み合わせの一部として実現されてもよい。ここに用いられるソフトウェアという用語は、コンピュータシステムにここに開示される１以上の機能及び／又はその組み合わせを実行させるよう格納されたコンピュータプログラムロジックを有するコンピュータ可読媒体を含むコンピュータプログラムを表す。
【００６０】
ここに提供される特徴が各種実現形態を参照して説明されたが、本開示は限定的な意味で解釈されるべきでない。ここに開示される実現形態の各種変更は、本開示が属する当業者に明らかな他の実現形態と共に、本開示の趣旨及び範囲内にあるとみなされる。
【符号の説明】
【００６１】
１０００ システム
１００２ プロセッサ
１０１２ メモリ
【技術分野】
【０００１】
本発明は、マルチフォーマットビデオ処理に関する。
【背景技術】
【０００２】
ビデオ画像を圧縮とするための各種ビデオコーデックが利用可能である。一般に、ビデオコーデックは、画像データを圧縮又は伸長する際にメモリリソースを頻繁に利用する。ＡＶＣ（Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）コーデック又はＳＭＰＴＥ（Ｓｏｃｉｅｔｙ ｏｆ Ｍｏｔｉｏｎ Ｐｉｃｔｕｒｅ ａｎｄ Ｔｅｌｅｖｉｓｉｏｎ Ｅｎｇｉｎｅｅｒｓ）コーデックスなどの異なるビデオコーデックは、ビットストリーム、ビットプレーンサーファス、バイトストリームデコーダ（ＢＳＤ）ローストア、ピクセルデータリクエストなどの異なる及び／又は特有のタイプのメモリリード又はライトリクエストをしばしば有する。従来のビデオデコーダの設計は、複数の固定サイズのバッファメモリを利用して、特定のタイプのビデオコーデックにより生成されるビデオコーデックリードストリームの処理をサポートする。例えば、ＡＶＣデコーダの設計は、リードストリーム処理のため３つの別々の同様のサイズのローストアバッファを必要とし、他方、ＳＭＴＰＥ ＶＣ−１デコーダの設計は、１つの最小サイズのローストアバッファ、１つの大きなＤＭＶ（Ｄｉｆｆｅｒｅｎｔｉａｌ Ｍｏｔｉｏｎ Ｖｅｃｔｏｒ）バッファ及び１つの小さなビットプレーンバッファを必要とする。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
従来のビデオデコーダの設計は、典型的には、大きな内部キャッシュ及び／又はリードストリーム毎に別々の所定の固定サイズのバッファを利用する。しかしながら、このようなアプローチは、極めてエリアコスト高であり、及び／又は高い電力消費となりうる。さらに、大部分の従来のビデオハードウェアアクセラレーションデコーダの設計は、一時的なデータを格納するため大きな内部キャッシュを有するのに十分なエリアを有していない。従って、大部分の設計は、プリフェッチロジックと複数の小さなバッファとを利用して、外部メモリからのリードリクエストの長いメモリ遅延を隠蔽している。
【０００４】
上記問題点に鑑み、本発明の一課題は、効果的なマルチフォーマットビデオ処理のためのコンフィギュレーションバッファ割当のための技術を提供することである。
【課題を解決するための手段】
【０００５】
上記課題を解決するため、本発明の一特徴は、コンピュータにより実現される方法であって、第１ビデオコーデックフォーマットに関連する第１リードストリームと、前記第１ビデオコーデックフォーマットと異なる第２ビデオコーデックフォーマットに関連する第２リードストリームとの処理をサポートするよう共有バッファを構成するステップと、前記第１リードストリームに関連するメモリリクエストに応答して、前記共有バッファ内の第１バッファライトアドレスを決定するステップと、前記第２リードストリームに関連するメモリリクエストに応答して前記共有バッファ内の前記第１バッファライトアドレスと異なる第２バッファライトアドレスを決定するステップとを有する方法に関する。
【０００６】
本発明の他の特徴は、第１ビデオコーデックフォーマットに関連する第１リードストリームの処理をサポートするよう共有バッファを構成するステップと、前記第１リードストリームに関連するメモリリクエストに応答して、前記共有バッファ内の第１バッファライトアドレスを決定するステップと、第２ビデオコーデックフォーマットに関連する第２リードストリームの処理をサポートするよう前記共有バッファを再構成するステップと、前記第２リードストリームに関連するメモリリクエストに応答して、前記共有バッファ内の第２バッファライトアドレスを決定するステップとをプロセッサが実行する方法に関する。
【０００７】
本発明の他の特徴は、プロセッサと、前記プロセッサに接続されるメモリとを有するシステムであって、前記プロセッサは、内部メモリを有し、前記メモリの命令は、第１ビデオコーデックフォーマットに関連する第１リードストリームの処理をサポートするよう前記内部メモリ内の共有バッファを構成し、前記第１リードストリームに関連するメモリリクエストに応答して、前記共有バッファ内の第１バッファライトアドレスを決定し、第２ビデオコーデックフォーマットに関連する第２リードストリームの処理をサポートするよう前記共有バッファを再構成し、前記第２リードストリームに関連するメモリリクエストに応答して、前記共有バッファ内の第２バッファライトアドレスを決定するよう前記プロセッサを設定するシステムに関する。
【発明の効果】
【０００８】
本発明によると、効果的なマルチフォーマットビデオ処理のためのコンフィギュレーションバッファ割当のための技術を提供することができる。
【図面の簡単な説明】
【０００９】
【図１】図１は、一例となるシステムを示す図である。
【図２】図２は、一例となる処理を示す。
【図３】図３は、一例となる共有バッファコンフィギュレーションを示す。
【図４】図４は、メモリリクエストに関する図１の一例となるシステムを示す。
【図５】図５は、メモリからのデータリターンに関する図１の一例となるシステムを示す。
【図６】図６は、データリードに関する図１の一例となるシステムを示す。
【図７】図７は、図２の一例となる処理の追加的な部分を示す。
【図８】図８は、追加的な一例となる共有バッファコンフィギュレーションを示す。
【図９】図９は、一例となるシステムを示す。
【図１０】図１０は、本開示の少なくともいくつかの実施例により構成される一例となるシステムを示す。
【発明を実施するための形態】
【００１０】
添付した図面を参照して、１以上の実施例が開示される。特定のコンフィギュレーション及び構成が開示されるが、これは単なる例示のためにすぎないことが理解されるべきである。当業者は、本開示の趣旨及び範囲から逸脱することなく他のコンフィギュレーション及び構成が利用されてもよいことを当業者は認識するであろう。ここに開示される技術及び／又は構成はまたここに開示される以外の他の各種システム及びアプリケーションにおいて利用されてもよいことは、当業者に明らかであろう。
【００１１】
以下の説明は、ＳｏＣ（Ｓｙｓｔｅｍ−ｏｎ−ａ−Ｃｈｉｐ）アーキテクチャなどのアーキテクチャに明らかにされるような各種実現形態を提供するが、ここに開示される技術及び／又は構成の実現形態は、特定のアーキテクチャ及び／又は計算システムに限定されず、同様の目的のため何れかのアーキテクチャ及び／又は計算システムにより実現されてもよい。例えば、複数の集積回路（ＩＣ）チップ及び／又はパッケージなどを利用した各種アーキテクチャ、及び／又はセットトップボックス、スマートフォンなどの各種計算装置及び／又は家電機器（ＣＥ）は、ここに開示された技術及び／又は構成を実現してもよい。さらに、以下の説明はロジック実現形態、システムコンポーネントのタイプ及び相関関係、ロジック分割／統合選択などの多数の特定の詳細を提供するが、請求される主題は、このような具体的詳細なしに実現されてもよい。他の例では、制御構造やフルソフトウェア命令シーケンスなどのいくつかの題材は、ここに開示される題材を不明瞭にしないように詳細には示されない。
【００１２】
ここに開示される題材は、ハードウェア、ファームウェア、ソフトウェア又はこれらの何れかの組み合わせにより実現されてもよい。ここに開示される題材はまた、１以上のプロセッサにより読み及び実行されてもよいマシーン可読媒体に格納されている命令として実現されてもよい。マシーン可読媒体は、マシーン（計算装置など）により可読な形態で情報を格納又は送信するための何れかの媒体及び／又は機構を含むものであってもよい。例えば、マシーン可読媒体は、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、磁気ディスク記憶媒体、光記憶媒体、フラッシュメモリ装置、電子、光、音響若しくは他の形態の伝搬信号（搬送波、赤外線信号、デジタル信号など）を含むものであってもよい。
【００１３】
“一実現形態”、“ある実現形態”、“一例となる実現形態”などの明細書の表現は、開示された実現形態が特定の特徴、構成又は特性を含むことを示すが、すべての実現形態が必ずしも当該特徴、構成又は特性を含む必要はないことを示す。さらに、このような表現は、同一の実現形態を必ずしも参照しているとは限らない。さらに、特定の特徴、構成又は特性が実現形態に関して開示されるが、ここに明示的に開示されるか否かに関係なく、他の実現形態に関して当該特徴、構成又は特性を実行することは当業者の知識の範囲内であることが主張される。
【００１４】
図１は、本開示による一例となるシステム１００を示す。一例となるシステム１００などの本開示による装置及び／又はシステムは、異なるビデオコーデック処理ニーズを満たすため、メディアパイプラインにおけるプリフェッチバッファリソース割当を動的に変更してもよい。システム１００は、ドライバレジスタ１０２、対応するマルチプレクサ１０４、制御レジスタ１０６、対応するマルチプレクサ１０８、ハードウェアリード／ライト（Ｒ／Ｗ）インタフェース１１０、加算ロジック１１２，１１４，イネーブルロジック１１６，１１８、共有バッファメモリ１２０、関連するマルチプレクサ１２２、及びメモリリクエスト遅延ＦＩＦＯ（Ｆｉｒｓｔ−Ｉｎ−Ｆｉｒｓｔ−Ｏｕｔ）１２４を有する。Ｒ／Ｗインタフェース１１０は、システム１００の外部のハードウェアから各種信号１２６を受信し、以下で詳細に説明されるように、システム１００の各種コンポーネントにこれらの信号を提供する。さらに、システム１００は、以下に詳細に説明されるように、システム１００の外部のメモリ（図示せず）に接続されるメモリインタフェース（図示せず）との間で提供及び／又は受信される各種信号１２８を有してもよい。さらに、システム１００は、以下に詳細に説明されるように、システム１００の外部のハードウェアに提供される各種信号１３０を有してもよい。
【００１５】
本開示によると、共有バッファ１２０は、ビデオデコーダリソース割当をサポートするため、ダイナミックベースにより複数のバッファ領域１３２に論理分割可能なプリフェッチバッファであってもよい。バッファ１２０の分割を指定するため、ドライバレジスタ１０２は、共有バッファ１２０内の各領域１３２のスタート位置を含むコンフィギュレーションデータを格納する。何れか特定のバッファ領域１３２のサイズ又は程度は、現在のバッファ領域から次のバッファ領域のスタート位置を差し引くことによって決定されてもよい。レジスタ１０２に格納されるコンフィギュレーションデータは、領域１３２のダイナミック再割当を提供するのに必要とされるように更新又は変更される。この結果、同様の相対サイズの７つの領域１３２を有するものとして図１に示されるが、領域１３２の個数及び／又は相対サイズは、以下に詳細に説明されるように、本開示により動的に設定される。
【００１６】
各種実現形態では、低レベルオンチップキャッシュメモリの少なくとも一部は、共有バッファ１２０を実現する。例えば、共有バッファ１２０は、キャッシュメモリのトータルのメモリアドレス又は位置などに関して表現されるバッファ１２０の全体のサイズが、必要に応じて、またレジスタ１０２のコンテンツにより指定されるように動的に変更可能な低レベルキャッシュメモリの一部により提供されてもよい。一般に共有バッファ１２０は、ＳＲＡＭ（Ｓｔａｔｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、フラッシュメモリなどを含む何れかのタイプのメモリにより実現されてもよい。
【００１７】
制御レジスタ１０６は、システム１００の内部レジスタすべてを格納する。各種実施例では、制御レジスタ１０６は、各バッファ領域１３２のスタート位置に関するリード及びライトオフセットを保持する。リード及び／又はライトオフセットは、ゼロの値からスタートし、リードリクエスト又はライトリクエストに応答してインクリメントされてもよい。共有バッファ１２０は、循環的なストレージとして扱われてもよく、リード及び／又はライトオフセットは、それらが対応する領域１３２のエンドに到達すると、ゼロにラップバック（ｗｒａｐ ｂａｃｋ）する（図１に図示されないラップアラウンドロジックを用いて）。共有バッファ１２０は、ビデオ処理に用いられるメモリデータのためのメインプリフェッチストレージとして機能するようにしてもよい。ＦＩＦＯ１２４は、システム１００の外部のメモリに発行されたリクエストを格納するのに利用されてもよい。
【００１８】
本開示によると、ビデオデコーダアーキテクチャは、システム１００などの単一の制御機構を用いて、共有バッファメモリとの間でビデオデータを読み及び／又は書き込む。さらに、ドライバレジスタ１０２を介しシステム１００とインタフェースをとるソフトウェアドライバは、使用モデルに従ってバッファ１２０のサイズ及び／又は領域１３２の個数及びサイズを調整することが可能とされてもよい。さらに、共有バッファ１２０は、ストリーム毎の異なるメモリ遅延を補償するよう再構成されてもよい。
【００１９】
本開示によると、ソフトウェアドライバは、バッファ領域１３２の個数及び／又はサイズを初期的にプログラムするのに利用されてもよい。共有バッファ１２０のプログラムされたコンフィギュレーションは、発行されたすべてのメモリリクエストが処理されるまで維持されてもよい。さらに、ハードウェアは、メモリリクエストを実行し、各バッファ領域１３２からデータを独立に読むことが可能とされてもよい。
【００２０】
システム１００の各種コンポーネントは、ソフトウェア、ファームウェア、ハードウェア及び／又はこれらの何れかの組み合わせにより実現されてもよい。例えば、システム１００の各種コンポーネントは、少なくとも家電（ＣＥ）システムにあるようなコンピューティングＳｏＣ（Ｓｙｓｔｅｍ−ｏｎ−ａ−Ｃｈｉｐ）のハードウェアにより提供されてもよい。例えば、非限定的な一例では、システム１００は、セットトップボックスなどのＣＥ装置により実現されてもよい。
【００２１】
図２は、本開示の各種実現形態によるメモリリクエスト処理のための一例となる処理２００のフロー図を示す。処理２００は、図２のブロック２０２，２０４，２０６，２０８，２１０，２１２，２１４，２１６の１以上により示されるような１以上の処理、機能又はアクションを含む物であってもよい。非限定的な一例によると、処理２００は、図１の一例となるシステム１００を参照して説明される。処理２００は、ブロック２０２から開始される。
【００２２】
ブロック２０２において、共有バッファが設定される。各種実現形態では、例えば、共有バッファ１２０は、コンフィギュレーションデータが異なるデコーダ処理に関するドライバにより提供されるレジスタ１０２に保持されるコンフィギュレーションデータに応答して、バッファ１２０をバッファ領域１３２に論理分割することによって構成されてもよい。本開示によると、ブロック２０２は、マルチフォーマットビデオ処理を可能にするため、共有バッファを異なる領域に分割することを含む。
【００２３】
図３は、ブロック２０２において６つのバッファ領域３０２〜３１２に構成される共有バッファ１２０の一例となる構成３００を示す。上述されるように、共有バッファ１２０の全体のサイズは、ドライバレジスタ１０２に保持されるコンフィギュレーションデータにより指定されるような領域１３２の個数及びサイズに依存して動的に決定される。
【００２４】
一例となる構成３００では、レジスタ１０２に保持されるコンフィギュレーションデータは、バッファ領域が１つのビデオフォーマット又は規格に従ってビデオ処理に利用可能となるようにバッファ領域３０２，３０４，３０６のサイズを指定する一方、これらの領域が他のビデオフォーマット又は規格に従ってビデオ処理に利用されるようにバッファ領域３０８，３１０，３１２のサイズを指定する。例えば、一例となる構成３００は、ローストア（ｒｏｗｓｔｏｒｅ）演算を実行するときにＡＶＣデコーダによる利用のためにこれら別々のバッファ３０２，３０４，３０６を備える一方、構成３００はまた、ＶＣ−１デコーダ処理による利用のためにローストアバッファ３０８、ＤＭＶ（Ｄｉｆｆｅｒｅｎｔｉａｌ Ｍｏｔｉｏｎ Ｖｅｃｔｏｒ）バッファ３１０及びビットプレーンバッファ３１２を備えるようにしてもよい。
【００２５】
ここに開示される構成３００は、異なる２つのビデオ処理規格に整合する処理により利用される異なるバッファ領域を備えるが、本開示による共有バッファは、何れかの個数のビデオ処理フォーマット又は規格により利用される何れかの個数及び／又は相対的なサイズのバッファ領域を備えるよう構成されてもよい。さらに、構成３００ほぼ等しいサイズのバッファ領域３０２〜３１２を示すが、構成３００は単なる一例であり、領域１３２の相対的なサイズ及び個数は各種実現形態では異なって構成されてもよいことを当業者は認識するであろう。例えば、ローストア処理中にＡＶＣデコーダにより利用されるよう構成されるバッファ３０２，３０４，３０６はほぼ等しいサイズを有してもよいが、ＤＭＶバッファ３１０は、バッファ３０２，３０４又は３０６の何れかより大きく、ビットプレーンバッファ３１２は、バッファ３０２，３０４又は３０６の何れかより小さくてもよい。
【００２６】
さらに、各種実現形態では、ブロック２０２は、１以上のビデオピクチャ又はフレームに対応するビットストリームデータを処理するため、又はビデオピクチャスライスなどのビデオフレームの一部のために共有バッファを構成することに関する。例えば、ブロック２０２は、外部メモリに格納されるビデオのフレームのスライスなどの少なくとも一部に対応するリードデータストリームを処理するために共有バッファ１２０を構成することに関し、後述されるように、処理２００がフレームデータの異なる部分をバッファ１２０に書き込むための外部メモリへのアクセスを要求する連続的なインスタンスに関する。ブロック２０４において、第１リードストリームに対するメモリリクエストが受信される。
【００２７】
図４は、本開示の各種実現形態によりブロック２０４のメモリリクエスト処理に関する一例となるシステム１００を示す。図４に示されるように、Ｒ／Ｗインタフェース１１０は、メモリからピクセル値などのデータを読むため、外部メモリへのアクセスを求めるメモリリクエスト４００を受信する。例えば、ＡＶＣデコーダは、ブロック２０２においてメモリリクエストを提供し、メモリリクエスト４００は、外部メモリからピクセルデータを読むことを求めるリードストリーム処理の一部であってもよい。例えば、ブロック２０４は、ＡＶＣデコーダ処理により実行されるローストア処理中に実行されてもよい。ここで用いられるピクセルデータとは、限定することなく、マクロブロック、ブロック及び／又はサブブロックデータ値（ピクセルＹＵＶ値など）、動きベクトルデータ値（Ｘ及びＹオフセットなど）、イントラブロック及び／又はインターブロックデータ値（量子化されたＡＣ及び／又は量子化されたＤＣ係数など）など、ビデオデコーダ処理に用いられる何れかの形態のデータを表す。
【００２８】
図１及び４に示されるような一例となるシステム１００を再び参照して、ブロック２０４において受信されるメモリリクエスト４００は、Ｍｅｍｏｒｙ Ｒｅｑｕｅｓｔ（Ｍｅｍ＿Ｒｅｑ）、Ｍｅｍｏｒｙ Ｂｕｆｆｅｒ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ（Ｍｅｍ＿Ｂｕｆｆｅｒ＿ＩＤ）、及びＭｅｍｏｒｙ Ａｄｄｒｅｓｓ（Ｍｅｍ＿Ａｄｄｒ）の各信号を含む。インタフェース１１０は、Ｍｅｍ＿Ｒｅｑ信号をＦＩＦＯ１２４とイネーブルロジック１１６との双方に提供する。Ｍｅｍ＿Ａｄｄｒ信号は、メモリリクエストが送付先である外部メモリのアドレスを指定し、ＦＩＦＯ１２４に提供される。Ｍｅｍ＿Ｂｕｆｆｅｒ＿ＩＤ信号は、メモリリクエストに応答して何れのバッファ領域１３２が使用されるべきか指定し、ドライバレジスタ１０２及び制御レジスタ１０６のそれぞれに関連するマルチプレクサ１０４，１０８にＲ／Ｗインタフェース１１０によって提供される。各種実現形態では、ブロック２０４においてメモリリクエスト４００を発行したハードウェアはまず、信号１３０の１つとして提供されるＲｅａｄ＿Ｄｏｎｅ信号を確認する。
【００２９】
ブロック２０６において、バッファライトアドレスが決定される。図４に示されるように、ブロック２０４においてマルチプレクサ１０４，１０８に提供されるＭｅｍ＿Ｂｕｆｆｅｒ＿ＩＤ信号は、各自のレジスタ１０２，１０６に格納されるデータと共に、Ｗｒｉｔｅ Ｂｕｆｆｅｒ Ｏｆｆｓｅｔ（ＷＢＯ）信号とＢｕｆｆｅｒ Ｂａｓｅ Ａｄｄｒｅｓｓ（ＢＢＡ）信号とを選択するのに利用される。ＷＢＯ及びＢＢＡ信号は、Ｓｔｏｒａｇｅ Ｗｒｉｔｅ Ａｄｄｒｅｓｓ（ＳＷＡ）信号を構成するためＷＢＯ及びＢＢＡ信号を論理合成する加算ロジック１１２に提供される。ＳＷＡ信号とＭｅｍ＿Ｒｅｑ信号との双方に応答して、イネーブルロジック１１６は、共有バッファ１２０にライトイネーブル（ＷＥ）信号を提供する。
【００３０】
ＷＥ信号は、ブロック２０４において受信したメモリリクエストにより求められるピクセルデータを一時的に格納するため指定されたバッファ１２０の特定の領域１３２内の位置又はアドレスを指定する。例えば、デコーダがブロック２０４においてリードリクエストの第１インスタンスを実行するとき、ＳＷＡ信号は、領域１３２内の開始又はスタートアドレスを示す。従って、ＷＢＯ信号は、ゼロ（０）の初期値を有してもよい。例えば、図３を参照して、ＡＶＣデコーダは、メモリリクエストのターゲットバッファとしてローストアバッファ３０２などを指定するＭｅｍ＿Ｂｕｆｆｅｒ＿ＩＤと共に、ブロック２０４においてリードリクエストを提供するようにしてもよい。ＳＷＡ信号は、バッファ３０２の正確な位置がＷＢＯ信号の値に依存するローストアバッファ３０２内の位置又はアドレスを指定する。
【００３１】
ＷＥ信号の受信に応答して、共有バッファ１２０は、システム１００がメモリリクエストｗｐ受信し、応答を開始したことを示すＷＲＰ（Ｗｒｉｔｅ Ｒｅｑｕｅｓｔ ｉｎ Ｐｒｏｇｒｅｓｓ）信号をアサートする。さらに、ブロック２０４においてメモリリクエストを受信することに応答して、システム１００は、後述されるように、データがメモリから返されるとき、ＳＷＡ信号により示される領域１３２内のライト位置又はアドレスを決定するのに利用可能なＭｅｍ＿Ｔａｇ信号を構成するため、ＷＢＯ及びＢＢＡ信号を合成する。Ｍｅｍ＿Ｔａｇ，Ｍｅｍ＿Ｒｅｑ及びＭｅｍ＿Ａｄｄｒの各信号は、ＦＩＦＯ１２４に格納され、以降にメモリインタフェースに提供される。ブロック２０８において、第１リードストリームのピクセルデータは、共有バッファに書き込まれてもよい。
【００３２】
図５は、本開示の各種実現形態によるブロック２０８におけるデータリターン処理に関してシステム１００を示す。図２及び５を参照して、各種実現形態では、ブロック２０８は、外部メモリがＭｅｍ＿Ａｄｄｒ信号を用いて読み込み対象のピクセルデータを決定することに関する。例えば、Ｍｅｍ＿Ａｄｄｒ信号は、外部メモリに格納されるピクセル値のローを示す。
【００３３】
外部メモリは、その後にシステム１００のメモリインタフェースを介し、Ｍｅｍ＿Ｄａｔａ信号としてピクセルデータを共有バッファ１２０に提供する。外部メモリにより提供されるＭｅｍ＿Ｔａｇ信号のＢＢＡ及びＷＢＯコンポーネントが、イネーブルロジック１１６にＳＷＡ信号を提供するため、ロジック１１２により加えられる。ロジック１１６は、その後に、Ｍｅｍｏｒｙ Ｒｅｑｕｅｓｔ Ｒｅｔｕｒｎ（Ｍｅｍ＿Ｒｅｑ＿Ｒｅｔｕｒｎ）に応答して、ＳＷＡ信号により示される部分１３２内の特定のアドレスにピクセルデータ（Ｍｅｍ＿Ｄａｔａ信号などに対応する）をバッファ１２０に格納させるＷＥ信号をバッファ１２０に提供する。上述した例に続いて、ＳＷＡ信号はローストアバッファ３０２内のアドレスを指定する場合、ブロック２０８は、ＡＶＣデコーダ処理によるローストア処理中にピクセルデータを当該位置に格納する。例えば、ピクセルデータのローは、ＳＷＡ信号により指定される位置から始まって格納される。
【００３４】
ピクセルデータが共有バッファに書き込まれると、システム１００は、要求されたピクセルデータがバッファ１２０から読み出されるのに利用可能であることをハードウェアに示すＤａｔａ Ａｖａｉｌａｂｌｅ（Ｄａｔａ＿Ａｖａｉｌ）信号をアサートする。さらに、ブロック２０８においてリードデータを書き込むとき、システム１００はまた、以降のメモリリクエストがバッファ１２０の特定の領域１３２内の次の位置にデータを書き込むように、ＷＢＯ値をインクリメントする。処理２００は、ブロック２１０において共有バッファから第１リードストリームピクセルデータを読み続ける。
【００３５】
図６は、本開示の各種実現形態によるブロック２１０におけるリードリクエスト処理に関する一例となるシステム１００を示す。図６に示されるように、ブロック２１０は、ブロック２０８の結果として共有バッファに格納されているピクセルデータにアクセスするため、Ｒ／Ｗインタフェース１１０がリードリクエスト６００を受信することを含む。例えば、ＡＶＣ復号化処理は、ローストア処理の実行中にブロック２１０においてリードリクエスト６００を提供する。
【００３６】
リードリクエスト６００は、Ｒｅａｄ Ｂｕｆｆｅｒ Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ（Ｒｅａｄ＿Ｂｕｆｆｅｒ＿ＩＤ）信号、Ｒｅａｄ Ｒｅｑｕｅｓｔ（Ｒｅａｄ＿Ｒｅｑ）信号及びＲｅａｄ＿Ｂｕｆｆｅｒ＿Ｅｖｉｃｔ信号を含む。Ｒｅａｄ＿Ｂｕｆｆｅｒ＿ＩＤ信号は、対応するＢＢＡ信号を提供するためマルチプレクサ１０４と、Ｒｅａｄ Ｂｕｆｆｅｒ Ｏｆｆｓｅｔ（ＲＢＯ）信号を提供するためマルチプレクサ１０８に提供される。ロジック１１４は、その後にブロック２１０において読み出されるピクセルデータを格納するバッファ１２０の特定の領域１３２内の特定の位置を示すＳｔｏｒａｇｅ Ｒｅａｄ Ａｄｄｒｅｓｓ（ＳＲＡ）信号を生成するため、ＲＢＯ信号をＢＢＡ信号に加える。上述した例に続いて、ＳＲＡ信号が、ブロック２０８においてピクセルデータが書き込まれたローストアバッファ３０２内のアドレスを指定する場合、ブロック２１０において、当該ピクセルデータがＡＶＣデコーダによるローストア処理中に当該位置から読まれる。例えば、ブロック２１０は、ピクセル値のローが共有バッファ１２０から読まれることに関する。
【００３７】
いくつかの実現形態では、ブロック２１０は、ハードウェアがＳＲＡ信号により示される位置の状態を確認できるように、Ｒｅａｄ＿Ｒｅｑ信号を設定している間にはＲｅａｄ＿Ｂｕｆｆｅｒ＿Ｅｖｉｃｔ信号を設定しないことに関する。その実行中に、ハードウェアが、当該位置においてデータが読み出しに利用可能であることを示すＲｅａｄ＿Ｄａｔａ信号が設定されていることを検出する場合、ハードウェアは、Ｒｅａｄ＿Ｄａｔａ信号にアクセスすることによって、共有バッファ１２０からデータを読むため、Ｒｅａｄ＿Ｒｅｑ信号とＲｅａｄ＿Ｂｕｆｆｅｒ＿Ｅｖｉｃｔとの双方を設定することによって、ブロック２１０の実現を継続してもよい。
【００３８】
イネーブルロジック１１８は、Ｒｅａｄ Ｅｎａｂｌｅ（ＲＥ）信号をバッファ１２０に提供することによって、ＳＲＡ信号、Ｒｅａｄ＿Ｒｅｑ信号及びＲｅａｄ＿Ｂｕｆｆｅｒ＿Ｅｖｉｃｔ信号に応答する。ＲＥ信号に関連して、ＳＲＡはマルチプレクサ１２２に提供され、格納されているデータはＲｅａｄ＿Ｄａｔａ信号として現れる。さらに、ブロック２１０においてリードデータを提供するとき、システム１００は、データがさらに利用されないことを示すＲｅａｄ＿Ｄｏｎｅ信号を設定し、以降のリードリクエストがバッファ１２０の特定の領域１３２内の次の位置にあるように、レジスタ１０６に格納されているＲＢＯ値をインクリメントしてもよい。
【００３９】
図２に戻って、処理２００は、ブロック２１２に続き、第１リードストリームの処理が続けられるべきか判断される。例えば、各種実現形態では、ビデオデコーダは、リードストリーム処理のためピクセルデータを取得する初期的な処理として、ブロック２０４〜２１０の最初の繰り返しを実行する。ビデオデコーダは、その後に、リードストリーム処理のピクセルデータの追加的な部分を取得するため、ブロック２０４〜２１０の１以上のさらなる繰り返しを実行する。従って、ブロック２１２において、第１リードストリームのさらなる処理が続けられるべきであると判断された場合、デコーダは、ブロック２０４〜２１２のもう１回の繰り返しを実行する前に、ブロック２１４においてメモリアドレスを修正するよう動作する（例えば、Ｍｅｍ＿Ａｄｄｒ信号値をインクリメントすることによって）。各種実現形態では、ビデオデコーダの処理は、ブロック２１２の最後のインスタンスにおいて、第１リードストリームの処理が終了したとデコーダが判断するまで、ブロック２０４〜２１４のロープ処理を継続する。例えば、処理２００を実行するＡＶＣデコーダは、ブロック２１２の最後のインスタンスにおいて、例えば、第１リードストリームの処理に対応するローストア処理が外部メモリから所望量のピクセルデータを取得したとき、第１リードストリームの処理が終了したと判断してもよい。他方、ブロック２１２において、第１リードストリームの処理が継続されるべきでないと判断された場合、処理２００は、さらなる処理、機能又はアクションによりブロック２１６において続けられる。
【００４０】
図７は、本開示の各種実現形態により示されるメモリリクエスト処理のための一例となる処理２００のさらなる部分を示す。処理２００は、ブロック２１８，２２０，２２２，２２４，２２６，２２８，２３０，２３２の１以上により示されるような１以上のさらなる処理、機能又はアクションを含む。非限定的な例により、図７に示されるような処理２００は、図１の一例となるシステム１００を参照して再び開示される。処理２００は、ブロック２１８において続けられる。
【００４１】
ブロック２１８において、共有バッファが再構成されるべきか判断される。各種実現形態では、ブロック２１８は、共有バッファ１２０が他のビデオ処理リードストリームなどの新たな又は第２のリードストリームの処理を実行するよう再構成される必要があるか判断することに関する。例えば、ＡＶＣデコーダにより生成されるリードストリームなどの第１ビデオフォーマット又は規格に準拠する第１リードストリームのリードストリーム処理が、図２のブロック２０４〜２１４において実行される間、ブロック２１８は、ＶＣ−１デコーダなどにより実行可能な他のビデオフォーマット又は規格に関する第２リードストリームの処理を実行するため共有バッファ１２０が再構成される必要があるか判断することに関する。
【００４２】
ブロック２１８において、共有バッファが再構成されるべきでないと判断された場合、処理２００は、第２リードストリームに対するメモリリクエストの受信（ブロック２２２）、当該メモリリクエストのバッファライトアドレスの決定（ブロック２２４）、当該第２リードストリームのピクセルデータの共有バッファへの書き込み（ブロック２２６）、及びブロック２２８における共有バッファからの当該ピクセルデータの読み込みに続く。ブロック２２２，２２４，２２６，２２８はそれぞれ、図２のブロック２０４，２０６，２０８，２１０について上述したのと同様に実行される。
【００４３】
各種実現形態では、図７のブロック２２２〜２２８において第２リードストリームの処理を可能にする方法により共有バッファがブロック２０２（図２）において構成されたとき、再構成がブロック２１８において実行されるべきでないと判断される。例えば、図３の一例となる構成３００を参照すると、第２リードストリームがＶＣ−１デコーダのリードストリームである場合、ブロック２０２におけるＶＣ−１デコーダの処理に適するよう構成された領域３０８，３１０，３１２を含む共有バッファ１２０は、再構成することなく図７のブロック２２２〜２２８において第２リードストリームの処理を実行するのに適するよう構成される。
【００４４】
他方、ブロック２１８において再構成が実行されるべきであると判断された場合、処理２００は、共有バッファを再構成することによってブロック２２０に続く。例えば、ブロック２１８において、共有バッファ１２０が第２リードストリームの処理を実現する方法により構成されていないと判断される可能性がある。各種実現形態では、ブロック２２０は、１以上のビデオデコーダの処理に関するソフトウェアドライバによってコンフィギュレーションデータがレジスタ１０２に配置されることに応答して実行される。例えば、第２リードストリームの処理を実行するＶＣ−１デコーダの処理に関するソフトウェアドライバは、コンフィギュレーションデータをレジスタ１０２に提供する。その後、システム１００は、第２リードストリームに関するコンフィギュレーションデータを利用して、共有バッファ１２０を再構成する。例えば、共有バッファ１２０は、図２のブロック２０４〜２１４において処理されたビデオビットストリームのフォーマットと異なるフォーマットに従って符号化されたビデオビットストリームを復号化するためシステム１００が呼び出されることに応答して、ブロック２２０において動的に再構成されてもよい。
【００４５】
図８は、図２のブロック２０２において実行された共有バッファ１２０の一例となる初期的な構成８００と、図７のブロック２２０において実行される共有バッファ１２０の一例となる再構成８１０とを示す。図８の例では、ブロック２０２（図２）において、共有バッファ１２０は、ローストア処理を実現するＡＶＣデコーダに準拠するよう構成される３つの同様のサイズのローストアバッファ８０２，８０４，８０６を有するよう構成されてもよい。この非限定的な例では、バッファ８０２，８０４，８０６を備えるよう構成されるとき、共有バッファ１２０がブロック２０２において具体的にフォーマット化又は設定されなかったさらなる領域を含むように、共有バッファ１２０は所定の全体サイズを有する。
【００４６】
図８の例では、ブロック２２０は、もはやバッファ８０２，８０４，８０６を含まず、対応するリードストリーム処理を実現するＶＣ−１デコーダに適したローストアバッファ８１２、ＤＭＶバッファ８１４及びビットプレーンバッファ８１６に適した領域に対応する新たに構成された領域を含むよう共有バッファ１２０を動的に再構成することに関する。ブロック２２０における再構成後、具体的にフォーマット化されなかった領域８０８が以前として存在するが、新たに構成されたバッファ８１２，８１４，８１６のサイズに依存して構成８００にあるものと異なるサイズを有してもよい。
【００４７】
図７に戻って、ブロック２２０における再構成後、処理２００は、第２リードストリームに対するメモリリクエストの受信（ブロック２２２）、当該メモリリクエストのバッファライトアドレスの決定（ブロック２２４）、第２リードストリームのピクセルデータの共有バッファへの書き込み（ブロック２２６）、及びブロック２２８における共有バッファからピクセルデータの読み出しに続く。ブロック２２２，２２４，２２６，２２８はそれぞれ、図２のブロック２０４，２０６，２０８，２１０について上述したのと同様の方法により実行されてもよい。
【００４８】
処理２００は、ブロック２３０に続き、第２リードストリームの処理が継続されるべきか決定される。例えば、各種実現形態では、ビデオデコーダは、リードストリーム処理のピクセルデータを取得する最初の部分としてブロック２２２〜２２８の最初の繰り返しを実行した。その後、ビデオデコーダは、リードストリームの処理のためピクセルデータのさらなる部分を取得するために、ブロック２２２〜２２８の１以上のさらなる繰り返しを実行する。従って、ブロック２３０において、第１リードストリームの処理が継続されるべきであるとデコーダが判断した場合、デコーダは、ブロック２２２〜２３０のもう１回の繰り返しを実行する前に、ブロック２３２においてメモリアドレスを修正するよう動作する（例えば、Ｍｅｍ＿Ａｄｄｒ信号値をインクリメントすることによって）。各種実現形態では、ビデオデコーダの処理は、ブロック２３０の最後のインスタンスにおいて、第２リードストリームの処理が終了したとデコーダが判断するまで、ブロック２２２〜２３２のループを継続する。例えば、図７に示されるような処理２００を実行するＶＣ−１デコーダは、ブロック２３０の最後のインスタンスにおいて、第２リードストリームの処理が継続されるべきでなく、処理２００が終了されるべきであると判断する。
【００４９】
図２及び７に示されるように、一例となる処理３００の実現は図示された順序によりブロック２０２〜２３２のすべてを実行することを含むが、請求される主題はこれに限定されず、各種具体例では、処理２００の実現は、図示された以外の順序により及び／又はブロック２０２〜２３２の一部のみを実行することを含むものであってもよい。
【００５０】
図２及び７の処理及び／又はブロックの何れか１以上は、１以上のコンピュータプログラムにより提供される命令に応答して実行されてもよい。このようなプログラムは、例えば、１以上のプロセッサコアにより実行されると、図１〜８に関して上述された機能を提供する命令を提供する媒体を担持する信号を含むものであってもよい。コンピュータプログラムは、何れかの形態のコンピュータ可読記憶媒体により提供されてもよい。例えば、１以上のプロセッサコアを含むプロセッサは、コンピュータ可読記憶媒体によりプロセッサに搬送される命令に応答して、図２及び７に示されるブロックの１以上を実行してもよい。
【００５１】
図９は、本開示による一例となるシステム９００を示す。システム９００は、ここに開示される各種機能の一部又はすべてを実行するのに利用され、本開示の各種実現形態に従ってマルチフォーマットビデオ処理のための設定可能なバッファ割当てを提供可能な何れかの装置又は装置群を含むものであってもよい。システム９００は、ＶＬＳＩ（Ｖｅｒｙ Ｌａｒｇｅ Ｓｃａｌｅ Ｉｎｔｅｇｒａｔｉｏｎ） ＳｏＣ ＩＣ（Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）９０２と、ＩＣ９０２に通信及び／又は動作接続する外部メモリ９０４とを有する。ＩＣ９０２は、１以上のプロセッサコア（図示せず）を有し、限定することなく、ＣＩＳＣ（Ｃｏｍｐｌｅｘ Ｉｎｓｔｒｕｃｔｉｏｎ Ｓｅｔ Ｃｏｍｐｕｔｅｒ）、ＲＩＳＣ（Ｒｅｄｕｃｅｄ Ｉｎｓｔｒｕｃｔｉｏｎ Ｓｅｔ Ｃｏｍｐｕｔｉｎｇ）マイクロプロセッサコア、ＶＬＩＷ（Ｖｅｒｙ Ｌｏｎｇ Ｉｎｓｔｒｕｃｔｉｏｎ Ｗｏｒｄ）マイクロプロセッサコア、何れかの命令セットの組み合わせを実現する１以上のプロセッサコア、又はデジタル信号プロセッサ若しくはマイクロコントローラなどの他の何れかのプロセッサ装置など、１以上のプロセッサコアを含む何れかのタイプのプロセッサベースシステムであってもよい。例えば、ＩＣ９０２は、複数のプロセッサコアを有し、モバイルコンピューティング装置（スマートフォン、タブレットコンピュータなど）などの家電（ＣＥ）装置により実現されてもよい。メモリ９０４は、限定することなく、ＤＲＡＭメモリ、ＳＲＡＭメモリ、フラッシュメモリなどを含む何れかのタイプのメモリであってもよい。
【００５２】
ＩＣ９０２は、キャッシュメモリなどの内部メモリ９０６を有し、ここに開示される各種構成、処理、機能及び／又はアクションを備える及び／又は実行するよう構成されるロジックを有するビデオハードウェアアクセラレーションエンジン（ＨＡＥ）９０８を備える及び／又はサポートするものであってもよい。ビデオＨＡＥ９０８は、ここに開示されるような動的に構成可能な共有バッファ９１０と共にこれを実行する。上述され、図９に示されるように、バッファ９１０は、内部メモリ９０６の少なくとも一部から構成されてもよい。各種実現形態では、図１のシステム１００は、少なくとも部分的にビデオＨＡＥ９０８及び共有バッファ９１０により提供される。さらに、共有バッファ９１０と共にビデオＨＡＥ９０８は、ＩＣ９０２に提供されるビデオデータの異なってフォーマット化されたストリームＡ及びＢに応答して、ここに開示される図２及び７のブロックの何れかを実行するようにしてもよい。ビデオＨＡＥ９０８は、コーデックモードの処理及び／又はあるタイプのビデオストリームが現在処理されていることに応答して、プリフェッチバッファサイズを調整してもよい。
【００５３】
図１０は、本開示による一例となるシステム１０００を示す。システム１０００は、ここに開示される各種機能の一部又はすべてを実行するのに利用され、本開示の各種実現形態によるマルチフォーマットビデオ処理のための設定可能なバッファ割当てを実行可能な何れかの装置又は装置群を含む。例えば、システム１０００は、本開示がこれに限定されるものでないが、デスクトップ、モバイル若しくはタブレットコンピュータ、スマートフォン、セットトップボックスなどの計算プラットフォーム又は装置の選択されたコンポーネントを有してもよい。いくつかの実現形態では、システム１０００は、ＣＥ装置のためのＩｎｔｅｌ（登録商標）アーキテクチャ（ＩＡ）に基づき計算プラットフォーム又はＳｏＣであってもよい。ここに開示される実現形態は本開示の範囲から逸脱することなく他の処理システムと共に利用可能であることは、当業者に容易に理解されるであろう。
【００５４】
システム１０００は、１以上のプロセッサコア１００４を有するプロセッサ１００２を有する。プロセッサコア１００４は、少なくとも部分的にソフトウェアを実行し、及び／又はデータ信号を処理可能な何れかのタイプのプロセッサロジックであってもよい。各種具体例では、プロセッサコア１００４は、ＣＩＳＣプロセッサコア、ＲＩＳＣマイクロプロセッサコア、ＶＬＩＷマイクロプロセッサコア及び／又は何れかの命令セットの組み合わせを実現する任意数のプロセッサコア又はデジタル信号プロセッサやマイクロコントローラなどの他の何れかのプロセッサ装置を有してもよい。
【００５５】
プロセッサ１００２はまた、ディスプレイプロセッサ１００８及び／又はグラフィックプロセッサ１０１０などにより受信される命令を制御信号及び／又はマイクロコードエントリポイントに復号化するのに利用可能なデコーダ１００６を有する。コア１００４と別々のコンポーネントとしてシステム１０００に示されるが、当業者は、１以上のコア１００４がデコーダ１００６、ディスプレイプロセッサ１００８及び／又はグラフィックプロセッサ１０１０を実現可能であることを理解するであろう。いくつかの実現形態では、デコーダ１００６は、図１〜９に関して説明される一例となる処理を含む、ここに開示される処理の何れかを実行するよう構成されるビデオデコーダであってもよい。さらに、制御信号及び／又はマイクロコードエントリポイントに応答して、ディスプレイプロセッサ１００８及び／又はグラフィックプロセッサ１０１０は、対応する処理を実行する。
【００５６】
プロセッサコア１００４、デコーダ１００６、ディスプレイプロセッサ１００８及び／又はグラフィックプロセッサ１０１０は、限定することなく、例えば、メモリコントローラ１０１４、オーディオコントローラ１０１８及び／又は周辺装置１０２０を含む他の各種システム装置と、及び／又は互いにシステムインターコネクト１０１６を介し通信及び／又は動作接続される。周辺装置１０２０は、例えば、ＵＳＢ（Ｕｎｉｆｉｅｄ Ｓｅｒｉａｌ Ｂｕｓ）ホストポート、ＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ）Ｅｘｐｒｅｓｓポート、ＳＰＩ（Ｓｅｒｉａｌ Ｐｅｒｉｐｈｅｒａｌ Ｉｎｔｅｒｆａｃｅ）インタフェース、拡張バス及び／又は他の周辺装置などを含む。図１０はインターコネクト１０１６によりデコーダ１００６及びプロセッサ１００８，１０１０に接続されるものとしてメモリコントローラ１０１６を示しているが、各種実現形態では、メモリコントローラ１０１４は、デコーダ１００６、ディスプレイプロセッサ１００８及び／又はグラフィックプロセッサ１０１０に直接接続されてもよい。
【００５７】
いくつかの実現形態では、システム１０００は、Ｉ／Ｏバス（図示せず）を介し図１０に図示されない各種Ｉ／Ｏ装置と通信する。このようなＩ／Ｏ装置は、限定することなく、例えば、ＵＡＲＴ（Ｕｎｉｖｅｒｓａｌ Ａｓｙｎｃｈｒｏｎｏｕｓ Ｒｅｃｅｉｖｅｒ／Ｔｒａｎｓｍｉｔｔｅｒ）装置、ＵＳＢ装置、Ｉ／Ｏ拡張インタフェース又は他のＩ／Ｏ装置を含む。各種実現形態では、システム１０００は、モバイル、ネットワーク及び／又は無線通信を実行するためのシステムの少なくとも一部を表す。
【００５８】
システム１０００はさらに、メモリ１０１２を有する。メモリ１０１２は、ＤＲＡＭ装置、ＳＲＡＭ装置、フラッシュメモリ装置、又は他のメモリ装置などの１以上のメモリコンポーネントであってもよい。図１０は、プロセッサ１００２の外部のものとしてメモリ１０１２を示しているが、各種実現形態では、メモリ１０１２はプロセッサ１００２の内部にあってもよい。メモリ１０１２は、プロセッサ１００２により実行可能なデータ信号により表される命令及び／又はデータを格納する。いくつかの実現形態では、メモリ１０１２は、システムメモリ部とディスプレイメモリ部とを含むものであってもよい。
【００５９】
上述されたシステムと、それにより実行されるここに開示された処理とは、ハードウェア、ファームウェア、ソフトウェア又はこれらの何れかの組み合わせにより実現されてもよい。さらに、ここに開示される１以上の特徴は、個別及び一体化された回路ロジック、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）ロジック及びマイクロコントローラを含む、ハードウェア、ソフトウェア、ファームウェア及びこれらの組み合わせにより実現されてもよく、ドメイン固有のＩＣパッケージ又はＩＣパッケージの組み合わせの一部として実現されてもよい。ここに用いられるソフトウェアという用語は、コンピュータシステムにここに開示される１以上の機能及び／又はその組み合わせを実行させるよう格納されたコンピュータプログラムロジックを有するコンピュータ可読媒体を含むコンピュータプログラムを表す。
【００６０】
ここに提供される特徴が各種実現形態を参照して説明されたが、本開示は限定的な意味で解釈されるべきでない。ここに開示される実現形態の各種変更は、本開示が属する当業者に明らかな他の実現形態と共に、本開示の趣旨及び範囲内にあるとみなされる。
【符号の説明】
【００６１】
１０００ システム
１００２ プロセッサ
１０１２ メモリ
【特許請求の範囲】
【請求項１】
コンピュータにより実現される方法であって、
第１ビデオコーデックフォーマットに関連する第１リードストリームと、前記第１ビデオコーデックフォーマットと異なる第２ビデオコーデックフォーマットに関連する第２リードストリームとの処理をサポートするよう共有バッファを構成するステップと、
前記第１リードストリームに関連するメモリリクエストに応答して、前記共有バッファ内の第１バッファライトアドレスを決定するステップと、
前記第２リードストリームに関連するメモリリクエストに応答して前記共有バッファ内の前記第１バッファライトアドレスと異なる第２バッファライトアドレスを決定するステップと、
を有する方法。
【請求項２】
前記第１バッファライトアドレスにピクセルデータを書き込むステップと、
前記共有バッファから前記ピクセルデータを読むステップと、
をさらに有する、請求項１記載の方法。
【請求項３】
前記第２バッファライトアドレスに第２ピクセルデータを書き込むステップと、
前記共有バッファから前記第２ピクセルデータを読むステップと、
をさらに有する、請求項２記載の方法。
【請求項４】
前記共有バッファは、プリフェッチバッファを有する、請求項１記載の方法。
【請求項５】
前記共有バッファは、キャッシュメモリを有する、請求項１記載の方法。
【請求項６】
前記共有バッファを構成するステップは、コンフィギュレーションデータに応答して前記共有バッファを構成することを有し、
前記コンフィギュレーションデータは、前記第１リードストリームに関連する第１ソフトウェアドライバと、前記第２リードストリームに関連する第２ソフトウェアドライバとにより提供されたものである、請求項１記載の方法。
【請求項７】
前記コンフィギュレーションデータは、前記第１バッファライトアドレスと前記第２バッファライトアドレストとを指定する、請求項６記載の方法。
【請求項８】
第１ビデオコーデックフォーマットに関連する第１リードストリームの処理をサポートするよう共有バッファを構成するステップと、
前記第１リードストリームに関連するメモリリクエストに応答して、前記共有バッファ内の第１バッファライトアドレスを決定するステップと、
第２ビデオコーデックフォーマットに関連する第２リードストリームの処理をサポートするよう前記共有バッファを再構成するステップと、
前記第２リードストリームに関連するメモリリクエストに応答して、前記共有バッファ内の第２バッファライトアドレスを決定するステップと、
をプロセッサが実行する方法。
【請求項９】
前記共有バッファを再構成するステップの前に、
前記第１バッファライトアドレスにピクセルデータを書き込むステップと、
前記共有バッファから前記ピクセルデータを読むステップと、
をさらに有する、請求項８記載の方法。
【請求項１０】
前記共有バッファを再構成するステップの後に、
前記第２バッファライトアドレスに第２ピクセルデータを書き込むステップと、
前記共有バッファから前記第２ピクセルデータを読むステップと、
をさらに有する、請求項９記載の方法。
【請求項１１】
前記共有バッファは、プリフェッチバッファを有する、請求項８記載の方法。
【請求項１２】
前記共有バッファは、キャッシュメモリを有する、請求項８記載の方法。
【請求項１３】
前記共有バッファを構成するステップは、前記第１リードストリームに関連するソフトウェアドライバにより提供される第１コンフィギュレーションデータに応答して、前記共有バッファを構成することを有し、
前記共有バッファを再構成するステップは、前記第２リードストリームに関連するソフトウェアドライバにより提供される第２コンフィギュレーションデータに応答して、前記共有バッファを構成することを有する、請求項８記載の方法。
【請求項１４】
前記第１コンフィギュレーションデータは、前記第１バッファライトアドレスを指定し、
前記第２コンフィギュレーションデータは、前記第２バッファライトアドレスを指定する、請求項１３記載の方法。
【請求項１５】
プロセッサと、
前記プロセッサに接続されるメモリと、
を有するシステムであって、
前記プロセッサは、内部メモリを有し、
前記メモリの命令は、
第１ビデオコーデックフォーマットに関連する第１リードストリームの処理をサポートするよう前記内部メモリ内の共有バッファを構成し、
前記第１リードストリームに関連するメモリリクエストに応答して、前記共有バッファ内の第１バッファライトアドレスを決定し、
第２ビデオコーデックフォーマットに関連する第２リードストリームの処理をサポートするよう前記共有バッファを再構成し、
前記第２リードストリームに関連するメモリリクエストに応答して、前記共有バッファ内の第２バッファライトアドレスを決定する、
よう前記プロセッサを設定するシステム。
【請求項１６】
ＩＣに接続される外部メモリをさらに有し、
前記外部メモリは、第１ピクセルデータと第２ピクセルデータとを格納し、
前記第１ピクセルデータは前記第１リードストリームであり、前記第２ピクセルデータは前記第２リードストリームに関連する、請求項１５記載のシステム。
【請求項１７】
ロジックはさらに、
前記第１バッファライトアドレスに前記第１ピクセルデータを書き込み、
前記第２バッファライトアドレスに前記第２ピクセルデータを書き込む、
よう構成される、請求項１６記載のシステム。
【請求項１８】
前記ＩＣはさらに、前記第１リードストリームに関連する第１コンフィギュレーションデータを格納し、前記第２リードストリームに関連する第２コンフィギュレーションデータを格納するための１以上のレジスタを有する、請求項１５記載のシステム。
【請求項１９】
前記ロジックはさらに、
前記第１コンフィギュレーションデータに応答して、前記共有バッファを構成し、
前記第２コンフィギュレーションデータに応答して、前記共有バッファを再構成する、
よう構成される、請求項１８記載のシステム。
【請求項２０】
前記共有バッファは、プリフェッチバッファを有する、請求項１５記載のシステム。
【請求項１】
コンピュータにより実現される方法であって、
第１ビデオコーデックフォーマットに関連する第１リードストリームと、前記第１ビデオコーデックフォーマットと異なる第２ビデオコーデックフォーマットに関連する第２リードストリームとの処理をサポートするよう共有バッファを構成するステップと、
前記第１リードストリームに関連するメモリリクエストに応答して、前記共有バッファ内の第１バッファライトアドレスを決定するステップと、
前記第２リードストリームに関連するメモリリクエストに応答して前記共有バッファ内の前記第１バッファライトアドレスと異なる第２バッファライトアドレスを決定するステップと、
を有する方法。
【請求項２】
前記第１バッファライトアドレスにピクセルデータを書き込むステップと、
前記共有バッファから前記ピクセルデータを読むステップと、
をさらに有する、請求項１記載の方法。
【請求項３】
前記第２バッファライトアドレスに第２ピクセルデータを書き込むステップと、
前記共有バッファから前記第２ピクセルデータを読むステップと、
をさらに有する、請求項２記載の方法。
【請求項４】
前記共有バッファは、プリフェッチバッファを有する、請求項１記載の方法。
【請求項５】
前記共有バッファは、キャッシュメモリを有する、請求項１記載の方法。
【請求項６】
前記共有バッファを構成するステップは、コンフィギュレーションデータに応答して前記共有バッファを構成することを有し、
前記コンフィギュレーションデータは、前記第１リードストリームに関連する第１ソフトウェアドライバと、前記第２リードストリームに関連する第２ソフトウェアドライバとにより提供されたものである、請求項１記載の方法。
【請求項７】
前記コンフィギュレーションデータは、前記第１バッファライトアドレスと前記第２バッファライトアドレストとを指定する、請求項６記載の方法。
【請求項８】
第１ビデオコーデックフォーマットに関連する第１リードストリームの処理をサポートするよう共有バッファを構成するステップと、
前記第１リードストリームに関連するメモリリクエストに応答して、前記共有バッファ内の第１バッファライトアドレスを決定するステップと、
第２ビデオコーデックフォーマットに関連する第２リードストリームの処理をサポートするよう前記共有バッファを再構成するステップと、
前記第２リードストリームに関連するメモリリクエストに応答して、前記共有バッファ内の第２バッファライトアドレスを決定するステップと、
をプロセッサが実行する方法。
【請求項９】
前記共有バッファを再構成するステップの前に、
前記第１バッファライトアドレスにピクセルデータを書き込むステップと、
前記共有バッファから前記ピクセルデータを読むステップと、
をさらに有する、請求項８記載の方法。
【請求項１０】
前記共有バッファを再構成するステップの後に、
前記第２バッファライトアドレスに第２ピクセルデータを書き込むステップと、
前記共有バッファから前記第２ピクセルデータを読むステップと、
をさらに有する、請求項９記載の方法。
【請求項１１】
前記共有バッファは、プリフェッチバッファを有する、請求項８記載の方法。
【請求項１２】
前記共有バッファは、キャッシュメモリを有する、請求項８記載の方法。
【請求項１３】
前記共有バッファを構成するステップは、前記第１リードストリームに関連するソフトウェアドライバにより提供される第１コンフィギュレーションデータに応答して、前記共有バッファを構成することを有し、
前記共有バッファを再構成するステップは、前記第２リードストリームに関連するソフトウェアドライバにより提供される第２コンフィギュレーションデータに応答して、前記共有バッファを構成することを有する、請求項８記載の方法。
【請求項１４】
前記第１コンフィギュレーションデータは、前記第１バッファライトアドレスを指定し、
前記第２コンフィギュレーションデータは、前記第２バッファライトアドレスを指定する、請求項１３記載の方法。
【請求項１５】
プロセッサと、
前記プロセッサに接続されるメモリと、
を有するシステムであって、
前記プロセッサは、内部メモリを有し、
前記メモリの命令は、
第１ビデオコーデックフォーマットに関連する第１リードストリームの処理をサポートするよう前記内部メモリ内の共有バッファを構成し、
前記第１リードストリームに関連するメモリリクエストに応答して、前記共有バッファ内の第１バッファライトアドレスを決定し、
第２ビデオコーデックフォーマットに関連する第２リードストリームの処理をサポートするよう前記共有バッファを再構成し、
前記第２リードストリームに関連するメモリリクエストに応答して、前記共有バッファ内の第２バッファライトアドレスを決定する、
よう前記プロセッサを設定するシステム。
【請求項１６】
ＩＣに接続される外部メモリをさらに有し、
前記外部メモリは、第１ピクセルデータと第２ピクセルデータとを格納し、
前記第１ピクセルデータは前記第１リードストリームであり、前記第２ピクセルデータは前記第２リードストリームに関連する、請求項１５記載のシステム。
【請求項１７】
ロジックはさらに、
前記第１バッファライトアドレスに前記第１ピクセルデータを書き込み、
前記第２バッファライトアドレスに前記第２ピクセルデータを書き込む、
よう構成される、請求項１６記載のシステム。
【請求項１８】
前記ＩＣはさらに、前記第１リードストリームに関連する第１コンフィギュレーションデータを格納し、前記第２リードストリームに関連する第２コンフィギュレーションデータを格納するための１以上のレジスタを有する、請求項１５記載のシステム。
【請求項１９】
前記ロジックはさらに、
前記第１コンフィギュレーションデータに応答して、前記共有バッファを構成し、
前記第２コンフィギュレーションデータに応答して、前記共有バッファを再構成する、
よう構成される、請求項１８記載のシステム。
【請求項２０】
前記共有バッファは、プリフェッチバッファを有する、請求項１５記載のシステム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【公開番号】特開２０１３−５４５２（Ｐ２０１３−５４５２Ａ）
【公開日】平成２５年１月７日（２０１３．１．７）
【国際特許分類】
【出願番号】特願２０１２−１３７６３１（Ｐ２０１２−１３７６３１）
【出願日】平成２４年６月１９日（２０１２．６．１９）
【出願人】（５９３０９６７１２）インテル コーポレイション (931)
【Ｆターム（参考）】
【公開日】平成２５年１月７日（２０１３．１．７）
【国際特許分類】
【出願日】平成２４年６月１９日（２０１２．６．１９）
【出願人】（５９３０９６７１２）インテル コーポレイション (931)
【Ｆターム（参考）】
[ Back to top ]