JP2020141225A - 送信装置、送信方法、及びプログラム - Google Patents

Abstract

【課題】メディアデータの配信に係る遅延時間を短縮すること。【解決手段】受信装置へメディアデータを送信する送信装置は、メディアデータの所定時間長の部分に対応するセグメントであって、そのメディアデータの再生のための基準となる所定の基準データを含んだ第１のセグメントと、所定の基準データを含まない第２のセグメントとを生成し、受信装置からのセグメントの要求に応じて、生成したセグメントを受信装置へ送信する。送信装置は、受信装置から要求されたセグメントが第２のセグメントであったことに基づいて、その第２のセグメントを第１のセグメントへ変更して受信装置へ送信する。【選択図】図５

Description

本発明は、メディアデータの配信技術に関する。

音声データや映像データ等により構成されるストリーミング形式のコンテンツをリアルタイムに配信し、ユーザは、自身が保持する端末装置を介して、そのようなコンテンツを視聴するシステムが存在する。このとき、端末装置は様々な能力を有し、また、様々な環境でコンテンツの再生が行われるため、コンテンツ再生の環境への適応技術が要求される。このような要求に対して、ＭＰＥＧ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）−ＤＡＳＨ（Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ Ｈｔｔｐ）が注目されている（非特許文献１参照）。ＭＰＥＧ−ＤＡＳＨは、取得されるストリームを動的に変更することを可能とする映像配信規格である。

ＭＰＥＧ−ＤＡＳＨでは、映像データが所定の時間長のセグメントに分割され、セグメントを取得するためのＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）がプレイリストと呼ばれるファイルに記述される。映像データを受信する受信側装置は、最初にこのプレイリストを取得し、プレイリストに記述されている情報を用いて要求する映像データを選択して、その選択された映像データの配信元の配信側装置に対して、映像データの配信を要求する。そして、受信側装置は、その映像データを配信側装置から取得する。なお、この映像データは、１つの映像データが分割されて得られるセグメントとして取得されうる。このとき、プレイリスト中にビットレートや解像度などが異なる複数のバージョンのセグメントに対するＵＲＬが記載されることにより、受信側装置は、自身の能力や通信環境に適したバージョンのセグメントを取得することができる。

セグメントは、ＩＳＯ Ｂａｓｅ Ｍｅｄｉａ Ｆｉｌｅ Ｆｏｒｍａｔ（以下では、このフォーマットのことを「ＩＳＯＢＭＦＦ」と呼ぶ。）のファイル形式で取り扱われる（非特許文献２参照）。ここで、ＩＳＯＢＭＦＦは、ヘッダ情報を格納する部分と符号化データを格納する部分とに大きく分けられる。ヘッダ情報には、セグメントに格納される符号化データのサイズや、タイムスタンプを示す情報などが含まれる。したがって、１つのセグメントを完成させるために、そのセグメントに格納される符号化データの生成が全て完了している必要がある。

一方、映像データのセグメントについては、Ｈ．２６４の様なフレーム間予測を用いて符号化したデータを使用する事が一般的である。ＭＰＥＧ−ＤＡＳＨの普及活動を行っている業界団体のＤＡＳＨ Ｉｎｄｕｓｔｒｙ Ｆｏｒｕｍ（ｈｔｔｐ：／／ｄａｓｈｉｆ．ｏｒｇ／）では、これに基づいて、最適なバージョンのセグメントへの切り替えを容易にするためのガイドラインが作成されている。例えば、ガイドラインでは、各セグメントが、単体でのデコードが可能なイントラ圧縮されたフレーム（以下では、このフレームを「Ｉ−Ｆｒａｍｅ」と呼ぶ。）を含み、ランダムアクセス可能となることなどが規定されている。

Ｉ−Ｆｒａｍｅは、参照画像と予測画像との差分を圧縮したフレームと比較して符号量が大きいため、符号量を抑えるためにＩ−Ｆｒａｍｅを生成する間隔を延ばす方法が用いられることがある。このとき、ＤＡＳＨ Ｉｎｄｕｓｔｒｙ Ｆｏｒｕｍのガイドラインを遵守すると、各セグメントは少なくとも１つのＩ−Ｆｒａｍｅを含む必要があるため、セグメントの最短の時間長がＩ−Ｆｒａｍｅの生成間隔となる。このため、セグメントの最短の時間長が、Ｉ−Ｆｒａｍｅの間隔に従って長くなる。

ＩＳＯ／ＩＥＣ ２３００９−１ ＩＳＯ／ＩＥＣ １４４９６−１２

ライブ映像をストリーミング配信する場合、１つのセグメントを構成する最後のフレームの符号化が完了してセグメントのヘッダを生成するまで、そのセグメントを配信することができない。このため、セグメント時間長が、映像データの生成（撮影等）から配信までの遅延時間にそのまま加算される。このため、ライブ映像の配信時におけるリアルタイム性が著しく損なわれうる。また、これは、配信するコンテンツの符号量を抑えるためにＩ−Ｆｒａｍｅの生成間隔を長くした場合にさらに顕著になりうる。

本発明は、メディアデータの配信に係る遅延時間を短縮する技術を提供する。

本発明の一態様による送信装置は、受信装置へメディアデータを送信する送信装置であって、前記メディアデータの所定時間長の部分に対応するセグメントであって、前記メディアデータの再生のための基準となる所定の基準データを含んだ第１のセグメントと、前記所定の基準データを含まない第２のセグメントとを生成する生成手段と、前記受信装置からのセグメントの要求に応じて、前記生成したセグメントを前記受信装置へ送信する送信手段と、を有し、前記送信手段は、前記所定の基準データを受信していない前記受信装置から要求されたセグメントが前記第２のセグメントであったことに基づいて、当該第２のセグメントを前記第１のセグメントへ変更して前記受信装置へ送信する、ことを特徴とする。

本発明によれば、メディアデータの配信に係る遅延時間を短縮することができる。

システム構成例を示す図である。 送信装置のハードウェア構成例を示す図である。 送信装置の機能構成例を示す図である。 ライブ映像配信の遅延が発生する仕組みを説明するための図である。 セグメント生成の概要を説明するための図である。 セグメント生成の別の概要を説明するための図である。 セグメントの取得要求から配信までの処理の流れの例を示す図である。

以下、添付図面を参照して実施形態を詳しく説明する。尚、以下の実施形態は特許請求の範囲に係る発明を限定するものでない。実施形態には複数の特徴が記載されているが、これらの複数の特徴の全てが発明に必須のものとは限らず、また、複数の特徴は任意に組み合わせられてもよい。さらに、添付図面においては、同一若しくは同様の構成に同一の参照番号を付し、重複した説明は省略する。

（システム構成）
図１に、本実施形態におけるコンテンツ配信システムの構成例を示す。本システムでは、映像コンテンツや音声コンテンツ等のメディアコンテンツが配信されるシステムであり、メディアコンテンツを配信する送信装置１００と、そのメディアコンテンツを受信する受信装置２００とを含んで構成される。送信装置１００は、一例において、通信路３００を介して、受信装置２００と通信可能に構成される。なお、図１の例では、１つの送信装置１００と１つの受信装置２００とが示されているが、これらの装置の少なくともいずれかが複数存在してもよい。

送信装置１００は、例えば、カメラ、ビデオカメラ、スマートフォン、ＰＣ（パーソナルコンピュータ）、携帯電話などでありうるが、後述の機能を実行可能な任意の他の電子機器であってもよい。受信装置２００は、コンテンツの再生・表示機能、通信機能、及びユーザからの入力を受け付ける機能を有する限りにおいて、スマートフォン、ＰＣ、テレビ、携帯電話等の任意の電子機器でありうる。通信路３００は、例えば有線と無線とを問わない任意の通信ネットワークでありうる。通信ネットワークは、インターネット／イントラネット、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）／ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）等の各種ネットワークのいずれかでありうる。また、有線通信インタフェースは、Ｅｔｈｅｒｎｅｔ（登録商標）規格に従うインタフェースでありうるが、他のインタフェースが用いられてもよい。無線通信インタフェースは、ＩＥＥＥ８０２．１１規格シリーズに準拠した無線ＬＡＮ規格に準拠したインタフェースであってもよいし、３Ｇ／４Ｇ／ＬＴＥ等のＷＡＮ、Ｂｌｕｅｔｏｏｔｈ（登録商標）等の規格に準拠するインタフェースが用いられてもよい。なお、無線接続形態として、インフラストラクチャネットワークでの接続が用いられてもよいし、アドホックネットワークでの接続が用いられてもよい。また、通信路３００は、有線通信路と無線通信路との組み合わせであってもよい。すなわち、送信装置１００と受信装置２００との間で接続が確立されて通信が行われる限りにおいて、通信路３００は任意の形式を有してもよい。

（送信装置の構成）
図２に、本実施形態に係る送信装置１００のハードウェア構成を示す。送信装置１００は、そのハードウェア構成として、例えば、記憶部１２１、制御部１２２、機能部１２３、入力部１２４、出力部１２５、及び通信部１２６を有する。なお、図２の構成は一例であり、送信装置１００は、図２に示す構成の一部のみを有してもよいし、図２に示される以外の構成を有してもよい。

記憶部１２１は、ＲＯＭ、ＲＡＭの両方、または、いずれか一方の、１以上のメモリにより構成され、後述する各種動作を行うためのプログラムや、無線通信のための通信パラメータ等の各種情報を記憶する。ここで、ＲＯＭはＲｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙの略であり、ＲＡＭはＲａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙの略である。なお、記憶部１２１として、ＲＯＭ、ＲＡＭ等のメモリの他に、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＤＶＤなどの記憶媒体が用いられてもよい。

制御部１２２は、例えば、ＣＰＵやＭＰＵ等の１つ以上のプロセッサ、ＡＳＩＣ（特定用途向け集積回路）、ＤＳＰ（デジタルシグナルプロセッサ）、ＦＰＧＡ（フィールドプログラマブルゲートアレイ）等により構成される。ここで、ＣＰＵはＣｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔの、ＭＰＵは、Ｍｉｃｒｏ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔの頭字語である。制御部１２２は、記憶部１２１に記憶されたプログラムを実行することにより送信装置１００の全体を制御する。なお、制御部１２２は、記憶部１２１に記憶されたプログラムとＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）との協働により送信装置１００の全体を制御するようにしてもよい。

また、制御部１２２は、機能部１２３を制御して、撮像や印刷、投影等の所定の処理を実行する。機能部１２３は、送信装置１００が所定の処理を実行するためのハードウェアである。例えば、送信装置１００がカメラである場合、機能部１２３は撮像部であり、撮像処理を行う。機能部１２３が処理するデータは、記憶部１２１に記憶されているデータであってもよいし、後述する通信部１２６を介してＳＴＡと通信したデータであってもよい。

入力部１２４は、ユーザからの各種操作の受付を行う。出力部１２５は、ユーザに対して各種出力を行う。ここで、出力部１２５による出力とは、画面上への表示や、スピーカによる音声出力、振動出力等の少なくとも１つを含む。なお、タッチパネルのように入力部１２４と出力部１２５の両方を１つのモジュールで実現するようにしてもよい。

通信部１２６は、有線通信又は無線通信の制御や、ＩＰ通信の制御を行う。送信装置１００は通信部１２６を介して、映像データや音声データ等のメディアコンテンツを他の通信装置（受信装置２００）と通信する。

図３は、送信装置１００の機能構成例を示す図である。送信装置１００は、一例において、メディアデータ取得部１４１、セグメント生成部１４２、プレイリスト生成部１４３、通信部１４４、要求処理部１４５を含んで構成される。メディアデータ取得部１４１は、符号化された映像データや音声データ等のメディアデータを取得する。セグメント生成部１４２は、メディアデータ取得部１４１によって取得されたメディアデータを、所定の時間ごとにまとめてセグメントを生成する。プレイリスト生成部１４３は、セグメント生成部１４２からセグメントが生成されたことを通知されたことに基づいて、セグメントの取得を可能とするＵＲＬが記述されたプレイリストを生成する。通信部１４４は、通信路３００を介して、受信装置２００からの要求信号の受信や、プレイリスト及びセグメントの送信等の処理を実行する。要求処理部１４５は、受信装置２００からの要求に応じて、生成されたプレイリスト及びセグメントを、通信部１４４を介して受信装置２００に送信するための処理を実行する。なお、図３に示す各機能部は、ＡＳＩＣ等の専用のハードウェア又はソフトウェアとして送信装置に実装されうる。ハードウェアとして実装される場合は、各機能部それぞれ又はいくつかをまとめた専用のハードウェアモジュールとして実装可能である。ソフトウェアとして実装される場合には、各機能部を実行するためのプログラムが前述の送信装置の記憶部１２１に記憶され、制御部１２２のプロセッサにより適宜読み出されて実行される。

（映像配信の遅延）
本実施形態において送信装置１００が実行する処理について説明する前に、図４を用いて、ライブ映像配信において遅延が発生する仕組みについて概説する。図４において、送信装置１００は、符号化データを３０秒毎にまとめてヘッダを生成し、セグメントを生成している。ここで、ＭＰＥＧ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔ Ｇｒｏｕｐ）で標準化された動画圧縮技術では、符号化されたフレームデータを１枚以上まとめた集まりがＧＯＰ（Ｇｒｏｕｐ Ｏｆ Ｐｉｃｔｕｒｅｓ）と呼ばれる。本実施形態では、先頭にのみＩ−Ｆｒａｍｅが存在し、残りは前方参照フレームであるＰ−Ｆｒａｍｅによって構成されるＧＯＰを例として説明する。

図４では、３０秒分の符号化データが１つのＧＯＰとされ、ＧＯＰ４０１は、そのＧＯＰの最後のフレームが生成されてから、ヘッダが付与され、そのＧＯＰ４０１とヘッダとを含んだ「セグメント（１）」が生成される。受信装置２００は、プレイリスト受信後に、プレイリストに記載されたコンテンツ情報に基づいて、セグメント（１）の取得を送信装置１００に対して要求する。図４では、送信装置１００は、時刻Ｔ１において受信装置２００からセグメント取得要求４０２を受信すると、生成済みのセグメント（１）の配信４０３を実行し、受信装置２００は、受信したセグメント（１）の再生処理を実行する。

以降、セグメントごとに生成・取得・再生を繰り返すことでストリーミング再生が行われる。図４の４０４で再生されるセグメント（１）は、ＧＯＰ４０１のデータが格納されたものであるため、図４に示す時間４０５が、実際のライブ映像と、再生される映像との時間差である遅延時間となる。受信装置２００が取得を要求するセグメントは、生成済みセグメントのうち最新のものである事が期待される。しかしながら、図４に示すように、期待通りの要求をした場合でも、遅延時間４０５は、少なくとも１セグメントから最大２セグメント分の遅延が発生する。すなわち、図４のように、ＧＯＰの時間長が３０秒のケースでは、３０秒から１分程度の遅延が発生することになる。なお、実際の遅延時間には、映像データの符号化／復号にかかる時間や通信路での伝送遅延など様々な要素が含まれうるが、本実施形態では、遅延時間に大きな影響を与えるセグメントの時間長と取得タイミングによって決まる時間４０５を主として取り扱う。

（処理の概要）
続いて、上述のような遅延時間を削減する方法の例について、説明する。

＜方法１＞
図５に、遅延時間を削減するセグメント生成の概要を示す。図５では、送信装置１００は、時間長３０秒のＧＯＰを６分割し、時間長５秒のセグメントを生成する。この場合、５秒分のフレームが生成され次第、順次セグメントが生成される。なお、上述のように、ＧＯＰは、先頭がＩ−Ｆｒａｍｅで、以降のフレームは全てＰ−Ｆｒａｍｅである。このため、３０秒の１つのＧＯＰに対応する６個のセグメントのうち、先頭の１つはＩ−Ｆｒａｍｅを含み、それ以外のセグメントはＩ−Ｆｒａｍｅを含まずにＰ−Ｆｒａｍｅのみを含んで構成される。

図５では、送信装置１００は、時刻Ｔｎに受信装置２００からセグメント（ｎ）の取得要求５０１を受信したものとする。このとき、要求されたセグメント（ｎ）がＩ−Ｆｒａｍｅを含まない場合、セグメント（ｎ）の先頭のＰ−Ｆｒａｍｅを、Ｉ−Ｆｒａｍｅに変更５０２し、変更したセグメント（ｎ）を受信装置２００に配信する。なお、Ｐ−ＦｒａｍｅからＩ−Ｆｒａｍｅへの変更は、対象のＰ−ＦｒａｍｅをＩ−Ｆｒａｍｅとして再エンコードする事によって行われうる。例えば、直前のＩ−Ｆｒａｍｅを基準として符号化されることによって得られていたＰ−Ｆｒａｍｅについて、対応するフレームを、そのような基準を用いずに符号化することによって、Ｉ−Ｆｒａｍｅとする。また、各セグメントの先頭フレームは、ＧＯＰの生成とは別に、事前にＩ−Ｆｒａｍｅを重複して生成し、変更が必要な場合に先頭フレームを入れ替えるようにしてもよい。また、ＭＰＥＧ−ＤＡＳＨ（Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ Ｈｔｔｐ）のように、プレイリストを利用するストリーミング手法では、プレイリストの配信後にセグメントの取得要求が受信される。このため、送信装置１００は、常にＩ−Ｆｒａｍｅを重複して生成することに代えて、プレイリスト配信後の所定の期間だけＩ−Ｆｒａｍｅを重複して生成するようにしてもよい。

受信装置２００は、以降、各セグメントを５秒ごとに順次取得し、再生処理することにより、ストリーミングでの動画再生を継続的に実行する。上述のように、遅延時間はセグメントの時間長に依存する。このため、図５の例では、遅延時間を、分割後のセグメントの時間長である５秒（〜２セグメント分の１０秒）程度の遅延時間５０４に抑える事ができる。

＜方法２＞
図６に、遅延時間を削減するセグメント生成の別の概要を示す。図６では、送信装置１００は、先頭がＩ−Ｆｒａｍｅで残りがＰ−Ｆｒａｍｅで構成される符号化シーケンスを持つＧＯＰの生成を繰り返し、１つのＧＯＰを分割したセグメントを生成する。ここで、送信装置１００は、時刻Ｔｎにおいて受信装置２００からセグメント（ｎ）の取得要求６０１を受信すると、セグメント（ｎ）、現在生成中のセグメント、及び、次に生成するセグメント（ｍ）がＩ−Ｆｒａｍｅを含まない予定であるかを判定する。そして、送信装置１００は、これらのセグメントがＩ−Ｆｒａｍｅを含まない予定である場合に、セグメント（ｍ）がＩ−Ｆｒａｍｅを含むように符号化シーケンスの変更６０２を行う。そして、送信装置１００は、セグメント（ｎ）ではなくセグメント（ｍ）の受信装置２００への配信６０３を実行する。これにより、セグメント（ｍ）は、生成完了後すぐに配信されるため、遅延時間は図６の時間６０４によって示される長さとなり、ほぼ１セグメント分の遅延に抑える事が可能となる。なお、ここでは、要求されたセグメントと、その次のセグメントがＩ−Ｆｒａｍｅを含む予定であるか否かが判定されたが、要求されたセグメントから後の時間に対応する任意の所定数のセグメントにＩ−Ｆｒａｍｅを含む予定であるか否かが判定されてもよい。

なお、時刻Ｔｎにおいて生成中のセグメントがＩ−Ｆｒａｍｅを含む場合、送信装置１００は、符号化シーケンスを変更することなく時刻Ｔｎにおいて生成中のセグメントの生成が完了し次第、配信しうる。また、次に生成するセグメント（ｍ）から比較的短い所定の時間内に次のＩ−Ｆｒａｍｅを含むセグメントを生成予定であった場合は、送信装置１００は、符号化シーケンスを変更せずに、次のＩ−Ｆｒａｍｅを含むセグメントを配信するようにしてもよい。

（処理の流れ）
上述のような本実施形態の送信装置１００が実行する一連の処理の流れについて、図７を用いて概説する。図７のフローチャートに示す各ステップは、例えば、送信装置の制御部１２２が記憶部１２１に記憶されたプログラムを読み出して実行することにより実施される。図７において、送信装置１００は、セグメント取得要求を受信する（Ｓ７０１）。なお、送信装置１００は、Ｓ７０１に至るまでの処理において、ＭＰＥＧ−ＤＡＳＨの場合、受信装置２００とのプレイリストのやり取りなどが行われるが、この説明については従来の処理と同様であるため、ここでの説明については省略する。送信装置１００は、要求されたセグメントがＩ−Ｆｒａｍｅを含むか判定し（Ｓ７０２）、要求されたセグメントがＩ−Ｆｒａｍｅを含んでいる場合（Ｓ７０２でＹＥＳ）は、そのセグメントを受信装置２００へ配信する（Ｓ７０５）。一方、送信装置１００は、要求されたセグメントがＩ−Ｆｒａｍｅを含んでいない場合（Ｓ７０２でＮＯ）は、次に生成するセグメントから所定の時間内にＩ−Ｆｒａｍｅを含むセグメントが生成される予定であるか否かを判定する（Ｓ７０３）。そして、送信装置１００は、所定の時間内にＩ−Ｆｒａｍｅを含んだセグメントが生成される予定の場合（Ｓ７０３でＹＥＳ）は、そのＩ−Ｆｒａｍｅを含んだセグメントが生成されるのを待って、そのセグメントを受信装置２００へ配信する（Ｓ７０５）。送信装置１００は、所定の時間内にＩ−Ｆｒａｍｅを含んだセグメントが生成される予定でない場合（Ｓ７０３でＮＯ）は、次に生成するセグメントをＩ−Ｆｒａｍｅを含むように変更する（Ｓ７０４）。そして、送信装置１００は、Ｉ−Ｆｒａｍｅを含むように変更したセグメントを受信装置２００へ配信する（Ｓ７０５）。これにより、送信装置１００は、受信装置２００へ、Ｉ−Ｆｒａｍｅを含むセグメントを所定の時間内に配信することができる。

なお、同じストリームを複数の受信装置が受信している場合、符号化シーケンスを変更すると、他の受信装置にビットレート変動の影響がある。そこで、ビットレート変動の影響を緩和するため、符号化シーケンスを変更して生成されるＩ−Ｆｒａｍｅの画像品質を落とすことなどにより、通常のＩ−Ｆｒａｍｅよりサイズを小さくしてもよい。これによれば、Ｉ−Ｆｒａｍｅを未受信の受信装置に、Ｉ−Ｆｒａｍｅを含んだセグメントを配信すると共に、Ｉ−Ｆｒａｍｅを既に取得していた受信装置のビットレートを一定に保つことが可能となる。

なお、ＭＰＥＧ−ＤＡＳＨによれば、解像度やビットレート等が異なる複数のストリームをサーバが生成し、クライアントは、受信するストリームを動的に切り替えることができる。このとき、クライアントは、ストリームの切り替え時には、切り替え後のストリームについてのＩ−Ｆｒａｍｅを含んだセグメントを取得できていないと、切り替え後のストリームを再生することができない。このため、サーバは、ストリーミングの開始時だけでなく、ストリーミングの切り替え時にも、上述の手法を適用することができる。すなわち、異なるストリームへの切り替えが行われた場合には、そのタイミングで上述の処理を実行し、Ｉ−Ｆｒａｍｅを含んだセグメントがクライアントに提供される。これにより、ストリーミングの開始時のみならず、ストリーミングの切り替え時にも、遅延時間を抑制することができる。

なお、上述の説明は、Ｈ．２６４規格を用いることを前提としたが、これに限られない。すなわち、メディアデータの一部であると共に再生の基準となるＩ−Ｆｒａｍｅのような所定の基準データと、その基準データを用いてメディアデータを再生するための他のデータとからなる任意の形式のメディアファイルに上述の議論を適用可能である。送信装置は、上述の所定の基準データを含んだ所定時間長のメディアデータ部分に対応するセグメントと、その基準データを含まない所定時間長のメディアデータ部分に対応するセグメントとを生成する。そして、送信装置は、所定の基準データを送信済みでない受信装置から、その所定の基準データを含まないセグメントを要求する信号を受信した場合、例えば、そのセグメントを、所定の基準データを含んだセグメントへと変換して送信する。これにより、受信装置において、メディアデータの再生に必要なデータを取得することができるまでの時間を短縮することができる。

なお、上述の説明では、送信装置１００がプレイリストを生成して受信装置２００へ送信すると説明したが、これに限られない。例えば、送信装置１００は、プレイリストを生成する生成装置に対して、生成が完了したセグメントの情報を逐次的に通知し、その生成装置が、その通知に基づいてプレイリストを生成するようにしてもよい。この場合、送信装置１００自身は、プレイリストを生成する必要がなくなる。

＜その他の実施形態＞
以上、実施形態例を詳述したが、本発明は例えば、システム、装置、方法、プログラム、または、記録媒体（記憶媒体）等としての実施態様をとることが可能である。具体的には、複数の機器（例えば、ホストコンピュータ、インタフェース機器、撮像装置、ｗｅｂアプリケーション等）から構成されるシステムに適用してもよいし、また、一つの機器からなる装置に適用してもよい。

本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

発明は上記実施形態に制限されるものではなく、発明の精神及び範囲から離脱することなく、様々な変更及び変形が可能である。従って、発明の範囲を公にするために請求項を添付する。

１００：送信装置、１４１：メディアデータ取得部、１４２：セグメント生成部、１４４：通信部、１４５：要求処理部、２００：受信装置

Claims (11)

1. 受信装置へメディアデータを送信する送信装置であって、
   前記メディアデータの所定時間長の部分に対応するセグメントであって、前記メディアデータの再生のための基準となる所定の基準データを含んだ第１のセグメントと、前記所定の基準データを含まない第２のセグメントとを生成する生成手段と、
   前記受信装置からのセグメントの要求に応じて、前記生成したセグメントを前記受信装置へ送信する送信手段と、
   を有し、
   前記送信手段は、前記受信装置から要求されたセグメントが前記第２のセグメントであったことに基づいて、当該第２のセグメントを前記第１のセグメントへ変更して前記受信装置へ送信する、
   ことを特徴とする送信装置。
2. 前記所定の基準データは、前記第１のセグメントに対応する所定時間長の前記メディアデータのうちの一部を、基準を用いずに符号化して得られるデータであり、
   前記送信手段は、前記第２のセグメントに対応する前記メディアデータの所定時間長の部分に含まれる一部を、基準を用いずに符号化して前記所定の基準データとすることにより、当該第２のセグメントを前記第１のセグメントへ変更する、
   ことを特徴とする請求項１に記載の送信装置。
3. 前記所定の基準データは、前記第１のセグメントに対応する所定時間長の前記メディアデータのうちの一部を、基準を用いずに符号化して得られるデータであり、
   前記生成手段は、前記第２のセグメントを生成する際に、当該第２のセグメントに対応する前記メディアデータの所定時間長の部分に含まれる一部について、基準を用いずに符号化した所定のデータを事前に生成しておき、
   前記送信手段は、前記第２のセグメントの前記一部を、前記事前に生成された前記所定のデータと置き換えることにより、当該第２のセグメントを前記第１のセグメントへ変更する、
   ことを特徴とする請求項１に記載の送信装置。
4. 前記受信装置は、前記メディアデータを含んだプレイリストに基づいて、前記セグメントを要求し、
   前記生成手段は、前記プレイリストが前記受信装置に配信されてから所定の期間の間だけ、前記第２のセグメントを生成する際に前記所定のデータを生成する、
   ことを特徴とする請求項３に記載の送信装置。
5. 前記プレイリストは、ＭＰＥＧ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）−ＤＡＳＨ（Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ Ｈｔｔｐ）のプレイリストである、
   ことを特徴とする請求項４に記載の送信装置。
6. 前記送信手段は、前記所定の基準データが送信されている前記受信装置からセグメントが要求された場合、又は、前記所定の基準データが送信されていない前記受信装置から要求されたセグメントが前記第１のセグメントである場合に、前記変更を行わない、
   ことを特徴とする請求項１から５のいずれか１項に記載の送信装置。
7. 前記送信手段は、前記所定の基準データが送信されていない前記受信装置から要求されたセグメントが前記第２のセグメントであった場合であっても、当該セグメントより後の時間に対応する所定数のセグメントのうちのいずれかが第１のセグメントであることが予定されている場合には、前記変更を行わず、前記要求されたセグメントとして、当該第１のセグメントを前記受信装置へ送信する、
   ことを特徴とする請求項１から６のいずれか１項に記載の送信装置。
8. 前記所定の基準データは、Ｈ．２６４規格のＩ−Ｆｒａｍｅである、
   ことを特徴とする請求項１から７のいずれか１項に記載の送信装置。
9. 前記送信手段は、前記第２のセグメントを前記第１のセグメントへ変更する場合、当該第２のセグメントから変更されたものでない前記第１のセグメントより品質を落としたセグメントを、当該変更の後のセグメントとして送信する、
   ことを特徴とする請求項１から８のいずれか１項に記載の送信装置。
10. 送信装置によって実行される受信装置へメディアデータを送信する送信方法であって、
    前記メディアデータの所定時間長の部分に対応するセグメントであって、前記メディアデータの再生のための基準となる所定の基準データを含んだ第１のセグメントと、前記所定の基準データを含まない第２のセグメントとを生成する生成工程と、
    前記受信装置からのセグメントの要求に応じて、前記生成したセグメントを前記受信装置へ送信する送信工程と、
    を有し、
    前記送信工程では、前記受信装置から要求されたセグメントが前記第２のセグメントであったことに基づいて、当該第２のセグメントを前記第１のセグメントへ変更して前記受信装置へ送信する、
    ことを特徴とする送信方法。
11. コンピュータを、請求項１から９のいずれか１項に記載の送信装置が有する各手段として機能させるためのプログラム。

Images