(57)【要約】【課題】コンテンツデータ、トリックプレイ用のデータを保持する必要がないため、低コストで実現することができるコンテンツ統合サーバを提供する。【解決手段】トリックプレイのコマンドを受信する受信手段１１と、コンテンツ情報を格納するコンテンツ情報格納手段１５と、フレームレートを取得するフレームレート取得手段１６と、一時停止要求の場合コマンドを受信した時点以降のキーフレームを、早送り又は早戻し要求の場合コマンドを受信した時点以降又は以前のキーフレームを取得するキーフレーム取得手段１８と、一時停止要求の場合取得されたキーフレームのタイムコードを変更し、早送り又は早戻し要求の場合、キーフレーム間のフレーム数と早送り又は早戻し速度情報に基づき決定された送信枚数分キーフレームのタイムコードを変更して出力するタイムコード変更手段１９と、キーフレームをプレーヤに送信する送信手段１２を備える。【選択図】図１
2008172629.tif 000002
【特許請求の範囲】
【請求項１】
フレーム構造を有するデータからなるコンテンツを有するコンテンツサーバから、再生装置の要求に応じて前記コンテンツを取得し、取得された前記コンテンツを前記再生装置に送信するコンテンツ統合サーバであって、
前記コンテンツを再生している前記再生装置から、再生している前記コンテンツの一時停止要求、所望の早送り速度情報を含む早送り要求、所望の早戻し速度情報を含む早戻し要求のいずれかを示すコマンドを受信する受信手段と、
前記コンテンツサーバが有する前記コンテンツに関する情報を格納するコンテンツ情報格納手段と、
再生している前記コンテンツを構成する、フレームごとにタイムコードが付されたコンテンツデータのフレームレートを前記コンテンツ情報格納手段から取得するフレームレート取得手段と、
受信された前記コマンドが前記一時停止要求である場合には、前記コマンドを受信した時点以降の送信予定の直近の、前記コンテンツを構成する複数のフレームを所定のグループに分ける際に基準となるフレームであるキーフレームを取得し、
受信された前記コマンドが前記早送り要求である場合には、前記コマンドを受信した時点以降の送信予定の、前記コンテンツを構成する複数のフレームを所定のグループに分ける際に基準となるフレームであるキーフレームを取得し、
受信された前記コマンドが前記早戻し要求である場合には、前記コマンドを受信した時点以前の送信済みの、前記コンテンツを構成する複数のフレームを所定のグループに分ける際に基準となるフレームであるキーフレームを取得するキーフレーム取得手段と、
前記コマンドが前記一時停止要求である場合には、取得された前記キーフレームのタイムコードを、取得された前記フレームレートに応じて逐次変更し、前記タイムコードが逐次変更された前記キーフレームを出力し、
前記コマンドが前記早送り要求である場合には、前記コンテンツ情報格納手段に格納されたキーフレーム間のフレーム数及び前記早送り速度情報に基づいて、早送りの際における、取得された前記キーフレームの前記再生装置への送信枚数を決定し、取得された前記キーフレームの前記タイムコードを、取得された前記フレームレートに応じて前記決定された送信枚数分逐次変更し、前記タイムコードが逐次変更された前記キーフレームを出力し、
前記コマンドが前記早戻し要求である場合には、前記コンテンツ情報格納手段に格納されたキーフレーム間のフレーム数及び前記早戻し速度情報に基づいて、早戻しの際における、取得された前記キーフレームの前記再生装置への送信枚数を決定し、取得された前記キーフレームの前記タイムコードを、取得された前記フレームレートに応じて前記決定された送信枚数分逐次変更し、前記タイムコードが逐次変更された前記キーフレームを出力するタイムコード変更手段と、
出力された前記キーフレームを前記再生装置に送信する送信手段とを、
備えるコンテンツ統合サーバ。
【請求項２】
前記一時停止要求、前記早送り要求、前記早戻し要求のいずれか１つの要求に基づいて、前記キーフレームが前記再生装置に送信されている際に、前記受信手段が前記再生装置から再生要求を示すコマンドを受信した場合、
前記タイムコード変更手段は、前記再生要求を示すコマンドを受信する直前に送信された前記キーフレームのタイムコードと、前記キーフレームが最初に送信された際のタイムコードとの差分値を計算し、計算により得られた前記差分値を前記送信されたキーフレーム以降に送信される予定のフレームのタイムコードに加算して前記タイムコードを逐次変更し、前記タイムコードが逐次変更された前記フレームを出力し、
前記送信手段は、出力された前記フレームを前記再生装置に送信する請求項１に記載のコンテンツ統合サーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを経由して映像・音声などを再生することが可能なコンテンツシステムにおけるコンテンツ統合サーバに関する。
【背景技術】
【０００２】
現在、パーソナルコンピュータやネットワーク機器の高速化により、ネットワークを経由してネットワーク越しのサーバに記録されている映像、音声などを再生するネットワークメディアプレーヤが出現している。また、様々なメーカーのサーバ、クライアントの相互接続性を実現するために、ＤＬＮＡ（Digital Living Network Alliance）により標準化が進められており、ＤＬＮＡ準拠のネットワークメディアサーバ／プレーヤが発売されている。このようなネットワークメディアサーバ／プレーヤにおいて、早送りや早戻しのようなトリックプレイを行う場合、プレーヤはサーバのデータに対して飛び飛びにランダムにアクセスしてデータを取得する必要がある。しかし、ＭＰＥＧ（Moving Picture Expert Group）の可変ビットレートのようにデータ量とタイムコードが必ずしも線形でない場合があり、一定の倍速で早送りや早戻しを行うことが困難となる。
【０００３】
これを解決する手段が下記の特許文献１に記載されている。特許文献１では、元の動画データとは別個にトリックプレイ用の動画データを蓄積する方法などが記載されている。この記載された技術は、トリックプレイのための動画符号化データをあらかじめ蓄積しておき、プレーヤがトリックプレイを行う場合、プレーヤはトリックプレイ用のデータを通常の再生と同じように再生するというものである。
【特許文献１】特開平８−１５４２３０号公報（段落００２０）
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、特許文献１に記載された技術では、トリックプレイを実現するためにトリックプレイ用の動画データを保持するため、１つの動画コンテンツに対して複数の動画データを蓄積する必要があり、データ容量が増大し、動画コンテンツを蓄積する記憶媒体のコストが増すことになる。また、２倍速、４倍速、３２倍速など多様なトリックプレイの要求に応じるには、それぞれに専用の動画データが必要となる。
【０００５】
本発明は、上記課題を解決するためのものであり、コンテンツデータ、トリックプレイ用のデータを保持する必要がないため、低コストで実現することができるコンテンツ統合サーバを提供することを目的とする。また、本発明によれば、同一ネットワークに接続されているサーバのコンテンツを統合管理することができる。また、バイトレンジ（ファイルの先頭からのバイト数）によるシーク（探索）のみ実装すればよく、開発が容易になる。
【課題を解決するための手段】
【０００６】
上記目的を達成するために、本発明によれば、フレーム構造を有するデータからなるコンテンツを有するコンテンツサーバから、再生装置の要求に応じて前記コンテンツを取得し、取得された前記コンテンツを前記再生装置に送信するコンテンツ統合サーバであって、前記コンテンツを再生している前記再生装置から、再生している前記コンテンツの一時停止要求、所望の早送り速度情報を含む早送り要求、所望の早戻し速度情報を含む早戻し要求のいずれかを示すコマンドを受信する受信手段と、前記コンテンツサーバが有する前記コンテンツに関する情報を格納するコンテンツ情報格納手段と、再生している前記コンテンツを構成する、フレームごとにタイムコードが付されたコンテンツデータのフレームレートを前記コンテンツ情報格納手段から取得するフレームレート取得手段と、受信された前記コマンドが前記一時停止要求である場合には、前記コマンドを受信した時点以降の送信予定の直近の、前記コンテンツを構成する複数のフレームを所定のグループに分ける際に基準となるフレームであるキーフレームを取得し、受信された前記コマンドが前記早送り要求である場合には、前記コマンドを受信した時点以降の送信予定の、前記コンテンツを構成する複数のフレームを所定のグループに分ける際に基準となるフレームであるキーフレームを取得し、受信された前記コマンドが前記早戻し要求である場合には、前記コマンドを受信した時点以前の送信済みの、前記コンテンツを構成する複数のフレームを所定のグループに分ける際に基準となるフレームであるキーフレームを取得するキーフレーム取得手段と、前記コマンドが前記一時停止要求である場合には、取得された前記キーフレームのタイムコードを、取得された前記フレームレートに応じて逐次変更し、前記タイムコードが逐次変更された前記キーフレームを出力し、前記コマンドが前記早送り要求である場合には、前記コンテンツ情報格納手段に格納されたキーフレーム間のフレーム数及び前記早送り速度情報に基づいて、早送りの際における、取得された前記キーフレームの前記再生装置への送信枚数を決定し、取得された前記キーフレームの前記タイムコードを、取得された前記フレームレートに応じて前記決定された送信枚数分逐次変更し、前記タイムコードが逐次変更された前記キーフレームを出力し、前記コマンドが前記早戻し要求である場合には、前記コンテンツ情報格納手段に格納されたキーフレーム間のフレーム数及び前記早戻し速度情報に基づいて、早戻しの際における、取得された前記キーフレームの前記再生装置への送信枚数を決定し、取得された前記キーフレームの前記タイムコードを、取得された前記フレームレートに応じて前記決定された送信枚数分逐次変更し、前記タイムコードが逐次変更された前記キーフレームを出力するタイムコード変更手段と、出力された前記キーフレームを前記再生装置に送信する送信手段とを、備えるコンテンツ統合サーバが提供される。この構成により、コンテンツデータ、トリックプレイ用のデータを保持する必要がないため、低コストで実現することができる。なお、上述した再生装置はプレーヤとも言う。
【０００７】
また、本発明のコンテンツ統合サーバにおいて、前記一時停止要求、前記早送り要求、前記早戻し要求のいずれか１つの要求に基づいて、前記キーフレームが前記プレーヤに送信されている際に、前記受信手段が前記プレーヤから再生要求を示すコマンドを受信した場合、前記タイムコード変更手段が、前記再生要求を示すコマンドを受信する直前に送信された前記キーフレームのタイムコードと、前記キーフレームが最初に送信された際のタイムコードとの差分値を計算し、計算により得られた前記差分値を前記送信されたキーフレーム以降に送信される予定のフレームのタイムコードに加算して前記タイムコードを逐次変更し、前記タイムコードが逐次変更された前記フレームを出力し、前記送信手段が出力された前記フレームを前記プレーヤに送信することは、本発明の好ましい態様である。この構成により、トリックプレイ後であってもスムーズにコンテンツを再生することができる。
【発明の効果】
【０００８】
本発明のコンテンツ統合サーバは上記構成を有するので、接続された再生装置（プレーヤ）はトリックプレイをスムーズに行うことが可能となる。また、このコンテンツ統合サーバでは、コンテンツデータ、トリックプレイ用のデータを保持する必要がないため、低コストで実現することができる。
【発明を実施するための最良の形態】
【０００９】
以下、本発明の実施の形態に係るコンテンツ統合サーバについて図１から図１８を用いて説明する。図１は本発明の実施の形態に係るコンテンツ統合サーバを含むコンテンツシステムの構成の一例を示す構成図である。図２は本発明の実施の形態におけるディレクトリ情報の一例を示す図である。図３は本発明の実施の形態におけるコンテンツ情報蓄積手段に蓄積されるサーバごとのコンテンツ情報の一例を示す図である。図４は本発明の実施の形態におけるコンテンツ一覧の一例を示す図である。図５は本発明の実施の形態における作成されるコンテンツ情報の構成の一例を示す図である。図６は本発明の実施の形態におけるＩ、Ｂ、Ｐのフレーム構造で構成されるＭＰＥＧデータの一例を示す図である。図７は本発明の実施の形態に係るコンテンツ統合サーバの動作フローの一例について説明するためのフローチャートである。図８は本発明の実施の形態におけるコンテンツ情報収集ステップについて説明するためのフローチャートである。
【００１０】
図９は本発明の実施の形態における再生ステップについて説明するためのフローチャートである。図１０は本発明の実施の形態における一時停止ステップについて説明するためのフローチャートである。図１１は本発明の実施の形態におけるトリックプレイ（一時停止）の場合の処理について説明するための図である。図１２は本発明の実施の形態における早送り／早戻しステップについて説明するためのフローチャートである。図１３は本発明の実施の形態におけるトリックプレイ（早送り）の場合の処理について説明するための図である。図１４は本発明の実施の形態におけるトリックプレイ（早戻し）の場合の処理について説明するための図である。図１５は本発明の実施の形態におけるレジューム再生ステップについて説明するためのフローチャートである。図１６は本発明の実施の形態におけるトリックプレイ（一時停止）から再生する場合の処理について説明するための図である。図１７は本発明の実施の形態におけるトリックプレイ（早送り）から再生する場合の処理について説明するための図である。図１８は本発明の実施の形態におけるトリックプレイ（早戻し）から再生する場合の処理について説明するための図である。
【００１１】
まず、本発明の実施の形態に係るコンテンツ統合サーバを含むコンテンツシステムについて図１を用いて説明する。図１に示すように、コンテンツシステムは、２台のネットワークメディアサーバ（以下、サーバＡ、サーバＢとも言う）と、ネットワークメディアプレーヤ（以下、単にプレーヤ１とも言う）と、コンテンツ統合サーバ（以下、単に統合サーバとも言う）１０とから構成され、それぞれが同一のネットワークに接続されている。なお、ここでのコンテンツシステムの構成は一例であり、それぞれの台数などはこれに限られるものではない。
【００１２】
本発明の実施の形態では、サーバＡ、サーバＢが保持しているコンテンツデータ（動画ファイル又は単にコンテンツとも言う）は、例えば図６に示すようなＩ、Ｂ、Ｐピクチャフレームで構成されるＭＰＥＧデータであるものとする。ここで、Ｉピクチャフレーム（Ｉフレームとも言う）は、後述するキーフレームに相当し、コンテンツを構成する複数のフレーム（Ｉ、Ｂ、Ｐピクチャフレーム）を所定の（編集単位の）グループ（ＧＯＰ（Group Of Picture）：ＭＰＥＧにおいて定められている動画を構成している最小の単位構造）に分ける際に基準となるフレームである。また、プレーヤ１はサーバＡ、サーバＢがあらかじめ保持しているＭＰＥＧデータをデコードする不図示のＭＰＥＧデコーダを有しており、コンテンツを受信・再生することができるものとする。
【００１３】
ここで、まず統合サーバ１０の概要について説明する。統合サーバ１０は、ネットワーク内のサーバＡ、サーバＢが有するコンテンツの情報（コンテンツ情報）を収集・蓄積する。その際、コンテンツそのものは蓄積しない。また、統合サーバ１０は、プレーヤ１に対してはサーバＡ、サーバＢと同様に、要求されたコンテンツを配信するサーバとして振舞う。その際、あらかじめ蓄積されたコンテンツ情報に基づいて要求されたコンテンツを有するサーバ（サーバＡ又はサーバＢ）を特定し、特定されたサーバからコンテンツを受信し、プレーヤ１へ送信する。また、プレーヤ１からトリックプレイ（一時停止、早送り、早戻し）を要求された場合、統合サーバ１０は、プレーヤ１が通常再生を行っている状態で、プレーヤ１の要求するトリックプレイが実現されるようにコンテンツを加工して送信する。トリックプレイの実現に関しては後述する。
【００１４】
次に、統合サーバ１０の構成の一例について説明する。なお、統合サーバ１０の構成はこれに限られるものではない。図１に示すように、統合サーバ１０は複数の構成要素から構成されている。まず、受信手段１１について説明する。受信手段１１は、プレーヤ１から受信した、プレーヤ１のユーザが所望する処理をさせるためのコマンドデータ１０２を制御手段１０６へ、サーバＡ又はサーバＢから受信したコンテンツデータ１０１をコンテンツ分岐手段１３へ、サーバＡ又はサーバＢから受信したディレクトリ情報１０９をコンテンツ情報取得手段１４へそれぞれ出力する。ここで、ディレクトリ情報１０９の一例を図２に示す。図２に示すディレクトリ情報は、サーバＡ、サーバＢが有するコンテンツを示しており、各サーバのディレクトリ構造も含まれる。図２から、サーバＡ及びサーバＢはビデオ、オーディオ、ピクチャのカテゴリ（フォルダ）ごとにファイル（コンテンツ）をそれぞれ有していることがわかる。
【００１５】
コンテンツ情報取得手段１４は、ディレクトリ情報１０９を用いて各サーバ（サーバＡ、サーバＢ）からコンテンツデータを受信し、コンテンツ情報１０３を作成し、後述するコンテンツ情報蓄積手段１５（上述したコンテンツ情報格納手段に相当）に格納する。ここで、コンテンツ情報１０３について説明する。例えば、図２に示すサーバＡのビデオファイルＡが、図６に示すフレーム構造を有するフレームレート２５fps（フレーム／秒）のＭＰＥＧデータであった場合のコンテンツ情報を図５に示す。コンテンツ情報１０３は、そのコンテンツファイルを保持しているサーバ名、ファイル名、ファイルサイズ、サーバ上のパス（例えば、「ビデオ」のカテゴリ（フォルダ）の配下にあることを示すもの）、フレームレート、キーフレーム（Ｉフレームとも言う）テーブルからなる。また、キーフレームテーブルは、フレーム番号（キーフレームのフレーム番号）、バイトレンジ（該当するキーフレームのファイルの先頭からのバイト数）、タイムコード（該当するキーフレームのファイルの先頭からの時間）からなる。
【００１６】
このコンテンツ情報１０３は、コンテンツデータそのものは含まないので、元のコンテンツデータに比べてデータ量は極めて少ない。図５の例では、ビデオファイルＡはファイルサイズ５２，４２８，８００byte（バイト）、フレームレート２５fpsの動画ファイルであり、サーバＡのビデオフォルダに格納されている。このようなコンテンツ情報１０３を、コンテンツ情報取得手段１４は、図３に示すようにコンテンツ情報のデータベースとして、サーバごとに後述するコンテンツ情報蓄積手段１５に格納する。
【００１７】
コンテンツ分岐手段１３は、後述する制御手段１６からの指示に基づいて、受信したコンテンツデータ１０１の出力を、コンテンツ情報取得手段１４、後述する映像／音声分離手段１７、タイムコード変更手段１９、送信手段１２のいずれかに対して行う。
【００１８】
映像／音声分離手段１７は、コンテンツ分岐手段１３から入力されたコンテンツデータ１０１を映像データ（ビデオデータ）と音声データに分離し、ビデオデータ１０４をキーフレーム取得手段１８及びタイムコード変更手段１９へ出力する。
【００１９】
キーフレーム取得手段１８は、映像／音声分離手段１７から入力されたビデオデータ１０４から、キーフレームのデータ（キーフレームデータ）１０６を取得し、タイムコード変更手段１９へ出力する。タイムコード変更手段１９は、主として後述するようにフレームに付されたタイムコードを変更する。送信手段１２は、コンテンツ分岐手段１３から入力されたコンテンツデータ１０１、タイムコード変更手段１９で加工された加工済みコンテンツデータ１１１、又はコンテンツ情報蓄積手段１５に蓄積されたコンテンツ情報１０３に基づいて制御手段１６によって作成されたコンテンツ一覧１１０をプレーヤ１に送信する。
【００２０】
次に、統合サーバ１０の動作について図７を用いて説明する。まず、統合サーバ１０はプレーヤ１からのアクセスがあるか否かを判断する（ステップＳ７０１）。プレーヤ１からのアクセスがない場合にはコンテンツ情報収集ステップＳ７０２へ進む。なお、各ステップにおける処理については後述する。一方、プレーヤ１からのアクセスがある場合には、アクセスの際のコマンドがどのようなものかを判断する（ステップＳ７０３）。コマンドがコンテンツ一覧要求である場合、コンテンツ一覧送信ステップＳ７０４へ進み、コマンドが再生要求である場合、再生ステップＳ７０５へ進む。
【００２１】
再生ステップＳ７０５へ進み、その後、再生が行われている際にプレーヤ１からコマンドを受けた場合、そのコマンドがどのようなものかを判断する（ステップＳ７０６）。受けたコマンドが早送り又は早戻し要求である場合、早送り／早戻しステップＳ７０８へ進む。また、受けたコマンドが一時停止要求である場合、一時停止ステップＳ７０７へ進み、受けたコマンドが停止要求である場合、ステップＳ７０１へ進む。
【００２２】
一時停止ステップＳ７０７又は早送り／早戻しステップＳ７０８の際に、プレーヤ１からコマンドを受けた場合、そのコマンドがどのようなものかを判断する（ステップＳ７０９）。受けたコマンドが再生要求である場合、レジューム再生ステップＳ７１０へ進み、受けたコマンドが停止要求である場合、ステップＳ７０１へ進む。レジューム再生ステップＳ７１０において、再生が終了したか否かを判断する（ステップＳ７１１）。再生が終了していない場合にはステップＳ７０６に戻り、再生が終了した場合にはそのまま終了となる。以下では図７に示す各ステップの詳細について説明する。
【００２３】
まず、コンテンツ情報収集ステップＳ７０２について図８を用いて説明する。まず、コンテンツ分岐変更ステップＳ８０１では、制御手段１６がコンテンツ分岐手段１３の出力をコンテンツ情報取得手段１４へ切り換える。そして、サーバ検索ステップＳ８０２では、制御手段１６がネットワーク内でコンテンツを保持しているサーバ（サーバＡ、サーバＢ）を検索する。サーバを発見した場合、制御手段１６がそのサーバにそのサーバが有しているコンテンツが認識できるような不図示のコンテンツの一覧を要求する（コンテンツ一覧要求ステップＳ８０３）。一方、サーバを発見しない場合には終了となる。コンテンツ情報比較ステップＳ８０４では、制御手段１６が、サーバに要求した不図示のコンテンツの一覧と、コンテンツ情報蓄積手段１５のコンテンツ情報とを比較する。
【００２４】
そして、コンテンツ情報蓄積手段１５内のコンテンツ情報に含まれないコンテンツをサーバが保持している場合には、コンテンツ情報取得ステップＳ８０５へ進む。コンテンツ情報取得ステップＳ８０５では、コンテンツ情報取得手段１４が、受信する該当するすべてのコンテンツデータに基づいて、例えば図５に示すコンテンツ情報を作成し、コンテンツ情報蓄積手段１５に蓄積する。なお、コンテンツ情報蓄積手段１５内のコンテンツ情報に含まれないコンテンツをサーバが保持していない場合には、そのまま終了する。
【００２５】
次に、コンテンツ一覧送信ステップＳ７０４について説明する。コンテンツ一覧送信ステップＳ７０４では、送信手段１２が、コンテンツ情報蓄積手段１５内のコンテンツ情報に基づいて制御手段１６によって作成されたコンテンツ一覧１１０をプレーヤ１へ送信する。例えば、コンテンツ情報蓄積手段１５に図３に示すようなコンテンツ情報１０３が蓄積されている場合、制御手段１６は、コンテンツ情報に基づいて制御手段１６自身が作成した図４に示すコンテンツ一覧１１０を送信手段１２に送信させる。すなわち、統合サーバ１０は、コンテンツ情報１０３の元となるコンテンツデータは保持していないにも関わらず、プレーヤ１に対してコンテンツデータを保持しているかのように振舞う。
【００２６】
次に、再生ステップＳ７０５について図９を用いて説明する。まず、コンテンツ分岐変更ステップＳ９０１では、制御手段１６が、コンテンツ分岐手段１３の出力を送信手段１２に切り換える。コンテンツ情報取得ステップＳ９０２では、制御手段１６が、プレーヤ１からの要求（送信して欲しいコンテンツを示す情報）に基づいて、コンテンツ情報蓄積手段１５から該当するコンテンツ情報を取得する。コンテンツ検索ステップＳ９０３では、制御手段１６が、コンテンツ情報取得ステップＳ９０２で得られたコンテンツ情報に基づいて、そのコンテンツを保持するサーバを特定し、プレーヤ１が要求するコンテンツデータの有無を特定されたサーバに確認する。
【００２７】
コンテンツデータがある場合にはコンテンツ受信ステップＳ９０４へ進み、コンテンツデータがない場合には再生ステップＳ７０５は終了する。コンテンツ受信ステップＳ９０４では、受信手段１１が、コンテンツ検索ステップＳ９０３で特定されたサーバからコンテンツデータを受信する。コンテンツ送信ステップＳ９０５では、送信手段１２が、受信したコンテンツデータをプレーヤ１へ送信する。そして、プレーヤ１から再生停止のコマンドがない場合（再生終了がない）は、コンテンツ受信ステップＳ９０４及びコンテンツ送信ステップＳ９０５を繰り返し実行する。
【００２８】
一方、再生停止のコマンドがプレーヤ１からあった場合（再生終了があった）は、再生ステップＳ７０５は終了する。すなわち、再生ステップＳ７０５では、プレーヤ１から再生要求があったコンテンツデータが、ネットワーク上のどのサーバに保持されているかをコンテンツ情報蓄積手段１５に蓄積されたコンテンツ情報から特定し、要求されたコンテンツデータを特定されたサーバから受信し、それをそのままプレーヤ１へ送信する。
【００２９】
次に、一時停止ステップＳ７０７について図１０を用いて説明する。まず、コンテンツ分岐変更ステップＳ１００１では、制御手段１６が、受信手段１１を介して受信したトリックプレイ（ここでは一時停止）の要求に基づいて、コンテンツ分岐手段１３の出力を映像／音声分離手段１７に切り換える。フレームレート通知ステップＳ１００２では、制御手段１６（上述したフレームレート取得手段に相当）が、コンテンツ情報蓄積手段１５のコンテンツ情報から取得したフレームレートの情報（フレームレート情報）１０５をタイムコード変更手段１９へ通知する。キーフレーム取得ステップＳ１００３では、キーフレーム取得手段１８が入力されたビデオデータ１０４からキーフレームを取得する。すなわち、キーフレーム取得手段１８は、一時停止のコマンドを受信した時点以降のキーフレーム（例えば、直近のキーフレーム）を取得する。
【００３０】
タイムコード変更ステップＳ１００４では、タイムコード変更手段１９が、フレームレート通知ステップ１００２で、制御手段１６から通知されたフレームレート情報１０５から、次のタイムコードを求めて、キーフレーム取得手段１８から入力されたキーフレームのデータ（キーフレームデータ）１０６のタイムコードを変更する。送信ステップＳ１００５では、タイムコード変更手段１９によってタイムコードが変更されたキーフレームデータ（加工済みコンテンツデータ１１１）を、送信手段１２がプレーヤ１へ送信する。そして、プレーヤ１から一時停止終了の要求があるまでタイムコード変更ステップＳ１００４及び送信ステップＳ１００５が繰り返される。
【００３１】
ここで、具体的に図５、図６、図１１を用いて説明する。プレーヤ１への再生中のコンテンツデータが図６に示すフレーム構造を有するフレームレート２５fpsのＭＰＥＧデータであり、ＭＰＥＧデータのコンテンツ情報が図５に示されるものであるとする。その際に、図１１に示すように、コンテンツデータの７３フレーム目（フレーム番号７３）を送信中にプレーヤ１から一時停止の要求を受信手段１１が受信した場合、キーフレーム取得手段１８が送信予定の直近の７５フレーム目のＩフレームを取得し、タイムコード変更手段１９が、そのＩフレームのタイムコードを３０００[ms]、３０４０[ms]、３０８０[ms]、・・・といった具合にフレームレートに応じて（合わせて）逐次変更し、送信手段１２が繰り返し送信する。
【００３２】
これにより、プレーヤ１が受信するコンテンツデータのタイムコードが連続するように適宜変更されるため、プレーヤ１は、通常の再生を行う場合と同様に、デコード及び表示処理をするだけで一時停止を実現できる。
【００３３】
次に、早送り／早戻しステップＳ７０８について図１２を用いて説明する。まず、コンテンツ分岐変更ステップＳ１２０１では、制御手段１６が、受信手段１１を介して受信したトリックプレイ（ここでは、早送り又は早戻し）の要求に基づいて、コンテンツ分岐手段１３の出力を映像／音声分離手段１７に切り換える。フレームレート通知ステップＳ１２０２では、制御手段１６が、コンテンツ情報蓄積手段１５のコンテンツ情報から取得したフレームレート情報１０５をタイムコード変更手段１９へ出力する。
【００３４】
タイムコード取得ステップＳ１２０３では、制御手段１６が、タイムコード変更手段１９からプレーヤ１へ送信されたビデオデータ１０４の最終タイムコード（タイムコード情報）１０７を取得する。バイトレンジ取得ステップＳ１２０４では、制御手段１６が、コンテンツ情報蓄積手段１５内のフレームレート情報と、タイムコード取得ステップＳ１２０３で得たタイムコード情報１０７と、プレーヤ１から要求された再生速度（プレーヤ１から受信したコマンドに含まれる再生速度の情報）と、コンテンツ情報蓄積手段１５のコンテンツ情報から得られるキーフレームのテーブルから、適切なキーフレームのバイトレンジを求める。
【００３５】
キーフレーム取得ステップＳ１２０５では、制御手段１６が、バイトレンジ取得ステップＳ１２０４で求めたバイトレンジでサーバにデータを要求し、映像／音声分離手段１７が、受信手段１１を介して受信された受信データ（コンテンツ）を分離し、ビデオデータ１０４をキーフレーム取得手段１８へ出力し、キーフレーム取得手段１８が、入力されたビデオデータ１０４からキーフレームを取得する。すなわち、キーフレーム取得手段１８は、早送り又は早戻しのコマンドを受信した時点以降又は受信した時点以前のキーフレームを取得する。
【００３６】
キーフレーム出力枚数決定ステップＳ１２０６では、制御手段１６が、コンテンツ情報蓄積手段１５のコンテンツ情報から得られるキーフレーム間のフレーム数と、プレーヤ１から要求された再生速度の情報とから、キーフレーム取得ステップＳ１２０５で得られたキーフレームを何回プレーヤ１に送信するかを決定し、その回数（キーフレーム出力情報１１２）をタイムコード変更手段１９へ通知する。なお、キーフレーム出力枚数決定ステップＳ１２０６におけるプレーヤ１へのキーフレームの送信回数の決定をタイムコード変更手段１９が行うようにしてもよい。
【００３７】
タイムコード変更ステップＳ１２０７では、キーフレーム取得ステップＳ１２０５で得られたキーフレームに、タイムコード変更手段１９が適切なタイムコードを付与し、キーフレーム送信ステップＳ１２０８では、送信手段１２がそのキーフレームをプレーヤ１へ送信する。そして、ステップＳ１２０９において、プレーヤ１からトリックプレイの終了コマンドを受信した場合に、早送り／早戻しステップＳ７０８が終了し、終了コマンドを受信しない場合にはタイムコード取得ステップＳ１２０３へ移行し、処理を繰り返す。
【００３８】
ここで、早送り／早戻しステップＳ７０８における早送りの場合ついて具体的に図１３を用いて説明する。対象のコンテンツデータが図６に示すフレーム構造を有するフレームレート２５fpsのＭＰＥＧデータであり、そのデータのコンテンツ情報が図５に示すものであるとする。その際に、統合サーバ１０が、７３フレーム目のデータを送信した直後にプレーヤ１から３倍速の早送り要求を受信した場合を考える。
【００３９】
上述したように、コンテンツ分岐変更ステップＳ１２０１で、制御手段１６がコンテンツ分岐手段１３の出力を映像／音声分離手段１７に切り替え、フレームレート通知ステップＳ１２０２で、コンテンツ情報蓄積手段１５のコンテンツ情報からフレームレート（２５fps）を得る。タイムコード取得ステップＳ１２０３では、制御手段１６が７３フレーム目（フレーム番号７３）のコンテンツデータのタイムコード（２９２０ms）を取得する。
【００４０】
バイトレンジ取得ステップＳ１２０４では、制御手段１６が、７３フレーム目以降であって、コンテンツ情報に基づき、最も近いＩフレームのバイトレンジを求める。この例ではフレーム番号７５のＩフレームが該当し、求められるバイトレンジは図５により２５０００[ms]となる。キーフレーム取得ステップＳ１２０５では、制御手段１６が、該当するサーバに対してコンテンツデータを２５０００[byte]のバイトレンジで要求し、キーフレーム取得手段１８がＩフレームを取得する。キーフレーム出力枚数決定ステップ１２０６では、制御手段１６（又はタイムコード変更手段１９）が、プレーヤ１から要求された再生速度（この例では、３倍速早送り再生）と、受信するＭＰＥＧデータのＩフレーム間のフレームの枚数（この例では、１５枚）からキーフレームの出力枚数を決定する。この例では１５枚／３倍速＝５枚となる。
【００４１】
タイムコード変更ステップＳ１２０７では、プレーヤ１で３倍速によって再生されるように、タイムコード変更手段１９が、キーフレーム取得ステップＳ１２０５で得られたキーフレームのタイムコードを変更する。この場合、５枚のキーフレームのタイムコードを３０００[ms]、３０４０[ms]、・・・、３１６０[ms]に変更し、送信手段１２がプレーヤ１へ送信する。以上の手順を繰り返し、タイムコードを変更して適切なキーフレームをプレーヤ１へ送信する。これにより、プレーヤ１は通常の再生を行う場合と同様に、デコード及び表示処理を行うだけで早送り／早戻しを実現することができる。
【００４２】
一方、早送り／早戻しステップＳ７０８における早戻しの場合ついて具体的に図１４を用いて説明する。ここで、上述した早送りの場合と同様、対象のコンテンツデータが図６に示すフレーム構造を有するフレームレート２５fpsのＭＰＥＧデータであり、そのデータのコンテンツ情報が図５に示すものであるとする。その際に、統合サーバ１０が、９２フレーム目のデータを送信した直後にプレーヤ１から３倍速の早戻し要求を受信した場合を考える。
【００４３】
上述したように、コンテンツ分岐変更ステップＳ１２０１で、制御手段１６がコンテンツ分岐手段１３の出力を映像／音声分離手段１７に切り替え、フレームレート通知ステップＳ１２０２で、コンテンツ情報蓄積手段１５のコンテンツ情報からフレームレート（２５fps）を得る。タイムコード取得ステップＳ１２０３では、制御手段１６が９２フレーム目（フレーム番号９２）のコンテンツデータのタイムコード（３６８０ms）を取得する。
【００４４】
バイトレンジ取得ステップＳ１２０４では、制御手段１６が、９２フレーム目以前であって、コンテンツ情報に基づき、最も近いＩフレームのバイトレンジを求める。この例ではフレーム番号９０のＩフレームが該当し、求められるバイトレンジは図５により３００００[ms]となる。キーフレーム取得ステップＳ１２０５では、制御手段１６が、該当するサーバに対してコンテンツデータを３００００[byte]のバイトレンジで要求し、キーフレーム取得手段１８がＩフレームを取得する。キーフレーム出力枚数決定ステップ１２０６では、制御手段１６（又はタイムコード変更手段１９）が、プレーヤ１から要求された再生速度（この例では、３倍速早戻し再生）と、受信するＭＰＥＧデータのＩフレーム間のフレームの枚数（この例では、１５枚）からキーフレームの出力枚数を決定する。この例では１５枚／３倍速＝５枚となる。
【００４５】
タイムコード変更ステップＳ１２０７では、プレーヤ１で３倍速によって再生されるように、タイムコード変更手段１９が、キーフレーム取得ステップＳ１２０５で得られたキーフレームのタイムコードを変更する。この場合、５枚のキーフレームのタイムコードを３６００[ms]、３５６０[ms]、・・・、３４４０[ms]に変更し、送信手段１２がプレーヤ１へ送信する。以上の手順を繰り返し、タイムコードを変更して適切なキーフレームをプレーヤ１へ送信する。これにより、プレーヤ１は、通常の再生を行う場合と同様に、デコード及び表示処理を行うだけで早送り／早戻しを実現できる。
【００４６】
次に、レジューム再生ステップＳ７１０について図１５を用いて説明する。図１５は、プレーヤ１がトリックプレイ（一時停止、早送り、早戻し）中に通常の再生開始を要求するコマンドを統合サーバ１０へ送信した場合における統合サーバ１０の動作フローを示すものである。まず、コンテンツ分岐変更ステップＳ１５０１では、制御手段１６が、受信手段１１を介して受信した再生開始の要求に基づいて、コンテンツ分岐変更手段１３の出力をタイムコード変更手段１９へ切り換える。タイムコード差分値計算ステップＳ１５０２では、タイムコード変更手段１９が、コンテンツ分岐手段１３から入力されたコンテンツ情報のタイムコードと、トリックプレイ中にタイムコード変更手段１９から最後のコンテンツデータがプレーヤ１へ送信された際の時点でのタイムコードとの差分値を計算する。すなわち、タイムコード変更手段１９は、再生要求を示すコマンドを受信する直前に送信されたキーフレームのタイムコードと、キーフレームが最初に送信された際のタイムコードとの差分値を計算する。
【００４７】
例えば、図１６に示すフレーム構造を有するフレームレート２５fpsのＭＰＥＧデータで、７３フレーム目（フレーム番号７３）で一時停止の要求を受信し、３秒間の一時停止後、再生を開始する場合を考える。この場合、上述した一時停止処理のように、７５フレーム目（フレーム番号７５）のＩフレームを７５回（２５fps×３秒間）送信し、レジューム再生ステップＳ７１０へ移行する。その際、一時停止ステップＳ７０７でプレーヤ１へ送信したコンテンツデータの最後のタイムコードは５９６０であり、また、コンテンツ分岐手段１３から入力されたコンテンツデータの（最初の）タイムコードは３０００であるから、求められるタイムコードの差分値は２９６０となる。
【００４８】
タイムコード変更ステップＳ１５０３では、タイムコード変更手段１９が、コンテンツ分岐手段１３から入力されたコンテンツデータ中のタイムコードに、上述したタイムコード差分値を加算して変更する。すなわち、タイムコード変更手段１９は、計算された差分値を送信されたキーフレーム以降に送信される予定のフレームのタイムコードに加算してタイムコードを逐次変更する。図１６に示すように、タイムコード差分値計算ステップＳ１４０２で求められるタイムコード差分値は２９６０であるから、統合サーバ１０からプレーヤ１に送信されるコンテンツデータのタイムコードは、７６フレーム目（フレーム番号７６）のタイムコード３０４０にタイムコード差分値２９６０を加算した６０００となり、それ以降６０４０、６０８０、・・・と変更される。プレーヤ１から再生終了のコマンドを受信していなければタイムコード変更ステップＳ１４０３を繰り返す。一方、プレーヤ１から再生終了のコマンドを受信した場合にはレジューム再生ステップＳ７１０は終了する。
【００４９】
上述したレジューム再生ステップＳ７１０は、一時停止から再生をする場合（一時停止ステップＳ７０７からレジューム再生ステップＳ７１０の場合）についてのものである。以下では、早送りから再生をする場合（早送り／早戻しステップＳ７０８からレジューム再生ステップＳ７１０の場合）について図１７を用い、また、早戻しから再生する場合（早送り／早戻しステップＳ７０８からレジューム再生ステップＳ７１０の場合）について図１８を用いて説明する。まず、早送りから再生する場合について説明する。図１７に示すように、統合サーバ１０が、７３フレーム目で早送り要求（この例では、３倍速早送り再生要求）をプレーヤ１から受信し、図１３と同様の状況下において、７５フレーム目（フレーム番号７５）のＩフレーム５枚をプレーヤ１に送信し、その後は９０フレーム目（フレーム番号９０）のＩフレーム５枚をプレーヤ１に送信する。なお、このときも上述したようにタイムコードを変更する。
【００５０】
ここで、９０フレーム目（フレーム番号９０）のＩフレームの５枚目が送信されたときに、再生要求のコマンドをプレーヤ１から受信すると、９１フレーム目（フレーム番号９１）のＢフレームのタイムコードをプレーヤ１側で連続して再生されるようにタイムコードを３６４０から３４００に変更する。そして、それ以降のフレームについてもタイムコードを変更してプレーヤ１へ送信する。
【００５１】
次に、早戻しから再生する場合について説明する。図１８に示すように、統合サーバ１０が、９２フレーム目（フレーム番号９２）で早戻し要求（この例では、３倍速早戻し再生要求）をプレーヤ１から受信し、図１４と同様の状況下において、９０フレーム目（フレーム番号９０）のＩフレーム５枚をプレーヤ１に送信し、その後は７５フレーム目（フレーム番号７５）のＩフレーム５枚をプレーヤ１に送信する。なお、このときも上述したようにタイムコードを変更する。
【００５２】
ここで、７５フレーム目（フレーム番号７５）のＩフレームの５枚目が送信されたときに、再生要求のコマンドをプレーヤ１から受信すると、７６フレーム目（フレーム番号７６）のＢフレームのタイムコードをプレーヤ１側で連続して再生されるようにタイムコードを３０４０から３２８０に変更する。そして、それ以降のフレームについてもタイムコードを変更してプレーヤ１へ送信する。
【００５３】
以上の動作を実現する統合サーバを既存のネットワークメディアサーバ／プレーヤシステム（プレーヤ及びコンテンツを有するサーバからなるもの）に追加することで、プレーヤは統合サーバへアクセスし、コンテンツを受信した場合にサーバの実装によらず、同様のトリックプレイを実現することができる。また、サーバはバイトレンジによるシークのみ実装されていればよく、サーバの開発も容易になる。さらに、統合サーバは、コンテンツデータそのものは保持せず、コンテンツ情報のみを蓄積・管理するため、統合サーバに必要な記憶容量は既存のものに比べ小さくてよく、低コストでの実現が可能である。また、トリックプレイに関しては、再エンコードを行わずに実現しているため、処理コストも少なく、安価なハードウェアで実現することができる。
【産業上の利用可能性】
【００５４】
本発明に係るコンテンツ統合サーバは、コンテンツデータ、トリックプレイ用のデータを保持する必要がないため、低コストで実現することができるため、ネットワークを経由して映像・音声などを再生することが可能なコンテンツシステムにおけるコンテンツ統合サーバなどに有用である。
【図面の簡単な説明】
【００５５】
【図１】本発明の実施の形態に係るコンテンツ統合サーバを含むコンテンツシステムの構成の一例を示す構成図である。
【図２】本発明の実施の形態におけるディレクトリ情報の一例を示す図である。
【図３】本発明の実施の形態におけるコンテンツ情報蓄積手段に蓄積されるサーバごとのコンテンツ情報の一例を示す図である。
【図４】本発明の実施の形態におけるコンテンツ一覧の一例を示す図である。
【図５】本発明の実施の形態における作成されるコンテンツ情報の構成の一例を示す図である。
【図６】本発明の実施の形態におけるＩ、Ｂ、Ｐのフレーム構造で構成されるＭＰＥＧデータの一例を示す図である。
【図７】本発明の実施の形態に係るコンテンツ統合サーバの動作フローの一例について説明するためのフローチャートである。
【図８】本発明の実施の形態におけるコンテンツ情報収集ステップについて説明するためのフローチャートである。
【図９】本発明の実施の形態における再生ステップについて説明するためのフローチャートである。
【図１０】本発明の実施の形態における一時停止ステップについて説明するためのフローチャートである。
【図１１】本発明の実施の形態におけるトリックプレイ（一時停止）の場合の処理について説明するための図である。
【図１２】本発明の実施の形態における早送り／早戻しステップについて説明するためのフローチャートである。
【図１３】本発明の実施の形態におけるトリックプレイ（早送り）の場合の処理について説明するための図である。
【図１４】本発明の実施の形態におけるトリックプレイ（早戻し）の場合の処理について説明するための図である。
【図１５】本発明の実施の形態におけるレジューム再生ステップについて説明するためのフローチャートである。
【図１６】本発明の実施の形態におけるトリックプレイ（一時停止）から再生する場合の処理について説明するための図である。
【図１７】本発明の実施の形態におけるトリックプレイ（早送り）から再生する場合の処理について説明するための図である。
【図１８】本発明の実施の形態におけるトリックプレイ（早戻し）から再生する場合の処理について説明するための図である。
【符号の説明】
【００５６】
１  プレーヤ
１０  統合サーバ
１１  受信手段
１２  送信手段
１３  コンテンツ分岐手段
１４  コンテンツ情報取得手段
１５  コンテンツ情報蓄積手段（コンテンツ情報格納手段）
１６  制御手段（フレームレート取得手段）
１７  映像／音声分離手段
１８  キーフレーム取得手段
１９  タイムコード変更手段
１０１  コンテンツデータ
１０２  コマンドデータ
１０３  コンテンツ情報
１０４  ビデオデータ
１０５  フレームレート情報
１０６  キーフレームデータ
１０７  タイムコード情報
１０８  制御情報
１０９  ディレクトリ情報
１１０  コンテンツ一覧
１１１  加工済みコンテンツデータ
１１２  キーフレーム出力情報
【図１】
2008172629.tif 000003
【図２】
2008172629.tif 000004
【図３】
2008172629.tif 000005
【図４】
2008172629.tif 000006
【図５】
2008172629.tif 000007
【図６】
2008172629.tif 000008
【図７】
2008172629.tif 000009
【図８】
2008172629.tif 000010
【図９】
2008172629.tif 000011
【図１０】
2008172629.tif 000012
【図１１】
2008172629.tif 000013
【図１２】
2008172629.tif 000014
【図１３】
2008172629.tif 000015
【図１４】
2008172629.tif 000016
【図１５】
2008172629.tif 000017
【図１６】
2008172629.tif 000018
【図１７】
2008172629.tif 000019
【図１８】
2008172629.tif 000020