JP2014192565A - 映像処理装置、映像処理方法及びコンピュータプログラム - Google Patents

Abstract

【課題】複数の符号化ストリームを合成して再生する際に、全てのコンテンツでＧＯＰ構成を同一に保ちつつ、ＧＯＰ構成を変更することが可能な映像処理装置を提供する。
【解決手段】同一のコンテンツについて異なる条件で符号化された複数のストリームの内のいずれかを複数のコンテンツについて取得し、該ストリームが復号される前に合成する合成部と、各前記ストリームのピクチャ構成の情報を取得し、取得した前記ピクチャ構成の情報を用いて、前記合成部で合成される各前記ストリームのピクチャ構成が同一となるように各前記コンテンツに対する前記ストリームを選択するストリーム選択部と、を備える、映像処理装置が提供される。
【選択図】図２

Description

本開示は、映像処理装置、映像処理方法及びコンピュータプログラムに関する。

コンテンツのデジタル化が進み、映像を伝送できるインフラも整備されてきたことにより、インターネットを通じた映像配信が普及しつつある。最近では受信側の装置として、パーソナルコンピュータ以外に、ネットワークに接続可能なテレビジョン受像機も増えてきており、配信される動画コンテンツをテレビジョン受像機で見ることもできるようになってきている。

また、近年、クラウドサービスの発展により、ネットワークを介して、プライベートコンテンツを含めた多様なチャンネルが視聴者に提供されるようになってきている。そのため、複数の動画コンテンツを同時に視聴して、見たい動画コンテンツを簡単に探索することができるマルチ映像再生システムに対するニーズがより高くなってきている。

複数の動画コンテンツの同時視聴を実現するために、符号化ストリーム情報を用いてマルチ画面合成を行うシステムがある。サーバ側で圧縮された状態で保持される複数本の符号化ストリーム情報を、クライアント側で複雑な復号化処理をすることなく１本の符号化ストリーム情報へ変換する。符号化ストリーム情報を用いてマルチ画面合成を行うことにより、サーバ側の処理負荷、ネットワークの利用帯域、クライアント側の処理負荷を各々軽減する事が可能となる。

上述の符号化ストリーム情報を用いてマルチ画面合成を行う技術は、前提として全てのストリームにおいてＧＯＰ（Ｇｒｏｕｐ ｏｆ Ｐｉｃｔｕｒｅ）の構成が一致していることが求められている。既存の技術では、クライアントが受信する全てのコンテンツでＧＯＰの構成を同一に保ちつつ、ＧＯＰの構成を変更する仕組みは存在しておらず、上記事情に鑑みれば、全てのコンテンツでＧＯＰの構成を同一に保ちつつ、ＧＯＰの構成を変更する技術が求められていた。

そこで本開示は、符号化ストリーム情報を用いてマルチ画面合成を行う際に、全てのコンテンツでＧＯＰ構成を同一に保ちつつ、ＧＯＰ構成を変更することが可能な、新規かつ改良された映像処理装置、映像処理方法及びコンピュータプログラムを提供する。

本開示によれば、同一のコンテンツについて異なる条件で符号化された複数のストリームの内のいずれかを複数のコンテンツについて取得し、該ストリームが復号される前に合成する合成部と、各前記ストリームのピクチャ構成の情報を取得し、取得した前記ピクチャ構成の情報を用いて、前記合成部で合成される各前記ストリームのピクチャ構成が同一となるように各前記コンテンツに対する前記ストリームを選択するストリーム選択部と、を備える、映像処理装置が提供される。

また本開示によれば、同一のコンテンツについて異なる条件で符号化された複数のストリームの内のいずれかを複数のコンテンツについて取得し、該ストリームが復号される前に合成するステップと、各前記ストリームのピクチャ構成の情報を取得し、取得した前記ピクチャ構成の情報を用いて、前記合成するステップで合成される各前記ストリームのピクチャ構成が同一となるように各前記コンテンツに対する前記ストリームを選択するステップと、を備える、映像処理方法が提供される。

また本開示によれば、コンピュータに、同一のコンテンツについて異なる条件で符号化された複数のストリームの内のいずれかを複数のコンテンツについて取得し、該ストリームが復号される前に合成するステップと、各前記ストリームのピクチャ構成の情報を取得し、取得した前記ピクチャ構成の情報を用いて、前記合成するステップで合成される各前記ストリームのピクチャ構成が同一となるように各前記コンテンツに対する前記ストリームを選択するステップと、を実行させる、コンピュータプログラムが提供される。

以上説明したように本開示によれば、符号化ストリーム情報を用いてマルチ画面合成を行う際に、全てのコンテンツでＧＯＰ構成を同一に保ちつつ、ＧＯＰ構成を変更することが可能な、新規かつ改良された映像処理装置、映像処理方法及びコンピュータプログラムを提供することが出来る。

本開示の一実施形態に係る映像処理システム１の全体構成例を示す説明図である。 本開示の一実施形態に係る動画コンテンツサーバ２、３の機能構成例を示す説明図である。 本開示の一実施形態に係る動画コンテンツサーバ２、３の機能構成例を示す説明図である。 本開示の一実施形態に係るクライアント端末１００の機能構成例を示す説明図である。 ストリーム合成部１０５での複数の符号化ストリームの合成処理を説明する説明図である。 ストリーム合成部１０５での複数の符号化ストリームの合成処理を説明する説明図である。 ストリーム合成部１０５で複数の符号化ストリームが合成された後の符号化ストリームの状態を説明する説明図である。 本開示の一実施形態に係るクライアント端末１００の動作例を示す流れ図である。 本開示の一実施形態に係るクライアント端末１００の動作例を示す流れ図である。 本開示の一実施形態に係るクライアント端末１００の動作例を示す流れ図である。 本開示の一実施形態に係るクライアント端末１００の動作例を示す流れ図である。 本開示の一実施形態に係るクライアント端末１００の動作例を示す流れ図である。 クライアント端末１００が動画コンテンツサーバ２、３から取得するコンテンツ情報リストの例を示す説明図である。 ＭＰＤ（Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｉｓｃｒｉｐｔｉｏｎ）ファイルの一部分を抜き出して示す説明図である。 全動画コンテンツで共通するＧＯＰ構成をリスト化したものを示す説明図である。 他のコンテンツに無いＧＯＰ構成を有するコンテンツ情報リストを示す説明図である。 コンテンツ取得リストｃ１１の例を示す説明図である。 コンテンツ取得リストｃ１２の例を示す説明図である。 コンテンツ取得リストｃ１３の例を示す説明図である。 コンテンツ取得リストｃ１４の例を示す説明図である。 伝送状態判定部１０８の構成例を示す説明図である。 ＧＯＰ構成情報決定部１０９の構成例を示す説明図である。 各優先度における要求値と、各動画コンテンツで共通となるＧＯＰ構成との対応例を示す説明図である。 ＧＯＰ構成情報決定部１０９の構成例を示す説明図である。 レート情報決定部１１０の構成例を示す説明図である。

以下に添付図面を参照しながら、本開示の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。

なお、説明は以下の順序で行うものとする。
＜１．本開示の一実施形態＞
［全体構成例］
［動画コンテンツサーバの機能構成例］
［クライアント端末の機能構成例］
［クライアント端末の動作例］
＜２．まとめ＞

＜１．本開示の一実施形態＞
［全体構成例］
まず図面を参照しながら、本開示の一実施形態に係るシステムの全体構成例について説明する。図１は、本開示の一実施形態に係る映像処理システム１の全体構成例を示す説明図である。以下、図１を用いて本開示の一実施形態に係る映像処理システム１の全体構成例について説明する。

図１に示した映像処理システム１は、複数の動画コンテンツサーバ２、３から、符号化ストリーム情報を、インターネット等のネットワーク１０を経てクライアント端末１００で受信し、クライアント端末１００で複数の動画コンテンツを合成して同時に再生する構成を有している。

動画コンテンツサーバ２、３は、符号化ストリームに変換された動画コンテンツを保持し、また動画コンテンツを符号化ストリームに変換し、クライアント端末１００からの求めに応じてクライアント端末１００に送出する装置である。本実施形態では、動画コンテンツサーバ２は、動画コンテンツＡ及び動画コンテンツＢを保持している。動画コンテンツＡ、Ｂは、リアルタイムで撮像された動画コンテンツであってもよく、予め撮像された動画コンテンツであってもよい。また動画コンテンツサーバ３は、動画コンテンツＣ及び動画コンテンツＤを保持している。動画コンテンツＣ、Ｄは、リアルタイムで撮像された動画コンテンツであってもよく、予め撮像された動画コンテンツであってもよい。もちろん、動画コンテンツサーバに保持される動画コンテンツの種類や数は係る例に限られないことは言うまでもない。

本実施形態の符号化ストリームは、例えばＨ．２６４／ＡＶＣ（Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）方式等で符号化されたものであるとする。

クライアント端末１００は、動画コンテンツサーバ２、３からインターネット等のネットワーク１０を経て送信される符号化ストリームを受信し、複数の符号化ストリームを合成してからその合成後の符号化ストリームを復号する。クライアント端末１００は、複数の符号化ストリームを合成してから復号することで、複数の動画コンテンツを同時に再生することが出来る。なお、複数の動画コンテンツの同時再生は、クライアント端末１００が実行しても良いし、クライアント端末１００と有線または無線で接続された、表示画面を有する他の装置が実行しても良い。

クライアント端末１００が受信して合成し、再生する動画コンテンツは、いずれもＧＯＰ（Ｇｒｏｕｐ ｏｆ Ｐｉｃｔｕｒｅ）がＮであるとする。動画コンテンツのＧＯＰが同じであることで、クライアント端末１００は、複数の符号化ストリームを合成してからその合成後の符号化ストリームを復号することを可能としている。

しかし裏返せば、クライアント端末１００は、ＧＯＰの構成、すなわち、Ｉピクチャを少なくとも１枚含むピクチャの集合を構成するピクチャの数（ピクチャ構成）が異なる動画コンテンツを合成することが出来ない。

既存の技術で用いられるＡＶＣ符号化ストリーム情報においては、コンテンツのＧＯＰ構成は任意に決定する事ができる。また、このＧＯＰ構成は、コンテンツを提供するサーバ側において事前に決定されている場合が多い。そのような環境でＧＯＰ構成の選択を行うために利用可能な参考技術として、ＨＴＴＰ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ方式や、ＭＰＥＧ−ＤＡＳＨ（ＩＳＯ／ＩＥＣ ２３００９−１）等の技術が存在する。これらの技術は、クライアント側が必要とするコンテンツの解像度（大きさ）や、利用可能なネットワーク帯域幅に応じて、サーバから取得するコンテンツの選択を可能としている。

このような技術を用いて、コンテンツの解像度やレートの選択と同様に、ＧＯＰ構成を選択する構成を追加する事は技術的に容易である。しかし、既存の技術では、複数の符号化ストリームを合成してからその合成後の符号化ストリームを復号するマルチ画面合成を行うための条件である、同一のＧＯＰ構成を持つコンテンツを選択する仕組みが存在しなかった。

また、クライアントはサーバから受信する動画コンテンツのＧＯＰ構成を変更する事で動画コンテンツの最適な再生を行える場合がある。しかし、複数の符号化ストリームを合成してからその合成後の符号化ストリームを復号するマルチ画面合成を行う場合では、動画コンテンツのＧＯＰ構成の変更は容易ではなかった。

ＡＶＣ符号化ストリーム情報においては、コンテンツの圧縮率、パケットロス時のデコーダでの再生が復旧までの時間、動画コンテンツの切り替え速度などを考慮した場合、それぞれの状況に最適なＧＯＰ構成が存在する。

例えば、動画コンテンツのＧＯＰ構成を短くすると、ＩＤＲピクチャの出現間隔が短くなる。ＩＤＲピクチャの出現間隔が短くなると、動画コンテンツが消費するネットワーク帯域は大きくなる。一方、動画コンテンツのＧＯＰ構成を短くすると、クライアントが動画コンテンツの再生途中に他の動画コンテンツへ切り替えを行う場合に、Ｉピクチャの出現間隔が短いので、切り替え時間を短くする事が可能となる。

また、ネットワーク伝送にＵＤＰを使用した場合など、パケットロスがデコーダへ影響を与える環境においては、ＧＯＰ構成を短くする事で、パケットロスの発生から短時間で映像再生を再開する事が可能となる。

逆に、動画コンテンツのＧＯＰ構成を長くすると、ＩＤＲピクチャの出現間隔が長くなる。ＩＤＲピクチャの出現間隔が長くなると、動画コンテンツの符号化効率が上がる。そのため、利用できる帯域が同一の場合は、クライアントは、ＧＯＰ構成がより長い動画コンテンツの方が、良好に再生出来る。

本開示の一実施形態に係る映像処理システム１は、符号化ストリーム情報を用いてマルチ画面合成を行う際に、全てのコンテンツでＧＯＰ構成（ピクチャ構成）を同一に保ちつつ、ＧＯＰ構成を変更することを可能にするものである。

以上、図１を用いて本開示の一実施形態に係る映像処理システム１の全体構成例について説明した。次に、本開示の一実施形態に係る動画コンテンツサーバ２、３の機能構成例について説明する。

［動画コンテンツサーバの機能構成例］
本開示の一実施形態に係る動画コンテンツサーバ２、３は、上述したように、リアルタイム動画コンテンツと蓄積動画コンテンツとのいずれも保持し得る。そのため、リアルタイム動画コンテンツを配信する場合と蓄積動画コンテンツを配信する場合とで分けて、本開示の一実施形態に係る動画コンテンツサーバ２、３の機能構成例について説明する。

図２は、本開示の一実施形態に係る動画コンテンツサーバ２、３の機能構成例を示す説明図である。図２に示したのは、リアルタイム動画コンテンツを配信する場合の動画コンテンツサーバ１、２の機能構成例である。

図２に示したように、本開示の一実施形態に係る動画コンテンツサーバ２、３は、制御部１１と、処理済み符号化ストリーム蓄積部１２と、符号化ストリーム送出部１５と、ネットワーク送受信部１６と、を含んで構成される。

制御部１１は、動画コンテンツサーバ２、３の各要素の動作を制御する。処理済み符号化ストリーム蓄積部１２は、動画コンテンツを予め再符号化し、再符号化後の符号化ストリームを蓄積する。処理済み符号化ストリーム蓄積部１２に蓄積された、再符号化後の動画コンテンツの符号化ストリームは、制御部１１の制御により符号化ストリーム送出部１５に送られる。

Ｈ．２６４／ＡＶＣ方式の符号化ストリームは、ＣＡＢＡＣ（Ｃｏｎｔｅｘｔ−ｂａｓｅｄ Ａｄａｐｔｉｖｅ Ｂｉｎａｒｙ Ａｒｉｔｈｍｅｔｉｃ Ｃｏｄｉｎｇ）， Ｉｎｔｒａ ＭＢ（Ｍａｃｒｏ Ｂｌｏｃｋ；マクロブロック） Ｐｒｅｄｉｃｔｉｏｎ， Ｍｏｔｉｏｎ Ｖｅｃｔｏｒ Ｐｒｅｄｉｃｔｉｏｎ などにおいて、同一スライス内で依存関係を有する。また符号化は、上から水平ラインごとに行われ、各水平ラインにおいては左から行われる。

処理済み符号化ストリーム蓄積部１２は、動画コンテンツの符号化ストリームの、水平方向に並ぶマクロブロックが、同一のスライスとして再符号化されたものを蓄積する。水平方向に並ぶマクロブロックが同一のスライスとして再符号化されることにより、各動画コンテンツにおいて、垂直方向の位置が異なるマクロブロック間の依存関係がなくなる。そのため、複数の動画コンテンツの符号化ストリームをクライアント端末１００で合成することにより、マクロブロックの符号化順が異なる場合であっても、復号後のマルチ映像再生画像は、元の動画コンテンツと同一となる。

符号化ストリーム送出部１５は、制御部１１の制御により、処理済み符号化ストリーム蓄積部１２に蓄積された動画コンテンツの符号化ストリームを、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）やＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）等のプロトコルを用いて、ネットワーク送受信部１６から送出させる。

ネットワーク送受信部１６は、ネットワーク１０からのデータの受信やネットワーク１０へのデータの送信を行う。本実施形態では、ネットワーク送受信部１６は、制御部１１の制御により、符号化ストリーム送出部１５から送出される動画コンテンツの符号化ストリームを受けて、ネットワーク１０へ送出する。

図３は、本開示の一実施形態に係る動画コンテンツサーバ１、２の機能構成例を示す説明図である。図３に示したのは、例えばリアルタイム動画コンテンツを配信する場合の動画コンテンツサーバ２、３の機能構成例である。

図３に示したように、本開示の一実施形態に係る動画コンテンツサーバ２、３は、制御部１１と、処理前符号化ストリーム蓄積部１３と、符号化ストリーム変換部１４と、符号化ストリーム送出部１５と、ネットワーク送受信部１６と、を含んで構成される。

制御部１１は、動画コンテンツサーバ１、２の各要素の動作を制御する。処理前符号化ストリーム蓄積部１４は、上述の再符号化前の動画コンテンツの符号化ストリームを蓄積する。処理前符号化ストリーム蓄積部１４に蓄積された動画コンテンツの符号化ストリームは、制御部１１の制御により符号化ストリーム変換部１４に送られる。

符号化ストリーム変換部１４は、制御部１１の制御により、上述の動画コンテンツの符号化ストリームの再符号化を行う。符号化ストリーム変換部１４は、動画コンテンツの符号化ストリームの再符号化を行うと、再符号化後の動画コンテンツの符号化ストリームを制御部１１の制御により符号化ストリーム送出部１５に送る。

符号化ストリーム送出部１５は、制御部１１の制御により、符号化ストリーム変換部１４から送られた動画コンテンツの符号化ストリームを、ＴＣＰやＲＴＰ等のプロトコルを用いて、ネットワーク送受信部１６から送出させる。ネットワーク送受信部１６は、ネットワーク１０からのデータの受信やネットワーク１０へのデータの送信を行う。本実施形態では、ネットワーク送受信部１６は、制御部１１の制御により、符号化ストリーム送出部１５から送出される動画コンテンツの符号化ストリームを受けて、ネットワーク１０へ送出する。

本開示の一実施形態に係る動画コンテンツサーバ２、３は、図２、３に示したような構成を有することで、クライアント端末１００での複数の符号化ストリームの合成に適した符号化ストリームを、クライアント端末１００へ送信することができる。

本開示の一実施形態に係る動画コンテンツサーバ２、３は、同一の動画コンテンツに対してそれぞれ異なる条件で符号化されたファイルを保持し得る。すなわち、本開示の一実施形態に係る動画コンテンツサーバ２、３は、同一の動画コンテンツに対して、解像度、符号化レート、ＧＯＰ構成が異なるファイルを保持し得る。そして本開示の一実施形態に係る動画コンテンツサーバ２、３は、クライアント端末１００から要求された条件や、ネットワーク１０の状態に応じて、異なる条件で符号化されたファイルの中から１つのファイルを選択して、クライアント端末１００へストリーミング配信する。

以上、図２、３を用いて本開示の一実施形態に係る動画コンテンツサーバ２、３の機能構成例について説明した。次に、本開示の一実施形態に係るクライアント端末１００の機能構成例について説明する。

［クライアント端末の機能構成例］
図４は、本開示の一実施形態に係るクライアント端末１００の機能構成例を示す説明図である。図４に示したのは、動画コンテンツサーバ２、３から送信される符号化ストリームを単に合成して再生するための構成を有するクライアント端末１００の例である。以下、図４を用いて本開示の一実施形態に係るクライアント端末１００の機能構成例について説明する。

図４に示したように、本開示の一実施形態に係るクライアント端末１００は、制御部１０１と、ネットワーク送受信部１０２と、符号化ストリーム分別部１０３と、コンテンツバッファ部１０４ａ、１０４ｂ、１０４ｃ、・・・、１０４ｎと、ストリーム合成部１０５と、ＡＶＣデコード部１０６と、アプリケーション部１０７と、伝送状態判定部１０８と、ＧＯＰ構成情報決定部１０９と、レート情報決定部１１０と、を含んで構成される。

制御部１０１は、クライアント端末１００の各要素の動作を制御する。ネットワーク送受信部１０２は、ネットワーク１０からのデータの受信やネットワーク１０へのデータの送信を、制御部１０１の制御により行う。本実施形態では、ネットワーク送受信部１０２は、動画コンテンツサーバ２、３から送信される符号化ストリームを受信する。ネットワーク送受信部１０２は、受信した符号化ストリームを、制御部１０１の制御に応じて符号化ストリーム分別部１０３に出力する。ネットワーク送受信部１０２は、複数の符号化ストリームを同時に受信し得るので、複数の符号化ストリームが受信された場合は、これらの複数の符号化ストリームは後段の符号化ストリーム分別部１０３で分別される。

符号化ストリーム分別部１０３は、ネットワーク送受信部１０２が受信した符号化ストリームを、動画コンテンツ単位に分別する。上述のようにネットワーク送受信部１０２は、複数の符号化ストリームを同時に受信し得るので、複数の符号化ストリームが受信された場合に、符号化ストリーム分別部１０３は複数の符号化ストリームを動画コンテンツ単位に分別する。符号化ストリーム分別部１０３による符号化ストリームの動画コンテンツ単位への分別は、例えば受信した符号化ストリームに含まれるコンテンツを識別するための情報を参照することで行われ得る。符号化ストリーム分別部１０３は、符号化ストリームを動画コンテンツ単位に分別すると、分別した符号化ストリームを動画コンテンツ単位にコンテンツバッファ部１０４ａ、１０４ｂ、１０４ｃ、・・・、１０４ｎへ出力する。

コンテンツバッファ部１０４ａ、１０４ｂ、１０４ｃ、・・・、１０４ｎは、符号化ストリーム分別部１０３が動画コンテンツ単位に分別した符号化ストリームを、それぞれ動画コンテンツ単位で保持する。コンテンツバッファ部１０４ａ、１０４ｂ、１０４ｃ、・・・、１０４ｎにそれぞれ動画コンテンツ単位で保持された符号化ストリームは、ストリーム合成部１０５へ出力される。

ストリーム合成部１０５は、コンテンツバッファ部１０４ａ、１０４ｂ、１０４ｃ、・・・、１０４ｎにそれぞれ動画コンテンツ単位で保持された符号化ストリームを、制御部１０１の制御により取り出して合成する。ストリーム合成部１０５は、複数の動画コンテンツの符号化ストリームのスライスヘッダを書き換えて、複数の符号化ストリームを１つに合成する。ストリーム合成部１０５は、複数の符号化ストリームを１つに合成すると、合成後の符号化ストリームをＡＶＣデコード部１０６へ出力する。

ストリーム合成部１０５での合成処理の一例を示す。ストリーム合成部１０５は、複数の動画コンテンツの符号化ストリームから、スライスのＮＡＬ（Ｎｅｔｗｏｒｋ Ａｂｓｔｒａｃｔｉｏｎ Ｌａｙｅｒ）ユニットのデータ長Ｉとスライスのマクロブロック数ｓｘを認識する。そしてストリーム合成部１０５は、データ長Ｉおよびマクロブロック数ｓｘ、並びに再生画像内の複数の動画コンテンツの配置に基づいて、複数の動画コンテンツの符号化ストリームのスライスヘッダを書き換える。

またストリーム合成部１０５は、コンテンツバッファ部１０４ａ、１０４ｂ、１０４ｃ、・・・、１０４ｎから供給される複数の動画コンテンツそれぞれの符号化ストリームに含まれるＰＰＳ（Ｐｉｃｔｕｒｅ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）のＮＡＬユニットから、可逆符号化の方式を表す可逆符号化方式フラグを取得する。ここで、可逆符号化の方式としては、ＣＡＶＬＣ（Ｃｏｎｔｅｘｔ−Ａｄａｐｔｉｖｅ Ｖａｒｉａｂｌｅ Ｌｅｎｇｔｈ Ｃｏｄｉｎｇ）、または、ＣＡＢＡＣ（Ｃｏｎｔｅｘｔ−Ａｄａｐｔｉｖｅ Ｂｉｎａｒｙ Ａｒｉｔｈｍｅｔｉｃ Ｃｏｄｉｎｇ）がある。そして、可逆符号化方式フラグは、ＣＡＢＡＣを表す場合１であり、ＣＡＶＬＣを表す場合０である。

ストリーム合成部１０５は、可逆符号化方式フラグに基づいて、スライスヘッダが書き換えられた複数の動画コンテンツそれぞれの符号化ストリームのスライスデータに対して所定の処理を施す。そして、ストリーム合成部１０５は、再生画像内の複数の動画コンテンツの配置に基づいて、上述の所定の処理が施されたスライスデータと、書き換え後のスライスヘッダを含む動画コンテンツの符号化ストリームを合成することにより、複数の動画コンテンツを１つの画像として再生するための再生画像の符号化ストリームを生成する。

ＡＶＣデコード部１０６は、ストリーム合成部１０５で１つに合成された符号化ストリームを、制御部１０１の制御によりデコードする。ＡＶＣデコード部１０６は、ストリーム合成部１０５で１つに合成された符号化ストリームをデコードすることで、複数の動画コンテンツを１つの画像として再生するための再生画像を生成し、出力することができる。ＡＶＣデコード部１０６は、デコード後のデータをアプリケーション部１０７に出力する。

ここでストリーム合成部１０５での複数の符号化ストリームの合成処理について具体的に説明する。図５は、ストリーム合成部１０５での複数の符号化ストリームの合成処理を説明する説明図である。図５では、４つの動画コンテンツＡ〜Ｄの符号化ストリームの合成処理が例示されている。図５では、動画コンテンツＡのピクチャ番号ＰＮがｉのピクチャを、動画コンテンツＢのピクチャ番号ＰＮがｊのピクチャを、動画コンテンツＣのピクチャ番号ＰＮがｋのピクチャを、動画コンテンツＤのピクチャ番号ＰＮがｌのピクチャを、それぞれストリーム合成部１０５で合成する場合が例示されている。

４つの動画コンテンツＡ〜Ｄの符号化ストリームがストリーム合成部１０５で合成されると、スライス合成が完了した１つのピクチャとなって符号化ストリームがストリーム合成部１０５から出力される。１つのピクチャとなった符号化ストリームは、ＡＶＣデコード部１０６でデコードされることで、それぞれの動画コンテンツＡ〜Ｄのピクセル群となってＡＶＣデコード部１０６から出力される。

図６は、ストリーム合成部１０５での複数の符号化ストリームの合成処理を説明する説明図である。図６には、コンテンツバッファ部１０４ａ、１０４ｂ、１０４ｃ、１０４ｄも示されている。ストリーム合成部１０５は、複数の符号化ストリームを合成する際に、全ての符号化ストリームのＧＯＰの構成を揃える。すなわち、図６に示すように、合成単位のピクチャが同じ種類のピクチャ（ＩＤＲピクチャまたは非ＩＤＲピクチャ）となるように合成される。

図７は、ストリーム合成部１０５で複数の符号化ストリームが合成された後の符号化ストリームの状態を説明する説明図である。ストリーム合成部１０５で４つの動画コンテンツＡ〜Ｄの符号化ストリームがピクチャ単位で合成（スライス合成）されると、図７に示すように、合成後の符号化ストリームがピクチャ単位でストリーム合成部１０５から出力され、ＡＶＣデコード部１０６に送られる。

ＡＶＣデコード部１０６は、このようにピクチャの種類を合わせて、ストリーム合成部１０５から送られる合成後の符号化ストリームをデコードすることで、それぞれの動画コンテンツＡ〜Ｄのピクセル群を有する画像を生成することができる。

アプリケーション部１０７は、クライアント端末１００で実行されるアプリケーションを実行する。アプリケーション部１０７は、ＡＶＣデコード部１０６から出力されたデータを取得する。そしてアプリケーション部１０７は、制御部１０１の制御によって、デコードによって得られる画像を表示画面に表示したり、表示画面を有する別の装置へ転送したりし得る。

伝送状態判定部１０８は、動画コンテンツサーバ２、３からクライアント端末１００への動画コンテンツの伝送状態を判定する。伝送状態判定部１０８は、本開示の状況検知部の一例として機能する。具体的には、伝送状態判定部１０８は、コンテンツバッファ部１０４ａ、１０４ｂ、１０４ｃ、・・・、１０４ｎへのパケットロス率や流入レートを計測することで、伝送状態を判定する。伝送状態判定部１０８は、動画コンテンツサーバ２、３からクライアント端末１００への動画コンテンツの伝送状態を判定すると、その判定の結果を制御部１０１に送る。伝送状態判定部１０８の詳細な構成については後に詳述する。

ＧＯＰ構成情報決定部１０９は、ストリーム合成部１０５が合成しようとする、動画コンテンツサーバ２、３から配信される全ての動画コンテンツで同一となるようにＧＯＰ構成を決定する。ＧＯＰ構成情報決定部１０９は、本開示のストリーム選択部の一例として機能する。ＧＯＰ構成情報決定部１０９は、例えばクライアント端末１００のユーザによる設定や、伝送状態判定部１０８が判定した伝送状態に基づいて、全ての動画コンテンツで同一となるようにＧＯＰ構成を決定し得る。またＧＯＰ構成情報決定部１０９は、後述のレート情報決定部１１０が決定した動画コンテンツの配信レートで用意されているＧＯＰ構成の情報も用いて、ＧＯＰ構成を決定し得る。ＧＯＰ構成情報決定部１０９は、決定したＧＯＰ構成の情報を制御部１０１に送る。ＧＯＰ構成情報決定部１０９の詳細な構成については後に詳述する。

レート情報決定部１１０は、動画コンテンツサーバ２、３から配信される動画コンテンツの配信レートを決定する。レート情報決定部１１０は、例えばクライアント端末１００のユーザによる設定や、伝送状態判定部１０８が判定した伝送状態に基づいて、動画コンテンツサーバ２、３から配信される動画コンテンツの配信レートを決定する。レート情報決定部１１０は、決定した動画コンテンツの配信レートの情報を制御部１０１に送る。レート情報決定部１１０の詳細な構成については後に詳述する。

図１８は、伝送状態判定部１０８の構成例を示す説明図である。図１８に示したように、伝送状態判定部１０８は、パケットロス計測部１１１と、流入速度計測部１１２と、を含んで構成される。

パケットロス計測部１１１は、コンテンツバッファ部１０４ａ、１０４ｂ、１０４ｃ、・・・、１０４ｎに流入するデータのパケットロス率を算出して、各バッファのパケットロス率の情報を百分率で出力する。流入速度計測部１１２は、コンテンツバッファ部１０４ａ、１０４ｂ、１０４ｃ、・・・、１０４ｎに流入するデータの流入レートを算出して、各バッファへの流入レートの情報をｂｐｓの単位で出力する。

本開示の一実施形態に係るクライアント端末１００は、図４に示したような構成を有することで、符号化ストリーム情報を用いてマルチ画面合成を行う際に、全てのコンテンツでＧＯＰ構成を同一に保ちつつ、ＧＯＰ構成を変更することが可能になる。

以上、本開示の一実施形態に係るクライアント端末１００の機能構成例について説明した。続いて、本開示の一実施形態に係るクライアント端末１００の動作例について説明する。

［クライアント端末の動作例］
図８〜図１０Ｂは、本開示の一実施形態に係るクライアント端末１００の動作例を示す流れ図である。図８〜図１０Ｂに示したのは、クライアント端末１００が、動画コンテンツサーバ２、３から複数の符号化ストリームを受信し、ピクチャを合成して符号化することで、複数の動画コンテンツを同時に再生する際の処理である。また図８〜図１０Ｂに示したのは、複数の動画コンテンツを同時に再生している際にＧＯＰ構成を変更する処理である。以下、図８〜図１０Ｂを用いて、本開示の一実施形態に係るクライアント端末１００の動作例について説明する。

クライアント端末１００は、動画コンテンツサーバ２、３から複数の符号化ストリームを受信する際に、動画コンテンツサーバ２、３が保持するコンテンツの情報をコンテンツ情報リストとして取得する（ステップＳ１０１）。

図１１Ａは、クライアント端末１００が動画コンテンツサーバ２、３から取得するコンテンツ情報リストの例を示す説明図である。図１１Ａには、４つのコンテンツＡ、Ｂ、Ｃ、Ｄについて、それぞれ解像度情報、レート情報、ＧＯＰ構成情報、コンテンツＵＲＬが記述されたコンテンツ情報リストの例が示されている。

例えばコンテンツＡを例に説明すれば、解像度はいずれも横６４０×縦４８０であるが、レートは１Ｍｂｐｓまたは２Ｍｂｐｓ、ＧＯＰ構成は３０、１００、１２０、３００のいずれかであるファイルが用意されていることがコンテンツ情報リストに示されている。

図１１Ａに示したコンテンツ情報リストについては、ＨＴＴＰ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ方式や、ＭＰＥＧ−ＤＡＳＨ（ＩＳＯ／ＩＥＣ ２３００９−１）等を用いても、同内容の表現が技術的に可能である。

図１１Ｂは、ＭＰＥＧ−ＤＡＳＨ（ＩＳＯ／ＩＥＣ ２３００９−１）を用いた場合に、配信されるコンテンツの内容を管理するＭＰＤ（Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｉｓｃｒｉｐｔｉｏｎ）ファイルの一部分を抜き出して示す説明図である。図１１Ｂに示したのは、ＭＰＤファイルの内、動画圧縮方式、画像サイズ、符号化レート、ＧＯＰ構成、ファイルの格納場所が記述された部分を抜き出したものである。

動画コンテンツサーバ２、３は、図１１Ｂに示したように記述されるＭＰＤファイルを、予め保持しておく。クライアント端末１００が動画コンテンツの配信を要求すると、動画コンテンツサーバ２、３は、図１１Ｂに示したように記述されるＭＰＤファイルをクライアント端末１００に提供する。クライアント端末１００は、図１１Ｂに示したように記述されるＭＰＤファイルを動画コンテンツサーバ２、３から取得することで、配信を受ける動画コンテンツの動画圧縮方式、画像サイズ、符号化レート、ＧＯＰ構成、ファイルの格納場所を知ることが出来る。そしてクライアント端末１００は、ＭＰＤファイルを取得して、ストリーム合成部１０５が合成しようとする全ての動画コンテンツで同一のＧＯＰ構成となるようにＧＯＰ構成をＧＯＰ構成情報決定部１０９で決定する事が出来る。

なお本実施形態では、動画コンテンツサーバ２、３は、あらかじめ決められたＧＯＰ構成を有する動画コンテンツを有しているとしたが、本開示は係る例に限定されない。例えば、ＧＯＰ構成が５０と２００しか無い場合に、ＧＯＰ構成が１００の動画コンテンツをクライアント端末１００が要求してきたときは、動画コンテンツサーバ２、３は、あらかじめ用意している動画コンテンツのＧＯＰ構成を変換して、ＧＯＰ構成が１００の動画コンテンツを動的に生成してもよい。動画コンテンツサーバ２、３がクライアント端末１００へ提供するＧＯＰ構成情報には、提供できるＧＯＰ構成の範囲が記述されてもよい。

上記ステップＳ１０１で動画コンテンツサーバ２、３が保持するコンテンツの情報をコンテンツ情報リストとして取得すると、続いてクライアント端末１００は、取得したコンテンツ情報リストを参照し、各動画コンテンツで共通となるＧＯＰ構成を決定する（ステップＳ１０２）。

例えば、図１１Ａに示したようなコンテンツ情報リストを動画コンテンツサーバ２、３から取得できた場合は、クライアント端末１００は、コンテンツＡ〜Ｄに共通するＧＯＰ構成は、３０、１００、３００の３つであることを、例えばＧＯＰ構成情報決定部１０９で知ることが出来る。図１２は、図１１Ａに示したようなコンテンツ情報リストが取得できた場合に、動画コンテンツＡ〜Ｄに共通するＧＯＰ構成をリスト化したものを示す説明図である。ＧＯＰ構成情報決定部１０９は、図１２に示すような、全コンテンツで一致するＧＯＰ構成情報リストｇ１１を、コンテンツ情報リストから生成することが出来る。

クライアント端末１００は、他のコンテンツに無いＧＯＰ構成の情報をコンテンツ情報リストから破棄しても良い。図１３は、他のコンテンツに無いＧＯＰ構成を有するコンテンツ情報リストを示す説明図である。図１３に示したＧＯＰ構成は、いずれも他のコンテンツには無いものであるため、その後のＧＯＰ構成の変更処理では使用できないものである。従って、クライアント端末１００は、図１３に示した情報をコンテンツ情報リストから破棄しても良い。

上記ステップＳ１０２で、各動画コンテンツで共通となるＧＯＰ構成を決定すると、続いてクライアント端末１００は、その初期ＧＯＰ構成として、たとえばユーザの好みやアプリケーションの指針に従って、共通となるＧＯＰ構成の中から１つ選択する。

図１９は、ＧＯＰ構成情報決定部１０９の構成例を示す説明図である。図１９に示したＧＯＰ構成情報決定部１０９は、コンテンツの切り替えの早さを優先したり、パケットロス等のエラー状態からの早い復旧を優先したりするために、各動画コンテンツで共通となるＧＯＰ構成の中から１つのＧＯＰ構成を、簡単な指標から選択する仕組みを有する。

図１９に示したＧＯＰ構成情報決定部１０９は、ＧＯＰ構成情報対応テーブル１２１を有する。ＧＯＰ構成情報対応テーブル１２１には、図１２に示したような、全コンテンツで一致するＧＯＰ構成情報リストｇ１１が格納される。そしてＧＯＰ構成情報対応テーブル１２１は、ＧＯＰ構成情報リストｇ１１に、図１９に示した各優先度における要求値を対応付けて格納する。

図２０は、図１９に示した各優先度における要求値と、各動画コンテンツで共通となるＧＯＰ構成との対応例を示す説明図である。図２０に示した例では、各要求値が０〜３３の場合はＧＯＰ構成が３００に、３４〜６６の場合はＧＯＰ構成が１００に、６７〜１００の場合はＧＯＰ構成が３０に、それぞれマッピングされている状態が示されている。もちろん、各優先度における要求値と、各動画コンテンツで共通となるＧＯＰ構成との対応関係は、係る例に限定されるものではない。

例えば、コンテンツの切り替えを早く行うために、クライアント端末１００のユーザがコンテンツ切り替え優先度に１００を指定すると、優先度１００という指定から、ＧＯＰ構成情報決定部１０９は、ＧＯＰ構成として３０を決定することが出来る。またエラー後の復旧の早さを優先する優先度という別の尺度からも同様に、ＧＯＰ構成情報決定部１０９はＧＯＰ構成を決定すること出来る。

コンテンツ切り替え優先度は、アプリケーション部１０７で実行されるアプリケーションが指定してもよい。またコンテンツ切り替え優先度は、時間とともに値が低下するものであってもよい。

エラー復旧の優先度は、アプリケーション部１０７で実行されるアプリケーションが指定してもよい。またエラー復旧の優先度は、コンテンツバッファ部１０４ａ、１０４ｂ、１０４ｃ、・・・、１０４ｎそれぞれのパケットロス率に基づいて決まるものであってもよい。

図２１は、ＧＯＰ構成情報決定部１０９の構成例を示す説明図である。図２１に示したのは、伝送状態判定部１０８が計測したコンテンツバッファ部１０４ａ、１０４ｂ、１０４ｃ、・・・、１０４ｎそれぞれのパケットロス率に基づいてエラー復旧の優先度を出力するためのＧＯＰ構成情報決定部１０９の構成例である。

図２１に示したように、ＧＯＰ構成情報決定部１０９は、ＧＯＰ変更判定部１２２を含む。ＧＯＰ変更判定部１２２は、伝送状態判定部１０８が計測したコンテンツバッファ部１０４ａ、１０４ｂ、１０４ｃ、・・・、１０４ｎそれぞれのパケットロス率を受け取り、そのパケットロス率に基づいてエラー復旧の優先度を０〜１００の間で決定する。

例えば、ＧＯＰ変更判定部１２２は、コンテンツバッファ部１０４ａ、１０４ｂ、１０４ｃ、・・・、１０４ｎそれぞれのパケットロス率を受け取り、さらに平均ビットレートや１つのＨＬＳ（ＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇ）セグメントの受信からエラー復旧の優先度を０〜１００の間で決定する。

クライアント端末１００は、初期ＧＯＰ構成を決定すると、続いて、ＧＯＰ構成を変更するための初期設定を実行する。図８に示した例では、クライアント端末１００は、ＧＯＰ構成を変更するための指標としてパケットロス率の閾値を設定する（ステップＳ１０３）。パケットロス率の閾値は、ＧＯＰ構成を上昇、または下降させるための閾値である。クライアント端末１００は、パケットロス率の閾値として２つの値を指定してもよい。パケットロス率の閾値として２つの値を指定することで、クライアント端末１００は、ＧＯＰ構成を上昇、または下降させる動作にヒステリシスを持たせることが出来る。

クライアント端末１００は、ＧＯＰ構成を変更するための指標としてパケットロス率の閾値を設定すると、続いて各動画コンテンツを取得する際の初期段階でのコンテンツレートを決定する（ステップＳ１０４）。ステップＳ１０４でのコンテンツレートの決定はレート情報決定部１１０が決定し得る。各動画コンテンツを取得する際の初期段階のように、利用可能なネットワーク帯域が不明な段階においては、値が一番低いものをコンテンツレートの初期値として選択することが多くの場合において妥当である。

ステップＳ１０１〜Ｓ１０４の処理には、図１１Ａに示したようなコンテンツ情報リストが用いられる。クライアント端末１００は、この後の処理についても、図１１Ａに示したようなコンテンツ情報リストを用いる。

各動画コンテンツを取得する際の初期段階でのコンテンツレートを決定すると、続いてクライアント端末１００は、各コンテンツについて指定された初期のコンテンツ取得リストを作成する（ステップＳ１０５）。コンテンツ取得リストは、例えば制御部１０１が作成し得る、

図１４は、コンテンツ取得リストｃ１１の例を示す説明図である。例えば、ステップＳ１０１〜Ｓ１０４の処理によって、各コンテンツのＧＯＰ構成とコンテンツレートが、図１１の画面ｖ１１の様に決定されたとする。クライアント端末１００は、この決定に基づいて、図１１Ａに示したようなコンテンツ情報リストから、図１４に示すコンテンツ取得リストｃ１１を作成する。

各コンテンツについて指定された初期のコンテンツ取得リストｃ１１を作成すると、続いてクライアント端末１００は、このコンテンツ取得リストｃ１１に基づいて、動画コンテンツサーバ２、３から動画コンテンツの取得を要求する（ステップＳ１０６）。

コンテンツ取得リストに基づいて、動画コンテンツサーバ２、３から動画コンテンツの取得を要求すると、動画コンテンツサーバ２、３から、その要求に基づいて動画コンテンツの符号化ストリームが配信される。クライアント端末１００は、動画コンテンツサーバ２、３から配信される符号化ストリームを受信して、コンテンツバッファ部１０４ａ、１０４ｂ、１０４ｃ、・・・、１０４ｎに格納する。そしてクライアント端末１００は、デコード実行のタイミングかどうか判断し（ステップＳ１０７）、デコード実行のタイミングであれば、コンテンツバッファ部１０４ａ、１０４ｂ、１０４ｃ、・・・、１０４ｎからピクチャデータを取り出して（ステップＳ１０８）、合成後にデコードを実行する（ステップＳ１０９）。

クライアント端末１００は、動画コンテンツサーバ２、３から動画コンテンツの取得を開始すると、コンテンツバッファ部１０４ａ、１０４ｂ、１０４ｃ、・・・、１０４ｎへの符号化ストリームの流入レートを計測する（ステップＳ１１０）。またクライアント端末１００は、コンテンツバッファ部１０４ａ、１０４ｂ、１０４ｃ、・・・、１０４ｎに流入するデータのパケットロス率を算出する（ステップＳ１１１）。流入レートの計測及びパケットロス率の算出は、伝送状態判定部１０８が実行する。

コンテンツバッファ部１０４ａ、１０４ｂ、１０４ｃ、・・・、１０４ｎへの符号化ストリームの流入レート及びコンテンツバッファ部１０４ａ、１０４ｂ、１０４ｃ、・・・、１０４ｎに流入するデータのパケットロス率を算出すると、続いてクライアント端末１００は、ある一定期間、特定のコンテンツバッファ部１０４ａ、１０４ｂ、１０４ｃ、・・・、１０４ｎのパケットロス率が、上記ステップＳ１０３で設定した閾値を上回るかどうか判定する（ステップＳ１１２）。係る判定は、伝送状態判定部１０８が行い得る。

上記ステップＳ１１２の判定の結果、ある一定期間、パケットロス率が閾値を上回っていれば、クライアント端末１００はＧＯＰ変更処理を実行する（ステップＳ１１３）。このステップＳ１１３でクライアント端末１００が実行するのは、現在のＧＯＰ構成より短い（ｓｈｏｒｔ）ものに変更するＧＯＰ変更処理である。

ステップＳ１１３でＧＯＰ変更処理を実行すると、クライアント端末１００は、処理対象のコンテンツバッファ部１０４ａ、１０４ｂ、１０４ｃ、・・・、１０４ｎのパケットロス率をリセットする（ステップＳ１１４）。

一方、上記ステップＳ１１２の判定の結果、ある一定期間、パケットロス率が閾値を上回っていなければ、続いてクライアント端末１００は、ある一定期間、特定のコンテンツバッファ部１０４ａ、１０４ｂ、１０４ｃ、・・・、１０４ｎのパケットロス率が、上記ステップＳ１０３で設定した閾値を下回るかどうか判定する（ステップＳ１１５）。係る判定は、伝送状態判定部１０８が行い得る。

上記ステップＳ１１５の判定の結果、ある一定期間、パケットロス率が閾値を上回っていれば、クライアント端末１００はＧＯＰ変更処理を実行する（ステップＳ１１６）。このステップＳ１１３でクライアント端末１００が実行するのは、現在のＧＯＰ構成より長い（ｌｏｎｇ）ものに変更するＧＯＰ変更処理である。

ステップＳ１１６でＧＯＰ変更処理を実行すると、クライアント端末１００は、処理対象のコンテンツバッファ部１０４ａ、１０４ｂ、１０４ｃ、・・・、１０４ｎのパケットロス率をリセットする（ステップＳ１１７）。

一方、上記ステップＳ１１５の判定の結果、ある一定期間、パケットロス率が閾値を下回っていなければ、続いてクライアント端末１００は、コンテンツバッファ部１０４ａ、１０４ｂ、１０４ｃ、・・・、１０４ｎの中に、ある一定期間、流入レートがコンテンツ取得リストのレート情報未満のものがあるかどうか判定する（ステップＳ１１８）。係る判定は、伝送状態判定部１０８が行い得る。

上記ステップＳ１１８の判定の結果、ある一定期間、流入レートがコンテンツ取得リストのレート情報未満のものがあれば、クライアント端末１００はレート変更処理を実行する（ステップＳ１１９）。流入レートがコンテンツ取得リストのレート情報未満ということは、クライアント端末１００は、動画コンテンツサーバ２、３で指定されているレートよりも低いレートでしか符号化ストリームを受信できていないことを意味している。従って、このステップＳ１１９でクライアント端末１００が実行するのは、現在のレートより低いものに変更（ｄｏｗｎ）するレート変更処理である。

ステップＳ１１９でレート変更処理を実行すると、クライアント端末１００は、処理対象のコンテンツバッファ部１０４ａ、１０４ｂ、１０４ｃ、・・・、１０４ｎの流入レートをリセットする（ステップＳ１２０）。

一方、上記ステップＳ１１８の判定の結果、ある一定期間、流入レートがコンテンツ取得リストのレート情報未満のものがなければ、続いてクライアント端末１００は、コンテンツバッファ部１０４ａ、１０４ｂ、１０４ｃ、・・・、１０４ｎの中に、ある一定期間、流入レートがコンテンツ取得リストのレート情報以上のものがあるかどうか判定する（ステップＳ１２１）。係る判定は、伝送状態判定部１０８が行い得る。

上記ステップＳ１２１の判定の結果、ある一定期間、流入レートがコンテンツ取得リストのレート情報以上のものがあれば、クライアント端末１００はレート変更処理を実行する（ステップＳ１２２）。流入レートがコンテンツ取得リストのレート情報以上ということは、クライアント端末１００は、動画コンテンツサーバ２、３で指定されているレートよりも高いレートで符号化ストリームを受信できていることを意味している。従って、このステップＳ１２２でクライアント端末１００が実行するのは、現在のレートより高いものに変更（ｕｐ）するレート変更処理である。

ステップＳ１２２でレート変更処理を実行すると、クライアント端末１００は、処理対象のコンテンツバッファ部１０４ａ、１０４ｂ、１０４ｃ、・・・、１０４ｎの流入レートをリセットする（ステップＳ１２３）。

一方、上記ステップＳ１２１の判定の結果、ある一定期間、流入レートがコンテンツ取得リストのレート情報以上のものがなければ、続いてクライアント端末１００は、ユーザからの要求や、アプリケーション部１０７が実行するアプリケーションからの要求などにより、コンテンツ切り替えの早さを優先する要求があったかどうか判定する（ステップＳ１２４）。係る判定は、制御部１０１が実行し得る。

上記ステップＳ１２４の判定の結果、コンテンツ切り替えの早さを優先する要求があれば、クライアント端末１００はＧＯＰ変更処理を実行する（ステップＳ１２５）。このステップＳ１２５でクライアント端末１００が実行するのは、現在のＧＯＰ構成より短い（ｓｈｏｒｔ）ものに変更するＧＯＰ変更処理である。

一方、上記ステップＳ１２４の判定の結果、コンテンツ切り替えの早さを優先する要求が無ければ、続いてクライアント端末１００は、ユーザからの要求や、アプリケーション部１０７が実行するアプリケーションからの要求などにより、エラー時の復帰の早さを優先する要求があったかどうか判定する（ステップＳ１２６）。係る判定は、制御部１０１が実行し得る。

上記ステップＳ１２６の判定の結果、エラー時の復帰の早さを優先する要求があれば、クライアント端末１００はＧＯＰ変更処理を実行する（ステップＳ１２７）。このステップＳ１２７でクライアント端末１００が実行するのは、現在のＧＯＰ構成より短い（ｓｈｏｒｔ）ものに変更するＧＯＰ変更処理である。

一方、上記ステップＳ１２６の判定の結果、エラー時の復帰の早さを優先する要求が無ければ、続いてクライアント端末１００は、ユーザからの要求や、アプリケーション部１０７が実行するアプリケーションからの要求などにより、動画コンテンツのレートを上げる要求があったかどうか判定する（ステップＳ１２８）。係る判定は、制御部１０１が実行し得る。

上記ステップＳ１２８の判定の結果、動画コンテンツのレートを上げる要求があれば、クライアント端末１００はレート変更処理を実行する（ステップＳ１２９）。このステップＳ１２９でクライアント端末１００が実行するのは、現在のレートより高いものに変更（ｕｐ）するレート変更処理である。

一方、上記ステップＳ１２８の判定の結果、動画コンテンツのレートを上げる要求が無ければ、続いてクライアント端末１００は、ユーザからの要求や、アプリケーション部１０７が実行するアプリケーションからの要求などにより、動画コンテンツのレートを下げる要求があったかどうか判定する（ステップＳ１３０）。係る判定は、制御部１０１が実行し得る。

上記ステップＳ１３０の判定の結果、動画コンテンツのレートを下げる要求があれば、クライアント端末１００はレート変更処理を実行する（ステップＳ１３１）。このステップＳ１３１でクライアント端末１００が実行するのは、現在のレートより低いものに変更（ｄｏｗｎ）するレート変更処理である。

クライアント端末１００は、動画コンテンツの続きの取得のため、ＧＯＰ構成やレートの変更に伴ったコンテンツ取得リストの更新を行う（ステップＳ１３２）。このコンテンツ取得リストの更新は制御部１０１が実行し得る。コンテンツ取得リストの更新を行うと、クライアント端末１００はステップＳ１０６の処理に戻って一連の処理を繰り返す。

図８〜９Ｂに示した処理は、クライアント端末１００での複数の動画コンテンツの同時再生が終了するまで継続される。

続いて、クライアント端末１００でのＧＯＰ構成変更処理について詳細に説明する。図１０Ａは、本開示の一実施形態に係るクライアント端末１００の動作例を示す説明図である。図１０Ａに示したのは、クライアント端末１００でのＧＯＰ構成変更処理の例である。

クライアント端末１００は、ＧＯＰ構成を変更する際に、まず現在のＧＯＰ構成より短い（ｓｈｏｒｔ）ものに変更するリクエストであったかどうか判定する（ステップＳ１４１）。係る判定は制御部１０１が実行し得る。

上記ステップＳ１４１の判定の結果、現在のＧＯＰ構成より短い（ｓｈｏｒｔ）ものに変更するリクエストであった場合は、クライアント端末１００は、コンテンツ情報リストから、同レートで、かつ現在のＧＯＰ構成より短いＧＯＰ構成を選択する（ステップＳ１４２）。係る選択はＧＯＰ構成情報決定部１０９が実行し得る。

一方、上記ステップＳ１４１の判定の結果、現在のＧＯＰ構成より短い（ｓｈｏｒｔ）ものに変更するリクエストで無かった場合、すなわち現在のＧＯＰ構成より長い（ｌｏｎｇ）ものに変更するリクエストであった場合は、クライアント端末１００は、コンテンツ情報リストから、同レートで、かつ現在のＧＯＰ構成より長いＧＯＰ構成を選択する（ステップＳ１４３）。係る選択はＧＯＰ構成情報決定部１０９が実行し得る。

上記ステップＳ１４２またはＳ１４３でリクエストに応じたＧＯＰ構成を選択すると、続いてクライアント端末１００は、選択したＧＯＰ構成へコンテンツ取得リストを更新する（ステップＳ１４４）。

ＧＯＰ構成の変更処理の具体例を説明する。図１５は、コンテンツ取得リストｃ１２の例を示す説明図であり、図１４に示したコンテンツ取得リストｃ１１の状態からＧＯＰ構成が長いものに変更された状態を示したものである。

コンテンツ情報リストが図１４に示したコンテンツ取得リストｃ１１のような状態である場合に、現在のＧＯＰ構成より長い（ｌｏｎｇ）ものに変更するリクエストがあると、クライアント端末１００は、レートが同じでＧＯＰ構成が現在のものより長くなるように、各動画コンテンツのＧＯＰ構成を決定する。この場合はＧＯＰ構成を３０から３００にすることで、レートを変えずにＧＯＰ構成を長くすることが出来る。従ってクライアント端末１００は、コンテンツ取得リストｃ１１からコンテンツ取得リストｃ１２に内容を更新する。

またクライアント端末１００は、コンテンツ情報リストをコンテンツ取得リストｃ１２に変更したことに伴い、コンテンツ取得リストｃ１２に基づいて動画コンテンツサーバ２、３へ動画コンテンツを要求する。その結果、クライアント端末１００は、各動画コンテンツのＧＯＰ構成とコンテンツレートが図１５の画面ｖ１２の様な、合成された４つの動画コンテンツを同時に再生する。

図１６は、コンテンツ取得リストｃ１３の例を示す説明図であり、図１５に示したコンテンツ取得リストｃ１２の状態からＧＯＰ構成が短いものに変更された状態を示したものである。

コンテンツ情報リストが図１５に示したコンテンツ取得リストｃ１２のような状態である場合に、現在のＧＯＰ構成より短い（ｓｈｏｒｔ）ものに変更するリクエストがあると、クライアント端末１００は、レートが同じでＧＯＰ構成が現在のものより短くなるように、各動画コンテンツのＧＯＰ構成を決定する。この場合はＧＯＰ構成を３００から１００にすることで、レートを変えずにＧＯＰ構成を短くすることが出来る。従ってクライアント端末１００は、コンテンツ取得リストｃ１２からコンテンツ取得リストｃ１３に内容を更新する。

またクライアント端末１００は、コンテンツ情報リストをコンテンツ取得リストｃ１３に変更したことに伴い、コンテンツ取得リストｃ１３に基づいて動画コンテンツサーバ２、３へ動画コンテンツを要求する。その結果、クライアント端末１００は、各動画コンテンツのＧＯＰ構成とコンテンツレートが図１６の画面ｖ１３の様な、合成された４つの動画コンテンツを同時に再生する。

続いて、クライアント端末１００でのレート変更処理について詳細に説明する。図１０Ｂは、本開示の一実施形態に係るクライアント端末１００の動作例を示す説明図である。図１０Ｂに示したのは、クライアント端末１００でのレート変更処理の例である。

クライアント端末１００は、レートを変更する際に、まずコンテンツ情報リストから、現在のＧＯＰ構成と同一である、選択可能なレートを取得する（ステップＳ１４５）。ステップＳ１４５で選択可能なレートを取得すると、続いてクライアント端末１００は、現在のレートより低いものに変更（ｄｏｗｎ）するリクエストであったかどうか判定する（ステップＳ１４６）。係る判定は制御部１０１が実行し得る。

上記ステップＳ１４６の判定の結果、現在のレートより低いものに変更（ｄｏｗｎ）するリクエストであった場合は、クライアント端末１００は、コンテンツ情報リストから、対応するコンテンツにおいて一段階低いレートを選択する（ステップＳ１４７）。係る選択はレート情報決定部１１０が実行し得る。

一方、上記ステップＳ１４６の判定の結果、現在のレートより低いものに変更（ｄｏｗｎ）するリクエストで無かった場合、すなわち現在のレートより高いものに変更（ｕｐ）するリクエストであった場合は、クライアント端末１００は、コンテンツ情報リストから、対応するコンテンツにおいて一段階高いレートを選択する（ステップＳ１４８）。係る選択はレート情報決定部１１０が実行し得る。

上記ステップＳ１４７またはＳ１４８でリクエストに応じたＧＯＰ構成を選択すると、続いてクライアント端末１００は、選択したレートへコンテンツ取得リストを更新する（ステップＳ１４９）。

レート変更処理の具体例を説明する。図１７は、コンテンツ取得リストｃ１４の例を示す説明図であり、図１６に示したコンテンツ取得リストｃ１３の状態からレートが高いものに変更された状態を示したものである。

コンテンツ情報リストが図１６に示したコンテンツ取得リストｃ１３のような状態である場合に、現在のレートより高いものに変更（ｕｐ）するリクエストがあると、クライアント端末１００は、ＧＯＰ構成が同じでレートが現在のものより高くなるように、各動画コンテンツのレートを決定する。この場合は、各動画コンテンツのレートを図１７に示したようなものを選択することで、クライアント端末１００は、ＧＯＰ構成を変えずにレートを上げることが出来る。従ってクライアント端末１００は、コンテンツ取得リストｃ１３からコンテンツ取得リストｃ１４に内容を更新する。

またクライアント端末１００は、コンテンツ情報リストをコンテンツ取得リストｃ１４に変更したことに伴い、コンテンツ取得リストｃ１４に基づいて動画コンテンツサーバ２、３へ動画コンテンツを要求する。その結果、クライアント端末１００は、各動画コンテンツのＧＯＰ構成とコンテンツレートが図１７の画面ｖ１４の様な、合成された４つの動画コンテンツを同時に再生する。

ここでレート情報決定部１１０の構成例について説明する。図２２は、レート情報決定部１１０の構成例を示す説明図である。図２１に示したのは、伝送状態判定部１０８が計測したコンテンツバッファ部１０４ａ、１０４ｂ、１０４ｃ、・・・、１０４ｎそれぞれの流入レートに基づいてレートを決定するためのレート情報決定部１１０の構成例である。図２２に示したように、レート情報決定部１１０は、レート変更判定部１３１を含んで構成される。

レート変更判定部１３１は、伝送状態判定部１０８が計測したコンテンツバッファ部１０４ａ、１０４ｂ、１０４ｃ、・・・、１０４ｎそれぞれの流入レートを受け取り、各動画コンテンツのレートを変更すべきか判定する。例えば、コンテンツバッファ部１０４ａ、１０４ｂ、１０４ｃ、・・・、１０４ｎそれぞれの流入レートによっては、まだレートを上げても問題無い場合がある。そのような場合に、レート変更判定部１３１は、ＧＯＰ構成が同じで、レートが現在のものより高くなるように、各動画コンテンツのレートを決定する。

図２２に示した例では、現在のＧＯＰ構成が１００であり、動画コンテンツＡの現在のレートが１Ｍｂｐｓ、動画コンテンツＢの現在のレートが２５６ｋｂｐｓであるとする。この場合に、動画コンテンツＡ、Ｂのレートを上げても問題無いと判断すれば、レート変更判定部１３１は、ＧＯＰ構成が１００であって、一段階高い動画コンテンツＡ、Ｂのレートをコンテンツ情報リストの中から選択し得る。図２２に示した例では、レート変更判定部１３１は、動画コンテンツＡのレートを２Ｍｂｐｓ、動画コンテンツＢの現在のレートを５１２ｋｂｐｓに、それぞれ選択し得る。

レート変更判定部１３１は、受信中の全ての動画コンテンツではなく、一部の動画コンテンツについてのみ、ＧＯＰ構成を維持しながらレートを変更しうる。例えば、ネットワーク１０の帯域に余裕が無ければ、レート変更判定部１３１は、レートの増加量が小さくなるように、一部の動画コンテンツについてのみ、ＧＯＰ構成を維持しながらレートを変更してもよい。またネットワーク１０の帯域に余裕があれば、レート変更判定部１３１は、受信中の全ての動画コンテンツのレートを、ＧＯＰ構成を維持しながら変更してもよく、またレートの増加量が余裕のある範囲内で最も大きくなるように、一部の動画コンテンツについてのみ、ＧＯＰ構成を維持しながらレートを変更してもよい。

本開示の一実施形態に係るクライアント端末１００は、上述したような動作を実行することで、符号化ストリーム情報を用いてマルチ画面合成を行う際に、全てのコンテンツでＧＯＰ構成を一致させつつ、ＧＯＰ構成を変更することが可能になる。また本開示の一実施形態に係るクライアント端末１００は、上述したような動作を実行することで、全てのコンテンツでＧＯＰ構成を一致させつつ、コンテンツのレートを変更することが出来る。

＜２．まとめ＞
以上説明したように本開示の一実施形態によれば、複数の符号化ストリームを合成し、合成後の符号化ストリームを復号することで、複数の動画コンテンツを同時に再生するクライアント端末１００を提供できる。また、本開示の一実施形態に係るクライアント端末１００は、複数の符号化ストリームを合成する際に、ユーザの指示や符号化ストリームの受信状態に応じて、全てのコンテンツでＧＯＰ構成を一致させつつ、ＧＯＰ構成の変更やレートの変更を行うことが出来る。

本開示の一実施形態に係るクライアント端末１００は、全てのコンテンツでＧＯＰ構成を一致させつつ、ＧＯＰ構成を短くすることで、動画コンテンツの切り替えに要する時間を短縮させることができる。また本開示の一実施形態に係るクライアント端末１００は、全てのコンテンツでＧＯＰ構成を一致させつつ、ＧＯＰ構成を短くすることで、パケットロスからの復帰に要する時間を短縮させることができる。また本開示の一実施形態に係るクライアント端末１００は、全てのコンテンツでＧＯＰ構成を一致させつつ、ＧＯＰ構成を長くすることで、符号化効率が上がり、綺麗な動画コンテンツを表示させることができる。

本明細書の各装置が実行する処理における各ステップは、必ずしもシーケンス図またはフローチャートとして記載された順序に沿って時系列に処理する必要はない。例えば、各装置が実行する処理における各ステップは、フローチャートとして記載した順序と異なる順序で処理されても、並列的に処理されてもよい。

また、各装置に内蔵されるＣＰＵ、ＲＯＭおよびＲＡＭなどのハードウェアを、上述した各装置の構成と同等の機能を発揮させるためのコンピュータプログラムも作成可能である。また、該コンピュータプログラムを記憶させた記憶媒体も提供されることが可能である。また、機能ブロック図で示したそれぞれの機能ブロックをハードウェアで構成することで、一連の処理をハードウェアで実現することもできる。

以上、添付図面を参照しながら本開示の好適な実施形態について詳細に説明したが、本開示はかかる例に限定されない。本開示の属する技術の分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本開示の技術的範囲に属するものと了解される。

なお、本技術は以下のような構成も取ることができる。
（１）
同一のコンテンツについて異なるピクチャ構成で符号化された複数のストリームの内のいずれかを複数のコンテンツについて取得し、該ストリームが復号される前に合成する合成部と、
各前記ストリームのピクチャ構成の情報を取得し、取得した前記ピクチャ構成の情報を用いて、前記合成部で合成される各前記ストリームのピクチャ構成が同一となるように各前記コンテンツに対するストリームを前記複数のストリームの中から選択するストリーム選択部と、
を備える、映像処理装置。
（２）
前記ストリーム選択部は、各前記ストリームが送信されるネットワークの状態に応じて前記ストリームを選択する、前記（１）に記載の映像処理装置。
（３）
前記ネットワークの状況の変化を検知する状況検知部を更に備え、
前記ストリーム選択部は、前記状況検知部が検知した変化に応じて適切なピクチャの組の構成を決定する、前記（１）または（２）に記載の映像処理装置。
（４）
前記状況検知部は、前記ネットワークを通じて配信されるストリームのパケットの欠損に関する情報を算出し、
前記ストリーム選択部は、前記状況検知部が算出した情報を用いて適切なピクチャの組の構成を決定する、前記（３）に記載の映像処理装置。
（５）
前記状況検知部の検知に応じて前記ストリームの取得レートを決定するレート決定部を更に備え、
前記レート決定部は、同時に再生されるストリームのピクチャ構成が同一となるよう前記取得レートを決定する、前記（３）または（４）に記載の映像処理装置。
（６）
前記ストリーム選択部は、前記コンテンツを送信する各装置から前記ピクチャ構成の情報を取得する、前記（１）〜（５）のいずれかに記載の映像処理装置。
（７）
前記ストリーム選択部は、取得した前記ピクチャ構成の情報の内、他の前記コンテンツには存在しないピクチャ構成の情報を破棄する、前記（６）に記載の映像処理装置。
（８）
前記ストリーム選択部は、前記コンテンツを送信する各装置から前記ピクチャ構成の情報として該装置が提供可能なピクチャ構成の範囲の情報を取得する、前記（６）または（７）に記載の映像処理装置。
（９）
同一のコンテンツについて異なる条件で符号化された複数のストリームの内のいずれかを複数のコンテンツについて取得し、該ストリームが復号される前に合成するステップと、
各前記ストリームのピクチャ構成の情報を取得し、取得した前記ピクチャ構成の情報を用いて、前記合成するステップで合成される各前記ストリームのピクチャ構成が同一となるように各前記コンテンツに対するストリームを前記複数のストリームの中から選択するステップと、
を備える、映像処理方法。
（１０）
コンピュータに、
同一のコンテンツについて異なる条件で符号化された複数のストリームの内のいずれかを複数のコンテンツについて取得し、該ストリームが復号される前に合成するステップと、
各前記ストリームのピクチャ構成の情報を取得し、取得した前記ピクチャ構成の情報を用いて、前記合成するステップで合成される各前記ストリームのピクチャ構成が同一となるように各前記コンテンツに対するストリームを前記複数のストリームの中から選択するステップと、
を実行させる、コンピュータプログラム。

２、３ 動画コンテンツサーバ
１００ クライアント端末
１０１ 制御部
１０２ ネットワーク送受信部
１０３ 符号化ストリーム分別部
１０４ａ、１０４ｂ、１０４ｃ、・・・、１０４ｎ コンテンツバッファ部
１０５ ストリーム合成部
１０６ ＡＶＣデコード部
１０７ アプリケーション部
１０８ 伝送状態判定部
１０９ ＧＯＰ構成情報決定部
１１０ レート情報決定部

Claims (10)

1. 同一のコンテンツについて異なるピクチャ構成で符号化された複数のストリームの内のいずれかを複数のコンテンツについて取得し、該ストリームが復号される前に合成する合成部と、
   各前記ストリームのピクチャ構成の情報を取得し、取得した前記ピクチ構成の情報を用いて、前記合成部で合成される各前記ストリームのピクチャ構成が同一となるように各前記コンテンツに対するストリームを前記複数のストリームの中から選択するストリーム選択部と、
   を備える、映像処理装置。
2. 前記ストリーム選択部は、各前記ストリームが送信されるネットワークの状態に応じて前記ストリームを選択する、請求項１に記載の映像処理装置。
3. 前記ネットワークの状況の変化を検知する状況検知部を更に備え、
   前記ストリーム選択部は、前記状況検知部が検知した変化に応じて適切なピクチャの組の構成を決定する、請求項２に記載の映像処理装置。
4. 前記状況検知部は、前記ネットワークを通じて配信されるストリームのパケットの欠損に関する情報を算出し、
   前記ストリーム選択部は、前記状況検知部が算出した情報を用いて適切なピクチャの組の構成を決定する、請求項３に記載の映像処理装置。
5. 前記状況検知部の検知に応じて前記ストリームの取得レートを決定するレート決定部を更に備え、
   前記レート決定部は、同時に再生されるストリームのピクチャ構成が同一となるよう前記取得レートを決定する、請求項３に記載の映像処理装置。
6. 前記ストリーム選択部は、前記コンテンツを送信する各装置から前記ピクチャ構成情報を取得する、請求項１に記載の映像処理装置。
7. 前記ストリーム選択部は、取得した前記ピクチャ構成の情報の内、他の前記コンテンツには存在しないピクチャ構成の情報を破棄する、請求項６に記載の映像処理装置。
8. 前記ストリーム選択部は、前記コンテンツを送信する各装置から前記ピクチャ構成の情報として該装置が提供可能なピクチャ構成の範囲の情報を取得する、請求項６に記載の映像処理装置。
9. 同一のコンテンツについて異なる条件で符号化された複数のストリームの内のいずれかを複数のコンテンツについて取得し、該ストリームが復号される前に合成するステップと、
   各前記ストリームのピクチャ構成の情報を取得し、取得した前記ピクチャ構成の情報を用いて、前記合成するステップで合成される各前記ストリームのピクチャ構成が同一となるように各前記コンテンツに対するストリームを前記複数のストリームの中から選択するステップと、
   を備える、映像処理方法。
10. コンピュータに、
    同一のコンテンツについて異なる条件で符号化された複数のストリームの内のいずれかを複数のコンテンツについて取得し、該ストリームが復号される前に合成するステップと、
    各前記ストリームのピクチャ構成の情報を取得し、取得した前記ピクチャ構成の情報を用いて、前記合成するステップで合成される各前記ストリームのピクチャ構成が同一となるように各前記コンテンツに対するストリームを前記複数のストリームの中から選択するステップと、
    を実行させる、コンピュータプログラム。
    
    

Images