(57)【要約】【課題】動き補償予測技術に基づく映像データからフレーム画像を生成して再生表示する視聴端末において、巻き戻し再生を連続して行う。【解決手段】デコーダ２０９は、外部から取得した映像データからフレーム画像を生成して画像バッファ２１０に格納し、ＧＵＩ部２１２は画像バッファ２１０からフレーム画像を読み出して表示する。制御部２０８は、通常速度で再生表示した後に画像バッファ２１０に最新の連続フレーム画像とより古い飛び飛びのフレーム画像とを残すように制御する。また巻き戻し再生の際に、連続したフレーム画像の巻き戻し再生を実現するように、最新の連続フレーム画像を巻き戻し再生表示する動作と飛び飛びのフレーム画像の１つと連続する映像データを取得する動作を並行して実行するよう制御する。【選択図】図１
2004159034.tif 000002
【特許請求の範囲】
【請求項１】
外部の装置から圧縮映像データを取得する手段と、前記圧縮映像データを伸長する手段と、伸長して得られたフレーム画像を記憶装置に格納する手段と、格納された前記フレーム画像を画面上に再生表示する手段とを有する映像再生装置において、
通常速度で前記フレーム画像を再生表示した後に前記記憶装置に連続フレーム画像と前記連続フレーム画像より古い飛び飛びのフレーム画像とを残すよう制御する手段と、巻き戻し再生の指示に応答して、前記フレーム画像を巻き戻し方向に再生表示する動作と前記飛び飛びのフレーム画像の１つと連続する前記圧縮映像データを取得する動作とを並行して実行させることによって前記画面上に連続したフレーム画像の巻き戻し再生を実現するよう制御する手段とを有することを特徴とする映像再生装置。
【請求項２】
さらにネットワーク上の伝送速度と前記巻き戻し再生の倍速度とから前記連続したフレーム画像の巻き戻し再生が可能か否か判定する手段を設けることを特徴とする請求項１記載の映像再生装置。
【請求項３】
連続フレーム画像と前記連続フレーム画像より古い飛び飛びのフレーム画像とを格納する画像バッファと、前記画像バッファに新しい連続フレーム画像を供給する手段と、前記画像バッファから前記連続フレーム画像を読み出して巻き戻し方向に再生表示する手段と、前記画像バッファ中に存在するフレーム画像を管理するためのテーブル手段と、前記画面上に連続したフレーム画像の巻き戻し再生を実現するように、前記テーブル手段を参照して前記再生表示する手段と前記飛び飛びのフレーム画像の１つと連続するフレーム画像を前記画像バッファに供給する前記供給する手段とを並行動作させるよう制御する手段と、前記画像バッファ中のフレーム画像の存在状況に応じて前記テーブル手段中のフレーム画像の存在状況を更新する手段とを有することを特徴とする映像再生装置。
【請求項４】
計算機に、外部の装置から圧縮映像データを取得する機能、前記圧縮映像データを伸長する機能、伸長して得られたフレーム画像を記憶装置に格納する機能、および格納された前記フレーム画像を画面上に再生表示する機能とを実現させるためのプログラムにおいて、
前記計算機に、通常速度で前記フレーム画像を再生表示した後に前記記憶装置に連続フレーム画像と前記連続フレーム画像より古い飛び飛びのフレーム画像とを残すよう制御する機能、および巻き戻し再生の指示に応答して、前記フレーム画像を巻き戻し方向に再生表示する動作と前記飛び飛びのフレーム画像の１つと連続する前記圧縮映像データを取得する動作とを並行して実行させることによって前記画面上に連続したフレーム画像の巻き戻し再生を実現するよう制御する機能を実現させるためのプログラム。
【請求項５】
連続フレーム画像と前記連続フレーム画像より古い飛び飛びのフレーム画像とを格納する画像バッファと、前記画像バッファ中に存在するフレーム画像を管理するためのテーブル手段とを有する計算機に、前記画像バッファに新しい連続フレーム画像を供給する機能、前記画像バッファから前記連続フレーム画像を読み出して巻き戻し方向に再生表示する機能、前記画面上に連続したフレーム画像の巻き戻し再生を実現するように、前記テーブル手段を参照して前記再生表示する手段と前記飛び飛びのフレーム画像の１つと連続するフレーム画像を前記画像バッファに供給する前記供給する手段とを並行動作させるよう制御する機能、および前記画像バッファ中のフレーム画像の存在状況に応じて前記テーブル手段中のフレーム画像の存在状況を更新する機能を実現させるためのプログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、映像データを再生表示する視聴端末の制御技術に係り、特に巻き戻し再生を行うための映像再生技術に関するものである。
【０００２】
【従来の技術】
従来、ビデオテープなどに録画された映像をビデオデッキなどの装置で再生して視聴する技術が普及した。その後、ＭＰＥＧなどの映像、音声圧縮技術が確立され、ハードディスク上に蓄積されている映像データをＰＣ（パーソナル・コンピュータ）を用いて再生することが可能となった。さらにローカルのハードディスクに蓄積されている映像データだけでなく、ＶＯＤ（ビデオ・オン・デマンド）サーバ内のハードディスクに蓄積される映像データをサーバから各端末へ配信することにより、各端末で映像を視聴することが可能になった。
【０００３】
ビデオテープの映像を再生するビデオデッキは、通常の再生だけでなく、コマ送り、一時停止、早送り、巻き戻しなどの特殊再生が可能である。そこでＰＣ上で映像を再生する場合も、これらの特殊再生が行えることが要求される。
【０００４】
ＭＰＥＧなど動き補償予測技術を用いた映像圧縮方式は、通常再生の方向に再生することを前提に考えられたものなので、任意のフレームから開始される再生ができないという問題点がある。
【０００５】
ＶＯＤサーバ内に格納されたＭＰＥＧ映像を、巻き戻し再生する技術として、例えば特開２０００−２０９５２９号公報（特許文献１）に記載されたものがある。これはＭＰＥＧデータを伸長して得られるフレーム画像を、あらかじめ逆順にエンコードしてハードディスクに蓄積し、巻き戻しの際はこの映像データを配信することにより、ＶＯＤサーバ／クライアントシステムで巻き戻し再生を実現するものである。
【０００６】
【特許文献１】
特開２０００−２０９５２９号公報
【０００７】
【発明が解決しようとする課題】
しかしながら、上記従来の方式は、サーバ側のハードディスクを多く消費するという問題がある。またフレーム単位で表示が可能なＩピクチャが一定間隔に挿入されていることを前提としているため、ＭＥＰＧ−４のようにＩピクチャが途中で全く挿入されないＭＰＥＧ映像を用いた場合に対応できないという問題点がある。その理由は、上記従来技術では、逆順のフレーム画像を生成するために、定期的に存在するＩピクチャを起点としてフレーム画像の列を生成しているからである。
【０００８】
さらに視聴端末がＶＯＤサーバからＭＰＥＧ配信を受けて映像を表示するような場合では、伝送速度や倍速度の指定により必ずしも巻き戻し再生が可能とは限らない。そこである条件下では巻き戻しを行うが、そうでない場合は代替手段を用意し、それらが使い分けられる必要性がある。
【０００９】
本発明の目的は、動き補償予測アルゴリズムに基づいた映像データからフレーム画像を生成して再生表示する視聴端末において、巻き戻し再生を連続して行うための技術を提供することにある。
【００１０】
【課題を解決するための手段】
本発明は、外部の装置から圧縮映像データを取得する手段と、この圧縮映像データを伸長する手段と、伸長して得られたフレーム画像を記憶装置に格納する手段と、格納されたフレーム画像を画面上に再生表示する手段とを有する映像再生装置において、通常速度でフレーム画像を再生表示した後に記憶装置に連続フレーム画像とこの連続フレーム画像より古い飛び飛びのフレーム画像とを残すよう制御し、巻き戻し再生の指示に応答して、フレーム画像を巻き戻し方向に再生表示する動作と飛び飛びのフレーム画像の１つと連続する圧縮映像データを取得する動作とを並行して実行させることによって画面上に連続したフレーム画像の巻き戻し再生を実現するよう制御する映像再生技術を特徴とする。
【００１１】
【発明の実施の形態】
以下、本発明の一実施形態について図面を用いて詳細に説明する。
【００１２】
図２は、本発明の映像再生方式が適用される環境の一例を示した図である。ＶＯＤサーバ１０１は、映像配信の要求を受けると、保持している圧縮映像データを送出する機能を持つ。視聴端末１０２は、映像配信の要求をＶＯＤサーバ１０１に向けて送信し、ＶＯＤサーバ１０１から送出された圧縮映像データを受信し、その圧縮映像データを伸長しながら画面上に再生する機能を持つ映像再生装置である。視聴端末１０２は、ＧＵＩ（グラフィカルユーザーインターフェース）を持ち、視聴者の操作に基づいて再生処理等を行なう。ネットワーク１００は、ＶＯＤサーバ１０１と視聴端末１０２との間に情報を伝達する。
【００１３】
ここでいう「圧縮映像データ」とは、ＭＰＥＧなどの動き補償予測技術を用いて映像情報を圧縮することによって生成されるデータである。ＭＰＥＧは、フレーム内符号化された画像（以下、Ｉピクチャとする）と、動き補償フレーム間符号化された画像から成る。
【００１４】
公知の視聴端末は、ＶＯＤサーバ１０１から圧縮映像データの送出を受け、通常再生を行なうことが可能である。ここで「通常再生」とは、圧縮映像データを作成する際に元となった映像と同じ早さで再生することを言う。公知の視聴端末では、ＭＰＥＧによる圧縮映像データの配信の場合、端末において巻き戻し再生を行なうのは困難であった。本発明の映像再生方式は、視聴端末１０２の上で巻き戻し再生を実現することを目的とする。
【００１５】
図１は、視聴端末１０２の内部構成を示す図である。視聴端末１０２は、計算機であり、バス２００、ＣＰＵ２０１、ディスプレイ２０２、キーボード２０３、ネットワークインタフェース２０４、ハードディスク２０５、主メモリ２０６、ジョグシャトル２１３及びマウス２１４などから構成される。バス２００は、複数の上記ハードウェア機器間の通信をつかさどる。ディスプレイ２０２、キーボード２０３、ジョグシャトル２１３及びマウス２１４は、視聴者に対する情報の入出力を司る。特にジョグシャトル２１３は、映像再生の方法を指示するために使われるハードウェア機器である。ネットワークインタフェース２０４，ハードディスク２０５及び主メモリ２０６は，バス２００を介してＣＰＵ２０１よりアクセスされる。
【００１６】
主メモリ２０６は、複数のプログラムとデータを格納する領域を保持する。主メモリ２０６は、プロトコル処理部２０７、制御部２０８、デコーダ２０９、画像バッファ２１０、管理テーブル２１１およびＧＵＩ部２１２を格納する。プロトコル処理部２０７は、ネットワーク１００へ送出するメッセージを生成したり、ネットワークから受信したメッセージを解釈するプログラムである。制御部２０８は、プロトコル処理部２０７、デコーダ２０９、画像バッファ２１０及び管理テーブル２１１の全体の動作を制御する。デコーダ２０９は、ＭＰＥＧ方式により圧縮された映像データを伸長し、画像を復元するプログラムである。画像バッファ２１０は、デコーダ２０９が復元したフレーム画像を保持する記憶領域である。画像バッファ２１０を中心とすると、デコーダ２０９、プロトコル処理部２０７、ネットワーク１００及びＶＯＤサーバ１０１は、画像バッファ２１０にフレーム画像を供給する手段と見ることもできる。管理テーブル２１１は、画像バッファ内のフレーム画像を管理するテーブルである。ＧＵＩ部２１２は、視聴者がディスプレイ２０２、キーボード２０３、ジョグシャトル２１３及びマウス２１４を介して情報の入出力を行う際にユーザーインターフェースを提供するプログラムである。ＣＰＵ２０１は、主メモリ２０６上のプログラムを実行する。
【００１７】
ここで視聴端末内において視聴者が映像情報を視聴するときのデータの流れと処理手順について説明する。視聴者が入力装置を介してＧＵＩ部２１２に映像再生命令を出すと、プロトコル処理部２０７が映像再生命令のメッセージを生成する。そのメッセージは、バス２００とネットワークインタフェース２０４を介してネットワーク１００へ送出される。ネットワーク１００から圧縮映像データがネットワーク上のメッセージとして送られてきたとき、そのメッセージは、ネットワークインタフェース２０４とバス２００を介してプロトコル処理部２０７に送られる。プロトコル処理部２０７は、ネットワーク上のメッセージから圧縮映像データを取り出し、デコーダ２０９に渡す。デコーダ２０９は、圧縮映像データを伸長し、フレーム画像を生成して、画像バッファ２１０に蓄積する。ＧＵＩ部２１２は、画像バッファ２１０内のフレーム画像を順次ディスプレイ２０２上に表示し、音声情報を図示しないスピーカに出力することにより、視聴者は映像を視聴することが可能となる。視聴者は、入力装置を介して通常の再生とは異なり、巻き戻しなどの特殊再生を指示することも可能である。通常再生との違いは、通常再生の場合はプロトコル処理部２０７が通常再生命令のメッセージを生成するのに対して、特殊再生の場合は特殊再生命令のメッセージを生成してネットワーク１００へ送出する点が異なっている。またその結果、特殊再生の場合はＶＯＤサーバから送られてくるデータが通常再生とは異なっており、視聴端末１０２内で行なわれる処理も異なる。本発明の映像再生方式は、特殊再生の中でも特に巻き戻し再生を対象とする。
【００１８】
次に図３及び図４を用いて巻き戻し再生方式について説明する。まず図３を用いてＶＯＤサーバ／クライアントシステムにおいて巻き戻し再生を行った場合に起こりがちな問題点について述べる。その後、図４を用いて本実施形態の映像再生方式を説明する。
【００１９】
ＭＰＥＧデータを受信する従来の視聴端末において、図３の方式では巻き戻し再生が正しく行えないことを説明する。巻き戻し再生が開始されると、最初にデコーダ２０９は、ＶＯＤサーバ１０１に対してＭＰＥＧデータの送出命令を送る（矢印４０１）。このとき読み出すべきＭＰＥＧデータは、ある決まったバイト数に限られる。ＶＯＤサーバ１０１はこれを受け、ＶＯＤサーバ１０１内の蓄積装置からＭＰＥＧデータを読み出し、デコーダ２０９に向けて送出する（矢印４０２）。デコーダ２０９は、ＭＰＥＧデータを受信すると、そのデータの伸長を行う（矢印４０３）。伸長が完了したとき、デコーダ２０９は、得られたフレーム画像を画像バッファ２１０に蓄積する（矢印４０４）。ＧＵＩ部２１２は、画像バッファ２１０中のフレーム画像を逆順に受け取ってディスプレイ２０２上に表示する（矢印４０５）。この表示動作と並行して、デコーダ２０９は次の送出命令をＶＯＤサーバ１０１に送る（矢印４０６）。以下、同じ処理を繰り返す。その結果、巻き戻し再生が実現する。
【００２０】
ところでＶＯＤサーバ１０１からデコーダ２０９へのＭＰＥＧデータの転送に時間が長くかかると、伸長の完了が遅くなり、デコーダ２０９が次の送出命令を発行するのが遅れる。その結果、次のＧＵＩ部２１２へのフレーム画像の転送が前回の転送に続けて行なうことができなくなる可能性がある。すなわち視聴者からは、巻き戻し再生がある時間動いては少し止まり、また動いては少し止まるといった動作を繰り返すように見える。
【００２１】
デコーダ２０９がＶＯＤサーバ１０１へ送出命令を出してからデータを受信し終わるまでの時間をＡ、ネットワーク上を情報が伝わるのにかかる時間をＮ、伸長処理にかかる時間をＢ、１回のＭＰＥＧデータ送出の結果を表示できる巻き戻し再生の再生時間をＣと仮定すると、
Ａ＋Ｂ＋Ｎ＞Ｃ
が成立すると、上述したように１回のＭＰＥＧデータ送出単位で巻き戻し再生が途切れる結果となる。
【００２２】
そこでネットワーク上の伝送時間の影響をできるだけ少なくするように、視聴端末の構成を改良する方法について、以下に説明する。
【００２３】
図４は、本発明の映像再生方式が適用される視聴端末において、巻き戻し再生を行なうときの処理の流れを示している。図４の構成では、プロトコル処理部２０７が備わっていることが特徴である。プロトコル処理部２０７がデコーダ２０９の処理とは独立に動作することによって、巻き戻し再生のフレーム画像を途切れなく再生することに役立っている。以下、処理の流れに従って説明する。
【００２４】
巻き戻し再生を開始すると、プロトコル処理部２０７は、ＶＯＤサーバ１０１に送出命令を発行する（矢印５０１）。送出命令は、要求するフレームについてフレーム番号の範囲を含んでいる。ＶＯＤサーバ１０１は送出命令を受け取ると、ハードディスク内のＭＰＥＧデータを読み出し、プロトコル処理部２０７に送出する（矢印５０２）。プロトコル処理部２０７は、この正順のＭＰＥＧデータを受信すると直ちにデコーダ２０９にＭＰＥＧデータを送る（矢印５０３）。デコーダ２０９はデータを受け取ると伸長を行なう（矢印５０４）。デコーダは伸長して生成したフレーム画像を画像バッファ２１０に渡す（矢印５０５）。ＧＵＩ部２１２は、画像バッファ２１０中のフレーム画像を逆順に受け取ってディスプレイ２０２上に表示する（矢印５０６）。一方、プロトコル処理部２０７は、デコーダ２０９にＭＰＥＧデータを渡した直後に、次のデータの送出命令をＶＯＤサーバ１０１に発行することができる（矢印５０７）。以後、この処理を繰り返すことにより、巻き戻し再生が可能となる。ここでデコーダ２０９の伸長処理とプロトコル処理部２０７のデータ受信処理が並行して行えるため、ネットワーク１００上のデータ転送に時間を要するにもかかわらず、途切れない巻き戻し再生が可能となっている。図４では、矢印５０４の最下点、すなわち伸長処理が終了する時刻が１回前の伸長の結果を用いて再生し終わる時刻よりも前であれば、連続した巻き戻し再生が行える。
【００２５】
プロトコル処理部２０７がＶＯＤサーバ１０１へ送出命令を出してからデータを受信し終わるまでの時間をＡ、ネットワークによる遅延をＮ、１回のＭＰＥＧデータ送出の結果を表示できる巻き戻し再生の時間をＣと仮定すると、
Ａ＋Ｎ＜Ｃ
が成立すると、巻き戻し再生が途切れなく行える。
【００２６】
ここで、Ａ、Ｎ、Ｃを得るための方法について説明する。Ａは通常十分小さいので無視できる。Ｎは次のようにして求めることができる。
【００２７】
Ｎ＝Ｃ×「ビットレート」×「倍速度」÷「伝送速度」
Ｃは、任意の適当な短い時間を使用する。例えば３秒といった値である。ビットレートは、映像データを再生するために毎秒必要なデータビット数であり、ＭＰＥＧデータから得ることが可能である。先に示した式に、これらを当てはめることにより、
「ビットレート」×「倍速度」＜「伝送速度」
が成立すると、巻き戻し再生がスムーズに行えることがわかる。伝送速度はネットワーク１００の伝送スループットである。
【００２８】
次に図５及び図６を用いて、制御部２０８が画像バッファ２１０内のフレーム画像の生成や削除の処理を行なう手順を説明する。画像バッファ２１０は、常に管理テーブル２１１によって管理される。管理テーブル２１１については後に説明する。
【００２９】
制御部２０８は再生時、画像バッファ２１０内の再生ずみのフレーム画像をすぐには削除しないことにより、巻き戻し再生が始まったときに、最初の数フレームは直ちに表示を開始することを可能とする。図５は、通常再生の後に画像バッファ２１０に残されるフレーム画像の推移を示す図である。フレーム画像が最初、数枚しかないうちは、全て残す。図５（ａ）は、フレーム画像の枚数がある枚数Ｆ枚に達したときの様子を示している。６１１は最初のフレーム画像で、６１２が最新のフレーム画像である。枚数がＦ枚になるまでは、全てのフレーム画像を残す。再生したフレーム画像がＦ枚を超えたとき、最新のＦ枚のフレーム画像はすべて残し、それより古いフレーム画像は、最初のフレーム画像６１１を除いてすべて削除する。最新のフレーム画像が１枚画像バッファ２１０に追加されるごとに最新のＦ枚のフレーム画像に次いで古いフレーム画像が１枚画像バッファ２１０から削除される。これが続くと、図５（ｂ）のように、２×Ｆ−１枚のフレーム画像を再生し終わる瞬間が来る。６２３は最新のフレーム画像である。６２２は新しいほうからＦ枚目のフレーム画像である。６２２と６２３の間のフレーム画像は全て保持している。６１１と６２２の間は全てのフレームを削除している。この状態で次のフレーム画像が新たに加わるときは、６２２のフレーム画像は削除しない。すなわち最初のフレーム画像からＦ枚目のフレーム画像は削除しない。さらにもう一枚、フレーム画像が加わると、６２２の右隣のフレーム画像を削除する。この状態が図５（ｃ）である。すなわち残っているのは最初のフレーム画像６１１、最初のフレーム画像からＦ枚右隣の画像６２２、最新のフレーム画像６３３と最新のフレーム画像からＦ枚左隣のフレーム画像６３２までの間の全てのフレーム画像である。最後に削除されたのは、フレーム画像６３１である。この状態で新しいフレーム画像が１枚加わると、次に削除されるのはフレーム画像６３２である。すなわち最新のフレーム画像から新しい順にＦ枚のフレーム画像を保持する。このようにフレーム画像の追加と削除を進めて削除するフレーム画像数がＦ−２枚になった時点で、一度削除処理を省略する。すなわち最初のフレーム画像から２×Ｆ−１枚目のフレーム画像が削除されない。この要領で処理をさらに続けると、最初のフレーム画像６１１、最初のフレーム画像から数えてｎＦ−（ｎ−１）番目のフレーム画像（ｎ＝１，２，…）と、最新のフレーム画像からＦ枚は全て残されている状態となる。この処理が続くほど画像バッファ２１０の記憶領域を消費する。よって、いつか画像バッファ２１０の残り容量がなくなるときが来る。それが図５（ｄ）の状態である。次に新しいフレーム画像が加わると、フレーム画像６４２を残さなければならない。しかし画像バッファの残りがないので、次の新しいフレーム画像を追加するために最も古いフレーム画像であるフレーム画像６１１を削除する。
【００３０】
以上の処理を続けると、常に最新のフレームからＦ枚は連続して保持し、それより古いフレーム画像はＦ−１枚ごとに１枚保持している状態が続く。制御部２０８は、上記のように通常速度でフレーム画像を再生表示した後に画像バッファ２１０内に最新の連続フレーム画像とより古い飛び飛びのフレーム画像とを残すように制御する。巻き戻し再生を始める際、最新のＦ枚をＧＵＩ部２１２に渡すことにより、直ちに巻き戻し再生の表示を開始することが可能となり、視聴者に早いレスポンスで対応することが可能となる。古いフレームをＦ−１枚ごとに１枚ずつ保持しておくことによる効果については、図６の説明の中で触れる。
【００３１】
続いて図６を用いて巻き戻し再生を行うときに、制御部２０８が画像バッファ２１０内のフレーム画像の格納と削除を行う処理の流れについて、説明する。
【００３２】
巻き戻し再生を行うのは、多くの場合通常再生を行った後である。図５を用いて説明したように、通常再生の後の画像バッファ２１０にはフレーム画像が残される。図６（ａ）は、その状態を示している。すなわち最新のフレーム画像７０４から７０３までのＦ枚は全てのフレームが保持されている。それより古いフレーム画像７０２，７０１は、一定の枚数おきに保持されているフレーム画像である。図６（ｂ）は、巻き戻し再生を始めた状態を示している。巻き戻し再生が始まると、ただちに７０４から７０３までのフレーム画像を新しい方から順にＧＵＩ部２１２へ転送する。ＧＵＩ部２１２は転送されたフレーム画像を表示する。その結果、巻き戻し再生が行われる。これと同時に、制御部２０８は、プロトコル処理部２０７を介してフレーム画像７０３とフレーム画像７０２との間の圧縮映像データをＶＯＤサーバ１０１に要求する。そしてプロトコル処理部２０７がＭＥＰＧデータを受信し、デコーダ２０９が伸長処理を行なう。その結果得られるフレーム画像を論理的にフレーム画像７０３と７０２の間に挿入するように画像バッファ２１０に格納する。これらの処理が終了すると、図６（ｃ）の状態になる。ＶＯＤサーバ１０１から取得したＭＰＥＧデータをもとにして、７０３から７０２までのフレーム画像が全て格納されている。フレーム画像７０３から順に７０２までのフレーム画像をＧＵＩ部２１２へ転送することにより、巻き戻し再生が行なわれる。それと同時にフレーム画像７０２とフレーム画像７０１との間のフレーム画像を上記手順で取得して格納する。以上の処理は、フレーム画像７０１のように一定間隔であらかじめ画像バッファ２１０に格納されているフレーム画像がある限り続けることができる。
【００３３】
以上を整理すると、古いフレームを一定枚数当たり１枚保持しておけば、そのフレームを起点とすることにより、一定枚分のフレーム画像による巻き戻し再生を、ＭＰＥＧのような動き補償予測に基づく映像データを用いて実現可能となる。
【００３４】
ところで従来の方式では、このように一定枚数ごとにフレーム画像を保持する代わりに、ＭＰＥＧデータのＩピクチャを用いていた。ＭＰＥＧ−１、２のようにＩピクチャの間隔が一定であることが保証されているデータについては従来の方式で問題ないが、ＭＰＥＧ−４のようにＩピクチャの間隔が一定でなかったり、Ｉピクチャがまったく存在しないデータを作成することが可能な場合については、本発明の方式が有効であるといえる。
【００３５】
しかしこの巻き戻し処理を続けると、最後には一定間隔に配置されたフレーム画像もなくなる。これが画像バッファ２１０のメモリ量の制限によることは既に説明した。図６（ｄ）はそのときの様子を示している。フレーム画像７０１は、あらかじめ画像バッファ２１０に格納されていた最も古いフレーム画像である。それより古いものは、既に画像バッファ２１０内には存在しない。ＭＰＥＧデータは多くの場合前後のフレーム画像との差分の情報のみを保持しているため、基本となるフレーム画像がないとＭＰＥＧデータだけを取得してもフレーム画像を生成することができない。その結果、フレーム画像７０１より前のフレーム画像を生成する目的でＭＰＥＧデータを取得してきても、フレーム画像は得られない。そこでここで初めて従来の方式であるＩピクチャを利用した巻き戻し再生を実行する。すなわちフレーム画像を保持していなくてもＶＯＤサーバ１０１からＩピクチャを得ることができれば、そこまでさかのぼってフレーム画像を取得できることになる。ＩピクチャはＶＯＤサーバ１０１側でＭＰＥＧファイル内をサーチすることによって、その場所を特定できる。フレーム画像７００がそのようにして得られたＩピクチャであるとすると、フレーム画像７０１より古いフレーム画像７００までのフレーム画像を取得できる。このようにすれば、画像バッファ２１０のメモリ量の限界により画像バッファ２１０内にあらかじめフレーム画像を保持していなくても巻き戻し再生を続けることが可能となる。
【００３６】
ただしここで問題がある。フレーム画像７０１とＩピクチャであるフレーム画像７００の間が何フレーム分離れているかは、ＭＰＥＧデータに依存する。ＭＰＥＧ−１、２ではＩピクチャの間隔は一定だが、ＭＰＥＧ−４の場合は可変である。もしこの間隔がフレーム画像７０２とフレーム画像７０１の間隔より大きい場合、ＶＯＤサーバ１０１からＭＰＥＧデータを取得するのにかかる時間が増大し、図４におけるＮの値が増えることになる。それに対してその時点で再生中のフレーム画像、すなわちフレーム画像７０２からフレーム画像７０１までの間は変わらないので、図４のＣの値は変わらないことになる。その結果、Ａ＋Ｎ＜Ｃが満たせなくなる可能性がある。これが満たせないと、巻き戻し再生が一瞬止まって見えるという結果になる。
【００３７】
Ａ＋Ｎ＜Ｃという式は、以上に説明したように、メモリ量の限界のため、保持しているフレーム画像がなくなった場合に起きる可能性がある他、巻き戻し再生の倍速度が大きかったり、ネットワークの伝送速度が小さい場合にもおきる。これはＮが倍速度や伝送速度に依存するからである。この場合、連続した巻き戻し再生（「連続巻き戻し」と呼ぶことにする）は不可能である。そこで、別の方式の巻き戻し再生を用意する。
【００３８】
それは、巻き戻しの際にＩピクチャのみをＶＯＤサーバ１０１から視聴端末１０２に送出させるものである（これを「間引き巻き戻し」と呼ぶことにする）。これにより、ネットワーク１００を通るＭＰＥＧデータ量が減るので、Ａ＋Ｎ＜Ｃという式のＮが減ることになる。その結果、受信したＭＰＥＧデータを直ちに伸長し、フレーム画像を取得することができる。
【００３９】
図７は、画像バッファ２１０を管理する管理テーブル２１１の構成例を示している。９０１の列には、画像バッファ２１０に格納されているそれぞれのフレーム画像の時刻が格納されている。通常、ＭＰＥＧデータなどの映像データにはタイムスタンプと呼ばれる時間に関する情報が含まれている。「時刻」とは、それを意味する。９０２の列には、それぞれのフレーム画像が画像バッファ２１０内に存在するかどうかを「あり」「なし」で示している。
【００４０】
列９０１，９０２の各エントリは、再生すべきＭＰＥＧデータのフレームごとに作成される。ただし再生が始まるまでは、列９０１，９０２の内容は空である。再生が始まった後、伸長によりフレーム画像が生成されると、管理テーブル２１１に追加される。その際、時刻でソートされるように追加される。管理テーブル２１１に追加された直後は、「存在」は「あり」であるが、図５で説明した処理手順によりフレーム画像が削除されると、対応するエントリの「存在」が「なし」に変更される。
【００４１】
９０３は、フレームの種類を示している。Ｉピクチャかそうでないかの区別をするものである。この情報は、メモリの制約により保持しているフレーム画像がなくなったためにＩピクチャを起点に巻き戻し画像を生成する際に、Ｉピクチャを探索する効率を上げるために使用される。
【００４２】
９０４には、現在時刻を格納している。これは列９０１内のフレームの時刻のいずれかをさしている。形式は、ｈｈ：ｍｍ：ｓｓ：ｆｆで、
ｈｈ＝時間、ｍｍ＝分、ｓｓ＝秒、ｆｆ＝フレーム番号
を意味する。９０５には、伝送速度を格納する。これは視聴端末の属性から得られるか、視聴者が手で入力することによって設定される。９０６には、視聴者が指定する特殊再生の倍速度を格納する。図９で説明するＧＵＩ部２１２から入力される。
【００４３】
制御部２０８は、管理テーブル２１１を参照することにより、巻き戻し再生の際、何枚前のフレーム画像が画像バッファ２１０に保持されているかを知ることができる。何枚前にあるかを知ることにより、ＶＯＤサーバ１０１にそのフレーム画像から後のフレーム画像を再生するためのＭＰＥＧデータの要求を出すことが可能となる。
【００４４】
巻き戻し再生の処理は、上述したようにＡ＋Ｎ＜Ｃが満たせる場合とそうでない場合で、大きく方式を変えることになる。そこで全体の処理としては、図８に示すフローチャートのようになる。
【００４５】
以下、図８のフローチャートを用いて、巻き戻し再生を行なうための制御部２０８の処理の流れを説明する。この処理手順は、入力装置からの巻き戻し再生の指示に応答して、巻き戻し処理を開始するときおよび所定数の連続フレームの巻き戻し再生が終了するごとに実行される。制御部２０８は、管理テーブル２１１から伝送速度と倍速度を取得する（ステップ３０１）。次に「連続巻き戻し」が可能か否か判定する（ステップ３０２）。判定基準は、伝送速度と倍速度をもとに上記の式に従って「連続巻き戻し」ができるか否か、あるいは後述の「連続巻き戻し」フラグがオンか否かである。
【００４６】
「連続巻き戻し」が可能であれば、制御部２０８は、管理テーブル２１１上で連続して画像バッファ２１０に存在するフレームを探索する（ステップ３０３）。所定数の連続フレームが存在すれば（ステップ３０４ＹＥＳ）、ＧＵＩ部２１２を駆動し、画像バッファ２１０上に所定数格納される連続フレームの巻き戻し再生を開始する（ステップ３０５）。次に制御部２０８は、管理テーブル２１１上で一定間隔ごとに存在するフレームで次に新しいフレームを探索する（ステップ３０６）。フレームが存在すれば（ステップ３０７ＹＥＳ）、プロトコル処理部２０７を駆動し、ＶＯＤサーバ１０１からこのフレームに連続する連続フレームの取得を開始する（ステップ３０８）。これによって巻き戻し再生動作と圧縮映像データの取得動作とが並行して実行される。フレームが存在しなければ（ステップ３０７ＮＯ）、次に巻き戻し処理が起動されたとき「間引き巻き戻し」を行うためにプログラム中の「連続巻き戻し」フラグをオフにする（ステップ３０９）。
【００４７】
制御部２０８は、「連続巻き戻し」が不可能と判定すれば（ステップ３０２ＮＯ）、「間引き巻き戻し」を実行する。制御部２０８は、画像バッファ２１０上で巻き戻し再生の済んだフレーム画像を削除するために管理テーブル２１１上でそのフレームの「存在」を「なし」に変更する。またプロトコル処理部２０７及びデコーダ２０９を介しＶＯＤサーバ１０１から取得したフレーム画像を画像バッファ２１０に格納するごとにそのフレーム画像についてのエントリを管理テーブル２１１に登録する。そのとき登録するフレームの「存在」を「あり」に設定する。
【００４８】
図９は、通常再生、連続巻き戻し再生及び間引き巻き戻し再生の画面遷移の様子を説明する図である。枠内の数字はフレーム番号である。通常再生ではすべてのフレーム画像が正順に表示されるのに対し、連続巻き戻し再生ではすべてのフレーム画像が逆順に表示される。連続巻き戻し再生中に画像バッファ２１０に連続するフレーム画像を補充するときも表示画面上にはフレーム画像が途切れることなく連続して再生表示される。また間引き巻き戻し再生では飛び飛びのフレーム画像が逆順に表示される。
【００４９】
図１０は、ディスプレイ２０２の表示画面の例を示す図である。表示画面は、ＭＰＥＧ映像を表示する領域１００１と、視聴者の再生指示を入力するコントロールパネル１００２からなる。１００３は巻き戻し再生を指示するボタン、１００４は停止を指示するボタン、１００５は通常再生を指示するボタン、１００６は一時停止を指示するボタン、１００７は早送り再生を指示するボタンである。これらのボタンは、マウス２１４を用いて押すことができる。１００８は、現在表示している映像の時刻を表示する領域で、この領域に時刻を入力すると、その時刻から再生を開始することも可能である。この「時刻」は、図７の管理テーブル２１１の「現在時刻」に相当する。１００９は速度調整バーで、再生の倍速度を指定するためにある。図の例では−５から５までの数字がふられている。バーがどの数字の場所にあるかで、再生の倍速数を表している。たとえば、３の上へ移動させると、それは３倍速の速さで再生、つまり早送り再生を行なうことを意味する。このバーもマウス２１４を用いて移動することができる。このバーは、１００３から１００７の再生速度を指定するボタンと一部機能が重なるので、連動して動く。例えばバーを０の場所に移動させると停止ボタン１００４が押された状態になり、バーを−４の上へ移動させると巻き戻しボタン１００３が押された状態になる、といった具合である。この速度調整バー１００９の代わりに、ジョグシャトル２１３を使用することも可能である。これを用いると、円形状の装置を回転させることによって、倍速度を指定することができる。手をはなすと中間の状態で停止する。これが倍速度０にあたる。時計回りに回すと、倍速度を＋の値に指定することができる。多くの角度を回すと、倍速度を大きくすることができる。
【００５０】
本発明の映像再生方式は、このようなユーザインタフェースを備えている視聴端末において、巻き戻し再生指示が出された場合に、スムーズな巻き戻し再生を行なうことを可能とするものである。
【００５１】
以上に述べてきたように、本発明の映像再生方式を用いると、ＭＰＥＧなどの動き補償予測アルゴリズムに基づく圧縮映像データを配信するＶＯＤサーバの視聴端末において、巻き戻し再生をスムーズに実現することが可能となる。なお、この方式はＶＯＤサーバ／クライアントシステムのみならず、ローカルハードディスク装置内のＭＰＥＧ映像を再生する再生装置にも適用可能である。
【００５２】
【発明の効果】
本発明の映像再生方式を用いると、ＭＰＥＧなどの動き補償予測符号化方式による映像データからフレーム画像を生成して再生表示する視聴端末において、巻き戻し再生をスムーズに行うことが可能となる。
【図面の簡単な説明】
【図１】視聴端末内部の構成例を示す図である。
【図２】本発明の映像再生方式が適用される環境の一例を示す図である。
【図３】従来の巻き戻し再生方式を説明する図である。
【図４】実施形態の巻き戻し再生方式を説明する図である。
【図５】通常再生時に画像バッファ内に残すフレーム画像の変遷の例を示す図である。
【図６】巻き戻し再生を行う際に画像バッファ内に生成、削除するフレーム画像の遷移の例を示す図である。
【図７】管理テーブル２１１の構成例を示す図である。
【図８】実施形態において巻き戻し再生を行う制御手順を示すフローチャートである。
【図９】各種再生について画面遷移の様子を説明する図である。
【図１０】ディスプレイ２０２の表示画面の例を示す図である。
【符号の説明】
１０１：ＶＯＤサーバ、１０２：視聴端末、２０７：プロトコル処理部、２０８：制御部、２０９：デコーダ、２１０：画像バッファ、２１１：管理テーブル、２１２：ＧＵＩ部
【図１】
2004159034.tif 000003
【図２】
2004159034.tif 000004
【図３】
2004159034.tif 000005
【図４】
2004159034.tif 000006
【図５】
2004159034.tif 000007
【図６】
2004159034.tif 000008
【図７】
2004159034.tif 000009
【図８】
2004159034.tif 000010
【図９】
2004159034.tif 000011
【図１０】
2004159034.tif 000012