JP4735666B2 - コンテンツサーバ、情報処理装置、ネットワーク機器、コンテンツ配信方法、情報処理方法およびコンテンツ配信システム - Google Patents

コンテンツサーバ、情報処理装置、ネットワーク機器、コンテンツ配信方法、情報処理方法およびコンテンツ配信システム Download PDF

Info

Publication number
JP4735666B2
JP4735666B2 JP2008135036A JP2008135036A JP4735666B2 JP 4735666 B2 JP4735666 B2 JP 4735666B2 JP 2008135036 A JP2008135036 A JP 2008135036A JP 2008135036 A JP2008135036 A JP 2008135036A JP 4735666 B2 JP4735666 B2 JP 4735666B2
Authority
JP
Japan
Prior art keywords
compressed
data stream
data
stream
video
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2008135036A
Other languages
English (en)
Other versions
JP2009284283A (ja
Inventor
卓也 五十嵐
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Corp
Original Assignee
Sony Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sony Corp filed Critical Sony Corp
Priority to JP2008135036A priority Critical patent/JP4735666B2/ja
Priority to EP09251299.5A priority patent/EP2124451A3/en
Priority to US12/468,567 priority patent/US20090293093A1/en
Priority to CN2009101421026A priority patent/CN101588476B/zh
Priority to CN2010101384369A priority patent/CN101800899B/zh
Publication of JP2009284283A publication Critical patent/JP2009284283A/ja
Application granted granted Critical
Publication of JP4735666B2 publication Critical patent/JP4735666B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Description

本発明は、コンテンツサーバ、情報処理装置、ネットワーク機器、コンテンツ配信方法、情報処理方法およびコンテンツ配信システムに関する。
ＩＰネットワークを利用した映像配信システムであるＩＰＴＶ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｔｅｌｅｖｉｓｉｏｎ）は、ＭＰＥＧ２やＨ．２６４／ＡＶＣ等の高能率映像符号化技術を利用して圧縮した映像を、ＩＰマルチキャストにて複数に端末に配信することで、従来の電波を利用したＴＶシステムと同等のサービスを実現できる。
しかしながら、ＩＰＴＶシステムは、そのシステムの特性上、チャンネル切り替えをおこなう時間が１〜３秒程度必要であり、通常のデジタルテレビ放送などと比較しても、チャンネル切り替えに要する時間が遅いという問題があった。
この問題は、以下で説明するような２つの問題点に起因する。第１の問題点は、アクセスネットワークに配信するパケットの切り替え制御に時間を要するという問題点である。これは、ＩＰＴＶシステムは、サービス加入者宅までのアクセスネットワークが限られた帯域のネットワーク（例えば、ＡＤＳＬ２の場合では１０Ｍｂｐｓ程度）であって、アクセスネットワークには端末が受信しているチャンネルのデータのみ伝送する方式を採用しており、そのデータ伝送の配信の切り替えに時間を要するために生じる問題である。
第２の問題点は、限られたデータ帯域のアクセスネットワークでチャンネルのデータを配信するために、圧縮映像、例えばＭＰＥＧ２のＧＯＰ（Ｇｒｏｕｐ Ｏｆ Ｐｉｃｔｕｒｅ）長をデジタル放送に比べても長めにせざる得ないため、切り替えたチャンネルのＭＰＥＧ２ストリームＧＯＰ先頭のＩピクチャ（ＡＶＣの場合はＩＤＲピクチャ）を受信するまで待たされるという問題である。
これらの問題に対して、ＩＰＴＶでチャンネル切り替えを高速化するための手段として、以下に示すような２つの方法が提案されている。第１の方式は、チャンネルの映像信号を低解像度でエンコードして低ビットレートにした圧縮データをチャンネル切り替え用のストリームとして同時に端末に配信する方法である（例えば、特許文献１および特許文献２を参照。）。この方法では、チャンネル切り替え時に低ビットレートの圧縮データを表示させた後、本来の解像度のビットレートの圧縮データ方式の表示に切り替えを行う。第２の方法は、アクセスネットワーク近傍にＩピクチャ（ＩＤＲピクチャー）をキャッシュ、バッファリングするサーバを配置し、チャンネル切り替え時には、一時的に端末にユニキャストでそのサーバからＩピクチャを高速伝送して表示させる方式（例えば、特許文献３を参照。）である。
国際公開第０４／１１４６６７号パンフレット 国際公開第０４／１１４６６８号パンフレット 米国特許出願公開第２００５／００８１２４４号明細書
ここで、チャンネル切り替えを行った際の次のチャンネルの映像が表示されるまでの待ち時間は、ＭＰＥＧの圧縮方式に起因するＩピクチャまたはＩＤＲピクチャがどの程度の頻度現れるかに依存する。しかしながら、特許文献１〜特許文献３に記載の方式では、チャンネル切り替え用の改善を図ってはあるが、例えば、１００以上ものチャンネルを提供する多チャンネルサービスにおいて、放送されているチャンネルを高速にプレビューしながらチャンネル選択を行うには、問題があった。
例えば、ＩＤＲピクチャ（ＭＰＥＧ２におけるＩピクチャに相当）が毎秒１回符号化されるＭＰＥＧシステムを利用したＩＰＴＶでは、原理的に、最も高速に継続してチャンネル切り替えを行った場合でも、１００チャンネルのチャンネル切り替えを行った場合でも、１００秒以上の時間がかかることとなる。
そこで、本発明は、このような問題に鑑みてなされたもので、その目的は、従来のアナログＴＶ方式におけるチャンネル切り替え（以下、チャンネルザッピングとも称する。）と同等以上に快適なＴＶ視聴環境を提供することが可能な、新規かつ改良されたコンテンツサーバ、情報処理装置、コンテンツ配信方法、情報処理方法およびコンテンツ配信システムを提供することにある。
上記課題を解決するために、本発明のある観点によれば、映像音声コンテンツを符号化し、映像信号の圧縮によって生成された時系列データにおいて、以前のデータに依存せずに、それ以降の映像信号の復号化を開始できるデータである基準圧縮映像データのみからなる圧縮映像データストリームと、圧縮音声データストリームと、を有する第１圧縮データストリームを生成する第１符号化部と、前記映像音声コンテンツを符号化し、前記基準圧縮映像データおよび当該基準圧縮映像データを用いて生成される圧縮映像データを含む圧縮映像データストリームと、圧縮音声データストリームと、を有する第２圧縮データストリームを生成する第２符号化部と、固有のネットワークアドレスが割り当てられており、前記第１圧縮データストリームを取得して、当該第１圧縮データストリームを、データ配信期間とデータ未配信期間とに区分し、区分した前記データ未配信期間と他のコンテンツサーバから配信される第１圧縮データストリームのデータ未配信期間とが互いに一致するように間欠的に配信する第１配信部と、前記第１配信部とは異なるネットワークアドレスが割り当てられており、前記第２圧縮データストリームを取得して、配信する第２配信部と、を備える、コンテンツサーバが提供される。
ここで、基準圧縮映像データとは、映像信号の圧縮によって生成された時系列データにおいて、以前のデータに依存せずに、それ以降の映像信号の復号化を開始できるデータであり、圧縮された時系列データには、複数の基準圧縮映像データが存在することができる。
かかる構成によれば、第１符号化部は、映像音声コンテンツを符号化し、基準圧縮映像データのみからなる圧縮映像データストリームと、圧縮音声データストリームと、を有する第１圧縮データストリームを生成し、第２符号化部は、前記映像音声コンテンツを符号化し、前記基準圧縮映像データおよび当該基準圧縮映像データを用いて生成される圧縮映像データを含む圧縮映像データストリームと、圧縮音声データストリームと、を有する第２圧縮データストリームを生成し、固有のネットワークアドレスが割り当てられた第１配信部は、前記第１圧縮データストリームを取得して、当該第１圧縮データストリームを、データ配信期間とデータ未配信期間とに区分し、区分した前記データ未配信期間と他のコンテンツサーバから配信される第１圧縮データストリームのデータ未配信期間とが互いに一致するように間欠的に配信し、第１配信部とは異なるネットワークアドレスが割り当てられた第２配信部は、前記第２圧縮データストリームを取得して配信する。
前記第１配信部は、データ未配信期間の直後、すなわち、データ配信期間の先頭に前期基準圧縮データが存在するように前記第１圧縮データストリームをデータパケットに格納し配信することが好ましい。
前記第２配信部は、前記第２圧縮データストリームを、データ配信期間とデータ未配信期間とに区分し、当該第２圧縮データストリームにおけるデータ未配信期間が、前記第１圧縮データストリームにおける前記データ未配信期間と同時刻に存在するように前記第２圧縮データストリームを間欠的に配信することが好ましい。
前記第２配信部は、前記データ配信期間の先頭に前記基準圧縮データが存在するように前記第２圧縮データストリームをデータパケットに格納することが好ましい。
前記第１配信部は、前記データ送信期間内では、前記第１圧縮データストリームが格納されたデータパケットを、等間隔に配置して送信するようにしてもよい。
前記第２配信部は、前記データ送信期間内では、前記第２圧縮データストリームが格納されたデータパケットを、等間隔に配置して送信するようにしてもよい。
前記第１圧縮データストリーム中の前記圧縮映像データストリームと、前記第２圧縮データストリーム中の前記圧縮映像データストリームとは、同一の解像度を有してもよい。
前記第１配信部および前記第２配信部は、生成された前記基準圧縮映像データが配信される配信予定時刻に関する基準圧縮映像データ配信予定時刻情報を出力してもよい。
前記コンテンツサーバは、前記第１符号化部および前記第１配信部を含む装置と、前記第２符号化部および前記第２配信部を含む装置とが並列に接続されたものであってもよい。また、前記第１符号化部、前記第２符号化部、前記第１配信部および前記第２配信部は、同一の装置内に設けられていてもよい。
上記課題を解決するために、本発明の別の観点によれば、映像音声コンテンツを符号化し、映像信号の圧縮によって生成された時系列データにおいて、以前のデータに依存せずに、それ以降の映像信号の復号化を開始できるデータである基準圧縮映像データのみからなる圧縮映像データストリームと、圧縮音声データストリームと、を有する第１圧縮データストリームを生成する第１符号化部と、前記映像音声コンテンツを符号化し、前記基準圧縮映像データおよび当該基準圧縮映像データを用いて生成される圧縮映像データを含む圧縮映像データストリームと、圧縮音声データストリームと、を有する第２圧縮データストリームを生成する第２符号化部と、固有のネットワークアドレスが割り当てられており、前記第１圧縮データストリームを取得して、当該第１圧縮データストリームを、データ配信期間とデータ未配信期間とに区分し、区分した前記データ未配信期間と他のコンテンツサーバから配信される第１圧縮データストリームのデータ未配信期間とが互いに一致するように間欠的に配信する第１配信部と、前記第１配信部とは異なるネットワークアドレスが割り当てられており、前記第２圧縮データストリームを取得して配信する第２配信部と、を備えるコンテンツサーバが複数存在し、複数の前記コンテンツサーバが配信する複数の前記第１圧縮データストリームおよび前記第２圧縮データストリームの中から、取得する圧縮データストリームを選択する取得ストリーム選択部と、前記取得ストリーム選択部による選択結果に基づいて、前記コンテンツサーバから配信された前記圧縮データストリームを取得するコンテンツ取得部と、を備える情報処理装置が提供される。
前記情報処理装置は、当該情報処理装置に対してなされた前記映像音声コンテンツに対応するチャンネルの選択操作を所定の信号に変換するチャンネル選択部を更に備え、前記取得ストリーム選択部は、前記チャンネル選択部から伝送される前記信号に基づいて、取得する前記圧縮データストリームを選択してもよい。
前記取得ストリーム選択部は、取得している前記チャンネルの変更が前記チャンネル選択部から通知された場合に、通知された前記チャンネルに対応する前記第１圧縮データストリームを選択してもよい。
前記取得ストリーム選択部は、前記チャンネルが確定すると、確定した前記チャンネルに対応する前記第２圧縮データストリームを選択してもよい。
前記取得ストリーム選択部は、あるチャンネルの前記第１圧縮データストリームから別のチャンネルの前記第１圧縮データストリームへ切り替えを行う場合に、前記データ未送信期間に前記圧縮データストリームの取得の切り替えが行われるように、前記圧縮データストリームの取得タイミングを前記コンテンツ取得部に通知することが好ましい。
前記取得ストリーム選択部は、視聴中のチャンネルの前記第１圧縮データストリームから別のチャンネルの前記第２圧縮データストリームへ切り替えを行う場合に、前記データ未送信期間に前記圧縮データストリームの取得の切り替えが行われるように、前記圧縮データストリームの取得タイミングを前記コンテンツ取得部に通知することが好ましい。
前記取得ストリーム選択部は、前記コンテンツサーバが出力した、生成された前記基準圧縮映像データが配信される配信予定時刻に関する基準圧縮映像データ配信予定時刻情報を取得し、取得した前記基準圧縮映像データ配信予定時刻情報に基づいて、前記圧縮データストリームを取得するタイミングを決定してもよい。
前記取得ストリーム選択部は、取得した圧縮データストリームを切り替えるために要する切替所要時間と、取得するストリームの選択処理を開始した時刻とを用いて、取得した圧縮データストリームの切り替えを完了する切替完了予想時刻を算出し、前記配信予定時刻と、選択した前記圧縮データストリームの前記切替完了予想時刻との間との間の時間間隔が所定の閾値以下である場合に、前記圧縮データストリームの取得タイミングを前記コンテンツ取得部に通知してもよい。
前記コンテンツ取得部は、ＩＧＭＰにより前記取得ストリーム選択部が選択した前記圧縮データストリームの切り替え制御を行ってもよい。
上記課題を解決するために、本発明の更に別の観点によれば、映像音声コンテンツを符号化し、映像信号の圧縮によって生成された時系列データにおいて、以前のデータに依存せずに、それ以降の映像信号の復号化を開始できるデータである基準圧縮映像データのみからなる圧縮映像データストリームと、圧縮音声データストリームと、を有する第１圧縮データストリームを生成する第１符号化部と、前記映像音声コンテンツを符号化し、前記基準圧縮映像データおよび当該基準圧縮映像データを用いて生成される圧縮映像データを含む圧縮映像データストリームと、圧縮音声データストリームと、を有する第２圧縮データストリームを生成する第２符号化部と、固有のネットワークアドレスが割り当てられており、前記第１圧縮データストリームを取得して、当該第１圧縮データストリームを、データ配信期間とデータ未配信期間とに区分し、区分した前記データ未配信期間と他のコンテンツサーバから配信される第１圧縮データストリームのデータ未配信期間とが互いに一致するように間欠的に配信する第１配信部と、前記第１配信部とは異なるネットワークアドレスが割り当てられており、前記第２圧縮データストリームを取得して配信する第２配信部と、を備えるコンテンツサーバが複数存在し、複数の前記コンテンツサーバが配信する複数の前記第１圧縮データストリームおよび前記第２圧縮データストリームの中から、取得する圧縮データストリームを選択する取得ストリーム選択部と、前記取得ストリーム選択部による選択結果に基づいて、前記コンテンツサーバから配信された前記圧縮データストリームを取得するコンテンツ取得部と、取得した前記圧縮データストリームを、外部に接続された情報処理装置に対して配信する配信制御部と、を備えるネットワーク機器が提供される。
前記取得ストリーム選択部は、あるチャンネルの前記第１圧縮データストリームから別のチャンネルの前記第１圧縮データストリームへ切り替えを行う場合に、前記データ未送信期間に前記圧縮データストリームの取得の切り替えが行われるように、前記圧縮データストリームの取得タイミングを前記コンテンツ取得部に通知することが好ましい。
前記取得ストリーム選択部は、視聴中のチャンネルの前記第１圧縮データストリームから別のチャンネルの前記第２圧縮データストリームへ切り替えを行う場合に、前記データ未送信期間に前記圧縮データストリームの取得の切り替えが行われるように、前記圧縮データストリームの取得タイミングを前記コンテンツ取得部に通知することが好ましい。
上記課題を解決するために、本発明の更に別の観点によれば、映像音声コンテンツを符号化し、映像信号の圧縮によって生成された時系列データにおいて、以前のデータに依存せずに、それ以降の映像信号の復号化を開始できるデータである基準圧縮映像データのみからなる圧縮映像データストリームと、圧縮音声データストリームと、を有する第１圧縮データストリームを生成する第１符号化ステップと、前記映像音声コンテンツを符号化し、前記基準圧縮映像データおよび当該基準圧縮映像データを用いて生成される圧縮映像データを含む圧縮映像データストリームと、圧縮音声データストリームと、を有する第２圧縮データストリームを生成する第２符号化ステップと、生成された前記第１圧縮データストリームを、データ配信期間とデータ未配信期間とに区分し、区分した前記データ未配信期間と他のコンテンツサーバから配信される第１圧縮データストリームのデータ未配信期間とが互いに一致するように間欠的に配信しつつ、第２圧縮データストリームを配信するステップと、を含むコンテンツ配信方法が提供される。
上記課題を解決するために、本発明の更に別の観点によれば、一つの映像音声コンテンツに対応して、映像信号の圧縮によって生成された時系列データにおいて、以前のデータに依存せずに、それ以降の映像信号の復号化を開始できるデータである基準圧縮映像データのみからなる圧縮映像データストリームおよび圧縮音声データストリームを有し、データパケットがデータ配信期間とデータ未配信期間とに区分され、区分された前記データ未配信期間と他のコンテンツサーバから配信される第１圧縮データストリームのデータ未配信期間とが互いに一致するように間欠的に配信される第１圧縮データストリームと、前記基準圧縮映像データおよび当該基準圧縮映像データを用いて生成される圧縮映像データを含む圧縮映像データストリームならびに圧縮音声データストリームを有する第２圧縮データストリームと、を配信するコンテンツサーバが複数存在し、配信されている複数の前記映像音声コンテンツに対応した複数の圧縮データストリームの中から、取得する前記圧縮データストリームを選択する取得ストリーム選択ステップと、選択した前記圧縮データストリームを取得するコンテンツ取得ステップと、を含む情報処理方法が提供される。
上記課題を解決するために、本発明の更に別の観点によれば、一つの映像音声コンテンツに対応して、映像信号の圧縮によって生成された時系列データにおいて、以前のデータに依存せずに、それ以降の映像信号の復号化を開始できるデータである基準圧縮映像データのみからなる圧縮映像データストリームおよび圧縮音声データストリームを有し、データパケットがデータ配信期間とデータ未配信期間とに区分され、区分された前記データ未配信期間と他のコンテンツサーバから配信される第１圧縮データストリームのデータ未配信期間とが互いに一致するように間欠的に配信される第１圧縮データストリームと、前記基準圧縮映像データおよび当該基準圧縮映像データを用いて生成される圧縮映像データを含む圧縮映像データストリームならびに圧縮音声データストリームを有する第２圧縮データストリームと、を配信するコンテンツサーバが複数存在し、配信されている複数の前記映像音声コンテンツに対応した複数の圧縮データストリームの中から、取得する前記圧縮データストリームを選択する取得ストリーム選択ステップと、選択した前記圧縮データストリームを取得するコンテンツ取得ステップと、取得した前記圧縮データストリームを、ネットワークを介して接続された情報処理装置に対して配信する配信制御ステップと、を含むコンテンツ配信方法が提供される。
前記コンテンツ取得ステップでは、前記データ未配信期間の直後から前記圧縮データストリームの取得が行われることが好ましい。
上記課題を解決するために、本発明の更に別の観点によれば、映像音声コンテンツを符号化し、映像信号の圧縮によって生成された時系列データにおいて、以前のデータに依存せずに、それ以降の映像信号の復号化を開始できるデータである基準圧縮映像データのみからなる圧縮映像データストリームと、圧縮音声データストリームと、を有する第１圧縮データストリームを生成する第１符号化部と、前記映像音声コンテンツを符号化し、前記基準圧縮映像データおよび当該基準圧縮映像データを用いて生成される圧縮映像データを含む圧縮映像データストリームと、圧縮音声データストリームと、を有する第２圧縮データストリームを生成する第２符号化部と、固有のネットワークアドレスが割り当てられており、前記第１圧縮データストリームを取得して、当該第１圧縮データストリームを、データ配信期間とデータ未配信期間とに区分し、区分した前記データ未配信期間と他のコンテンツサーバから配信される第１圧縮データストリームのデータ未配信期間とが互いに一致するように間欠的に配信する第１配信部と、前記第１配信部とは異なるネットワークアドレスが割り当てられており、前記第２圧縮データストリームを取得して、配信する第２配信部と、を備える複数のコンテンツサーバと、前記複数のコンテンツサーバが配信する複数の圧縮データストリームの中から、取得する前記圧縮データストリームを選択する取得ストリーム選択部と、前記取得ストリーム選択部による選択結果に基づいて、前記コンテンツサーバから配信された前記圧縮データストリームを取得するコンテンツ取得部と、を備える情報処理装置と、を含むコンテンツ配信システムが提供される。
上記課題を解決するために、本発明の更に別の観点によれば、映像音声コンテンツを符号化し、映像信号の圧縮によって生成された時系列データにおいて、以前のデータに依存せずに、それ以降の映像信号の復号化を開始できるデータである基準圧縮映像データのみからなる圧縮映像データストリームと、圧縮音声データストリームと、を有する第１圧縮データストリームを生成する第１符号化部と、前記映像音声コンテンツを符号化し、前記基準圧縮映像データおよび当該基準圧縮映像データを用いて生成される圧縮映像データを含む圧縮映像データストリームと、圧縮音声データストリームと、を有する第２圧縮データストリームを生成する第２符号化部と、固有のネットワークアドレスが割り当てられており、前記第１圧縮データストリームを取得して、当該第１圧縮データストリームを、データ配信期間とデータ未配信期間とに区分し、区分した前記データ未配信期間と他のコンテンツサーバから配信される第１圧縮データストリームのデータ未配信期間とが互いに一致するように間欠的に配信する第１配信部と、前記第１配信部とは異なるネットワークアドレスが割り当てられており、前記第２圧縮データストリームを取得して、配信する第２配信部と、を備える複数のコンテンツサーバと、前記複数のコンテンツサーバが配信する複数の圧縮データストリームの中から、再生を希望する前記圧縮データストリームを通知し、取得した前記圧縮データストリームを再生する情報処理装置と、前記情報処理装置から受信した通知に基づいて、前記複数のコンテンツサーバが配信する前記複数の圧縮データストリームの中から、取得する前記圧縮データストリームを選択する取得ストリーム選択部と、前記取得ストリーム選択部による選択結果に基づいて、前記複数のコンテンツサーバから配信された前記圧縮データストリームを取得するコンテンツ取得部と、取得した前記圧縮データストリームを、ネットワークを介して前記情報処理装置に対して配信する配信制御部と、を備えるネットワーク機器と、を含むコンテンツ配信システムが提供される。
本発明によれば、従来のアナログＴＶ方式におけるチャンネル切り替え（以下、チャンネルザッピングとも称する。）と同等以上に快適なＴＶ視聴環境を実現でき、多チャンネルを高速にプレビューすることが可能である。
以下に添付図面を参照しながら、本発明の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。
＜基盤技術に関する説明＞
まず、本発明に係る好適な実施形態について詳細な説明をするに先立ち、本実施形態を実現する上で基盤を成す技術的事項について述べる。なお、本実施形態は、以下に記載する基盤技術の上に改良を加えることにより、より顕著な効果を得ることができるように構成されたものである。従って、その改良に係る技術こそが本実施形態の特徴を成す部分である。つまり、本実施形態は、ここで述べる技術的事項の基礎概念を踏襲するが、その本質はむしろ改良部分に集約されており、その構成が明確に相違すると共に、その効果において基盤技術とは一線を画するものであることに注意されたい。
図２３は、一般的なＩＰＴＶシステム９００におけるマルチキャスト映像配信に関するネットワーク構成図である。図２３に示したように、一般的なＩＰＴＶシステム９００は、例えば、それぞれのチャンネルに対応した複数のコンテンツサーバ９０１と、スイッチ９０３，９０９と、ルータ９０５，９０７と、視聴者が使用する複数の端末９１１と、を主に備える。
コンテンツサーバ９０１は、映像音声信号（映像音声コンテンツ）を符号化するエンコーダと、配信サーバとから構成される。各ＴＶチャンネル（例えば、総数３００チャンネルとする。）の映像信号は、例えばＨ．２６４／ＡＶＣを利用してリアルタイムでエンコードされ、各ＴＶチャンネルのオーディオ信号は、ＨＥ−ＡＡＣ（Ｈｉｇｈ−Ｅｆｆｉｃｉｅｎｃｙ Ａｄｖａｎｃｅｄ Ａｕｄｉｏ Ｃｏｄｉｎｇ）などの高能率音声符号化技術を利用してリアルタイムでエンコードされる。その後、エンコーダは、エンコードした各信号をＭＰＥＧ２−ＴＳ（ＭＰＥＧ２−Ｔｒａｎｓｐｏｒｔ Ｓｔｒｅａｍ）の形式に多重化した後、ストリームデータとして配信サーバに伝送する。配信サーバは、それら複数のＭＰＥＧ２−ＴＳのパケットをＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）のパケットフォーマットにし、ＭＰＥＧ２−ＴＳパケットを入れた上でさらにＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）の伝送プロトコルによりＩＰネットワークにマルチキャスト配信する。
各チャンネルのストリームのＩＰパケットは、個別のマルチキャストアドレスが指定され、コアネットワーク、アクセスネットワークを経由して端末９１１に配信される。コアネットワークは、光ファイバーを利用し、ＷＤＭ（Ｗａｖｅｌｅｎｇｔｈ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅｘｉｎｇ）などの技術を用いて、毎秒数ギガ〜数十ギガビットのデータ伝送が可能な広帯域ネットワークが用いられる。他方、ＩＰＴＶサービス加入者宅（すなわち、エッジスイッチ９０９から端末９１１）までのアクセスネットワークは、例えば、既存のアナログ電話回線の銅線配線を利用したＡＤＳＬ（Ａｓｙｍｍｅｔｒｉｃ Ｄｉｇｉｔａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｌｉｎｅ）などの技術が利用される。ＡＤＳＬにもさまざまな規格があり、データ帯域は回線の長さにも依存するが、例えば、ＡＤＳＬ２という規格を用いれば、基地局から４キロメートル以下であれば、毎秒１０メガビット以上の帯域を実現でき、ハイビジョンテレビの解像度の映像信号を一本は配信することが可能である。
このように、コアネットワークは十分な帯域があり、ＩＰＴＶサービスが提供するすべてのチャンネルのストリームを配信できるのに対し、アクセスネットワークのデータ帯域は限られているため、アクセスネットワークには、端末が受信しているチャンネルのデータのみを配信する必要がある。このマルチキャストデータの配信制御に、一般にはＩＧＭＰ（Ｉｎｔｅｒｎｅｔ Ｇｒｏｕｐ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）が利用される。
端末９１１は、受信したいチャンネルのデータのマルチキャストグループに加入するためにＩＧＭＰメッセージをネットワークに送信すると、エッジルータ９０７は要求があったネットワークのみにマルチキャストデータを配信する。ただし、エッジルータ９０７の配下に複数の端末が接続されている場合、エッジルータ９０７は、該当するマルチキャストデータを受信していない端末９１１が接続されたアクセスネットワークに対しても、データを配信してしまう。そこで、ＩＧＭＰによるマルチキャストグループへの加入要求をしていない端末９１１が接続されたアクセスワークへの配信を防ぐ必要がある。そのため、エッジスイッチ９０９であるＤＳＬＡＭ（Ｄｉｇｉｔａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｌｉｎｅ Ａｃｃｅｓｓ Ｍｕｌｔｉｐｌｅｘｅｒ）などは、ＩＧＭＰ ＳＮＯＯＰＩＮＧが実装されている。ＤＳＬＡＭは、端末９１１から送信されたＩＧＭＰパケットを盗みみて、要求を受けた端末９１１が接続されるアクセスネットワークのみにマルチキャストグループのデータを配信するように、フィルタリング制御をなっている。
本発明の各実施形態に係るＩＰＴＶシステムは、上述のような一般的なアーキテクチャーのＩＰＴＶシステムを踏襲した上で、なされたものである。以下に、本発明の各実施形態について、詳細に説明する。
（第１の実施形態）
＜コンテンツ配信システムについて＞
まず、図１を参照しながら、本発明の第１の実施形態に係るコンテンツ配信システムについて、詳細に説明する。図１は、本実施形態に係るコンテンツ配信システムを説明するための説明図である。なお、以下の説明では、コンテンツ配信システムの一例として、ＩＰＴＶシステムを例に挙げながら、詳細に説明する。
本実施形態に係るコンテンツ配信システム１は、例えば図１に示したように、それぞれのチャンネルに対応した複数のコンテンツサーバ１０Ａ，１０Ｂ，１０Ｃと、スイッチ１２，１８と、ルータ１４，１６と、視聴者が使用する複数の情報処理装置２０Ａ，２０Ｂ，２０Ｃ，２０Ｄと、配信予定時刻情報送信サーバ３０と、基準クロックサーバ４０と、を主に備える。
コンテンツサーバ１０は、ＩＰＴＶシステムにおける各チャンネルの放送局に対応しており、映像音声コンテンツ（映像音声信号）を所定の方式で符号化して圧縮データストリームとし、所定の伝送プロトコルを用いて、ＩＰネットワークにマルチキャスト配信する。図１では、コンテンツサーバ１０は、３つしか図示されていないが、コンテンツサーバ１０は、例えばＩＰＴＶシステム上のチャンネル数と同じ数だけ存在し、チャンネル総数が３００である場合には、コンテンツ配信システム１上には、３００台のコンテンツサーバ１０が存在することとなる。
スイッチ１２は、コアネットワーク上を流れるパケットの交換機能（スイッチング機能）を有する通信装置であり、スイッチ１８は、アクセスネットワーク上を流れるパケットの交換機能を有する通信装置であり、コアネットワークの周辺にあるため特にエッジスイッチと呼ばれる。これらのスイッチ１２，１８は、パケットの宛先を判断して、特定の相手にのみ通信を取り次ぐように設定されている。
ルータ１４，１６は、ネットワーク上を流れるパケット等のデータを中継する装置である。これらのルータは、いわゆるＯＳＩ参照モデルでいうネットワーク層やトランスポート層の一部のプロトコルを解析して、データの転送を行う。また、ネットワーク層に記載されているアドレスを解析して、どの経路を通じてデータを転送すべきかを判断する経路選択機能を有する。
情報処理装置２０は、コンテンツ配信システム１の視聴者が使用する端末であって、各コンテンツサーバ１０が配信している複数の映像音声コンテンツの中から、視聴したいコンテンツを取得し、取得したコンテンツを再生する。
なお、上述のコンテンツサーバ１０および情報処理装置２０については、以下で改めて詳細に説明する。
配信予定時刻情報送信サーバ３０は、個々のコンテンツサーバ１０から出力される基準圧縮映像データ配信予定時刻情報をそれぞれ受信して、コンテンツ配信システム１上に存在するコンテンツサーバ１０全ての基準圧縮映像データ配信予定時刻情報を取りまとめる。また、配信予定時刻情報送信サーバ３０は、取りまとめた基準圧縮映像データ配信予定時刻情報を、システムに接続されている情報処理装置２０に対して、所定の時間間隔（例えば、１０ミリ秒〜２０ミリ秒周期）で送信する。なお、上述の基準圧縮映像データ配信予定時刻情報については、以下で詳細に説明する。
基準クロックサーバ４０は、例えば１万分の１秒精度の時刻情報源を有するサーバであり、例えばＮＴＰ（Ｎｅｔｗｏｒｋ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）を利用して、コンテンツ配信システム１に接続されているコンテンツサーバ１０や情報処理装置２０等のコンピュータの内部クロックを、基準クロックサーバ４０が有する時刻情報源に同期させる。
以上、本実施形態に係るコンテンツ配信システム１について、説明を行った。続いて、図２および図３を参照しながら、本実施形態に係るコンテンツサーバ１０および情報処理装置２０について、詳細に説明する。
＜コンテンツサーバの構成について＞
次に、図２を参照しながら、本実施形態に係るコンテンツサーバ１０の構成について、詳細に説明する。図２は、本実施形態に係るコンテンツサーバ１０の構成について説明するためのブロック図である。
本実施形態に係るコンテンツサーバ１０は、当該コンテンツサーバ１０内のクロックがコンテンツ配信システム１上に存在する基準クロックサーバ４０と同期している。コンテンツサーバ１０は、サーバの起動時や、コンテンツサーバ１０の管理者が内部クロックの更新命令を入力した時などの任意のタイミングで、例えばＮＴＰを用いて内部クロックを基準クロックサーバ４０の時刻と同期させることが可能である。
本実施形態に係るコンテンツサーバ１０の各処理部は、基準クロックサーバ４０に同期している内部クロックの現在時刻を参照しながら、所定の処理を実施する。
本実施形態に係るコンテンツサーバ１０は、例えば図２に示したように、プレビュー用ストリーム処理部１１Ａと、視聴用ストリーム処理部１１Ｂと、を備える。プレビュー用ストリーム処理部１１Ａおよび視聴用ストリーム処理部１１Ｂには、同一のチャンネルの映像音声信号がそれぞれ入力される。
プレビュー用ストリーム処理部１１Ａは、図２に示したように、例えば、第１符号化部１０１と、第１配信部１０５と、記憶部１０９と、を主に備える。また、視聴用ストリーム処理部１１Ｂは、図２に示したように、例えば、第２符号化部１０３と、第２配信部１０７と、記憶部１１１と、を主に備える。
図２に示したように、プレビュー用ストリーム処理部１１Ａおよび視聴用ストリーム処理部１１Ｂは、一つの符号化部および一つの配信部からなる組を少なくとも１つ備える処理部であり、各符号化部および各配信部は、それぞれ互いに独立して機能する。
第１符号化部１０１および第２符号化部１０３は、例えば、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）から構成されている。第１符号化部１０１および第２符号化部１０３は、入力された映像音声信号のうち、映像信号を、例えばＨ．２６４／ＡＶＣを利用してリアルタイムで符号化（以下、エンコードとも称する。）するとともに、音声信号を、例えばＨＥ−ＡＡＣ等の高能率音声符号化技術を利用してリアルタイムでエンコードする。続いて、第１符号化部１０１は、エンコードした各信号をＭＰＥＧ２−ＴＳの形式に多重化した後、第１圧縮データストリームとして、第１配信部１０５に伝送する。また、第２符号化部１０３は、エンコードした各信号をＭＰＥＧ２−ＴＳの形式に多重化した後、第２圧縮データストリームとして、第２配信部１０７に伝送する。
ここで、第１符号化部１０１は、チャンネルあたりのデータを伝送するために確保されたデータ帯域の範囲において、秒あたりのピクチャ数を減らすことにより、基準圧縮映像データの出現頻度ができる限り多くなるように、チャンネルの映像音声信号を符号化（エンコード）して、圧縮映像データストリームを生成する。この際、第１符号化部１０１により生成される圧縮映像データストリームは、基準圧縮映像データのみから構成される。このようにして生成される圧縮映像データストリームを含む第１圧縮データストリームは、高速プレビュー用のデータストリームとして利用される。
また、第２符号化部１０３は、入力された映像音声信号のフレームレートと同様のピクチャ数（例えば、６０Ｈｚのインターレースであれば、毎秒３０枚のピクチャ数）となり、かつ、配信ネットワークで確保されたデータ帯域の範囲において、映像画質ができる限り良好なものとなるように、チャンネルの映像音声信号を符号化して、圧縮映像データストリームを生成する。この際、第２符号化部１０３により生成される圧縮映像データストリームは、基準圧縮映像データと、この基準圧縮映像データを用いて生成される圧縮映像データと、から構成される。このようにして生成される圧縮映像データストリームを含む第２圧縮データストリームは、チャンネル視聴用のデータストリームとして利用される。
ここで、基準圧縮映像データは、この映像データよりも時間的に前の圧縮映像データを参照することなく、映像データを復号可能な圧縮映像データを意味している。このような基準圧縮映像データの例として、例えば、Ｈ．２６４／ＡＶＣでのＩＤＲ（Ｉｎｓｔａｎｔａｎｅｏｕｓ Ｄｅｃｏｄｅｒ Ｒｅｆｒｅｓｈ：デコーダ復号動作の瞬時リフレッシュ）ピクチャや、ＭＰＥＧ２ビデオでのＩピクチャ（Ｉｎｔｒａ ｐｉｃｔｕｒｅ：ピクチャ内符号化ピクチャ）を挙げることができる。
また、基準圧縮映像データを用いて生成される圧縮映像データは、動き補償フレーム間予測符号化（ｍｏｔｉｏｎ ｃｏｍｐｅｎｓａｔｅｄ ｉｎｔｅｒｆｒａｍｅ ｐｒｅｄｉｃｔｉｏｎ）を用いて符号化され、基準圧縮映像データからの差分のみを表すデータから構成される圧縮映像データを意味している。このような基準圧縮映像データを用いて生成される圧縮映像データの一例として、Ｐピクチャ（Ｐｒｅｄｉｃｔｉｖｅ ｐｉｃｔｕｒｅ：予測符号化ピクチャ）およびＢピクチャ（Ｂｉ−ｐｒｅｄｉｃｔｉｖｅ Ｐｉｃｔｕｒｅ：双予測ピクチャ）を挙げることができる。
なお、第１符号化部１０１および第２符号化部１０３は、映像音声信号の符号化に際して、それぞれ後述する記憶部１０９および記憶部１１１に記録されている各種のデータベース等を参照することが可能である。また、第１符号化部１０１および第２符号化部１０３は、生成した圧縮データストリームを、それぞれ記憶部１０９および記憶部１１１に記録してもよい。
第１配信部１０５および第２配信部１０７は、例えば、ＣＰＵ、ＲＯＭ、ＲＡＭ、通信装置等から構成されており、いわゆるＲＴＰ（Ｒｅａｌ−Ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）サーバの機能を有している。第１配信部１０５および第２配信部１０７は、それぞれ第１符号化部１０１および第２符号化部１０３が生成したＭＰＥＧ２−ＴＳのパケットを、ＲＴＰパケットおよびＵＤＰパケットに格納した上で、ＩＰマルチキャストパケットに格納して、送信する。これらのＩＰパケットは、例えば、スイッチ１２等を経由して、ＩＰネットワークにより配信される。
また、第１配信部１０５および第２配信部１０７は、第１符号化部１０１および第２符号化部１０３によって生成された基準圧縮映像データが配信される配信予定時刻を算出し、この配信予定時刻が記載された基準圧縮映像データ配信予定時刻情報（以下、配信予定時刻情報と略記する。）を定期的に生成する。配信予定時刻の算出方法については、以下で改めて詳細に説明する。
第１配信部１０５および第２配信部１０７は、それぞれが生成した配信予定時刻情報を、配信予定時刻情報送信サーバ３０へと定期的に出力する。また、第１配信部１０５および第２配信部１０７は、生成した配信予定時刻情報を、それぞれ記憶部１０９および記憶部１１１に記録してもよい。
記憶部１０９は、本実施形態に係るプレビュー用ストリーム処理部１１Ａが、何らかの処理を行う際に保存する必要が生じた様々なパラメータや処理の途中経過等、または、各種のデータベース等が、適宜記録される。記憶部１０９は、第１符号化部１０１および第１配信部１０５等が、自由に読み書きを行うことが可能である。
同様に、記憶部１１１には、本実施形態に係る視聴用ストリーム処理部１１Ｂが、何らかの処理を行う際に保存する必要が生じた様々なパラメータや処理の途中経過等、または、各種のデータベース等が、適宜記録される。記憶部１１１は、第２符号化部１０３および第２配信部１０７等が、自由に読み書きを行うことが可能である。
また、プレビュー用ストリーム処理部１１Ａおよび視聴用ストリーム処理部１１Ｂは、１台のコンテンツサーバの筐体内に設けられていてもよい。また、プレビュー用ストリーム処理部１１Ａおよび視聴用ストリーム処理部１１Ｂがそれぞれ一つの装置として独立しており、これらの装置が並列に複数台接続されていてもよい。
以上、本実施形態に係るコンテンツサーバ１０の機能の一例を示した。上記の各構成要素は、汎用的な部材や回路を用いて構成されていてもよいし、各構成要素の機能に特化したハードウェアにより構成されていてもよい。また、各構成要素の機能を、ＣＰＵ等が全て行ってもよい。従って、本実施形態を実施する時々の技術レベルに応じて、適宜、利用する構成を変更することが可能である。
＜情報処理装置の構成について＞
続いて、図３を参照しながら、本実施形態に係る情報処理装置２０の構成について、詳細に説明する。図３は、本実施形態に係る情報処理装置２０の構成を説明するためのブロック図である。
本実施形態に係る情報処理装置２０は、当該情報処理装置２０内のクロックがコンテンツ配信システム１上に存在する基準クロックサーバ４０と同期している。情報処理装置２０は、装置の起動時や、情報処理装置２０の使用者が内部クロックの更新命令を入力した時などの任意のタイミングで、例えばＮＴＰを用いて内部クロックを基準クロックサーバ４０の時刻と同期させることが可能である。
本実施形態に係る情報処理装置２０は、例えば図３に示したように、チャンネル選択部２０１と、取得ストリーム選択部２０３と、コンテンツ取得部２０５と、コンテンツ再生部２０７と、記憶部２０９と、を主に備える。
チャンネル選択部２０１は、例えば、ＣＰＵ、ＲＯＭ、ＲＡＭ等から構成されている。ユーザが、情報処理装置２０に設けられたチャンネル選択スイッチ、チャンネル選択ボタン等の操作部や、リモートコントローラ等を操作して、配信されている複数のチャンネルの中から特定のチャンネルを選択した場合に、チャンネル選択部２０１は、チャンネル選択スイッチやチャンネル選択ボタン等による入力を所定の信号に変換する。また、チャンネル選択部２０１は、ユーザ入力を変換した所定の信号を、後述する取得ストリーム選択部２０３に出力する。
取得ストリーム選択部２０３は、例えば、ＣＰＵ、ＲＯＭ、ＲＡＭ、通信装置等から構成されており、基準クロックサーバ４０に同期している内部クロックの現在時刻を参照しながら、以下で説明するような処理を実施する。
取得ストリーム選択部２０３は、チャンネル選択部２０１から、あるチャンネルを指定されると、指定されたチャンネルから配信された視聴用圧縮データストリームを取得するように、後述するコンテンツ取得部２０５に通知する。また、あるタイミングで、視聴者がチャンネルザッピングを開始して、チャンネル選択部２０１から、異なるチャンネルを指定された場合には、該当するチャンネルから配信されたプレビュー用圧縮データストリームを取得するように、後述するコンテンツ取得部２０５に通知する。その後、視聴者がチャンネルザッピングを終了し、視聴するチャンネルが確定すると、取得ストリーム選択部２０３は、確定したチャンネルから配信された視聴用圧縮データストリームを取得するように、後述するコンテンツ取得部２０５に通知する。
また、取得ストリーム選択部２０３は、個々のコンテンツサーバ１０から出力され、配信予定時刻情報送信サーバ３０によって取りまとめられた配信予定時刻情報を、配信予定時刻情報送信サーバ３０から定期的に受信する。取得ストリーム選択部２０３は、受信した配信予定時刻情報を参照して、高速チャンネル切り替え時にプレビュー用圧縮データストリームから他のプレビュー用圧縮データストリームの切り替えタイミングの判断、および、プレビュー用圧縮データストリームから視聴用圧縮データストリームへ切り替えるタイミングを判断する。
より詳細には、取得ストリーム選択部２０３は、チャンネル選択部２０１から通知されたチャンネルの圧縮データストリームを取得して切り替えるために要する切替所要時間と、取得する圧縮データストリームの選択処理を開始した時刻とを用いて、取得した圧縮データストリームの切り替えを完了する切替完了予想時刻を算出する。ここで、上述の切替所要時間は、現在表示しているチャンネルから異なるチャンネルにチャンネル切り替えを行った際に、新たなチャンネルで配信されているコンテンツが表示されるまでに要する時間を意味するものである。取得ストリーム選択部２０３は、算出した切替完了予想時刻と、配信予定時刻情報送信サーバ３０から取得した配信予定時刻情報とを比較して、切替完了予想時刻以降の直近の配信予定時刻を有する圧縮データストリームを受信できるように、取得するデータストリームの切り替えを通知する。
なお、これらの選択処理を行うにあたって、取得ストリーム選択部２０３は、後述する記憶部２０９に記録されている各種のデータベース等を参照しながら処理を行うことが可能である。
また、取得ストリーム選択部２０３は、配信予定時刻と、圧縮データストリームの切替完了予想時刻との間の時間間隔が所定の閾値以下であれば、選択結果をコンテンツ取得部２０５に通知する。また、取得ストリーム選択部２０３は、上記時間間隔が所定の閾値超過であれば、新たに配信予定時刻情報送信サーバ３０から通知される配信予定時刻情報に基づいて、再度圧縮データストリームの選択処理を実行し、選択結果をコンテンツ取得部２０５に通知する。
切替完了予想時刻と、配信予定時刻との間に、所定の値以上の時間間隔が存在する場合には、取得ストリーム選択部２０３の選択結果に基づいて表示切り替えを行ったとしても、表示画面は、画面に黒などの色を表示するブラックアウト状態のままとなる。そのため、新たに配信予定時刻情報送信サーバ３０から通知される配信予定時刻情報を待っている間は、切り替え前のチャンネルのストリームが継続して取得されているので、その映像を画面表示続けることで、視聴者の使用感を損なうことなく、圧縮データストリームの選択処理を再度実行することができる。
上述のような取得ストリームの選択方法については、以下で改めて詳細に説明する。
コンテンツ取得部２０５は、例えば、ＣＰＵ、ＲＯＭ、ＲＡＭ、通信装置等から構成されており、配信されている複数のチャンネルの中から、取得ストリーム選択部２０３から伝送された選択結果に対応したチャンネルが配信しているコンテンツを取得する。本実施形態に係るコンテンツ配信システムでは、１つのチャンネルに属するコンテンツに対して、プレビュー用の圧縮データストリームと、視聴用の圧縮データストリームとが配信されているため、コンテンツ取得部２０５は、取得ストリーム選択部２０３から通知された選択結果に基づいて、圧縮データストリームの取得を行う。
なお、コンテンツの取得に際して、コンテンツ取得部２０５は、後述する記憶部２０９に記録されている各種のデータベース等を参照しながら、コンテンツの取得処理を実行することが可能である。
コンテンツ再生部２０７は、例えば、ＣＰＵ、ＲＯＭ、ＲＡＭ等から構成されており、コンテンツ取得部２０５が取得したコンテンツを再生して、情報処理装置２０が備える表示部（図示せず。）に表示する。ここで、コンテンツの再生とは、コンテンツ取得部２０５から伝送された圧縮データストリームの復号を行った上で、復号されたコンテンツを再生すること、および、圧縮データストリームの復号を行いながら、コンテンツを再生することを含む。コンテンツ再生部２０７は、コンテンツの復号やコンテンツの再生を行う際に、後述する記憶部２０９に記録されているデータベース等を参照することが可能である。
記憶部２０９は、本実施形態に係る情報処理装置２０が、何らかの処理を行う際に保存する必要が生じた様々なパラメータや処理の途中経過等、または、各種のデータベース等が、適宜記録される。記憶部２０９は、チャンネル選択部２０１、取得ストリーム選択部２０３、コンテンツ取得部２０５、コンテンツ再生部２０７等が、自由に読み書きを行うことが可能である。
以上、本実施形態に係る情報処理装置２０の機能の一例を示した。上記の各構成要素は、汎用的な部材や回路を用いて構成されていてもよいし、各構成要素の機能に特化したハードウェアにより構成されていてもよい。また、各構成要素の機能を、ＣＰＵ等が全て行ってもよい。従って、本実施形態を実施する時々の技術レベルに応じて、適宜、利用する構成を変更することが可能である。
＜コンテンツ配信方法について＞
続いて、図４〜図１２を参照しながら、本実施形態に係るコンテンツサーバ１０が実行するコンテンツ配信方法について、詳細に説明する。
［圧縮映像データストリームのピクチャ構造について］
図４は、プレビュー用ストリーム処理部１１Ａおよび視聴用ストリーム処理部１１Ｂから出力される圧縮映像データストリームのピクチャ構造を説明するための説明図である。以下では、例えば、アクセスネットワークの帯域を毎秒８メガビット確保し、ハイビジョン解像度（１９２０Ｘ１０２４）で毎秒６０フレームのインターレースの元信号を配信するＩＰＴＶシステムを例にとって、説明を行う。
このようなシステムでは、例えば、毎秒７メガビット程度の帯域がＭＰＥＧビデオのストリームに割り当てられている。Ｈ．２６４／ＡＶＣにてエンコードする場合は、図４のコンテンツ視聴用データストリームのピクチャ構造に示すように、毎秒３０枚のＭＰＥＧピクチャがエンコードされる。なお、ＭＰＥＧ２ビデオのＧＯＰ（Ｇｒｏｕｐ Ｏｆ Ｐｉｃｔｕｒｅ）の表記に従い、本明細書では、ＩＤＲピクチャを先頭に含む複数のピクチャのまとまりを、ＧＯＰと示すこととする。
ＩＤＲピクチャ、Ｐピクチャ、Ｂピクチャの出現パターンも動的に変えることも可能であるが、本実施形態に係る第２符号化部１０３では、ＧＯＰを毎秒３０ピクチャになるように設定されており、Ｐピクチャ、Ｂピクチャも固定パターンでエンコードされる。ここで、ＩＤＲピクチャ、ＰピクチャおよびＢピクチャに割り当てられるデータ量の割合は異なっており、例えば、３対２対１のデータ量となるように設定される。ただし、図４では、便宜上、各ピクチャの大きさはデータ量には比例せずに、一定の大きさで図示している。
他方、本実施形態にかかるプレビュー用ストリーム処理部１１Ａから出力されるチャンネルプレビュー用の圧縮データストリームは、図４に示したように、ＩＤＲピクチャのみから構成されている。プレビュー用の圧縮データストリームを構成するＩＤＲピクチャは、視聴用ストリーム処理部１１Ｂから出力されるデータストリームと同一の解像度および同等の品質となるように第１符号化部１０１によりエンコードされる。このようにして生成された圧縮データストリームは、例えば図４に示したように、１秒間に１０枚のＩＤＲピクチャから構成される。ここで、第１符号化部１０１は、ＩＤＲピクチャのデータ量が一定となるように符号化を行う。第１配信部１０５によりＭＰＥＧ２−ＴＳパケットがＲＴＰ・ＵＤＰパケットに格納される際に、後述するように、各ＵＤＰパケットの間隔がほぼ等間隔となるようにシェーピングされ、ネットワーク上に配信される。そのため、情報処理装置２０がプレビュー用圧縮データストリームを受信する場合には、約１００ミリ秒おきにＩＤＲピクチャを受信開始できるタイミングが実現できる。
［ＵＤＰパケットのフォーマットについて］
図５は、本実施形態に係る配信部１０５，１０７が送出するＵＤＰパケットのフォーマットを説明するための説明図である。コンテンツサーバ１０が備える各符号化部１０１，１０３で生成されたＭＰＥＧ２−ＴＳパケットは、それぞれの符号化部が属する処理部に設けられた配信部に出力され、ＩＰパケットとして伝送される。このＩＰパケットは、例えば図５に示したようなフォーマットを有する。
図５に示したように、ＩＰマルチキャストのＵＤＰパケットは、ＩＰヘッダと、ＵＤＰヘッダと、ＲＴＰヘッダと、ＲＴＰペイロードと、から構成される。コンテンツサーバ１０の各符号化部１０１，１０３で生成されたＭＰＥＧ２−ＴＳパケットは、ＲＴＰペイロードに格納される。通常、ＲＴＰペイロードには、図５に示したように、７個のＭＰＥＧ２−ＴＳパケットが格納される。
コンテンツサーバ１０の各配信部１０５，１０７は、図５のようなＵＤＰパケットを生成し、マルチキャスト配信する。
ここで、図５に示したように７個のＭＰＥＧ２−ＴＳパケットが格納される場合には、一つのＵＤＰパケットは１３５６バイト程度となる。ここで、アクセスネットワークの最大帯域である毎秒８メガビットまで利用してストリームを伝送する場合には、約７３７個のＵＤＰパケットが一秒間に伝送されることとなり、一つのＩＤＲピクチャは、約７４個のＵＤＰパケットに分割される。ＵＤＰパケットは、後述するようなシーピング処理を施された上で配信されるため、ＵＤＰパケットは、平均１．３ミリ秒間隔で伝送されることになる。
［プレビュー用圧縮データストリームの配信について］
続いて、図６を参照しながら、各チャンネルのプレビュー用ストリームを利用して、複数チャンネルを高速にプレビューする方法について説明する。図６は、本実施形態に係るプレビュー用圧縮データストリームを説明するための説明図である。
例えば、視聴者の操作によりチャンネルプレビュー操作が開始されると、視聴者は、各チャンネルあたり、例えば、１枚〜３枚程度の映像フレーム（時間的には０．１秒〜０．３秒程度のチャンネル映像）を見ただけで、チャンネルで放送されている番組名やジャンル（例えば、ニュース、ドラマ、出演中のアーティスト等）を認識したり、番組の盛り上がり状況（例えば、スポーツ番組における盛り上がり状況）などを認識したりすることは十分可能である。そのため、視聴者は通常、リモートコントローラ等のプレビューボタンを長押しすることで、プレビューしているチャンネルの切り替えを行う。このチャンネル切り替えの際、端末である情報処理装置２０は、できる限り取りこぼしなく、切り替わり元と切り替わり先のチャンネルの双方のストリームのＵＤＰパケットを、受信することが望ましい。
ここで、図６に示すように、各チャンネルから配信されるプレビュー用圧縮データストリームにおいて、毎秒１０枚のＩＤＲピクチャが配信されている場合について考える。シームレスな映像切り替えを視聴者に提供するために、情報処理装置２０は、理想的には、以下のようにＵＤＰパケットを受信することが望ましい。すなわち、例えばチャンネル１のストリームからチャンネル２のストリームに配信を切り替える際に、情報処理装置２０は、チャンネル１の５番目のＩＤＲピクチャを格納する全てのＵＤＰパケット受信し、かつチャンネル２の６番目のＩＤＲピクチャを格納する全てのＵＤＰパケットを受信する。このようにＵＤＰパケットを受信することで、情報処理装置２０では、シームレスに映像を切り替えることが可能となる。このためには、アクセスネットワーク経由で情報処理装置２０に配信されるチャンネル１とチャンネル２のストリームの切り替えを、約１．３ミリ秒以内に処理することが求められる。
このようなストリーム切り替えは、端末である情報処理装置２０がＩＧＭＰメッセージを発行することによって行われる。図７Ａおよび図７Ｂは、ＲＦＣ３３７６で規定されるＩＧＭＰバージョン３における、情報処理装置２０からマルチキャストデータ配信制御を行うためのＩＧＭＰメッセージのフォーマットである。
情報処理装置２０がマルチキャストグループに参加および離脱する場合は、図７Ａに示したレポートフォーマットのＩＧＭＰメッセージを利用する。そのほか、マルチキャストルータがマルチキャストグループに加入していることを確認するクエリーフォーマットのＩＧＭＰメッセージもあるが、これらＩＧＭＰの仕様についての詳細説明は、省略する。
図７Ａに示したように、レポートフォーマットのＩＧＭＰメッセージには、「Ｎｕｍｂｅｒ ｏｆ Ｇｒｏｕｐ Ｒｅｃｏｒｄｓ」という欄に、当該レポートに含まれるレコードの数が明記されており、続いて、明記されたレコードの数の分だけ、「Ｇｒｏｕｐ Ｒｅｃｏｒｄ」が記載される。図７Ｂは、各グループレコードのフォーマットである。図７Ｂに示したように、グループレコードのフォーマットには、「Ｒｅｃｏｒｄ Ｔｙｐｅ」という欄が存在し、この欄に所定の値を入力することで、マルチキャストグループへの参加や離脱を指定することが可能である。
しかしながら、ＩＧＭＰによるマルチキャスト配信の切り替えには、通常、例えば５０〜１００ミリ程度の時間を要する。上述のようなＩＭＧＰバージョン３の機能を利用し、一つのＩＧＭＰレポートメッセージでマルチキャストグループへの加入および離脱を行う方式を採用し、かつ、ＩＧＭＰスヌーピングを行うエッジスイッチ（例えば、ＤＳＬＡＭ）の配信切り替え処理の高速化を図ったとしても、配信の切り替えには、数十ミリ程度必要となる。そのため、マルチキャスト配信の切り替えを、上述のように１．３ミリ秒以下で行うことは、技術的に困難を伴う。
［パケットのシェーピング処理について］
この問題を解決するために、本実施形態に係るコンテンツサーバ１０の各配信部では、ＭＰＥＧストリームを配信する際に、図８に示すシェーピングを行う。図８は、本実施形態に係るコンテンツサーバが実施するパケットのシェーピング処理を説明するための説明図である。
本実施形態に係る第１配信部１０５は、ストリームの各ＩＤＲピクチャを含むＭＰＥＧ２−ＴＳパケットが格納されるＵＤＰパケットをチャンク（ｃｈｕｎｋ）にまとめ、このチャンクの区間で、各ＵＤＰパケットが等間隔に配置されるようにシェーピングする。また、チャンクとチャンクとの間には、ＵＤＰパケットをアクセスネットワークに配信しない未配信期間を設ける。すなわち、本実施形態に係る第１配信部１０５が生成する圧縮データストリームは、図８に示したように、ＵＤＰパケットを配信する期間（データ配信期間）と、ＵＤＰパケットが配信されない期間（データ未配信期間）とから構成されており、データパケットが間欠的に配信されることとなる。
また、周期的に出現するデータ未配信期間は、他のチャンネルのプレビュー用データストリームのデータ未配信期間と、同時刻に同じ期間だけ出現するようにするために、各コンテンツサーバ１０の符号化部は、各映像音声コンテンツのＩＤＲピクチャが出現する時間的位置が、他のコンテンツサーバ１０と同時刻になるように映像音声コンテンツをエンコードする。例えば、ＩＤＲピクチャが毎秒１０枚、固定的な時間位置に相当するように設定し、符号化部は、ＩＤＲピクチャの出現する時刻を、基準クロックを元に合わせるようにすることで、実現可能である。なお、このために、Ｈ．２６４．ＡＶＣのエンコーダやＭＰＥＧ２の多重化のシステムクロックが、互いに同期している必要はない。
上記の方法により、各コンテンツサーバ１０のプレビュー用圧縮データストリームのＩＤＲピクチャの存在時刻を合わせることができるので、同じデータ未送信期間の長さを各配信部に設定すれば、各コンテンツサーバから配信されるパケットのデータ未送信期間が同時刻、同区間で起こるようにシェーピングを実現できる。
また、各視聴用圧縮データストリームについても同様のシェーピングを行うことにより、スムーズに視聴用ストリームへの切り替えを行うことができる。この場合のシェーピングは、視聴用ストリームの各ＩＤＲピクチャの直前にデータ未送信区間が存在し、かつ、そのデータ未送信期間が、プレビュー用圧縮データの何れかのデータ未送信期間と同時刻、同期間に出現するようにシェーピングする。視聴用圧縮データストリームが固定用のＧＯＰにて、例えば、１秒に１回出現するようにエンコードを設定すれば、プレビュー用圧縮データストリームのデータ未送信期間の１０回目ごとに、視聴用データストリームのデータ未送信期間が同時刻に出現するようにシェーピングできる。
このデータ未配信期間は、端末である情報処理装置２０がチャンネル切り替えを行う際に、配信切り替え時間として利用される。
本実施形態では、このデータ未配信期間を例えば２０ミリ秒とし、残り８０ミリ秒の間にＵＤＰパケットを送信する（すなわち、データ配信期間を８０ミリ秒とする）ことで、１００ミリ秒ごとに、ＩＤＲピクチャのデータを送信することが可能となる。一つのＩＤＲピクチャを含むＭＰＥＧ２−ＴＳパケットは、７４個程度のＵＤＰパケットから構成されるので、この場合は、約１ミリ間隔でＵＤＰパケットが送出されることとなる。この際、送出するＵＤＰパケットの合計数は従来のものと変わらないため、アクセスネットワークに配信するデータ帯域は変わらない。しかしながら、局所的なシェーピングが、同じくアクセスネットワークに送出する他のトラフィックに影響がある場合は、プレビュー用ストリームの画像音声の品質などを落としてエンコードしてもよい。このようにすることで、ＭＰＥＧストリームのビットレートを約毎秒６．１メガビット程度低減し、一つのＩＤＲピクチャを含むＭＰＥＧ２−ＴＳパケットを格納するＵＤＰパケットの数を、約５７個にすることができ、通常にシェーピングした場合と同じＵＤＰパケット間隔が実現できる。プレビューなど切り替わりながら表示される映像に対しては、映像品質の劣化は、人間の感覚の特性として、比較的問題にならない。
［配信予定時刻の算出について］
次に、図９を参照しながら、本実施形態に係るコンテンツサーバ１０が備える各配信部が実施する配信予定時刻の算出方法について、詳細に説明する。本実施形態に係るコンテンツサーバは、プレビュー用ストリーム処理部１１Ａおよび視聴用ストリーム処理部１１Ｂから送出されるＵＤＰパケットそれぞれについて、各ＩＤＲピクチャを含む先頭のＭＰＥＧ２−ＴＳパケットを格納したＵＤＰパケットが配信される予定時刻を、配信予定時刻として算出する。以下では、視聴用ストリーム処理部１１Ｂにおける配信予定時刻の算出方法を例にとって、詳細に説明する。図９は、本実施形態に係るコンテンツサーバが実施する配信予定時刻の算出方法について説明するための説明図である。
本実施形態に係る視聴用ストリーム処理部１１Ｂが備える第２配信部１０７は、ＩＤＲピクチャの配信予定時刻の算出を行うが、この算出処理は、以下の式を用いて行われる。
算出時刻ＣでのＩＤＲピクチャ配信予定時刻：時刻Ｆ＝時刻Ｃ＋時間Ｄ＋時間Ｅ
・・・（式１）
ここで、上記式１において、時間Ｄは、図９に示したように、時間Ｄ＝（時刻Ｂ−時刻Ａ）を用いて算出することができる。この時間Ｄは、第２符号化部１０３から生成されたＩＤＲピクチャのデータを含むＭＰＥＧ２−ＴＳパケットが生成されてから、ＩＰマルチパケットにて送出されるまでの遅延時間として考えることができる。
図９における時刻Ｂは、ＩＤＲピクチャのデータが含まれる最初のＭＰＥＧ２−ＴＳパケットの生成時間であり、時刻Ａは、そのＭＰＥＧ２−ＴＳパケットが第２配信部１０７から送信される時刻である。この遅延時間Ｄは、通常は、ほぼ一定であるので、一回の計測で得られた値を使用してもよいし、固定値をつかってもよいし、ＩＤＲピクチャの送出ごとに計算してもよい。
図９における時間Ｅは、時刻Ｃの時点における次のＩＤＲピクチャの最初のデータが含まれるＭＰＥＧ２−ＴＳパケットの生成までにかかる時間である。時間Ｅは、時刻Ｃの経過とともに更新されるので、ＩＤＲピクチャ配信予定時刻の計測のたびに、第２符号化部１０３に問い合わせる必要がある。通常、リアルタイムエンコードでは、エンコードによる遅延を小さくするために、ＩＤＲピクチャ配信予定時刻は第２符号化部１０３が予測した時間となる。例えば、第２符号化部１０３が、毎秒１秒ごとに固定間隔でＩＤＲピクチャを生成するように設定されている場合は、時間Ｅは容易に求めることができる。そうではない場合も、符号化部によって生成され記憶部等に記録されているエンコーダバッファ管理情報を元に、時間Ｅの予測は十分可能である。既に時刻Ｃの時点で未送出のＩＤＲパケットが存在する場合は、時間Ｅはマイナスの値をとる。
本実施形態に係るコンテンツサーバが備える各配信部は、上述のような方法を用いて、基準圧縮映像データ配信予定時刻を算出する。配信部は、このようにして算出された配信予定時刻を、配信部自身に割り当てられている所在情報（例えば、ＩＰアドレス番号）に関連付けて、配信予定時刻情報として配信予定時刻情報送出サーバ４０に出力する。
［配信予定時刻情報の例について］
続いて、図１０を参照しながら、上述のような方法で算出された配信予定時刻情報の具体的な記述例について、詳細に説明する。図１０は、本実施形態に係る基準圧縮映像データ配信予定時刻情報の具体例を説明するための説明図である。
基準圧縮映像データ配信予定時刻情報の一例であるＩＤＲピクチャ配信予定時刻情報は、例えば図１０に示したように、ＩＰヘッダと、ＵＤＰヘッダと、ＲＴＰヘッダと、ＲＴＰペイロードと、から構成されている。ＩＤＲピクチャ配信予定時刻情報は、図１０に示したように、ＵＤＰパケットのＲＴＰペイロードに格納され、１２バイトのヘッダとともにＭ個のＩＤＲピクチャ送出予定時刻レコードが記述される。
ＩＤＲピクチャ配信予定時刻情報のヘッダには、このＵＤＰパケットがＩＤＲピクチャ配信予定時刻情報のパケット形式であることを示す識別子や、バージョン番号等が指定される。ひとつのＭＰＥＧストリームのＩＤＲピクチャ配信予定時刻情報は、ＩＰマルチキャストアドレス（４バイト）と、配信予定時刻（４バイト）とからなる８バイトで表記され、ひとつのＵＤＰパケットは、Ｍ＝１５０個ほどのＭＰＥＧストリームに対する配信予定時刻が記述可能である。
ひとつのレコードのＩＰマルチキャストアドレスは、以下で説明するようなブロードキャストディスカバリーレコードの各チャンネルのＩＰＭｕｌｔｉｃａｓｔＡｄｄｒｅｓｓに対応するものであり、該当するＩＰマルチキャストのストリームのＩＤＲピクチャを含むＩＰパケットが、次に配信される予定時刻が記録されている。
配信予定時刻は、例えば１０００分の１秒程度の精度で十分であるが、１００００分の１秒つまり０．１ミリ秒の精度とすることが好ましい。この配信予定時刻は、少なくとも同じチャンネルのＩＰマルチキャストストリームを送出する各処理部１１間において、同じクロックで計測されていれば十分であるが、すべての処理部にて同じクロックにて配信予定時刻の計測をおこなってもよい。
次に、図１０を参照しながら、コンテンツ配信システム１の各コンテンツサーバ１０で計測されたＩＤＲピクチャの配信予定時刻情報を集計して、端末である情報処理装置２０に伝送する仕組みを説明する。
前述のように、すべてのコンテンツサーバ１０および情報処理装置２０のクロックは、ＮＴＰ（Ｎｅｔｗｏｒｋ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）によってネットワークに接続された基準クロックサーバ４０のクロックと同期するように設定されており、各コンテンツサーバ１０は、この基準クロックにＮＴＰにて自身のクロックを同期させ、同期したクロックにて次のＩＤＲピクチャが配信される予定時刻を算出する。コンテンツサーバ１０の処理部１１内に設けられた配信部は、前述のように、算出した時刻を、ＩＤＲピクチャ配信予定時刻情報送信サーバ３０に送信する。
この場合、各処理部１１の配信部は、図１０で示したＵＤＰパケットを、ＩＰユニキャストにて送信する。このＵＤＰパケットには、その処理部１１が送出するＩＰパケットストリームについての配信予定時刻レコードのみ記録される。換言すれば、図１０のＵＤＰパケットは、Ｍ＝１となる。ＩＤＲピクチャ配信予定時刻情報送信サーバ３０は、各コンテンツサーバ１０（より詳細には、各処理部１１）から送信されたＩＤＲピクチャ配信予定時刻を集計して、図１０に示したようなＵＤＰパケットを生成する。
図１および図２に示したように、コンテンツ配信システム１上に３００チャンネル（すなわち、３００台のコンテンツサーバ１０）が存在し、各チャンネルあたり２つの処理部１１がある場合は、図１０に示したＵＤＰパケットは、６００個のＩＰマルチキャストストリームの情報となる。そのため、各ＵＤＰパケットでは、Ｍ＝１５０となり、４つのＵＤＰパケットに分割されて送信される。ＵＤＰパケットの喪失の恐れがネットワーク環境においては、重複して同一のパケットを送信する。
配信予定時刻情報送信サーバ３０から送信されるＵＤＰパケットのＩＰマルチキャストアドレスは、後述するようなブロードキャストディスカバリーレコードのＣｈａｎｎｅｌＣｈａｎｇｅＩｎｆｏに指定したＩＰマルチキャストアドレスである。各情報処理装置２０は、ＩＤＲピクチャ配信予定時刻情報を受信するためには、このＩＰマルチキャストアドレスを指定してＩＧＭＰにてマルチキャストグループへの加入を行う。ＩＤＲピクチャの配信時刻情報の送出は、例えば、１秒間に１００回ほどの頻度、つまり１０ミリ秒周期にておこなわれ、情報処理装置２０は、１０ミリ秒ごとに最新のＩＤＲピクチャ配信予定時刻情報を受信できる。
なお、本実施形態に基づけば、本来、各コンテンツサーバ１０から配信されるプレビュー用ストリームのＩＤＲピクチャは同時刻に配信されるので、送出予定時刻情報も同一であり、各コンテンツサーバ１０はこれについて通知する必要はない。しかしながら、本実施形態に係る配信予定時刻情報送信サーバ３０は、各プレビュー用ストリーム処理部１１Ａから出力される情報についても集計する。
視聴用ストリーム処理部１１Ｂから出力される配信予定時刻は、情報処理装置２０がチャンネルザッピングから、チャンネルの視聴へとマルチキャスト配信を切り替える際に、視聴用データストリームのＩＤＲピクチャを情報処理装置２０が受信するまでの待ち時間を最適化して、シームレスにストリームを移行するために利用される。
［ＩＰパケットの伝送について］
次に、図１１および図１２を参照しながら、本実施形態に係るＩＰパケットが情報処理装置へ伝送される仕組みについて、詳細に説明する。なお、以下では、ＩＰＴＶシステムの規格であるＤＶＢ−ＩＰ（ＥＴＳＩ ＴＳ１０２ ０３４）に基づき、詳細に説明を行う。
端末である情報処理装置２０は、各チャンネルに対するＭＰＥＧストリームを受信するために、チャンネルのデータが配信されるＩＰマルチキャストアドレスを知る必要がある。ＤＶＢ−ＩＰでは、チャンネルの情報は、ＳＤ＆Ｓのブロードキャストディスカバリーレコードに記述される。このブロードキャストディスカバリーレコードは、ＥＰＧサーバ等のＩＰＴＶアプリケーションサーバ（図示せず。）から情報処理装置２０へと、ＤＶＢ−ＩＰ規定のＤＶＢ ＳＤ＆Ｓ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ（ＤＶＢ ＳＴＰ）によりマルチキャストで伝送される。なお、このブロードキャストディスカバリーレコードは、ＭＰＥＧ２−ＴＳストリームとは別のＩＰマルチキャストアドレスにて転送される。
そのため、本実施形態に係るコンテンツ配信システム１内に存在するコンテンツサーバ１０は、事前に、コンテンツサーバ１０の各処理部１１に割り当てられているＩＰマルチキャストアドレスや、各種のチャンネル情報を、ＩＰＴＶアプリケーションサーバに通知しておく必要がある。
図１１は、ＤＶＢ−ＩＰのブロードキャストディスカバリーレコードのデータ形式を説明するための説明図である。ブロードキャストディスカバリーレコードには、ＩＰＴＶサービスが提供するすべてのチャンネルの情報が記述されている。例えば、３００チャンネル放送するＩＰＴＶサービスであれば、端末である情報処理装置２０は、３００個のチャンネルの情報が記述されたブロードキャストディスカバリーレコードを受信する。
チャンネル情報としては、例えば図１１に示したように、ＴｅｘｔｕａｌＩｄｅｎｔｉｆｉｅｒ＠ＳｅｒｖｉｃｅＮａｍｅにはチャンネル名が文字列で記述され、チャンネル名を表示するのに使用される。また、ＩＰＭｕｌｔｉｃａｓｔＡｄｄｒｅｓｓ＠ＡｄｄｒｅｓｓとＩＰＭｕｌｔｉｃａｓｔＡｄｄｒｅｓｓ＠Ｐｏｒｔには、視聴用ストリーム処理部１１Ｂから配信されるＩＰマルチキャストパケットのＩＰマルチキャストアドレスとポート番号とが記述されている。
端末である情報処理装置２０は、ＩＧＭＰにて、ブロードキャストディスカバリーレコードに記載されているＩＰマルチキャストアドレスグループに加入することで、希望のチャンネルのＩＰマルチキャストパケットの配信が開始され、ＩＰマルチキャストパケットを受信可能となる。
さらに、本実施形態に係るブロードキャストディスカバリーレコードでは、ＤＶＢ−ＩＰ規格におけるブロードキャストディスカバリーレコードを拡張し、＜ｘｘ：ＰｒｅｖｉｅｗＳｅｒｖｉｃｅＬｏｃａｔｉｏｎ＞というＸＭＬエレメントを設ける。本実施形態に係るブロードキャストディスカバリーレコードでは、このＸＭＬエレメントに、プレビュー用ストリーム処理部１１Ａから出力されるＩＰマルチキャストパケットのＩＰマルチキャストアドレスとポート番号とが記述される。
図１２は、ブロードキャストディスカバリーレコードをＸＭＬ表記した場合の例を説明するための説明図である。このブロードキャストディスカバリーレコードの例では、３００チャンネル分のサービス情報が記述されており、各「＜ＳｉｎｇｌｅＳｅｒｖｉｃｅ＞」のＸＭＬエレメントが、チャンネルひとつ分の情報に相当する。
例えば、先頭のチャンネル情報には、チャンネル名（ＳｅｒｖｉｃｅＮａｍｅ）である「Ｃｈａｎｎｅｌ １」が記載されている。さらに、視聴用ストリーム処理部１１Ｂから出力されるＩＰパケットのマルチキャストアドレス（アドレス２２４．０．１．１、ポート番号１６００）と、プレビュー用ストリーム処理部１１Ａから出力されるＩＰパケットのマルチキャストアドレス（アドレス２２４．０．１．１、ポート番号１６００）とが記述されている。次に列挙されているチャンネル情報では、チャンネル名である「Ｃｈａｎｎｅｌ ２」と、視聴用およびプレビュー用の２種類のマルチキャストアドレスが記述されている。以下、チャンネル情報の記述は省略されているが、合計３００チャンネル分の情報が列挙されて記述されることになる。以上のブロードキャストディスカバリーレコードにより、情報処理装置２０は、各チャンネルにおけるプレビュー用と視聴用の２つのチャンネルアドレスを知ることが可能となる。
次に、各マルチキャストアドレスで配信されるＭＰＥＧ２−ＴＳストリームでのＩＤＲピクチャ配信予定情報の取得方法について、説明する。本実施形態では、ＤＶＢ−ＩＰ規定のブロードキャストディスカバリーレコードを拡張し、「＜ＣｈａｎｎｅｌＣｈａｎｇｅＩｎｆｏ＞」というＸＭＬエレメントを記述する。「＜ＣｈａｎｎｅｌＣｈａｎｇｅＩｎｆｏ＞」のＸＭＬエレメントでは、ＩＰＴＶサービスから配信されるすべてのＭＰＥＧストリームのＩＤＲピクチャ配信予定時刻情報を取得可能な、配信予定時刻情報送信サーバ３０のマルチキャストアドレスが、「＜ＩＰＭｕｌｔｉｃａｓｔＡｄｄｒｅｓｓ＞」に指定されている。図１２に示した例では、ＩＤＲピクチャ配信予定時刻情報は、アドレス２２４．０．１．０のポート番号１５００から取得できることが示されている。
以上説明したように、本実施形態に係るコンテンツ配信方法では、一つのチャンネルに対して、プレビュー用に符号化された圧縮データストリームと、視聴用に符号化された圧縮データストリームの２種類が配信されることとなる。プレビュー用に符号化された圧縮データストリームは、ＩＤＲピクチャに例示される基準圧縮映像データのみから構成されており、このデータストリームが格納されたパケットは、高速チャンネルザッピングに適したシェーピングがなされる。その結果、本実施形態に係るコンテンツ配信方法では、端末である情報処理装置がプレビュー用圧縮データストリームを取得し、その再生を複数チャンネルに対して繰り返すことによって、高速チャンネルザッピングを実現することが可能となる。
＜情報処理方法について＞
続いて、図１３〜図２０を参照しながら、本実施形態に係る情報処理装置２０が実行する情報処理方法について、詳細に説明する。図１２は、本実施形態に係る情報処理装置２０が実施する情報処理方法を説明するための流れ図である。
視聴者（ユーザ）により、本実施形態に係る情報処理装置２０の電源が投入された場合や、ＩＰＴＶのサービスメニュー等からＴＶサービスが選択された場合には、本実施形態に係る情報処理装置２０は、ＴＶ視聴処理を開始する。
まず、情報処理装置２０は、装置に備えられているＣＰＵ、ＲＯＭ、ＲＡＭ、通信装置等を利用して、ＥＰＧサーバ等のＩＰＴＶアプリケーションサーバ（図示せず。）からブロードキャストディスカバリーレコードを取得する（ステップＳ１０１）。このブロードキャストディスカバリーレコードは、図１２に示したようなＤＶＢ−ＩＰ規定のプロトコルに基づいて記載されており、情報処理装置２０は各チャンネルに対応したチャンネル情報を取得することができる。チャンネル情報が頻繁には変わらない場合には、既にＩＰＴＶサービスから取得済みのチャンネル情報を利用するようにしてもよい。
次に、情報処理装置２０は、装置に備えられているＣＰＵ、ＲＯＭ、ＲＡＭ、通信装置等を利用して、ＩＤＲピクチャ配信予定時刻情報の配信開始要請のためのＩＧＭＰメッセージの発行と、この配信予定時刻情報に関するマルチキャストパケットの受信を開始する（ステップＳ１０３）。
情報処理装置２０がマルチキャストグループに参加および離脱する場合は、図７Ａに示したレポートフォーマットのＩＧＭＰメッセージを利用する。
より詳細には、情報処理装置２０がＩＤＲピクチャ配信予定時刻情報を配信しているマルチキャストグループの配信開始を指示するには、図１４Ａに示したようなＩＧＭＰメッセージを発行する。「Ｒｅｃｏｒｄ Ｔｙｐｅ」の欄に指定されている「１」という値は、ＭＯＤＥ＿ＩＳ＿ＩＮＣＬＵＤＥを示し、上述のステップＳ１０１にて取得したマルチキャストアドレス（例では２２４．０．１．０）に対して、マルチキャストグループに参加することを示すものである。このＩＧＭＰによるマルチキャストグループへの参加により、配信予定時刻情報送信サーバ３０から、ＩＤＲピクチャ配信予定時刻情報が定期的（例えば、１０ミリ秒周期）に情報処理装置２０へ配信されることとなる。情報処理装置２０は、ＩＤＲピクチャ配信予定時刻情報を受信し、記憶部２０９に常に最新の情報を保持しておく。
続いて、情報処理装置２０のチャンネル選択部２０１は、チャンネル選択情報の初期設定を実施する（ステップＳ１０５）。初期設定されるチャンネル選択情報は、「ＣｕｒｒｅｎｔＣｈａｎ」、「ＣｕｒｒｅｎｔＡｄｄｒｅｓｓ」、「ＳｅｌｅｃｔＣｈａｎ」、「ＳｅｌｅｃｔＡｄｄｒ」という４つのパラメータである。
パラメータ「ＣｕｒｒｅｎｔＣｈａｎ」は、情報処理装置２０が現在選局中のチャンネルのポジションを示すパラメータであり、パラメータ「ＣｕｒｒｅｎｔＡｄｄｒｅｓｓ」は、現在選局されているチャンネルが配信されているマルチキャストアドレスを示すパラメータである。初期設定では、これら２つのパラメータともに−１を設定する。これは、現在、チャンネル選局がおこなわれていないことを示す値である。また、パラメータ「ＳｅｌｅｃｔＣｈａｎ」は、これから選局するチャンネルのチャンネルポジションを示すパラメータであり、パラメータ「ＳｅｌｅｃｔＡｄｄｒ」は、選局されたチャンネルのＭＰＥＧ２−ＴＳストリームが配信されるマルチキャストアドレスを示すパラメータである。初期設定では、「ＳｅｌｅｃｔＣｈａｎ」には１を設定する。もし、以前に選曲したチャンネル情報を端末が保持している場合は、そのチャンネルポジションを指定する。「ＳｅｌｅｃｔＡｄｄｒｅｓｓ」には、−１を設定して初期化を行う。
続いて、チャンネル選択部２０１は、パラメータ「ＳｅｌｅｃｔＣｈａｎ」に示されたチャンネルを取得ストリーム選択部２０３に通知する。取得ストリーム選択部２０３は、パラメータ「ＳｅｌｅｃｔＣｈａｎ」に設定されたチャンネルの視聴用圧縮データストリームを取得するようにコンテンツ取得部２０５に通知し、コンテンツ取得部２０５は、視聴用ストリームへの切り替え処理を行う（ステップＳ１０７）。この視聴用ストリームへの切り替え処理については、以下で改めて詳細に説明する。この処理により、情報処理装置２０の表示部（図示せず。）の画面には、チャンネルの映像が表示され、スピーカからは音声が再生される。
視聴用ストリームへの切り替え処理が終了すると、チャンネル選択部２０１は、現在選局中のチャンネルに関するチャンネル情報を更新する（ステップＳ１０９）。すなわち、パラメータ「ＣｕｒｒｅｎｔＣｈａｎ」にはパラメータ「ＳｅｌｅｃｔＣｈａｎ」の値が設定され、パラメータ「ＣｕｒｒｅｎｔＡｄｄｒ」にはパラメータ「ＳｅｌｅｃｔＡｄｄｒ」の値が設定される。
続いて、情報処理装置２０のチャンネル選択部２０１は、ユーザ操作の入力を待ち受ける（ステップＳ１１１）。
ここで、ユーザにより、例えば、リモコンの電源オフボタンを押すなど終了操作が入力された場合には（ステップＳ１１３）、チャンネル選択部２０１は、入力された操作に応じた信号を生成し、ステップＳ１２３のチャンネル受信終了処理に進む。また、ユーザにより、チャンネルを切り替えてチャンネルプレビューを行う旨の操作が入力された場合には（ステップＳ１１５）、後述するステップＳ１１７に進む。そうでなかった場合は、ステップＳ１１１に戻り、ユーザ操作の待ちうけを行う。実際には、これらの制御以外にも、ボリューム制御等の他のユーザ操作の処理もあるが、図１３での記述は省略する。
ユーザにより、チャンネル切り替え操作、例えば、リモートコントローラのチャンネルアップボタンやチャンネルダウンボタンが操作された場合には、情報処理装置２０は、チャンネルプレビュー処理を行う（ステップＳ１１７）。このチャンネルプレビュー処理については、以下で改めて詳細に説明する。
その後、チャンネル選択部２０１は、ステップＳ１０９と同様に、現在選局中のチャンネルに関するチャンネル情報を更新する（ステップＳ１１９）。
続いて、情報処理装置２０のチャンネル選択部２０１は、ユーザ操作の入力を待ち受け、ＴＶ視聴が続く。
他方、ユーザ操作が終了操作であった場合には、コンテンツ取得部２０５は、チャンネル受信終了処理を実施する（ステップＳ１２１）。チャンネル受信終了処理については、以下で改めて詳細に説明する。
その後、情報処理装置２０は、装置に備えられているＣＰＵ、ＲＯＭ、ＲＡＭ、通信装置等を利用して、ステップＳ１０３にて開始したＩＤＲピクチャ配信予定時刻情報の配信を停止させ、配信予定時刻情報のマルチキャストパケットの受信も終了する（ステップＳ１２３）。情報処理装置２０は、図１４Ｂに示したようなＩＧＭＰメッセージを送信することで、配信を停止可能である。ここで、図１４Ｂにおける「ＲｅｃｏｒｄＴｙｐｅ＝２」は、ＭＯＤＥ＿ＩＳ＿ＥＸＣＬＵＤＥであることを示し、２２４．０．１．０のマルチキャストグループからの離脱を意味する。
続いて、情報処理装置２０は、ＴＶ視聴を終了し、他のＩＰＴＶサービスメニューに戻るか、端末の他の機能に移行する。
［チャンネルプレビュー処理について］
続いて、図１５を参照しながら、本実施形態に係る情報処理装置２０が実施するチャンネルプレビュー処理について、詳細に説明する。図１５は、本実施形態に係る情報処理方法におけるチャンネルプレビュー処理を説明するための流れ図である。
チャンネルプレビュー処理は、各チャンネルに対応するプレビュー用圧縮データストリームの映像を順番に切り替えて再生する。この際に、最初は例えば０．８秒間隔でチャンネル切り替えを行い、視聴者がチャンネルプレビュー操作を継続し続ける（例えば、チャンネル切替ボタン等を押し続ける）と、チャンネルの切り替えが早くなるように設定される。チャンネル切り替えの時間間隔（換言すれば、チャンネル切替速度）の最小値は、任意に設定することが可能であるが、例えば０．１秒間隔で映像の切り替えを行うことが可能である。本処理では、チャンネル切替速度を変更するタイミングを判定するために利用される切替速度変更時間が定義される。この切替速度変更時間は、例えば２秒程度に設定することが可能である。
まず、チャンネル選択部２０１は、チャンネルプレビューに関する２つのパラメータである、パラメータ「ＰｒｅｖｉｅｗＩｎｔｅｒｖａｌ」と、パラメータ「ＰｒｅｖｉｅｗＴｉｍｅｒ」とを初期化する（ステップＳ２０１）。ここで、パラメータ「ＰｒｅｖｉｅｗＩｎｔｅｒｖａｌ」は、チャンネルを切り替えるタイミングの基準として利用され、本ステップでは、例えば８００ミリ秒（０．８秒）に設定される。これにより、視聴者がチャンネルプレビュー操作を継続していた場合には、０．８秒間隔でチャンネル切り替えが行われる。また、パラメータ「ＰｒｅｖｉｅｗＴｉｍｅｒ」は、チャンネル切り替えのタイミングを計測するためのタイマーとして利用され、本ステップでは、既にチャンネルプレビューを開始しているので、初期値として現在時刻が設定される。
続いて、チャンネル選択部２０１は、チャンネルプレビューで次に切り替えるチャンネルの設定を行う（ステップＳ２０３）。例えば、リモートコントローラのＮＥＸＴボタンのように、チャンネル番号を増加させてプレビューを行う操作がなされた場合には、チャンネル選択部２０１は、パラメータ「ＣｕｒｒｅｎｔＣｈａｎ」に１を加算した値を、パラメータ「ＳｅｌｅｃｔＣｈａｎ」に設定する。また、チャンネル番号を減少させてプレビューを行う操作がなされた場合には、チャンネル選択部２０１は、パラメータ「ＣｕｒｒｅｎｔＣｈａｎ」に１を減算した値を、パラメータ「ＳｅｌｅｃｔＣｈａｎ」に設定する。また、チャンネル選択部２０１は、パラメータ「ＰｒｅｖｉｅｗＳｗｉｔｃｈＴｉｍｅ」を設定する。このパラメータは、次のチャンネルへの切り替え操作の実行を決定する際に利用されるパラメータであり、本ステップでは、現在時刻が設定される。
次に、情報処理装置２０は、パラメータ「ＳｅｌｅｃｔＣｈａｎ」に設定されたチャンネルのプレビュー用圧縮データストリームへの切り替えを行う（ステップＳ２０５）。このプレビュー用ストリームへの切り替え処理については、以下で詳細に説明する。
プレビュー用圧縮データストリームへの切り替え後に、チャンネル選択部２０１は、現在プレビュー中のチャンネルに関するチャンネル情報を更新する（ステップＳ２０７）。すなわち、パラメータ「ＣｕｒｒｅｎｔＣｈａｎ」にはパラメータ「ＳｅｌｅｃｔＣｈａｎ」の値が設定され、パラメータ「ＣｕｒｒｅｎｔＡｄｄｒ」にはパラメータ「ＳｅｌｅｃｔＡｄｄｒ」の値が設定される。
続いて、チャンネル選択部２０１は、視聴者がプレビュー操作（チャンネルザッピング操作）を継続しているかを確認する（ステップＳ２０９）。より詳細には、例えば、チャンネル選択部２０１にチャンネルの変更に関する入力信号が入力されたか否かに基づいて確認することが可能である。視聴者が切り替えたプレビュー用圧縮データストリームに対応するチャンネルを視聴することにし、チャンネルを決定した場合には、後述するステップＳ２１１が実施される。また、視聴者がプレビュー操作を継続している場合には、後述するステップＳ２１３が実施される。
視聴するチャンネルが決定した場合には、情報処理装置２０は、視聴用圧縮データストリームへの切り替え処理を行う（ステップＳ２１１）。この視聴用圧縮データストリームへの切り替え処理については、以下で詳細に説明する。
このようにして、チャンネルのプレビュー処理は終了し、そのままＩＰＴＶテレビ視聴は継続することとなる。
他方、プレビュー操作が継続している場合には、情報処理装置２０の取得ストリーム選択部２０３は、チャンネルの切替速度を変更するか否かを判定する（ステップＳ２１３）。より詳細には、取得ストリーム選択部２０３は、パラメータ「ＰｒｅｖｉｅｗＴｉｍｅｒ」から現在時刻を減算して得られた時間が、切替速度変更時間よりも大きいか否かに基づいて行われる。減算して得られた時間が切替速度変更時間よりも大きい場合には、後述するステップＳ２１５が実施される。また、減算して得られた時間が切替速度変更時間以下である場合には、後述するステップＳ２１７が実施される。
減算して得られた時間が切替速度変更時間よりも大きい場合には、取得ストリーム選択部２０３は、パラメータ「ＰｒｅｖｉｅｗＩｎｔｅｒｖａｌ」の値が最小値になっているか否かを判定する（ステップＳ２１５）。パラメータ「ＰｒｅｖｉｅｗＩｎｔｅｒｖａｌ」の値が最小値以下である場合には、チャンネルの切替速度を変更せずに、後述するステップＳ２１９を実施する。また、パラメータ「ＰｒｅｖｉｅｗＩｎｔｅｒｖａｌ」の値が最小値超過である場合には、後述するステップＳ２１７を実施する。
チャンネルの切替速度が最小値よりも大きい場合には、取得ストリーム選択部２０３は、チャンネルの切替速度を変更する（ステップＳ２１７）。例えば、取得ストリーム選択部２０３は、現在設定されている切替速度の半分の値を、新たな切替速度として設定することが可能である。本実施形態では、パラメータ「ＰｒｅｖｉｅｗＩｎｔｅｒｖａｌ」は８００ミリ秒に初期設定されており、プレビュー操作を継続中の場合には、例えば切替速度変更時間毎に切替速度の変更が行われる。その後、切替速度の変更に伴い、パラメータ「ＰｒｅｖｉｅｗＩｎｔｅｒｖａｌ」の値は、８００ミリ秒、４００ミリ秒、２００ミリ秒、１００ミリ秒の４段階で変更される。なお、上述の切替速度の変更方法は、あくまでも一例であって、チャンネルプレビューの画面構成や、リモートコントローラのボタン操作や、視聴者の嗜好等に応じて、様々な切替速度の変更方法が適用可能である。
続いて、取得ストリーム選択部２０３は、パラメータ「ＰｒｅｖｉｅｗＩｎｔｅｒｖａｌ」に設定されている時間が、以前のチャンネル切り替えから経過しているか否かを判定する（ステップＳ２１９）。より詳細には、取得ストリーム選択部２０３は、パラメータ「ＰｒｅｖｉｅｗＳｗｉｔｃｈＴｉｍｅｒ」の値にパラメータ「ＰｒｅｖｉｅｗＩｎｔｅｒｖａｌ」の値を加算した時刻が、現在時刻を経過しているか否かを判定する。現在時刻を経過していない場合には、このステップで待機を行う。また、現在時刻を経過している場合には、前述のステップＳ２０３に戻って、次のチャンネルのプレビュー用圧縮データストリームへの切り替えを行う。
［プレビュー用圧縮データストリームへの切り替え処理について］
続いて、図１６を参照しながら、本実施形態に係る情報処理装置２０が実施するプレビュー用圧縮データストリームへの切り替え処理について、詳細に説明する。図１６は、本実施形態に係る情報処理方法におけるプレビュー用圧縮データストリームへの切り替え処理を説明するための流れ図である。
まず、取得ストリーム選択部２０３は、記憶部２０９等に記録されている最新のＩＤＲピクチャ配信予定時刻情報から、パラメータ「ＳｅｌｅｃｔＣｈａｎ」に該当するチャンネル情報を取得する（ステップＳ３０１）。
より詳細には、取得ストリーム選択部２０３は、まず、ブロードキャストディスカバリーレコードからチャンネルのマルチキャストアドレスを取得する。図１２に示した例では、パラメータ「ＳｅｌｅｃｔＣｈａｎ」が１に設定されている場合、先頭位置の「＜ＳｉｎｇｌｅＳｅｒｖｉｃｅ＞」が該当するチャンネル情報である。このチャンネル情報の「＜ＳｅｒｖｉｃｅＬｏｃａｔｉｏｎ＞」には、図１２に示したように、プレビュー用圧縮データストリームおよび視聴用圧縮データストリームの２種類のマルチキャストアドレスが記述されている。図１２の例では、パラメータ「ｘｘ：ＰｒｅｖｉｅｗＳｅｒｖｉｃｅＬｏｃａｔｉｏｎ」に記載されている＜ＩＰＭｕｌｔｉｃａｓｔＡｄｄｒｅｓｓ＞の値より、２２４．０．１．２が設定される。
次に、取得ストリーム選択部２０３は、最新のＩＤＲピクチャ配信予定時刻情報から、各マルチキャストアドレスの配信予定時刻情報レコードを検索し、ＩＤＲピクチャ配信予定時刻を「ＮｅｘｔＴｉｍｅ」に設定する。ただし、ＩＤＲピクチャの配信時刻はコンテンツサーバ１０の各配信部から送出された時刻であり、本来、ＩＤＲピクチャを含む先頭のＭＰＥＧ２−ＴＳパケットが情報処理装置２０に届くまでには遅延がある。そのため、遅延時間が大きく無視できない場合は、コンテンツサーバ１０から情報処理装置２０までのネットワークの条件に合わせて、「ＮｅｘｔＴｉｍｅ」に適宜遅延時間を加算する必要がある。
次に、取得ストリーム選択部２０３は、マルチキャスト配信の切替完了予想時刻を算出する（ステップＳ３０３）。この切替完了予想時刻は、直ちにＩＧＭＰメッセージを発行して配信の開始や切り替えを行った場合に、新規に加入したマルチキャストグループの最初のパケットが到着するまでの予想時間である。この切替完了予想時刻「ＳｗｉｔｃｈＴｉｍｅ」は、現在時刻に切替所要時間を加算することで得ることができる。ここで、切替所要時間は、以下に示した時間の総和となる。
（１） 情報処理装置２０がＩＧＭＰメッセージを発行するまでに要する時間
（２） ＩＧＭＰメッセージがＩＧＭＰプロクシーをおこなっているエッジスイッチ、（例えば、ＤＳＬＡＭ）に到達するまでの所要時間
（３） エッジスイッチが、現在、端末の接続されているアクセスネットワークに配信しているマルチキャストグループのパケットの配信を停止し、新たに加入したマルチキャストグループのパケットの配信を開始するまでの所要時間
（４） エッジスイッチが配信を開始した最初のパケットが情報処理装置２０に到達するまでの所要時間
（５） 情報処理装置２０が最初のパケットを受信して保存するのに要する時間
上記（１）〜（５）の値は、ＩＰＴＶサービスのネットワークおよび情報処理装置２０の性能に依存し、情報処理装置２０やネットワークの条件に対応する切替所要時間の最大値が、予め情報処理装置２０に設定されているものとする。例えば、切替所要時間の最大値を、８ミリ秒程度に設定することが可能である。
また、上記（３）において、加入者宅に複数台の情報処理装置２０が接続されている場合は、パケット配信の停止に際して、他の情報処理装置２０が同じマルチキャストグループへ加入していないかを確認するために要する時間も含む。通常、この確認は、ＲＦＣ−３３７６に規定されているように、定期的なＩＧＭＰクエリーメッセージによって行われる。また、複数の情報処理装置２０が、個別のマルチキャストグループへの加入、つまり、複数の情報処理装置２０にて異なるチャンネルを視聴する場合には、アクセスネットワークには、複数のチャンネル分のマルチキャストを流すのに十分なデータ帯域が必要となる。このためのネットワークの帯域保障には、例えば、ＩＭＳ（ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ）などのＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）制御が利用可能である。
続いて、取得ストリーム選択部２０３は、配信の切り替えを実行するか否かを判定する（ステップＳ３０５）。より詳細には、取得ストリーム選択部２０３は、プレビュー用ストリームのＩＤＲピクチャを含むＩＰパケット到着時刻と、算出した切替完了予定時刻ＳｗｉｔｃｈＴｉｍｅとの差を、所定の閾値と比較する。算出した差が閾値よりも大きい場合は、配信の切り替えは行わず、次のＩＤＲピクチャ配信予定時刻情報のパケットまで待って（ステップＳ３０７）、ステップＳ３０１からの処理を実施する。
この切り替え実行に関する判定は、以下のような理由のために設定される。すなわち、直ちに表示の切り替えを実施したとしても、パケットの受信を開始してＩＤＲピクチャが到着するまでは、情報処理装置２０のコンテンツ再生部２０７は映像を伸張できない。そのため、画像が停止してしまう期間（以下、フリーズ期間と称する。）が生じてしまう。この判定により、フリーズ期間を短縮することが可能である。シームレスな映像の切り替えには、フリーズ期間をできるだけ短くするのが望ましいが、ＩＤＲピクチャの配信予定時刻のパケットの送出周期よりも長くする必要がある。そのため、フリーズ期間の最大値（以下、フリーズ許容時間と称する。）は、例えば、１０ミリ秒に設定することが好ましい。
上述のような条件判定に基づき、取得ストリーム選択部２０３によってタイミングの決定がなされると、選局結果が、取得ストリーム選択部２０３からコンテンツ取得部２０５へと伝送される。コンテンツ取得部２０５は、選局結果に基づいてＩＧＭＰメッセージを発行して、情報処理装置２０が接続しているアクセスネットワークへ配信されるマルチキャストパケットの配信切り替えを行う（ステップＳ３０９）。このＩＧＭＰメッセージの発行は、図７Ａおよび図７Ｂに示したＲＦＣ−３３７６規定のＩＧＭＰバージョン３のレポートフォーマットにて行われる。
図１７Ａ〜図１７ＣにＩＧＭＰパケットの例を示す。図１７Ａは、パラメータ「ＣｕｒｒｅｎｔＣｈａｎ」が−１の場合、つまり、既に配信しているマルチキャストがない場合のものである。図１７Ａでは、パラメータ「ＳｅｌｅｃｔＣｈａｎ」（例では１）のマルチキャストアドレス「ＳｅｌｅｃｔＡｄｄｒｅｓｓ」（例では２２４．０．１．１）のマルチキャストグループに対して、ＲｅｃｏｒｄＴｙｐｅ＝１（ＭＯＤＥ＿ＩＳ＿ＩＮＣＬＵＤＥ）を指定して、マルチキャストデータ配信を開始するためにマルチキャストアドレスに加入することを意味している。図１７Ｂは、パラメータ「ＣｕｒｒｅｎｔＣｈａｎ」が−１以外の場合、つまり、既に配信しているマルチキャストアドレスがある場合のものである。例えば、「ＣｕｒｒｅｎｔＣｈａｎ」（例では１）の「ＣｕｒｒｅｎｔＡｄｄｒｅｓｓ」（例２２４．０．１．０）のマルチキャストグループに、ＲｅｃｏｒｄＴｙｐｅ＝２（ＭＯＤＥ＿ＩＳ＿ＥＸＣＬＵＤＥ）を指定して配信の停止を指示し、「ＳｅｌｅｃｔＣｈａｎｎｅｌ」（例では２）のマルチキャストアドレス「ＳｅｌｅｃｔＡｄｄｒｅｓｓ」（例では２２４．０．１．４）のマルチキャストグループに、ＲｅｃｏｒｄＴｙｐｅ＝１（ＭＯＤＥ＿ＩＳ＿ＩＮＣＬＵＤＥ）を指定して配信の開始を指示している。
ＩＭＧＰバージョン３では、図１７Ｂに示したように、ひとつのＩＧＭＰパケットによって一括して指示がおこなえるので、切り替え時にアクセスネットワークに重複してマルチキャストアドレスが配信されないような実装が可能であるという利点がある。
これにより、コンテンツ取得部２０５は、「ＳｅｌｅｃｔＡｄｄｒｅｓｓ」のマルチキャストパケットの受信を開始することとなる（ステップＳ３１１）。
配信の切り替えが完了するまでは、最大切替所要時間の間待機する必要があるので、マルチキャストパケットを受信していない場合は待機する（ステップＳ３１３）。ネットワークにてＩＧＭＰパケットの喪失の恐れがある場合は、複数のパケットをステップＳ３０９にて送信しておくか、ステップＳ３０９にてタイムアウトなどを設けて、ＩＧＭＰパケットの再送信の処理を行うようにしてもよい。
ステップＳ３１３で待機した結果、待機後にはマルチキャストの配信切り替えが終了しているので、以前選局していたチャンネルが存在する場合には、コンテンツ取得部２０５は、該当する「ＣｕｒｒｅｎｔＡｄｄｒｅｓｓ」のマルチキャストパケットの受信を終了する（ステップＳ３１５）。
その後、コンテンツ取得部２０５は、受信したマルチキャストパケットをコンテンツ再生部２０７に伝送し、コンテンツ再生部２０７は、新たに受信を開始したチャンネルのマルチキャストパケットに格納されているＭＰＥＧ２−ＴＳの再生を開始する（ステップＳ３１７）。実際には、ＩＤＲピクチャを含むＭＰＥＧ２−ＴＳパケットを受信してから、映像が情報処理装置２０の表示部（図示せず。）に表示されることになる。このようにして、プレビュー用圧縮データストリームの切り替え処理は終了し、そのままチャンネルプレビューは継続することとなる。
［視聴用圧縮データストリームへの切り替え処理について］
続いて、図１８を参照しながら、本実施形態に係る情報処理装置２０が実施する視聴用圧縮データストリームへの切り替え処理について、詳細に説明する。図１８は、本実施形態に係る情報処理方法における視聴用圧縮データストリームへの切り替え処理を説明するための流れ図である。
本実施形態に係る情報処理方法における視聴用圧縮データストリームへの切り替え処理は、図１８に示したように、図１６に示したプレビュー用圧縮データストリームへの切り替え処理と同様の流れにより行われる。本実施形態に係る視聴用圧縮データストリームへの切り替え処理は、図１６におけるプレビュー用圧縮データストリームに関するパラメータに換えて視聴用圧縮データストリームに関するパラメータを適用することで実行可能である。
ここで、図１８に示した配信の切り替え実行判定（ステップＳ４０５）において、以下のような観点で判断がなされる。すなわち、プレビュー用ストリームから視聴用ストリームに切り替える場合にも、取得ストリーム選択部２０３は、スムーズな切り替え、ブラックアウトや画面のフリーズ等を起こさないように処理を行う。そのため、取得ストリーム選択部２０３は、図１９に示すような場合分けにて、切り替えタイミングの判断を行う。この場合、前述のように、視聴用ストリームもデータ未送信期間があるようにシェーピングして配信され、そのデータ未送信期間がプレビュー用ストリームのデータ未送信期間と同時刻に存在するようになっているため、よりスムーズに切り替えを行うことができる。
図１９は、本実施形態に係る情報処理方法におけるデータストリームの切り替えタイミングの場合分けを説明するための説明図である。図１９に示した（ケース１）では、ストリームの切り替えがＩＤＲピクチャの到着までに間に合わないため、次のＩＤＲピクチャの到着を待ってから、視聴用ストリームへの切り替えを行う。また、図１９に示した（ケース２）では、ストリームの切り替えを行ったとしても、視聴用ストリームにおける次のＩＤＲピクチャを受信するまでは遅延が生じることとなる。そのため、視聴用ストリームの次のＩＤＲピクチャの受信を待ちながら、プレビュー用ストリームを受信し続ける。また、図１９に示した（ケース３）では、実際にプレビュー用ストリームから視聴用ストリームへと切り替えを行う。
［チャンネル受信終了処理について］
続いて、図２０を参照しながら、情報処理装置２０が実施するチャンネル受信終了の処理について詳細に説明する。
まず、コンテンツ取得部２０５は、現在、受信中のマルチキャストパケットを停止する。マルチキャストパケットの受信停止は、図１７Ｃに示したＩＧＭＰレポートメッセージを送信することで停止可能である（ステップＳ５０１）。図１７Ｃに示したように、コンテンツ取得部２０５は、パラメータ「ＣｕｒｒｅｎｔＡｄｄｒｅｓｓ」（例では２２４．０．１．４）のマルチキャストグループに対して、ＲｅｃｏｒｄＴｙｐｅ＝２（ＭＯＤＥ＿ＩＳ＿ＥＸＣＬＵＤＥ）を指定してＩＧＭＰメッセージを送信することで、マルチキャストパケット配信の停止ができる。
次に、コンテンツ取得部２０５は、マルチキャストの受信を終了する（ステップＳ５０３）。その後、コンテンツ再生部２０７は、ＭＰＥＧ２−ＴＳストリームの再生を終了する（ステップＳ５０５）。このような処理を行うことで、チャンネル受信終了の処理は完了する。
以上、本実施形態に係るＩＰＴＶシステムの高速チャンネル切り替えについて説明した。上記実施形態のみならず、本発明によれば、別の実施形態を考案することは容易であり、例えば、以下のような別の実施形態が考えられる。
また、本発明に係る実施形態では、Ｈ．２６４／ＡＶＣの場合について説明したが、ＭＰＥＧ２の映像圧縮を利用した場合でもＩＤＲピクチャをＩピクチャと考えることで、ＭＰＥＧ２の映像圧縮を利用したＩＰＴＶシステムにも、本発明を容易に適用することが可能である。
また、本発明に係る実施形態では、圧縮映像データと音声データとをＭＰＥＧ２−ＴＳにて多重化して送信したが、圧縮映像、音声データを個別にＩＰパケットにて配信する場合でも、本発明を適用することで、それらＩＰパケット配信を切り替えて高速チャンネル切り替えを実現するＩＰＴＶシステムを容易に実現することが可能である。
また、本発明に係る実施形態では、ひとつの映像音声信号のみを、圧縮映像データおよび音声データとしてＭＰＥＧ２−ＴＳにて多重化し、ＩＰパケットに格納した上で配信の切り替えを行う。しかしながら、ＭＰＥＧ２−ＴＳに複数の映像音声信号の圧縮映像データおよび音声データを多重化して配信し、情報処理装置２０へのネットワーク経路にて、選択された映像音声信号に該当する圧縮映像・音声パケットのみをフィルターして送信することで、本実施形態と同様の高速チャンネル切り替えを実現したＩＰＴＶシステムを容易に実現可能である。
また、本発明に係る実施形態では、ＩＤＲピクチャの配信予定時刻情報は、次に送出される一つのＩＤＲピクチャのみ端末である情報処理装置２０に送信した。ここで、ＩＤＲピクチャの配信予定時刻レコードに複数のＩＤＲピクチャについての配信予定時刻を指定して送信するようにすれば、情報処理装置２０は、より厳密にチャンネル選択時におけるマルチキャストアドレスの選択を行うことができるのは自明である。
また、本発明に係る実施形態では、プレビュー用圧縮データストリームは、ＩＤＲピクチャのＭＰＥＧ２−ＴＳパケットのみが配置されるように符号化されるが、データ未配信期間に区切られたチャンクには、ＩＤＲピクチャ以外のＰピクチャやＢピクチャを数枚配置するようにしてもよい。このようにすることで、スムーズにプレビュー映像を再生することが可能である。ただし、この場合には、プレビュー用圧縮データストリームの画像解像度や毎秒のピクチャ数等を減らすなどして、アクセスネットワークに確保されるデータ帯域の制限を超えないようにする必要がある。
また、本発明に係る実施形態では、ＩＧＭＰバージョン３の機能を利用し、一つのＩＧＭＰパケットにてマルチキャストグループの配信切り替えを行うことで、切り替え中にパケットが重複してアクセスネットワークに配信されないようにし、アクセスネットワークでＩＰＴＶシステムが使用するデータ帯域を制限するようにした。しかしながら、ＩＧＭＰバージョン２を利用の場合でも、マルチキャストグループへの離脱を行って、配信が停止された後、切り替えるマルチキャストグループに加入する処理をすることで、同様にＩＰＴＶシステムで使用するデータ帯域を制限することは可能である。
また、本発明に係る実施形態では、コンテンツサーバ１０が各チャンネルの複数ＭＰＥＧ２−ＴＳストリームをエンコードし、コアネットワーク経由にて配信した。ここで、コアネットワークの帯域に制限のある環境では、以下のようなことを実施することも可能である。すなわち、コンテンツサーバ１０では各チャンネルあたり一つの符号化されたパケットをコアネットワークにて配信を行い、アクセスネットワーク等の配信ネットワークの途中に、エッジサーバまたはエッジルータなどの別のコンテンツサーバを配置する。これらの別のコンテンツサーバにて、受信したＭＰＥＧ２−ＴＳストリームに対して、映像音声信号を元にＩＤＲピクチャの配信タイミングが異なるＭＰＥＧ２−ＴＳストリームを生成して、配信する。このようにすることで、コアネットワークの帯域を制限しながら、本実施形態で説明したＩＴＰＶシステムと同様の高速チャンネルスイッチを実現することができる。
また、本発明に係る実施形態では、端末である情報処理装置２０にＩＤＲピクチャの配信予定時刻情報を送信し、情報処理装置２０が、チャンネルのマルチキャストアドレスの選択およびアクセスネットワークに送信するマルチキャストパケットの切り替のタイミングの判断を行った。ここで、ＩＤＲピクチャの配信予定時刻を、実際に配信切り替えを実行するＩＧＭＰスヌーピングをおこなうエッジスイッチ、または、エッジルータに配信し、情報処理装置２０は、チャンネル選局処理が開始した時点で、直ちにマルチキャスト配信切り替え指示を行うようにする。指示を受信したエッジスイッチ、エッジルータは、ＩＤＲピクチャの配信予定情報を用いて、図１３に示した情報処理装置の選局処理と同等の判断にて、マルチキャストアドレスの選択および配信切り替えタイミングを制御してもよい。
この場合には、エッジスイッチ、エッジルータ等のネットワーク機器は、図３に示した情報処理装置２０が備える各処理部と同様の機能を有する処理部（例えば、コンテンツ取得部および取得ストリーム選択部）を有し、さらに、取得した圧縮データストリームを、所定のネットワークを介して情報処理装置２０へと配信する配信制御部を備えることが好ましい。かかる処理部を有するネットワーク機器は、エッジサーバとして機能することが可能となる。
＜プレビュー画面の一例について＞
続いて、図２１を参照しながら、本実施形態に係る情報処理方法を利用したＩＰＴＶのプレビュー画面の一例を示す。図２１は、本実施形態に係る情報処理方法を利用したＩＰＴＶのプレビュー画面の一例を説明するための説明図である。
本実施形態に係る情報処理方法では、表示部（図示せず。）の表示画面全体にプレビュー画面ひとつのみを表示し、高速にチャンネルプレビューを切り替えることが可能である。しかしながら、表示部の表示画面５０１に複数のプレビューウィンドウを表示させて、チャンネルプレビューを実現することも可能である。
ここで、本実施形態に係る情報処理方法では、現在プレビューしているチャンネルの動画を、動画表示ウィンドウ５０３に表示しつつ、既にプレビューされたチャンネルの静止画を記憶部２０９にキャプチャーしておき、静止画表示ウィンドウ５０５に表示させることが可能である。このようなユーザインタフェースを実現させることで、視聴者は前後のチャンネルの映像を見ることが可能である。
なお、本発明の各実施形態では、プレビュー用圧縮データストリームは１種類のみ配信されているが、図２１に示したようなユーザインタフェースでは、プレビュー用ストリームは視聴用ストリームよりも低い画像解像度で良いため、ビットレートを低くすることができる。そのため、アクセスネットワークに同時に複数のプレビュー用ストリームを配信することが可能となる。例えば、視聴用の画面がハイディフィニション（１９２０×１０２４ピクセル）の場合であれば、同じデータ帯域で、解像度がスタンダード（７２０×４８０ピクセル）である４〜５のストリームが配信できる。５つのプレビュー用ストリームを同時に受信し、プレビュー切り替え時に１つのストリームの配信切り替えに本発明の各実施形態に係る切り替え方法を適用することで、切り替え時にＩＤＲピクチャのデータの取りこぼしを防ぐことができる。その結果、スムーズにプレビュー画面の切り替えを行うことができ、図２１に示した画像を全て動画とすることができる。
＜ハードウェア構成について＞
次に、図２２を参照しながら、本発明の各実施形態に係るコンテンツサーバ１０および情報処理装置２０のハードウェア構成について、詳細に説明する。図２２は、本実施形態に係るコンテンツサーバ１０および情報処理装置２０のハードウェア構成を説明するためのブロック図である。
コンテンツサーバ１０および情報処理装置２０は、主に、ＣＰＵ７０１と、ＲＯＭ７０３と、ＲＡＭ７０５と、ホストバス７０７と、ブリッジ７０９と、外部バス７１１と、インターフェース７１３と、入力装置７１５と、出力装置７１７と、ストレージ装置７１９と、ドライブ７２１と、接続ポート７２３と、通信装置７２５とを備える。
ＣＰＵ７０１は、演算処理装置および制御装置として機能し、ＲＯＭ７０３、ＲＡＭ７０５、ストレージ装置７１９、またはリムーバブル記録媒体７２７に記録された各種プログラムに従って、コンテンツサーバ１０および情報処理装置２０内の動作全般またはその一部を制御する。ＲＯＭ７０３は、ＣＰＵ７０１が使用するプログラムや演算パラメータ等を記憶する。ＲＡＭ７０５は、ＣＰＵ７０１の実行において使用するプログラムや、その実行において適宜変化するパラメータ等を一次記憶する。これらはＣＰＵバス等の内部バスにより構成されるホストバス７０７により相互に接続されている。
ホストバス７０７は、ブリッジ７０９を介して、ＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ／Ｉｎｔｅｒｆａｃｅ）バスなどの外部バス７１１に接続されている。
入力装置７１５は、例えば、マウス、キーボード、タッチパネル、ボタン、スイッチおよびレバーなどユーザが操作する操作手段である。また、入力装置７１５は、例えば、赤外線やその他の電波を利用したリモートコントロール手段（いわゆる、リモコン）であってもよいし、コンテンツサーバ１０および情報処理装置２０の操作に対応した携帯電話やＰＤＡ等の外部接続機器７２９であってもよい。さらに、入力装置７１５は、例えば、上記の操作手段を用いてユーザにより入力された情報に基づいて入力信号を生成し、ＣＰＵ７０１に出力する入力制御回路などから構成されている。コンテンツサーバ１０または情報処理装置２０のユーザは、この入力装置７１５を操作することにより、コンテンツサーバ１０または情報処理装置２０に対して各種のデータを入力したり処理動作を指示したりすることができる。
出力装置７１７は、例えば、ＣＲＴディスプレイ装置、液晶ディスプレイ装置、プラズマディスプレイ装置、ＥＬディスプレイ装置およびランプなどの表示装置や、スピーカおよびヘッドホンなどの音声出力装置や、プリンタ装置、携帯電話、ファクシミリなど、取得した情報をユーザに対して視覚的または聴覚的に通知することが可能な装置で構成される。出力装置７１７は、例えば、コンテンツサーバ１０および情報処理装置２０が行った各種処理により得られた結果を出力する。具体的には、表示装置は、コンテンツサーバ１０および情報処理装置２０が行った各種処理により得られた結果を、テキストまたはイメージで表示する。他方、音声出力装置は、再生された音声データや音響データ等からなるオーディオ信号をアナログ信号に変換して出力する。
ストレージ装置７１９は、コンテンツサーバ１０および情報処理装置２０の記憶部の一例として構成されたデータ格納用の装置であり、例えば、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）等の磁気記憶部デバイス、半導体記憶デバイス、光記憶デバイス、または光磁気記憶デバイス等により構成される。このストレージ装置７１９は、ＣＰＵ７０１が実行するプログラムや各種データ、および外部から取得した音響信号データや画像信号データなどを格納する。
ドライブ７２１は、記録媒体用リーダライタであり、コンテンツサーバ１０および情報処理装置２０に内蔵、あるいは外付けされる。ドライブ７２１は、装着されている磁気ディスク、光ディスク、光磁気ディスク、または半導体メモリ等のリムーバブル記録媒体７２７に記録されている情報を読み出して、ＲＡＭ７０５に出力する。また、ドライブ７２１は、装着されている磁気ディスク、光ディスク、光磁気ディスク、または半導体メモリ等のリムーバブル記録媒体７２７に記録を書き込むことも可能である。リムーバブル記録媒体７２７は、例えば、ＤＶＤメディア、ＨＤ−ＤＶＤメディア、Ｂｌｕ−ｒａｙメディア、コンパクトフラッシュ（登録商標）（ＣｏｍｐａｃｔＦｌａｓｈ：ＣＦ）、メモリースティック、または、ＳＤメモリカード（Ｓｅｃｕｒｅ Ｄｉｇｉｔａｌ ｍｅｍｏｒｙ ｃａｒｄ）等である。また、リムーバブル記録媒体７２７は、例えば、非接触型ＩＣチップを搭載したＩＣカード（Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ ｃａｒｄ）または電子機器等であってもよい。
接続ポート７２３は、例えば、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）ポート、ｉ．Ｌｉｎｋ等のＩＥＥＥ１３９４ポート、ＳＣＳＩ（Ｓｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍ Ｉｎｔｅｒｆａｃｅ）ポート、ＲＳ−２３２Ｃポート、光オーディオ端子、ＨＤＭＩ（Ｈｉｇｈ−Ｄｅｆｉｎｉｔｉｏｎ Ｍｕｌｔｉｍｅｄｉａ Ｉｎｔｅｒｆａｃｅ）ポート等の、機器をコンテンツサーバ１０および情報処理装置２０に直接接続するためのポートである。この接続ポート７２３に外部接続機器７２９を接続することで、コンテンツサーバ１０および情報処理装置２０は、外部接続機器７２９から直接音響信号データや画像信号データを取得したり、外部接続機器７２９に音響信号データや画像信号データを提供したりする。
通信装置７２５は、例えば、通信網７３１に接続するための通信デバイス等で構成された通信インターフェースである。通信装置７２５は、例えば、有線または無線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、Ｂｌｕｅｔｏｏｔｈ、またはＷＵＳＢ（Ｗｉｒｅｌｅｓｓ ＵＳＢ）用の通信カード、光通信用のルータ、ＡＤＳＬ（Ａｓｙｍｍｅｔｒｉｃ Ｄｉｇｉｔａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｌｉｎｅ）用のルータ、または、各種通信用のモデム等である。この通信装置７２５は、例えば、インターネットや他の通信機器との間で、例えばＴＣＰ／ＩＰ等の所定のプロトコルに則して信号等を送受信することができる。また、通信装置７２５に接続される通信網７３１は、有線または無線によって接続されたネットワーク等により構成され、例えば、インターネット、家庭内ＬＡＮ、赤外線通信、ラジオ波通信または衛星通信等であってもよい。
以上、本発明の各実施形態に係るコンテンツサーバ１０および情報処理装置２０の機能を実現可能なハードウェア構成の一例を示した。上記の各構成要素は、汎用的な部材を用いて構成されていてもよいし、各構成要素の機能に特化したハードウェアにより構成されていてもよい。従って、本実施形態を実施する時々の技術レベルに応じて、適宜、利用するハードウェア構成を変更することが可能である。
なお、本発明の各実施形態に係るコンテンツサーバ１０は、以下に示すような機能を有するプログラムとして提供されることも可能である。このプログラムは、コンピュータに、映像音声コンテンツを符号化し、映像信号の圧縮によって生成された時系列データにおいて、以前のデータに依存せずに、それ以降の映像信号の復号化を開始できるデータである基準圧縮映像データのみからなる圧縮映像データストリームと、圧縮音声データストリームと、を有する第１圧縮データストリームを生成する第１符号化機能と、前記映像音声コンテンツを符号化し、前記基準圧縮映像データおよび当該基準圧縮映像データを用いて生成される圧縮映像データを含む圧縮映像データストリームと、圧縮音声データストリームと、を有する第２圧縮データストリームを生成する第２符号化機能と、前記第１圧縮データストリームを取得して、当該第１圧縮データストリームを、データ配信期間とデータ未配信期間とに区分し、区分した前記データ未配信期間と他のコンテンツサーバから配信される第１圧縮データストリームのデータ未配信期間とが互いに一致するように間欠的に配信する第１配信機能と、前記第２圧縮データストリームを取得して配信する第２配信機能と、を実現させるためのプログラムである。
このコンピュータプログラムは、コンピュータが備える記憶部に格納され、コンピュータが備えるＣＰＵに読み込まれて実行されることにより、コンピュータを上記のコンテンツサーバ１０として機能させる。また、コンピュータプログラムが記録された、コンピュータで読み取り可能な記録媒体も提供することができる。記録媒体は、例えば、磁気ディスク、光ディスク、光磁気ディスク、フラッシュメモリなどである。また、上記のコンピュータプログラムは、記録媒体を用いずに、例えばネットワークを介して配信してもよい。
また、本発明の各実施形態に係る情報処理装置２０は、以下に示すような機能を有するプログラムとして提供されることも可能である。このプログラムは、コンピュータに、一つの映像音声コンテンツに対応して、映像信号の圧縮によって生成された時系列データにおいて、以前のデータに依存せずに、それ以降の映像信号の復号化を開始できるデータである基準圧縮映像データのみからなる圧縮映像データストリームおよび圧縮音声データストリームを有し、データパケットがデータ配信期間とデータ未配信期間とに区分され、区分された前記データ未配信期間と他のコンテンツサーバから配信される第１圧縮データストリームのデータ未配信期間とが互いに一致するように間欠的に配信される第１圧縮データストリームと、前記基準圧縮映像データおよび当該基準圧縮映像データを用いて生成される圧縮映像データを含む圧縮映像データストリームならびに圧縮音声データストリームを有する第２圧縮データストリームと、を配信するコンテンツサーバが複数存在し、配信されている複数の前記映像音声コンテンツに対応した複数の圧縮データストリームの中から、取得する前記圧縮データストリームを選択する取得ストリーム選択機能と、選択した前記圧縮データストリームを取得するコンテンツ取得機能と、を実現させるためのプログラムである。
このコンピュータプログラムは、コンピュータが備える記憶部に格納され、コンピュータが備えるＣＰＵに読み込まれて実行されることにより、コンピュータを上記の情報処理装置２０として機能させる。また、コンピュータプログラムが記録された、コンピュータで読み取り可能な記録媒体も提供することができる。記録媒体は、例えば、磁気ディスク、光ディスク、光磁気ディスク、フラッシュメモリなどである。また、上記のコンピュータプログラムは、記録媒体を用いずに、例えばネットワークを介して配信してもよい。
以上説明したように、本発明の各実施形態によれば、ＩＰＴＶの加入者宅へのアクセスネットワークのデータ帯域が限定される環境でも、高品位な映像にて複数のチャンネルを高速に切り替えながらプレビューを実現することができる。その結果、本発明の各実施形態では、従来のアナログ放送のテレビと同等、またはそれ以上に、視聴したいチャンネルを快適に探す方法をチャンネル利用者に提供できる。
また、本発明の各実施形態によれば、プレビューのストリーム、視聴用のストリームに切り替えをおこなう際、映像が表示されないブラックアウト期間、または、プレビューのストリームの映像を停止状態で表示しておく時間を最小にすることが可能である。その結果、視聴者にはシームレスなチャンネル切り替えを提供することができる。
また、本発明の各実施形態によれば、視聴用ストリームだけ受信すれば、なんら従来のＩＰＴＶシステムと変わりない。そのため、本発明の各実施形態に基づく高速プレビューをサポートしない端末（既存の端末）も共存したＩＰＴＶシステムを構築可能である。
以上、添付図面を参照しながら本発明の好適な実施形態について説明したが、本発明はかかる例に限定されないことは言うまでもない。当業者であれば、特許請求の範囲に記載された範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、それらについても当然に本発明の技術的範囲に属するものと了解される。
本発明の第１の実施形態に係るコンテンツ配信システムを説明するための説明図である。 同実施形態に係るコンテンツサーバの構成を説明するためのブロック図である。 同実施形態に係る情報処理装置の構成を説明するためのブロック図である。 同実施形態に係る圧縮映像データストリームのピクチャ構造を説明するための説明図である。 同実施形態に係るコンテンツサーバが送出するＵＤＰパケットのフォーマットを説明するための説明図である。 同実施形態に係るプレビュー用圧縮データストリームを説明するための説明図である。 ＩＧＭＰメッセージのフォーマットを説明するための説明図である。 ＩＧＭＰメッセージのフォーマットを説明するための説明図である。 同実施形態に係るコンテンツサーバが実施するパケットのシェーピング処理を説明するための説明図である。 同実施形態に係るコンテンツサーバが実施する配信予定時刻の算出方法について説明するための説明図である。 同実施形態に係る基準圧縮映像データ配信予定時刻情報の具体例を説明するための説明図である。 ＤＶＢ−ＩＰのブロードキャストディスカバリーレコードのデータ形式を説明するための説明図である。 ブロードキャストディスカバリーレコードをＸＭＬ表記した場合の例を説明するための説明図である。 同実施形態に係る情報処理方法を説明するための流れ図である。 同実施形態に係るＩＧＭＰメッセージの一例を説明するための説明図である。 同実施形態に係るＩＧＭＰメッセージの一例を説明するための説明図である。 同実施形態に係る情報処理方法におけるチャンネルプレビュー処理を説明するための流れ図である。 同実施形態に係る情報処理方法におけるプレビュー用圧縮データストリームへの切り替え処理を説明するための流れ図である。 同実施形態に係るＩＧＭＰメッセージの一例を説明するための説明図である。 同実施形態に係るＩＧＭＰメッセージの一例を説明するための説明図である。 同実施形態に係るＩＧＭＰメッセージの一例を説明するための説明図である。 同実施形態に係る情報処理方法における視聴用圧縮データストリームへの切り替え処理を説明するための流れ図である。 同実施形態に係る情報処理方法におけるデータストリームの切り替えタイミングの場合分けを説明するための説明図である。 同実施形態に係る情報処理方法におけるチャンネル受信終了処理を説明するための流れ図である。 同実施形態に係る情報処理方法を利用したＩＰＴＶのプレビュー画面の一例を説明するための説明図である。 同実施形態に係るコンテンツサーバおよび情報処理装置のハードウェア構成を説明するためのブロック図である。 一般的なＩＰＴＶシステムについて説明するための説明図である。
符号の説明
１ コンテンツ配信システム
１０ コンテンツサーバ
１１Ａ プレビュー用ストリーム処理部
１１Ｂ 視聴用ストリーム処理部
２０ 情報処理装置
３０ 配信予定時刻情報送信サーバ
４０ 基準クロックサーバ
１０１ 第１符号化部
１０３ 第２符号化部
１０５ 第１配信部
１０７ 第２配信部
１０９，１１１ 記憶部
２０１ チャンネル選択部
２０３ 取得ストリーム選択部
２０５ コンテンツ取得部
２０７ コンテンツ再生部
２０９ 記憶部

Claims (20)

  1. 映像音声コンテンツを符号化し、映像信号の圧縮によって生成された時系列データにおいて、以前のデータに依存せずに、それ以降の映像信号の復号化を開始できるデータである基準圧縮映像データのみからなる圧縮映像データストリームと、圧縮音声データストリームと、を有する第１圧縮データストリームを生成する第１符号化部と、
    前記映像音声コンテンツを符号化し、前記基準圧縮映像データおよび当該基準圧縮映像データを用いて生成される圧縮映像データを含む圧縮映像データストリームと、圧縮音声データストリームと、を有する第２圧縮データストリームを生成する第２符号化部と、
    前記第１符号化部から前記第１圧縮データストリームを取得して、当該第１圧縮データストリームをデータ配信期間とデータ未配信期間とに区分し、区分した前記データ未配信期間と他のコンテンツサーバから配信される映像音声コンテンツの第１圧縮データストリームのデータ未配信期間とが互いに一致するように前記第１符号化部から取得した第１圧縮データストリームを間欠的に配信する第１配信部と、
    前記第２符号化部から前記第２圧縮データストリームを取得して、取得した当該第２圧縮データストリームを配信する第２配信部と、
    を備える、コンテンツサーバ。
  2. 前記第１配信部は、前記データ配信期間の先頭に前記基準圧縮映像データが存在するように前記第１圧縮データストリームをデータパケットに格納する、請求項１に記載のコンテンツサーバ。
  3. 前記第２配信部は、前記第２圧縮データストリームを、データ配信期間とデータ未配信期間とに区分し、当該第２圧縮データストリームにおけるデータ未配信期間が、前記第１圧縮データストリームにおける前記データ未配信期間と同時刻に存在するように前記第２圧縮データストリームを間欠的に配信する、請求項２に記載のコンテンツサーバ。
  4. 前記第２配信部は、前記データ配信期間の先頭に前記基準圧縮映像データが存在するように前記第２圧縮データストリームをデータパケットに格納する、請求項３に記載のコンテンツサーバ。
  5. 前記第１配信部は、前記データ送信期間内では、前記第１圧縮データストリームが格納されたデータパケットを、等間隔に配置して送信する、請求項１に記載のコンテンツサーバ。
  6. 前記第１圧縮データストリーム中の前記圧縮映像データストリームと、前記第２圧縮データストリーム中の前記圧縮映像データストリームとは、同一の解像度を有する、請求項１に記載のコンテンツサーバ。
  7. 前記第１配信部および前記第２配信部は、生成された前記基準圧縮映像データが配信される配信予定時刻に関する基準圧縮映像データ配信予定時刻情報を出力する、請求項１に記載のコンテンツサーバ。
  8. 映像音声コンテンツを符号化し、映像信号の圧縮によって生成された時系列データにおいて、以前のデータに依存せずに、それ以降の映像信号の復号化を開始できるデータである基準圧縮映像データのみからなる圧縮映像データストリームと、圧縮音声データストリームと、を有する第１圧縮データストリームを生成する第１符号化部と、前記映像音声コンテンツを符号化し、前記基準圧縮映像データおよび当該基準圧縮映像データを用いて生成される圧縮映像データを含む圧縮映像データストリームと、圧縮音声データストリームと、を有する第２圧縮データストリームを生成する第２符号化部と、前記第１符号化部から前記第１圧縮データストリームを取得して、当該第１圧縮データストリームを、データ配信期間とデータ未配信期間とに区分し、区分した前記データ未配信期間と他のコンテンツサーバから配信される映像音声コンテンツの第１圧縮データストリームのデータ未配信期間とが互いに一致するように前記第１符号化部から取得した第１圧縮データストリームを間欠的に配信する第１配信部と、前記第２符号化部から前記第２圧縮データストリームを取得して、取得した当該第２圧縮データストリームを配信する第２配信部と、を備えるコンテンツサーバが複数存在し、複数の前記コンテンツサーバが配信する複数の前記第１圧縮データストリームおよび前記第２圧縮データストリームの中から、取得する圧縮データストリームを選択する取得ストリーム選択部と、
    前記取得ストリーム選択部による選択結果に基づいて、前記コンテンツサーバから配信された前記圧縮データストリームを取得するコンテンツ取得部と、
    を備える、情報処理装置。
  9. 前記情報処理装置は、当該情報処理装置に対してなされた前記映像音声コンテンツに対応するチャンネルの選択操作を所定の信号に変換するチャンネル選択部を更に備え、
    前記取得ストリーム選択部は、前記チャンネル選択部から伝送される前記信号に基づいて、取得する前記圧縮データストリームを選択する、請求項８に記載の情報処理装置。
  10. 前記取得ストリーム選択部は、
    取得している前記チャンネルの変更が前記チャンネル選択部から通知された場合に、通知された前記チャンネルに対応する前記第１圧縮データストリームを選択し、
    前記チャンネルが確定すると、確定した前記チャンネルに対応する前記第２圧縮データストリームを選択する、請求項９に記載の情報処理装置。
  11. 前記取得ストリーム選択部は、あるチャンネルの前記第１圧縮データストリームから別のチャンネルの前記第１圧縮データストリームへ切り替えを行う場合、または、視聴中のチャンネルの前記第１圧縮データストリームから別のチャンネルの前記第２圧縮データストリームへ切り替えを行う場合に、前記データ未送信期間に前記圧縮データストリームの取得の切り替えが行われるように、前記圧縮データストリームの取得タイミングを前記コンテンツ取得部に通知する、請求項１０に記載の情報処理装置。
  12. 前記取得ストリーム選択部は、前記コンテンツサーバが出力した、生成された前記基準圧縮映像データが配信される配信予定時刻に関する基準圧縮映像データ配信予定時刻情報を取得し、取得した前記基準圧縮映像データ配信予定時刻情報に基づいて、前記圧縮データストリームを取得するタイミングを決定する、請求項８に記載の情報処理装置。
  13. 前記取得ストリーム選択部は、取得した圧縮データストリームに表示を切り替えるために要する切替所要時間と、取得するストリームの選択処理を開始した時刻とを用いて、取得した圧縮データストリームの切り替えを完了する切替完了予想時刻を算出し、
    前記配信予定時刻と、選択した前記圧縮データストリームの前記切替完了予想時刻との間との間の時間間隔が所定の閾値以下である場合に、前記圧縮データストリームの取得タイミングを前記コンテンツ取得部に通知する、請求項１２に記載の情報処理装置。
  14. 映像音声コンテンツを符号化し、映像信号の圧縮によって生成された時系列データにおいて、以前のデータに依存せずに、それ以降の映像信号の復号化を開始できるデータである基準圧縮映像データのみからなる圧縮映像データストリームと、圧縮音声データストリームと、を有する第１圧縮データストリームを生成する第１符号化部と、前記映像音声コンテンツを符号化し、前記基準圧縮映像データおよび当該基準圧縮映像データを用いて生成される圧縮映像データを含む圧縮映像データストリームと、圧縮音声データストリームと、を有する第２圧縮データストリームを生成する第２符号化部と、前記第１符号化部から前記第１圧縮データストリームを取得して、当該第１圧縮データストリームを、データ配信期間とデータ未配信期間とに区分し、区分した前記データ未配信期間と他のコンテンツサーバから配信される映像音声コンテンツの第１圧縮データストリームのデータ未配信期間とが互いに一致するように前記第１符号化部から取得した第１圧縮データストリームを間欠的に配信する第１配信部と、前記第２符号化部から前記第２圧縮データストリームを取得して、取得した当該第２圧縮データストリームを配信する第２配信部と、を備えるコンテンツサーバが複数存在し、複数の前記コンテンツサーバが配信する複数の前記第１圧縮データストリームおよび前記第２圧縮データストリームの中から、取得する圧縮データストリームを選択する取得ストリーム選択部と、
    前記取得ストリーム選択部による選択結果に基づいて、前記コンテンツサーバから配信された前記圧縮データストリームを取得するコンテンツ取得部と、
    取得した前記圧縮データストリームを、外部に接続された情報処理装置に対して配信する配信制御部と、
    を備える、ネットワーク機器。
  15. 前記取得ストリーム選択部は、あるチャンネルの前記第１圧縮データストリームから別のチャンネルの前記第１圧縮データストリームへ切り替えを行う場合、または、視聴中のチャンネルの前記第１圧縮データストリームから別のチャンネルの前記第２圧縮データストリームへ切り替えを行う場合に、前記データ未送信期間に前記圧縮データストリームの取得の切り替えが行われるように、前記圧縮データストリームの取得タイミングを前記コンテンツ取得部に通知する、請求項１４に記載のネットワーク機器。
  16. 映像音声コンテンツを符号化し、映像信号の圧縮によって生成された時系列データにおいて、以前のデータに依存せずに、それ以降の映像信号の復号化を開始できるデータである基準圧縮映像データのみからなる圧縮映像データストリームと、圧縮音声データストリームと、を有する第１圧縮データストリームを生成する第１符号化ステップと、
    前記映像音声コンテンツを符号化し、前記基準圧縮映像データおよび当該基準圧縮映像データを用いて生成される圧縮映像データを含む圧縮映像データストリームと、圧縮音声データストリームと、を有する第２圧縮データストリームを生成する第２符号化ステップと、
    生成された前記第１圧縮データストリームを、データ配信期間とデータ未配信期間とに区分し、区分した前記データ未配信期間と他のコンテンツサーバから配信される映像音声コンテンツの第１圧縮データストリームのデータ未配信期間とが互いに一致するように取得した第１圧縮データストリームを間欠的に配信しつつ、取得した第２圧縮データストリームを配信するステップと、
    を含む、コンテンツ配信方法。
  17. 一つの映像音声コンテンツに対応して、映像信号の圧縮によって生成された時系列データにおいて、以前のデータに依存せずに、それ以降の映像信号の復号化を開始できるデータである基準圧縮映像データのみからなる圧縮映像データストリームおよび圧縮音声データストリームを有し、データパケットがデータ配信期間とデータ未配信期間とに区分され、区分された前記データ未配信期間と他のコンテンツサーバから配信される映像音声コンテンツの第１圧縮データストリームのデータ未配信期間とが互いに一致するように間欠的に配信される第１圧縮データストリームと、前記基準圧縮映像データおよび当該基準圧縮映像データを用いて生成される圧縮映像データを含む圧縮映像データストリームならびに圧縮音声データストリームを有する第２圧縮データストリームと、を配信するコンテンツサーバが複数存在し、配信されている複数の前記映像音声コンテンツに対応した複数の圧縮データストリームの中から、取得する前記圧縮データストリームを選択する取得ストリーム選択ステップと、
    選択した前記圧縮データストリームを取得するコンテンツ取得ステップと、
    を含む、情報処理方法。
  18. 一つの映像音声コンテンツに対応して、映像信号の圧縮によって生成された時系列データにおいて、以前のデータに依存せずに、それ以降の映像信号の復号化を開始できるデータである基準圧縮映像データのみからなる圧縮映像データストリームおよび圧縮音声データストリームを有し、データパケットがデータ配信期間とデータ未配信期間とに区分され、区分された前記データ未配信期間と他のコンテンツサーバから配信される映像音声コンテンツの第１圧縮データストリームのデータ未配信期間とが互いに一致するように間欠的に配信される第１圧縮データストリームと、前記基準圧縮映像データおよび当該基準圧縮映像データを用いて生成される圧縮映像データを含む圧縮映像データストリームならびに圧縮音声データストリームを有する第２圧縮データストリームと、を配信するコンテンツサーバが複数存在し、配信されている複数の前記映像音声コンテンツに対応した複数の圧縮データストリームの中から、取得する前記圧縮データストリームを選択する取得ストリーム選択ステップと、
    選択した前記圧縮データストリームを取得するコンテンツ取得ステップと、
    取得した前記圧縮データストリームを、ネットワークを介して接続された情報処理装置に対して配信する配信制御ステップと、
    を含む、コンテンツ配信方法。
  19. 映像音声コンテンツを符号化し、映像信号の圧縮によって生成された時系列データにおいて、以前のデータに依存せずに、それ以降の映像信号の復号化を開始できるデータである基準圧縮映像データのみからなる圧縮映像データストリームと、圧縮音声データストリームと、を有する第１圧縮データストリームを生成する第１符号化部と、
    前記映像音声コンテンツを符号化し、前記基準圧縮映像データおよび当該基準圧縮映像データを用いて生成される圧縮映像データを含む圧縮映像データストリームと、圧縮音声データストリームと、を有する第２圧縮データストリームを生成する第２符号化部と、
    前記第１符号化部から前記第１圧縮データストリームを取得して、当該第１圧縮データストリームを、データ配信期間とデータ未配信期間とに区分し、区分した前記データ未配信期間と他のコンテンツサーバから配信される映像音声コンテンツの第１圧縮データストリームのデータ未配信期間とが互いに一致するように前記第１符号化部から取得した第１圧縮データストリームを間欠的に配信する第１配信部と、
    前記第２符号化部から前記第２圧縮データストリームを取得して、取得した当該第２圧縮データストリームを配信する第２配信部と、
    を備える複数のコンテンツサーバと、
    前記複数のコンテンツサーバが配信する複数の圧縮データストリームの中から、取得する前記圧縮データストリームを選択する取得ストリーム選択部と、
    前記取得ストリーム選択部による選択結果に基づいて、前記コンテンツサーバから配信された前記圧縮データストリームを取得するコンテンツ取得部と、
    を備える情報処理装置と、
    を含む、コンテンツ配信システム。
  20. 映像音声コンテンツを符号化し、映像信号の圧縮によって生成された時系列データにおいて、以前のデータに依存せずに、それ以降の映像信号の復号化を開始できるデータである基準圧縮映像データのみからなる圧縮映像データストリームと、圧縮音声データストリームと、を有する第１圧縮データストリームを生成する第１符号化部と、
    前記映像音声コンテンツを符号化し、前記基準圧縮映像データおよび当該基準圧縮映像データを用いて生成される圧縮映像データを含む圧縮映像データストリームと、圧縮音声データストリームと、を有する第２圧縮データストリームを生成する第２符号化部と、
    前記第１符号化部から前記第１圧縮データストリームを取得して、当該第１圧縮データストリームを、データ配信期間とデータ未配信期間とに区分し、区分した前記データ未配信期間と他のコンテンツサーバから配信される映像音声コンテンツの第１圧縮データストリームのデータ未配信期間とが互いに一致するように前記第１符号化部から取得した第１圧縮データストリームを間欠的に配信する第１配信部と、
    前記第２符号化部から前記第２圧縮データストリームを取得して、取得した当該第２圧縮データストリームを配信する第２配信部と、
    を備える複数のコンテンツサーバと、
    前記複数のコンテンツサーバが配信する複数の圧縮データストリームの中から、再生を希望する前記圧縮データストリームを通知し、取得した前記圧縮データストリームを再生する情報処理装置と、
    前記情報処理装置から受信した通知に基づいて、前記複数のコンテンツサーバが配信する前記複数の圧縮データストリームの中から、取得する前記圧縮データストリームを選択する取得ストリーム選択部と、
    前記取得ストリーム選択部による選択結果に基づいて、前記複数のコンテンツサーバから配信された前記圧縮データストリームを取得するコンテンツ取得部と、
    取得した前記圧縮データストリームを、ネットワークを介して前記情報処理装置に対して配信する配信制御部と、
    を備えるネットワーク機器と、
    を含む、コンテンツ配信システム。
JP2008135036A 2008-05-23 2008-05-23 コンテンツサーバ、情報処理装置、ネットワーク機器、コンテンツ配信方法、情報処理方法およびコンテンツ配信システム Expired - Fee Related JP4735666B2 (ja)

Priority Applications (5)

Application Number Priority Date Filing Date Title
JP2008135036A JP4735666B2 (ja) 2008-05-23 2008-05-23 コンテンツサーバ、情報処理装置、ネットワーク機器、コンテンツ配信方法、情報処理方法およびコンテンツ配信システム
EP09251299.5A EP2124451A3 (en) 2008-05-23 2009-05-12 Content server, information processing apparatus, network device, content distribution method, information processing method, and content distribution system
US12/468,567 US20090293093A1 (en) 2008-05-23 2009-05-19 Content server, information processing apparatus, network device, content distribution method, information processing method, and content distribution system
CN2009101421026A CN101588476B (zh) 2008-05-23 2009-05-25 内容服务器、信息处理装置/方法、网络设备、内容发布方法/系统
CN2010101384369A CN101800899B (zh) 2008-05-23 2009-05-25 内容服务器、信息处理装置/方法、网络设备、内容发布方法/系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2008135036A JP4735666B2 (ja) 2008-05-23 2008-05-23 コンテンツサーバ、情報処理装置、ネットワーク機器、コンテンツ配信方法、情報処理方法およびコンテンツ配信システム

Publications (2)

Publication Number Publication Date
JP2009284283A JP2009284283A (ja) 2009-12-03
JP4735666B2 true JP4735666B2 (ja) 2011-07-27

Family

ID=41454257

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2008135036A Expired - Fee Related JP4735666B2 (ja) 2008-05-23 2008-05-23 コンテンツサーバ、情報処理装置、ネットワーク機器、コンテンツ配信方法、情報処理方法およびコンテンツ配信システム

Country Status (1)

Country Link
JP (1) JP4735666B2 (ja)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015012305A (ja) * 2013-06-26 2015-01-19 ソニー株式会社 コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、およびコンテンツ供給システム
WO2015001986A1 (ja) 2013-07-02 2015-01-08 ソニー株式会社 コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、およびコンテンツ供給システム
WO2015012140A1 (ja) * 2013-07-26 2015-01-29 ソニー株式会社 コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、およびコンテンツ供給システム
JP7499583B2 (ja) 2020-03-09 2024-06-14 日本放送協会 動画配信装置、動画送出装置、動画配信システム、動画配信方法及び動画配信プログラム
JP7304096B2 (ja) * 2021-10-29 2023-07-06 ＭａｓｔｅｒＶｉｓｉｏｎｓ株式会社 動画配信装置

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005033556A (ja) * 2003-07-14 2005-02-03 Toshiba Corp データ送信装置、データ送信方法、データ受信装置、データ受信方法
WO2005043784A1 (ja) * 2003-10-30 2005-05-12 Matsushita Electric Industrial Co., Ltd. 複数サービスが多重化された放送波の受信装置および受信方法
JP2006527974A (ja) * 2003-06-16 2006-12-07 トムソン ライセンシング 圧縮ビデオの高速チャンネル変更を可能にする符号化方法および装置
JP2007281868A (ja) * 2006-04-06 2007-10-25 Nippon Hoso Kyokai <Nhk> 送信装置及び受信装置
JP2008035102A (ja) * 2006-07-27 2008-02-14 Oki Electric Ind Co Ltd コンテンツ受信端末装置

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006527974A (ja) * 2003-06-16 2006-12-07 トムソン ライセンシング 圧縮ビデオの高速チャンネル変更を可能にする符号化方法および装置
JP2005033556A (ja) * 2003-07-14 2005-02-03 Toshiba Corp データ送信装置、データ送信方法、データ受信装置、データ受信方法
WO2005043784A1 (ja) * 2003-10-30 2005-05-12 Matsushita Electric Industrial Co., Ltd. 複数サービスが多重化された放送波の受信装置および受信方法
JP2007281868A (ja) * 2006-04-06 2007-10-25 Nippon Hoso Kyokai <Nhk> 送信装置及び受信装置
JP2008035102A (ja) * 2006-07-27 2008-02-14 Oki Electric Ind Co Ltd コンテンツ受信端末装置

Also Published As

Publication number Publication date
JP2009284283A (ja) 2009-12-03

Similar Documents

Publication Publication Date Title
JP4702397B2 (ja) コンテンツサーバ、情報処理装置、ネットワーク機器、コンテンツ配信方法、情報処理方法およびコンテンツ配信システム
US20090293093A1 (en) Content server, information processing apparatus, network device, content distribution method, information processing method, and content distribution system
JP5363473B2 (ja) 改善されたメディア・セッション管理の方法と装置
US9148696B2 (en) Data transmission system, receiving apparatus, and receiving method as well as sending apparatus and sending method
US11375258B2 (en) Transitioning between broadcast and unicast streams
CN101917613B (zh) 一种流媒体采集编码服务系统
US20070174880A1 (en) Method, apparatus, and system of fast channel hopping between encoded video streams
JP2008507898A (ja) デジタルメディアシステムにおける高速チャンネル切換
JPWO2005043784A1 (ja) 複数サービスが多重化された放送波の受信装置および受信方法
JP2010509802A (ja) チャンネル変更時間を低減し且つチャンネル変更期間に於いてオーディオ／ビデオ・コンテンツを同期させる方法
CN112752115A (zh) 直播数据传输方法、装置、设备及介质
WO2011000253A1 (zh) 一种媒体流处理方法及通讯系统以及相关设备
CN112770122B (zh) 一种在云导播台视频同步的方法及系统
WO2011000270A1 (zh) 一种减小媒体延迟的方法、设备及系统
WO2008148333A1 (fr) Système et procédé de traitement d&#39;un flux vidéo
JP4735666B2 (ja) コンテンツサーバ、情報処理装置、ネットワーク機器、コンテンツ配信方法、情報処理方法およびコンテンツ配信システム
JP5428734B2 (ja) ネットワーク機器、情報処理装置、ストリーム切替方法、情報処理方法、プログラムおよびコンテンツ配信システム
JP2017520940A (ja) 階層符号化されたコンテンツを多重化するための方法および装置
JP4526294B2 (ja) ストリームデータ送信装置、受信装置、プログラムを記録した記録媒体、およびシステム
KR100640467B1 (ko) 멀티미디어 스트림 평활화가 가능한 아이피 스트리밍 장치
JP4373730B2 (ja) 映像データ送信装置、映像データ送受信システム、及び、その方法
KR20100131365A (ko) 채널 변경 지연을 줄이기 위한 스트리밍 서버, 이동 단말기 및 그 방법
WO2010022598A1 (zh) 交互电视频道切换方法及系统、音视频流发送方法及装置
KR20080005044A (ko) 고속 버퍼링 스위치를 이용한 인터넷 방송 서비스 제공방법 및 그 장치
JP2010258489A (ja) 映像表示装置、受信装置、送受信システム、及び映像表示方法

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20100408

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20100413

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20100614

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20101116

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110215

A911 Transfer of reconsideration by examiner before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20110223

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20110329

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20110411

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140513

Year of fee payment: 3

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees