JP6462566B2 - 送信装置、送信方法、受信装置および受信方法 - Google Patents

Description

本技術は、送信装置、送信方法、受信装置および受信方法に関し、特に、多画像配置の配信サービスを行うための送信装置等に関する。

放送やネットワークからの複数のストリームをマルチデコードし、マルチデコードによって得られた複数の画像を１つのディスプレイに表示させるマルチ画面表示に関する技術が実現、または提案されている。

例えば、いわゆるＰinＰ(Picture in Picture)の形で複数の画像が表示されることにより、ユーザは、サブ画面に小さく表示される他のチャンネルの番組の画像を見ながら、メイン画面に大きく表示されるあるチャネルの番組の画像を見ることができる。また、例えば、ディスプレイの右半分と左半分に異なるチャンネルの番組の画像が並べて表示されることにより、ユーザは、２つのチャネルの番組の画像を同時に見ることができる。

例えば、特許文献１には、通常表示の状態においてマルチ画面の表示が指示された場合、マルチ画面への表示の切り替えを迅速に行うことができるようにした技術が開示されている。

特開２０００−１３７１２号公報

例えば、送信側から多画像配置に係る複数の画像の画像データを送り、受信側ではこの複数の画像データを処理して多画像配置画像を得て、表示を行うことが考えられる。この場合、受信側では複数の画像の配置を適切に行うことが必要となる。

本技術の目的は、多画像配置の配信サービスを良好に行い得るようにすることにある。

本技術の概念は、
多画像配置の配信サービスに係る複数の画像の符号化画像データを含む、所定数のビデオストリームを有する所定フォーマットのコンテナを送信する送信部と、
上記ビデオストリームのレイヤに、上記複数の画像の配置位置を示す位置情報を挿入する情報挿入部とを備える
送信装置にある。

本技術において、送信部により、多画像配置の配信サービスに係る複数の画像の符号化画像データを含む、所定数のビデオストリームを有する所定フォーマットのコンテナが送信される。例えば、コンテナは、デジタル放送規格で採用されているトランスポートストリーム（ＭＰＥＧ−２ ＴＳ）であってもよい。また、例えば、コンテナは、インターネットの配信などで用いられるＭＰ４、あるいはＭＭＴなどそれ以外のフォーマットのコンテナであってもよい。情報挿入部により、ビデオストリームのレイヤに、複数の画像の配置位置を示す位置情報が挿入される。

このように本技術においては、ビデオストリームのレイヤに複数の画像の配置位置を示す位置情報が挿入されるものであり、受信側では複数の画像の配置を適切に行うことが容易に可能となる。

なお、本技術において、例えば、情報挿入部は、複数の画像の表示タイミングを調整するためのオフセット情報を、ビデオストリームのレイヤにさらに挿入する、ようにされてもよい。これにより、受信側では、多画像配置画像を構成する複数の画像の表示タイミングを調整して、これらの複数の画像の表示開始タイミングを一致させることが可能となる。

また、本技術において、例えば、情報挿入部は、多画像配置のタイプを示すタイプ情報を、ビデオストリームのレイヤにさらに挿入する、ようにされてもよい。これにより、受信側では、多画像配置のタイプを的確に認識でき、複数の画像の配置を適切に行うことが容易に可能となる。また、本技術において、例えば、情報挿入部は、複数の画像の表示可能な時間が制御されるか否かを示すライフタイム情報を、ビデオストリームのレイヤにさらに挿入する、ようにされてもよい。この情報により、受信側では、例えば、仮想ディスプレイバッファ内に蓄積されている画像データの削除制御を自動的に行うことが可能となる。

また、本技術において、例えば、情報挿入部は、複数の画像の表示時のローテーションタイプを示すタイプ情報を、上記ビデオストリームのレイヤにさらに挿入する、ようにされてもよい。これにより、複数の画像を、サービス側が意図した回転状態で表示させることが可能となる。

また、本技術において、例えば、情報挿入部は、コンテナのレイヤに、多画像配置の配信サービスであることを識別する識別情報をさらに挿入する、ようにされてもよい。これにより、受信側では、多画像配置の配信サービスであることを容易に認識でき、その処理のための準備を行うことが可能となる。この場合、例えば、情報挿入部は、コンテナのレイヤに、多画像配置の配信サービスが、動画静止画の混在サービスであるか否かを識別する識別情報をさらに挿入する、ようにされてもよい。

また、本技術において、例えば、情報挿入部は、コンテナのレイヤに、多画像配置の配信サービスに関与するビデオストリームの総数の情報をさらに挿入する、ようにされてもよい。これにより、受信側では、処理すべきビデオストリームの総数を容易に把握でき、適切な処理が可能となる。

また、本技術において、例えば、情報挿入部は、コンテナのレイヤに、各ビデオストリームが動画ストリームであるか、静止画ストリームであるか、あるいは静止画動画混在の混在ストリームであるかを示すタイプ情報をさらに挿入する、ようにされていてもよい。これにより、受信側では、ビデオストリームのストリームのタイプを容易に把握でき、適切な処理を行うことが可能となる。

また、本技術の概念は、
多画像配置の配信サービスに係る複数の画像の符号化画像データを含み、上記複数の画像の配置位置を示す位置情報が挿入されている所定数のビデオストリームを受信する受信部と、
上記所定数のビデオストリームをデコードして上記複数の画像の画像データを得るデコード部と、
上記デコード後の複数の画像の画像データを上記位置情報に基づいて配置して多画像配置画像の画像データを得る処理部とを備える
受信装置にある。

本技術において、受信部により、多画像配置の配信サービスに係る複数の画像の符号化画像データを含み、この複数の画像の配置位置を示す位置情報が挿入されている所定数のビデオストリームが受信される。デコード部により、所定数のビデオストリームがデコードされて、複数の画像の画像データが得られる。

そして、処理部により、デコード後の複数の画像の画像データが位置情報に基づいて配置されて多画像配置画像の画像データが得られる。例えば、デコード部で得られた複数の画像の画像データを一時的に蓄積するデコーデッドバッファと、多画像配置の画像データを一時的に蓄積する仮想ディスプレイバッファとをさらに備え、処理部は、デコーデッドバッファから上記複数の画像の画像データを順次読み出し、仮想ディスプレイバッファの上記位置情報が示す配置位置に応じた領域に書き込む、ようにされてもよい。

このように本技術においては、デコード後の複数の画像の画像データが位置情報に基づいて配置されて、多画像配置画像の画像データが得られるものである。したがって、多画像配置画像の画像データを効率よく、かつ適切に得ることが可能となる。

なお、本技術において、例えば、仮想ディスプレイバッファから多画像配置画像の一部または全部の表示領域に対応した画像データを読み出し、この表示領域の画像を表示する表示制御部をさらに備える、ようにされてもよい。この場合、例えば、表示制御部に表示領域を指示するユーザ操作部をさらに備える、ようにされてもよい。これにより、例えば、ディスプレイに表示される画像を変化させることができ、サイズ（解像度）の小さなディスプレイに例えばユーザ操作に基づいてサイズの大きな多画像配置画像をスクロールして表示することも可能となる。また、この場合、例えば、表示制御部に表示領域の画像を表示するディスプレイの数を指定するユーザ操作部をさらに備える、ようにされてもよい。

また、本技術において、例えば、所定数のビデオストリームの送信の停止および再開の要求を送信側に送る要求送信部をさらに備える、ようにされてもよい。これにより、例えば、画像データを一時的に蓄積しておくバッファをオーバフローさせることなく、静止画像である多画像配置画像を、ユーザのタイミングで閲覧することが可能となる。

また、本技術の他の概念は、
配信サーバがネットワークを通じて配信可能な多画像配置の配信サービスに係る複数の画像の符号化画像データを含む、所定数のビデオストリームをクライアント端末が取得するための情報を持つメタファイルを生成するメタファイル生成部と、
上記クライアント端末から送信要求があるとき、上記ネットワークを通じて、該クライアント端末に、上記生成されたメタファイルを送信するメタファイル送信部とを備え、
上記ビデオストリームのレイヤに、上記複数の画像の配置位置を示す位置情報が挿入されており、
上記メタファイル生成部は、上記メタファイルに、上記所定数のビデオストリームを常に読むことを示す情報を含める
送信装置にある。

本技術において、メタファイル生成部により、所定数のビデオストリームをクライアント端末が取得するための情報を持つメタファイルが生成される。この所定数のビデオストリームには、配信サーバがネットワークを通じて配信可能な多画像配置の配信サービスに係る複数の画像の符号化画像データが含まれる。この場合、ビデオストリームのレイヤには、複数の画像の配置位置を示す位置情報が挿入されている。

メタファイル送信部により、クライアント端末から送信要求があるとき、ネットワークを通じて、このクライアント端末に、メタファイルが送信される。このメタファイルには、メタファイル生成部により、所定数のビデオストリームを常に読むことを示す情報が含められる。

このように本技術においては、メタファイルには、所定数のビデオストリームを常に読むことを示す情報が含まれる。そのため、受信側では、このメタファイルの情報に基づいて所定数のビデオストリームを常に読むようにされるため、多画像配置画像の画像データを良好に得ることが可能となる。

なお、本技術において、例えば、メタファイル生成部は、メタファイルに、所定数のビデオストリームが静止画ストリームであるか動画ストリームであるかを識別する識別情報をさらに含める、ようにされてもよい。これにより、クライアント端末は、所定数のビデオストリームが静止画ストリームであるか動画ストリームであるかを容易に判別可能となる。

本技術によれば、多画像配置の配信サービスを良好に行うことができる。なお、ここに記載された効果は必ずしも限定されるものではなく、本開示中に記載されたいずれかの効果であってもよい。

実施の形態としての配信システムの構成例を示すブロック図である。 水平・垂直方向２次元多画像配置の一例を示す図である。 水平方向１次元多画像配置の一例を示す図である。 静止画によるグループピクチャの例を示す図である。 動画によるグループピクチャの例を示す図である。 動画によるグループピクチャの例を示す図である。 静止画・動画によるグループピクチャの例を示す図である。 静止画（Still picture）サービスの単一ストリームによる配信例を示す図である。 静止画（Still picture）サービスの複数ストリームによる配信例を示す図である。 静止画（Still picture）、動画(Moving picture)の混在サービスの単一ストリームによる配信例を示す図である。 トランスポートストリームを生成する送信データ生成部の構成例を示すブロック図である。 単一ストリームによる配信を行う場合のトランスポートストリームの構成例を示す図である。 複数ストリームによる配信を行う場合のトランスポートストリームの構成例を示す図である。 グループ・ピクチャ・タグＳＥＩ（Group_picture_tag SEI）の構造例(Syntax)を示す図である。 グループ・ピクチャ・タグＳＥＩの構造例における主要な情報の内容（Semantics）を示す図である。 「display_coordinate」による表示時のローテーションの一例を示す図である。 グループピクチャを構成する各画像の表示タイミングＣＴＰの算出例を示す図である。 グループ・ピクチャ・タグＳＥＩの各種情報の時間的変遷の一例を示す図である。 マルチ・ストリーム・サービス・デスクリプタ（multi_stream_service_descriptor）の構造例（Syntax）を示す図である。 マルチ・ストリーム・サービス・デスクリプタの構造例における主要な情報の内容（Semantics）を示す図である。 ミックスト・ストリーム・デスクリプタ（mixed_stream_descriptor）の構造例（Syntax）とその主要な情報の内容（Semantics）を示す図である。 ピクチャ・ライフタイム・デスクリプタ（Picture_lifetime_descriptor）の構造例（Syntax）とその主要な情報の内容（Semantics）を示す図である。 仮想ディスプレイ（Virtual Display）上の画像と表示領域との関係の一例を示す図である。 仮想ディスプレイ上における表示領域の位置および大きさの一例を示す図である。 仮想ディスプレイ（Virtual Display）上の画像と表示領域との関係の一例を示す図である。 仮想ディスプレイ上における表示領域の位置および大きさの一例を示す図である。 パノラマ画像を表示するためのディスプレイの構成例を示す図である。 グループピクチャが水平方向に連続した７個の画像から構成されている場合における表示領域の指定例を示す図である。 ＤＡＳＨベースのストリーム配信システムの構成例を示すブロック図である。 ＭＰＤファイルの階層構造を示す図である。 ＭＰＤファイルに階層的に配置されている各構造体の関係の一例を示す図である。 コンテンツからＤＡＳＨセグメントやＤＡＳＨ ＭＰＤファイルを生成するまでのフローの一例を示す図である。 ストリーム配信システムを構成するＩＰＴＶクライアントの構成例を示す図である。 一般的な、ＤＡＳＨベースのストリーム配信システムの系を示す図である。 ビデオストリームを含むFragmentedMP4ストリームの構成例を示す図である。 多画像配置の配信サービスにおけるＭＰＤファイルの記述例を示す図である。 多画像配置の配信サービスにおけるＭＰＤファイルの記述例を示す図である。

以下、発明を実施するための形態（以下、「実施の形態」とする）について説明する。なお、説明を以下の順序で行う。
１．実施の形態
２．変形例

＜１．実施の形態＞
［配信システムの構成例］
図１は、配信システム１０の構成例を示している。この配信システム１０において、送信側には放送局１１０、ネット配信サーバ１２０およびＮＴＰ（Network Time Protocol）配信サーバ１３０が配置され、受信側には受信機２００が配置されている。

放送局１１０は、ＲＦ伝送路を通じて、静止画、動画のリニアサービス、あるいは静止画、動画のダウンロードサービスを行う。放送局１１０は、放送配信多重化データとして、例えばＭＰＥＧ２−ＴＳ（以下、単に、「トランスポートストリーム」と呼ぶ）のコンテナを送信する。この実施の形態において、トランスポートストリームは、多画像配置の配信サービスに係る複数の画像（ピクチャ）の符号化画像データを含む、所定数のビデオストリームを有するものとされる。

多画像配置には、例えば、複数の画像が水平・垂直方向に２次元配置された水平・垂直方向２次元多画像配置、複数の画像が水平方向に１次元配置された水平方向１次元多画像配置、複数の画像が垂直方向に１次元配置された垂直方向１次元多画像配置などがある。

ビデオストリームのレイヤには、複数の画像の配置位置を示す位置情報の他、複数の画像の表示タイミングを調整するためのオフセット情報、多画像配置のタイプを示すタイプ情報、複数の画像の表示時のローテーションタイプを示すタイプ情報などが挿入される。例えば、画像データがＡＶＣ（Advanced Video Coding）、ＨＥＶＣ（High Efficiency Video Coding）などで符号化されている場合、これらの情報は新たに定義されるＳＥＩメッセージに挿入される。

図２は、水平・垂直方向２次元多画像配置の一例を示している。この例においては、水平・垂直の双方向に４つの画像が配置されている。この４×４の画像で構成される多画像配置画像（以下、適宜、「グループピクチャ」と呼ぶ）は仮想ディスプレイ（Virtual Display）に対応した解像度を持っている。例えば、１つの画像がＨＤ解像度である場合、グループピクチャは８Ｋ解像度を持つものとなる。

「００００」〜「１１１１」は、各画像の位置情報である４ビットデータを示している。この場合、前半の２ビットは、仮想ディスプレイの４分割のうちのどの位置かを示す。また、後半の２ビットは、その４分割をさらに４分割に細分化した各々の位置を示す。また、「Picture rendering type」は、多画像配置のタイプを示すタイプ情報である。「Picture rendering type = 011」は、水平・垂直方向２次元多画像配置であることを示す。

図３は、水平方向１次元多画像配置の一例を示している。この例においては、水平方向に５つの画像が配置されている。この５画像で構成されるグループピクチャは仮想ディスプレイ（Virtual Display）に対応した解像度を持っている。例えば、１つの画像がＨＤ解像度である場合、水平方向には、その５倍の解像度を持つものとなる。

「１１１０」、「１１１１」、「００００」、「０００１」、「００１０」は、各画像の位置情報である４ビットデータを示している。例えば、水平方向１次元多画像配置の場合、正面の画像の位置情報は「００００」、正面の右隣りＮ個目の画像の位置情報は「００００＋Ｎ」、さらに、正面左隣りＮ個目の画像の位置情報は「００００−Ｎ」とされる。

なお、垂直方向１次元多画像配置の例の説明は省略するが、上述した水平方向１次元多画像配置の例と同様となる。

また、トランスポートストリームのレイヤに、多画像配置の配信サービスであることを示す識別情報、その配信サービスが動画静止画の混在サービスであるか否かを識別する識別情報、多画像配置の配信サービスに関与するビデオストリームの総数などが挿入される。これらの情報は、例えば、プログラム・マップ・テーブル（ＰＭＴ：Program Map Table）の配下に挿入される、新たに定義されるデスクリプタに記述される。

１つのビデオストリームには、１つまたは複数の画像の符号化画像データが含まれる。また、ビデオストリームは、動画ストリーム、静止画ストリーム、あるいは動画静止画混在ストリームとされる。

図４は、静止画によるグループピクチャの例を示している。この例では、グループピクチャは２×２の画像（静止画）で構成される。そして、この例では、１つのビデオストリームで各画像の符号化画像データが時分割的に送られる。この場合、受信側では各画像の符号化データが順次復号化され、各画像の画像データは、それぞれ、位置情報に基づいて、仮想ディスプレイバッファ（Virtual Display Buffer）の対応する領域に書き込まれる。

図５は、動画によるグループピクチャの例を示している。この例では、グループピクチャは２×２の画像（動画）で構成される。そして、この例では、１つのビデオストリームで各画像の符号化画像データが時分割的に送られる。この場合、受信側では各画像の符号化データが順次復号化され、各画像の画像データは、それぞれ、位置情報に基づいて、仮想ディスプレイバッファの対応する領域に書き込まれる。

図６は、動画によるグループピクチャの例を示している。この例では、グループピクチャは２×２の画像（動画）で構成される。そして、この例では、４つのビデオストリームで各画像の符号化画像データが送られる。この場合、受信側では各画像の符号化データが復号化され、各画像の画像データは、それぞれ、位置情報に基づいて、仮想ディスプレイバッファの対応する領域に書き込まれる。

図７は、静止画・動画によるグループピクチャの例を示している。この例では、グループピクチャは２×２の画像（静止画、動画）で構成される。そして、この例では、１つのビデオストリームで各画像の符号化画像データが送られる。この場合、画像３（Picture 3）としては、静止画と動画が存在する。この場合、受信側では各画像の符号化データが復号化され、各画像の画像データは、それぞれ、位置情報に基づいて、仮想ディスプレイバッファの対応する領域に書き込まれる。

図８は、静止画（Still picture）サービスの単一ストリームによる配信例を示している。この例では、グループピクチャは２×２の画像で構成される。図において、丸数字が付された矩形部分がアクセスユニットを示している。この例は、ＨＥＶＣによる符号化が行われている例を示している。なお、「１」〜「４」の丸数字は、それぞれ、画像１（Picture 1）〜画像４（Picture 4）の符号化画像データが含まれていることを示している。

最初、画像１（Picture 1）〜画像４（Picture 4）の静止画の符号化画像データが順に送信される。次に、画像３（Picture 3）の更新された符号化画像データが送信される。次に、さらに、画像３（Picture 3）の更新された符号化画像データが送信される。次に、画像１（Picture 1）〜画像４（Picture 4）の更新された符号化画像データが順に送信される。

なお、「group_picture_start」は、ある時点で表示更新すべきグループピクチャの開始を示す。一方、「group_picture_end」は、ある時点で表示更新すべきグループピクチャの終了を示す。これらの情報は、後述するように、ビデオストリームのレイヤに挿入されている。以下の各例においても同様である。

図９は、静止画（Still picture）サービスの複数ストリームによる配信例を示している。この例では、グループピクチャは２×２の画像で構成される。図において、丸数字が付された矩形部分がアクセスユニットを示している。なお、「１」〜「４」の丸数字は、それぞれ、画像１（Picture 1）〜画像４（Picture 4）の符号化画像データが含まれていることを示している。

最初、ビデオストリーム１〜４によりそれぞれ画像１（Picture 1）〜画像４（Picture 4）の符号化画像データが順に送信される。次に、ビデオストリーム３により画像３（Picture 3）の更新された符号化画像データが送信される。次に、さらに、ビデオストリーム３により画像３（Picture 3）の更新された符号化画像データが送信される。次に、ビデオストリーム１〜４によりそれぞれ画像１（Picture 1）〜画像４（Picture 4）の更新された符号化画像データが順に送信される。

図１０は、静止画（Still picture）、動画(Moving picture)の混在サービスの単一ストリームによる配信例を示している。この例では、グループピクチャは２×２の画像で構成される。図において、丸数字が付された矩形部分がアクセスユニットを示している。なお、「１」〜「４」の丸数字は、それぞれ、画像１（Picture 1）〜画像４（Picture 4）の符号化画像データが含まれていることを示している。

最初、画像１（Picture 1）〜画像４（Picture 4）の静止画の符号化画像データが順に送信される。次に、画像３（Picture 3）の動画の符号化画像データが送信される。次に、画像１（Picture 1）〜画像４（Picture 4）の更新された静止画の符号化画像データが順に送信される。

図１１は、放送局１１０において、上述したトランスポートストリームを生成する送信データ生成部１１０の構成例を示している。この送信データ生成部１１０は、動画・静止画出力部１１２と、ビデオエンコーダ１１３と、マルチプレクサ１１４を有している。

動画・静止画出力部１１２は、多画像配置の配信サービスに係る複数の画像の画像データを出力する。この動画・静止画出力部１１２は、例えば、被写体を撮像して画像データを出力するカメラ、あるいは記憶媒体から画像データを読み出して出力する画像データ読み出し部などにより構成される。静止画サービスの場合には（例えば、図４参照）、複数の静止画の画像データを出力する。動画サービスの場合には（例えば、図５、図６参照）、複数の動画の画像データを出力する。さらに、動画、静止画の混在サービスの場合には（例えば、図７参照）、動画、静止画の複数の画像データを出力する。

ビデオエンコーダ１１３は、動画・静止画出力部１１２から出力される複数の画像の画像データに対して、例えば、ＡＶＣあるいはＨＥＶＣなどの符号化を施し、符号化画像データを得る。また、ビデオエンコーダ１１３は、後段に備えるストリームフォーマッタにより、符号化画像データを含む所定数のビデオストリーム（ビデオエレメンタリストリーム）を生成する。この場合、一つのビデオストリームには、多画像配置に係る一つ画像の符号化画像データを含む場合の他、多画像配置に係る複数の画像の符号化画像データを含む場合がある。

ここで、ビデオエンコーダ１１３は、ビデオストリームのレイヤに、複数の画像の配置位置を示す位置情報の他、複数の画像の表示タイミングを調整するためのオフセット情報、多画像配置のタイプを示すタイプ情報、複数の画像の表示時のローテーションタイプを示すタイプ情報などを挿入する。これらの情報は、画像データがＡＶＣ（Advanced Video Coding）、ＨＥＶＣ（High Efficiency Video Coding）などで符号化されている場合、新たに定義されるＳＥＩメッセージに挿入される。これらの情報の詳細については後述する。

マルチプレクサ１１４は、ビデオエンコーダ１１３で生成された各ビデオストリームをパケット化して多重化し、トランスポートストリームを生成する。ここで、マルチプレクサ１１４は、コンテナのレイヤ（システムレイヤ）に、多画像配置の配信サービスであることを示す識別情報、その配信サービスが動画静止画の混在サービスであるか否かを識別する識別情報、多画像配置の配信サービスに関与するビデオストリームの総数などを挿入する。これらの情報は、例えば、プログラム・マップ・テーブル（ＰＭＴ：Program Map Table）の配下に挿入される、新たに定義されるデスクリプタに記述される。これらの情報の詳細については後述する。

図１１に示す送信データ生成部１１０の動作を簡単に説明する。動画・静止画出力部１１２から多画像配置の配信サービスに係る複数の画像の画像データが出力される。これらの画像データは、ビデオエンコーダ１１３に供給される。ビデオエンコーダ１１３では、これらの画像データに対して、例えば、ＡＶＣあるいはＨＥＶＣなどの符号化が施され、符号化画像データが得られる。そして、このビデオエンコーダ１１３では、その符号化画像データを含む所定数のビデオストリームが生成される。

この際、ビデオエンコーダ１１３では、ビデオストリームのレイヤに、例えば、新たに定義されるＳＥＩメッセージにより、複数の画像の配置位置を示す位置情報の他、複数の画像の表示タイミングを調整するためのオフセット情報、多画像配置のタイプを示すタイプ情報、複数の画像の表示時のローテーションタイプを示すタイプ情報などが挿入される。

また、ビデオエンコーダ１１３から出力される所定数のビデオストリームは、マルチプレクサ１１４に供給される。マルチプレクサ１１４では、各ビデオストリームがパケット化されて多重化され、トランスポートストリームが生成される。この際、マルチプレクサ１１４では、トランスポートストリームのレイヤに、新たに定義されるデスクリプタにより、多画像配置の配信サービスであることを示す識別情報、その配信サービスが動画静止画の混在サービスであるか否かを識別する識別情報、多画像配置の配信サービスに関与するビデオストリームの総数などが挿入される。

［ＴＳ構成、ＳＥＩメッセージの構造、デスクリプタの構造］
図１２は、単一ストリームによる配信を行う場合のトランスポートストリームの構成例を示している。トランスポートストリームには、１つのビデオストリームが含まれている。すなわち、この構成例では、画像データが符号化されているビデオストリームのＰＥＳパケット「video PES1」が存在する。このビデオストリームには、多画像配置の配信サービスに係る複数の画像の符号化画像データが含まれている。

このビデオストリームには、各画像の符号化画像データのアクセスユニット毎に、グループ・ピクチャ・タグＳＥＩ（Group_picture_tag SEI）メッセージが挿入される。このＳＥＩメッセージにより、上述したように、ビデオストリームのレイヤに、各画像の配置位置を示す位置情報の他、各画像の表示タイミングを調整するためのオフセット情報、多画像配置のタイプを示すタイプ情報、各画像の表示時のローテーションタイプを示すタイプ情報などが挿入される。

また、トランスポートストリームＴＳには、ＰＳＩ（Program Specific Information）として、ＰＭＴ（Program Map Table）が含まれている。このＰＳＩは、トランスポートストリームに含まれる各エレメンタリストリームがどのプログラムに属しているかを記した情報である。

ＰＭＴには、プログラム全体に関連する情報を記述するプログラム・ループ（Program loop）が存在する。このプログラム・ループの配下に、マルチ・ストリーム・サービス・デスクリプタ（multi_stream_service_descriptor）が挿入される。また、ＰＭＴには、各エレメンタリストリームに関連した情報を持つエレメンタリ・ループが存在する。この構成例では、ビデオエレメンタリ・ループ（video ES1 loop）が存在する。

このビデオエレメンタリ・ループには、ビデオストリーム（video PES1）に対応して、ストリームタイプ、パケット識別子（PID）等の情報が配置されると共に、そのビデオストリームに関連する情報を記述するデスクリプタも配置される。このデスクリプタの一つとして、ミックスト・ストリーム・デスクリプタ（mixed_stream_descriptor）と、ピクチャ・ライフタイム・デスクリプタ（Picture_lifetime_descriptor）が挿入される。

このようにＰＭＴの配下に挿入されるデスクリプタにより、上述したように、多画像配置の配信サービスであることを示す識別情報、その配信サービスが動画静止画の混在サービスであるか否かを識別する識別情報、多画像配置の配信サービスに関与するビデオストリームの総数などが挿入される。

図１３は、複数ストリーム、ここでは４ストリームによる配信を行う場合のトランスポートストリームの構成例を示している。トランスポートストリームには、４つのビデオストリームが含まれている。すなわち、この構成例では、画像データが符号化されているビデオストリームのＰＥＳパケット「video PES1, video PES2, video PES3, video PES4」が存在する。これらのビデオストリームには、多画像配置の配信サービスに係る複数の画像の符号化画像データが含まれている。

これらのビデオストリームには、各画像の符号化画像データのアクセスユニット毎に、グループ・ピクチャ・タグＳＥＩ（Group_picture_tag SEI）メッセージが挿入される。このＳＥＩメッセージにより、上述したように、ビデオストリームのレイヤに、各画像の配置位置を示す位置情報の他、各画像の表示タイミングを調整するためのオフセット情報、多画像配置のタイプを示すタイプ情報、各画像の表示時のローテーションタイプを示すタイプ情報などが挿入される。

また、トランスポートストリームＴＳには、ＰＳＩ（Program Specific Information）として、ＰＭＴ（Program Map Table）が含まれている。このＰＳＩは、トランスポートストリームに含まれる各エレメンタリストリームがどのプログラムに属しているかを記した情報である。

ＰＭＴには、プログラム全体に関連する情報を記述するプログラム・ループ（Program loop）が存在する。このプログラム・ループの配下に、マルチ・ストリーム・サービス・デスクリプタ（multi_stream_service_descriptor）が挿入される。また、ＰＭＴには、各エレメンタリストリームに関連した情報を持つエレメンタリ・ループが存在する。この構成例では、４つのビデオエレメンタリ・ループ（video ES1 loop, video ES2 loop, video ES3 loop, video ES4 loop）が存在する。

これらのビデオエレメンタリ・ループには、各ビデオストリームに対応して、ストリームタイプ、パケット識別子（PID）等の情報が配置されると共に、そのビデオストリームに関連する情報を記述するデスクリプタも配置される。このデスクリプタの一つとして、ミックスト・ストリーム・デスクリプタ（mixed_stream_descriptor）と、ピクチャ・ライフタイム・デスクリプタ（Picture_lifetime_descriptor）が挿入される。

このようにＰＭＴの配下に挿入されるデスクリプタにより、上述したように、多画像配置の配信サービスであることを示す識別情報、その配信サービスが動画静止画の混在サービスであるか否かを識別する識別情報、多画像配置の配信サービスに関与するビデオストリームの総数などが挿入される。

図１４は、グループ・ピクチャ・タグＳＥＩ（Group_picture_tag SEI）の構造例(Syntax)を示している。また、図１５は、その構造例における主要な情報の内容（Semantics）を示している。「group_picture_id」の８ビットフィールドは、静止画を含む、複数のピクチャの集合表示のための関連付け情報である。つまり、グループピクチャ（多画像配置画像）を構成する各画像の「group_picture_id」は同一とされる。

「picture_rendering_type」の３ビットフィールドは、多画像配置のタイプ、つまりグループピクチャに含まれる画像の配置タイプを示す。“００１”は水平方向１次元多画像配置であることを示し、“０１０”は垂直方向１次元多画像配置であることを示し、“０１１”は水平・垂直方向２次元多画像配置であることを示す。この情報により、受信側では、多画像配置のタイプを的確に認識でき、複数の画像の配置を適切に行うことが容易に可能となる。

「lifetime_controlled」の１ビットフィールドは、表示可能な時間が制限されるか否かを示す。“１”は、 表示可能な時間が制限されていることを示す。この場合、システムレイヤ（コンテナのレイヤ）で指定されるＮＴＰ時刻まで表示可能となる。“０”は、表示可能な時間が制限されていないこと、つまり無期限に表示可能であることを示す。この情報により、受信側では、例えば、仮想ディスプレイバッファ内に蓄積されている画像データの削除制御を自動的に行うことが可能となる。

「location_ID」の４ビットフィールドは、グループピクチャを構成する各画像の配置位置を示す（図２、図３参照）。「version_number」の８ビットフィールドは、画像の更新（update）を示す昇順値である。この情報に基づいて、例えば、グループピクチャを構成する静止画の更新を順次行うことが可能となる。「number_of_pictures」の４ビットフィールドは、グループピクチャを構成する画像の総数、つまり、同一の「group_picture_id」を持ち、同時表示される画像の最大数である。

「display_coordinate」の３ビットフィールドは、表示時のローテーションのタイプを示す。“０１０”は、画像毎に時計回りに９０度回転して表示することを示す。“０１１”は、画像毎に反時計回りに９０度回転して表示することを示す。“１１０”は、グループピクチャ全体で時計回りに９０度回転して表示することを示す。“１１１”は、グループピクチャ全体で反時計回りに９０度回転して表示することを示す。この情報により、グループピクチャを構成する複数の画像を、サービス側が意図した回転状態で表示させることが可能となる。

図１６は、「display_coordinate」による表示時のローテーションの一例を示している。この例は、水平・垂直方向２次元多画像配置の例であって、グループピクチャが２×２の画像で構成される例である。図１６（ａ）は、「display_coordinate」が“１１０”である場合の例を示している。デコード画像に対して、表示画像はグループピクチャ全体が時計回りに９０度回転したものとなる。また、図１６（ｂ）は、「display_coordinate」が“０１０”である場合の例を示している。デコード画像に対して、表示画像は画像（ピクチャ）毎に時計回りに９０度回転したものとなる。

図１４に戻って、「group_picture_start」の１ビットフィールドは、ある時点で表示更新すべきグループピクチャの開始を示す。「group_picture_end」の１ビットフィールドは、ある時点で表示更新すべきグループピクチャの終了を示す。「PTD(Presentation Time Distance)」の８ビットフィールドは、グループピクチャに含まれる各画像を同時表示させるためのオフセット値である。つまり、この「ＰＴＤ」は、グループピクチャを構成する複数の画像の表示タイミングを調整するためのオフセット情報である。

グループピクチャを構成する画像(i)の表示タイミングＣＴＰ(i)は、ＰＴＤ(i)を用いて、以下の数式（１）に示すように、求めることができる。ここで、ＰＴＤ(max)は、「group_picture_start」と「group_picture_end」で挟まれた同一「group_picture_id」を有する画像の中で、最遅の表示タイミング（ＰＴＳ）を持つ画像に付せられるＰＴＤである。
ＣＴＰ(i)
＝ＰＴＳ(i)＋（ＰＴＤ(max)−ＰＴＤ(i)）＊システムクロック精度(90KHz)
・・・（１）

図１７は、グループピクチャを構成する各画像の表示タイミングＣＴＰの算出例を示している。この例は、図１７（ａ）に示すように、水平・垂直方向２次元多画像配置の例であって、グループピクチャが２×２の画像（Picture 1, Picture 2, Picture 3, Picture 4）で構成される例である。この場合、図１７（ｂ）に示すように、例えば、各画像のＰＴＳがＰ１，Ｐ２，Ｐ３，ｐ４であるのに対して、各画像のＰＴＤは１，２，３，４に設定される。ＰＴＤ(max)＝４である。

この場合、画像１（Picture 1）の表示タイミングＣＴＰ１は、“Ｐ１＋（４−１）＊１/９００００”と求められる。また、画像２（Picture 2）の表示タイミングＣＴＰ２は、“Ｐ２＋（４−２）＊１/９００００”と求められる。また、画像３（Picture 3）の表示タイミングＣＴＰ３は、“Ｐ３＋（４−３）＊１/９００００”と求められる。そして、画像４（Picture 4）の表示タイミングＣＴＰ４は、“Ｐ４＋（４−４）＊１/９００００＝Ｐ４”と求められる。なお、グループピクチャ内の各画像の表示タイミングをずらす場合には、各ＣＴＰの値を異なるように設定すればよい。

図１８は、グループ・ピクチャ・タグＳＥＩの各種情報の時間的変遷の一例を示している。図において、丸数字が付された矩形部分がアクセスユニットを示している。なお、「１」〜「４」の丸数字は、それぞれ、画像１（Picture 1）〜画像４（Picture 4）の符号化画像データが含まれていることを示している（図１７（ａ）参照）。

最初、「group_picture_id」が「１」である静止画の画像１（Picture 1）〜画像４（Picture 4）の符号化画像データが順に送信される。この場合、画像１（Picture 1）〜画像４（Picture 4）の符号化画像データには、「location_id」として「１」〜「４」が付されると共に、「version_number」として「１」が付され、さらに、「display_coordinate」として「０」が付されている。そして、この場合、画像１（Picture 1）の符号化画像データには「group_picture_start」によりグループピクチャのサービスが開始されることが示され、画像４（Picture 4）の符号化画像データには「group_picture_end」によりグループピクチャのサービスが終了したことが示される。

次に、画像２（Picture 2）の更新された符号化画像データが送信される。この場合、画像２（Picture 2）の符号化画像データには、「location_id」として「２」が付されると共に、「version_number」として「２」が付され、さらに、「display_coordinate」として「０」が付されている。そして、この場合、画像２（Picture 2）の符号化画像データには「group_picture_start」によりグループピクチャのサービスが開始されることが示されると共に、「group_picture_end」によりグループピクチャのサービスが終了したことが示される。

次に、画像２（Picture 2）のさらに更新された符号化画像データが送信される。この場合、画像２（Picture 2）の符号化画像データには、「location_id」として「２」が付されると共に、「version_number」として「３」が付され、さらに、「display_coordinate」として「０」が付されている。そして、この場合、画像２（Picture 2）の符号化画像データには「group_picture_start」によりグループピクチャのサービスが開始されることが示されると共に、「group_picture_end」によりグループピクチャのサービスが終了したことが示される。

次に、画像１（Picture 1）〜画像４（Picture 4）の更新された符号化画像データが順に送信される。この場合、画像１（Picture 1）〜画像４（Picture 4）の符号化画像データには、「location_id」として「１」〜「４」が付されると共に、「version_number」として「４」が付され、さらに、「display_coordinate」として「１」が付されている。そして、この場合、画像１（Picture 1）の符号化画像データには「group_picture_start」によりグループピクチャのサービスが開始されることが示され、画像４（Picture 4）の符号化画像データには「group_picture_end」によりグループピクチャのサービスが終了したことが示される。

図１９は、マルチ・ストリーム・サービス・デスクリプタ（multi_stream_service_descriptor）の構造例（Syntax）を示している。また、図２０は、その構造例における主要な情報の内容（Semantics）を示している。

「multi_stream_service_descriptor_tag」の８ビットフィールドは、デスクリプタタイプを示し、ここでは、マルチ・ストリーム・サービス・デスクリプタであることを示す。「multi_stream_service_descriptor_length」の８ビットフィールドは、デスクリプタの長さ（サイズ）を示し、デスクリプタの長さとして、以降のバイト数を示す。「multiple_stream_service_flag」の１ビットフィールドは、多重配信サービス、つまり、多画像配置の配信サービスであることを示すフラグである。“１”は多重配信サービスであることを示し、“０”は非多重配信サービスであることを示す。この情報により、受信側では、多画像配置の配信サービスであることを容易に認識でき、その処理のための準備を行うことが可能となる。

「moving_picture_still_picture_mixed_service」の１ビットフィールドは、静止画・動画混在サービスであることを示すフラグである。“１”は静止画・動画混在サービスであることを示し、“０”は非混在サービスであることを示す。「number_of_streams」の４ビットフィールドは、多重配信サービスに関与するストリームの総数を示す。“０００１”〜“１１１１”は、それぞれ、１ストリーム〜１５ストリームを示す。この情報により、受信側では、処理すべきビデオストリームの総数を容易に把握でき、適切な処理が可能となる。

図２１（ａ）は、ミックスト・ストリーム・デスクリプタ（mixed_stream_descriptor）の構造例（Syntax）を示している。また、図２１（ｂ）は、その構造例における主要な情報の内容（Semantics）を示している。

「mixed_stream_descriptor tag」の８ビットフィールドは、デスクリプタタイプを示し、ここでは、ミックスト・ストリーム・デスクリプタであることを示す。「mixed_stream_descriptor length」の８ビットフィールドは、デスクリプタの長さ（サイズ）を示し、デスクリプタの長さとして、以降のバイト数を示す。「service_stream_type」の２ビットフィールドは、ストリームのタイプを示す。“０１”は動画ストリームを示し、“１０”は静止画ストリームを示し、“１１”は静止画・動画混在ストリームを示す。この情報により、受信側では、ビデオストリームのストリームタイプを容易に把握でき、適切な処理を行うことが可能となる。

図２２（ａ）は、ピクチャ・ライフタイム・デスクリプタ（Picture_lifetime_descriptor）の構造例（Syntax）を示している。また、図２２（ｂ）は、その構造例における主要な情報の内容（Semantics）を示している。

「Picture_lifetime_descriptor tag」の８ビットフィールドは、デスクリプタタイプを示し、ここでは、ピクチャ・ライフタイム・デスクリプタであることを示す。「Picture_lifetime_descriptor length」の８ビットフィールドは、デスクリプタの長さ（サイズ）を示し、デスクリプタの長さとして、以降のバイト数を示す。「number_of_group_pictures」の１６ビットフィールドは、「group_picture_id」で識別されるグループピクチャの数を示す。「NTP」の６４ビットフィールドは、ＮＴＰ（Network Time Protocol)で規定されるクロック値を示すもので、グループピクチャごとに設定することができる。

図１に戻って、ネット配信サーバ１２０は、通信ネットワークを通じて、静止画、動画のリニアサービス、あるいは静止画、動画のダウンロードサービスを行う。ネット配信サーバ１２０は、ＩＰ配信データとして、例えばＭＰ４のコンテナを配信する。このＭＰ４は、上述の放送局１１０で取り扱ったトランスポートストリームと同様に、多画像配置の配信サービスに係る複数の画像（ピクチャ）の符号化画像データを含む、所定数のビデオストリームを有するものとされる。ネット配信サーバ１２０は、受信側からの再生コマンドに基づいて、ＭＰ４のＩＰパケットが連続的に配置された伝送ストリームを、通信ネットワークを通じて、受信側に送信する。

この場合、ビデオストリームのレイヤには、複数の画像の配置位置を示す位置情報の他、複数の画像の表示タイミングを調整するためのオフセット情報、多画像配置のタイプを示すタイプ情報、複数の画像の表示時のローテーションタイプを示すタイプ情報などが挿入されている。また、コンテナのレイヤ（システムレイヤ）に、多画像配置の配信サービスであることを示す識別情報、その配信サービスが動画静止画の混在サービスであるか否かを識別する識別情報、多画像配置の配信サービスに関与するビデオストリームの総数などが挿入されている。

図１に戻って、受信機２００は、チューナ２０１と、デマルチプレクサ２０２と、圧縮データバッファ（デコードバッファ）２０３と、デコーダ２０４と、非圧縮データバッファ（デコーデッドバッファ）２０５を有している。また、受信機２００は、仮想ディスプレイバッファ（ＶＰバッファ）２０６と、スケーラ２０７と、ディスプレイ（スクリーンデバイス）２０８と、ゲートウェイ／ネットワークルータ２０９と、ＣＰＵ（Central Processing Unit）２１０と、ユーザ操作部２１１を有している。

ＣＰＵ２１０は、受信機２００の各部の動作を制御する。ユーザは、ユーザ操作部２１１により種々の指示入力を行うことができる。このユーザ操作部２１１は、リモートコントロール部、近接/タッチにより指示入力を行うタッチパネル部、マウス、キーボード、カメラで指示入力を検出するジェスチャ入力部、音声で指示する音声入力部などである。

チューナ２０１は、送信側からＲＦ伝送路を通じて送られてくる放送波を受信し、ＲＦ復調を行って、放送配信多重化データとして、トランスポートストリームを得る。この実施の形態において、トランスポートストリームは、上述したように、多画像配置の配信サービスに係る複数の画像（ピクチャ）の符号化画像データを含む、所定数のビデオストリームを有するものである。

ゲートウェイ/ネットワークルータ部２０９は、配信サーバ１２０から通信ネットワークを通じて送られてくるＩＰパケット列を受信し、デパケット化を行って、ＩＰ配信データとしてのＭＰ４を得る。この実施の形態において、ＭＰ４は、上述のトランスポートストリームと同様に、多画像配置の配信サービスに係る複数の画像（ピクチャ）の符号化画像データを含む、所定数のビデオストリームを有するものである。

デマルチプレクサ２０２は、チューナ２０１で得られたトランスポートストリーム（放送配信多重化データ）、あるいはゲートウェイ/ネットワークルータ部２０９で得られたＭＰ４（ＩＰ配信データ）から、所定数のビデオストリームを抽出し、圧縮データバッファ２０３に一時的に蓄積する。この際、デマルチプレクサ２０２は、コンテナのレイヤに挿入されている種々の情報を抽出し、ＣＰＵ２１０に送る。この情報には、上述したように、多画像配置の配信サービスであることを示す識別情報、その配信サービスが動画静止画の混在サービスであるか否かを識別する識別情報、多画像配置の配信サービスに関与するビデオストリームの総数などが挿入されている。

なお、デマルチプレクサ２０２には、外部にある蓄積媒体２１２、例えばＨＤＤが接続されており、チューナ２０１で得られたトランスポートストリーム（放送配信多重化データ）、あるいはゲートウェイ/ネットワークルータ部２０９で得られたＭＰ４（ＩＰ配信データ）の記録再生が可能とされている。デマルチプレクサ２０２は、蓄積媒体２１２から再生データに対しても同様の処理が可能とされている。

デコーダ２０４は、圧縮データバッファ２０３に蓄積されている所定数のビデオストリームを所定のデコードタイミングで取り出し、復号化処理を施して、グループピクチャ（多画像配置画像）を構成する各画像の画像データを得、非圧縮データバッファ２０５に一時的に蓄積する。この際、デコーダ２０４は、ビデオストリームのレイヤに挿入されている種々の情報を抽出し、ＣＰＵ２１０に送る。この情報には、上述したように、各画像の配置位置を示す位置情報の他、各画像の表示タイミングを調整するためのオフセット情報、多画像配置のタイプを示すタイプ情報、各画像の表示時のローテーションタイプを示すタイプ情報などが挿入されている。

仮想ディスプレイバッファ２０６は、非圧縮データバッファ２０５に蓄積されているグループピクチャを構成する各画像の画像データを取得し、各画像に対応した領域に一時的に蓄積する。非圧縮データバッファ２０５から仮想ディスプレイバッファ２０６への読み出しは、例えば、ＰＴＳ（Presentation Time Stamp）に依存したタイミングで行われる（図１７のＣＴＰ参照）。

スケーラ２０７は、仮想ディスプレイバッファ２０６からグループピクチャの一部または全部の領域（表示領域）の画像データを読み出し、必要に応じて、スケーリング処理を施して、ディスプレイ２０８に送る。このスケーリングは、例えば、仮想ディスプレイバッファ２０６から読み出される表示領域の画像データの解像度を、ディスプレイ２０８の解像度に合わせるために行われる。

仮想ディスプレイバッファ２０６からの読み出しタイミング（表示タイミング）、さらには、表示領域の位置や大きさは、ユーザ操作部２１１から指定可能とされる。この場合、ユーザ操作部２１１から、画像表示を行うディスプレイ２０８の個数の指定も可能とされている。なお、図示ではディスプレイ２０８が一つだけ示されているが、複数のディスプレイ２０８を備えることが前提となる。

図２３は、仮想ディスプレイ（Virtual Display）上の画像と表示領域との関係の一例を示している。図示の例は、水平・垂直方向２次元多画像配置で、２×２個の画像Ｐ１〜Ｐ４でグループピクチャが構成されている。仮想ディスプレイに対して、ユーザ操作で設定された大きさの表示領域が、さらに、図示のように、ユーザ操作により、任意にその位置が変更可能とされる。この場合、ディスプレイ２０８には、仮想ディスプレイ上の画像Ｐ１〜Ｐ４のうち、表示領域に対応した画像のみが表示される。

なお、この場合、ＣＰＵ２１０の制御の下、ディスプレイ２０８に、あるいは図示しない別な表示素子に、仮想ディスプレイ上における現在の表示領域の位置および大きさが表示されてもよい。この表示により、ユーザは、仮想ディスプレイ上における表示領域の位置および大きさを容易に把握でき、表示領域の位置および大きさの指定を適切かつ効率よく行うことができる。

図２４（ａ）は、仮想ディスプレイ上における表示領域の位置および大きさの一例を示している。図２４（ｂ）は、それに対応した、ディスプレイ２０８に表示される位置インジケータ２５０の一例を示している。この位置インジケータ２５０は、仮想ディスプレイの全体を示す図形２５０ａと、その図形上に、表示領域の位置および大きさに対応して配置された現在の表示領域を示す矩形状図形２５０ｂとからなっている。

また、図２５も、仮想ディスプレイ（Virtual Display）上の画像と表示領域との関係の一例を示している。図示の例は、水平方向１次元多画像配置で、５個の画像Ｐ１〜Ｐ５でグループピクチャが構成されている。仮想ディスプレイに対して、ユーザ操作で設定された大きさの表示領域が、さらに、図示のように、ユーザ操作により、任意にその位置が変更可能とされる。この場合、ディスプレイ２０８には、仮想ディスプレイ上の画像Ｐ１〜Ｐ５のうち、表示領域に対応した画像のみが表示される。

図２６（ａ）は、仮想ディスプレイ上における表示領域の位置および大きさの一例を示している。図２６（ｂ）は、それに対応した、ディスプレイ２０８に表示される位置インジケータ２６０の一例を示している。この位置インジケータ２６０は、仮想ディスプレイの全体を示す図形２６０ａと、その図形上に、表示領域の中心位置に対応して配置された現在の表示領域の中心位置を示す棒状図形２６０ｂとからなっている。この場合も、表示領域の位置および大きさを矩形状図形で示すようにされてもよい。

図２７は、パノラマ画像を表示するためのディスプレイの構成例を示している。このディスプレイは、複数個、この例では３個の平面状（一点鎖線で示す）あるいは曲面状（実線で示す）のディスプレイ２０８が水平方向に連接されて構成されている。この場合、３個のディスプレイ２０８に、例えば、水平方向に連続した３つの画像が選択的に表示されることで、パノラマ画像の表示が可能となる。

図２８は、グループピクチャが水平方向に連続した７個の画像から構成されている場合における表示領域の指定例を示している。図２８（ａ）は、３つのディスプレイ２０８（例えば、図２７参照）にパノラマ画像の一部を表示するために、例えば３画像分の大きさで位置指定を行っていく例である。図２８（ｂ）は、１つのディスプレイ２０８にパノラマ画像の一部を表示するために、例えば１画像分の大きさで位置指定を行っていく例である。

図１に戻って、グループピクチャを構成する画像が静止画である場合、ユーザ操作に応じて、静止画の更新（update）が行われる。この場合、「location_id」と、「version_number」に従って、仮想ディスプレイバッファ２０６から、更新対象の画像の画像データが読み出されて、表示画像の更新がなされる。

例えば、上述の図１８に示すような配信例の場合を考える。この場合、最初、「version_number」が「１」である「location_id」が「１」〜「４」の４画像の画像データが仮想ディスプレイバッファ２０６から読み出されて静止画のグループピクチャが表示されているものとする。この状態で、ユーザの更新操作あると、仮想ディスプレイバッファ２０６からは「version_number」が「２」である「location_id」が「２」の画像の画像データが読み出され、当該画像の表示が更新される。

また、この状態で、ユーザの更新操作あると、仮想ディスプレイバッファ２０６からは「version_number」が「３」である「location_id」が「２」の画像の画像データが読み出され、当該画像の表示が再更新される。また、この状態で、ユーザの更新操作あると、「version_number」が「４」である「location_id」が「１」〜「４」の４画像の画像データが仮想ディスプレイバッファ２０６から読み出され、当該４画像の表示が更新される。

グループピクチャを構成する画像が静止画である場合、仮想ディスプレイバッファ２０６から画像データが読み出されてディスプレイ２０８に表示された後も、「lifetime_controlled」が“０”に設定されている場合には、ユーザによる解放指示が出されるまで、画像データは仮想ディスプレイバッファ２０６に残留する。一方、「lifetime_controlled」が“１”に設定されている場合には、システムレイヤ（コンテナのレイヤ）で指定されるＮＴＰ時刻が経過した後は、仮想ディスプレイバッファ２０６から該当するグループピクチャに属する画像データは自動的に削除される。

グループピクチャを構成する複数の画像の一部または全部が動画である場合、その動画の画像データは、ＰＴＳに依存したタイミングで非圧縮データバッファ２０５から仮想ディスプレイバッファ２０６に読み出された後、一定の時間内に読み出され、スケーラ２０７を介して、ディスプレイ２０８に送られる。この場合も、ユーザによって大きさおよび位置が指定された表示領域の画像データのみが読み出され、必要に応じて、スケーラ２０７によりサイズ変換（解像度変換）が行われる。

また、ユーザは、ユーザ操作部２１１からの画像回転操作により、ディスプレイ２０８の表示画像を、グループピクチャ全体で、あるいはグループピクチャを構成する画像毎に、回転可能とされる。なお、画像の回転は、基本的には、「display_coordinate」の情報により制御される。これにより、サービス側が意図した回転状態で表示させることが可能となる。しかし、ユーザの操作により、さらに、画像の回転が可能となっている。

また、ユーザは、ユーザ操作部２１１の操作により、ネット配信サーバ１２０に、再生コマンド、さらには、ポーズコマンド、レジューム（再開）コマンド、スキップコマンド、再生終了コマンドなどを送ることができる。また、例えば、仮想ディスプレイバッファ２０６がオーバフローする前に、例えば、ＣＰＵ２１０が、自動的に、ネット配信サーバ１２０にポーズコマンドを送り、その後、仮想ディスプレイバッファ２０６の容量に余裕ができた場合に、レジューム（再開）コマンドを送るということも行われる。

受信機２００の動作を簡単に説明する。最初に、受信機２００が放送波を受ける場合について説明する。チューナ２０１により、静止画リニアサービス、動画リニアサービスが受信され、トランスポートストリーム（放送配信多重化データ）が得られる。このトランスポートストリームは、デマルチプレクサ２０２に送られる。

デマルチプレクサ２０２では、トランスポートストリーム（放送配信多重化データ）から、所定数のビデオストリームが抽出され、圧縮データバッファ２０３に一時的に蓄積される。この際、デマルチプレクサ２０２では、コンテナのレイヤに挿入されている種々の情報が抽出され、ＣＰＵ２１０に送られる。なお、デマルチプレクサ２０２では、蓄積媒体２１２での記録再生を経たトランスポートストリーム（放送配信多重化データ）に対しても同様の処理がなされる。

デコーダ２０４では、圧縮データバッファ２０３に蓄積されている所定数のビデオストリームが所定のデコードタイミングで取り出され、復号化処理が施されて、グループピクチャ（多画像配置画像）を構成する各画像の画像データが得られ、非圧縮データバッファ２０５に一時的に蓄積される。この際、デコーダ２０４では、ビデオストリームのレイヤに挿入されている種々の情報が抽出され、ＣＰＵ２１０に送られる。

仮想ディスプレイバッファ２０６では、非圧縮データバッファ２０５に蓄積されているグループピクチャを構成する各画像の画像データが取得され、各画像に対応した領域に一時的に蓄積される。非圧縮データバッファ２０５から仮想ディスプレイバッファ２０６への読み出しは、例えば、ＰＴＳ（Presentation Time Stamp）に依存したタイミングで行われる。

このように仮想ディスプレイバッファ２０６に蓄積されたグループピクチャを構成する各画像の画像データのうち、ユーザが指定した位置および大きさの領域が、適宜なタイミングで読み出され、スケーラ２０７でサイズ（解像度）変換された後に、ディスプレイ２０８に送られる。これにより、ディスプレイ２０８には、グループピクチャのうちユーザが指定した表示領域の表示が行われる。

この場合、リニアサービスの動画データは、サービス受信から固定時間の遅延の後、表示へ至る。一方、静止画サービスにおいては、ユーザの嗜好による視聴時間の自由度があるため、ユーザからの表示内容の更新指示は不定期である。そのため、表示期間を含めて受信機２００内の遅延量は一定ではない。

仮想ディスプレイバッファ２０６は、その遅延時間と受信ストリームにおいて予め符号化配信されたタイミングとの違いを吸収する。仮想ディスプレイバッファ２０６がオーバフローする前に、リニアサービスの場合には、受信機２００は、受信ストリームを蓄積媒体２１２へ記録するか、あるいはサービス受信を一時中止するなどの判断を行う。

また、受信機２００が、放送波から動画あるいは静止画のダウンロードサービスを受ける際には、チューナ２０１経由のファイルは、一旦蓄積媒体２１２で蓄積され、あるいはデマルチプレクサ２０２から蓄積媒体２１２へ蓄積を行いながら、同時にデコーダ２０４においてデコードが行われ、仮想ディスプレイバッファ２０６でグループピクチャが構成され、表示へ至る。

次に、受信機２００がネット配信を受ける場合について説明する。ゲートウェイ/ネットワークルータ部２０９により、静止画リニアサービス、動画リニアサービスが受信され、ＭＰ４（ＩＰ配信データ）が得られる。このＭＰ４は、デマルチプレクサ２０２に送られる。

デマルチプレクサ２０２では、ＭＰ４（ＩＰ配信データ）から、所定数のビデオストリームが抽出され、圧縮データバッファ２０３に一時的に蓄積される。この際、デマルチプレクサ２０２では、コンテナのレイヤに挿入されている種々の情報が抽出され、ＣＰＵ２１０に送られる。なお、デマルチプレクサ２０２では、蓄積媒体２１２での記録再生を経たＭＰ４（ＩＰ配信データ）に対しても同様の処理がなされる。

デコーダ２０４では、圧縮データバッファ２０３に蓄積されている所定数のビデオストリームが所定のデコードタイミングで取り出され、復号化処理が施されて、グループピクチャ（多画像配置画像）を構成する各画像の画像データが得られ、非圧縮データバッファ２０５に一時的に蓄積される。この際、デコーダ２０４では、ビデオストリームのレイヤに挿入されている種々の情報が抽出され、ＣＰＵ２１０に送られる。

仮想ディスプレイバッファ２０６では、非圧縮データバッファ２０５に蓄積されているグループピクチャを構成する各画像の画像データが取得され、各画像に対応した領域に一時的に蓄積される。非圧縮データバッファ２０５から仮想ディスプレイバッファ２０６への読み出しは、例えば、ＰＴＳ（Presentation Time Stamp）に依存したタイミングで行われる。

このように仮想ディスプレイバッファ２０６に蓄積されたグループピクチャを構成する各画像の画像データのうち、ユーザが指定した位置および大きさの領域が、適宜なタイミングで読み出され、スケーラ２０７でサイズ（解像度）変換された後に、ディスプレイ２０８に送られる。これにより、ディスプレイ２０８には、グループピクチャのうちユーザが指定した表示領域の表示が行われる。

この場合、リニアサービスの動画データは、サービス受信から固定時間の遅延の後、表示へ至る。一方、静止画サービスにおいては、ユーザの嗜好による視聴時間の自由度があるため、ユーザからの表示内容の更新指示は不定期である。そのため、表示期間を含めて受信機２００内の遅延量は一定ではない。

仮想ディスプレイバッファ２０６は、その遅延時間と受信ストリームにおいて予め符号化配信されたタイミングとの違いを吸収する。仮想ディスプレイバッファ２０６がオーバフローする前に、リニアサービス（マルチキャスト）の場合には、受信機２００は、受信ストリームを蓄積媒体２１２へ記録するか、あるいはサービス受信を一時中止するなどの判断を行う。あるいは、瞬時にＶＯＤ(ユニキャストサービス）へ移行し、ＶＯＤ配信サーバに対して再生制御コマンド(再生開始、ポーズ、レジューム、ストップなど)を送信する。

受信機２００がネット配信から動画あるいは静止画のダウンロードサービスを受ける際には、ゲートウェイ/ネットワークルータ部２０９経由のファイルは、一旦蓄積媒体２１２で蓄積され、あるいはデマルチプレクサ２０２から蓄積媒体２１２へ蓄積を行いながら、同時にデコーダ２０４においてデコードが行われ、仮想ディスプレイバッファ２０６でグループピクチャが構成され、表示へ至る。

その際、受信機２００は、仮想ディスプレイバッファ２０６がオーバフローする前に、ダウンロード受信を一時的に中止し、後のタイミングで再開するように受信機設定を行う。ネット配信サービスでのダウンロード受信は、リニアサービスの受信と同様に、仮想ディスプレイバッファ２０６で吸収できない場合には、蓄積媒体２１２を利用し、あるいはＶＯＤ(ユニキャストサービス）へ移行し、ＶＯＤ配信サーバに対して再生制御コマンド(再生開始、ポーズ、レジューム、ストップなど)を送信する。

上述したように、図１に示す配信システム１０においては、多画像配置の配信サービスに係る複数の画像の符号化画像データを含む、所定数のビデオストリームを有する所定フォーマットのコンテナをＲＦ伝送路あるいは通信ネットワークを通じて受信側に送信する際に、ビデオストリームのレイヤに複数の画像の配置位置を示す位置情報（location_id）が挿入されるものである。そのため、例えば、受信側ではグループピクチャ（多画像配置画像）を構成する複数の画像の配置を効率よく、かつ適切に行うことが可能となる。

また、図１に示す配信システム１０においては、受信機２００では、デコード後のグループピクチャを構成する複数の画像の画像データが位置情報に基づいて配置されて、グループピクチャの画像データが得られるものである。そのため、例えば、グループピクチャの画像データを効率よく、かつ適切に得ることが可能となる。

＜２．変形例＞
なお、本技術は、ＭＰＥＧ−ＤＡＳＨベースの配信システムにも適用できる。図２９は、ＭＰＥＧ−ＤＡＳＨベースの配信システム１０Ａの構成例を示している。この配信システム１０Ａは、ＤＡＳＨセグメントストリーマ１１およびＤＡＳＨ ＭＰＤサーバ１２に、Ｎ個のＩＰＴＶクライアント１３-1，１３-2，・・・，１３-Nが、ＣＤＮ（Content Delivery Network）１４を介して、接続された構成となっている。

ＤＡＳＨセグメントストリーマ１１は、所定のコンテンツのメディアデータ（ビデオデータ、オーディオデータ、字幕データなど）に基づいて、ＤＡＳＨ仕様のストリームセグメント（以下、「ＤＡＳＨセグメント」という）を生成し、ＩＰＴＶクライアントからのＨＴＴＰ要求に応じてセグメントを送出する。このＤＡＳＨセグメントストリーマ１１は、ウェブ（Web）サーバである。

また、ＤＡＳＨセグメントストリーマ１１は、ＩＰＴＶクライアント１３（１３-1，１３-2，・・・，１３-N）からＣＤＮ１４を介して送られてくる所定ストリームのセグメントの要求に対応して、そのストリームのセグメントを、ＣＤＮ１４を介して、要求元のＩＰＴＶクライアント１３に送信する。

ＤＡＳＨ ＭＰＤサーバ１２は、ＤＡＳＨセグメントストリーマ１１において生成されるＤＡＳＨセグメントを取得するためのＭＰＤファイルを生成するサーバである。コンテンツマネジメントサーバ（図２９には図示せず）からのコンテンツメタデータと、ＤＡＳＨセグメントストリーマ１１において生成されたセグメントのアドレス（url）をもとに、ＭＰＤファイルを生成する。

ＭＰＤのフォーマットでは、ビデオやオーディオなどのそれぞれのストリーム毎にリプレゼンテーション（Representation）という要素を利用して、それぞれの属性が記述される。例えば、ＭＰＤファイルには、多画像配置の配信サービスに係る複数の画像の符号化データを含む、所定数のビデオストリーム毎に、リプレゼンテーションを分けて、記述される。また、ＭＰＤファイルには、その所定数のビデオストリームを常に読み込むことを示す情報が記述される。ＩＰＴＶクライアント１３は、多画像配置の配信サービスを受ける場合、このＭＰＤファイルの記述を参考にして、所定数のビデオストリームを取得する。

ＭＰＤファイルは、図３０に示すように、階層構造をとる。このＭＰＤファイルには、ＤＡＳＨセグメントストリーマ１１に格納した動画の圧縮方式や符号化速度、画像サイズ、言語などの情報がＸＭＬ形式で階層的に記述される。このＭＰＤファイルは、ピリオド（Period）、アダプテーションセット（Adaptation Set）、リプレゼンテーション（Representation）、セグメントインフォ（Segment Info）、イニシャライゼーション・セグメント（Initialization Segment）、メディア・セグメント（Media Segment）などの構造体が、階層的に含まれている。

ピリオドの構造体は、プログラム（同期を取った１組の動画や音声等のデータ）の情報を持つ。また、ピリオドの構造体に含まれるアダプテーションセットの構造体は、ストリームの選択範囲（リプレゼンテーション群）をグルーピングする。また、アダプテーションセットの構造体に含まれるリプレゼンテーションの構造体は、動画や音声の符号化速度、動画の音声サイズなどの情報を持つ。

また、リプレゼンテーションの構造体に含まれるセグメントインフォの構造体は、動画や音声のセグメント関連の情報を持つ。また、セグメントインフォの構造体に含まれるイニシャライゼーション・セグメントの構造体は、データ圧縮方式などの初期化情報を持つ。また、セグメントインフォの構造体に含まれるメディア・セグメントの構造体は、動画や音声のセグメントを取得するアドレスなどの情報を持つ。

図３１は、上述のＭＰＤファイルに階層的に配置されている各構造体の関係の一例を示している。図３１（ａ）に示すように、ＭＰＤファイル全体としてのメディア・プレゼンテーション（Media Presentation）には、時間間隔で区切られた複数のピリオド（Period）が存在する。例えば、最初のピリオドはスタートが０秒から、次のピリオドはスタートが１００秒から、などとなっている。

図３１（ｂ）に示すように、ピリオドには、複数のリプレゼンテーション（Representation）が存在する。この複数のリプレゼンテーションには、上述したアダプテーションセット（Adaptation Set）でグルーピングされる、例えば、多画像配置の配信サービスに係る複数の画像の符号化データを含む、所定数のビデオストリームに係るリプレゼンテーション群が存在する。

図３１（ｃ）に示すように、リプレゼンテーションには、セグメントインフォ（SegmentInfo）が含まれている。このセグメントインフォには、図３１（ｄ）に示すように、イニシャライゼーション・セグメント（Initialization Segment）と、ピリオドをさらに細かく区切ったセグメント（Segment）毎の情報が記述される複数のメディア・セグメント（Media Segment）が存在する。メディア・セグメントには、ビデオやオーディオなどのセグメントデータを実際に取得するためのアドレス(url)の情報等が存在する。

図３２は、コンテンツからＤＡＳＨセグメントやＤＡＳＨ ＭＰＤファイルを生成するまでのフローの一例を示している。コンテンツマネジメントサーバ１５からＤＡＳＨセグメントストリーマ１１にコンテンツが送付される。ＤＡＳＨセグメントストリーマ１１は、そのコンテンツを構成するビデオデータ、オーディオデータ等に基づいて、各データストリームのＤＡＳＨセグメントを生成する。

また、ＤＡＳＨセグメントストリーマ１１は、生成した各データストリームのＤＡＳＨセグメントのアドレス（url）の情報を、ＤＡＳＨ ＭＰＤサーバ１２に送付する。コンテンツマネジメントサーバ１５は、コンテンツのメタデータを、ＤＡＳＨ ＭＰＤサーバ１２に送付する。ＤＡＳＨ ＭＰＤサーバ１２は、各データストリームのＤＡＳＨセグメントのアドレス情報と、コンテンツのメタデータとに基づいて、ＤＡＳＨ ＭＰＤファイルを生成する。

図３３は、ＩＰＴＶクライアント１３（１３-1〜１３-N）の構成例を示している。ＩＰＴＶクライアント１３は、ストリーミングデータ制御部１３１と、ＨＴＴＰアクセス部１３２と、動画再生部１３３を有している。ストリーミングデータ制御部１３１は、ＤＡＳＨ ＭＰＤサーバ１２からＭＰＤファイルを取得し、その内容を解析する。

ＨＴＴＰアクセス部１３２は、動画再生に用いる動画や音声のセグメントをＤＡＳＨセグメントストリーマ１１に要求する。ここで、ＨＴＴＰアクセス部１３２は、多画像配置の配信サービスを受ける場合、ＭＰＤファイルの記述を参考にして、多画像配置の配信サービスに係る複数の画像の符号化データを含む、所定数のビデオストリームのセグメントを要求する。

ＨＴＴＰアクセス部１３２は、受け取った動画や音声のセグメントを動画再生部１３３に送る。動画再生部１３３は、ＨＴＴＰアクセス部１３２から送られてくる各セグメントに復号処理を施して、グループピクチャ（多画像配置画像）を構成する各画像の画像データおよびそれに付随する音声データなどを得て、画像や音声を再生する。なお、ＩＰＴＶクライアント１３の各部の処理は例えばソフトウェアにより行われる。

図３４は、一般的な、ＤＡＳＨベースのストリーム配信システムの系を示している。ＤＡＳＨ ＭＰＤファイルも、ＤＡＳＨセグメントも、全てＣＤＮ（Content Delivery Network）１４を介して配信される。ＣＤＮ１４は、複数のキャッシュサーバ（ＤＡＳＨキャッシュサーバ）がネットワーク配列された構成となっている。

キャッシュサーバは、ＩＰＴＶクライアント１３からのＭＰＤファイルの取得のためのＨＴＴＰリクエストを受ける。キャッシュサーバは、ローカルＭＰＤキャッシュにあれば、ＩＰＴＶクライアント１３にＨＴＴＰレスポンスとして返す。また、キャッシュサーバは、ローカルＭＰＤキャッシュになければ、そのリクエストをＤＡＳＨ ＭＰＤサーバ１２あるいは上位のキャッシュサーバに転送する。そして、キャッシュサーバは、ＭＰＤファイルの格納されたＨＴＴＰレスポンスを受け、ＩＰＴＶクライアント１３に転送すると共に、キャッシュ処理を行う。

また、キャッシュサーバは、ＩＰＴＶクライアント１３からのＤＡＳＨセグメント取得のＨＴＴＰリクエストを受ける。キャッシュサーバは、ローカルセグメントキャッシュにあれば、ＩＰＴＶクライアント１３にＨＴＴＰレスポンスとして返す。また、キャッシュサーバは、ローカルセグメントキャッシュになければ、そのリクエストをＤＡＳＨセグメントストリーマ１１あるいは上位のキャッシュサーバに転送する。そして、キャッシュサーバは、ＤＡＳＨセグメントの格納されたＨＴＴＰレスポンスを受け、ＩＰＴＶクライアント１３に転送すると共に、キャッシュ処理を行う。

ＣＤＮ１４では、最初にＨＴＴＰリクエストを発したＩＰＴＶクライアント１３-1へ配信されるＤＡＳＨセグメントが、経路のキャッシュサーバで一時的にキャッシュされ、後続の他のＩＰＴＶクライアント１３-2からのＨＴＴＰリクエストに対しては、そのキャッシュされたＤＡＳＨセグメントが配信される。そのため、大多数のＩＰＴＶクライアントに対するＨＴＴＰストリーミングの配信効率を向上させることができる。

ＣＤＮ１４は、複数のキャッシュサーバの他に、所定個数のキャッシュ管理サーバを有している。このキャッシュ管理サーバは、ＭＰＤファイルに含まれる各ビデオデータストリームのＤＡＳＨセグメントのキャッシュに関する指標に基づいて、キャッシュ制御ポリシーを作成し、各キャッシュサーバに配布する。各キャッシュサーバは、このキャッシュ制御ポリシーに基づいて、各ビデオデータストリームのＤＡＳＨセグメントのキャッシング処理を行う。

図３５は、FragmentedMP4ストリームの構成例を示している。ビデオのFragmentedMP4ストリームには、ビデオストリームをパケット化して得られたFragmentedMP4が含まれている。FragmentedMP4の「mdat」の部分にビデオストリームの所定ピクチャ分が挿入される。このビデオストリームには、上述実施の形態と同様に、アクセスユニット毎に、グループ・ピクチャ・タグＳＥＩ（Group_picture_tag SEI）メッセージが挿入される。そして、上述実施の形態と同様に、ＩＰＴＶクライアント１３では、例えば、グループピクチャを構成する各画像の位置情報（「location_id」）に基づいて、各画像の配置が効率よく、かつ適切に行われる。

なお、トランスポートストリームをそのままＤＡＳＨで送る場合もある。その場合には、マルチ・ストリーム・サービス・デスクリプタ（multi_stream_service_descriptor）、ミックスト・ストリーム・デスクリプタ（mixed_stream_descriptor）、ピクチャ・ライフタイム・デスクリプタ（Picture_lifetime_descriptor）が挿入されたトランスポートストリームがそのまま送られる。

図３６、図３７は、多画像配置の配信サービスにおけるＭＰＤファイルの記述例を示している。図３６の「Adaptation Set」の階層で、「parallelStream = “4”」の記述は、４つのストリームを常に読むことを示している。また、「frameRate = “0”」の記述はフレームレートが０であること、つまり静止画ストリームであることを示している。そして、図３７に示すように、４つのストリームにそれぞれ対応して、４つのリプレゼンテーション（Representation）が存在する。

このように、多画像配置の配信サービスの場合、ＭＰＤファイルに、多画像配置の配信サービスに係る複数の画像の符号化データを含む、所定数のビデオストリームを常に読むことが記述される。そのため、ＩＰＴＶクラインアント１３では、グループピクチャを構成する各画像の画像データ、したがってグループピクチャの画像を良好に得ることが可能となる。

また、本技術は、以下のような構成を取ることもできる。
（１）多画像配置の配信サービスに係る複数の画像の符号化画像データを含む、所定数のビデオストリームを有する所定フォーマットのコンテナを送信する送信部と、
上記ビデオストリームのレイヤに、上記複数の画像の配置位置を示す位置情報を挿入する情報挿入部とを備える
送信装置。
（２）上記情報挿入部は、上記複数の画像の表示タイミングを調整するためのオフセット情報を、上記ビデオストリームのレイヤにさらに挿入する
前記（１）に記載の送信装置。
（３）上記情報挿入部は、上記多画像配置のタイプを示すタイプ情報を、上記ビデオストリームのレイヤにさらに挿入する
前記（１）または（２）に記載の送信装置。
（４）上記情報挿入部は、上記複数の画像の表示時のローテーションタイプを示すタイプ情報を、上記ビデオストリームのレイヤにさらに挿入する
前記（１）から（３）のいずれかに記載の送信装置。
（５）上記情報挿入部は、上記複数の画像の表示可能な時間が制御されるか否かを示すライフタイム情報を、上記ビデオストリームのレイヤにさらに挿入する
前記（１）から（４）のいずれかに記載の送信装置。
（６）上記情報挿入部は、上記コンテナのレイヤに、上記多画像配置の配信サービスであることを識別する識別情報をさらに挿入する
前記（１）から（５）のいずれかに記載の送信装置。
（７）上記情報挿入部は、上記コンテナのレイヤに、上記多画像配置の配信サービスが、動画静止画の混在サービスであるか否かを識別する識別情報をさらに挿入する
前記（６）に記載の送信装置。
（８）上記情報挿入部は、上記コンテナのレイヤに、上記多画像配置の配信サービスに関与する上記ビデオストリームの総数の情報をさらに挿入する
前記（１）から（７）のいずれかに記載の送信装置。
（９）上記情報挿入部は、上記コンテナのレイヤに、上記各ビデオストリームが動画ストリームであるか、静止画ストリームであるか、あるいは静止画動画混在の混在ストリームであるかを示すタイプ情報をさらに挿入する
前記（１）から（８）のいずれかに記載の送信装置。
（１０）多画像配置の配信サービスに係る複数の画像の符号化データを含む、所定数のビデオストリームを有する所定フォーマットのコンテナを送信する送信ステップと、
上記ビデオストリームのレイヤに、上記複数の画像の配置位置を示す位置情報を挿入する情報挿入ステップとを有する
送信方法。
（１１）多画像配置の配信サービスに係る複数の画像の符号化画像データを含み、上記複数の画像の配置位置を示す位置情報が挿入されている所定数のビデオストリームを受信する受信部と、
上記所定数のビデオストリームをデコードして上記複数の画像の画像データを得るデコード部と、
上記デコード後の複数の画像の画像データを上記位置情報に基づいて配置して多画像配置画像の画像データを得る処理部とを備える
受信装置。
（１２）上記デコード部で得られた上記複数の画像の画像データを一時的に蓄積するデコーデッドバッファと、
上記多画像配置の画像データを一時的に蓄積する仮想ディスプレイバッファとをさらに備え、
上記処理部は、上記デコーデッドバッファから上記複数の画像の画像データを順次読み出し、上記仮想ディスプレイバッファの上記位置情報が示す配置位置に応じた領域に書き込む
前記（１１）に記載の受信装置。
（１３）上記仮想ディスプレイバッファから上記多画像配置画像の一部または全部の表示領域に対応した画像データを読み出し、該表示領域の画像を表示する表示制御部をさらに備える
前記（１２）に記載の受信装置。
（１４）上記表示制御部に上記表示領域を指示するユーザ操作部をさらに備える
前記（１３）に記載の受信装置。
（１５）上記表示制御部に上記表示領域の画像を表示するディスプレイの数を指示するユーザ操作部をさらに備える
前記（１４）に記載の受信装置。
（１６）上記所定数のビデオストリームの送信の停止および再開の要求を送信側に送る要求送信部をさらに備える
前記（１１）から（１５）のいずれかに記載の受信装置。
（１７）多画像配置の配信サービスに係る複数の画像の符号化データを含み、上記複数の画像の配置位置を示す位置情報が挿入されている所定数のビデオストリームを有する所定フォーマットのコンテナを受信する受信ステップと、
上記所定数のビデオストリームをデコードして上記複数の画像の画像データを得るデコードステップと、
上記デコード後の複数の画像の画像データを上記位置情報に基づいて配置して多画像配置画像の画像データを得る処理ステップとを有する
受信方法。
（１８）配信サーバがネットワークを通じて配信可能な多画像配置の配信サービスに係る複数の画像の符号化画像データを含む、所定数のビデオストリームをクライアント端末が取得するための情報を持つメタファイルを生成するメタファイル生成部と、
上記クライアント端末から送信要求があるとき、上記ネットワークを通じて、該クライアント端末に、上記生成されたメタファイルを送信するメタファイル送信部とを備え、
上記ビデオストリームのレイヤに、上記複数の画像の配置位置を示す位置情報が挿入されており、
上記メタファイル生成部は、上記メタファイルに、上記所定数のビデオストリームを常に読むことを示す情報を含める
送信装置。
（１９）上記メタファイル生成部は、上記メタファイルに、上記所定数のビデオストリームが静止画ストリームであるか動画ストリームであるかを識別する識別情報をさらに含める
前記（１８）に記載の送信装置。

本技術の主な特徴は、多画像配置の配信サービスに係る複数の画像の符号化画像データを含む、所定数のビデオストリームを有する所定フォーマットのコンテナをＲＦ伝送路あるいは通信ネットワークを通じて送信する際に、ビデオストリームのレイヤに複数の画像の配置位置を示す位置情報（location_id）を挿入することで、受信側ではグループピクチャ（多画像配置画像）を構成する複数の画像の配置を効率よく、かつ適切に行うことを可能にしたことである（図１８参照）。

１０，１０Ａ・・・配信システム
１１・・・ＤＡＳＨ セグメントストリーマ
１２・・・ＤＡＳＨ ＭＰＤサーバ
１３，１３-1〜１３-N・・・ＩＰＴＶクライアント
１４・・・ＣＤＮ
１５・・・コンテンツマネジメントサーバ
１１０・・・放送局
１１２・・・動画・静止画出力部
１１３・・・ビデオエンコーダ
１１４・・・マルチプレクサ
２００・・・受信機
２０１・・・チューナ
２０２・・・デマルチプレクサ
２０３・・・圧縮データバッファ
２０４・・・デコーダ
２０５・・・非圧縮データバッファ
２０６・・・仮想ディスプレイバッファ
２０７・・・スケーラ
２０８・・・ディスプレイ
２０９・・・ゲートウェイ/ネットワークルータ
２１０・・・ＣＰＵ
２１１・・・ユーザ操作部
２１２・・・蓄積媒体

Claims (19)

1. 多画像配置の配信サービスに係る複数の画像の符号化画像データを含む、所定数のビデオストリームを有する所定フォーマットのコンテナを送信する送信部と、
   上記所定数のビデオストリームのそれぞれに、上記所定数のビデオストリームからの画像によって形成された多画像配置画像における配置位置を示す位置情報を挿入する情報挿入部とを備える
   送信装置。
2. 上記情報挿入部は、上記複数の画像の表示タイミングを調整するためのオフセット情報を、上記ビデオストリームのレイヤにさらに挿入する
   請求項１に記載の送信装置。
3. 上記情報挿入部は、上記多画像配置のタイプを示すタイプ情報を、上記ビデオストリームのレイヤにさらに挿入する
   請求項１に記載の送信装置。
4. 上記情報挿入部は、上記複数の画像の表示時のローテーションタイプを示すタイプ情報を、上記ビデオストリームのレイヤにさらに挿入する
   請求項１に記載の送信装置。
5. 上記情報挿入部は、上記複数の画像の表示可能な時間が制御されるか否かを示すライフタイム情報を、上記ビデオストリームのレイヤにさらに挿入する
   請求項１に記載の送信装置。
6. 上記情報挿入部は、上記コンテナのレイヤに、上記多画像配置の配信サービスであることを識別する識別情報をさらに挿入する
   請求項１に記載の送信装置。
7. 上記情報挿入部は、上記コンテナのレイヤに、上記多画像配置の配信サービスが、動画静止画の混在サービスであるか否かを識別する識別情報をさらに挿入する
   請求項６に記載の送信装置。
8. 上記情報挿入部は、上記コンテナのレイヤに、上記多画像配置の配信サービスに関与する上記ビデオストリームの総数の情報をさらに挿入する
   請求項１に記載の送信装置。
9. 上記情報挿入部は、上記コンテナのレイヤに、上記各ビデオストリームが動画ストリームであるか、静止画ストリームであるか、あるいは静止画動画混在の混在ストリームであるかを示すタイプ情報をさらに挿入する
   請求項１に記載の送信装置。
10. 多画像配置の配信サービスに係る複数の画像の符号化データを含む、所定数のビデオストリームを有する所定フォーマットのコンテナを送信する送信ステップと、
    上記所定数のビデオストリームのそれぞれに、上記所定数のビデオストリームからの画像によって形成された多画像配置画像における配置位置を示す位置情報を挿入する情報挿入ステップとを有する
    送信方法。
11. 多画像配置の配信サービスに係る複数の画像の符号化画像データをそれぞれ含むと共に、位置情報がそれぞれ挿入されている所定数のビデオストリームを受信し、上記位置情報は上記所定数のビデオストリームからの画像によって形成された多画像配置画像における配置位置を示す受信部と、
    上記所定数のビデオストリームをデコードして上記所定数のビデオストリームの画像データを得るデコード部と、
    上記所定数のビデオストリームのデコードされた画像データを上記位置情報に基づいて配置して上記所定数のビデオストリームのデコードされた画像データを含む上記多画像配置画像の画像データを得る処理部とを備える
    受信装置。
12. 上記デコード部で得られた上記所定数のビデオストリームのデコードされた画像データを一時的に蓄積するデコーデッドバッファと、
    上記多画像配置の画像データを一時的に蓄積する仮想ディスプレイバッファとをさらに備え、
    上記処理部は、上記デコーデッドバッファから上記所定数のビデオストリームのデコードされた画像データを順次読み出し、上記仮想ディスプレイバッファの上記位置情報が示す配置位置に応じた領域に書き込む
    請求項１１に記載の受信装置。
13. 上記仮想ディスプレイバッファから上記多画像配置画像の一部または全部の表示領域に対応した画像データを読み出し、該一部または全部の画像の領域の画像を表示する表示制御部をさらに備える
    請求項１２に記載の受信装置。
14. 上記表示制御部に上記表示領域を指示するユーザ操作部をさらに備える
    請求項１３に記載の受信装置。
15. 上記表示制御部に上記表示領域の画像を表示するディスプレイの数を指示するユーザ操作部をさらに備える
    請求項１４に記載の受信装置。
16. 上記所定数のビデオストリームの送信の停止および再開の要求を送信側に送る要求送信部をさらに備える
    請求項１１に記載の受信装置。
17. 多画像配置の配信サービスに係る複数の画像の符号化データをそれぞれ含むと共に、位置情報がそれぞれ挿入されている所定数のビデオストリームを有する所定フォーマットのコンテナを受信し、上記位置情報は上記所定数のビデオストリームからの画像によって形成された多画像配置画像における配置位置を示す受信ステップと、
    上記所定数のビデオストリームをデコードして上記所定数のビデオストリーム画像データを得るデコードステップと、
    上記所定数のビデオストリームのデコードされた画像データを上記位置情報に基づいて配置して上記所定数のビデオストリームのデコードされた画像データを含む上記多画像配置画像の画像データを得る処理ステップとを有する
    受信方法。
18. 配信サーバがネットワークを通じて配信可能な多画像配置の配信サービスに係る複数の画像の符号化画像データを含む、所定数のビデオストリームをクライアント端末が取得するための情報を持つメタファイルを生成するメタファイル生成部と、
    上記クライアント端末から送信要求があるとき、上記ネットワークを通じて、該クライアント端末に、上記生成されたメタファイルを送信するメタファイル送信部とを備え、
    上記所定数のビデオストリームのそれぞれに、上記所定数のビデオストリームからの画像によって形成された多画像配置画像における配置位置を示す位置情報が挿入されており、
    上記メタファイル生成部は、上記メタファイルに、上記所定数のビデオストリームを常に読むことを示す情報を含める
    送信装置。
19. 上記メタファイル生成部は、上記メタファイルに、上記所定数のビデオストリームが静止画ストリームであるか動画ストリームであるかを識別する識別情報をさらに含める
    請求項１８に記載の送信装置。

Images