(57)【要約】【課題】構成するパケットが失われた画像フレームを、サーバ装置から送信されたクライアント装置は、その画像フレームを全く再生できない。【解決手段】クライアント装置から受信したエラー通知パケットと、該エラー通知パケットを受信するまでに送信したパケット量に基づいて伝送帯域を算出し、その伝送帯域に収まるようなパケットの送信間隔を算出し、記憶部に格納するステップ（Ｓ２０２）と、画像フレームを送信する前に、後続する該送信すべき画像フレームの送信タイミングが、先行する画像フレームの送信タイミングに重なるか否かをチェックする（Ｓ３０１）。それらの画像フレームの送信タイミングが重ならない場合、前記パケットの送信間隔に従って、後続する画像フレームのパケットを送信する（Ｓ３０２）。それらの画像フレームの送信タイミングが重なる場合、後続する画像フレームを送信せずに、該後続する画像フレームを破棄する（Ｓ３０３）。【選択図】図１
2009094847.tif 000002
【特許請求の範囲】
【請求項１】
記憶部，通信部，撮影された動画データを入力する入力部を備え、
該入力部によって入力された動画データを構成する画像フレームの撮影順に応じ該画像フレームを分割したパケットを識別する通番を割り振ってパケットに分割し、
送信したパケット量を該記憶部に格納し、
それらのパケットを通信回線を介してクライアント装置に送信するサーバ装置
に使用する動画通信処理方法であって、
前記クライアント装置から、欠落したパケットの通番を含むパケット欠落通知を有するエラー通知パケットを前記通信部を使って受信し、
該エラー通知パケットと、該エラー通知パケットを受信するまでにサーバ装置自体の送信したパケット量に基づいて伝送帯域を算出し、その伝送帯域に収まるようなパケットの送信間隔を算出し、該算出したパケットの送信間隔を前記記憶部に格納するステップと、
画像フレームを送信する前に、後続する該送信すべき画像フレームの送信タイミングが、先行する画像フレームの送信タイミングに重なるか否かをチェックするステップと、
後続する画像フレームの送信タイミングが先行する画像フレームの送信タイミングに重ならない場合、前記記憶部に格納されたパケットの送信間隔に従って、送信間隔を開けて、後続する画像フレームのパケットを前記通信部を使って送信するステップと、
後続する画像フレームの送信タイミングが先行する画像フレームの送信タイミングに重なってしまう場合、後続する画像フレームを送信せずに、該後続する画像フレームを破棄するステップと、
を有することを特徴とする動画通信処理方法。
【請求項２】
請求項１に記載の動画通信処理方法を、コンピュータで実行可能なコンピュータプログラムとして記述したことを特徴とする動画通信処理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、動画像通信技術に関するものである。
【背景技術】
【０００２】
ストリーミングサーバ装置（以下、単にサーバという）とストリーミングクライアント装置（以下、単にクライアントという）がＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）で接続されており、サーバから動画データ（以下、単に動画という）における画像データ（例えば、画像フレーム）をＬＡＮ経由で送信し、クライアントで受信画像を再生する画像サービスシステム（例えば、特許文献１参照）が知られている。
【０００３】
ここで、上述のような画像サービスシステムの構成の一例を図３に基づいて説明する。図３中の画像サービスシステムにおけるサーバ１には、静止画や動画を撮影する撮影装置（例えば、ビデオカメラ）２が接続されている。撮影装置２によって撮影された画像データをサーバ１がネットワーク１００を介してクライアント３に送信する。そして、クライアント３は、その送信された画像データを再生し、表示装置（例えば、ディスプレイ装置）４を使って表示する。
【０００４】
なお、サーバ１及びクライアント３は、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）など制御部（図示省略），メモリやハードディスクドライブ装置などを含む記憶部（図示省略），ネットワークインタフェース装置（図示省略）を含む通信部を備えているものとする。サーバ１及びクライアント３は、例えば、コンピュータと考えてよい。また、サーバ１は、撮影された動画もしくは静止画データを入力する入力部（例えば、前記記憶部に一旦格納された動画を入力する入力部や撮影装置から入力する入力部など；図示省略）を備える。
【０００５】
また、サーバ１におけるストリーミング方式は、静止画像（ＪＰＥＧ（Ｊｏｉｎｔ  Ｐｈｏｔｏｇｒａｐｈｉｃ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ）画像フレーム）を１秒間に３０枚送信することで、動画（あるいは準動画）として見えるモーションＪＰＥＧとする。
【０００６】
一般的に、１枚のＪＰＥＧ画像フレーム（以下、画像フレームという）のデータサイズはＬＡＮの１パケットより大きくなるため、複数パケットに分割して送信する必要がある。画像フレームを複数パケットに分割する様子を図４に基づいて説明する。例えば、図４中の約５０ｋＢｙｔｅ（キロバイト）の画像フレームＦAは、１パケット当たり１５００Ｂｙｔｅ（バイト）のパケット群ＰAに分割して送信される。同様に、画像フレームＦBはパケット群ＰBに、画像フレームＦCはパケット群ＰCに分割して送信される。また、撮影装置２による画像フレームの生成間隔は、例えば、３３ｍｓ（ミリセコンド）である。さらに、パケットの送信間隔は、予め設定された値に従う。
【０００７】
また、パケットは、そのパケットのヘッダ部分に、画像フレームの撮影された順（撮影順）に応じ該画像フレームを分割したパケットを識別する通番を割り振って（あるいは、パケットに埋め込んで）分割されている。その通番は、例えば、画像フレーム毎の撮影された順番を示す番号と、その画像フレームを分割したパケット毎の番号と、を含むものである。より具体的に、図４に基づいて説明すると、画像フレームＦAは、通番Ａ1〜Ａnを割り振られたパケットに分割される。この通番Ａ1〜Ａnでは、「Ａ」が画像フレーム毎の番号、下付き添え字「１」〜「ｎ」が分割パケット毎の番号になる。
【０００８】
このため、クライアント３では、分割された全てのパケット（例えば、パケット群ＰA）が到着した時点で、画像フレーム（例えば、画像フレームＦA）を通番に従って構成して画像として再生する。すなわち、１フレームの画像データは、複数のＬＡＮにおけるパケット（あるいは、ＬＡＮフレーム）で構成されることになる。
【特許文献１】特開平１０−４２１８５号公報（段落［００１４］〜［００５０］等）。
【発明の開示】
【発明が解決しようとする課題】
【０００９】
上述のような画像サービスシステムでは、伝送帯域が十分でなく、さらに、パケットが欠落した状態（即ち、パケット欠落）が発生するようなＬＡＮ環境において、１画像フレームを構成するパケットが１つでも失われる場合、クライアントでは、その画像フレームを再生できなくなる。
【００１０】
さらに、画像フレームにおける僅かなパケット欠落の発生であっても、各画像フレームに均一に発生してしまうと、クライアントでは動画を全く再生できなくなってしまう。
【００１１】
本発明は、前記課題に基づいてなされたものであって、上述のようなシステムにおけるサーバにおいて、パケット欠落が発生しても、クライアントが再生できるように、動画における最低限の画像を送信する動画通信処理方法及び動画通信処理プログラムを提供することにある。
【課題を解決するための手段】
【００１２】
前記課題の解決を図るために、請求項１記載の発明は、記憶部，通信部，撮影された動画データを入力する入力部を備え、該入力部によって入力された動画データを構成する画像フレームの撮影順に応じ該画像フレームを分割したパケットを識別する通番を割り振ってパケットに分割し、送信したパケット量を該記憶部に格納し、それらのパケットを通信回線を介してクライアント装置に送信するサーバ装置に使用する動画通信処理方法であって、前記クライアント装置から、欠落したパケットの通番を含むパケット欠落通知を有するエラー通知パケットを前記通信部を使って受信し、該エラー通知パケットと、該エラー通知パケットを受信するまでにサーバ装置自体の送信したパケット量に基づいて伝送帯域を算出し、その伝送帯域に収まるようなパケットの送信間隔を算出し、該算出したパケットの送信間隔を前記記憶部に格納するステップと、画像フレームを送信する前に、後続する該送信すべき画像フレームの送信タイミングが、先行する画像フレームの送信タイミングに重なるか否かをチェックするステップと、後続する画像フレームの送信タイミングが先行する画像フレームの送信タイミングに重ならない場合、前記記憶部に格納されたパケットの送信間隔に従って、送信間隔を開けて、後続する画像フレームのパケットを前記通信部を使って送信するステップと、後続する画像フレームの送信タイミングが先行する画像フレームの送信タイミングに重なってしまう場合、後続する画像フレームを送信せずに、該後続する画像フレームを破棄するステップと、を有することを特徴とする。
【００１３】
請求項２記載の発明は、動画通信処理プログラムであって、請求項１に記載の動画通信処理方法を、コンピュータで実行可能なコンピュータプログラムとして記述したことを特徴とする。
【００１４】
前記請求項１の発明によれば、パケット欠落に基づいて、動画における画像フレームを間引いて送信できる。
【００１５】
前記請求項２の発明によれば、請求項１に記載の動画通信処理方法をコンピュータプログラムとして記載できる。
【発明の効果】
【００１６】
以上示したように請求項１の発明によれば、伝送帯域の狭い伝送路において、パケット欠落が発生しても、動画における最低限の画像をクライアント装置に送信できる。さらに、クライアント装置が、その動画を全く再生できない事態を回避できる。
【００１７】
請求項２の発明によれば、請求項１に記載の動画通信処理方法を実装したコンピュータプログラムを提供できる。
【００１８】
これらを以って動画像通信技術分野に貢献できる。
【発明を実施するための最良の形態】
【００１９】
以下、本発明の実施形態における画像サービスシステムの動画通信処理方法を図面等に基づいて詳細に説明する。なお、本実施形態の装置構成は、図３と同じものを採用する。
【００２０】
本実施形態における画像サービスシステムでは、画像フレームを、撮影装置（例えば、ビデオカメラ）の仕様によって定期的（例えば、３３ｍｓ（ミリセコンド）間隔）に生成し、伝送帯域が十分広い場合、先行する画像フレームの送信は、後続する画像フレームが生成されるまでの間に送信しきってしまうことを理想的な状態と想定している。しかし、実際には、画像フレームのパケットの送信間隔が間延びしてしまうため、本実施形態における画像サービスシステムにおけるサーバは、先行する画像フレームのパケットの送信間隔が間延びして、後続する画像フレームの生成まで間に合わなかった場合に、その後続する画像フレームを廃棄して送信を行わないようにする動画通信処理方法を採用している。
【００２１】
本実施形態における動画通信処理方法を図１，図２に基づいて説明する。以下の説明で、図３と同じ符号のものの説明は省略する。なお、図１はサーバにおける動画通信処理方法を示すフローチャートであって、図１（Ａ）はサーバにおけるメイン処理ループを示すフローチャート、図１（Ｂ）はサーバにおけるエラー通知パケット処理を示すフローチャート、図１（Ｃ）はサーバにおける画像フレーム送信処理を示すフローチャート、図２はサーバにおける動画送信処理方法の概念図である。
【００２２】
まず、クライアント３は、受信したパケットをチェックし、パケット欠落（通番の抜け）を検出すると、ただちに、パケット欠落通知（例えば、欠落したパケットの通番を含む通知）を含むエラー通知パケットをサーバ１へ送信する。
【００２３】
そして、サーバ１は、パケット欠落通知を含むエラー通知パケットを通信部を使って受信した（Ｓ１０１，Ｓ１０２，Ｓ１０３，Ｓ２０１）場合、図２のように、割り当てられた伝送帯域に合わせてパケットの送信間隔Ｔbを適切に延ばし、１画像フレームを確実にクライアント３へ伝送するようにする（Ｓ２０２）。なお、図１中のステップＳ１０４は、エラー通知パケットでないパケットに関する処理のため、説明を省略する。
【００２４】
より具体的には、サーバ１は、クライアント３から通知されたエラー通知パケット（例えば、該エラー通知パケットに含まれる欠落したパケットの通番）とそのエラー通知パケットが受信されるまでにサーバ１自体の送信したパケット量に基づいて伝送帯域を算出し、その伝送帯域に収まるようなパケットの送信間隔Ｔbを算出し、該送信間隔Ｔbを記憶部の所定領域に格納する。なお、サーバ１自体の送信したパケット量は、パケット送信毎に更新され、前記記憶部に格納されるものとする。
【００２５】
なお、図１中のステップＳ２０３は、パケット欠落通知を含まない他のエラー通知パケットに関する処理のため、説明を省略する。
【００２６】
また、サーバ１は、例えば、新たな画像フレーム（即ち、後続する画像フレーム）の入力によって画像フレームを送信するイベントが発生し（Ｓ１０５，Ｓ１０６）、その画像フレーム送信前に、後続する画像フレームの送信タイミングが、先行する画像フレームの送信タイミング（あるいは、送信間隔）に重なってしまう（即ち、先行する画像フレームが送信中）か否かをチェックする（Ｓ３０１）。後続する画像フレームの送信タイミングが先行する画像フレームの送信タイミングに重なってしまう場合、ステップＳ３０３へ進む。後続する画像フレームの送信タイミングが先行する画像フレームの送信タイミングに重ならない場合、ステップＳ３０２へ進む。
【００２７】
ステップＳ３０２では、前記所定領域に格納されたパケットの送信間隔Ｔbに従って、送信間隔を開けて、送信すべき画像フレームのパケットを通信部を使って送信する。
【００２８】
ステップＳ３０３では、後続する画像フレームを送信せずに、破棄する。例えば、図２中のように、先行する画像フレームＦAのパケットの送信間隔Ｔbを延ばすと、後続する画像フレームＦBの送信タイミングに重なってしまうため、その画像フレームＦBを送信せずに、該画像フレームＦBを廃棄する。従って、図２中では、画像フレームＦAの次に送信すべき画像フレームは画像フレームＦcとなる。
【００２９】
なお、本実施形態の動画通信処理方法における手順をコンピュータのプログラムで構成し、そのプログラムをコンピュータに実行させることができることは言うまでもない。
【００３０】
さらに、上述の動画通信処理方法を記述したコンピュータプログラムを、該動画通信処理方法に必要とされる入出力データを格納したメモリや外部記憶装置等にアクセスするように実装してもよい。
【００３１】
以上のように、本実施形態によれば、ストリーミングにおける画像フレームが間引かれることになり、３０画像フレーム毎秒の再生を達成できなくなるため、動画の再生のなめらかさが損なわれるが、まったく再生できない事態を回避できる。
【００３２】
以上、本発明において、記載された具体例に対してのみ詳細に説明したが、本発明の技術思想の範囲で多彩な変形および修正が可能であることは、当業者にとって明白なことであり、このような変形および修正が特許請求の範囲に属することは当然のことである。
【００３３】
例えば、本実施形態では、ネットワークを介して通信を行っているが、一般的な通信回線（例えば、電話回線）であっても良い。
【００３４】
また、本実施形態は、モーションＪＰＥＧを対象とするだけでなく、画像フレーム毎に送信する形態であれば、どんなものでも適応可能である。
【図面の簡単な説明】
【００３５】
【図１】本実施形態における動画通信処理方法を示すフローチャートであって、図１（Ａ）はストリーミングサーバ装置におけるメイン処理ループを示すフローチャート、図１（Ｂ）はストリーミングサーバ装置におけるエラー通知パケット処理を示すフローチャート、図１（Ｃ）はストリーミングサーバ装置における画像フレーム送信処理を示すフローチャート。
【図２】ストリーミングサーバ装置における動画送信処理方法の概念図。
【図３】一般的な画像サービスシステムの一例を示す図。
【図４】画像フレームを複数パケットに分割する様子を示す概念図。
【符号の説明】
【００３６】
１…ストリーミングサーバ
２…撮影装置
３…ストリーミングクライアント
４…表示装置
１００…ネットワーク
ＦA，ＦB，ＦC…画像フレーム
ＰA，ＰB，ＰC…パケット群
Ａ1〜Ａ3，Ａn，Ｂ1〜Ｂ3，Ｂn，Ｃ1〜Ｃ3，Ｃn…パケット
Ｔb…パケットの送信間隔
【図１】
2009094847.tif 000003
【図２】
2009094847.tif 000004
【図３】
2009094847.tif 000005
【図４】
2009094847.tif 000006