(57)【要約】  高フレームレートソースコンテンツを処理する方法は、ソースコンテンツの高フレームレートよりも低い第２のフレームレートを有する少なくとも１つの画像ブロックにソースコンテンツの画像をタイル化することを含む。タイル化後、少なくとも１つの画像ブロックに対する少なくとも１つの動作が実行される。次に、少なくとも１つの画像ブロックにタイル化された連続画像は、高フレームレートでの順次表示のために選択される。
2017520176.tif 000002
【特許請求の範囲】
【請求項１】
高フレームレートソースコンテンツを処理する方法であって、
前記ソースコンテンツの高フレームレートよりも低い第２のフレームレートを有する少なくとも１つの画像ブロックに前記ソースコンテンツの画像をタイル化することと、
少なくとも１つの動作を前記少なくとも１つの画像ブロックに対して実行することと
を含む、方法。
【請求項２】
前記少なくとも１つの動作は編集動作を含む、請求項１に記載の方法。
【請求項３】
前記少なくとも１つの動作は圧縮動作を含む、請求項１に記載の方法。
【請求項４】
前記圧縮動作は動きベースの圧縮を含む、請求項３に記載の方法。
【請求項５】
前記動きベースの圧縮動作を示すメタデータを提供するステップを更に含む、請求項４に記載の方法。
【請求項６】
前記動きベースの圧縮は、フレーム内符号化を使用する、請求項４に記載の方法。
【請求項７】
前記動きベースの圧縮は、プログレッシブフレーム符号化及び双方向フレーム符号化のうちの少なくとも一方を更に使用する、請求項６に記載の方法。
【請求項８】
前記動きベースの圧縮はスライス符号化を更に使用する、請求項６に記載の方法。
【請求項９】
前記第２のフレームレートは、前記高フレームレートの４倍であり、前記ソースコンテンツの４つの画像は、前記少なくとも１つの画像ブロックのそれぞれにタイル化される、請求項１に記載の方法。
【請求項１０】
前記ソースコンテンツの前記画像は、前記少なくとも１つの画像ブロックよりも低い解像度を有する、請求項１に記載の方法。
【請求項１１】
前記ソースコンテンツは、前記少なくとも１つの画像ブロックと等しい解像度を有する、請求項１に記載の方法。
【請求項１２】
前記少なくとも１つの画像ブロックへのタイル化の前に、前記ソースコンテンツの前記画像をスケーリングすることを含む、請求項１に記載の方法。
【請求項１３】
前記ソースコンテンツの前記画像は、前記少なくとも１つの画像ブロックへのタイル化の前に、アナモルフィックにスケーリングされる、請求項１２に記載の方法。
【請求項１４】
前記ソースコンテンツは、３Ｄ立体画像対であって、それぞれの画像対が右目画像及び左目画像を有する、３Ｄ立体画像対を含む、請求項１に記載の方法。
【請求項１５】
第１のフレームレートで、右目画像及び左目画像の立体画像対を有するレート３Ｄソースコンテンツを処理する方法であって、
前記ソースコンテンツの前記第１のフレームレートよりも低い第２のフレームレートを有する少なくとも１つの画像ブロックに前記ソースコンテンツの連続立体画像対をタイル化することと、
少なくとも１つの動作を前記少なくとも１つの画像ブロックに対して実行することと
を含む、方法。
【請求項１６】
前記少なくとも１つの動作は編集動作を含む、請求項１５に記載の方法。
【請求項１７】
前記少なくとも１つの動作は圧縮動作を含む、請求項１５に記載の方法。
【請求項１８】
前記圧縮動作は動きベースの圧縮を含む、請求項１７に記載の方法。
【請求項１９】
前記動きベースの圧縮動作を示すメタデータを提供するステップを更に含む、請求項１８に記載の方法。
【請求項２０】
前記動きベースの圧縮は、フレーム内符号化を使用する、請求項１８に記載の方法。
【請求項２１】
前記動きベースの圧縮は、プログレッシブフレーム符号化及び双方向フレーム符号化のうちの少なくとも一方を更に使用する、請求項２０に記載の方法。
【請求項２２】
前記動きベースの圧縮はスライス符号化を更に使用する、請求項２０に記載の方法。
【請求項２３】
前記第１のフレームレートは前記第２のフレームレートの２倍であり、前記ソースコンテンツの２つの立体画像対は、前記少なくとも１つの画像ブロックのそれぞれにタイル化される、請求項１５に記載の方法。
【請求項２４】
前記ソースコンテンツの前記立体画像対の各画像は、前記少なくとも１つの画像ブロックよりも低い解像度を有する、請求項１５に記載の方法。
【請求項２５】
ソースコンテンツの前記立体画像対の各画像は、前記少なくとも１つの画像ブロックと等しい解像度を有する、請求項１５に記載の方法。
【請求項２６】
前記ソースコンテンツの前記立体画像対の各画像は、前記少なくとも１つの画像ブロックへのタイル化の前に、スケーリングされる、請求項１５に記載の方法。
【請求項２７】
前記ソースコンテンツの前記立体画像対の各画像は、前記少なくとも１つの画像ブロックへのタイル化の前に、アナモルフィックにスケーリングされる、請求項２６に記載の方法。
【請求項２８】
第１のフレームレートを有する少なくとも１つの画像ブロックにタイル化された画像を復号化する方法であって、
前記少なくとも１つの画像ブロックにタイル化された連続画像を選択するステップと、
前記第１のフレームレートよりも高い第２のフレームレートで表示するために、前記選択された画像を順次提供するステップと
を含む、方法。
【請求項２９】
連続画像を選択的に選択する前に、少なくとも１つの動作を前記少なくとも１つの画像ブロックに対して実行するステップを更に含む、請求項２８に記載の方法。
【請求項３０】
前記少なくとも１つの動作は編集動作を含む、請求項２８に記載の方法。
【請求項３１】
前記少なくとも１つの動作は復元動作を含む、請求項２８に記載の方法。
【請求項３２】
前記復元動作は、動きベースの圧縮に対するものである、請求項３１に記載の方法。
【請求項３３】
前記動きベースの圧縮を示すメタデータを特定するステップを更に含む、請求項３２に記載の方法。
【請求項３４】
前記動きベースの圧縮は、フレーム内符号化を使用する、請求項３２に記載の方法。
【請求項３５】
前記動きベースの圧縮は、プログレッシブフレーム符号化及び双方向フレーム符号化のうちの少なくとも一方を更に使用する、請求項３４に記載の方法。
【請求項３６】
前記動きベースの圧縮はスライス符号化を使用する、請求項３２に記載の方法。
【請求項３７】
前記第２のフレームレートは、前記第１のフレームレートの４倍であり、前記ソースコンテンツの４つの画像は、前記少なくとも１つの画像ブロックのそれぞれにタイル化される、請求項１に記載の方法。
【請求項３８】
第１のフレームレートを有する少なくとも１つの画像ブロックにタイル化された立体画像対を表示する方法であって、
前記少なくとも１つの画像ブロックにタイル化された立体画像の連続対を選択するステップと、
前記第１のフレームレートよりも高い第２のフレームレートで表示するために、前記選択された立体画像を順次提供するステップと
を含む、方法。
【請求項３９】
連続立体画像を選択的に選択する前に、少なくとも１つの動作を前記少なくとも１つの画像ブロックに対して実行するステップを更に含む、請求項２８に記載の方法。
【請求項４０】
前記少なくとも１つの動作は編集動作を含む、請求項３８に記載の方法。
【請求項４１】
前記少なくとも１つの動作は復元動作を含む、請求項３８に記載の方法。
【請求項４２】
前記復元動作は、動きベースの圧縮に対するものである、請求項４１に記載の方法。
【請求項４３】
前記動きベースの圧縮を示すメタデータを特定するステップを更に含む、請求項４２に記載の方法。
【請求項４４】
前記動きベースの圧縮は、フレーム内符号化を使用する、請求項４２に記載の方法。
【請求項４５】
前記動きベースの圧縮は、プログレッシブフレーム符号化及び双方向フレーム符号化のうちの少なくとも一方を更に使用する、請求項４４に記載の方法。
【請求項４６】
前記動きベースの圧縮はスライス符号化を使用する、請求項４２に記載の方法。
【請求項４７】
前記第２のフレームレートは、前記第１のフレームレートの２倍であり、立体画像の２つの対は、前記少なくとも１つの画像ブロックのそれぞれにタイル化される、請求項３８に記載の方法。
【請求項４８】
第１のフレームレートで画像を符号化する装置であって、
前記画像を受信する受信機と、
前記受信機により受信された前記画像を記憶するバッファと、
前記第１のフレームレートよりも遅い第２のフレームレートで少なくとも１つの画像ブロックを出力する画像ブロック出力モジュールであって、前記少なくとも１つの画像ブロックは、その中にタイル化された前記画像を有する、画像ブロック出力モジュールと
を含む、装置。
【請求項４９】
前記画像ブロック出力モジュールは、前記少なくとも１つの画像ブロックを圧縮する、請求項４８に記載の装置。
【請求項５０】
前記画像ブロック出力モジュールは、動きベースの圧縮を使用して前記少なくとも１つの画像ブロックを圧縮する、請求項４９に記載の装置。
【請求項５１】
前記画像ブロック出力モジュールは、前記圧縮動作を示すメタデータを提供する、請求項４９に記載の装置。
【請求項５２】
前記動きベースの圧縮はフレーム内符号化を使用する、請求項５０に記載の装置。
【請求項５３】
前記動きベースの圧縮は、プログレッシブフレーム符号化及び双方向フレーム符号化のうちの少なくとも一方を更に使用する、請求項５２に記載の装置。
【請求項５４】
前記動きベースの圧縮はスライス符号化を使用する、請求項５０に記載の装置。
【請求項５５】
第１のフレームレートを有する少なくとも１つの画像ブロックのそれぞれにタイル化された画像を復号化する装置であって、
少なくとも１つの低フレームレート画像ブロックを受信する受信機と、
前記受信機により受信された前記少なくとも１つの画像ブロックを記憶するバッファと、
前記少なくとも１つの画像ブロックにタイル化された連続画像を選択し、且つ前記第１のフレームレートよりも高い第２のフレームレートで表示するために、前記選択された画像を順次提供するように構成される画像ブロック出力モジュールと
のステップを含む、装置。
【請求項５６】
前記受信機は前記少なくとも１つの画像ブロックを復元する、請求項５５に記載の装置。
【請求項５７】
前記受信機は、動きベースの圧縮を使用して前記少なくとも１つの画像ブロックを復元する、請求項５６に記載の装置。
【請求項５８】
前記受信機は、前記復元動作を示すメタデータを特定する、請求項５６に記載の装置。
【請求項５９】
前記動きベースの圧縮はフレーム内符号化を使用する、請求項５７に記載の装置。
【請求項６０】
前記動きベースの圧縮は、プログレッシブフレーム符号化及び双方向フレーム符号化のうちの少なくとも一方を更に使用する、請求項５９に記載の装置。
【請求項６１】
前記動きベースの圧縮はスライス符号化を使用する、請求項５７に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願の相互参照
本願は、米国特許法第１１９条（ｅ）下で、２０１４年５月３０日に出願された米国仮特許出願第６２／００５，３９７号及び２０１４年８月７日に出願された米国仮特許出願第６２／０３４，２４８号に対する優先権を主張するものであり、これらの教示は本明細書に援用される。
技術分野
本発明は、ビデオ圧縮に関し、より詳細には、高フレームレートビデオの圧縮に関する。
【背景技術】
【０００２】
背景技術
米国では、テレビ局が歴史的に、毎秒６０フィールドでのインターレースフィールドで、毎秒３０フレームで標準精細形式（約４８０線のピクチャ）を使用して、放送チャネルを介してテレビ番組を送信してきた。標準精細形式でのテレビコンテンツの送信は、良好な動きの感覚（例えば、スポーツ放送で）を提供し、陰極線管を有するテレビジョンセットに関連する蛍光体の時定数を良好に補償する。テレビ局は、今では標準精細から高精細（ＨＤ）に変換した。現在、２つの主なＨＤ形式が存在する：インターレース式である１０８０ｉ及びプログレッシブ式の７２０ｐ。動きが遅いコンテンツは、１０８０ｉ（毎秒６０フィールド）でのより高い空間解像度から恩恵を受け、一方、スポーツのような高速動作は、７２０ｐ（毎秒６０フレームのより高い時間解像度から恩恵を受ける。最近、テレビ局は、高い２１６０ｐ線のピクチャ（３８４０×２１６０ピクセル）としての解像度を有する超高精細形式に移行し始めた。したがって、インターレース形式は現在、放送局からあまり支持されていない。
【０００３】
多くの最近導入された高精細消費者表示システムは、プログレッシブスキャンを使用したサポート形式として立体３Ｄを含む。そのような３Ｄ表示システムは、一般に互換性のある眼鏡を用いて、立体画像対の別個の左目画像及び右目画像を各目に届ける。幾つかのビデオ配信方式は、３Ｄを１つの画像として符号化し、視差マップを利用して、左目画像及び右目画像を作成する。しかし、３Ｄビデオ配信メカニズムの大半（例えば、Blu-Ray（商標）ディスク及び北米での３Ｄ放送）は、左目画像と右目画像との対を１つの複合フレーム、通常、３８４０×１０８０ピクセルにパックすることに依存する。３ＤのBlu-Rayディスクの場合、フルサイズの左目画像及び右目画像対は、１つのオーバーサイズフレームドにオーバー／アンダータイリングされる。
【０００４】
複合画像は、受信側から単純に見た場合、それぞれ明瞭度が異なる幾つかの代替の方法のうちの１つで一緒に組み合わせられる各立体対の両画像を含む。しかし、適宜復号化される場合、各画像は画面を埋めるように見え、それぞれ適宜、左目又は右目のみに見える。ＳＭＰＴＥ規格ＳＴ２０６８：２０１３−ＨＤＴＶ用立体３Ｄフレーム互換性パッキング及びシグナリングは、ニューヨーク州、White PlainsのSociety of Motion Picture and Television Engineersにより２０１３年７月２９日に公開され、立体画像対を提供する装置にシグナリングする１つの周知のメカニズムを記述している。
【０００５】
今日、放送局によっては、超高精細（ＵＨＤ）コンテンツを比較的低いフレームレートで放送し始めているところがある。特定のテレビコンテンツ、特にスポーツでは、高いフレームレートが優れた閲覧経験をもたらす。不都合なことに、高フレームレートが可能なシステムは、広くは存在せず、配信チャネルに浸透していない。更に、より小さいタイミング単位（例えば、１／１２０秒）を放送チェーンに導入することは、スイッチャー及びエディター等の時間コードの影響を受けやすいデバイスに問題、例えば、異なるフレームレートコンテンツ中からの切り替えを要する問題を提示するおそれがある。例えば、時間コードの影響を受けやすいデバイスは、切り替えが行われるべきときに、１２０ｆｐｓの奇数フレームがパイプライン中間フレームを出た（より低いフレームレートで）ことを見つけるためにのみ、異なる番組に切り替える必要があり得（例えば、０時に）、これは許容できない状況である。その結果、従来の放送チャネルを通して高フレームレートコンテンツを提供する実用的な方法は現在のところ存在しない。
【０００６】
したがって、上述した欠点を解消する高フレームレートコンテンツを処理することが必要とされている。
【発明の概要】
【０００７】
概要
手短に言えば、高フレームレートソースコンテンツを処理する方法は、ソースコンテンツの高フレームレートよりも低い第２のフレームレートを有する少なくとも１つの画像ブロックにソースコンテンツの画像をタイル化することにより開始される。タイル化後、少なくとも１つの画像ブロックに対して少なくとも１つの動作が実行される。
【０００８】
本原理の別の態様によれば、第１のフレームレートを有する少なくとも１つの画像ブロックにタイル化された画像を表示する方法は、少なくとも１つの画像ブロックにタイル化された連続フレームを選択するステップと、第１のフレームレートよりも高い第２のフレームレートで表示するために、選択されたフレームを順次提供するステップとを含む。
【図面の簡単な説明】
【０００９】
【図１】本原理の第１の態様による、一連の高フレームレート画像を捕捉し、それらをＩフレーム及びＰフレームの圧縮に適したより低いフレームレート画像ブロックにパックするプロセスを示す。
【図２】表示のために図１の低フレームレート画像ブロックから高フレームレート画像をアンパックするプロセスを示す。
【図３】図１に示されるように、高フレームレート画像をより低いフレームレート画像ブロックにパックし、図２に示されるように、そのようなフレームレートのより低い画像ブロックを続けてアンパックする方法のステップをフローチャート形態で示す。
【図４】最小に近いタイミング要件を示す、図３のパック及びアンパック方法の説明的なタイミング図を示す。
【図５】本原理の第２の態様による、一連の高フレームレート画像を捕捉し、それらをＩフレーム、Ｐフレーム、及びＢフレームの圧縮に適するより低いフレームレート画像ブロックにパックするプロセスを示す。
【図６】表示のために図５のより低いフレームレート画像ブロックから高フレームレート画像をアンパックするプロセスを示す。
【図７】図５に示されるように、高フレームレート画像をより低いフレームレート画像ブロックにパックし、図６に示されるように、続けてそれらをアンパックする方法のステップをフローチャート形態で示す。
【図８】最小に近いタイミング要件を示す、図７のパック及びアンパック方法の説明的なタイミング図を示す。
【図９】本原理のパック及びアンパックプロセスのそれぞれの方法をフローチャート形態で示す。
【図１０】高フレームレート２Ｄ画像及び立体３Ｄ画像がパックされた幾つかの例示的な低フレームレート画像ブロックを示す。
【図１１】図１に示されるパックプロセスの様々な例示的な符号化シーケンスを示す。
【図１２】図２に示されるアンパックプロセスの様々な例示的な符号化シーケンスを示す。
【図１３】本原理による例示的な高フレームレート処理システムのブロック図を示す。
【発明を実施するための形態】
【００１０】
詳細な考察
図１は、高フレームレート（ＨＲＦ）画像ストリームが捕捉（又は他の実施形態では、作成）されるステップ１０１を含むフレームレート圧縮技法１００を示す。図１に示される実施形態では、被写体１０７に対する視野１０６を有するＨＦＲカメラ１０５が、高フレームレート画像ストリームを生成し、その一部１１０は個々の順次画像１１１〜１２６を含む。図１の例示的な実施形態では、他の図にも示されるように、カメラ１０７により捕捉される被写体１０７は、馬に乗っている男性を含む。被写体１０７の画像１１１〜１２６は、個々の画像が明確に区別可能な違いを示すように、時間尺度を誇張した状態で、図１及び他の図において見られる。画像１１１〜１２６は、Eadweard Muybridgeによる１８８７年の作品「Jumping a hurdle, black horse」内の画像に対応する。これらの画像は、多くの人への親しみやすさにより選ばれ、したがって、本発明の理解に役立つ認識可能なシーケンスを提示する。
【００１１】
図１のステップ１０１中に捕捉されたストリーム部分１１０内の画像１１１〜１２６は、ステップ１０２中、捕捉バッファ１３０に蓄積され、それにより、サブシーケンス１３１〜１３４の組を生成する。ステップ１０３中、サブシーケンス１３１〜１３４は符号化を受けて、サブシーケンス（ＨＦＲ画像を含む）を低フレームレート（ＬＦＲ）画像ブロック１４１〜１４４の組１４０にパックする。例えば、各サブシーケンス１３１〜１３４の第１の画像は統合されて、１つのＬＦＲ画像ブロック１４１になる。同様に、各サブシーケンスからの第２の画像も統合されて、低フレームレート画像ブロック１４２になり、各サブシーケンスからの第３の画像及び第４の画像もそれぞれ、画像ブロック１４３及び１４４にパックされる。
【００１２】
本明細書全体を通して、「画像ブロック」という用語は、より高いフレームレートのソースコンテンツからの画像群をタイル化することにより得られるフレームレートがより低い画像の識別に使用され、一方、「画像」は、単独で使用されて、ソースコンテンツの個々のフレーム又はその再構築を指す。異なる実施形態では、画像ブロックは、詳細に後述するように、個々の画像より大きくてもよく、同じサイズであってもよく、又は小さくてもよい。
【００１３】
画像圧縮が望ましいことを証明することができる状況下では、ＬＦＲ画像ブロック１４１〜１４４は、例えば、周知のＪＰＥＧ又はＪＰＥＧ−２０００圧縮方式を使用して個々に圧縮（「符号化」としても知られる）することができる。代替的には、ＭＰＥＧ−２又はＨ．２６４／ＭＰＥＧ−４等のモーションベースの圧縮方式を使用して符号化される場合、ＬＦＲ画像ブロック１４１〜１４４は、符号化された「ピクチャ群」（ＧＯＰ）１４０を形成する。そのようなモーションベースの圧縮方式は通常、３つの種類のフレーム符号化を利用する：Ｉフレーム、Ｐフレーム、及びＢフレーム。Ｉフレームは、「イントラ符号化」フレームを含み、すなわち、Ｉフレームは、他のフレームを全く参照せずに符号化され、したがって、独立することができる。Ｐフレーム又は「予測フレーム」は、１つ又は複数の前の参照フレームに対して符号化されるフレームを構成し、効率的な表現（一般にＩフレームよりも小さい表現）のためにフレーム間の冗長性を利用する。Ｂフレーム又は「双方向予測」フレームは、前後両方の参照フレーム間の類似性を利用することにより符号化される。
【００１４】
Ｐフレーム及びＢフレームでの符号化プロセスの大部分は、圧縮（符号化）を受けるフレームにも存在する参照フレーム内の領域を識別する。そのようなフレームへの符号化プロセスは、そのような共通領域の動きも推定して、動きベクトルとして符号化できるようにする。幾つかの実施形態では、エンコーダは、参照としてＩフレームを使用するのみならず、他のＰフレーム又はＢフレームも同様に使用することができる。現在フレームの領域の動きベクトル表現は通常、領域のピクセルのより明示的な表現よりもコンパクトである。
【００１５】
なお、図１に示されるＬＦＲ画像ブロック１４１〜１４４へのＨＦＲ画像１１１〜１２６のタイル化は、サブシーケンス１３１〜１３４の時間的順序及び順次性を保持し、それにより、ＬＦＲ画像ブロック１４１〜１４４への圧縮（タイル化）後、例えば、サブシーケンス１３１での連続ＨＦＲ画像間の差を維持するという利点を提供する。したがって、ＨＦＲ時間解像度はＬＦＲの時間解像度を超えるため、連続ＨＦＲ画像間で予期される動きベクトルのサイズは一般に、より低いフレームレートで捕捉されたシーケンス（図示せず）の場合よりも小さくなる。同様に、連続して捕捉された画像間の対応する領域は一般に、捕捉フレームレートがより遅い場合よりも多くの類似性を有し、その理由は、ＨＦＲでは被写体の連続画像間で過ぎる時間が短いためである。
【００１６】
本原理による高フレームレート画像のより低いフレームレート画像ブロックへのタイル化は、符号化ＧＯＰ１４０での複合画像の動きを利用する圧縮方式の効率を上げる。それらの複合画像ブロックの各象限内には、連続ＬＦＲ画像ブロック１４１〜１４４間の見掛けの時間増分は、ＧＯＰ１４０の画像ブロック１４１〜１４４の送出がＬＦＲで行われる場合であっても、ＨＦＲに対応する。しかし、現在の符号化ＧＯＰ１４０の最後のＬＦＲ画像ブロック１４４と、次のＧＯＰ（図示せず）の最初のＬＦＲ画像ブロック（図示せず）との間では、時間の不連続性が各象限で生じる。図１の例でのこの時間の不連続性の大きさは、ＬＦＲ間隔では３×又はＨＦＲ間隔では１２×である。この時間不連続性により、あるＧＯＰの末尾と次のＧＯＰの冒頭との類似性を利用しようとする（すなわち、Ｂフレームを使用して）圧縮方式は、特に上手くいかない。したがって、本原理と併用される従来の動き符号化技法は、好ましくは、Ｉフレーム及びＰフレームに制限される。
【００１７】
図２は、対応するフレームレート復元プロセス２００を示す。プロセス２００中、図１の符号化ＧＯＰ１４０に対応し、複合ＬＦＲ画像ブロック２１１〜２１４を表す符号化ＧＯＰ２１０は、ステップ２０１中、復号化され、復号化画像バッファ２２０に記憶するために、ＬＦＲ画像ブロック２１１〜２１４を復元する。したがって、画像バッファ２２０の各象限は、連続ＨＦＲ画像サブシーケンス２２１〜２２４を受信する。ステップ２０２中に実行される出力プロセスは、サブシーケンス２２１〜２２４を再構築高フレームレート画像シーケンス２３０に構成し、このシーケンス２３０は、ステップ２０３中、ＨＦＲ提示２５１として、例えば、表示デバイス２５０に表示するのに適するＨＦＲ画像２３１〜２４６からなる。
【００１８】
１３０及び２２０等の画像バッファが離散した別個の象限（例えば、サブシーケンス１３１〜１３４及び２２１〜２２４を含む象限）又は別個のＬＦＲ画像ブロック平面を必要としないことを当業者は認識する。これらの分離は、その他の点では同質のメモリアレイ内の論理的差異として存在することができるが、他の実施形態では、非常に明確な物理的差異が、例えば、ＦＰＧＡ又はＡＳＩＣ内のＬＦＲ画像ブロック平面及び／又は象限のそれぞれの間に存在して、画像処理パイプラインの特定の符号化又は復号化をサポートすることができる。
【００１９】
本原理による高フレームレート（ＨＦＲ）画像の低フレームレート（ＬＦＲ）画像ブロックへのタイル化では、低フレームレートに従来使用される従来のデバイスにより、編集又は他の動作等のＬＦＲ画像ブロックの処理が可能である。ＬＦＲ画像ブロックが、編集等の１つ又は複数の処理動作を受けると、個々のＨＦＲサブシーケンスは、ステップ２０３中の表示に適するＨＦＲ画像２３１〜２４６からなる再構築画像シーケンス２３０に構成することができる。
【００２０】
図３は、本原理の態様によるＨＦＲ符号化／復号化プロセス３００をフローチャート形態で示す。図３に示されるように、符号化段階３１０は、復号化段階３２０による復号化に適する、例えばビットストリームとして符号化ＧＯＰ１４０を生成する。符号化段階３１０により実行される符号化は、ステップ３０１において、捕捉ステップ１０２中、第１の画像バッファ１３０が受信画像を蓄積するように、ＨＦＲ画像シーケンス１１０を受信することで開始される。この例では、ＨＦＲは通常「４Ｓ」、すなわち、「Ｓ」と示されるＬＦＲの４倍を含む。この実施形態の実際の実装形態では、ＬＦＲである「Ｓ」は、毎秒３０フレーム（ｆｐｓ）を含み得、この場合、４ＳであるＨＦＲは１２０ｆｐｓである。図３のステップ１０３中に行われる符号化は、図１に示される符号化と一致し、ここで、ＧＯＰ内のＬＦＲ画像ブロック数「Ｎ」は４である。これらの「Ｎ」個のＬＦＲ画像ブロックは全体的に、４Ｎ  ＨＦＲ画像、すなわち、１６に対応する。したがって、捕捉バッファ１３０内の考慮中の画像は、連続した番号０．．．４Ｎ−１（すなわち、０．．１５）を有し、選択がインデックス値「ｉ」に従って行われる。「Ｎ」個のＬＦＲ画像ブロックのインデックス付けは、インデックス値「ｊ」に従って行われ、インデックス値ｊは、０〜Ｎ−１（すなわち、０．．．３）の値をとる。ここで、「ｑ」は、値０．．．３をとり、４象限のうちの対応する１つを識別する。この例示的な実施形態では、以下の式が、捕捉バッファ１３０内のＨＦＲ画像と、符号化ＧＯＰ１４０のＬＦＲ画像ブロックへのタイル化との関係を指定する。
式１：
LFR_Image[j].quadrant[q]=HFR_Image[i], j=0...3, q=0..3、但しi=j+qN
符号化ＧＯＰ１４０は、ステップ３０４中、復号化のために別のデバイスにストリーミングすることができるか、又は続けて復号化されるために非一時的ファイルとして記憶し得る。
【００２１】
復号化段階３２０の一実施形態では、受信ストリームは、示されるように、ステップ３０５中、符号化ＧＯＰ２１０として記憶することができる。代替的には、符号化ＧＯＰ２１０は、ファイルとして受信することができる。ステップ３０６で開始されるループの実行中に実行される復元（復号化）は、ここでは、「ｋ」としてインデックス付けられる復号化されるＬＦＲ画像ブロック毎に１回行われ、ここで、ｋは連続して０．．．Ｎ−１（すなわち、０．．．３）である。この復号化は、Ｉフレームのみ又はＩフレーム及びＰフレームの両方で構成される実施形態では良好に機能し、その理由は、ｐフレームは、先行する１つ又は複数のフレームのみを参照できるためである。各ＬＦＲ画像ブロック（例えば、２１１〜２１４）が、復号化及び復号化ＬＦＲ画像ブロックバッファ２２０に記録されると、個々の象限ｑ（０．．３）は復元ＨＦＲ画像「ｍ」に対応するようになり、ここで、ｍは０．．４Ｎ−１（すなわち、０．．１５）であり、ｍ＝４ｑ＋ｋである。復号化ループがステップ３０７において完了するか、又はよりタイトにパイプライン化されたアーキテクチャでは、ＨＦＲフレーム間隔の数分の１だけ早く、出力プロセス２０２は、ｍがインデックス付けられ、ステップ２０３中、例えば、ＨＦＲ表示デバイス２５０に提示可能な再構築画像シーケンス２３０で、復元されたＨＦＲ画像（例えば、２３１〜２４６）を提供する。
【００２２】
図４は、ＨＦＲ符号化／復号化プロセス３００の例示的な実行を示すタイミング図４００を示す。一般に、図４では時間は左から右に進むが、個々の画像内ではそうではない。例えば、サブシーケンス１３１は４つの個々のＨＦＲ画像を含み、したがって、これらの画像は順次提示することができる。しかし、これらの個々のＨＦＲ画像内には、画像捕捉の開始時及び終了時以外の時間的文脈指示は存在しない（例えば、順序又はピクセル、行、若しくは列のタイミングは暗示されない）。同様に、符号化ＧＯＰ１４０を生成する符号化プロセスは、符号化ＧＯＰ１４０が現れたとき（必要に応じて追加の計算時間を加えた時間）に行われるが、個々のＬＦＲ画像ブロック、例えば、画像ブロック１４１は時間的表現ではない。
【００２３】
ＨＦＲフレーム時間４０１は、ＨＦＲの逆数と等しい。第１のサブシーケンス１３１は、図１に示されるように４つの画像１１１〜１１４を含み、ＨＦＲフレーム時間４０１の４倍の期間を含む間隔４０２に広がる。間隔４０３は、ストリーム部分１１０の１６の画像１１１〜１２６（図１から）を提示するための時間を表す。ＬＦＲフレーム時間４０４により表される持続時間は、ＬＦＲの逆数であるが、示される時間に利用可能になるＬＦＲ画像に対応しない。例として、ＬＦＲ画像ブロック１４１は、４つそれぞれのサブシーケンス１３１〜１３４内の最初のＨＦＲ画像からそれぞれ取得される４つの象限を含む。したがって、ＬＦＲ画像ブロック１４１の全体画像内容は、サブシーケンス１３４の最初の画像の受信が完了するまでは、不明確なままである。
【００２４】
同様に、ＬＦＲ画像ブロック１４４の全体画像内容は、サブシーケンス１３４の最後の画像の受信が完了するまでは、不明確なままである。したがって、符号化プロセス１０３は、サブシーケンス１３１の最初のＨＦＲ画像の捕捉が開始された後、幾らかの待ち時間間隔に続けて開始される。ここで、例として、待ち時間は概ね１つのＨＦＲフレーム時間に対応する。間隔４０５は、符号化プロセス１０３の開始から、シーケンス１１０の捕捉完了時まで続く。間隔４０６（一定の縮尺で示されていない）は、符号化プロセス１０３の残りの部分を表す。符号化されると、ＧＯＰ１４０は完全になるが、任意の待ち時間が生じ、この待ち時間は、例として、リアルタイムストリーミング用途では、（ａ）符号化ＧＯＰ１４０を送信可能な状態にするためのセットアップ時間、送信バッファ待機時間、及び実際のネットワーク輸送待ち時間を含む送信待ち時間４０７、（ｂ）ビットストリームセグメント４５０の幅としてここでは表される実際のネットワーク輸送持続時間、並びに（ｃ）受信バッファ待機時間４０８を含む。受信され、バッファに蓄積されたビットストリームセグメント４５０は、符号化ＧＯＰ２１０に対応する。なお、この例では、復号化プロセス２０１が、ビットストリームセグメントの受信完了前であっても、ビットストリームセグメント４５０（例えば、少数の無意味なビットとして本明細書では象徴的に示される符号化ＧＯＰ２１０）からの復号化画像バッファ２２０に配置し始めるように、受信バッファ待機時間４０８は負の値を有する。（代替の実施形態では、この受信バッファ待機時間４０８は、正の値を有することができ、数秒の長さであることができ、より深い受信バッファを提供し、それにより、欠落パケット置換又は順方向誤り訂正技法を可能にすることができる）。
【００２５】
復号化プロセス２０１は、間隔４０９を通して行われ、その間、復号化ＬＦＲ画像ブロックバッファ２２０内に、ＬＦＲ画像ブロックが配置される。バッファ２２０内で、４つのＬＦＲ画像ブロック２１１〜２１４はそれぞれ復号化され、各象限はサブシーケンス２２１〜２２４に対応する（図２のバッファ２２内のサブシーケンス群により示されるように）。出力プロセス２０２は、復元画像シーケンス２３０でのサブシーケンス２２１〜２２４から、順番に、ＨＦＲフレーム間隔毎に１つのレートで復元ＨＦＲ画像２３１〜２４６（図２から）を提供する。この例では、出力バッファ待機時間４１０も負の値を有し、復号化プロセス２０１が復号化ＬＦＲ画像ブロックバッファ２２０の充填を終える前に、画像シーケンス２３０の出力を開始することができることを示す。この例では、待機時間４１０は負の値、ＨＦＲフレーム時間の約３倍の負の値を有し、サブシーケンス２２１の最初の３つのＨＦＲ画像の出力を実行することができるが、サブシーケンス２２１の４番目（最後）の画像の出力には、復号化プロセス２０１がＬＦＲ画像ブロック２１４をバッファ２２０に配置し終えることが必要であることを示唆する。最終的には、合計パイプライン待ち時間４１１は、サブシーケンス１３４が捕捉を終える時間から、サブシーケンス２２４の出力終了に対応する時間まで測定される間隔に対応する。なお、ファイルが後で再生するための時間圧縮画像シーケンスを記憶するように機能する実施形態、符号化プロセス３１０と復号化プロセス３２０との間の間隔は、任意の長い値を有することができる。
【００２６】
図５〜図８は、本発明のわずかに異なる実施形態を示し、各連続ＨＦＲ画像は、そのＬＦＲ画像ブロックが充填されるまで、同じＬＦＲ画像ブロックの異なる象限に配置され、充填後、続くＬＦＲ画像ブロックは同様に構築される。図５は、部分１１０が前述同様に出現するＨＦＲ画像ストリームを生成する同様の作成（又は捕捉）プロセス１０１を使用する第２のフレームレート圧縮プロセス５００を示す。捕捉ステップ５０２中、ストリーム部分１１０の画像１１１〜１２６は捕捉バッファ５３０に蓄積されるが、ＨＦＲ画像１１１〜１１４を含む図１のサブシーケンス１３１等のサブシーケンスは、４つの象限５３１〜５３４（又は他の正則分割）に分配され、それにより、符号化プロセス５０３中、ＬＦＲ画像ブロック５４１〜５４４にパックされる際、ＨＦＲ画像（例えば、画像１１１〜１１４）のサブシーケンスは、１つのＬＦＲ画像ブロック（例えば、画像５４１）にパックされ符号化される。同様に、第２のサブシーケンス（図１の１３２）からのＨＦＲ画像は、ＨＦＲ画像５４２に符号化され、以下同様であり、符号化ＧＯＰ５４０を生成する。
【００２７】
図５の複合ＬＦＲ画像ブロック５４１〜５４４が、図１のＬＦＲ画像ブロック１４１〜１４４とは異なる１つの特定の特性を有することに留意することが重要である：連続ＬＦＲ画像ブロック５４１〜５４４の任意の特定の象限において、対応するＨＦＲ画像間（例えば、左上の象限では、ＨＦＲ画像１１１及び１１５の間、１１５及び１１９の間、１１９及び１２３の間）のタイミング差は、一定のままであり、ＬＦＲ画像ブロックのフレームレートに対応する。これは、符号化ＧＯＰ５４０内のみならず、連続ＧＯＰ間でも当てはまり、一方、連続ＬＦＲ画像ブロック１４１〜１４４の任意の特定の象限では、対応する連続ＨＦＲ画像（例えば、左上の象限では、ＨＦＲ画像１１１及び１１２、１１２及び１１３、１１３及び１１４）からのタイミング差は、一定のままであるが、ＨＦＲ画像のフレームレートに対応するが、この状況は、符号化ＧＯＰ１４０内部でのみ存在し、連続ＧＯＰ間では劇的に異なり、連続ＧＯＰ間では、タイミング差は１２のＨＦＲフレーム間隔（又は３つのＬＦＲ画像ブロック間隔）に跳ね上がる。
【００２８】
不相応に大きい時間ギャップ（１２のＨＦＲ間隔）が、あるＧＯＰの終了時（例えば、符号化ＧＯＰ１４０内のＬＦＲ画像ブロック１４４）及び次のＧＯＰの開始時（図示されていないが、ＧＯＰ内の最初のＬＦＲ画像ブロック１４１と同様）での連続ＬＦＲ画像間の所与の象限内に表されるＨＦＲ画像間に存在する。このため、次のＧＯＰの最初のＬＦＲ画像ブロックがあまりにも類似していないため、ＧＯＰ１４０内の画像を予測するに当たり信頼性の高い値であることができなくなることから、双方向フレーム符号化（Ｂフレーム）を使用したＧＯＰの符号化は適さないままである。図５に示される構成は、ＧＯＰ（例えば、５４０）内又はＧＯＰ間（次のＧＯＰは示されていない）の連続ＬＦＲ画像ブロックのそれぞれが、先行画像ブロックの同様部分間で一定の時間オフセットを有するため、この問題を改善する。したがって、ＧＯＰ５４０のフレームと次のＧＯＰ（図示せず）のフレームとの間での双方向符号化は、ＧＯＰ５４０内のフレーム間の双方向符号化と同じ程度に実用的なままである。
【００２９】
図６は、図５のフレームレート圧縮プロセス５００に対応するフレームレート復元プロセス６００を示す。ここでは、符号化ＧＯＰ６１０は符号化ＧＯＰ５４０に対応し、複合ＬＦＲ画像ブロック６１１〜６１４を表す。復号化プロセス６０１は、符号化ＧＯＰ６１０を受信する。次に、復号化プロセス６０１は、ＬＦＲ画像ブロック６１１〜６１４を復号化画像バッファ６２０内に復元する。したがって、画像バッファ６２０内の各平面は、連続ＨＦＲ画像、例えば、ＨＦＲ画像６３１〜６３４のサブシーケンスを受信する。出力プロセス６０２は、次の平面に進む前に、各象限６２１〜６２４から、第１の平面でのサブシーケンスＨＦＲ画像（例えば、６３１〜６３４）を連続して選択する。最終的には、出力プロセス６０２はＨＦＲ画像６４６を選択し、それにより、画像シーケンス６３０を再構築し、この画像シーケンスは、ステップ６０３中に提示するのに適する、例えば、表示デバイス６５０にＨＦＲ提示６５１として表示するのに適するＨＦＲ画像６３１〜６４６で構成される。なお、ＧＯＰ間双方向符号化が使用されている場合、幾つかのＬＦＲ画像ブロック（例えば、６１２〜６１４）の復号化は、復号化に使用するために、次のＧＯＰ（図示せず）からの最初のＩ符号化ＬＦＲ画像ブロックを受信し、それにアクセスする必要があり得る。上述したように、幾つかの実施形態では、画像バッファ５３０及び６２０は、メモリアレイの論理的区分を含むことができるが、他の例示的な実施形態では、そのようなバッファは、画像処理パイプラインの適切な要素に接続された離散した物理的な画像バッファとして存在することができる。
【００３０】
図７は、フローチャート形態で示される別のＨＦＲ符号化／復号化プロセス７００を示し、符号化段階７１０は、復号化段階７２０による復号化に適する符号化ＧＯＰ５４０を生成し、ＧＯＰは、例えば、ビットストリーム又はファイルとして転送される。符号化段階７１０により実行される符号化は、ステップ７０１中に開始され、それにより、ＨＦＲ画像シーケンス１１０が受信されると、供給された画像のバッファへの蓄積が、捕捉段階５０２中に行われる。ここでも、この例では、ＨＦＲは４Ｓを含み、すなわち、「Ｓ」と見なされるＬＦＲの４倍を含む。ここでも、この例では、ＬＦＲである「Ｓ」は、毎秒３０フレーム（ｆｐｓ）の値を有することができ、この場合、４ＳであるＨＦＲは１２０ｆｐｓである。図７に示される符号化プロセス５０３は、図５に示されるものと一致したままであり、ここで、ＧＯＰ内のＬＦＲ画像ブロック数「Ｎ」は４である。これらの「Ｎ」個のＬＦＲ画像ブロックは全体的に、４Ｎ  ＨＦＲ画像、すなわち、１６に対応する。したがって、捕捉バッファ５３０内の考慮中の画像は、連続した番号０．．．４Ｎ−１（すなわち、０．．１５）を有し、インデックス値「ｉ」によりインデックス付けられる。「Ｎ」個のＬＦＲ画像ブロックは、「ｊ」によりインデックス付けられ、インデックス値ｊは、０〜Ｎ−１（すなわち、０．．３）の値をとる。ここで、インデックス「ｑ」は、値０．．．３をとり、４象限を識別する。この例示的な実施形態では、以下の式が、捕捉バッファ５３０内のＨＦＲ画像と、符号化ＧＯＰ５４０のＬＦＲ画像ブロックへのタイル化との関係を指定する。
式２：
LFR_Image[j].quadrant[q]=HFR_Image[i], j=0..3, q=0..3、但しi=jN+q
なお、式（２）は、インデックス値「ｉ」の計算に関して式（１）と異なる。符号化ＧＯＰ５４０は、ステップ７０４中、復号化のために、又は非一時的ファイルとして記憶されて、続けて復号化されるために、別のデバイスにストリーミングすることができる。
【００３１】
ＧＯＰの符号化が連続ＧＯＰ間の双方向符号化を含む実施形態では、あるＧＯＰを符号化するには、次のＧＯＰ（図示せず）の少なくとも一部を準備する必要があり得る。
【００３２】
図７の復号化段階７２０の例示的な実施形態では、ステップ７０５中に示されるように、ストリームを受信し、符号化ＧＯＰ６１０として記憶することができる。代替的には、符号化ＧＯＰ６１０は、ファイルとして受信することができる。符号化／復号化プロセス３００とは異なり、復号化段階７２０の幾つかの実施形態は、次のＧＯＰからの情報を必要とする双方向符号化方式を使用する場合に生じるように、符号化ＧＯＰ６１０のみならず、符号化段階７１０からの連続した次の符号化ＧＯＰ（図示せず）も必要とし得る。ステップ７０６で開始されるループ中に実行される復元（復号化）は、ここでも、「ｋ」としてインデックス付けられる復号化されるＬＦＲ画像ブロック毎に１回行われる。しかし、図３の復号化プロセス３２０中、インデックス値ｋは、Ｉフレーム及びＰフレームのみを符号化に使用する場合、ｋは連続して０．．．Ｎ−１（すなわち、０．．３）であることができるが、本復号化プロセス７２０はＢフレームを利用し、この場合、ｋの適切な値のシーケンスは連続しない。むしろ、特定のＢフレームの復号化に必要なＩフレーム及び／又はＰフレームは、必要なフレームのうちの少なくとも１つが時間順でＢフレームの後に来る場合であっても、Ｂフレームの前に復号化される。ｋ番目のＨＦＲ画像が復号化され、復号化ＬＦＲ画像ブロックバッファ６２０に記憶されると、個々の象限ｑ（０．．３）は復元ＨＦＲ画像「ｍ」に対応するようになり、ここで、ｍは０．．．４Ｎ−１（すなわち、０．．１５）であり、ｍ＝４ｋ＋ｑである。２つの連続ＧＯＰ間にＢフレーム符号化を利用する実施形態では、次のＧＯＰ（図示せず）の少なくとも部分的な復号化後に生じ得る、復号化ループ７０７が完了する場合、出力プロセス６０２は、ｍがインデックス付けられ、ステップ６０３中、例えば、ＨＦＲ表示デバイス６５０に提示可能な再構築画像シーケンス６３０で、復元されたＨＦＲ画像ブロック（例えば、ブロック６３１〜６４６）を提供する。
【００３３】
図８は、ＨＦＲ符号化／復号化プロセス７００の例示的な一実行を示すタイミング図８００を示す。図８において、この図では時間は左から右に進むが、個々の画像内ではそうではなく、例えば、サブシーケンス５３１は４つの個々のＨＦＲ画像を含む。これらの画像は順次提示される。しかし、それらの個々のＨＦＲ画像内には、画像捕捉の開始時及び終了時以外の時間的文脈指示が存在する（例えば、順序又はピクセル、行、若しくは列のタイミングは暗示されない）。同様に、符号化ＧＯＰ５４０を作成する符号化プロセスは、符号化ＧＯＰ５４０が現れたとき（必要に応じて追加の計算時間を加えた時間）に行われるが、個々のＬＦＲ画像、例えば、５４１は時間的表現ではない。
【００３４】
ＨＦＲフレーム時間８０１は、ＨＦＲの逆数に相当する。第１のサブシーケンス５３１は、４つの画像１１１〜１１４（図５から）を含み、ＨＦＲフレーム時間８０１の４倍の期間を含む間隔８０２にわたって現れる。間隔８０３は、ストリーム部分１１０の１６の画像１１１〜１２６（図５から）を提示するための期間を表す。ＬＦＲフレーム時間８０４により表される持続時間は、ＬＦＲの逆数に相当するが、必ずしも、示される時間に利用可能になるＬＦＲ画像ブロックに対応する必要はない。例として、ＬＦＲ画像ブロック５４１は、最初のＨＦＲサブシーケンス、すなわち、ＨＦＲ画像１１１〜１１４からそれぞれ取得される４つの象限で構成される。しかし、ＬＦＲ画像ブロックの符号化は、続くＬＦＲ画像ブロック（例えば、ＬＦＲ画像ブロック５４２〜５４４のうちの１つ又は複数）の内容に関する情報を必要とし得る。幾つかの実施形態では、後のＬＦＲ画像ブロック（例えば、ＬＦＲ画像ブロック５４４）の符号化は、続くＧＯＰ（図示せず）からの最初のＬＦＲ画像ブロックの受信が完了するまで、行うことができない。符号化プロセス５０３は、サブシーケンス５３１の最初のＨＦＲ画像の捕捉が開始された後、幾らかの待ち時間間隔に続けて開始される。間隔８０５は、符号化プロセス５０３の開始から、シーケンス５１０の捕捉完了時まで続く。次のＧＯＰからの情報に依存する実施形態では、間隔８０２’は、次のサブシーケンス５３５のＨＦＲ画像（図示せず）を捕捉する時間を表す。間隔８０６は、符号化プロセス５０３の残りの持続時間を表す。符号化ＧＯＰ５４０が完成すると、任意の待ち時間が生じ、この待ち時間は、例として、リアルタイムストリーミング用途では、（ａ）符号化ＧＯＰ５４０を送信可能な状態にするためのセットアップ時間、送信バッファ待機時間、実際のネットワーク輸送待ち時間を含む送信待ち時間８０７、（ｂ）ビットストリームセグメント８５０の幅としてここでは表される実際のネットワーク輸送持続時間（上記のビットストリーム４５０と同様に、ここでは、少数の無意味のビットとして象徴的に示される）、及び（ｃ）受信バッファ待機時間８０８を含む。受信され、バッファに蓄積されたビットストリームセグメント８５０は、符号化ＧＯＰ６１０に対応する。
【００３５】
なお、この例では、復号化プロセス６０１が、ビットストリームセグメント８５０の受信完了前であっても、ビットストリームセグメント８５０（符号化ＧＯＰ６１０）からの復号化画像バッファ６２０に配置し始めるように、受信バッファ待機時間８０８は負の値を有する。（代替の実施形態では、この受信バッファ待機時間８０８は、数秒の長さの正の値を有することができ、深い受信バッファ期間を提供し、それにより、欠落パケット置換又は順方向誤り訂正技法を可能にすることができる）。復号化プロセス６０１は進み、間隔８０９の完了まで、復号化ＬＦＲ画像ブロック６１１はバッファ６２０内に配置される。バッファ６２０内で、４つのＬＦＲ画像ブロック６１１〜６１４はそれぞれ復号化されるが、必ずしも、含まれるＨＦＲ画像の捕捉時間に対応する順序である必要はない。復号化が完了する前にＨＦＲ画像が表示に必要になることがないように、出力プロセス６０２の開始が早すぎないよう、タイミングに注意しなければならない。最初の複合ＬＦＲ画像ブロック６１１の画像は準備でき得るが、連続ＬＦＲ画像ブロック（例えば、ブロック６１２〜６１４）は、先のフレームを復号化するには、その前に後のフレームが必要となり得るため、Ｂフレーム符号化を使用する実施形態では、各連続ＨＦＲフレーム時間で準備することができないことがある。出力プロセス６０２は、再構築フレームシーケンス６３０において、順番にＨＦＲフレーム間隔毎に１つずつ、復元ＨＦＲフレーム６３１〜６４６（図６から）を提供する。この例では、出力バッファ待機時間８１０も負の値を有し、幾つかの実施形態では、復号化プロセス６０１が復号化ＬＦＲ画像ブロックバッファ６２０の充填を終える前に、画像シーケンス６３０の出力を開始することができることを示す。この例では、待機時間８１０はＨＦＲフレーム時間の約−１倍の値として現れるが、待機時間８１０は主に、Ｂフレーム符号化の場合に特定され、その理由は、４番目のサブシーケンス６２４の復号化及び出力が、次のＧＯＰ８６０の少なくとも一部にアクセスし、バッファ待機時間８０８’がバッファ待機時間８０８と同様であるバッファ築器及び復号化（図示せず）を受ける必要があるためである。最終的に、合計パイプライン待ち時間８１１は、サブシーケンス５３４が捕捉を終える時間から、対応するサブシーケンス６２４の出力終了時間までの時間間隔である。ここでも、ファイルが後で再生するための時間圧縮画像シーケンスを記憶するように機能する実施形態では、符号化プロセス７１０と復号化プロセス７２０との間の間隔は、任意の長い値を有することができる。
【００３６】
図９は、別個のＨＦＲ符号化プロセス９１０及びＨＦＲ復号化プロセス９２０を示す、ＨＦＲ符号化／復号化技法９００の簡易ブロック図を示す。符号化プロセス９１０は、ステップ９１１において、ＨＦＲ画像を受信するようにバッファを準備することで開始される。ステップ９１２中、バッファは、ファイル又は画像を表すビットストリームとして、ＨＦＲ画像を取得する。ステップ９１３中、各ＬＦＲ画像ブロックへの複数のＨＦＲ画像のパックが行われる。幾つかの実施形態では、メタデータは、２つ以上のパックパターンが利用可能な場合、使用される特定のパックパターンを通知することができる。このメタデータは、各ＬＦＲ画像ブロックを伴ってもよく、又は複数のＬＦＲ画像ブロックを伴ってもよい（例えば、実施形態に応じて、各符号化ＧＯＰ内、ＬＦＲ画像ブロックストリーム内に定期的に、符号化されるか否か、又は特定のコンテンツに対して１度のみ）。任意選択的に、ステップ９１４中、ＬＦＲ画像ブロックは圧縮されて、よりコンパクトな表現を提供することができる。ＬＦＲ画像ブロックを表すデータは、圧縮されるか否かに関わらず、ステップ９１５において、非一時的ファイルとして、例えば、コンピュータメモリ若しくはリムーバブル媒体（例えば、ＤＶＤのような）において、又はビットストリームとして配信される。符号化プロセス９１０は、ステップ９１６において終了する。
【００３７】
復号化プロセス９２０は、ステップ９２１において、ＬＦＲ画像ブロックとしてフレームレート圧縮ＨＦＲ画像を受信するようにバッファを準備することで開始される。ステップ９２２において、ＬＦＲ画像ブロックが受け入れられる。任意選択的に、ステップ９２３中、ＬＦＲ画像ブロックは復元される（例えば、ステップ９１４などで圧縮された画像ブロックの場合）。ステップ９２４中、ＬＦＲ画像ブロックのアンパックが、ＬＦＲ画像ブロックからの各ＨＦＲ画像を選択し、そのＨＦＲ画像を表示又は送信のために提供することにより行われる。代替の実施形態では、表示のためにＨＦＲ画像を提供する代わりに、アンパックステップ９２４は、アンパックＨＦＲ画像を後で使用するために非一時的形態で記憶することができる。復号化プロセス９２０は、ステップ９２５において終了する。
【００３８】
したがって、これまで考察した例は、４：１の率でフレームレート圧縮される、すなわち、４つのＨＦＲ画像が各ＬＦＲ画像ブロックにパックされ、ＬＦＲ画像ブロックのフレームレートがＨＦＲ画像の１／４であるＨＦＲ画像を参照している。図１０は、幾つかの代替のＨＦＲパックパターン例を限定ではなく例として示す。図１０では、パックパターン１０１０は、上記の図５と同様のパックパターンを再現しており、４つのＨＦＲ画像０．．３が１つのＬＦＲ画像ブロックにまとめられ、したがって、ＨＦＲはＬＦＲの４倍である。図１０の一構成のパターン１０１０では、各軸でのＬＦＲ解像度はＨＦＲ画像の２倍であり、すなわち、ＬＦＲ画像ブロックは、１つのＨＦＲ画像の４倍のピクセルを有し、ＨＦＲ画像の各ピクセルは、ＬＦＲ画像ブロックの全ピクセルにより表される。個々のＨＦＲ画像内部の円は、ＨＦＲ画像の元のアスペクト比（これらの例全体を通して１６：９）がＬＦＲ画像ブロック（同様にアスペクト比１６：９を有する）にパックされる間にわたり維持されることを示す。
【００３９】
パックパターン１０１０を使用する別の実施形態では、ＨＦＲ画像及びＬＦＲ画像ブロックは同じサイズを有することができ、すなわち、両方とも同じ解像度を有することができ、その場合、各ＨＦＲ画像の解像度は、ＬＦＲ画像ブロックにパックされる場合、復元され、元の解像度に復元（再スケーリング）される際、わずかにぼける（すなわち、幾らかの細部を失う）ことを犠牲として低減する（より低い解像度にスケーリング又はデシメーションされる）。同様に、ＨＦＲ画像がＬＦＲ画像ブロックの解像度の半分未満である（各軸で）が、略同じアスペクトル比を有さない他の実施形態では、ＨＦＲ画像はそれに従ってスケーリングされて、パックパターン１０１０を達成し、アンパック時、表示のために元の解像度（しかし、やはり幾らかの細部を失う）又は異なる解像度に復元することができる。ソース画像をスケールダウンし、後に欠落情報を再補間する必要がある場合、単純なスケーリングの代わりに５点形のような線他のデシメーションパターンを使用することもできる。
【００４０】
パックパターン１０３０は、異なるパック構成を示し、「アナモルフィックパック」を示し、すなわち、ＨＦＲ画像の横軸及び縦軸は、ＬＦＲ画像ブロックにパックされるとき、異なるスケーリング値を有する。横軸及び縦軸のこの非対称スケーリングは、元のＨＦＲ画像及びＬＦＲ画像ブロックが異なるアスペクト比を有する場合、又はここに示されるように、水平タイル化及び垂直タイル化が等しくないため、必要とされ得る。パックパターン１０３０に見られるように、６つのＨＦＲ画像０．．５は、３×２アレイ（水平タイル化３は、垂直タイル化２と等しくない）で１つのＬＦＲ画像ブロックにパックされる。したがって、この例では、ＨＦＲはＬＦＲの６倍である。このパックパターンの一例では、ＬＦＲ画像ブロックは、各軸で、元のＨＦＲ画像の２倍の解像度を有する。ここでも、元のＨＦＲ画像及びＬＦＲ画像ブロックは、同じアスペクト比を有する。しかし、これは、解像度を幾らかを失わなければ、４つのＨＦＲをパックする余地しか残さない。画像全体を均一にスケーリングするのではなくむしろ、アナモルフィック圧縮が適用され、円を楕円形に変える。３つのＨＦＲ画像は、前は２つのＨＦＲ画像で占められていた水平解像度に圧縮され、すなわち、３：２水平圧縮である。縦軸では、これらのＨＦＲ画像は圧縮されず、アンパック時、横軸は２：３拡大を受け、元のＨＦＲ画像解像度を復元するが、水平細部は幾らか失われる。
【００４１】
考察したようなフレームレート圧縮は、立体画像に適用することもできる。パックパターン１０２０は２つの立体対：左右目対「０」（「０Ｌ」は対０の左画像であり、「０Ｒ」は右画像である）及び左右目対「１」（同様に示される）を示す。パックはパターン１０１０と同様であり、４つの画像が１つのＬＦＲ画像ブロックにパックされるが、ここでは、ＨＦＲはＬＦＲの２倍に達するのみであり、その理由は、各フレーム間隔で、立体対の左画像及び右画像という２つの画像が必要なためである。このパックパターンでは、左画像は左側に見られ、右画像は右側に見られる。
【００４２】
パックパターン１０４０も立体画像対に適用されるが、ここでは、左目画像０Ｌ、１Ｌ、２Ｌは上に見られ、右目画像０Ｒ、１Ｒ、２Ｒは下に見られる。ＨＦＲはＬＦＲの３倍である。画像は、パターン１０３０と同様に、アナモルフィック圧縮を用いてパックされ、画像の横軸は３：２で圧縮される。再構築画像の品質を強化するためには、基本スケーリングの代わりに碁盤目状のデシメーションを使用することもできる。
【００４３】
更に、ＨＦＲ画像は、ＬＦＲ画像ブロックにパックされる際、回転することができる。この例はパックパターン１０５０に見られる。パターン１０４０にパックされたものと同様の３つの立体画像対は、９０°回転され、１つのＬＦＲ画像ブロック内の１行としてパックされた。一実施形態では、これらのＨＦＲ画像の元の水平解像度は、ＬＦＲ画像ブロックの垂直解像度未満であり、したがって、元のＨＦＲ画像の横軸はスケーリングされず、未使用のＬＦＲ画像ブロックスペース１０５１の領域が残る。しかし、ＨＦＲ画像の元の垂直解像度は、ＬＦＲ画像ブロックの水平解像度の１／６を超え、６つをパックするには、ＨＦＲ画像を２７：１６で圧縮する必要がある。全圧縮、したがって、細部の損失は、パターン１０４０よりもパックパターン１０５０で大きく、元のＨＦＲ画像の横軸をそのままにする。これは、立体３Ｄ効果の知覚が水平方向でのわずかな左目画像と右目画像との差により強く影響される立体画像で特に有利であることができる。この例では、９０°回転は、元のＨＦＲ画像の横軸を保持し、したがって、３Ｄ効果の知覚に関して水平細部をよりよく保持する。別の利点は、パッシブ立体ディスプレイが左画像及び右画像をインターレースし、したがって、垂直解像度の半分のみを既に使用するが、水平解像度の１００％を使用し、したがって、水平細部の保存が、それらのディスプレイ上で優れた画像を提供することである。
【００４４】
これらの原理を使用して、多くの異なるパックパターンを開発することができる。システムが１つのパックパターンのみを適用又は受信する場合、符号化は均一である。しかし、複数のパックパターンを使用するシステムの場合、メタデータを提供して、何れのパックパターンがいつ適用されているのかを示すべきである。そのようなメタデータは、各パックパラメータの個々の設定、例えば、ＬＦＲ画像ブロック内のＨＦＲ画像シーケンス、垂直及び水平圧縮比、回転、ＨＦＲ画像が３Ｄであるか否か、左目画像及び右目画像が配置される場所、ＨＦＲフレームレートとＬＦＲフレームレートとの比率、又はＨＦＲフレームレートの規定を提供することができる。パラメータの可能な全ての組合せの中からの少数の特定の組合せが、システムで使用される場合、それらの各組合せを使用して、対応する「モード」を定義し得、それにより、メタデータは、個々の各パラメータを独立して識別するのではなくむしろ、単に使用されている「モード」を識別するのみでよい。
【００４５】
図１１及び図１２はそれぞれ、ＨＦＲ画像をＬＦＲ画像ブロックにパックする幾つかの符号化方式例を示す。これらの例は、６つのＨＦＲ画像が各ＬＦＲ画像ブロックにパックされるパック方式１０３０に基づく。図１１は、パックされたＬＦＲ画像ブロック１１０１〜１１０４を示し、連続ＨＦＲ画像が群の連続ＬＦＲ画像ブロックに挿入される。楕円形内の数字は、捕捉ストリーム部分内の元の時間順を示す。表１１０５は、列１１１０に列挙される特定のＨＦＲ画像の符号化を記述する４つの異なる例示的な符号化方式１１２０、１１３０、１１４０、及び１１５０を識別する。括弧１１０６は、現在のＧＯＰのリミットを識別する。ＨＦＲ画像２４についての最下行は、次のＧＯＰを開始する。
【００４６】
符号化１１２０の列は、ＬＦＲストリームの従来のＩフレーム及びＰフレーム符号化を表す。最初のＬＦＲ画像ブロック１１０１は、Ｉフレームとして符号化され、すなわち、フレーム内符号化のみが使用され、いかなる他のフレームも参照せずに復号化することができる。これは、列１１２０の最初の６行のそれぞれにおいて「Ｉ」で示され、それぞれ最初のＬＦＲ画像ブロック１１０１内の６つのＨＦＲ画像に対応する。次のＬＦＲ画像ブロック１１０２〜１１０４はＰフレームとして符号化され、それぞれの復号化のために、復号化されたＩフレーム１１０１にアクセスする必要がある。ＧＯＰ１１０６を復号化するために、次のＧＯＰへの参照は必要とされず、このことは図１１全体を通して当てはまる。
【００４７】
符号化１１３０は幾らかのＢフレーム符号化を使用するが、厳密にＧＯＰ１１０６内である。２番目及び３番目のＬＦＲ画像ブロック１１０２及び１１０３は、Ｉフレーム符号化された最初のＬＦＲ画像ブロック１１０１及びＰフレーム符号化された４番目のＬＦＲ画像ブロック１１０４を使用して符号化されたＢフレームである。
【００４８】
符号化１１４０は、１つのフレーム内のスライス符号化という新しい概念を導入し、スライスを使用して、ＬＦＲ画像ブロック内にパックされた個々のＨＦＲ画像を表す。ここで、ＬＦＲ画像ブロック１１０１の符号化は、ＨＦＲ画像０、８、及び１６に対応してＩスライスを使用し、それに対応して、ＨＦＲ画像４、１２、及び２０ではそれらのＩスライスに基づくＰスライスを使用する。３番目のＬＦＲ画像ブロック１１０３内の各ＨＦＲ画像２、６、１０、１４、１８、２２はそれに対応して、最初のＬＦＲ画像ブロック１１０１内の先のＩフレームからとられるＰスライスとして表される（又は実装形態に応じて、適する場合、先のＰスライスから導出することができる）。２番目のＬＦＲ画像ブロック１１０２は、ここでは、Ｂスライスの集まりとして符号化され、各Ｂスライスは、対応する前後のＩスライス及び／又はＰスライスを参照する。例えば、ＨＦＲ画像１は、ＨＦＲ画像０に対応するＩスライス及びＨＦＲ画像２に対応するＰスライスに基づいて、Ｂスライスとして符号化される。ＨＦＲ画像５は、ＨＦＲ画像０に対応するＩスライス（又はＨＦＲ画像４の場合、Ｐスライス）及びＨＦＲ画像６に対応するＰスライスに基づいて、Ｂスライスとして符号化することができる。４番目のＬＦＲ画像ブロック１１０４は、３番目のＬＦＲ画像ブロック１１０３の先のＰスライス及び最初のＬＦＲ画像ブロック１１０１からの（時間的に）後のＩスライス又はＰスライスに基づいて、大半はＢスライスとして符号化される。
【００４９】
なお、４番目のＬＦＲ画像ブロック１１０４のＢスライスでは、各Ｂスライスは、３番目のＬＦＲ画像ブロック１１０３の対応する先のＰスライスの位置と一致する画像ブロック１１０４内の位置を保持するが、このことは、最初のＬＦＲ画像ブロック１１０１内の対応する後のＩスライス又はＰスライスに関しては当てはまらず、これらの場合、後のスライスは画像ブロック１１０１で異なる位置を保持し、この特性は本明細書では「スライスオフセット」と呼称される。対応する後のスライスは、イントラフレームパックシーケンス内の次の位置に対応する位置を占める（例えば、ＬＦＲ画像ブロック１１０４内のＨＦＲ画像７を表すスライスの復号化に必要な後のＩスライスは、ＨＦＲ画像８を表すスライスであり、ＬＦＲ画像ブロック１１０１でのその位置は、ＨＦＲ画像７の後でＬＦＲ画像ブロック１１０４にパックされる次のＨＦＲ画像であるＨＦＲ画像１１の位置と対応する）。例外は、ＨＦＲ画像２３の符号化であり、この符号化は、ＧＯＰ１１０６外部のＨＦＲ画像データを参照するのではなくむしろ、Ｐスライスとして示され、それにより、ＧＯＰ１１０６を別のＧＯＰを参照せずに完全に復号化できるようにする。
【００５０】
図１の表１１６０は、表現効率の粗い推定を示し、Ｉフレーム（又はＩスライス）の符号化は、１．０に正規化され、それにより、Ｐフレーム（又はＰスライス）は空間の約１／２（０．５）を消費し、Ｂフレーム（Ｂスライス）は約１／４（０．２５）を消費する。行１１７０は、各列のこれらの表現効率の和を示し、２４．０は、全てＩフレーム（Ｉスライス）の符号化ＧＯＰのサイズである。行１１８０は、全てＩフレームの符号化と比較した、各符号化方式の効率％を示す。
【００５１】
図１２は、パックされたＬＦＲ画像ブロック１２０１〜１２０４を示し、連続ＨＦＲ画像は、そのＬＦＲ画像ブロックが完全にパックされるまで、同じＬＦＲ画像ブロックに挿入される。続くＨＦＲ画像は、次のＬＦＲ画像ブロックに、それが埋まるまでパックされ、以下同様である。ここでも、楕円形内部の数字は、捕捉ストリーム部分内の元の時間順を示す。表１２０５は、列１２１０に列挙される特定のＨＦＲ画像がいかに符号化されるかを記述する４つの異なる符号化方式例１２２０、１２３０、１２４０、及び１２５０を識別する。括弧１２０６は、現在のＧＯＰのリミットを識別するが、後述するように、符号化方式１２４０及び１２５０のみに該当する。ＨＦＲ画像２４についての最下行は、次のＧＯＰを開始する。
【００５２】
符号化１２２０の列は、各ＬＦＲ画像ブロックが厳密にフレーム内符号化される（すなわち、ＬＦＲ画像ブロックの符号化が、いかなる他の画像ブロックも参照せずに達成される）。しかし、各フレーム内で、１つのみのスライス（ＨＦＲ画像０、６、１２、及び１８に対応する）がスライス内符号化され、他の各スライス（ＬＦＲ画像ブロック１２０１内のＨＦＲ画像１．．．５に対応する）は、Ｉスライスに対するＰスライスとしてスライス間符号化される。１つのＬＦＲ画像ブロック内で、任意のＰスライスを復号化する前に、Ｉスライスを復号化しなければならないことに留意する。これは、画像内のスライスが、並列プロセッサにより別個に独立して復号化可能であることを予期し、Ｐスライスが前の画像（ここでは、前のＬＦＲ画像ブロック）で復号化されたＩスライスを参照する従来技術による幾つかの復号化技法と異なり得る。例えば、Ｉスライスが複数のタイルで構成される場合、並列処理をやはりサポートすることが可能であることにも留意し、各タイルを別個に独立して処理することができ、その後、同じＬＦＲ画像ブロック内の復号化されたＩスライスを参照して、Ｐスライス（タイル化等される）を別個に独立して処理することができる。更に、スライス及びタイルの並列処理に関するここでのコメントが、これらの符号化例のうちの他の符号化例でも当てはまり得るが、簡潔にするために、主題をその都度再考しないことに留意する。符号化１２２０でのあらゆるＬＦＲ画像ブロックは、フレーム内符号化されるため、ＧＯＰ長は事実上１である（したがって、括弧１２０６は該当しない）。各ＬＦＲ画像ブロックは、独立して復号化することができる。
【００５３】
ＬＦＲ画像ブロック１２０１にパックされるＨＦＲ画像が連続しており、したがって、スライス間符号化から恩恵を受ける可能性が高く、一方、ＬＦＲ画像ブロック１１０１では、ＨＦＲ画像は時間的に更に離れて離間され、その場合、スライス間符号化の価値の低下（完全にはなくならないが）が予期されることに起因して、列１２２０の符号化方式が１１２０といかに異なるかに留意する。
【００５４】
符号化１２３０は、全体を通してイントラフレームのままである。したがって、符号化１２３０の有効ＧＯＰ長も１である。しかし、符号化１２３０はＢスライス符号化を使用する。各ＬＦＲ画像ブロック内で、最初（例えば、ＨＦＲ画像０）はＩスライス符号化され、最後（例えば、ＨＦＲ画像５）はＰスライス符号化される。残りのＬＦＲ画像ブロック１．．４はＢスライスであり、処理を可能にするには、ＬＦＲ画像ブロック０及び５の復号化を必要とし、その理由は、Ｂスライスが、周囲の時間的に最近傍のＩスライス及び／又はＰスライスに関して符号化されるためである。
【００５５】
符号化１２４０は、全てのフレームにフレーム間符号化を使用する（これは典型的な実施ではない）。ＬＦＲ画像ブロック１２０１内のＨＦＲ画像０のＩスライスは、最初に復号化されなければならず、次に、次のＬＦＲ画像ブロック１２０２内のＰスライスを復号化しなければならない。その次でのみ、ＬＦＲ画像ブロック１２０１（ＨＦＲ画像１〜５を表す）内のＢスライスを復号化することができ、それにより、ＧＯＰ１２０６内の最初のＬＦＲ画像ブロック１２０１は別の画像に依存する。同様に、連続ＬＦＲ画像ブロック１２０３及び１２０４内のＰスライスも、ＬＦＲ画像ブロック１２０２及び１２０３のそれぞれ内のＢスライス前に復号化されなければならない。ＬＦＲ画像ブロック１２０４内のＢスライス（ＨＦＲ画像１９〜２３に対応する）が復号化され得るには、その前に、次のＧＯＰの冒頭にあり、ＨＦＲ画像２４に対応するＩスライスを受信し復号化しなければならない。
【００５６】
符号化１２５０はこれを極端にしたものであり、ＧＯＰ１２０６内のＬＦＲ画像ブロックは、まず、次のＧＯＰの少なくとも最初の部分を受信して、Ｉスライス符号化ＨＦＲ画像２４を取得せずには、復号化することができず、その理由は、全てのＨＦＲ画像１．．．２３が、ＨＦＲ画像０及び２４に依存するＢスライスであるためである。
【００５７】
符号化１２４０及び１２５０は、独立したＩスライス又はＬＦＲ画像ブロック１２０１内のＨＦＲ画像０を表すＩスライスに依存するＰスライスとして、ＧＯＰ１２０６内の最後のＨＦＲ画像２３を符号化することにより、ＧＯＰ間の依存性を壊すことができる。
【００５８】
表１２６０は、表現効率の粗い推定を示し、Ｉフレーム（又はＩスライス）の符号化はここでも、１．０に正規化され、それにより、Ｐフレーム（又はＰスライス）は空間の約１／２（０．５）を消費し、Ｂフレーム（Ｂスライス）は約１／４（０．２５）を消費する。行１２７０は、各列のこれらの表現効率の和を示し、２４．０は、全てＩフレーム（Ｉスライス）の符号化ＧＯＰのサイズである。行１２８０は、全てＩフレームの符号化と比較した、各符号化方式の効率％を示す。符号化１１３０においてＩフレーム、Ｐフレーム、Ｂフレームにより提供される５０％効率（行１１８０から）と比較して、フレーム内符号化１２３０（イントラフレームは使用するが、フレーム内のＩスライス、Ｐスライス、及びＢスライスは使用しない）は略１０％より効率的であり（行１２８０から４２％）、一方、フレーム間／スライス間符号化１２４０は約２０％より効率的である（行１２８０から３１％）。
【００５９】
２つ以上の符号化パターンが可能な実施形態では、Ｉフレーム、Ｐフレーム、及びＢフレーム（例えば、符号化例１１２０、１１３０）及び／又はＩスライス、Ｐスライス、及びＢスライス（例えば、符号化例１１４０、１１５０、１２２０、１２３０、１２４０、及び１２５０）の符号化パターンを記述する追加のメタデータを提供することができる。
【００６０】
図１３は、ＨＦＲ／ＬＦＲエンコーダ１３２０及びＬＦＲ／ＨＦＲデコーダ１３４０を含む高フレームレート処理システム１３００の一例のブロック図を示す。例として、ＨＦＲカメラ１３１１は、一連のＨＦＲ画像をＨＦＲ／ＬＦＲエンコーダ１３２０のＨＦＲ画像受信モジュール１３２１に提供する。ＨＦＲ画像受信モジュール１３２１は、受信したＨＦＲ画像をバッファ１３２２に書き込む。十分なＨＦＲ画像がバッファ１３２２に蓄積すると、ＬＦＲ画像ブロック出力モジュール１３２３は、ＬＦＲ画像ブロック（上述したように、その中にタイル化された高フレームレート画像を有する）を出力する。実際には、ＬＦＲ画像ブロックモジュール１３２３は、即時送信するか、又は後で使用するために、ＬＦＲ画像ブロックをＬＦＲ画像ストリーム又はファイル１３３０として出力する。代替の実施形態では、ＬＦＲ画像ブロック圧縮モジュール１３２４は、バッファ１３２２にアクセスして、結果として圧縮されたＬＦＲ画像ブロックを圧縮ＬＦＲ画像ストリーム又はファイル１３３１として出力することができる。これに関して、ＬＦＲ画像ブロック圧縮モジュール１３２４も、ＨＦＲ画像を少なくとも１つのＬＦＲ画像ブロックにタイル化する。ＬＦＲ画像ブロック出力モジュール１３２３又は圧縮ＬＦＲ画像ブロック出力モジュール１３２４は、画像ブロックタイル化又は圧縮の性質を示すメタデータを供給し得る。ＨＦＲ画像受信モジュール１３２１、バッファ１３２２、及びＬＦＲ画像ブロック出力モジュール１３２３（又はＬＦＲ画像ブロック圧縮器１３２４）で構成されるのではなくむしろ、ＨＦＲ／ＬＦＲエンコーダは、これらの要素の集合的機能を実行する１つのプロセッサ又は同様のデバイス（図示せず）で構成することができる。
【００６１】
なお、ＬＦＲストリーム又はファイル１３３０及び／又は圧縮ＬＦＲストリーム又はファイル１３３１は、ＭＰＥＧ（Moving Pictures Expert Group）により記述される等の既存の動画ストリーム又はファイル形式の形態をとることができる。幾つかの実施形態では、ＨＦＲ／ＬＦＲエンコーダ１３２０は、ＨＦＲ画像を取得し（例えば、カメラ１３１１から）、それらをＨＦＲと比較して、ＬＦＲ形式を含む周知の動画形式にパッケージする。そのような符号化の例は、図１１の表１１０５の列１１２０及び１１３０に見られる。例として、表１１０５の残り及び図１２の表１２０３は、圧縮ＬＦＲストリーム又はファイル１３３１の形式が、従来技術による形式と異なり、ＬＦＲ画像ブロック１３３０のタイル化性質に起因して存在し得る冗長性を利用する他の実施形態を表す。
【００６２】
ＬＦＲストリーム又はファイル１３３０は、任意選択的に、他の動作１３３２、例えば、送信、切り換え、編集、又は圧縮を受け得る。同様に、圧縮ＬＦＲストリーム又はファイル１３３１も、提供される場合、他の動作１３３２、例えば、送信、切り換え、編集、又は更なる圧縮を受け得る。
【００６３】
そのような他の動作１３３２に続き、ＬＦＲストリーム又はファイル１３３０は、ＬＦＲ／ＨＦＲデコーダ１３４０のＬＦＲ画像ブロック受信モジュール１３４２により受信され、バッファ１３４３に記憶される。幾つかの実施形態では、受信モジュール１３４２は、ＬＦＲストリーム若しくはファイル１３３０の欠落部分を再要求するか、又は順方向誤り訂正若しくは他のメカニズムを実行して、通信及び／又は処理エラーを検出及び／又は復元することができる。圧縮ＬＦＲストリーム又はファイル１３３１がデコーダ１３４０により受信される場合、圧縮ＬＦＲ画像ブロック受信モジュール１３４５は、ＬＦＲ画像をＬＦＲ画像ブロック復元モジュール１３４６に提供し、ＬＦＲ画像ブロック復元モジュール１３４６は、復元ＬＦＲ画像ブロックをバッファ１３４３に記憶する。ＨＦＲ画像ブロック出力モジュール１３４４は、バッファ１３４３からの個々のＨＦＲ画像をアンパックし、デコーダ１３４０の出力として、例えば、ＨＦＲディスプレイ１３５０に提供する。
【００６４】
メタデータは、受信モジュール１３４２内の受信ＬＦＲ画像ブロックを伴うか、又は受信モジュール１３４５内の圧縮ＬＦＲ画像ブロックを伴う場合、タイル化及び／又は圧縮のモード又はＬＦＲ画像ブロックについての他の情報を特定する役割を果たすことができる。
【００６５】
ＬＦＲ画像ブロック圧縮器１３２４により実行される圧縮は、Ｉフレーム符号化、Ｉフレーム及びＢフレーム符号化、又はＩフレーム、Ｂフレーム、及びＰフレーム符号化を使用する、上述したように動きに基づく圧縮を含むことができる。同様に、ＨＦＲ画像ブロック復元器１３２４により実行される復元は、Ｉフレーム復号化、Ｉフレーム及びＢフレーム復号化、又はＩフレーム、Ｂフレーム、及びＰフレーム復号化を使用する、上述したように動きに基づく復元を含むことができる。
【００６６】
上記説明は、高フレームレートビデオを圧縮（符号化）する技法を記載している。
【図１】
2017520176.tif 000003
【図２】
2017520176.tif 000004
【図３】
2017520176.tif 000005
【図４】
2017520176.tif 000006
【図５】
2017520176.tif 000007
【図６】
2017520176.tif 000008
【図７】
2017520176.tif 000009
【図８】
2017520176.tif 000010
【図９】
2017520176.tif 000011
【図１０】
2017520176.tif 000012
【図１１】
2017520176.tif 000013
【図１２】
2017520176.tif 000014
【図１３】
2017520176.tif 000015
【国際調査報告】
2017520176.tif 000016
2017520176.tif 000017
2017520176.tif 000018