JP2018098784A - 画像データ処理方法 - Google Patents

Abstract

【課題】 小さな解像度の動画が多く表示される遊技機に含まれるような画像処理装置であっても、復号処理能力が落ちることのない画像データ処理方法を提供する。【解決手段】 まず、復号処理設計を行う（ステップＳ１）。例えば、動画Ｘについては単独で処理し、垂直解像度の小さい動画Ｙ及び動画Ｚについては、合体して復号処理できる可能性がある、と設計する。そして、動画Ｘ、動画Ｙ、及び動画Ｚをそれぞれ符号化する（ステップＳ２）。次に、動画Ｘについては、その符号化データを単独で復号し、動画Ｘを復元して、画像処理装置の表示部に所定のタイミングで表示する。一方、動画Ｙ及び動画Ｚについては、それらの表示タイミングによっては、それらの符号化データを合体させて復号し、動画Ｘ及び動画Ｙを復元し、更にそれらを分離することにより、表示部にそれぞれのタイミングで表示する（ステップＳ３）。【選択図】 図１

Description

本発明は、画像データ処理方法に関し、特に、多くの小さな解像度の動画を、ハードウェアデコーダにより復号処理を行いつつ表示するような画像処理装置を使用する場合の画像データ処理方法に関する。

昨今の各種情報機器における動画再生処理においては、容量の観点から予め符号化して格納しておいた符号化動画情報を記憶媒体から読み出したり、又はネットワークを介してダウンロードし、それを符号化に対応した復号処理により復号して表示装置に供給することにより、液晶機器等に動画が再生される。

符号化処理には、時間的な余裕があることからソフトウェアで処理することも可能である。しかし、復号処理においては、高精細の動画であっても停滞なく再生されることを担保するためにハードウェア回路、特に専用の画像処理プロセッサ、を設けることも一般的になっている。

つまり、その上位の処理制御部が、処理の指令のみをその専用の画像処理プロセッサに対して与えておき、あとは当該画像処理プロセッサが自律的に画像処理を行うことにより、画像処理の効率化を図るという構成となっている。

図１８は従来の画像処理装置Ａの構成を示す図であり、１００は画像処理装置全体を制御する上位ＣＰＵ、２００は画像データＲＯＭ、３００は画像処理プロセッサ、４００は表示部である。画像データＲＯＭ２００には、例えば、Ｈ．２６４（ＭＰＥＧ４／ＡＶＣ）規格に基づき符号化された１つ以上の動画情報が格納されている。なお、画像処理装置Ａに符号化された動画情報の格納手段である画像データＲＯＭを備えているが、ネットワーク上のサーバ等から符号化された動画情報をダウンロードする構成でも良い。

上位ＣＰＵ１００は、一般的にＡＰＩ（Application Program Interface）と呼ばれる処理指令を画像処理プロセッサ３００に対して発行する。機器が動作する元となっているオペレーティングシステム（ＯＳ）が、例えば、Ｗｉｎｄｏｗｓであれば、ＤＸＶＡ２(DirectX Video Acceleration 2)というＡＰＩであり、Ｌｉｎｕｘ（登録商標）であれば、ＶＤＰＡＵ(Video Decode and Presentation API for Unix)というように、各機器が採用するソフトウェアプラットフォームにより固有のものが提供されている。

上位ＣＰＵ１００は、表示部４００に所定のタイミングで表示させたい、必要な符号化画像データを画像データＲＯＭ２００から読み出す。次に、上位ＣＰＵ１００は、表示の指令（表示タイミング、表示場所等）とともにその符号化画像データを画像処理プロセッサ３００に送る。当該指令と対応する符号化画像データを受け取った画像処理プロセッサ３００は、図示しない内部のハードウェアデコーダにより、当該符号化処理に対応した復号処理を施すことにより、元の画像を復元する。そして、画像処理プロセッサ３００が、その復号画像データを表示部４００に供給すれば、表示部４００の液晶画面等に動画が再生される。

次に画像データＲＯＭ２００内に格納されている動画情報の規格であるＨ．２６４について簡単に説明する。ＭＰＥＧ２やＭＰＥＧ４（ＡＶＣを除く）では、シンタックスの階層構造が定められ、ビットストリームの中で並べられる情報は階層構造に沿ったものである。これに対して、Ｈ．２６４では、パラメータセットとそれを参照するスライスの配置についてはＭＰＥＧ２等と比較して制約が少ない。

また、パラメータセットには、シーケンス全体の符号化に係わる情報を格納するＳＰＳ（Sequence Parameter Set：シーケンスパラメータセット）や、ピクチャ全体の符号化モードを示すＰＰＳ（Picture Parameter Set：ピクチャーパラメータセット）や、任意の情報を符号化できるＳＥＩ（Supplemental Enhancement Information）が含まれる。Ｈ．２６４では、フレームごとにＳＰＳやＰＰＳのパラメータセットを配置することができるので、一つのビットストリーム中で複数のシーケンスを取り扱うことができる。

図１９は、Ｈ．２６４規格に基づき符号化された画像の符号化データの一般的なビットストリームを示す図である。説明の便宜上、パラメータセットであるＳＰＳとＰＰＳの組は１組として表している。Ｈ．２６４規格では、ＶＣＬ（Video Coding Layer：動画像符号化処理層）と分離されたＮＡＬ（Network Abstraction Layer：ネットワーク抽象層）と称したレイヤーが規定されている。Ｈ．２６４規格では、ＶＣＬで生成された符号化データや、パラメータセットをＮＡＬユニットとして取り扱うことができるようになっており、符号化データはＶＣＬのＮＡＬユニット、ＳＰＳやＰＰＳは非ＶＣＬのＮＡＬユニットと称される。

ＶＣＬのＮＡＬユニットである各スライスにはヘッダー領域があり、そこには自スライスの先頭マクロブロック座標（first_mb_in_slice）の情報が少なくとも格納される。また、ＭＰＥＧ２などではピクチャが符号化単位になっているのに対し、Ｈ．２６４ではスライスが符号化単位になっているので、例えば処理を並列化させるために、ピクチャを複数のスライスに分割し、スライス毎に処理を行うことも可能になっている。

例えば特許文献１には、動きベクトルの符号化効率を改善するために、１フレームを複数スライスとして、すなわち１つの画像を複数に分割して複数のスライスとして符号化する技術が開示されている。また、特許文献２には、他の画像情報を参照せずに復号可能なＩピクチャを符号化したタイルを利用し、ストリーム補正手段により読み出したタイルのフレーム内での位置を補正することで、動画像の視聴領域を任意に設定し、かつインタラクティブに視聴領域を変更することができる動画像配信システムが開示されている。

しかしながら、特許文献１に代表されるような従来の技術においては、１つの動画の各画像を複数に分割するものであり、解像度の小さい画像を複数取り扱う場合の復号処理の効率低下を回避する目的で複数の動画のそれぞれを符号化し、それらを各スライスとして構成するものではない。また、特許文献２に記載の発明は、動画像の視聴領域を任意に変更する技術に関するものであり、この先行技術も解像度の小さい画像を複数取り扱う場合の復号処理の効率低下を回避するものではない。

特開２０１２−１９１５１３号公報 国際公開第２０１２／０６０４５９号

ところで、パチンコ機やパチスロ機のような遊技機における動画再生では、一本の動画を再生する一般的な動画再生とは顕著に異なる特徴がある。

図２０は、パチンコ機やパチスロ機のような遊技機における動画再生を説明するための図である。具体的には、同図（ａ）に示すように、パチンコ機やパチスロ機のような遊技機においては、１つの液晶画面等の任意の複数の領域に、大小さまざまな解像度の動画が表示される。

更に、同図（ｂ）に示すように、それらの各動画の再生開始時点及び再生時間は区々である。しかも、動画Ｄのように、表示タイミングをずらす目的等で、途中で一時停止するものがあったり、また、動画Ｅと動画Ｇの関係のように、遊技の進行に応じて、動画Ｅが最後まで再生されずに中断して、代わりに動画Ｇが再生し始める、というような態様もある。動画Ｅにおける矢印の網掛け部分は、当初再生を行う予定があったが、再生中断された部分を示している。

ここで、解像度の異なる画像に対するハードウェアデコーダによる復号処理について注目すると、その処理性能は、解像度に依存せずに一定になるというわけではなく、解像度に依存する。しかし、解像度に比例して復号の処理時間が決まるわけではない。例えば、解像度が１／２になったからといって、復号の処理時間が半分になるというものではない。

図２１は、汎用ハードウェアデコーダにおけるデコード性能を示す図であり、横軸が画像解像度、縦軸が処理性能（Gdps：Giga dot per sec）である。この図には、参考として、ソフトウェアにより復号処理を行う場合のデコード性能も併記している。ハードウェアデコーダ、ソフトウェアデコーダのいずれも、理論的にはデコード処理性能は解像度によって変わらないはずである。しかし、同図に示すように、ソフトウェア処理によれば、解像度が小さくなるにつれて比例的に処理性能が減衰し、また、ハードウェア処理によれば、解像度が小さくなるにつれて極端に処理性能が落ちてしまうことが分かる。

このように、ハードウェアデコーダによる復号処理において、解像度が小さくなるにつれて極端に処理性能が落ちてしまう理由は、ハードウェアデコーダが、画像の垂直方向において、所定の解像度単位で並列処理を行っているためと考えられる。

図２２は、ハードウェアデコーダにおける垂直方向の並列処理について説明するための図である。同図（ａ）は、ハードウェアデコーダが並列処理を行わない場合であり、同図（ｂ）はハードウェアデコーダが並列処理を行う場合を示している。

一般的に、復号処理はマクロブロック（ＭＢ）（例えば、１６×１６画素）単位で行われ、並列処理を行わない場合であれば、同図（ａ）に示すように、マクロブロックの水平一列に対応した１つのデコーダコアが、当該列の各マクロブロックを順に復号していく。ここで、Ｈ．２６４規格のように、イントラ予測が採用されているのであれば、既に復号処理された周りの所定のマクロブロックの情報を参照しつつ、一行ごとに復号が進められていく。

これに対して、ハードウェアデコーダが並列処理機能を有する場合は、同図（ｂ）に示すように、複数のマクロブロックに対応した複数のデコーダコアが備わっており、それら複数のデコーダコアが複数のマクロブロックに対して同時並列的に復号処理を進めていく。

この場合も、イントラ予測が採用されているのであれば、同図（ｂ）に示すように、典型的には波状に処理が進むこととなり、そのことから、かかる並列処理は、ウェイブフロント並列処理（wave front parallel processing）と呼ばれている。

図２２（ｂ）に示すような複数ハードウェアデコーダコアによる並列処理にあっては、垂直方向に十分大きな解像度を有する画像であれば並列処理の利点を十分に享受できるものの、垂直方向に解像度の小さい画像については、その利点を享受できない場合がある。

例えば、マクロブロックが１６×１６画素であり、マクロブロックに対して１対１で備わるハードウェアデコーダコアが８個備わっているとすると（なお、同図（ｂ）ではハードウェアデコーダコアが５個の場合を例示している）、一度に処理する垂直方向の画素数が１２８画素（１６画素×８＝１２８画素）ということとなり、理論的には、その１２８画素より小さい垂直方向の画素数を有する画像は、当該並列処理の利点を享受できないこととなる。

このように、小さな解像度の画像を復号処理する場合、どの程度、処理性能が低下するかは、並列処理時に用いられるデコーダコア数と復号される画像の解像度とに依存する。しかし、大きな解像度を有する画像の復号処理を高速に行うことを目的に多数のデコーダコアで並列処理を行う汎用のハードウェアデコーダを利用すると、小さな解像度の画像を復号処理する場合は、大きな解像度の画像を処理する場合と比較し、相対的に処理性能が落ちることとなる。

また、上記のように並列処理を前提とした汎用ハードウェアデコーダにおける処理性能低下に加え、解像度の小さい画像を処理する環境に起因した処理速度の低下も考えられる。すなわち、解像度の小さな画像も解像度の大きな画像も１ピクチャである点で変わらず、１ピクチャを復号する処理においては、画像データの符号化処理自体以外に、デコーダの初期化等の付随処理が必ず伴う。

したがって、遊技機等のように小さな解像度の画像を複数表示しようとすると、各画像を表示するために行われるデコーダの初期化等の付随処理が画像数に応じて増加し、その結果、見かけ上の復号処理性能が落ちてしまう。

以上のような理由から、パチンコ機及びパチスロ機に代表される遊技機のように、解像度の小さな動画を、特に並列的に、多く表示するような装置では、処理速度が極端に遅くなるという課題があった。

本発明は上述のような事情から為されたものであり、本発明の目的は、小さな解像度の動画が多く表示される遊技機に含まれるような画像処理装置であっても、復号処理能力が落ちることのない画像データ処理方法を提供することにある。

上記目的を達成するため、本発明の画像データ処理方法は、動画に係る符号化画像データを出力すると共に、その動画の再生に係る指令を発行する上位ＣＰＵと、ハードウェアデコーダを有し、入力される前記指令に基づき、前記動画に係る符号化画像データを復号する画像処理プロセッサと、前記画像処理プロセッサにより復号された画像データに基づいて前記動画が再生される表示部と、を備えた画像処理装置を使用した画像データ処理方法であって、指令に基づき表示部に複数の動画が再生される場合に、上位ＣＰＵは、各動画を符号化画像データであるスライスのレベルで合体させて、複数スライスの１ピクチャと見立てて一括して符号化画像データを構成して前記画像処理プロセッサに供給し、ハードウェアデコーダは、その一括化された符号化画像データを復号することを要旨とする。

本発明の画像データ処理方法によれば、解像度が小さい複数の動画を再生する際、上位ＣＰＵでは各動画をスライスレベルで合体させ、複数スライスの１ピクチャとした符号化画像データを生成し、ハードウェアデコーダでは複数の動画が合体された複数スライスの１ピクチャを復号するので、動画再生毎に必要なハードウェアデコーダの初期化等の処理を不要とし、復号処理速度を向上することができる。

（ａ）は本発明の画像データ処理方法における実施形態の概要を説明するためのフローチャートであり、（ｂ）はその説明図である。 各動画の符号化処理の手順を示すフローチャートである。 （ａ）（ｂ）は画像データの補填（パディング）処理を説明するための図である。 復号前の事前処理における、各動画間のピクチャタイプを合せる時間調整を説明するための図である。 符号化後の各動画のビットストリームを示す図である。 本発明の画像データ処理方法の第一の実施の形態において使用される画像処理装置の構成を示すブロック図である。 各動画を符号化データであるスライスのレベルで合体させて、複数スライスの１ピクチャと見立てて一括して復号することを説明するための図である。 （ａ）（ｂ）は事後処理部の処理を説明するための図である。 （ａ）（ｂ）は動画が中断して他の動画に切り替わる場合を説明するための図である。 動画が中断して他の動画に切り替わる場合を説明するための図である。 本発明の画像データ処理方法の第二の実施の形態において使用される画像処理装置の構成を示すブロック図である。 パチンコ機やパチスロ機のような遊技機における動画再生の例を示す図である。 （ａ）〜（ｆ）は具体例に基づき、事前処理部における処理を説明するための図である。 （ａ）〜（ｆ）は具体例に基づき、事前処理部における処理を説明するための図である。 （ａ）〜（ｆ）は具体例に基づき、事前処理部における処理を説明するための図である。 （ａ）、（ｂ）、（ａ）’、（ｂ）’は具体例に基づき、事前処理部における処理を説明するための図である。 （ａ）〜（ｃ）は具体例に基づき、事後処理部における処理を説明するための図である。 従来の画像処理装置の構成を示す図である。 Ｈ．２６４規格に基づき符号化された画像の符号化データの一般的なビットストリームを示す図である。 （ａ）（ｂ）はパチンコ機やパチスロ機のような遊技機における動画再生を説明するための図である。 汎用ハードウェアデコーダにおけるデコード性能を示す図である。 （ａ）（ｂ）はハードウェアデコーダにおける垂直方向並列処理を説明するための図である。

以下、図面を参照して、本発明の実施の形態について詳細に説明する。
図１を参照して、本発明の画像データ処理方法における第一の実施の形態の概要を説明する。

本発明においては、端的に言えば、垂直方向の解像度が小さい複数の動画の符号化画像データを合体させて、その合体したものを復号し、得られた画像データから、元の複数の動画を分離する、という処理を行うことにより、垂直方向の解像度が小さい動画が多くあっても、復号処理性能を落とさないようにするものである。

より具体的には、同図（ａ）において、まず、演出画像の設計者は、所定の動画の表示処理が行われる画像処理装置（例えば、パチンコ機に組み込まれているもの）において、どのような動画をどのタイミングで表示するか等の演出設計を行い、その際、画像処理装置に表示される各動画のうち、複数の動画をどのように合体して復号処理を行うべきかという、動画選別を含む復号処理設計を行う（ステップＳ１）。ここで、演出設計者とは、例えば、パチンコ等の遊技機のある演出において、同時に再生すべき動画を決める者である。

演出設計者は、同図（ｂ）に示すように、垂直解像度の大きい動画Ｘについては単独で処理し、垂直解像度の小さい動画Ｙ及び動画Ｚについては、合体して復号処理できる可能性がある、と設計する。そして、エンコーダは、動画Ｘ、動画Ｙ、及び動画Ｚをそれぞれ符号化する（ステップＳ２）。

次に、デコーダは、動画Ｘについては、その符号化データを単独で復号し、動画Ｘを復元して、画像処理装置の表示部に所定のタイミングで表示する。一方、デコーダは、動画Ｙ及び動画Ｚについては、それらの表示タイミングによっては、それらの符号化データを合体させて復号し、動画Ｘ及び動画Ｙを復元し、更にそれらを分離することにより、表示部にそれぞれのタイミングで表示する（ステップＳ３）。

なお、上記復号処理設計においては、設計者が演出に必要な動画を選択し、その表示タイミングを入力することで合体すべき動画を選別するソフトウェアを用いても良い。また、ソフトウェアに画像処理装置の同時再生処理能力を入力することで、同時再生処理能力を基準に合体可能な動画を選択できるよう制御しても良い。
以下、上述した概要をより具体的にした第１実施形態について、いくつかの所定条件も含めて詳細に説明する。
＜復号設計処理（ステップＳ１）＞
復号時に合体させるべき動画を選別する条件を解像度の観点で検討すると以下の通りである。
（１）合体させるべき各動画の垂直方向の解像度は、複数のデコーダコアによる並列処理の”画素数”以下である
（２）合体させるべき各動画の垂直方向の解像度の合計値が、複数のデコーダコアによる並列処理の”画素数”を越えること
（３）ただし、合体させるべき各動画の垂直方向の解像度の合計値が、デコーダの垂直方向の”最大解像度”を越えないこと

条件（１）は従来の技術で説明したように個々の動画が複数デコーダコアによる並列処理の恩恵を受けられないものであることを示している。また条件（２）は複数の動画を合体した結果、その垂直方向の解像度の合計が複数のデコーダコアの並列処理の画素数を超えることで、並列処理の恩恵を受けることを示している。更に条件（３）はデコーダで復号処理ができないほど複数の動画を合体しないことを示している。

すなわち、通常であれば複数デコーダコアによる並列処理の恩恵が受けられない動画を、デコーダで復号処理ができる範囲で複数合体させることで、複数デコーダコアによる並列処理の恩恵をうけることを示している。また、各動画を画像処理装置に表示するタイミングの観点に立つと、合体させるべき各動画は、表示タイミングが可及的に近いもの同士である。

上記の解像度の観点の条件を満たしていれば、どのようなタイミングで表示される動画同士でもよいのであるが、復号処理の時点と表示の時点が離れているほど、復号処理後の画像データを一旦蓄えておく画像データバッファでの滞留時間が長くなってしまう。

したがって、表示するタイミングの観点における、合体させるべき各動画の選別は、当該画像データバッファの容量に依存する。なお、遊技機を例に挙げて説明すると、一つのイベントで同時或いは同時期に再生される動画であって、上記条件（１）〜（３）を満たすものを合体させるデータとして復号設計処理を行うのが好適である。

＜符号化処理（ステップＳ２）＞
次に、図２を参照して、各動画の符号化処理について説明する。演出設計者は、符号化すべき動画を選択する（ステップＳ２１）。そして、演出設計者は、選択した動画が、前述の復号設計処理に基づき、他の動画と合体させるべき動画か否かを判断する（ステップＳ２２）。

図２０（ａ）に例示したような表示画面一杯に表示される動画Ａのような場合は、単独で復号処理を行うので、ステップＳ２２は否定判定となる。そして、演出設計者は、ステップＳ２３をスキップしてステップＳ２４に移行する。

一方、図２０（ａ）に例示したような動画Ｂ乃至動画Ｇ（垂直方向解像度が例えば１２８画素以下）の場合は、演出設計者は他のいずれかと合体させて復号処理するとしたものであるので、ステップＳ２２は肯定判定となり、ステップＳ２３に移行する。

ステップＳ２３においては、演出設計者は、画像データの補填処理（パディング）を行う。なお、上記ステップ２２、２３は演出作成用のソフトウェアを用いて処理しても良い。すなわち、設計者が演出に必要な動画を選択し、その表示タイミングを入力することができるソフトウェアで、選択された動画を上記条件に照らし合わせて合体すべき動画であるか否かを判定し、また合体する動画の解像度に応じて必要があればパディングしたデータを出力するようにしてもよい。
図３は、その補填処理を説明するための図である。

例えば、動画Ｂと動画Ｆとが組で合体でき、動画Ｃ、動画Ｄ、及び動画Ｅ（動画Ｇ）とが組で合体すべき場合を想定する。なお、動画Ｇは、図２０（ｂ）に示したように、動画Ｅが再生途中で中断した場合に、そこから再生されるべき動画である。そこで、少なくとも同じ組の各動画は、後述する復号処理の方式から、水平方向の解像度が揃っている必要がある。

したがって、演出設計者またはソフトウェアは、水平方向の解像度を揃えるために各動画の水平方向について画像データの補填処理を行う。このとき、演出設計者またはソフトウェアは、各動画の水平方向の解像度をデコーダの水平方向の最大処理解像度に一律に揃えてもよい。そうすれば、すべての組について、その同じ最大処理解像度に揃えることができるので、補填処理自体は簡易となる。

しかしながら、例えば、動画Ｃ、動画Ｄ、動画Ｅのように、水平方向に小さな解像度の動画ばかりを合体させる際に、各動画の水平方向の解像度を一律にデコーダの水平方向最大処理解像度に揃えようとすれば、補填データばかりが大きくなり、符号化効率が低下する。

そのため、各動画を合体させる場合には、例えば、水平方向１２０、２４０、４８０、９６０、１９２０画素というように、いくつかの揃える基準を設けるのが得策である。揃える基準は、合体させる各動画のうちの最大の水平方向解像度を有する動画の当該解像度によって決まるのであるから、それらの基準の数やその値の設定は、合体させる各動画の各水平方向解像度のばらつきに依存する。

このように水平方向解像度にいくつかの基準を設定した場合には、上述した条件（１）〜条件（３）に加え、各動画の水平方向解像度も合体させるべき動画の選定条件の一つとなる。

ステップＳ２４においては、エンコーダは、各動画の符号化処理を行う。エンコーダは、例えば、Ｈ．２６４規格に基づき、ソフトウェア処理により各動画の符号化処理を行う。このときの条件としては、少なくとも組み合わせられる各動画については、１ＧＯＰに含まれるフレームの数が同一（例えば、３０）であり、かつ、各動画のフレームのピクチャタイプの順序が同じになるような符号化処理を行うことである。

図４は動画Ｃ、動画Ｄ、動画Ｅについて、各動画間のピクチャタイプを合せて符号化処理を行うイメージ図であり、前述した補填処理を行い、少なくとも各動画の垂直方向解像度が揃い、かつピクチャタイプの順序が一致した状態で符号化される。同図に示す例では各動画のＧＯＰは第１番目のフレームがＩピクチャ、第２番目及び第３番目のフレームがＰピクチャ、第４番目のフレームがＢピクチャとして示している。また動画Ｃ、動画Ｄ、動画Ｅの各ＧＯＰ［１］に含まれるフレーム数は同一で、同様に各動画のＧＯＰ［２］に含まれるフレーム数は同一である。但し、ＧＯＰ［１］のフレーム数とＧＯＰ［２］のフレーム数とは同一である必要はない。

次に、図５を参照して、符号化後の各動画のビットストリームについて説明する。図５は、符号化後の動画のビットストリームを示す図である。動画のビットストリームは、従来と同様、１ピクチャが１スライスとして構成され、また、スライスのヘッダーにはマクロブロック開始座標の情報が格納される。

本発明に特徴的なものとしては、更に、“元画像のデータサイズ”（解像度）（例えば、図３に示す動画Ｃであれば、１１０×４８）を別途、ＳＥＩもしくはＭＰ４などＮＡＬを内包するコンテナに入れて符号化処理を行うことである。これは、後述するように、各動画の復号処理を行い表示する画像処理装置において、復号処理後に、元画像を抽出できるようにするためである。

ステップＳ２５においては、演出設計者またはソフトウェアは、未処理の動画が残っているか否かを判定し、残っていれば（肯定判定）、ステップＳ２１に戻り、以上の処理を繰り返し、全動画終了であれば、処理を終える。なお、上述の第１実施形態においては、垂直方向の解像度については、各動画についてそのまま、すなわち区々とした。しかし、合体して復号処理すべき各動画については、補填処理により垂直方向の解像度も揃えるということも考えられる。

垂直方向の解像度も揃えると、同一組として合体して復号処理すべき各動画の入れ替えが、簡単に行え、上述の符号化設計処理において処理が簡素になる。例えば、動画Ｃの垂直方向の解像度は６４画素なので、合体の対象となっている動画Ｄ、動画Ｅ、動画Ｇの垂直方向の解像度を４８画素から６４画素となるよう補填処理を行う。その後、演出設計者は動画Ｅに代えて動画Ｈ（補填処理したか否かに関わらず、垂直方向解像度が６４画素、図示せず）を表示させたいと考えた際に動画Ｅと動画Ｈとを簡単に入れ替えることが可能となる。

＜デコーダを備えた画像処理装置における画像データ処理（ステップＳ３）＞
図６は、本発明の第１実施形態において使用される画像処理装置Ｂの構成を示すブロック図である。

同図に示す画像処理装置Ｂは、上位ＣＰＵ（central processing unit）１と、画像データＲＯＭ２と、画像処理プロセッサ３と、表示部４とで構成されている。

上位ＣＰＵ１は事前処理部１１を有し、事前処理部１１は、各動画再生タイミング情報生成部１１１と動画間各ピクチャ合体部１１２とを有している。また、画像処理プロセッサ３は、事後処理部３１と、ハードウェアデコーダ３２と、ビデオメモリ３３とを有し、更に事後処理部３１は、命令解釈部３１１と、描画制御部３１２とを有している。描画制御部３１２には、各動画分離部３１２１と、元画像切出し部３１２２と、各動画表示タイミング制御部３１２３とが含まれている。

ここで、画像データＲＯＭ２には、上述の＜符号化処理（ステップＳ２）＞によって符号化された各動画のデータが格納されている。すなわち、動画の再生タイミングに応じて、他の動画と合体すべき動画の水平方向解像度が統一または水平方向解像度と垂直方向解像度の双方が統一された状態で、かつ、各動画のストリームのＳＥＩ等の非ＶＣＬ_ＮＡＬユニットに元の画像サイズのデータ情報が格納されたものである。
図６に示す画像処理装置における画像データ処理は以下の通りである。

まず、上位ＣＰＵ１は、画像処理装置Ｂでの演出設計に基づき、画像データＲＯＭ２から必要な動画に係る符号化画像データを読み出してくる。ここで読み出されるデータは前述の＜復号設計処理（ステップＳ１）＞で設計された合体可能な各動画に係る情報に基づいたものであり、読み出されたデータは事前処理部１１の動画間各ピクチャ合体部１１２で合体される。

図７は事前処理部１１の動画間各ピクチャ合体部１１２で行われるビットストリームの組み替えを示す図であり、動画間各ピクチャ合体部１１２では、読み出された１ピクチャ分の各動画のデータをスライスレベルで合体し、複数スライスの動画データにする。前述のように、各動画の符号化データのビットストリームにおいては、通常、同図の左側に示すように、１ピクチャ１スライスで構成されている。これに対して、合体の処理においては、各動画の符号化データのビットストリームからスライス部分を抽出し、それをシリーズに並べることにより合体させる。

なお、本実施の形態においては、ＳＰＳ（Sequence Parameter Set）、ＰＰＳ（Picture Parameter Set）及びＳＥＩ（Supplemental Enhancement Information）を一組としており、合体後のビットストリームのパラメータセット等は必要に応じてそれらを書き変えることとなる。例えば、ＳＰＳには、参照フレーム数やフレームの幅及び高さの情報が含まれているが、合体させた後の１ピクチャは元の個々のピクチャと高さ（垂直方向解像度）が異なるので、少なくとも高さ情報は修正される。なお、ＰＰＳには符号化方式や量子化係数等の情報が含まれているが、これらは符号化処理の際に各動画で共通としておけば、修正の必要はない。また、合体する動画の量子化係数が異なる場合には、スライスのヘッダーに含まれるSlice_QP_deltaを書き換えることで修正する。

合体前の各動画のビットストリームのＳＥＩ等のコンテナには元画像のデータサイズの情報が格納されており、動画間各ピクチャ合体部１１２は合体する動画のビットストリームの各ＳＥＩから元画像データの情報を抽出し、画像処理プロセッサ３に供給する。更に、合体する各スライスのヘッダーには開始マクロブロック座標の情報が格納されている。図７に示す例では動画Ｃのスライスのヘッダーに格納された開始マクロブロック座標は書換えの必要がない。しかし、動画Ｄ及び動画Ｅの各スライスのヘッダーに格納された開始マクロブロック座標は各動画Ｄ、動画Ｅの開始マクロブロックの位置に応じて動画間各ピクチャ合体部１１２にて書き換えられる。

上記のような方法で各動画のスライスを順次抽出し、合体させて新たなビットストリームとし、そのビットストリームを画像処理プロセッサ３のハードウェアデコーダ３２に供給する。なお、各動画を符号化する際、ＧＯＰのフレーム数および各フレームのピクチャタイプを揃えているので、動画間各ピクチャ合体部１１２で合体される各動画のスライスのピクチャタイプは一致している。

複数のスライスで構成された合体後の符号化画像データに基づく各動画は、表示させるべきタイミングが異なる場合がある。例えば、図２０（ｂ）に示したように動画Ｃ、動画Ｄ、動画Ｅは再生開始のタイミングがずれているので、上位ＣＰＵ１は、設計された演出情報に基づき各動画再生タイミング情報生成部１１１を用いて各動画の再生タイミング情報を生成し、その情報を画像処理プロセッサ３に供給する。

ハードウェアデコーダ３２は、上位ＣＰＵ１から供給された合体後の符号化画像データに対して復号処理を行い、復号結果をビデオメモリ３３に供給すると共に、図示しない復号完了通知を上位ＣＰＵ１に出力する。

ハードウェアデコーダ３２から復号の完了通知を受け取った上位ＣＰＵ１は、画像処理プロセッサ３の事後処理部３１に事後処理の指令を行い、その命令解釈部３１１は、その指令に含まれる、少なくとも、合体に係る各動画の元画像データ情報や各動画の再生タイミングに係る情報を描画制御部３１２に供給する。

描画制御部３１２に含まれる各動画分離部３１２１、元画像切出し部３１２２、及び各動画表示タイミング制御部３１２３は、各動画の元画像データ情報や各動画の再生タイミングに係る情報と、各スライスのヘッダーに格納された開始マクロブロック座標データに基づき、ビデオメモリ３３に格納された復号画像データに対して所定の事後処理を施したのち、その結果を表示部４に供給して各動画として表示させる。

図８乃至図１０を参照して、事前処理部１１及び事後処理部３１の処理内容について更に説明する。上位ＣＰＵ１では、画像処理装置に対して設計された動作処理（遊技機であれば、当該画像処理装置が組み込まれた遊技機における遊技の進行の設計動作）に基づき、動画の表示指令が発行される。例えば、図２０（ａ）、（ｂ）に示した例においては、上位ＣＰＵ１では、“動画Ａを所定のタイミングから再生せよ”であるとか、動画Ｅが再生されている途中で、“動画Ｅの再生を中断し、代わりに動画Ｇを再生し始めよ”というような指令が発行される。

上位ＣＰＵ１は、発行された指令に基づき、画像データＲＯＭ２から符号化画像データを取得し、例えば“動画Ａを所定のタイミングから再生せよ”という指令であれば、画像データＲＯＭ２から動画Ａに関する符号化画像データを取得する。そして、上位ＣＰＵ１は、動画Ａに関する符号化画像データを画像処理プロセッサ３のハードウェアデコーダ３２に供給し、ハードウェアデコーダ３２によりビデオメモリ３３に復号された画像データが格納された後、描画制御部３１２を用いて画像を作成し、所定のタイミングで表示部４に供給することで動画Ａの再生が表示部４で行われる。

また、上位ＣＰＵ１で複数の動画、例えば、動画Ｃ、Ｄ、Ｅ及びＧを再生する指令が発生すると、上位ＣＰＵ１は、必要な符号化画像データを画像データＲＯＭ２から読み出す。動画間各ピクチャ合体部１１２は、読み出した各動画のビットストリームに含まれるスライスのヘッダー領域に含まれる先頭マクロブロック座標の情報を動画の合体状況に応じて書き換えると共に、複数のスライスを合体させ、それを画像処理プロセッサ３のハードウェアデコーダ３２に供給する。なお、上位ＣＰＵ１は必要な符号化画像データを画像データＲＯＭ２から読み出す際、読み出した各動画のビットストリームのＳＥＩに格納された元画像のデータサイズに関する情報を抽出する。

スライスのヘッダー領域に含まれる先頭マクロブロックの座標情報書き換えとは、ヘッダー領域に当該スライスの先頭マクロブロックの番号に関する情報が格納されており、通常、画面左上から先頭マクロブロックが始まるので当初は「０」の情報が格納されている。しかし、合体される動画データは合体する際の各スライスの配置に応じて先頭マクロブロックの座標が変わるので、それを所望の値に変更するものである。

図８（ａ）に示すように動画Ｃ、動画Ｄ、動画Ｅをまとめて大きな１つの画像として合体させる場合、動画Ｃのスライスのヘッダー領域に含まれる先頭マクロブロックの座標情報は書き換える必要がないが、動画Ｄ、動画Ｅは先頭マクロブロックの座標が変わるので、合体の状態に応じて座標情報を書き換える必要がある。例えば、マクロブロックが１６×１６画素、動画Ｃ（垂直方向画素数は４８）の水平方向の解像度が補填データを含めて１２０の場合、動画Ｄの先頭マクロブロック座標は２４なので、当初「０」が格納された情報を「２４」に変更する。同様に動画Ｅの先頭マクロブロック座標は「５６」に変更される。このように、上位ＣＰＵ１は、ハードウェアデコーダ３２が正常に復号できる複数スライスからなるＨ．２６４ストリームを生成する。

ハードウェアデコーダ３２では、当該符号化画像データを受け取ると、１ピクチャが複数スライス（例では３スライス）で構成されたものと認識する。１ピクチャを複数スライスで構成することは、規格（Ｈ．２６４）で認められているので、ハードウェアデコーダ３２は入力した符号化画像データをそのまま復号処理を行うことができる。

しかしながら、ハードウェアデコーダ３２は、当該符号化画像データが複数の動画を合体させたものであるということまでは認識しない。これは、言い換えれば、ハードウェアデコーダ３２については、何ら手を加える必要がないということを意味している。

ハードウェアデコーダ３２で符号化画像データが復号され、ビデオメモリ３３に格納された後、上位ＣＰＵ１は、合体した復号画像データから個々の画像へ切出すための情報、各動画の元画像のデータサイズ及び動画表示タイミング等の情報を指令情報として生成し、画像処理プロセッサ３に出力し、この指令情報は画像処理プロセッサ３の命令解釈部３１１で解釈される。

例えば、命令解釈部３１１は、解釈した指令が、“動画Ｃを所定のタイミングから再生せよ”、“動画Ｄを所定のタイミングから再生せよ”、“動画Ｅを所定のタイミングから再生せよ”というものであった場合、ビデオメモリ３３内に格納されている復号画像データのうち、動画Ｃに係わる画像と、動画Ｄに係わる画像と、動画Ｅに係わる画像をそれぞれ切出すよう描画制御部３１２に指令を出力する。すなわち、上位ＣＰＵ１の事前処理部１１から、合体した復号画像データを個々の画像へ切出すための情報、各動画の元画像のデータサイズ情報及び動画表示タイミング等の情報を受け取っているので、これらの情報を描画制御部３１２に出力し、描画制御部３１２では各動画分離部３１２１、元画像切出し部３１２２、各動画表示タイミング制御部３１２３を制御して上位ＣＰＵ１の指令に応じた動画を表示装置４に表示する。

図８（ａ）は画像処理プロセッサ３における画像処理の一部、（ｂ）は各動画の再生タイミングを示している。ビデオメモリ３３には同図（ａ）の左側に記載したような復号データが格納されており、各動画を切出すための情報及び元画像データサイズ情報を用いて同図（ａ）右側に示したように補填データが削除された所望の領域の動画である、動画Ｃ、動画Ｄ、動画Ｅを得る。更に動画表示タイミング情報に基づいて同図（ｂ）に示したようなタイミングで各動画を表示装置４に表示する。したがって、ビデオメモリ３３は復号した画像データを所望のタイミングまで格納しておく機能、所謂、バッファのような機能も必要である。

なお、図８（ｂ）に示したように、各動画は、再生時間が区々であることから、復号処理は再生時間の短いものから先に終了していく。すなわち、動画Ｃ、Ｄ、Ｅを合体してハードウェアデコーダ３２に符号化画像データを供給した場合、各動画の再生時間が動画Ｄ＞動画Ｃ＞動画Ｅのため、動画Ｄの復号中に動画Ｃ及びＥの復号処理が終了する。このとき、動画の垂直解像度、表示タイミング、ビデオメモリ内のデータバッファとしての容量の観点で条件を満たせば、別の動画を復号が終了している動画Ｅや動画Ｃの領域に差し入れることもできる。その場合も、他の動画とＧＯＰ単位で整合をおこなう。

次に図８（ｂ）に示したように、動画Ｅが途中で動画Ｇに切り替わる場合のＧＯＰ及び各スライスの状態について、図９及び図１０を用いて説明する。図９（ａ）は動画Ｅの中段が無い場合の各動画のＧＯＰを示す図あり、各動画のＧＯＰ［１］〜ＧＯＰ［３］が画像データＲＯＭ２から読み出されることを示している。一方、図９（ｂ）は動画Ｅが中断して代わりに動画Ｇが再生される場合に画像データＲＯＭ２から読み出されるＧＯＰを示している。（ｂ）に示した例では動画ＥのＧＯＰ［２］の後に、動画ＥのＧＯＰ［３］の代わりに、動画ＧのＧＯＰ［１］が組み込まれている。

図１０は、動画ＥのＧＯＰ［２］と動画ＧのＧＯＰ［１］の境目を、各動画のピクチャの合体の観点から見たものである。なお、ＳＰＳ、ＰＰＳ及びＳＥＩのＮＡＬユニットについては記載を省略している。同図に示すように、切替え前の最終フレームにおいては、動画Ｃ、動画Ｄ、及び動画Ｅの各Ｐピクチャを合体させるようになっているが、切替え後の最初のフレームにおいては、動画Ｃ、動画Ｄ、及び動画Ｇの各Ｉピクチャを合体させるようになっている。すなわち、動画Ｇの再生を開始するためには、必ず動画ＧのＩピクチャが必要となるので、動画Ｃ、動画ＤのピクチャタイプがＩピクチャのタイミングで動画Ｅから動画Ｇへの切り替えを行う必要がある。

以上のように、本発明の画像データ処理方法における第１実施形態によれば、垂直方向に解像度が小さい各動画については、合体させて一括で復号処理をしているので、垂直方向に複数のデコーダコアにより並列処理を行っているような場合でも、その機能を享受することができる。
また、複数の動画を合体させて復号処理の数を減らした分だけ、デコーダの初期化等の付随処理が減ることとなり、処理時間は格段に短くなる。

また、各動画のピクチャ単位でそれらのスライスを複数のスライスとして纏めるというやり方で、各動画を合体させているので、ハードウェアデコーダ３２の構成や機能を何ら変更する必要はない。

次に、本発明に係る第二の実施の形態について説明する。上述した第一の実施の形態では、各動画を合体させるため、符号化の際に各動画のＧＯＰのピクチャタイプの順番を揃えると共に、フレーム数も一致させている。したがって、動画を切り替えるタイミングはピクチャタイプが全てＩピクチャである必要があり動画の切り替えタイミングに少し制約がある。また動画の再生タイミングが近いもの同士を合体させているが、動画表示タイミングを制御するための情報を上位ＣＰＵ１の事前処理部１１から画像処理プロセッサ３の事後処理部に供給すると共に画像データを格納しておくデータバッファが必要である。

そこで第二の実施の形態では第一の実施の形態を更に改良し、ＧＯＰのピクチャタイプの順番を揃えたり、表示タイミングを制御するための情報を画像処理プロセッサに供給しない方法を開示する。

まず、画像データ処理方法の全体の流れは、図１に示したように、演出画像の設計者が、所定の動画の表示処理が行われる画像処理装置（例えば、パチンコ機に組み込まれているもの）において、どのような動画をどのタイミングで表示するか等の演出設計を行い、その際、画像処理装置に表示される各動画のうち、複数の動画をどのように合体して復号処理を行うべきかという、動画選別を含む復号処理設計を行う（ステップＳ１）。ここで、演出設計者とは、例えば、パチンコ等の遊技機のある演出において、同時に再生すべき動画を決める者である。例えば、同図（ｂ）に示すように、動画Ｘについては単独で処理し、垂直解像度の小さい動画Ｙ及び動画Ｚについては、合体して復号処理できる可能性がある、と設計する。

そして、エンコーダは、動画Ｘ、動画Ｙ、及び動画Ｚをそれぞれ符号化する（ステップＳ２）。次に、デコーダは、動画Ｘについては、その符号化データを単独で復号し、動画Ｘを復元して、画像処理装置の表示部に所定のタイミングで表示する。一方、デコーダは、動画Ｙ及び動画Ｚについては、それらの表示タイミングによっては、それらの符号化データを、表示タイミングに応じて合体させて復号し、動画Ｘ及び動画Ｙを復元し、更にそれらを分離することにより、表示部に表示する（ステップＳ３）。

ここで、第一の実施の形態と異なるのは、ステップＳ２の符号化において合体する動画のＧＯＰのピクチャタイプの順番を揃える必要はなく、またフレーム数を一致させる必要がない点である。したがって、合体すべき動画は合体される他の動画のピクチャタイプやフレーム数を気にすることなく用意しておけば良い。また、符号化された各動画のデータを表示タイミングに応じて合体させ、復号する点も第一の実施の形態と異なっている。

＜復号設計処理（ステップＳ１）＞
復号時に合体させるべき動画を選別する条件は解像度の観点から以下の通りである。
（１）合体させるべき各動画の垂直方向の解像度は、複数のデコーダコアによる並列処理の”画素数”以下である
（２）’表示タイミングに応じて合体させるべき各動画の垂直方向の解像度の合計値が、相当時間において、複数のデコーダコアによる並列処理の”画素数”を越えること
（３）’ただし、表示タイミングに応じて合体させるべき各動画の垂直方向の解像度の合計値が、いずれの時刻においても、デコーダの垂直方向の”最大解像度”を越えないこと

条件（１）は従来の技術で説明したように個々の動画が複数デコーダコアによる並列処理の恩恵を受けられないものであることを示している。また条件（２）’は表示のタイミングで複数の動画を合体した結果、その垂直方向の解像度の合計が複数のデコーダコアの並列処理の画素数を超えることで、並列処理の恩恵を受けることを示している。更に条件（３）’はいずれの時刻においても、デコーダで復号処理ができないほど複数の動画を合体しないことを示している。

すなわち、通常であれば複数デコーダコアによる並列処理の恩恵が受けられない動画を、デコーダで復号処理ができる範囲で複数合体させることで、複数デコーダコアによる並列処理の恩恵をうけることを示している。

第一の実施の形態では、動画の再生タイミングが近いものを纏めてデコーダに供給していたので、上記条件（２）及び（３）は表示タイミングを考慮していなかったが、第二の実施の形態では表示タイミングに応じて動画を合体させるため、条件（２）’、（３）’は表示タイミングに関する条件が含まれている。

なお、本実施の形態においてはデコーダの垂直方向の“最大解像度”を越えないような所定の垂直方向解像度を規定しておき、上記条件（１）及び（２）’を満たす各動画を、規定した解像度範囲内で適宜組み合わせる、という概念を導入する。つまり、一般的なメモリ管理のように、表示タイミングに応じた動画の追加や削除は、垂直方向解像度に係る空き領域の管理で行うようにする。
また各動画を画像処理装置に表示するタイミングの観点からは、合体させるべき各動画は、表示タイミングが近いもの同士である。

この点に関し、第一の実施の形態においては、合体させるべき各動画の表示タイミングに拘わらず、各符号化画像データの時間的先頭を揃え、ＧＯＰも揃えて復号処理を行っていることから、各動画の表示タイミングを踏まえて復号処理後の画像データを一旦蓄えておくデータバッファが必要であった。したがって、データバッファの容量の制限を踏まえると、合体させるべき各動画は、表示タイミングが可及的に近いもの同士ということになる、としていた。

一方、本実施の形態おいては、後述するように、各動画の表示タイミングでそれらの符号化画像データを合体させているので、第一の実施の形態のように復号処理後の画像データを格納しておくデータバッファは必要ではない。ただし、ビデオメモリを有効に活用するためには、第一の実施の形態で説明したように、“一つのイベントで同時或いは同時期に再生される動画”を対象として合体させるのが好適である。

このような復号設計処理は、演出設計者が行っても良いし、設計者が演出に必要な動画を選択し、その表示タイミングを入力することで合体すべき動画を選別するソフトウェアを用いても良い。また、ソフトウェアに画像処理装置の同時再生処理能力を入力することで、同時再生処理能力を基準に合体すべき動画を選別するよう制御しても良いし、後述する合体画像枠を設定し、その枠を利用して動画選別を制御しても良い。

＜符号化処理（ステップＳ２）＞
次に、各動画の符号化処理について説明する。符号化処理の手順については、前述した第一の実施の形態と同様に図２に示した通りである。また、各動画の水平解像度を一致させるための補填処理（図３）や符号化後の各動画のビットストリーム（図５）も同じである。
演出設計者は、符号化すべき動画を選択する（ステップＳ２１）。

そして、演出設計者またはソフトウェアは、選択した動画が、前述の復号設計処理に基づき、他の動画と合体させるべき動画か否かを判断する（ステップＳ２２）。

単独で復号処理を行う動画であればステップＳ２２は否定判定となる。そして、演出設計者またはソフトウェアは、ステップＳ２３をスキップしてステップＳ２４に移行する。
一方、他のいずれかと合体させて復号処理するものであれば、ステップＳ２２は肯定判定となり、ステップＳ２３に移行する。

ステップＳ２３の補填処理については第一の実施の形態と同様であるため、その説明を省略する。なお、第二の実施の形態では、デコーダの垂直方向の“最大解像度”と補填処理を前提とした水平方向解像度とで規定される画像の大きさを、説明の便宜上“合体画像枠”と称する。

次に、ステップＳ２４においてエンコーダは、各動画の符号化処理を行う。エンコーダは、例えば、Ｈ．２６４規格に基づきソフトウェア処理により行う。このときの条件として、第一の実施の形態においては、少なくとも同じ組である各動画については、１ＧＯＰに含まれるフレームの数が同一（例えば、３０）で、かつ、ピクチャタイプの順番が同じになるような符号化処理を行う、を規定していた。

これに対して、第二の実施の形態においては、少なくともステップＳ２２において同じ組とした各動画については、復号タイミングと復号出力タイミングとがずれないような符号化処理を行う。復号タイミングと復号出力タイミングとがずれないようにするためには、各動画における参照バッファの管理を同一とすれば良く、例えば、Ｈ．２６４規格ではＰＯＣ Ｔｙｐｅ＝２、かつ時間的に未来に当たる画像を参照画として用いず、ＳＰＳ（Sequence Parameter Set）、ＰＰＳ（Picture Parameter Set）の解像度に関する項目以外については共通する符号化がこれに当たる。合体すべき各動画間での、参照バッファの管理の同一化の更なる具体例としては、以下のようなものがある。
（ａ）Ｂピクチャは使用しないで参照バッファを１つとする
（ｂ）Ｂピクチャを採用して２つの参照バッファ（例えば、バッファ“０”とバッファ“１”）を採用するものの、未来方向の画像は参照せず、かつ時間的に古い画像の方を常にバッファ“０”に入れる

このような参照バッファの管理に関する条件を一致させて各動画を符号化すると共に、後述のように補間スライスという概念を導入すれば、第一の実施の形態の図４で説明したようにＧＯＰ構成を同一にしてピクチャタイプを揃えなくても、合体して復号処理が行えるようになる。

符号化後の各動画のビットストリーム（図５参照）は１ピクチャが１スライスとして構成され、また、スライスのヘッダーにはマクロブロック開始座標の情報が格納される。更に、本発明では第一の実施の形態及び第二の実施の形態共に、“元画像のデータサイズ”（例えば、図３に示す動画Ｃであれば、１１０×４８：解像度）を別途、ＳＥＩもしくはＭＰ４などＮＡＬを内包するコンテナに入れる処理を行っている。

ステップＳ２５においては、演出設計者またはソフトウェアは、未処理の動画が残っているか否かを判定し、残っていれば（肯定判定）、ステップＳ２１に戻り、以上の処理を繰り返し、全動画終了であれば、処理を終える。

図３に示した、各動画の水平解像度を一致させるための補填処理では合体する各動画の垂直方向の解像度を統一していないが、第一の実施の形態で説明したように、各動画の垂直方向の解像度も幾つかのタイプに揃えて合体画像枠を構成しても良い。この場合、同一組として合体して復号処理すべき各動画の入れ替えが簡単に行えるというメリットがある。

＜デコーダを備えた画像処理装置の実動による画像データ処理（ステップＳ３）＞
図１１は、本発明の画像データ処理方法の第二の実施の形態において使用される画像処理装置Ｃの構成を示すブロック図である。同図に示す画像処理装置Ｃは、上位ＣＰＵ１と、画像データＲＯＭ２と、画像処理プロセッサ３と、表示部４とで構成されている。

上位ＣＰＵ１は、事前処理部１５を有し、事前処理部１５は、動画間各ピクチャ合体部１６と、各動画合体情報生成部１７とを有している。また動画間各ピクチャ合体部１６は、補完スライス生成部１８を有している。

また、画像処理プロセッサ３は、ハードウェアデコーダ３２と、ビデオメモリ３３と、事後処理部３５とを有し、更に事後処理部３５は、命令解釈部３６と、描画制御部３７とを有している。描画制御部３７には、各動画分離部３１２１と、元画像切出し部３１２２とが含まれている。

ここで、画像データＲＯＭ２には、上述の処理によって符号化された各動画のデータが格納されている。すなわち、復号のタイミングと復号画出力タイミングとがずれないよう、参照バッファの管理が同一の動画データが画像データＲＯＭ２に格納されている。
図１１に示す画像処理装置Ｃにおける画像データ処理の概要は以下の通りである。なお、事前処理部１５及び事後処理部３５の詳細説明については、後述する。

上位ＣＰＵ１は、画像処理装置での設計動作に基づき、画像データＲＯＭ２から必要な動画に係る符号化画像データを読み出してくる。上位ＣＰＵ１は、＜復号設計処理（ステップＳ１）＞で設計された合体可能な各動画に係る情報に基づき、画像データＲＯＭ２から合体可能な複数の動画に係る符号化画像データを読み出す。その後、動画間各ピクチャ合体部１６が、各動画を表示させるべきタイミングに応じて、各動画ピクチャを各スライスとして合体すると共に、合体させるスライスのヘッダー領域に含まれる先頭マクロブロック座標の情報を書き換える。また、合体した各動画について、表示しない時間帯や一時停止の時間帯については、補完スライス生成部１８が補完スライスを生成して充当する。そして、動画間各ピクチャ合体部１６は、複数のスライスで構成された合体後の符号化画像データを画像処理プロセッサ３のハードウェアデコーダ３２に供給する。

ハードウェアデコーダ３２は供給された符号化画像データを復号するが、供給された符号化画像データが事前処理部１５で複数の動画を合体したものであれば、供給された動画のビットストリームの各スライスのヘッダーには書き換えられた合体後の先頭マクロブロック座標の情報が含まれているため、ハードウェアデコーダ３２は複数スライスの画像として処理する。

なお、第二の実施の形態においては、動画間各ピクチャ合体部１６が合体させるべき各動画を表示させるべきタイミングで合体させるのであるから、第一の実施の形態のように、各動画に係る再生タイミング情報を生成して、画像処理プロセッサ３側に知らせる必要はない。

しかしながら、合体画像枠の垂直方向のうち、表示すべき画像がどの領域を占めており、どの領域が使用されていないかの情報や元画像のデータサイズを、逐次、画像プロセッサ３側に知らせる必要がある。上位ＣＰＵ１は各動画のビットストリームを画像データＲＯＭ２から読み出す際に各ストリームのＳＥＩ等のＮＡＬから元画像のデータサイズに関する情報を抽出し、更に各画像を合体させた際の画像合体枠の使用領域に関する情報（以下、元画像・合体画像情報）を各動画合体情報生成部１７で生成し、元画像データサイズ情報と共に指令として画像処理プロセッサ３に供給する。

すなわち、上位ＣＰＵ１は、符号化画像データを画像処理プロセッサ３のハードウェアデコーダ３２に供給すると同時に、上述の各動画合体情報生成部１７で生成した元画像・合体画像情報を含む復号の指令を画像処理プロセッサ３の事後処理部３５に対して発行する。

画像処理プロセッサ３においては、ハードウェアデコーダ３２が、上位ＣＰＵ１から供給された符号化画像データに対して復号処理を行い、復号結果をビデオメモリ３３に供給する。このとき、ハードウェアデコーダ３２により供給される復号後の画像データは、常に各動画が表示に必要な最新のフレームで構成されている。その理由は、上位ＣＰＵ１において、表示タイミングに応じて合体させているからである。従って、第二の実施の形態においては、第一の実施の形態において必要としていた特段のバッファは必要ではない。

一方、上位ＣＰＵ１からの指令を受け取った事後処理部３５の命令解釈部３６は当該指令を解釈する。ここで、事後処理部３５は、その指令に含まれる、元画像・合体画像情報に含まれる水平方向解像度に係る情報や、合体に係る各動画が垂直方向のうちのどの領域を占めており、どの領域が未使用であるかを表す情報、及び元画像のデータサイズを描画制御部３７に供給する。

描画制御部３７に含まれる各動画分離部３１２１は、合体に係る各動画が垂直方向のうちのどの領域を占めており、どの領域が未使用であるかを表す情報に基づき、各動画を分離する。また元画像切出し部３１２２は、元画像・合体画像情報に含まれる水平方向解像度や垂直方向解像度に係る情報に基づき、元画像を切り出して復元する。そして、元画像切出し部３１２２は、その結果を表示部４に供給して各動画として表示させる。
図１２〜図１７を参照しつつ、事前処理部１１及び事後処理部３１の詳細な処理内容について説明する。

上位ＣＰＵ１では、画像処理装置に対して設計された動作処理（遊技機であれば、当該画像処理装置が組み込まれた遊技機における遊技の進行の設計動作）に基づき、動画の表示指令が発行される。

例えば、図１２に示した例において、上位ＣＰＵ１では、“動画Ａを再生せよ”であるとか、“動画Ｂ及び動画Ｆの各符号化画像データを合体させて送るので、それらを分離して順次再生せよ”であるとか、“動画Ｃ、Ｄ、Ｅ、及びＧの各符号化画像データを、一時停止や中断の情報も含めて合体させて送るので、それらを分離して順次再生せよ”というような指令が発行される。

上位ＣＰＵ１は、動作処理設計に基づき、画像データＲＯＭ２から符号化画像データを取得し、例えば“動画Ａを再生せよ”という指令であれば、画像データＲＯＭ２から動画Ａに関する符号化画像データを取得し、画像処理プロセッサ３のハードウェアデコーダ３２に供給する。次に、ハードウェアデコーダ３２は、符号化画像データを復号し、復号された画像データをビデオメモリ３３に格納した後に、描画制御部３７を用いて画像を作成し、表示部４に供給することで動画Ａの再生が表示部４で行われる。

また、動作処理が、複数の動画、例えば、動画Ｃ、Ｄ、Ｅ及びＧを再生する、である場合に、上位ＣＰＵ１は、画像データＲＯＭ２から必要な動画の符号化画像データを読み出すと共に、各動画のビットストリームに含まれる元画像のデータサイズ情報を抽出する。

そして、動画間各ピクチャ合体部１６は、まず、前述の合体画像枠を決定した後、合体させる動画のビットストリームの一部を構成するスライスを抽出し、そのヘッダー領域に含まれる先頭マクロブロック座標の情報を必要に応じて書き換え、さらに、表示タイミングに応じて、複数のスライスを合体させ、合体後の圧縮データを生成し、それを画像処理プロセッサ３のハードウェアデコーダ３２に供給する。

各符号化画像データのスライス毎の合体については、前述した第一の実施の形態（図７及びその説明）と同様である。なお、第一の実施の形態においては、ＧＯＰ構成を同一にしてピクチャタイプを揃える必要があったが、第二の実施の形態では、既述の条件のもとでは、ピクチャタイプが異なっていても、合体して復号処理が行え、例えば、ある動画の途中のＰピクチャに対して、他の動画の先頭のＩピクチャを合体させることもできる。

事前処理部１５の動画間各ピクチャ合体部１６は、各動画の符号化画像データを上述のようにスライスレベルで編成することにより、各動画を合体させつつ、当該符号化画像データをハードウェアデコーダ３２に供給する。ここで、ハードウェアデコーダ３２では、当該符号化画像データを受け取ると、１ピクチャが複数スライス（例では３スライス）で構成されたものとは認識する。しかし、これは規格（Ｈ．２６４）で定められた処理の範囲内であり、ハードウェアデコーダ３２でそのまま復号処理を行うことができる。ただし、ハードウェアデコーダ３２は当該符号化画像データが複数の動画を合体させたものであるということまでは認識しない。

これは、言い換えれば、ハードウェアデコーダ３２については、何ら手を加える必要がないということを意味している。つまり、第二の実施の形態においても、ハードウェアデコーダ３２について何ら手を加えることなく、複数の動画を合体、分離できるよう事前処理および事後処理を行っている。

第二の実施の形態においては、合体画像枠を用いて合成すべき動画の挿入や差し替え等を行い、かつ合体される動画は表示のタイミングに応じて選択される。したがって、合体画像枠内には動画の表示タイミングによっては未使用領域が生じ、その未使用領域を制御することも必要である。

この未使用領域や動画を一時停止するために用いるのが補完スライスであり、補完スライス生成部１８が動画の表示タイミングに応じて必要な補完スライスを生成し、各動画合体情報生成部に供給している。なお、補完スライス生成部１８で生成される補完スライスは、前のフレームをそのまま表示するものであり、直前のフレームを変更なく取得する時間方向予測で構成されるスライスである。

例えば、Ｈ．２６４規格においては、補完スライスは、全てのマクロブロック（ＭＢ）がスキップ（Ｓｋｉｐ）で構成されたＰスライスとなる。ただし、合体処理の開始フレームについては、不足領域の補完スライスは、面内符号化（イントラ符号化）で構成される。例えばＨ．２６４規格では、ＩＤＲスライスとなる。また、合体処理の開始フレーム以外の不足領域の補完スライスは、面内符号化で構成されるものでもよい。例えばＨ．２６４規格では、スライスタイプがＩピクチャ（以下、Ｉスライス）がこれに当たる。

図１２に示した各動画の再生タイミングの例を元に、図１３〜図１６を用いて動画間各ピクチャ合体部１６の具体的処理について説明する。なお、図１３〜図１６に関しては、ＳＰＳ及びＰＰＳを省略している。

まず、図１３を参照して、動画Ｂ及び動画Ｆの合体処理について説明する。なお、動画間各ピクチャ合体部１６では、動画Ｂと動画Ｆとを合体させて単一のビットストリームにして復号処理するという処理設計を前提としている。

この場合、動画間各ピクチャ合体部１６による合体後のビットストリームは、少なくとも２つ以上のスライスで構成される。具体的に、図１２に示す時刻ｔ８においては、合体後のビットストリームは、図１３（ａ）に示すように、動画ＦのＩライスと補完スライス（ＩＤＲピクチャのスライス）とで構成される。すなわち、動画Ｂと動画Ｆとを合体して復号を行うが、時刻ｔ８において表示される動画は動画Ｆのみであるため、動画ＦのＩスライスと補完スライスとを用いて合体処理が行われる。ここで、本実施の形態においては、一つの補完スライスをビットストリームに挿入しているが、複数の補完スライスで構成しても良い。このように構成したビットストリームを復号した場合、時刻ｔ８からｔ９までの合体画像枠内のピクチャ構成は、図１３（ｂ）に示すようになる。

次に、図１２に示す時刻ｔ９においては、合体後のビットストリームは、図１３（ｃ）に示すように、動画Ｆの任意ピクチャに係るスライスと動画ＢのＩスライスとで構成される。当該任意のピクチャとは、Ｉスライスである必要はなく、スライスタイプがＰピクチャ（以下、Ｐスライス）でもよいということである。また、時刻ｔ９からｔ１０までの合体画像枠内のピクチャ構成は、図１３（ｄ）に示すようになる。

次に、図１２に示す時刻ｔ１０においては、動画Ｆの合体が解除されるので、動画Ｆのスライスに代えて補間スライスが挿入され、合体後のビットストリームは、図１３（ｅ）に示すように、補完スライスと動画Ｂのスライスとで構成される。この実施の形態では、一つの補完スライスを用いた例を挙げているが、複数の補完スライスで構成しても良い。また、時刻ｔ１０以降の合体画像枠内のピクチャ構成は、図１３（ｆ）に示すようになる。

次に、動画間各ピクチャ合体部１１２が合体すべき動画Ｃ、動画Ｄ、動画Ｅ、及び動画Ｇについて説明する。この場合、動画間各ピクチャ合体部１１２による合体後のビットストリームは、少なくとも２つ以上のスライスで構成される。

具体的に、図１２の時刻ｔ１においては、合体対象の動画Ｃ、Ｄ、Ｅ、Ｇのうち、表示される動画は動画Ｃのみなので、合体後のビットストリームは、図１４（ａ）に示すように、動画ＣのＩスライスと２つの補完スライスとで構成される。すなわち、設定された合体画像枠を埋めるよう補完スライスが挿入される。ここでは、同じ時刻に動画Ｃ、動画Ｄ、動画Ｅが合体されることが分かっているので、時刻ｔ１において表示されない動画Ｄ、動画Ｅの部分は補間スライスが用いられている。なお、この実施の形態においても、動画毎にスライスを割り当てている例を挙げて説明しているが、動画Ｄ、動画Ｅの空き領域を設定するために１つの補完スライスを用いても良いし、また３以上の補完スライスを挿入しても良い。すなわち、ピクチャ構成で連続している領域には、１つの補完スライスを割り当てることができるので、２つの補完スライスを１つの補完スライスとしても良いし、２つの補完スライスをさらに分割して構成しても良い。このようなビットストリームを復号した時刻ｔ１からｔ２までの合体画像枠内のピクチャ構成は、図１４（ｂ）に示すようになる。

次に、図１２に示す時刻ｔ２においては、動画Ｃの再生に加え、動画Ｄの再生が開始されるので、合体後のビットストリームは、図１４（ｃ）に示すように、動画Ｃの任意ピクチャに係るスライスと動画ＤのＩスライスと１つ以上の補完スライスで構成される。また、時刻ｔ２からｔ３までの合体画像枠内のピクチャ構成は、図１４（ｄ）に示すようになる。この場合も、上記と同様に、補完スライスを複数の補完スライスで構成しても良い。

次に、図１２に示す時刻ｔ３においては、動画Ｃ、動画Ｄの再生に加え、動画Ｅの再生が開始されるので、合体後のビットストリームは、図１４（ｅ）に示すように、動画Ｃの任意ピクチャに係るスライスと動画Ｄの任意ピクチャに係るスライスと動画ＥのＩスライスで構成される。また、時刻ｔ３からｔ４までの合体画像枠内のピクチャ構成は、図１４（ｆ）に示すようになる。なお、この例では、合体画像枠の垂直方向解像度を、合体させるべきすべての動画の垂直方向解像度の合計値に一致させているが、合体画像枠の垂直方向解像度を予め大きく規定していてもよい。

次に、図１２の時刻ｔ４においては、動画Ｃ、動画Ｅの再生が行われている際中に、動画Ｄの再生が一時停止されるので、合体後のビットストリームは、図１５（ａ）に示すように、動画Ｃのスライスと動画Ｄの一時停止補完スライスと動画Ｅのスライスで構成される。ここで、補完スライス生成部１８が生成した一時停止補完スライスとは、対象の動画と同じ解像度となる補完スライスである。したがって、時刻ｔ４からｔ５までの合体画像枠内のピクチャ構成は、図１５（ｂ）に示すようになる。ここで、時刻ｔ４からｔ５における動画Ｄについては、時刻ｔ４での画像のリピートとなる。

次に、図１２に示す時刻ｔ５においては、動画Ｄの一時停止が解除され、再び動画Ｃ、動画Ｄ、動画Ｅの再生が行われるので、合体後のビットストリームは、図１５（ｃ）に示すように、動画Ｃのスライスと動画Ｄの再生再開画像のスライスと動画Ｅのスライスで構成される。また、時刻ｔ５からｔ６までの合体画像枠内のピクチャ構成は、図１５（ｄ）に示すようになる。

次に、図１２に示す時刻ｔ６においては、動画Ｃの再生が終了するので、合体後のビットストリームは、同図（ｅ）に示すように、補完スライスと動画Ｄのスライスと動画Ｅのスライスで構成される。また、時刻ｔ６からｔ７までの合体画像枠内のピクチャ構成は、同図（ｆ）に示すようになる。この場合も、上記と同様、複数の補完スライスとしても良い。

次に、図１２に示す時刻ｔ７においては、動画Ｅの再生が中断されて、代わりに動画Ｇが再生されるタイミングである。したがって、動画Ｅのスライスに代えて動画ＧのＩスライスが挿入され、合体後のビットストリームは、図１６（ａ）に示すように、補完スライスと動画Ｄの任意のピクチャに係るスライスと動画ＧのＩスライスで構成される。また、時刻ｔ７直後の合体画像枠内のピクチャ構成は、図１６（ｂ）に示すようになる。なお、動画Ｅと動画Ｇの垂直方向解像度は同一であるので、図１６（ｂ）に示した時刻ｔ７直後の合体画像枠内のピクチャ構成において、動画Ｅの領域に動画Ｇをそのまま代わりに当て嵌めている。

しかし、時刻ｔ７の時点で、垂直方向解像度がより大きい動画Ｃが割り当てられていた領域が空き領域として開放されているので、図１６（ｂ）’で示すように動画Ｃが割り当てられていた領域に動画Ｇを割り当てることもできる。このように動画Ｃが割り当てられていた領域に動画Ｇを割り当てる場合には、合体画像枠内における垂直方向の空き領域を調整するため動画Ｇと動画Ｄの間の空き領域に相当する補完スライスを挿入する。したがって、そのときの合体後のビットストリームは、図１６（ａ）’に示すように、動画ＧのＩスライスと、補完スライスと、動画Ｄの任意のピクチャに係るスライスと、補完スライスで構成される。

次に、事後処理部３５における処理の具体例について図１７を用いて説明する。上述のように、表示タイミングに応じて合体された符号化画像データは、逐次、ハードウェアデコーダ３２において復号処理が行われ、復号後の画像データはビデオメモリ３３に供給される。

一方、事後処理部３５においては、命令解釈部３６から描画制御部３７に、合体画像枠の水平方向解像度に係る情報や、合体に係る各動画が合体画像枠の垂直方向のうちのどの領域を占めており、どの領域が未使用であるかを表す情報や、各画像の元画像のデータサイズに関する情報が逐次送られる。

描画制御部３７に含まれる各動画分離部３１２１は、合体に係る各動画が垂直方向のうちのどの領域を占めており、どの領域が未使用であるかを表す情報に基づき、復号後の画像データを分離する。例えば、各動画分離部３１２１は、図１７（ａ）に示す時刻ｔ３からｔ４までの任意の時点においては、同図中央に示すように、動画Ｃ、動画Ｄ、及び動画Ｅに分離する。また、各動画分離部３１２１は、図１７（ｂ）に示す時刻ｔ４からｔ５までの任意の時点においては、同図中央に示すように、動画Ｃ、動画Ｄのｔ４時点の画像のリピート、及び動画Ｅに分離する。更に、各動画分離部３１２１は、図１７（ｃ）に示す時刻ｔ６からｔ７までの任意の時点においては、同図中央に示すように、動画Ｄ及び動画Ｅに分離する。

次に、描画制御部３１２に含まれる元画像切出し部３１２２は、合体画像枠の水平方向解像度に係る情報や、上位ＣＰＵ１から供給された各動画の元画像のデータサイズに基づいて、フレームごとに＜符号化処理（ステップＳ２）＞のときに補填された補填データを削除し、図１７（ａ）、（ｂ）、（ｃ）のそれぞれ右側に記載したように元の動画が再構築される。なお、図１７においては、３つの時間区分の例しか挙げていないが、他の時間区分も当業者であれば容易に理解できるであろう。そして、このようにフレームごとに元画像が再現された各動画のデータは、逐次、表示部４にて再生されていく。

以上のように、本発明の画像データ処理方法における第二の実施の形態によれば、垂直方向に解像度が小さい各動画については、合体させて一括で復号処理をしているので、垂直方向に複数のデコーダコアにより並列処理を行っているような場合でも、その機能を享受することができる。
また、複数の動画を合体させ、復号するストリーム数を減らした分だけ、デコーダの初期化等の付随処理が減ることとなり、処理時間は格段に短くなる。

また、第二の実施の形態によれば、各動画を構成するスライスを抽出し、複数のスライスとして纏めて一つの符号化画像データを生成し、各動画を合体させているので、ハードウェアデコーダ３２の構成や機能を何ら変更する必要はない。更に、復号タイミングと復号画出力タイミングがずれないようにするため、合体に係る各動画において、参照バッファの管理が同一となるよう符号化しているので、スライスレベルで合体させる際のピクチャタイプを合せる必要がなくなり、各動画の表示タイミングに応じた合体が可能になる。

＜本実施形態の態様例の作用、効果のまとめ＞
＜第一態様＞
本発明の画像データ処理方法は、動画に係る符号化画像データを出力すると共に、その動画の再生に係る指令を発行する上位ＣＰＵと、ハードウェアデコーダを有し、入力される前記指令に基づき、前記動画に係る符号化画像データを復号する画像処理プロセッサと、前記画像処理プロセッサにより復号された画像データに基づいて前記動画が再生される表示部と、を備えた画像処理装置を使用した画像データ処理方法であって、指令に基づき表示部に複数の動画が再生される場合に、上位ＣＰＵは、各動画を、各ピクチャ符号化画像データであるスライスのレベルで合体させて、複数スライスの１ピクチャと見立てて一括して符号化画像データを構成して前記画像処理プロセッサに供給し、ハードウェアデコーダは、その一括化された符号化画像データを復号する。

これにより、解像度が小さい複数の動画を再生する際、上位ＣＰＵでは各動画をスライスレベルで合体させ、複数スライスの１ピクチャとした符号化画像データを生成し、ハードウェアデコーダでは複数の動画が合体された複数スライスの１ピクチャを復号するので、動画再生毎に必要なハードウェアデコーダの初期化等の処理を不要とし、復号処理速度を向上することができる。

＜第二態様＞
本発明の画像データ処理方法は、ハードウェアデコーダが一括して復号した画像データから各動画を分離するよう上位ＣＰＵが画像処理プロセッサに要求し、分離された各動画が前記表示部に再生される。したがって、同じ復号処理で複数の動画を再生することができ、動画再生毎に必要なハードウェアデコーダの初期化等の処理を不要とし、復号処理速度を向上することができる。

＜第三態様＞
また、上位ＣＰＵが合体させる動画の元画像サイズ情報を各動画データから抽出し、該元画像サイズ情報を画像処理プロセッサに供給し、画像処理プロセッサは一括して復号した画像データから元画像サイズ情報に基づいて各動画を分離する。これにより、垂直方向に解像度が小さい動画を多く再生する場合でも、動画再生毎に必要なハードウェアデコーダの初期化等の処理を不要とし、並列処理機能を有するハードウェアデコーダを用いた場合には並列処理機能の利点を享受できる。

＜第四態様＞
また、上位ＣＰＵが読み出す合体に係る各動画については、参照バッファの管理が同一となるよう符号化した符号化画像データを使用する。これにより、合体に係る各動画の各スライスのピクチャタイプを一致させる必要はないので、動画の再生タイミングに関する制限が少なくなる。

＜第五態様＞
また、復号タイミングと復号画出力タイミングがずれない符号化画像データを用い、各動画を表示部に表示させるべきタイミングに応じて、スライスのレベルで合体させので、動画の再生タイミングに関する制限が少なくなると共に、復号後の画像データを格納しておくデータバッファが不要となる。

＜第六態様＞
また、上位ＣＰＵは、各動画を表示部に表示させるべきタイミングに応じて、スライスのレベルで合体させる際に、表示に係る時間帯以外は補完スライスを充当し、当該補完スライスを含めた複数スライスの１ピクチャと見立てて一括して符号化画像データを構成することもできる。これにより、合体画像枠内に収まる動画の再生数が変更されても補完スライスを充当することで復号処理を変更せずに動画を再生できる。したがって、ハードウェアデコーダの初期化等の処理を不要とし、復号処理速度を向上することができる。

＜第七態様＞
また、上位ＣＰＵは、各動画を表示部に表示させるべきタイミングに応じて、スライスのレベルで合体させる際に、表示が終了した動画については当該動画のスライスが配置されていた個所に補完スライスを充当する。これにより、合体画像枠内に収まる動画の再生数が変更されても補完スライスを充当することで復号処理を変更せずに動画を再生できる。したがって、ハードウェアデコーダの初期化等の処理を不要とし、復号処理速度を向上することができる。

＜第八態様＞
また、上位ＣＰＵは、各動画を表示部に表示させるべきタイミングに応じて、スライスのレベルで合体させる際に、表示途中で一時停止させる動画については、当該一時停止させる期間について、直前のフレームを変更なく取得する時間方向予測で構成されるスライスを繰り返し充当する。これにより、符号化画像データの形式を変えず、一つの復号処理として継続して行うので、復号処理に必要な初期化等の手続きを少なくし、復号処理速度を向上することができる。

＜第九態様＞
また、上位ＣＰＵは、各動画を表示部に表示させるべきタイミングに応じて、スライスのレベルで合体させる際に、新たに表示される動画については、補完スライスを終了し、当該新たに表示される動画に係る先頭スライスを充当する。これにより、一つの復号処理を継続して行い、復号処理に必要な初期化等の手続きを少なくすることができる。

＜第十態様＞
さらに、上位ＣＰＵは、所定の解像度に係る合体画像枠を規定し、各動画を表示部に表示させるべきタイミングに応じて、スライスのレベルで合体させる際に、各動画が合体画像枠の垂直方向のどの位置を占めるのかに関する情報を指令に含める。これにより、合体画像枠内の動画の必要な個所を適切に切出すことができる。

＜第十一態様＞
本発明の画像データ処理方法は、動画に係る符号化画像データのうち、合体に係る各動画については、同一ＧＯＰ間隔かつピクチャタイプを揃えて符号化した符号化画像データを使用する。これにより各動画の符号化画像データをスライスのレベルで合体させることができる。

＜第十二態様＞
また、動画に係る符号化画像データのうち、合体に係る各動画は、水平方向にデータを補填することにより、水平解像度を揃えて符号化しておく。これにより、複数の動画を合体させた符号化画像データを単一のデコーダで復号することができる。

＜第十三態様＞
また、動画に係る符号化画像データのうち、合体に係る各動画は、その垂直解像度が、所定値以下である。これにより、複数の動画を合体させた符号化画像データを単一のデコーダで復号することができる。

＜第十四態様＞
更に、合体に係る各動画の各垂直解像度の総和は、ハードウェアデコーダの垂直方向処理容量を越えないようにする。これにより、複数の動画を合体させた符号化画像データを単一のデコーダで復号することができる。

＜第十五態様＞
また、動画に係る符号化画像データのうち、合体に係る各動画は、垂直方向にデータを補填することにより、垂直解像度を揃えて符号化しておく。これにより、合体させる動画の差し替えが容易となる。

＜第十六態様＞
更に、水平解像度に複数の基準値を設け、それらのうちの一の基準値に合わせることにより、水平解像度を揃える。これにより、合体させる動画の選別基準が明確となり、容易に演出設計時に合体に係る画像を選択することができる。

＜第十七態様＞
本発明の画像データ処理方法では、ビットストリームのＳＥＩもしくはＭＰ４等のコンテナに格納した符号化画像データを使用する。これにより、上位ＣＰＵが各動画を読み出す際に元画像サイズ情報を抽出し、それを画像処理プロセッサに供給でき、画像処理プロセッサでは補填処理された復号データから補填データを削除し、所望の領域の画像を抽出することができる。

＜第十八態様＞
また、画像処理プロセッサは、表示部に各動画を再生させる際に、各動画の各々のフレーム単位の所望の表示タイミングを担保するために、ハードウェアデコーダから得られた復号された画像データを画像データ格納部に蓄積しておく。これにより、動画再生タイミング情報に基づいて、所望のタイミングで動画を再生することができる。

上記のいずれの態様においても、垂直方向に解像度が小さい動画を多く再生する場合であっても、ハードウェアデコーダの初期化等の処理を不要とし、高速に複数の動画を再生することができ、さらに、並列処理機能を有するハードウェアデコーダを用いた場合には並列処理機能の利点を享受できる。

上記のいずれの態様においても各動画のピクチャ単位でそれらのスライスを複数のスライスとして纏めるというやり方で、各動画を合体させているので、ハードウェアデコーダ自体の構成や機能を何ら変更することなく、復号処理速度を向上することができる。

本発明の画像データ処理方法は、例えば、パチンコ機等の遊技機に採用できる。

１ 上位ＣＰＵ
１１、１５ 事前処理部
１１１ 各動画再生タイミング情報生成部
１６、１１２ 動画間各ピクチャ合体部
１７ 各動画合体情報生成部
１８ 補完スライス生成部
２ 画像データＲＯＭ
３ 画像処理プロセッサ
３１、３５ 事後処理部
３６、３１１ 命令解釈部
３７、３１２ 描画制御部
３１２１ 各動画分離部
３１２２ 元画像切出し部
３１２３ 各動画表示タイミング制御部
３２ ハードウェアデコーダ
３３ ビデオメモリ
４ 表示部
１００ 上位ＣＰＵ
２００ 画像データＲＯＭ
３００ 画像処理プロセッサ
４００ 表示部

Claims (18)

1. 動画に係る符号化画像データを出力すると共に、その動画の再生に係る指令を発行する上位ＣＰＵと、
   ハードウェアデコーダを有し、入力される前記指令に基づき、前記動画に係る符号化画像データを復号する画像処理プロセッサと、
   前記画像処理プロセッサにより復号された画像データに基づいて前記動画が再生される表示部と、
   を備えた画像処理装置を使用した画像データ処理方法であって、
   前記指令に基づき前記表示部に複数の動画が再生される場合に、前記上位ＣＰＵは、各動画を符号化画像データであるスライスのレベルで合体させて、複数スライスの１ピクチャと見立てて一括して符号化画像データを構成して前記画像処理プロセッサに供給し、前記ハードウェアデコーダは、その一括化された符号化画像データを復号することを特徴とする画像データ処理方法。
2. 前記上位ＣＰＵは、前記ハードウェアデコーダが一括して復号した画像データから各動画を分離するよう前記画像処理プロセッサに要求し、分離された各動画が前記表示部に再生されることを特徴とする請求項１に記載の画像データ処理方法。
3. 前記上位ＣＰＵは、合体させる動画の元画像サイズ情報を各動画データから抽出し、該元画像サイズ情報を画像処理プロセッサに供給し、
   前記画像処理プロセッサは一括して復号した画像データから前記元画像サイズ情報に基づいて各動画を分離したことを特徴とする請求項２に記載の画像データ処理方法。
4. 前記合体に係る各動画については、参照バッファの管理が同一となるよう符号化した符号化画像データを使用したことを特徴とする請求項１に記載の画像データ処理方法。
5. 前記上位ＣＰＵは、各動画を前記表示部に表示させるべきタイミングに応じて、前記スライスのレベルで合体させることを特徴とする請求項１に記載の画像データ処理方法。
6. 前記上位ＣＰＵは、各動画をスライスのレベルで合体させる際に、表示に係る時間帯以外は補完スライスを充当し、当該補完スライスを含めた複数スライスの１ピクチャと見立てて一括して符号化画像データを構成したことを特徴とする請求項５に記載の画像データ処理方法。
7. 前記上位ＣＰＵは、各動画スライスのレベルで合体させる際に、表示が終了した動画についても、以降、前記補完スライスを充当することを特徴とする請求項６に記載の画像データ処理方法。
8. 前記上位ＣＰＵは、各動画をスライスのレベルで合体させる際に、表示途中で一時停止させる動画については、当該一時停止させる期間について、直前のフレームを変更なく取得する時間方向予測で構成されるスライスを繰り返し充当することを特徴とする請求項５に記載の画像データ処理方法。
9. 前記上位ＣＰＵは、各動画をスライスのレベルで合体させる際に、新たに表示される動画については、前記補完スライスを終了し、当該新たに表示される動画に係る先頭スライスを充当することを特徴とする請求項６に記載の画像データ処理方法。
10. 前記上位ＣＰＵは、所定の解像度に係る合体画像枠を規定し、各動画が前記合体画像枠の垂直方向のどの位置を占めるかの情報を前記画像処理プロセッサに供給したことを特徴とする請求項５に記載の画像データ処理方法。
11. 前記動画に係る符号化画像データのうち、前記合体に係る各動画については、同一ＧＯＰ間隔かつピクチャタイプを揃えて符号化した符号化画像データを使用したことを特徴とする請求項１記載の画像データ処理方法。
12. 前記動画に係る符号化画像データのうち、前記合体に係る各動画は、水平方向にデータを補填することにより、水平解像度を揃えて符号化しておくことを特徴とする請求項４または１１に記載の画像データ処理方法。
13. 前記動画に係る符号化画像データのうち、前記合体に係る各動画は、その垂直解像度が、所定値以下であることを特徴とする請求項４または１１に記載の画像データ処理方法。
14. 前記合体に係る各動画の各垂直解像度の総和は、前記ハードウェアデコーダの垂直方向処理容量を越えないことを特徴とする請求項１３に記載の画像データ処理方法。
15. 前記動画に係る符号化画像データのうち、前記合体に係る各動画は、垂直方向にデータを補填することにより、垂直解像度を揃えて符号化しておくことを特徴とする請求項１３に記載の画像データ処理方法。
16. 前記水平解像度に複数の基準値を設け、それらのうちの一の基準値に合わせることにより、前記水平解像度を揃えることを特徴とする請求項１２に記載の画像データ処理方法。
17. 各動画の元画像のサイズの情報は、ＳＥＩもしくはＭＰ４等のＮＡＬコンテナに格納した符号化画像データを使用したことを特徴とする請求項４または１１記載の画像データ処理方法。
18. 前記画像処理プロセッサは、前記表示部に各動画を再生させる際に、各動画の各々のフレーム単位の所望の表示タイミングを担保するために、前記ハードウェアデコーダから得られた復号された画像データを画像データ格納部に蓄積しておくことを特徴とする請求項１記載の画像データ処理方法。