JP3364869B2 - ビットストリームの再生方法およびビデオオンデマンドシステム - Google Patents

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、画像情報と音声情
報を処理して構成されたビットストリームの再生方法に
関する。

【０００２】

【従来の技術】図６はビデオオンデマンドシステムの従
来例の構成図である。

【０００３】従来例のビデオオンデマンドシステムはエ
ンコーダシステム１０とビデオサーバ２０’と端末３０
とネットワーク４０で構成されている。

【０００４】エンコーダシステム１０はビデオ入力装置
１１とビデオ入力処理装置１２とＭＰＥＧビデオエンコ
ーダ１３とオーディオ入力装置１４とオーディオ入力処
理装置１５とＭＰＥＧオーディオエンコーダ１６とＭＰ
ＥＧシステムエンコーダ１７とネットワークインタフェ
ース１８で構成されている。

【０００５】ビデオサーバ２０’は蓄積装置２１と蓄積
装置インタフェース２２と蓄積装置コントローラ２３と
バッファ２４とネットワークインタフェース２５で構成
されている。

【０００６】端末３０はデコーダ３１を備えている。

【０００７】例えばビデオカメラであるビデオ入力装置
１１で撮影された画像情報はビデオ入力処理装置１２で
Ａ／Ｄ変換され、ＭＰＥＧビデオエンコーダ１３でビデ
オデータが符号化されてビデオストリーム（ＭＰＥＧビ
デオ層）が構成される。例えばマイクであるオーディオ
入力装置１４から入力された音声はオーディオ入力処理
装置１５でＡ／Ｄ変換され、ＭＰＥＧオーディオエンコ
ーダ１６でオーディオデータが符号化されてオーディオ
ストリーム（ＭＰＥＧオーディオ層）が構成される。Ｍ
ＰＥＧシステムエンコーダ１７はビデオストリームをビ
デオパケットへ、オーディオストリームをオーディオパ
ケットへそれぞれ分割し、さらにビデオパケットをいく
つか一塊にして固定長のビデオパックを構成し、オーデ
ィオパケットをいくつか一塊にして固定長のオーディオ
パックを構成し、ビデオのパックとオーディオのパック
を適切な割合でつなぎあわせてビットストリーム（ＭＰ
ＥＧシステム層）を構成する。ビットストリームはネッ
トワーク４０を経由してビデオサーバ２０’に送られ
る。ビデオサーバ２０’はビットストリームをいくつか
のパックを一塊としてブロックを構成し、蓄積装置２１
に蓄積する。前記ブロックは、ビデオサーバ２０’にお
けるビットストリームの蓄積および再生の単位となる。

【０００８】次に、この種のビットストリームの蓄積フ
ォーマットについて、ビットストリームの符号化方式に
ＭＰＥＧ１（ＩＳＯ／ＩＥＣ標準１１１７２−２）を用
いた場合を例として説明する。

【０００９】図７はビットストリームの蓄積フォーマッ
トを示す図である。図７中、５０はシーケンスヘッダ、
５１はＧＯＰ（Ｇｒｏｕｐ ｏｆ Ｐｉｃｔｕｒｅ
ｓ）、５２はＧＯＰヘッダ、５３はＧＯＰデータ、５４
はビデオパケット、５５はビデオパケットヘッダ、５６
はビデオパケットデータ、５７はビデオパック、５８は
ビデオパックヘッダ、５９はビデオパックデータ、６０
はＡＡＵ（Ａｕｄｉｏ Ａｃｃｅｓｓ Ｕｎｉｔ）、６
１はオーディオパケット、６２はオーディオパケットヘ
ッダ、６３はオーディオパケットデータ、６４はオーデ
ィオパック、６５はオーディオパックヘッダ、６６はオ
ーディオパックデータ、６７は蓄積、読取りの単位であ
るブロック、６８はブロックヘッダ、６９はブロックデ
ータ、７０はブロークンリンクフラグである。

【００１０】符号化されたビデオストリームは、何枚か
のフレーム間符号化された画面データと少くとも１枚の
フレーム内符号化された画面データを一まとまりにした
ＧＯＰ５１を単位とした構造を持ち、各ＧＯＰ５１はＧ
ＯＰヘッダ２２とＧＯＰデータ５３から構成される。Ｇ
ＯＰヘッダ５２にはブロークンリンクフラグ７０が存在
する。ＧＯＰ５１毎にシーケンスヘッダ５０が付与され
る。ビデオストリーム中のランダムな位置へのアクセス
は、ＧＯＰ５１を単位として実現可能であり、このラン
ダム・アクセスの頭出しに使われるのがシーケンスヘッ
ダ５０である。シーケンスヘッダ５０とＧＯＰ５１から
ビデオストリームが構成される。

【００１１】ＧＯＰ５１内の最初のいくつかのフレーム
間符号化された画面データは、ビデオの符号化シーケン
スのつながりから見て直前のＧＯＰ５１に属する画面デ
ータからの予測を利用するように符号化されていたとす
る。ジャンプや飛ばし読み再生のようにビデオの符号化
シーケンスとは異なる順番でビットストリームを再生す
る場合には、ビデオストリームの切替わり部分の先頭Ｇ
ＯＰ５１の再生時に参照すべき直前のＧＯＰ５１に属す
る画面データが利用できないため、マクロブロックのギ
ザギザが出るといった再生映像の乱れを生じる。そこ
で、ビデオサーバ２０’は、ジャンプや飛ばし読み等を
行なうときには、新しいビットストリームがその直前に
読出したビットストリームとは関連のないデータである
ことを示すブロークンリンクフラグ７０を立てる。デコ
ーダ３１は、ブロークンリンクフラグ７０が立っている
ときにはＧＯＰ５１の先頭のいくつかのフレーム間符号
化された画面データをデコーダしないことで映像の乱れ
を見せない。

【００１２】符号化されたビデオストリームは、ＧＯＰ
５１とは無関係なビデオパケットデータ５６に分割さ
れ、ビデオパケットヘッダ５５を付与されてビデオパケ
ット５４を構成する。ビデオパケット５４は、いくつか
一塊となってビデオパックデータ５９を構成し、ビデオ
パックヘッダ５８を付与されて固定長のビデオパック５
７を構成する。符号化されたオーディオストリームは、
単独でオーディオ信号に復号できるＡＡＵ６０を単位と
した構造を持つ。ＡＡＵ６０は、ヘッダ、エラーチェッ
クビット、オーディオデータとオーディオデータの終り
がＡＡＵ６０の終りに達しない場合に付加されるオーデ
ィオデータ以外の任意データから構成される。オーディ
オストリームは、ＡＡＵ６０とは無関係なオーディオパ
ケットデータ６３に分割され、オーディオパケットヘッ
ダ６２を付与されてオーディオパケット６１を構成す
る。オーディオパケット６１は、いくつか一塊となって
オーディオパックデータ６６を構成し、オーディオパッ
クヘッダ６５を付与されて固定長のオーディオパック６
４を構成する。ビデオパック５７とオーディオパック６
４は、適切な割合でつなぎ合わされてビットストリーム
を構成する。ビットストリームは、いくつかのパック毎
に一塊となってブロックデータ６９を構成し、ブロック
ヘッダ６８を付与されてブロック６７を構成する。ビデ
オサーバ２０におけるビットストリームの蓄積および読
出しは、このブロック６７を単位として行なわれる。

【００１３】また、ビデオサーバ２０’は、端末３０か
らジャンプなどの再生状態変更要求を受信した場合、指
定された再生ポイントに対応するビットストリームを含
むブロックを読み出して端末３０に送信する。端末３０
では、従来は、再生状態変更要求を出す以前の古いビッ
トストリームと再生状態変更要求以後の新しいビットス
トリームとの切り替え点を識別する方法がなかったた
め、ビデオサーバ２０’、ネットワーク４０および端末
３０のバッファに残された古いビットストリームであっ
ても、それを再生してからでないと新しいビットストリ
ームを受信できなかった。あるいは、受信したビットス
トリームの新旧を判断するために、一度復号化して、そ
の中の再生時刻情報等を解釈しなければならなかった。

【００１４】

【発明が解決しようとする課題】従来のビデオサーバに
おけるビットストリームの蓄積フォーマットは、ブロー
クンリンクフラグとは無関係な境界で分割したブロック
を単位としたものであったため、ブロークンリンクフラ
グがブロックのどの位置に存在するかは不明であり、ビ
デオサーバはジャンプや飛ばし読み再生といったビデオ
の符号化シーケンスとは異なる順番でビットストリーム
を再生する場合には、ブロック中のブロックヘッダを解
釈して、シーケンスヘッダを解釈して、ブロック中の初
めのブロークンリンクフラグをサーチして所定の値を設
定した後に、ビットストリームを転送するという手順を
ふむ必要があった。その結果、ジャンプや飛ばし読み再
生等を行なう場合には、ビデオサーバにおけるビットス
トリームの提供処理に要する負荷や遅延が大きく、応答
時間の増大やビデオサーバが処理できるビットストリー
ム数の減少といった問題があった。

【００１５】また、ビデオサーバがジャンプや飛ばし読
み再生等の要求を受信した時には、デコーダやネットワ
ークインタフェース上のバッファメモリに再生する必要
のなくなった旧ビットストリームが残っている可能性が
ある。デコーダは、受信したデータがジャンプや飛ばし
読み再生等のための新しいビットストリームなのか、バ
ッファメモリに残っていた旧ビットストリームなのか判
別できないため、ジャンプや飛ばし読み再生を開始した
時に不要な旧ビットストリームを再生するおそれがあっ
た。

【００１６】また、従来の方法では、動画像再生中、端
末から再生状態変更の要求があった場合、端末やビデオ
サーバ、ネットワークインタフェースのバッファに蓄積
されたビットストリームを端末で全て表示するため、ユ
ーザが新しいデータを見るまでには、多くの時間がかか
ってしまう。また、符号化データ中の時間情報を判定す
る方法では、多くの符号化データが柔軟な構造を持たせ
るため、固定的な構造を持っておらず、ビットストリー
ム型データの中から時間情報の位置を調べていくだけで
時間がかかる。さらに、端末でもっている時間とビット
ストリーム中の時間情報は異なるため、時間情報を常に
判定しなければならず、端末に高い処理能力を持たせる
必要がある。

【００１７】本発明の目的は、ジャンプや飛ばし読み再
生といったビデオの符号化シーケンスとは異なる順番で
ビットストリームを再生する場合に、ビデオサーバにお
けるブロークンリンクフラグ等の設定処理に伴う負荷を
軽減するとともに遅延を短縮する、ビットストリームの
再生方法とビデオオンデマンドシステムを提供すること
にある。

【００１８】本発明の他の目的は、端末デコーダにおけ
る新ビットストリームと旧ビットストリームの識別がで
きないといった問題点を解決する、ビットストリームの
再生方法を提供することにある。

【００１９】

【課題を解決するための手段】本発明の、ビットストリ
ームの再生方法は、ビットストリームを再生する時に、
新たに読出したブロックが直前に読出したブロックとビ
デオの符号化シーケンス上連続するか否かを示す情報を
ビットストリームの復号化の単位ごとに設定し、符号化
されたビットストリームの内容を解釈して、前記情報の
位置が当該ブロックの先頭から固定の位置になるように
ビットストリームをブロックへ分割するものである。

【００２０】本発明の実施態様によれば、前記情報をＭ
ＰＥＧシステム層のプライベートな領域に設定する。

【００２１】本発明の他の実施態様によれば、前記情報
としてＭＰＥＧビデオ層のブロークンリンクフラグを用
いる。

【００２２】

【００２３】本発明の実施態様によれば、前記プライベ
ートな領域の先頭を境界としてビットストリームを前記
ブロックへ分割する。

【００２４】本発明の実施態様によれば、ＭＰＥＧビデ
オ層のシーケンスヘッダの先頭を境界としてビットスト
リームを前記ブロックへ分割する。

【００２５】本発明の実施態様によれば、ＭＰＥＧビデ
オ層のＧＯＰヘッダの先頭を境界としてビットストリー
ムを前記ブロックへ分割する。

【００２６】本発明の実施態様によれば、前記情報は複
数ビットからなる情報である。

【００２７】本発明のビットストリーム再生方法は、ビ
ットストリームを再生する時に、新たに読出したブロッ
クが直前に読出したブロックとビデオの符号化シーケン
ス上連続するか否かを示す情報を前記ビットストリーム
の復号化の単位ごとに設定し、符号化されたビットスト
リームの内容を解釈し、前記情報の位置が当該ブロック
の先頭から固定の位置になるように前記ビットストリー
ムをブロックへ分割し、端末において、再生状態変更要
求を受信した場合には、ビットストリーム中の前記情報
を参照し、新たに受信したブロックが直前に受信したブ
ロックとビデオの符号化シーケンス上連続することを示
していれば新たに受信したデータを破棄して次のデータ
の受信を待ち、新たに受信したブロックが直前に受信し
たブロックとビデオの符号化シーケンス上連続していな
いことを示していれば、新たに受信したデータから再生
を開始する。

【００２８】本発明の実施態様によれば、前記情報とし
て複数のビットからなる情報を用い、端末からビデオサ
ーバに新規のビットストリームの要求がある毎に前記情
報を変更していく。

【００２９】本発明の、ビットストリームの再生方法
は、ビットストリームの、新たに読出したブロックが直
前に読出したブロックとビデオの符号化シーケンス上連
続するか否かを示す情報の位置がブロックの先頭から固
定の位置になるようにビットストリームをブロックへ分
割する。

【００３０】

【００３１】本発明のビデオオンデマンドシステムは、
符号化されたビットストリームの内容を解釈し、前記情
報の位置がブロックの先頭から固定の位置になるように
ビットストリームをブロックへ分割する手段をエンコー
ダシステムまたはビデオサーバが有する。

【００３２】本発明は、ビットストリームを再生する時
に、新たに読み出したブロックが直前に読み出したブロ
ックとビデオの符号化シーケンス上連続するか否かを示
す情報をビットストリームの復号化の単位毎に設け、ビ
ットストリームを再生する時に、符号化されたビットス
トリームの内容を解釈して、前記情報が前記ブロックの
特定の位置になるようにビットストリームをブロックへ
分割することによって、前記ブロックの中の最初の前記
情報の位置を前記ブロックの先頭から固定の位置に定め
ることができる。また、端末において、前記情報を用い
て受信したビットストリームの新旧を識別することがで
きる。

【００３３】したがって、ビデオサーバはジャンプや飛
ばし読み再生といったビデオの符号化シーケンスとは異
なる順番でビットストリームを再生する場合に、前記情
報の位置を探すために前記ブロック中のヘッダ情報を解
釈し、前記情報をサーチする必要がなくなる。また、端
末において、不要な旧ビットストリームを受信した場合
には、それを破棄して次に続く新しいビットストリーム
を速やかに受信できる。

【００３４】よって、ビデオサーバにおいては、新たに
読出したブロックが直前に読出したブロックとビデオの
符号化シーケンス上連続しないことを示す情報の設定に
要する負荷を軽減するとともに、遅延を短縮し、端末に
おいては、新しいビットストリームの再生を開始するま
での時間を短縮できるため、ジャンプや飛ばし読み再生
等を行なう時のビデオサーバが提供できるビットストリ
ーム数が増加し、応答時間が短く使い勝手の良いビジュ
アルサーチ機能を実現できるようになる。

【００３５】

【発明の実施の形態】次に、本発明の実施形態について
図面を参照して説明する。

【００３６】図１は本発明の一実施形態を示すビデオオ
ンデマンドシステムの構成図である。本実施形態で用い
るデータは、圧縮、符号化されたビットストリーム（動
画像データ）である。

【００３７】図２は本実施形態における蓄積ブロックの
蓄積フォーマットを示す図である。ビットストリームの
符号化方式にＭＰＥＧ１（ＩＳＯ／ＩＥＣ標準１１１７
２−２）を用いた場合を例に説明する。図２中、参照番
号は同７中同じものを示す。

【００３８】本ビデオオンデマンドシステムは図６のビ
デオオンデマンドシステムとビデオサーバ２０のみ異な
っている。すなわち、ビデオサーバ２０は蓄積フォーマ
ット変換部２６を新たに備えている。

【００３９】蓄積フォーマット変換部２６は、エンコー
ダシステム１０から送られてきたビットストリームの内
容を解釈してシーケンスヘッダ５０を探し、シーケンス
ヘッダ５０の先頭を境界としてビットストリームをブロ
ックへ分割し、ブロックデータを構成する。この時、シ
ーケンスヘッダ５０を含んでいたビデオパック５７が分
割されるので、分割されたビデオパック５７のヘッダが
付いていた側ではビデオパックヘッダ５８中のレングス
情報を修正し、ヘッダがなかった側には新たにビデオパ
ックヘッダ５８を付与する。ブロークンリンクフラグ７
０は、ＧＯＰヘッダ５２に含まれるが、シーケンスヘッ
ダ５０の先頭からは固定の位置にある。したがって、ブ
ロークンリンクフラグ７０は、ブロック６７の先頭から
固定の位置に定まる。蓄積コントローラ２３は、ブロッ
ク６７を単位としたビットストリームの蓄積および読取
り処理を行なう。

【００４０】ビットストリームをビデオサーバ２０の蓄
積装置２１に蓄積する時に蓄積および再生の単位となる
ブロック６７の境界をシーケンスヘッダ５０の開始位置
と一致した蓄積フォーマットに変換することによって、
ブロック６７の中の最初のブロークンリンクフラグ７０
の位置をブロック６７の先頭から固定の位置に定めるこ
とができる。したがって、ビデオサーバ２０はジャンプ
や飛ばし読み再生といったビデオの符号化シーケンスと
は異なる順番でビットストリームを再生する場合に、ブ
ロークンリンクフラグ７０を探すためにブロックヘッダ
６８を解釈し、シーケンスヘッダ５０を解釈し、ブロー
クンリンクフラグ７０をサーチするといった処理の必要
がなくなる。よって、ジャンプや飛ばし読み再生等を行
なう時にビデオサーバ２０におけるビットストリームの
提供処理に要する負荷を軽減し、遅延を短縮できるた
め、ビデオサーバ２０が提供できるビットストリーム数
を増加できるとともに、応答時間が短くて使い勝手の良
いビジュアルサーチ機能を実現できる。

【００４１】ここでは、シーケンスヘッダ５０を利用す
る場合について説明したが、シーケンスヘッダ５０の代
りにＧＯＰヘッダ５２を利用した場合も同様である。ブ
ロークンリンクフラグ７０の代りにＭＰＥＧシステム層
のプライベートヘッダ中に同様な用途の情報を設け、そ
の位置を検出するためにプライベートヘッダを利用する
場合も同様である。

【００４２】ブロークンリンクフラグ７０は１ビットの
情報であるため、ジャンプ等の要求が一度に複数回生じ
た時には対応できない。それに対応するには、プライベ
ートヘッダ中に複数ビットからなる同様な用途の情報
（以下の説明では新／旧フラグと呼ぶ）を設けて、ビッ
トストリームをジャンプあるいは飛ばし読みする回数だ
け前記情報をインクリメントすることによってビットス
トリームの新旧の判断を行なうことができる。

【００４３】次に、ビットストリーム再生時のデータの
流れを説明する。まず、端末３０からの再生要求をネッ
トワーク４０を通じてビデオサーバ２０で受信する。こ
の再生要求は、ネットワークインタフェース２５を通
り、バッファ２４を経由して蓄積装置コントローラ２３
に送られ、蓄積装置コントローラ２３によって、蓄積装
置２１内のブロックについて検索操作がおこなわれる。
検索された結果、該当したブロックは、蓄積装置２１か
らいったんバッファ２４に読み出され、新／旧フラグの
領域に初期値が書込まれ、ネットワークインタフェース
２５を経由しネットワーク４０に放出され、端末３０へ
と送られ、再生が行なわれる。

【００４４】図３はビデオサーバ２０の処理を示すフロ
ーチャートである。まず、新／旧フラグを、例えば１に
初期化し（ステップ７１）、端末３０からのブロック要
求を待つ（ステップ７２，７３）。端末３０は自らのバ
ッファがなくなるとビデオサーバ２０へ次のブロックの
読出しを要求する。この場合には再生状態変更ではない
ので、ビデオサーバ２０は、蓄積装置２１へ継続するブ
ロックの読出しを指示し（ステップ７８）、バッファ２
４へブロックを読出す（ステップ７９）。そして、新／
旧フラグの領域は何も変更せずにビデオビットレートに
従って端末３０へ送信する（ステップ７７）。ユーザが
ジャンプや早送りを指示したり、逆に早送りから通常へ
戻る指示をすると、端末３０はビデオサーバ２０へジャ
ンプや早送り等（再生状態変更）の要求が生じたことを
伝えるために、例えば、ジャンプの要求を送信したり、
例えば、直前の要求とは継続しない番号のブロックを要
求する。ビデオサーバ２０は、端末３０から受信したブ
ロック要求が再生状態変更を表している場合、蓄積装置
２１へ所望のブロックの読出しを指示し（ステップ７
４）、バッファ２４へブロックを読出す（ステップ７
５）。そして、新／旧フラグの領域に今までの値と異な
る値を設定し（ステップ７６）、ビデオビットレートに
従って端末３０へ送信する（ステップ７７）。

【００４５】図４は端末３０の処理を示すフローチャー
トである。端末３０は、端末３０側で管理している新／
旧フラグ情報へ初期値（ビデオサーバ２０が絶対設定し
ない値）を設定する（ステップ８１）。この初期値は、
要求しているビットストリームに関してはまだ再生状態
変更の要求を出していないことを表すユニークな値であ
り、今後再生状態変更を行う場合にビデオサーバ２０が
新／旧フラグへ設定する値とは一致しない任意の値であ
る。まず、新規ビットストリームの要求の場合には再生
状態変更の要求はなしとする新規ビットストリームの要
求の場合には、その先頭ブロックの要求をビデオサーバ
２０へ送信する（ステップ８２，８９）。ビデオサーバ
２０からビットストリームを受信し（ステップ９０）、
一時的にバッファへ蓄積していく（ステップ９１）。復
号化単位分のデータが蓄積できた時点でデコードを開始
しディスプレイへ表示する（ステップ９２）。さらに、
端末３０はユーザからの再生状態変更要求が無いかを判
断し（ステップ８２）、無い場合には継続するブロック
の要求をビデオサーバ２０へ送信する（ステップ８
９）。再生状態変更要求がない間は上記のような動作を
繰り返す。

【００４６】再生状態変更要求があれば再生状態変更要
求をビデオサーバ２０に送信した後（ステップ８３）、
ビデオサーバ２０から送信されてくるビットストリーム
を受信し、バッファに蓄積し、新／旧フラグの領域を検
査する（ステップ８４〜８７）。要求前と同じ値が入っ
ていれば、そのデータを破棄し（ステップ８８）、次の
データを受信する（ステップ８４）。新／旧フラグの領
域に要求前と異なる値が入っていればそのデータから再
生を開始する（ステップ９２）。

【００４７】図５は端末３０とビデオサーバ２０間のデ
ータの具体的なやりとり、および新／旧フラグの遷移の
一例を示す。この例では、新／旧フラグの初期値を１と
して、再生状態変更要求を受信するたびに、１ずつ増や
すこととする。端末３０では、ブロック３を受信した
後、ユーザからブロック２０へのジャンプの要求を受け
たとする。そのとき、ブロック３に設定されている新／
旧フラグの値は１である。次に、端末３０は、ブロック
４のデータを受信した。このブロック４は、ジャンプの
要求がビデオサーバ２０で受付られる前にビデオサーバ
２０から送信されているため、新／旧フラグの値は１で
ある。したがって、端末３０では、ブロック４を破棄す
る。その後、ブロック２０のデータを受信する。このデ
ータの新／旧フラグは２に設定されているので、端末３
０ではこのデータからデコードを開始することができ
る。

【００４８】また、端末３０でブロック２１をデコード
中にブロック３０へのジャンプ要求をユーザから受け、
その直後にブロック４０へのジャンプ要求を受けたとす
る。このジャンプの要求とすれ違いで、ブロック３０の
データがビデオサーバ２０から送信されてくる。このデ
ータの新／旧フラグは３となっているのが、端末３０で
は、ブロック４０へのジャンプの要求を送信しており期
待している新／旧フラグの値は４であるので、ブロック
３０は破棄する。次に、ブロック４０のデータがビデオ
サーバ２０から送信されてくる。このデータの新／旧フ
ラグは４であるので、このデータから端末３０でデコー
ドを開始することができる。

【００４９】なお、ビットストリームのブロックへの分
割はエンコーダシステム１０で行うこともできる。

【００５０】

【発明の効果】以上説明したように、本発明によれば、
新たに読出したブロックが直前に読出したブロックとビ
デオの符号化シーケンス上連続するか否かを示す情報を
ビットストリームの符号化の単位毎に設け、ビットスト
リームを再生する時に、符号化されたビットストリーム
の内容を解釈して、前記情報の位置が前記ブロックの先
頭から固定の位置になるようにビットストリームを前記
ブロックへ分割することによって、前記ブロックの中の
最初の前記情報の位置を前記ブロックの先頭から固定の
位置としたものであり、ビデオサーバにおいて前記情報
の探索および設定処理を容易にでき、端末において前記
情報を用いて受信したビットストリームの新旧を識別し
て旧ビットストリームの場合にはそれを破棄することに
よって新たなビットストリームを速やかに受信できるよ
うにしたものであるから、ジャンプや飛ばし読み再生等
のビデオの符号化シーケンスとは異なる順番でビットス
トリームを再生する時に、ビデオサーバが提供できるビ
ットストリーム数を増加させることができることと、応
答遅延が短く使い勝手の良いビジュアルサーチ機能を実
現できるという効果がある。

【図面の簡単な説明】

【図１】本発明の一実施形態のビデオオンデマンドシス
テムの構成図である。

【図２】図１の実施形態におけるビットストリームの蓄
積フォーマットを示す図である。

【図３】ビデオサーバ２０の処理を示すフローチャート
である。

【図４】端末３０の処理を示すフローチャートである。

【図５】ビデオサーバ２０と端末３０間での新／旧フラ
グの遷移図である。

【図６】ビデオオンデマンドシステムの従来例の構成図
である。

【図７】図６の従来例におけるビットストリームの蓄積
フォーマットを示す図である。

【符号の説明】

１０ エンコーダシステム １１ ビデオ入力装置 １２ ビデオ入力処理装置 １３ ＭＰＥＧビデオエンコーダ １４ オーディオ入力装置 １５ オーディオ入力処理装置 １６ ＭＰＥＧオーディオエンコーダ １７ ＭＰＥＧシステムエンコーダ １８ ネットワークインタフェース ２０ ビデオサーバ ２１ 蓄積装置 ２２ 蓄積装置インタフェース ２３ 蓄積装置コントローラ ２４ バッファ ２５ ネットワークインタフェース ２６ 蓄積フォーマット変換部 ３０ 端末 ３１ デコーダ ４０ ネットワーク ５０ シーケンスヘッダ ５１ ＧＯＰ ５２ ＧＯＰヘッダ ５３ ＧＯＰデータ ５４ ビデオパケット ５５ ビデオパケットヘッダ ５６ ビデオパケットデータ ５７ ビデオパック ５８ ビデオパックヘッダ ５９ ビデオパックデータ ６０ ＡＡＵ ６１ オーディオパケット ６２ オーディオパケットヘッダ ６３ オーディオパケットデータ ６４ オーディオパック ６５ オーディオパックヘッダ ６６ オーディオパックデータ ６７ ブロック ６８ ブロックヘッダ ６９ ブロックデータ ７０ ブロークンリンクフラグ ７１〜７９，８１〜９２ ステップ

───────────────────────────────────────────────────── フロントページの続き (72)発明者 西村 一敏 東京都新宿区西新宿三丁目19番２号 日 本電信電話株式会社内 (72)発明者 君山 博之 東京都新宿区西新宿三丁目19番２号 日 本電信電話株式会社内 (72)発明者 大串 美希子 東京都新宿区西新宿三丁目19番２号 日 本電信電話株式会社内 (72)発明者 川口 知昭 東京都新宿区西新宿三丁目19番２号 日 本電信電話株式会社内 (56)参考文献 特開 平９−121324（ＪＰ，Ａ) 特開 平６−268995（ＪＰ，Ａ) (58)調査した分野(Int.Cl.⁷，ＤＢ名) H04N 5/76 - 5/956 H04N 7/24 - 7/68 G11B 20/10 - 20/12

Claims (11)

(57)【特許請求の範囲】
1. 【請求項１】 画像情報と音声情報を処理して構成され
   たビットストリームを再生する時に、新たに読出したブ
   ロックが直前に読出したブロックとビデオの符号化シー
   ケンス上連続するか否かを示す情報を前記ビットストリ
   ームの復号化の単位ごとに設定し、符号化されたビット
   ストリームの内容を解釈して、前記情報の位置が当該ブ
   ロックの先頭から固定の位置になるように前記ビットス
   トリームを前記ブロックへ分割する、ビットストリーム
   の再生方法。
2. 【請求項２】 前記情報をＭＰＥＧシステム層のプライ
   ベートな領域に設定する、請求項１記載の、ビットスト
   リームの再生方法。
3. 【請求項３】 前記情報としてＭＰＥＧビデオ層のブロ
   ークンリンクフラグを用いる、請求項１記載の、ビット
   ストリームの再生方法。
4. 【請求項４】 前記プライベートな領域の先頭を境界と
   して前記ビットストリームを前記ブロックへ分割する、
   請求項１記載の、ビットストリームの再生方法。
5. 【請求項５】 ＭＰＥＧビデオ層のシーケンスヘッダの
   先頭を境界として前記ビットストリームを前記ブロック
   へ分割する、請求項１記載の、ビットストリームの再生
   方法。
6. 【請求項６】 ＭＰＥＧビデオ層のＧＯＰヘッダの先頭
   を境界として前記ビットストリームを前記ブロックへ分
   割する、請求項１記載の、ビットストリームの再生方
   法。
7. 【請求項７】 前記情報が複数のビットからなる情報で
   ある、請求項１記載の、ビットストリームの再生方法。
8. 【請求項８】 画像情報と音声情報を処理してビットス
   トリームを構成するエンコーダシステムと、前記ビット
   ストリームを小さなブロックに分割し、該ブロックを単
   位としてビットストリームの蓄積および再生を行うビデ
   オサーバと、前記ビットストリームを再生する端末と、
   前記エンコーダシステムと前記ビデオサーバと前記端末
   を接続するネットワークを有するビデオオンデマンドシ
   ステムにおいて、 前記ビットストリームを再生する時に、新たに読出した
   ブロックが直前に読出したブロックとビデオの符号化シ
   ーケンス上連続するか否かを示す情報を前記ビットスト
   リームの復号化の単位ごとに設定し、 符号化されたビットストリームの内容を解釈し、前記情
   報の位置が当該ブロックの先頭から固定の位置になるよ
   うに前記ビットストリームを前記ブロックを分割し、 前記端末において、再生状態変更要求を送信した場合に
   は、前記ビットストリーム中の前記情報を参照し、新た
   に受信したブロックが直前に受信したブロックとビデオ
   の符号化シーケンス上連続することを示していれば新た
   に受信したデータを破棄して次のデータの受信を待ち、
   新たに受信したブロックが直前に受信したブロックとビ
   デオの符号化シーケンス上連続していないことを示して
   いれば、新たに受信したデータから再生を開始する、ビ
   ットストリームの再生方法。
9. 【請求項９】 前記情報として複数のビットからなる情
   報を用い、前記端末から前記ビデオサーバに新規のビッ
   トストリームの要求がある毎に前記情報を変更してい
   く、請求項８記載の、ビットストリームの再生方法。
10. 【請求項１０】 前記情報をＭＰＥＧシステム層のプラ
    イベートな領域に設定する、請求項８記載の、ビットス
    トリームの再生方法。
11. 【請求項１１】 画像情報と音声情報を処理し、ビット
    ストリームを構成するエンコーダシステムと、前記ビッ
    トストリームを小さなブロックに分割し、該ブロックを
    単位としてビットストリームの蓄積および再生を行うビ
    デオサーバと、前記ビットストリームを再生する端末
    と、前記エンコーダシステムと前記ビデオサーバと前記
    端末を接続するネットワークを有するビデオオンデマン
    ドシステムにおいて、 符号化されたビットストリームの内容を解釈し、前記ビ
    ットストリームの、新たに読出したブロックが直前に読
    出したブロックとビデオの符号化シーケンス上連続する
    か否かを示す情報の位置が当該ブロックの先頭から固定
    の位置になるように前記ビットストリームを前記ブロッ
    クへ分割する手段を前記エンコーダシステムまたは前記
    ビデオサーバが有することを特徴とするビデオオンデマ
    ンドシステム。