"複数のデータブロックが蓄積されるバッファと、前記データブロックを送信するため、前記バッファから前記データブロックを読み出すバッファ制御部と、前記データブロックの送信中に前記データブロックが前記バッファから廃棄された場合に、廃棄により送信できなかったデータブロックの部分に代えてダミーデータを送信する送信部と、を備える、通信装置。前記データブロックの送信中に前記データブロックが前記バッファから廃棄された場合に、廃棄により送信できなかったデータブロックの前記部分に相当するダミーデータを生成するダミーデータ生成部を備え、前記送信部は、前記バッファから読み出された前記データブロックを送信するとともに、前記ダミーデータが生成された場合は、廃棄により送信できなかったデータブロックの前記部分に代えて前記ダミーデータを送信する、請求項1に記載の通信装置。前記データはMPEG2-TS形式であり、所定数のTSパケットが前記データブロックを構成し、前記ダミーデータ生成部は、前記データブロックの送信中に前記データブロックが廃棄された場合は、途中で分断されたTSパケットの未送信分に相当するデータと、未送信のTSパケットとを含む前記ダミーデータを生成する、請求項2に記載の通信装置。前記データはMP4形式であり、MOOFが前記データブロックを構成し、前記ダミーデータ生成部は、前記データブロックの送信中に前記データブロックが廃棄された場合は、前記MOOFの未送信分に相当するデータを前記ダミーデータとして生成する、請求項2に記載の通信装置。複数のデータブロックが蓄積されるバッファと、送信要求に応じて前記データブロックを送信するため、前記バッファから前記データブロックを読み出すバッファ制御部と、前記データブロックの送信中に前記データブロックが前記バッファから廃棄された場合に、廃棄により送信できなかったデータブロックの部分に代えてダミーデータを送信する送信部と、を備える、通信装置と、前記送信要求を前記送信装置に送信し、前記送信部から送信された前記データブロック及び前記ダミーデータを受信する受信装置と、を備える、通信システム。複数のデータブロックが蓄積されたバッファから、前記データブロックを送信するため、前記データブロックを読み出すことと、前記データブロックの送信中に前記データブロックが前記バッファから廃棄された場合に、廃棄により送信できなかったデータブロックの部分に代えてダミーデータを送信することと、を備える、通信方法。複数のデータブロックが蓄積されたバッファから、前記データブロックを送信するため、前記データブロックを読み出す手段、前記データブロックの送信中に前記データブロックが前記バッファから廃棄された場合に、廃棄により送信できなかったデータブロックの部分に代えてダミーデータを送信する手段、としてコンピュータを機能させるためのプログラム。上記のアダプティブストリーミングのシステムでは、配信サーバは、複数のレートでエンコードしたコンテンツを、更にそれぞれを断片化したファイルとして用意する。クライアントは、配信サーバとの間のスループットに適したビットレートの断片ファイルをダウンロードすることで、配信中にスループットの変化に追従できる。しかしながら、従来の技術は、十分なバッファを持つ大規模なサーバから送信することを前提にしているので、バッファ容量が限界に達した場合に、送信機側でデータが破棄されることは想定していない。一方、アダプティブストリーミング配信を、組み込み機器で、しかもライブ映像に適用しようとした場合、バッファ容量が小さいため、バッファに蓄積されるデータ量が限界に達した場合に、送信中の断片化されたデータが破棄されてしまうことが想定される。この場合、送信側はHTTPのセッションを切断してしまい、通信が途絶してしまう可能性がある。パケットロスやジッタによるエラーを回避するため、上記特許文献1に記載されているような、受信側でバッファリングすることでジッタを吸収する技術があるが、これらの技術は、ジッタを吸収しきれなかったものに対しての想定はしていない。そこで、送信側のバッファで送信中のデータが破棄された場合においても、通信を継続できる仕組みが求められていた。本開示によれば、複数のデータブロックが蓄積されるバッファと、前記データブロックを送信するため、前記バッファから前記データブロックを読み出すバッファ制御部と、前記データブロックの送信中に前記データブロックが前記バッファから廃棄された場合に、廃棄により送信できなかったデータブロックの部分に代えてダミーデータを送信する送信部と、を備える、通信装置が提供される。また、前記データブロックの送信中に前記データブロックが前記バッファから廃棄された場合に、廃棄により送信できなかったデータブロックの部分に相当するダミーデータを生成するダミーデータ生成部を備え、前記送信部は、前記バッファから読み出された前記データブロックを送信するとともに、前記ダミーデータが生成された場合は、廃棄により送信できなかったデータブロックの前記部分に代えて前記ダミーデータを送信するものであってもよい。また、前記データはMPEG2-TS形式であり、所定数のTSパケットが前記データブロックを構成し、前記ダミーデータ生成部は、前記データブロックの送信中に前記データブロックが廃棄された場合は、途中で分断されたTSパケットの未送信分に相当するデータと、未送信のTSパケットとを含む前記ダミーデータを生成するものであってもよい。また、前記データはMP4形式であり、MOOFが前記データブロックを構成し、前記ダミーデータ生成部は、前記データブロックの送信中に前記データブロックが廃棄された場合は、前記MOOFの未送信分に相当するデータを前記ダミーデータとして生成するものであってもよい。また、本開示によれば、複数のデータブロックが蓄積されるバッファと、送信要求に応じて前記データブロックを送信するため、前記バッファから前記データブロックを読み出すバッファ制御部と、前記データブロックの送信中に前記データブロックが前記バッファから廃棄された場合に、廃棄により送信できなかったデータブロックの部分に代えてダミーデータを送信する送信部と、を備える、通信装置と、前記送信要求を前記送信装置に送信し、前記送信部から送信された前記データブロック及び前記ダミーデータを受信する受信装置と、を備える、通信システムが提供される。また、本開示によれば、複数のデータブロックが蓄積されたバッファから、前記データブロックを送信するため、前記データブロックを読み出すことと、前記データブロックの送信中に前記データブロックが前記バッファから廃棄された場合に、廃棄により送信できなかったデータブロックの部分に代えてダミーデータを送信することと、を備える、通信方法が提供される。また、本開示によれば、複数のデータブロックが蓄積されたバッファから、前記データブロックを送信するため、前記データブロックを読み出す手段、前記データブロックの送信中に前記データブロックが前記バッファから廃棄された場合に、廃棄により送信できなかったデータブロックの部分に代えてダミーデータを送信する手段、としてコンピュータを機能させるためのプログラムが提供される。本開示によれば、送信側のバッファで送信中のデータが破棄された場合においても、通信を継続することが可能となる。以下に添付図面を参照しながら、本開示の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。なお、説明は以下の順序で行うものとする。1.システムの構成例2.エンコードしたデータをバッファに蓄積するシーケンスの例3.受信機がデータを取得するシーケンスの例4.プレイリストファイル、データブロック取得要求、データブロック取得応答の例5.データ量がバッファ容量の上限に達した場合のシーケンスの例6.データブロックの取得中に、取得中のデータブロックがバッファから削除されてしまった場合のデータ取得シーケンスの例7.ダミーデータを生成してダウンロード継続させるシーケンスの例8.ダミーデータを生成する動作について9.ダミーデータとして送信するTSパケットの内容例10.MP4のファイルフォーマットの例1.システムの構成例まず、図1を参照して、本開示の第1の実施形態に係るシステムの概略構成について説明する。図1は、本実施形態に係る、ライブ映像をリアルタイムにエンコードしてアダプティブストリーミング配信するシステムの概要図を示す。送信機100と受信機200は、IPネットワーク250を介して接続されている。なお、送信機100と受信機200は、無線通信ネットワークを介して接続されるものであってもよい。送信機100は、エンコーダマルチプレクサ102、バッファ制御部104、通信部106、バッファ108、ダミーデータ生成部110を有して構成される。送信機100のエンコーダマルチプレクサ102は、ビデオカメラ等から送られた映像入力をエンコードし、MEPG2-TSもしくはMP4に多重化する。エンコーダマルチプレクサ102から出力されたデータは、バッファ制御部104を介してバッファ108に蓄積される。通信部106は、受信機200からのHTTPによるデータ取得要求を待ち受け、データ取得要求を受信すると、要求に応じたデータを、バッファ制御部104を介してバッファ108より取得し、受信機300へ返信する。受信機200は、通信部202と、デコーダデマルチプレクサ204を有して構成される。受信機200は、通信部202からデータの取得要求を送信機100へ送信し、要求に応じたデータブロックを取得すると、デコーダデマルチプレクサ204へ取得したデータを送る。デコーダデマルチプレクサ204は、多重化されたストリームを分離し、デコードしてモニタ等に出力する。なお、図1に示す構成は、ハードウェア回路、または、CPU中央演算処理装置とこれを機能させるためのソフトウェアプログラムから構成することができる。この場合において、そのプログラムは、送信機100または受信機200が備えるメモリなどの記憶部、または外部から接続される光ディスク等の記憶媒体に格納されることができる。2.エンコードしたデータをバッファに蓄積するシーケンスの例図2は、送信機100において、エンコードしたデータをバッファ108に蓄積するシーケンスを示す模式図である。図2に示すように、バッファ制御部104は、ステップS10において、エンコーダマルチプレクサ102にデータを要求し、ステップS12においてデータを取得する。そして、バッファ制御部104は、ステップS14において、取得したデータをバッファ108に書き込む。以降、この処理が繰り返し行われる。3.受信機がデータを取得するシーケンスの例図3は、受信機200がデータを取得するシーケンスを示す模式図である。先ず、受信機200の通信部202は、ステップS20においてプレイリストの要求を送信機100の通信部106へ送り、ステップS22において、通信部106からプレイリストファイルを取得する。プレイリストファイルには、断片化したファイルのURLリストが記述されている。ステップS24において、通信部202は、プレイリストファイル中のデータブロックAの取得要求データブロックAのURLを送信する。データ取得要求を受け取った通信部106は、バッファ制御部104に該当する範囲のデータを要求するステップS26。バッファ制御部104は、該当するデータをバッファ108へ要求しステップS28、バッファ108から該当するデータ読み出してステップS30、通信部106に送るステップS32。通信部106は、バッファ制御部104から送られてきたデータにHTTPレスポンスヘッダを付与して受信機200の通信部202に送るステップS34。通信部202は。デコーダマルチプレクサ204にデータを送りステップS36、映像が再生される。受信機200は、データブロックAのダウンロードが終了すると、プレイリストファイル中の次のデータブロックBを取得するステップS40以降。プレイリストファイルは再読み込みすることで更新される。以上のように、アダプティブストリーミングにおいて、断片化されてデータブロック毎に分割されたデータは、受信機200側がプレイリスト中のURLを指定してデータブロック毎に要求することで、データブロック毎に送信機100から送信される。このように、比較的データ長の長いデータを一度に送るのではなく、断片化されたデータブロック事に送ることで、例えばデータの送信中に通信の帯域のビットレートに変化が生じた場合は、受信機200は、適切なビットレートのデータブロックを要求することができる。従って、帯域が不安定になった場合等においても安定してデータを受信することができ、特にライブ映像のデータを受信する場合等に適している。図4は、プレイリストファイル、データブロック取得要求、データブロック取得応答の例を示す模式図である。図4では、IETFHTTPLiveStreamingの場合の例を示している。IETFHTTPLiveStreamingは、m3u8形式のプレイリストファイルを用い、データファイルのフォーマットはMPEG2-TSである。このプレイリストでは、8秒毎に断片化された3つのデータブロックが記述されている。1のデータブロックが8秒分のTSパケットを含んだ1ファイルのように扱われている。データの取得はHTTPGETにより行う。5.データ量がバッファ容量の上限に達した場合のシーケンスの例図5は、送信機100において、エンコードしたデータをバッファ108に蓄積するシーケンスにおいて、データ量がバッファ108の容量の上限に達した場合のシーケンスを示す模式図である。データ量がバッファ108の容量の上限に達する前のシーケンスは図2と同様である。データ量がバッファ108の容量の上限に達すると、バッファ制御部104による書き込み処理がエラーとなるのでステップS16、バッファ制御部104は、最も古いデータブロックを削除しステップS18、空いた領域にデータを書き込むステップS20。図6~図9は、図5の動作を示す模式図である。図6は、図2のシーケンスに従って、バッファ108にデータブロックA~Dが書き込まれ、データブロックEのTSパケットが書き込まれている様子を示している。図7は、バッファ108にデータブロックA~Eが書き込まれ、データ量がバッファ108の容量の上限に達した場合を示している。この場合、バッファ108にTSパケットを書き込むことができなくなるため、バッファ制御部104による書き込み処理がエラーとなる。図8は、バッファ制御部104による書き込み処理がエラーとなった後、バッファ制御部104が、バッファ108内の最も古いデータブロックAを廃棄した状態を示している。図9は、バッファ制御部104が、バッファ108内の最も古いデータブロックAを廃棄した後、空いたデータ領域にデータブロックFのTSパケットを書き込んでいる様子を示している。図9に示すように、データブロックAを廃棄したことにより、次のデータブロックFを書き込むことが可能となる。6.データブロックの取得中に、取得中のデータブロックがバッファから削除されてしまった場合のデータ取得シーケンスの例図10は、データブロックの取得中に、取得中のデータブロックがバッファ108から削除されてしまった場合のデータ取得シーケンスを示す模式図である。図10に示すように、データブロックAについては、全てのデータが受信機200に送られる。しかし、データブロックBについては、2つ目のデータをバッファ108から取得している最中に、図5のようにデータブロックBがバッファ108から廃棄されてしまい、バッファ制御部104はバッファ108からデータブロックBの以降のデータを取得することができないステップS42。このように、図10の例では、データブロックBのデータを取得中に、データブロックBが図6~図8で説明したように破棄されてしまい、これ以降のデータを受信機200に送ることができない事態が生じている。受信機200は、データブロックBの取得要求を送信した直後に、図4に示したデータブロック取得応答を送信機100から受信するため、データブロックBのコンテンツのデータ長Content-Lengthを認識している。このため、受信機200は、データブロックBに関し、Content-Lengthのサイズを全てダウンロードするまでは、次のデータブロックを取得する処理を行わないため、映像データがこれ以上ダウンロードされないこととなり、ダウンロードが中止してしまう。このため、本実施形態では、図10のような事態が生じた場合に、ダミーデータを生成して以降のダウンロードを引き続き行うことを可能としている。7.ダミーデータを生成してダウンロード継続させるシーケンスの例図11は、本実施形態における、ダミーデータを生成してダウンロード継続させるシーケンスを示す模式図である。図11において、ステップS42までの処理は図10と同様である。バッファ制御部104は、破棄されたデータを取得しようとした際にデータの読込に失敗するとステップS42、次のステップS44において、不足しているサイズ分のダミーデータを生成するように、ダミーデータ生成部110に対して要求する。ダミーデータ生成部110は、この要求を受けて、ダミーデータを生成するステップS46。生成されたダミーデータは、バッファ制御部104に送られステップS48、通信部106を介して受信機200の通信部202に送られるステップS50,S52。これにより、受信機200は、図4に示したContent-Lengthの分のデータを受信することができる。そして、受信機200は、Content-Length分のデータを受け取ると、次のデータブロックCのダウンロードを開始するステップS54。これにより、バッファ108からデータを取得している最中に、そのデータブロックのデータが廃棄されてしまった場合においても、ダウンロードが停止することがなく、以降のデータをダウンロードすることが可能となる。8.ダミーデータを生成する動作について図12~図14は、ダミーデータを生成する動作を示す模式図である。図12は、バッファ制御部104が、バッファ108内のデータブロックAのTSパケットを読み込んでいる様子を示している。図13は、図12に示す状態から、データブロックAが廃棄された様子を示している。この場合、バッファ制御部104は、廃棄された後はデータブロックAのTSパケットを読み込むことができず、エラーが発生する。図14は、図13のエラー発生により、バッファ制御部104が、ダミーデータ生成部110にダミーデータの生成要求を送った状態を示している。これにより、ダミーデータ生成部110がダミーデータを生成し、生成されたダミーデータは、バッファ制御部104へ送られ、更にバッファ制御部104、通信部106を介して受信機200へ送られる。図15は、IETFHTTPLiveStreamingにおける、ダミーデータの概要を示す模式図である。図15では、バッファ104のデータブロックAが廃棄されたことにより、ステップS42において、TSパケット300,302,304の送信中にデータブロックが破棄されている。1つ目、2つ目のTSパケット300,302については受信機200側に送信されるものの、3つ目のTSパケット304が途中で分断され、TSパケットは一部のみが送信されている。ダミーデータ400は、その分断されたTSパケット304の送信されなかった分を補完するデータ402と、未送信のTSパケット分のNULLパケット4044つ目のTSパケットに相当から構成され、通信部106を介して受信機200の通信部202へ送信される。IETFHTTPLiveStreamingにおける,生成するダミーデータのサイズを求める式は以下の通りである。データブロックサイズ=TSパケットサイズ×パケット数ダミーデータとして送信するNULLパケットの数=/TSパケットサイズ÷TSパケットサイズデータブロックは、ある一定数のTSパケットで構成され、1つのTSパケットは、188バイト×パケット数となる。ダミーデータとして送るNULLパケット404の数は、/TSパケットサイズであり、断片化したTSパケットを補完するデータ402のサイズは、その余りである。9.ダミーデータとして送信するTSパケットの内容例図16は、ダミーデータとして送信するTSパケットNULLパケット404の内容例を示す模式図である。NULLパケット404の各データは、例えば無効なデータに設定される。タイムスタンプつきTSの場合、TSタイムスタンプは0とする。また、同期ワードは0x47とする。また、図16に示すトランスポートエラーインジケータA1bitとしては、エラーを示す1を設定し、ペイロードユニットスタートインジケータB1bit、トランスポート優先度C1bitにはそれぞれ0を設定する。また、パケット識別子13bitには、NULLパケットを示す0x1ffを設定する。トランスポートスクランブルコントロールD2bit、アダプテーションフィールドコントロールE2bit、巡回カウンターF4bitにもそれぞれ0を設定し、ペイロード184byteは、ダミーデータに設定する。断片化したTSパケットを補完するダミーデータ400は、このNULLパケット404の一部から生成する。通信部106は、バッファ104から読み出したデータ量を検知できるため、各データブロックの送信済のデータ量を検知できる。従って、通信部106は、3つ目のTSパケット304の全データが送信できなかったこと、及び3つ目のTSパケット304が何ビットまで送信されたかを検知することができる。各TSパケットは、TSタイムスタンプ、同期ワード、トランスポートエラーインジケータA、ペイロードユニットスタートインジケータBの順で送信されるため、通信部106は、3つ目のTSパケット304がどの部分まで送信されたかを検知できる。ダミーデータ生成部110は、これらの情報に基づいて、上述した計算式により、TSパケット304の未送信分のデータ量に相当するダミーデータ400を生成するとともに、このNULLパケット404を生成する。10.MP4のファイルフォーマットの例AdobeHTTPDynamicStreamingや、MirosoftHTTPSmoothStreamingの場合、プレイリストファイルの形式がそれぞれ異なるが、同様の方法でダミーデータ生成を行うことができる。これらの方式では、データファイルのフォーマットは、MPEG2-TSではなくMP4となるが、MPEG2-TSの場合と同様に、送信されるべきデータ長と、送信済みデータ量とから、未送信分のデータ量を算出することができる。従って、未送信分のデータ量に基づいてダミーデータを生成することが可能である。図17は、MP4のファイルフォーマットを簡略化して示す模式図である。1つのMP4ファイルは、主にMOOVMovieMetadataとMOOFMovieFragmentで構成される。上述したIETFHTTPLiveStreamingの場合、1つのデータブロックが1つのファイルであるように扱われていたが、MP4を利用する方式の場合は、1データブロックが1つのMOOFMovieFragmentに対応するようになる。MOOFは可変長であるが、のデータサイズのダミーデータをダミーデータ生成部110で生成することによって、通信部106からダミーデータを送信することができる以上説明したように本実施形態によれば、送信機100側のバッファリングなどで吸収しきれずにエラーとなった場合においても、通信が終了することがなく、通信を継続させることが可能となる。以上、添付図面を参照しながら本開示の好適な実施形態について詳細に説明したが、本開示の技術的範囲はかかる例に限定されない。本開示の技術分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本開示の技術的範囲に属するものと了解される。なお、以下のような構成も本開示の技術的範囲に属する。1複数のデータブロックが蓄積されるバッファと、前記データブロックを送信するため、前記バッファから前記データブロックを読み出すバッファ制御部と、前記データブロックの送信中に前記データブロックが前記バッファから廃棄された場合に、廃棄により送信できなかったデータブロックの前記部分に代えてダミーデータを送信する送信部と、を備える、通信装置。2前記データブロックの送信中に前記データブロックが前記バッファから廃棄された場合に、廃棄により送信できなかったデータブロックの部分に相当するダミーデータを生成するダミーデータ生成部を備え、前記送信部は、前記バッファから読み出された前記データブロックを送信するとともに、前記ダミーデータが生成された場合は、廃棄により送信できなかったデータブロックの前記部分に代えて前記ダミーデータを送信する、前記1に記載の通信装置。3前記データはMPEG2-TS形式であり、所定数のTSパケットが前記データブロックを構成し、前記ダミーデータ生成部は、前記データブロックの送信中に前記データブロックが廃棄された場合は、途中で分断されたTSパケットの未送信分に相当するデータと、未送信のTSパケットとを含む前記ダミーデータを生成する、前記2に記載の通信装置。4前記データはMP4形式であり、MOOFが前記データブロックを構成し、前記ダミーデータ生成部は、前記データブロックの送信中に前記データブロックが廃棄された場合は、前記MOOFの未送信分に相当するデータを前記ダミーデータとして生成する、前記3に記載の通信装置。5複数のデータブロックが蓄積されるバッファと、送信要求に応じて前記データブロックを送信するため、前記バッファから前記データブロックを読み出すバッファ制御部と、前記データブロックの送信中に前記データブロックが前記バッファから廃棄された場合に、廃棄により送信できなかったデータブロックの前記部分に代えてダミーデータを送信する送信部と、を備える、通信装置と、前記送信要求を前記送信装置に送信し、前記送信部から送信された前記データブロック及び前記ダミーデータを受信する受信装置と、を備える、通信システム。6複数のデータブロックが蓄積されたバッファから、前記データブロックを送信するため、前記データブロックを読み出すことと、前記データブロックの送信中に前記データブロックが前記バッファから廃棄された場合に、廃棄により送信できなかったデータブロックの前記部分に代えてダミーデータを送信することと、を備える、通信方法。7複数のデータブロックが蓄積されたバッファから、前記データブロックを送信するため、前記データブロックを読み出す手段、前記データブロックの送信中に前記データブロックが前記バッファから廃棄された場合に、廃棄により送信できなかったデータブロックの前記部分に代えてダミーデータを送信する手段、としてコンピュータを機能させるためのプログラム。"