動画再生装置、動画再生方法、動画再生プログラム、及び動画配信システム
【課題】回線品質を保証した通信を用いたリアルタイムな動画配信でのリアルタイム性が損なわれることを抑制することができる動画再生装置を提供する。
【解決手段】回線品質を保証するプロトコル（例えばＴＣＰ）を採用した通信部（ネットワーク送信部１Ｂ、ネットワーク２、ネットワーク受信部３Ａ）から送られてくる動画データを再生する動画再生装置（再生部３Ｂ）であって、前記通信部から１フレームの動画データが届いた時点において再生中の動画データが有るか否かを判定する判定部（不図示）と、前記判定部での判定結果が否でない期間内に前記通信部から届いた各フレームの動画データの少なくとも一部を間引く間引き処理部（不図示）とを備える動画再生装置。
【解決手段】回線品質を保証するプロトコル（例えばＴＣＰ）を採用した通信部（ネットワーク送信部１Ｂ、ネットワーク２、ネットワーク受信部３Ａ）から送られてくる動画データを再生する動画再生装置（再生部３Ｂ）であって、前記通信部から１フレームの動画データが届いた時点において再生中の動画データが有るか否かを判定する判定部（不図示）と、前記判定部での判定結果が否でない期間内に前記通信部から届いた各フレームの動画データの少なくとも一部を間引く間引き処理部（不図示）とを備える動画再生装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、回線品質を保証した通信を用いたリアルタイムな動画配信に関する。ここで、配信対象である動画データは、映像データと音声データの両方が含まれているもの、又は、映像データだけのものを意味する。例えば、カメラとマイクを用いて取得された動画データは映像データと音声データの両方が含まれているが、カメラのみを用いて取得された動画データは映像データだけとなる。また、リアルタイムとは、厳密に同一時間ではなく、各種処理による若干の時間的誤差を含む概念であり、配信元で記録された動画データが記録時とほぼ同時に配信先で再生されることを意味している。
【背景技術】
【０００２】
従来より、回線品質を保証した通信におけるリアルタイムな動画配信を行う動画配信システムが開発されている。このような動画配信システムの構成例を図１に示す。図１に示す動画配信システムは、配信サーバー１と、ネットワーク２と、再生クライアント３とを備えている。
【０００３】
配信サーバー１は、ネットワーク２に接続されたノードであって、動画データの配信元となる。配信サーバー１は、映像外部入力端子（不図示）と、音声外部入力端子（不図示）とを有している。配信サーバー１の映像外部入力端子はケーブルを介してカメラ４の外部出力端子（不図示）に接続可能であり、配信サーバー１の音声外部入力端子はケーブルを介してマイク５の外部出力端子（不図示）に接続可能である。
【０００４】
ネットワーク２は、通信プロトコルとしてＴＣＰ（Transmission Control Protocol）のようにリトライ機能を持った回線品質を保証するプロトコルを採用したネットワークである。ネットワーク２の構成は、有線回線のみによる構成、無線回線のみによる構成、有線回線及び無線回線による構成のいずれであっても構わない。
【０００５】
再生クライアント３は、ネットワーク２に接続されたノードであって、動画データを受け取って再生する。
【０００６】
配信サーバー１として、例えばＴＣＰに適合する通信機能と、映像外部入力端子と、音声外部入力端子とを有するプログラマブル表示器を用い、再生クライアント３として、例えばパーソナルコンピュータ（以下、パソコンという。）を用いることができる。当該プログラマブル表示器は、自身のモニタ画面にカメラ４の撮影画像を表示することができる。したがって、カメラ４が工場の生産ラインを撮影するようにカメラ４を工場の生産ラインの周辺に設置し、当該プログラマブル表示器も工場の生産ラインの周辺に設置し、当該パソコンを工場の生産ラインから離れた場所に設置することで、作業者は当該プログラマブル表示器のモニタ画面によりリアルタイムに工場の生産ラインの画像を確認することができるとともに、工場の生産ラインから離れた場所にいる管理者は当該パソコンのモニタ画面によりリアルタイムに工場の生産ラインの画像を確認することができる。
【０００７】
ここで、パソコンの概略構成を図３に示す。図３に示すパソコンは、パソコン全体の制御を行うＣＰＵ（Central Processing Unit）１１と、ＣＰＵ１１において実行されるプログラムや設定データなどを記録するＲＯＭ（Read Only Memory）１２と、ＣＰＵ１１においてプログラムを実行する際の作業領域として用いられるＲＡＭ（Random Access Memory）１３と、キーボードやマウスなどの操作部１４と、ディスプレイなどの表示部１５と、所定のネットワークにアクセス可能であるネットワークインターフェース１６と、記録メディアにアクセス可能である記録メディアインターフェース１７と、各部を相互に接続するためのバス１８とを備えている。図３に示すパソコンを再生クライアント３として用いる場合、動画再生プログラムをＲＯＭ１２に格納する。
【０００８】
また、図１に示す動画配信システムは、その機能面から、録画部と、通信部と、再生部とに大きく分けられる。以下、図２に示す機能ブロック図を参照して説明する。
【０００９】
録画部１Ａは、外部（カメラ４・マイク５又はカメラ４）から受け取った映像信号・音声信号又は映像信号を動画データとして纏めて記録する部分である。録画部１Ａは、配信サーバー１内に配置され、通常ＤＳＰ（Digital Signal Processor）などの専用ハードウェアを利用して圧縮された動画データを生成する。
【００１０】
通信部は、録画部１Ａから受け取った動画データをネットワーク２経由で配信サーバー１から再生クライアント３内の再生部３Ｂに送る部分である。通信部は、配信サーバー１内に配置されるネットワーク送信部１Ｂと、ネットワーク２と、再生クライアント３内に配置されるネットワーク受信部３Ａとによって構成される。
【００１１】
再生部３Ｂは、通信部から受け取った動画データを再生する部分である。再生部３Ｂは、再生クライアント３内に配置され、通信部から受け取った動画データを伸長して再生する。
【００１２】
上記構成例の動画配信システムの動作について、録画部１Ａが一定周期（１／４秒周期）で１フレームの圧縮動画データを生成して１秒間に４フレームの圧縮動画データを生成し、通信部が正常な状態では通信部が１フレームの動画データを通信するのに１／４秒よりも短い時間しか必要としない場合を例に挙げて、説明する。
【００１３】
図４は、通信部が正常な状態である場合におけるデータ処理例の様子を示す図である。
【００１４】
図４において、便宜上、時刻ｔ０から時刻ｔ２０迄の事象を１／４秒毎に２０個のサブ事象に区切っている。したがって、１番目のサブ事象は時刻ｔ０から１／４秒経過した時刻ｔ１で終了している。時刻ｔ０から時刻ｔ２０迄の事象は絶え間無く起こっているので、サブ事象間に隙間はない。
【００１５】
録画部１Ａは、１フレーム分の映像信号・音声信号又は映像信号を蓄積する毎に、１フレームの圧縮動画データを生成し始める。録画部１Ａは、時刻ｔ１において、１番目のサブ事象に対応する１フレーム分の映像信号・音声信号又は映像信号を蓄積するので、時刻ｔ１から、１番目のサブ事象に対応する１フレームの圧縮動画データ（以下、ｋ番目のサブ事象に対応する１フレームの圧縮動画データを「第ｋフレームの圧縮動画データ」ともいう。）を生成し始める。１フレームの圧縮動画データが一定周期（１／４秒周期）で生成されるので、１フレームの圧縮動画データを生成するための処理時間が１／４秒よりも短ければ、第１フレームの圧縮動画データの生成終了時刻ｔ１’と第２フレームの圧縮動画データの生成開始時刻ｔ２との間に空き時間Δｔ１ができる。
【００１６】
録画部１Ａが第１フレームの圧縮動画データを生成し終えると、通信部は第１フレームの圧縮動画データのデータ送信を開始する。すなわち、時刻ｔ１’は、第１フレームの圧縮動画データの生成終了時刻であるとともに、第１フレームの圧縮動画データのデータ送信開始時刻でもある。その後、第１フレームの圧縮動画データのデータ送信終了時刻ｔ１’’において、第１フレームの圧縮動画データが再生部３Ｂに届く。第１フレームの圧縮動画データのデータ送信終了時刻ｔ１’’から第２フレームの圧縮動画データの生成終了時刻ｔ２’迄は、通信部にとって待ち時間となる。そして、録画部１Ａが第２フレームの圧縮動画データの生成を終了し次第、通信部は第２フレームの圧縮動画データのデータ送信を開始する。
【００１７】
再生部３Ｂは、第１フレームの圧縮動画データが届くと、第１フレームの圧縮動画データの再生を開始する。第１フレームの圧縮動画データは１／４秒間分のデータであるので、その再生には１／４秒かかる。第１フレームの圧縮動画データの再生終了とほぼ同時に、第２フレームの圧縮動画データが再生部３Ｂに届くので、第１フレームの圧縮動画データの再生終了後ほぼ隙間無く第２フレームの圧縮動画データの再生が開始される。
【００１８】
上述した通り録画部１Ａが一定周期（１／４秒）で１フレームの圧縮録画データを生成するので、通信部が１フレームの圧縮録画データを再生部３Ｂにデータ送信し終えた後からその周期（１／４秒）以内に次の１フレームの圧縮録画データを再生部３Ｂにデータ送信し終えることができれば、再生部３Ｂも一定周期で１フレームの圧縮録画データの再生を順次開始することができ、その結果、圧縮動画データの再生を絶え間無く行える。すなわち、通信部が正常な状態である場合、配信サーバー１側での事象の発生から僅かな遅延でその事象に対応する動画を再生クライアント３側で再生すること、すなわちリアルタイムな動画配信が実現される。
【先行技術文献】
【特許文献】
【００１９】
【特許文献１】特開２００４−５６８１９号公報（要約）
【特許文献２】特許第２８７１３１６号公報（請求項１）
【特許文献３】特許第３９２７４２２号公報（段落００２５、段落００２６）
【発明の概要】
【発明が解決しようとする課題】
【００２０】
しかしながら、ネットワーク２は、リトライ機能を持った回線品質を保証するプロトコルを採用したネットワークであるため、パケットロストなどの発生により通信部においてリトライが発生する。このリトライの発生頻度に応じて、通信部の通信速度は速くなったり遅くなったり動的に変化する。すなわち、リトライの発生頻度が低い期間においては通信部の通信速度は速くなり、リトライの発生頻度が高い期間においては通信部の通信速度は遅くなる。
【００２１】
通信部の通信速度が一旦遅くなると、その後通信部の通信速度が速くなっても（復旧しても）、通信部の通信速度が遅くなっていた間に拡大した遅延時間（配信サーバー１側での事象に対するその事象に対応する再生クライアント３側での再生動画の遅延時間）は復旧しないので、通信部の通信速度が一旦遅くなる度に、上記遅延時間が拡大してリアルタイムな動画配信でのリアルタイム性が損なわれる。
【００２２】
通信部の通信速度が一時的に遅くなる例として、ここでは、第６フレームの圧縮動画データのデータ送信が一旦失敗し、再送で復旧した場合について説明する。
【００２３】
図５は、第６フレームの圧縮動画データのデータ送信が一旦失敗し、再送で復旧した場合における従来のデータ処理例の様子を示す図である。
【００２４】
ノイズ等の要因により、第６フレームの圧縮動画データのデータ送信に失敗する。この場合、再生部３Ｂは、第５フレームの圧縮動画データを再生し終えた時に、第６フレームの圧縮動画データを受け取っていないので、再生するデータが枯渇し、第５フレームの圧縮動画データの再生終了時刻から後述する第６フレームの圧縮動画データのデータ送信終了時刻ｔ６’’迄の時間ΔＴにおいて再生が途切れる。
【００２５】
通信部では、通信プロトコルの再送処理により第６フレームの圧縮動画データを再度送信する。この再送信が成功し、第６フレームの圧縮動画データのデータ送信終了時刻ｔ６’’において、第６フレームの圧縮動画データが再生部３Ｂに届く。第６フレームの圧縮動画データが再生部３Ｂに届くと、再生部３Ｂは再生処理を再開する。
【００２６】
ところが、時間ΔＴにおいて通信が途絶えている間にも、録画部１Ａは一定周期（１／４秒）で第７フレーム以降の圧縮動画データを生成し、順次通信部に渡している。このため、通信部が送信待ちの圧縮動画データをネットワーク送信部１Ｂ内のフレームバッファメモリ（不図示）に蓄積することになり、高負荷状態になる。この高負荷状態は、通信部において蓄積されている送信待ちの圧縮動画データが無くなる（時刻ｔ１４’）まで続く。
【００２７】
録画部１Ａが１フレームの圧縮動画データを生成するために必要な処理時間よりも、通信部が１フレームの圧縮動画データをデータ送信するために必要な処理時間の方が短いのであれば（通常は短くなっている）、通信部において蓄積されている送信待ちの圧縮動画データがいずれ無くなり、通信は完全に復旧したことになる。なお、通信が完全に復旧した状態とは、録画部１Ａが生成した１フレームの圧縮動画データを通信部がリアルタイムに再生部３Ｂへ送ることができる状態をいう。また、録画部１Ａは、動的に変化する通信部の通信速度に応じて録画品質を変化させ、通信部の通信速度が遅い場合には圧縮動画データを生成する際の圧縮率を高くして１フレームのデータ量を少なくするようにしてもよい。これにより、通信部が高負荷状態になることを抑制でき、また、通信部が高負荷状態になったときでも通信の復旧を早めることができる。
【００２８】
再生部３Ｂは、再生再開後、第７フレーム以降の圧縮動画データを順次再生しているが、１フレームの圧縮動画データの再生時間は１／４秒に固定されており、速く再生することはできないので、結果的に、配信サーバー１側での事象に対するその事象に対応する再生クライアント３側での再生動画の遅延時間は、通信が途絶えていた時間分だけ拡大し、復旧しない。
【００２９】
なお、特許文献１では、放送映像データの送受信を何らかの理由（例えばオンデマンド映像データの割り込み送信）で中断した後に再開する場合、送信再開直後の部分からでも放送映像データを受信側が正しく復号、画面表示できる送受信システムを提案している。しかしながら、かかる送受信システムには、送受信を中断している間の放送映像データに対応する画面表示が完全にカットされてしまうという問題点がある。
【００３０】
また、特許文献２では、シーンチェンジなどにより予測誤差が急激に大きくなり、そのピクチャーの符号化データをそのまま伝送すると所定の伝送レートを超過してしまう場合、そのピクチャーの符号化データを伝送することなく、そのピクチャーをスキップするようにした動画像符号化装置（録画部）を提案している。しかしながら、かかる動画像符号化装置（録画部）は、当該動画像符号化装置（録画部）から出力されるデータを伝送する伝送路（通信部）が正常な状態であることを前提にして、上記「所定の伝送レート」を設定しているため、回線品質を保証した通信を用いたリアルタイムな動画配信でのリアルタイム性が損なわれることを抑制できないという問題点がある。
【００３１】
また、特許文献３では、動画像を高い圧縮率で効率よく送受信しつつ、通信エラーがあっても速やかに対処し得るようにするために、受信局内の復号器での復号処理において、キーＧＯＢ（Group of Block）についてエラー検出を行い、エラーが発見された場合にはキーＧＯＢの再送要求を送信局に送信する動画像送受信システムを提案している。しかしながら、かかる動画像送受信システムには、キーＧＯＢの再送によって動画像送受信のリアルタイム性が損なわれてしまうという問題点がある。
【００３２】
本発明は、上記の状況に鑑み、回線品質を保証した通信を用いたリアルタイムな動画配信でのリアルタイム性が損なわれることを抑制することができる動画再生装置、動画再生方法、動画再生プログラム、及び動画配信システムを提供することを目的とする。
【課題を解決するための手段】
【００３３】
上記目的を達成するために本発明に係る動画再生装置は、回線品質を保証するプロトコルを採用した通信部から送られてくる動画データを再生する動画再生装置であって、前記通信部から１フレームの動画データが届いた時点において再生中の動画データが有るか否かを判定する判定部と、前記判定部での判定結果が否でない期間内に前記通信部から届いた各フレームの動画データの少なくとも一部を間引く間引き処理部とを備える構成とする。
【００３４】
また、間引き処理が行われた後、最初に再生するフレームデータは差分フレームであれば前画面の情報がないため、特別な補間処理等を行わない限り、その再生が不可能となる。したがって、上記構成の動画再生装置において、前記間引き処理部が、前記判定部での判定結果が否でない期間内に前記通信部から届いた各フレームの動画データのうち、差分フレームについては全て間引くようにすることが望ましい。さらに、通信トラブル発生中の映像・音声又は映像を一切視聴することができなくなることを防止する観点から、前記間引き処理部が、前記判定部での判定結果が否でない期間内に前記通信部から届いた各フレームの動画データのうち、全画フレームについては全て間引かないようにしてもよい。
【００３５】
上記目的を達成するために本発明に係る動画再生方法は、回線品質を保証するプロトコルを採用した通信部から送られてくる動画データを再生する動画再生方法であって、前記通信部から１フレームの動画データが届いた時点において再生中の動画データが有るか否かを判定する判定ステップと、前記判定ステップでの判定結果が否でない期間内に前記通信部から届いた各フレームの動画データの少なくとも一部を間引く間引き処理ステップとを備えるようにする。
【００３６】
上記目的を達成するために本発明に係る動画再生プログラムは、コンピュータを、回線品質を保証するプロトコルを採用した通信部から送られてくる動画データを再生する動画再生装置として機能させるための動画再生プログラムであって、さらに、前記コンピュータを、前記通信部から１フレームの動画データが届いた時点において再生中の動画データが有るか否かを判定する判定手段、及び前記判定手段での判定結果が否でない期間内に前記通信部から届いた各フレームの動画データの少なくとも一部を間引く間引き処理手段として機能させるようにする。
【００３７】
上記目的を達成するために本発明に係る動画配信システムは、外部から受け取った映像信号・音声信号又は映像信号を動画データとして纏めて記録する録画部と、再生部と、前記録画部から受け取った動画データをネットワーク経由で前記再生部に送る通信部とを備え、前記通信部が回線品質を保証するプロトコルを採用した通信部であり、前記再生部が上記いずれかの構成の録画再生装置であるようにする。
【発明の効果】
【００３８】
本発明によると、通信部が高負荷状態になったと考えられるときに、動画再生装置に届いた動画データを間引くことができるので、録画部側での事象に対するその事象に対応する再生部側での再生動画の遅延時間を復旧することができる。したがって、回線品質を保証した通信を用いたリアルタイムな動画配信でのリアルタイム性が損なわれることを抑制することができる。
【図面の簡単な説明】
【００３９】
【図１】回線品質を保証した通信におけるリアルタイムな動画配信を行う動画配信システムの構成例を示す図である。
【図２】図１に示す動画配信システムの機能ブロック図である。
【図３】再生クライアントとして用いるパソコンの概略構成を示す図である。
【図４】通信部が正常な状態である場合におけるデータ処理例の様子を示す図である。
【図５】通信部が異常な状態である場合における従来のデータ処理例の様子を示す図である。
【図６】現フレームの圧縮動画データの再生終了時刻と次フレームの圧縮動画データのデータ送信終了時刻との関係を示す図である。
【図７】本発明に係る再生部の動作例を示すフローチャートである。
【図８】通信部が異常な状態である場合における本発明に係る動画配信システムでのデータ処理例の様子を示す図である。
【図９】図８に示すデータ処理例を実行した場合の再生部の挙動を示す図である。
【発明を実施するための形態】
【００４０】
本発明の実施形態について図面を参照して以下に説明する。本発明者等は、回線品質を保証した通信を用いたリアルタイムな動画配信でのリアルタイム性が損なわれることを抑制する手法について鋭意検討した結果、リアルタイム性が損なわれることを間引き処理を行うことによって抑制する手法に想到した。
【００４１】
間引き処理は、動画配信システムの録画部、通信部、及び再生部の３つの箇所それぞれで行うことが可能である。しかしながら、録画部で間引き処理を行う場合、録画部は通信部の状態によりその挙動を変える必要があり、録画部が通信部に依存してしまい録画部、通信部、及び再生部それぞれの独立性が損なわれるので、本発明では録画部で間引き処理を行わないことにした。
【００４２】
また、通信部で間引き処理を行う場合、通信部が意図的にデータを欠落させることになり、回線品質を保証する、すなわち通信でのデータの欠落を防ぐという本来の目的に反することになるので、本発明では通信部で間引き処理を行わないことにした。
【００４３】
上記の検討結果から、本発明では再生部で間引き処理を行うことにした。本発明に係る動画配信システムの構成例は図１に示す構成と同様である。そして、図１に示す動画配信システムの機能ブロック図は、図２のようになる。また、本実施形態では、再生クライアント３として図３に示すパソコンを用いている。
【００４４】
配信サーバー１内の録画部１Ａは請求項中の「録画部」の一例であり、配信サーバー１内のネットワーク送信部１Ｂとネットワーク２と再生クライアント３内のネットワーク３Ａとを含む部分は請求項中の「通信部」の一例であり、再生クライアント３内の再生部３Ｂは請求項中の「動画再生装置」、「コンピュータ」、及び「再生部」それぞれの一例である。なお、録画部１Ａの独立性は多少損なわれることになるが、録画部１Ａは、動的に変化する通信部の通信速度に応じて録画品質を変化させ、通信部の通信速度が遅い場合には圧縮動画データを生成する際の圧縮率を高くして１フレームのデータ量を少なくするようにしてもよい。従来の動画配信システムと本発明に係る動画配信システムとの相違点は、図３に示すパソコンのＲＯＭ１２に格納されている動画再生プログラムの内容が異なり、従来の動画配信システムの再生部３Ｂが間引き処理を行わないのに対して、本発明に係る動画配信システムの再生部３Ｂは間引き処理を行う点である。以下、本発明に係る動画配信システムの再生部３Ｂでの間引き処理について説明する。
【００４５】
＜間引きタイミング＞
間引き処理が必要となるのは、通信部が高負荷状態（図５参照）になったときである。しかし、再生部３Ｂは通信部と独立しているため、通信部の状態を知ることができない。
【００４６】
一方、再生部３Ｂは、自身が現在再生しているフレームの圧縮動画データの再生終了時刻ｔE（図６参照）を把握している。この再生終了時刻ｔEと次フレームの圧縮動画データが通信部から再生部３Ｂに届く時刻との関係は、図６（ａ）〜（ｃ）に示す３パターンが考えられる。
【００４７】
図６（ａ）に示す第１のパターンでは、現在再生しているフレームの圧縮動画データの再生終了時刻ｔEとほぼ同時に次フレームの圧縮動画データが再生部３Ｂに到着する。通信部が正常な状態である場合、このパターンになる。
【００４８】
図６（ｂ）に示す第２のパターンでは、現在再生しているフレームの圧縮動画データの再生終了時刻ｔEの後、しばらくして次フレームの圧縮動画データが再生部３Ｂに到着する。通信トラブルが発生し、通信部の通信速度が遅くなっている場合にこのパターンになる。
【００４９】
図６（ｂ）に示す第３のパターンでは、現在再生しているフレームの圧縮動画データの再生終了時刻ｔEより前に次フレームの圧縮動画データが再生部３Ｂに到着する。録画部１Ａは一定周期（１／４秒）で１フレームの圧縮動画データを生成し、再生部３Ｂはその周期で１フレームの圧縮動画データを再生している。現在再生しているフレームの圧縮動画データの再生終了時刻ｔEより前に次フレームの圧縮動画データが再生部３Ｂに到着するのは、以前に通信部の通信速度が遅くなり、現在それが復旧処理中であると考えられる。
【００５０】
図６（ａ）に示す第１のパターン及び図６（ｂ）に示す第２のパターンの場合、次フレームの圧縮動画データが再生部３Ｂに到着した時点において、再生部３Ｂには次フレームの圧縮動画データ以外に再生すべき圧縮動画データがないため、再生部３Ｂは、到着した次フレームの圧縮動画データを間引く事なく再生する。
【００５１】
これに対して、図６（ｃ）に示す第３のパターンの場合、到着した次フレームの圧縮動画データを、現在再生しているフレームの圧縮動画データに続けて再生すると、配信サーバー１側での事象に対するその事象に対応する再生クライアント３側での再生動画の遅延時間が拡大し続けるので、間引くようにする。つまり、間引き処理は、再生部３Ｂが圧縮動画データを再生中に（ただし、再生がほぼ終了している場合は上記第１のパターンに属するので除く。）、次フレームの圧縮動画データが再生部３Ｂに到着した場合に行うようにする。
【００５２】
＜間引き対象フレームデータ＞
１フレームの圧縮動画データ（フレームデータ）の種類には、１画面分の全ての情報が格納された全画フレームと、前フレームからの差分情報だけを持った差分フレームとがある。ちなみに、ＭＰＥＧ４（Moving Picture Experts Group ４）では、全画フレームをＩフレームと称し、差分フレームをＰフレームと称している。
【００５３】
通信トラブルが長い間発生していると、通信部には多くのフレームデータが蓄積される。通信トラブルが復旧すると、通信部は一気にフレームデータを再生部３Ｂに届けるため、再生部３Ｂは１つのフレームデータ再生中に、複数のフレームデータを受け取る事がある。
【００５４】
配信サーバー１側での事象に対するその事象に対応する再生クライアント３側での再生動画の遅延時間の復旧を速くするためには、基本的に、再生部３Ｂは、再生中に届いたフレームデータを全て間引く必要がある。しかし、全てのフレームデータを間引いてしまうと、通信トラブル発生中の動画データを全て再生し無くなってしまうため、通信トラブル発生中の映像・音声又は映像を一切視聴することができなくなり、通信インフラが不安定な状況下では、再生動画の停止が頻繁に起こり視聴しにくい再生となってしまう。
【００５５】
このため、通信トラブル中の映像を少し残して再生する事が望ましい。これにより、配信サーバー１側での事象に対するその事象に対応する再生クライアント３側での再生動画の遅延時間の復旧に時間はかかるが（残したフレームの再生時間分復旧が遅れるが）、視聴者から見れば、 通信トラブル中の映像・音声又は映像を“早送り”の如く視聴する事ができるようにする。
【００５６】
なお、差分フレームから再開する事は前画面の情報がないため不可能である。したがって、前述した間引き処理が行われた後、最初に再生するフレームデータは全画フレームでなければならない。
【００５７】
＜間引き処理の手順＞
上記の考察の結果、本実施形態では、再生部３Ｂが以下のような手順で間引き処理を行うようにする。
【００５８】
再生部３Ｂは、間引き状態でない場合に、次のようなデータ処理を実行する。
【００５９】
フレームデータの再生終了時刻とほぼ同時に、すなわちフレームデータの再生終了時刻±所定時間（フレームデータの再生終了時刻の前後で所定時間が同じであってもよく異なっていてもよい。）の期間内に、再生部３Ｂにフレームデータが届いた場合（図６（ａ）参照）、再生部３Ｂは届いたフレームデータを再生する。
【００６０】
再生部３Ｂにフレームデータが届いた時点において、再生中のフレームデータがない場合（図６（ｂ）参照）、再生部３Ｂは届いたフレームデータを再生する。
【００６１】
再生部３Ｂにフレームデータが届いた時点において、再生中のフレームデータがある場合（図６（ｃ）参照）、届いたフレームデータが差分フレームであれば届いたフレームデータを間引き、それ以降間引き状態に移行し、届いたフレームデータが全画フレームであれば届いたフレームデータを再生する。
【００６２】
一方、再生部３Ｂは、間引き状態である場合に、次のようなデータ処理を実行する。
【００６３】
再生部３Ｂは、全画フレームを受信するまでの間、全ての差分フレームを間引き、間引き状態を継続する。そして、全画フレームを受信すると、再生部３Ｂは、全画フレームを間引かずに、再生中のフレームがなければ間引き状態から非間引き状態に移行し、再生中のフレームが有れば間引き状態を継続する。
【００６４】
したがって、再生部３Ｂは、図７に示すフローチャートのような動作を行う。ステップＳ１０において、再生部３Ｂは、通信部から渡されるフレームデータを受信し、受信が完了すると、ステップＳ２０に移行する。ステップＳ２０において、再生部３Ｂは、自身の状態が間引き状態であるか否かを判定する。なお、間引き状態であるか否かの判定や間引き状態、非間引き状態間の移行には、例えば間引き状態であるか否かを示す状態フラグを利用するとよい。
【００６５】
ステップＳ２０での判定の結果、間引き状態でなければ（ステップＳ２０のＮＯ）、ステップＳ１０で受信したフレームデータが全画フレームであるか否かを判定する（ステップＳ３０）。全画フレームであれば（ステップＳ３０のＹＥＳ）、再生部３Ｂは、ステップＳ１０で受信したフレームデータの再生を開始し（ステップＳ１１０）、その後ステップＳ１０に移行し、次のフレームデータを受信する。全画フレームでなければ（ステップＳ３０のＮＯ）、再生部３Ｂは、再生中のフレームデータが有るか否かを判定する（ステップＳ４０）。再生中のフレームデータがなければ（ステップＳ４０のＮＯ）、再生部３Ｂは、ステップＳ１０で受信したフレームデータの再生を開始し（ステップＳ１１０）、その後ステップＳ１０に移行し、次のフレームデータを受信する。一方、再生中のフレームデータが有れば（ステップＳ４０のＹＥＳ）、再生部３Ｂは、ステップＳ１０で受信したフレームデータを廃棄（間引き）し（ステップＳ５０）、自身の状態を非間引き状態から間引き状態に移行し（ステップＳ６０）、その後ステップＳ１０に移行し、次のフレームデータを受信する。
【００６６】
また、ステップＳ２０での判定の結果、間引き状態であれば（ステップＳ２０のＹＥＳ）、再生部３Ｂは、ステップＳ１０で受信したフレームデータが全画フレームであるか否かを判定する（ステップＳ７０）。全画フレームでなく差分フレームであれば（ステップＳ７０のＮＯ）、ステップＳ１０で受信したフレームデータを廃棄（間引き）し（ステップＳ８０）、自身の状態を間引き状態に保ったままステップＳ１０に移行し、次のフレームデータを受信する。一方、全画フレームであれば（ステップＳ７０のＹＥＳ）、再生部３Ｂは、再生中のフレームデータが有るか否かを判定する（ステップＳ９０）。再生中のフレームデータが有れば（ステップＳ９０のＹＥＳ）、再生部３Ｂは、自身の状態を間引き状態に保ったまま、ステップＳ１０で受信したフレームデータの再生を開始し（ステップＳ１１０）、その後ステップＳ１０に移行し、次のフレームデータを受信する。一方、再生中のフレームデータがなければ（ステップＳ９０のＮＯ）、再生部３Ｂは、自身の状態を間引き状態から非間引き状態に移行し（ステップＳ１００）、ステップＳ１０で受信したフレームデータの再生を開始し（ステップＳ１１０）、その後ステップＳ１０に移行し、次のフレームデータを受信する。
【００６７】
なお、ステップＳ４０及びステップＳ９０での再生中のフレームデータがないとの判定には、フレームデータの再生終了時刻とほぼ同時にステップＳ１０での受信が完了する場合も含まれるものとする。再生部３Ｂは、ステップＳ４０及びステップＳ９０の処理を行うので、請求項中の「判定部」を備えていることになる。また、再生部３Ｂは、ステップＳ５０及びステップＳ８０の処理を行うので、請求項中の「間引き処理部」を備えていることになる。
【００６８】
再生部３Ｂが上記のような動作をすることにより、通信部が正常な状態である場合における本発明に係る動画配信システムの動作は、通信部が正常な状態である場合における従来の動画配信システムの動作と同様になり、その場合のデータ処理例の様子は図４に示すようになる。
【００６９】
一方、再生部３Ｂが上記のような動作をすることにより、通信部が正常な状態でない場合における本発明に係る動画配信システムの動作は、通信部が正常な状態でない場合における従来の動画配信システムの動作（図５参照）と異なる。
【００７０】
ここで、本発明に係る動画配信システムにおいて、第６フレームの圧縮動画データのデータ送信が一旦失敗し、再送で復旧した場合について説明する。
【００７１】
図８は、第６フレームの圧縮動画データのデータ送信が一旦失敗し、再送で復旧した場合における本発明に係る動画配信システムでのデータ処理例の様子を示す図である。なお、図８において、第１，５，９，１３，１７フレームの圧縮動画データは全画フレームであり、それ以外のフレームデータは差分フレームである。
【００７２】
ノイズ等の要因により、第６フレームの圧縮動画データのデータ送信に失敗する。この場合、再生部３Ｂは、第５フレームの圧縮動画データを再生し終えた時に、第６フレームの圧縮動画データを受け取っていないので、再生するデータが枯渇し、第５フレームの圧縮動画データの再生終了時刻から後述する第６フレームの圧縮動画データのデータ送信終了時刻ｔ６’’迄の時間ΔＴにおいて再生が途切れる。
【００７３】
通信部では、通信プロトコルの再送処理により第６フレームの圧縮動画データを再度送信する。この再送信が成功し、第６フレームの圧縮動画データのデータ送信終了時刻ｔ６’’において、第６フレームの圧縮動画データが再生部３Ｂに届く。第６フレームの圧縮動画データが再生部３Ｂに届くと、再生部３Ｂは再生処理を再開する。
【００７４】
ところが、時間ΔＴにおいて通信が途絶えている間にも、録画部１Ａは一定周期（１／４秒）で第７フレーム以降の圧縮動画データを生成し、順次通信部に渡している。このため、通信部が送信待ちの圧縮動画データをネットワーク送信部１Ｂ内のフレームバッファメモリ（不図示）に蓄積することになり、高負荷状態になる。この高負荷状態は、通信部において蓄積されている送信待ちの圧縮動画データが無くなる（時刻ｔ１４’）まで続く。逆に言えば、時刻ｔ１４’において、通信は完全に復旧する。また、時刻ｔ１４’において、再生も完全復旧する。
【００７５】
図８に示すデータ処理例を実行した場合の再生部３Ｂの挙動をまとめると、図９に示すようになる。
【００７６】
以上、本発明に係る実施形態について説明したが、本発明の範囲はこれに限定されるものではなく、発明の主旨を逸脱しない範囲で種々の変更を加えて実行することができる。例えば、上述した実施形態での間引き処理を第１のモードとし、再生中に届いたフレームデータを全て間引く間引き処理を第２のモードとし、上述した実施形態のように全画フレームを全く間引かないのではなく、再生中に届いた差分フレームを全て間引き且つ再生中に届いた全画フレームを所定数おきに間引く間引き処理を第３のモードとし、上記第１〜３のモードの少なくとも２つを有し、図３に示すパソコンの操作部１４を操作によってモードの選択を可能にしてもよい。
【符号の説明】
【００７７】
１ 配信サーバー
１Ａ 録画部
１Ｂ ネットワーク送信部（通信部の一例の一部）
２ ネットワーク（通信部の一例の一部）
３ 再生クライアント
３Ａ ネットワーク受信部（通信部の一例の一部）
３Ｂ 再生部（動画再生装置の一例）
４ カメラ
５ マイク
１１ ＣＰＵ
１２ ＲＯＭ
１３ ＲＡＭ
１４ 操作部
１５ 表示部
１６ ネットワークインターフェース
１７ 記録メディアインターフェース
１８ バス
【技術分野】
【０００１】
本発明は、回線品質を保証した通信を用いたリアルタイムな動画配信に関する。ここで、配信対象である動画データは、映像データと音声データの両方が含まれているもの、又は、映像データだけのものを意味する。例えば、カメラとマイクを用いて取得された動画データは映像データと音声データの両方が含まれているが、カメラのみを用いて取得された動画データは映像データだけとなる。また、リアルタイムとは、厳密に同一時間ではなく、各種処理による若干の時間的誤差を含む概念であり、配信元で記録された動画データが記録時とほぼ同時に配信先で再生されることを意味している。
【背景技術】
【０００２】
従来より、回線品質を保証した通信におけるリアルタイムな動画配信を行う動画配信システムが開発されている。このような動画配信システムの構成例を図１に示す。図１に示す動画配信システムは、配信サーバー１と、ネットワーク２と、再生クライアント３とを備えている。
【０００３】
配信サーバー１は、ネットワーク２に接続されたノードであって、動画データの配信元となる。配信サーバー１は、映像外部入力端子（不図示）と、音声外部入力端子（不図示）とを有している。配信サーバー１の映像外部入力端子はケーブルを介してカメラ４の外部出力端子（不図示）に接続可能であり、配信サーバー１の音声外部入力端子はケーブルを介してマイク５の外部出力端子（不図示）に接続可能である。
【０００４】
ネットワーク２は、通信プロトコルとしてＴＣＰ（Transmission Control Protocol）のようにリトライ機能を持った回線品質を保証するプロトコルを採用したネットワークである。ネットワーク２の構成は、有線回線のみによる構成、無線回線のみによる構成、有線回線及び無線回線による構成のいずれであっても構わない。
【０００５】
再生クライアント３は、ネットワーク２に接続されたノードであって、動画データを受け取って再生する。
【０００６】
配信サーバー１として、例えばＴＣＰに適合する通信機能と、映像外部入力端子と、音声外部入力端子とを有するプログラマブル表示器を用い、再生クライアント３として、例えばパーソナルコンピュータ（以下、パソコンという。）を用いることができる。当該プログラマブル表示器は、自身のモニタ画面にカメラ４の撮影画像を表示することができる。したがって、カメラ４が工場の生産ラインを撮影するようにカメラ４を工場の生産ラインの周辺に設置し、当該プログラマブル表示器も工場の生産ラインの周辺に設置し、当該パソコンを工場の生産ラインから離れた場所に設置することで、作業者は当該プログラマブル表示器のモニタ画面によりリアルタイムに工場の生産ラインの画像を確認することができるとともに、工場の生産ラインから離れた場所にいる管理者は当該パソコンのモニタ画面によりリアルタイムに工場の生産ラインの画像を確認することができる。
【０００７】
ここで、パソコンの概略構成を図３に示す。図３に示すパソコンは、パソコン全体の制御を行うＣＰＵ（Central Processing Unit）１１と、ＣＰＵ１１において実行されるプログラムや設定データなどを記録するＲＯＭ（Read Only Memory）１２と、ＣＰＵ１１においてプログラムを実行する際の作業領域として用いられるＲＡＭ（Random Access Memory）１３と、キーボードやマウスなどの操作部１４と、ディスプレイなどの表示部１５と、所定のネットワークにアクセス可能であるネットワークインターフェース１６と、記録メディアにアクセス可能である記録メディアインターフェース１７と、各部を相互に接続するためのバス１８とを備えている。図３に示すパソコンを再生クライアント３として用いる場合、動画再生プログラムをＲＯＭ１２に格納する。
【０００８】
また、図１に示す動画配信システムは、その機能面から、録画部と、通信部と、再生部とに大きく分けられる。以下、図２に示す機能ブロック図を参照して説明する。
【０００９】
録画部１Ａは、外部（カメラ４・マイク５又はカメラ４）から受け取った映像信号・音声信号又は映像信号を動画データとして纏めて記録する部分である。録画部１Ａは、配信サーバー１内に配置され、通常ＤＳＰ（Digital Signal Processor）などの専用ハードウェアを利用して圧縮された動画データを生成する。
【００１０】
通信部は、録画部１Ａから受け取った動画データをネットワーク２経由で配信サーバー１から再生クライアント３内の再生部３Ｂに送る部分である。通信部は、配信サーバー１内に配置されるネットワーク送信部１Ｂと、ネットワーク２と、再生クライアント３内に配置されるネットワーク受信部３Ａとによって構成される。
【００１１】
再生部３Ｂは、通信部から受け取った動画データを再生する部分である。再生部３Ｂは、再生クライアント３内に配置され、通信部から受け取った動画データを伸長して再生する。
【００１２】
上記構成例の動画配信システムの動作について、録画部１Ａが一定周期（１／４秒周期）で１フレームの圧縮動画データを生成して１秒間に４フレームの圧縮動画データを生成し、通信部が正常な状態では通信部が１フレームの動画データを通信するのに１／４秒よりも短い時間しか必要としない場合を例に挙げて、説明する。
【００１３】
図４は、通信部が正常な状態である場合におけるデータ処理例の様子を示す図である。
【００１４】
図４において、便宜上、時刻ｔ０から時刻ｔ２０迄の事象を１／４秒毎に２０個のサブ事象に区切っている。したがって、１番目のサブ事象は時刻ｔ０から１／４秒経過した時刻ｔ１で終了している。時刻ｔ０から時刻ｔ２０迄の事象は絶え間無く起こっているので、サブ事象間に隙間はない。
【００１５】
録画部１Ａは、１フレーム分の映像信号・音声信号又は映像信号を蓄積する毎に、１フレームの圧縮動画データを生成し始める。録画部１Ａは、時刻ｔ１において、１番目のサブ事象に対応する１フレーム分の映像信号・音声信号又は映像信号を蓄積するので、時刻ｔ１から、１番目のサブ事象に対応する１フレームの圧縮動画データ（以下、ｋ番目のサブ事象に対応する１フレームの圧縮動画データを「第ｋフレームの圧縮動画データ」ともいう。）を生成し始める。１フレームの圧縮動画データが一定周期（１／４秒周期）で生成されるので、１フレームの圧縮動画データを生成するための処理時間が１／４秒よりも短ければ、第１フレームの圧縮動画データの生成終了時刻ｔ１’と第２フレームの圧縮動画データの生成開始時刻ｔ２との間に空き時間Δｔ１ができる。
【００１６】
録画部１Ａが第１フレームの圧縮動画データを生成し終えると、通信部は第１フレームの圧縮動画データのデータ送信を開始する。すなわち、時刻ｔ１’は、第１フレームの圧縮動画データの生成終了時刻であるとともに、第１フレームの圧縮動画データのデータ送信開始時刻でもある。その後、第１フレームの圧縮動画データのデータ送信終了時刻ｔ１’’において、第１フレームの圧縮動画データが再生部３Ｂに届く。第１フレームの圧縮動画データのデータ送信終了時刻ｔ１’’から第２フレームの圧縮動画データの生成終了時刻ｔ２’迄は、通信部にとって待ち時間となる。そして、録画部１Ａが第２フレームの圧縮動画データの生成を終了し次第、通信部は第２フレームの圧縮動画データのデータ送信を開始する。
【００１７】
再生部３Ｂは、第１フレームの圧縮動画データが届くと、第１フレームの圧縮動画データの再生を開始する。第１フレームの圧縮動画データは１／４秒間分のデータであるので、その再生には１／４秒かかる。第１フレームの圧縮動画データの再生終了とほぼ同時に、第２フレームの圧縮動画データが再生部３Ｂに届くので、第１フレームの圧縮動画データの再生終了後ほぼ隙間無く第２フレームの圧縮動画データの再生が開始される。
【００１８】
上述した通り録画部１Ａが一定周期（１／４秒）で１フレームの圧縮録画データを生成するので、通信部が１フレームの圧縮録画データを再生部３Ｂにデータ送信し終えた後からその周期（１／４秒）以内に次の１フレームの圧縮録画データを再生部３Ｂにデータ送信し終えることができれば、再生部３Ｂも一定周期で１フレームの圧縮録画データの再生を順次開始することができ、その結果、圧縮動画データの再生を絶え間無く行える。すなわち、通信部が正常な状態である場合、配信サーバー１側での事象の発生から僅かな遅延でその事象に対応する動画を再生クライアント３側で再生すること、すなわちリアルタイムな動画配信が実現される。
【先行技術文献】
【特許文献】
【００１９】
【特許文献１】特開２００４−５６８１９号公報（要約）
【特許文献２】特許第２８７１３１６号公報（請求項１）
【特許文献３】特許第３９２７４２２号公報（段落００２５、段落００２６）
【発明の概要】
【発明が解決しようとする課題】
【００２０】
しかしながら、ネットワーク２は、リトライ機能を持った回線品質を保証するプロトコルを採用したネットワークであるため、パケットロストなどの発生により通信部においてリトライが発生する。このリトライの発生頻度に応じて、通信部の通信速度は速くなったり遅くなったり動的に変化する。すなわち、リトライの発生頻度が低い期間においては通信部の通信速度は速くなり、リトライの発生頻度が高い期間においては通信部の通信速度は遅くなる。
【００２１】
通信部の通信速度が一旦遅くなると、その後通信部の通信速度が速くなっても（復旧しても）、通信部の通信速度が遅くなっていた間に拡大した遅延時間（配信サーバー１側での事象に対するその事象に対応する再生クライアント３側での再生動画の遅延時間）は復旧しないので、通信部の通信速度が一旦遅くなる度に、上記遅延時間が拡大してリアルタイムな動画配信でのリアルタイム性が損なわれる。
【００２２】
通信部の通信速度が一時的に遅くなる例として、ここでは、第６フレームの圧縮動画データのデータ送信が一旦失敗し、再送で復旧した場合について説明する。
【００２３】
図５は、第６フレームの圧縮動画データのデータ送信が一旦失敗し、再送で復旧した場合における従来のデータ処理例の様子を示す図である。
【００２４】
ノイズ等の要因により、第６フレームの圧縮動画データのデータ送信に失敗する。この場合、再生部３Ｂは、第５フレームの圧縮動画データを再生し終えた時に、第６フレームの圧縮動画データを受け取っていないので、再生するデータが枯渇し、第５フレームの圧縮動画データの再生終了時刻から後述する第６フレームの圧縮動画データのデータ送信終了時刻ｔ６’’迄の時間ΔＴにおいて再生が途切れる。
【００２５】
通信部では、通信プロトコルの再送処理により第６フレームの圧縮動画データを再度送信する。この再送信が成功し、第６フレームの圧縮動画データのデータ送信終了時刻ｔ６’’において、第６フレームの圧縮動画データが再生部３Ｂに届く。第６フレームの圧縮動画データが再生部３Ｂに届くと、再生部３Ｂは再生処理を再開する。
【００２６】
ところが、時間ΔＴにおいて通信が途絶えている間にも、録画部１Ａは一定周期（１／４秒）で第７フレーム以降の圧縮動画データを生成し、順次通信部に渡している。このため、通信部が送信待ちの圧縮動画データをネットワーク送信部１Ｂ内のフレームバッファメモリ（不図示）に蓄積することになり、高負荷状態になる。この高負荷状態は、通信部において蓄積されている送信待ちの圧縮動画データが無くなる（時刻ｔ１４’）まで続く。
【００２７】
録画部１Ａが１フレームの圧縮動画データを生成するために必要な処理時間よりも、通信部が１フレームの圧縮動画データをデータ送信するために必要な処理時間の方が短いのであれば（通常は短くなっている）、通信部において蓄積されている送信待ちの圧縮動画データがいずれ無くなり、通信は完全に復旧したことになる。なお、通信が完全に復旧した状態とは、録画部１Ａが生成した１フレームの圧縮動画データを通信部がリアルタイムに再生部３Ｂへ送ることができる状態をいう。また、録画部１Ａは、動的に変化する通信部の通信速度に応じて録画品質を変化させ、通信部の通信速度が遅い場合には圧縮動画データを生成する際の圧縮率を高くして１フレームのデータ量を少なくするようにしてもよい。これにより、通信部が高負荷状態になることを抑制でき、また、通信部が高負荷状態になったときでも通信の復旧を早めることができる。
【００２８】
再生部３Ｂは、再生再開後、第７フレーム以降の圧縮動画データを順次再生しているが、１フレームの圧縮動画データの再生時間は１／４秒に固定されており、速く再生することはできないので、結果的に、配信サーバー１側での事象に対するその事象に対応する再生クライアント３側での再生動画の遅延時間は、通信が途絶えていた時間分だけ拡大し、復旧しない。
【００２９】
なお、特許文献１では、放送映像データの送受信を何らかの理由（例えばオンデマンド映像データの割り込み送信）で中断した後に再開する場合、送信再開直後の部分からでも放送映像データを受信側が正しく復号、画面表示できる送受信システムを提案している。しかしながら、かかる送受信システムには、送受信を中断している間の放送映像データに対応する画面表示が完全にカットされてしまうという問題点がある。
【００３０】
また、特許文献２では、シーンチェンジなどにより予測誤差が急激に大きくなり、そのピクチャーの符号化データをそのまま伝送すると所定の伝送レートを超過してしまう場合、そのピクチャーの符号化データを伝送することなく、そのピクチャーをスキップするようにした動画像符号化装置（録画部）を提案している。しかしながら、かかる動画像符号化装置（録画部）は、当該動画像符号化装置（録画部）から出力されるデータを伝送する伝送路（通信部）が正常な状態であることを前提にして、上記「所定の伝送レート」を設定しているため、回線品質を保証した通信を用いたリアルタイムな動画配信でのリアルタイム性が損なわれることを抑制できないという問題点がある。
【００３１】
また、特許文献３では、動画像を高い圧縮率で効率よく送受信しつつ、通信エラーがあっても速やかに対処し得るようにするために、受信局内の復号器での復号処理において、キーＧＯＢ（Group of Block）についてエラー検出を行い、エラーが発見された場合にはキーＧＯＢの再送要求を送信局に送信する動画像送受信システムを提案している。しかしながら、かかる動画像送受信システムには、キーＧＯＢの再送によって動画像送受信のリアルタイム性が損なわれてしまうという問題点がある。
【００３２】
本発明は、上記の状況に鑑み、回線品質を保証した通信を用いたリアルタイムな動画配信でのリアルタイム性が損なわれることを抑制することができる動画再生装置、動画再生方法、動画再生プログラム、及び動画配信システムを提供することを目的とする。
【課題を解決するための手段】
【００３３】
上記目的を達成するために本発明に係る動画再生装置は、回線品質を保証するプロトコルを採用した通信部から送られてくる動画データを再生する動画再生装置であって、前記通信部から１フレームの動画データが届いた時点において再生中の動画データが有るか否かを判定する判定部と、前記判定部での判定結果が否でない期間内に前記通信部から届いた各フレームの動画データの少なくとも一部を間引く間引き処理部とを備える構成とする。
【００３４】
また、間引き処理が行われた後、最初に再生するフレームデータは差分フレームであれば前画面の情報がないため、特別な補間処理等を行わない限り、その再生が不可能となる。したがって、上記構成の動画再生装置において、前記間引き処理部が、前記判定部での判定結果が否でない期間内に前記通信部から届いた各フレームの動画データのうち、差分フレームについては全て間引くようにすることが望ましい。さらに、通信トラブル発生中の映像・音声又は映像を一切視聴することができなくなることを防止する観点から、前記間引き処理部が、前記判定部での判定結果が否でない期間内に前記通信部から届いた各フレームの動画データのうち、全画フレームについては全て間引かないようにしてもよい。
【００３５】
上記目的を達成するために本発明に係る動画再生方法は、回線品質を保証するプロトコルを採用した通信部から送られてくる動画データを再生する動画再生方法であって、前記通信部から１フレームの動画データが届いた時点において再生中の動画データが有るか否かを判定する判定ステップと、前記判定ステップでの判定結果が否でない期間内に前記通信部から届いた各フレームの動画データの少なくとも一部を間引く間引き処理ステップとを備えるようにする。
【００３６】
上記目的を達成するために本発明に係る動画再生プログラムは、コンピュータを、回線品質を保証するプロトコルを採用した通信部から送られてくる動画データを再生する動画再生装置として機能させるための動画再生プログラムであって、さらに、前記コンピュータを、前記通信部から１フレームの動画データが届いた時点において再生中の動画データが有るか否かを判定する判定手段、及び前記判定手段での判定結果が否でない期間内に前記通信部から届いた各フレームの動画データの少なくとも一部を間引く間引き処理手段として機能させるようにする。
【００３７】
上記目的を達成するために本発明に係る動画配信システムは、外部から受け取った映像信号・音声信号又は映像信号を動画データとして纏めて記録する録画部と、再生部と、前記録画部から受け取った動画データをネットワーク経由で前記再生部に送る通信部とを備え、前記通信部が回線品質を保証するプロトコルを採用した通信部であり、前記再生部が上記いずれかの構成の録画再生装置であるようにする。
【発明の効果】
【００３８】
本発明によると、通信部が高負荷状態になったと考えられるときに、動画再生装置に届いた動画データを間引くことができるので、録画部側での事象に対するその事象に対応する再生部側での再生動画の遅延時間を復旧することができる。したがって、回線品質を保証した通信を用いたリアルタイムな動画配信でのリアルタイム性が損なわれることを抑制することができる。
【図面の簡単な説明】
【００３９】
【図１】回線品質を保証した通信におけるリアルタイムな動画配信を行う動画配信システムの構成例を示す図である。
【図２】図１に示す動画配信システムの機能ブロック図である。
【図３】再生クライアントとして用いるパソコンの概略構成を示す図である。
【図４】通信部が正常な状態である場合におけるデータ処理例の様子を示す図である。
【図５】通信部が異常な状態である場合における従来のデータ処理例の様子を示す図である。
【図６】現フレームの圧縮動画データの再生終了時刻と次フレームの圧縮動画データのデータ送信終了時刻との関係を示す図である。
【図７】本発明に係る再生部の動作例を示すフローチャートである。
【図８】通信部が異常な状態である場合における本発明に係る動画配信システムでのデータ処理例の様子を示す図である。
【図９】図８に示すデータ処理例を実行した場合の再生部の挙動を示す図である。
【発明を実施するための形態】
【００４０】
本発明の実施形態について図面を参照して以下に説明する。本発明者等は、回線品質を保証した通信を用いたリアルタイムな動画配信でのリアルタイム性が損なわれることを抑制する手法について鋭意検討した結果、リアルタイム性が損なわれることを間引き処理を行うことによって抑制する手法に想到した。
【００４１】
間引き処理は、動画配信システムの録画部、通信部、及び再生部の３つの箇所それぞれで行うことが可能である。しかしながら、録画部で間引き処理を行う場合、録画部は通信部の状態によりその挙動を変える必要があり、録画部が通信部に依存してしまい録画部、通信部、及び再生部それぞれの独立性が損なわれるので、本発明では録画部で間引き処理を行わないことにした。
【００４２】
また、通信部で間引き処理を行う場合、通信部が意図的にデータを欠落させることになり、回線品質を保証する、すなわち通信でのデータの欠落を防ぐという本来の目的に反することになるので、本発明では通信部で間引き処理を行わないことにした。
【００４３】
上記の検討結果から、本発明では再生部で間引き処理を行うことにした。本発明に係る動画配信システムの構成例は図１に示す構成と同様である。そして、図１に示す動画配信システムの機能ブロック図は、図２のようになる。また、本実施形態では、再生クライアント３として図３に示すパソコンを用いている。
【００４４】
配信サーバー１内の録画部１Ａは請求項中の「録画部」の一例であり、配信サーバー１内のネットワーク送信部１Ｂとネットワーク２と再生クライアント３内のネットワーク３Ａとを含む部分は請求項中の「通信部」の一例であり、再生クライアント３内の再生部３Ｂは請求項中の「動画再生装置」、「コンピュータ」、及び「再生部」それぞれの一例である。なお、録画部１Ａの独立性は多少損なわれることになるが、録画部１Ａは、動的に変化する通信部の通信速度に応じて録画品質を変化させ、通信部の通信速度が遅い場合には圧縮動画データを生成する際の圧縮率を高くして１フレームのデータ量を少なくするようにしてもよい。従来の動画配信システムと本発明に係る動画配信システムとの相違点は、図３に示すパソコンのＲＯＭ１２に格納されている動画再生プログラムの内容が異なり、従来の動画配信システムの再生部３Ｂが間引き処理を行わないのに対して、本発明に係る動画配信システムの再生部３Ｂは間引き処理を行う点である。以下、本発明に係る動画配信システムの再生部３Ｂでの間引き処理について説明する。
【００４５】
＜間引きタイミング＞
間引き処理が必要となるのは、通信部が高負荷状態（図５参照）になったときである。しかし、再生部３Ｂは通信部と独立しているため、通信部の状態を知ることができない。
【００４６】
一方、再生部３Ｂは、自身が現在再生しているフレームの圧縮動画データの再生終了時刻ｔE（図６参照）を把握している。この再生終了時刻ｔEと次フレームの圧縮動画データが通信部から再生部３Ｂに届く時刻との関係は、図６（ａ）〜（ｃ）に示す３パターンが考えられる。
【００４７】
図６（ａ）に示す第１のパターンでは、現在再生しているフレームの圧縮動画データの再生終了時刻ｔEとほぼ同時に次フレームの圧縮動画データが再生部３Ｂに到着する。通信部が正常な状態である場合、このパターンになる。
【００４８】
図６（ｂ）に示す第２のパターンでは、現在再生しているフレームの圧縮動画データの再生終了時刻ｔEの後、しばらくして次フレームの圧縮動画データが再生部３Ｂに到着する。通信トラブルが発生し、通信部の通信速度が遅くなっている場合にこのパターンになる。
【００４９】
図６（ｂ）に示す第３のパターンでは、現在再生しているフレームの圧縮動画データの再生終了時刻ｔEより前に次フレームの圧縮動画データが再生部３Ｂに到着する。録画部１Ａは一定周期（１／４秒）で１フレームの圧縮動画データを生成し、再生部３Ｂはその周期で１フレームの圧縮動画データを再生している。現在再生しているフレームの圧縮動画データの再生終了時刻ｔEより前に次フレームの圧縮動画データが再生部３Ｂに到着するのは、以前に通信部の通信速度が遅くなり、現在それが復旧処理中であると考えられる。
【００５０】
図６（ａ）に示す第１のパターン及び図６（ｂ）に示す第２のパターンの場合、次フレームの圧縮動画データが再生部３Ｂに到着した時点において、再生部３Ｂには次フレームの圧縮動画データ以外に再生すべき圧縮動画データがないため、再生部３Ｂは、到着した次フレームの圧縮動画データを間引く事なく再生する。
【００５１】
これに対して、図６（ｃ）に示す第３のパターンの場合、到着した次フレームの圧縮動画データを、現在再生しているフレームの圧縮動画データに続けて再生すると、配信サーバー１側での事象に対するその事象に対応する再生クライアント３側での再生動画の遅延時間が拡大し続けるので、間引くようにする。つまり、間引き処理は、再生部３Ｂが圧縮動画データを再生中に（ただし、再生がほぼ終了している場合は上記第１のパターンに属するので除く。）、次フレームの圧縮動画データが再生部３Ｂに到着した場合に行うようにする。
【００５２】
＜間引き対象フレームデータ＞
１フレームの圧縮動画データ（フレームデータ）の種類には、１画面分の全ての情報が格納された全画フレームと、前フレームからの差分情報だけを持った差分フレームとがある。ちなみに、ＭＰＥＧ４（Moving Picture Experts Group ４）では、全画フレームをＩフレームと称し、差分フレームをＰフレームと称している。
【００５３】
通信トラブルが長い間発生していると、通信部には多くのフレームデータが蓄積される。通信トラブルが復旧すると、通信部は一気にフレームデータを再生部３Ｂに届けるため、再生部３Ｂは１つのフレームデータ再生中に、複数のフレームデータを受け取る事がある。
【００５４】
配信サーバー１側での事象に対するその事象に対応する再生クライアント３側での再生動画の遅延時間の復旧を速くするためには、基本的に、再生部３Ｂは、再生中に届いたフレームデータを全て間引く必要がある。しかし、全てのフレームデータを間引いてしまうと、通信トラブル発生中の動画データを全て再生し無くなってしまうため、通信トラブル発生中の映像・音声又は映像を一切視聴することができなくなり、通信インフラが不安定な状況下では、再生動画の停止が頻繁に起こり視聴しにくい再生となってしまう。
【００５５】
このため、通信トラブル中の映像を少し残して再生する事が望ましい。これにより、配信サーバー１側での事象に対するその事象に対応する再生クライアント３側での再生動画の遅延時間の復旧に時間はかかるが（残したフレームの再生時間分復旧が遅れるが）、視聴者から見れば、 通信トラブル中の映像・音声又は映像を“早送り”の如く視聴する事ができるようにする。
【００５６】
なお、差分フレームから再開する事は前画面の情報がないため不可能である。したがって、前述した間引き処理が行われた後、最初に再生するフレームデータは全画フレームでなければならない。
【００５７】
＜間引き処理の手順＞
上記の考察の結果、本実施形態では、再生部３Ｂが以下のような手順で間引き処理を行うようにする。
【００５８】
再生部３Ｂは、間引き状態でない場合に、次のようなデータ処理を実行する。
【００５９】
フレームデータの再生終了時刻とほぼ同時に、すなわちフレームデータの再生終了時刻±所定時間（フレームデータの再生終了時刻の前後で所定時間が同じであってもよく異なっていてもよい。）の期間内に、再生部３Ｂにフレームデータが届いた場合（図６（ａ）参照）、再生部３Ｂは届いたフレームデータを再生する。
【００６０】
再生部３Ｂにフレームデータが届いた時点において、再生中のフレームデータがない場合（図６（ｂ）参照）、再生部３Ｂは届いたフレームデータを再生する。
【００６１】
再生部３Ｂにフレームデータが届いた時点において、再生中のフレームデータがある場合（図６（ｃ）参照）、届いたフレームデータが差分フレームであれば届いたフレームデータを間引き、それ以降間引き状態に移行し、届いたフレームデータが全画フレームであれば届いたフレームデータを再生する。
【００６２】
一方、再生部３Ｂは、間引き状態である場合に、次のようなデータ処理を実行する。
【００６３】
再生部３Ｂは、全画フレームを受信するまでの間、全ての差分フレームを間引き、間引き状態を継続する。そして、全画フレームを受信すると、再生部３Ｂは、全画フレームを間引かずに、再生中のフレームがなければ間引き状態から非間引き状態に移行し、再生中のフレームが有れば間引き状態を継続する。
【００６４】
したがって、再生部３Ｂは、図７に示すフローチャートのような動作を行う。ステップＳ１０において、再生部３Ｂは、通信部から渡されるフレームデータを受信し、受信が完了すると、ステップＳ２０に移行する。ステップＳ２０において、再生部３Ｂは、自身の状態が間引き状態であるか否かを判定する。なお、間引き状態であるか否かの判定や間引き状態、非間引き状態間の移行には、例えば間引き状態であるか否かを示す状態フラグを利用するとよい。
【００６５】
ステップＳ２０での判定の結果、間引き状態でなければ（ステップＳ２０のＮＯ）、ステップＳ１０で受信したフレームデータが全画フレームであるか否かを判定する（ステップＳ３０）。全画フレームであれば（ステップＳ３０のＹＥＳ）、再生部３Ｂは、ステップＳ１０で受信したフレームデータの再生を開始し（ステップＳ１１０）、その後ステップＳ１０に移行し、次のフレームデータを受信する。全画フレームでなければ（ステップＳ３０のＮＯ）、再生部３Ｂは、再生中のフレームデータが有るか否かを判定する（ステップＳ４０）。再生中のフレームデータがなければ（ステップＳ４０のＮＯ）、再生部３Ｂは、ステップＳ１０で受信したフレームデータの再生を開始し（ステップＳ１１０）、その後ステップＳ１０に移行し、次のフレームデータを受信する。一方、再生中のフレームデータが有れば（ステップＳ４０のＹＥＳ）、再生部３Ｂは、ステップＳ１０で受信したフレームデータを廃棄（間引き）し（ステップＳ５０）、自身の状態を非間引き状態から間引き状態に移行し（ステップＳ６０）、その後ステップＳ１０に移行し、次のフレームデータを受信する。
【００６６】
また、ステップＳ２０での判定の結果、間引き状態であれば（ステップＳ２０のＹＥＳ）、再生部３Ｂは、ステップＳ１０で受信したフレームデータが全画フレームであるか否かを判定する（ステップＳ７０）。全画フレームでなく差分フレームであれば（ステップＳ７０のＮＯ）、ステップＳ１０で受信したフレームデータを廃棄（間引き）し（ステップＳ８０）、自身の状態を間引き状態に保ったままステップＳ１０に移行し、次のフレームデータを受信する。一方、全画フレームであれば（ステップＳ７０のＹＥＳ）、再生部３Ｂは、再生中のフレームデータが有るか否かを判定する（ステップＳ９０）。再生中のフレームデータが有れば（ステップＳ９０のＹＥＳ）、再生部３Ｂは、自身の状態を間引き状態に保ったまま、ステップＳ１０で受信したフレームデータの再生を開始し（ステップＳ１１０）、その後ステップＳ１０に移行し、次のフレームデータを受信する。一方、再生中のフレームデータがなければ（ステップＳ９０のＮＯ）、再生部３Ｂは、自身の状態を間引き状態から非間引き状態に移行し（ステップＳ１００）、ステップＳ１０で受信したフレームデータの再生を開始し（ステップＳ１１０）、その後ステップＳ１０に移行し、次のフレームデータを受信する。
【００６７】
なお、ステップＳ４０及びステップＳ９０での再生中のフレームデータがないとの判定には、フレームデータの再生終了時刻とほぼ同時にステップＳ１０での受信が完了する場合も含まれるものとする。再生部３Ｂは、ステップＳ４０及びステップＳ９０の処理を行うので、請求項中の「判定部」を備えていることになる。また、再生部３Ｂは、ステップＳ５０及びステップＳ８０の処理を行うので、請求項中の「間引き処理部」を備えていることになる。
【００６８】
再生部３Ｂが上記のような動作をすることにより、通信部が正常な状態である場合における本発明に係る動画配信システムの動作は、通信部が正常な状態である場合における従来の動画配信システムの動作と同様になり、その場合のデータ処理例の様子は図４に示すようになる。
【００６９】
一方、再生部３Ｂが上記のような動作をすることにより、通信部が正常な状態でない場合における本発明に係る動画配信システムの動作は、通信部が正常な状態でない場合における従来の動画配信システムの動作（図５参照）と異なる。
【００７０】
ここで、本発明に係る動画配信システムにおいて、第６フレームの圧縮動画データのデータ送信が一旦失敗し、再送で復旧した場合について説明する。
【００７１】
図８は、第６フレームの圧縮動画データのデータ送信が一旦失敗し、再送で復旧した場合における本発明に係る動画配信システムでのデータ処理例の様子を示す図である。なお、図８において、第１，５，９，１３，１７フレームの圧縮動画データは全画フレームであり、それ以外のフレームデータは差分フレームである。
【００７２】
ノイズ等の要因により、第６フレームの圧縮動画データのデータ送信に失敗する。この場合、再生部３Ｂは、第５フレームの圧縮動画データを再生し終えた時に、第６フレームの圧縮動画データを受け取っていないので、再生するデータが枯渇し、第５フレームの圧縮動画データの再生終了時刻から後述する第６フレームの圧縮動画データのデータ送信終了時刻ｔ６’’迄の時間ΔＴにおいて再生が途切れる。
【００７３】
通信部では、通信プロトコルの再送処理により第６フレームの圧縮動画データを再度送信する。この再送信が成功し、第６フレームの圧縮動画データのデータ送信終了時刻ｔ６’’において、第６フレームの圧縮動画データが再生部３Ｂに届く。第６フレームの圧縮動画データが再生部３Ｂに届くと、再生部３Ｂは再生処理を再開する。
【００７４】
ところが、時間ΔＴにおいて通信が途絶えている間にも、録画部１Ａは一定周期（１／４秒）で第７フレーム以降の圧縮動画データを生成し、順次通信部に渡している。このため、通信部が送信待ちの圧縮動画データをネットワーク送信部１Ｂ内のフレームバッファメモリ（不図示）に蓄積することになり、高負荷状態になる。この高負荷状態は、通信部において蓄積されている送信待ちの圧縮動画データが無くなる（時刻ｔ１４’）まで続く。逆に言えば、時刻ｔ１４’において、通信は完全に復旧する。また、時刻ｔ１４’において、再生も完全復旧する。
【００７５】
図８に示すデータ処理例を実行した場合の再生部３Ｂの挙動をまとめると、図９に示すようになる。
【００７６】
以上、本発明に係る実施形態について説明したが、本発明の範囲はこれに限定されるものではなく、発明の主旨を逸脱しない範囲で種々の変更を加えて実行することができる。例えば、上述した実施形態での間引き処理を第１のモードとし、再生中に届いたフレームデータを全て間引く間引き処理を第２のモードとし、上述した実施形態のように全画フレームを全く間引かないのではなく、再生中に届いた差分フレームを全て間引き且つ再生中に届いた全画フレームを所定数おきに間引く間引き処理を第３のモードとし、上記第１〜３のモードの少なくとも２つを有し、図３に示すパソコンの操作部１４を操作によってモードの選択を可能にしてもよい。
【符号の説明】
【００７７】
１ 配信サーバー
１Ａ 録画部
１Ｂ ネットワーク送信部（通信部の一例の一部）
２ ネットワーク（通信部の一例の一部）
３ 再生クライアント
３Ａ ネットワーク受信部（通信部の一例の一部）
３Ｂ 再生部（動画再生装置の一例）
４ カメラ
５ マイク
１１ ＣＰＵ
１２ ＲＯＭ
１３ ＲＡＭ
１４ 操作部
１５ 表示部
１６ ネットワークインターフェース
１７ 記録メディアインターフェース
１８ バス
【特許請求の範囲】
【請求項１】
回線品質を保証するプロトコルを採用した通信部から送られてくる動画データを再生する動画再生装置であって、
前記通信部から１フレームの動画データが届いた時点において再生中の動画データが有るか否かを判定する判定部と、
前記判定部での判定結果が否でない期間内に前記通信部から届いた各フレームの動画データの少なくとも一部を間引く間引き処理部とを備えることを特徴とする動画再生装置。
【請求項２】
前記間引き処理部が、
前記判定部での判定結果が否でない期間内に前記通信部から届いた各フレームの動画データのうち、差分フレームについては全て間引くことを特徴とする請求項１に記載の動画再生装置。
【請求項３】
前記間引き処理部が、
前記判定部での判定結果が否でない期間内に前記通信部から届いた各フレームの動画データのうち、全画フレームについては全て間引かないことを特徴とする請求項２に記載の動画再生装置。
【請求項４】
回線品質を保証するプロトコルを採用した通信部から送られてくる動画データを再生する動画再生方法であって、
前記通信部から１フレームの動画データが届いた時点において再生中の動画データが有るか否かを判定する判定ステップと、
前記判定ステップでの判定結果が否でない期間内に前記通信部から届いた各フレームの動画データの少なくとも一部を間引く間引き処理ステップとを備えることを特徴とする動画再生方法。
【請求項５】
コンピュータを、回線品質を保証するプロトコルを採用した通信部から送られてくる動画データを再生する動画再生装置として機能させるための動画再生プログラムであって、
さらに、前記コンピュータを、
前記通信部から１フレームの動画データが届いた時点において再生中の動画データが有るか否かを判定する判定手段、及び
前記判定手段での判定結果が否でない期間内に前記通信部から届いた各フレームの動画データの少なくとも一部を間引く間引き処理手段として機能させるための動画再生プログラム。
【請求項６】
外部から受け取った映像信号・音声信号又は映像信号を動画データとして纏めて記録する録画部と、
再生部と、
前記録画部から受け取った動画データをネットワーク経由で前記再生部に送る通信部とを備え、
前記通信部が回線品質を保証するプロトコルを採用した通信部であり、
前記再生部が請求項１〜３のいずれか１項に記載の録画再生装置であることを特徴とする動画配信システム。
【請求項１】
回線品質を保証するプロトコルを採用した通信部から送られてくる動画データを再生する動画再生装置であって、
前記通信部から１フレームの動画データが届いた時点において再生中の動画データが有るか否かを判定する判定部と、
前記判定部での判定結果が否でない期間内に前記通信部から届いた各フレームの動画データの少なくとも一部を間引く間引き処理部とを備えることを特徴とする動画再生装置。
【請求項２】
前記間引き処理部が、
前記判定部での判定結果が否でない期間内に前記通信部から届いた各フレームの動画データのうち、差分フレームについては全て間引くことを特徴とする請求項１に記載の動画再生装置。
【請求項３】
前記間引き処理部が、
前記判定部での判定結果が否でない期間内に前記通信部から届いた各フレームの動画データのうち、全画フレームについては全て間引かないことを特徴とする請求項２に記載の動画再生装置。
【請求項４】
回線品質を保証するプロトコルを採用した通信部から送られてくる動画データを再生する動画再生方法であって、
前記通信部から１フレームの動画データが届いた時点において再生中の動画データが有るか否かを判定する判定ステップと、
前記判定ステップでの判定結果が否でない期間内に前記通信部から届いた各フレームの動画データの少なくとも一部を間引く間引き処理ステップとを備えることを特徴とする動画再生方法。
【請求項５】
コンピュータを、回線品質を保証するプロトコルを採用した通信部から送られてくる動画データを再生する動画再生装置として機能させるための動画再生プログラムであって、
さらに、前記コンピュータを、
前記通信部から１フレームの動画データが届いた時点において再生中の動画データが有るか否かを判定する判定手段、及び
前記判定手段での判定結果が否でない期間内に前記通信部から届いた各フレームの動画データの少なくとも一部を間引く間引き処理手段として機能させるための動画再生プログラム。
【請求項６】
外部から受け取った映像信号・音声信号又は映像信号を動画データとして纏めて記録する録画部と、
再生部と、
前記録画部から受け取った動画データをネットワーク経由で前記再生部に送る通信部とを備え、
前記通信部が回線品質を保証するプロトコルを採用した通信部であり、
前記再生部が請求項１〜３のいずれか１項に記載の録画再生装置であることを特徴とする動画配信システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【公開番号】特開２０１１−４０４５（Ｐ２０１１−４０４５Ａ）
【公開日】平成２３年１月６日（２０１１．１．６）
【国際特許分類】
【出願番号】特願２００９−１４４２３０（Ｐ２００９−１４４２３０）
【出願日】平成２１年６月１７日（２００９．６．１７）
【出願人】（０００１３４１０９）株式会社デジタル (224)
【Ｆターム（参考）】
【公開日】平成２３年１月６日（２０１１．１．６）
【国際特許分類】
【出願日】平成２１年６月１７日（２００９．６．１７）
【出願人】（０００１３４１０９）株式会社デジタル (224)
【Ｆターム（参考）】
[ Back to top ]