JP2007074684A - 動画配信システム - Google Patents

Abstract

【課題】 カメラで撮影されたリアルタイム動画データを、その即時性を著しく損なわせることなく、フレーム落ちのない状態で視聴者に提供する。
【解決手段】 動画配信システムを、リアルタイム動画データを録画して所定時間Ｔごとに分割された動画データＤ_１〜Ｄ_Ｎ（Ｎは、２以上の整数）を順次生成する映像サーバと、映像サーバから動画データＤ_１〜Ｄ_Ｎを順次受信してクライアントへ公開する公開サーバとを備えたものとした。クライアントから公開サーバへ動画データの視聴要求があった際には、その時点で公開サーバが受信を完了している最新の動画データＤ_ｎ（ｎは、１以上でＮ以下の整数）以降の動画データ動画データＤ_ｎ〜Ｄ_ｎ＋δＮ（δＮは、０以上でＮ−ｎ以下の整数）を順次受信して順次再生するように指定を行うプレイリストが公開サーバからクライアントへと送信される。
【選択図】 図１

Description

本発明は、インターネットなどのネットワークを介して動画データをダウンロードする際に用いられる動画配信システムに関する。

従来より、ある地点で撮影されたライブ映像をインターネットを介して遠隔地のクライアントにライブ配信することが行われている（例えば、特許文献１を参照。）。しかし、従来のライブ配信は、クライアントで再生される映像の即時性を重視していたために、撮影されたライブ映像は、フレーム（コマ）単位で送信されていた。また、何らかの通信障害によって伝送路上でフレームが消失した場合であっても、そのまま次のフレームを送信していた。このため、クライアントで再生される映像には、フレーム落ち（コマ落ち）が生じてしまい、視聴者がストレスを感じることも多かった。即時性が多少損なわれてもフレーム落ちのない映像を視聴したいという要望はあったが、このような要望に応えることのできる動画配信システムは、未だ提案されていなかった。

特開２００３−２０９８２８号公報（特許請求の範囲、図１）

本発明は、上記課題を解決するためになされたものであり、リアルタイム動画データ（ライブ映像）を、その即時性を著しく損なわせることなく、フレーム落ちのない状態で視聴者に提供することを目的とする。

上記課題は、リアルタイム動画データを録画して所定時間Ｔごとに分割された動画データＤ_１〜Ｄ_Ｎ（Ｎは、２以上の整数）を順次生成する映像サーバと、映像サーバから動画データＤ_１〜Ｄ_Ｎを順次受信してクライアントへ公開する公開サーバとを備え、クライアントから公開サーバへ動画データの視聴要求があった際に、その時点で公開サーバが受信を完了している最新の動画データＤ_ｎ（ｎは、１以上でＮ以下の整数）以降の動画データＤ_ｎ〜Ｄ_ｎ＋δＮ（δＮは、０以上でＮ−ｎ以下の整数）を順次受信して順次再生するように指定を行うプレイリストが公開サーバからクライアントへ送信されることを特徴とする動画配信システムを提供することによって解決される。

これにより、リアルタイム動画データは、フレーム単位ではなく、連続する複数のフレームがまとめられた動画データ（動画ファイル）単位で公開サーバに送信されるようになる。したがって、映像サーバと公開サーバとの通信に、ＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）やＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）など、高機能な通信プロトコルを使用することが可能になり、リアルタイム動画データをフレーム落ちなく確実に公開サーバへと送信することが可能になる。また、視聴者は、リアルタイム動画データが撮影されてから数十秒〜数分遅れで視聴することも可能である。

録画時間Ｔは、特に限定されないが、短く設定しすぎると、映像サーバと公開サーバとを結ぶ通信回線に障害が生じて動画データＤ_１〜Ｄ_Ｎの送信に遅れが生じた場合などに、その遅れを回復することが困難になるおそれがある。このため、録画時間Ｔは、通常、１０秒以上に設定される。録画時間Ｔは、３０秒以上であると好ましく、１分以上であるとより好ましく、３分以上であるとさらに好ましい。一方、録画時間Ｔは、長く設定しすぎると、クライアントが再生する動画データの即時性が著しく失われるおそれがあるために、通常、３０分以下に設定される。録画時間Ｔは、２０分以下であると好ましく、１５分以下であるとより好ましく、１０分以下であるとさらに好ましい。

δＮの値は、クライアントから指定できるようになっていると好ましい。これにより、クライアントで動画データを視聴するユーザは、再生する動画データの数を希望に応じて指定することが可能になり、動画データを視聴する時間の長さを変更することができるようになる。例えば、δＮを０に設定すると、動画データＤ_ｎだけを視聴することができるし、δＮをＮ−ｎに設定すると、動画データＤ_ｎから最後の動画データＤ_Ｎまで視聴することができる。

映像サーバと公開サーバとの通信が、パケット再送方式によって行われることも好ましい。ここで、パケット再送方式とは、伝送路上で損失したパケットを受信側（公開サーバ）で検知して、送信側（映像サーバ）に損失したパケットの再送を要求する方式のことをいう。これにより、動画データをパケット損失なく送信することが可能になり、映像サーバが生成した動画データＤ_１〜Ｄ_Ｎと、公開サーバに格納された動画データＤ_１〜Ｄ_Ｎとの同一性を担保することが可能になる。

以上のように、本発明によって、カメラで撮影されたリアルタイム動画データを、その即時性を著しく損なわせることなく、フレーム落ちのない状態で視聴者に提供することが可能になる。

本発明の動画配信システムをより具体的に説明する。図１は、本発明の動画配信システムの好適な実施態様を示したシステム構成図である。本実施態様の動画配信システムは、図１に示すように、映像サーバと公開サーバとを備えたものとなっている。図１においては、クライアントを１台しか記載していないが、実際には多数のクライアントが存在している。また、公開サーバも１台しか記載していないが、公開サーバにかかる負担が大きく、分散処理を行う必要がある場合などには、公開サーバを複数台設けてもよい。

［映像サーバ］
１．概要
まず、映像サーバについて説明する。本実施態様の映像サーバは、図１に示すように、カメラから送られてくるリアルタイム動画データを録画して、所定時間ごとに分割された動画データＤ_１〜Ｄ_Ｎを順次生成し、生成した動画データＤ_１〜Ｄ_Ｎを公開サーバへと順次送信するものとなっている。ここで、Ｎは、２以上の整数であり、リアルタイム動画データの分割数を示している。

２．分割処理
図２は、所定時間ごとに分割された動画データＤ_１〜Ｄ_Ｎを順次生成していく処理（以下において、単に‘分割処理’と呼ぶことがある。）を示したフローチャートである。この分割処理は、映像サーバで行われ、映像サーバがカメラからリアルタイム動画データを受信し始めると開始される。

分割処理についてさらに詳しく説明する。映像サーバは、図２に示すように、分割処理を開始すると（処理１０１）、動画データＤ_ｉの録画を開始する（処理１０３）。ここで、ｉは、１以上でＮ以下の整数であり、その初期値は１に設定されている（処理１０２）。動画データＤ_ｉの録画は、動画データＤ_ｉの録画開始から所定時間Ｔが経過するまで続けられる（処理１０４）。本実施態様の映像サーバにおいて、所定時間Ｔ（録画時間Ｔ）は５分に設定されている。

動画データＤ_ｉの録画が終了すると（処理１０５）、映像サーバは、録画した動画データＤ_ｉをａｖｉ（Ａｕｄｉｏ Ｖｉｄｅｏ Ｉｎｔｅｒｌｅａｖｉｎｇ）やｍｐｅｇ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）など、所望の動画ファイル形式にエンコードする。エンコードされた動画データＤ_ｉは、完結したファイルとして映像サーバに格納される（処理１０６）。

続いて、映像サーバは、動画データＤ_１〜Ｄ_Ｎの全てを録画したかどうかを確認する（処理１０７）。まだ録画していない動画データが残っている場合には、ｉに１を加えて（処理１０８）、次の動画データＤ_ｉの録画を開始する（処理１０３）。一方、動画データＤ_１〜Ｄ_Ｎの全てを録画し終えている場合には、分割処理を終了する（処理１０９）。映像サーバは、分割処理が終了するまでに、Ｎ個の動画データＤ_１〜Ｄ_Ｎを完結したファイルとして生成する。

処理１０６において、動画データＤ_ｉをエンコードする際には、動画データＤ_ｉを複数種のサンプリング周波数でエンコードしてもよい。これにより、ファイルサイズの異なる複数種の動画データＤ_ｉを公開サーバで公開することが可能になり、各クライアントが接続している通信回線の通信速度にバラツキが存在する場合であっても、各クライアントは自らの通信速度に応じたファイルサイズの動画データＤ_ｉを選択して視聴することが可能になる。

また、処理１０６において、動画データＤ_ｉを映像サーバに格納する際には、動画データＤ_ｉに自動的にファイル名がつけられるようにしておくとよい。ファイル名のつけ方は、特に限定されないが、本実施態様の映像サーバは、動画データＤ_ｉの内容と、動画データＤ_ｉの撮影年月日と、動画データＤ_ｉの番号（ｉの値）とを反映させたファイル名をつけるように設定されている。例えば、西暦２００５年９月９日に撮影されたサッカーの試合の動画データＤ_１には、‘ｓｏｃｃｅｒ２００５０９０９０００１’といったファイル名がつけられる。

３．アップロード処理
図３は、公開サーバへ動画データＤ_１〜Ｄ_Ｎを順次送信していく処理（以下において、単に‘アップロード処理’と呼ぶことがある。）を示したフローチャートである。このアップロード処理は、映像サーバで行われ、映像サーバに動画データＤ_ｉが新たに格納されるたびに開始される。

アップロード処理についてさらに詳しく説明する。映像サーバは、図３に示すように、アップロード処理を開始すると（処理２０１）、公開サーバに通信接続を開始する（処理２０３）。公開サーバへの通信接続は、成功するまで続けられる（処理２０４）。映像サーバと公開サーバとの通信に用いるプロトコルとしては、ＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）やＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）などが例示される。

公開サーバとの通信接続に成功すると、映像サーバは、動画データＤ_ｉをＭ個（Ｍは、２以上の整数）のパケットＰ_１〜Ｐ_Ｍに分割し、公開サーバに対して動画データＤ_ｉのパケットＰ_ｊの送信を開始する（処理２０５）。ここで、ｊは、１以上でＭ以下の整数であり、その初期値は１に設定されている（処理２０２）。パケットＰ_ｊには、送信先（公開サーバ）のアドレスや誤り訂正符号など、各種の制御情報が付加される。

続いて、映像サーバは、パケットＰ_ｊの送信が正常に終了したかどうかを確認する（処理２０６）。パケットＰ_ｊの送信が正常に終了しなかった場合には、公開サーバにパケットＰ_ｊを再送信する（処理２０５）。この通信方式は、パケット再送方式と呼ばれており、動画データＤ_ｉをパケット損失なく送信することを可能にする。また、動画データＤ_ｉを送信している途中に映像サーバと公開サーバとの通信接続が切断した場合には、動画データＤ_ｉの送信を途中から再開することができるために、動画データＤ_ｉの送信時間を短縮することも可能になる。このような機能は、レジューム機能と呼ばれている。

このとき、パケットＰ_ｉの再送信は、パケットＰ_ｊの送信が正常に終了しなかった時点から所定時間が経つと自動的に行われるように設定してもよいが、映像サーバと公開サーバとの接続が再度確認されてから行うように設定すると好ましい。これにより、パケットＰ_ｊを無駄に送信するのを防ぐだけでなく、パケットＰ_ｊの再送信までの待機時間を短縮することも可能になる。

一方、処理２０６でパケットＰ_ｊの送信が正常に終了したことが確認できた場合には、動画データＤ_ｉのパケットＰ_１〜Ｐ_Ｍの全てを送信したかどうかを確認する（処理２０７）。まだ送信していないパケットが残っている場合には、ｊに１を加えて（処理２０８）、次のパケットＰ_ｊを送信する（処理２０５）。一方、動画データＤ_ｉのパケットＰ_１〜Ｐ_Ｍの全てを送信したことが確認できた場合には、動画データＤ_ｉのアップロード処理を終了する（処理２０９）。

［公開サーバ］
１．概要
次に、公開サーバについて説明する。本実施態様の公開サーバは、図１に示すように、映像サーバから動画データＤ_１〜Ｄ_Ｎを順次受信し、クライアントから動画データの視聴要求があるたびにプレイリストを生成してクライアントに送信するものとなっている。公開サーバとクライアントとの通信は、通常、ＦＴＰやＨＴＴＰなどによって行われる。

２．プレイリスト
図４は、公開サーバで生成されるプレイリストの一例を示した図である。このプレイリストは、クライアントから視聴要求があった時点で公開サーバが受信を完了していた最新の動画データＤ_ｎ以降の動画データＤ_ｎ〜Ｄ_ｎ＋δＮをシーンＳ_１〜Ｓ_δＮ＋１の順に受信して再生するように、クライアントに対して指定を行うものとなっている。

ここで、δＮは、０以上でＮ−ｎ以下の整数である。δＮの値は、公開サーバに予め設定しておいてもよいが、クライアントから指定できるようになっていると好ましい。これにより、クライアントで動画データを視聴するユーザは、再生する動画データの数を希望に応じて指定することが可能になり、動画データを視聴する時間の長さを変更することができるようになる。クライアントによるδｎの指定は、視聴要求する際などに行われる。

３．プレイリスト生成処理
図５は、プレイリストを生成する処理（以下において、単に‘プレイリスト生成処理’と呼ぶことがある。）を示したフローチャートである。このプレイリスト生成処理は、公開サーバで行われ、公開サーバがクライアントから視聴要求を受けるたびに開始される。図５のフローチャートにおいて、ｎは、公開サーバがクライアントから視聴要求を受けた時点で格納していた最新の動画データＤ_ｎの番号を示している。

プレイリスト生成処理についてさらに詳しく説明する。公開サーバは、図５に示すように、プレイリスト生成処理を開始すると（処理３０１）、公開サーバが動画データＤ_１の受信を完了しているかどうかを確認する（処理３０３）。公開サーバが動画データＤ_１の受信を完了していない場合には、「現在、視聴することができません。」といったエラーメッセージをクライアントへと送信する（処理３０４）。

一方、公開サーバが動画データＤ_１の受信を完了していた場合には、その時点で公開サーバが受信を完了している最新の動画データＤ_ｐをプレイリストのシーンＳ_ｑに登録する（処理３０５）。ここで、ｐは、ｎ以上でｎ＋δＮ以下の整数であり、その初期値はｎに設定されている（処理３０２）。また、ｑは、１以上でδＮ＋１以下の整数であり、その初期値は１に設定されている（処理３０２）。

続いて、公開サーバは、動画データＤ_ｎ〜Ｄ_ｎ＋δＮの全てをプレイリストに登録したかどうかを確認する（処理３０６）。プレイリストに登録すべき動画データが残っている場合には、ｐとｑにそれぞれ１ずつを加えて（処理３０７）、次の動画データＤ_ｐを次のシーンＳ_ｑに登録する。一方、動画データＤ_ｎ〜Ｄ_ｎ＋δＮの全てをプレイリストに登録した場合には、プレイリスト生成処理を終了する（処理３０８）。このとき、公開サーバには、図４に示すプレイリストが生成されている。

［クライアント］
次に、クライアントについて説明する。本実施態様のクライアントは、図１に示すように、公開サーバに対して動画データの視聴要求を行って、公開サーバからプレイリストを受信する。公開サーバからプレイリストを受信したクライアントは、そのプレイリストに基づいて、動画データＤ_ｎ〜Ｄ_ｎ＋δＮの送信要求を公開サーバに対して順次行い、公開サーバから動画データＤ_ｎ〜Ｄ_ｎ＋δＮを順次受信する。クライアントに受信された動画データＤ_ｎ〜Ｄ_ｎ＋δＮは、クライアントで順次再生される。

［動画配信システムの動作］
次に、本実施態様の動画配信システムの動作について説明する。図６は、映像サーバが動画データを録画する時間と、公開サーバが動画データを受信する時間と、クライアントが動画データを受信する時間と、クライアントが動画データを再生する時間との関係を示したタイムチャートである。ただし、プレイリストの生成や送受信などに要する時間は、動画データの受信に要する時間と比較して微小であるために、無視して描いてある。

映像サーバは、図６に示すように、リアルタイム動画データを録画して所定時間（録画時間Ｔ）ごとに分割された動画データＤ_１〜Ｄ_Ｎ（図６では、動画データＤ_ｎ〜Ｄ_ｎ＋３のみを記載。）を順次生成する。また、公開サーバは、映像サーバが動画データＤ_１〜Ｄ_Ｎの格納を終了するたびに動画データＤ_１〜Ｄ_Ｎの受信を開始し、その開始からｔ_１後に動画データＤ_１〜Ｄ_Ｎの受信を終了する。ｔ_１の値は、動画データＤ_１〜Ｄ_Ｎのファイルサイズや、映像サーバと公開サーバとを結ぶ通信回線の通信速度などに影響される。

公開サーバが動画データＤ_ｎの受信を終了してからｔ_２後に、クライアントから公開サーバに視聴要求が送信されると、クライアントは、動画データＤ_ｎの受信を開始し、その開始からｔ_３後に動画データＤ_ｎの受信を終了する。動画データＤ_ｎ＋１以降の受信は、公開サーバが動画データＤ_ｎ＋１以降の受信を終了するたびに開始される。ｔ_３の値は、動画データＤ_１〜Ｄ_Ｎのファイルサイズや、公開サーバとクライアントとを結ぶ通信回線の通信速度などに影響される。

クライアントは、動画データＤ_ｎの受信を終了すると、動画データＤ_ｎの再生を開始し、その開始からｔ_４後に動画データＤ_ｎの再生を終了する。動画データＤ_ｎ＋１以降の再生は、直前の動画データの再生が終了するたびに開始される。ｔ_４の値は、クライアントに搭載されているＣＰＵやメモリなどの性能に問題がない限りは、通常、録画時間Ｔに一致する。

本実施態様の動画配信システムでは、カメラで撮影されてからＴ＋ｔ_１＋ｔ_２＋ｔ_３後に動画データＤ_ｎの視聴を開始することができるようになっている。カメラで撮影されてから視聴できるまでの待機時間は、動画データＤ_ｎをストリーミング再生することなどによって、さらに短縮することができる。

［動画配信システムの用途］
最後に、本発明の動画配信システムの用途について説明する。本発明の動画配信システムは、各種用途に用いることができる。例えば、スポーツの試合や風景をインターネットで放送する場合などに用いることができる。なかでも、カメラと映像サーバを移動している自動車に搭載して公開サーバをビルの一室に設置するなど、映像サーバと公開サーバとを有線で接続することが困難である場合や、映像サーバと公開サーバとを無線を介して接続する必要がある場合に好適に用いることができる。このような例としては、マラソンの放送や交通情報の収集などが挙げられる。

本発明の動画配信システムの好適な実施態様を示したシステム構成図である。 所定時間ごとに分割された動画データＤ_１〜Ｄ_Ｎを順次生成していく処理（分割処理）を示したフローチャートである。 公開サーバへ動画データＤ_１〜Ｄ_Ｎを順次送信していく処理（アップロード処理）を示したフローチャートである。 公開サーバで生成されるプレイリストの一例を示した図である。 プレイリストを生成する処理（プレイリスト生成処理）を示したフローチャートである。 映像サーバが動画データを録画する時間と、公開サーバが動画データを受信する時間と、クライアントが動画データを受信する時間と、クライアントが動画データを再生する時間との関係を示したタイムチャートである。

符号の説明

１０１〜１０９ 分割処理
２０１〜２０９ アップロード処理
３０１〜３０８ プレイリスト生成処理

Claims (4)

1. リアルタイム動画データを録画して所定時間Ｔごとに分割された動画データＤ_１〜Ｄ_Ｎ（Ｎは、２以上の整数）を順次生成する映像サーバと、映像サーバから動画データＤ_１〜Ｄ_Ｎを順次受信してクライアントへ公開する公開サーバとを備え、クライアントから公開サーバへ動画データの視聴要求があった際に、その時点で公開サーバが受信を完了している最新の動画データＤ_ｎ（ｎは、１以上でＮ以下の整数）以降の動画データＤ_ｎ〜Ｄ_ｎ＋δＮ（δＮは、０以上でＮ−ｎ以下の整数）を順次受信して順次再生するように指定を行うプレイリストが公開サーバからクライアントへ送信されることを特徴とする動画配信システム。
2. 所定時間Ｔが１０秒〜３０分に設定された請求項１記載の動画配信システム。
3. δＮの値をクライアントから指定できる請求項1又は２記載の動画配信システム。
4. 映像サーバと公開サーバとの通信が、パケット再送方式によって行われる請求項１〜３いずれか記載の動画配信システム。

Images