JP5227875B2

JP5227875B2 - 動画像符号化装置

Info

Publication number: JP5227875B2
Application number: JP2009092009A
Authority: JP
Inventors: 貴記松下; 博樹溝添; スティアワンボンダン
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2009-04-06
Filing date: 2009-04-06
Publication date: 2013-07-03
Anticipated expiration: 2029-04-06
Also published as: CN101860751A; US20100254456A1; JP2010245822A

Description

本発明は動画像符号化装置および動画像符号化方法に係り、特にテレビ電話やテレビ会議などリアルタイム映像音声通信システムに利用する際に、遅延を低減し、またデータのアンダーフローを防ぐ動画像符号化装置および動画像符号化方法に関するものである。

近年、映像圧縮技術の発達や通信回線の発達に伴い、テレビ電話やテレビ会議などの映像音声通信装置が普及している。また、携帯電話などのモバイル製品にもリアルタイム映像音声通信を行える機能が搭載されてきている。
一方で、撮像技術、圧縮技術の進歩により、ＨＤ（High Definition）映像を撮影できるカメラ製品が市場に登場してきており、ＨＤ画質のリアルタイム映像音声通信も期待されている。しかし、ＨＤ映像によるリアルタイム映像音声通信はデータ量の増大により、二地点間での遅延が増大し、双方でのコミュニケーションが円滑に進まないという問題がある。

前記の映像音声通信遅延を低減する動画像符号化装置として、特許文献１や特許文献２が挙げられる。
特許文献１では、受信側において復号誤りが検出された場合に発行される画面更新要求を送信側が受付け、送信バッファのデータをクリアし、遅延を低減する。また、直後の入力動画はフレーム内処理によってイントラ符号化することにより、再び受信側で復号誤りを起こすことを防いでいる。
特許文献２では、より簡単なロジックによって、送信側のみで遅延を低減する。すなわち送信バッファを監視し、一定量以上の蓄積データがある場合には、入力動画のイントラ符号化を行った後に、送信バッファ内のデータをクリアする。これにより受信側での遅延を低減し、復号誤りの発生を防ぐ。

特開平７−１９３８２１号公報特開２００６−８０７８８号公報

特許文献１、特許文献２によって遅延を低減し、かつ受信側での復号誤りを無くすことが出来る。
しかしながら、特許文献１では、符号化データのクリア処理から次の動画の符号化データ完成までに要する時間を予測した上で、最低限送信に必要な符号化データを送信バッファ内に残しておかなければならない。この場合、正確なバッファ内符号化データの送信タイミングの予測が困難なことから、バッファ内部符号化データの残余量の最適値と実際値との差異によって、送信バッファ内部のアンダーフローが生じる可能性がある。

また、特許文献２では、イントラ符号化の終了を待ってから送信データのクリアを行うため、遅延低減のタイミングが遅れることがある。
また、一般的に映像音声通信を行う場合、映像と音声は例えばＴＳ（Transport Stream）やＰＳ（Program Stream）などのフォーマットに多重化されて送信される。特許文献１及び特許文献２はともに、ピクチャ単位（Ｉピクチャ；Intra Picture、Ｐピクチャ；Predictive Picture、Ｂピクチャ；Bi-directionally Predictive Picture）の境界は考慮しているが、ＴＳやＰＳといったＭＰＥＧ（Moving Picture Experts Group）システム層のパケット境界を意識せずに送信バッファ内のデータをクリアするため、受信側の復号化装置によっては受信ストリームのパケット境界がずれてしまい、復号誤りが発生する可能性がある。

本発明の目的は以上の点に鑑み、遅延を低減し、またデータのアンダーフローを防ぐ動画像符号化装置および動画像符号化方法を提供することにある。また、受信側の動画像復号装置における復号可能入力フォーマットの制約に従い、復号誤りの少ない動画像符号化装置および動画像符号化方法を提供することにある。

前記の目的を達成するため本発明は、動画像を符号化する動画像符号化装置であって、被写体を撮影して前記動画像を生成する撮像部と、前記動画像のデータ量を圧縮する圧縮回路と、該圧縮回路から供給される前記動画像の圧縮データを蓄積するストリームバッファと、該ストリームバッファに蓄積された前記動画像の圧縮データをネットワークへ送信する通信回路と、前記動画像符号化装置を動作制御するシステム制御部を有し、該システム制御部は、前記ストリームバッファに蓄積された圧縮データの蓄積量が所定の閾値以上である場合には、前記圧縮データの前記ストリームバッファからの読み出し位置を、時間軸上で先に進めるように制御することを特徴としている。

また本発明は、動画像を符号化する動画像符号化方法であって、被写体を撮影して前記動画像を生成する撮像ステップと、前記動画像のデータ量を圧縮する圧縮ステップと、該圧縮ステップで生成された前記動画像の圧縮データを蓄積する蓄積ステップと、該蓄積ステップで蓄積された前記動画像の圧縮データをネットワークへ送信する通信ステップと、前記圧縮ステップと蓄積ステップと通信ステップを制御するシステム制御ステップを有し、該システム制御ステップは、前記蓄積ステップで蓄積された前記動画像の圧縮データの蓄積量が所定の閾値以上であるか否かを判定する蓄積量判定ステップを有し、該蓄積量判定ステップでの判定の結果、前記蓄積ステップで蓄積された前記動画像の圧縮データの蓄積量が所定の閾値以上であると判定された場合には、前記圧縮データの前記蓄積ステップからの読み出し位置を、時間軸上で先に進めるように制御することを特徴としている。

本発明によれば、遅延を低減した動画像符号化装置および動画像符号化方法を提供できる。ある実施形態においては、データのアンダーフローを防止した動画像符号化装置および動画像符号化方法を提供できる。別な実施形態においては、受信側の動画像復号装置における復号誤りの少ない動画像符号化装置および動画像符号化方法を提供できる。いずれの場合も、テレビ電話やテレビ会議のシステムで使い勝手を向上できるという効果がある。

本発明の一実施例を示す符号化装置のハード構成図である。実施例１の符号化装置全体のフローチャートである。実施例１の符号化装置の圧縮工程に関するフローチャートである。実施例１の符号化装置のネットワーク送信工程に関するフローチャートである。実施例２の符号化装置のネットワーク送信工程に関するフローチャートである。実施例２の符号化装置の補正サイズ計算方法である。ＯｐｅｎＧＯＰとＣｌｏｓｅｄＧＯＰの概念図である。実施例３の符号化装置のネットワーク送信工程に関するフローチャートである。実施例４の符号化装置の圧縮工程に関するフローチャートである。実施例４の符号化装置のネットワーク送信工程に関するフローチャートである。

以下、本発明の実施例を、図１〜図１０を用いて詳細に説明する。
図１は本発明の一実施例を示す符号化装置１００のハードウェア構成図であり、以下で示す実施例１から実施例４において適用可能である。図１に示すように、レンズ１０１、撮像素子１０２、カメラＤＳＰ（Digital Signal Processor）１０３、マイク１０４、映像圧縮回路１０５、音声圧縮回路１０６、映像音声多重回路１０７、ストリームバッファ１０８、通信回路１０９、通信入出力端子１１０、システム制御部１１１を備えている。

リアルタイム映像音声通信では、リモートに存在する復号装置から開始要求が発行され、符号化装置はその要求を受信し処理を開始する。映像を送信する符号化装置１００はまずレンズ１０１から入力される光信号を、撮像素子１０２において電気信号へ変換し、アナログ電気信号をデジタル信号に変換する。カメラＤＳＰ１０３は、撮像素子１０２から入力される映像信号を映像圧縮回路１０５に入力できる形式に変換する。マイク１０４からの音声入力信号は音声圧縮回路１０６に入力される。映像圧縮回路１０５で圧縮された映像エレメンタリーストリームと音声圧縮回路１０６で圧縮された音声エレメンタリーストリームは映像音声多重回路１０７によってＴＳやＰＳなどのフォーマットにパケット化され、ストリームバッファ１０８へ蓄積される。通信回路１０９は外部機器との通信を行う回路であり、ストリームバッファ１０８に蓄積されたコンテンツをネットワークへ送信する。外部との通信は、入出力端子１１０とインターネットなどのネットワークを介して行うことができる。システム制御部１１１は符号化装置１００のシステム全体を制御する。具体的にはカメラＤＳＰ１０３、映像圧縮回路１０５、音声圧縮回路１０６、映像音声多重回路１０７、ストリームバッファ１０８、通信回路１０９を制御することによってリアルタイム映像音声通信システムの送信側処理を実行する。

ストリームバッファ１０８はＲＡＭ（Random Access Memory）を用い、パケット化されたストリームを蓄積する。通信回路１０９は無線用回路でも有線用回路でも良いが、無線であれば通信入出力端子１１０は省略可能である。送受信するデータは圧縮した映像音声ストリームであるが、他にもファイル転送プロトコルなどの各種コマンドを送受信することが出来る。システム制御部１１１は主にＣＰＵ（Central Processing Unit）やフラッシュメモリで構成され、あらかじめフラッシュメモリに格納されているプログラムをＣＰＵがロードして実行する。

本発明の一実施例を、図２〜４を用いて説明する。図２は本実施例における、符号化からネットワーク送信に到る符号化装置全体のフローチャートである。ステップＳ２００では、符号化装置１００の通信回路１０９がリモートに存在する復号装置からの送信開始要求を受け付ける。送信開始要求が受け付けられると、これに応じてシステム制御部１１１は前記各構成要素を制御して、ステップＳ２０１の撮像工程を実行する。符号化装置１００は符号化対象となる動画を撮像し、映像圧縮回路１０５に入力する。具体的には撮像工程Ｓ２０１では、レンズ１０１で取り込まれた光信号は撮像素子１０２において電気信号へ変換され、カメラＤＳＰ１０３によって映像圧縮回路１０５に入力できる形式に変換されて、映像圧縮回路１０５に供給される。また、マイク１０４で採取された音声情報も音声圧縮回路１０６へ供給される。

次にステップＳ２０２の圧縮工程にて、撮像工程Ｓ２０１によって生成された入力動画および入力音声を符号化する。映像の符号化の種類にはＭＰＥＧ２（ISO/IEC 13818）やＭＰＥＧ４ＡＶＣ／Ｈ．２６４（ISO/IEC 14496-10）等が利用される。また、音声の符号化にはＡＡＣ（Advanced Audio Coding）やＡＣ３（Dolby-Digital Audio Code number 3）等が利用される。但し、前記以外の符号化方式でも要求元の復号装置でサポートされている符号化方式であれば使用可能である。具体的には映像圧縮回路１０５で符号化された映像データと、音声圧縮回路１０６で符号化された音声データは、映像音声多重回路１０７で多重化された後、ストリームバッファ１０８に蓄積される。

圧縮工程Ｓ２０２が終了すると、ステップＳ２０３のネットワーク送信工程が実行される。ネットワーク送信工程Ｓ２０３では、ストリームバッファ１０８に蓄積された圧縮ストリームは、通信回路１０９を用いて復号装置（図示せず）へ送信される。
ネットワーク送信工程Ｓ２０３の実行が終わるとステップＳ２０４では、復号装置から送信停止要求を受信しているか否かを判定し、受信していなければ（図中のＮｏ）、ステップＳ２０１の撮像工程から処理を繰り返す。また、送信停止要求を受信している場合は（図中のＹｅｓ）、処理を終了する。

図３は、実施例１におけるステップＳ２０２の圧縮工程を詳細に説明したフローチャートである。ここでは、前記した送信バッファ内部のアンダーフローを防ぐことに特徴がある。
ステップＳ３００では撮像工程Ｓ２０１によって生成された入力映像信号と音声信号を、映像圧縮回路１０５と音声圧縮回路１０６で符号化する。符号化はピクチャ単位で行う。ステップＳ３０１では、システム制御部１１１は直前に符号化したピクチャ種別がＩピクチャか否かを判定する。Ｉピクチャか否かの判定は圧縮ストリーム中のピクチャ種別を表す情報から判定しても良いし、ＩピクチャはＧＯＰ（Group Of Picture）の先頭であることから、ピクチャ枚数を数えることで判定しても良い。Ｉピクチャの符号化であると判定された場合には（図中のＹｅｓ）、ステップＳ３０２においてシステム制御部１１１は、Ｉピクチャの先頭位置を記憶し、ステップＳ３０３に遷移する。

ステップＳ３０１にて直前に符号化したピクチャ種類がＩピクチャではないと判定された場合には（図中のＮｏ）、ステップＳ３０３の処理に遷移する。ステップＳ３０３ではシステム制御部１１１は、符号化終了したストリームデータサイズが復号装置から要求された送信サイズを超えているか否かを判定する。要求された送信サイズを越えている場合には（図中のＹｅｓ）、ステップＳ２０２の圧縮工程を終了し、ステップＳ２０３のネットワーク送信工程に遷移する。要求された送信サイズを越えていない場合には（図中のＮｏ）、ステップＳ３００へ遷移し、次のピクチャの符号化処理を繰り返す。なお、要求された送信サイズを越えていない場合にも、ステップS２０３のネットワーク送信工程は実行される。

このようにデータサイズを復号装置から要求される送信サイズと比較して、後者よりも量の多いデータをストリームバッファ１０８に蓄積することにより、ストリームバッファ１０８のアンダーフローを確実に防ぐことが出来る。なお、復号装置から要求される送信サイズとは、十から数十ｋバイト程度のことが多い。

図４は実施例１におけるステップＳ２０３のネットワーク送信工程を詳細に説明したフローチャートである。ここでは、前記した遅延の低減をすることに特徴がある。
ステップＳ４００ではシステム制御部１１１は、ストリームバッファ１０８に蓄積されたストリームデータサイズが、所定の閾値を超えたか否かを判定する。閾値はシステム設計者が最適な値を設定しても良いし、ユーザが設定しても良い。一般的にＨＤ画質のＴＳストリームのビットレートは１０Ｍｂｐｓ〜２５Ｍｂｐｓの範囲であり、１ＧＯＰ当たり６４０ｋバイト〜１．６Ｍバイト程度の符号量が発生する。１ＧＯＰは０．５秒なので、符号化装置の遅延を０．５秒以内抑える必要があるならば、５００ｋバイト程度に設定するべきである。

ステップＳ４００で閾値を超えていないと判定された場合には（図中のＮｏ）、通信が順調に進行しており遅延が発生する可能性は小さいため、ステップＳ４０３に遷移し、通信回路１０９は蓄積データを順次ネットワークへ送信する。閾値を超えていると判定され場合には（図中のＹｅｓ）、遅延が発生する可能性は大きいため、ステップＳ４０１に遷移し、システム制御部１１１は図３のステップＳ３０２において記憶したＩピクチャ先頭位置が、未送信データ領域に存在するか否かを判定する。未送信データ領域とは、通信回路１０９がストリームバッファ１０８に蓄積されたストリームデータを読み出す位置と、映像音声多重回路１０７がストリームバッファ１０８へ書き込む位置との間にあるデータ領域のことである。ステップＳ４０１において、Ｉピクチャ先頭位置が未送信データ領域に存在すると判定した場合には（図中のＹｅｓ）、ステップＳ４０２において、システム制御部１１１はＩピクチャ先頭位置を次の読み出し位置に設定したうえで、ステップＳ４０３において、通信回路１０９はストリームバッファ１０８の蓄積データをネットワークへ送信する。Ｉピクチャ先頭位置が未送信データ領域に存在しないと判定された場合には（図中のＮｏ）、ステップＳ４０３へ遷移し、通信回路１０９はストリームバッファ１０８の蓄積データを順次ネットワークへ送信する。

なお、ストリームバッファ１０８の蓄積データにＩピクチャが複数存在する場合には、最も新しく蓄積されたＩピクチャ、すなわち時間軸上で最も後ろのＩピクチャを次の読み出し位置に設定すると良い。これにより遅延を低減する効果を大きくすることができる。
このように、ストリームバッファ１０８における蓄積データが、所定の閾値を超えていて遅延が問題となる場合には、送信回路１０９はＩフレームまで読み出し位置をジャンプして送信することにより、遅延を低減するようにしている。

図３に示した圧縮工程Ｓ２０２と、図４に示したネットワーク送信工程Ｓ２０３を組合せた場合に本実施例は、ストリームバッファ１０８の蓄積データが、たとえば１０ｋバイト以下となればデータのアンダーフローを防ぎ、たとえば５００ｋバイト以上となれば遅延を低減するように作用することとなる。

以上、図２〜図４を用いて、本発明の実施例の一つ、リアルタイム映像音声通信での遅延低減の例を示した。これにより、ネットワーク環境などの外的な要因で発生した遅延を、符号化装置側で待ち時間無く低減することが出来る。また、ストリームバッファ１０８の読み出し位置をＩピクチャ境界にジャンプさせることによって、データ受信の遅延による復号装置側での映像の乱れを、最小限に抑えることが出来るという利点がある。さらに、Ｓ２０２の圧縮工程では復号装置から要求されたサイズがストリームバッファ上に存在するかどうかを確認するために、アンダーフローが発生しないという利点がある。

次に図５と図６を用いて、Ｓ２０３のネットワーク送信工程における実施例１とは別な遅延低減方法を説明する。
一般的にＴＶ電話装置やＴＶ会議システムでは、映像と音声それぞれのエレメンタリーストリームは映像音声多重回路１０７のような多重化部によってＴＳやＰＳなどへ多重化されて、ネットワークへ送信される。ＴＳやＰＳはそれぞれ決まったパケットサイズ（ＴＳは１９２バイト、ＰＳは２０４８バイト）の連続であり、また、パケットサイズは映像や音声のフレームサイズとは関係がない。

また、復号装置側は一般的にＴＳ形式やＰＳ形式にパケット化されたストリームを映像及び音声のエレメンタリーストリームへ分離してから復号する。したがって、復号装置によっては映像音声分離回路に正常なストリームが入力されなければ、正常な分離処理が出来ず、破綻してしまう可能性がある。つまり、復号装置によってはパケット境界の周期が一定でないストリームが入力されると、映像音声の分離が正常にできなくなる可能性がある。
実施例１による遅延低減方法を復号装置によらず有効にするためには、パケット境界の周期に合わせて読み出し位置をジャンプさせる必要がある。

図５は図４のネットワーク送信工程Ｓ２０３の処理にパケット境界の条件を加えた例である。ステップＳ５００において、前回のネットワーク送信工程までに送信したストリームデータサイズとパケットサイズから、パケット境界位置までの補正サイズを計算する。この補正サイズの意味と計算方法については、後に図６を用いて説明する。続いて、ステップＳ５０１にてシステム制御部１１１は、ストリームバッファ１０８に蓄積されたストリームデータサイズが所定の閾値を超えたか否かを判定する。閾値は図４のステップＳ４００と同様にシステム設計者が最適な値を設定しても良いし、ユーザが設定しても良い。閾値を超えていない場合には（図中のＮｏ）、遅延が発生する可能性は小さいためステップＳ５０４に遷移し、通信回路１０９はストリームバッファ１０８の蓄積データを順次ネットワークへ送信する。閾値を超えている場合には（図中のＹｅｓ）、遅延が発生する可能性は大きいためステップＳ５０２に遷移し、システム制御部１１１は図３のステップＳ３０２において記憶したＩピクチャ先頭位置からステップＳ５００で計算した補正サイズを引いて求めた位置（以下、Ｉピクチャ先頭補正位置と称する）が、未送信データ領域に存在するか否かを判定する。ステップＳ５０２において、Ｉピクチャ先頭補正位置が未送信データ領域に存在する場合には（図中のＹｅｓ）、ステップＳ５０３において、システム制御部１１１はＩピクチャ先頭補正位置を次の読み出し位置に設定し、ステップＳ５０４において、通信回路１０９はストリームバッファ１０８の蓄積データをネットワークへ送信する。ステップＳ５０２でＩピクチャ先頭補正位置が未送信データ領域に存在しない場合には（図中のＮｏ）、ステップＳ５０４へ遷移し、ストリームバッファ１０８の蓄積データを順次ネットワークへ送信する。

図６は補正サイズの計算方法をタイムスタンプ付きＴＳに適用した例を示す図である。ここで図中の送信済と記した部分のパケットを前回送信したとする。タイムスタンプ付きＴＳのパケットサイズは１９２バイトであるが、復号装置から要求される送信サイズはＴＳパケットサイズと無関係である。したがい図示するように、最後のパケットの途中で送信が終了する場合がある。ストリームバッファ１０８のデータサイズが所定の閾値よりも小さく、遅延が問題とならない場合には、次の送信では前回送信を終了したパケットの途中から順次送信するので、復号装置で復号誤りが起こる問題はない。

しかし、ストリームバッファ１０８のデータサイズが所定の閾値よりも大きく、遅延が問題となる場合に、次のＩピクチャ先頭位置を開始位置として送信を開始すると、次の問題がある。図６でＩピクチャ先頭位置と記した場所に次のＩピクチャがあったとする。Ｉピクチャはパケットの先頭にある。このためパケット境界の周期が所定値からずれることとなり、復号装置での復号誤りを起こすことがある。
復号装置から要求される送信サイズとパケットサイズから、前回送信を終了した位置を知ることができる。この位置と次のパケット境界との差を求めて、図示する補正サイズ（斜め縞部分）を求める。Ｉピクチャ先頭位置から補正サイズだけ前の位置をＩピクチャ先頭補正位置とし、これを次の送信の開始位置とすれば、パケット境界の周期は変わることない。このため前記した復号誤りの問題は解消できる。なおこの時には、ストリームバッファ１０８からの圧縮データの読み出し位置は、パケットサイズの整数倍だけシフトすることになる。

復号装置から要求される送信サイズが常にパケットサイズの倍数サイズであれば、この補正サイズは常に０となる。しかし、復号装置から要求される送信サイズがパケットサイズの倍数でない場合は、パケット境界がずれる。従って、図５のステップＳ５００ではシステム制御部１１１は、送信の際に毎回補正サイズを計算する。尚、図６の例はＴＳを例にして説明したが、ＰＳであっても、その他のパケッタイズ方式であっても同様に補正サイズを計算することにより、復号誤りは回避可能である。

以上、図５、６を用いて、遅延削減の為の読み出し位置ジャンプの際に、パケット境界を考慮してジャンプする例を示した。以上により、パケット境界を考慮しない不正なストリームを入力すると破綻するような復号装置で受信される場合においても、正常に遅延削減処理を実行することが出来る。

次に図７と図８を用いて、復号装置における復号誤りを防ぐことのできる、さらに別な実施例について説明する。
ＭＰＥＧ２やＭＰＥＧ４ＡＶＣ／Ｈ．２６４といった映像圧縮規格では、ＯｐｅｎＧＯＰとＣｌｏｓｅｄＧＯＰの２つのＧＯＰ構成がある。図７において、（ａ）はＯｐｅｎＧＯＰ、（ｂ）はＣｌｏｓｅｄＧＯＰの例を示す。ＯｐｅｎＧＯＰのビットストリーム構成は、図７（ａ）の７００のような並びであり、これを受信する復号装置では７０１に示す順番でデコードされる。デコード時に各ピクチャは２ピクチャずつ後ろにシフトするが、ＧＯＰ境界は変わらない。このため７０１のＧＯＰ境界において、後ろのＧＯＰ先頭のＢピクチャは直前のＧＯＰの末尾Ｐピクチャを参照して復号される。つまり、ＯｐｅｎＧＯＰとは直前のＧＯＰのピクチャを参照画像とするＢピクチャを持つＧＯＰである。

一般的にストリームの分割編集などはＧＯＰ単位で行うことが多いが、ＯｐｅｎＧＯＰの場合、前記したＢピクチャの影響で、ＧＯＰ境界の後のストリームを先頭から復号しようとすると復号装置によっては復号誤りを起こす可能性があるため、ブロークンリンクフラグを設定する。ブロークンリンクフラグとは、ＯＰＥＮＧＯＰでは前のＧＯＰを参照するＢピクチャを無視するように指示するフラグである。したがいブロークンリンクフラグを設定したストリームは復号装置に対して、対象のピクチャを復号しなくても良いことを通知することが出来る。なお、ブロークンリクフラグはＭＰＥＧ２の場合、ＭＰＥＧビデオ層のＧＯＰヘッダー内で設定できる。また、ＭＰＥＧ４ＡＶＣ／Ｈ．２６４の場合は、ＮＡＬ（Network Abstraction Layer）ユニットのＳＥＩ（Supplemental Enhancement Information）に設定できる。

一方、ＣｌｏｓｅｄＧＯＰは図７（ｂ）の７０２のようなビットストリーム構成をとり、これを受信した復号装置では７０３に示すような順番でデコードされる。デコード時には各ピクチャは１ピクチャずつ後ろにシフトするが、ＧＯＰ境界も同様にシフトするので、相対的な関係は変わらない。ここでは図面の煩雑化を避けるために、Ｂピクチャがない場合で示したが、これが存在するＣｌｏｓｅｄＧＯＰもある。この場合、後半のＧＯＰには直前のＧＯＰを参照するピクチャが無い。なお、ＩピクチャとＰピクチャのみのＧＯＰ構造の場合は、必ずＣｌｏｓｅｄＧＯＰのストリームとなる。
以上より、実施例１及び実施例２で示した、読み出し位置ジャンプ手段及びパケット境界ジャンプ手段は、ジャンプ直後に読み出すＧＯＰがＯｐｅｎＧＯＰである場合には復号装置側で復号誤りを起こす可能性がある。この問題の回避策を、図８のフローチャートを用いて説明する。

図８は実施例３におけるステップＳ２０３ネットワーク送信工程を詳細に説明したフローチャートである。ステップＳ８００では、システム制御部１１１はストリームバッファ１０８に蓄積されたストリームデータサイズが所定の閾値を超えたか否かを判定する。閾値は図４と同様、システム設計者が最適な値を設定しても良いし、ユーザが設定しても良い。閾値を超えていない場合は（図中のＮｏ）、遅延が発生する可能性は小さいので、ステップＳ８０４に遷移し、通信回路１０９はストリームバッファ１０８の蓄積データを順次ネットワークへ送信する。閾値を超えている場合は、遅延が発生する可能性は大きいためステップＳ８０１に遷移し、システム制御部１１１は図３のステップＳ３０２において記憶したＩピクチャ先頭位置（またはＩピクチャ先頭補正位置）が未送信データ領域に存在するか否かを判定する。ステップＳ８０１において、Ｉピクチャ先頭位置（またはＩピクチャ先頭補正位置）が未送信データ領域に存在する場合には（図中のＹｅｓ）、ステップＳ８０２において、システム制御部１１１はＩピクチャ先頭位置（またはＩピクチャ先頭補正位置）を次の読み出し位置に設定する。続いてステップＳ８０３において、システム制御部１１１は前記ブロークンリンクフラグを設定し、ステップＳ８０４に遷移する。ステップＳ８０４では、読み出し位置から蓄積データを読み出し、ネットワークへ送信する。ステップＳ８０１においてＩピクチャ先頭位置（またはＩピクチャ先頭補正位置）が未送信データ領域に存在しない場合は、ステップＳ８０４へ遷移し、通信回路１０９は蓄積データを順次ネットワークへ送信する。

以上、図７と図８を用いて、実施例３におけるブロークンリンクフラグ設定方法を示した。これにより、遅延低減のために読み出し位置をジャンプさせた位置がＯｐｅｎＧＯＰである場合でも、復号装置側での復号誤り発生を防ぐことが出来る。

次に図９と図１０を用いて、復号装置における復号誤りを防ぐことのできる、さらに別な実施例について説明する。
実施例３では、ブロークンリンクフラグを設定することにより、読み出し位置ジャンプ後の復号誤りを回避しているが、送信直前にエンコードしたストリームを編集する必要があるため、符号化装置の負荷が若干大きくなる。そこで実施例４では、Ｉピクチャ先頭位置（またはＩピクチャ先頭補正位置）へ読み出し位置ジャンプ後、復号が不必要なピクチャがある場合には、さらに読み出し位置をジャンプする。

図９は、実施例４におけるステップＳ２０２の圧縮工程を詳細に説明したフローチャートである。ステップＳ９００では映像圧縮回路１０５は、撮像工程Ｓ２０１によって生成された入力動画を符号化する。符号化はピクチャ単位で行う。ステップＳ９０１ではシステム制御部１１１は、直前に符号化したピクチャ種別がＩピクチャか否かを判定する。Ｉピクチャであると判定した場合には（図中のＹｅｓ）、ステップＳ９０２においてシステム制御部１１１はＩピクチャの先頭位置を記憶し、ステップＳ９０５に遷移する。ステップＳ９０１にて直前に符号化したピクチャ種別がＩピクチャではないと判定した場合には（図中のＮｏ）、ステップＳ９０３の処理に遷移する。ステップＳ９０３ではシステム制御部１１１は、直前に符号化したピクチャ種別がＧＯＰ内先頭のＰピクチャか否かを判定する。ＧＯＰ内先頭Ｐピクチャであると判定した場合には（図中のＹｅｓ）、ステップＳ９０４においてシステム制御部１１１は、ＧＯＰ内先頭Ｐピクチャの先頭位置を記憶し、ステップＳ９０５に遷移する。ステップＳ９０３にて直前に符号化したピクチャ種別がＧＯＰ内先頭Ｐピクチャではないと判定した場合には（図中のＮｏ）、ステップＳ９０５の処理に遷移する。ステップＳ９０５ではシステム制御部１１１は、符号化終了したストリームデータサイズが復号装置から要求された送信サイズを超えているかどうかを判断する。要求された送信サイズを越えている場合には（図中のＹｅｓ）、Ｓ２０２の圧縮工程を終了し、Ｓ２０３のネットワーク送信工程の処理に遷移する。要求された送信サイズを越えていない場合には（図中のＮｏ）、ステップＳ９００へ遷移し、ピクチャの符号化処理から繰り返す。

図１０は実施例４におけるステップＳ２０３のネットワーク送信工程を詳細に説明したフローチャートである。ステップＳ１０００ではシステム制御部１１１は、ストリームバッファ１０８に蓄積されたストリームデータサイズが所定の閾値を超えたか否かを判定する。閾値は図４と同様に、システム設計者が最適な値を設定しても良いし、ユーザが設定しても良い。閾値を超えていない場合には（図中のＮｏ）遅延が発生する可能性は小さいので、ステップＳ１００６に遷移し、蓄積データを順次ネットワークへ送信する。閾値を超えている場合には（図中のＹｅｓ）遅延が発生する可能性が大きいので、ステップＳ１００１に遷移しシステム制御部１１１は、図９のステップＳ９０２において記憶したＩピクチャ先頭位置（またはＩピクチャ先頭補正位置）が未送信データ領域に存在するか否かを判定する。ステップＳ１００１において、Ｉピクチャ先頭位置（またはＩピクチャ先頭補正位置）が未送信データ領域に存在する場合には（図中のＹｅｓ）、ステップＳ１００２においてシステム制御部１１１は、Ｉピクチャ先頭位置（またはＩピクチャ先頭補正位置）を次の読み出し位置に設定し、ステップＳ１００３へ遷移する。ステップＳ１００３では通信回路１０９は、ストリームバッファ１０８から蓄積データを読み出しＩピクチャのみネットワーク送信を行う。続いてステップＳ１００４においてシステム制御部１１１は、図９のステップＳ９０４において記憶したＧＯＰ内先頭Ｐピクチャ先頭位置（またはＧＯＰ内先頭Ｐピクチャ先頭補正位置）が未送信データ領域に存在するか否かを判定する。ＧＯＰ内先頭Ｐピクチャ（またはＧＯＰ内先頭Ｐピクチャ先頭補正位置）が未送信データ領域に存在する場合には（図中のＹｅｓ）、ステップＳ１００５においてシステム制御部１１１は、ＧＯＰ内先頭Ｐピクチャ先頭位置（またはＧＯＰ内先頭Ｐピクチャ先頭補正位置）を次の読み出し位置に設定し、ステップＳ１００６で通信回路１０９は、ストリームバッファ１０８の蓄積ストリームをネットワーク送信する。このためＧＯＰの先頭にＢピクチャがある場合には、これを無視して復号することができ、前記したＯＰＥＮＧＯＰにおける復号の誤りを解消することができる。

ステップＳ１００１において、Ｉピクチャ先頭位置（またはＩピクチャ先頭補正位置）が未送信データ領域に存在しない場合には（図中のＮｏ）、ステップＳ１００６へ遷移し、通信回路１０９はストリームバッファ１０８の蓄積データを順次ネットワークへ送信する。また、ステップＳ１００４において、ＧＯＰ内先頭Ｐピクチャ位置（またはＧＯＰ内先頭Ｐピクチャ先頭補正位置）が未送信データ領域に存在しない場合には（図中のＮｏ）、ステップＳ１００６に遷移し、通信回路１０９はストリームバッファ１０８の蓄積データを順次ネットワークへ送信する。

以上、図９と図１０を用いて、実施例４におけるＩピクチャへのジャンプ後の復号誤り回避方法を示した。これにより、遅延低減のために読み出し位置をジャンプさせた位置がＯｐｅｎＧＯＰである場合でも、復号装置側での復号誤りの発生を防ぐことが出来る。また、実施例３とは異なり圧縮ストリームへの修正が必要ないため、符号化装置の負荷が大きくなることもない。

以上、実施例１〜４に示したシステム構成や、処理手順はあくまで一例であり、本発明の内容を逸脱しない範囲であれば、異なる構成や、処理手順であっても良い。また、各実施例を組み合わせて使用することも可能であり、いずれも本発明の範疇にある。

１００・・・符号化装置、１０１・・・レンズ、１０２・・・撮像素子、１０３・・・カメラＤＳＰ、１０４・・・マイク、１０５・・・映像圧縮回路、１０６・・・音声圧縮回路、１０７・・・映像音声多重回路、１０８・・・ストリームバッファ、１０９・・・通信回路、１１０・・・通信入出力端子、１１１・・・システム制御部、６００・・・トランスポートストリーム、７００・・・ＯｐｅｎＧＯＰのビットストリーム、７０１・・・ＯｐｅｎＧＯＰのデコード順番、７０２・・・ＣｌｏｓｅｄＧＯＰのビットストリーム、７０３・・・ＣｌｏｓｅｄＧＯＰのデコード順番。

Claims

動画像を符号化する動画像符号化装置であって、
被写体を撮影して前記動画像を生成する撮像部と、
前記動画像のデータ量を圧縮する圧縮回路と、
該圧縮回路から供給される前記動画像の圧縮データを蓄積するストリームバッファと、
該ストリームバッファに蓄積された前記動画像の圧縮データをネットワークへ送信する通信回路と、
前記動画像符号化装置を動作制御するシステム制御部を有し、
該システム制御部は、前記ストリームバッファに蓄積された圧縮データの蓄積量が所定の閾値以上である場合には、前記圧縮データの前記ストリームバッファからの読み出し位置を、時間軸上で後ろのIピクチャ先頭位置より、前回送信を終了した位置と次のパケット境界位置との差だけ前の位置へ進めるように制御することを特徴とする動画像符号化装置。