JP4333870B2

JP4333870B2 - 配信システム、配信サーバ装置、及び配信プログラム

Info

Publication number: JP4333870B2
Application number: JP2003064745A
Authority: JP
Inventors: 賢久染谷
Original assignee: Sony Ericsson Mobile Communications Japan Inc
Current assignee: Sony Corp
Priority date: 2002-12-27
Filing date: 2003-03-11
Publication date: 2009-09-16
Anticipated expiration: 2023-03-11
Also published as: JP2004254260A

Description

【０００１】
【発明の属する技術分野】
本発明は、ストリーミング形式のコンテンツをリアルタイムに配信する処理に適用して好適な、配信システム、配信サーバ装置、及び配信プログラムに関する。
【０００２】
【従来の技術】
近年、音声や映像等により構成されるストリーミング形式のコンテンツをユーザにリアルタイムに配信する配信システムが提供されるようになり、このような配信システムによれば、ユーザは、自身の端末装置を介して、ライブ映像等の所望のコンテンツをリアルタイムで楽しむことができる（例えば、特許文献１を参照）。
【０００３】
【特許文献１】
特開２００２−１７６６０９号公報
【０００４】
【発明が解決しようとする課題】
ところで、上記配信システムを利用してコンテンツを視聴する場合には、ユーザは、ＲＴＰ（Realtime Transport Protocol）−ＲＴＳＰ（Real Time Streaming Protocol）を使用した、複雑な制御を伴うプロトコルスタックが実装された端末装置を使用しなければならない。
【０００５】
しかしながら、上記プロトコルスタックを、携帯電話機やＰＤＡ（Personal Digital Assistant）等の携帯通信端末に実装し、さらには、携帯通信端末特有の不安定なネットワーク状態に対応できるようにするためには、非常に多くの開発工数が必要となる。また、世代によってネットワークの品質が変化した場合には、プロトコルスタックが既に実装されている携帯通信端末をネットワークの変化に対応するように再構成することは非常に難しい。さらに、上記プロトコルスタックは、端末装置とサーバ装置間でフロー制御やタイミング同期等の処理を実行する仕様となっているために、処理能力が限られている携帯通信端末に適用した場合には、携帯通信端末の処理負荷が非常に大きくなる。このような背景から、従来までの配信システムでは、ユーザは既存の携帯通信端末を利用することができなかった。
【０００６】
本発明は、上記課題を解決するためになされたものであり、その目的は、携帯通信端末に大きな負荷を掛けることなく、不安定なネットワーク状態であっても、既存の携帯通信端末を利用してストリーミングコンテンツを視聴することが可能な、配信システム、配信サーバ装置、及び配信プログラムを提供することにある。
【０００７】
【課題を解決するための手段】
本発明では、サーバ装置が、ストリーミング形式のコンテンツデータを一定時間長毎に区切ることで連続的に繋がった複数のデータファイルを生成する処理を、一定時間長より短い所定遅延時間ずつ累進的に遅延させつつ並行して実行し、その生成した各データファイルをコンテンツ記憶部へ記憶していく。そして、サーバ装置は、配信要求を受信した時、コンテンツ記憶部に記憶された複数のデータファイルの中から、当該配信要求の受信時刻前にコンテンツ記憶部に記憶された最新のデータファイルを選択し、その選択したデータファイルをコンテンツデータとして携帯通信端末に送信する。
【０００８】
すなわち、本発明においては、コンテンツデータを配信するサーバ装置が、ネットワークの品質や携帯通信端末の状態を判断し、コンテンツデータの配信処理に関わる全ての制御を実行する。そして、このような本発明の構成によれば、ユーザは、携帯通信端末に大きな負荷を掛けることなく、不安定なネットワーク状態であっても、既存の携帯通信端末でストリーミング形式のコンテンツを視聴することができる。
【０００９】
【発明の実施の形態】
本発明に係る配信システムは、図１に示すような、ライブカメラにより撮影された映像を携帯電話機に配信する配信システムに適用することができる。以下、図面を参照して、本発明の一実施形態となる配信システムの構成及び動作について詳しく説明する。
【００１０】
［配信システムの構成］
始めに、図１を参照して、本発明の一実施形態となる配信システムの構成について説明する。
【００１１】
本発明の一実施形態となる配信システムは、図１に示すように、ユーザからの視聴要求に応じて、ライブカメラ１により撮影された映像（以下、ライブ映像と表記する）を配信するサーバ装置２と、サーバ装置２から配信されたライブ映像を電気通信回線３を介して受信、表示する携帯電話機４とを備える。
【００１２】
なお、上記電気通信回線３には、インターネット通信回線、電話通信回線、ＷＡＮ（Wide Area Network）、ＬＡＮ（Local Area Network）、光ファイバ通信、ケーブル通信、衛星通信等の情報通信網が含まれる。また、サーバ装置２は、携帯電話機４から送信されたライブカメラ１の操作指示に従って、ライブカメラ１の動作を制御し、送信された操作指示内容に応じてライブ映像を携帯電話機４に配信してもよい。
【００１３】
〔コンテンツサーバ装置の構成〕
上記サーバ装置２は、汎用のパーソナルコンピュータやワークステーション等のコンピュータシステムにより構成され、図２に示すように、制御部１１、ＲＡＭ（Random Access Memory)１２、記憶部１３、通信制御部１４、データ変換部１５、及びコンテンツストレージ１６を備える。
【００１４】
上記制御部１１は、ＣＰＵ（Central Processing Unit）等の一般的なプロセッサ装置により構成され、記憶部１３内に記憶されたコンピュータプログラムや処理用データに従って各種処理を実行することにより、サーバ装置２の各種機能を実現する。また、上記ＲＡＭ１２は、半導体メモリ等の揮発性の記録媒体により構成され、制御部１１が実行するコンピュータプログラムや処理用データを一時的に格納するワークエリアを提供する。
【００１５】
上記記憶部１３は、磁気的、光学的記録媒体、半導体メモリ等の制御部１１が読み取り可能な不揮発性の記録媒体により構成され、サーバ装置２の起動プログラム等の基本プログラム（図示せず）、後述するサーバ装置２の動作を実現する配信プログラム１７等のアプリケーションプログラム、及びこれらプログラムの実行に必要な処理用データ（図示せず）を記憶する。
【００１６】
ここで、記憶部１３内に記憶される情報の一部若しくは全部は、電気通信回線３を介してインストールする構成にしてもよい。また、上記アプリケーションプログラムは、後述する処理を実行する際に、制御部１１が記録媒体から読み出すようにしてもよい。この場合、制御部１１は、処理を実行する際に、記録媒体から読み出したアプリケーションプログラムをＲＡＭ１２内に記録した後に、アプリケーションプログラムを実行する。なお、上記記録媒体には、例えば、半導体メモリ、磁気ディスク、光ディスク、光磁気ディスク、磁気テープ等の制御部１１が読み取り可能な全ての記録媒体が含まれる。
【００１７】
上記通信制御部１４は、例えば通信モデム装置により構成され、電気通信回線３の仕様に対応したプロトコルスタックを実装する。具体的には、この実施の形態では、通信制御部１４は、ＨＴＴＰ（Hyper Text Transfer Protocol）、ＴＣＰ／ＩＰ（Transmission Control Protocol / Internet Protocol）等の通信用プロトコルを実装し、この通信用プロトコルに従ってライブ映像を携帯電話機４に送信する。また、通信制御部１４は、この通信用プロトコルに従って、ライブ映像の視聴要求やライブカメラ１の操作指示等の各種情報を携帯電話機４から受信し、受信した情報を制御部１１が処理可能な形式に変換する。
【００１８】
上記データ変換部１５は、ライブカメラ１が撮影した音声や映像のデータをＭＰＥＧ（Moving Picture Experts Group）形式等の所定のデータ圧縮形式に変換してコンテンツストレージ１６内に蓄積する。この際、データ変換部１５は、図３に示すように、データを一定時間（ｍ秒）長（フラグメント長）の画像コンテンツ（以下、フラグメントコンテンツと表記する）毎に区切り、連続する複数のフラグメントコンテンツから成るファイル▲１▼を生成する。さらに、データ変換部１５は、ファイル▲１▼の生成と並行して、ファイル▲１▼よりｎ秒（ディレイタイム）ずつ累進的に遅延したフラグメントコンテンツから成るファイル▲２▼，ファイル▲３▼，ファイル▲４▼，及びファイル▲５▼を生成する。そして、詳しくは後述するが、制御部１１は、携帯電話機４からの視聴要求に応じて、ライブ映像をフラグメントコンテンツ単位で携帯電話機４に送信する。
【００１９】
〔携帯電話機の概観〕
上記携帯電話機４は、図１に示すように、主な構成要素として、表示部５、操作入力部６、受話口７、及び送話口８を備える。上記表示部５は、ＬＣＤ（Liquid Crystal Display）やＥＬ（ElectroLuminescence）パネル等の表示装置により構成され、後述するＣＰＵ２８（図４を参照）の制御に従って、文字や数字、記号、アイコン、カーソル、画像、動画像等を可視表示する。上記操作入力部６は、例えば「０」から「９」までの数字の入力、文字の入力、記号の入力、発信や受信の指示入力、電源のオン／オフの指示入力等の操作に使用する複数のキーボタン９を有する。また、この操作入力部６は、表示部５上に表示されたカーソルの移動操作や画面のスクロール操作等の操作に使用するダイアル（ジョグダイアル）１０を有する。この操作入力部６を操作することにより、ユーザは、ライブ映像の視聴処理等の様々な処理の実行を携帯電話機４に指示することができる。上記受話口７及び送話口８はそれぞれ、後述するスピーカ及びマイクロフォンに接続し、ユーザが通話相手先と音声通話を行う際に使用される。
【００２０】
〔携帯電話機の内部構成及びその基本動作〕
次に、図４を参照して、上記携帯電話機４の内部構成及びその基本動作について説明する。なお、図４に示す表示部５及び操作入力部６の構成及びその動作は図１に示すそれと同じであるので以下ではその説明を省略する。
【００２１】
図４に示す携帯電話機４において、送話口８に接続されているマイクロフォン２１は、ユーザの通話音声等をアナログ音声信号に変換する。そして、このアナログ音声信号は、図示しない増幅器により増幅された後、ＤＳＰ（Digital Siginal Processor）２２に入力される。
【００２２】
ＤＳＰ２２は、アナログ音声信号が入力されると、アナログ音声信号を所定のサンプリングレートでアナログ／デジタル（Ａ／Ｄ）変換する。そして、ＤＳＰ２２は、Ａ／Ｄ変換により得られたデジタル音声データに対し、トランスポートブロック（ＴＢ）毎にＣＲＣ（Cyclic Redundancy Check）符号を付加し、チャネル符号化（誤り訂正符合化）及びインターリーブ処理を施す。なお、上記トランスポートブロックとは、物理レイヤが処理を行うデータの基本単位（MAC(Medium Access Control)レイヤから物理レイヤにデータが転送される単位）を示す。
【００２３】
また、ＤＳＰ２２は、上記インターリーブ処理後のビット系列に対し、チャネル確定のためのパイロットビット等のオーバーヘッドを付加した後にデータ変調処理を行い、データ変調マッピングされた位相平面上の同相（In-Phase）及び直交（Quadrature）成分をそれぞれ２階層の拡散符号系列で拡散する。そして、ＤＳＰ２２は、拡散後のチップデータ系列を自乗余弦ルートナイキストフィルタで所定帯域（５ＭＨｚ）に帯域制限した後にデジタル／アナログ（Ｄ／Ａ）変換によりアナログ信号に変換し、アナログ信号を送信部２３に入力する。
【００２４】
送信部２３は、ＤＳＰ２２からアナログ信号が入力されると、アナログ信号を直交復調し、直交復調された中間周波数信号を高周波信号（２ＧＨｚ帯のＲＦ信号）に周波数変換する。そして、送信部２３は、この高周波信号を増幅し、増幅後の高周波信号を送信信号としてデュプレクサ２４に出力する。
【００２５】
デュプレクサ２４は、アンテナ共用器である。すなわち、デュプレクサ２４は、送信信号と受信信号とで１本のアンテナ２５を共用し、アンテナ２５からの受信信号を受信部２６に送り、且つ、送信部２３からの送信信号をアンテナ２５へ送出する機能を備えたフィルタ回路により構成される。
【００２６】
受信部２６は、アンテナ２５及びデュプレクサ２４を介して供給された高周波の受信信号を増幅し、増幅した受信信号を中間周波数の信号に周波数変換する。そして、受信部２６は、自動利得制御により中間周波数の信号を線形増幅し、線形増幅した中間周波数の信号をＤＳＰ２２に入力する。
【００２７】
このときＤＳＰ２２は、受信部２６からの信号を直交検波（Quardrature Detection）し、直交検波による同相及び直交成分のアナログ信号を所定のサンプリングレートでＡ／Ｄ変換する。そして、ＤＳＰ２２は、Ａ／Ｄ変換によりデジタル値に変換された同相及び直交成分を、自乗余弦ルートナイキストフィルタで帯域制限した後に受信信号の拡散符号と同一の拡散符号により逆拡散することにより、伝搬遅延時間が異なる複数のマルチパス成分に時間分離する。
【００２８】
また、ＤＳＰ２２は、時間分離した各パスのデータをコヒーレントレイク合成し、コヒーレントレイク合成後のデータ系列をデインターリーブ及びチャネル復号した後、２値のデータ判定を行って相手先の端末が送信してきたデータ系列を再生する。そして、ＤＳＰ２２は、再生したデータ系列を音声データとその他の通信データに弁別する。音声データは、ＤＳＰ２２によりＤ／Ａ変換され、さらに図示しない増幅器により増幅された後、受話口７に内蔵されているスピーカ２７へ送られる。スピーカ２７は、増幅されたアナログ音声信号により駆動される。これにより、通話相手先の端末からの通話音声がスピーカ２７から放音されることになる。
【００２９】
また、ＤＳＰ２２は、上記通信データがどのようなデータであるのかを解析し、その解析結果に応じた処理を行う。例えば上記通信データがテキストデータである場合、ＤＳＰ２２はテキストデータをＣＰＵ２８に送り、ＣＰＵ２８は表示部５上にテキストデータを表示制御する。また、例えば通信データが圧縮された画像データである場合、ＤＳＰ２２は圧縮画像データを伸張した後にＣＰＵ２８に送り、ＣＰＵ２８は表示部５上に画像データを表示制御する。また、例えば通信データが圧縮された音声データである場合、ＤＳＰ２２は、圧縮音声データを伸張し、スピーカ２７又はスピーカ２９に音声データを出力する。
【００３０】
記録部３０は、フラッシュメモリ等の記憶保持動作が不要な書き換え可能なメモリにより構成され、画像データ、音声データ等、様々なデータを記録する。ＲＯＭ（Read Only Memory）３１は、サーバ装置２から配信されたライブ映像を再生する際に使用する再生プログラム等の種々のコンピュータプログラム、及びコンピュータプログラムを実行する際に使用される処理用データを記録する。このＲＯＭ３１は、ＥＥＰＲＯＭ(Electrically Erasable and Programmable Read Only Memory)のような書き換え可能なＲＯＭであってもよい。また、上記コンピュータプログラムや処理用データはその一部若しくは全部をネットワークを介して受信するようにしてもよい。
【００３１】
ＲＡＭ（Random Access Memory)３２は、揮発性の記憶装置により構成される。このＲＡＭ３２は、ＣＰＵ２８が各種処理を行う際のワークエリアとして機能し、随時データを格納する。ＣＰＵ２８は、一般的なプロセッサ装置により構成される。このＣＰＵ２８は、記録部３０やＲＯＭ３１に格納されているコンピュータプログラムに従って各部の動作を制御すると共に、各種の演算処理を行う。
【００３２】
ここで、上記ＣＰＵ２８は、ＲＯＭ３１内等に実装されている図５に示すプロトコルスタックに従って携帯電話機４の動作を制御する。図５に示すプロトコルスタックは、一般的な携帯電話機用のプロトコルスタックであり、図中、ＨＴＴＰはアプリケーション層プロトコル、ＴＣＰ，ＩＰ，及びＷ−ＣＤＭＡはその他の通信用プロトコルを示す。
【００３３】
また、詳しくは後述するが、携帯電話機４は、アプリケーション層プロトコルであるＨＴＴＰに含まれるＧＥＴメソッドを利用して、サーバ装置２が配信するライブ映像の視聴要求を送信する。より具体的には、携帯電話機４は、例えばfunction get(){url - "http://www.aaa.co.jp/datafile";}のように、配信を要求するコンテンツのファイル名（datafile）をＧＥＴメソッド内に指定、送信することにより、ライブ映像の視聴要求をサーバ装置２に送信する。なお、携帯電話機４は、一連の配信処理内では同一のファイル名を用いてライブ映像の視聴要求をサーバ装置２に送信する。
【００３４】
［配信システムの動作］
次に、図６及び図１２に示すフローチャートを参照して、上記配信システムの動作をサーバ装置側と携帯電話機側の処理とに分けて説明する。
【００３５】
〔サーバ装置側の処理〕
始めに、図６に示すフローチャートを参照して、上記配信システムにおけるサーバ装置の動作について説明する。
【００３６】
図６に示すフローチャートは、ＨＴＴＰのＧＥＴメソッドを利用して携帯電話機４から送信されたライブ映像の視聴要求をサーバ装置２が受信することで開始となり、この配信処理はステップＳ１の処理に進む。なお、以下に示すサーバ装置２の動作は、制御部１１が、記憶部１３からＲＡＭ１２内にロードした配信プログラム１７を実行することで実現される。
【００３７】
ステップＳ１の処理では、サーバ装置２が、携帯電話機４から送信された視聴要求にセッションＩＤが付与されているか否かを判別することにより、携帯電話機４からの視聴要求が初回、若しくは、２回目以降のものであるのかを判別する。そして、セッションＩＤが付与され、携帯電話機４からの視聴要求が二回目以降のものであると判別された場合、サーバ装置２は配信処理をステップＳ１の処理からステップＳ５の処理に進める。一方、セッションＩＤが付与されてなく、携帯電話機４からの視聴要求が初回のものであると判別された場合には、サーバ装置２は配信処理をステップＳ１の処理からステップＳ２の処理に進める。
【００３８】
ステップＳ２の処理では、サーバ装置２が、視聴要求を送信した携帯電話機４固有のセッションＩＤを付与したストリーミングセッションを生成する。なお、この実施形態では、セッションＩＤは、携帯電話機４毎にランダムに生成した英数字から成るストリングを表す。これにより、このステップＳ２の処理は完了し、この配信処理はステップＳ２の処理からステップＳ３の処理に進む。
【００３９】
ステップＳ３の処理では、サーバ装置２が、コンテンツストレージ１６に記憶されている最新のフラグメントコンテンツ及びステップＳ２の処理において生成したストリーミングセッションのセッションＩＤを携帯電話機４に送信する。具体的には、図７に示すt=t1(sec)の時点で携帯電話機４から視聴要求信号を受信した場合、サーバ装置２は、図７に示すように、t=t1(sec)の時点で最新であるフラグメントコンテンツ＜６＞に対応する圧縮データファイルを選択し、圧縮データファイルの送信を開始する。なお、圧縮データファイルを送信する際、サーバ装置２は、圧縮データファイルのファイル名を携帯電話機４から送信されたＧＥＴコマンド内に記述されているファイル名に変更する。これにより、このステップＳ３の処理は完了し、この配信処理はステップＳ３の処理からステップＳ４の処理に進む。
【００４０】
ステップＳ４の処理では、サーバ装置２が、携帯電話機４に送信したフラグメントコンテンツ（又はフラグメントコンテンツの識別情報）をストリーミングセッションに記録する。なお、サーバ装置２は、次のフラグメントコンテンツの送信処理（ステップＳ５以後の処理）に対応できるように、フラグメントコンテンツが記録されたストリーミングセッションを所定時間保持する。これにより、このステップＳ４の処理は完了し、一連の配信処理は終了する。
【００４１】
ステップＳ５の処理では、サーバ装置２が、携帯電話機４から送信されたセッションＩＤに対応するストリーミングセッションを認識する。なお、前回の視聴要求時から所定時間経過し、ストリーミングセッションが保持されていない場合には、サーバ装置２は、「再ログインをお願いします」等のエラーメッセージを送信するエラー処理を実行する。これにより、このステップＳ５の処理は完了し、この配信処理はステップＳ５の処理からステップＳ６の処理に進む。
【００４２】
ステップＳ６の処理では、サーバ装置２が、セッションＩＤの受信タイミングと認識したストリーミングセッションとを参照して、前回送信したフラグメントコンテンツと同じファイル番号のフラグメントコンテンツを携帯電話機４が連続的に再生することができるか否かを判別する。そして、携帯電話機４が同じファイル番号のフラグメントコンテンツを連続的に再生することができないと判断した場合、サーバ装置２は配信処理をステップＳ６の処理からステップＳ９の処理に進める。一方、携帯電話機４が同じファイル番号のフラグメントコンテンツを連続的に再生することができると判断した場合には、サーバ装置２は配信処理をステップＳ６の処理からステップＳ７の処理に進める。
【００４３】
ステップＳ７の処理では、サーバ装置２は、前回送信したフラグメントコンテンツに連続的に繋がる、同じファイル番号のフラグメントコンテンツがコンテンツストレージ１６に蓄積されるまで待機する。ここで、このステップＳ７の処理の理解を容易にするために、図８に示すように、携帯電話機４に直前に送信したフラグメントコンテンツがフラグメントコンテンツ＜６＞であり、フラグメントコンテンツ＜６＞の送信が完了するのに応じて携帯電話機４から送信されるセッションＩＤをサーバ装置２がt=t2の時点で受信した（＝フラグメントコンテンツ＜６＞の送信が完了するまでに（t2-t1）時間要した）場合を考える。この場合、t=t2の時点では、直前に送信したフラグメントコンテンツ＜６＞と連続的に繋がる、同じファイル番号（ファイル▲１▼）のフラグメントコンテンツ＜１１＞がコンテンツストレージ１６に蓄積されていない。そこで、サーバ装置２は、フラグメントコンテンツ＜１１＞が蓄積されるまで待機する。このような処理によれば、ユーザは、前回送信されたフラグメントコンテンツの終了時刻が開始時刻となるフラグメントコンテンツを受信し、ライブ映像を連続的に楽しむことができる。これにより、このステップＳ７の処理は完了し、この配信処理はステップＳ７の処理からステップＳ８の処理に進む。
【００４４】
ステップＳ８の処理では、サーバ装置２が、フラグメントコンテンツが蓄積されるのに応じて、蓄積されたフラグメントコンテンツを携帯電話機４に送信する。なお、既に述べたように、一連の配信処理内で携帯電話機４は同一のファイル名をＧＥＴメソッド内に記述するので、ステップＳ８の処理において、サーバ装置２は、携帯電話機４に送信する圧縮データファイルのファイル名を携帯電話機４から送信されたＧＥＴメソッド内に記述されているファイル名に変更した後、圧縮データファイルを携帯電話機４に送信する。これにより、このステップＳ８の処理は完了し、この配信処理はステップＳ８の処理からステップＳ４の処理に戻る。
【００４５】
ステップＳ９の処理では、サーバ装置２が、携帯電話機４に次に送信するフラグメントコンテンツをスキップ操作により選択する。ここで、このステップＳ９の処理の理解を容易にするために、図９に示すように、携帯電話機４に直前に送信したフラグメントコンテンツがフラグメントコンテンツ＜６＞であり、セッションＩＤをt=t3の時点で受信した（＝フラグメントコンテンツ＜６＞の送信が完了するまでに（t3-t1）時間要した）場合を考える。この場合には、本来、サーバ装置２は、フラグメントコンテンツ＜６＞に連続的に繋がるフラグメントコンテンツ＜１１＞を次に送信するべきであるが、t=t3の時点ではフラグメントコンテンツ＜１１＞よりも新しいフラグメントコンテンツがコンテンツストレージ１６内に既に蓄積されているので、サーバ装置２は、フラグメントコンテンツ＜１１＞ではなく（スキップ操作）、セッションＩＤを受信した時点t=t3で最新のフラグメントコンテンツ＜１３＞を携帯電話機４に次に送信するフラグメントコンテンツとして選択する。なお、このような処理によれば、ライブ映像の一部（図９に示すt=t4からt=t5間のデータ）がスキップされて携帯電話機４に送信されることになるが、この一連の処理は全てサーバ装置２側で制御されるので、ユーザは、携帯電話機４に大きな負荷を掛けることなく、最新のライブ映像を楽しむことができる。なお、リアルタイム性が要求されないのであれば、ステップＳ９の処理において、サーバ装置２は、直前に送信したフラグメントコンテンツ＜６＞と連続的に繋がるフラグメントコンテンツ＜１１＞を送信してもよい。これにより、このステップＳ９の処理は完了し、この配信処理はステップＳ９の処理からステップＳ１０の処理に進む。
【００４６】
ステップＳ１０の処理では、サーバ装置２が、スキップ操作により選択したフラグメントコンテンツを携帯電話機４に送信する。これにより、このステップＳ１０の処理は完了し、この配信処理はステップＳ１０の処理からステップＳ４の処理に戻る。
【００４７】
なお、上記ステップＳ９の処理において、サーバ装置２は、セッションＩＤの時間間隔を算出し、算出した時間間隔に従って携帯電話機４に送信するフラグメントコンテンツのビットレートを変更してもよい。具体的には、図１０に示すように、前回及び次回のセッションＩＤをそれぞれ時刻t=t1及びt5の時に受信した場合、サーバ装置２は、時刻t=t1及びt3の時間間隔(t3-t1)を算出する。そして、サーバ装置２は、算出した時間間隔(t3-t1)が所定の値よりも大きい場合には携帯電話機４に送信するフラグメントコンテンツのビットレートを下げる等して、携帯電話機４に送信するフラグメントコンテンツのビットレートを算出した時間間隔(t3-t1)に従って変更する。このような処理によれば、ユーザは、携帯電話機４に大きな負荷を掛けることなく、不安定なネットワーク状態であってもライブ映像を視聴することができる。なお、ビットレートを変更した場合、携帯電話機４がビットレートの変更を認識することができるように、サーバ装置２は、携帯電話機４に送信するファイルのヘッダ等にビットレートの変更後の値を記述する。
【００４８】
また、上記配信処理では、サーバ装置２は、セッションＩＤの受信タイミングと認識したストリーミングセッションとを参照して携帯電話機４が同じファイル番号のフラグメントコンテンツを連続的に再生することができるか否かを判別したが、通信遅延時間や携帯電話機４のバッファ容量を考慮して前回送信したフラグメントコンテンツの再生終了予想時刻と次に送信したフラグメントコンテンツの受信開始予想時刻とを算出し、算出した時刻に基づいて判別してもよい。なお、この場合、通信遅延時間は設計仕様に従ってサーバ装置２の管理者が適宜指定する。具体的には、図１１に示すように、ファイル▲１▼のフラグメントコンテンツ＜１＞を携帯電話機４にt=t1の時点で送信した場合、サーバ装置２は、始めに、通信遅延時間tdとフラグメント長（ｍ秒）を考慮してフラグメントコンテンツ＜１＞の再生終了予想時刻t5（=t1+t2+m）を算出すると共に、携帯電話機４からt=t3の時点で視聴要求を受信するのに応じて、通信遅延時間tdを考慮して次に送信するフラグメントコンテンツの受信開始予想時刻t4（=t3+td）を算出する。そして、この例の場合、図に示すように、次に送信するフラグメントコンテンツの受信開始予想時刻t4がフラグメントコンテンツ＜１＞の再生終了予想時刻よりも前の時刻になるので、サーバ装置２は、携帯電話機４が同じファイル番号のフラグメントコンテンツを連続的に再生することができると判断し、前回送信したフラグメントコンテンツ＜１＞に連続する、ファイル▲１▼のフラグメントコンテンツ＜６＞の送信を開始する。上記のようにしてフラグメントコンテンツ＜６＞の送信が開始すると、次に、サーバ装置２は、フラグメントコンテンツ＜１＞の再生終了予想時刻t5にフラグメント長（ｍ秒）を加算することにより、現在送信しているフラグメントコンテンツ＜６＞の再生終了予想時刻t6を算出すると共に、携帯電話機４からt=t7の時点で視聴要求を受信するのに応じて、通信遅延時間tdを考慮して次に送信するフラグメントコンテンツの受信開始予想時刻t8（=t7+td）を算出する。そして、この例の場合には、図から明らかなように、フラグメントコンテンツの受信開始予想時刻t8はフラグメントコンテンツ＜６＞の再生終了予想時刻よりも後の時刻となるので、サーバ装置２は、携帯電話機４が同じファイル番号のフラグメントコンテンツを連続的に再生することができないと判断し、t=t7の時点で最新の他のファイルのフラグメントコンテンツの送信を開始する。
【００４９】
〔携帯電話機側の処理〕
次に、図１２に示すフローチャートを参照して、上記配信システムにおける携帯電話機４の動作について説明する。
【００５０】
図１２に示すフローチャートは、ユーザが操作入力部６を操作してライブ映像の視聴要求を携帯電話機４に入力することで開始となり、この視聴処理はステップＳ２１の処理に進む。なお、以下に示す携帯電話機４の動作は、ＣＰＵ２８が、ＲＯＭ３１からＲＡＭ３２内にロードした再生プログラムを実行することで実現される。
【００５１】
ステップＳ２１の処理では、携帯電話機４が、配信を要求するコンテンツのファイル名をＧＥＴメソッド内で指定、送信することにより、ライブ映像の視聴要求をサーバ装置２に送信する。なお、携帯電話機４は、一連の配信処理内では同一のファイル名を用いてライブ映像の視聴要求をサーバ装置２に送信する。これにより、このステップＳ２１の処理は完了し、この視聴処理はステップＳ２１の処理からステップＳ２２の処理に進む。
【００５２】
ステップＳ２２の処理では、携帯電話機４が、サーバ装置２から送信されたフラグメントコンテンツ及びセッションＩＤを受信する。これにより、このステップＳ２２の処理は完了し、この視聴処理はステップＳ２２の処理からステップＳ２３の処理に進む。
【００５３】
ステップＳ２３の処理では、携帯電話機４が、受信したフラグメントコンテンツをデコードし、表示部５やスピーカ２７，２９にライブ映像の画像や音声を出力する。より具体的には、携帯電話機４は、サーバ装置２からフラグメントコンテンツを受信するのに応じて、フラグメントコンテンツからヘッダを取り除き、フラグメントコンテンツの再生に必要な情報だけを抽出する。そして、携帯電話機４は、前回受信したフラグメントコンテンツのデータに抽出したデータを繋ぎ合わせて、フラグメントコンテンツを再生する。なお、受信したフラグメントコンテンツのヘッダ内にビットレートが変更されたことを示す情報が記述されている場合には、携帯電話機４は、変更後のビットレートに対応するようにデコーダを切り換えてフラグメントコンテンツを再生する。これにより、このステップＳ２３の処理は完了し、この視聴処理はステップＳ２３の処理からステップＳ２４の処理に進む。
【００５４】
ステップＳ２４の処理では、携帯電話機４が、ＨＴＴＰのＧＥＴメソッドを使用して、受信したセッションＩＤと共に次のフラグメントコンテンツの視聴要求をサーバ装置２に送信する。これにより、このステップＳ２４の処理は完了し、この視聴処理はステップＳ２４の処理からステップＳ２５の処理に進む。
【００５５】
ステップＳ２５の処理では、携帯電話機４が、サーバ装置２から送信された次のフラグメントコンテンツ及びセッションＩＤを受信する。これにより、このステップＳ２５の処理は完了し、この視聴処理はステップＳ２５の処理からステップＳ２６の処理に進む。
【００５６】
ステップＳ２６の処理では、携帯電話機４が、次のフラグメントコンテンツ及びセッションＩＤの受信が完了するまで待機し、受信が完了するのに応じて、視聴処理をステップＳ２６の処理をステップＳ２４の処理に戻し、次のフラグメントコンテンツの視聴要求をサーバ装置２に送信する。以後、携帯電話機４は、ユーザが操作入力部６を操作して視聴中止要求を入力するまで、上記ステップＳ２３〜ステップＳ２６の処理を繰り返し実行する。
【００５７】
［実施の形態の効果］
以上の説明から明らかなように、本発明の一実施形態となる配信システムでは、サーバ装置２が、ライブ映像データからｎ秒おきに抽出した、ｍ秒長のフラグメントコンテンツをコンテンツストレージ１６内に複数記憶し、携帯電話機４から送信されたセッションＩＤの受信時間に従って、携帯電話機４に送信する最適なフラグメントコンテンツを選択し、選択したフラグメントコンテンツをライブ映像データとして携帯電話機４に送信する。そして、このような構成によれば、サーバ装置２が、ネットワークの品質や携帯電話機４の状態を判断し、ライブ映像の配信処理に関わる全ての制御を実行することになるので、ユーザは、携帯電話機４に大きな負荷を掛けることなく、不安定なネットワーク状態であっても、既存の携帯電話機４でライブ映像を視聴ことができる。
【００５８】
また、本発明の一実施形態となる配信システムによれば、携帯電話機４は、アプリケーション層プロトコルの一つであるＨＴＴＰを利用してサーバ装置２が配信するライブ映像を受信するので、携帯電話機４内にＲＴＰ−ＲＴＳＰを実装する必要がなくなり、ユーザは既存の携帯電話機４でライブ映像を楽しむことができる。
【００５９】
［その他の実施形態］
以上、本発明者らによってなされた発明を適用した実施の形態について説明したが、この実施の形態による本発明の開示の一部をなす論述及び図面により本発明は限定されることはない。例えば、上記実施の形態では、サーバ装置２は、ライブカメラ１で撮影した映像をユーザに配信したが、本発明はこれに限られることはなく、サーバ装置２が配信するコンテンツは、ストリーミング形式のものであれば、どのような内容であっても構わない。すなわち、この実施の形態に基づいて当業者等によりなされる他の実施の形態、実施例及び運用技術等は全て本発明の範疇に含まれることは勿論であることを付け加えておく。
【００６０】
【発明の効果】
本発明によれば、携帯通信端末に大きな負荷を掛けることなく、不安定なネットワーク状態であっても、既存の携帯通信端末を利用してストリーミングコンテンツを視聴することができる。
【図面の簡単な説明】
【図１】本発明の実施の形態となる配信システムの構成を示す模式図である。
【図２】図１に示すサーバ装置の内部構成を示す模式図である。
【図３】図２に示すコンテンツストレージ内に蓄積されるライブ映像のデータ形式を説明するための図である。
【図４】図１に示す携帯電話機の内部構成を示す模式図である。
【図５】図１に示す携帯電話機に実装されているプロトコルスタックを示す模式図である。
【図６】図１に示すサーバ装置の動作を示すフローチャート図である。
【図７】初回のフラグメントコンテンツ配信動作を説明するための図である。
【図８】携帯電話機がライブ映像を連続的に再生することができると判断した場合のフラグメントコンテンツ配信動作を説明するための図である。
【図９】携帯電話機がライブ映像を連続的に再生することができないと判断した場合のフラグメントコンテンツ配信動作を説明するための図である。
【図１０】携帯電話機がライブ映像を連続的に再生することができないと判断した場合のフラグメントコンテンツ配信動作の応用例を説明するための図である。
【図１１】携帯電話機がライブ映像を連続的に再生することができるか否かをサーバ装置が判断する処理の応用例を説明するための図である。
【図１２】図１に示す携帯電話機の動作を示すフローチャート図である。
【符号の説明】
１…ライブカメラ、２…サーバ装置、３…電気通信回線、４…携帯電話機、５…表示部、６…操作入力部、１１…制御部、１２，３２…ＲＡＭ（Random Access Memory）、１３…記憶部、１４…通信制御部、１５…データ変換部、１６…コンテンツストレージ、１７…配信プログラム、２２…ＤＳＰ（Digital Signal Processor）、２８…ＣＰＵ（Central Processing Unit）、３１…ＲＯＭ（Read Only Memory）

Claims

ストリーミング形式のコンテンツデータの配信要求をサーバ装置へ送信し、そのサーバ装置から受信したコンテンツデータを再生する携帯通信端末と、
受信した配信要求に対応したコンテンツデータを上記携帯通信端末へ送信するサーバ装置とを備え、
上記サーバ装置は、
上記コンテンツデータを一定時間長毎に区切ることで連続的に繋がった複数のデータファイルを生成する処理を、上記一定時間長より短い所定遅延時間ずつ累進的に遅延させつつ並行して実行するデータファイル生成部と、
上記データファイル生成部が生成した各データファイルを記憶していくコンテンツ記憶部と、
上記配信要求を受信した時、上記コンテンツ記憶部に記憶された複数のデータファイルの中から、当該配信要求の受信時刻前にコンテンツ記憶部に記憶された最新のデータファイルを選択し、当該選択したデータファイルを上記コンテンツデータとして携帯通信端末に送信する制御部と
を有し、
上記携帯通信端末は、上記データファイル単位で上記コンテンツデータの配信要求を送信する
ことを特徴とする配信システム。
上記サーバ装置は、上記配信要求を受信した時、直前に送信したデータファイルの送信開始時刻から当該配信要求の受信時刻までに要した時間と、データファイルの上記一定時間長とから、上記携帯通信端末が上記連続的に繋がったデータファイルを再生できるか判断し、上記連続的に繋がったデータファイルを再生できないと判断した場合には、当該配信要求の受信時刻前にコンテンツ記憶部に記憶された最新のデータファイルを、次に送信するデータファイルとして選択することを特徴とする請求項１記載の配信システム。
上記サーバ装置は、携帯通信端末から送信されてきた配信要求の時間間隔に応じて、次に送信するデータファイルのビットレートを変更することを特徴とする請求項１記載の配信システム。
上記サーバ装置は、前回送信したデータファイルと連続的に繋がったデータファイルを次に送信するデータファイルとして選択することを特徴とする請求項１記載の配信システム。
上記携帯通信端末はアプリケーション層プロトコルを使用して上記配信要求を送信することを特徴とする請求項１記載の配信システム。
携帯通信端末との間で通信を行うための通信部と、
ストリーミング形式のコンテンツデータを一定時間長毎に区切ることで連続的に繋がった複数のデータファイルを生成する処理を、上記一定時間長より短い所定遅延時間ずつ累進的に遅延させつつ並行して実行するデータファイル生成部と、
上記データファイル生成部が生成した各データファイルを記憶していくコンテンツ記憶部と、
携帯通信端末から送信されてきたコンテンツデータ配信要求を上記通信部にて受信した時、上記コンテンツ記憶部に記憶された複数のデータファイルの中から、上記配信要求の受信時刻前に上記コンテンツ記憶部に記憶された最新のデータファイルを選択し、当該選択したデータファイルを上記コンテンツデータとして上記通信部から上記携帯通信端末へ送信させる制御部と
を有する配信サーバ装置。
上記制御部は、上記配信要求を受信した時、直前に送信されたデータファイルの送信開始時刻から当該配信要求の受信時刻までに要した時間と、データファイルの上記一定時間長とから、上記携帯通信端末が上記連続的に繋がったデータファイルを再生できるか判断し、上記連続的に繋がったデータファイルを再生できないと判断した場合には、上記配信要求の受信時刻前に上記コンテンツ記憶部に記憶された最新のデータファイルを、次に送信するデータファイルとして選択する請求項６記載の配信サーバ装置。
上記データファイル生成部は、携帯通信端末から送信されてきた配信要求の時間間隔に応じて、次に送信するデータファイルのビットレートを変更する請求項６記載の配信サーバ装置。
上記制御部は、前回送信したデータファイルと連続的に繋がったデータファイルを次に送信するデータファイルとして選択する請求項６記載の配信サーバ装置。
ストリーミング形式のコンテンツデータを一定時間長毎に区切ることで連続的に繋がった複数のデータファイルを生成する処理を、上記一定時間長より短い所定遅延時間ずつ累進的に遅延させつつ並行して実行するデータファイル生成部と、
上記データファイル生成部が生成した各データファイルをコンテンツ記憶部へ記憶させていくコンテンツ記憶制御部と、
携帯通信端末から送信されてきたコンテンツデータ配信要求が通信部で受信された時、上記コンテンツ記憶部に記憶された複数のデータファイルの中から、上記配信要求の受信時刻前に当該コンテンツ記憶部に記憶された最新のデータファイルを選択し、当該選択したデータファイルを上記コンテンツデータとして通信部から上記携帯通信端末へ送信させる制御部として、
コンピュータを動作させることを特徴とする配信プログラム。