(58)【調査した分野】(Int.Cl.,DB名)
上記第1の処理装置は、動画サーバから、複数のTSパケットを含む動画ファイルをHTTPに準拠して受け取り、上記動画ファイルをUDPパケットに分解してIPマルチキャスト送信する請求項1〜4のいずれかに記載の動画コンテンツ配信システム。
【発明の概要】
【発明が解決しようとする課題】
【0005】
この発明は、以上の事情を考慮してなされたものであり、HTTPに準拠して動画を配信する場合に、IPマルチキャスト通信を用い、さらに、再生ロスを可及的に減少させるコンテンツ配信技術を提供することを目的としている。
【課題を解決するための手段】
【0006】
この発明によれば、上述の目的を達成するために、特許請求の範囲に記載のとおりの構成を採用している。ここでは、発明を詳細に説明するのに先だって、特許請求の範囲の記載について補充的に説明を行なっておく。
【0007】
すなわち、この発明の一側面によれば、上述の目的を達成するために、動画コンテンツ配信システムを:複数のTSパケットを含む動画ファイルをUDPパケットに分解してIPマルチキャスト送信する第1の処理装置と;上記第1の処理装置からIPマルチキャスト送信されてくるUDPパケットを受け取って動画ファイルに再構築してユーザ端末にHTTPに準拠して送信する第2の処理装置とを含んで構成し;上記第2の処理装置は、上記動画ファイルに対応する複数のUDPパケットのうちの少なくとも1つのUDPパケットを受け取らない場合に、完全なTSパケットのみを含む態様で上記動画ファイルを再構築するようにしている。
【0008】
TSパケットは、トランスポートストリームを構成するパケット(トランスポートストリームパケット)であり、典型的には、MPEG2−TS(Moving Picture Experts Group 2 Transport Stream)の規格に規定されるMPEG−2 TSパケットであるけれども、これに限定されない。
【0009】
動画ファイルは、映像データおよび音声データを含んで良く、典型的には、HTTP Live Streaming(米国アップル社)、MPEG−DASH(ISO/IEC23009−1)、HTTP Dynamic Streaming(米国Adobe Systems社)、Smooth Streaming(米国Microsoft社)等のHTTPストリーミング手法で送信する動画ファイル(セグメントファイル)であって良い。
【0010】
この構成において、上記受けとられなかったUDPパケットに対応する部分にTSパケットのヌルパケット(NULLパケット)を用いて完全なTSパケットのみを含む態様で上記動画ファイルを再構築してよい。
【0011】
ヌルパケット(NULLパケット)は、パケットの内容が無効であることを示すものであり、ヘッダを含むすべてのビットが「1」である。ヌルパケットに代えて、動画を再生する際に、パケットの内容が利用できないことを示すパケット、または再生側でそのように解釈できるように構成されている場合には、そのような特定のパケットを採用して良い。、また、MPEG−2 TSパケットのヘッダのトランスポートエラーインジケータフラグを「1」にセットしたパケットでもよい。
【0012】
また、上記第1の処理装置は、いずれのTSパケットも2つの前後するUDPパケットに跨って分割されないようにしてよい。
【0013】
この場合、上記第1の処理装置は、完全な複数のTSパケットとパッド部とを含んで良く、受け取ったUDPパケットに含まれる完全な複数のTSパケットから上記動画ファイルを再構築してよい。
【0014】
また、上記第1の処理装置は、動画サーバから、複数のTSパケットを含む動画ファイルをHTTPに準拠して受け取り、上記動画ファイルをUDPパケットに分解してマルチキャスト送信してよい。
【0015】
また、
関連技術の一側面によれば、上述の目的を達成するために、複数のTSパケットを含む動画ファイルを分解してIPマルチキャスト送信されてくるUDPパケットを受け取って上記動画ファイルに再構築する処理装置は、上記動画ファイルに対応する複数のUDPパケットのうちの少なくとも1つのUDPパケットを受け取らない場合に、完全なTSパケットのみを含む態様で上記動画ファイルを再構築する。
【0016】
また、
関連技術の他の側面によれば、上述の目的を達成するために、複数のTSパケットを含む動画ファイルを分解してIPマルチキャスト送信されてくるUDPパケットを受け取って上記動画ファイルに再構築して再生するユーザ端末は、上記動画ファイルに対応する複数のUDPパケットのうちの少なくとも1つのUDPパケットを受け取らない場合に、完全なTSパケットのみを含む態様で上記動画ファイルを再構築する。
【0017】
また、
関連技術の他の側面によれば、上述の目的を達成するために、コンピュータプログラムが、通信ネットワークに接続可能なユーザ端末を:複数のTSパケットを含む動画ファイルを分解してIPマルチキャスト送信されてくるUDPパケットを受け取る手段と;上記受け取ったUDPパケットから上記動画ファイルを再構築する手段と;再構築された上記動画ファイルを再生する手段として実現させ、再構築する手段は、上記動画ファイルに対応する複数のUDPパケットのうちの少なくとも1つのUDPパケットを受け取らない場合に、完全なTSパケットのみを含む態様で上記動画ファイルを再構築する。
【0018】
また、この発明の他の側面によれば、動画コンテンツ配信システムに:HTTPサーバから
受信した複数のTSパケットを含む動画ファイルをUDPパケットに分解してIPマルチキャスト送信する第1の処理装置と;上記第1の処理装置からIPマルチキャスト送信されてくるUDPパケットを受け取って動画ファイルに再構築してユーザ端末にHTTPに準拠して送信する第2の処理装置とを設けるようにしている。
【0019】
また、この発明のさらに他の側面によれば、動画配信システムに:複数のTSパケットを含む動画ファイルをUDPパケットに分解してIPマルチキャスト送信する第1の処理装置と;上記第1の処理装置からIPマルチキャスト送信されてくるUDPパケットを受け取って動画ファイルに再構築してユーザ端末にHTTPに準拠して送信する第2の処理装置とを設け;上記第2の処理装置は、HTTPヘッダに対応するUDPパケットを受け取らない場合に、クライアント装置から、当該UDPパケットを含む動画ファイルを送信するようにHTTP要求を受けたときに、コンテンツ長がゼロであることを示すHTTP応答を返すようにしている。
【0020】
動画ファイルのHTTPヘッダの部分がUDPパケットの損失で正確に記述されない場合などでは、再生がフリーズする等の問題があるけれども、この構成では、当該動画ファイルの再生がスキップされて、後続の動画ファイルが適宜に再生可能になる。
【0021】
なお、この発明は装置またはシステムとして実現できるのみでなく、方法としても実現可能である。また、そのような発明の一部をソフトウェアとして構成することができることはもちろんである。またそのようなソフトウェアをコンピュータに実行させるために用いるソフトウェア製品もこの発明の技術的な範囲に含まれることも当然である。
【0022】
この発明の上述の側面および他の側面は特許請求の範囲に記載され以下実施例を用いて詳述される。
【発明を実施するための形態】
【0024】
以下、この発明の実施例について説明する。
【0025】
図1は、この発明の動画コンテンツ配信システムの1実施例を示しており、この図において、動画コンテンツ配信システム100は、HTTP配信サーバ200、ファイルパケット化装置300、ファイル再構築装置400、コンテンツ配信ネットワーク500、UDP非対応端末装置600、およびUDP対応端末装置700等を含んで構成されている。ファイル再構築装置400は、後述するように、ファイルパケット化装置300からIPマルチキャストでUDPパケットを受け取るものであり、典型的には複数設けられる。UDP非対応端末装置600およびUDP対応端末装置700も図では1つしか示されないけれども典型的には複数個設けられる。UDP非対応端末装置600は、位置情報等に基づいてどのファイル再構築装置400にアクセスするかを決定できる。
【0026】
コンテンツ配信ネットワーク500は、ユニキャスト通信のほか、マルチキャスト通信を効率よく実現できるネットワークである。コンテンツ配信ネットワーク500は、マルチキャスト通信を効率よく実現するために専用のネットワークサービスを利用することが好ましいが、これに限定されない。
【0027】
HTTP配信サーバ200は、動画コンテンツ例えばテレビ放送コンテンツのファイルをHTTPを利用して配信する。このHTTP配信サーバ200は、HTTPに準拠してファイルをクライアントに送信して動画コンテンツ配信を行うものであり、例えば、米国アップル社のHLS(HTTP Live Streaming)システムであり、HTTPに準拠したWebサーバで実現可能である。この例では、HTTP配信サーバ200は図示しない通信ネットワークに接続されているけれども、コンテンツ配信ネットワーク500に接続されても良い。また、UDP非対応端末装置600等は、慣用的な態様と同様に、HTTP配信サーバ200からIPユニキャストで動画コンテンツ配信サービスを利用してよい。
【0028】
HTTPに準拠した動画配信サービスは、
図9に示すような、プレイリストファイル(例えばm3u8ファイル)および1または複数の動画セグメントファイル(MPEG2−TSセグメントファイル)を用意する。
図9の例では、マスターインデックスファイルを用いて解像度の異なる複数(2つ)の代替プレイリストを選択できるようになっている。プレイリストが1つだけであてもよい。代替プレイリスト(プレイリスト)は書き換えられて繰り返し送信されて良い。プレイリストを参照して動画セグメントファイルを順次に取り出すことができる。
【0029】
HTTP配信サーバ200は、
図10に示す従来のHTTP手順と同様に、HTTPクライアントであるファイルパケット化装置300からのプレイリスト要求(マスターインデックス、代替プレイリストの要求)に基づいてマスターインデックスファイル、代替プレイリストファイル(以下、単にプレイリストと呼ぶことがある)をファイルパケット化装置300に返す。そののち、HTTP配信サーバ200は、ファイルパケット化装置300からのセグメント要求に応じて順次に動画セグメントファイルを返す。動画セグメントファイルは例えばMPEG2−TSパケットを含んで構成される。
【0030】
ファイルパケット化装置300は、HTTP配信サーバ200のクライアントとして動画配信サービスのプレイリストファイルおよび動画セグメントファイルを受け取り、これらのファイルをUDPパケットに分割して所定のマルチキャストグループでIPマルチキャスト送信する。ファイルパケット化装置300は、
図3に示すように、HTTPクライアント処理部301、記憶部302、パケット化部303、および送信部304を含んで構成される。
【0031】
ファイルパケット化装置300のHTTPクライアント処理部301は、HTTP配信サーバ200からプレイリストファイルおよび動画セグメントファイルを受信する。
図4の(a)欄は、HTTPクライアント処理部301が受信した動画セグメントファイルの例を示す。記憶部302は、受信したファイルを記憶する。パケット化部303は、HTTPクライアント処理部301が受信したファイルをUDPパケットに分解する。
図4の(b)欄は、
図4の(a)欄の動画セグメントファイルをUDPパケットに分解したものである。
図4の(a)欄の動画セグメントファイルは典型的には数秒から数十秒の長さのデータであるが、これに限定されない。
図4の(b)欄のUDPパケットは、パケット化ヘッダ、HTTPヘッダ、ペイロードを含み、パケットヘッダは、(c)欄に示すように、ヘッダサイズ(header_size)、ストリーム識別子(stream_id)、開始フラグ(start_flag)、総合サイズ(total_size)、ペイロードサイズ(payload_size)、およびペイロードオフセット(payload_offset)を含む。ヘッダサイズ(header_size)は、パケット化ヘッダおよびHTTPヘッダの合計サイズを示し、ストリーム識別子(stream_id)は、当該UDPパケットがどのファイルに所属するかを示す識別子であり、開始フラグ(start_flag)は、先頭のUDPパケットであることを示すフラグであり、総合サイズ(total_size)は、ファイルの総バイト数を示し、ペイロードサイズ(payload_size)は、当該UDPパケットで送られるファイル部分のバイト数を示し、ペイロードオフセット(payload_offset)は、当該UDPパケットで送られるファイル部分の開始位置を示す。その他、前方誤り訂正符号(FEC)等を含んでよい。UDPパケットは典型的にはイーサネット(商標)に準拠して1500バイト以下の固定長であるけれども、これに限定されない。動画コンテンツのTSパケットは分割されることなく1つのUDPパケットに含まれ、UDPパケットの各々でペイロード部分に残余がある場合には、埋め込み部分(パッド)を含ませ良い。
【0032】
プレイリストファイルも、TSパケットに関連する考慮を除いて、同様にUDPパケット化される。
【0033】
送信部304は、マルチキャストグループを指定してIPマルチキャストでUDPパケットを配信する。
【0034】
ファイル再構築装置400は、適宜に、ファイルパケット化装置300のマルチキャストグループに参加し、ファイルパケット化装置300からコンテンツ配信ネットワーク500を介してIPマルチキャストで送信されるUDPパケットを受信し、プレイリストファイルおよび動画セグメントファイルを再構築する。
【0035】
ファイル再構築装置400は、
図5に示すように、UDPパケット受信部401、UDPパケット損失検出部402、ヌルパケット挿入部403、パケット連結部404、記憶部405、およびHTTPサービス部406を含む。UDPパケット受信部401は、当該IPマルチキャストのグループに参加し、宛先ポートでUDPパケットを受信するものである。UDPパケット損失検出部402は、動画セグメントファイルを構成するUDPパケットが受信されないときには、これを例えばpayload−size、CRCチェックコード、チェックサム等に基づいて検出し、さらに損失位置のUDPパケットをpayload−0ffsetから検出し、ヌルパケット挿入部403が、これに代えて、TSパケットのヌルパケットを挿入する(
図6)。ヌルパケットはヘッダを含めてすべてビットは「1」の値をとるパケットである。プレイリストファイルについては、繰り返し送信されてくるので、UDPパケット損失が検出されたときには、ファイルを破棄し、次回に送られてくるプレイリストファイルの受信を待って良い。UDPパケットが動画セグメントファイルのものかプレイリストファイルのものかは、UDPパケットのHPPTヘッダに含まれるコンテンツタイプに基づいて判定できる、例えば、
図7(a)に示すように「Content−Type:video/MP2」の場合には動画セグメントファイルのUDPパケットであると判定して損失部分にTSパケットのヌルパケットを挿入する。あるいは、
図7(b)に示すようにHTTPヘッダにNP(NULL Packet)補完フラグのフィールドを設け、動画セグメントファイルのUDPパケットのHTTPヘッダにNP補完フラグをフラグ付けしてもよい。
【0036】
UDPパケット検出部402は、UDPパケットにシリアル番号が付与されるときには、その連続性に基づいてUDPパケットの損失を判別して良い。
【0037】
なお、プレイリスト応答およびセグメントファイル応答のHTTP電文の例は、
図11(a)および(b)に示すとおりであり、「Content−Type」を下線で示す。
【0038】
パケット連結部404は、UDPパケットをlayload−offset等に基づいて順序付けて、また、動画セグメントファイルの欠損位置にTSパケットのヌルパケットを挿入してファイルを再構築する。ファイルを再構築する際には、不要な埋め込み部(Pad)は除去される。
所定のファイル記憶管理部が、再構築したプレイリストファイルおよび動画セグメントファイルを記憶部
405に記憶管理する。
【0039】
HTTPサービス部
406は、UDP非対応端末装置600からのHTTPの要求に基づいて
図10に示したものと同様の態様でプレイリストファイルおよび動画セグメントファイルをUDP非対応端末装置600に返す。UDP非対応端末装置600は受け取ったファイルに基づいて動画を再生する。UDP非対応端末装置600はHTTP端末として機能できるものであれば、どのようなものでもよく、典型的にはスマートフォン等の携帯端末であるけれどもこれに限定されず、どのような情報端末(情報化家庭電器製品を含む)であってもよい。
【0040】
UDP非対応端末装置600を構成する携帯端末の例は、
図8に示すようなものである。
図8において、携帯端末800は、処理システム810、メモリ820、入出力サブシステム830、高周波回路部840、および音声回路部850を含む。構成要素の各々は、適宜、信号処理集積回路、特定用途向け集積回路、を含むハードウェア、ソフトウェア、またはこれらを組み合わせて実現できる。高周波回路部840は、他の装置に、無線リンクまたはネットワーク上で情報を送信・受信するのに用いられ、この機能を実行するために、アンテナ・システム、RF送受信機、増幅器、チューナ、発振器、デジタル信号プロセッサ、CODECチップセット、メモリ、その他の周知の回路構成を含むがこれらに限られない。高周波回路部840は、時分割多重アクセス(TDMA)、符号分割多重接続(CDMA)等のモバイル通信、無線LAN(IEEE 802.11b、IEEE802.11a、IEEE802.11g及び/又はIEEE802.11N)、ブルートゥース(IEEE802.15.1、商標)、Wi−MAX(IEEE802.16)等の通信プロトコルを利用できるけれども、これに限定されない。音声回路部850は、音声スピーカ851とマイクロフォン852に連結される。処理システム810はプロセッサ811、メモリコントローラ812、周辺装置インターフェース813を含む、メモリ820は、プロセッサ811が実行するコードやデータを格納する。メモリ820は、RAM、ROM、FLASH、ディスク・ドライブ、磁気テープ等の任意の記憶装置を含んで良い。プロセッサ811は、メモリ820に格納された多様なソフトウェア・コンポーネントを実行する。例えば、ソフトウェア・コンポーネントは、オペレーティング・システム821、通信モジュール822、接触/動作モジュール823、グラフィック・モジュール824、アプリケーション825、タイマ・モジュール826、およびウェブ・ブラウザ・モジュール827を含む。アプリケーション825は、ブラウザ、アドレス帳、電子メール、暗号化、グローバル・ポジショニング・システム(GPS)等の位置決定機能、および、動画コンテンツ再生機能を含む。この実施例では、携帯端末は、例えば、UDP非対応端末装置600として動作し、HTTPクライアントおよび動画再生部の少なくとも一部はアプリケーション825として実現される。対応するアプリケーションをメモリ820にインストールすることにより携帯端末800をHTTPクライアントおよび動画再生部として機能させる。
【0041】
UDP対応端末装置700は、ファイル再構築装置400の機能を有するものであり、ファイルパケット化装置300からIPマルチキャストで配信されてくるUDPパケットを受信してプレイリストファイルおよび動画セグメントファイルを再構築し動画を再生するものである。UDP対応端末装置700は、ファイル再構築装置400のUDPパケット損失検出部402およびヌルパケット挿入部403と同等の機能部によりUDPパケット損失に対応できる。UDP対応端末装置700を
図8に示す携帯端末で実現できる。すなわち、
図12に示すように、UDP対応装置700は、UDPパケット受信部701、UDPパケット損失検出部702、ヌルパケット挿入部703、パケット連結部704、記憶部705、動画再生部706を含んで構成される。これらのうち、UDPパケット受信部701、UDPパケット損失検出部702、ヌルパケット挿入部703、パケット連結部704、記憶部705は、ファイル再構築装置400のUDPパケット受信部
401、UDPパケット損失検出部
402、ヌルパケット挿入部
403、パケット連結部
404、記憶部
405と同様に構成して良い。動画再生部706は、記憶部705に記憶されたプレイリストファイルおよび動画セグメントファイルを用いて動画を再生するものである。この場合、直接にファイルをアクセスするように構成してもよいし、HTTPに準拠してファイルを取得してもよい。
図12に示すUDPパケット受信部701、UDPパケット損失検出部702、ヌルパケット挿入部703、およびパケット連結部704等を携帯端末800のアプリケーション825で実現してよい。
【0042】
図2は、
図1の動画コンテンツ配信システム100の全般的な動作を示す。
図2において、動画コンテンツは、HTTP配信サーバ200からIPユニキャストでファイルパケット化装置300に送られ、さらに、ファイルパケット化装置300からIPマルチキャストでファイル再構築装置400に送られ、さらに、UDP非対応端末装置600にIPユニキャストで送られる。
図2では示さないが、UDP対応端末装置700がファイル再構築装置400の位置に配置され、動画コンテンツをファイルパケット化装置300からIPマルチキャストで受け取って動画を再生する。
【0043】
まず、ファイルパケット化装置300は、プレイリストファイルの取得要求をHTTP配信サーバ200に送る(X01)。HTTP配信サーバ200はこれに応じてプレイリストをファイルパケット化装置300に返す(X02)。こののち、ファイルパケット化装置300は、プレイリストに記述された動画セグメントファイルについて順次に取得要求をHTTP配信サーバ200に送り(X03)、HTTP配信サーバ200はこれに応じて動画セグメントファイルを順次にファイルパケット化装置300に返す(X04)。
【0044】
ファイルパケット化装置300は受け取ったプレイリストファイルおよび動画セグメントファイルをUDPパケットに分解してファイル再構築装置400にIPマルチキャストで配信する(X05)。以上の処理X01〜X05が繰り返し実行される。
【0045】
ファイル再構築装置400は受け取ったUDPパケットからプレイリストファイルおよび動画セグメントファイルを再構築して記憶部405に記憶保持する(X06、X07)。なお、動画セグメントファイルの再構築に際してUDPのパケット損失がある場合にはこれをヌルパケットに置換する。プレイリストファイルを再構築するときにUDPパケットの損失がある場合には、大構築中のプレイリストファイルを破棄し、次回に配信されてくるプレイリストファイルのUDPパケットにより再構築を行う。
【0046】
ファイル再構築装置400は、UDP非対応端末装置600に対してHTTPサーバとして機能する。すなわち、UDP非対応端末装置600は、プレイリストファイルの取得要求をファイル再構築装置400に送る(X08)。ファイル再構築装置400はこれに応じてプレイリストをUDP非対応端末装置600に返す(X09)。こののち、UDP非対応端末装置600は、プレイリストに記述された動画セグメントファイルについて順次に取得要求をファイル再構築装置400に送り(X10)、ファイル再構築装置400はこれに応じて動画セグメントファイルを順次にUDP非対応端末装置600に返す(X11)。UDP非対応端末装置600は動画セグメントファイルに基づいて順次に動画を生成する。
【0048】
なお、この発明は特許請求の範囲の記載に基づいて決定されるものであり、実施例の具体的な構成、課題、および効果には限定されない。この発明は上述の実施例に限定されるものではなくその趣旨を逸脱しない範囲で種々変更が可能である。
【0049】
なお、上述の例では、損失UDPパケットに相当する部分にTSパケットのヌルパケットを挿入したけれども、完全なTSパケットのみを含むものであれば、TSパケットのヌルパケットを挿入しなくてもよい。例えば、
図6の例で、ヌルパケットを除いて、成功裏に受信されたUDPパケットに含まれる完全なHTTPヘッダおよび完全なTSパケットを含むようにファイルを再構築してよい。
【0050】
また、セグメントファイルの損失UDPパケットがHTTPヘッダに相当する場合には、HTTPヘッダが棄損している。これに対処するために、当該セグメントファイルについてクライアントからHTTP要求があった場合には、コンテンツ長(Content−Length)がゼロであることを示すHTTP応答、例えば
図13に示すようなHTTP応答を返して良い。
図13ではコンテンツ長の記述を矢印で示す。この構成では、当該動画ファイルの再生がスキップされて、後続の動画ファイルが、適宜に、例えばTSストリームのタイムスタンプに基づくタイミングで、再生できる。このHTTP応答には本体は含まれない。
【0051】
また、上述の例では、ファイルパケット化装置300はHTTP配信サーバ200からHTTPに準拠した動画配信用のファイルをHTTPで取得するようにしたけれども、これらのファイルはファイルパケット化装置300自体が生成・準備してもよく、また任意のソースから取得してよい。