JP2005184429A

JP2005184429A - 映像データ処理方法および映像データ処理装置

Info

Publication number: JP2005184429A
Application number: JP2003422024A
Authority: JP
Inventors: Yoshiaki Kusunoki; 恵明楠; Takeshi Abe; 毅安部
Original assignee: Mitsubishi Electric Corp
Current assignee: Mitsubishi Electric Corp
Priority date: 2003-12-19
Filing date: 2003-12-19
Publication date: 2005-07-07
Anticipated expiration: 2023-12-19
Also published as: EP1699240A1; JP4118232B2; EP1699240B1; US20070140647A1; EP1699240A4; WO2005062614A1; US7613381B2

Abstract

【課題】ネットワーク上でサーバと端末間で特殊再生を行う場合、Ｉフレームのみを利用すると必要とするネットワーク帯域が上昇したり、デコーダバッファの破綻を生じる可能性があり、特殊再生ストリームを再生するデコーダで映像の乱れを生じる可能性があった。
【解決手段】抽出部１２で通常再生ストリームからＩフレームを抽出し、デコーダバッファ計算部１４およびフレーム内符号化ピクチャデータ変換処理部１５で上記Ｉフレームの符号化パラメータおよびVBV Delay等のデコーダバッファに関する制御パラメータを特殊再生用に変更し、リピートピクチャ付加部１６で上記Ｉフレームと同じ内容を表示するリピートピクチャを生成した上で、上記Ｉフレームの後ろに付加し、さらに符号量制御部１７で転送レートの制御を行う。
【選択図】図１

Description

本発明は、映像をサーバに記録蓄積し、端末からの要求によって蓄積している映像ストリームを要求のあった端末に配信する映像配信システムにおいて、通常の再生に対して速度および／または再生方向を変更した、例えば早送り、早巻き戻し、一時停止などの特殊再生を実現するためのデータ処理方法およびデータ処理装置に関するものである。

従来、特にネットワークを利用した映像再生システムにおいて、ＭＰＥＧ−２等で圧縮された映像ストリーム（以下、特殊再生ストリームと区別するために通常再生ストリームと称する）について、再生の速度および／または再生方向を変更した特殊再生を実行しようとする場合、通常再生ストリームから時間的に断続したフレーム内符号化ピクチャ（Ｉフレーム）のみを抽出し、さらに抽出したＩフレームを連続的に端末に配信し、端末で受信後、再生する構成をとるのが一般的であった。

しかしながら、上記従来の方法では、通常再生ストリームからＩフレームのみを抽出するので、本来のＭＰＥＧ−２の構造から逸脱したストリームになる場合がある。そのため、Ｉフレームのみから構成される特殊再生ストリームの再生を可能にするために、再生側のデコーダに何らかの仕組みを用意しなければならない問題があった。

また、符号量の大きなＩフレームのみを高速に抽出し、連続して配信することから、単位時間当たりの転送符号量（転送レート）が非常に大きくなるために、伝送路上にあるバッファ、例えば多重装置や分離装置のバッファがオーバーフローを発生したり、ネットワークの帯域制限を越えたり、再生側のデコーダバッファがオーバーフローを発生したりする問題があった。そのため、転送レートが増大した特殊再生ストリームの転送を可能にするために、ネットワークの帯域を拡大したり、伝送路の各バッファメモリサイズを大きくしたりするなどの対策が必要であった。

特に、ネットワーク帯域についての問題は深刻で、Ｉフレームのみを利用した特殊再生方法では、Ｉフレームの符号量にもよるが、通常再生に比べて一般的に３倍程度の帯域を必要とした。しかし、現実的に特殊再生のために帯域を上げることは困難である。そこで、１つの対策として、特殊再生ストリームを別途用意する方法が用いられるが、この方法は、システムの構成上は簡単ではあるが、通常再生ストリームに加え、特殊再生ストリームを別途用意することなるため、蓄積するデータ量が多くなる上、通常再生ストリームと特殊再生ストリームを関連付けて管理することが必要であるという問題があった。

このような従来の問題について、特殊再生ストリームとしてフレームもしくはフィールド内符号化されたデータに続いて、マクロブロックの動きベクトルを０、予測誤差を０に符号化されたリピートピクチャを挿入し、データを配信する方法が提案された（例えば、特許文献１参照）。このリピートピクチャを挿入する方法によると、特殊再生の実行において、符号量の大きいＩフレームに続いて、符号量の非常に少ないリピートピクチャを追加することによって、転送レートを大幅に削減することができるので、転送レートの上昇を防ぎ、特殊再生用に大きなメモリを確保する必要がない。さらに、生成される特殊再生ストリームは、シンタックス的に通常再生ストリームと同じ構成にできるため、特殊ストリームを扱う上で、別途ロジックや回路の増設を必要とせず、特殊再生時に専用のロジックに切り替える必要もない。

また、ネットワーク上にあるサーバと端末との間における特殊再生時のデータ生成方法については、特殊再生を行う際に、通常再生ストリームから抽出したＩフレームと、保存されているリピートピクチャデータから、特殊再生ストリームを構築し、さらに抽出したＩフレームデータのVBV Delayに基づいて、ＶＢＶバッファを破綻させないようにリピーチピクチャに続いてスタッフィングを挿入する方法が提案された（例えば、特許文献２参照）。

特許第３３０４６３４号（第１０頁，図１）特開２００２−７７８１１号公報（第１２頁，図１）

しかしながら、上記リピートピクチャを挿入する従来技術では、Ｉフレームに続いてリピートピクチャを挿入するだけでは、生成された特殊再生ストリームにおける各フレームのデータとしては全く問題がなくとも、複数の連続した映像として見た場合、符号化されているパラメータについて整合性が取れない場合がある。例えば、元の通常再生ストリームに符号化されているパラメータである各フレームの再生順番、転送レート、デコーダバッファにおけるデータの滞在時間（VBV Delay）について、生成した特殊再生ストリームに対応した値になるように適正化を行っていなければ、特殊再生ストリームの再生が正しく行われず、結果として再生映像が乱れる可能性がある。特に、VBV Delayの値が正しくないと、再生側のデコーダバッファの破綻や、もし伝送路に多重装置が存在するならば、多重処理において多重ミスを発生する問題がある。通常VBV Delayを求めるには、ＶＢＶバッファのシミュレートを行う等、複雑な計算処理によって求めなくてはならず、システム負荷との兼ね合いもあり、実用の範囲で求めることができなかった。

また、上記リピーチピクチャに続いてスタッフィングを挿入する従来技術では、リピートピクチャを前もって用意し、特殊再生の状態や変換前の元ストリームの状態を常に管理しておく必要があり、プログラムの構造が複雑になり、リアルタイムかつ多くのストリームが並列で処理されるシステムには適していなかった。また、通常再生ストリームに符号化されているVBV Delayを特殊再生ストリームでも使用しているため、通常再生ストリームと同じデータサイズ分だけスタッフィングを行うことになる。そのため、ＶＢＶバッファの破綻を防ぐことは可能になるが、特殊再生ストリームの転送レートを削減することはもとより、特殊再生ストリームの転送レートを制御することはできない。また、特殊再生ストリームに埋め込まれた元ストリームの映像および圧縮に関するパラメータ（以下、符号化パラメータ）については、通常再生ストリームの値をそのまま流用し、特殊再生ストリームに対しての適正化が行われていない。そのため、一般的なＭＰＥＧ−２ストリームの規約から逸脱する場合があり、再生映像が乱れたり、多重装置において多重化が失敗したりする恐れがある。

このように、特殊再生を行う従来の技術では、通常再生ストリームから特殊再生ストリームを生成する場合に符号化パラメータの適正化を行っていないので、ネットワーク上でサーバと端末間で特殊再生を行う場合、Ｉフレームのみを利用すると必要とするネットワーク帯域が上昇したり、デコーダバッファの破綻を生じる可能性があり、特殊再生ストリームを再生するデコーダで映像の乱れを生じる可能性があった。

本発明は、このような従来の課題を解消するためになされたものであり、ネットワーク越しに特殊再生を行う場合に、映像の乱れの少ない映像データ処理方法および映像データ処理装置を提供するものである。

本発明の映像データ処理方法は、
フレーム間予測を用いて符号化された映像ストリームに対して、再生速度および再生方向を変更した特殊再生ストリームを生成する映像データ処理方法であって、
生成する特殊再生ストリームの速度と方向に合わせて、上記映像ストリームからフレーム内符号化ピクチャを選択的に抽出する工程と、
上記抽出したフレーム内符号化ピクチャの符号化パラメータを解析する工程と、
上記速度と方向に合わせて、上記符号化パラメータを変更する工程と、
上記抽出したフレーム内符号化ピクチャと同じ表示内容を示すリピートピクチャを生成する工程と、
上記リピートピクチャを、データの伝送順で上記再生速度および再生方向に基づいて選択される上記符号化パラメータを変更したフレーム内符号化ピクチャの後ろに続けて付加することによって、特殊再生ストリームを生成する工程と
を備えた
ことを特徴とする。

また、本発明の映像データ処理装置は、
フレーム間予測を用いて符号化された映像ストリームに対して、再生速度および再生方向を変更した特殊再生ストリームを生成する映像データ処理装置であって、
生成する特殊再生ストリームの速度と方向に合わせて、上記映像ストリームからフレーム内符号化ピクチャを選択的に抽出する手段と、
上記抽出されたフレーム内符号化ピクチャの符号化パラメータを解析する手段と、
上記速度と方向に合わせて、上記符号化パラメータを変更する手段と、
上記抽出されたフレーム内符号化ピクチャと同じ表示内容を示すリピートピクチャを生成する手段と、
上記リピートピクチャを、データの伝送順で上記再生速度および再生方向に基づいて選択される上記符号化パラメータを変更したフレーム内符号化ピクチャの後ろに続けて付加することによって、特殊再生ストリームを生成する手段と
を備えた
ことを特徴とする。

本発明によれば、生成する特殊再生ストリームの速度と方向に合わせて、映像ストリームからフレーム内符号化ピクチャを選択的に抽出し、そのフレーム内符号化ピクチャの符号化パラメータを解析し、上記速度と方向に合わせて、上記符号化パラメータを変更するとともに、上記フレーム内符号化ピクチャと同じ表示内容を示すリピートピクチャを生成し、上記リピートピクチャをデータの伝送順で上記符号化パラメータを変更したフレーム内符号化ピクチャの後ろに付加した特殊再生ストリームを生成することにより、特殊再生ストリームのネットワーク越しでの再生において、映像の乱れが発生することがないという効果がある。

実施の形態１．
図１はネットワーク上に映像を配信するサーバおよびこのサーバから配信された映像を受信して再生を行う端末から構成される本発明の実施の形態１の映像配信システムを示す図である。

この実施の形態１の映像配信システムでは、映像が記録された速度と同一の再生速度である通常再生と、通常再生に対して速度を変更した特殊再生、例えば通常再生の速度に対して２倍，５倍，１５倍等の速度を変えた早送り再生、さらに早送り再生に対して再生方向を逆にした早巻き戻し再生、また同じ映像を継続的に表示する一時停止を実現する。ここで、この実施の形態１で使用する映像ストリームは、ＩＳＯ／ＩＥＣ１３８１８−１、いわゆるＭＰＥＧ−２のプログラムストリームで記録されているものとする。

サーバ１は、蓄積部２と、読み出し部３と、スイッチ４，スイッチ６と、再生制御部５と、配信部７と、抽出部１２と、特殊再生処理部１１と、アドレスマップ２１とを備えている。

蓄積部２は、内部に映像ストリームを保存するために設けられたものであり、この蓄積部２には、通常再生ストリームが複数保存される。また、アドレスマップ２１には、蓄積部２に保存されている通常再生ストリームのＧＯＰ（Group of Picture）単位の再生タイムスタンプと、蓄積部２に保存されているアドレスとを対応付けたテーブルが保存されている。

読み出し部３は、再生制御部５からの指示により、アドレスマップ２１に記録されているタイムスタンプとアドレス情報をもとに、蓄積部２から該当ストリームの該当アドレスに記録されたＧＯＰデータを読み出す。

再生制御部５は、後述する端末５１〜５３からの再生要求が、通常再生か、特殊再生かによって読み出し部３，スイッチ４，スイッチ６を制御し、蓄積部２からのストリームの流れを制御する。

抽出部１２は、通常再生ストリームから、ＭＰＥＧ−２の映像単位の先頭を示すシーケンスヘッダから最初のピクチャデータであるフレーム内符号化ピクチャデータまでを抽出する。この実施の形態１では、通常再生ストリームはプログラムストリーム形式で保存されているので、上記抽出作業に並行して、プログラムストリームをエレメンタリーストリームに分離するデマルチプレックスも合わせて行う。

特殊再生処理部１１は、入力されたフレーム内符号化ピクチャの解析を行う解析部１３と、生成する特殊再生ストリームのデコーダバッファの計算を行うデコーダバッファ計算部１４と、入力されたフレーム内符号化ピクチャの符号化パラメータを変更するフレーム内符号化ピクチャデータ変換処理部１５と、フレーム内符号化ピクチャと同じ映像表示を行うリピートピクチャを生成するリピートピクチャ付加部１６と、生成する特殊再生ストリームの発生符号量を制御する符号量制御部１７と、特殊再生ストリームを通常再生ストリームと同じ形式のプログラムストリームに多重化を行うＰＳ化部１８とによって構成されており、通常再生ストリームのフレーム内符号化ピクチャを基に特殊再生ストリームの生成を行う。

特殊再生処理部１１において、解析部１３は、入力されたフレーム内符号化ピクチャのVBV Delay，テンポラル・リファレンス（Temporal Reference），ピクチャ・コーディング・タイプ（Picture Coding Type），符号量等の解析を行い、特殊再生処理部１１内で必要なパラメータを取得する。

また、特殊再生処理部１１において、デコーダバッファ計算部１４は、解析部１３から取得したパラメータをもとに、生成する特殊再生ストリームのVBV Delayの計算を行う。なお、VBV
Delayの計算方法については後述する。

また、特殊再生処理部１１において、フレーム内符号化ピクチャデータ変換処理部１５は、入力したフレーム内符号化ピクチャが生成する特殊再生ストリームに適するように、例えばTemporal ReferenceやVBV Delayおよびシーケンスヘッダ以降フレーム内符号化ピクチャまでのビット・レート・バリュー（Bit Rate Value）やＶＢＶ・バッファ・サイズ・バリュー（VBV Buffer Size Value）を変更する。

また、特殊再生処理部１１において、リピートピクチャ付加部１６は、先行するフレーム内符号化ピクチャと表示内容が同じになるように、動きベクトルを０かつ予測誤差を０に符号化し、かつスキップドマクロブロックを使用することによって符号量を大幅に削減したデータを生成する。

また、特殊再生処理部１１において、符号量制御部１７は、生成する特殊再生ストリームの目標転送レートに対して、発生する符号量を予測し、予測符号量が目標転送レートに比べて小さいなら、スタッフィングによって目標転送レートに近づけ、一方予測符号量が目標転送レートを上回りそうであれば、一時的に目標符号量を上げるとともに関連する例えばBit Rate ValueやＳＣＲの再調整を行い、ＭＰＥＧの規格に対して矛盾が生じない処理を行うことによって、発生符号量の制御を行う。

また、特殊再生処理部１１において、ＰＳ化部１８は、ビデオエレメンタリーストリームの形式で生成された特殊再生ストリームをパック単位に分割し、プログラムストリームの形式に変換を行う。

配信部７は、通常再生ストリームおよび特殊再生ストリームについて、例えば映像をストリーミング再生するための伝送プロトコルであるＲＴＰ（Real-time Transport Protocol）に従って、ネットワーク３１を介して配信要求がなされた端末５１に対して配信を行う。

次に、端末５１〜５３の構成について説明する。端末５１〜５３は全て同一構成をとるため、ここでは端末５１について説明を行う。

端末５１は、ネットワーク３１を介して接続されたサーバ１に対して配信を要求し、その際に希望する映像ストリームの種類、通常再生か特殊再生か、特殊再生の場合は再生方向と再生速度を指定する。また、端末５１は、サーバ１から配信された映像ストリームを受信し、さらにデコードすることによって通常再生および特殊再生を行う。

この端末５１は、ユーザからの操作を受け付ける再生入力部４１と、受け付けたユーザの要求を内部のコマンドに変換してネットワークを介してサーバ１に送信する再生指示部４２と、サーバ１からの映像ストリームを受信する受信部４３と、受信した映像ストリームをデコードするデコーダ部４４と、デコードした映像を表示する表示部４５とによって構成される。

端末５１において、再生入力部４１は、ユーザが再生を希望するストリームの種類および通常再生、早送り、早巻き戻し、一時停止等の再生状態の受け付けを行う。また、再生指示部４２は、ネットワーク３１を介してサーバ１に論理的に接続されている。再生入力部４１で受け付けられたユーザ要求が再生指示部４２で内部のコマンドに変換され、接続されたサーバ１に送信される。また、受信部４３は、端末５１で受信すべきストリームの受信を行い、受信したＲＴＰパケットから必要な映像ストリームを抜き出す。また、デコーダ４４は、ＭＰＥＧ−２で圧縮されたストリームをデコードし、表示部４５で表示を行う。

次に、実施の形態１の動作について説明する。まず、端末５１においてユーザが視聴したいデータを通常再生する場合について説明する。端末５１では、ユーザがリクエストしたストリームの種類および再生状態（通常再生）が再生入力部４１に入力され、再生指示部４２は、ユーザのリクエスト内容を内部のコマンドに変換し、ネットワーク３１を経由してサーバ１の再生制御部５に命令を送信する。

再生制御部５は、再生指示部４２からの命令を受信し、命令の内容に従って、読み出し部２，スイッチ４，スイッチ６を制御する。今回の場合、通常再生が指示されているので、スイッチ４をａ側に、スイッチ６をｃ側に設定する。

さらに、再生制御部５は、再生すべきストリームについて、アドレスマップ２１に保持されている、タイムスタンプと蓄積部２の蓄積アドレスとを対応付けたテーブルをもとに、再生すべきタイムスタンプから蓄積アドレスを求め、読み出し部３に対してこの求めたアドレスに記録された１つのＧＯＰデータを読み出すように指示を出す。

読み出し部３は、指示されたアドレスに記録されたＧＯＰデータを蓄積部２から読み出し、読み出したＧＯＰのデータをスイッチ４およびスイッチ６を経由して配信部７に送る。

配信部７は、プログラムストリーム形式の通常再生ストリームをＲＴＰパケット化し、ネットワーク帯域と転送レートおよび再生タイムスタンプを鑑みながら、ネットワーク３１に配信を行う。このとき、ＲＴＰパケットはリクエストのあった端末５１のＩＰアドレスを指定して送信が行われ、別の端末が誤って受信しないようになっている。

このようにして１ＧＯＰの配信が終了すると、再生制御部５は、次の配信すべきタイムスタンプと蓄積アドレスをアドレスマップ２１から求め、次の再生すべきＧＯＰの蓄積アドレスを読み出すように読み出し部３に指示を出す。読み出されたＧＯＰデータは、配信部７により、先のＧＯＰデータに続いて配信が行われる。この動作を繰り返すことによって、通常再生ストリームが順次読み出され、ＲＴＰパケット化されたデータとしてネットワークに送出される。

次に、端末５１における通常再生ストリームの受信動作を説明する。端末５１においては、受信部４３は、ネットワーク３１を経由してサーバ１から送信されたＲＴＰパケットの内、送信先として端末５１のＩＰアドレスが指定されたＲＴＰパケットのみを受信する。さらに、受信部４３は、受信したＲＴＰパケットから再生に不要なＲＴＰパケットヘッダを取り除き、プログラムストリームに変換する。このプログラムストリームは、デコーダ４４にてＭＰＥＧ−２のデコードを行い、表示部４５で表示を行う。

ＲＴＰパケットは、端末５１の受信および再生状態によらず、サーバ１から次々と送信されてくる。よって、受信部４３は、送信先として端末５１のＩＰアドレスが記述されたＲＴＰパケットであれば全て受信を行い、受信したデータを次々とデコーダ４４へ送信を行う。このような動作により、サーバ１と端末５１間のＲＴＰ通信による通常再生が可能となっている。

次に、特殊再生の動作を説明する。まず、早送りの特殊再生について説明する。端末５１において、ユーザが特殊再生、例えば早送りの指示を再生入力部４１に行うと、再生指示部４２は、ネットワーク３１を経由して対応する命令をサーバ１の再生制御部５に伝える。再生制御部５は、特殊再生を行う場合、スイッチ４をｂ側に、スイッチ６をｄ側に設定し、特殊再生処理部１１に映像ストリームが流れるようにする。

この実施の形態１では、早送りを行う場合、全てのＧＯＰを再生するのではなく、早送りの速度に応じて幾つかのＧＯＰをスキップする。スキップするＧＯＰの数は、特殊再生ストリームに付加されるリピートピクチャ数にも依存する。例えば、リピートピクチャを２個使用し、ＧＯＰあたり３つのピクチャからなる特殊再生ストリームを構成する場合、５倍速の早送りであれば通常再生ストリームの全てのＧＯＰを読み出し、１５倍速であれば３ＧＯＰ毎に該当ＧＯＰを読み出すような構成をとる。

再生制御部５は、早送りの速度に合わせて、アドレスマップ２１に保持されたタイムスタンプと蓄積アドレスの対応テーブルから、早送りとして再生すべきタイムスタンプに対応する蓄積アドレスを求め、その蓄積アドレスを蓄積部２から読み出すように読み出し部３に命令を送る。

読み出し部３は、蓄積アドレスに記録された特殊再生を行うストリームのＧＯＰデータを蓄積部２から読み出し、スイッチ４を経由して抽出部１２に送る。抽出部１２は、プログラムストリームの形式である通常再生ストリームをビデオエレメンタリーにデマルチプレックスし、さらにフレーム内符号化ピクチャのみを抽出する。抽出したフレーム内符号化ピクチャは特殊再生処理部１１に送られ、特殊再生ストリームを生成する処理が行われる。

特殊再生処理部１１では、まず最初に、解析部１３において、入力されたフレーム内符号化ピクチャからVBV Delay，Temporal Reference，Picture Coding Type，符号量等のパラメータを抽出および解析を行う。そして、生成する特殊再生ストリームのフレーム構成を組み立てる。

図２に特殊再生処理部１１で生成される早送りの特殊再生ストリームのフレーム構成を示す。図２（ａ）は、特殊再生ストリームを生成する元となる通常再生ストリームであり、この通常再生ストリームは、Ｍ＝３，Ｎ＝１５のＧＯＰ構造を持つ。また、図２（ｂ）は、図２（ａ）の通常再生ストリームから生成した早送りの特殊再生ストリームであり、通常再生ストリームのフレーム内符号化ピクチャＩ_０と、このＩ_０に続いてＩ_０の表示内容を繰り返す２フレームのリピートピクチャＢ_Ｒを続けて付加することで特殊再生ストリームを構成する。さらにその後には、上述のフレーム内符号化ピクチャＩ_０に対応する特殊再生ストリームに続いて、次のＧＯＰのフレーム内符号化ピクチャＩ_１５と２個のリピートピクチャＢ_Ｒを続けて付加することにより構成された特殊再生ストリームが再生速度および再生方向に基づく特殊再生ストリームとして生成される（すなわち、上記フレーム内符号化ピクチャＩ_０およびそれに続くフレーム内符号化ピクチャＩ_１５が再生速度および再生方向に基づいて選択される符号化パラメータを変更したフレーム内符号化ピクチャに相当する）。

図２（ａ）と図２（ｂ）を比較するとわかるように、元がＧＯＰ内のフレーム数が１５フレームである通常再生ストリームに対して、特殊再生ストリームではＧＯＰ内のフレーム数が３にまで削減されており、結果として５倍速の早送り映像表示を行うことができる。

同様に、フレーム内符号化ピクチャＩ_０と２個のリピートピクチャＢ_Ｒの後ろに、Ｉ_１５を続けずに、図示されていないがさらに次のＧＯＰのフレーム内符号化ピクチャであるＩ_３０と２個のリピートピクチャＢ_Ｒを続けることによって、１０倍速を実現できる。このように、早送りの速度に合わせて通常再生ストリームからＩフレームを選択的に抽出することによって、早送りの速度を調整することができる。

一方で、リピートピクチャとは、フレーム内符号化ピクチャの表示内容を繰り返して表示するように符号化されたもので、例えば動きベクトル０、予測誤差０となるように符号化を行っており、さらにデータ量削減のためマクロブロックの符号化を省略したスキップドマクロブロックを使用する。ここでは、リピートピクチャの符号化方式として、双方向予測ピクチャを用いることとするが、順方向予測ピクチャを用いてもよい。

このようなリピートピクチャを用いることによって、図２で示すように、この実施の形態１の特殊再生ストリームでは通常再生ストリーム１つのＧＯＰ内のＢ_１からＢ_１４までのピクチャデータを一切使用せず、２個のリピートピクチャＢ_Ｒと若干のスタッフィングで置き換えるので、符号量が非常に小さくなるとともに、生成された特殊再生ストリームを構成するフレーム内符号化ピクチャＩ_０と２個のリピートピクチャＢ_Ｒから構成されるＧＯＰの転送レートも小さくすることができる。

そのため、一般的な特殊再生として行われるＩフレームのみの転送では、その転送レートが非常に大きくなるのに対して、この実施の形態１の特殊再生方法による特殊再生ストリームでは、転送レートの上昇を防ぐことができる。例えば、６［Ｍｂｐｓ］の転送レート、１ＧＯＰが１５フレームからなる通常再生ストリームについてＩフレームのみを転送することによって１５倍速の特殊再生を行う場合、一般的に１８［Ｍｂｐｓ］の帯域が必要となる。

しかしながら、この実施の形態１のようにリピートピクチャを２個利用した特殊再生では、全てのＧＯＰを再生した場合は５倍速の再生速度で６［Ｍｂｐｓ］、３ＧＯＰ毎の再生であれば１５倍速でも同じく６［Ｍｂｐｓ］の帯域で特殊再生を行うことができる。この構成をとった特殊再生ストリームについて再生を行うと、同じ映像が３フレーム分再生されるが、視覚上全く問題がない。

なお、ピクチャタイプは、この実施の形態１では双方向予測ピクチャとするが、順方向予測ピクチャであってもよい。また、この実施の形態１では、リピートピクチャを２個使用する構成をとっているが、その理由は、例えば通常再生ストリームの転送レートが６［Ｍｂｐｓ］の場合に、特殊再生ストリームも同じ６［Ｍｂｐｓ］程度の転送レートにしたい場合に適切な数であるためであり、必要に応じてリピートピクチャの数を変更してもよい。

次に、解析部１３で得られたVBV Delayおよび通常再生ストリームの符号量をもとに、デコーダバッファ計算部１４では、特殊再生ストリームのVBV Delayの計算を行う。通常、VBV
Delayは、連続するストリームのＶＢＶバッファに占めるピクチャデータの遷移を示し、ＶＢＶバッファのオーバーフローおよびアンダーフローを発生させないような値でなければならない。よって、VBV Delayを決定する場合、ＶＢＶの遷移をシミュレートすることによって正確な値の制御を行うことが必要となる。しかしながら、ＶＢＶバッファの遷移を常にシミュレートすることは、計算負荷が大きく、現実的でない。そこで、この実施の形態１では、デコーダバッファ計算部１４において、VBV Delayが簡単な算術計算によって導出する。なお、特殊再生ストリームのVBV Delayが簡単な算術計算によって導出できることおよび詳細な計算方法については後述する。

フレーム内符号化ピクチャデータ変換処理部１５では、生成される特殊再生ストリームに対応したフレーム内符号化ピクチャになるように、そのTemporal ReferenceやVBV Delayおよびシーケンスヘッダからフレーム内符号化ピクチャまでのBit Rate ValueやVBV Buffer Size Valueが変更される。例えば、通常再生ストリームにおいてフレーム内符号化ピクチャのTemporal Referenceが２であり、特殊再生ストリームでリピートピクチャを１個付加する場合は、Temporal Referenceは１に変更される。また、VBV Delayも、デコーダバッファ計算部１４で計算された特殊再生ストリーム用のVBV Delayに置き換えられる。

リピートピクチャ付加部１６では、フレーム内符号化ピクチャの表示内容と同じ表示を行うリピートピクチャのデータを生成し、フレーム内符号化ピクチャの後ろに符号化を行う。さらに、符号量制御部１７では、予測する符号量が目標とする転送レートに対して少ないようであればスタッフィングを行い、上回るようであれば目標転送レートを一時的に上昇させて、生成する特殊再生ストリームのデータが転送できるように調整を行う。最後に、ＰＳ化部１８では、生成された特殊再生ストリームをプログラムストリームにマルチプレックスを行う。

以上のようにして特殊再生処理部１１で生成された特殊再生ストリームは、スイッチ６を経由して配信部７に送られる。配信部７では、通常再生ストリームと同様に、リクエストを行った端末を送信先ＩＰアドレスとしてＲＴＰパケット化を行い、配信を行う。この操作を、特殊再生ストリームとして利用するＧＯＰ単位で繰り返すことによって、特殊再生ストリームの配信が行える。

次に、端末５１における特殊再生ストリームの受信動作を説明する。端末５１では、通常再生ストリームを受信するのと同様に、受信部４３は、ネットワーク３１を経由してサーバ１から送信されたＲＴＰパケットの内、送信先として端末５１のＩＰアドレスが指定されたＲＴＰパケットのみを受信する。さらに、受信部４３は、受信したＲＴＰパケットから再生に不要なＲＴＰパケットヘッダを取り除き、プログラムストリームに変換する。

プログラムストリームに戻された特殊再生ストリームは、映像ストリームの内容は特殊再生である早送り映像であるが、シンタックス上は通常のプログラムストリームと何ら変わりがない。そのため、通常再生と同様に、デコーダ４４にてＭＰＥＧ−２のデコードを行い、表示部４５に再生画を表示することが可能である。

図３に一時停止の場合の特殊再生ストリームのフレーム構成を示す。図３（ａ）は、特殊再生ストリームを生成する元となる通常再生ストリームであり、この通常再生ストリームは、Ｍ＝３，Ｎ＝１５のＧＯＰ構造を持つ。また、図３（ｂ）は、図３（ａ）の通常再生ストリームから生成した一時停止の特殊再生ストリームであり、図２（ｂ）で示した早送り再生の構成に対して、使用するＩフレームが常に同じＩ_０を用いる以外、同じ構成をとる。

一時停止においては、通常再生ストリームにおける一時停止として表示したいＧＯＰのフレーム内符号化ピクチャＩ_０を利用し、このＩ_０に続いてＩ_０の表示内容を繰り返す２フレームのリピートピクチャＢ_Ｒを続けて付加することで特殊再生ストリームを構成する。さらにその後には、上述のフレーム内符号化ピクチャＩ_０に対応する特殊再生ストリームに続いて、同じ映像を構成するために、この同じＩ_０と２個のリピートピクチャＢ_Ｒを続けて付加することにより構成された特殊再生ストリームが再生速度および再生方向に基づく特殊再生ストリームとして生成される（すなわち、上記フレーム内符号化ピクチャＩ_０およびそれに続く同じフレーム内符号化ピクチャＩ_０が再生速度および再生方向に基づいて選択される符号化パラメータを変更したフレーム内符号化ピクチャに相当する）。このような構成により、継続的に同じ映像を示す一時停止用の特殊再生ストリームを構成できる。一時停止の場合は継続的に同じ映像を表示すればいいので、リピートピクチャＢ_Ｒの数を増やすことによって、サーバおよびネットワークの負荷を下げるようにすることもできる。

次に、図１を用いて、一時停止を行う動作について説明する。図１において、再生制御部５は、アドレスマップ２１を参照しながら常に同じタイムスタンプデータの蓄積アドレスを蓄積部２から読み出すように、読み出し部３に対して指示を行う。読み出されたＧＯＰデータは、特殊再生処理部１１によって図３（ｂ）に示すような一時停止の特殊再生ストリームに変換され、配信部７から端末５１に対して配信が行われる。生成された一時停止用の特殊再生ストリームは、継続的に同じ再生画が表示されるデータ構造を持ち、端末５１は、通常再生や早送りのときと同じように、順次デコードおよび再生処理を継続するだけで、一時停止の再生画を表示することができる。

図４に早巻き戻しの場合の特殊再生ストリームのフレーム構成を示す。図４（ａ）は、特殊再生ストリームを生成する元となる通常再生ストリームであり、この通常再生ストリームは、Ｍ＝３，Ｎ＝１５のＧＯＰ構造を持つ。また、図４（ｂ）は、図４（ａ）の通常再生ストリームから生成した早巻き戻しの特殊再生ストリームである。

早巻き戻しでは、時間的に後の映像が先に表示されるように構成されなければならない。そのため、早巻き戻しの特殊再生ストリームは、通常再生ストリームの時間的に後のフレーム内符号化ピクチャＩ_１５と、このＩ_１５に続いてＩ_１５の表示内容を繰り返す２フレームのリピートピクチャＢ_Ｒを続けて付加することで特殊再生ストリームを構成する。さらにその後には、上述のフレーム内符号化ピクチャＩ_１５に対応する特殊再生ストリームに続いて、前のＧＯＰのフレーム内符号化ピクチャＩ_０と２個のリピートピクチャＢ_Ｒを続けて付加することにより構成された特殊再生ストリームが再生速度および再生方向に基づく特殊再生ストリームとして生成される（すなわち、上記フレーム内符号化ピクチャＩ_１５およびそれに続くフレーム内符号化ピクチャＩ_０が再生速度および再生方向に基づいて選択される符号化パラメータを変更したフレーム内符号化ピクチャに相当する）。このような構成により、表示映像の順が通常再生ストリームと反対になった早巻き戻し再生用の特殊再生ストリームを生成することができる。

図４（ａ）と図４（ｂ）を比較するとわかるように、元がＧＯＰ内のフレーム数が１５フレームである通常再生ストリームに対して、特殊再生ストリームではＧＯＰ内のフレーム数が３にまで削減されており、結果として５倍速の早巻き戻し映像表示を行うことができる。さらに、作成する特殊再生ストリームに使用するフレーム内符号化ピクチャを２ＧＯＰ毎にすれば１０倍速、３ＧＯＰ毎にすれば１５倍速の早巻き戻しが可能である。

次に、図１を用いて、早巻き戻しを行う動作について説明する。図１において、再生制御部５は、早巻き戻しの速度に合わせて、読み出すべき通常再生ストリームのタイムスタンプを決定する。さらに、アドレスマップ２１を参照し、読み出すべきタイムスタンプデータの蓄積アドレス決定し、蓄積部２から該当ＧＯＰデータを読み出す。読み出されたＧＯＰデータは、特殊再生処理部１１によって早巻き戻しの特殊再生ストリームに変換される。同様に、早巻き戻し速度に合わせて、次の読み出しタイムスタンプを決定し、アドレスマップ２１から蓄積アドレスを求め、該当ＧＯＰデータを蓄積部２から読み出し、特殊再生処理部１１に送り込む動作を続けることによって、図４（ｂ）に示すような早巻き戻しの特殊再生ストリームが生成される。生成された早巻き戻しの特殊再生ストリームは、配信部７から端末５１に対して配信が行われる。この早巻き戻しの特殊再生ストリームは、再生画が時間的に逆になったデータ構造を持ち、端末５１は通常再生のときと同じように順次デコードおよび再生処理を継続するだけで早巻き戻しの再生画を表示することができる。

次に、特殊再生ストリームにおけるVBV Delayの導出方法について説明する。図５（ａ）は通常再生ストリームにおける仮想デコーダのＶＢＶバッファの遷移を示した図であり、図５（ｂ）は特殊再生ストリームにおける仮想デコーダのＶＢＶバッファの遷移を示した図である。図５（ａ）および図５（ｂ）の両図とも、横軸に時間、縦軸にＶＢＶバッファの占有量を示し、実線がＶＢＶバッファの遷移を示している。

図５において、ＶＢＶバッファの実線の傾きａ_Ｎは、通常再生ストリームの転送レートを表している。先頭のＩピクチャは、転送レートａ_ＮでＶＢＶバッファに充填が行われ、VBV Delayで示されるτ_Ｎ０時間後にデコードが開始される。そのとき、Ｉピクチャのデータ量であるｄ_Ｎ０がＶＢＶバッファから抜き去られる。

次のピクチャは、先頭ピクチャの充填が完了し次第すぐに充填が開始され、同じくτ_Ｎ１時間後にｄ_Ｎ１がＶＢＶバッファから抜き去られる。このとき、隣接するピクチャの充填開始時間の差ｘ_Ｎ０は、
ｘ_Ｎ０＝τ_Ｎ０＋Δｆ−τ_Ｎ１…（１）
で表される。ここで、Δｆは表示フレームの間隔であり、ＮＴＳＣでは１／２９．９７である。また、転送レートａ_Ｎと符号量ｄ_Ｎ０との間には、
ｄ_Ｎ０＝ａ_Ｎ×ｘ_Ｎ０…（２）
という関係がある。

一方、図５（ｂ）に示される特殊再生ストリームについても、上記通常再生ストリームと同じ関係がある。つまり、
ｘ_Ｔ０＝τ_Ｔ０＋Δｆ−τ_Ｔ１…（３）
ｄ_Ｔ０＝ａ_Ｔ×ｘ_Ｔ０…（４）
である。ここで、ｘ_Ｔ０は特殊再生ストリームの先頭Ｉピクチャと次のピクチャの充填開始時間の差、ｘ_Ｔ１は特殊再生ストリームの２番目のピクチャと３番目のピクチャの充填開始時間の差、τ_Ｔ０は特殊再生ストリームの先頭ＩピクチャのVBV Delay、τ_Ｔ１は特殊再生ストリームの２番目のピクチャのVBV Delay、ｄ_Ｔ０は特殊再生ストリームの先頭Ｉピクチャのデータ量、ａ_Ｔは特殊再生ストリームの転送レートである。

さらに、通常再生ストリームと特殊再生ストリームの間において、先頭のＶＢＶバッファの充填量を同じと仮定すると、
ａ_Ｎ×τ_Ｎ０＝ａ_Ｔ×τ_Ｔ０…（５）
の関係が導かれる。これは、図５において破線で示す内容である。

以上より、特殊再生ストリームのVBV Delayは、
τ_Ｔ０＝ａ_Ｎ／ａ_Ｔ×τ_Ｎ０…（６）
τ_Ｔ１＝τ_Ｔ０−ｄ_Ｔ０／ａ_Ｔ＋Δｆ…（７）
τ_Ｔ２＝τ_Ｔ１−ｄ_Ｔ１／ａ_Ｔ＋Δｆ…（８）
の関係が導かれる。つまり、通常再生ストリームの転送レートａ_Ｎ、特殊再生ストリームの転送レートａ_Ｔ、通常再生ストリームにおける先頭ピクチャのVBV Delayであるτ_Ｎ０から、特殊再生ストリームのVBV Delayを求めることができる。以上より、一般的にVBV Delayを求めるときのようにＶＢＶバッファの遷移をシミュレートすることによってVBV Delayを求めることなく、上記簡単な算術計算によって特殊再生ストリームのVBV Delayを求めることができる。

なお、上記では特殊再生ストリームのVBV Delayを計算によって導出する方法を示したが、全てのVBV Delayを固定値０ｘＦＦＦＦに置き換えることによっても、特殊再生ストリームを構成することができる。VBV Delayが０ｘＦＦＦＦであることは、ストリームがＶＢＲ（Variable Bit Rate）であることを示す値である。一方、VBV Delayとして０ｘＦＦＦＦ以外の値が入っている場合は、ＣＢＲ（Constant Bit Rate）を示す。ＭＰＥＧ−２では、ＣＢＲはＶＢＲの特殊な形態と定義されているため、生成した特殊再生ストリームをＶＢＲに設定することについて何ら問題はない。この場合、VBV Delayに関する計算処理が全く必要なく、データの置き換えだけで済むのでさらに高速な処理が可能になる。

このように実施の形態１では、ネットワーク上で接続されたサーバと端末間で映像の特殊再生を実行する場合において、通常再生ストリームから特殊再生ストリームをリアルタイムに生成するので、あらかじめ記録媒体に特殊再生ストリームを用意しておく必要や、あらかじめ用意しておいた特殊再生ストリームに対する特別な管理を行う必要がない。

また、生成する特殊再生ストリームは、通常再生ストリームから抽出したＩフレームに、符号量の少ないリピートピクチャを付加して、転送レートを抑えた特殊再生ストリームを生成し、秒あたりの符号量を削減しているので、特殊再生のときも、ネットワークの負荷を上昇させることなく転送が可能である。

また、生成された特殊再生ストリームは、再生側で通常の速度で再生することによって、あたかも特殊再生されたかのような映像を呈するように生成されているので、再生側で特殊再生ストリームを再生するにあたり、特別な仕組みを設ける必要がなく、特殊再生を実現できる。

さらに、通常再生ストリームから抽出したＩフレームの符号化パラメータの値を、生成する特殊再生ストリームおよびＭＰＥＧ−２ストリームの規約に従うように再設定して特殊生成ストリームに使用するので、符号化パラメータが不正な値をとることによる再生映像の乱れや、多重装置における多重化の失敗がなくなる。

また、生成する特殊再生ストリームに適合するように、デコーダバッファを制御するVBV Delay等のデコーダバッファに関する制御パラメータを適正な値に設定し直すので、デコーダバッファの破綻を防ぐことができる。

また、VBV Delayが適正な値になっているので、もし特殊再生ストリームが配信される経路上に多重装置があっても、多重ミスを生じることがない。

また、デコーダバッファ制御用パラメータを、特殊再生ストリームに変換する前の転送レートならびにデコーダバッファの制御用パラメータおよび変換後の転送レートから求めるので、特殊再生ストリームのデコーダバッファ制御用パラメータとして、より適切な値を導出でき、さらにデコーダバッファの破綻が起きなくなる。

また、この実施の形態１で示したVBV Delayの計算方法では、簡単な算術計算によりVBV Delayを求めることができるので、デコーダバッファのシミュレートによりVBV Delayを求める方法に比べてシステムの負荷が少なく、計算によるシステムの負荷上昇を発生させることなく、また高速に求めることができる。

さらに、VBV Delay等のデコーダバッファ制御用パラメータを０ｘＦＦＦＦ等の固定値に設定することにより、上記簡単な算術計算すら行う必要がなく、デコーダバッファ制御用パラメータの計算処理に係る時間および負荷がほとんど発生しないので、システムの負荷をほとんど上昇させることなく、VBV Delay等のデコーダバッファ制御用パラメータを設定することができる。

さらに、変動する特殊再生ストリームの符号量に対して、転送レートの調整を発生符号量が少ないときはスタッフィングで調整し、符合量が大きいときは目標とする符号量を一時的に上昇させて、符号量を制御することにより、生成する特殊再生ストリームに対して転送レートの調整の制御ができるので、通常再生と同じ転送レートにしたり、特殊再生のときのみ転送レートを変化させたり、簡単に転送レートを調整できる。

以上のように実施の形態１によれば、特殊再生ストリームのネットワーク越しでの再生において、映像の乱れが発生することがない。

実施の形態２．
図６は本発明の実施の形態２の広域監視システムを示す図である。この実施形態２では、カメラ１０１〜１０３で撮影された映像をサーバ１２０に蓄積保存し、複数台の端末１１１〜１１３から蓄積された映像を視聴できるシステムを構築している。端末は、任意の映像を通常の再生速度で視聴できる他に、早送り、早巻き戻し、一時停止などの特殊再生も可能である。

監視カメラ１０１〜１０３は、撮影した映像をＭＰＥＧ−２プログラムストリームに圧縮を行い、さらにＲＴＰプロトコルに対応したＲＴＰ／ＵＤＰパケット化を行い、ネットワーク１００を経由してサーバ１２０に送信する。

サーバ１２０は、カメラ１０１〜１０３が撮影した映像ストリームについて３つの蓄積機能を有しており、初期設定で選択が可能である。その１つ目は、カメラ１０１〜１０３からのマルチキャストストリームを、エンドレスに常時受信・蓄積を行う一次蓄積サーバ機能、２つ目は、カメラ１０１〜１０３からのマルチキャストストリームを、アラームをトリガに受信・蓄積するアラーム蓄積サーバ機能、３つ目は、図６に示されていない別のサーバに蓄積された映像ストリームを退避する画像保存サーバ機能であり、これら３つの蓄積機能を初期設定で切り替えて使用できる。ここでは、サーバ１２０は、一次蓄積サーバに設定されているものとして、以下説明を続ける。

サーバ１２０は、要求受付モジュール１２１と、受信モジュール１２２と、映像データベース１２３と、蓄積モジュール１２５と、特殊再生モジュール１２６と、ＨＤＤ１２７とを備えている。

要求受付モジュール１２１は、外部からの蓄積および配信要求に応じるためのモジュールであって、端末１１１〜１１３および図６に示されていない別のサーバからの映像の配信および蓄積の要求を受け付け、サーバ１２０内の他のモジュールに対して内部Ｉ／Ｆを利用して制御を行うとともに、要求のあった端末もしくはサーバに対して要求に対する応答メッセージ送信も行う。この要求受付モジュール１２１は、ＲＴＳＰ（Real Time Streaming Protocol）に対応しており、サーバ１２０に蓄積されている映像ストリームの通常再生および特殊再生が可能になっている。また、要求受付モジュール１２１は、映像データベース１２３を利用した各種検索機能も備えており、例えば時間や撮影されたカメラを検索キーにして対象となる映像ストリームを検索することも可能である。

受信モジュール１２２は、カメラ１０１〜１０３からマルチキャスト配信されたストリームの受信処理を行う。カメラ１０１〜１０３がマルチキャストで送信するメリットは、１つの映像ストリームを他のサーバで同時に保存が可能であることと、端末１１１〜１１３から直接カメラの映像が視聴可能となることであり、サーバ１２０に対してのみ送信したいのであればユニキャストで送信してもよい。この受信モジュール１２２は、ＲＴＰ／ＵＤＰパケットの送信ＩＰアドレスがサーバ１２０のＩＰアドレスもしくはマルチキャストアドレスであり、かつポート番号が一致していたときのみ受信を行う。また、受信モジュール１２２は、ＲＴＰ／ＵＤＰパケットで送られたＧＯＰの先頭データを受信した時刻をタイムスタンプとして取得する。受信したＲＴＰ／ＵＤＰパケットは、ＲＴＰ／ＵＤＰヘッダが付加されているので、それらを取り除き、ＲＴＰ／ＵＤＰパケットのペイロード部を結合し、プログラムストリームにする。

蓄積モジュール１２５は、受信したプログラムストリームである映像ストリームについてＧＯＰ単位でＨＤＤ１２７に蓄積を行うとともに、ＨＤＤ１２７に蓄積されたデータについてＧＯＰ単位で管理を行う。

映像データベース１２３は、蓄積モジュール１２５が管理・蓄積を行っている映像ストリームおよびＧＯＰのメタ情報についての記録・管理および検索機能を提供する。映像ストリームのメタ情報の種類としては、例えばカメラ番号、映像の圧縮方式および圧縮レベル、受信モジュール１２２で取得した時間を示すタイムスタンプ、撮影時刻等がある。

配信モジュール１２４は、要求受付モジュール１２１からの要求に従い、蓄積モジュール１２５が管理する映像ストリームをネットワーク１００に配信を行う。映像ストリームをネットワーク１００経由で、例えば端末１１１に対して通常再生ストリームとして配信するときは、送信データであるプログラムストリームをＲＴＰ／ＵＤＰパケット化し、送信先ＩＰアドレスとして端末１１１のＩＰアドレスを設定するとともに、映像データベース１２３に記録されているＧＯＰ毎の受信タイムスタンプをもとにＧＯＰ単位の送信のタイミングの制御を行う。

一方、特殊再生ストリームを配信するときは、蓄積モジュール１２５から読み出した通常再生ストリームを特殊再生モジュール１２６に一旦転送し、特殊再生モジュール１２６が生成した特殊再生ストリームについて配信を行う。特殊再生ストリームの配信タイミングは、早送りおよび早巻き戻しについては、配信するＧＯＰの受信タイムスタンプ間隔が、１５倍速であれば１／１５になるように配信を行う。特殊再生モジュール１２６を利用するには、通常再生ストリームからフレーム内符号化ピクチャ（Ｉフレーム）を抽出して特殊再生モジュール１２６に渡すとともに、特殊再生ストリームを生成するために必要とされるパラメータ、例えば通常再生ストリームの転送レート、希望する特殊再生ストリームの転送レート等のパラメータについても特殊再生モジュール１２６に渡し、特殊再生ストリーム生成を行う。

端末１１１〜１１３では、サーバ１２０に蓄積された映像ストリームを視聴することが可能であり、サーバ１２０の要求受付モジュール１２１に再生のリクエストを送ることによって視聴が可能になる。例えば、端末１１１が視聴したい映像ストリームをサーバ１２０にリクエストすると、対応する映像ストリームがＲＴＰ／ＵＤＰパケット単位でサーバ１２０から配信される。端末１１１は、ネットワーク上のＲＴＰ／ＵＤＰパケット内の送信ＩＰアドレスおよびポート番号が一致しているパケットについて受信を行うことによって、リクエストした映像ストリームの再生を行うことができる。

次に、図７を用いて、特殊再生モジュール１２６について説明する。特殊再生モジュール１２６は、配信モジュール１２４から転送されるＩフレームを受信するためのＩフレームバッファ１３１と、受信したＩフレームデータのデータ構造や符号化パラメータの解析を行う解析部１３２と、生成する特殊再生ストリームのVBV Delayの計算を行うデコーダバッファ計算部１３３と、特殊再生ストリームに利用するＩフレームデータについてパラメータの変更を行うＩフレームデータ変換処理部１３４と、Ｉフレームに続いてこのＩフレームと同じ表示内容を示すリピートピクチャを生成・付加するリピートピクチャ付加部１３５と、生成する特殊再生ストリームの符号量を目標とする転送レートに合うように制御を行う符号量制御部１３６と、生成された特殊再生ストリームをプログラムストリームに変換するＰＳ化部１３７と、生成された特殊再生ストリームを配信モジュール１２４に伝えるための特殊再生ストリームバッファ１３８とによって構成されている。

次に、実施の形態２の動作について説明する。サーバ１２０は、蓄積方法としてカメラ１０１〜１０３からのマルチキャストストリームをエンドレスに常時受信・蓄積を行う一次蓄積サーバに設定がなされているものとする。サーバ１２０が一次蓄積サーバに設定がなされると、サーバ１２０の受信モジュール１２２は、常時ネットワーク１００のＲＴＰ／ＵＤＰパケットについて監視を行い、ＲＴＰ／ＵＤＰパケットの送信先ＩＰアドレスが自らのＩＰアドレスもしくはマルチキャストアドレスであり、さらにポート番号が一致していれば、該当ＲＴＰ／ＵＤＰパケットの受信を行う。

受信モジュール１２２で受信されたパケット単位の映像ストリームは、ＲＴＰ／ＵＤＰパケット形式からプログラムストリームに変換され、さらに単独もしくは複数のパケットでＧＯＰ単位が構成されるごとにＧＯＰ単位でＨＤＤ１２７に記録が行われる。また、映像データベース１２３は、該当ＧＯＰがサーバ１２０において受信された時刻をＧＯＰの受信タイムスタンプとして記録するとともに、カメラ情報、映像の圧縮方式および圧縮レベル等のメタ情報の記録を行う。この動作を繰り返すことによって、サーバ１２０に映像ストリームが蓄積されていく。

次に、通常再生の動作について説明する。まず、例えば端末１１１から任意の映像を選択し、再生する場合について説明する。まず最初に、端末１１１は、サーバ１２０の要求受付モジュール１２１に対して、サーバ１２０内に蓄積されている映像ストリームの一覧を取得する。映像ストリームの一覧を取得するには、映像データベース１２３の検索機能を利用し、検索キーとして特に何も指定しないで検索を実行すると、蓄積された映像ストリームの一覧を取得することができる。こうして取得した映像ストリームの一覧から、端末１１１は、任意の希望する映像ストリームを選択することができる。映像ストリームは、それぞれについて重複しない映像ＩＤが割り当てられており、映像ストリームの特定には映像Ｉが利用される。

次に、端末１１１は、選択した映像ストリームを再生するために、要求受付モジュール１２１に対して、選択した映像ＩＤの再生要求コマンドを発行する。再生要求を受けた要求受付モジュール１２１は、配信モジュール１２４に対して指定された映像ＩＤの再生を開始するように命令を送る。配信モジュール１２４は、映像データベース１２３を利用して、映像ＩＤに一致し、かつ再生時間に一致する映像ストリームのＧＯＰを特定し、蓄積モジュール１２５に再生の指示を出す。蓄積モジュール１２５は、前記特定した映像ストリームのＧＯＰをＨＤＤ１２７から読み出し、配信モジュール１２４に送る。配信モジュール１２４は、蓄積モジュール１２５から取得したＧＯＰの配信を行う。

配信モジュール１２５による配信においては、映像ストリームのＧＯＰをＲＴＰ／ＵＤＰパケット化し、送信先ＩＰアドレスとして端末１１１のＩＰアドレスおよび受信する端末と同一のポート番号を指定し、さらに映像データベース１２３に記録しておいた配信データのメタ情報の１つである受信タイムスタンプをもとに配信タイミングの制御を行う。つまり、配信モジュール１２４は、該当ＧＯＰの配信タイミングとして、受信モジュール１２２でＧＯＰを受信した時刻である受信タイムスタンプを再現するようにＧＯＰの配信を行う。これによって、カメラにて撮影され、さらにエンコードされた映像データのカメラからの配信タイミングが再現され、結果としてネットワークおよび再生環境における各種バッファにおいてオーバーフローおよびアンダーフローを発生することなく、リアルタイムなデコード再生が可能になる。

配信モジュール１２５から配信されたＲＴＰ／ＵＤＰパケットは、再生を要求した端末１１１により受信される。端末１１１は、連続的に配信されるＲＴＰ／ＵＤＰパケットについてＲＴＰ／ＵＤＰヘッダを取り除き、複数のＲＴＰ／ＵＤＰパケットのペイロードをつなぎ合わせることによってプログラムストリームの形をした通常再生ストリームを取得できる。以上より、端末１１１は、サーバ１２０に蓄積された映像再生ストリームを取得し、さらに図示しないが内部に備えられたデコーダによって取得した映像再生ストリームを再生することができる。

次に、特殊再生の動作について説明する。ここでは、代表的な特殊再生の１つである早送りの方法について説明する。説明の簡略化のために、蓄積されている通常再生データは、ＭＰＥＧ−２プログラムストリームで、Ｎ＝１５とする。

早送りの場合、ＧＯＰ内のＩフレームのみを順次再生すれば１５倍速であるが、Ｉフレームの後にリピートピクチャを２枚付加した特殊再生ストリームを生成し、再生を行うと、通常再生ストリームに比べ５倍速の表示を行うことができる。さらに早送りの速度を高速にするには、離散的にＧＯＰを読み出せばよく、例えば３ＧＯＰ毎に読み出せば１５倍速、６ＧＯＰ毎に読み出せば３０倍速の早送りを行うことができる。ここでは、端末１１１から任意の映像について１５倍速の早送りの特殊再生がリクエストされたものとする。

通常再生の場合と同じように、端末１１１は、サーバ１２０の要求受付モジュール１２１に対して、特殊再生を行う映像ＩＤと特殊再生を行う命令を発行する。再生要求を受け付けた要求受付モジュール１２１は、配信モジュール１２４に対して、選択された映像ＩＤと早送りのコマンドを発行する。配信モジュール１２４は、映像データベース１２３を用いて、選択された映像ＩＤのストリームのメタ情報を取得し、１５倍速の早送りを実現するための読み込み対象のＧＯＰを決定する。

図８にＧＯＰと受信タイムスタンプの関係を示す。図８において、Ｎ＝１５、リピートピクチャが２枚の場合の１５倍速の早送りでは、３ＧＯＰ毎の読み出しを行えばよい。このようにして早送り速度に応じて読み込みＧＯＰを決定し、決定したＧＯＰを蓄積モジュール１２５がＨＤＤ１２７から読み出しを行う。配信モジュール１２４は、取得した通常再生ストリームのＧＯＰデータからＩフレームを抽出し、特殊再生モジュール１２６に送る。

図７において、特殊再生モジュール１２６のＩフレームバッファ１３１には、配信モジュール１２４から送られたＩフレームデータが格納される。解析部１３２は、Ｉフレームバッファ１３１に格納されたＩフレームデータのVBV Delay，Temporal Reference，Picture Coding Type，符号量の解析を行い、特殊再生モジュール１２６内の各処理で必要なパラメータを取得する。

デコーダバッファ計算部１３３では、解析部１３２から取得したパラメータをもとに、生成する特殊再生ストリームのVBV Delayの計算を行う。このVBV
Delayの計算方法については、上記実施の形態１で示した方法を用いるものとする。

Ｉフレームデータ変換処理部１３４は、入力したＩフレームピクチャが生成される特殊再生ストリームに適合するように、例えばTemporal ReferenceやVBV Delayおよびシーケンスヘッダ以降ＩフレームまでのBit Rate ValueやVBV Buffer Size Valueを変更する。

リピートピクチャ付加部１３５は、先行するＩフレームと表示内容が同じになるように、動きベクトルを０かつ予測誤差を０になるように、かつスキップドマクロブロックを使用しデータ量を大幅に削減するように符号化されたリピートピクチャのデータを作成する。

符号量制御部１３６は、生成する特殊再生ストリームの目標転送レートに対して、発生する符号量を予測し、予測符号量が目標転送レートに比べて小さいなら、スタッフィングによって目標転送レートに近づけ、予測符号化量が目標転送レートを上回りそうであれば、一時的に目標転送レートを上げるとともに関連する例えばBit Rate ValueやＳＣＲの再調整を行い、ＭＰＥＧの規格に対して矛盾が生じない処理を行うことによって、発生符号量の制御を行う。

ＰＳ化部１３７は、ビデオエレメンタリーストリームの形式で生成された特殊再生ストリームをパック単位に分割し、プログラムストリームの形式に変換を行う。生成されたプログラムストリームは、特殊再生ストリームバッファ１３８に保存され、当該データを配信モジュール１２４に渡す。

配信モジュール１２４は、受け取った特殊再生ストリームについても、通常再生ストリームと同様に、ＲＴＰ／ＵＤＰパケット化し、送信先ＩＰアドレスとして端末１１１のＩＰアドレスおよびポート番号を指定し、さらに映像データベース１２３に記録しておいた配信データのメタ情報の１つであるＧＯＰ毎の受信タイムスタンプをもとに早送り速度を鑑みながら、つまり１５倍速であればＧＯＰ間の受信タイムスタンプの間隔が１／１５になるように、ＧＯＰ単位での配信タイミングの制御を行う。配信モジュール１２４から配信されたＲＴＰ／ＵＤＰパケットは、再生を要求した端末１１１により受信される。

端末１１１は、連続的に配信されるＲＴＰ／ＵＤＰパケットについて、ＲＴＰ／ＵＤＰヘッダを取り除き、プログラムストリームのパケットにし、さらに複数のペイロードパケットをつなぎ合わせることによって、特殊再生ストリームを取得できる。そして、取得した特殊再生ストリームを通常再生ストリームと同様に再生することによって、１５倍速の早送りの特殊再生を実現することができる。この特殊再生ストリームは、シンタックス上、通常再生ストリームと何ら変わりがないため、通常再生ストリームと同様に扱うことが可能である。以上より、端末１１１は、取得した特殊再生ストリームを再生することができる。

ここでは、早送りの１５倍速について説明したが、早送りの３０倍速であれば、６ＧＯＰ毎に１つのＩフレームを読み出し、配信するタイムテーブルの時間間隔を１／１５にすればよい。また、早巻き戻しであれば、逆方向に読み出して、特殊再生モジュール１２６に送ればよい。また、一時停止であれば、同じＧＯＰのデータを繰り返し、特殊再生モジュール１２６に送ればよい。

なお、早送りおよび早巻き戻しの特殊再生ストリームの配信タイミングについては、受信時のタイムスタンプをもとに配信することによってリアルタイム性を確保できたが、一時停止の特殊再生において配信を行うタイミングは、受信時刻が同一であるため、受信タイムテーブルを使用するのは無意味である。従って、生成した特殊再生ストリームの時刻情報をもとに配信を行なう方法をとる。

この実施の形態２で説明した特殊再生ストリームは、再生側で通常の速度で再生することによって、あたかも特殊再生されたかのような映像を呈するように生成されているので、再生側で特殊再生ストリームを再生するにあたり、特別な仕組みを設ける必要がなく、通常再生ストリームと同様に扱うことができる。

また、通常再生から特殊再生、もしくは特殊再生から通常再生に遷移するときに、シームレスに再生を続けるためには、プログラムストリームのＳＣＲ（System Clock Reference）およびＰＴＳ（Presentation Time Stamp）やＤＴＳ（Decoding Time Stamp）の時間情報の連続性を保証することが必要である。もし、これらの時間情報が連続していないと、デコーダによっては、デコーダバッファのオーバーフローやアンダーフローが発生したり、デコードの一時中断や停止が発生したりする恐れがある。

従って、通常再生と特殊再生間の切り替え時には、先行するストリームの最終ＳＣＲをもとに、後続するストリームのＳＣＲが連続するように、後続するストリームのＳＣＲにオフセットを行うことが望ましい。さらに、後続するストリームのＰＴＳおよびＤＴＳについても、ＳＣＲが行ったオフセット相当を行うことも必要である。

このように実施の形態２では、ネットワーク上で接続されたサーバと端末間で映像の特殊再生を実行する場合において、通常再生ストリームから特殊再生ストリームをリアルタイムに生成するので、あらかじめ記録媒体に特殊再生ストリームを用意しておく必要や、あらかじめ用意しておいた特殊再生ストリームに対する特別な管理を行う必要がない。

また、VBV Delayが適正な値になっているので、もし特殊再生ストリームが配信される経路上に多重装置があっても多重ミスを生じることがない。

また、デコーダバッファ制御用パラメータの導出が簡単な算術計算であるため、計算によるシステムの負荷上昇を発生させることなく、また高速に求めることができる。

さらに、デコーダバッファ制御用パラメータを固定値に設定することにより、デコーダバッファ制御用パラメータの計算処理に係る時間および負荷がほとんど発生しないので、システムの負荷をほとんど上昇させることなく、デコーダバッファ制御用パラメータを設定することができる。

以上のように実施の形態２によれば、特殊再生ストリームのネットワーク越しでの再生において、映像の乱れが発生することがない。

本発明の実施の形態１の映像配信システムを示す図である。本発明の実施の形態１においての早送り再生のストリームの構造を説明する図である。本発明の実施の形態１においての一時停止のストリームの構造を説明する図である。本発明の実施の形態１においての早巻き戻し再生のストリームの構造を説明する図である。本発明の実施の形態１においてのＶＢＶバッファの遷移を示す図である。本発明の実施の形態２の広域監視システムを示す図である。本発明の実施の形態２においての特殊再生モジュールを示す図である。本発明の実施の形態２においてのＧＯＰ毎のタイムスタンプを説明する図である。

符号の説明

１サーバ、２蓄積部、３読み出し部、４スイッチ、５再生制御部、６スイッチ、７配信部、１１特殊再生処理部、１２抽出部、１３解析部、１４デコーダバッファ計算部、１５フレーム内符号化ピクチャデータ変換処理部、１６リピートピクチャ付加部、１７符号量制御部、１８ＰＳ化部、２１アドレスマップ、３１ネットワーク、４１再生入力部、４２再生指示部、４３受信部、４４デコーダ、４５表示部、５１，５２，５３端末、１００ネットワーク、１０１，１０２，１０３カメラ、１１１，１１２，１１３端末、１２０サーバ、１２１要求受付モジュール、１２２受信モジュール、１２３映像データベース、１２４配信モジュール、１２５蓄積モジュール、１２６特殊再生モジュール、１２７ＨＤＤ、１３１Ｉフレームバッファ、１３２解析部、１３３デコーダバッファ計算部、１３４Ｉフレームデータ変換処理部、１３５リピートピクチャ付加部、１３６符号量制御部、１３７ＰＳ下部、１３８特殊再生ストリームバッファ。

Claims

フレーム間予測を用いて符号化された映像ストリームに対して、再生速度および再生方向を変更した特殊再生ストリームを生成する映像データ処理方法であって、
生成する特殊再生ストリームの速度と方向に合わせて、上記映像ストリームからフレーム内符号化ピクチャを選択的に抽出する工程と、
上記抽出したフレーム内符号化ピクチャの符号化パラメータを解析する工程と、
上記速度と方向に合わせて、上記符号化パラメータを変更する工程と、
上記抽出したフレーム内符号化ピクチャと同じ表示内容を示すリピートピクチャを生成する工程と、
上記リピートピクチャを、データの伝送順で上記再生速度および再生方向に基づいて選択される上記符号化パラメータを変更したフレーム内符号化ピクチャの後ろに続けて付加することによって、特殊再生ストリームを生成する工程と
を備えた
ことを特徴とする映像データ処理方法。
上記抽出したフレーム内符号化ピクチャのデコーダバッファに関する制御制御パラメータを解析する工程と、
伝送された上記特殊再生ストリームがデコーダバッファで破綻に至らないように、上記デコーダバッファに関する制御パラメータを変更する工程と
をさらに備えた
ことを特徴とする請求項１記載の映像データ処理方法。
デコーダバッファに関する制御パラメータを変更する上記工程は、上記特殊再生ストリームを構成するフレーム内符号化ピクチャおよびリピートピクチャのデコーダバッファに関する制御パラメータを、上記抽出されたフレーム内符号化ピクチャの上記解析されたデコーダバッファ制御用パラメータ、ならびに上記映像ストリームの転送レート、および生成する特殊再生ストリームの転送レートから導出することを特徴とする請求項２記載の映像データ処理方法。
デコーダバッファに関する制御パラメータを変更する上記工程は、上記特殊再生ストリームを構成するフレーム内符号化ピクチャおよびリピートピクチャのデコーダバッファに関する制御パラメータを、上記映像ストリームおよび生成する特殊再生ストリームの符号化構成によらず、有意な固定値とすることを特徴とする請求項２記載の映像データ処理方法。
上記特殊再生ストリームの発生する符号量が、目標とする転送レート以下と予想される場合は、スタッフィングにより上記目標とする転送レートに合わせ、上記特殊再生ストリームの発生する符号量が、上記目標とする転送レートを上回ると予想される場合は、上記目標とする転送レートを一時的に上げる工程をさらに備えたことを特徴とする請求項１記載の映像データ処理方法。
フレーム間予測を用いて符号化された映像ストリームに対して、再生速度および再生方向を変更した特殊再生ストリームを生成する映像データ処理装置であって、
生成する特殊再生ストリームの速度と方向に合わせて、上記映像ストリームからフレーム内符号化ピクチャを選択的に抽出する手段と、
上記抽出されたフレーム内符号化ピクチャの符号化パラメータを解析する手段と、
上記速度と方向に合わせて、上記符号化パラメータを変更する手段と、
上記抽出されたフレーム内符号化ピクチャと同じ表示内容を示すリピートピクチャを生成する手段と、
上記リピートピクチャを、データの伝送順で上記再生速度および再生方向に基づいて選択される上記符号化パラメータを変更したフレーム内符号化ピクチャの後ろに続けて付加することによって、特殊再生ストリームを生成する手段と
を備えた
ことを特徴とする映像データ処理装置。
上記抽出したフレーム内符号化ピクチャのデコーダバッファに関する制御制御パラメータを解析する手段と、
伝送された上記特殊再生ストリームがデコーダバッファで破綻に至らないように、上記デコーダバッファに関する制御パラメータを変更する手段と
をさらに備えた
ことを特徴とする請求項６記載の映像データ処理装置。
デコーダバッファに関する制御パラメータを変更する上記手段は、上記特殊再生ストリームを構成するフレーム内符号化ピクチャおよびリピートピクチャのデコーダバッファに関する制御パラメータを、上記抽出されたフレーム内符号化ピクチャの上記解析されたデコーダバッファ制御用パラメータ、ならびに上記映像ストリームの転送レート、および生成する特殊再生ストリームの転送レートから導出することを特徴とする請求項７記載の映像データ処理装置。
デコーダバッファに関する制御パラメータを変更する上記手段は、上記特殊再生ストリームを構成するフレーム内符号化ピクチャおよびリピートピクチャのデコーダバッファに関する制御パラメータを、上記映像ストリームおよび生成する特殊再生ストリームの符号化構成によらず、有意な固定値とすることを特徴とする請求項７記載の映像データ処理装置。
上記特殊再生ストリームの発生する符号量が、目標とする転送レート以下と予想される場合は、スタッフィングにより上記目標とする転送レートに合わせ、上記特殊再生ストリームの発生する符号量が、上記目標とする転送レートを上回ると予想される場合は、上記目標とする転送レートを一時的に上げる手段をさらに備えたことを特徴とする請求項６記載の映像データ処理装置。