特許 6387511 画像データ処理方法

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

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

(11)【特許番号】6387511

(24)【登録日】2018年8月24日

(45)【発行日】2018年9月12日

(54)【発明の名称】画像データ処理方法

(51)【国際特許分類】

   H04N 19/42 20140101AFI20180903BHJP

   H04N 19/44 20140101ALI20180903BHJP

【ＦＩ】

   H04N19/42

   H04N19/44

【請求項の数】8

【全頁数】17

(21)【出願番号】特願2016-121278(P2016-121278)

(22)【出願日】2016年6月17日

(65)【公開番号】特開2017-225096(P2017-225096A)

(43)【公開日】2017年12月21日

【審査請求日】2017年7月12日

(73)【特許権者】

【識別番号】398034168

【氏名又は名称】株式会社アクセル

(74)【代理人】

【識別番号】100106426

【弁理士】

【氏名又は名称】山田 賢二

(72)【発明者】

【氏名】客野 一樹

(72)【発明者】

【氏名】横関 亘

【審査官】 岩井 健二

(56)【参考文献】

【文献】 特開２０１４−１９２５６４（ＪＰ，Ａ）

【文献】 特開２０１４−１１０４５２（ＪＰ，Ａ）

【文献】 国際公開第２０１５／１６８１５０（ＷＯ，Ａ１）

【文献】 国際公開第２０１５／０５８７１９（ＷＯ，Ａ１）

【文献】 国際公開第２０１２／０６０４５９（ＷＯ，Ａ１）

【文献】 国際公開第２００９／０３５９３６（ＷＯ，Ａ１）

【文献】 国際公開第２００１／０５６２９３（ＷＯ，Ａ１）

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

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

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

【請求項1】

動画に係る符号化画像データを出力すると共に、その動画の再生に係る指令を発行する上位ＣＰＵと、
複数のデータコアによる並列処理を行うハードウェアデコーダを有し、入力される前記指令に基づき、前記動画に係る符号化画像データを復号化する画像処理プロセッサと、
前記画像処理プロセッサにより復号化された画像データに基づいて前記動画が再生される表示部と、
を備えた画像処理装置を使用した画像データ処理方法であって、
前記表示部に再生されるべき複数の前記動画のうちの、その垂直解像度が前記ハードウェアデコーダの前記並列処理に係る画素数以下のものの中から、前記表示部に再生されるタイミングに関し、相互に所定内の近接度にあるものを組とし、同一組とされた各動画については、同一ＧＯＰ間隔で符号化して前記符号化画像データを生成しておき、
前記指令に基づき前記表示部に複数の動画が再生される場合に、前記上位ＣＰＵは、前記組とされた各動画を、各ピクチャ符号化画像データであるスライスのレベルでピクチャタイプを揃えて合体させて、各スライスのヘッダー領域に含まれる開始マクロブロック座標の情報を書き変えて複数スライスの１ピクチャと見立てて一括して符号化画像データを構成して前記画像処理プロセッサに供給し、前記ハードウェアデコーダは、その一括化された符号化画像データを復号化し、
前記上位ＣＰＵは、前記ハードウェアデコーダから得られた復号化された画像データから各動画を分離するよう前記画像処理プロセッサに要求し、分離された各動画が前記表示部に再生されることを特徴とする画像データ処理方法。

【請求項2】

前記組とされた各動画の垂直解像度の合計が、前記複数のデータコアによる並列処理の画素数を超えることを特徴とする請求項１に記載の画像データ処理方法。

【請求項3】

前記画像処理プロセッサは、前記表示部に各動画を再生させる際に、各動画の各々のフレーム単位の所望の表示タイミングを担保するために、前記ハードウェアデコーダから得られた復号化された画像データを画像データ格納部に蓄積しておくことを特徴とする請求項１に記載の画像データ処理方法。

【請求項4】

前記動画に係る符号化画像データのうち、前記合体に係る各動画は、水平方向にデータを補填することにより、水平解像度を揃えて符号化しておくことを特徴とする請求項１に記載の画像データ処理方法。

【請求項5】

前記水平解像度に複数の基準値を設け、それらのうちの一の基準値に合わせることにより、前記水平解像度を揃えることを特徴とする請求項４に記載の画像データ処理方法。

【請求項6】

前記動画に係る符号化画像データのうち、前記合体に係る各動画は、垂直方向にもデータを補填することにより、垂直解像度も揃えて符号化しておくことを特徴とする請求項４に記載の画像データ処理方法。

【請求項7】

各動画の元画像のサイズの情報は、ＳＥＩもしくはコンテナに格納しておくことを特徴とする請求項４乃至６のいずれかに記載の画像データ処理方法。

【請求項8】

前記合体に係る各動画に係る符号化画像データの前記ハードウェアデコーダによる復号化処理に際し、いずれかの動画に係る符号化処理が終了した場合、又はいずれかの動画の再生が中断されるべき場合、新たな動画が、前記ＧＯＰ単位で組み込まれることを特徴とする請求項１に記載の画像データ処理方法。

【発明の詳細な説明】

【技術分野】

【0001】

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

【背景技術】

【0002】

昨今の各種情報機器における動画再生処理においては、容量の観点から予め符号化して格納しておいた符号化動画情報を、読み出したり、又はネットを介してダウンロードしてきて、それを符号化に対応した復号化処理により復号化して表示装置に供給することにより、液晶機器等に動画が再生される。符号化処理には時間的な余裕があることからソフトウェアで処理することも可能であるが、復号化処理においては、高精細の動画であっても停滞なく再生されることを担保するためにハードウェア回路、特に専用の画像処理プロセッサ、を設けることも一般的になっている。

【0003】

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

【0004】

上記概念の概要を図１１に示す。
ここで、画像データＲＯＭ２００には、例えば、H.264(MPEG 4/AVC)規格に基づき符号化された１つ以上の動画情報が格納されている。なお、ここでは、情報機器本体に符号化された動画情報が格納される格納手段が備わっている場合を示しているが、ネット上のサーバ等からダウンロードしてくるような機器についても同様である。

【0005】

ここで、H.264規格について簡単に説明する。MPEG 2やMPEG 4ではシンタックスの階層構造が定められ、ビットストリームの中で並べられる情報は階層構造に沿ったものであるのに対し、H.264ではパラメータ・セットとそれを参照するスライスの配置についてはMPEG 2等と比較して制約が少ない。またパラメータ・セットにはシーケンス全体の符号化にかかわる情報を格納するＳＰＳ（Sequence Parameter Set：シーケンスパラメータセット）やピクチャ全体の符号化モードを示すＰＰＳ（Picture Parameter Set：ピクチャーパラメータセット）、任意の情報を符号化できるＳＥＩ（Supplemental Enhancement Information）が含まれ、フレームごとにＳＰＳやＰＰＳを配置することができるので、一つのビットストリーム中で複数のシーケンスを取り扱うことができる。

【0006】

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

【0007】

ここで、各スライスには、ヘッダー領域があり、そこには自スライスの先頭マクロブロック座標（first_mb_in_slice）の情報が少なくとも格納される。また、MPEG 2やMPEG 4でもそうであったように、H.264でも、一般的には、１ピクチャは１個以上のスライスで構成される。しかし、実際に１つの動画を普通に符号化すると、１フレームは、１スライスで構成される１ピクチャとして符号化される。ある種の効果を求めて、１フレームを複数スライスとして、すなわち１つの画像を複数に分割して複数のスライスとして符号化する技術は、例えば特許文献１に開示されている。

【0008】

しかしながら、特許文献１に代表されるような従来の技術においては、あくまで１つの動画の各画像を複数に分割するものであって、後述する本願発明の特徴のように、複数の動画のそれぞれを符号化して、それらを各スライスとして構成するような概念は従来にはない。

【0009】

図１１に戻り、上位ＣＰＵ１００からは、画像処理プロセッサ３００に対して、一般的にＡＰＩ（Application Program Interface）と呼ばれる処理指令が発せされる。機器が動作する元となっているオペレーティングシステム（ＯＳ）が、例えば、Windowsであれば、DXVA2(DirectX Video Acceleration 2)というＡＰＩであり、Linux（登録商標）であれば、VDPAU(Video Decode and Presentation API for Unix)というように、各機器が採用するソフトウェアプラットフォームにより固有のものが提供されている。上位ＣＰＵ１００は、表示部４００に所定のタイミングで表示させたい、必要な符号化画像データを画像データＲＯＭ２００から読み出し、表示の指令（表示タイミング、表示場所等）とともにその符号化画像データを画像処理プロセッサ３００に送る。当該指令と対応する符号化画像データを受け取った画像処理プロセッサ３００は、図示しない内部のハードウェアデコーダにより、当該符号化処理に対応した復号化処理を施すことにより、元の画像を復元する。そして、画像処理プロセッサ３００が、その復号化画像データを表示部４００に供給すれば、表示部４００の液晶画面等に動画が再生される。

【0010】

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

【0011】

しかしながら、特許文献２に記載の発明は動画像の視聴領域を任意に変更する技術に関するものであり、後述するような解像度の小さい画像を複数取り扱う場合の復号化処理の効率低下を回避するものではない。

【先行技術文献】

【特許文献】

【0012】

【特許文献1】特開２０１２−１９１５１３号公報

【特許文献2】国際公開第２０１２／０６０４５９号

【発明の概要】

【発明が解決しようとする課題】

【0013】

ところで、パチンコ機やパチスロ機のような遊技機における動画再生は、一本の動画が再生される一般的な動画再生とは顕著に異なる特徴がある。図１３は、パチンコ機やパチスロ機のような遊技機における動画再生を説明するための図である。具体的には、同図（ａ）に示すように、パチンコ機やパチスロ機のような遊技機においては、１つの液晶画面等の任意の複数の領域に、大小さまざまな解像度の動画が表示される。更に、同図（ｂ）に示すように、それらの各動画の再生開始時点及び再生時間は区々である。しかも、動画Ｅと動画Ｇの関係のように、遊技の進行に応じて、動画Ｅが最後まで再生されずに中断して、代わりに動画Ｇが再生し始める、というような態様もある。

【0014】

ここで、解像度の異なる画像のハードウェアデコーダによる復号化処理について注目すると、その処理性能は、解像度に依存せずに一定というわけではなく、解像度に依存してしまう。言い換えれば、解像度に応じて比例的に復号化の処理時間が決まるわけではない。例えば、解像度が１／２になったからといって、復号化の処理時間が半分になるものではない。図１４は、画像解像度（横軸）と処理性能（Gdps）（縦軸）との関係を示す図である。ここでは、参考までに、ソフトウェアにより復号化処理を行う場合も掲載している。理論的には、解像度によっては処理性能は変わらないはずであるが、同図に示すように、ソフトウェア処理によれば、解像度が小さくなるにつれて比例的に処理性能が減衰し、一方、ハードウェア処理によれば、解像度が小さくなるにつれて極端に処理性能が落ちてしまうことが分かる。

【0015】

上述のように、ハードウェアデコーダによる復号化処理において、解像度が小さくなるにつれて極端に処理性能が落ちてしまう理由は、主に以下の２つが考えられる。

【0016】

１つには、ハードウェアデコーダが、画像の垂直方向において、所定の解像度単位で並列処理を行っているからである。
図１５は、ハードウェアデコーダにおける垂直方向並列処理を説明するための図である。同図（ａ）は、並列処理を行わない場合であり、同図（ｂ）は並列処理を行う場合を示している。一般的、復号化処理は、マクロブロック（ＭＢ）（例えば、１６×１６画素）単位で行われ、並列処理を行わない場合であれば、同図（ａ）に示すように、マクロブロックの水平一列に対応した１つのデコーダコアが、当該列の各マクロブロックを順に復号化していく。ここで、H.264規格のように、イントラ予測が採用されているのであれば、既に復号化処理された周りの所定のマクロブロックの情報を参照しつつ、一行ごとに復号化が進められていく。

【0017】

これに対して、並列処理機能を有する場合は、同図（ｂ）に示すように、複数のマクロブロックに対応した複数のデコーダコアが備わっており、それら複数のデコーダコアが複数のマクロブロックに対して同時並列的に復号化処理を進めていく。この場合も、イントラ予測が採用されているのであれば、同図（ｂ）に示すように、典型的には波状に処理が進むこととなり、そのことから、かかる並列処理は、ウェイブフロント並列処理（wave front parallel processing）と呼ばれている。

【0018】

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

【0019】

このように、どの程度の並列処理機能を備えるかによるが、概して、大きな解像度を有する画像を処理する場合と比較すると、小さな解像度を有する画像に対して復号化処理を行う場合は、相対的に処理性能が落ちることとなる。

【0020】

２つめの理由は、解像度の小さな画像も解像度の大きな画像も１ピクチャである点で変わらず、１ピクチャを復号化する処理においては、画像データの符号化処理自体以外に、デコーダの初期化等の付随処理が必ず伴うものであり、このことから、小さな解像度の画像であっても、その数が増えると、格段に処理ステップが増え、結果として、大きな解像度を有する画像を処理する場合と比較すると、小さな解像度の画像であっても、その数が増えると、その復号化処理性能は落ちることとなる。

【0021】

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

【0022】

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

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

【0023】

上記目的を達成するため、本発明の画像データ処理方法は、動画に係る符号化画像データを出力すると共に、その動画の再生に係る指令を発行する上位ＣＰＵと、複数のデータコアによる並列処理を行うハードウェアデコーダを有し、入力される前記指令に基づき、前記動画に係る符号化画像データを復号化する画像処理プロセッサと、前記画像処理プロセッサにより復号化された画像データに基づいて前記動画が再生される表示部と、を備えた画像処理装置を使用した画像データ処理方法であって、前記表示部に再生されるべき複数の前記動画のうちの、その垂直解像度が前記ハードウェアデコーダの前記並列処理に係る画素数以下のものの中から、前記表示部に再生されるタイミングに関し、相互に所定内の近接度にあるものを組とし、同一組とされた各動画については、同一ＧＯＰ間隔で符号化して前記符号化画像データを生成しておき、前記指令に基づき前記表示部に複数の動画が再生される場合に、前記上位ＣＰＵは、前記組とされた各動画を、各ピクチャ符号化画像データであるスライスのレベルでピクチャタイプを揃えて合体させて、各スライスのヘッダー領域に含まれる開始マクロブロック座標の情報を書き変えて複数スライスの１ピクチャと見立てて一括して符号化画像データを構成して前記画像処理プロセッサに供給し、前記ハードウェアデコーダは、その一括化された符号化画像データを復号化し、前記上位ＣＰＵは、前記ハードウェアデコーダから得られた復号化された画像データから各動画を分離するよう前記画像処理プロセッサに要求し、分離された各動画が前記表示部に再生されることを要旨とする。

【0024】

このとき、前記組とされた各動画の垂直解像度の合計が、前記複数のデータコアによる並列処理の画素数を超えることが好適である。

【0026】

一方、前記画像処理プロセッサは、前記表示部に各動画を再生させる際に、各動画の各々のフレーム単位の所望の表示タイミングを担保するために、前記ハードウェアデコーダから得られた復号化された画像データを画像データ格納部に蓄積しておく場合がある。

【0029】

また、前記動画に係る符号化画像データのうち、前記合体に係る各動画は、水平方向にデータを補填することにより、水平解像度を揃えて符号化しておくことが好ましい。そのとき、前記水平解像度に複数の基準値を設け、それらのうちの一の基準値に合わせることにより、前記水平解像度を揃えることが一案である。また、前記動画に係る符号化画像データのうち、前記合体に係る各動画は、垂直方向にもデータを補填することにより、垂直解像度も揃えて符号化しておくことも好ましい。このような補填の際には、各動画の元画像のサイズの情報は、ＳＥＩもしくはコンテナに格納しておく。

【0030】

また、前記合体に係る各動画に係る符号化画像データの前記ハードウェアデコーダによる復号化処理に際し、いずれかの動画に係る符号化処理が終了した場合、又はいずれかの動画の再生が中断されるべき場合、新たな動画が、前記ＧＯＰ単位で組み込まれることも特徴である。

【発明の効果】

【0031】

本発明の画像データ処理方法によれば、ＣＰＵは、各動画を、各ピクチャ符号化画像データであるスライスのレベルで合体させて、複数スライスの１ピクチャと見立てて一括してハードウェアデコーダに復号化させているので、復号化処理速度が向上する。

【0032】

特に、垂直方向に解像度が小さい動画を多く再生する場合でも、ハードウェアデコーダの並列処理機能の利点を享受できるので、効果的である。

【0033】

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

【図面の簡単な説明】

【0034】

【図1】本発明の画像データ処理方法における一実施形態の概要を説明するための図である。

【図2】各動画の符号化処理の手順を示すフローチャートである。

【図3】画像データの補填（パディング）処理を説明するための図である。

【図4】符号化後の各動画のビットストリームを示す図である。

【図5】本発明の画像データ処理方法の一実施形態において使用される画像処理装置の構成を示すブロック図である。

【図6】復号化前の事前処理における、各動画間のピクチャタイプを合せる時間調整を説明するための図である。

【図7】各動画を、各ピクチャ符号化データであるスライスのレベルで合体させて、複数スライスの１ピクチャと見立てて一括して復号化することを説明するための図である。

【図8】ある動画が中断して他の動画に切り替わる場合を説明するための図である。

【図9】ある動画が中断して他の動画に切り替わる場合を説明するための図である。

【図10】事後処理部３１２の処理を説明するための図である。

【図11】動画を再生するための機器の構成を示す図である。

【図12】H.264規格に基づき符号化された画像の符号化データの一般的なビットストリームを示す図である。

【図13】パチンコ機やパチスロ機のような遊技機における動画再生を説明するための図である。

【図14】画像解像度（横軸）と処理性能（Gdps）（縦軸）との関係を示す図である。

【図15】ハードウェアデコーダにおける垂直方向並列処理を説明するための図である。

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

【0035】

以下、図面を参照して、本発明の実施の形態について詳細に説明する。
＜概要＞
図１は、本発明の画像データ処理方法における一実施形態の概要を説明するための図である。本発明においては、端的に言えば、垂直方向の解像度が小さい複数の動画の符号化画像データを合体させて、その合体したものを復号化し、得られた画像データから、元の複数の動画を分離する、というような処理を行うことにより、垂直方向の解像度が小さい動画が多くあっても、復号化処理性能を落とさないようにする、というものである。

【0036】

より具体的には、同図（ａ）において、まず、所定の動画の表示処理を含む所定の処理が行われるように意図されている画像処理装置（例えば、パチンコ機に組み込まれているもの）についてのその処理設計（特に、動画表示については、どのような動画をどのタイミングで表示するか等）から、当該装置に表示される各動画のうち、合体して復号化処理を行うべき動画を選別するという復号化処理設計を行う（ステップＳ１）。例えば、同図（ｂ）に示すように、動画Ｘについては単独で処理し、垂直解像度の小さい動画Ｙ及び動画Ｚについては、合体して復号化処理できる可能性がある、と設計する。そして、動画Ｘ、動画Ｙ、及び動画Ｚをそれぞれ符号化する（ステップＳ２）。次に、動画Ｘについては、その符号化データを単独で復号化し、動画Ｘを復元して、画像処理装置の表示部に所定のタイミングで表示する。一方、動画Ｙ及び動画Ｚについては、それらの表示タイミングによっては、それらの符号化データを合体させて復号化し、動画Ｘ及び動画Ｙを復元し、更にそれらを分離することにより、表示部にそれぞれのタイミングで表示する（ステップＳ３）。

【0037】

以下、上述した概要をより具体的にした実施形態を、いくつかの所定条件も含めて詳細に説明する。
＜復号化設計処理（ステップＳ１）＞
復号化時に合体させるべき動画を選別する条件として、解像度の観点からは以下である。
・合体させるべき各動画の垂直方向の解像度は、複数のデコーダコアによる並列処理の”画素数”以下である
・合体させるべき各動画の垂直方向の解像度の合計値が、複数のデコーダコアによる並列処理の”画素数”を越えること
・ただし、合体させるべき各動画の垂直方向の解像度の合計値が、デコーダの垂直方向の”最大解像度”を越えないこと

【0038】

また、各動画を画像処理装置に表示するタイミングの観点からは、合体させるべき各動画は、表示タイミングが可及的に近いもの同士である。上記の解像度の観点の条件を満たしていれば、どのようなタイミングで表示される動画同士でもよいのであるが、復号化処理の時点と表示の時点が離れていればいるほど、復号化処理後の画像データを一旦蓄えておく画像データバッファでの滞留時間が長くなってしまう。従って、表示するタイミングの観点における、合体させるべき各動画の選別は、当該画像データバッファの容量に依存する。なお、遊技機を例に挙げて説明すると、一つのイベントで同時或いは同時期に再生される動画であって、上記条件を満たすものを合体して復号させるデータとして復号化設計処理を行うのが好適である。

【0039】

＜符号化処理（ステップＳ２）＞
次に、各動画の符号化処理について説明する。図２は、その処理手順を示すフローチャートである。そこで、符号化すべき動画を選択する（ステップＳ２１）。そして、選択した動画が、前述の復号化設計処理に基づき、他の動画と合体させるべき動画か否かを判断する（ステップＳ２２）。図１３に例示したような動画Ａのような場合は、単独で復号化処理を行うので、ステップＳ２２は否定判定となり、ステップＳ２３をスキップしてステップＳ２４に移行する。一方、図１３に例示したような動画Ｂ乃至動画Ｇ（垂直方向解像度が例えば１２８画素以下）のそれぞれの場合は、他のいずれかと合体させて復号化処理するとしたものであり、よって、ステップＳ２２は肯定判定となり、そのままステップＳ２３に移行する。

【0040】

ステップＳ２３においては、画像データの補填（パディング）処理を行う。図３は、その補填処理を説明するための図である。そこで、例えば、動画Ｂと動画Ｆとが組で合体でき、動画Ｃ、動画Ｄ、及び動画Ｅ（動画Ｇ）とが組で合体すべき場合があるとする。なお、動画Ｇは、動画Ｅが再生途中で中断した場合に、そこから再生されるべき動画である。そこで、少なくとも同じ組の各動画は、後述する復号化処理の方式から、水平方向の解像度が揃っている必要がある。従って、水平方向の解像度を揃えるために各動画の水平方向について画像データの補填処理を行う。このとき、一律にデコーダの水平方向の最大処理解像度に揃えるとしてもよい。そうすれば、すべての組について、その同じ最大処理解像度に揃えることができるので、補填処理自体は簡易となる。しかしながら、水平方向にも小さな解像度の動画ばかりの各動画を合体させる場合も一律にそのようにするとすれば、補填データばかりが大きくなり、復号化処理において無駄が生じてしまう。従って、例えば、水平方向１２０、２４０、４８０、９６０、１９２０画素というように、いくつかの揃える基準を設けるのが得策である。揃える基準は、合体させる各動画のうちの最大の水平方向解像度を有する動画の当該解像度によって決まるのであるから、それらの基準の数やその値の設定は、合体させる各動画の各水平方向解像度のばらつきに依存する。逆に言えば、合体させるべき動画の選定の条件として、水平方向解像度を入れることもできる。

【0041】

ステップＳ２４においては、各動画の符号化処理を行う。例えば、H.264規格に基づき典型的には、ソフトウェア処理により行う。このときの条件としては、少なくとも同じ組である各動画については、１ＧＯＰに含まれるフレームの数が同一（例えば、３０）になるような符号化処理を行う、ということである。後述の復号化処理において、合体して復号化処理が行えるようにするためである。また、図４は、符号化後の各動画のビットストリームを示す図であるが、従来と同様、１ピクチャが１スライスとして構成され、また、スライスのヘッダーには、従来通り、マクロブロック開始座標の情報が格納されるが、本発明に特徴的なものとしては、更に、“元画像のデータサイズ”（解像度）（例えば、図３に示す動画Ｃであれば、１１０×４８）を別途、ＳＥＩもしくはＭＰ４などＮＡＬを内包するコンテナに入れる処理を行う、ということである。これは、後述するように、各動画の復号化処理を行い表示する画像処理装置において、復号化処理後に、元画像を抽出できるようにするためである。

【0042】

ステップＳ２５においては、未処理の動画が残っているかを判定し、残っていれば（肯定判定）、ステップＳ２１に戻り、以上の処理を繰り返し、全動画終了であれば、処理を終える。

【0043】

なお、上述の実施形態においては、垂直方向の解像度については、各動画についてそのまま、すなわち区々としたが、合体して復号化処理すべき各動画については、補填処理により垂直方向の解像度も揃えるということも考えられる。垂直方向の解像度も揃えると、同一組として合体して復号化処理すべき各動画の入れ替えが画一的に行え、上述の符号化設計処理において処理が簡素になる。

【0044】

＜デコーダを備えた画像処理装置の実動による画像データ処理（ステップＳ３）＞
図５は、本発明の画像データ処理方法の一実施形態において使用される画像処理装置の構成を示すブロック図である。
同図に示す画像処理装置は、上位ＣＰＵ１と、画像データＲＯＭ２と、画像処理プロセッサ３と、表示部４とで構成されている。上位ＣＰＵ１は事前処理部１１を有し、事前処理部１１は、各動画再生タイミング情報生成部１１１と動画間各ピクチャ合体部１１２とを有している。また、画像処理プロセッサ３は、事後処理部３１と、ハードウェアデコーダ３２と、ビデオメモリ３３とを有し、更に事後処理部３１は、命令解釈部３１１と描画回路３１２とを有している。描画回路３１２には、各動画分離部３１２１と、元画像切出し部３１２２と、各動画表示タイミング制御部３１２３が含まれている。ここで、画像データＲＯＭ２には、上述の＜符号化処理（ステップＳ２）＞によって符号化された各動画のデータが格納されている。

【0045】

図５に示す画像処理装置における画像データ処理の概要は以下の通りである。なお、事前処理部１１及び事後処理部３１の詳細説明については、後述する。
上位ＣＰＵ１は、当該画像処理装置での設計動作に基づき、画像データＲＯＭ２から必要な動画に係る符号化画像データを読み出してくるのであるが、特に、前述の＜復号化設計処理（ステップＳ１）＞で設計された合体可能な各動画に係る情報に基づき、画像データＲＯＭ２から合体可能な複数の動画に係る符号化画像データを読み出してくる場合、後に詳述のように、動画間各ピクチャ合体部１１２が、各動画間でピクチャタイプが揃った状態で、各動画ピクチャを各スライスとして合体するのであるが、そのとき、合体させるスライスのヘッダー領域に含まれる先頭マクロブロック座標の情報を書き換える。そして、動画間各ピクチャ合体部１１２は、複数のスライスで構成された合体後の符号化画像データを画像処理プロセッサ３のハードウェアデコーダ３２に供給する。

【0046】

複数のスライスで構成された合体後の符号化画像データに基づく各動画は、表示させるべきタイミングは通常それぞれ異なるので、上位ＣＰＵ１は、各動画の再生タイミング情報を画像処理プロセッサ３側に知らせる必要がある。その再生タイミング情報を生成する処理を行うのが、各動画再生タイミング情報生成部１１１である。すなわち、各動画再生タイミング情報生成部１１１は、例えば、遊技機の一つのイベントで表示される複数の動画の再生タイミング等の調整時間を設定し、その情報を画像処理プロセッサ３に供給する。

【0047】

ハードウェアデコーダ３２は、上位ＣＰＵ１から供給された合体後の符号化画像データに対して復号化処理を行い、復号結果をビデオメモリ３３に供給すると共に、図示しない復号完了通知を上位ＣＰＵ１に出力する。ハードウェアデコーダ３２から復号化の完了通知を受け取った上位ＣＰＵ１は、画像処理プロセッサ３の事後処理部３１に事後処理の指令を行い、その命令解釈部３１１は、その指令に含まれる、少なくとも、合体に係る各動画を表す情報や各動画の再生タイミングに係る情報を描画回路３１２に供給する。描画回路３１２に含まれる各動画分離部３１２１、元画像切出し部３１２２、及び各動画表示タイミング制御部３１２３は、それらの情報と、ビデオメモリ３３に格納された復号化画像データ自体に含まれる元画像のデータサイズの情報（図４参照）に基づき、ビデオメモリ３３に格納された復号化画像データに対して所定の事後処理を施したのち、その結果を表示部４に供給して各動画として表示させる。

【0048】

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

【0049】

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

【0050】

また、上位ＣＰＵ１で複数の動画、例えば、動画Ｃ、Ｄ、Ｅ及びＧを再生する指令が発生すると、必要な符号化画像データであるスライスを画像データＲＯＭ２から読み出し、動画間各ピクチャ合体部１１２は、合体させるスライスのヘッダー領域に含まれる先頭マクロブロック座標の情報を書き換えて、複数のスライスを合体させ、合体後の圧縮データを生成し、それを画像処理プロセッサ３のハードウェアデコーダ３２に供給する。なお、画像データＲＯＭ２から読み出される動画Ｃ、Ｄ、Ｅについては読み出し後に補填処理を施してもよい。

【0051】

また、スライスのヘッダー領域に含まれる先頭マクロブロックの座標情報書き換えとは、各スライスの先頭マクロブロックの座標情報は当初「０」が格納されているので、大きな１つの画像として合体する際の各スライスの配置に応じて先頭マクロブロックの座標情報を所望の値に変更するものである。例えば、図１０（ａ）に示すように動画Ｃ、動画Ｄ、動画Ｅをまとめ、大きな１つの画像として合体させる場合、動画Ｃのスライスのヘッダー領域に含まれる先頭マクロブロックの座標情報は書き換える必要がないが、動画Ｄ及び動画Ｅのスライスのヘッダー領域に含まれる先頭マクロブロックの座標情報はそれぞれ配置される位置の情報に応じて書き換えられる。このように複数スライスを含む符号化画像データをハードウェアデコーダ３２で正常に復号化できる有効なH.264ストリームを生成するためである。

【0052】

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

【0053】

例えば、命令解釈部３１１で解釈した指令が、“動画Ｃを所定のタイミングから再生せよ”、“動画Ｄを所定のタイミングから再生せよ”、“動画Ｅを所定のタイミングから再生せよ”というものであった場合、ビデオメモリ３３内に格納されている復号化画像データのうち、動画Ｃにかかる画像と、動画Ｅにかかる画像と、動画Ｅにかかる画像をそれぞれ切出し、指定されたタイミングで表示装置４に表示するよう描画回路３１２が制御される。

【0054】

なお、複数の動画に関する画像データをスライスとして合体し、その合体後の圧縮データを同一のハードウェアデコーダ３２で処理するため、スライスとして合体させる各画像データのピクチャタイプは同一である必要がある。そこで、合体の可能性のある各動画の１ＧＯＰに含まれるフレーム数を同一とし、図６に示すように、各動画（動画Ｃ、動画Ｄ、動画Ｅ）の任意の（先頭の）ＧＯＰのＩピクチャを揃えてスライスを合体させなければならない。

【0055】

一方、図１３に示したように動画Ｃ、動画Ｄ、動画Ｅの再生タイミングが全て異なる場合には、各動画に用いる画像を復号し、同時に各画像を描画することはできない。そのため、動画の再生タイミング（描画の開始タイミング）の情報を上位ＣＰＵ１の各動画再生タイミング情報生成部１１１で生成し、その情報に基づいて画像処理プロセッサ３の描画回路３１２が画像を作成し、所定のタイミングで表示装置４に表示するよう制御が必要である。

【0056】

上述のように各動画のピクチャタイプが揃った状態で、動画間各ピクチャ合体部１１２は、各動画をフレーム単位で、すなわち、各動画を、各ピクチャ符号化データであるスライスのレベルで合体させて、複数スライスの１ピクチャと見立てて編成させる。図７はこれを説明するための図である。前述のように、各動画の符号化データのビットストリームにおいては、通常、同図の左側に示すように、１ピクチャ１スライスで構成されているのに対して、合体の処理においては、各スライスを並べることにより、すなわち、スライスレベルで合体させる。なお、ここでは、ＳＰＳ（Sequence Parameter Set）、ＰＰＳ（Picture Parameter Set）及びＳＥＩ（Supplemental Enhancement Information）を一組としており、そのときはそれらを書き変えることとなる。例えば、ＳＰＳには参照フレーム数やフレームの幅及び高さの情報が含まれているが、合体させた後の高さ情報等は調整が必要である。また、ＰＰＳには符号化方式や量子化係数等の情報が含まれているが、各画像でこれらの情報が異なる場合には調整が必要である。また、図１２を参照して説明した、スライスのヘッダーに含まれる開始マクロブロック座標についても、各スライスにおいて合体に応じて書き変えるようにする。

【0057】

事前処理部１１は、各動画の符号化画像データを上述のようにスライスレベルで編成することにより、各動画を合体させつつ、当該符号化画像データをハードウェアデコーダ３２に供給する。ここで、ハードウェアデコーダ３２側では、当該符号化画像データを受けると、１ピクチャが複数スライス（例では３スライス）で構成されたものとは認識するが、あくまでこれは規格（H.264）で定められた範囲であり（MPEG-2、4でも同様）、そのまま復号化処理を行うことができる。しかしながら、ハードウェアデコーダ３２は、複数の動画を合体させたものであるということまでは認識しない。これは、言い換えれば、ハードウェアデコーダ３２については、何ら手を加える必要がないということを意味している。つまり、そのように事前処理、また後述する事後処理を行っているということである。

【0058】

図６に戻り、各動画は再生時間が区々であることから、短いものから先に終了していく。このとき、空いたところに別の動画を差し入れることもできるが（垂直解像度、表示タイミング、画像データバッファ３１２４の容量の観点）、そのときも、他の動画とＧＯＰ単位で整合をおこなう。また、図１３で例示するように動画Ｅが途中で動画Ｇに切り替わる場合を説明するものが図８及び図９である。図８（ａ）は、動画Ｅの中断がない場合を示しており、同図（ｂ）は、動画Ｅが中断して代わりに動画Ｇが再生される場合を示している。この場合も、ＧＯＰ単位で切り替わるが、同図（ｂ）の例では、動画ＥのＧＯＰ［２］の後に、動画ＥのＧＯＰ［３］の代わりに、動画ＧのＧＯＰ［１］が組み込まれている。動画ＥのＧＯＰ［２］と動画ＧのＧＯＰ［１］の境目を、各動画のピクチャの合体の観点から見たものが、図９である。同図に示すように、切替え前の最終フレームにおいては、動画Ｃ、動画Ｄ、及び動画Ｅの各Ｐピクチャを合体させるようになっているが、切替え後の最初のフレームにおいては、動画Ｃ、動画Ｄ、及び動画Ｇの各Ｉピクチャを合体させるようになっている。

【0059】

次に、事後処理部３１について説明する。図１０は、事後処理部３１の処理を説明するための図である。
ハードウェアデコーダ３２からの復号化後の画像データがビデオメモリ３３に格納されると、まず、各動画分離部３１２１は、図１０（ａ）の左側にあるように、各スライスヘッダーに書き込んだ各動画の開始マクロブロック座標に基づき、フレームごとに各動画を分離する。次に、元画像切出し部３１２２は、同図（ａ）の右側にあるように、各動画のＳＥＩもしくはコンテナに格納されていた元画像のデータサイズに基づいて、フレームごとに＜符号化処理（ステップＳ２）＞のときに補填された補填データを削除する。そして、このようにフレームごとに元画像が再現された各動画のデータは、ビデオメモリ３３に蓄積されていく。そして、各動画表示タイミング制御部３１２３は、上位ＣＰＵ１の各動画再生タイミング情報生成部１１１からの各動画の再生タイミングに関する情報に基づいて、同図（ｂ）に示すように、各動画の所望の表示タイミングで、それぞれ表示部４に再生していく。

【0060】

なお、上述の説明においては、図１３で示した動画Ｃ、動画Ｄ、動画Ｅ、動画Ｇを例にして説明したが、同図（又は図３（ａ））にある動画Ｂ及び動画Ｆでも同様である。

【0061】

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

【0062】

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

【産業上の利用可能性】

【0063】

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

【符号の説明】

【0064】

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

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】