JP4373379B2 - データ圧縮装置 - Google Patents

Description

本発明は、圧縮対象となるデータを圧縮するデータ圧縮装置に関し、特に圧縮データにタイムスタンプを効果的に付加するデータ圧縮装置に関する。

近年のネットワーク技術の発達により、カメラで撮影した画像データをネットワークで伝送するようになった。画像データは画像圧縮技術との組み合わせで、伝送データ量の削減が行われる。例えば、１つのネットワーク上に複数の画像データ圧縮装置を接続することで、同時に複数の画像圧縮データを伝送することが可能である。特に、侵入者等を検知する目的の監視システムでは、画像圧縮データを記録する画像レコーダと組み合わせ、侵入者等が進入した様子を記録するようになっている。このような監視システムにおける記録画像が犯罪捜査に使用される場合、カメラで記録した正確な絶対時刻情報が重要になる。また、最近では画像圧縮方式としてネットワークとの親和性がよいＭＰＥＧ−４（Moving Picture Experts Group phase 4）方式を採用した画像圧縮装置が増えている。

ＭＰＥＧ−４方式では、画像データ復号装置が復号画像を表示するタイミングを管理するため、圧縮データにタイムスタンプ（時刻情報）を付加する。このタイムスタンプを用いることで、前回表示した画像データに対し、何フレーム後に次の画像データを表示すべきかを管理している。しかし、圧縮後のフレーム単位のデータであるＶＯＰ（Video Object Plane）に付加するタイムスタンプは１秒未満のフレーム単位の時間のみ管理し、時分秒は、複数のＶＯＰをまとめたＧＯＶ（Group of VOP）と呼ばれる単位で付加するＧＯＶヘッダのタイムスタンプとして付加される（例えば、非特許文献１参照）。そして、絶対時刻情報は、この２つのタイムスタンプから計算しなければならない。

また、近年の圧縮処理は、圧縮方式の変更などの処理の変更が容易なことから、専用ＬＳＩ以外に、ＣＰＵ等のプロセッサを使用したソフトウェア処理で実行するものも増えてきている。
ＩＳＯ／ＩＥＣ １４４９６−２

ネットワークを用いた画像データ圧縮装置の構成例を図１に示す。
画像データ圧縮装置は、エンコーダモジュール１と、ネットワーク配信モジュール６から構成される。また、エンコーダモジュール１は、ＮＴＳＣデコーダ２と、プロセッサ３と、ＲＴＣ（Real Time Clock）８から構成される。

まず、エンコーダモジュール１の動作について説明する。
ＮＴＳＣデコーダ２は、カメラ５から入力したアナログ画像データ１４をＡ／Ｄ変換し、デジタル画像データ９と垂直同期信号Ｖｓｙｎｃ１０を抽出してプロセッサ３へ出力する。

プロセッサ３は、入力されたデジタル画像データ９に対して、圧縮処理部４でＭＰＥＧ−４画像圧縮処理を行い、圧縮データ１１としてネットワーク配信モジュール６へ出力する。また、入力されたＶｓｙｎｃ１０から算出したフレーム単位の時間（後述する）と、ＲＴＣ８から入力された時分秒データ１３を合わせ、圧縮処理部４でタイムスタンプの計算に使用する。

ＲＴＣ８は、水晶振動子によりカウントアップした時分秒のデジタル情報を、時分秒データ１３としてプロセッサ３へ出力する。
次に、画像データ圧縮装置の動作を同じ図１を用いて説明する。

ＮＴＳＣデコーダ２は、カメラ５からアナログ画像データ１４が１フレーム入力されるたびに画像データをＡ／Ｄ変換し、同期したデジタル画像データ９と垂直同期信号であるＶｓｙｎｃ１０を出力する。よって、Ｖｓｙｎｃ１０が出力される周期は、アナログ画像データ１４が入力される周期であり、その周期の発生源はカメラ５が持つ内部クロックにより決定される周期である。

ＲＴＣ８は、前述したように独自の水晶振動子によりカウントアップした時分秒データ１３を出力する。カメラ５が出力するＶｓｙｎｃ１０と時分秒データ１３は、非同期である。そのため、ＲＴＣ８の水晶振動子とカメラ５の内部クロックのカウントアップ精度によりクロック周期がずれ、長時間動作させると時間のずれが発生する。

一般に、ＲＴＣ８が出力する時間の情報は、年月日時分秒であり、それより細かい精度のフレーム単位を表現する情報は出力されない。そのため、フレーム単位の時間を取得するにはＶｓｙｎｃ１０を利用する必要がある。

プロセッサ３は、デジタル画像データ９が入力されると、圧縮処理部４でＭＰＥＧ−４画像圧縮処理を行う。また、プロセッサ３は、Ｖｓｙｎｃ１０から前回Ｖｓｙｎｃ１０が入力されてからの経過時間を計算するためのカウンタ値と、ＲＴＣ８より時分秒データ１３を読み出し、圧縮処理部４へ渡し、圧縮処理後に圧縮データ１１をネットワーク配信モジュール６へ出力する。なお、プロセッサ３の動作の詳細は後述する。

ネットワーク配信モジュール６は、入力された圧縮データ１１を、ネットワークパケット化し、ネットワークパケットデータ１２としてネットワーク７へ配信する。
次に、プロセッサ３の詳細な動作を図２と図３に示すフローチャートを用いて説明する。

電源投入時は、図２に示す割込初期化処理を行う。まず、フレーム単位の時間を計測するカウンタＦをゼロにする（ステップＳ２ａ）。次に、ＲＴＣ８に現在の時刻を設定する（ステップＳ２ｂ）。この初期化処理により、カウンタＦとＲＴＣの秒の切り替わり点は同一箇所になる。

ここで、カウンタＦについて説明する。ＮＴＳＣのフレーム周期は、約２９．９７Ｈｚである。この周期をデジタル値で表す方法として、以下の方法がある。まず、カウンタＦが３００００カウントアップされると１秒と定義する。この定義においてフレーム周期は、１００１カウントアップしたら１フレームとなる。よって、カウンタＦは、０から２９９９９までの値をとり、フレーム毎に１００１を加算する。桁あふれにより３００００以上になったときに１秒経過したと判断する。

次に、プロセッサ３の通常動作時は、ＮＴＳＣデコーダ２からＶｓｙｎｃ１０が入力されることで割り込み処理を実行する。
図３に示すＶｓｙｎｃ割込では、まず、デジタル画像データ９を取り込む（ステップＳ３ａ）。次に、ＲＴＣ８より時分秒データ１３を取得する（ステップＳ３ｂ）。次に、カウンタＦに１００１を加算し、１フレームの経過を示す（ステップＳ３ｃ）。

次に、カウンタＦが３００００以上であるか否かを判定する（ステップＳ３ｄ）。カウンタＦが３００００以上であれば（ステップＳ３ｄでＹｅｓ）、桁あふれが発生するのでカウンタＦから３００００を減算する（ステップＳ３ｅ）。カウンタFが３００００未満であれば（ステップＳ３ｄでＮｏ）、そのままステップＳ３ｆへ移行する。

次に、圧縮処理部４が圧縮処理中であるか否かを判定する（ステップＳ３ｆ）。圧縮処理中であれば（ステップＳ３ｆでＹｅｓ）、何もせずにＶｓｙｎｃ割込を終了する。圧縮処理が完了していれば（ステップＳ３ｆでＮｏ）、画像データを圧縮処理部４へ出力する（ステップＳ３ｇ）。次に、時分秒データ１３を圧縮処理部４へ出力する（ステップＳ３ｈ）。次に、カウンタＦの値を圧縮処理部４へ出力し（ステップＳ３ｉ）、次の画像圧縮処理を始めるための準備を完了し、Ｖｓｙｎｃ割込を終了する。

次に、図４に示すＭＰＥＧ−４圧縮データの構造から、圧縮処理部４でのタイムスタンプの付加について説明する。
図４に示すように、１フレームの画像データを圧縮したものをＶＯＰと呼び、ＶＯＰの区切りを示すＶＯＰヘッダ２２を付加する。ＶＯＰヘッダ２２の後に、タイムスタンプを表すｍｏｄｕｌｏ＿ｔｉｍｅ＿ｂａｓｅ２３とｖｏｐ＿ｔｉｍｅ＿ｉｎｃｒｅｍｅｎｔ２４がある。ｖｏｐ＿ｔｉｍｅ＿ｉｎｃｒｅｍｅｎｔ２４は、既にカウンタＦについて説明したのと同様に、ＮＴＳＣの場合なら３００００で桁上がりするカウンタ値である。但し、カウンタＦと同じ値になるとは限らない。いくつかのオフセットを持つことがあり、それは圧縮処理部４の実装次第である。ｍｏｄｕｌｏ＿ｔｉｍｅ＿ｂａｓｅ２３は、ｖｏｐ＿ｔｉｍｅ＿ｉｎｃｒｅｍｅｎｔ２４が桁あふれを起こしたときに１が立ち、それ以外では０になる。よって、ｍｏｄｕｌｏ＿ｔｉｍｅ＿ｂａｓｅ２３の値を見れば、秒の桁上がりが発生したかの判断が可能になる。

また、複数のＶＯＰをまとめたものをＧＯＶと呼び、ＧＯＶの区切りを示すＧＯＶヘッダ２０を付加する。ＧＯＶヘッダ２０の後に、タイムスタンプを表すタイムコード２１がある。タイムコード２１は、ＲＴＣ８から得られた時分秒を示す。

ＧＯＶヘッダ２０を付加する周期が１秒より長い場合、例えば５秒ならば、ＧＯＶヘッダ２０が出現する間に４回の秒の桁上がりが発生するが、この場合ＶＯＰに付加されたｍｏｄｕｌｏ＿ｔｉｍｅ＿ｂａｓｅ２３を用いて、始めに取得したＧＯＶのタイムコード２１の値に加算していかなければならない。但し、ＧＯＶのタイムコード２１の秒の値が桁上がりしており、かつ、直後のＶＯＰのｍｏｄｕｌｏ＿ｔｉｍｅ＿ｂａｓｅ２３に１が立っていた場合、ｍｏｄｕｌｏ＿ｔｉｍｅ＿ｂａｓｅ２３の１は無視して加算しないようにする。ｍｏｄｕｌｏ＿ｔｉｍｅ＿ｂａｓｅ２３の１を無視する理由は、ＧＯＶのタイムコード２１の値が絶対時間を表し、秒の桁上がりが発生したことが既に分かっているため、直後のＶＯＰの秒の桁上がりを無視して構わないからである。

次に、タイムスタンプの計算方法の詳細について、デコーダ側の処理を例に説明する。ここで、デコーダで受信する圧縮データは、図５に示す構造であるとする。ＧＯＶは、０．５秒に１回の頻度で挿入されている。また、ｖｏｐ＿ｔｉｍｅ＿ｉｎｃｒｅｍｅｎｔ２４は１秒で３００００をカウントする早さでカウントアップするので、１フレーム時間で１００１カウントアップする。

図５に示すように、現在受信したＧＯＶ内のタイムコード２１は、１２時４８分０２秒であり、直後に受信したＶＯＰデータのｍｏｄｕｌｏ＿ｔｉｍｅ＿ｂａｓｅ２３は２進数で表し１０、ｖｏｐ＿ｔｉｍｅ＿ｉｎｃｒｅｍｅｎｔ２４は１０進数で表し０００２３である。なお、例えば、ＭＰＥＧ−４の規格では、ｍｏｄｕｌｏ＿ｔｉｍｅ＿ｂａｓｅ２３を２進数、つまりビット単位で見た時に、０が出るまでに１が何個あるか、その個数を秒桁上がりの個数としている。

デコーダは最初に、受信したＧＯＶのタイムコード２１を、時・分・秒に分けて読み出す。次に、受信したＶＯＰでは、ＧＯＶの直後である場合、ｖｏｐ＿ｔｉｍｅ＿ｉｎｃｒｅｍｅｎｔ２４の桁上がり情報を示すｍｏｄｕｌｏ＿ｔｉｍｅ＿ｂａｓｅ２３を読み捨てる。何故ならｍｏｄｕｌｏ＿ｔｉｍｅ＿ｂａｓｅ２３は秒の桁上がりを示しても、ＧＯＶのタイムコード２１にはＲＴＣ８から得られた秒の絶対値が格納されており、桁上がり情報を使わずとも、秒の値が分かるからである。

続けて、ＶＯＰのｖｏｐ＿ｔｉｍｅ＿ｉｎｃｒｅｍｅｎｔ２４を読み出す。この値は、前回受信したＶＯＰのｖｏｐ＿ｔｉｍｅ＿ｉｎｃｒｅｍｅｎｔ２４と比較し、前回のＶＯＰが表示されてからの時間経過を算出するために用いる。先程の例としてｖｏｐ＿ｔｉｍｅ＿ｉｎｃｒｅｍｅｎｔ２４が０００２３であるとしたが、さらに前回のＶＯＰのｖｏｐ＿ｔｉｍｅ＿ｉｎｃｒｅｍｅｎｔ２４が２９０２２であるとする。この２つのｖｏｐ＿ｔｉｍｅ＿ｉｎｃｒｅｍｅｎｔ２４から時間経過を算出するのには、（現在受信したｖｏｐ＿ｔｉｍｅ＿ｉｎｃｒｅｍｅｎｔ２４）−（前回受信したｖｏｐ＿ｔｉｍｅ＿ｉｎｃｒｅｍｅｎｔ２４）を計算する。しかし、０００２３＜２９０２２であり、引き算結果はマイナスになる。

これは前回のＶＯＰのｖｏｐ＿ｔｉｍｅ＿ｉｎｃｒｅｍｅｎｔ２４をカウントアップしていった結果、２９９９９を超えて０になったためである。よって、引き算結果のマイナス値に３００００を足すことで時間経過に相当するカウンタ値が得られる。計算結果は、０００２３−２９０２２＋３００００＝１００１となり、１００１は１フレーム時間と等しいため、前回のＶＯＰから１フレーム時間経過したときに現在のＶＯＰを表示すれば良いことが分かる。

次の例として、デコーダで受信する圧縮データが、図６に示す構造であるとする。ＧＯＶは５秒に１回の頻度で挿入されている。また、ｖｏｐ＿ｔｉｍｅ＿ｉｎｃｒｅｍｅｎｔ２４は１秒で３００００をカウントする早さでカウントアップするので、１フレーム時間で１００１カウントアップするのは図５に示した場合と同様である。ＧＯＶの挿入が５秒ごとなのでタイムコード２１だけでは秒の桁上がりの管理が出来ない。そこで秒の桁上がりの管理はＶＯＰのｍｏｄｕｌｏ＿ｔｉｍｅ＿ｂａｓｅ２３とｖｏｐ＿ｔｉｍｅ＿ｉｎｃｒｅｍｅｎｔ２４を用いる。なお、図６の構造は、前のＶＯＰから次のＶＯＰの時間経過が２秒＋２フレームの場合とする。

図６に示すように、現在受信したＧＯＶ内のタイムコード２１は、１２時４８分０２秒であり、直後に受信したＶＯＰデータのｍｏｄｕｌｏ＿ｔｉｍｅ＿ｂａｓｅ２３は１０、ｖｏｐ＿ｔｉｍｅ＿ｉｎｃｒｅｍｅｎｔ２４は０００２３であるのは、図５に示した場合と同様である。デコーダは最初に、受信したＧＯＶのタイムコード２１を、時・分・秒に分けて読み出す。次に受信したＶＯＰが、ＧＯＶの直後である場合に、ｖｏｐ＿ｔｉｍｅ＿ｉｎｃｒｅｍｅｎｔ２４の桁上がり情報を示すｍｏｄｕｌｏ＿ｔｉｍｅ＿ｂａｓｅ２３を読み捨てるのは、先程の図５に示した場合と同様である。

続けて、ＶＯＰのｖｏｐ＿ｔｉｍｅ＿ｉｎｃｒｅｍｅｎｔ２４を読み出す。これも図５の場合と同様にｖｏｐ＿ｔｉｍｅ＿ｉｎｃｒｅｍｅｎｔ２４が０００２３であり、前回のＶＯＰのｖｏｐ＿ｔｉｍｅ＿ｉｎｃｒｅｍｅｎｔ２４が２９０２２であるとする。この２つのｖｏｐ＿ｔｉｍｅ＿ｉｎｃｒｅｍｅｎｔ２４から時間経過を算出すると、０００２３−２９０２２＋３００００＝１００１となるため、前回のＶＯＰから１フレーム時間経過したときに現在のＶＯＰを表示すれば良い。

次に受信するのはＶＯＰだけであり、ｍｏｄｕｌｏ＿ｔｉｍｅ＿ｂａｓｅ２３が２進数で表すと１１０、ｖｏｐ＿ｔｉｍｅ＿ｉｎｃｒｅｍｅｎｔ２４が１０進数で表すと０２０２５である。

始めにｍｏｄｕｌｏ＿ｔｉｍｅ＿ｂａｓｅ２３は、ビット毎に１が発生する数をカウントする。２進数で１１０であるから２つカウントする。カウント回数は、前回受信したＶＯＰのｖｏｐ＿ｔｉｍｅ＿ｉｎｃｒｅｍｅｎｔ２４から、今回受信したｖｏｐ＿ｔｉｍｅ＿ｉｎｃｒｅｍｅｎｔ２４の値になるまでに桁上がりした回数を示す。桁上がりは、この例では３００００で桁上がりするので、２９９９９の次に１つ上がると０００００になり、ｍｏｄｕｌｏ＿ｔｉｍｅ＿ｂａｓｅ２３が１つカウントされる。

次に、ｖｏｐ＿ｔｉｍｅ＿ｉｎｃｒｅｍｅｎｔ２４を読み出すと、０２０２５である。前回のＶＯＰが０００２３であり、ｍｏｄｕｌｏ＿ｔｉｍｅ＿ｂａｓｅ２３は２回桁上がりをカウントしているので、ｖｏｐ＿ｔｉｍｅ＿ｉｎｃｒｅｍｅｎｔ２４のカウンタの動きは、０００２３→桁上がり→桁上がり→０２０２５、となったことが分かる。よって、２つのｖｏｐ＿ｔｉｍｅ＿ｉｎｃｒｅｍｅｎｔ２４から時間経過を算出するには、先程の図５に示した例と同様な時間経過の算出式に加え、桁上がりの回数だけ３００００を加算すれば良い。

つまり、算出式は、（現在受信したｖｏｐ＿ｔｉｍｅ＿ｉｎｃｒｅｍｅｎｔ２４）−（前回受信したｖｏｐ＿ｔｉｍｅ＿ｉｎｃｒｅｍｅｎｔ２４）＋（ｍｏｄｕｌｏ＿ｔｉｍｅ＿ｂａｓｅ２３のカウント回数）×３００００となり、計算結果は、０２０２５−０００２３＋２×３００００＝６２００２となる。３００００で１秒であるから、６２００２は、２秒と２００２カウントと見なせる。２００２カウントは、１００１が２回であるから２フレーム時間となり、前回のＶＯＰからの時間経過は、２秒＋２フレーム時間と算出できる。

この２秒の経過時間は、ＧＯＶを受信した際に読み出した、時・分・秒の秒に加算する。加算により６０秒を超えた場合、分、また時への繰り上げ処理を行う。このように、ＧＯＶが受信できずとも、ＶＯＰのｍｏｄｕｌｏ＿ｔｉｍｅ＿ｂａｓｅ２３とｖｏｐ＿ｔｉｍｅ＿ｉｎｃｒｅｍｅｎｔ２４の値から、時・分・秒の管理ができる。

次に、タイムスタンプの付加と計算方法を図７と図８に示すタイムチャートを用いて説明する。
図７では、ＧＯＶの秒桁上がり（ＧＯＶのタイムコード２１の秒の桁上がり）と、ＶＯＰの秒桁上がり（ｖｏｐ＿ｔｉｍｅ＿ｉｎｃｒｅｍｅｎｔ２４の桁上がり）のタイミングが一致している場合を例にする。ＧＯＶの秒が桁上がりしたとき、ＶＯＰの秒も桁上がりし、ｍｏｄｕｌｏ＿ｔｉｍｅ＿ｂａｓｅ２３が１になる。この場合、デコーダでの再生時間の秒の計算は、ＧＯＶのタイムコード２１の秒の値をそのまま反映させればよいので、例えば、タイムチャートの始まりのように、ＧＯＶの秒が３秒を示しているときは、デコーダでの再生時間も３秒となる。よって、ｍｏｄｕｌｏ＿ｔｉｍｅ＿ｂａｓｅ２３が１になっていても１秒加算する処理をしないようにする。

しかし、図８の右側の図のように、ｖｏｐ＿ｔｉｍｅ＿ｉｎｃｒｅｍｅｎｔ２４が時間情報の非同期が原因でずれた場合、ＧＯＶで秒の桁上がりが発生しデコーダでの再生時間の秒の計算値は３秒になる。次のフレームでｍｏｄｕｌｏ＿ｔｉｍｅ＿ｂａｓｅ２３が１であるので、もう１秒をデコーダでの再生時間に加算することになる。このため、２フレームの期間でデコーダでの再生時間の計算値は、２秒時間が進んだように見えてしまう。

対策として、ＲＴＣ８の秒の桁上がりを検出するたびに、ｖｏｐ＿ｔｉｍｅ＿ｉｎｃｒｅｍｅｎｔ２４の値を初期化してゼロにする手段が考えられる。これによりＲＴＣ８の秒桁上がりのたびにｍｏｄｕｌｏ＿ｔｉｍｅ＿ｂａｓｅ２３に１を立たせることができる。

しかし、ｖｏｐ＿ｔｉｍｅ＿ｉｎｃｒｅｍｅｎｔ２４の秒桁上がりの周期がＧＯＶの周期より早く、ｍｏｄｕｌｏ＿ｔｉｍｅ＿ｂａｓｅ２３に１が立った場合では、次のフレームでＧＯＶの秒桁上がりが発生したときに、ｖｏｐ＿ｔｉｍｅ＿ｉｎｃｒｅｍｅｎｔ２４の値の初期化を行うため、もう一度ｍｏｄｕｌｏ＿ｔｉｍｅ＿ｂａｓｅ２３に１が立ってしまう。よって、ｍｏｄｕｌｏ＿ｔｉｍｅ＿ｂａｓｅ２３は２フレーム連続して１が立つことになる。通常はＧＯＶの秒桁上がりと同時に１になったｍｏｄｕｌｏ＿ｔｉｍｅ＿ｂａｓｅ２３は無視すればよいが、一部のシステムにはＧＯＶのタイムスタンプを参照せずｖｏｐ＿ｔｉｍｅ＿ｉｎｃｒｅｍｅｎｔ２４だけを使用するシステムが存在するため、ｍｏｄｕｌｏ＿ｔｉｍｅ＿ｂａｓｅ２３が２回連続して出力されるのはｖｏｐ＿ｔｉｍｅ＿ｉｎｃｒｅｍｅｎｔ２４がその連続する２つのＶＯＰ間で降順の値となってしまう場合があり好ましくない。

以上のように、ＧＯＶのタイムスタンプを生成する時間情報と、ＶＯＰのタイムスタンプを生成する時間情報が非同期なため、１秒余分に時間が進んだように見えてしまうという問題がある。

本発明は、このような事情に鑑み為されたもので、圧縮データにタイムスタンプを効果的に付加することができるデータ圧縮装置を提供することを目的とする。

上記目的を達成するため、本発明に係るデータ圧縮装置は、圧縮対象となるデータを圧縮するデータ圧縮装置であって、１秒単位の第１のタイムスタンプと、１秒未満単位の第２のタイムスタンプを付加するタイムスタンプ付加手段と、少なくとも前記第１のタイムスタンプの秒桁上がりが発生する際に、前記第２のタイムスタンプを所定のしきい値以上の値に補正するタイムスタンプ補正手段とを備えるように構成される。

また、上記目的を達成するため、本発明に係る画像データ圧縮装置は、デコーダと、計時手段と、前記デコーダが出力する画像データを圧縮する圧縮処理手段と、前記計時手段が出力する時分秒データからタイムスタンプの計算に必要な値を第１のカウンタに設定する手段と、前記デコーダが出力する垂直同期信号からタイムスタンプの計算に必要な値を第２のカウンタに設定する手段を備えた画像データ圧縮装置であって、起動時に所定の値を前記第２のカウンタに設定する初期化手段と、垂直同期信号が入力される毎に前記計時手段の秒桁上がり時に前記所定の値を前記第２のカウンタに設定する補正手段を備えるように構成される。

以上説明したように、本発明に係るデータ圧縮装置によると、１秒単位の第１のタイムスタンプと、１秒未満単位の第２のタイムスタンプを付加するタイムスタンプ付加手段を備え、少なくとも前記第１のタイムスタンプの秒桁上がりが発生する際に、第２のタイムスタンプを所定のしきい値以上の値に補正するようにしたため、圧縮データにタイムスタンプを効果的に付加することができる。

以下、本発明の実施の形態について、図面を参照しながら説明する。
本発明のタイムスタンプを付加した画像データ圧縮装置について説明する。本発明の特徴部分は、プロセッサ３の動作にあり、画像データ圧縮装置の構成は図１の例と同様であるため説明は省略する。

次に、プロセッサ３の動作を図９と図１０に示すフローチャートを用いて説明する。
電源投入時は、図９に示す割込初期化処理を行う。まず、フレーム単位の時間を計測するカウンタＦを７５００にする（ステップＳ９ａ）。これは、カウンタＦのカウントアップが１秒に相当する値、３００００の１／４である。この値は、３００００−（１００１×２９）＝９７１以上の時間になれば違う値でも構わない。これは、カウンタ値にして９７１より小さい値であると、ｖｏｐ＿ｔｉｍｅ＿ｉｎｃｒｅｍｅｎｔ２４の桁上がり位置をＧＯＶの秒桁上がり位置より離した位置にしようとも、ＶＯＰが表示される単位はフレーム単位であるので、結局はＧＯＶの秒桁上がり位置と一致してしまうためである。

また、ＧＯＶの発生周期の最も短い場合を考慮する必要があり、ＧＯＶとＶＯＰの秒桁上がり位置が一致しないような値をカウンタＦに設定する。この例の７５００は、ＧＯＶが１秒に２回発生する場合の一例である。７５００は、３００００の１／４であることから、ＧＯＶの発生位置がｖｏｐ＿ｔｉｍｅ＿ｉｎｃｒｅｍｅｎｔ２４のカウンタ値で表すと０と１５０００であれば、一致することはない。

つまり、ＧＯＶとＶＯＰの秒桁上がり位置が一致しないように、上述したように９７１以上離れた位置関係にあれば、この例のカウンタＦの値は７５００に限定するものでは無い。また、これらの値はＮＴＳＣデコーダ２をＰＡＬデコーダに変更した場合等、ＮＴＳＣ以外であれば違う値になることがある。

次に、ＲＴＣ８に現在の時刻を設定する（ステップＳ９ｂ）。この時刻は、絶対時刻であり、例えばＮＴＰ（Network Time Server）から設定された値である。ＲＴＣ８に秒を設定したことで、ＲＴＣ８の秒の繰り上がりは設定の１秒後となり、この時にカウンタＦは７５００で始まっているので、ＶＯＰカウンタの秒の繰り上がりは０．７５秒後となる。つまり、１／４秒だけｖｏｐ＿ｔｉｍｅ＿ｉｎｃｒｅｍｅｎｔ２４が進んでいることになる。

次に、プロセッサ３の通常時の動作を図１０を用いて説明する。通常時は、ＮＴＳＣデコーダ２からＶｓｙｎｃ１０が入力されることで図１０に示すＶｓｙｎｃ割込処理を実行する。図１０に示すＶｓｙｎｃ割込処理では、まず、始めにデジタル画像データ９を取り込む（ステップＳ１０ａ）。次に、ＲＴＣ８より時分秒データ１３を取得し（ステップＳ１０ｂ）、ＧＯＶのタイムコード２１の設定値とする。但し、ＧＯＶは数秒に１回付加する場合があるため、ＲＴＣ８より取得した時分秒データを必ずＧＯＶとして圧縮データに付加するわけではない。

次に、ＲＴＣ８より取得した秒が前回取得した時点より桁上がりしているか否かを判定する（ステップＳ１０ｃ）。この桁上がりの判定はＶｓｙｎｃ１０が入力される間隔である１フレームの周期以下の誤差を持つが、本発明では１フレーム単位でＶＯＰのタイムスタンプを管理するため問題とならない。秒が桁上がりしていれば（ステップＳ１０ｃでＹｅｓ）、カウンタＦに７５００を代入する（ステップＳ１０ｄ）。これにより、ＲＴＣ８の秒桁上がり時にｖｏｐ＿ｔｉｍｅ＿ｉｎｃｒｅｍｅｎｔ２４が７５００になるよう補正される。もしくは、ＧＯＶとＶＯＰの秒桁上がりの非同期誤差が分かっており、その誤差をｖｏｐ＿ｔｉｍｅ＿ｉｎｃｒｅｍｅｎｔ２４のカウンタ値に換算できれば、補正値をｖｏｐ＿ｔｉｍｅ＿ｉｎｃｒｅｍｅｎｔ２４に加算、もしくは減算することで補正する。

ステップＳ１０ｃにおいて秒が桁上がりしてない場合は、カウンタＦに１００１を加算する（ステップＳ１０ｅ）。ステップＳ１０ｆ以降は、上述した図３の動作と同様になり、カウンタＦが３００００を超えたか否かの判定処理と、圧縮処理部４が圧縮中であるかの判定を行い、圧縮処理が完了していれば、画像データと時分秒データ、カウンタＦの値を圧縮処理部４へ出力する（ステップＳ１０ｆ〜ステップＳ１０ｋ）。

次に、タイムスタンプの秒の桁上がりの様子を図１１に示すタイムチャートを用いて説明する。
ｖｏｐ＿ｔｉｍｅ＿ｉｎｃｒｅｍｅｎｔ２４の秒の桁上がりタイミングは、ＧＯＶの秒の桁上がりタイミングより１／４秒だけ進んでいる。始めにＧＯＶのタイムコード２１の秒の値が２秒を示しているときに、ｖｏｐ＿ｔｉｍｅ＿ｉｎｃｒｅｍｅｎｔ２４の桁上がりが発生し、タイムスタンプからデコーダでの再生時間を計算すると（２＋１）＝３秒になる。

次のフレームでＧＯＶのタイムコード２１の秒の値が３秒になるが、先程計算したデコーダでの再生時間は３秒であり、これと一致しているため、３秒のままである。また、ＲＴＣ８の秒桁上がり時にｖｏｐ＿ｔｉｍｅ＿ｉｎｃｒｅｍｅｎｔ２４が７５００になるように補正する。３／４秒経過すると、ｖｏｐ＿ｔｉｍｅ＿ｉｎｃｒｅｍｅｎｔ２４の桁上がりが発生し、デコーダでの再生時間は（３＋１）＝４秒となる。

次に、ＧＯＶのタイムコード２１の秒の値が４秒を示しているが、計算したデコーダでの再生時間の４秒と一致しているのは、先程と同様である。また、ＲＴＣ８の秒桁上がり時にｖｏｐ＿ｔｉｍｅ＿ｉｎｃｒｅｍｅｎｔ２４が７５００になるように補正する。以降、同じ動作を繰り返す。

ここで、ｖｏｐ＿ｔｉｍｅ＿ｉｎｃｒｅｍｅｎｔ２４が非同期によるずれを起こした、もしくは補正されずれた場合を考える。ｖｏｐ＿ｔｉｍｅ＿ｉｎｃｒｅｍｅｎｔ２４の桁上がり位置がずれても、ＧＯＶの秒の桁上がり位置はこのずれ以上に離れた位置にあるため、お互いの秒の桁上がり位置が一致、もしくは交差することは発生しない。このため、１秒余計に加算されることは発生しなくなる。

以上のように、本実施例の画像データ圧縮装置では、ＮＴＳＣデコーダ２と、ＲＴＣ８と、画像データを圧縮する圧縮処理部４と、ＮＴＳＣデコーダ２が出力するＶｓｙｎｃ１０とＲＴＣ８が出力する時分秒データ１３からタイムスタンプの計算に必要なカウンタ値を圧縮処理部４へ出力するプロセッサ３と、ネットワーク配信モジュール６を備え、起動時に所定の値をＶｓｙｎｃの入力タイミングから算出したカウンタに設定する初期化手段と、Ｖｓｙｎｃが入力される毎にＲＴＣ８の秒桁上がり時に初期化手段で設定したのと同じ所定の値をカウンタに設定するＲＴＣ秒桁上がり処理手段を有するプロセッサを有する。

従って、ＧＯＶとＶＯＰの秒の桁上がり位置をずらす、この例ではｖｏｐ＿ｔｉｍｅ＿ｉｎｃｒｅｍｅｎｔ２４を１／４秒早めることにより、１秒余計に加算されることのない画像データ圧縮装置が実現できる。つまり、上記の画像データ圧縮装置を用いることで、ＧＯＶとＶＯＰとの双方の秒桁上がり位置に非同期を原因とするずれが生じた時に、ｖｏｐ＿ｔｉｍｅ＿ｉｎｃｒｅｍｅｎｔ２４を補正しても１秒余分に時間が進んで見えることなく、例えば、ＭＰＥＧ−４圧縮データにタイムスタンプを付加することができる。

なお、本実施例のデータ圧縮装置では、プロセッサ３や圧縮処理部４の機能によりタイムスタンプ付加手段が構成されており、プロセッサ３の機能によりタイムスタンプ補正手段が構成されている。

また、本実施例の画像データ圧縮装置では、ＲＴＣ８の機能により計時手段が構成されており、圧縮処理部４の機能により圧縮処理手段が構成されており、プロセッサ３の機能により第１のカウンタに設定する手段が構成されており、プロセッサ３の機能により第２のカウンタに設定する手段が構成されており、プロセッサ３の機能により初期化手段が構成されており、プロセッサ３の機能により補正手段が構成されている。

ここで、本発明に係る画像データ圧縮装置などの構成としては、必ずしも以上に示したものに限られず、種々な構成が用いられてもよい。また、本発明は、例えば、本発明に係る処理を実行する方法或いは方式や、このような方法や方式を実現するためのプログラムや当該プログラムを記録する記録媒体などとして提供することも可能であり、また、種々な装置やシステムとして提供することも可能である。

また、本発明の適用分野としては、必ずしも以上に示したものに限られず、本発明は、種々な分野に適用することが可能なものである。
また、本発明に係る画像データ圧縮装置などにおいて行われる各種の処理としては、例えばプロセッサやメモリ等を備えたハードウエア資源においてプロセッサがＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）に格納された制御プログラムを実行することにより制御される構成が用いられてもよく、また、例えば当該処理を実行するための各機能手段が独立したハードウエア回路として構成されてもよい。

また、本発明は上記の制御プログラムを格納したフロッピー（登録商標）ディスクやＣＤ（Ｃｏｍｐａｃｔ Ｄｉｓｃ）−ＲＯＭ等のコンピュータにより読み取り可能な記録媒体や当該プログラム（自体）として把握することもでき、当該制御プログラムを当該記録媒体からコンピュータに入力してプロセッサに実行させることにより、本発明に係る処理を遂行させることができる。

画像データ圧縮装置の構成例を示す図である。 画像データ圧縮装置の処理の手順の一例を示す図である。 画像データ圧縮装置の処理の手順の一例を示す図である。 タイムスタンプの付加について説明するための図である。 タイムスタンプの計算方法を説明するための図である。 タイムスタンプの計算方法を説明するための図である。 タイムスタンプの付加と計算方法を説明するための図である。 タイムスタンプの付加と計算方法を説明するための図である。 本発明の一実施例に係る画像データ圧縮装置の処理の手順の一例を示す図である。 本発明の一実施例に係る画像データ圧縮装置の処理の手順の一例を示す図である。 本発明の一実施例に係るタイムスタンプの秒の桁上がりの様子を説明するための図である。

符号の説明

１：エンコーダモジュール、２：ＮＴＳＣデコーダ、３：プロセッサ、４：圧縮処理部、５：カメラ、６：ネットワーク配信モジュール、７：ネットワーク、８：ＲＴＣ、９：デジタル画像データ、１０：Ｖｓｙｎｃ、１１：圧縮データ、１２：ネットワークパケットデータ、１３：時分秒データ、１４：アナログ画像データ。

Claims (2)

1. 圧縮対象となるデータを圧縮するデータ圧縮装置であって、圧縮された１フレームの画像データ複数分の集合体に対し１秒単位の第１のタイムスタンプを付加し、前記圧縮された１フレームの画像データに対し１秒未満単位の第２のタイムスタンプを付加するタイムスタンプ付加手段と、少なくとも前記第１のタイムスタンプの秒桁上がりが発生する際に、前記第２のタイムスタンプを、前記第１のタイムスタンプを付加する周期のカウント数から前記第１のタイムスタンプを付加する周期の間に経過するフレーム数分のカウント数を減算した値以上の値であり、かつ、前記第１のタイムスタンプを付加する周期のカウント数より小さい値に補正するタイムスタンプ補正手段と、
   を備えたことを特徴とするデータ圧縮装置。
2. デコーダと、計時手段と、前記デコーダが出力する画像データを圧縮する圧縮処理手段と、前記計時手段が出力する時分秒データからタイムスタンプの計算に必要な値を第１のカウンタに設定する手段と、前記デコーダが出力する垂直同期信号からタイムスタンプの計算に必要な値を第２のカウンタに設定する手段を備えた画像データ圧縮装置であって、
   起動時に、前記第１のカウンタのタイムスタンプを付加する周期のカウント数から前記第１のカウンタのタイムスタンプを付加する周期の間に経過するフレーム数分のカウント数を減算した値以上の値であり、かつ、前記第１のカウンタのタイムスタンプを付加する周期のカウント数より小さい値を前記第２のカウンタに設定する初期化手段と、前記計時手段の秒桁上がりを判定する判定手段と、該判定手段が前記計時手段の秒桁が上ったと判定した場合に、前記第１のカウンタのタイムスタンプを付加する周期のカウント数から前記第１のカウンタのタイムスタンプを付加する周期の間に経過するフレーム数分のカウント数を減算した値以上の値であり、かつ、前記第１のカウンタのタイムスタンプを付加する周期のカウント数より小さい値を前記第２のカウンタに設定する補正手段と、
   を備えたことを特徴とする画像データ圧縮装置。