通信装置、通信システム、通信方法及びプログラム
【課題】送信側のバッファで送信中のデータが破棄された場合においても、通信を継続する。
【解決手段】本開示に係る通信装置は、複数のデータブロックが蓄積されるバッファと、
前記データブロックを送信するため、前記バッファから前記データブロックを読み出すバッファ制御部と、前記データブロックの送信中に前記データブロックが前記バッファから廃棄された場合に、廃棄により送信できなかったデータブロックの前記部分に代えてダミーデータを送信する送信部と、を備える。
【解決手段】本開示に係る通信装置は、複数のデータブロックが蓄積されるバッファと、
前記データブロックを送信するため、前記バッファから前記データブロックを読み出すバッファ制御部と、前記データブロックの送信中に前記データブロックが前記バッファから廃棄された場合に、廃棄により送信できなかったデータブロックの前記部分に代えてダミーデータを送信する送信部と、を備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、通信装置、通信システム、通信方法及びプログラムに関する。
【背景技術】
【０００２】
近時では、断片化された映像データを受信機がＨＴＴＰによって連続的に取得する、ＨＴＴＰアダプティブストリーミングの手法が知られている。このＨＴＴＰアダプティブストリーミングの仕様としては、ＩＥＴＦ ＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇ，Ａｄｏｂｅ ＨＴＴＰ Ｄｙｎａｍｉｃ Ｓｔｒｅａｍｉｎｇ，Ｍｉｃｒｏｓｏｆｔ Ｓｍｏｏｔｈ Ｓｔｒｅａｍｉｎｇなど、何種類かの手法が存在する。
・IETF HTTP Live Streaming
(http://tools.ietf.org/html/draft-pantos-http-live-streaming-05)
・Adobe HTTP Dynamic Streaming (http://www.adobe.com/products/httpdynamicstreaming/)
・Mirosoft HTTP Smooth Streaming
(http://technet.microsoft.com/ja-jp/library/dd775200.aspx)
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１０−０４５７６０号公報
【特許文献２】特開２０１０−２４６１４６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
上記のアダプティブストリーミングのシステムでは、配信サーバは、複数のレートでエンコードしたコンテンツを、更にそれぞれを断片化したファイルとして用意する。クライアントは、配信サーバとの間のスループットに適したビットレートの断片ファイルをダウンロードすることで、配信中にスループットの変化に追従できる。
【０００５】
しかしながら、従来の技術は、十分なバッファを持つ大規模なサーバから送信することを前提にしているので、バッファ容量が限界に達した場合に、送信機側でデータが破棄されることは想定していない。
【０００６】
一方、アダプティブストリーミング配信を、組み込み機器で、しかもライブ映像に適用しようとした場合、バッファ容量が小さいため、バッファに蓄積されるデータ量が限界に達した場合に、送信中の断片化されたデータが破棄されてしまうことが想定される。この場合、送信側はＨＴＴＰのセッションを切断してしまい、通信が途絶してしまう可能性がある。
【０００７】
パケットロスやジッタによるエラーを回避するため、上記特許文献１に記載されているような、受信側でバッファリングすることでジッタを吸収する技術があるが、これらの技術は、ジッタを吸収しきれなかったものに対しての想定はしていない。
【０００８】
そこで、送信側のバッファで送信中のデータが破棄された場合においても、通信を継続できる仕組みが求められていた。
【課題を解決するための手段】
【０００９】
本開示によれば、複数のデータブロックが蓄積されるバッファと、前記データブロックを送信するため、前記バッファから前記データブロックを読み出すバッファ制御部と、前記データブロックの送信中に前記データブロックが前記バッファから廃棄された場合に、廃棄により送信できなかったデータブロックの部分に代えてダミーデータを送信する送信部と、を備える、通信装置が提供される。
【００１０】
また、前記データブロックの送信中に前記データブロックが前記バッファから廃棄された場合に、廃棄により送信できなかったデータブロックの部分に相当するダミーデータを生成するダミーデータ生成部を備え、前記送信部は、前記バッファから読み出された前記データブロックを送信するとともに、前記ダミーデータが生成された場合は、廃棄により送信できなかったデータブロックの前記部分に代えて前記ダミーデータを送信するものであってもよい。
【００１１】
また、前記データはＭＰＥＧ２−ＴＳ形式であり、所定数のＴＳパケットが前記データブロックを構成し、前記ダミーデータ生成部は、前記データブロックの送信中に前記データブロックが廃棄された場合は、途中で分断されたＴＳパケットの未送信分に相当するデータと、未送信のＴＳパケットとを含む前記ダミーデータを生成するものであってもよい。
【００１２】
また、前記データはＭＰ４形式であり、ＭＯＯＦが前記データブロックを構成し、前記ダミーデータ生成部は、前記データブロックの送信中に前記データブロックが廃棄された場合は、前記ＭＯＯＦの未送信分に相当するデータを前記ダミーデータとして生成するものであってもよい。
【００１３】
また、本開示によれば、複数のデータブロックが蓄積されるバッファと、送信要求に応じて前記データブロックを送信するため、前記バッファから前記データブロックを読み出すバッファ制御部と、前記データブロックの送信中に前記データブロックが前記バッファから廃棄された場合に、廃棄により送信できなかったデータブロックの部分に代えてダミーデータを送信する送信部と、を備える、通信装置と、前記送信要求を前記送信装置に送信し、前記送信部から送信された前記データブロック及び前記ダミーデータを受信する受信装置と、を備える、通信システムが提供される。
【００１４】
また、本開示によれば、複数のデータブロックが蓄積されたバッファから、前記データブロックを送信するため、前記データブロックを読み出すことと、前記データブロックの送信中に前記データブロックが前記バッファから廃棄された場合に、廃棄により送信できなかったデータブロックの部分に代えてダミーデータを送信することと、を備える、通信方法が提供される。
【００１５】
また、本開示によれば、複数のデータブロックが蓄積されたバッファから、前記データブロックを送信するため、前記データブロックを読み出す手段、前記データブロックの送信中に前記データブロックが前記バッファから廃棄された場合に、廃棄により送信できなかったデータブロックの部分に代えてダミーデータを送信する手段、としてコンピュータを機能させるためのプログラムが提供される。
【発明の効果】
【００１６】
本開示によれば、送信側のバッファで送信中のデータが破棄された場合においても、通信を継続することが可能となる。
【図面の簡単な説明】
【００１７】
【図１】本実施形態に係る、ライブ映像をリアルタイムにエンコードしてアダプティブストリーミング配信するシステムの概要図である。
【図２】送信機において、エンコードしたデータをバッファに蓄積するシーケンスを示す模式図である。
【図３】受信機がデータを取得するシーケンスを示す模式図である。
【図４】プレイリストファイル、 データブロック取得要求、データブロック取得応答の例を示す模式図である。
【図５】送信機において、エンコードしたデータをバッファに蓄積するシーケンスにおいて、データ量がバッファの容量の上限に達した場合のシーケンスを示す模式図である。
【図６】図２のシーケンスに従って、バッファにデータブロックＡ〜Ｄが書き込まれ、データブロックＥのＴＳパケットが書き込まれている様子を示す模式図である。
【図７】バッファにデータブロックＡ〜Ｅが書き込まれ、データ量がバッファの容量の上限に達した場合を示す模式図である。
【図８】バッファ制御部による書き込み処理がエラーとなった後、バッファ制御部１０４が、バッファ内の最も古いデータブロックＡを廃棄した状態を示す模式図である。
【図９】バッファ制御部が、バッファ１０８内の最も古いデータブロックＡを廃棄した後、空いたデータ領域にデータブロックＦのＴＳパケットを書き込んでいる様子を示す模式図である。
【図１０】データブロックの取得中に、取得中のデータブロックがバッファから削除されてしまった場合のデータ取得シーケンスを示す模式図である。
【図１１】本実施形態における。ダミーデータを生成してダウンロード継続させるシーケンスを示す模式図である。
【図１２】バッファ制御部が、バッファ内のデータブロックＡのＴＳパケットを読み込んでいる様子を示す模式図である。
【図１３】図１２に示す状態から、データブロックＡが廃棄された様子を示す模式図である。
【図１４】図１３のエラー発生により、バッファ制御部が、ダミーデータ生成部にダミーデータの生成要求を送った状態を示す模式図である。
【図１５】ＩＥＴＦ ＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇにおける、ダミーデータの概要を示す模式図である。
【図１６】ダミーデータとして送信するＴＳパケットの内容例を示す模式図である。
【図１７】ＭＰ４のファイルフォーマットを簡略化して示す模式図である。
【発明を実施するための形態】
【００１８】
以下に添付図面を参照しながら、本開示の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。
【００１９】
なお、説明は以下の順序で行うものとする。
１．システムの構成例
２．エンコードしたデータをバッファに蓄積するシーケンスの例
３．受信機がデータを取得するシーケンスの例
４．プレイリストファイル、 データブロック取得要求、データブロック取得応答の例
５．データ量がバッファ容量の上限に達した場合のシーケンスの例
６．データブロックの取得中に、取得中のデータブロックがバッファから削除されてしまった場合のデータ取得シーケンスの例
７．ダミーデータを生成してダウンロード継続させるシーケンスの例
８．ダミーデータを生成する動作について
９．ダミーデータとして送信するＴＳパケットの内容例
１０．ＭＰ４のファイルフォーマットの例
【００２０】
１．システムの構成例
まず、図１を参照して、本開示の第１の実施形態に係るシステムの概略構成について説明する。図１は、本実施形態に係る、ライブ映像をリアルタイムにエンコードしてアダプティブストリーミング配信するシステムの概要図を示す。送信機１００と受信機２００は、ＩＰネットワーク２５０を介して接続されている。なお、送信機１００と受信機２００は、無線通信ネットワークを介して接続されるものであってもよい。
【００２１】
送信機１００は、エンコーダ・マルチプレクサ１０２、バッファ制御部１０４、通信部１０６、バッファ１０８、ダミーデータ生成部１１０を有して構成される。送信機１００のエンコーダ・マルチプレクサ１０２は、ビデオカメラ等から送られた映像入力をエンコードし、ＭＥＰＧ２−ＴＳもしくはＭＰ４に多重化する。エンコーダ・マルチプレクサ１０２から出力されたデータは、バッファ制御部１０４を介してバッファ１０８に蓄積される。通信部１０６は、受信機２００からのＨＴＴＰによるデータ取得要求を待ち受け、データ取得要求を受信すると、要求に応じたデータを、バッファ制御部１０４を介してバッファ１０８より取得し、受信機３００へ返信する。
【００２２】
受信機２００は、通信部２０２と、デコーダ・デマルチプレクサ２０４を有して構成される。受信機２００は、通信部２０２からデータの取得要求を送信機１００へ送信し、要求に応じたデータブロックを取得すると、デコーダ・デマルチプレクサ２０４へ取得したデータを送る。デコーダ・デマルチプレクサ２０４は、多重化されたストリームを分離し、デコードしてモニタ等に出力する。
【００２３】
なお、図１に示す構成は、ハードウェア（回路）、または、ＣＰＵ（中央演算処理装置）とこれを機能させるためのソフトウェア（プログラム）から構成することができる。この場合において、そのプログラムは、送信機１００または受信機２００が備えるメモリなどの記憶部、または外部から接続される光ディスク等の記憶媒体に格納されることができる。
【００２４】
２．エンコードしたデータをバッファに蓄積するシーケンスの例
図２は、送信機１００において、エンコードしたデータをバッファ１０８に蓄積するシーケンスを示す模式図である。図２に示すように、バッファ制御部１０４は、ステップＳ１０において、エンコーダ・マルチプレクサ１０２にデータを要求し、ステップＳ１２においてデータを取得する。そして、バッファ制御部１０４は、ステップＳ１４において、取得したデータをバッファ１０８に書き込む。以降、この処理が繰り返し行われる。
【００２５】
３．受信機がデータを取得するシーケンスの例
図３は、受信機２００がデータを取得するシーケンスを示す模式図である。先ず、受信機２００の通信部２０２は、ステップＳ２０においてプレイリストの要求を送信機１００の通信部１０６へ送り、ステップＳ２２において、通信部１０６からプレイリストファイルを取得する。プレイリストファイルには、断片化したファイルのＵＲＬリストが記述されている。ステップＳ２４において、通信部２０２は、プレイリストファイル中のデータブロックＡの取得要求（データブロックＡのＵＲＬ）を送信する。
【００２６】
データ取得要求を受け取った通信部１０６は、バッファ制御部１０４に該当する範囲のデータを要求する（ステップＳ２６）。バッファ制御部１０４は、該当するデータをバッファ１０８へ要求し（ステップＳ２８）、バッファ１０８から該当するデータ読み出して（ステップＳ３０）、通信部１０６に送る（ステップＳ３２）。通信部１０６は、バッファ制御部１０４から送られてきたデータにＨＴＴＰレスポンスヘッダを付与して受信機２００の通信部２０２に送る（ステップＳ３４）。通信部２０２は。デコーダ・マルチプレクサ２０４にデータを送り（ステップＳ３６）、映像が再生される。受信機２００は、データブロックＡのダウンロードが終了すると、プレイリストファイル中の次のデータブロックＢを取得する（ステップＳ４０以降）。プレイリストファイルは再読み込みすることで更新される。
【００２７】
以上のように、アダプティブストリーミングにおいて、断片化されてデータブロック毎に分割されたデータは、受信機２００側がプレイリスト中のＵＲＬを指定してデータブロック毎に要求することで、データブロック毎に送信機１００から送信される。このように、比較的データ長の長いデータを一度に送るのではなく、断片化されたデータブロック事に送ることで、例えばデータの送信中に通信の帯域のビットレートに変化が生じた場合は、受信機２００は、適切なビットレートのデータブロックを要求することができる。従って、帯域が不安定になった場合等においても安定してデータを受信することができ、特にライブ映像のデータを受信する場合等に適している。
【００２８】
図４は、プレイリストファイル、 データブロック取得要求、データブロック取得応答の例を示す模式図である。図４では、ＩＥＴＦ ＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇの場合の例を示している。ＩＥＴＦ ＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇは、ｍ３ｕ８形式のプレイリストファイルを用い、データファイルのフォーマットはＭＰＥＧ２−ＴＳである。このプレイリストでは、８秒毎に断片化された３つのデータブロックが記述されている。１のデータブロックが８秒分のＴＳパケットを含んだ１ファイルのように扱われている。データの取得はＨＴＴＰ ＧＥＴにより行う。
【００２９】
５．データ量がバッファ容量の上限に達した場合のシーケンスの例
図５は、送信機１００において、エンコードしたデータをバッファ１０８に蓄積するシーケンスにおいて、データ量がバッファ１０８の容量の上限に達した場合のシーケンスを示す模式図である。データ量がバッファ１０８の容量の上限に達する前のシーケンスは図２と同様である。データ量がバッファ１０８の容量の上限に達すると、バッファ制御部１０４による書き込み処理がエラーとなるので（ステップＳ１６）、バッファ制御部１０４は、最も古いデータブロックを削除し（ステップＳ１８）、空いた領域にデータを書き込む（ステップＳ２０）。
【００３０】
図６〜図９は、図５の動作を示す模式図である。図６は、図２のシーケンスに従って、バッファ１０８にデータブロックＡ〜Ｄが書き込まれ、データブロックＥのＴＳパケットが書き込まれている様子を示している。
【００３１】
図７は、バッファ１０８にデータブロックＡ〜Ｅが書き込まれ、データ量がバッファ１０８の容量の上限に達した場合を示している。この場合、バッファ１０８にＴＳパケットを書き込むことができなくなるため、バッファ制御部１０４による書き込み処理がエラーとなる。
【００３２】
図８は、バッファ制御部１０４による書き込み処理がエラーとなった後、バッファ制御部１０４が、バッファ１０８内の最も古いデータブロックＡを廃棄した状態を示している。
【００３３】
図９は、バッファ制御部１０４が、バッファ１０８内の最も古いデータブロックＡを廃棄した後、空いたデータ領域にデータブロックＦのＴＳパケットを書き込んでいる様子を示している。図９に示すように、データブロックＡを廃棄したことにより、次のデータブロックＦを書き込むことが可能となる。
【００３４】
６．データブロックの取得中に、取得中のデータブロックがバッファから削除されてしまった場合のデータ取得シーケンスの例
図１０は、データブロックの取得中に、取得中のデータブロックがバッファ１０８から削除されてしまった場合のデータ取得シーケンスを示す模式図である。図１０に示すように、データブロックＡについては、全てのデータが受信機２００に送られる。しかし、データブロックＢについては、２つ目のデータをバッファ１０８から取得している最中に、図５のようにデータブロックＢがバッファ１０８から廃棄されてしまい、バッファ制御部１０４はバッファ１０８からデータブロックＢの以降のデータを取得することができない（ステップＳ４２）。
【００３５】
このように、図１０の例では、データブロックＢのデータを取得中に、データブロックＢが図６〜図８で説明したように破棄されてしまい、これ以降のデータを受信機２００に送ることができない事態が生じている。受信機２００は、データブロックＢの取得要求を送信した直後に、図４に示したデータブロック取得応答を送信機１００から受信するため、データブロックＢのコンテンツのデータ長（Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ）を認識している。このため、受信機２００は、データブロックＢに関し、Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈのサイズを全てダウンロードするまでは、次のデータブロックを取得する処理を行わないため、映像データがこれ以上ダウンロードされないこととなり、ダウンロードが中止してしまう。
【００３６】
このため、本実施形態では、図１０のような事態が生じた場合に、ダミーデータを生成して以降のダウンロードを引き続き行うことを可能としている。
【００３７】
７．ダミーデータを生成してダウンロード継続させるシーケンスの例
図１１は、本実施形態における、ダミーデータを生成してダウンロード継続させるシーケンスを示す模式図である。図１１において、ステップＳ４２までの処理は図１０と同様である。
【００３８】
バッファ制御部１０４は、破棄されたデータを取得しようとした際にデータの読込に失敗すると（ステップＳ４２）、次のステップＳ４４において、不足しているサイズ分のダミーデータを生成するように、ダミーデータ生成部１１０に対して要求する。ダミーデータ生成部１１０は、この要求を受けて、ダミーデータを生成する（ステップＳ４６）。生成されたダミーデータは、バッファ制御部１０４に送られ（ステップＳ４８）、通信部１０６を介して受信機２００の通信部２０２に送られる（ステップＳ５０，Ｓ５２）。
【００３９】
これにより、受信機２００は、図４に示したＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈの分のデータを受信することができる。そして、受信機２００は、Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ分のデータを受け取ると、次のデータブロックＣのダウンロードを開始する（ステップＳ５４）。これにより、バッファ１０８からデータを取得している最中に、そのデータブロックのデータが廃棄されてしまった場合においても、ダウンロードが停止することがなく、以降のデータをダウンロードすることが可能となる。
【００４０】
８．ダミーデータを生成する動作について
図１２〜図１４は、ダミーデータを生成する動作を示す模式図である。図１２は、バッファ制御部１０４が、バッファ１０８内のデータブロックＡのＴＳパケットを読み込んでいる様子を示している。
【００４１】
図１３は、図１２に示す状態から、データブロックＡが廃棄された様子を示している。この場合、バッファ制御部１０４は、廃棄された後はデータブロックＡのＴＳパケットを読み込むことができず、エラーが発生する。
【００４２】
図１４は、図１３のエラー発生により、バッファ制御部１０４が、ダミーデータ生成部１１０にダミーデータの生成要求を送った状態を示している。これにより、ダミーデータ生成部１１０がダミーデータを生成し、生成されたダミーデータは、バッファ制御部１０４へ送られ、更にバッファ制御部１０４、通信部１０６を介して受信機２００へ送られる。
【００４３】
図１５は、ＩＥＴＦ ＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇにおける、ダミーデータの概要を示す模式図である。図１５では、バッファ１０４のデータブロックＡが廃棄されたことにより、ステップＳ４２において、ＴＳパケット３００，３０２，３０４の送信中にデータブロックが破棄されている。１つ目、２つ目のＴＳパケット３００，３０２については受信機２００側に送信されるものの、３つ目のＴＳパケット３０４が途中で分断され、ＴＳパケットは一部のみが送信されている。ダミーデータ４００は、その分断されたＴＳパケット３０４の送信されなかった分を補完するデータ４０２と、未送信のＴＳパケット分のＮＵＬＬパケット４０４（４つ目のＴＳパケットに相当）から構成され、通信部１０６を介して受信機２００の通信部２０２へ送信される。
【００４４】
ＩＥＴＦ ＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇにおける，生成するダミーデータのサイズを求める式は以下の通りである。
データブロックサイズ＝ＴＳパケットサイズ×パケット数
ダミーデータとして送信するＮＵＬＬパケットの数＝(データブロックサイズ−送信済データサイズ)／ＴＳパケットサイズ
(断片化したＴＳを補完するダミーデータのサイズ＝(データブロックサイズ−送信済データサイズ)÷ＴＳパケットサイズ)
【００４５】
データブロックは、ある一定数のＴＳパケットで構成され、１つのＴＳパケットは、１８８バイト(タイムスタンプつきＴＳの場合は１９２バイトである。
従って、データブロックのサイズは、
１８８バイト(タイムスタンプつきＴＳの場合は１９２バイト)×パケット数
となる。
【００４６】
ダミーデータとして送るＮＵＬＬパケット４０４の数は 、
(データブロックサイズ−送信済データサイズ)／ＴＳパケットサイズ
であり、断片化したＴＳパケットを補完するデータ４０２のサイズは、その余りである。
【００４７】
９．ダミーデータとして送信するＴＳパケットの内容例
図１６は、ダミーデータとして送信するＴＳパケット（ＮＵＬＬパケット４０４）の内容例を示す模式図である。ＮＵＬＬパケット４０４の各データは、例えば無効なデータに設定される。タイムスタンプつきＴＳの場合、ＴＳ（タイムスタンプ）は０とする。また、同期ワードは（０ｘ４７）とする。
【００４８】
また、図１６に示すトランスポートエラーインジケータＡ（１ｂｉｔ）としては、エラーを示す１を設定し、ペイロードユニットスタートインジケータＢ（１ｂｉｔ）、トランスポート優先度Ｃ（１ｂｉｔ）にはそれぞれ０を設定する。また、パケット識別子（１３ｂｉｔ）には、ＮＵＬＬパケットを示す（０ｘ１ｆｆ）を設定する。トランスポートスクランブルコントロールＤ（２ｂｉｔ）、アダプテーションフィールドコントロールＥ（２ｂｉｔ）、巡回カウンターＦ（４ｂｉｔ）にもそれぞれ０を設定し、ペイロード（１８４ｂｙｔｅ）は、ダミーデータ(たとえば０ｘ００や０ｘＦＦ)に設定する。断片化したＴＳパケットを補完するダミーデータ４００は、このＮＵＬＬパケット４０４の一部から生成する。通信部１０６は、バッファ１０４から読み出したデータ量を検知できるため、各データブロックの送信済のデータ量を検知できる。従って、通信部１０６は、３つ目のＴＳパケット３０４の全データが送信できなかったこと、及び３つ目のＴＳパケット３０４が何ビットまで送信されたかを検知することができる。各ＴＳパケットは、ＴＳ（タイムスタンプ）、同期ワード、トランスポートエラーインジケータＡ、ペイロードユニットスタートインジケータＢの順で送信されるため、通信部１０６は、３つ目のＴＳパケット３０４がどの部分まで送信されたかを検知できる。ダミーデータ生成部１１０は、これらの情報に基づいて、上述した計算式により、ＴＳパケット３０４の未送信分のデータ量に相当するダミーデータ４００を生成するとともに、このＮＵＬＬパケット４０４を生成する。
【００４９】
１０．ＭＰ４のファイルフォーマットの例
Ａｄｏｂｅ ＨＴＴＰ Ｄｙｎａｍｉｃ Ｓｔｒｅａｍｉｎｇや、Ｍｉｒｏｓｏｆｔ ＨＴＴＰ Ｓｍｏｏｔｈ Ｓｔｒｅａｍｉｎｇの場合、プレイリストファイルの形式がそれぞれ異なるが、同様の方法でダミーデータ生成を行うことができる。
【００５０】
これらの方式では、データファイルのフォーマットは、ＭＰＥＧ２−ＴＳではなくＭＰ４となるが、ＭＰＥＧ２−ＴＳの場合と同様に、送信されるべきデータ長と、送信済みデータ量とから、未送信分のデータ量を算出することができる。従って、未送信分のデータ量に基づいてダミーデータを生成することが可能である。図１７は、ＭＰ４のファイルフォーマットを簡略化して示す模式図である。１つのＭＰ４ファイルは、主にＭＯＯＶ（Ｍｏｖｉｅ Ｍｅｔａｄａｔａ）とＭＯＯＦ（Ｍｏｖｉｅ Ｆｒａｇｍｅｎｔ）で構成される。上述したＩＥＴＦ ＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇの場合、１つのデータブロックが１つのファイルであるように扱われていたが、ＭＰ４を利用する方式の場合は、１データブロックが１つのＭＯＯＦ（Ｍｏｖｉｅ Ｆｒａｇｍｅｎｔ）に対応するようになる。ＭＯＯＦは可変長であるが、 (データブロック長−送信済データ長)のデータサイズのダミーデータ(たとえば０ｘ００や０ｘＦＦ)をダミーデータ生成部１１０で生成することによって、通信部１０６からダミーデータを送信することができる.
【００５１】
以上説明したように本実施形態によれば、送信機１００側のバッファリングなどで吸収しきれずにエラーとなった場合においても、通信が終了することがなく、通信を継続させることが可能となる。
【００５２】
以上、添付図面を参照しながら本開示の好適な実施形態について詳細に説明したが、本開示の技術的範囲はかかる例に限定されない。本開示の技術分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本開示の技術的範囲に属するものと了解される。
【００５３】
なお、以下のような構成も本開示の技術的範囲に属する。
（１）複数のデータブロックが蓄積されるバッファと、
前記データブロックを送信するため、前記バッファから前記データブロックを読み出すバッファ制御部と、
前記データブロックの送信中に前記データブロックが前記バッファから廃棄された場合に、廃棄により送信できなかったデータブロックの前記部分に代えてダミーデータを送信する送信部と、
を備える、通信装置。
【００５４】
（２）前記データブロックの送信中に前記データブロックが前記バッファから廃棄された場合に、廃棄により送信できなかったデータブロックの部分に相当するダミーデータを生成するダミーデータ生成部を備え、
前記送信部は、前記バッファから読み出された前記データブロックを送信するとともに、前記ダミーデータが生成された場合は、廃棄により送信できなかったデータブロックの前記部分に代えて前記ダミーデータを送信する、前記（１）に記載の通信装置。
【００５５】
（３）前記データはＭＰＥＧ２−ＴＳ形式であり、所定数のＴＳパケットが前記データブロックを構成し、
前記ダミーデータ生成部は、前記データブロックの送信中に前記データブロックが廃棄された場合は、途中で分断されたＴＳパケットの未送信分に相当するデータと、未送信のＴＳパケットとを含む前記ダミーデータを生成する、前記（２）に記載の通信装置。
【００５６】
（４）前記データはＭＰ４形式であり、ＭＯＯＦが前記データブロックを構成し、
前記ダミーデータ生成部は、前記データブロックの送信中に前記データブロックが廃棄された場合は、前記ＭＯＯＦの未送信分に相当するデータを前記ダミーデータとして生成する、前記（３）に記載の通信装置。
【００５７】
（５）複数のデータブロックが蓄積されるバッファと、
送信要求に応じて前記データブロックを送信するため、前記バッファから前記データブロックを読み出すバッファ制御部と、
前記データブロックの送信中に前記データブロックが前記バッファから廃棄された場合に、廃棄により送信できなかったデータブロックの前記部分に代えてダミーデータを送信する送信部と、
を備える、通信装置と、
前記送信要求を前記送信装置に送信し、前記送信部から送信された前記データブロック及び前記ダミーデータを受信する受信装置と、
を備える、通信システム。
【００５８】
（６）複数のデータブロックが蓄積されたバッファから、前記データブロックを送信するため、前記データブロックを読み出すことと、
前記データブロックの送信中に前記データブロックが前記バッファから廃棄された場合に、廃棄により送信できなかったデータブロックの前記部分に代えてダミーデータを送信することと、
を備える、通信方法。
【００５９】
（７）複数のデータブロックが蓄積されたバッファから、前記データブロックを送信するため、前記データブロックを読み出す手段、
前記データブロックの送信中に前記データブロックが前記バッファから廃棄された場合に、廃棄により送信できなかったデータブロックの前記部分に代えてダミーデータを送信する手段、
としてコンピュータを機能させるためのプログラム。
【符号の説明】
【００６０】
１００ 送信機
１０４ バッファ制御部
１０６ 通信部
１０８ バッファ
１１０ ダミーデータ生成部
２００ 受信機
【技術分野】
【０００１】
本開示は、通信装置、通信システム、通信方法及びプログラムに関する。
【背景技術】
【０００２】
近時では、断片化された映像データを受信機がＨＴＴＰによって連続的に取得する、ＨＴＴＰアダプティブストリーミングの手法が知られている。このＨＴＴＰアダプティブストリーミングの仕様としては、ＩＥＴＦ ＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇ，Ａｄｏｂｅ ＨＴＴＰ Ｄｙｎａｍｉｃ Ｓｔｒｅａｍｉｎｇ，Ｍｉｃｒｏｓｏｆｔ Ｓｍｏｏｔｈ Ｓｔｒｅａｍｉｎｇなど、何種類かの手法が存在する。
・IETF HTTP Live Streaming
(http://tools.ietf.org/html/draft-pantos-http-live-streaming-05)
・Adobe HTTP Dynamic Streaming (http://www.adobe.com/products/httpdynamicstreaming/)
・Mirosoft HTTP Smooth Streaming
(http://technet.microsoft.com/ja-jp/library/dd775200.aspx)
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１０−０４５７６０号公報
【特許文献２】特開２０１０−２４６１４６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
上記のアダプティブストリーミングのシステムでは、配信サーバは、複数のレートでエンコードしたコンテンツを、更にそれぞれを断片化したファイルとして用意する。クライアントは、配信サーバとの間のスループットに適したビットレートの断片ファイルをダウンロードすることで、配信中にスループットの変化に追従できる。
【０００５】
しかしながら、従来の技術は、十分なバッファを持つ大規模なサーバから送信することを前提にしているので、バッファ容量が限界に達した場合に、送信機側でデータが破棄されることは想定していない。
【０００６】
一方、アダプティブストリーミング配信を、組み込み機器で、しかもライブ映像に適用しようとした場合、バッファ容量が小さいため、バッファに蓄積されるデータ量が限界に達した場合に、送信中の断片化されたデータが破棄されてしまうことが想定される。この場合、送信側はＨＴＴＰのセッションを切断してしまい、通信が途絶してしまう可能性がある。
【０００７】
パケットロスやジッタによるエラーを回避するため、上記特許文献１に記載されているような、受信側でバッファリングすることでジッタを吸収する技術があるが、これらの技術は、ジッタを吸収しきれなかったものに対しての想定はしていない。
【０００８】
そこで、送信側のバッファで送信中のデータが破棄された場合においても、通信を継続できる仕組みが求められていた。
【課題を解決するための手段】
【０００９】
本開示によれば、複数のデータブロックが蓄積されるバッファと、前記データブロックを送信するため、前記バッファから前記データブロックを読み出すバッファ制御部と、前記データブロックの送信中に前記データブロックが前記バッファから廃棄された場合に、廃棄により送信できなかったデータブロックの部分に代えてダミーデータを送信する送信部と、を備える、通信装置が提供される。
【００１０】
また、前記データブロックの送信中に前記データブロックが前記バッファから廃棄された場合に、廃棄により送信できなかったデータブロックの部分に相当するダミーデータを生成するダミーデータ生成部を備え、前記送信部は、前記バッファから読み出された前記データブロックを送信するとともに、前記ダミーデータが生成された場合は、廃棄により送信できなかったデータブロックの前記部分に代えて前記ダミーデータを送信するものであってもよい。
【００１１】
また、前記データはＭＰＥＧ２−ＴＳ形式であり、所定数のＴＳパケットが前記データブロックを構成し、前記ダミーデータ生成部は、前記データブロックの送信中に前記データブロックが廃棄された場合は、途中で分断されたＴＳパケットの未送信分に相当するデータと、未送信のＴＳパケットとを含む前記ダミーデータを生成するものであってもよい。
【００１２】
また、前記データはＭＰ４形式であり、ＭＯＯＦが前記データブロックを構成し、前記ダミーデータ生成部は、前記データブロックの送信中に前記データブロックが廃棄された場合は、前記ＭＯＯＦの未送信分に相当するデータを前記ダミーデータとして生成するものであってもよい。
【００１３】
また、本開示によれば、複数のデータブロックが蓄積されるバッファと、送信要求に応じて前記データブロックを送信するため、前記バッファから前記データブロックを読み出すバッファ制御部と、前記データブロックの送信中に前記データブロックが前記バッファから廃棄された場合に、廃棄により送信できなかったデータブロックの部分に代えてダミーデータを送信する送信部と、を備える、通信装置と、前記送信要求を前記送信装置に送信し、前記送信部から送信された前記データブロック及び前記ダミーデータを受信する受信装置と、を備える、通信システムが提供される。
【００１４】
また、本開示によれば、複数のデータブロックが蓄積されたバッファから、前記データブロックを送信するため、前記データブロックを読み出すことと、前記データブロックの送信中に前記データブロックが前記バッファから廃棄された場合に、廃棄により送信できなかったデータブロックの部分に代えてダミーデータを送信することと、を備える、通信方法が提供される。
【００１５】
また、本開示によれば、複数のデータブロックが蓄積されたバッファから、前記データブロックを送信するため、前記データブロックを読み出す手段、前記データブロックの送信中に前記データブロックが前記バッファから廃棄された場合に、廃棄により送信できなかったデータブロックの部分に代えてダミーデータを送信する手段、としてコンピュータを機能させるためのプログラムが提供される。
【発明の効果】
【００１６】
本開示によれば、送信側のバッファで送信中のデータが破棄された場合においても、通信を継続することが可能となる。
【図面の簡単な説明】
【００１７】
【図１】本実施形態に係る、ライブ映像をリアルタイムにエンコードしてアダプティブストリーミング配信するシステムの概要図である。
【図２】送信機において、エンコードしたデータをバッファに蓄積するシーケンスを示す模式図である。
【図３】受信機がデータを取得するシーケンスを示す模式図である。
【図４】プレイリストファイル、 データブロック取得要求、データブロック取得応答の例を示す模式図である。
【図５】送信機において、エンコードしたデータをバッファに蓄積するシーケンスにおいて、データ量がバッファの容量の上限に達した場合のシーケンスを示す模式図である。
【図６】図２のシーケンスに従って、バッファにデータブロックＡ〜Ｄが書き込まれ、データブロックＥのＴＳパケットが書き込まれている様子を示す模式図である。
【図７】バッファにデータブロックＡ〜Ｅが書き込まれ、データ量がバッファの容量の上限に達した場合を示す模式図である。
【図８】バッファ制御部による書き込み処理がエラーとなった後、バッファ制御部１０４が、バッファ内の最も古いデータブロックＡを廃棄した状態を示す模式図である。
【図９】バッファ制御部が、バッファ１０８内の最も古いデータブロックＡを廃棄した後、空いたデータ領域にデータブロックＦのＴＳパケットを書き込んでいる様子を示す模式図である。
【図１０】データブロックの取得中に、取得中のデータブロックがバッファから削除されてしまった場合のデータ取得シーケンスを示す模式図である。
【図１１】本実施形態における。ダミーデータを生成してダウンロード継続させるシーケンスを示す模式図である。
【図１２】バッファ制御部が、バッファ内のデータブロックＡのＴＳパケットを読み込んでいる様子を示す模式図である。
【図１３】図１２に示す状態から、データブロックＡが廃棄された様子を示す模式図である。
【図１４】図１３のエラー発生により、バッファ制御部が、ダミーデータ生成部にダミーデータの生成要求を送った状態を示す模式図である。
【図１５】ＩＥＴＦ ＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇにおける、ダミーデータの概要を示す模式図である。
【図１６】ダミーデータとして送信するＴＳパケットの内容例を示す模式図である。
【図１７】ＭＰ４のファイルフォーマットを簡略化して示す模式図である。
【発明を実施するための形態】
【００１８】
以下に添付図面を参照しながら、本開示の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。
【００１９】
なお、説明は以下の順序で行うものとする。
１．システムの構成例
２．エンコードしたデータをバッファに蓄積するシーケンスの例
３．受信機がデータを取得するシーケンスの例
４．プレイリストファイル、 データブロック取得要求、データブロック取得応答の例
５．データ量がバッファ容量の上限に達した場合のシーケンスの例
６．データブロックの取得中に、取得中のデータブロックがバッファから削除されてしまった場合のデータ取得シーケンスの例
７．ダミーデータを生成してダウンロード継続させるシーケンスの例
８．ダミーデータを生成する動作について
９．ダミーデータとして送信するＴＳパケットの内容例
１０．ＭＰ４のファイルフォーマットの例
【００２０】
１．システムの構成例
まず、図１を参照して、本開示の第１の実施形態に係るシステムの概略構成について説明する。図１は、本実施形態に係る、ライブ映像をリアルタイムにエンコードしてアダプティブストリーミング配信するシステムの概要図を示す。送信機１００と受信機２００は、ＩＰネットワーク２５０を介して接続されている。なお、送信機１００と受信機２００は、無線通信ネットワークを介して接続されるものであってもよい。
【００２１】
送信機１００は、エンコーダ・マルチプレクサ１０２、バッファ制御部１０４、通信部１０６、バッファ１０８、ダミーデータ生成部１１０を有して構成される。送信機１００のエンコーダ・マルチプレクサ１０２は、ビデオカメラ等から送られた映像入力をエンコードし、ＭＥＰＧ２−ＴＳもしくはＭＰ４に多重化する。エンコーダ・マルチプレクサ１０２から出力されたデータは、バッファ制御部１０４を介してバッファ１０８に蓄積される。通信部１０６は、受信機２００からのＨＴＴＰによるデータ取得要求を待ち受け、データ取得要求を受信すると、要求に応じたデータを、バッファ制御部１０４を介してバッファ１０８より取得し、受信機３００へ返信する。
【００２２】
受信機２００は、通信部２０２と、デコーダ・デマルチプレクサ２０４を有して構成される。受信機２００は、通信部２０２からデータの取得要求を送信機１００へ送信し、要求に応じたデータブロックを取得すると、デコーダ・デマルチプレクサ２０４へ取得したデータを送る。デコーダ・デマルチプレクサ２０４は、多重化されたストリームを分離し、デコードしてモニタ等に出力する。
【００２３】
なお、図１に示す構成は、ハードウェア（回路）、または、ＣＰＵ（中央演算処理装置）とこれを機能させるためのソフトウェア（プログラム）から構成することができる。この場合において、そのプログラムは、送信機１００または受信機２００が備えるメモリなどの記憶部、または外部から接続される光ディスク等の記憶媒体に格納されることができる。
【００２４】
２．エンコードしたデータをバッファに蓄積するシーケンスの例
図２は、送信機１００において、エンコードしたデータをバッファ１０８に蓄積するシーケンスを示す模式図である。図２に示すように、バッファ制御部１０４は、ステップＳ１０において、エンコーダ・マルチプレクサ１０２にデータを要求し、ステップＳ１２においてデータを取得する。そして、バッファ制御部１０４は、ステップＳ１４において、取得したデータをバッファ１０８に書き込む。以降、この処理が繰り返し行われる。
【００２５】
３．受信機がデータを取得するシーケンスの例
図３は、受信機２００がデータを取得するシーケンスを示す模式図である。先ず、受信機２００の通信部２０２は、ステップＳ２０においてプレイリストの要求を送信機１００の通信部１０６へ送り、ステップＳ２２において、通信部１０６からプレイリストファイルを取得する。プレイリストファイルには、断片化したファイルのＵＲＬリストが記述されている。ステップＳ２４において、通信部２０２は、プレイリストファイル中のデータブロックＡの取得要求（データブロックＡのＵＲＬ）を送信する。
【００２６】
データ取得要求を受け取った通信部１０６は、バッファ制御部１０４に該当する範囲のデータを要求する（ステップＳ２６）。バッファ制御部１０４は、該当するデータをバッファ１０８へ要求し（ステップＳ２８）、バッファ１０８から該当するデータ読み出して（ステップＳ３０）、通信部１０６に送る（ステップＳ３２）。通信部１０６は、バッファ制御部１０４から送られてきたデータにＨＴＴＰレスポンスヘッダを付与して受信機２００の通信部２０２に送る（ステップＳ３４）。通信部２０２は。デコーダ・マルチプレクサ２０４にデータを送り（ステップＳ３６）、映像が再生される。受信機２００は、データブロックＡのダウンロードが終了すると、プレイリストファイル中の次のデータブロックＢを取得する（ステップＳ４０以降）。プレイリストファイルは再読み込みすることで更新される。
【００２７】
以上のように、アダプティブストリーミングにおいて、断片化されてデータブロック毎に分割されたデータは、受信機２００側がプレイリスト中のＵＲＬを指定してデータブロック毎に要求することで、データブロック毎に送信機１００から送信される。このように、比較的データ長の長いデータを一度に送るのではなく、断片化されたデータブロック事に送ることで、例えばデータの送信中に通信の帯域のビットレートに変化が生じた場合は、受信機２００は、適切なビットレートのデータブロックを要求することができる。従って、帯域が不安定になった場合等においても安定してデータを受信することができ、特にライブ映像のデータを受信する場合等に適している。
【００２８】
図４は、プレイリストファイル、 データブロック取得要求、データブロック取得応答の例を示す模式図である。図４では、ＩＥＴＦ ＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇの場合の例を示している。ＩＥＴＦ ＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇは、ｍ３ｕ８形式のプレイリストファイルを用い、データファイルのフォーマットはＭＰＥＧ２−ＴＳである。このプレイリストでは、８秒毎に断片化された３つのデータブロックが記述されている。１のデータブロックが８秒分のＴＳパケットを含んだ１ファイルのように扱われている。データの取得はＨＴＴＰ ＧＥＴにより行う。
【００２９】
５．データ量がバッファ容量の上限に達した場合のシーケンスの例
図５は、送信機１００において、エンコードしたデータをバッファ１０８に蓄積するシーケンスにおいて、データ量がバッファ１０８の容量の上限に達した場合のシーケンスを示す模式図である。データ量がバッファ１０８の容量の上限に達する前のシーケンスは図２と同様である。データ量がバッファ１０８の容量の上限に達すると、バッファ制御部１０４による書き込み処理がエラーとなるので（ステップＳ１６）、バッファ制御部１０４は、最も古いデータブロックを削除し（ステップＳ１８）、空いた領域にデータを書き込む（ステップＳ２０）。
【００３０】
図６〜図９は、図５の動作を示す模式図である。図６は、図２のシーケンスに従って、バッファ１０８にデータブロックＡ〜Ｄが書き込まれ、データブロックＥのＴＳパケットが書き込まれている様子を示している。
【００３１】
図７は、バッファ１０８にデータブロックＡ〜Ｅが書き込まれ、データ量がバッファ１０８の容量の上限に達した場合を示している。この場合、バッファ１０８にＴＳパケットを書き込むことができなくなるため、バッファ制御部１０４による書き込み処理がエラーとなる。
【００３２】
図８は、バッファ制御部１０４による書き込み処理がエラーとなった後、バッファ制御部１０４が、バッファ１０８内の最も古いデータブロックＡを廃棄した状態を示している。
【００３３】
図９は、バッファ制御部１０４が、バッファ１０８内の最も古いデータブロックＡを廃棄した後、空いたデータ領域にデータブロックＦのＴＳパケットを書き込んでいる様子を示している。図９に示すように、データブロックＡを廃棄したことにより、次のデータブロックＦを書き込むことが可能となる。
【００３４】
６．データブロックの取得中に、取得中のデータブロックがバッファから削除されてしまった場合のデータ取得シーケンスの例
図１０は、データブロックの取得中に、取得中のデータブロックがバッファ１０８から削除されてしまった場合のデータ取得シーケンスを示す模式図である。図１０に示すように、データブロックＡについては、全てのデータが受信機２００に送られる。しかし、データブロックＢについては、２つ目のデータをバッファ１０８から取得している最中に、図５のようにデータブロックＢがバッファ１０８から廃棄されてしまい、バッファ制御部１０４はバッファ１０８からデータブロックＢの以降のデータを取得することができない（ステップＳ４２）。
【００３５】
このように、図１０の例では、データブロックＢのデータを取得中に、データブロックＢが図６〜図８で説明したように破棄されてしまい、これ以降のデータを受信機２００に送ることができない事態が生じている。受信機２００は、データブロックＢの取得要求を送信した直後に、図４に示したデータブロック取得応答を送信機１００から受信するため、データブロックＢのコンテンツのデータ長（Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ）を認識している。このため、受信機２００は、データブロックＢに関し、Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈのサイズを全てダウンロードするまでは、次のデータブロックを取得する処理を行わないため、映像データがこれ以上ダウンロードされないこととなり、ダウンロードが中止してしまう。
【００３６】
このため、本実施形態では、図１０のような事態が生じた場合に、ダミーデータを生成して以降のダウンロードを引き続き行うことを可能としている。
【００３７】
７．ダミーデータを生成してダウンロード継続させるシーケンスの例
図１１は、本実施形態における、ダミーデータを生成してダウンロード継続させるシーケンスを示す模式図である。図１１において、ステップＳ４２までの処理は図１０と同様である。
【００３８】
バッファ制御部１０４は、破棄されたデータを取得しようとした際にデータの読込に失敗すると（ステップＳ４２）、次のステップＳ４４において、不足しているサイズ分のダミーデータを生成するように、ダミーデータ生成部１１０に対して要求する。ダミーデータ生成部１１０は、この要求を受けて、ダミーデータを生成する（ステップＳ４６）。生成されたダミーデータは、バッファ制御部１０４に送られ（ステップＳ４８）、通信部１０６を介して受信機２００の通信部２０２に送られる（ステップＳ５０，Ｓ５２）。
【００３９】
これにより、受信機２００は、図４に示したＣｏｎｔｅｎｔ−Ｌｅｎｇｔｈの分のデータを受信することができる。そして、受信機２００は、Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ分のデータを受け取ると、次のデータブロックＣのダウンロードを開始する（ステップＳ５４）。これにより、バッファ１０８からデータを取得している最中に、そのデータブロックのデータが廃棄されてしまった場合においても、ダウンロードが停止することがなく、以降のデータをダウンロードすることが可能となる。
【００４０】
８．ダミーデータを生成する動作について
図１２〜図１４は、ダミーデータを生成する動作を示す模式図である。図１２は、バッファ制御部１０４が、バッファ１０８内のデータブロックＡのＴＳパケットを読み込んでいる様子を示している。
【００４１】
図１３は、図１２に示す状態から、データブロックＡが廃棄された様子を示している。この場合、バッファ制御部１０４は、廃棄された後はデータブロックＡのＴＳパケットを読み込むことができず、エラーが発生する。
【００４２】
図１４は、図１３のエラー発生により、バッファ制御部１０４が、ダミーデータ生成部１１０にダミーデータの生成要求を送った状態を示している。これにより、ダミーデータ生成部１１０がダミーデータを生成し、生成されたダミーデータは、バッファ制御部１０４へ送られ、更にバッファ制御部１０４、通信部１０６を介して受信機２００へ送られる。
【００４３】
図１５は、ＩＥＴＦ ＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇにおける、ダミーデータの概要を示す模式図である。図１５では、バッファ１０４のデータブロックＡが廃棄されたことにより、ステップＳ４２において、ＴＳパケット３００，３０２，３０４の送信中にデータブロックが破棄されている。１つ目、２つ目のＴＳパケット３００，３０２については受信機２００側に送信されるものの、３つ目のＴＳパケット３０４が途中で分断され、ＴＳパケットは一部のみが送信されている。ダミーデータ４００は、その分断されたＴＳパケット３０４の送信されなかった分を補完するデータ４０２と、未送信のＴＳパケット分のＮＵＬＬパケット４０４（４つ目のＴＳパケットに相当）から構成され、通信部１０６を介して受信機２００の通信部２０２へ送信される。
【００４４】
ＩＥＴＦ ＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇにおける，生成するダミーデータのサイズを求める式は以下の通りである。
データブロックサイズ＝ＴＳパケットサイズ×パケット数
ダミーデータとして送信するＮＵＬＬパケットの数＝(データブロックサイズ−送信済データサイズ)／ＴＳパケットサイズ
(断片化したＴＳを補完するダミーデータのサイズ＝(データブロックサイズ−送信済データサイズ)÷ＴＳパケットサイズ)
【００４５】
データブロックは、ある一定数のＴＳパケットで構成され、１つのＴＳパケットは、１８８バイト(タイムスタンプつきＴＳの場合は１９２バイトである。
従って、データブロックのサイズは、
１８８バイト(タイムスタンプつきＴＳの場合は１９２バイト)×パケット数
となる。
【００４６】
ダミーデータとして送るＮＵＬＬパケット４０４の数は 、
(データブロックサイズ−送信済データサイズ)／ＴＳパケットサイズ
であり、断片化したＴＳパケットを補完するデータ４０２のサイズは、その余りである。
【００４７】
９．ダミーデータとして送信するＴＳパケットの内容例
図１６は、ダミーデータとして送信するＴＳパケット（ＮＵＬＬパケット４０４）の内容例を示す模式図である。ＮＵＬＬパケット４０４の各データは、例えば無効なデータに設定される。タイムスタンプつきＴＳの場合、ＴＳ（タイムスタンプ）は０とする。また、同期ワードは（０ｘ４７）とする。
【００４８】
また、図１６に示すトランスポートエラーインジケータＡ（１ｂｉｔ）としては、エラーを示す１を設定し、ペイロードユニットスタートインジケータＢ（１ｂｉｔ）、トランスポート優先度Ｃ（１ｂｉｔ）にはそれぞれ０を設定する。また、パケット識別子（１３ｂｉｔ）には、ＮＵＬＬパケットを示す（０ｘ１ｆｆ）を設定する。トランスポートスクランブルコントロールＤ（２ｂｉｔ）、アダプテーションフィールドコントロールＥ（２ｂｉｔ）、巡回カウンターＦ（４ｂｉｔ）にもそれぞれ０を設定し、ペイロード（１８４ｂｙｔｅ）は、ダミーデータ(たとえば０ｘ００や０ｘＦＦ)に設定する。断片化したＴＳパケットを補完するダミーデータ４００は、このＮＵＬＬパケット４０４の一部から生成する。通信部１０６は、バッファ１０４から読み出したデータ量を検知できるため、各データブロックの送信済のデータ量を検知できる。従って、通信部１０６は、３つ目のＴＳパケット３０４の全データが送信できなかったこと、及び３つ目のＴＳパケット３０４が何ビットまで送信されたかを検知することができる。各ＴＳパケットは、ＴＳ（タイムスタンプ）、同期ワード、トランスポートエラーインジケータＡ、ペイロードユニットスタートインジケータＢの順で送信されるため、通信部１０６は、３つ目のＴＳパケット３０４がどの部分まで送信されたかを検知できる。ダミーデータ生成部１１０は、これらの情報に基づいて、上述した計算式により、ＴＳパケット３０４の未送信分のデータ量に相当するダミーデータ４００を生成するとともに、このＮＵＬＬパケット４０４を生成する。
【００４９】
１０．ＭＰ４のファイルフォーマットの例
Ａｄｏｂｅ ＨＴＴＰ Ｄｙｎａｍｉｃ Ｓｔｒｅａｍｉｎｇや、Ｍｉｒｏｓｏｆｔ ＨＴＴＰ Ｓｍｏｏｔｈ Ｓｔｒｅａｍｉｎｇの場合、プレイリストファイルの形式がそれぞれ異なるが、同様の方法でダミーデータ生成を行うことができる。
【００５０】
これらの方式では、データファイルのフォーマットは、ＭＰＥＧ２−ＴＳではなくＭＰ４となるが、ＭＰＥＧ２−ＴＳの場合と同様に、送信されるべきデータ長と、送信済みデータ量とから、未送信分のデータ量を算出することができる。従って、未送信分のデータ量に基づいてダミーデータを生成することが可能である。図１７は、ＭＰ４のファイルフォーマットを簡略化して示す模式図である。１つのＭＰ４ファイルは、主にＭＯＯＶ（Ｍｏｖｉｅ Ｍｅｔａｄａｔａ）とＭＯＯＦ（Ｍｏｖｉｅ Ｆｒａｇｍｅｎｔ）で構成される。上述したＩＥＴＦ ＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇの場合、１つのデータブロックが１つのファイルであるように扱われていたが、ＭＰ４を利用する方式の場合は、１データブロックが１つのＭＯＯＦ（Ｍｏｖｉｅ Ｆｒａｇｍｅｎｔ）に対応するようになる。ＭＯＯＦは可変長であるが、 (データブロック長−送信済データ長)のデータサイズのダミーデータ(たとえば０ｘ００や０ｘＦＦ)をダミーデータ生成部１１０で生成することによって、通信部１０６からダミーデータを送信することができる.
【００５１】
以上説明したように本実施形態によれば、送信機１００側のバッファリングなどで吸収しきれずにエラーとなった場合においても、通信が終了することがなく、通信を継続させることが可能となる。
【００５２】
以上、添付図面を参照しながら本開示の好適な実施形態について詳細に説明したが、本開示の技術的範囲はかかる例に限定されない。本開示の技術分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本開示の技術的範囲に属するものと了解される。
【００５３】
なお、以下のような構成も本開示の技術的範囲に属する。
（１）複数のデータブロックが蓄積されるバッファと、
前記データブロックを送信するため、前記バッファから前記データブロックを読み出すバッファ制御部と、
前記データブロックの送信中に前記データブロックが前記バッファから廃棄された場合に、廃棄により送信できなかったデータブロックの前記部分に代えてダミーデータを送信する送信部と、
を備える、通信装置。
【００５４】
（２）前記データブロックの送信中に前記データブロックが前記バッファから廃棄された場合に、廃棄により送信できなかったデータブロックの部分に相当するダミーデータを生成するダミーデータ生成部を備え、
前記送信部は、前記バッファから読み出された前記データブロックを送信するとともに、前記ダミーデータが生成された場合は、廃棄により送信できなかったデータブロックの前記部分に代えて前記ダミーデータを送信する、前記（１）に記載の通信装置。
【００５５】
（３）前記データはＭＰＥＧ２−ＴＳ形式であり、所定数のＴＳパケットが前記データブロックを構成し、
前記ダミーデータ生成部は、前記データブロックの送信中に前記データブロックが廃棄された場合は、途中で分断されたＴＳパケットの未送信分に相当するデータと、未送信のＴＳパケットとを含む前記ダミーデータを生成する、前記（２）に記載の通信装置。
【００５６】
（４）前記データはＭＰ４形式であり、ＭＯＯＦが前記データブロックを構成し、
前記ダミーデータ生成部は、前記データブロックの送信中に前記データブロックが廃棄された場合は、前記ＭＯＯＦの未送信分に相当するデータを前記ダミーデータとして生成する、前記（３）に記載の通信装置。
【００５７】
（５）複数のデータブロックが蓄積されるバッファと、
送信要求に応じて前記データブロックを送信するため、前記バッファから前記データブロックを読み出すバッファ制御部と、
前記データブロックの送信中に前記データブロックが前記バッファから廃棄された場合に、廃棄により送信できなかったデータブロックの前記部分に代えてダミーデータを送信する送信部と、
を備える、通信装置と、
前記送信要求を前記送信装置に送信し、前記送信部から送信された前記データブロック及び前記ダミーデータを受信する受信装置と、
を備える、通信システム。
【００５８】
（６）複数のデータブロックが蓄積されたバッファから、前記データブロックを送信するため、前記データブロックを読み出すことと、
前記データブロックの送信中に前記データブロックが前記バッファから廃棄された場合に、廃棄により送信できなかったデータブロックの前記部分に代えてダミーデータを送信することと、
を備える、通信方法。
【００５９】
（７）複数のデータブロックが蓄積されたバッファから、前記データブロックを送信するため、前記データブロックを読み出す手段、
前記データブロックの送信中に前記データブロックが前記バッファから廃棄された場合に、廃棄により送信できなかったデータブロックの前記部分に代えてダミーデータを送信する手段、
としてコンピュータを機能させるためのプログラム。
【符号の説明】
【００６０】
１００ 送信機
１０４ バッファ制御部
１０６ 通信部
１０８ バッファ
１１０ ダミーデータ生成部
２００ 受信機
【特許請求の範囲】
【請求項１】
複数のデータブロックが蓄積されるバッファと、
前記データブロックを送信するため、前記バッファから前記データブロックを読み出すバッファ制御部と、
前記データブロックの送信中に前記データブロックが前記バッファから廃棄された場合に、廃棄により送信できなかったデータブロックの部分に代えてダミーデータを送信する送信部と、
を備える、通信装置。
【請求項２】
前記データブロックの送信中に前記データブロックが前記バッファから廃棄された場合に、廃棄により送信できなかったデータブロックの前記部分に相当するダミーデータを生成するダミーデータ生成部を備え、
前記送信部は、前記バッファから読み出された前記データブロックを送信するとともに、前記ダミーデータが生成された場合は、廃棄により送信できなかったデータブロックの前記部分に代えて前記ダミーデータを送信する、請求項１に記載の通信装置。
【請求項３】
前記データはＭＰＥＧ２−ＴＳ形式であり、所定数のＴＳパケットが前記データブロックを構成し、
前記ダミーデータ生成部は、前記データブロックの送信中に前記データブロックが廃棄された場合は、途中で分断されたＴＳパケットの未送信分に相当するデータと、未送信のＴＳパケットとを含む前記ダミーデータを生成する、請求項２に記載の通信装置。
【請求項４】
前記データはＭＰ４形式であり、ＭＯＯＦが前記データブロックを構成し、
前記ダミーデータ生成部は、前記データブロックの送信中に前記データブロックが廃棄された場合は、前記ＭＯＯＦの未送信分に相当するデータを前記ダミーデータとして生成する、請求項２に記載の通信装置。
【請求項５】
複数のデータブロックが蓄積されるバッファと、
送信要求に応じて前記データブロックを送信するため、前記バッファから前記データブロックを読み出すバッファ制御部と、
前記データブロックの送信中に前記データブロックが前記バッファから廃棄された場合に、廃棄により送信できなかったデータブロックの部分に代えてダミーデータを送信する送信部と、
を備える、通信装置と、
前記送信要求を前記送信装置に送信し、前記送信部から送信された前記データブロック及び前記ダミーデータを受信する受信装置と、
を備える、通信システム。
【請求項６】
複数のデータブロックが蓄積されたバッファから、前記データブロックを送信するため、前記データブロックを読み出すことと、
前記データブロックの送信中に前記データブロックが前記バッファから廃棄された場合に、廃棄により送信できなかったデータブロックの部分に代えてダミーデータを送信することと、
を備える、通信方法。
【請求項７】
複数のデータブロックが蓄積されたバッファから、前記データブロックを送信するため、前記データブロックを読み出す手段、
前記データブロックの送信中に前記データブロックが前記バッファから廃棄された場合に、廃棄により送信できなかったデータブロックの部分に代えてダミーデータを送信する手段、
としてコンピュータを機能させるためのプログラム。
【請求項１】
複数のデータブロックが蓄積されるバッファと、
前記データブロックを送信するため、前記バッファから前記データブロックを読み出すバッファ制御部と、
前記データブロックの送信中に前記データブロックが前記バッファから廃棄された場合に、廃棄により送信できなかったデータブロックの部分に代えてダミーデータを送信する送信部と、
を備える、通信装置。
【請求項２】
前記データブロックの送信中に前記データブロックが前記バッファから廃棄された場合に、廃棄により送信できなかったデータブロックの前記部分に相当するダミーデータを生成するダミーデータ生成部を備え、
前記送信部は、前記バッファから読み出された前記データブロックを送信するとともに、前記ダミーデータが生成された場合は、廃棄により送信できなかったデータブロックの前記部分に代えて前記ダミーデータを送信する、請求項１に記載の通信装置。
【請求項３】
前記データはＭＰＥＧ２−ＴＳ形式であり、所定数のＴＳパケットが前記データブロックを構成し、
前記ダミーデータ生成部は、前記データブロックの送信中に前記データブロックが廃棄された場合は、途中で分断されたＴＳパケットの未送信分に相当するデータと、未送信のＴＳパケットとを含む前記ダミーデータを生成する、請求項２に記載の通信装置。
【請求項４】
前記データはＭＰ４形式であり、ＭＯＯＦが前記データブロックを構成し、
前記ダミーデータ生成部は、前記データブロックの送信中に前記データブロックが廃棄された場合は、前記ＭＯＯＦの未送信分に相当するデータを前記ダミーデータとして生成する、請求項２に記載の通信装置。
【請求項５】
複数のデータブロックが蓄積されるバッファと、
送信要求に応じて前記データブロックを送信するため、前記バッファから前記データブロックを読み出すバッファ制御部と、
前記データブロックの送信中に前記データブロックが前記バッファから廃棄された場合に、廃棄により送信できなかったデータブロックの部分に代えてダミーデータを送信する送信部と、
を備える、通信装置と、
前記送信要求を前記送信装置に送信し、前記送信部から送信された前記データブロック及び前記ダミーデータを受信する受信装置と、
を備える、通信システム。
【請求項６】
複数のデータブロックが蓄積されたバッファから、前記データブロックを送信するため、前記データブロックを読み出すことと、
前記データブロックの送信中に前記データブロックが前記バッファから廃棄された場合に、廃棄により送信できなかったデータブロックの部分に代えてダミーデータを送信することと、
を備える、通信方法。
【請求項７】
複数のデータブロックが蓄積されたバッファから、前記データブロックを送信するため、前記データブロックを読み出す手段、
前記データブロックの送信中に前記データブロックが前記バッファから廃棄された場合に、廃棄により送信できなかったデータブロックの部分に代えてダミーデータを送信する手段、
としてコンピュータを機能させるためのプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【公開番号】特開２０１２−２５７０４１（Ｐ２０１２−２５７０４１Ａ）
【公開日】平成２４年１２月２７日（２０１２．１２．２７）
【国際特許分類】
【出願番号】特願２０１１−１２８３５８（Ｐ２０１１−１２８３５８）
【出願日】平成２３年６月８日（２０１１．６．８）
【出願人】（０００００２１８５）ソニー株式会社 (34,172)
【Ｆターム（参考）】
【公開日】平成２４年１２月２７日（２０１２．１２．２７）
【国際特許分類】
【出願日】平成２３年６月８日（２０１１．６．８）
【出願人】（０００００２１８５）ソニー株式会社 (34,172)
【Ｆターム（参考）】
[ Back to top ]