(57)【要約】  ピクチャ・イン・ピクチャ・アプリケーションのための１つより多くのコンポーネントストリームを含むメディアストリームを準備する方法及び装置について、ピクチャ・イン・ピクチャ・モードでメディアストリームをレンダリングするための対応する方法及び装置と共に説明する。本発明は、メディアストリームに含まれるコンポーネントストリームのライブで動的なピクチャ・イン・ピクチャのレンダリングを可能にする。このような動的なピクチャ・イン・ピクチャ機能を可能にするために、MPEG-2トランスポートストリーム及びISOメディアフォーマットのような様々なマルチメディアアプリケーションをサポートするメディアフォーマットへの拡張が提案される。
2013538482.tif 000002
【特許請求の範囲】
【請求項１】
ピクチャ・イン・ピクチャ・アプリケーションのための複数のコンポーネントストリームを含むメディアストリームを準備する方法であって、
前記メディアストリームに含まれる前記複数のコンポーネントストリームに基づいてピクチャ・イン・ピクチャ情報を生成するステップと、
前記ピクチャ・イン・ピクチャ情報を前記メディアストリームに挿入するステップと
を有する方法。
【請求項２】
前記複数のコンポーネントストリームの変化に従って前記ピクチャ・イン・ピクチャ情報を更新するステップを更に有する、請求項１に記載の方法。
【請求項３】
前記メディアストリームは、トランスポートストリーム及びプログラムストリームのうち１つである、請求項２に記載の方法。
【請求項４】
前記挿入するステップは、
前記生成されたピクチャ・イン・ピクチャ情報に従ってピクチャ・イン・ピクチャ・データユニットを構築するステップと、
前記ピクチャ・イン・ピクチャ・データユニットを前記メディアストリームに挿入するステップと
を有する、請求項２に記載の方法。
【請求項５】
前記ピクチャ・イン・ピクチャ・データユニットは、ピクチャ・イン・ピクチャ記述子を有し、
前記挿入するステップは、前記ピクチャ・イン・ピクチャ記述子を前記メディアストリームのプログラムマップテーブルに挿入するステップを更に有する、請求項４に記載の方法。
【請求項６】
前記ピクチャ・イン・ピクチャ・データユニットは、ピクチャ・イン・ピクチャ情報ボックスを有し、
前記挿入するステップは、前記ピクチャ・イン・ピクチャ情報ボックスを前記複数のコンポーネントストリームに挿入するステップを更に有する、請求項４に記載の方法。
【請求項７】
ピクチャ・イン・ピクチャ情報ボックスは、ライブでの更新のためのピクチャ・イン・ピクチャ情報ボックス及びオフラインでの更新のためのピクチャ・イン・ピクチャ情報ボックスのうち１つである、請求項６に記載の方法。
【請求項８】
前記ピクチャ・イン・ピクチャ情報は、ピクチャ・イン・ピクチャ・モードでの前記コンポーネントストリームのレイヤ、位置、サイズ及びアスペクト比の情報を有する、請求項２に記載の方法。
【請求項９】
各コンポーネントストリームの前記ピクチャ・イン・ピクチャ情報は、マスターレイヤのコンポーネントストリーム及びアンカーコンポーネントストリームのうち１つに関して定義される、請求項８に記載の方法。
【請求項１０】
ピクチャ・イン・ピクチャ・アプリケーションのための複数のコンポーネントストリームを含むメディアストリームを準備する装置であって、
前記メディアストリームに含まれる前記複数のコンポーネントストリームに基づいてピクチャ・イン・ピクチャ情報を生成する相関器と、
前記ピクチャ・イン・ピクチャ情報を前記メディアストリームに挿入する埋め込み器と
を有する装置。
【請求項１１】
前記メディアストリームは、トランスポートストリーム及びプログラムストリームのうち１つである、請求項１０に記載の装置。
【請求項１２】
識別されたピクチャ・イン・ピクチャ情報からピクチャ・イン・ピクチャ・データユニットを生成するピクチャ・イン・ピクチャ情報構築器を更に有し、
前記ピクチャ・イン・ピクチャ・データユニットは、前記メディアストリームに挿入するために前記埋め込み器に供給される、請求項１１に記載の装置。
【請求項１３】
前記ピクチャ・イン・ピクチャ・データユニットは、ピクチャ・イン・ピクチャ記述子を有し、
前記埋め込み器は、前記ピクチャ・イン・ピクチャ記述子を前記メディアストリームのプログラムマップテーブルに挿入するステップを更に実行する、請求項１２に記載の装置。
【請求項１４】
前記ピクチャ・イン・ピクチャ・データユニットは、ピクチャ・イン・ピクチャ情報ボックスを有し、
前記埋め込み器は、前記ピクチャ・イン・ピクチャ情報ボックスを前記複数のコンポーネントストリームに挿入するステップを更に実行する、請求項１２に記載の装置。
【請求項１５】
ピクチャ・イン・ピクチャ情報ボックスは、ライブでの更新のためのピクチャ・イン・ピクチャ情報ボックス及びオフラインでの更新のためのピクチャ・イン・ピクチャ情報ボックスのうち１つである、請求項１４に記載の装置。
【請求項１６】
ピクチャ・イン・ピクチャ・モードで複数のコンポーネントストリームを含むメディアストリームをレンダリングする方法であって、
前記メディアストリームに関係するピクチャ・イン・ピクチャ情報を取得するステップと、
前記取得されたピクチャ・イン・ピクチャ情報に従って、前記メディアストリームから複数のコンポーネントストリームを抽出するステップと、
前記取得されたピクチャ・イン・ピクチャ情報に従って、前記複数のコンポーネントストリームをレンダリングするステップと
を有する方法。
【請求項１７】
前記メディアストリームは、トランスポートストリーム及びプログラムストリームのうち１つである、請求項１６に記載の方法。
【請求項１８】
前記複数のコンポーネントストリームは、マスターレイヤのコンポーネントストリームと、少なくとも１つのスレーブレイヤのコンポーネントストリームとを有する、請求項１６に記載の方法。
【請求項１９】
必要に応じて、レンダリングの前に、前記ピクチャ・イン・ピクチャ情報に従って、前記抽出された複数のコンポーネントストリームのうち少なくとも１つを前処理するステップを更に有する、請求項１６に記載の方法。
【請求項２０】
前記取得するステップは、
前記メディアストリームからピクチャ・イン・ピクチャ情報データユニットを抽出するステップと、
前記ピクチャ・イン・ピクチャ情報データユニットを分析し、前記ピクチャ・イン・ピクチャ情報を識別するステップと
を有する、請求項１９に記載の方法。
【請求項２１】
ピクチャ・イン・ピクチャ・データユニットは、ピクチャ・イン・ピクチャ記述子、ライブでの更新のためのピクチャ・イン・ピクチャ情報ボックス及びオフラインでの更新のためのピクチャ・イン・ピクチャ情報ボックスのうち少なくとも１つを有する、請求項２０に記載の方法。
【請求項２２】
前記ピクチャ・イン・ピクチャ情報は、前記ピクチャ・イン・ピクチャ・モードでの前記コンポーネントストリームのレイヤ、位置、サイズ及びアスペクト比の情報を有する、請求項１６に記載の方法。
【請求項２３】
各コンポーネントストリームの前記ピクチャ・イン・ピクチャ情報は、マスターコンポーネントストリーム及びアンカーコンポーネントストリームのうち１つに関して定義される、請求項２２に記載の方法。
【請求項２４】
前記前処理するステップは、前記抽出されたコンポーネントストリームのうち少なくとも１つを、前記ピクチャ・イン・ピクチャ情報で指定されたサイズに拡大縮小するステップを有する、請求項２２に記載の方法。
【請求項２５】
ピクチャ・イン・ピクチャ・モードで複数のコンポーネントストリームを含むメディアストリームをレンダリングする装置であって、
前記メディアストリームからピクチャ・イン・ピクチャ情報を抽出し、前記ピクチャ・イン・ピクチャ情報に従って、複数のコンポーネントストリームを抽出する抽出器と、
前記ピクチャ・イン・ピクチャ情報に従って、前記抽出された複数のコンポーネントストリームを処理するプロセッサと
を有する装置。
【請求項２６】
前記抽出器は、前記メディアストリームからピクチャ・イン・ピクチャ情報データユニットを抽出し、
前記装置は、前記ピクチャ・イン・ピクチャ情報データユニットを分析し、ピクチャ・イン・ピクチャ情報を取得し、前記複数のコンポーネントストリームへの参照を前記抽出器に提供する分析器を更に有する、請求項２５に記載の装置。
【請求項２７】
前記ピクチャ・イン・ピクチャ・モードで前記メディアストリームを表示するディスプレイを更に有する、請求項２６に記載の装置。
【請求項２８】
前記メディアストリームは、トランスポートストリーム及びプログラムストリームのうち１つである、請求項２５に記載の装置。
【請求項２９】
前記複数のコンポーネントストリームは、マスターレイヤのコンポーネントストリームと、少なくとも１つのスレーブレイヤのコンポーネントストリームとを有する、請求項２５に記載の装置。
【請求項３０】
ピクチャ・イン・ピクチャ・データユニットは、ピクチャ・イン・ピクチャ記述子、ライブでの更新のためのピクチャ・イン・ピクチャ情報ボックス及びオフラインでの更新のためのピクチャ・イン・ピクチャ情報ボックスのうち少なくとも１つを有する、請求項２５に記載の装置。
【請求項３１】
前記ピクチャ・イン・ピクチャ情報は、前記ピクチャ・イン・ピクチャ・モードでの前記コンポーネントストリームのレイヤ、位置、サイズ及びアスペクト比の情報を有する、請求項２５に記載の装置。
【請求項３２】
各コンポーネントストリームの前記ピクチャ・イン・ピクチャ情報は、マスターコンポーネントストリーム及びアンカーコンポーネントストリームのうち１つに関して定義される、請求項３１に記載の装置。
【請求項３３】
前記プロセッサは、前記少なくとも１つのコンポーネントストリームを、前記ピクチャ・イン・ピクチャ情報で指定されたサイズに拡大縮小する前処理ユニットを有する、請求項２５に記載の装置。
【請求項３４】
前記プロセッサは、制御信号を受け付け、前記制御信号に従って前記抽出されたコンポーネントストリームのうち少なくとも１つを処理する、請求項２５に記載の装置。
【請求項３５】
ディスプレイは、前記ピクチャ・イン・ピクチャ・モードで前記メディアストリームを表示する複数のスクリーンを有する、請求項２５に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
この出願は、2010年7月13日に出願された“Method  of  Picture-in-Picture  in  the  MPEG-2  TS  for  the  HTTP  Streaming”という題の米国仮特許出願第61/363,697号の優先権と、2010年7月13日に出願された“Method  of  Picture-in-Picture  in  the  ISO  Base  Media  File  Format  for  the  HTTP  Streaming”という題の米国仮特許出願第61/363,699号の優先権とを主張する。前述の仮特許出願の教示を援用する。
【０００２】
本発明は、概して、送信及びレンダリング（rendering）のようなマルチメディアアプリケーションのためのピクチャ・イン・ピクチャに関する。より具体的には、本発明は、マルチメディアアプリケーションのためのピクチャ・イン・ピクチャ機能のサポート及びピクチャ・イン・ピクチャの柔軟性の改善に関する。
【背景技術】
【０００３】
ピクチャ・イン・ピクチャ（PIP：picture-in-picture）は、視聴者が複数の別々のビデオソースを同時に視聴することを可能にする。例えば、或るブルーレイディスクのタイトルは、視聴者が視聴している映画につての監督のコメントを見ることを可能にするピクチャ・イン・ピクチャ・トラックを含む。通常では、ブルーレイディスクのアプリケーション等では、ピクチャ・イン・ピクチャは、ハードコードされたPIPビデオを生成することにより（すなわち、背景のビデオの領域を前面のビデオに置換することにより）実装される。ハードコードされたPIPビデオは圧縮され、受信機に送信される。その結果、視聴者は、（背景のビデオのコピーが別々に送信されない限り）PIP機能の有効化／無効化のように、PIPを動的に調整すること、前述のビデオの位置を変更すること等はできない。他の従来のPIPアプリケーションは、２つの独立したビデオストリームをプレイヤ側で重ね合わせるが、ビデオトランスポートは、PIPビデオストリームの相関情報を提供できない。
【０００４】
インタラクティブなマルチメディア技術の進展により、複数のビデオのコンポーネントは相互に関連付けられ、一式のメディア（すなわち、PIPメディア）を形成することができる。PIPメディアのレンダリングは動的でもよく、これは、コンテンツ生成又はユーザ相互作用により決定された前面のビデオの位置、縮尺及びアルファブレンディングが再生中に変更できることを意味する。前面のビデオが背景のビデオについての監督のコメントを表示する前述の例では、動的なPIPは、例えば前面のビデオを移動させることにより、監督が背景のビデオの異なる位置を示すという効果が可能になる。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
MPEG2トランスポートストリーム及びISOメディアファイルフォーマットのような現在のメディアファイルフォーマットの１つの欠点は、ストリームレイヤ（すなわち、トランスポートレイヤ）におけるPIPストリームの位置、レイヤ及び縮尺の情報をライブ（生）で又は動的に更新できないという点にある。動的な位置及び縮尺の情報がなければ、同じ解像度を共有しない表示領域にビデオソースを確実に適合させること又は重ね合わせることはできない。１つの可能性は、ビデオデコーダから情報を取得することである。特定のエンコーダのコーデック及び出力に応じて、このような情報は存在しない可能性があり、信頼性がない可能性がある。また、システムがコーデックからこの情報を同様に抽出することは困難である可能性がある。システムレベルの手法は、使用される基礎となるビデオコーデックに拘らず一貫した経験を提供するためには好適な手法である。
【０００６】
本発明は、送信及びレンダリングのようなマルチメディアアプリケーションのためのピクチャ・イン・ピクチャ機能をサポートし、ピクチャ・イン・ピクチャの柔軟性を改善する対策を提供する。
【課題を解決するための手段】
【０００７】
本発明は、ピクチャ・イン・ピクチャ・アプリケーションのための複数のコンポーネントストリームを含むメディアストリームを準備し、ピクチャ・イン・ピクチャ・モードでこのようなメディアストリームをレンダリングする方法及び装置を対象とする。
【０００８】
本発明の態様によれば、ピクチャ・イン・ピクチャ・アプリケーションのための複数のコンポーネントストリームを含むメディアストリームを準備する方法が提供される。ピクチャ・イン・ピクチャ情報は、メディアストリームに含まれる複数のコンポーネントストリームに基づいて生成される。このようなピクチャ・イン・ピクチャ情報は、受信機に送信される前にメディアストリームに埋め込まれる。このような方法を実行する装置も提供される。この装置は、メディアストリームに含まれる複数のコンポーネントストリームからピクチャ・イン・ピクチャ情報を生成する相関器と、ピクチャ・イン・ピクチャ情報をメディアストリームに挿入する埋め込み器とを有する。
【０００９】
本発明の他の態様によれば、ピクチャ・イン・ピクチャ・モードで複数のコンポーネントストリームを含むメディアストリームをレンダリングする方法が提供される。メディアストリームに関係するピクチャ・イン・ピクチャ情報が取得される。このようなピクチャ・イン・ピクチャ情報に従って、複数のコンポーネントストリームは、メディアストリームから抽出され、ピクチャ・イン・ピクチャ・モードでレンダリングされる。この方法を実施する装置も提供される。このような装置は、抽出器と、プロセッサとを有する。抽出器は、メディアストリームからピクチャ・イン・ピクチャ情報を抽出し、ピクチャ・イン・ピクチャ情報に従って複数のコンポーネントストリームを抽出する。抽出されたコンポーネントストリームは、ピクチャ・イン・ピクチャ・モードでレンダリングするために、プロセッサで処理される。
【図面の簡単な説明】
【００１０】
【図１】１つのスレーブレイヤのピクチャがマスターレイヤのピクチャに重ね合わさったピクチャ・イン・ピクチャ表示モード
【図２】本発明に従ってピクチャ・イン・ピクチャ目的のための複数のコンポーネントストリームを含むメディアストリームを準備するために使用される装置の図
【図３】ピクチャ・イン・ピクチャ・アプリケーションで使用されるメディアストリームを準備するための本発明の一実施例
【図４】ピクチャ・イン・ピクチャ情報を含むメディアストリームを読み取り、ピクチャ・イン・ピクチャ・モードでストリームをレンダリングするために使用されるピクチャ・イン・ピクチャ・レンダリング装置の構成
【図５】本発明に従ってピクチャ・イン・ピクチャ情報を含むメディアストリームを読み取り、ピクチャ・イン・ピクチャ・モードでストリームをレンダリングする処理
【発明を実施するための形態】
【００１１】
本発明の前述の特徴は、添付図面を参照して詳細な例示的な実施例で説明することにより、明らかになる。
【００１２】
本発明では、PIPモードにおける各コンポーネントストリームの解像度／サイズ、位置及びアスペクト比のようなPIP情報をシステムレベルでビットストリームに挿入することにより、システムレベルのPIPの対策が提案される。これにより、受信機は、デコーダからの情報にアクセスせずに、PIPを動的に操作することができる。
【００１３】
図１は、２つのピクチャソースを有するピクチャ・イン・ピクチャ表示モードを示している。背景のピクチャはマスターレイヤ110としてラベルが付与されており、前面のピクチャはスレーブレイヤ120としてラベルが付与されている。一実施例では、スレーブレイヤ120の位置は、オフセットの対（水平オフセット及び垂直オフセット）として、マスターレイヤ110に関して定義される。スレーブレイヤ120のアスペクト比及び解像度も、マスターレイヤ110の所望の表示領域に従って決定される。他のパラメータ（マスター及びスレーブレイヤのピクチャのアルファブレンディング等）も、アプリケーションに従って定義されてもよい。本発明は、複数のスレーブレイヤをサポートしてもよい。各レイヤも同様に定義されてもよい。異なる実施例では、マスターレイヤ及びスレーブレイヤは、位置、縮尺及び他のPIP情報が全てのレイヤで整合されるように、アンカー（anchor）ピクチャ／ビデオと呼ばれる固定のピクチャ／ビデオに関して定義されてもよい。本発明では、マスターレイヤ又はスレーブレイヤから構成されるコンテンツストリームをコンポーネントストリームと呼ぶ。コンポーネントストリームは、ビデオ、画像、サブタイトル、基本レイヤビデオ、SVCの拡張レイヤビデオ、又はMVCのビデオの１つのビューでもよい点に留意すべきである。以下では、ビデオのコンポーネントストリームが本発明を説明するために使用される。他のコンポーネント種別にも同じ原理が当てはまる。
【００１４】
図２は、ピクチャ・イン・ピクチャ目的のための複数のコンポーネントストリームを含むメディアストリームを準備する装置を示している。例えば、メディアストリームは、プログラム（番組）ストリーム又はトランスポートストリームでもよい。ストリーム識別子210は、メディアストリーム205に含まれるコンポーネントストリーム215を識別する。相関器220は、ピクチャ・イン・ピクチャ関係に従って、これらの識別されたコンポーネントストリームを相互に関連付ける。このようなPIP関係は、アプリケーションにより決定される。１つのアプリケーションでは、例えば、スレーブビデオとしての衛星画像のビデオは、マスタービデオとしての天気予報についての気象学者のコメントのビデオに関連付けられてもよい。異なるアプリケーションでは、マスタービデオとしての衛星画像のビデオは、教育目的のためのスレーブビデオとしての竜巻により打撃を受けた地方都市を記録したビデオに関連付けられてもよい。相関器220はまた、マスター及びスレーブのコンポーネントビデオの情報に基づいてPIP情報225を生成する。PIP情報225は、下記のものを含むが、これらに限定されない。
・どのコンポーネントビデオがマスターレイヤのビデオであり、どのコンポーネントビデオがスレーブレイヤのビデオであるかのような、異なるレイヤの間の重なり関係を示すレイヤ情報。複数のスレーブレイヤをサポートするアプリケーションでは、レイヤ情報はまた、スレーブレイヤの間の重なり関係を含む。
・ピクチャ・イン・ピクチャ・モードで表示されたときの各レイヤの位置を示す位置情報。一実施例では、位置情報は、マスターレイヤのコンポーネントビデオに関して計算されてもよい。異なる実施例では、位置情報は、アンカーコンポーネオとビデオに関するものである。
・ピクチャ・イン・ピクチャ・モードで表示されたときの各レイヤのサイズ又は解像度を示すサイズ情報。一例では、スレーブレイヤのビデオのサイズ又は解像度は、スレーブレイヤのビデオを表示することを意図したマスターレイヤのビデオ内の領域のサイズにより決定される。
・ピクチャ・イン・ピクチャ・モードで表示されたときの各レイヤのアスペクト比を示すアスペクト比情報。同様に、一例では、スレーブレイヤのビデオのアスペクト比は、スレーブレイヤのビデオを表示することを意図したマスターレイヤのビデオ内の領域のアスペクト比により決定される。
【００１５】
レイヤのアルファブレンディングのような他の情報も含まれてもよい。
【００１６】
識別されたPIP情報225は、埋め込み器240によりメディアストリームに挿入されてもよい。一実施例では、このような埋め込みは、PIP情報データユニット235を生成するために、PIP情報225をPIP情報構築器230に供給することにより実現される。情報データユニット235は、PIP情報225と同じ情報を伝達するが、コンポーネントストリーム215のフォーマットに準拠する。埋め込み器240は、フォーマットに準拠したPIP情報データユニット235をコンポーネントストリーム215と共にメディアストリームに挿入する。これにより、PIP情報は、受信機側でPIPが有効になるように、コンポーネントストリームに関連付けられ得る。出力メディアストリーム245は、出力メディアストリーム245が埋め込み器240により挿入されたPIP情報を含むという点で、入力メディアストリーム205とは異なる。
【００１７】
図３は、ピクチャ・イン・ピクチャアプリケーションのための複数のコンポーネントストリームを含むメディアストリームを準備する処理を示している。ステップ320において、ステップ310で取得されたメディアストリームに含まれる各コンポーネントストリームが検査される。まず、ステップ330において、現在のコンポーネントストリームの他のコンポーネントストリームとのPIP関係が識別される。その間に、前述のPIP情報が生成される。ステップ340において、このようなPIP情報は、メディアストリームのフォーマットに準拠したPIP情報データユニットにカプセル化される。ステップ350において、PIP情報データユニットは、受信機に送信されるメディアストリームに挿入される。
【００１８】
一般的に、コンポーネントストリームのPIP情報は、ビデオの１つのシーン内のような特定の期間に安定している。すなわち、位置、サイズ及び他のPIP情報の値は、そのシーン内の全てのフレームについて同じままである。しかし、マスターレイヤ又はスレーブレイヤのコンポーネントストリームのコンテンツが変化すると、PIP情報が更新される必要がある可能性がある。このような変化の一例は、監督のビデオを異なるサイズ及びアスペクト比で異なる位置に動かすことを必要とする、監督のコメントの話題が変化することである。他の例は、スレーブレイヤのビデオのソースが異なるコンポーネントストリームに切り替わることでもよい。このようなPIP情報の変化は、メディアストリーム内に更新されて挿入される必要がある。PIP情報データユニットがPIP情報を伝達するために使用される場合、PIP情報データユニットも、メディアストリームのフォーマットに準拠して更新されたPIP情報に基づいて再構築され、メディアストリームに埋め込まれるべきである。
【００１９】
本発明は、複数のコンポーネント関係をサポートすることを目的とする。これは、HTTPストリーミング及びHTML5の機能の強化のような多くのマルチメディアアプリケーションで使用されてもよい。以下では、HTTPストリーミングをサポートすべき２つのストリーミング標準（MPEG2トランスポートストリーム及びISOメディアフォーマットストリーミング）について、PIP情報データユニットの設計の２つの実施例が開示される。双方の標準の現在のバージョンは、システムレベルのPIPの実装はサポートしていないため、提案する実施例は現在の標準に対する拡張になる。ここには明示的に記載又は図示しないが、当業者は、この原理を具現してその要旨及び範囲内に含まれるPIP情報データユニットの様々なバージョンを考案することができることが分かる。
【００２０】
表１に、pip_descriptorと呼ばれる、MPEG-2  TS仕様の提案するPIP情報データユニットを記載する。記述子は、ビデオソースの位置、縮尺及びアスペクト比の情報の詳細を含む。pip_descriptorのシンタックスは以下に説明する。
【００２１】
【表１】
2013538482.tif 000003
・descriptor_tag（記述子タグ）−descriptor_tagは、MPEG-2標準において各記述子を識別する8ビットのフィールドである。MPEG-2の記述子についての更なる詳細については、Information  technology  −  Generic  coding  of  moving  pictures  and  associated  audio  information:  systems,  ISO/IEC  13818-1:2007のSection  2.6を参照のこと。
・descriptor_length（記述子長）−descriptor_lengthは、descriptor_lengthフィールドの直後に続く記述子のバイト数を示す8ビットのフィールドである。
・layer_num（レイヤ番号）−このフィールドは、どのようにマスターレイヤのコンポーネントビデオとスレーブレイヤのコンポーネントビデオが重なっているかを示す。0の値は、重ね合わせの中の最低のレイヤである。一般的に、１つのディスプレイでは、レイヤiのコンテンツとレイヤjのコンテンツとの間にいずれかの重なりが存在し、i<jであり、レイヤjのコンテンツは重なった領域にレンダリングされる。layer_numのパラメータを使用して、複数ディスプレイの装置のサポートが容易に実装可能になる。主ディスプレイスクリーンとしてTVを使用して副ディスプレイスクリーンとしてiPadを使用するような、複数ディスプレイ／スクリーンを備えたシステムでは、アプリケーションは、副ディスプレイスクリーンでレンダリングされる高いlayer_num値を備えたコンポーネントストリームのコンテンツに高い確率を割り当ててもよい。
・master_layer（マスターレイヤ）−このフィールドは、どのコンポーネントビデオが現在のコンポーネントビデオのレイヤのマスターレイヤであるかを示す。マスターレイヤの値がレイヤ番号の値と同じである場合、現在のコンポーネントビデオがマスターレイヤであることを意味する。
・horizontal_offset（水平オフセット）−このフィールドは、図１に示すようにマスターレイヤのコンポーネントビデオ又は表示領域の左上の画素に関する現在のコンポーネントビデオの表示領域の左上の画素の水平位置を示す。この値は、アンカーコンポーネントビデオに関して測定されてもよい。
・vertical_offset（垂直オフセット）−このフィールドは、図１に示すようにマスターレイヤのコンポーネントビデオの表示領域の左上の画素に関する現在のコンポーネントビデオの表示領域の左上の画素の垂直位置を示す。この値は、アンカーコンポーネントビデオに関して測定されてもよい。
・width（幅）−このフィールドは、現在のコンポーネントビデオの表示領域の水平サイズである。現在のコンポーネントビデオのビデオフレームは、このサイズまで拡大縮小される。
・height（高さ）−このフィールドは、現在のコンポーネントビデオの表示領域の水平サイズである。現在のコンポーネントビデオのビデオフレームは、このサイズまで拡大縮小される。
・aspect_ratio_info_present_flag（アスペクト比情報存在フラグ）−このフィールドの値が1に等しい場合、aspect_ratio_idcが存在することを意味する。aspect_ratio_info_present_flagが0に等しい場合、aspect_ratio_idcは存在しない。
・aspect_ratio_idc（アスペクト比インジケータ）−このフィールドは、コンポーネントビデオ内のルーマ（luma）サンプルのサンプルアスペクト比の値を示す。表２にこのコードの意味を示す。aspect_ratio_idcがExtended_SARを示す場合、サンプルアスペクト比は、sar_width及びsar_heightにより表される。aspect_ratio_idcのシンタックス要素が存在しない場合、aspect_ratio_idcの値は0に等しいと推定されるべきである。
【００２２】
【表２】
2013538482.tif 000004
・sar_widthは、（任意の単位での）サンプルアスペクト比の水平サイズを示す。
・sar_heightは、（sar_widthと同じ任意の単位での）サンプルアスペクト比の垂直サイズを示す。
sar_width及びsar_heightは、互いに素であるべき又は0に等しいべきである。aspect_ratio_idcが0に等しい場合又はsar_widthが0に等しい場合若しくはsar_heightが0に等しい場合、サンプルアスペクト比は、指定なしと考えられるべきである。
・flexibility（柔軟性）は、プレイヤのPIP動作を示す。これが0に設定された場合、これは、ハードコードされたPIPの種類であり、プレイヤがこれを変更又は除去できないことを意味する。これは、除去できない広告のようなアプリケーションで使用され得る。flexibilityフィールドが1に設定された場合、プレイヤは、スクリーンサイズ及び関心（point-of-interest）マスクレイヤ等のようなアルゴリズムに従ってPIPを変更することができる。flexibilityフィールドが2に設定された場合、プレイヤは、ユーザがPIPを変更することを許可し、PIPをオフにすることすら許可する。これは、相互作用の経験を向上させ、また、制御オーバヘッドを低減する。
【００２３】
ピクチャ・イン・ピクチャ・モードでは、target_background_descriptor及びpip_descriptorは、図１に示すように、ビデオをディスプレイの指定の位置に配置するために使用される。target_background_descriptorは、Information  technology  −  Generic  coding  of  moving  pictures  and  associated  audio  information:  systems,  ISO/IEC  13818-1:2007のSection  2.6.12に詳細に記載されている。pip_descrptorは、Information  technology  −  Generic  coding  of  moving  pictures  and  associated  audio  information:  systems,  ISO/IEC  13818-1:2007のSection  2.4.4.8に規定されたプログラムマップテーブル／セクション（PMT）の記述子ループに含まれるべきである。PIP情報の更新が必要である場合、pip_descriptorは、PMT情報と共に動的に更新されてもよい。
【００２４】
ISOメディアファイルフォーマットでは、２つのPIP情報ボックスが提案されている。１つはライブ（生）での更新であり、１つはオフラインでの更新である。ライブで更新するPIP情報ボックスは、ライブストリーミングの間に使用され、PIP情報ボックスは、コンポーネントストリームのメタデータ部分に含まれ、常に更新可能である。オフラインで更新するPIP情報ボックスは、DVDのようなオフラインアプリケーションで使用され、これにより、PIP情報は、ボックス内に１回のみ送信され、情報は、ストリームのデータサンプル部分に挿入される。PIP情報が変化すると、PIP情報ボックスが更新され、ストリームの現在のデータサンプル部分に挿入される。
1.ライブでの更新のためのPIP情報ボックス
定義:
Box  Type:  ’pip1’
Container:  Track  Fragment  Box  (‘traf‘)  or  Track  Box  (‘trak‘)
Mandatory:  No
Quantity:  Zero  or  one
シンタックス:
aligned(8)  class  PiPInfoBox  extends  Box  (‘pipl‘)  {
template  int(16)  layer_num  =  0;
template  int(16)  master_layer  =  0;
unsigned  int(32)  horizontal_offset;
unsigned  int(32)  vertical_offset;
unsigned  int(32)  width;
unsigned  int(32)  height;
}
意味:
各エントリは、前述のものと同じである。
2.オフラインでの更新のためのPIP情報ボックス
定義:
Box  Type:  ‘pips’
Container:  Sample  Table  Box  (‘stb1‘)
Mandatory:  No
Quantity:  Zero  or  one
シンタックス:
aligned(8)  class  PiPInfoBox  extends  Box  (‘pips‘)  {
unsigned  int(32)  entry_count;
int  i;
for  (i=0;  i<entry_count;  i++)  {
unsigned  int(32)  pip_sample_number;
template  int(16)  layer_num  =  0;
template  int(16)  master_layer  =  0;
unsigned  int(32)  horizontal_offset;
unsigned  int(32)  vertical_offset;
unsigned  int(32)  width;
unsigned  int(32)  height;
}
}
意味:
entry_countは、以下のテーブルのエントリ数を与える整数である。各エントリは、メディアストリームのコンポーネントストリームに対応する。
【００２５】
pip_sample_numberは、ストリーム内のPIPポイントであるサンプル数を与える。サンプルの定義についての詳細は、Information  Technology  −  Coding  of  Audio-Visual  Objects  −  Part  12:  ISO  base  media  file  formatに記載されている。
【００２６】
受信機側では、複数のコンポーネントストリームを含むメディアストリームのピクチャ・イン・ピクチャをレンダリングするために、PIP情報は、メディアストリームから抽出される。PIP情報に従って、マスターレイヤのコンポーネントストリームと１つ以上のスレーブレイヤのコンポーネントストリームとを含む複数のコンポーネントストリームが決定され、メディアストリームから抽出される。マスターレイヤ及びスレーブレイヤのコンポーネントストリームを含むコンポーネントストリームは、PIP情報に従ってレンダリングされる。或る場合には、例えばコンポーネントストリーム内のビデオコンテンツがPIPの必要なサイズ及びアスペクト比とは異なるサイズ／解像度及びアスペクト比を有する場合、コンポーネントストリームは、レンダリング前に前処理される必要がある。このような前処理は、コンポーネントストリームの拡大縮尺動作に関係する。コンポーネントストリーム及びPIP情報に従って、他の前処理も必要になる可能性がある。レンダリング処理は、PIP情報を絶えず監視し、PIP情報が更新した場合には常に変更を行う。
【００２７】
図４は、PIP情報を含むメディアストリームを読み取るために使用されるPIPレンダリング装置の構成を示している。抽出器410は、入力メディアストリームからPIP情報を抽出し、更に、PIP情報に従ってメディアストリームからマスターコンポーネントストリーム及び全てのスレーブコンポーネントストリームを抽出する。プロセッサ430は、ピクチャ・イン・ピクチャ情報に従って抽出されたコンポーネントストリームを処理し、ディスプレイ440への出力を生成する。一実施例では、抽出器410は、メディアストリームからpip_descriptor又はPIP情報ボックスのようなPIP情報データユニットを抽出し、分析器420は、抽出されたPIP情報データユニットを分析するために使用される。分析器420からの１つの出力は、マスター及びスレーブレイヤのコンポーネントビデオストリームへの参照である。これらの参照を用いて、抽出器410は、プロセッサ430のために必要なコンポーネントストリームを抽出することができる。分析器420は、PIP情報データユニットを更に解析し、プロセッサ430に理解可能なPIP情報を生成する。プロセッサ430はまた、例えば視聴者から、PIP機能の有効化又は無効化のようなPIP効果を制御するための外部制御信号を受け付けてもよい。制御信号は、コンポーネントストリームの所望の位置又はサイズの情報を含んでもよい。このような情報は、メディアストリームからのPIP情報で提供される対応する情報を上書きする。プロセッサ430は、抽出されたマスター及びスレーブのコンポーネントストリームを復号化するビデオデコーダを有してもよい。マスター及びスレーブレイヤのコンポーネントストリームの復号化は、並列して実行されてもよい。前述の前処理がコンポーネントストリームに必要な場合、プロセッサ430は、ディスプレイ440に表示するためのPIPビデオを生成する前に前処理ユニットを呼び出すことにより、このような前処理を更に実行する。ディスプレイ440はまた、前述のように、複数ディスプレイアプリケーションのための１つより多くのディスプレイスクリーンを含んでもよい。
【００２８】
図５は、本発明に従ってPIP情報を含むメディアストリームを読み取り、PIPモードでストリームをレンダリングする処理を示している。ステップ510において、pip_descriptor又はPIP情報ボックスのようなPIP情報データユニットが抽出される。ステップ520において、PIP情報は、どのストリームがマスター及びスレーブレイヤのコンポーネントストリームであるかのような抽出されたPIP情報データユニットを分析することにより、更に識別される。ステップ530において、PIP情報を用いて、処理は、メディアストリームから必要なコンポーネントストリームを抽出することができる。コンポーネントストリーム毎に、判定ステップ550は、コンポーネントストリームが前処理を必要とするか否かを判定する。前処理が必要である場合、ステップ560において、コンポーネントストリームのコンテンツは、所望のサイズ及びアスペクト比へのコンテンツのサイズ変更のように、PIP情報に従って処理される。前処理が不要であると判定された場合、レンダリングのために、処理は直接ステップ570に進む。各コンポーネントストリームのループは、マルチコアのプロセッサを使用して又はマルチスレッドの実装を通じて並列して実現されてもよい。
【００２９】
本発明の好ましい実施例についてここで説明したが、本発明はこれらの実施例に限定されず、特許請求の範囲により規定された本発明の範囲を逸脱することなく、他の変更及び変形が当業者により行われてもよいことが分かる。
【図１】
2013538482.tif 000005
【図２】
2013538482.tif 000006
【図３】
2013538482.tif 000007
【図４】
2013538482.tif 000008
【図５】
2013538482.tif 000009
【国際調査報告】
2013538482.tif 000010
2013538482.tif 000011
2013538482.tif 000012