(57)【要約】【課題】  カメラで撮影されたリアルタイム動画データを、その即時性を著しく損なわせることなく、フレーム落ちのない状態で視聴者に提供する。【解決手段】  動画配信システムを、リアルタイム動画データを録画して所定時間Ｔごとに分割された動画データＤ１〜ＤＮ（Ｎは、２以上の整数）を順次生成する映像サーバと、映像サーバから動画データＤ１〜ＤＮを順次受信してクライアントへ公開する公開サーバとを備えたものとした。クライアントから公開サーバへ動画データの視聴要求があった際には、その時点で公開サーバが受信を完了している最新の動画データＤｎ（ｎは、１以上でＮ以下の整数）以降の動画データ動画データＤｎ〜Ｄｎ＋δＮ（δＮは、０以上でＮ−ｎ以下の整数）を順次受信して順次再生するように指定を行うプレイリストが公開サーバからクライアントへと送信される。【選択図】  図１
2007074684.tif 000002
【特許請求の範囲】
【請求項１】
リアルタイム動画データを録画して所定時間Ｔごとに分割された動画データＤ１〜ＤＮ（Ｎは、２以上の整数）を順次生成する映像サーバと、映像サーバから動画データＤ１〜ＤＮを順次受信してクライアントへ公開する公開サーバとを備え、クライアントから公開サーバへ動画データの視聴要求があった際に、その時点で公開サーバが受信を完了している最新の動画データＤｎ（ｎは、１以上でＮ以下の整数）以降の動画データＤｎ〜Ｄｎ＋δＮ（δＮは、０以上でＮ−ｎ以下の整数）を順次受信して順次再生するように指定を行うプレイリストが公開サーバからクライアントへ送信されることを特徴とする動画配信システム。
【請求項２】
所定時間Ｔが１０秒〜３０分に設定された請求項１記載の動画配信システム。
【請求項３】
δＮの値をクライアントから指定できる請求項1又は２記載の動画配信システム。
【請求項４】
映像サーバと公開サーバとの通信が、パケット再送方式によって行われる請求項１〜３いずれか記載の動画配信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、インターネットなどのネットワークを介して動画データをダウンロードする際に用いられる動画配信システムに関する。
【背景技術】
【０００２】
従来より、ある地点で撮影されたライブ映像をインターネットを介して遠隔地のクライアントにライブ配信することが行われている（例えば、特許文献１を参照。）。しかし、従来のライブ配信は、クライアントで再生される映像の即時性を重視していたために、撮影されたライブ映像は、フレーム（コマ）単位で送信されていた。また、何らかの通信障害によって伝送路上でフレームが消失した場合であっても、そのまま次のフレームを送信していた。このため、クライアントで再生される映像には、フレーム落ち（コマ落ち）が生じてしまい、視聴者がストレスを感じることも多かった。即時性が多少損なわれてもフレーム落ちのない映像を視聴したいという要望はあったが、このような要望に応えることのできる動画配信システムは、未だ提案されていなかった。
【０００３】
【特許文献１】特開２００３−２０９８２８号公報（特許請求の範囲、図１）
【発明の開示】
【発明が解決しようとする課題】
【０００４】
本発明は、上記課題を解決するためになされたものであり、リアルタイム動画データ（ライブ映像）を、その即時性を著しく損なわせることなく、フレーム落ちのない状態で視聴者に提供することを目的とする。
【課題を解決するための手段】
【０００５】
上記課題は、リアルタイム動画データを録画して所定時間Ｔごとに分割された動画データＤ１〜ＤＮ（Ｎは、２以上の整数）を順次生成する映像サーバと、映像サーバから動画データＤ１〜ＤＮを順次受信してクライアントへ公開する公開サーバとを備え、クライアントから公開サーバへ動画データの視聴要求があった際に、その時点で公開サーバが受信を完了している最新の動画データＤｎ（ｎは、１以上でＮ以下の整数）以降の動画データＤｎ〜Ｄｎ＋δＮ（δＮは、０以上でＮ−ｎ以下の整数）を順次受信して順次再生するように指定を行うプレイリストが公開サーバからクライアントへ送信されることを特徴とする動画配信システムを提供することによって解決される。
【０００６】
これにより、リアルタイム動画データは、フレーム単位ではなく、連続する複数のフレームがまとめられた動画データ（動画ファイル）単位で公開サーバに送信されるようになる。したがって、映像サーバと公開サーバとの通信に、ＦＴＰ（Ｆｉｌｅ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）やＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）など、高機能な通信プロトコルを使用することが可能になり、リアルタイム動画データをフレーム落ちなく確実に公開サーバへと送信することが可能になる。また、視聴者は、リアルタイム動画データが撮影されてから数十秒〜数分遅れで視聴することも可能である。
【０００７】
録画時間Ｔは、特に限定されないが、短く設定しすぎると、映像サーバと公開サーバとを結ぶ通信回線に障害が生じて動画データＤ１〜ＤＮの送信に遅れが生じた場合などに、その遅れを回復することが困難になるおそれがある。このため、録画時間Ｔは、通常、１０秒以上に設定される。録画時間Ｔは、３０秒以上であると好ましく、１分以上であるとより好ましく、３分以上であるとさらに好ましい。一方、録画時間Ｔは、長く設定しすぎると、クライアントが再生する動画データの即時性が著しく失われるおそれがあるために、通常、３０分以下に設定される。録画時間Ｔは、２０分以下であると好ましく、１５分以下であるとより好ましく、１０分以下であるとさらに好ましい。
【０００８】
δＮの値は、クライアントから指定できるようになっていると好ましい。これにより、クライアントで動画データを視聴するユーザは、再生する動画データの数を希望に応じて指定することが可能になり、動画データを視聴する時間の長さを変更することができるようになる。例えば、δＮを０に設定すると、動画データＤｎだけを視聴することができるし、δＮをＮ−ｎに設定すると、動画データＤｎから最後の動画データＤＮまで視聴することができる。
【０００９】
映像サーバと公開サーバとの通信が、パケット再送方式によって行われることも好ましい。ここで、パケット再送方式とは、伝送路上で損失したパケットを受信側（公開サーバ）で検知して、送信側（映像サーバ）に損失したパケットの再送を要求する方式のことをいう。これにより、動画データをパケット損失なく送信することが可能になり、映像サーバが生成した動画データＤ１〜ＤＮと、公開サーバに格納された動画データＤ１〜ＤＮとの同一性を担保することが可能になる。
【発明の効果】
【００１０】
以上のように、本発明によって、カメラで撮影されたリアルタイム動画データを、その即時性を著しく損なわせることなく、フレーム落ちのない状態で視聴者に提供することが可能になる。
【発明を実施するための最良の形態】
【００１１】
本発明の動画配信システムをより具体的に説明する。図１は、本発明の動画配信システムの好適な実施態様を示したシステム構成図である。本実施態様の動画配信システムは、図１に示すように、映像サーバと公開サーバとを備えたものとなっている。図１においては、クライアントを１台しか記載していないが、実際には多数のクライアントが存在している。また、公開サーバも１台しか記載していないが、公開サーバにかかる負担が大きく、分散処理を行う必要がある場合などには、公開サーバを複数台設けてもよい。
【００１２】
［映像サーバ］
１．概要
まず、映像サーバについて説明する。本実施態様の映像サーバは、図１に示すように、カメラから送られてくるリアルタイム動画データを録画して、所定時間ごとに分割された動画データＤ１〜ＤＮを順次生成し、生成した動画データＤ１〜ＤＮを公開サーバへと順次送信するものとなっている。ここで、Ｎは、２以上の整数であり、リアルタイム動画データの分割数を示している。
【００１３】
２．分割処理
図２は、所定時間ごとに分割された動画データＤ１〜ＤＮを順次生成していく処理（以下において、単に‘分割処理’と呼ぶことがある。）を示したフローチャートである。この分割処理は、映像サーバで行われ、映像サーバがカメラからリアルタイム動画データを受信し始めると開始される。
【００１４】
分割処理についてさらに詳しく説明する。映像サーバは、図２に示すように、分割処理を開始すると（処理１０１）、動画データＤｉの録画を開始する（処理１０３）。ここで、ｉは、１以上でＮ以下の整数であり、その初期値は１に設定されている（処理１０２）。動画データＤｉの録画は、動画データＤｉの録画開始から所定時間Ｔが経過するまで続けられる（処理１０４）。本実施態様の映像サーバにおいて、所定時間Ｔ（録画時間Ｔ）は５分に設定されている。
【００１５】
動画データＤｉの録画が終了すると（処理１０５）、映像サーバは、録画した動画データＤｉをａｖｉ（Ａｕｄｉｏ  Ｖｉｄｅｏ  Ｉｎｔｅｒｌｅａｖｉｎｇ）やｍｐｅｇ（Ｍｏｖｉｎｇ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ）など、所望の動画ファイル形式にエンコードする。エンコードされた動画データＤｉは、完結したファイルとして映像サーバに格納される（処理１０６）。
【００１６】
続いて、映像サーバは、動画データＤ１〜ＤＮの全てを録画したかどうかを確認する（処理１０７）。まだ録画していない動画データが残っている場合には、ｉに１を加えて（処理１０８）、次の動画データＤｉの録画を開始する（処理１０３）。一方、動画データＤ１〜ＤＮの全てを録画し終えている場合には、分割処理を終了する（処理１０９）。映像サーバは、分割処理が終了するまでに、Ｎ個の動画データＤ１〜ＤＮを完結したファイルとして生成する。
【００１７】
処理１０６において、動画データＤｉをエンコードする際には、動画データＤｉを複数種のサンプリング周波数でエンコードしてもよい。これにより、ファイルサイズの異なる複数種の動画データＤｉを公開サーバで公開することが可能になり、各クライアントが接続している通信回線の通信速度にバラツキが存在する場合であっても、各クライアントは自らの通信速度に応じたファイルサイズの動画データＤｉを選択して視聴することが可能になる。
【００１８】
また、処理１０６において、動画データＤｉを映像サーバに格納する際には、動画データＤｉに自動的にファイル名がつけられるようにしておくとよい。ファイル名のつけ方は、特に限定されないが、本実施態様の映像サーバは、動画データＤｉの内容と、動画データＤｉの撮影年月日と、動画データＤｉの番号（ｉの値）とを反映させたファイル名をつけるように設定されている。例えば、西暦２００５年９月９日に撮影されたサッカーの試合の動画データＤ１には、‘ｓｏｃｃｅｒ２００５０９０９０００１’といったファイル名がつけられる。
【００１９】
３．アップロード処理
図３は、公開サーバへ動画データＤ１〜ＤＮを順次送信していく処理（以下において、単に‘アップロード処理’と呼ぶことがある。）を示したフローチャートである。このアップロード処理は、映像サーバで行われ、映像サーバに動画データＤｉが新たに格納されるたびに開始される。
【００２０】
アップロード処理についてさらに詳しく説明する。映像サーバは、図３に示すように、アップロード処理を開始すると（処理２０１）、公開サーバに通信接続を開始する（処理２０３）。公開サーバへの通信接続は、成功するまで続けられる（処理２０４）。映像サーバと公開サーバとの通信に用いるプロトコルとしては、ＦＴＰ（Ｆｉｌｅ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）やＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）などが例示される。
【００２１】
公開サーバとの通信接続に成功すると、映像サーバは、動画データＤｉをＭ個（Ｍは、２以上の整数）のパケットＰ１〜ＰＭに分割し、公開サーバに対して動画データＤｉのパケットＰｊの送信を開始する（処理２０５）。ここで、ｊは、１以上でＭ以下の整数であり、その初期値は１に設定されている（処理２０２）。パケットＰｊには、送信先（公開サーバ）のアドレスや誤り訂正符号など、各種の制御情報が付加される。
【００２２】
続いて、映像サーバは、パケットＰｊの送信が正常に終了したかどうかを確認する（処理２０６）。パケットＰｊの送信が正常に終了しなかった場合には、公開サーバにパケットＰｊを再送信する（処理２０５）。この通信方式は、パケット再送方式と呼ばれており、動画データＤｉをパケット損失なく送信することを可能にする。また、動画データＤｉを送信している途中に映像サーバと公開サーバとの通信接続が切断した場合には、動画データＤｉの送信を途中から再開することができるために、動画データＤｉの送信時間を短縮することも可能になる。このような機能は、レジューム機能と呼ばれている。
【００２３】
このとき、パケットＰｉの再送信は、パケットＰｊの送信が正常に終了しなかった時点から所定時間が経つと自動的に行われるように設定してもよいが、映像サーバと公開サーバとの接続が再度確認されてから行うように設定すると好ましい。これにより、パケットＰｊを無駄に送信するのを防ぐだけでなく、パケットＰｊの再送信までの待機時間を短縮することも可能になる。
【００２４】
一方、処理２０６でパケットＰｊの送信が正常に終了したことが確認できた場合には、動画データＤｉのパケットＰ１〜ＰＭの全てを送信したかどうかを確認する（処理２０７）。まだ送信していないパケットが残っている場合には、ｊに１を加えて（処理２０８）、次のパケットＰｊを送信する（処理２０５）。一方、動画データＤｉのパケットＰ１〜ＰＭの全てを送信したことが確認できた場合には、動画データＤｉのアップロード処理を終了する（処理２０９）。
【００２５】
［公開サーバ］
１．概要
次に、公開サーバについて説明する。本実施態様の公開サーバは、図１に示すように、映像サーバから動画データＤ１〜ＤＮを順次受信し、クライアントから動画データの視聴要求があるたびにプレイリストを生成してクライアントに送信するものとなっている。公開サーバとクライアントとの通信は、通常、ＦＴＰやＨＴＴＰなどによって行われる。
【００２６】
２．プレイリスト
図４は、公開サーバで生成されるプレイリストの一例を示した図である。このプレイリストは、クライアントから視聴要求があった時点で公開サーバが受信を完了していた最新の動画データＤｎ以降の動画データＤｎ〜Ｄｎ＋δＮをシーンＳ１〜ＳδＮ＋１の順に受信して再生するように、クライアントに対して指定を行うものとなっている。
【００２７】
ここで、δＮは、０以上でＮ−ｎ以下の整数である。δＮの値は、公開サーバに予め設定しておいてもよいが、クライアントから指定できるようになっていると好ましい。これにより、クライアントで動画データを視聴するユーザは、再生する動画データの数を希望に応じて指定することが可能になり、動画データを視聴する時間の長さを変更することができるようになる。クライアントによるδｎの指定は、視聴要求する際などに行われる。
【００２８】
３．プレイリスト生成処理
図５は、プレイリストを生成する処理（以下において、単に‘プレイリスト生成処理’と呼ぶことがある。）を示したフローチャートである。このプレイリスト生成処理は、公開サーバで行われ、公開サーバがクライアントから視聴要求を受けるたびに開始される。図５のフローチャートにおいて、ｎは、公開サーバがクライアントから視聴要求を受けた時点で格納していた最新の動画データＤｎの番号を示している。
【００２９】
プレイリスト生成処理についてさらに詳しく説明する。公開サーバは、図５に示すように、プレイリスト生成処理を開始すると（処理３０１）、公開サーバが動画データＤ１の受信を完了しているかどうかを確認する（処理３０３）。公開サーバが動画データＤ１の受信を完了していない場合には、「現在、視聴することができません。」といったエラーメッセージをクライアントへと送信する（処理３０４）。
【００３０】
一方、公開サーバが動画データＤ１の受信を完了していた場合には、その時点で公開サーバが受信を完了している最新の動画データＤｐをプレイリストのシーンＳｑに登録する（処理３０５）。ここで、ｐは、ｎ以上でｎ＋δＮ以下の整数であり、その初期値はｎに設定されている（処理３０２）。また、ｑは、１以上でδＮ＋１以下の整数であり、その初期値は１に設定されている（処理３０２）。
【００３１】
続いて、公開サーバは、動画データＤｎ〜Ｄｎ＋δＮの全てをプレイリストに登録したかどうかを確認する（処理３０６）。プレイリストに登録すべき動画データが残っている場合には、ｐとｑにそれぞれ１ずつを加えて（処理３０７）、次の動画データＤｐを次のシーンＳｑに登録する。一方、動画データＤｎ〜Ｄｎ＋δＮの全てをプレイリストに登録した場合には、プレイリスト生成処理を終了する（処理３０８）。このとき、公開サーバには、図４に示すプレイリストが生成されている。
【００３２】
［クライアント］
次に、クライアントについて説明する。本実施態様のクライアントは、図１に示すように、公開サーバに対して動画データの視聴要求を行って、公開サーバからプレイリストを受信する。公開サーバからプレイリストを受信したクライアントは、そのプレイリストに基づいて、動画データＤｎ〜Ｄｎ＋δＮの送信要求を公開サーバに対して順次行い、公開サーバから動画データＤｎ〜Ｄｎ＋δＮを順次受信する。クライアントに受信された動画データＤｎ〜Ｄｎ＋δＮは、クライアントで順次再生される。
【００３３】
［動画配信システムの動作］
次に、本実施態様の動画配信システムの動作について説明する。図６は、映像サーバが動画データを録画する時間と、公開サーバが動画データを受信する時間と、クライアントが動画データを受信する時間と、クライアントが動画データを再生する時間との関係を示したタイムチャートである。ただし、プレイリストの生成や送受信などに要する時間は、動画データの受信に要する時間と比較して微小であるために、無視して描いてある。
【００３４】
映像サーバは、図６に示すように、リアルタイム動画データを録画して所定時間（録画時間Ｔ）ごとに分割された動画データＤ１〜ＤＮ（図６では、動画データＤｎ〜Ｄｎ＋３のみを記載。）を順次生成する。また、公開サーバは、映像サーバが動画データＤ１〜ＤＮの格納を終了するたびに動画データＤ１〜ＤＮの受信を開始し、その開始からｔ１後に動画データＤ１〜ＤＮの受信を終了する。ｔ１の値は、動画データＤ１〜ＤＮのファイルサイズや、映像サーバと公開サーバとを結ぶ通信回線の通信速度などに影響される。
【００３５】
公開サーバが動画データＤｎの受信を終了してからｔ２後に、クライアントから公開サーバに視聴要求が送信されると、クライアントは、動画データＤｎの受信を開始し、その開始からｔ３後に動画データＤｎの受信を終了する。動画データＤｎ＋１以降の受信は、公開サーバが動画データＤｎ＋１以降の受信を終了するたびに開始される。ｔ３の値は、動画データＤ１〜ＤＮのファイルサイズや、公開サーバとクライアントとを結ぶ通信回線の通信速度などに影響される。
【００３６】
クライアントは、動画データＤｎの受信を終了すると、動画データＤｎの再生を開始し、その開始からｔ４後に動画データＤｎの再生を終了する。動画データＤｎ＋１以降の再生は、直前の動画データの再生が終了するたびに開始される。ｔ４の値は、クライアントに搭載されているＣＰＵやメモリなどの性能に問題がない限りは、通常、録画時間Ｔに一致する。
【００３７】
本実施態様の動画配信システムでは、カメラで撮影されてからＴ＋ｔ１＋ｔ２＋ｔ３後に動画データＤｎの視聴を開始することができるようになっている。カメラで撮影されてから視聴できるまでの待機時間は、動画データＤｎをストリーミング再生することなどによって、さらに短縮することができる。
【００３８】
［動画配信システムの用途］
最後に、本発明の動画配信システムの用途について説明する。本発明の動画配信システムは、各種用途に用いることができる。例えば、スポーツの試合や風景をインターネットで放送する場合などに用いることができる。なかでも、カメラと映像サーバを移動している自動車に搭載して公開サーバをビルの一室に設置するなど、映像サーバと公開サーバとを有線で接続することが困難である場合や、映像サーバと公開サーバとを無線を介して接続する必要がある場合に好適に用いることができる。このような例としては、マラソンの放送や交通情報の収集などが挙げられる。
【図面の簡単な説明】
【００３９】
【図１】本発明の動画配信システムの好適な実施態様を示したシステム構成図である。
【図２】所定時間ごとに分割された動画データＤ１〜ＤＮを順次生成していく処理（分割処理）を示したフローチャートである。
【図３】公開サーバへ動画データＤ１〜ＤＮを順次送信していく処理（アップロード処理）を示したフローチャートである。
【図４】公開サーバで生成されるプレイリストの一例を示した図である。
【図５】プレイリストを生成する処理（プレイリスト生成処理）を示したフローチャートである。
【図６】映像サーバが動画データを録画する時間と、公開サーバが動画データを受信する時間と、クライアントが動画データを受信する時間と、クライアントが動画データを再生する時間との関係を示したタイムチャートである。
【符号の説明】
【００４０】
１０１〜１０９  分割処理
２０１〜２０９  アップロード処理
３０１〜３０８  プレイリスト生成処理
【図１】
2007074684.tif 000003
【図２】
2007074684.tif 000004
【図３】
2007074684.tif 000005
【図４】
2007074684.tif 000006
【図５】
2007074684.tif 000007
【図６】
2007074684.tif 000008