JP2018170770A - コンテンツ配信システム - Google Patents

Abstract

【課題】ＨＴＴＰに準拠して動画を配信する場合に、ＩＰマルチキャスト通信を用い、さらに、再生ロスを可及的に減少させる。
【解決手段】ファイルパケット化装置３００は、動画配信サービスのプレイリストファイルおよび動画セグメントファイルをＵＤＰパケットに分割してＩＰマルチキャストで配信する。ファイル再構築装置４００は、ファイルパケット化装置３００からＩＰマルチキャストで配信されるＵＤＰパケットを受信し、プレイリストファイルおよび動画セグメントファイルを再構築する。ファイル再構築装置４００はＵＤＰパケットの損失がある場合に対応する部分にＴＳパケットのヌルパケットを挿入する。端末装置６００はファイル再構築装置４００からＨＴＴＰに準拠してプレイリストファイルおよび動画セグメントファイルを取得して動画を再生する。
【選択図】 図２

Description

この発明は、テレビ放送等の動画コンテンツをマルチキャスト配信するコンテンツ配信システムに関する。

通信ネットワークを使用してテレビ放送を配信するテレビ放送配信サービス等、種々の動画配信サービスが提供されている。テレビ放送は多くの視聴者が同時に視聴を行うのでマルチキャスト送信を利用することが好ましい（特許文献１および特許文献２）。ところで、インターネットにおいては、上位プロトコルとしてＨＴＴＰを使用することが多く、ＨＴＴＰに準拠して、動画を送信する、動画配信サービスが提供されている（例えば、米国アップル社のＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇ）。このような動画配信サービスでは、複数の動画セグメントファイルをプレイリスト情報を参照して配信している。しかしながら、ＨＴＴＰに準拠した動画配信サービスをマルチキャスト送信により実現しようとする場合、コネクションレスのＵＤＰを用いるため、通信ロスが生じやすく、セグメントファイル単位で再生ロスの原因となる。通常のデジタルテレビ放送の場合、ＭＰＥＧ２−ＴＳパケット単位（１８８バイト固定長）での情報ロスになり、映像中に横方向に太さ１６ドットの筋状のノイズが、０．５秒程度あらわれる程度であるけれども、ＩＰマルチキャストのＵＤＰパケットに起因して、セグメントファイル単位で情報ロスが生じると、数秒〜数十秒の間、映像が停止してしまう。

上述の従来技術やその問題点は、この発明の背景の一部を説明するためにのみ説明している。この発明は上述の従来技術や問題点に限定されるものではない点に留意されたい。

特開２００２−１８５９４３号公報 特表２００３−５２２４４２号公報

この発明は、以上の事情を考慮してなされたものであり、ＨＴＴＰに準拠して動画を配信する場合に、ＩＰマルチキャスト通信を用い、さらに、再生ロスを可及的に減少させるコンテンツ配信技術を提供することを目的としている。

この発明によれば、上述の目的を達成するために、特許請求の範囲に記載のとおりの構成を採用している。ここでは、発明を詳細に説明するのに先だって、特許請求の範囲の記載について補充的に説明を行なっておく。

この発明の一側面によれば、上述の目的を達成するために、通信ネットワークに接続可能な動画コンテンツ処理装置を：複数のＴＳパケットを含む動画ファイルを分解してＩＰマルチキャスト送信されてくるＵＤＰパケットを受け取るＵＤＰパケット受信手段と；上記ＵＤＰパケット受信手段が受け取ったＵＤＰパケットから上記動画ファイルに再構築する動画ファイル再構築手段と；上記動画ファイル再構築手段が再構築した上記動画ファイルを上記通信ネットワークを介してユーザ端末にＨＴＴＰに準拠して送信する送信手段とを含んで構成し；上記動画ファイル再構築手段は、上記動画ファイルに対応する複数のＵＤＰパケットのうちの少なくとも１つのＵＤＰパケットを受け取らない場合に、完全なＴＳパケットのみを含む態様で上記動画ファイルを再構築するようにしている。

また、この発明の他の側面によれば、上述の目的を達成するために、通信ネットワークに接続可能なユーザ端末を：複数のＴＳパケットを含む動画ファイルを再生する再生手段と；複数のＴＳパケットを含む動画ファイルを分解してＩＰマルチキャスト送信されてくるＵＤＰパケットを受け取るＵＤＰパケット受信手段と；上記ＵＤＰパケット受信手段が受け取ったＵＤＰパケットから上記動画ファイルに再構築してＨＴＴＰに準拠して上記再生手段に供給する動画ファイル再構築手段とを含んで構成し；上記動画ファイル再構築手段は、上記動画ファイルに対応する複数のＵＤＰパケットのうちの少なくとも１つのＵＤＰパケットを受け取らない場合に、完全なＴＳパケットのみを含む態様で上記動画ファイルを再構築するようにしている。

また、この発明の他の側面によれば、上述の目的を達成するために、コンピュータプログラムが、通信ネットワークに接続可能なユーザ端末を：複数のＴＳパケットを含む動画ファイルを再生する再生手段；複数のＴＳパケットを含む動画ファイルを分解してマルチキャスト送信されてくるＵＤＰパケットを受け取るＵＤＰパケット受信手段；上記ＵＤＰパケット受信手段が受け取ったＵＤＰパケットから上記動画ファイルを再構築してＨＴＴＰに準拠して上記再生手段に供給する動画ファイル再構築手段として実現させるために使用され；上記動画ファイル再構築手段は、上記動画ファイルに対応する複数のＵＤＰパケットのうちの少なくとも１つのＵＤＰパケットを受け取らない場合に、完全なＴＳパケットのみを含む態様で上記動画ファイルを再構築するようになっている。

また、この発明の他の側面によれば、上述の目的を達成するために、コンピュータプログラムが、通信ネットワークに接続可能な動画コンテンツ処理装置を：複数のＴＳパケットを含む動画ファイルを分解してＩＰマルチキャスト送信されてくるＵＤＰパケットを受け取るＵＤＰパケット受信手段；上記ＵＤＰパケット受信手段が受け取ったＵＤＰパケットから上記動画ファイルに再構築する動画ファイル再構築手段；上記動画ファイル再構築手段が再構築した上記動画ファイルを上記通信ネットワークを介してユーザ端末にＨＴＴＰに準拠して送信する送信手段として実現させるために使用され；上記動画ファイル再構築手段は、上記動画ファイルに対応する複数のＵＤＰパケットのうちの少なくとも１つのＵＤＰパケットを受け取らない場合に、完全なＴＳパケットのみを含む態様で上記動画ファイルを再構築するようになっている。

この構成において、上記受け取られなかったＵＤＰパケットに対応する部分にＴＳパケットのヌルパケットを用いて完全なＴＳパケットのみを含む態様で上記動画ファイルを再構築して良い。

この構成において、上記第１の処理装置は、いずれのＴＳパケットも２つの前後するＵＤＰパケットに跨って分割されないようにして良い。

また、この構成において、上記第１の処理装置から送信される上記ＵＤＰパケットは、完全な複数のＴＳパケットとパッド部とを含み、上記第２の処理装置は、受け取ったＵＤＰパケットに含まれる完全な複数のＴＳパケットから上記動画ファイルを再構築する請求項６記載の動画コンテンツ処理装置。

また、この構成において、上記動画ファイルは、ＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇ（米国アップル社の商標）、ＭＰＥＧ−ＤＡＳＨ（ＩＳＯ／ＩＥＣ２３００９−１）、ＨＴＴＰ Ｄｙｎａｍｉｃ Ｓｔｒｅａｍｉｎｇ（米国Ａｄｏｂｅ Ｓｙｓｔｅｍｓ社の商標）、または、Ｓｍｏｏｔｈ Ｓｔｒｅａｍｉｎｇ（米国Ｍｉｃｒｏｓｏｆｔ社の商標）のＨＴＴＰストリーミング手法により送信されて良い。

さらに、ここで説明する技術的特徴についてまとめておく。ここで説明する技術的特徴の一側面によれば、上述の目的を達成するために、動画コンテンツ配信システムを：複数のＴＳパケットを含む動画ファイルをＵＤＰパケットに分解してＩＰマルチキャスト送信する第１の処理装置と；上記第１の処理装置からＩＰマルチキャスト送信されてくるＵＤＰパケットを受け取って動画ファイルに再構築してユーザ端末にＨＴＴＰに準拠して送信する第２の処理装置とを含んで構成し；上記第２の処理装置は、上記動画ファイルに対応する複数のＵＤＰパケットのうちの少なくとも１つのＵＤＰパケットを受け取らない場合に、完全なＴＳパケットのみを含む態様で上記動画ファイルを再構築するようにしている。

ＴＳパケットは、トランスポートストリームを構成するパケット（トランスポートストリームパケット）であり、典型的には、ＭＰＥＧ２−ＴＳ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ ２ Ｔｒａｎｓｐｏｒｔ Ｓｔｒｅａｍ）の規格に規定されるＭＰＥＧ−２ ＴＳパケットであるけれども、これに限定されない。

動画ファイルは、映像データおよび音声データを含んで良く、典型的には、ＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇ（米国アップル社）、ＭＰＥＧ−ＤＡＳＨ（ＩＳＯ／ＩＥＣ２３００９−１）、ＨＴＴＰ Ｄｙｎａｍｉｃ Ｓｔｒｅａｍｉｎｇ（米国Ａｄｏｂｅ Ｓｙｓｔｅｍｓ社）、Ｓｍｏｏｔｈ Ｓｔｒｅａｍｉｎｇ（米国Ｍｉｃｒｏｓｏｆｔ社）等のＨＴＴＰストリーミング手法で送信する動画ファイル（セグメントファイル）であって良い。

この構成において、上記受け取られなかったＵＤＰパケットに対応する部分にＴＳパケットのヌルパケット（ＮＵＬＬパケット）を用いて完全なＴＳパケットのみを含む態様で上記動画ファイルを再構築してよい。

ヌルパケット（ＮＵＬＬパケット）は、パケットの内容が無効であることを示すものであり、ヘッダを含むすべてのビットが「１」である。ヌルパケットに代えて、動画を再生する際に、パケットの内容が利用できないことを示すパケット、または再生側でそのように解釈できるように構成されている場合には、そのような特定のパケットを採用して良い。、また、ＭＰＥＧ−２ ＴＳパケットのヘッダのトランスポートエラーインジケータフラグを「１」にセットしたパケットでもよい。

また、上記第１の処理装置は、いずれのＴＳパケットも２つの前後するＵＤＰパケットに跨って分割されないようにしてよい。

この場合、上記第１の処理装置から送信される上記ＵＤＰパケットは、完全な複数のＴＳパケットとパッド部とを含んで良く、上記第２の処理装置は、受け取ったＵＤＰパケットに含まれる完全な複数のＴＳパケットから上記動画ファイルを再構築してよい。

また、上記第１の処理装置は、動画サーバから、複数のＴＳパケットを含む動画ファイルをＨＴＴＰに準拠して受け取り、上記動画ファイルをＵＤＰパケットに分解してマルチキャスト送信してよい。

また、ここで説明する技術的特徴の他の側面によれば、上述の目的を達成するために、複数のＴＳパケットを含む動画ファイルを分解してＩＰマルチキャスト送信されてくるＵＤＰパケットを受け取って上記動画ファイルに再構築する処理装置は、上記動画ファイルに対応する複数のＵＤＰパケットのうちの少なくとも１つのＵＤＰパケットを受け取らない場合に、完全なＴＳパケットのみを含む態様で上記動画ファイルを再構築する。

また、ここで説明する技術的特徴の他の側面によれば、上述の目的を達成するために、複数のＴＳパケットを含む動画ファイルを分解してＩＰマルチキャスト送信されてくるＵＤＰパケットを受け取って上記動画ファイルに再構築して再生するユーザ端末は、上記動画ファイルに対応する複数のＵＤＰパケットのうちの少なくとも１つのＵＤＰパケットを受け取らない場合に、完全なＴＳパケットのみを含む態様で上記動画ファイルを再構築する。

また、ここで説明する技術的特徴の他の側面によれば、上述の目的を達成するために、コンピュータプログラムが、通信ネットワークに接続可能なユーザ端末を：複数のＴＳパケットを含む動画ファイルを分解してＩＰマルチキャスト送信されてくるＵＤＰパケットを受け取る手段と；上記受け取ったＵＤＰパケットから上記動画ファイルを再構築する手段と；再構築された上記動画ファイルを再生する手段として実現させ、再構築する手段は、上記動画ファイルに対応する複数のＵＤＰパケットのうちの少なくとも１つのＵＤＰパケットを受け取らない場合に、完全なＴＳパケットのみを含む態様で上記動画ファイルを再構築する。

また、ここで説明する技術的特徴の他の側面によれば、動画コンテンツ配信システムに：ＨＴＴＰサーバから受信した複数のＴＳパケットを含む動画ファイルをＵＤＰパケットに分解してＩＰマルチキャスト送信する第１の処理装置と；上記第１の処理装置からＩＰマルチキャスト送信されてくるＵＤＰパケットを受け取って動画ファイルに再構築してユーザ端末にＨＴＴＰに準拠して送信する第２の処理装置とを設けるようにしている。

また、ここで説明する技術的特徴のさらに他の側面によれば、動画配信システムに：複数のＴＳパケットを含む動画ファイルをＵＤＰパケットに分解してＩＰマルチキャスト送信する第１の処理装置と；上記第１の処理装置からＩＰマルチキャスト送信されてくるＵＤＰパケットを受け取って動画ファイルに再構築してユーザ端末にＨＴＴＰに準拠して送信する第２の処理装置とを設け；上記第２の処理装置は、ＨＴＴＰヘッダに対応するＵＤＰパケットを受け取らない場合に、クライアント装置から、当該ＵＤＰパケットを含む動画ファイルを送信するようにＨＴＴＰ要求を受けたときに、コンテンツ長がゼロであることを示すＨＴＴＰ応答を返すようにしている。

動画ファイルのＨＴＴＰヘッダの部分がＵＤＰパケットの損失で正確に記述されない場合などでは、再生がフリーズする等の問題があるけれども、この構成では、当該動画ファイルの再生がスキップされて、後続の動画ファイルが適宜に再生可能になる。

なお、この発明は装置またはシステムとして実現できるのみでなく、方法としても実現可能である。また、そのような発明の一部をソフトウェアとして構成することができることはもちろんである。またそのようなソフトウェアをコンピュータに実行させるために用いるソフトウェア製品もこの発明の技術的な範囲に含まれることも当然である。

この発明の上述の側面および他の側面は特許請求の範囲に記載され以下実施例を用いて詳述される。

この発明の実施例の動画コンテンツ配信システムが実行される環境を説明する図である。 図１の動画コンテンツ配信システムの動作例の概要を説明する図である。 図１のファイルパケット化装置３００の構成例を示す機能ブロック図である。 ＨＴＴＰファイルのパケット化の例を説明する図である。 図１のファイル再構築装置４００の構成例を示す機能ブロック図である。 図１のファイル再構築装置４００の動作例を説明する図である。 図６のヌルパケット挿入部４０３の動作例を説明する図である。 図１のＵＤＰ非対応端末装置６００をなす携帯端末の構成例を説明する機能ブロック図である。 従来のＨＴＴＰ準拠の動画配信サービスを説明する図である。 図９の動画配信サービスの動作例を説明する図である。 図１０の動作例におけるＨＴＴＰ電文サンプルを説明する図である。 図６のＵＤＰ対応端末装置７００の構成例を示す機能ブロック図である。 変形例を説明する図である。

以下、この発明の実施例について説明する。

図１は、この発明の動画コンテンツ配信システムの１実施例を示しており、この図において、動画コンテンツ配信システム１００は、ＨＴＴＰ配信サーバ２００、ファイルパケット化装置３００、ファイル再構築装置４００、コンテンツ配信ネットワーク５００、ＵＤＰ非対応端末装置６００、およびＵＤＰ対応端末装置７００等を含んで構成されている。ファイル再構築装置４００は、後述するように、ファイルパケット化装置３００からＩＰマルチキャストでＵＤＰパケットを受け取るものであり、典型的には複数設けられる。ＵＤＰ非対応端末装置６００およびＵＤＰ対応端末装置７００も図では１つしか示されないけれども典型的には複数個設けられる。ＵＤＰ非対応端末装置６００は、位置情報等に基づいてどのファイル再構築装置４００にアクセスするかを決定できる。

コンテンツ配信ネットワーク５００は、ユニキャスト通信のほか、マルチキャスト通信を効率よく実現できるネットワークである。コンテンツ配信ネットワーク５００は、マルチキャスト通信を効率よく実現するために専用のネットワークサービスを利用することが好ましいが、これに限定されない。

ＨＴＴＰ配信サーバ２００は、動画コンテンツ例えばテレビ放送コンテンツのファイルをＨＴＴＰを利用して配信する。このＨＴＴＰ配信サーバ２００は、ＨＴＴＰに準拠してファイルをクライアントに送信して動画コンテンツ配信を行うものであり、例えば、米国アップル社のＨＬＳ（ＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇ）システムであり、ＨＴＴＰに準拠したＷｅｂサーバで実現可能である。この例では、ＨＴＴＰ配信サーバ２００は図示しない通信ネットワークに接続されているけれども、コンテンツ配信ネットワーク５００に接続されても良い。また、ＵＤＰ非対応端末装置６００等は、慣用的な態様と同様に、ＨＴＴＰ配信サーバ２００からＩＰユニキャストで動画コンテンツ配信サービスを利用してよい。

ＨＴＴＰに準拠した動画配信サービスは、図９に示すような、プレイリストファイル（例えばｍ３ｕ８ファイル）および１または複数の動画セグメントファイル（ＭＰＥＧ２−ＴＳセグメントファイル）を用意する。図９の例では、マスターインデックスファイルを用いて解像度の異なる複数（２つ）の代替プレイリストを選択できるようになっている。プレイリストが１つだけであてもよい。代替プレイリスト（プレイリスト）は書き換えられて繰り返し送信されて良い。プレイリストを参照して動画セグメントファイルを順次に取り出すことができる。

ＨＴＴＰ配信サーバ２００は、図１０に示す従来のＨＴＴＰ手順と同様に、ＨＴＴＰクライアントであるファイルパケット化装置３００からのプレイリスト要求（マスターインデックス、代替プレイリストの要求）に基づいてマスターインデックスファイル、代替プレイリストファイル（以下、単にプレイリストと呼ぶことがある）をファイルパケット化装置３００に返す。そののち、ＨＴＴＰ配信サーバ２００は、ファイルパケット化装置３００からのセグメント要求に応じて順次に動画セグメントファイルを返す。動画セグメントファイルは例えばＭＰＥＧ２−ＴＳパケットを含んで構成される。

ファイルパケット化装置３００は、ＨＴＴＰ配信サーバ２００のクライアントとして動画配信サービスのプレイリストファイルおよび動画セグメントファイルを受け取り、これらのファイルをＵＤＰパケットに分割して所定のマルチキャストグループでＩＰマルチキャスト送信する。ファイルパケット化装置３００は、図３に示すように、ＨＴＴＰクライアント処理部３０１、記憶部３０２、パケット化部３０３、および送信部３０４を含んで構成される。

ファイルパケット化装置３００のＨＴＴＰクライアント処理部３０１は、ＨＴＴＰ配信サーバ２００からプレイリストファイルおよび動画セグメントファイルを受信する。図４の（ａ）欄は、ＨＴＴＰクライアント処理部３０１が受信した動画セグメントファイルの例を示す。記憶部３０２は、受信したファイルを記憶する。パケット化部３０３は、ＨＴＴＰクライアント処理部３０１が受信したファイルをＵＤＰパケットに分解する。図４の（ｂ）欄は、図４の（ａ）欄の動画セグメントファイルをＵＤＰパケットに分解したものである。図４の（ａ）欄の動画セグメントファイルは典型的には数秒から数十秒の長さのデータであるが、これに限定されない。図４の（ｂ）欄のＵＤＰパケットは、パケット化ヘッダ、ＨＴＴＰヘッダ、ペイロードを含み、パケットヘッダは、（ｃ）欄に示すように、ヘッダサイズ（ｈｅａｄｅｒ＿ｓｉｚｅ）、ストリーム識別子（ｓｔｒｅａｍ＿ｉｄ）、開始フラグ（ｓｔａｒｔ＿ｆｌａｇ）、総合サイズ（ｔｏｔａｌ＿ｓｉｚｅ）、ペイロードサイズ（ｐａｙｌｏａｄ＿ｓｉｚｅ）、およびペイロードオフセット（ｐａｙｌｏａｄ＿ｏｆｆｓｅｔ）を含む。ヘッダサイズ（ｈｅａｄｅｒ＿ｓｉｚｅ）は、パケット化ヘッダおよびＨＴＴＰヘッダの合計サイズを示し、ストリーム識別子（ｓｔｒｅａｍ＿ｉｄ）は、当該ＵＤＰパケットがどのファイルに所属するかを示す識別子であり、開始フラグ（ｓｔａｒｔ＿ｆｌａｇ）は、先頭のＵＤＰパケットであることを示すフラグであり、総合サイズ（ｔｏｔａｌ＿ｓｉｚｅ）は、ファイルの総バイト数を示し、ペイロードサイズ（ｐａｙｌｏａｄ＿ｓｉｚｅ）は、当該ＵＤＰパケットで送られるファイル部分のバイト数を示し、ペイロードオフセット（ｐａｙｌｏａｄ＿ｏｆｆｓｅｔ）は、当該ＵＤＰパケットで送られるファイル部分の開始位置を示す。その他、前方誤り訂正符号（ＦＥＣ）等を含んでよい。ＵＤＰパケットは典型的にはイーサネットに準拠して１５００バイト以下の固定長であるけれども、これに限定されない。動画コンテンツのＴＳパケットは分割されることなく１つのＵＤＰパケットに含まれ、ＵＤＰパケットの各々でペイロード部分に残余がある場合には、埋め込み部分（パッド）を含ませ良い。

プレイリストファイルも、ＴＳパケットに関連する考慮を除いて、同様にＵＤＰパケット化される。

送信部３０４は、マルチキャストグループを指定してＩＰマルチキャストでＵＤＰパケットを配信する。

ファイル再構築装置４００は、適宜に、ファイルパケット化装置３００のマルチキャストグループに参加し、ファイルパケット化装置３００からコンテンツ配信ネットワーク５００を介してＩＰマルチキャストで送信されるＵＤＰパケットを受信し、プレイリストファイルおよび動画セグメントファイルを再構築する。

ファイル再構築装置４００は、図５に示すように、ＵＤＰパケット受信部４０１、ＵＤＰパケット損失検出部４０２、ヌルパケット挿入部４０３、パケット連結部４０４、記憶部４０５、およびＨＴＴＰサービス部４０６を含む。ＵＤＰパケット受信部４０１は、当該ＩＰマルチキャストのグループに参加し、宛先ポートでＵＤＰパケットを受信するものである。ＵＤＰパケット損失検出部４０２は、動画セグメントファイルを構成するＵＤＰパケットが受信されないときには、これを例えばｐａｙｌｏａｄ−ｓｉｚｅ、ＣＲＣチェックコード、チェックサム等に基づいて検出し、さらに損失位置のＵＤＰパケットをｐａｙｌｏａｄ−０ｆｆｓｅｔから検出し、ヌルパケット挿入部４０３が、これに代えて、ＴＳパケットのヌルパケットを挿入する（図６）。ヌルパケットはヘッダを含めてすべてビットは「１」の値をとるパケットである。プレイリストファイルについては、繰り返し送信されてくるので、ＵＤＰパケット損失が検出されたときには、ファイルを破棄し、次回に送られてくるプレイリストファイルの受信を待って良い。ＵＤＰパケットが動画セグメントファイルのものかプレイリストファイルのものかは、ＵＤＰパケットのＨＰＰＴヘッダに含まれるコンテンツタイプに基づいて判定できる、例えば、図７（ａ）に示すように「Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：ｖｉｄｅｏ／ＭＰ２」の場合には動画セグメントファイルのＵＤＰパケットであると判定して損失部分にＴＳパケットのヌルパケットを挿入する。あるいは、図７（ｂ）に示すようにＨＴＴＰヘッダにＮＰ（ＮＵＬＬ Ｐａｃｋｅｔ）補完フラグのフィールドを設け、動画セグメントファイルのＵＤＰパケットのＨＴＴＰヘッダにＮＰ補完フラグをフラグ付けしてもよい。

ＵＤＰパケット検出部４０２は、ＵＤＰパケットにシリアル番号が付与されるときには、その連続性に基づいてＵＤＰパケットの損失を判別して良い。

なお、プレイリスト応答およびセグメントファイル応答のＨＴＴＰ電文の例は、図１１（ａ）および（ｂ）に示すとおりであり、「Ｃｏｎｔｅｎｔ−Ｔｙｐｅ」を下線で示す。

パケット連結部４０４は、ＵＤＰパケットをｌａｙｌｏａｄ−ｏｆｆｓｅｔ等に基づいて順序付けて、また、動画セグメントファイルの欠損位置にＴＳパケットのヌルパケットを挿入してファイルを再構築する。ファイルを再構築する際には、不要な埋め込み部（Ｐａｄ）は除去される。所定のファイル記憶管理部が、再構築したプレイリストファイルおよび動画セグメントファイルを記憶部４０５に記憶管理する。

ＨＴＴＰサービス部４０６は、ＵＤＰ非対応端末装置６００からのＨＴＴＰの要求に基づいて図１０に示したものと同様の態様でプレイリストファイルおよび動画セグメントファイルをＵＤＰ非対応端末装置６００に返す。ＵＤＰ非対応端末装置６００は受け取ったファイルに基づいて動画を再生する。ＵＤＰ非対応端末装置６００はＨＴＴＰ端末として機能できるものであれば、どのようなものでもよく、典型的にはスマートフォン等の携帯端末であるけれどもこれに限定されず、どのような情報端末（情報化家庭電器製品を含む）であってもよい。

ＵＤＰ非対応端末装置６００を構成する携帯端末の例は、図８に示すようなものである。図８において、携帯端末８００は、処理システム８１０、メモリ８２０、入出力サブシステム８３０、高周波回路部８４０、および音声回路部８５０を含む。構成要素の各々は、適宜、信号処理集積回路、特定用途向け集積回路、を含むハードウェア、ソフトウェア、またはこれらを組み合わせて実現できる。高周波回路部８４０は、他の装置に、無線リンクまたはネットワーク上で情報を送信・受信するのに用いられ、この機能を実行するために、アンテナ・システム、ＲＦ送受信機、増幅器、チューナ、発振器、デジタル信号プロセッサ、ＣＯＤＥＣチップセット、メモリ、その他の周知の回路構成を含むがこれらに限られない。高周波回路部８４０は、時分割多重アクセス（ＴＤＭＡ）、符号分割多重接続（ＣＤＭＡ）等のモバイル通信、無線ＬＡＮ（ＩＥＥＥ ８０２．１１ｂ、ＩＥＥＥ８０２．１１ａ、ＩＥＥＥ８０２．１１ｇ及び／又はＩＥＥＥ８０２．１１Ｎ）、ブルートゥース（ＩＥＥＥ８０２．１５．１）、Ｗｉ−ＭＡＸ（ＩＥＥＥ８０２．１６）等の通信プロトコルを利用できるけれども、これに限定されない。音声回路部８５０は、音声スピーカ８５１とマイクロフォン８５２に連結される。処理システム８１０はプロセッサ８１１、メモリコントローラ８１２、周辺装置インターフェース８１３を含む、メモリ８２０は、プロセッサ８１１が実行するコードやデータを格納する。メモリ８２０は、ＲＡＭ、ＲＯＭ、ＦＬＡＳＨ、ディスク・ドライブ、磁気テープ等の任意の記憶装置を含んで良い。プロセッサ８１１は、メモリ８２０に格納された多様なソフトウェア・コンポーネントを実行する。例えば、ソフトウェア・コンポーネントは、オペレーティング・システム８２１、通信モジュール８２２、接触／動作モジュール８２３、グラフィック・モジュール８２４、アプリケーション８２５、タイマ・モジュール８２６、およびウェブ・ブラウザ・モジュール８２７を含む。アプリケーション８２５は、ブラウザ、アドレス帳、電子メール、暗号化、グローバル・ポジショニング・システム（ＧＰＳ）等の位置決定機能、および、動画コンテンツ再生機能を含む。この実施例では、携帯端末は、例えば、ＵＤＰ非対応端末装置６００として動作し、ＨＴＴＰクライアントおよび動画再生部の少なくとも一部はアプリケーション８２５として実現される。対応するアプリケーションをメモリ８２０にインストールすることにより携帯端末８００をＨＴＴＰクライアントおよび動画再生部として機能させる。

ＵＤＰ対応端末装置７００は、ファイル再構築装置４００の機能を有するものであり、ファイルパケット化装置３００からＩＰマルチキャストで配信されてくるＵＤＰパケットを受信してプレイリストファイルおよび動画セグメントファイルを再構築し動画を再生するものである。ＵＤＰ対応端末装置７００は、ファイル再構築装置４００のＵＤＰパケット損失検出部４０２およびヌルパケット挿入部４０３と同等の機能部によりＵＤＰパケット損失に対応できる。ＵＤＰ対応端末装置７００を図８に示す携帯端末で実現できる。すなわち、図１２に示すように、ＵＤＰ対応装置７００は、ＵＤＰパケット受信部７０１、ＵＤＰパケット損失検出部７０２、ヌルパケット挿入部７０３、パケット連結部７０４、記憶部７０５、動画再生部７０６を含んで構成される。これらのうち、ＵＤＰパケット受信部７０１、ＵＤＰパケット損失検出部７０２、ヌルパケット挿入部７０３、パケット連結部７０４、記憶部７０５は、ファイル再構築装置４００のＵＤＰパケット受信部４０１、ＵＤＰパケット損失検出部４０２、ヌルパケット挿入部４０３、パケット連結部４０４、記憶部４０５と同様に構成して良い。動画再生部７０６は、記憶部７０５に記憶されたプレイリストファイルおよび動画セグメントファイルを用いて動画を再生するものである。この場合、直接にファイルをアクセスするように構成してもよいし、ＨＴＴＰに準拠してファイルを取得してもよい。図１２に示すＵＤＰパケット受信部７０１、ＵＤＰパケット損失検出部７０２、ヌルパケット挿入部７０３、およびパケット連結部７０４等を携帯端末８００のアプリケーション８２５で実現してよい。

図２は、図１の動画コンテンツ配信システム１００の全般的な動作を示す。図２において、動画コンテンツは、ＨＴＴＰ配信サーバ２００からＩＰユニキャストでファイルパケット化装置３００に送られ、さらに、ファイルパケット化装置３００からＩＰマルチキャストでファイル再構築装置４００に送られ、さらに、ＵＤＰ非対応端末装置６００にＩＰユニキャストで送られる。図２では示さないが、ＵＤＰ対応端末装置７００がファイル再構築装置４００の位置に配置され、動画コンテンツをファイルパケット化装置３００からＩＰマルチキャストで受け取って動画を再生する。

まず、ファイルパケット化装置３００は、プレイリストファイルの取得要求をＨＴＴＰ配信サーバ２００に送る（Ｘ０１）。ＨＴＴＰ配信サーバ２００はこれに応じてプレイリストをファイルパケット化装置３００に返す（Ｘ０２）。こののち、ファイルパケット化装置３００は、プレイリストに記述された動画セグメントファイルについて順次に取得要求をＨＴＴＰ配信サーバ２００に送り（Ｘ０３）、ＨＴＴＰ配信サーバ２００はこれに応じて動画セグメントファイルを順次にファイルパケット化装置３００に返す（Ｘ０４）。

ファイルパケット化装置３００は受け取ったプレイリストファイルおよび動画セグメントファイルをＵＤＰパケットに分解してファイル再構築装置４００にＩＰマルチキャストで配信する（Ｘ０５）。以上の処理Ｘ０１〜Ｘ０５が繰り返し実行される。

ファイル再構築装置４００は受け取ったＵＤＰパケットからプレイリストファイルおよび動画セグメントファイルを再構築して記憶部４０５に記憶保持する（Ｘ０６、Ｘ０７）。なお、動画セグメントファイルの再構築に際してＵＤＰのパケット損失がある場合にはこれをヌルパケットに置換する。プレイリストファイルを再構築するときにＵＤＰパケットの損失がある場合には、大構築中のプレイリストファイルを破棄し、次回に配信されてくるプレイリストファイルのＵＤＰパケットにより再構築を行う。

ファイル再構築装置４００は、ＵＤＰ非対応端末装置６００に対してＨＴＴＰサーバとして機能する。すなわち、ＵＤＰ非対応端末装置６００は、プレイリストファイルの取得要求をファイル再構築装置４００に送る（Ｘ０８）。ファイル再構築装置４００はこれに応じてプレイリストをＵＤＰ非対応端末装置６００に返す（Ｘ０９）。こののち、ＵＤＰ非対応端末装置６００は、プレイリストに記述された動画セグメントファイルについて順次に取得要求をファイル再構築装置４００に送り（Ｘ１０）、ファイル再構築装置４００はこれに応じて動画セグメントファイルを順次にＵＤＰ非対応端末装置６００に返す（Ｘ１１）。ＵＤＰ非対応端末装置６００は動画セグメントファイルに基づいて順次に動画を生成する。

以上で実施例の説明を終了する。

なお、この発明は特許請求の範囲の記載に基づいて決定されるものであり、実施例の具体的な構成、課題、および効果には限定されない。この発明は上述の実施例に限定されるものではなくその趣旨を逸脱しない範囲で種々変更が可能である。

なお、上述の例では、損失ＵＤＰパケットに相当する部分にＴＳパケットのヌルパケットを挿入したけれども、完全なＴＳパケットのみを含むものであれば、ＴＳパケットのヌルパケットを挿入しなくてもよい。例えば、図６の例で、ヌルパケットを除いて、成功裏に受信されたＵＤＰパケットに含まれる完全なＨＴＴＰヘッダおよび完全なＴＳパケットを含むようにファイルを再構築してよい。

また、セグメントファイルの損失ＵＤＰパケットがＨＴＴＰヘッダに相当する場合には、ＨＴＴＰヘッダが棄損している。これに対処するために、当該セグメントファイルについてクライアントからＨＴＴＰ要求があった場合には、コンテンツ長（Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ）がゼロであることを示すＨＴＴＰ応答、例えば図１３に示すようなＨＴＴＰ応答を返して良い。図１３ではコンテンツ長の記述を矢印で示す。この構成では、当該動画ファイルの再生がスキップされて、後続の動画ファイルが、適宜に、例えばＴＳストリームのタイムスタンプに基づくタイミングで、再生できる。このＨＴＴＰ応答には本体は含まれない。

また、上述の例では、ファイルパケット化装置３００はＨＴＴＰ配信サーバ２００からＨＴＴＰに準拠した動画配信用のファイルをＨＴＴＰで取得するようにしたけれども、これらのファイルはファイルパケット化装置３００自体が生成・準備してもよく、また任意のソースから取得してよい。

１００ 動画コンテンツ配信システム
２００ ＨＴＴＰ配信サーバ
３００ ファイルパケット化装置
４００ ファイル再構築装置
５００ コンテンツ配信ネットワーク
６００ ＵＤＰ非対応端末装置
７００ ＵＤＰ対応端末装置
８００ 携帯端末

Claims (8)

1. 通信ネットワークに接続可能な動画コンテンツ処理装置において、
   複数のＴＳパケットを含む動画ファイルを分解してＩＰマルチキャスト送信されてくるＵＤＰパケットを受け取るＵＤＰパケット受信手段と、
   上記ＵＤＰパケット受信手段が受け取ったＵＤＰパケットから上記動画ファイルに再構築する動画ファイル再構築手段と、
   上記動画ファイル再構築手段が再構築した上記動画ファイルを上記通信ネットワークを介してユーザ端末にＨＴＴＰに準拠して送信する送信手段とを有し、
   上記動画ファイル再構築手段は、上記動画ファイルに対応する複数のＵＤＰパケットのうちの少なくとも１つのＵＤＰパケットを受け取らない場合に、完全なＴＳパケットのみを含む態様で上記動画ファイルを再構築することを特徴とする動画コンテンツ処理装置。
2. 通信ネットワークに接続可能なユーザ端末において、
   複数のＴＳパケットを含む動画ファイルを再生する再生手段と、
   複数のＴＳパケットを含む動画ファイルを分解してＩＰマルチキャスト送信されてくるＵＤＰパケットを受け取るＵＤＰパケット受信手段と、
   上記ＵＤＰパケット受信手段が受け取ったＵＤＰパケットから上記動画ファイルに再構築してＨＴＴＰに準拠して上記再生手段に供給する動画ファイル再構築手段とを有し、
   上記動画ファイル再構築手段は、上記動画ファイルに対応する複数のＵＤＰパケットのうちの少なくとも１つのＵＤＰパケットを受け取らない場合に、完全なＴＳパケットのみを含む態様で上記動画ファイルを再構築することを特徴とするユーザ端末。
3. 通信ネットワークに接続可能なユーザ端末を、
   複数のＴＳパケットを含む動画ファイルを再生する再生手段、
   複数のＴＳパケットを含む動画ファイルを分解してマルチキャスト送信されてくるＵＤＰパケットを受け取るＵＤＰパケット受信手段、
   上記ＵＤＰパケット受信手段が受け取ったＵＤＰパケットから上記動画ファイルを再構築してＨＴＴＰに準拠して上記再生手段に供給する動画ファイル再構築手段、
   として実現させるために使用され、
   上記動画ファイル再構築手段は、上記動画ファイルに対応する複数のＵＤＰパケットのうちの少なくとも１つのＵＤＰパケットを受け取らない場合に、完全なＴＳパケットのみを含む態様で上記動画ファイルを再構築することを特徴とするコンピュータプログラム。
4. 通信ネットワークに接続可能な動画コンテンツ処理装置を、
   複数のＴＳパケットを含む動画ファイルを分解してＩＰマルチキャスト送信されてくるＵＤＰパケットを受け取るＵＤＰパケット受信手段、
   上記ＵＤＰパケット受信手段が受け取ったＵＤＰパケットから上記動画ファイルに再構築する動画ファイル再構築手段、
   上記動画ファイル再構築手段が再構築した上記動画ファイルを上記通信ネットワークを介してユーザ端末にＨＴＴＰに準拠して送信する送信手段
   として実現させるために使用され、
   上記動画ファイル再構築手段は、上記動画ファイルに対応する複数のＵＤＰパケットのうちの少なくとも１つのＵＤＰパケットを受け取らない場合に、完全なＴＳパケットのみを含む態様で上記動画ファイルを再構築することを特徴とするコンピュータプログラム。
5. 上記受け取られなかったＵＤＰパケットに対応する部分にＴＳパケットのヌルパケットを用いて完全なＴＳパケットのみを含む態様で上記動画ファイルを再構築する請求項１記載の動画コンテンツ処理装置。
6. 上記第１の処理装置は、いずれのＴＳパケットも２つの前後するＵＤＰパケットに跨って分割されないようにする請求項１記載の動画コンテンツ処理装置。
7. 上記第１の処理装置から送信される上記ＵＤＰパケットは、完全な複数のＴＳパケットとパッド部とを含み、上記第２の処理装置は、受け取ったＵＤＰパケットに含まれる完全な複数のＴＳパケットから上記動画ファイルを再構築する請求項６記載の動画コンテンツ処理装置。
8. 上記動画ファイルは、ＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇ（米国アップル社の商標）、ＭＰＥＧ−ＤＡＳＨ（ＩＳＯ／ＩＥＣ２３００９−１）、ＨＴＴＰ Ｄｙｎａｍｉｃ Ｓｔｒｅａｍｉｎｇ（米国Ａｄｏｂｅ Ｓｙｓｔｅｍｓ社の商標）、または、Ｓｍｏｏｔｈ Ｓｔｒｅａｍｉｎｇ（米国Ｍｉｃｒｏｓｏｆｔ社の商標）のＨＴＴＰストリーミング手法により送信される請求項１、５〜７のいずれかに記載の動画コンテンツ処理装置。

Images