特許 5969914 動画像圧縮伸張装置

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

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

(11)【特許番号】5969914

(24)【登録日】2016年7月15日

(45)【発行日】2016年8月17日

(54)【発明の名称】動画像圧縮伸張装置

(51)【国際特許分類】

   H04N 19/433 20140101AFI20160804BHJP

   H04N 19/12 20140101ALI20160804BHJP

   H04N 19/154 20140101ALI20160804BHJP

   H04N 19/156 20140101ALI20160804BHJP

   H04N 19/172 20140101ALI20160804BHJP

   H04N 19/503 20140101ALI20160804BHJP

【ＦＩ】

   H04N19/433

   H04N19/12

   H04N19/154

   H04N19/156

   H04N19/172

   H04N19/503

【請求項の数】4

【全頁数】9

(21)【出願番号】特願2012-278274(P2012-278274)

(22)【出願日】2012年12月20日

(65)【公開番号】特開2014-123830(P2014-123830A)

(43)【公開日】2014年7月3日

【審査請求日】2015年1月9日

(73)【特許権者】

【識別番号】000233295

【氏名又は名称】株式会社日立情報通信エンジニアリング

(74)【代理人】

【識別番号】110001689

【氏名又は名称】青稜特許業務法人

(74)【代理人】

【識別番号】110000350

【氏名又は名称】ポレール特許業務法人

(72)【発明者】

【氏名】小味 弘典

(72)【発明者】

【氏名】谷田部 祐介

(72)【発明者】

【氏名】海野 恭平

(72)【発明者】

【氏名】元場 良幸

(72)【発明者】

【氏名】堀 敏彰

(72)【発明者】

【氏名】柏原 義昌

(72)【発明者】

【氏名】柳原 利一

【審査官】 山▲崎▼ 雄介

(56)【参考文献】

【文献】 特許第３９１８２６３（ＪＰ，Ｂ２）

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

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

【文献】 米国特許出願公開第２０１１／０２４９９５９（ＵＳ，Ａ１）

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

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

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

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

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

【請求項1】

動画像データの圧縮および伸張を行う動画像圧縮伸張装置であって、
当該動画像圧縮伸張装置に入力された動画像信号に対し当該画像のフレーム間予測を行ってデータ圧縮して得た第１の動画像圧縮データを出力し、前記動画像圧縮伸張装置に入力された動画像圧縮データに対しデータ伸張して得た動画像信号を出力する動画像圧縮伸張処理部と、
当該動画像圧縮伸張処理部においてデータ圧縮される前記動画像信号及び前記フレーム間予測を行う際に参照する参照画像信号を前記動画像圧縮伸張処理部におけるデータ圧縮とは異なる方法でデータ圧縮して得た第２の動画像圧縮データを前記動画像圧縮伸張装置に外付けされた又は内蔵されたメモリに対して書込み、当該メモリから読み出した前記第２の動画像圧縮データをデータ伸張するデータ変換部を有し、
当該データ変換部は、前記第２の動画像圧縮データを前記メモリに書込み読み出す際のメモリアドレスの順序を、同一の画像フレーム内において書込み時と読み出し時で異ならせるものであって、
前記第２の動画像圧縮データを生成する際に、前記動画像信号の各走査線のデータを第１のデータ量のバースト単位で複数のバーストに分割して圧縮し、圧縮されて第２のデータ量とされた前記バーストを前記メモリにデータとして前記走査線の走査方向に順次書込み、
前記メモリに書込まれたデータを読み出す際に、前記各走査線のデータから前記第１のデータ量分のデータを、前記走査線に対し垂直な方向に順次読み出す
ことを特徴とする動画像圧縮伸張装置。

【請求項2】

請求項１に記載の動画像圧縮伸張装置において、前記データ変換部は、
前記動画像信号、或いは前記参照画像のフレーム種別と前記データ変換部の動作モードに応じて、ロスレス圧縮モード又はロッシー圧縮モードのいずれかを選択する
ことを特徴とする動画像圧縮伸張装置。

【請求項3】

請求項１に記載の動画像圧縮伸張装置において、前記データ変換部は、
前記第２の動画像圧縮データを生成する際に、画質を優先する場合にはロスレス圧縮によるデータ圧縮を行い、アクセスレートの削減を優先する場合にはロッシー圧縮によるデータ変換を行う
ことを特徴とする動画像圧縮伸張装置。

【請求項4】

請求項１に記載の動画像圧縮伸張装置において、前記データ変換部は、
前記第２の動画像圧縮データを生成する際の圧縮動作を、画質と外部メモリへのアクセス量の削減効果の関係に応じて定める
ことを特徴とする動画像圧縮伸張装置。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は動画像圧縮伸張装置に係り、特に画像圧縮伸張処理を行う際、画像フレームを格納するメモリへのアクセスバンド幅の利用効率を向上させる技術に関する。

【背景技術】

【0002】

動画像処理を行うシステムLSIにおいては、信号処理過程の画像データをたとえばDDR3−SDRAM（Double Data Rate 3 Synchronous Dynamic Random Access Memory）などの大容量メモリに格納する際の、データレートの増加を抑制する技術が従来から開示されている。例えば特許文献１では、符号化ストリームをデコードし、表示する際の連続する画像データ間の相関を用いて、データを可逆（ロスレス）圧縮もしくは非可逆（ロッシー）圧縮を行うことにより、SDRAMコントローラへのアクセス集中を緩和する技術が記載されている。

【先行技術文献】

【特許文献】

【0003】

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

【発明の概要】

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

【0004】

しかし、上記発明を画像圧縮伸張に適用する際については、ロスレスやロッシー圧縮の適用をいかに制御するか、効率の良いメモリアクセスをどのように実現するかに関し、具体的な技術については記載していない。
本発明の目的は、かかる課題を解決し、画質への影響を少なく保ちつつ、メモリへのアクセスバンド幅の利用効率を向上させた画像圧縮伸張装置を実現することにある。

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

【0005】

本特許の実施例に解決手段を記載する。

【発明の効果】

【0006】

本発明によれば、画像圧縮伸張装置において、画質への影響を少なく保ちつつ、メモリへのアクセスバンド幅の利用効率を向上させることができ、当該装置の基本性能の向上に寄与できるという効果がある。

【図面の簡単な説明】

【0007】

【図1】一実施例における画像圧縮伸張をシステムLSI内で実現した例を示すブロック図。

【図2】一実施例におけるラインアクセスとブロックアクセスの変換の説明図。

【図3】一実施例におけるブロックアクセスのリードライトアクセスの説明図。

【図4】一実施例におけるＳＤＲＡＭ内のメモリ割当の一例を示す図。

【図5】一実施例におけるロスレス圧縮とロッシー圧縮の切り替えの組み合わせを示す図。

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

【0008】

図１は、本発明の実施例１の動画像圧縮伸張装置を用いて、画像処理のためのシステムＬＳＩ１を構築した例を示すブロック図である。図中、５のブロックが、本実施例の動画像圧縮伸張装置に該当する。以下、図面に沿って説明する。
画像処理システムＬＳＩ１では、画像入力端子２から入力される動画像データをリアルタイムで圧縮符号化処理し、ストリームデータとしてストリーム入出力端子８より、外部に接続されたＳＤカード、コンパクトフラッシュ（登録商標）などの蓄積媒体にデータを蓄える装置を想定する。また、いったん外部の蓄積媒体に格納されたデータは、同ＬＳＩ１に読み込まれ、動画像の復号処理の後、画像出力端子１１から、図示しない外部のディスプレイに動画として出力される動作を想定する。

【0009】

まず動画像の圧縮時の動作について説明する。画像入力端子２からはここでは、Full HD相当の映像が入力されるものとする。この場合、有効画像サイズは水平１９２０×垂直１０８０画素を想定する。またフレームレートはプログレッシブ走査方式で６０Ｈｚとする。
この場合ビデオＩＦ部３は入力されたデータを順次水平走査線方向のデータとしてたとえば、BT.709などのデジタルフォーマットで受信する。データは輝度（Ｙ）、色差（Ｃｂ，Ｃｒ）の４：２：２成分として入力され、H.264の標準的なフォーマットとされる４:２:０成分にコンバートされた後、動画像圧縮伸張処理部５に入力される。この場合走査線方向でデータが入力されるものとする。

【0010】

一般に、H.264の動画圧縮では、入力される各画像フレームを、面内予測処理のみを行うイントラピクチャ（Ｉピクチャ）、時間軸上で片方向の動き予測を行う（Ｐピクチャ）、時間軸上で両方向の動き予測を行う（Ｂピクチャ）と符号化のタイプに応じていずれかのピクチャタイプでエンコードされる。
Ｂピクチャの場合、圧縮処理中の現在のフレームに対して、時間方向で前と後ろに存在するフレーム画像データを参照する必要がある。そのため、いったん複数枚の入力画像（以下、原画像と呼ぶ）をフレームメモリに格納し、前後のフレーム参照が可能になった段階でエンコード処理する。

【0011】

また、Ｉ、Ｐ、Ｂピクチャとして圧縮されたデータは、その付近の他のＰ、Ｂピクチャの動き予測のための参照フレームとして利用される。このため、当該圧縮後のデータは、圧縮装置中でいったん復号され、他の参照のためにフレームメモリに格納される。これを参照画像と呼ぶ。
本実施例では、上記処理のために、入力された原画像を動画像圧縮伸張処理部５の外部のメモリに格納する。本実施例中では、外部に大容量のDDR2−SDRAM１０を接続し、その所定のメモリ空間に原画像領域を確保し、順次格納する。

【0012】

この際、データ変換部５１において、外部DDR2−SDRAM１０に格納する際に、動画像データ圧縮伸張処理部５２と比較して、より簡易なデータ圧縮技術を用いて画像データ量を削減することにより、SDRAM１０へのデータアクセス量（以下バンド幅と呼ぶ）を削減する回路を内部に設ける。
本内部回路の構成については、たとえば特許文献１における図１の１３、および１７に記載のデータ圧縮回路およびデータ伸張回路を用いて実現可能である。本回路部の詳細については、前記した特許文献１の回路を活用するものとして、詳細説明は省略する。

【0013】

本実施例においては、上記DDR2−SDRAM１０に画像データを格納するためのデータ圧縮回路およびデータ伸張回路を、データ変換部５１として示す。本データ変換部５１では、データを可逆圧縮もしくは非可逆圧縮を施すことで、そのデータ量を削減することが出来る。
また非可逆圧縮については、その圧縮率が最も悪化する場合の最悪圧縮率をあらかじめ設定することにより、データ変換後のデータ量のワーストケースが規定できるものとする。本回路には、データの所定の画素数分入力され、たとえば元のデータ量の４０〜６０％程度のデータ量に圧縮されたデータが出力されるようなデータ圧縮を想定する。

【0014】

この場合、圧縮されたデータは、ビット単位で連続して詰めたデータとして、出力される。一般にSDRAMへのアクセスは、バーストアクセスを行うことが効率よく、たとえばバースト長８、ＳＤＲＡＭのビット幅６４ｂｉｔの場合、１単位６４ｂｉｔ×８＝５１２ｂｉｔを一つのバーストとして連続的にＳＤＲＡＭにアクセスする。従って、４単位分２０４８ｂｉｔの原画が入った段階で、６０％にデータ量が連続して圧縮される場合には、この５１２ｂｉｔは４単位分で約１２２９ｂｉｔ程度になるため、約３単位のデータに収めて出力することが出来る。
ここで、原画の書き込み時と読み出し時で、効率よく読むためのデータアクセス順序が異なる場合がある。たとえば本実施例では、入力はライン走査で入力されるが、出力は、H.264で一般的であるＭＢ（マクロブロック）単位のアクセスとなる。このため、本実施例では、次に説明するような方法でアクセスする。
原画像の場合、走査線方向に入力されたデータは、逐次ロスレスもしくはロッシー圧縮変換がデータ変換回路部５１において施され、DDR2−SDRAM１０に格納される。

【0015】

図２は、一実施例におけるラインアクセスとブロックアクセスの変換の説明図であり、３００は、ライン単位で原画が入力される様子を示す。また、３０１に示す範囲（前記の例では１単位、５１２ｂｉｔに相当）ごとに、バーストアクセスでデータ変換部５１にデータが出力される。このとき、各バーストは、データ変換５１においてデータの圧縮変換がかかる。
たとえば、３０１の分のデータは、３０２のように通常、元のバーストデータ数以下の範囲に収まる。また圧縮されたデータは、ビット単位で詰められ、バースト長分データ変換部５１に保持できた段階で、そのつどＳＤＲＡＭアクセスコントローラ９に転送される。転送されたデータは、最終的にDDR2−SDRAM１０に格納される。例として、３００におけるハッチング部分のＬｉｎｅ２は、データ変換されDDR2−SDRAM１０中の３０３のハッチング部分に格納されることになる。

【0016】

次に、動画圧縮のために原画像としてデータを読み出す場合は、動画像圧縮伸張処理部５２は、ＭＢ単位で原画像のデータをデータ変換部５１に要求する。
データ変換部５１は、DDR2−SDRAM１０からデータを読む際に、３０４に示すように、先ずＭＢ０のＬｉｎｅ０から１５までのデータを読む。次いでＭＢ１、ＭＢ２、・・・と順番にＭＢ単位でＬｉｎｅ０から１５までのデータを読む。なお、各ＭＢのサイズは非圧縮時のデータ量に応じて決まっている。このため、３０４に示すように例えばデータ圧縮後のＭＢ０を読む際には、非圧縮時のＭＢ１、さらにはＭＢ２に属するデータの一部も読むこととなる。
データ変換部５１は、それぞれのラインのデータに逆変換（伸張）をかける。
もし、そのバースト長に、所望のＭＢ（非圧縮時）のラインデータがある場合には、既に読んだ次のＭＢ部分（３０４におけるハッチングのない部分）のデータを保持する。ＭＢ０のデータを読むために読むバースト部分は太枠で囲った３０４の部分のＬｉｎｅ０〜１５の位置であり、実際にＭＢ０（非圧縮時）のデータが格納されている箇所はハッチングをかけた箇所となる。

【0017】

各ハッチング部分は、順次３０５に示すように、データ変換部５１内で逆変換され、元のＭＢ０の分のデータとして、動画像圧縮伸張処理部５２に渡される。
ＭＢ０におけるＭＢ１（非圧縮時）以降のデータは、次のデータ逆変換のためにデータ変換部５１内で保持される。
また、ＭＢ１，２と引き続き処理が行われるが、各Ｌｉｎｅのデータは保持されたデータに逆変換をかけ、もし続きのデータが必要になる場合には、続きのバーストが読まれる。
もし、必要にならない場合には、次のデータをリードしない。

【0018】

各Ｌｉｎｅのデータがどれぐらいのデータ量に圧縮されるかは、入力された画像依存となり、各ラインを読み進めるうちに、更新すべきバースト位置は異なる。たとえば、ＭＢ２（非圧縮時）のデータを読む際のバーストリード位置と実際のデータ位置は３０６の太枠で囲った位置とハッチングのかかった位置になり、データ逆変換された後、動画像圧縮伸張処理部５２に渡される部分は、３０７のようになる。
もし、ライト時とリード時で同じアドレス順序でアクセスする場合、一度読んだデータを破棄しないように、ＭＢの縦幅×ライン幅の分のデータバッファを持ち、ラインごとにリードし、１６ライン分たまった段階で、ＭＢ０、ＭＢ１、ＭＢ２と順次データを逆変換かける必要があり、相当数リードデータを格納するバッファが必要なる。一方、本実施例の方法でアドレス順序の変更をかける場合には、ＭＢ１個分のバーストバッファと、途中のアクセスしているビット位置を保持してバーストの境界を記憶するためのバッファ程度で回路が組め、コスト増加を抑制できるという利点を持つ。

【0019】

同じく、本実施例のデータ変換回路５１を介して、動画像圧縮伸張処理部５２は、参照画像のライトおよびリードを行う。この場合、基本的にライト、リードともにＭＢ単位のデータアクセスになる。このため、各々ＭＢのデータごとに連続でデータ変換をかけ、ＭＢごとに本来格納するエリアに、ライト・リードしても効率的にとくに支障にならない。
次に、図２とは異なる実施例を説明する。
図３は、一実施例におけるブロックアクセスのリードライトアクセスの説明図である。ライト時には図３の４０１のＭＢ０を４０２に示したように、ハッチングの部分に圧縮をかけて、保持していき、太枠で囲ったバースト単位ごとにアクセスしても良い。
最後に動画像圧縮されて生成されたストリームデータは、ロッシー圧縮技術を用いると、データが復号不可能になり、ロスレス圧縮をかけてもほとんどバンド幅圧縮の効果が無いため、データ圧縮は行わずスルーしてDDR2−SDRAM１０にデータを書き込む。

【0020】

次に、伸張時の動作について説明する。ストリーム入出力端子８経由で外部メモリから読まれたストリームは、データ変換部５１においては、データは変換処理されることなく、動画像圧縮伸張処理部５２に出力される。入力されたストリームは可変長符号化が解かれ、各フレームの復号画像が生成される。各復号画像は、その他の画像の参照画像として使用され、また最終的にビデオＩＦ３を経由して、ライン単位で出力される。このため、先ほどの例では参照画像はブロックアクセス処理して得られたが、本例の動画伸張時には、図２の原画領域と同様にライン単位でデータライトされ、参照画像を参照する際にはブロックとしてリードされる。また、ビデオＩＦ３がリードを必要とする場合には、ライン方向にそのまま読み出すという処理に変更される。

【0021】

以上のように、同じ参照画像領域でも、用途に応じて、データ変換された画像のアドレッシング順序を変更できる構成を持つことにより、各々の処理に必要なバッファのコストを削減しつつ回路を実現し、バンド幅を削減することが可能となる。
一般に動画像の画像処理LSIにおいては、図１に示すように、動画像圧縮伸張回路５のほかに、システム管理を行うホストＣＰＵ６や、その他入力画像の画像処理を行う画像処理部４を含む複数の処理ブロックが、同一のSDRAM１０へデータアクセスを行う。
図４は、一実施例におけるSDRAM１０のデータ割当の例を示す。前記した事情により、メモリコントローラへのアクセス量が非常に多くなる。従い、たとえば内部バスの線数を増やす必要が生じ、また、システムクロックを引き上げる要因となる。これは結果としてシステムのチップ面積の増加を招き、消費電力を増加させることになる。従って、安価にLSIを実現する上での課題となる。本実施例は、当該の課題に対する解決方法を提供することができる。

【0022】

また、本実施例におけるデータ変換回路５１はロスレス、ロッシーの切り替え機能を有する。ロスレス圧縮時には、画像の劣化は起きないが、バンド幅の削減率は扱う絵柄に応じて大きく変動するため、システム設計が難しくなる。逆にロッシーの場合には、圧縮率を確定し、その中でシステム設計できる一方で、画像の劣化が生じるため、使用用途に制限がかかる。本実施例では、例えば処理する画像に応じてロスレス、ロッシーの切り替えをすることにより、当該の課題に対する解決方法を提供することができる。
図５は、一実施例におけるロスレス圧縮とロッシー圧縮の切り替えの組み合わせを示す図である。図５に示すように、本実施例では動作モードを指定し、その動作モードとフレームごとに、データアクセス時にロスレスかロッシーかを指定する。これにより、ユーザの要求に対して、最適な画質とバンド幅削減効果のバランスを取ることが可能となる。
データ変換回路部５１で処理するデータ変換処理により、SDRAMアクセスコントローラ９とのデータアクセス量を削減することができ、結果としてシステムのコストを下げ、消費電力を下げるという効果が得られる。

【0023】

本発明の実施例では、まずH.264/AVC（ISO/IEC14496−10）に従って、Full HDの解像度の画像を圧縮伸張することを想定する。特に上記実施例では、H.264の規格に準拠した圧縮伸張処理を想定したが、他のMPEG１，２，４などフレーム間予測を行うような処理においても本発明が有効であることは明らかである。
上記、実施例でのデータアクセス方法に限らず、リード時とライト時で、他のブロックのＩＦの兼ね合いで、ブロック方向のアクセスと、ライン方向のアクセスの組み合わせを変更し、また、連続して格納するメモリの領域、サイズを変更しても同様の効果を得られることは明らかである。

【符号の説明】

【0024】

１…画像処理システムＬＳＩ、２…画像入力端子、３…ビデオＩＦ、４…画像処理部、５…動画像圧縮伸張装置、６…ホストＣＰＵ、７…ストリームＩＦ、８…ストリーム入出力端子、９…SDRAMアクセスコントローラ、１０…DDR2−SDRAM、１１…映像出力端子。

【図1】

【図2】

【図3】

【図4】

【図5】