(57)【特許請求の範囲】
【請求項１】
コンテンツのエンコーディングに使用する方法であって、
ソース・コンテンツを受け取ること、
前記ソース・コンテンツをエンコードし、エンコードされたコンテンツを作ること、
前記エンコードされたコンテンツの第１のエンコードされたセグメントを、複数のバッファ・モデルと較べて評価すること、
前記評価することに基づいて、前記エンコードされたコンテンツの前記第１のエンコードされたセグメントが再エンコードされるべきかどうかを前記複数のバッファ・モデルのうちの１つまたは複数と較べて決定すること、および
前記第１のエンコードされたセグメントが再エンコードされるべきであると決定されると、前記第１のエンコードされたセグメントを再エンコードすることであって、前記第１のエンコードされたセグメントを再エンコードすることは、
前記第１のエンコードされたセグメントを再エンコードし、第１の再エンコードされたセグメントを作成すること、
前記第１のエンコードされたセグメントとは別に前記第１の再エンコードされたセグメントを格納すること、および
前記第１の再エンコードされたセグメントを前記エンコードされたコンテンツとマージし、前記第１の再エンコードされたセグメントのバッファ・レベルおよびアクセス・ユニット情報を用いて前記エンコードされたコンテンツのバッファ・レベルおよびアクセス・ユニット情報を調整することを含む、前記ソース・コンテンツのエンコーディングをファイナライズすること
を含む、再エンコードすること
を備えることを特徴とする方法。
【請求項２】
前記エンコードされたコンテンツの前記第１のエンコードされたセグメントが再エンコードされるべきかどうかを決定することは、前記エンコードされたコンテンツが前記複数のバッファ・モデルのうちの第１のバッファ・モデルに失敗するかどうかを決定することを備え、
前記再エンコードすることは、前記エンコードされたコンテンツが第１のバッファ・モデルに失敗すると決定されると、前記第１のエンコードされたセグメントを再エンコードすることを備える
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記エンコードされたコンテンツが、前記複数のバッファ・モデルの第２のバッファ・モデルに失敗することを識別すること、および
前記第２のバッファ・モデルを、前記エンコードされたコンテンツに関連して無効化することをさらに備え、
前記無効化は、前記第２のバッファ・モデルを、前記エンコードされたコンテンツに関連して無効として指定し、かつ／またはそのストリームについて有効であることが分かっているバッファ・モデルによって置換することを含むことを特徴とする請求項２に記載の方法。
【請求項４】
前記第２のバッファ・モデルを無効化することは、前記第２のバッファ・モデルのパラメータを、前記エンコードされたコンテンツに関して有効であることが分かっているバッファ・モデルである第４のバッファ・モデルからのパラメータで置換することを備えることを特徴とする請求項３に記載の方法。
【請求項５】
前記エンコードされたコンテンツの第２のセグメントを識別すること、および
前記第２のセグメントを再エンコードし、ビットを解放すること
をさらに備え、前記第１のエンコードされたセグメントを再エンコードすることは、前記第１のエンコードされたセグメントを再エンコードして、前記解放されたビットを利用することを備える
ことを特徴とする請求項１に記載の方法。
【請求項６】
第３のセグメントを識別すること、
チャプタ・ポイントが前記エンコードされたコンテンツに挿入されるべきであると、前記第３のセグメントに関連して識別すること、および
前記第３のセグメントを再エンコードし、チャプタ・ポイントを組み込むこと
をさらに備えることを特徴とする請求項１に記載の方法。
【請求項７】
前記第１のエンコードされたセグメントを評価することは、複数の別個のバッファ・モデルに従って前記第１のエンコードされたセグメントの部分を同時にデコードすることを備えることを特徴とする請求項１に記載の方法。
【請求項８】
前記コンテンツをエンコードすることは、
前記ソース・コンテンツの複数のセグメントを識別すること、
前記ソース・コンテンツの前記複数のセグメントを分離すること、
前記ソース・コンテンツの前記複数のセグメントを別々にエンコードし、エンコードされた分割されたセグメントを作ること、および
前記エンコードされた分割された複数のセグメントをスプライスし、エンコードされたコンテンツ・ストリームを作ること
を備えることを特徴とする請求項１に記載の方法。
【請求項９】
前記ソース・コンテンツの複雑度を識別すること、および
前記ソース・コンテンツの前記複数のセグメントの前記識別された複雑度に従ってバッファ・レベルを調整すること
をさらに備えることを特徴とする請求項８に記載の方法。
【請求項１０】
前記ソース・コンテンツの時間相関を評価すること、および
前記ソース・コンテンツの前記複数のセグメントを識別することが、識別された境界に従って前記セグメントを定義することを備えるように、前記ソース・コンテンツ内の前記境界を識別すること
をさらに備えることを特徴とする請求項８に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本実施形態は、全般的にはデジタル・データのフォーマッティングに関し、詳細には、デジタル・データのエンコーディングに関する。
【背景技術】
【０００２】
生成され、記録され、かつ／または伝送されるデジタル・コンテンツの量の増加に伴って、コンテンツの圧縮および伝送を改善する必要も高まってきた。多くの圧縮、エンコーディング、および／または標準規格が、コンテンツの圧縮および伝送を提供するために開発され、定義されてきた。
【０００３】
これらの技法および／または標準規格の多くは、格納されまたは伝送されなければならないデータの量を減らす。さらに、これらの技法の多くは、コンテンツの品質の低下を最小限にした状態でデータの削減を可能にする。
【発明の開示】
【課題を解決するための手段】
【０００４】
本実施形態は、マルチメディア・コンテンツなどのコンテンツのエンコーディングおよび／またはフォーマッティングに使用される方法、装置、システムを提供する。幾つかの実施形態は、コンテンツのエンコーディングに使用される方法を提供する。これらの方法は、ソース・コンテンツを受け取り、ソース・コンテンツをエンコードし、エンコードされたコンテンツを作り、エンコードされたコンテンツの第１のエンコードされたセグメントを、複数のバッファ・モデルと較べて評価し、評価に基づいて、エンコードされたコンテンツの第１のセグメントが再エンコードされるべきかどうかを、複数のバッファ・モデルのうちの１つまたは複数と較べて決定し、第１のセグメントは再エンコードされるべきであると決定される、第１のセグメントを再エンコードする。
【０００５】
いくつかの実施形態は、エンコーディングに使用される方法を提供する。これらの方法は、ソース・コンテンツのエンコーディングを開始し、エンコードされたコンテンツを作り、再エンコードされるべきエンコードされたコンテンツのセグメントを識別し、セグメントの再エンコーディングの第１の候補スタート・ポイントを識別し、エンコードされたコンテンツの第１の部分を、第１の候補スタート・ポイントと較べて評価することによって、第１の候補スタート・ポイントが有効なスタート・ポイントであるかどうかを決定し、第１の候補スタート・ポイントが有効にされる、有効な再エンコード・スタート・ポイントとして第１の候補スタート・ポイントをセットする。
【０００６】
いくつかの実施形態は、さらに、ソース・コンテンツのエンコーディングを開始し、エンコードされたコンテンツを作ること、再エンコードされるべきエンコードされたコンテンツのセグメントを識別すること、セグメントの再エンコーディングの第の１候補エンド・ポイントを識別すること、エンコードされたコンテンツの第４の部分を、第１の候補エンド・ポイントと較べて評価することによって、第１の候補エンド・ポイントが有効なエンド・ポイントであるかどうかを決定すること、および第１の候補エンド・ポイントが有効にされるときに、有効な再エンコード・エンド・ポイントとして第１の候補エンド・ポイントをセットすることによる、エンコーディングに使用される方法を提供する。
【０００７】
いくつかの実施形態で、コンテンツのエンコーディングに使用される方法が提供され、そこでは、ソース・コンテンツを受け取り、ソース・コンテンツをエンコードし、エンコードされたコンテンツを作り、エンコードされたコンテンツのトータル・ビット・カウントを識別し、トータル・ビット・カウントが閾値ビット・カウントとの事前定義の関係を有するかどうかを決定し、トータル・ビット・カウントが閾値ビット・カウントとの事前定義の関係を有しないときに、再エンコードされたセグメントに関する調整されたトータル・ビット・カウントが閾値ビット・カウントとの事前定義の関係を有するように、エンコードされたコンテンツの１つまたは複数のセグメントを再エンコードし、１つまたは複数の再エンコードされたセグメントを作る。
【０００８】
さらに、いくつかの実施形態は、第１の閾値限度との事前定義の関係を有する品質レベルを有するエンコードされたコンテンツの１つまたは複数の第１のセグメントを識別し、第２の閾値レベルとの事前定義の関係を有する品質レベルを有し、第１のセグメントのうちの１つまたは複数から事前定義の範囲内にある１つまたは複数の追加セグメントがあるかどうかを決定し、追加セグメントのうちの１つまたは複数を再エンコードし、再エンコードされた追加セグメントが１つまたは複数の追加セグメントより少数のビットを利用するようになる品質レベルを有する１つまたは複数の再エンコードされた追加セグメントを作り、第１のセグメントのうちの１つまたは複数を再エンコードし、１つまたは複数の再エンコードされた第１のセグメントが対応する第１のセグメントの品質レベルより高い品質レベルを有するように１つまたは複数の再エンコードされた第１のセグメントを作る、マルチメディア・コンテンツのエンコーディングに使用される方法を提供する。
【０００９】
いくつかの実施形態は、エンコードされたマルチメディア・コンテンツ・ストリームを解析し、コンテンツ・ストリームのパラメータを識別すること、識別されたパラメータのうちの１つを変更すること、変更されたパラメータに基づいてエンコードされたコンテンツ・ストリームの少なくとも部分的なデコーディングをシミュレートすること、バッファ閾値が超えられているかどうかを識別すること、およびバッファ閾値が超えられていないときに、変更されたパラメータに従ってエンコードされたコンテンツ・ストリームを変更することによる、コンテンツのフォーマッティングに使用される方法を提供する。
【００１０】
さらに、いくつかの実施形態は、デジタル・コンテンツのエンコーディングを容易にするのに使用される方法を提供する。これらの実施形態は、エンコードされたコンテンツの諸部分のビットレートをグラフィカルに表すビットレート・トラックを生成し、ビットレート・トラックに対応するエンコードされたコンテンツの諸部分のエンコーディングの品質をグラフィカルに表す品質トラックを生成し、再エンコードされるべきエンコードされたコンテンツの部分の選択をビットレート・トラック内で識別する。
【００１１】
上述したニーズは、特に図面と共に熟読されるときに、次の詳細な説明に記載のデジタル・コンテンツのエンコーディングに使用される方法、装置、および／またはシステムの提供を介して、少なくとも部分的に、満足される。
【００１２】
対応する符号は、図面の複数のビューを通じて対応するコンポーネントを示す。当業者は、図面の要素が、単純さおよび明瞭さのために図示され、必ずしも原寸通りに描かれてはいないことを了解するであろう。例えば、図面の要素のいくつかの寸法は、本発明の様々な実施形態の理解を改善するのを助けるために、他の要素と較べて強調されている場合がある。また、商業的に実現可能な実施形態に有用であるか必要である、一般的であるがよく理解されている要素は、しばしば、本発明のこれらの様々な実施形態のより遮られないビューを容易にするために、図示されていない。
【発明を実施するための最良の形態】
【００１３】
本実施形態は、１つまたは複数のデコーダ・バッファ・モデルおよび／またはエンコーディング方式を達成するために、コンテンツのエンコーディングに使用される方法およびシステムを提供する。さらに、いくつかの実施形態は、コンテンツの正確なエンコーディングを可能にするので、エンコードされたコンテンツが、要求されるエンコーディング方式別に複数のデコーダ・モデル（multiple decoder models）に従うようになる、る。いくつかの実施形態は、エンコーディングを加速し、いくつかの実装では、さらに、エンコードされたコンテンツ１２６の品質を維持しながら加速された速度でのコンテンツのエンコーディングを可能にするために、コンテンツ・ストリームの時間的分割を提供する。さらに、いくつかの実施形態は、改訂されかつ／または再エンコードされるべき、例えばコンテンツ・ストリーム全体のフル再エンコードを必要とせずに１つまたは複数の満足されていないデコーダ・モデルに適合する、エンコードされたコンテンツのうちの部分またはセグメント、を識別する。
【００１４】
図１に、いくつかの実施形態によるエンコーディング・システム１２０の単純化されたブロック図を示す。このシステムは、ソース・コンテンツ１２２、エンコーダ１２４、エンコーダ出力１２６、コンテンツ書き込みシステム１３０、およびストレージ媒体１３２を含む。ビデオ、オーディオ、および／または他のコンテンツなどのソース・コンテンツ１２２は、エンコーダ１２４に供給される。エンコーダは、ソース・コンテンツをエンコードし、部分的にコンテンツを圧縮して、例えば、書き込みシステム１３０が、コンテンツを格納するのに必要なストレージ媒体１３２のメモリ・スペースの量を減らすことを可能にする。エンコーディング・システムは、ハードウェア、ソフトウェア、ファームウェア、および／またはこれらの組合せを介して実装することができ、いくつかの例で、単一プロセッサもしくはマルチ・プロセッサのコンピュータ・システム、ミニコンピュータ、メインフレーム・コンピュータ、プロセッサ、マイクロ・プロセッサ、ならびにパーソナル・コンピュータ、ハンドヘルド・コンピューティング・デバイス、マイクロ・プロセッサ・ベースのまたはプログラマブルな消費者エレクトロニクスから操作することができる。さらに、いくつかの実施形態で、エンコーディング・システム１２０を、分散ネットワークを介して、所望されるエンコードされた出力を達成するために協力する、異なる物理的位置にある、システムのコンポーネントに分散させることができる。
【００１５】
上で紹介したように、システム１２０を、ハードウェア、ソフトウェア、コンピュータ実行可能命令、ファームウェア、および／またはその組合せを介して実装することができ、これらは、他の、プログラムならびに／あるいはハードウェア、ソフトウェアおよび／または組合せ、と組み合わせて実装することができる。エンコーディングおよび／または再エンコーディングは、通信ネットワークを介してリンクされたリモート処理デバイスによってある種のタスクが実行される分散コンピューティング環境で実行することもできる。分散コンピューティング環境では、ソフトウェア、実行可能ファイル、スクリプト、および類似物を、ローカルとリモートとの両方のメモリ・ストレージ・デバイスに配置することができる。コンピュータおよび／またはコンピュータ・ネットワークは、通常、揮発性および不揮発性の媒体、リムーバブルおよびノンリムーバブルの媒体などのコンピュータ読取り可能な媒体を含み、これらの媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュ・メモリ、または他のメモリ・テクノロジ、ＣＤ−ＲＯＭ、ＤＶＤ、ＨＤ−ＤＶＤ、ＢＤ、または他の光学ディスク・ストレージ、磁気カセット、磁気テープ、磁気ディスク・ストレージ、または他の磁気ストレージデバイス、ならびに／あるいは所望する情報を格納するのに使用でき、情報をそこから取り出すことができる実質的にすべての他の媒体を含むことができる。コンピュータおよび／またはネットワークを介する通信は、有線ネットワークもしくは直接配線ネットワーク、音響、ＲＦ、赤外線、および他の無線通信接続などの無線媒体、ならびに／あるいは他の関連する通信または通信リンクおよび／またはプロトコルの組合せを介するものとすることができる。
【００１６】
図２に、図１のエンコーディング・システム１２０の一部またはすべてを実装し、かつ／あるいは上で説明したおよび／または下でさらに説明するエンコーディングおよび再エンコーディングの一部またはすべてを実行するためにいくつかの実施形態で利用することができるコンピュータ・システム２２０の単純化されたブロック図を示す。コンピュータ２２０は、処理ユニット２２２、メモリ２２４、および通信リンクまたはネットワーク２２６を含むことができる。処理ユニット２２２は、実質的にすべてのプロセッサ、マイクロ・プロセッサ、および／または複数のプロセッサとすることができる。通信ネットワーク２２６は、システム・コンポーネントを一緒に直接におよび／または間接に結合する。メモリ２２４は、上で説明したメモリなど、実質的にすべての関連するメモリを含むことができ、データ、プログラム、ルーチン、実行可能ファイル、スクリプト、オーディオ・コンテンツ、ビデオ・コンテンツ、および類似物を格納することができる。
【００１７】
コンピュータ２２０は、さらに、このコンピュータにキーボード、ポインティング・デバイス、光学および／またはオーディオ検出器、タッチ・スクリーン、スタイラス、ディスプレイ、ならびに／あるいは他のそのようなデバイスをインターフェースし、かつ／または接続する１つまたは複数の有線または無線のユーザ・インターフェース２３０を含むことができる。このコンピュータは、さらに、外部デバイス２４０（例えば、外部ハードドライブ、プリンタ、ディスプレイ、および他のそのような外部デバイス）ならびに／あるいは１つもしくは複数のリモート・サーバ２４６、コンピュータ２４８、データベース２５０、および／または他のそのようなデバイスと通信する外部の有線および／または無線のネットワーク２４２、２４４と結合するポートおよび／またはソケット２３２を含むことができる。
【００１８】
戻って図１を参照すると、エンコーダ１２４は、通常、ＭＰＥＧ２（Moving Picture Experts Group）など、よく認識されている所与の標準規格または方式に従ってコンテンツ１２６をエンコードするように構成される。他のエンコーディング方式が、その代わりにおよび／またはそれに加えて利用され、これらのうちのいくつかは、通常、高品位ビデオ・コンテンツ、高分解度コンテンツなど、相対的により高いビットレートのコンテンツに使用され、ＭＰＥＧ４  ｐａｒｔ  １０  ＡＶＣ、ＶＣ−１（ＷＭＶ９）、および他のそのようなエンコーディング方式を含む。これらの標準規格のうちの少なくともいくつかによるエンコーディングは、部分的に、ＡＶＣおよびＶＣ１など、これらの標準規格のうちのいくつかは、エンコードされるコンテンツ１２６ごとに満足されなければならない複数のデコーダ・バッファ・モデルなどの、複数のデコーダ要件を提供するので、ＭＰＥＧより複雑である。
【００１９】
本実施形態は、コンテンツの正確なエンコーディングを可能にし、要求されるエンコーディング方式による複数のデコーダ・モデルを満足する。さらに、いくつかの実施形態は、いくつかの実装で、エンコードされるコンテンツ１２６の品質を維持しながら複数のエンコーダ（multiple encoders）および／またはプロセッサ（processors）にまたがってコンテンツ・ストリームを分割することによって、加速されたエンコーディングをもたらす。さらに、本実施形態は、例えば１つまたは複数の満足されていないデコーダ・モデルに適合する、エンコードされたコンテンツのうちで改訂されかつ／または再エンコードされるべき部分またはセグメントのユーザ選択されかつ／または自動化された選択、を可能にする。
【００２０】
図３に、１つまたは複数の所望されるデコーダ・バッファ・モデルに従うエンコードされたコンテンツを作るためにエンコーディングを実装する、いくつかの実施形態によるプロセス３２０の単純化された流れ図を示す。ステップ３２２で、ソース・コンテンツを受け取る。このコンテンツは、記録された媒体（例えば、テープ、ディスク、または他のそのような媒体）から受け取ることができ、このコンテンツを、記録デバイスから受け取られる初期コンテンツとすることができ、このコンテンツは、ローカル・データ・ストレージからまたはリモート・データ・ストレージ（例えば、インターネットなどの分散ネットワークを介してアクセスされる）および他のそのようなソースまたはソースの組合せから獲得することができる。ステップ３２４で、１つまたは複数のデコーダ・バッファ・モデルに従ってコンテンツをエンコードする。ステップ３２６で、エンコードされたコンテンツが評価される。この評価は、コンテンツのエンコード中に、またはコンテンツの完全なエンコードの後に、実行することができる。ステップ３３０で、このプロセスは、エンコードされたコンテンツの１つまたは複数のセグメントが１つまたは複数の所望のデコーダ・バッファ・モデルを満足するのに失敗するかどうかを決定する。いくつかの実装において、以下で説明するｐｅａｋ  ｓｉｇｎａｌ−ｔｏ−ｒｅｃｏｎｓｔｒｕｃｔｅｄ  ｉｍａｇｅ比較など、１つまたは複数の品質閾値レベルが、オリジナル・コンテンツに対して評価される。
【００２１】
１つまたは複数のセグメントが、ステップ３３０で１つまたは複数のモデルを満足するのに失敗し、かつ／または品質限度を満足するのに失敗するものとして識別されると、このプロセスは、ステップ３３２に入り、ここで、識別されたセグメントのうちの１つまたは複数が再エンコードされるべきかどうかを決定する。セグメントが再エンコードされるべきであると、ステップ３３４に入り、１つまたは複数の識別されたセグメントを再エンコードする。ステップ３３６では、再エンコードされたセグメントを評価して、再エンコードされたセグメントが、前には満足されなかったデコーダ・バッファ・モデルのうちの１つまたは複数を満足するかどうかを決定する。再エンコードされたセグメントがモデルを満足するのに失敗すると、このプロセスは、ステップ３３２に戻って、セグメントはもう一度再エンコードされるべきかどうかを決定する。エンコードされたセグメントがモデルを満足すると、このプロセスはステップ３４０に入って、さらなるセグメントが評価されかつ／または再エンコードされるべきかどうかを決定する。追加のセグメントを再エンコードされるべきであるときには、このプロセスはステップ３３２に戻って、１つまたは複数のセグメントが再エンコードされるべきかどうかを決定し、あるいは、評価されるべきさらなるセグメントがないときには、このプロセスはステップ３４４に継続する。
【００２２】
ステップ３４４では、このプロセスは、１つまたは複数のチャプタ・ポイントを含めること（例えば、エントリ・ポイントを含めることを伴うセグメント再エンコードを介して）または下で説明する他の処理など、エンコードされたコンテンツの追加の処理が実行されるべきかどうかを決定する。さらなる処理が実行されるべきであるときには、ステップ３４６に入り、ここで、さらなる処理を実行する。あるいは、ステップ３５０に入り、ここで、エンコードされたコンテンツをファイナライズし、かつ／または格納する。コンテンツをファイナライズし、書き込む際に、コンテンツのうちで再エンコードされた部分が、バッファ・モデル・パラメータおよび／または品質限度を満足するのに失敗した、最初にエンコードされたコンテンツの代わりに、書き込まれる。
【００２３】
ストリーム全体を再エンコードすることを余儀なくさせる代わりに、コンテンツの再エンコーディングをコンテンツのセグメントに制限することは、少なくとも、エンコーディング時間を減らし、処理速度を高め、処理オーバーヘッドを減らし、全体的なエンコーディング性能を改善し、エンコードされたコンテンツが所望のデコーダ・バッファ・モデルを満足することを確認し、効果的にＡＶＣ、ＶＣ１、および／または他のエンコーディング方式などの１つまたは複数のエンコーディング標準規格を満足させ、上で説明したものおよび下でさらに説明する他の利益を提供する。
【００２４】
いくつかの実施形態によって提供されるセグメント・ベースの再エンコーディングは、先在するエンコードされたコンテンツ・ストリーム内のビデオ・データなどのエンコードされた（例えば、圧縮された）コンテンツの諸部分または諸領域の、１つまたは複数の変更されたエンコーディング・パラメータに従って再エンコードされたセグメント（例えば、高められたビットレート、トランスレーティング（translating）、および他のエンコーディング・パラメータまたはエンコーディング技法に従ってエンコードされた）との効率的な置換を可能にし、結果の共同のエンコードされたコンテンツが、１つまたは複数の標準規格および／またはデコーダ・モデルを満足するようになる。多数の以前のシステムは、通常、１つまたは複数のセクションがエラーを有し、かつ／またはデコーダ・モデルを満足するのに失敗したときに、ビデオ・ストリーム全体の再エンコードを必要とした。ストリーム全体の再エンコーディングは、エンコーディング・プロセスにかなりの長さの処理時間を追加し、生産性を劇的に低下させる可能性がある。いくつかの既存のシステムは、ＭＰＥＧ２の単一の明確に定義され確立された標準規格に従う、あるタイプの再エンコーディングを可能にする。しかし、ＭＰＥＧ２を満足するための再エンコーディングを、ＡＶＣ、ＶＣ１、および多数の他のエンコーディング標準規格などの多数の他のエンコーディング標準規格に適用することはできない。これは、部分的には、ＭＰＥＧ２が単一バッファ・モデルを満足することだけを提供するが、ＡＶＣおよびＶＣ１などの他のエンコーディング方式が、エンコードされたコンテンツが多くの場合に複数バッファ・モデル（multiple buffer models）を満足するように定義されているという事実に起因する。
【００２５】
いくつかの実施形態は、エンコードされたコンテンツの１つまたは複数の個々のセグメントを変更し、再エンコードすることを可能にし、その後、再エンコードされたセグメントが、メインのエンコードされたストリームに戻して組み込まれる。したがって、いくつかの実施形態は、後戻りしてコンテンツ・ストリーム全体（例えば、２時間のムービー）の完全な再エンコードを行う必要を回避する。その代わりに、本実施形態は、１分のセグメント、３０秒のセグメント、１０秒のセグメント、１秒のセグメント、１秒未満および／または実質的に任意の長さのセグメントなどの、セグメントを、再エンコードし、エンコードされたストリームに戻して組み込むことを可能にし、所望のパラメータを満足するコンテンツ・ストリームのエンコーディングを達成するのに必要な時間を劇的に減らす。
【００２６】
上で紹介したように、いくつかの実施形態は、コンテンツが一つ以上のデコーダ・バッファ・モデルを満足するようにエンコードされることを可能にする。これらのバッファ・モデルは、データが、デコーダにどのように取り込まれ、デコーダからどのように解放されるかを定義する。本実施形態は、これらの全般的に厳密な標準規格（通常はＡＶＣまたはＶＣ１の仕様などのエンコーディング仕様に詳細に記載されている）に従いながらのセグメント再エンコーディングを可能にし、ここで、結果のエンコードされたストリームは、複数のデコーダ・バッファ・モデルを満足する。これらのデコーダ・バッファ・モデルは、通常、ＭＰＥＧ２に対するよりもＡＶＣおよびＶＣ１と同じではなく、その理由は、ＭＰＥＧ２エンコーディングが、部分的に、通常は単一バッファ・モデルを満足するだけでよいが、ＡＶＣ標準規格および／またはＶＣ１標準規格を満足するエンコードされたストリームが複数のモデルを満足することができるからである。
【００２７】
複数のモデルを満足することは、デコーダが、単純に、そのデコーダがストリームをデコードすることを可能にする複数のモデル（リーキー・バケット・モデル；leaky bucket models）のうちのいずれか１つを満足しなければならないので、デコーダ側においてより高い柔軟性を条件とする。その代わりに、ＭＰＥＧ２では、満足されるべき単一のモデルがある。さらに、複数のモデルを満足することの利点は、異なるデコーダがストリームをデコードすることを可能にし、例えば、いくつかのデコーダが、相対的に高いフィル・レート（fill rate）を有するが相対的に小さいバッファを有することができ、他のデコーダが、相対的に大きいバッファを有するが相対的に低いフィル・レートを有することができる。通常、デコーダは、エンコードされたストリームにアクセスし、そのデコーダがそのストリームをデコードでき、再生できるかどうかを前もって識別することができる。
【００２８】
このシステムは、さらに、エンコードされたコンテンツを分析して、１つまたは複数のデコーダ・バッファ・モデルおよび／またはパラメータが満足されるかどうかを決定し、かつ／または検証することができる。モデルを満足することについての検証は、いくつかの実装で、デコーダの挙動（behavior）と、これらのデコーダが関連するバッファからのデータの消費に関してストリームをデコードする方法とをシミュレートすることによって実行される。いくつかの実装で、このシステムは、一時に１つのモデルをシーケンシャルにシミュレートする。いくつかの実装は、モデルを並列にシミュレートすることによって、潜在的なモデルのうちの複数またはすべてを実質的に同時に評価する。このシステムは、シーケンシャルにまたは並列に実行されたものであれ、シミュレーションからデータを抽出し、次に、１つまたは複数のデコーダ・モデルが失敗するかどうかを決定する。
【００２９】
１つまたは複数のデコーダのシミュレーションを実行するために、いくつかの本実施形態は、いくつかの実装で１つまたは複数のデコーダおよびその入力バッファの数学的モデルである、１つまたは複数の仮想参照デコーダ（hypothetical reference decoder、ＨＲＤ）を使用する。このＨＲＤは、ＡＶＣ標準規格およびＶＣ１標準規格の一方または両方によるなど、エンコードされたストリームによって満足されるべき、要求される標準規格に従って定義される。通常、要求される標準規格に準拠すべき所与のエンコードされたストリームについて、そのストリームは、ストリーム内で指定されるモデルのパラメータを与えられた複数のリファレンス・モデルに準拠する。ＨＲＤでのデコーダとその入力バッファとの間の関係は、「リーキー・バケット」バッファ・モデルに関して定義される。このバッファ・モデルは、ビットレート（ビット毎秒）およびバッファ充満度に関してバッファがどのように充填され、空にされるかのパラメータを指定する。ストリームが例えばＡＶＣおよびＶＣ１に準拠するためには、そのストリームは、ＨＲＤがバッファ充満度範囲を超えずに動作する、デコーダ・モデル・パラメータの１つまたは複数のセットを指定しなければならない。
【００３０】
いくつかの好ましい実装のＨＲＤは、エンコードされたストリームが従わなければならない複数のモデルを一度に定義することができる。例えば、ＨＲＤは、異なるフィル・レートおよび異なるサイズを有する５個、１０個、２０個、１００個、またはそれより多数のバッファ・モデルを定義することができ、エンコードされた信号は、これらの異なるバッファのうちの複数に従い、いくつかの例では異なるモデルのすべてに従う。
【００３１】
ＨＲＤは、１つまたは複数のモデルが失敗するかどうかを調べるために、一度に複数の、好ましくはすべての指定された可能なバッファ・モデルの同時検証を実行する。１つまたは複数のモデルが失敗したとして識別されると、このシステムおよび／またはユーザは、エンコードされたストリームの１つまたは複数のセグメントの、その後の再エンコードを実行することによって、後戻りして、ストリームを修正することができる。代替案では、このシステムおよび／またはユーザは、その特定のポイントでの（任意の１つまたは複数の部分／セクションでの）コンテンツの性質（nature）に起因して、１つまたは複数のモデルを満足しないおよび／または満足できない、と決定しまたは判断することができ、次に、このシステムは、ストリーム内のパラメータ指定を変更することができ、エンコードされたストリームが実際に標準規格（例えば、ＡＶＣおよび／またはＶＣ１）に従う全てのバッファ・モデルより少ないバッファ・モデルをサポートしていることを識別する。例えば、いくつかの実施形態は、エンコードされたストリームによって満足されないデコーダ・バッファ・モデルを、メタデータとして、維持する。エンコードされたコンテンツを格納する際に、最終的なエンコードされたコンテンツによって満足されないモデルは、ヘッダまたはパラメータ・データ内で識別されず、あるいは、ストレージ媒体（例えば、ディスク、コンパクト・ディスク（ＣＤ）、デジタル多用途ディスク（ＤＶＤ）、他の光学的に読み取り可能な媒体、および／または他の媒体）の指定、ヘッダ、および／またはパラメータ・データ内で、満足されないものとして識別することができる。
【００３２】
通常、エンコード中のＭＰＥＧ２システムは、エンコーダが試み、達成するように指示される「イン」バッファ・レベルおよび「アウト」バッファ・レベルを指定する。しばしば、バッファは、アウト・ポイントを正しく達成せず、したがって、下流で、バッファ・モデルが失敗する。一部のＭＰＥＧ２システムは、モデルに失敗した１つまたは複数の領域を修正するために、コンテンツ・ストリーム全体を、変更されたビットレートでのもう１つのエンコードを自動的に実装することを試み、その結果、最終的にストリーム全体が準拠する。これは、ストリーム全体の総合的なエンコーディング品質を下げるという効果を有する。
【００３３】
代替案では、上で紹介したように、複数のモデルに従うことを試みるいくつかの実施形態は、コンテンツの１つまたは複数のセグメントが複数のモデルのうちの１つまたは複数に失敗する場合を識別することができ、その後に再エンコードを開始するのではなく、単に失敗したバッファ・モデルを無効化する。したがって、いくつかの実施形態は、再エンコードを試みることを避けることができ、その結果、エンコードされたストリームは、ストリーム内で指定されるすべてのモデルより少ないモデルを満足するようになる。
【００３４】
図４に、いくつかの実施形態によるＨＲＤモデル４２０の単純化されたブロック図を示す。ＨＲＤ４２０は、デコーダ・モデル４２４〜４２６のうちの１つまたは複数を有するプロセッサ４２２を含む。いくつかの実施形態で、プロセッサ４２２は、少なくとも部分的にエンコーダ１２４などのエンコーダのプロセスを介して実装される。プロセッサ４２２は、標準規格（例えば、ＡＶＣ、ＶＣ１、および類似物）に従って評価されるべきモデルごとに１つのデコーダ・モデルを含み、かつ／またはこれにアクセスする。プロセッサ４２２は、所望のデコーダ評価を実装できることが当技術分野で知られている、コンピュータまたはコンピュータ・システム（例えば、コンピュータ・システム２２０）、マイクロ・プロセッサ、ロジック、および他の処理回路網を介して実装することができる。いくつかの実施形態で、デコーダ・モデル４２４〜４２６は、ソフトウェアを介して、例えば、定義されたバッファ・モデルに従うデコーダの処理要件（例えば、フィル・レート、バッファ・サイズ、および他のパラメータ）を模倣するように構成されたオブジェクト指向プログラムおよび／またはクラスのベクトルとして実装される。いくつかの実施形態で、ＨＲＤは、オプションとして、ＨＲＤ用処理能力がプロセッサ４２２、４４０、４４２にまたがって分散されるように、それぞれが１つまたは複数のデコーダ・モデル４２４〜４２６、４５０、および４５２を有する、複数のプロセッサまたはコンピュータ４２２、４４０、４４２を組み込む。プロセッサを、同一位置に配置したり、かつ／またはイントラネット、インターネット、もしくは他のそのようなネットワークなどのネットワーク上で分散させたりすることができる。
【００３５】
エンコードされたコンテンツ４３０が、ＨＲＤ４２０に供給される。データ・セットの各要素は、各デコーダ・モデル４２４〜４２６（およびオプションで４５０、４５２）に供給される。モデルは、それぞれ、その特定のデータを直列にまたは並列に処理し、デコードされたストリーム内で発生するエラーを探す。要素の評価に基づいて、後続要素が、モデルに供給され、評価される。このシステムは、ストリームの各要素が評価のために各デコーダ・モデル４２４〜４２６に向けられ、ストリームが完全に評価されるように、ループバックし続ける。いくつかの実施形態で、ＨＲＤ４２０は、コンテンツ・ストリーム１２２がエンコードされているときに、エンコードされたストリームを評価するのに使用される。ＨＲＤは、いくつかの実装で、さらに、エンコーディングおよびエンコードされたコンテンツの構成における使用のためにコンテンツ・ストリームの予測機能を提供することができる。例えば、ＨＲＤには、ＭＰＥＧ２エンコーダなど、ビデオ・コンテンツを処理する単純化されたエンコーダを含めることができる。ＨＲＤ  ＭＰＥＧ２エンコーダを介して達成されたエンコーディングに基づいて、ＨＲＤは、推定されるバッファ・レベル、ＡＶＣエンコーダ、ＶＣ１エンコーダ、ＭＰＥＧ４エンコーダ、および／または他のエンコーダのエンコーディング・レート、ならびに他のエンコーディング・パラメータを識別したり、予測したりすることができる。
【００３６】
図５に、セグメントの再エンコードを実装するプロセス５２０の単純化された流れ図を示す。ステップ５２２で、ＨＲＤを介するなど、エンコードされたコンテンツの処理を介して識別されたエラーを取り出す。ステップ５２４で、エラーを評価し、このプロセスは、１つまたは複数のセグメントの再エンコードを実行しなければならないかどうかを決定する。再エンコードが開始されるべきかどうかの決定は、１つまたは複数の要因に基づくものとすることができる。いくつかの実装で、再エンコードの決定は、ユーザによって指定される。このシステムは、バッファ・モデルが失敗する区域を識別して再エンコードを実装することができ、かつ／または再エンコードされるべき区域をユーザが指定することを可能にする。いくつかの実施形態で、再エンコードは、バッファ・モデルを満足するのに失敗する事実上すべてのセグメントについて開始することができる。さらに、いくつかの実施形態は、バッファ・モデルが満足されず、その後の再エンコードがセグメントの品質を閾値未満に劣化させない区域に、セグメントの再エンコードを制限する。それに加えておよび／またはその代わりに、セグメントの再エンコードを、品質が閾値未満に下がり、十分なビットリソースがより高いビットレートでの再エンコードに使用可能であるときに実装することができる。下で説明するように、他の要因および／または条件を利用して、再エンコードが開始されるべきときを決定することができる。
【００３７】
再エンコードが実行されるべきときには、ステップ５２６に入り、ここで、再エンコードを、識別されたセグメントについて開始する。ステップ５３０で、このプロセスは、１つまたは複数のデコーダ・モデルについて、再エンコードされたセグメントに関して１つまたは複数のエラーが検出されるかどうかを決定する。さらなるエラーが、再エンコードされたセグメントに関して検出される場合には、このプロセスは、ステップ５３２で、そのセグメントの、その後の再エンコードを実装しなければならないかどうかをもう一度決定する。再び、再エンコードがコンテンツの品質を大きく劣化させる（例えば、閾値を超えて）かどうか、使用可能なビット、閾値レベル、および／または他の要因を決定するなど、これらに限定されないが、多数の要因が、再エンコードを開始しなければならないかどうかを決定するために、再検討することができ、かつ／または再検討される。再エンコードされたセグメントの、その後の再エンコードが実行されるべきである場合には、このプロセスは５２６に戻る。その代わりに、その後の再エンコードを実行しないときには、このプロセスは、ステップ５３６にスキップする。
【００３８】
ステップ５３０での決定で、再エンコードされたセグメントが、要求されるバッファ・モデルを満足するときに、この処理は、ステップ５３４に入り、ここで、再エンコードされたセグメントを格納し、いくつかの実施形態では、再エンコードされたセグメントが、別々のファイルまたはストレージ位置に格納される。次に、このプロセスはステップ５４０に継続する。ステップ５２４および５３２で、再エンコーディングを、エラーが検出されるセグメントについて実行しないと決定される場合には、識別された１つまたは複数のセグメントについて失敗するバッファ・モデルが、ステップ５３６で失敗として記録される。いくつかの例で、失敗したバッファ・モデルは、別々のファイルに格納される。ステップ５４０で、このプロセスは、さらなるエラーを、再エンコードについて評価しなければならないかどうかを決定する。追加のエラーを評価しなければならないときには、このプロセスは、ステップ５２２に戻り、そうでない場合には、このプロセスは、ステップ５４２に継続する。
【００３９】
ステップ５４２で、エンコードされたストリームの記録を開始するが、ここでは、ステップ５３６で１つまたは複数のデコーダ・モデルに関して失敗として識別されたデコーダ・バッファ・モデルが、ストリームのヘッダから除去され、エンコードされたストリームが満足するバッファ・モデルが、記録される。ステップ５４６で、エンコードされたコンテンツの記録を開始する。ステップ５５０で、再エンコードされたセグメントを、コンテンツの記録中に識別する。ステップ５５２で、このプロセスは、最初に失敗してエンコードされたセグメント、または一緒に再エンコードされた他のセグメントを、再エンコードされたセグメントに置換し、かつ／または、再エンコードされたセグメントの形縫い合わせし（例えば、再エンコードされたコンテンツを別々のファイルから取り出し、失敗したセグメントを、取り出された再エンコードされたセグメントで置換し）、再エンコードされたセグメントを書き込む。ステップ５５４で、このプロセスは、書き込まれるべきさらなるエンコードされたコンテンツがあり、ステップ５４６に戻って、エンコードされたコンテンツおよび再エンコードされたコンテンツの書き込みを継続しなければならないかどうか、を決定する。そうでない場合には、このプロセスは終了する。
【００４０】
いくつかの実装で、デコーダ・バッファ・モデルを満足するのに失敗し、そのセグメントの再エンコードが所望の品質を達成せず、かつ／または、さらに要求されるデコーダ・バッファ・モデルを満足するのに失敗するセグメントについて、その失敗するセグメントに近接するコンテンツ・ストリームが、さらに評価され、かつ／または隣接するセグメントの再エンコードが、さらに実装される。対象とするセグメントの周囲のセグメントを再エンコードすることによって、再エンコードされたセグメントが、バッファ・モデルのイン・レート（in rates）および／またはアウト・レート（out rates）を満足するように、対象とするセグメントのバッファ・モデル要件を減らすことができる。さらに、隣接セグメントの再エンコーディングを利用して、再エンコードに続くエンコードされたストリームに戻す再エンコードされたセグメントの組み込みを単純にするか、よりたやすく可能にすることができる。
【００４１】
いくつかの実施形態は、ストリーム全体の完全な再エンコーディングを必要とする代わりに、コンテンツのセグメントだけの再エンコーディングを可能にすること、およびストリームが要求されるエンコーディング標準規格および／または要求されるデコーダ・モデルを満足するようにするために、再エンコードされたセグメントを最終的なエンコードされたコンテンツに組み込むこと、によって、エンコーディング・プロセスおよび処理時間を改善する。さらに、いくつかの実施形態は、要求されない、および／またはコンテンツの全体的な品質を大きく劣化させなければ満足することのできない、モデルの１つまたは複数の無効化されたバッファ・モデルを満足するために必要になるはずの、不必要な再エンコード、を防ぐことができる。要求されないモデルおよび／または閾値（ユーザ定義、システム定義、バッファ・モデル定義とすることができる）を超えて品質を劣化させなければ満足できないモデルについて、いくつかの実施形態は、要求されないバッファ・モデルの識別を提供し、コンテンツ・ストリームについてこれらのモデルを無効化する。例えば所与の再エンコードに関するターゲットのセグメントのアウト・ポイント・バッファ・レベルを達成しないことに起因する再エンコードの後に、満足されないデコーダ・モデル・パラメータ・セットを単純に識別し、かつ／または無効化することによって、このシステムは、全体的なコンテンツ品質を改善し、処理オーバーヘッドを減らし、処理時間を減らす。
【００４２】
図５に関して上で紹介したように、いくつかの実施形態は、エンコードされたストリームの処理が完了し、エンコードされたコンテンツが最終的な形で書き込まれなければならない（例えば、ＤＶＤまたは他の媒体に書き込む）ときに、再エンコードされたセグメントをコンテンツのエンコードされたストリームに戻して、一緒にしたり縫い合わせしたりすることによって、処理時間を改善し、処理オーバーヘッドを減らす。これらの実施形態では、最初のベース・エンコードが実行され、これに、エンコードされるべきセグメントの識別、再エンコードの実行、および１つまたは複数の別々のファイル内での再エンコードされたセグメントの維持、ならびに再エンコードされたセグメントは組み込まれるべきエンコードされたストリーム内の位置を識別するためのリンクの生成、が続く。再エンコードおよび他の処理が完了するとき、および／またはユーザがエンコードされた最終結果に満足するときに、エンコーディング処理がファイナライズされ、ここで、無効化されるモデルが識別され、１つまたは複数の再エンコードされたセグメントが、再エンコードされるべきと識別されたセグメントを置換して、エンコードされたストリームに戻して縫い合わされ、無効化されたモデルおよび改訂されたエンコードされたセグメント全体が格納される。１つまたは複数のモデルの無効化は、コーディング方式によって変化する場合がある。例えば、ＡＶＣに関して、モデルの無効化は、いくつかの実装で、無効化されたモデル・パラメータを含まない新しいデータを用いてストリーム内のｈｒｄ＿ｐａｒａｍｅｔｅｒデータ構造体を再構成することによって達成することができる。いくつかの実施形態は、さらに、ユーザおよび／またはシステムが、エンコードされたコンテンツをファイナライズした後の追加のセグメント再エンコード、フル再エンコード、および／または他の処理と、その後の、変更されたエンコードされたストリームの格納のためにもう一度再ファイナライズすること、を実装することを可能にする。
【００４３】
エンコードされたコンテンツのストリームを評価する際に、いくつかの実施形態は、エンコードされたストリームが要求されるデコーダ・モデルを満足するかどうかを決定し、かつ／またはエンコーディングに起因する信号の品質もしくは劣化を決定することができる。いくつかの実施形態は、オリジナルのコンテンツ・ストリームとのデコードされたストリーム（例えば、ＨＲＤを介してデコードされた）の比較、ピクチャ品質の評価、ピクチャ・パラメータの品質の評価、および／または他の評価もしくは評価の組合せを実装する。例えば、いくつかの実装で、エンコーディングに続くピクチャ品質の評価は、圧縮されたビデオ・アプリケーションに関連するピクチャ品質減損を定量化する、最小可知差異（ＪＮＤ）の方法論またはアルゴリズムを使用することによって達成される。ＪＮＤは、いろいろなピクチャ欠陥に敏感であり、ある範囲のピクチャ品質にまたがって働き、人間の視覚的評価によく一致することを試みる予測をもたらす。それに加えておよび／またはその代わりに、ＪＮＤ方法論の結果を近似するアルゴリズム（例えば、サーノフ）を使用することができる。
【００４４】
信号対雑音比（ＳＮＲ）比較および／またはｐｅａｋ  ｓｉｇｎａｌ−ｔｏ−ｒｅｃｏｎｓｔｒｕｃｔｅｄ  ｉｍａｇｅ（ＰＳＮＲ）比較を、それに加えておよび／またはその代わりに使用して、エンコードされた品質を決定することができる。ＰＳＮＲは、本質的に、品質、歪み、および／またはデコードされた後のエンコードされたコンテンツがオリジナル・コンテンツにどれほどよく一致するかの決定の尺度である。他のエンコーディング評価および／またはイメージ評価を、当技術分野で既知のように利用して、エンコードされたコンテンツの品質を決定することができ、動きベクトルが多様であるか変化しているフレームの領域の識別、圧縮方式形成ベクトル（compression scheme formation vectors）の評価、量子化の値、マクロブロックの影響、冗長性を有する区域、およびエンコーディングの品質を測定するために、潜在的にエラーを示す可能性がより高いブロックを識別する他の要因の評価、ならびに品質を査定する他の方法または、複数の方法の組合せなどを利用することができる。
【００４５】
コンテンツの品質を決定する際に、いくつかの実装のシステムは、エンコーディング中にコンテンツの部分的デコードを実行することによって、エンコード・プロセスの一部として品質データ（例えば、ＪＮＤおよび／またはＰＳＮＲデータ）を入手する。通常、部分的デコードは、コンテンツの完全なエンコーディングの前であるが、コンテンツをエンコードすることの悪影響の少なくとも一部を評価できる段階で、開始することができる。部分的デコードは、評価できるコンテンツを作り、かつ／または後に評価される（例えば、ＰＳＮＲ値、ＪＮＤ値、および／またはある他の歪みの尺度）実質的に完全にデコードされたフレームを作る。通常、エンコーディングは、例えば、離散コサイン変換（ＤＣＴ）、あるフレームから別のフレームに進むインター・フレーム圧縮、エントロピ・エンコーディング、量子化、および／または他のエンコーディング・レイヤを利用する、エンコーディング・プロセスのレイヤ化されたセットである。部分的デコードを、例えばＨＲＤ４２０を介して開始して、エンコーディングの１つまたは複数のレイヤの間のある時のストリームを評価して、所望のＰＳＮＲ、ＪＮＤ、または他の評価結果を生成することができる。その後、評価結果を閾値レベルと比較して、エンコードするプロセッサに返すことができるエンコーディング品質の尺度を入手する。
【００４６】
エンコードされた信号の品質の評価に関するＰＳＮＲ、ＪＮＤ、および／または他のパラメータの選択および使用は、処理能力および／または処理オーバーヘッド、期待される実行時間、結果が必要な速度、ならびに他の要因を含む、多数の要因に依存する可能性がある。例えば、エンコードされたコンテンツをリアルタイム・レートで評価するときには、このシステムは、ＰＳＮＲの決定が、通常は相対的にすばやいアルゴリズムを使用するので、評価をＰＳＮＲに制限することができる。評価の速度がそれほどクリティカルでない、および／または信号処理能力が十分である情況では、ＪＮＤ評価を使用することができる。
【００４７】
いくつかの実装は、ＰＳＮＲとＪＮＤとの両方を使用するなど、複数の比較および／または品質評価を利用する。このシステムは、いくつかの実装で、さらに、エンコーディングを評価し、品質を決定するのに１つまたは複数の比較のうちのどれを使用するかをユーザが選択することを可能にすることができる。同様に、ユーザは、複数のアルゴリズムおよび／または比較の間の重み付け（ユーザの進歩したレベルに依存して）を指定することができ、さらに、利用される処理能力の量を指定することができる。
【００４８】
評価を、フレーム全体に対して実行することができ、評価は、フレームごとに、サブフレームごとに、またはフレームのグループ化に対して実装される。処理速度および／または処理オーバーヘッドについて補償するために、いくつかの実装で、このシステムは、統計的サンプリング機構を使用して、特定のイメージ内のコンテンツの１つまたは複数のブロックをランダムに、任意に、および／または選択的に取得し、その１つまたは複数のブロックについて、現在のＰＳＮＲ値、ＪＮＤ値、および／または他の評価技法をサンプリングする。このサンプリングは、サンプリングされるイメージの全体的な歪み（distortion）の統計的マッピングを生成することを可能にする。いくつかの実装で、このサンプリングは、エンコードされた信号を正確に評価し、エンコーディング・レベルに対する調整をもたらすのに十分な情報を提供する。サンプリングし、かつ／または評価を案内するためにブロックを選択する際に、いくつかの実施形態は、動きベクトルが相対的に大きく変化するか移動しつつある領域について、圧縮方式形成ベクトル、量子化の値（量子化の粗い値は、相対的に大きい量の圧縮を示す可能性がある）、および他の要因をチェックして、エンコーディング品質の相対的に正確な表現を提供し、かつ／またはエンコーディングの品質の測定に関する１つまたは複数の誤差を示す可能性が潜在的により高いブロックを識別する。
【００４９】
図６に、エンコードされたコンテンツを評価するプロセス６２０の単純化された流れ図を示す。ステップ６２２で、コンテンツ・ストリームの少なくとも一部を、そのストリームがエンコードされているときにデコードする。ステップ６２４で、相対的に高い圧縮の区域など、フレームまたはピクチャ内の１つまたは複数の区域を識別する。ステップ６２６で、少なくともこれらの識別された区域を評価し、評価の結果を１つまたは複数の閾値レベルと比較する。ステップ６３２で、このプロセスは、結果がその１つまたは複数の閾値レベルを満足するか、または超える（あるいは、評価されるパラメータおよび／または閾値限度に依存して、それ未満になる）かどうかを決定する。評価の結果が閾値を満足し、したがって品質レベルが満足なものであるときには、このプロセスはステップ６４２にスキップする。
【００５０】
その代わりに、品質が閾値限度未満になるときには、このプロセスはステップ６３４に入り、ここで、再エンコードが実行されるべきかどうかを決定する。やはり、この決定は、閾値レベルに基づいて、このプロセスおよび／またはシステムによって行うことができる。その代わりに、このシステムは、エンコードされたストリームのうちで潜在的品質問題を有する区域を識別し、再エンコードされるべきセグメントをユーザが選択することを可能にすることができる。例えば、潜在的品質問題を有する区域、相対的に高い圧縮を有する区域、デコーダが失敗する区域および／または潜在的エラーが発生する区域、ならびに／あるいは他の関連する情報を識別するレポートおよび／またはタイムライン、を生成することができる。再エンコードが開始されるべきときには、このプロセスはステップ６３６に入り、ここで、セグメント再エンコードを開始する。再エンコードの後に、このプロセスはステップ６２４に戻る。
【００５１】
再エンコードが実行されないときには、ステップ６４０に入り、ここで、識別されたセグメントについて失敗した１つまたは複数のデコーダ・モデルを記録する。ステップ６４２では、プロセス６２０は、エンコードされたコンテンツ・ストリームの終りに達したかどうかを決定する。そうでない場合には、このプロセスはステップ６２２に戻る。そうである場合には、このプロセスは終了する。
【００５２】
当技術分野で既知の通り、ＡＶＣ、ＶＣ１、ＭＰＥＧ２、および他のエンコーディング方式など、いくつかのエンコーディング方式および／またはエンコーディング標準規格は、１つまたは複数の異なるフレームを参照して１つのピクチャまたはフレームを定義することによって、維持されなければならないデータの量を減らす。例えば、第１のフレームが、第２のフレームを参照し、第２のフレームに対して行われる変更を定義して、第１のフレームを得ることができる。さらなる例として、ＡＶＣ圧縮方式は、通常、大きいコーディング効率ゲインのために、フレームのインター・フレーム予測に頼る。インター予測のタイプは、フレーム・タイプすなわち、Ｐフレーム（予測フレーム）、Ｂフレーム（両方向予測フレーム）、Ｉフレーム（イントラ・フレーム）、または他の定義されたフレーム・タイプのいずれであるかに依存する。Ｐフレームは、通常は１つの他の基準フレームから予測することができ、Ｂフレームは、通常は２つの他の基準フレームの組合せから予測することができる。いくつかの実施形態は、セグメント再エンコードを実装する際に、複数のフレームの間のインター予測方式を妨害するのを避けることを試み、かつ／または正確なデコーディングを提供するために参照を再指定する。
【００５３】
例えば、ＡＶＣなどのいくつかのエンコーディング仕様は、基準フレームのインデックスを格納するのに使用される基準フレーム・リスト（ＡＶＣの場合には、時々Ｌ０およびＬ１と呼ばれる２つの基準フレーム・リストが通常は維持される）を定義することによって、参照されるフレームの管理をどのように維持し、実装しなければならないかを指定する。デコーダは、デコーディング中に、Ｌ０またはＬ１のいずれかによってインデクシングされる基準フレームのストレージを維持する。フレームをデコードするときに、リストＬ０および／またはＬ１が、対象とするフレームを再構成する際に使用される適当な基準フレームを突き止めるために、対象とするフレームのデコーディングのために参照される他のフレームを識別するためにアクセスされる。
【００５４】
さらに、ＭＰＥＧ２などのいくつかのエンコーディング方式では、コンテンツがビジュアル・コンテンツであるときなどに、ピクチャのフレームが一緒にグループ化される（グループ・オブ・ピクチャすなわちＧＯＰと呼ばれる）。通常はＩフレームから始まり、ＧＯＰを通って規則的なインターバルのＰフレームおよびＩ／Ｐフレームの各対の間の１つまたは複数のＢフレームを含み、閉じた複数のＧＯＰの間のインター予測を許容しない、ＧＯＰの編成および／または構造のゆえに、このエンコーディング方式は、セグメント再エンコードを使用するための便利なインターバルを提供する。ＭＰＥＧ２について、相対的に短いか相対的に少数のフレームを収容するＧＯＰを有することが通常である。例えば、ＭＰＥＧ２について、ＧＯＰは、通常、おおむね再生中の約１／２秒の時間のインターバルと等しい、約１３〜１５個のピクチャまたはフレームを含む（３０フレーム毎秒で再生するときすなわち、１５／３０毎秒または約１／２秒）。相対的に短いＧＯＰは、ＭＰＥＧ２に関する再エンコーディングのスタート・ポイントおよびエンド・ポイントの識別を単純にする。
【００５５】
しかし、ＡＶＣ、ＶＣ１、および他の関連するエンコーディング方式など、他のエンコーディング方式は、しばしば、ＧＯＰ構造を定義しないか、通常はＭＰＥＧ２  ＧＯＰ構造に対してはるかにより大きいおよび／またはより長いＧＯＰ構造を有する。例えば、ＡＶＣのＧＯＰ構造は、いくつかの場合に、１５０個以上のフレームまたはピクチャ（通常、複数のＩフレーム、Ｂフレーム、Ｐフレーム、および／またはＩＤＲフレームを含む）を含むことができる。その結果、ＡＶＣまたはＶＣ１などの方式を用いてエンコードされたＧＯＰに従って再エンコーディングするときに、その再エンコーディングは、多数のピクチャが再エンコードされることをもたらす可能性があり、これは、計算処理上負荷が重く、時間がかかる可能性がある。さらに、長いＧＯＰは、しばしば、再エンコーディングに関して、不便であるか、難しいレベルの粒度（granularity）である。
【００５６】
いくつかの実施形態は、再エンコードされるべきセグメントの長さを減らし、処理オーバーヘッドを減らすと同時に処理時間を減らすために、ＧＯＰ内および／またはサブＧＯＰレベルでセグメントの再エンコードを開始する能力を提供する。ＧＯＰ内またはサブＧＯＰレベルの粒度（granularity）での再エンコードの開始は、スタート・ピクチャ境界およびエンド・ピクチャ境界の外側のフレームがこれらの境界内のフレームを参照しない、再エンコードされる一連のフレームの境界を定めるストリーム内の、スタート・フレームまたはスタート・ピクチャとエンド・フレームまたはエンド・ピクチャと、を識別することによって、および／またはアップグレードされたＰフレームまたはＢフレームでの再エンコードの開始に対してＰフレームまたはＢフレームをＩフレームにアップグレードすることによって、達成される。
【００５７】
図７に、複数のピクチャまたはフレーム７２２を含むコンテンツのストリーム７２０の一部の単純化されたタイムライン表現を示す。このタイムラインは、コーディングされたピクチャのインデックス表現である。アクセスおよびユーザ理解を容易にするために、いくつかの実装では、タイムラインを、エンコード順序に併置された時刻表示順序７２６に対して相対的に生成することができる。上で示したように、フレームは、通常、フレーム・タイプに従って定義され、図７の例では、Ｉフレーム、Ｂフレーム、Ｐフレーム、およびＩＤＲフレームとして指定される。セグメント再エンコードを開始する前に、いくつかの実施形態は、ストリーム７２０のセグメントを、再エンコードされる部分に対して評価して、ピクチャ参照および／または依存性の妨害を避けることを試みて再エンコーディングを実装できるかどうか、およびどこで実装できるか、を決定する。
【００５８】
いくつかの実施形態は、ストリーム７２０のフレーム７２２を評価して、１つまたは複数のセグメント再エンコード・スタート・ポイントまたはイン・ポイントと、１つまたは複数のエンド・ポイントまたはアウト・ポイントとを識別する。いくつかの例で、例えばＡＶＣを満足するときに、参照リストＬ０およびＬ１が、対象とするフレームが参照する他のフレームを決定するのに利用される（例えば、対象とするフレームＢピクチャ７３０は、将来に４フレーム離れたＩフレーム７３２および過去に５フレーム離れたＢピクチャ７３４を参照する）。参照リストＬ０および／またはＬ１は、将来への１つまたは複数の基準ピクチャおよび／または過去への１つまたは複数の基準ピクチャを決定するためにアクセスされる。
【００５９】
上で説明したように、いくつかのエンコーディング標準規格は、複数のフレームの参照を提供し、参照リストが、基準ピクチャのインデックスを格納するのに使用される。デコーダは、基準ピクチャのストレージを維持し、予測を実装するために基準フレームをルックアップするのに、このリストを使用する。セグメント再エンコード中に、いくつかのシステムは、他のフレームまたはピクチャへの参照を妨害することを避けることを試みる。ストリーム７２０を評価する際に、いくつかの実施形態は、提案されたセグメントの外側のピクチャが、再エンコードされる提案されたセグメント内のピクチャを参照してるかどうかを決定することによって、適当な再エンコード・スタート・ポイントおよび／またはエンド・ポイントを識別することを試みる。いくつかの実装で、ピクチャ・タイプ（例えば、Ｉ、Ｂ、Ｐ、ＩＤＲ）、持続時間、ビット単位のサイズ、いくつかの例でバッファ状態（例えば、ＨＲＤバッファ状態など）、および／または他の関連情報など、ストリームのピクチャに関連する情報を含む、データ構造体などの情報を含むインデックスが生成される。ピクチャのインデックスには、そのピクチャを参照するエンコードされたストリーム内の他のピクチャ７５４〜７５８の、タイムライン・インデックスなどのインデックスまたはリスティング７５２をも含めることができる。
【００６０】
この、他のピクチャのリスト７５２は、多数の異なるフォーマットおよび／または構成で格納することができ、いくつかの実装では、メタデータおよび／またはタイムライン・ピクチャ・データ構造体を付加されたリストして格納される。例えば、図７に、Ｉピクチャ７５０を参照している各ピクチャ７５４〜７５８を識別する参照リスト７５２と共にＩピクチャ７５０を示す。このインデックスは、システムおよび／またはユーザが、検討されているピクチャを参照する他のピクチャをすばやく簡単に識別することを可能にする。
【００６１】
ピクチャを参照するピクチャのインデックス７５２は、実質的に任意の個数のピクチャを含むことができる。例えば、ストリームまたはＧＯＰの先頭に位置する完全に黒のディスプレイ・スクリーンを生成するコンテンツの１フレームを、そのストリームまたはＧＯＰ内のすべての他の黒いフレームによって参照することができる。しかし、いくつかの実装で、エンコードされたストリームの特定のプロファイルおよびレベルが、あるピクチャを参照できるピクチャの個数に対する限界をセットアップすることができる。
【００６２】
リスト７５２は、再エンコードされるべきセグメントまたはサブＧＯＰの潜在的なスタート・ポイントおよびエンド・ポイントを識別するためのストリーム７２０の評価を単純にする。参照リスト７５２にアクセスすることによって、対象とするピクチャを参照するピクチャを識別する検索アルゴリズムを使用することができる。それに加えておよび／またはその代わりに、このシステムは、対象とするピクチャが参照するピクチャを決定するのに使用されるアルゴリズムを使用することができる。
【００６３】
再エンコード・セグメント識別アルゴリズムは、コンテンツのストリーム７２０に沿ったセグメント・スタート・ポイントおよびセグメント・エンド・ポイントを識別する。いくつかの実施形態は、ストリームのうちで再エンコードすべきものとして識別される部分またはその付近でスタート・ポイントおよびエンド・ポイントを識別することを試みる。さらに、いくつかの実施形態は、再エンコードすべきものとして識別されるセグメントから離れた穏当な位置または穏当な個数のピクチャを定義する限度をセットする。例えば、ユーザが、ほぼ時刻「Ｔ」（例えば、ストリームに約５０秒入ったところ）で再エンコードを開始することを選択するときに、そのユーザは、再エンコードされるセグメントのスタート・ポイントがその「Ｔ」ポイント付近になることを期待するであろう。したがって、この限度は、決定されたスタート・ポイントが、要求されたスタート・ポイントを近似することを保証することを試みる。いくつかの実施形態は、複数の潜在的なスタート・ポイントおよびエンド・ポイントを識別する。この複数の潜在的なスタート・ポイントおよびエンド・ポイントに基づいて、ユーザは、使用すべきポイントを選択することができる。
【００６４】
図８に、いくつかの実施形態によるセグメント再エンコード・スタート・ポイントおよびセグメント再エンコード・エンド・ポイントを識別するのに使用されるプロセス８２０の単純化された流れ図を示す。図７および８を参照すると、ステップ８２２で、候補スタート・ポイント・ピクチャが、コンテンツのストリーム７２０の評価中に識別されるセグメントに対して相対的に識別される。例えば、ステップ８２２には、再エンコードすべきものとして識別されたセグメント（ステップ５３４で識別されたセグメントなど）の事前定義の限度内にＩピクチャまたはＩＤＲピクチャがあるかどうかの決定、ユーザによる選択、オリジナル・コンテンツとの比較を介する識別、および／または候補ピクチャを識別する他の方法、を含めることができる。ステップ８２４で、プロセス８２０は、選択された候補スタート・ピクチャに対して相対的に後続のピクチャへ、例えばタイムライン７２０上で１ピクチャ前方（forward）へ、スキャンする。
【００６５】
ステップ８２６で、評価されているピクチャの参照リスト７５２が使用可能であるときにはこれにアクセスして、識別された候補スタート・ポイント・ピクチャの以前（previous）のピクチャが、評価されているピクチャを参照し、したがって潜在的なセグメント（potential segment）の外側にあるかどうかを決定し、あるいは、他の評価を実行して基準ピクチャを決定する。スキャンされたピクチャの１つが、候補スタート・ポイントの以前（previous）（例えば、図７では左）のピクチャによって参照されると決定される場合には、このプロセスは、ステップ８３２に入り、ここで、候補スタート・ポイントを無効なスタート・ポイントとして定義する。ステップ８３４で、新しい候補スタート・ポイントを選択し（例えば、以前の候補の以前（図７では左）のピクチャ）、評価する。通常、その後の候補スタート・ポイント・ピクチャは、少なくとも、ステップ８２６で識別されたピクチャまたはそのピクチャの以前のピクチャである。この評価は、セグメントが自己完結的であり、このセグメントの外側のピクチャが、このセグメント内のピクチャを参照していないことを、保証することを試みる。この理由は、再エンコード後のこのセグメント内のピクチャに変化を生じさせる可能性が高いからである。その後、このプロセスは、ステップ８２６に戻って、後で選択された候補スタート・ポイントを評価する。
【００６６】
ステップ８２６で、評価されているピクチャが、候補スタート・ポイントの向こうのピクチャによって参照されないと決定されるときには、ステップ８３０に入り、ここで、評価された順方向ピクチャの個数を、デコード・ピクチャ・バッファのサイズなど、所定の閾値と比較する。通常、順方向の評価は、デコード・ピクチャ・バッファのサイズを超えて進む必要がない。というのは、参照されるピクチャが、現在のピクチャがデコードされる前にデコードされなければならないので、デコーディング・システムが、通常はこのポイントの向こうのピクチャを参照しないからである。
【００６７】
ステップ８３０で、候補スタート・ポイントから評価されたピクチャの個数が閾値（例えば、バッファ・サイズ）以上ではないと決定されるときには、このプロセスは、ステップ８２４に戻って、再エンコードすべきセグメント内の別のピクチャを評価する。その代わりに、評価されたピクチャの個数が限度以上であり、ピクチャが候補スタート・ポイントの前のピクチャによって参照されないときには、ステップ８３６に入り、ここで、候補スタート・ポイントを有効なスタート・ポイントとして定義する。
【００６８】
候補スタート・ポイントが、ステップ８３６で有効として識別されたならば、再エンコードされるセグメントのエンド・ポイント・ピクチャを識別する。ステップ８４０で、最初のエンド・ポイント候補を選択し、このシステムは、識別されたスタート・ポイント・ピクチャ、ＩＤＲピクチャ（例えば、ＡＶＣに関して）、または他のインジケータに達するまで、候補エンド・ポイントから候補セグメントのピクチャを通って逆方向にスキャンして、提案された再エンコード・セグメントの外側のピクチャがセグメント内のピクチャを参照するかどうかをさらに決定する。上で示したように、スタート・ポイントを評価するときに、スタート・ポイントから順方向に評価されるピクチャは、通常、デコード・ピクチャ・バッファのサイズに制限される。候補エンド・ポイントから後ろにピクチャを評価するときには、通常、評価されるピクチャの個数に限度はなく、いくつかの場合に、スタート・ポイント・ピクチャまでのすべてのピクチャが評価される。しかし、基準ピクチャは、ＶＣ１およびＡＶＣなどの多数のエンコーディング方式について、逆方向でＩＤＲピクチャの向こうのピクチャを参照しない。ＩＤＲピクチャは、イントラ予測され、したがって他のピクチャを参照しない。さらに、ＩＤＲピクチャの出現は、通常、デコーダに現在格納されている基準ピクチャをフラッシュさせ、したがって、デコード順で後続のデコードされるピクチャは、通常、ＩＤＲピクチャの前のピクチャを参照しない。
【００６９】
ステップ８４０で、候補セグメントの再エンコード・エンド・ポイントを選択する。やはり、エンド・ポイントは、再エンコーディングになるべきものとして識別されたセグメントの近くで選択され、ユーザによって選択することができ、再エンコードされるセグメントに近接するＩピクチャまたはＩＤＲピクチャおよび他の選択方法とすることができる。ステップ８４２で、プロセス８２０は、評価されているピクチャが、識別された候補エンド・ポイント・ピクチャの向こう（例えば、図７では候補の右）のピクチャによって参照されるかどうかを決定する。いくつかの実施形態で、ステップ８４２での評価は、参照リスト７５２を使用することによって単純にされる。評価されているピクチャが、候補エンド・ポイントの向こうのピクチャによって参照される場合には、ステップ８５０で新しい候補エンド・ポイントを選択し、このプロセスは、ステップ８４２に戻って、その新しい候補エンド・ポイントに対して相対的にピクチャを評価する。
【００７０】
ステップ８４２で、評価されているピクチャが、候補エンド・ポイントの向こうのピクチャによって参照されないと決定されるときには、ステップ８４４に入り、ここで、評価されているピクチャが、ステップ８３６で識別されたセグメントの再エンコード・スタート・ポイントピクチャであるかどうかを決定する。評価されているピクチャがスタート・ポイント・ピクチャである場合には、このプロセスはステップ８５４に継続し、そうでない場合には、このプロセスはステップ８４６に移動する。ステップ８４６では、このプロセスは、評価されているピクチャがＩＤＲピクチャであるかどうかを決定する。ピクチャがＩＤＲピクチャではない場合には、このプロセスは、ステップ８５２に継続して、前のピクチャを選択し、その後、ステップ８４２に戻って、選択された前のピクチャを再評価する。
【００７１】
ステップ８４４および８４６で、評価されているピクチャが、スタート・ピクチャまたはＩＤＲピクチャであると決定されるときに、このプロセスは、ステップ８５４で、候補エンド・ピクチャを、再エンコードされるセグメントの境界を定義する有効なセグメント再エンコードエンドピクチャとして識別する。通常、ピクチャは、キャッシュのフラッシュおよび類似物に起因して、逆方向でＩＤＲピクチャの向こうのピクチャを参照せず、したがって、評価を、ＩＤＲピクチャで停止させることができ、この候補エンド・ポイント・ピクチャは、有効として識別され、したがって、再エンコードされるセグメントの境界が確立される。
【００７２】
いくつかの実装で、ステップ８２２での候補スタート・ポイント・ピクチャの選択は、少なくとも部分的に、候補スタート・ポイント・ピクチャが満たさなければならない参照を制限するために、Ｉフレームに制限され、ここでは、そのＩフレームの前のピクチャは、そのＩフレームまたはそのＩフレームの向こうのピクチャを参照しない。代替案では、いくつかの実施形態は、候補スタート・ポイント・ピクチャをＢピクチャおよび／またはＰピクチャにすることを許容する。例えば、Ｂピクチャは、通常、そのＢピクチャを実際にデコードできるようになる前に既にデコードされている１つまたは複数のフレームを参照する。したがって、いくつかの実施形態は、再エンコードを実装する際に、再エンコードを開始し、そのＢピクチャの参照をリセットするか再定義し、その結果、そのＢピクチャが、前のフレームを参照しないＩピクチャに置換されるようにする。したがって、いくつかの実施形態は、サブＧＯＰを定義し、そのサブＧＯＰを再エンコードすることによって、長いＧＯＰ（例えば、ＡＶＣエンコーディング方式およびＶＣ１エンコーディング方式のＧＯＰ）について補償する。
【００７３】
Ｉピクチャの生成および／またはＢピクチャもしくはＰピクチャのＩピクチャへの変換の前に、いくつかの実施形態は、Ｉフレームへのアップグレードに関連するバッファおよび／または処理オーバーヘッドが使用可能であることを検証する。例えば、アップグレードすべきＰフレームの選択は、選択され、Ｉフレームへの変換を可能にするのに十分な処理バッファ・オーバーヘッドがあることが検証される。変換に必要なオーバーヘッドの評価は、少なくとも部分的に、変換されるピクチャに対する相対的な使用可能バッファ・レベルが、十分なデータを後のデコード中に抽出することを可能にするのに十分に高いことの検証を含む。
【００７４】
このシステムは、様々なバッファ・モデルを検証する（例えば、図５のプロセス５２０を介する検証）際に生成されるデータを利用することができる。検証データは、さらに、ＰフレームまたはＢフレームをＩフレームに変換するのに使用可能なヘッドルームおよび／またはオーバーヘッドの量を決定するのに使用することができる。１つまたは複数のオーバーヘッド閾値を使用して、エンコーダがバッファのオーバーフローを予測するのに１つまたは複数の制御アルゴリズムを組み込むように、潜在的な候補スタート・ポイントを評価することができ、処理レベルおよび／またはバッファ・レベルが最大バッファ・レベルに近いか最大バッファ・レベルからの閾値限度以内にある場合には、このシステムは、ＢフレームまたはＰフレームのＩフレームへの変換を避ける。したがって、これらの実施形態は、再エンコードが低い品質をもたらす可能性がある、相対的に低いレベルまたはビットレートである場合に、その要求を制限し、かつ／または避ける。いくつかの実施形態は、現在のＢフレームをＩフレームに変換するときに、ピクチャ・サイズ（ビット数）の変化の予測を得るために、１つまたは複数の、以前のＢフレーム対Ｉフレームサイズ比を調査する。ピクチャ・サイズの予測された変化が、バッファ内の使用可能スペースと比較される。十分なスペースがあり、通常は誤差のマージンをもたらす過剰なスペースがあるときに、このシステムは、ＢフレームまたはＰフレームからＩフレームへの変更を実装し、バッファ・レベルを評価して、レベルを超えたかどうかを決定する。レベルを超えるときには、セグメント再エンコードを実行してサイズを調整することができ、あるいは、その変換を利用しない。代替案では、変化がピクチャ・サイズであることを予測する代わりに、いくつかの実施形態は、ＢフレームまたはＰフレームからＩフレームへの変換を実装し、その後、バッファ・サイズを評価して、失敗が発生し、かつ／または再エンコードが実行されるべきかどうかを決定する。
【００７５】
再エンコードを実装し、再エンコードされたセグメント（１つまたは複数）をメイン・コンテンツに組み込む際に、いくつかの実施形態は、バッファ・モデルを評価して、有効な再エンコードが所望のセグメントで実装されたかどうか、ならびに／あるいはモデル標準規格および／またはモデル仕様を満足しながら所望のエンコーディングを可能にするようにバッファ・モデルを調整することができるかどうかを決定する。
【００７６】
図９に、再エンコードに関連してバッファ・モデルの評価を決定し、実装するのに使用されるプロセス９２０の単純化された流れ図を示す。ステップ９２２で、このプロセスは、コンテンツ・ストリームを解析し（例えば、ベース・エンコーディング中または初期エンコーディング中に）、バッファ・モデルの分析およびシミュレーションで使用されるパラメータおよび／またはメタデータを識別する。ステップ９２４で、バッファ・モデル動作（例えば、部分的にビットレートまたはバッファ・サイズの変化に起因するバッファに対する影響）のシミュレーションを含み、ならびに／あるいは再エンコードされるセグメントおよびコンテンツ・ストリームのパラメータおよび／またはメタデータのマージング（merging）におけるバッファ・モデル処理を実装する。ステップ９２６で、１つまたは複数のバッファ・モデル・フィールドを、ストリーム内で訂正する。
【００７７】
バッファは、「リーキー」バケット・モデルに従ってモデル化することができる。リーキー・バケット・モデルは、いくつかの例で、３つのパラメータすなわち、伝送ビットレート（Ｒ）、バケット・サイズまたはデコーダ・バッファ・サイズ（Ｂ）、およびバッファ充満度（Ｆ）によって特徴を表すことができる。いくつかの実装で、伝送ビットレートＲは、ビットがデコーダ・バッファに入るときのピーク伝送ビットレート（ビット毎秒単位）に基づくものとすることができる。固定ビットレート（ＣＢＲ）シナリオでは、ビットレートＲは、しばしば、チャネル・ビット・レートおよび／またはビデオ、ビデオ・セグメント、もしくはビデオ・チップの平均ビットレートである。バケットまたはデコーダ・バッファのサイズＢ（ビット単位）は、ビットレート変動を平滑化することができるが、通常、期待されるデコーディング・デバイスの物理バッファ未満のレベルで維持される。バッファ充満度Ｆは、デコーダがバッファからのビットの取り出しを開始する前の初期デコーダ・バッファ充満度（ビット単位）によって定義することができる。いくつかの例で、初期スタートアップ遅延（Ｄ）を、充満度ＦおよびビットレートＲによって定義することができ、ここで、遅延Ｄ＝Ｆ／Ｒ秒である。
【００７８】
図１０に、リーキー・バケット・モデル１０２０の単純化されたグラフィカル表現を示す。通常、リーキー・バケット・モデルでは、ビットは、充満度Ｆのレベル１０２４までは傾き１０２２によって表されるレートＲでバッファに入り、その後、第１のフレームの初期個数のビットｂ（０）１０２６が、時刻ｔ１に取り出される。ビットは、ビットレートＲでバッファに入り続ける。デコーダは、所与の瞬間（例えば、それぞれｔ２、ｔ３、．．．、ｔｎ）に、後続フレームのビットｂ（１）１０３０、ｂ（２）１０３２、．．．、ｂ（ｎ−１）、ｂ（ｎ）１０３４を取り出し続ける。通常、固定ビットレート（ＣＢＲ）を提供するシステムでは、傾き１０２２は、データ転送中に固定された所定のレートを有する固定ビットレートの代表値に実質的に等しい。可変ビットレート（ＶＢＲ）を用いると、多くのシステムは、バッファが充填されるまでは実質的に最大のレートでコンテンツを供給することによって動作し、その後、いくつかの例ではバッファからのビットの取り出し後に、待機し、充填を再開する。
【００７９】
図１１に、可変ビットレートによるリーキー・バケット・モデル１１２０の単純化されたグラフィカル表現を示す。ビットは、傾き１１２２によって表される最大フィル・レート付近で供給される。ビットは、バッファが満杯１１２４になるまで、そのレートで供給される。期間１１２６中には、ビットは、バッファに供給されない。１１３０でのビットの取り出しの後に、ビットは、もう一度実質的に最大レートでバッファに供給される。
【００８０】
プロセス９２０の解析フェーズ９２２を実装する際に、いくつかの実施形態は、コンテンツ・ストリームに関するパラメータまたはデータを識別し、収集し、かつ／または抽出する。少なくとも部分的にこれらのパラメータに基づいて、リーキー・バッファ・モデルを、例えば、以下で「ｂｕｆｆｅｒＭｏｄｅｌ」と称する次の構造体によって表すことができる。  
・  ａｕｔｃ：アクセス・ユニット時間増分（逆フレームレート）、  
・  ｂｉｔｒａｔｅ：コーディングされたデータがＨＲＤの入力に供給されるビットストリームレート指定  
・  ｖｂｖｓｉｚｅ：ＨＲＤバッファのサイズ、  
・  ｉｓｃｂｒ：ＣＢＲストリームを示すフラグ、および／または  
・  ｌｏｗｄｅｌａｙ：低遅延モードを示すフラグ。
【００８１】
ｌｏｗｄｅｌａｙフラグは、（例えば、「１」をセットされたときに）シーケンスがＢピクチャを含まないこと、フレーム再順序付け遅延がビデオ・バッファリング・ベリファイヤ（ＶＢＶ）記述に存在しないこと、および／またはビット・ストリームが「ビッグ・ピクチャ」を含む場合があり、通常期待される時間でのピクチャのデコーディングが、ＶＢＶバッファをアンダーフローさせる可能性があることを示す。
【００８２】
いくつかの実装で、例えばＡＶＣおよび／またはＶＣ１と共に適用されるときに、１つのストリームが複数のリーキー・バッファ・モデルを有することができる。エンコーダは、いくつかの要求されるリーキー・バケットに含まれるビデオ・ビット・ストリームを作成することができ、あるいは、ビット・ストリームが生成された後にパラメータのセットを単純に計算することができる。解析プロセス中に、アクセス・ユニットごとに、ピクチャ・サイズ、ピクチャ・タイプ、ピクチャ位置、タイミング情報、および／または各コーデックに固有のある情報を収集することができる。解析を介して識別された情報およびリーキー・バッファ・モデルに基づいて、各アクセス・ユニットのバッファ・レベルの値を決定するか計算することができる。いくつかの実施形態で、取り出された解析された情報および／またはバッファリング・レベルを、次の構造のうちの１つまたは複数（これらに限定はされない）によって定義することができる。  
・  ｔａｉ：アクセス・ユニットからの最初のビットの到着時刻、  
・  ｔａｆ：アクセス・ユニットからの最後のビットの到着時刻、  
・  ｔｒｎ：バッファからのアクセス・ユニットの取り出し時刻、  
・  ｔｏｎ：アクセス・ユニットの表示時刻、  
・  ｐｒｅＢｕｆｆｅｒＬｅｖｅｌ：取り出しの前の取り出し時刻でのバッファ・レベル、  
・  ａｕｓｉｚｅ：アクセス・ユニットのサイズ、  
・  ｍａｘＢｕｆｆｅｒＬｅｖｅｌ：この取り出し時刻で見られる最大バッファ・レベル、  
・  ｍｉｎＢｕｆｆｅｒＬｅｖｅｌ：この取り出す時刻で見られる最小バッファ・レベル、  
・  ｕｎｂｏｕｎｄＢｕｆｆｅｒＬｅｖｅｌ：バッファ・サイズに制限されないバッファ・レベル（無限バッファ・サイズを有するバッファ・レベル）、および／または  
・  他の関連情報。
【００８３】
例えばＡＶＣに固有とすることができる、追加のまたは代替の情報を定義することができる。そのような追加情報は、次を含むことができるが、これらに限定はされない。  
・  ｉｓｂｐｅｒｉｏｄ：これがバッファリング期間（ＧＯＶＵスタート）であるかどうかを示すフラグ、  
・  ｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙ：特定の取り出し時刻のデコード前遅延、  
・  ｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙ＿ｏｆｆｓｅｔ：特定の取り出し時刻のデコード前遅延オフセット、および／または  
・  ｃａｌｃ＿ｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙ：特定の取り出し時刻の理想的なデコード前遅延の計算された値。
【００８４】
例えばＭＰＥＧに固有とすることができる、追加のまたは代替の情報を定義することができる。そのような追加情報は、次を含むことができるが、これらに限定はされない。  
・  ｉｓｇｏｖｕ：新しいＧＯＰを示すフラグ、  
・  ｖｂｖ＿ｄｅｌａｙ：ＣＢＲの場合に各ピクチャのバッファ充満度を示す、および／または  
・  ｃａｌｃ＿ｖｂｖ＿ｄｅｌａｙ：各ピクチャのバッファ充満度の理想的な値。
【００８５】
例えばＶＣ１に固有とすることができる、追加のまたは代替の情報を定義することができる。そのような追加情報は、次を含むことができるが、これらに限定はされない。  
・  ｉｓｇｏｖｕ：新しいエントリ・ポイントを示すフラグ、  
・  ｈｒｄ＿ｆｕｌｌ：各ピクチャのバッファ充満度を示す、および／または  
・  ｃａｌｃ＿ｈｄｒ＿ｆｕｌｌ：各ピクチャのバッファ充満度の理想的な値。
【００８６】
アクセス・ユニットについて、いくつかの実施形態は、例えばＭＰＥＧの場合にｖｂｖ＿ｄｅｌａｙ、ＶＣ１の場合にｈｄｒ＿ｆｕｌｌ、ＡＶＣの場合にｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙなど、ストリームが示さなければならないバッファ充満度の値を計算することができる。
【００８７】
解析プロセス９２２を介して、アクセス・ユニットに関する情報のベクトル（例えば、ＡＶＣの場合にＡＶＣＡＵＩｎｆｏのベクトル）、Ｎ個のリーキー・バッファリング・モデル（Ｎは、解析されたストリーム内で指定されるリーキー・バッファリング・モデルの個数である）、およびこれらのモデルごとに、バッファリング・レベルの対応するベクトル（例えば、ＡＶＣの場合にＡＶＣＡＵｂｕｆｆｅｒＬｅｖｅｌのベクトル）が生成される。解析を介して識別される情報、パラメータ、および／またはメタデータは、それに加えておよび／またはその代わりに、所与のビット・ストリームの伝送レート・パラメータおよび／またはバッファ・サイズ・パラメータを変更することによって１つまたは複数の新しいバッファリング・モデルをシミュレートするのに、あるいは有効なバッファ・モデルを維持するためにセグメント再エンコードを実行するときに、使用することができる。
【００８８】
解析を介して識別されるパラメータ、情報、および／またはメタデータを利用して、１つまたは複数のリーキー・バッファ・モデルをシミュレートすることができ、特定のストリームに適用できる１つまたは複数の新しい有効なバッファ・モデルの作成が可能になる。シミュレーション９２４は、いくつかの実施形態で、ビットレート、バッファ・サイズ、および／またはビットレート・モード（例えば、ＶＢＲ／ＣＢＲ）を変更するのに部分的に使用される。例えば、ＡＶＣの場合のシミュレーションを、次のように記述することができる。
【００８９】
【表１】
0005404038.tif 000002
【００９０】
各シミュレーションは、オーバーフロー閾値および／またはアンダーフロー閾値など、１つまたは複数のバッファ閾値を超えるときを識別し、検出されたオーバーフローおよびアンダーフローの回数の結果をｂｕｆｆｅｒＭｏｄｅｌ構造体で返すことならびに／あるいはストリームおよび／またはセグメントにまたがるバッファ・レベルのベクトルを返すことなど、の結果を返す。シミュレーションが、オーバーフローまたはアンダーフローなしで成功するときには、ストリームを、下でさらに説明するストリーム訂正フェーズ中に、上で渡される新しいｂｕｆｆｅｒＭｏｄｅｌに基づいて変更することができる。いくつかの実装は、さらに、例えばＶＣ１およびＭＰＥＧ２について、新たに決定された値がベース・エンコードからの値と一致するときに再分析を停止することを可能にする、バッファ再分析の改善を試みる。さらに、いくつかの実施形態で、バッファ分析は、これらの情報、パラメータ、および／またはメタデータを分析することによって単純にされ、通常は、ストリーム全体をディスクから読み取り、データを解析する必要がない。
【００９１】
訂正フェーズ９２６は、部分的に、いくつかの実施形態で、もはや有効ではないものとして識別されたベース・エンコード内で指定されるリーキー・バッファ・モデルを訂正し、または置換するための、フィールドの書き直しからなる。ストリームは、上で説明し下でさらに説明するセグメントの再エンコードの場合に、シミュレーションおよび／またはマージング処理（merging processing）９２４に由来する新しいモデルに従うように変更される。訂正フェーズは、部分的に、１つまたは複数のフィールドの書き直しを実行する。例えば、ＭＰＥＧ２の場合に、訂正フェーズは、次のフィールドのうちの１つまたは複数の書き直しを引き起こすことができる。  
・  ｂｉｔ＿ｒａｔｅ＿ｖａｌｕｅおよびｂｉｔ＿ｒａｔｅ＿ｅｘｔｅｎｓｉｏｎ：ビットレートの新しい値、  
・  ｖｂｖ＿ｂｕｆｆｅｒ＿ｓｉｚｅ＿ｖａｌｕｅおよびｖｂｖ＿ｂｕｆｆｅｒ＿ｓｉｚｅ＿ｅｘｔｅｎｓｉｏｎ：バッファ・サイズの新しい値、および／または  
・  ｖｂｖ＿ｄｅｌａｙ：各ピクチャのバッファ充満度の新しい値。
【００９２】
同様に、ＶＣ１について、訂正フェーズは、次のフィールドのうちの１つまたは複数の追加のまたは代替の書き直しを引き起こすことができる。  
・  ｈｒｄ＿ｒａｔｅ［ｎ］：この特定のリーキー・バッファ・モデルのビットレートの新しい値、  
・  ｈｒｄ＿ｂｕｆｆｅｒ［ｎ］：この特定のリーキー・バッファ・モデルのバッファ・サイズの新しい値、および／または  
・  ｈｒｄ＿ｆｕｌｌ［ｎ］：この特定のリーキー・バッファ・・モデルの各ピクチャのバッファ充満度の新しい値。
【００９３】
さらに、ＡＶＣに関して、訂正フェーズは、次のフィールドのうちの１つまたは複数の追加のまたは代替の書き直しを引き起こすことができる。  
・  ｂｉｔ＿ｒａｔｅ＿ｖａｌｕｅ＿ｍｉｎｕｓ１［ｎ］：この特定のリーキー・バッファ・モデルのビットレートの新しい値、  
・  ｃｐｂ＿ｓｉｚｅ＿ｖａｌｕｅ＿ｍｉｎｕｓ１［ｎ］：この特定のリーキー・バッファ・モデルのバッファ・サイズの新しい値、  
・  ｃｂｒ＿ｆｌａｇ［ｎ］：この特定のリーキー・バッファ・モデルのＣＢＲ／ＶＢＲフラグの新しい値、  
・  ｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙ［ｎ］：この特定のリーキー・バッファ・モデルのデコーディング遅延の新しい値、および／または
・  ｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙ＿ｏｆｆｓｅｔ［ｎ］：この特定のリーキー・バッファ・モデルのデコーディング遅延オフセットの新しい値。
【００９４】
ｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙの新しい値は、バッファリングレベルベクトルに格納された好ましい値または理想的な値ｃａｌｃ＿ｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙに対応するものとすることができる。ｃａｌｃ＿ｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙの値は、いくつかの実装によれば、次のように計算することができる。  
ｃａｌｃ＿ｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙ＝ｔｇ，９０（ｎ）＝９００００＊（ｔｒ，ｎ（ｎ）−ｔａｆ（ｎ−１））  
ここで、ｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙ＜＝Ｃｅｉｌ（Δｔｇ，９０（ｎ））というＶＢＲの制約に従い、かつ／またはＦｌｏｏｒ（Δｔｇ，９０（ｎ））＜＝ｉｎｉｔｉａｌ＿ｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙ＜＝Ｃｅｉｌ（Δｔｇ，９０（ｎ））というＣＢＲの制約に従う。
【００９５】
セグメント・ベースの再エンコーディングは、少なくとも部分的に、ビデオのセクションの再エンコーディングを可能にして、例えば、ビジュアル品質標準規格を満足しないセグメントの品質を高める。高められた品質は、例えば、セグメントのビットレートを高めることによって達成することができる。セグメント・ベースの再エンコーディングは、それに加えておよび／またはその代わりに、例えば、ストリームの他のセグメントまたはセクションに余分なビットを供給するために、あるセグメント内で利用されるビット数を減らすのに使用することができる。いくつかの実施形態で、変更に起因する下流のアンダーフローおよび／またはオーバーフローを実質的に回避できる、所与のセグメントについて利用できかつ／またはユーザによって指定できる最大ビットレートを決定することが有益である。セグメント再エンコードの前に、ルールに従ったストリームをもたらすビットレート境界およびバッファ充満度境界を決定することができる。例えば、境界を、次のように決定することができる。
【００９６】
【表２】
0005404038.tif 000003
【００９７】
ｍｉｎｉｍｕｍＢｉｔｒａｔｅは、オーバーフローなしのＣＢＲでのレートに対応し、ｍａｘｉｍｕｍＢｉｔｒａｔｅは、アンダーフローなしのレートに対応し、ｍｉｎｉｍｕｍＢｕｆｆｅｒＦｕｌｌｎｅｓｓは、アンダーフローなしのビット単位のターゲット最小バッファ充満度に対応し、ｍａｘｉｍｕｍＢｕｆｆｅｒＦｕｌｌｎｅｓｓは、オーバーフローなしのビット単位のターゲット最大バッファ充満度に対応する。
【００９８】
いくつかの実施形態で、セグメントの再エンコードのために許容できる最大ビットレートを計算するときに、バッファ・モデル・シミュレーションが、例えば、ＭＰＥＧ−２および／またはＶＣ１の場合に無限大のサイズのバッファを用い、ＡＶＣで非制約到着時刻（no constraint arrival time）リーキー・バケット・モデル（ＣＡＴ−ＬＢ）制約で、実行される。これらの制約を適用することによって、バッファ・レベル・グラフのビットレートを０にされたフラット・セクションが実質的に除去され、バッファ・レベルは、バッファ・サイズまたはＣＡＴ−ＬＢ制約によって制限されない。バッファ・レベル構造体内のｕｎｂｏｕｎｄｅｄＢｕｆｆｅｒＬｅｖｅｌの値は、この無制限のバッファ・レベルに対応する。次に、セグメント再エンコードの終りの後の最初のピクチャから始まり、ストリームの終りまたは他の終わるポイント（例えば、いくつかの例で、このエンド・ポイントをフラット・セクション１１２６とすることができる）で終わる、このバッファ・モデル・シミュレーションから生じる最小「無制限」バッファ・レベルの検索を実行することができる。この無制限レベルを、下ではｕｎｂｏｕｎｄｅｄＢｕｆｆｅｒＬｅｖｅｌｂ（Ｍｉｎ）と称する。さらに、ｕｎｂｏｕｎｄＢｕｆｆｅｒＬｅｖｅｌの最大値を、再エンコード・セグメントの後の最初のピクチャから始まり、ストリームの終りまたは他のエンド・ポイントで終わる値を考慮することによって決定することができ、この値を、下ではｕｎｂｏｕｎｄＢｕｆｆｅｒＬｅｖｅｌｂ（Ｍａｘ）と称する。少なくとも部分的にｕｎｂｏｕｎｄｅｄＢｕｆｆｅｒＬｅｖｅｌｂ（Ｍｉｎ）およびｕｎｂｏｕｎｄＢｕｆｆｅｒＬｅｖｅｌｂ（Ｍａｘ）に基づいて、最小レベルおよび最大レベルの変更を、次のように決定することができる。
【００９９】
【表３】
0005404038.tif 000004
【０１００】
ここで、ｕｎｂｏｕｎｄＢｕｆｆｅｒＬｅｖｅｌ（ｎ）は、再エンコードされる最初のピクチャのｕｎｂｏｕｎｄＢｕｆｆｅｒＬｅｖｅｌの値であり、ｐｒｅＢｕｆｆｅｒＬｅｖｅｌ（ｎ）は、再エンコードされる最初のピクチャのｐｒｅＢｕｆｆｅｒＬｅｖｅｌの値である。Ｒが、ストリームの実際のレートを表し、Ｂが、バッファのサイズを表し、ｓｅｇＬｅｎが、再エンコードされるセグメントの秒単位の長さを表すものとすると、最大ビットレートを、いくつかの実装で次のように計算することができる。  
ｍａｘＢｉｔｒａｔｅ＝Ｒ＋ＤｅｌｔａＬｅｖｅｌＭｉｎ／ｓｅｇＬｅｎ
【０１０１】
最小バッファ・レベルは、ベース・エンコードの最後のピクチャの取り出しの後のバッファ充満度（この値は＞＝０にクリッピングされる）からＤｅｌｔａＬｅｖｅｌＭｉｎ値を引くことによって決定することができる。これは、効果的に、バッファ可用性の量のシフトをもたらし、効果的に、グラフ（例えば、グラフ１０２０）を、バッファのアンダーフローを回避することを試みて、ほぼ最小バッファ・レベル分だけ下にシフトする。同様に、ＣＢＲでの最小ビットレートは、ｍｉｎＢｉｔｒａｔｅ＝Ｒ−ＤｅｌｔａＬｅｖｅｌＭａｘ／ｓｅｇＬｅｎに対応するものとすることができ、いくつかの例で、ＶＢＲについて０である。ＣＢＲでの最小バッファ・レベルは、ベース・エンコードの最後のピクチャの取り出しの後のバッファ充満度（この値は＞＝０にクリッピングされる）への（Ｂ−ｕｎｂｏｕｎｄＢｕｆｆｅｒＬｅｖｅｌｂ（Ｍａｘ））の加算として定義することができる。これは、効果的に、バッファのオーバーフローを回避することを試みて、ある量だけグラフを上にシフトする。
【０１０２】
いくつかの実装で、セグメントの再エンコードの後に、ベース・エンコードからのバッファ・レベルおよびアクセス・ユニット情報を再エンコードされたセグメントエンコードデータにマージするマージング９２４が実行される。このマージングは、少なくとも部分的に、バッファ・モデルを再エンコードされたセグメント中および／または再エンコードされたセグメント後に有効に保つことを試みる。少なくともＡＶＣに関するマージング・プロセスの例を、次のように記述することができる。
【０１０３】
【表４】
0005404038.tif 000005
【０１０４】
ここで、引数は、次のように定義することができる。  
・  ｍｅｒｇｅＩｎｄｅｘ：マージング・インデックス、  
・  ａｕＢａｓｅＬｉｓｔ：アクセス・ユニット情報のベース・リスト、  
・  ａｕＢａｓｅＢｕｆｆｅｒ：バッファ・レベルのベース・リスト、  
・  ａｕＳｅｇＬｉｓｔ：アクセス・ユニット情報のセグメント・リスト、  
・  ａｕＳｅｇＢｕｆｆｅｒ：バッファ・レベルのセグメント・リスト、  
・  ｍｏｄｅｌ：使用中のバッファ・モデル、  
・  ａｕＯｕｔＬｉｓｔ：アクセス・ユニット情報の出力リスト、および
・  ａｕＯｕｔＢｕｆｆｅｒ：バッファ・レベルの出力リスト。
【０１０５】
このマージング・プロセスは、オーバーフローおよび／またはアンダーフローの結果の回数を返す。このマージング・プロセスによって生成される出力値は、その後、後続のセグメント再エンコードの新しいベース・エンコードとして使用することができる。マージが、オーバーフローもアンダーフローもなしに成功する場合に、ストリーム・バッファ充満度情報を、訂正フェーズ９２６中にストリームを訂正するのに使用することができる。
【０１０６】
このマージング・プロセスは、いくつかの実装で、ストリーム内に存在するリーキー・バッファ・モデルごとのセグメント再エンコードごとに実行され、ＡＶＣおよびＶＣ１の場合に必ずしも一意ではない。ストリーム内に複数のリーキー・バッファ・モデルがある場合には、１つまたは複数のモデルを、例えばアンダーフローまたはオーバーフローの存在に起因して無効化できることが可能である。いくつかの実施形態で、無効なモデルは、無効として指定され、かつ／またはそのストリームについて有効であることがわかっているバッファ・モデルによって置換される。例えば、失敗したモデルのバッファ・ベクトルおよび／または他のパラメータもしくはメタデータ（例えば、バッファ・サイズ、バッファ・レート、バッファ充満度、および／または他のデータ）を、有効なモデルのパラメータおよび／またはメタデータによって置換することができる。それに加えておよび／またはその代わりに、上で説明したように、１つまたは複数の無効なバッファ・モデルを変更することができ、その結果、モデルを有効にすることができるようになる。モデルの変更は、モデルを所与の仕様（例えば、ｈｉｇｈ  ｄｅｆｉｎｉｔｉｏｎ  ＤＶＤ（ＨＤ−ＤＶＤ）、Ｂｌｕ−ｒａｙ  ｄｉｓｃ（ＢＤ）および／または他の仕様）内で維持するが、モデルを、当初に定義されたパラメータ（例えば、ストリームの多重化を考慮に入れるためのパラメータなど、ユーザ指定パラメータ）から変更する。モデルの変更は、いくつかの例で、変更されたバッファ・モデルを満足しながら、実行される再エンコードの個数を減らすことができる。
【０１０７】
いくつかの実施形態は、さらに、事後分析の実行およびより有効なモデルの提供を可能にするダミー・バッファ・モデルまたはプレース・ホルダ・バッファ・モデルを可能にする。モデルは、ベース・エンコードおよび／またはセグメント再エンコード中に実行された解析に基づいて、後で構築するか指定することができる。これは、プレース・ホルダ・モデルを置換できる、実質的に任意の個数のモデルを定義することを可能にする。
【０１０８】
さらに、いくつかの実施形態は、セグメント再エンコードの前に、アンダーフローを超えるマージンおよび／またはオーバーフローを下回るマージンを効果的に利用することによって利用できる追加のバッファ可用性の量を識別する前処理を実行する。図１０をもう一度参照すると、バッファが、ビットの充填および解放を通ってサイクルするときに、フィル・レベル（fill level）は、下側レベルまたは０レベル１０４０に接近する。フィル・レベルと最小バッファ・レベルとの間の最小距離１０４２を、いくつかの実装で、バッファ可用性のマージンとして識別することができる。上で紹介したように、いくつかの実施形態は、バッファ可用性の量のシフトを提供し、バッファのアンダーフローおよび／またはオーバーフローを回避しながら高められたバッファ利用度を提供することを試みて、おおむね可用性のマージンだけグラフを下に効果的にシフトする。最小マージンを利用する際に、アンダーフローが、通常は回避される。いくつかの実施形態は、さらなるシミュレーションまたはその後のシミュレーションを実行して、シフトがアンダーフローまたはオーバーフローを引き起こすかどうかを決定する。
【０１０９】
使用可能バッファ・マージンの類似する使用を、可変ビットレート（ＶＢＲ）エンコーディングと共に使用することができる。図１１を参照すると、やはり、フィル・レベルと下側レベルまたは０レベルとの間の最小マージンを識別することができる。しかし、ＶＢＲの場合に、シフトの後に、フィル・レベルが最大フィル１１２６に達し、ビットの受け入れを停止すると、このシフトは、効果的に除去され、バッファ・モデルは、シフトがないかのように継続する。したがって、いくつかの実施形態は、ストリームに沿った複数のシフトを可能にし、最小マージンが、最大フィルレベル（例えば、フラット領域１１２６）の間で決定される。使用可能バッファ・シフトの量は、いくつかの実施形態で、シミュレーションプロセス９２４を介して決定される。いくつかの実装で、使用可能シフトについての決定は、バッファをより十分に利用するために、セグメント再エンコードを実行する前に実装される。シミュレーションは、複数のモデルが識別されるときに、バッファ・モデルのそれぞれについて実行することができる。
【０１１０】
上で紹介したように、いくつかの実施形態は、ユーザがエンコーディングおよび／または再エンコードを制御することを可能にし、エンコーディング・プロセスに対するより高い制御およびエンコードされた最終製品のより高い満足度をユーザに与える。例えば、このシステムは、モデルに失敗する１つまたは複数のセグメントを識別し、新しいＩフレームを生成すべき場所をそれらからユーザに選択するために複数の可能なＰピクチャおよび／またはＢピクチャを識別し、かつ／または他のそのようなフィードバックおよび情報を識別することができる。次に、ユーザは、どのフレームを変換しなければならないか、どのセグメントを再エンコードしなければならないかを選択し、あるいは他の機能を実行することができる。
【０１１１】
図１２に、ユーザがコンテンツをエンコードし、エンコードされたコンテンツを再検討し、かつ／または１つもしくは複数のセグメントの再エンコーディングを実装し、制御することを容易にし、かつ／または可能にする、いくつかの実施形態によるグラフィカル・ユーザ・インターフェース１２２０を示す。このユーザ・インターフェースは、コンピュータまたは他の関連するデバイスを介して生成することができ、いくつかの実施形態では、エンコーディング・システム１２４は、ユーザ・インターフェース１２２０をも生成し、表示するコンピュータを介して実装される。ユーザ・インターフェース１２２０は、セッティング・ウィンドウ１２２２、ソース・コード・コントロール・ウィンドウ１２２４、再生またはムービー・コントロール・ウィンドウ１２２６、プレビュー・ウィンドウ１２３０、タイムライン・ウィンドウ１２３２、およびユーザ・インターフェース・ツールバー１２３４を含む。いくつかの実装で、タイムライン・ウィンドウ１２３２は、評価されるコンテンツがベース・エンコーディングまたは初期エンコーディングを介してエンコードされ終わるまで、ユーザ・インターフェース１２２０内に示されない。タイムライン・ウィンドウは、さらに、下でさらに説明するように、強調表示され、選択され、再エンコードすべきものとして識別され、かつ／または再エンコードされた１つまたは複数のセグメント１２５０、１２５２、１２５４、１２５４を識別することができる。
【０１１２】
図１３に、ソース・コード・コントロール・ウィンドウ１２２４の単純化されたグラフィカル表現を示す。ソース・コード・コントロール・ウィンドウは、ユーザが、エンコードすべきコンテンツのソースを定義し、アクセスすることを可能にし、キーボード、マウス、スタイラス、リモート・コントロールもしくは他のポインティング・デバイス、および／または他のそのような方法を使用してアクセスでき、選択を行うことができる。さらに、ソース・コントロール・ウィンドウは、再生１３２２、停止１３２４、巻き戻し１３２６、早送り１３２８、ループ再生１３３０、可変速再生１３３２、前および／または後のエントリ・ポイント呼び戻し１３３４、および／または他のそのようなボタンなどの複数のオプション、キーおよび／またはボタン；シャトル・コントロール・バー１３３６；可変速コントロール・ドラッグ・バー１３４０；モニタ・コントロール１３４２；ロケーションＡインジケータ１３４４；ロケーションＢインジケータ１３４６；タイム・コード・ディスプレイ１３５０；フレーム・ドロップ１３５２、シンク・モード１３５４、および他のそのようなインジケータなどのインジケータ；および／または他のオプション、機能（features）、および／またはボタンを含む。ソース・コントロール・ウィンドウを使用することによって、ユーザは、部分的に、エンコードすべき素材（material ）のスタート・ポイントおよびエンド・ポイントを見つけることができる。
【０１１３】
シャトル・コントロール１３３６は、近くの位置に前後に往復する。左（例えば、後方を表す）または右（例えば、前方を表す）にシャトル・コントロールが大きくドラッグされるほど、位置がより速く変化し、したがって、解放されたときに中央などの、事前定義の位置に戻るように効果的にバイアスを与えることができる。ナッジボタン（nudge buttons：微調整ボタン）１３３４は、１回にコンテンツの１エントリ・ポイント毎のナビゲーションを可能にする。「ロケートＡ」１３４４は、ソース素材（source material）の１つのタイムコード位置を格納し、リコールし、「ロケートＢ」１３４８は、ソース素材の１つのタイムコード位置を格納し、リコールする。タイム・コード・ディスプレイ１３４８は、ソース素材の現在のタイムコード位置を示す。シンク・ステータス１３５４は、シンク・モードがイネーブルされ、ムービー・コントロール・ウィンドウ１２２６がソース・コントロール・ウィンドウ１２２４からの再生と同期したままになることが可能にされているかどうかを示す。フレーム・ドロップ１３５２は、ソース再生中にコマ落ちが発生するときを示す。モニタ・コントロール１３４２は、どのトランスポートがアクティブ・トランスポートであるか（ソース・コントロール・ウィンドウ１２２４またはムービー・コントロール・ウィンドウ１２２６）をトグルする。
【０１１４】
図１４に、ムービー・コントロール・ウィンドウ１２２６の単純化されたグラフィカル表現を示す。ムービー・コントロール・ウィンドウは、ユーザがエンコードされたコンテンツをプレビューすることを可能にし、キーボード、マウス、スタイラス、リモート・コントロールもしくは他のポインティング・デバイス、および／または他のそのような方法を使用してアクセスでき、選択を行うことができる。さらに、ムービー・コントロール・ウィンドウは、複数のボタン、インジケータ、コントロール・バー、タイム・ディスプレイ、および類似物を含み、いくつかの実装で、これらのボタン、インジケータ、および類似物は、ソース・コントロール・ウィンドウ１２２４のボタン、インジケータ、および類似物に類似する。
【０１１５】
図１５に、いくつかの実施形態によるタイムライン・ウィンドウ１２３２の単純化されたグラフィカル表現を示す。タイムライン・ウィンドウは、ツール・バー１５２２、ビットレート・トラック１５２４、エントリ・ポイント・トラック１５２６、ピクチャ構造トラック１５３０、信号対雑音比（ＰＳＮＲ）トラックなどの品質トラック１５３２、ステータス・バー１５３４、タイム・マーカー１５３６、１つまたは複数のスクロール・バー１５４０、および他の関連するフィールドまたは領域を含む。タイム・ライン・ツール・バー１５２２は、少なくとも部分的に、ユーザがコンテンツをナビゲートし、セグメントをマークすることを可能にし、ステータス・バー１５３４は、セッションに関する情報を表示する。通常、ビットレート・トラック１５２４、エントリ・ポイント・トラック１５２６、ピクチャ構造トラック１５３０、および品質トラック１５３２は、各トラック内のエントリが、他のトラックのうちの１つまたは複数内のエントリに対応するように、協力し、かつ／または調整される。例えば、いくつかの実施形態は、エントリ・ポイント・トラック１５２６、ピクチャ構造トラック１５３０、および品質トラック１５３２がビットレート・トラック１５２４と対応するように、トラックを構成する。
【０１１６】
タイムライン・ウィンドウ１２３２は、コンテンツ・ビットレート１５２４、エントリ・ポイント１５２６、ピクチャ構造１５３０、および品質の尺度１５３２を表示するトラックを含む。個々のトラックは、それ自体の高さにセットすることができ、隠すことができる。いくつかの実施形態で、タイムラインおよび／またはトラック・データをズームして、より高い分解度を提供することができる。ビットレート・トラック１５２４は、ビデオ・エンコードされたコンテンツのビットレートのプロットを表示する。いくつかの例で、コンテンツがＣＢＲを用いてエンコードされているときには、このグラフは、一般に、水平線または直線であるが、ＶＢＲを用いてエンコードされているときには、このグラフは、ビットレートが例えば各ＧＯＰと共に変化するときに、経時的に変化する。プロットの最小値および最大値は、エンコーダ、ターゲット・アプリケーション（例えば、ＨＤ−ＤＶＤ、Ｂｌｕ−ｒａｙ、または類似物）、および／または他のそのような要因に依存して異なる。
【０１１７】
エントリ・ポイント・トラック１５２６は、コンテンツ内のエントリ・ポイントを垂直線として表示する。複数のタイプのエントリ・ポイントを定義することができ、いくつかの実施形態で、少なくとも２タイプのエントリ・ポイントすなわち、「ノーマル」（Ｎ）１５５０および「カスタム」（Ｃ）１５５２を表示することができ、ここで、カスタム・ポイントは、チャプタ・ポイントおよび／または再エンコードを開始するか終了しなければならない他のポイントなど、ユーザ定義のポイントとすることができる。多くの例で、カスタム・エントリ・ポイント１５５２は、エンコードの前にリスト内で指定される。いくつかの実施形態で、タイムライン１２３２がズーム・インされるときに、カスタム・エントリ・ポイント１５５２の数も表示される。エントリ・ポイントは、再生ヘッドを洗浄するとき、セグメント再エンコードのイン・ポイントおよびアウト・ポイント、チャプタ・ポイントの位置をセットするとき（例えば、ＨＤ−ＤＶＤコンテンツ、Ｂｌｕ−ｒａｙコンテンツ、および／または他の関連するコンテンツをオーサリングするとき）に有効な位置を定義する。さらに、エントリ・ポイントは、いくつかの例で、例えばＭＰＥＧについてＩフレームがある場所をコンテンツ・ストリームに沿って示す、ＧＯＰヘッダポイント、チャプタ・ポイントを定義できるポイント、および／または例えば再エンコードのスタート・ポイントを定義できるものなどの他のポイントを示す。ノーマル識別子１５５０は、いくつかの例で、シーン変化が発生する場所を識別することができる。いくつかの実施形態で、再エンコーディングは、フレーム構造を再構成し、新しいＩフレームの生成および／またはＢフレームもしくはＰフレームのＩフレームへの変換を可能にする。エントリ・ポイント・トラック１５２６は、いくつかの実装で、さらに、これらの新しいおよび／または変換されたＩフレームを識別することができる。
【０１１８】
ピクチャ構造トラック１５３０は、いくつかの実装で、例えば変化する線高さによって区別される垂直線を用いて、各ＧＯＰ内の個々のピクチャ・タイプを表示することができる（例えば、Ｉフレームは高い線、Ｐフレームは中間の線、Ｂフレームは短い線）。
【０１１９】
タイムライン１２３２は、さらに、いくつかの実装でピーク信号対雑音比データを示すＰＳＮＲトラックである、品質測定値トラック１５３２を示すことができる。いくつかの実施形態で、ＰＳＮＲトラックは、輝度（Ｙ）に基づくＰＳＮＲ−Ｙトラックである。ＰＳＮＲは、エンコードの品質を決定するのに使用することができ、いくつかの実施形態で、エンコードされたイメージにまたがる輝度強度をソース・コンテンツ内の輝度強度と比較することによって、または他の信号対雑音比計算によって決定することができる。通常、ＰＳＮＲトラック１５３２は、エンコードされたコンテンツの各ＧＯＰおよび／またはフレームのＰＳＮＲを示す。ＰＳＮＲ値は、要求されるエンコーディング結果および／またはピクチャ品質を満足できない１つまたは複数のＧＯＰおよび／またはフレームならびに再エンコードすべきセグメントを識別する際にユーザを助けることができる。
【０１２０】
図１６に、タイム・ライン・ツール・バー１５２２の拡大されたビューの単純化されたグラフィカル表現を示す。このツール・バーは、複数の異なるツールまたは特徴を含み、このツールまたは特徴には、複数のオプション、ボタン、トグル・スイッチ、テキスト・フィールドおよび／または数値フィールド、インジケータ、パラメータ情報、ならびに／あるいは実質的にすべての他の関連するツールを含めることができる。いくつかの実施形態で、タイム・ライン・ツール・バー１５２２は、ズーム・イン・ツール１６２２およびズーム・アウト・ツール１６２４、「イン・ポイント」セッティング・ツール１６２６および「アウト・ポイント」セッティング・ツール１６２８、セグメント・マーキング・オプション１６３０、セグメント・クリア・オプション１６３２、前セグメント・オプション１６３４、次セグメント・オプション１６３６、バッチ・エンコードにセッションを追加オプション１６３８、タイム・ライン・ディスプレイ・オプション・ダイアログボックスを開くツール１６４０、ならびに／あるいは他の関連するオプションおよびツールを含む。タイム・ライン・ツールバー１５２２は、再生ヘッド位置フィールド１６４４、再生ヘッド・ビットレート・フィールド１６４６、再生ヘッドＰＳＮＲフィールド１６４８、イン・ポイント位置フィールド１６５０、アウト・ポイント位置フィールド１６５２、セグメント持続時間フィールド１６５４、セグメント・ビットレート・フィールド１６５６、セグメントＰＳＮＲフィールド１６６０、および／または他の関連するフィールドをも含む。
【０１２１】
図１７に、ステータス・バー１５３４の拡大されたビューの単純化されたグラフィカル表現を示す。ステータス・バーは、追加情報および統計をユーザに与える複数のフィールドを含む。いくつかの実施形態で、ステータス・バー１５３４は、ビット・バジェット・フィールド１７２２、ビット・バジェット・メータおよびフィールド１７２４、総持続時間フィールド１７２６、平均ビットレート・フィールド１７３０、平均ＰＳＮＲフィールド１７３２、ビデオ標準規格フィールド１７３４、最終保存フィールド１７３６、および／または他のそのようなフィールドを含む。
【０１２２】
ビット・バジェット・フィールド１７２２は、例えばコンテンツ内のビデオ素材の、ターゲット容量を提供し、エンコードされたコンテンツおよび再エンコードすべき他のコンテンツまたは素材を含むことができる。ユーザは、値をフィールド１７２２に直接に入力することができる。それに加えてまたはその代わりに、このフィールドに、いくつかの実施形態でユーザ・インターフェース・ツール・バー１２３４を介してアクセスできるデフォルト・ヘッドルーム・オプションで指定された定義されたヘッドルームとエンコードされたコンテンツのサイズとの合計と等しいデフォルト値に基づいて自動的に書き込むことができる。例えば、エンコードされたコンテンツが１３０ＭＢであり、デフォルト・ヘッドルーム・オプションに２０％がセットされているときに、デフォルト・ビット・バジェットは、近似的に１５７ＭＢ（すなわち、１３０＊１．２）にセットされる。いくつかの実施形態で、ビット・バジェット・フィールド１７２２に直接に入力できる最大値は、ターゲット・アプリケーションによって決定される（例えば、ＨＤ  ＤＶＤ−Ｖｉｄｅｏの３００００ＭＢ、Ｂｌｕｅ−ｒａｙの５００００ＭＢ、およびターゲット・アプリケーションに基づく他のそのような最大値）。
【０１２３】
ビット・バジェット・メータ・フィールド１７２４は、セッションのまたはプロジェクトの残りスペースおよび使用済みスペースを表示する。いくつかの実装は、上で説明したものまたは他のそのような選択デバイスなどの選択デバイスを用いて選択しまたはクリックして、残りスペースと使用済みスペースとの間でトグルすることができるプルダウンまたはトグル・スイッチ１７４４を含む。セッションの容量は、ビット・バジェット・フィールド１７２２に表示される。使用済みスペースは、いくつかの実施形態で、エンコードされた素材のサイズに保留中のセグメント再エンコードを加算することによって計算される。いくつかの実施形態で、選択されたセグメントのビットレートが変更されるときに、ビット・バジェット・フィールド１７２２を調整して、再エンコードが実行された場合にどれほどの余分のデータが使用されかつ／または必要になるかをユーザに示すことができる。さらに、いくつかの実施形態は、再エンコードのビット・バジェットについて維持されなければならないヘッドルームの量をユーザが指定することを可能にするためにアクティブ化することのできるオプションメニューを提供する。いくつかの実施形態で、ビット・バジェットは、ベース・バジェットを超過するパーセンテージと定義される。
【０１２４】
総持続時間フィールド１７２６は、時間単位、分単位、秒単位、およびフレーム単位のコンテンツの全持続時間を表示する。平均ビットレート・フィールド１７３０は、コンテンツ・ストリームの平均ビットレートを表示し、いくつかの実施形態で、１つまたは複数のセグメントが再エンコードを保留されている（例えば、再エンコーディングについて選択されているが、まだ再エンコードされていない）ときに、平均ビットレートの決定は、保留されているセグメントの初期エンコードからのビットレート値に基づく（例えば、選択された保留中の再エンコードされるビットレートではなく）。
【０１２５】
平均ＰＳＮＲフィールド１７３２は、コンテンツ全体の平均ＰＳＮＲ値を表示する。いくつかの実施形態で、ＰＳＮＲは、輝度ＰＳＮＲであり、平均ＰＳＮＲは、コンテンツ・ストリーム全体の平均輝度ＰＳＮＲ値を表示するが、他の信号対雑音比値を使用し、かつ／またはコンテンツの諸部分を定義することができる（例えば、１セグメントまたは他のそのような部分の平均ＰＳＮＲ）。平均ビットレート・フィールド１７３０および平均ＰＳＮＲフィールド１７３２で識別される値は、選択されたまたは強調表示されたセグメントの現在の平均値に基づくものとすることができ、これは、通常、選択されたセグメントのビットレートが変更された時をリストするセグメント・タブ・ウィンドウ内で指定される値とは異なる。ビデオ標準規格フィールド１７３４は、コンテンツ・ストリームの垂直分解度、スキャン・モード、およびフレームレートを表示し、最終保存フィールド１７３６は、セッションが最後に保存されたときの日時を表示する。
【０１２６】
図１２のユーザ・インターフェース１２２０のプレビュー・ウィンドウ１２３０は、コンテンツ・イメージを表示し、ソース・コンテンツまたはエンコードされたコンテンツとすることができる。再エンコードが実行されたならば、ユーザは、再エンコードされたセグメントの前のヘッド・エンド・ポイントを選択し（例えば、１つのポイントまたは類似物を使用して）、再生をアクティブ化することができ、その結果、再エンコードされたセグメントが、プレビュー・ウィンドウ１２３０内で再生されるようになる。いくつかの実施形態で、上で説明し、下でさらに説明するように、再エンコードされたセグメントのデータは、ベース・エンコードされたファイルとは別々のファイルに格納され、再エンコードされたセグメントの再生の際には、その別々のファイルが、再生のためにアクセスされる。さらに、ユーザは、フル・スクリーンまたは実質的に任意の所望のサイズになるようにプレビュー・ウィンドウをアクティブ化することができる。いくつかの実装で、プレビュー・ウィンドウを別々のディスプレイまたはモニタに表示することができ、ユーザがユーザ・インターフェース１２２０の他のウィンドウを利用することを可能にしながら、より大きいまたはフル・スクリーンのビューが可能になる。
【０１２７】
図１８〜２１に、セッティング・ウィンドウ１２２２内の様々なオプションを示す。より具体的には、セッティング・ウィンドウは、セッティング・ウィンドウを介して使用可能な様々なオプションにユーザがアクセスすることを可能にする１つまたは複数のタブあるいは他の選択ボタン１８２２を含む。いくつかの実施形態で、タブ１８２２は、入力タブ１８２４、ビデオ・タブ１８２６、セグメント・タブ１８２８、ｅｘｐｒｅｓｓまたはｅｘｐｒｅｓｓＱＣタブ１８３０、および／または他のそのようなタブを含むことができる。
【０１２８】
入力タブは、エンコーディングの前に選択されると、ユーザがセッティングおよびパラメータにアクセスし、調整し、コンテンツのベース・エンコードの後のパラメータセッティングの一部を定義する統計を見ることを可能にする入力セッティング・ウィンドウにアクセスする。ビデオ・ソースは、単一のビデオ・ファイル、イメージ・シーケンス・フォルダ、および／または他の関連するソースからなるものとすることができる。ソース素材に関する情報は、セッティング要約タブに表示される。エンコードの前に、入力タブ・セッティング・ウィンドウは、入力ファイル・セッティング・ダイアログ・ボックスを開くセッティング編集ボタンを有し、このダイアログ・ボックスで、ユーザは、ビデオ・ソース素材のセッティングを構成することができる。いくつかの実施形態で、入力セッティング・ウィンドウは、ビデオ・ソース・タイプのセッティング（例えば、ファイルのうちの１つ、複数のビデオ・フレーム・ファイル（イメージ・シーケンス）、および・／または他のソース・タイプをソース・タイプにセットすること）、媒体の追加（パラメータ・フィールドは、媒体ファイルから読み取られた値を用いて更新でき、媒体から決定されない任意のパラメータの値を指定することができ、ピクセル・フォーマットは、ＲＧＢまたはＹＵＶビデオサンプルのデータ構造を指定する）、ソース・スタート・タイム・コードの指定、追加の媒体ファイルを追加するための前のステップの繰り返し、１つまたは複数の媒体ファイルの取り出し、異なるソースのブラウズ、および／または他のセッティングまたはパラメータを可能にする。
【０１２９】
図１８に、ベース・エンコードの後の、入力タブ・セッティング・ウィンドウ１８２０が表示された、セッティング・ウィンドウ１２２２を示す。入力タブ・ウィンドウは、ベース・エンコード中に実際に使用されたパラメータの要約を表示する。例えば、入力タブ・ウィンドウは、ソース・ファイル１８４０、ソース・ファイルのパラメータ、および／または分解度、スキャン・モード、タイム・コーダ、ピクセル・フォーマット、および実質的にすべての他の関連するパラメータなど、エンコーディング中に使用されたパラメータを示すことができる。
【０１３０】
ビデオ・タブ１８２６は、ユーザがビデオ・エンコーディング・パラメータのセッティングにアクセスすることを可能にするビデオ・タブ・セッティング・ウィンドウ１９２０をアクティブ化する。エンコーディングの前に、ビデオ・タブ・セッティング・ウィンドウは、ビデオ・プリセットおよびデフォルト・セッティングをリコールするセッティング・ポップアップ・メニューを含むことができる。セッティング・ポップアップ・メニューは、ビデオ・エンコーディング・パラメータを構成し、保存することができるビデオ・セッティング・ダイアログ・ボックスを開く編集コマンドをも含むことができる。
【０１３１】
図１９に、ベース・エンコードの後の、ビデオ・タブ・セッティング・ウィンドウ１９２０が表示された、セッティング・ウィンドウ１２２２を示す。エンコードの後に、ビデオ・タブ・ウィンドウは、コーデック、エンコーダ、プロファイル、レベル、分解度、ピクチャ構造、フレームレート、ディスプレイ・アスペクト比、ターゲット・アプリケーション、ビットレート・パラメータ、制御モード、パスカウント、ターゲット・ビットレート、最大ビットレート、ピクチャ構造、シーン検出、ＩＤＲインターバル、最小ＩＤＲインターバル、Ｂフレーム、ダイナミックＢフレーム配置、ピラミッドＢフレーム構造使用、動き検索、基準フレーム数、サブピクセル精度、イントラ検索形状、インター検索形状、レート歪み最適化、アダマール変換、複数基準フレーム、サブ・ブロック、イントラ・フレーム、エントロップ・エンコーディング・モード、イン・ループ・デブロッキング・フィルタ・フラグ、Ｃｂ量子化オフセット、Ｃｒ量子化オフセット、アルファ・フィルタ・オフセット、ベータ・フィルタ・オフセット、他のエンコーディング方式（例えば、ＭＰＥＧ２、ＡＶＣ、ＶＣ１、および／または他のそのような方式）に関する他のパラメータ、および実質的にすべての他の関連するパラメータなど、エンコーディング中に利用されたパラメータを示す。
【０１３２】
図２０に、セグメント・タブ・セッティング・ウィンドウ２０２０が表示された、セッティング・ウィンドウ１２２２を示す。セグメント・タブ・セッティング・ウィンドウは、セッションを選択され、強調表示され、および／または再エンコードされたセグメントに関する情報を表示し、選択されたセグメントに関する１つまたは複数の再エンコードのビットレートをセッティングするコントロールを含むことができる。いくつかの実施形態で、選択されたセグメントは、スタート・ポイント２０２２およびエンド・ポイント２０２４（通常は、コンテンツのタイムラインに対する相対的な時刻としてリストされる）によって識別される。さらに、セグメント・タブ・セッティング・ウィンドウは、各セグメントの新しい再エンコードビットレート２０２６およびセグメントのステータス２０３０を指定することができる（例えば、「ｍａｒｋｅｄ（マーク済み）」は、強調表示されているが、ビットレートがまだセットされていないか変更されていないセグメントを識別し、「ｐｅｎｄｉｎｇ（保留中）」は、ビットレートを変更されたがまだ再エンコードされていない選択されたセグメントであり、「ｄｏｎｅ（終了）」は、変更されたビットレートに従って再エンコードされたセグメントおよび／または他のそのような識別子である）。セグメントは、列（column）ヘッド２０３２をクリックすることによってソートすることができ、列は、列区切り（column dividers）をドラッグすることによってサイズを変更することができる。
【０１３３】
いくつかの実施形態で、セグメント・タブ・セッティング・ウィンドウ２０２０は、ユーザがビットレート値フィールド２０４２にビットレート値を入力することを可能にするセグメント・ビットレート領域２０４０を含む。ビットレート値は、さらに、「絶対」セグメント、相対セグメント、および／または他のそのような定義として定義されたモード編集２０４４によって修飾することができる。いくつかの実装で、絶対セグメントを、ビットレート値フィールド２０４２で指定された絶対ビットレートで再エンコードすることができる。複数のセグメントを絶対ビットレートで編集するときに、新しいビットレートは、通常、セグメントのそれぞれについて実質的に同一である。相対セグメントは、相対ビットレートで再エンコードすることができ、ここで、既存のビットレートは、ビットレート値フィールド２０４２内で指定された値だけ増やされる。例えば、４．０Ｍｂｐｓ、４．５Ｍｂｐｓ、および５．１Ｍｂｐｓのビットレートを有する３つのセグメントが、＋１．５Ｍｂｐｓの相対ビットレートを用いて再エンコードされる場合に、新しいビットレートは、それぞれ５．５Ｍｂｐｓ、６．０Ｍｂｐｓ、および６．６Ｍｂｐｓになる。それに加えてまたはその代わりに、ユーザは、ビットレート・ドラッグ・バー２０４６を使用することができ、このバーがドラッグされると、ビットレート値フィールド２０４２内のビットレート値が変化する。いくつかの実装で、デコーダ・モデルに従って使用可能な最大値および最小値（通常は以前にセットされた）、ベース・エンコードの最大値および最小値、または他の関連する最大値および最小値を表す、最大ビットレート値および最小ビットレート値を表示することができる。再エンコードに関する調整されたビットレートが選択された（例えば、ビットレート・フィールド２０４２に直接に入力することによって、ビットレート・ドラッグ・バー２０４６を調整することによって、タイムライン１２３２上の平均ビットレート・インジケータを移動することによって、および／または他のそのような入力によって）ならば、再エンコードのビットレートは、ビットレート列２０２６に反映され、選択されたセグメントのステータスが、例えば保留中に変化する。いくつかの実施形態で、保留中のセグメントは、強調表示、異なる色、または類似物によってタイムライン・ウィンドウ１２３２内で識別されまたは区別され、いくつかの例で、タイムライン・ウィンドウに保留中ビットレートを示す。
【０１３４】
図２１に、ｅｘｐｒｅｓｓＱＣタブ・セッティング・ウィンドウ２１２０が表示された、セッティング・ウィンドウ１２２２を示す。ｅｘｐｒｅｓｓＱＣタブセッティングウ・ィンドウは、少なくともエンコードの後に使用可能であり、例えばＰＳＮＲ統計などの品質測定値に基づいて、再エンコードについてセグメントを選択するのに使用できるコントロールを提供する。いくつかの実施形態で、ｅｘｐｒｅｓｓＱＣタブ・セッティング・ウィンドウ２１２０は、検出モード・パラメータ２１２２およびセグメント長パラメータ２１２４を含む。検出モード・パラメータは、ＰＳＮＲ閾値オプション２１２８、閾値レベル・フィールド２１３０、および／または閾値レベル・ドラッグ・バー２１３２、ならびに／あるいはセグメント数オプション２１３４、セグメント数閾値フィールド２１３６、および／またはセグメント数ドラッグ・バー２１３８を含むことができる。
【０１３５】
セグメント長パラメータは、最小ＧＯＰ長フィールド２１４０およびＧＯＰ長ドラッグバー２１４２を含むことができる。セグメント・マーク・オプションまたはボタン２１４４が、さらに、コンテンツの検索または評価を開始し、コンテンツ全体あるいは検出モード・パラメータ２１２２および／またはセグメント長パラメータ２１２４によって指定される閾値および／またはレベルに関して定義された関係を有するコンテンツの選択された部分を通じて１つまたは複数のセグメントをマークするために含まれる。例えば、ある閾値未満のＰＳＮＲレベルを有するセグメントを識別するときに、これらのセグメントは、タイムライン・ウィンドウ１２３２上ですばやく突き止められ、強調表示される（例えば、選択された３つのセグメント１２５０、１２５２、および１２５４を示す図１２を参照されたい）。ユーザ・インターフェース１２２０は、さらに、ユーザが、ｅｘｐｒｅｓｓＱＣパラメータおよび／または閾値を使用して自動化されたプロセスを介してマークされた１つまたは複数のセグメントを選択解除することを可能にする。
【０１３６】
それに加えてまたはその代わりに、タイムライン１２３２を使用して、セグメントを選択し、かつ／または選択されたセグメントを定義することができる。いくつかの実施形態で、ユーザは、インジケータを位置決めするかドラッグして、エンコードされたコンテンツの１つまたは複数の区域を識別する。図１２、１５〜１６、および２０〜２１を参照すると、ユーザは、イン・ポイント・ツール１６２６およびアウト・ポイント・ツール１６２８を使用して、対象とするセグメント１２５４の境界を定めるイン・マーカーまたはイン識別子１２６０およびアウト識別子１２６２を位置決めすることによって、不満足な部分を含む１つまたは複数のセグメントを選択することができる。ユーザは、所望の位置に識別子をドラッグすることによって、識別子を配置することができる。いくつかの実施形態で、識別子の正確な配置は、ユーザによって選択された位置決めに対して相対的に、システムによって調整することができる。この調整は、イン識別子とアウト識別子との間で境界を示された選択された領域内のセグメントおよび／または下流のコンテンツの評価に基づくものとすることができる。再エンコードのスタート・ポイントおよびエンド・ポイントを定義するイン・ポイントおよびアウト・ポイントに対する調整を、下でさらに説明するが、この調整は、適当な再エンコードのスタート・ポイントおよびエンド・ポイントの決定、フレームの間の依存性、および他のそのような要因を含む多数の要因に基づいて調整することができる。
【０１３７】
いくつかの実装で、イン識別子１２６０およびアウト識別子１２６２によって境界を定められた現在選択されているセグメント（１つまたは複数）は、第１の強調表示（例えば、異なる色、クロスハッチ、点線、明るさ、および／または他のそのような区別する特性）を用いて強調表示される。他のセグメントは、代替強調表示を用いて識別することができ、例えば、既に再エンコードされたセグメント、例えば第４のセグメント１２５６を、第２の強調表示（例えば、第２の色）を用いて識別することができ、マークされたセグメントは、第３の強調表示（例えば、第３の色）を有することができ、かつ／または、保留中のセグメントは、第４の強調表示（例えば、第４の色）を有することができる。
【０１３８】
上で説明したように、ＧＯＰ１５６０毎の平均ビットレート値を示すビットレート・グラフ１５２４。タイム・ライン・ツール・バー１５２２は、再生ヘッドの位置（例えば、識別され、強調表示され、および／または選択されたＧＯＰに関する）での再生位置平均ビットレート１６４６の値をも示す。再生ヘッドが、例えばマウスなどのポインタ・デバイスを使用して再生ヘッドインジケータをドラッグすることによって、移動されるときに、再生位置平均ビットレート・フィールド１６４６内のビットレートの値が、変化する。
【０１３９】
いくつかの実施形態で、タイムラインは、さらに、選択されおよび／または強調表示されたセグメントに関するセグメント・ビットレート・バー１５７０を含む。セグメント・ビットレート・バーまたはインジケーション（表示；indication）は、当初に、選択されたセグメントの平均ビットレートを識別する。ユーザは、セグメント・ビットレート・バー１５７０を利用して、このバーを（例えばポインタ・デバイスを使用して）所望のビットレートにドラッグすることによって、選択されたセグメントについて所望の平均ビットレートを変更することができる。いくつかの実施形態は、さらに、セグメント・ビットレート・バー１５７０の位置に関連し、このバーが移動されるときに変化する選択されたセグメント・ビットレート１５７２を表示する。それに加えてまたはその代わりに、上で説明したように、ユーザは、セグメント・タブ・セッティング・ウィンドウ２０２０のセグメント・ビットレート領域２０４０を利用して、ビットレート・フィールド２０４２またはビットレート・ドラッグ・バー２０４６にビットレート値を入力することができる。
【０１４０】
ユーザ・インターフェース１２３２は、さらに、ユーザが１つまたは複数の保留中のおよび／またはマークされたセグメントの再エンコードをアクティブ化することを可能にする。いくつかの実施形態で、複数のセグメントを一時に選択することができる。セグメント再エンコードのアクティブ化の際に、進行状況ウィンドウを表示し、再エンコードの進行状況についてユーザに通知することができる。ユーザが、バッファのアンダーフローまたはオーバーフローを引き起こす限度を超えてビットレートを変更することを試みる場合には、エラーまたは警告インジケータを表示することができる。いくつかの場合に、この警告インジケータは、セグメント、変更されたビットレート、下流コンテンツ、および／またはバッファ・モデルの事前分析に基づいて、再エンコードが試みられる前に生成される。エラー・メッセージは、いくつかの場合に、再エンコードが試みられる際に生成し、その再エンコードがオーバーフローまたはアンダーフローをもたらし得ることを示すことができる。しかし、上で紹介したように、いくつかの実施形態は、さらに、選択されたセグメントから下流のおよび／または選択されたセグメントに隣接するセグメント内のビットレートおよび／またはバッファ・レベルを調整することによって潜在的なエラーを減らすためのビットレート変更に関する調整および／または補償を可能にする。
【０１４１】
いくつかの実装で、ユーザ・インターフェース１２２０は、ユーザが、選択されたセグメントのビットレートをモデルについてセットされた最大ビットレートと最小ビットレートとの間で調整することを可能にする。しかし、いくつかの実施形態は、選択されたセグメントの再エンコードに使用可能とすることができる選択されたセグメントから下流のコンテンツおよび／またはメタデータを分析することによって、最大および／または最小の使用可能なビットレートを計算する。これは、ユーザが実際に達成できるものと、隣接するおよび／または他のセグメントのさらなる再エンコードが追加ビットを解放するために必要であるかどうか、とに関するさらなるフィードバックをユーザに提供する。
【０１４２】
所定の時刻にマークできる、かつ／または選択できる、セグメントの個数に関して、事実上制限はない。したがって、ユーザは、複数のセグメントをマークし、その複数のセグメントに対して反復調整を行って、より高い優先順位を有するセグメントに対して要求されるビットレートを達成することができる。例えば、ユーザは、第１のセグメント１２５０ならびに第１のセグメントの下流の第２のセグメント１２５２および第３のセグメント１２５４を選択し、第２および第３のセグメントに対して調整を行って、第１のセグメントのためにビットを解放することができ、この解放は、第２および／または第３のセグメントのビットレートが調整されるときに第１セグメントの最大使用可能ビットレートの変化の表示によって反映することができる。
【０１４３】
ユーザが、所望する再エンコーディングを完了したならば、ユーザは、ユーザ・インターフェース１２２０を介してファイナライゼーションをアクティブ化することができる。ファイナライゼーションは、セグメント再エンコードをベース・エンコードとマージし、上で十分に説明し、下でさらに説明するように、バッファ・レベルについてストリームのデータを更新する。いくつかの実施形態で、ユーザ・インターフェース１２２０には、セッティング・ウィンドウ１２２２内に追加の編集済みセグメント・タブを含めることができ、このタブは、ターゲット・ビットレート、最小ビットレートもしくはフロア・ビットレート、クロミナンスの量子化オフセット、イン・ループ・デブロッキング・フィルタもしくは他のフィルタリング、バッファ・サイズ、バッファ充満度レベル、および／または他のそのような関連パラメータなどのパラメータをユーザが定義し、かつ／または変更することを可能にする。これらのパラメータは、適用される指定されたコーデックに依存して変更することができる。それに加えておよび／またはその代わりに、いくつかの実施形態は、ユーザが、例えばタイムライン１２３２を介して、特定のフレームを選択し、ＢフレームまたはＰフレームをＩフレームに昇格させるなど、ピクチャ・タイプにおける変更を定義する（例えば、ドロップ・ダウン・ウィンドウを使用すること、ピクチャ・フレーム・タイプ・インジケータにドラッグすること、および／または他のそのようなアクティブ化によって）を可能にする。フレーム・タイプのこの昇格は、例えば、シーン変化をマークする（例えば、シーン検出システムがシーン変化を正確に検出するのに失敗するとき）のに使用することができる。
【０１４４】
ズーム・イン・オプション１６２２およびズーム・アウト・オプション１６２４は、タイムライントラック上でのズーミング機能を提供する。図１５に示されたタイムライン１２３２は、符号１２４０によってラベルを付けられたタイムライン１２３２の部分に沿ってより高い精度を示す、タイムラインの部分１２４０のズーム・インされたビューである。このズーミングは、より正確なデータへのよりよいアクセスをさらに提供しながら、ユーザがコンテンツのより大きい部分またはすべてに対して相対的にタイムラインを見ることを可能にし、さらに、フレームおよび／またはセグメントの識別および／または選択に対するより正確な制御ならびにエンコードされたストリームおよびＰＳＮＲトラック１５３２のＰＳＮＲデータのより正確な評価をユーザに与える。
【０１４５】
図１２および１５を参照すると、部分１２４０のＧＯＰが、図１５でズーム・インされ、展開されている（例えば、このビューでは約１１個のＧＯＰ全体が示されている）。ビットレート・トラック１５２４は、各ＧＯＰにまたがる近似平均ビットレート１５６２をグラフィカルに示す。さらに、ユーザは、エントリ・ポイント・トラック１５２６に沿って示されたノーマル・エントリ・ポイント１５５０およびカスタム・エントリ・ポイント１５５２ならびにピクチャ構造トラック１５３０に沿って示されたピクチャ・タイプをより正確に識別することができる。上で説明したように、ユーザは、セグメントを選択し、セグメント・ビットレート・バー１５７０を使用して、再エンコードに所望されるビットレートをセットすることができる。
【０１４６】
エンコーディングおよび／またはセグメント再エンコーディングを実装する際に、いくつかの実施形態は、減らされた処理時間をもたらす加速されたエンコーディング・レートを可能にするエンコーディング・プロセスおよび／またはエンコーディング・システムを使用する。高品位コンテンツおよび／または大量のデータを含む他のコンテンツなど、一部のコンテンツに関して供給されるデータの量に関して、データレートは、極端になる可能性があり、通常は、結果の出力品質ニーズが、非常に高くなる可能性がある。したがって、一部のコンテンツのエンコーディングに関する処理要件が、非常に高くなる可能性がある。いくつかの本実施形態は、部分的にはエンコードされていないコンテンツを時間的に分解しまたはスライスし、並列エンコーディングをもたらし、効果的に処理をスケールアップして所望するエンコーディング・レートを達成することによって、ほぼリアルタイム・レートでのエンコーディングなど、相対的に高いデータレートで高品質エンコードされたコンテンツを提供する。並列エンコーディングは、不当な追加の処理時間なしで、コンテンツがエンコードされる速度を高め、かつ／または高められたもしくはより正確なエンコーディングを可能にする。
【０１４７】
図２２に、いくつかの実施形態によるエンコーディング・システム２２２０の単純化されたブロック図を示す。このエンコーディング・システムは、ダイサ（dicer）またはディバイダ２２２２、複数のダイサ・バッファ２２２４〜２２２６、複数のエンコーディング・プロセッサ・ユニット２２３０〜２２３２、スプライサまたはコンカテネータ（concatenator）２２３６、およびホスト・コントローラ２２３８を含む。動作中に、エンコードされていないコンテンツ２２４０、例えば高品位デジタル・コンテンツが、ダイサ２２２２に供給される。ダイサは、コンテンツをどのように分割するかを決定し、コンテンツを分割し、分割されたセグメント２２４２をダイサ・バッファ２２２４〜２２２６のうちの１つに転送する。ダイサは、ハードウェア、ソフトウェア、ファームウェア、および／または組合せとして実装することができ、いくつかの例で、ホスト・コンピュータなどのコンピュータから操作することができる。
【０１４８】
分割されたセグメントは、バッファを介してエンコーディング・プロセッサ・ユニット２２３０〜２２３２に配送されるフレームのシーケンスからなり、エンコーディング・プロセッサ・ユニットは、コンテンツをエンコードする。セグメントの分割されたグループを、ｆｉｒｅｗｉｒｅ接続、ハードウェア固有接続、イーサネット（登録商標）、１つまたは複数のバス（例えば、ｐｅｒｉｐｈｅｒａｌ  ｃｏｍｐｏｎｅｎｔ  ｉｎｔｅｒｃｏｎｎｅｃｔすなわちＰＣＩ）、および／または他の接続を介してバッファおよび／またはエンコーディング・プロセッサ・ユニットに転送することができる。エンコーディング処理ユニット２２３０〜２２３２は、ハードウェア、ソフトウェア、ファームウェア、および／またはその組合せを介して実装することができ、単一のプロセッサ、単一のコンピュータ、複数のプロセッサおよび／またはコンピュータ、個々のデジタル信号プロセッサ（ＤＳＰ）、ＤＳＰのアレイ、ならびに／あるいは他のデバイスまたはデバイスの組合せで実装することができる。いくつかの実施形態で、エンコーディング・プロセッサ・ユニットは、処理オーバーヘッドを減らし、処理速度を改善し、複雑度を減らす、ストリップ・ダウンされかつ／または単純化されたオペレーティング・システムを有する１つまたは複数のプロセッサおよび／またはコンピュータから操作される。
【０１４９】
その後、エンコードされた分割されたセグメント２２４４は、例えばイーサネット（登録商標）、ＰＣＩバス、または他の関連する通信リンク（１つまたは複数）を介して、スプライサ２２３６に供給される。スプライサは、コンテンツのエンコードされた分割されたセグメントを、一緒に、エンコードされたコンテンツ・ストリーム２２４６に戻して組み合わせる。コンテンツ２２４０が分割されるので、各エンコーダは、エンコードされていないコンテンツ２２４０が受け取られているレートより低いレートで動作することができる。その結果、エンコーダ２２３０〜２２３２は、エンコーディング・レートを加速しながら下げられたレートおよび／または質を高められたエンコーディングで正確なエンコーディングを提供することができ、いくつかの実装で、リアルタイム・レートに接近し、かつ／または達成する。いくつかの実施形態で、スプライサ２２３６は、ホスト・コンピュータ内で実装されるが、代替実施形態では、スプライサを、独立のハードウェア、１つまたは複数の別々のコンピュータ、プロセッサ、および／またはその組合せを介して実装することができる。エンコードされたセグメントは、例えば圧縮ストリーム連結技法を使用して、一緒に戻して縫い合わされ、連結されエンコードされたストリーム２２４６が、相対的に最小限の、好ましくは０の品質ロスを伴って、要求されるバッファ・モデルおよび／またはエンコーディング標準規格（例えば、ＡＶＣ、ＶＣ１、および他のそのような標準規格）に準拠するようになっている。
【０１５０】
ストリームを分割しまたは時間的に分離する際に、ダイサは、各セグメントがそのセグメントの外部の他のピクチャを参照せず、それらのピクチャによって参照されない、完全すなわち閉じている、エンコードされるべきセグメントを生成する。上で示したように、ダイサ分割ポイントまたはダイサ分離ポイントは、使用可能なバッファ・レベル、完全なピクチャ境界（例えば、フィルム・フレームからビデオ・フレームへの変換を考慮に入れる）、エントリ・ポイント・アラインメント、および／または他の関連する要因によって決定することができる。「イン」バッファ・レベルおよび「アウト」バッファ・レベルの予測アルゴリズムをさらに利用して、バッファ・モデルを満足することを試みて、セグメントの潜在的なターゲット・スライシング・ポイントを識別することができる。スプライスされたエンコードされたストリームは、通常、バッファ・モデルが達成されるかどうかを決定するためにさらに評価され、所望のモデルを満足するために、上で説明したように再エンコーディングが利用される。
【０１５１】
いくつかの実装で、ベースのまたは初期のエンコードされたデータ２２４６は、第１のファイルに格納される。１つまたは複数の追加ファイルを、再エンコードされたセグメントを格納するために維持することができる。この１つまたは複数のファイルあるいは追加ファイルを利用して、ビット・カウント調整、セグメント品質スムージング、チャプタ・ポイント挿入、および／または他のエンコーディング調整を記録することができる。初期のエンコードされたデータのうちで、再エンコードされ、チャプ・タポイントが挿入され、他の操作が生成された部分を識別するマッピングまたはリンクが、記録され、維持される。さらに、エンコードされたコンテンツが従わないおよび／または満足できないバッファ・モデルを、追加して記録することができる。セグメント・ベースの再エンコードおよび他の調整の完了の際に、最終的なエンコードされたコンテンツが、例えば上で図５のプロセス５２０を参照して説明したように書き込まれ、ここで、満足されないモデルが指定され（例えば、ヘッダ内で指定され）、再エンコードされたセグメントが、１つまたは複数の追加ファイルから取り出されて、再エンコードされるべきものとして識別された初期エンコードされたセグメントを置換する。
【０１５２】
エンコーダ・システム２２２０は、事前定義のレートで、例えばリアルタイムでのエンコードを試みる。というのは、圧縮されていないコンテンツ・データ（例えば、高品位ビデオ）のプロダクション・ワークフローが、テープ・マシンなどのソースから受け取られる可能性があり、リアルタイムで全体としてデータ・リンクを介してエンコーダ・システムに転送されつつあり、ここで、このシステムが、データフローを停止することができず、したがってコンテンツをそのフィード・レートで受け入れる場合があるからである。いくつかの代替実施形態は、追加バッファを介するなど、データをステージングし、より低いレートで動作する。しかし、このステージングは、通常のデータのサイズを与えられて、一部のコンテンツについて非実用的である可能性がある。他の実施形態は、リアルタイム・レートでのエンコードを試みる。システム２２２０は、いくつかの実施形態で、標準的なネットワークおよび／またはバスを使用して標準在庫コンポーネントを介して組み立てることができ、したがって、老朽化を回避し、かつ／またはより高速のプロセッサおよびコンポーネントが入手可能になるときにこれらを活用することを試みる。
【０１５３】
図２３に、ダイサ２２２２によって分割されたセグメント２２４２に分割されたコンテンツのストリーム２２４０の単純化されたブロック図表現を示す。コンテンツ２２４０は、ビデオ・コンテンツを含むときに、通常、ピクチャまたはフレーム２３２０のストリングとして受け取られ、ここで、各フレームは、通常、複数のピクセルを定義するデータを含む。エンコードされていないコンテンツが、ダイサ２２２２に供給される。
【０１５４】
図２４に、いくつかの実施形態によるダイサ２２２２の例の実装の単純化されたブロック図を示すが、ここで、ダイサ２２２２は、少なくとも部分的にハードウェア・アーキテクチャを介して実装される。ダイサは、コンテンツ・ストリーム・レシーバ２４２２、ダイシング・プロセッサ・ユニット２４２４、メモリ２４２６、オーディオ・エクストラクタ（audio extractor）２４３０、出力ポート２４３２、およびコントローラ２４３４を含む。コンテンツ・ストリーム・レシーバ２４２２は、いくつかの実施形態で、少なくとも部分的に、ストリーミングのエンコードされていないコンテンツ２２４０を受け取るシリアル・デジタル・インターフェース（ＳＤＩ）レシーバ（例えば、ＳＭＰＴＥ２９２Ｍ）を介して実装することができる。ダイシング・プロセッサ・ユニット２４２４は、コンテンツ（例えば、ビデオ）をダイシングし、ホスト（例えば、ＰＣＩバスを介して）、マイクロ・プロセッサ、および／または他のプロセッサもしくはプロセッサの組合せと通信するフィールド・プログラマブル・ゲート・アレイを含むことができる。メモリは、通常、１つまたは複数のバッファ・メモリ、好ましくは、セグメントを吸収する深いまたは相対的に大きいコモディティ・メモリ（commodity memory）（１つまたは複数）を含み、約５０フレーム以上のサイズ（例えば、エンコーディング・プロセッサ・ユニットごとに約２５０ＭＢ以上）など、期待されるエンコーディング方式による実用的なセグメントサイズを処理するのに十分に大きいが、受け取られると期待されるデータおよび／または使用されるエンコーディング方式に依存して、他のサイズを使用することができる。
【０１５５】
ポート２４３２は、実質的に任意のポートとすることができ、いくつかの実装では、分割されたセグメントをエンコーダ・プロセッサ・ユニット２２３０〜２２３２（図２２を参照されたい）に配送する複数のｆｉｒｅｗｉｒｅポート（例えば、１３９４ｂ−８００Ｍｂｐｓ  ｆｉｒｅｗｉｒｅポート）を含む。いくつかの実施形態で、コンテンツ・ストリームは、ビジュアルおよびオーディオ・コンテンツを含む。したがって、オーディオ・エクストラクタ２４３０は、レシーバからオーディオを抽出し、これを処理のためにホストおよび／または代替プロセッサに配送する。コントローラ２４３４は、マシン・コントロール・サービスを含む、ダイサ２２２２の全体的な制御をもたらす。
【０１５６】
図２５に、図２２のエンコーディング・システム２２２０の例のホスト・システム２２３８の単純化されたブロック図を示す。ホスト・システム２２３８は、中央コントローラ２５２２、トランスコーダ２５２４、コンテン・ツルータ２５２６、およびグラフィカル・ユーザ・インターフェース（ＧＵＩ）コントローラ２５３０を含むことができる。いくつかの実施形態で、ダイサ２２２２および／またはスプライサ２２３６が、ホスト２２３８の一部である。中央コントローラ２５２２は、エンコーディング・システム２２２０を管理し、少なくともダイシングおよびスプライシングを調整する。いくつかの実施形態で、中央コントローラ２５２２は、オペレーティング・システム２５３２を使用し、カメラ、ビデオ・テープ・レコーダ（ＶＴＲ）デッキ、および他のソースなどのソースからのコンテンツの獲得を制御するソフトウェアのライブラリなどのソフトウェアにアクセスし、実行する、１つまたは複数のマイクロ・プロセッサおよび／またはコンピュータを介して実装される。オペレーティング・システムは、例えば、Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ（登録商標）ＸＰ、Ｌｉｎｕｘ、あるいは、制御の全体的なレイヤを提供し、他のコンテンツ・ソースおよび／または編集システム（例えば、Ｍｉｃｒｏｓｏｆｔ社のＤｉｒｅｃｔＳｈｏｗ（商標）、ＱｕｉｃｋＴｉｍｅ（商標）、および他のそのようなシステム）などの他のシステムおよび／またはプログラムを有するホストと協力する他のオペレーティング・システムとすることができる。コントローラ２５２２は、さらに、エンコーディングを監視し、かつ／またはエンコーダ・プロセッサ・ユニット２２３０のバッファ・レベルのコンプライアンスを監視する追加モニタを含むことができる。ルータ２５２６は、ダイサ２２２２へのコンテンツ・ストリーム２２４０の配送を部分的に制御する。いくつかの実装で、ルータは、ファイル・ベースのコンテンツとしてコンテンツを配送する。ＧＵＩ  ２５３０は、それを介してユーザがシステム動作を操作し、制御し、変更し、パラメータ、閾値、および／または他の情報を供給し、かつ／あるいはレポート、統計、結果を入手し、かつ／あるいはエンコードされたコンテンツ（ストリーム全体および／または再エンコードされたコンテンツを含む）を見ることができるインターフェースを提供する。
【０１５７】
戻って図２２および２３を参照すると、動作中に、エンコーディング・システム２２２０は、コンテンツを受け取り、ダイサ２２２２を介してそのコンテンツを分割されたセグメントに分割し、分割されたセグメントをエンコードし、エンコードされた分割されたセグメントを、一緒に、エンコードされた出力ストリーム２２４６として戻してスプライスする。ダイサ２２２２は、各セグメントが複数のフレーム２３２０を含む、一連の分割されたセグメント２３３１〜２３３６に分割すべき圧縮されていない入力２２４０を受け取る。分割されたセグメントは、通常、連続するフレームのセットをグループ化することによって定義される。ダイサは、分割されたセグメントを分離し、これらのセグメントを異なるバッファ２２２４〜２２２６に配送する。例えば、第１の分割されたセグメント２３３１は、第１のエンコーダ・バッファ２２２４に配送され、このセグメントは、複数のフレームＳ１＋０からＳ１＋ｎまでを含む。第２の分割されたセグメント２３３２は、第２のバッファ２２２５に配送され、第３の分割されたセグメント２３３３は、第３のバッファ２２２６に配送される。このシステムが、３つのエンコーダだけを含む場合に、第４のセグメント２３３４は、通常、第１のバッファ２２２４に配送され、第５のセグメント２３３５は、第２のバッファ２２２５に配送され、以下同様である。しかし、いくつかの実装で、セグメントが、長さおよび／または内容において等しくなく、したがって、第１のバッファ２２２４にリサイクルする際に、第１のバッファが、それでも、１つまたは複数の前のセグメントが十分に大きいことに起因して、閾値を超えるコンテンツを含む場合があり、ダイサは、第１のバッファをスキップし、分割されたセグメントの配送について後続バッファを評価することに留意されたい。さらに、このシステムは、実質的に任意の個数のエンコーディング処理ユニットを含むことができる。
【０１５８】
分割されたセグメント２３３１〜２３３６は、実質的に任意の個数のピクチャまたはフレームを含むことができ、各分割されたセグメントは、必ずしも同一個数のフレームを含む必要はない。いくつかの実施形態は、分割されたセグメントの境界としてＩフレームを利用し、したがって、これらの分割されたセグメントは、Ｉフレームから始まる。
【０１５９】
エンコーディング・システム２２２０によってもたらされる利益の１つは、エンコーディング・プロセッサ・ユニット２２３０〜２２３２が、バッファ２２２４〜２２２６に接続され、データ２２４０が受け取られているレート（例えば、リアルタイム・レート）より低いレートでバッファからコンテンツ・データを引き出すことである。したがって、エンコーディング・プロセッサ・ユニット２２３０〜２２３２は、受け取られるデータレートより低いレートで動作することができる。例えば、データが、リアル・タイム・フルレートで入ってきつつあり、３つのエンコーダ・プロセッサ・ユニット２２３０〜２２３２がある場合に、各エンコーディング・プロセッサ・ユニットは、効果的に、受け取られるコンテンツのレートの約１／３で動作することができ、３つのエンコーディング・プロセッサ・ユニットの合計が、効果的に、受け取られるレートとほぼ等しいエンコーディング・レートを提供する。エンコーディング処理を並列化することによって、エンコーディング・システム２２２０は、動作帯域幅を増やす。いくつかの実施形態で、エンコーディング・プロセッサ・ユニット２２３０〜２２３２は、並列エンコーディングの合計が、受け取られる入力信号２２４０のレートを超えて、処理によって導入される遅延について部分的に補償するようにするためのレートで動作させられる。例えば、３つのエンコーディング・プロセッサ・ユニットを用いると、各エンコーディング・プロセッサ・ユニットを、入力コンテンツ２２４０のデータレートの約３５〜４０％で動作し、効果的に１０５〜１２０％エンコーディング・レートをもたらすように実装することができ、ここで、＋５〜２０％の追加は、ダイシング、バッファリング、スプライシング、および／または他の潜在的な処理オーバーヘッドに関連するオーバーヘッド処理時間について補償する。
【０１６０】
図２６に、いくつかの実施形態による、少なくともダイサ２２２２、エンコーディング制御、およびフィードバックの詳細をさらに示す、エンコーディング・システム２２２０の部分のブロック図を示す。このシステムは、イメージ複雑度アナライザ２６２２、制御ループ２６２４、オプションのエラー・フィードバック・プロセッサ２６２６、制御ループ・コンペンセータ２６３０、マッピング関数２６３２、ターゲット・バッファ・レベル・ディストリビュータ２６３４、遅延バッファ２６４０、ダイサ・ディストリビュータ２６４２、およびオプションの時間相関アナライザ２６４４を含む。
【０１６１】
イメージ複雑度アナライザ２６２２は、ビデオ・データなどのコンテンツ・ストリーム２２４０の複雑度の分析を実行する。複雑度決定に基づいて、複雑度アナライザは、コンテンツ・ストリームに対して相対的な所与のポイントで使用できるバッファ・レベルに関連する複雑度パラメータおよび／または複雑度ガイドを生成する。一般に、データが複雑であればあるほど、システムはより多くのバッファ・レベルを使用している傾向があり、通常、コンテンツ・ストリームが複雑であればあるほど、より多くのバッファス・ペースが必要になるようになっている。バッファ・レベル・ニーズに対する複雑度の間のこの関係は、通常は、線形の関係ではない。
【０１６２】
図２７に、複雑度アナライザ２６２２を介して生成できる、１にスケーリングされたコンテンツ・ストリームの複雑度プロファイルまたは複雑度マッピング２７２０の単純化されたグラフィカル表現を示す。図２６および２７を参照すると、複雑度アナライザ２６２２は、要求されるデコーダ・バッファ・レベル・モデルを満足することを試みてエンコーディング・プロセッサ・ユニット２２３０〜２２３２のエンコーディング・レベルを調整するのに利用される複雑度パラメータまたは複雑度スケールを生成する。一般に、複雑度が高まるにつれて、エンコーディング・レートが高まる。
【０１６３】
いくつかの実施形態で、複雑度アナライザ２６２２は、複雑度を予測するために、少なくとも部分的にＭＰＥＧ２エンコーダおよび／または他の単純化されたエンコーダを介して実装される。例えば、複雑度アナライザは、少なくとも部分的に、固定クワント・モード（fixed quant mode）または固定品質モードで動作するようにセットされたオフザセルフＭＰＥＧ２エンコーダを介して実装することができる。固定品質モードは、一般に、バッファ・レベルおよびデータ・ビットレートを顧慮せずに動作し、エンコードする。そうではなく、このエンコーダは、自由形式エンコーディングを実行する。固定クワント・エンコーダを介して処理されたピクチャまたはフレームのエンコードされたコンテンツは、任意のデータ・サイズを有するエンコードされたピクチャをもたらす。データ・サイズは、いくつかの実施形態で、そのフレームのエンコーディングの複雑度の反映として使用することができる。それでも、他の実施形態は、処理能力が使用可能であるときに、複雑度アナライザの一部としてＡＶＣエンコーダ、ＶＣ１エンコーダ、または他のエンコーダを使用することができる。平均ピクセル値からの標準偏差を使用されるダイナミック・レンジと比較するイントラ・フレーム分析、ピクチャからピクチャへのイントラ測定値を比較するインターフレーム分析、ピクチャからピクチャへのヒストグラムの比較、動きベクトルの相関を測定する動き分析、および／または他の分析など、他の複雑度分析も使用することができる。
【０１６４】
次に、このシステムは、複雑度パラメータ（いくつかの実施形態で、エンコードされたフレームのデータ・サイズである）を定義し、その複雑度パラメータを格納する。コンテンツ・ストリーム２２２４の一連の複雑度パラメータに基づいて、データ・セット（例えば、コンテンツ・ストリーム）の複雑度マッピング２７２０が、定義され、いくつかの実装では、ピクチャの粒度（granularity）またはＧＯＰの粒度（granularity）を有する。いくつかの例では、複雑度マッピングを合計して、このシステムを介して処理されつつある分割されたセグメントのマッピング全体を得る。
【０１６５】
エンコーディング・システムのいくつかの実装は、結果のエンコードされたコンテンツに基づくエラー・フィードバック２６６０を受け取るオプションのエラー・フィードバック・プロセッサ２６２６を含む。エラー・フィードバック・プロセッサは、エラーパラメータ２６６２内のエラーを処理する。いくつかの例で、複雑度アナライザおよび／またはマッピング関数の精度を示す定義されたエンコーディング・ターゲット・レベルを満足する際にエン・コーディング・プロセッサ・ユニットが有した困難に対する相対的な情報を返すフィードバックが、エンコーディング・プロセッサ・ユニットから受け取られる。
【０１６６】
次に、下で十分に説明するように、これらの困難パラメータを制御ループ２６３０によって利用して、マッピング関数を調整することができる。制御ループは、エンコーディング・プロセッサ・ユニットからのエラー応答に基づくフィードバックを介して適合されるバッファ・レベル予測をエンコーディング・プロセッサ・ユニットに供給する。それに加えておよび／またはその代わりに、制御ループ２６３０は、現在のフレームまたは分割されたセグメントの決定された複雑度と、その複雑度データが前のフレームまたは分割されたセグメントの前の複雑度データにどのように関係付けられるか（例えば、量子化レベルを評価することによって）とに基づいて、マッピング関数を調整することができる。
【０１６７】
制御ループ２６３０は、エンコーダ・プロセッサ・ユニットが要求されるレートでエンコーディングしているかどうかを決定することを試みて、複雑度プロファイルおよび／またはフィードバック・パラメータを比較する。システムがエンコーディング・レートとして指定するものとエンコーダ・プロセッサ・ユニットが実行しつつあるレートとの間の差すなわちデルタは、システム動作に影響する可能性があり、少なくともバッファ・レベルまで永続される。例えば、エンコーダ・プロセッサ・ユニットが、指定されたレート未満のレートで実行するときに、データは、データが供給するレートと等しいレートではバッファからプルされず、バッファ・レベルは、期待されるレベルより高まり、これが、後続フレームのエンコーディングのレベルに影響する可能性がある。同様に、エンコーダ・プロセッサ・ユニットが、期待値を越えるレートで動作する場合に、バッファ・レベルは、より低くなる。
【０１６８】
制御ループ比較に基づいて、制御ループ・コンペンセータ２６３０は、補償パラメータを定義する。この補償パラメータは、マッピング関数２６３２内で、データが処理される際の複雑度予測を改善するためにマッピングを変更するのに使用される。これは、処理中および／またはリアルタイムでのマッピング関数の調整を可能にする。というのは、マッピング関数が、効果的に、コンテンツ依存である近似であるからである。代替実施形態は、ストリーム全体の複雑度分析を開始することによって２パス・プロセスを使用する。分析の後に、複雑度が、エンコーディング・プロセッサ・ユニットを制御するのに利用される。２パス・プロセスを使用するこれらのシステムは、通常はルックアヘッド・バッファ２６４０を含まない。というのは、複雑度パラメータが、エンコーディング・プロセッサ・ユニットを調整するためのパスに基づいて既に既知であるからである。
【０１６９】
マッピング関数２６３２は、いくつかの実施形態で、マッピング関数として二次または三次の多項式を使用する。マッピングは、ターゲット・バッファ・レベル・ディストリビュータ２６３４に供給され、ターゲット・バッファ・レベル・ディストリビュータ２６３４は、バッファ・レベル・ターゲット・レート２６７０を生成し、バッファ・レベル・ターゲット・レート２６７０は、要求されるまたは期待されるバッファ・レベルを満足することを試みてエンコーディング・レートを調整し、かつ／または維持するためにエンコーディング・プロセッサ・ユニット２２３０〜２２３２に供給される。いくつかの実施形態で、テーブルまたはスプレッドシートを、マッピング機能の調整を実装するのに利用することができる。例えば、異なるレベルのデータレートに関する要求されるエンコーディング・バッファ・レベルを含む１つまたは複数のルックアップ・テーブルを利用することができる。それに加えておよび／またはその代わりに、これらのテーブルが、制御ループ・コンペンセータ２６３０によって分析された識別された複雑度、データレート、および／またはエラー・フィードバックに依存して使用できる多項式のセットを定義することができる。
【０１７０】
マッピング機能に対する調整は、エンコーディング・レートに対する連続的調整を可能にするために連続的に実装することができる。他の実装では、エンコーディング・レートおよび／または要求されるバッファ・レベルに対する調整が、分割されたセグメントの境界で実装される（境界は、通常、１つの分割されたセグメントの最後のフレームおよび／または後続の分割されたセグメントの先頭である）。エンコーディング・レートのこの調整は、続く分割されたセグメントのスタート・ポイントをカバーする特定のセグメントの追加ポイントについて要求されるターゲット・バッファ・レベルを達成することを試みる。エンコーディング・プロセッサ・ユニットは、その目標を満足することを試みてバッファ・レベル・ターゲット・レート２６７０を利用し、このシステムは、その目標を満足することの困難に関するフィードバック２６６０を受け取り続ける。
【０１７１】
上で説明したように、ダイサ２２２２は、コンテンツ・ストリーム２２４０を複数の分割されたセグメント２３３１〜２３３６に分割する。分割されたセグメントの間の境界の決定は、事前定義の周期的な個数のフレーム、事前定義の時間の長さ、コンテンツ２２４０の複雑度、および他のパラメータまたはパラメータの組合せに基づくものとすることができる。例えば、本発明のいくつかの単純化された実装では、分割されたセグメントの境界を、コンテンツを顧慮せずに時間の期間に盲目的に基づいて（例えば、１秒おきに）セットすることができる。次に、エンコーディング・プロセッサ・ユニットは、その１秒の時間境界と位置合せするために、分割されたセグメントをエンコードし、結果のエンコードされた分割されたセグメントを最後に一緒に継ぎ合わせることを可能にする。コンテンツを顧慮しない分割されたセグメントの境界の選択（例えば、時間またはフレーム数に周期的に基づく）は、しばしば、最適未満のコーディング品質をもたらす可能性がある。
【０１７２】
いくつかの実施形態は、その代わりに、複雑度マッピング２７２０を利用して、より正確なエンコーディングを提供し、かつ／またはエンコーディング処理を複数のエンコーディング・プロセッサ・ユニットにまたがってより均等に分散させる境界を分割されたセグメント２３３１〜２３３６の間で実装できるコンテンツ２２４０内の位置を識別する。複雑度分析を利用する際に、このシステムは、分割するセグメントの境界をコンテンツ内の適当なポイントに位置合せすることを試みる。例えば、ビデオ・コンテンツに関して、境界ポイントを、大きいアクションおよび／または経時的により少ない相関（フレーム間のより少ない参照）（例えば、シーン変化または高速ショット）を含むコンテンツ内のポイントで選択することができる。多くの例で、大きいアクションを有するかより少ない相関を有するコンテンツの部分にＩフレームを位置決めすることが望ましく、したがって、これは、分割されたセグメント２３３１〜２３３６の多くが各グループ化されたセグメントの先頭にＩフレームを有することを可能にする。
【０１７３】
さらに図２６および２７を参照すると、このシステムは、遅延バッファまたはルックアヘッド・バッファ２６４０を使用して、少なくとも部分的に、潜在的な分割されたセグメントの境界を識別する時間を与える。この遅延バッファは、例えば１秒の遅延を与えることができるが、実質的に任意の遅延を、システムおよび使用可能なシステム・リソースに依存して利用することができる。これは、ダイサ・ディストリビュータ２６４２によって、ダイシングされエンコードされるコンテンツ・ストリームを受け取る前に複雑度データ２７２０を受け取ることを可能にする。複雑度データをルックアヘッドすることによって、ダイサ・ディストリビュータ２６４２は、複雑度を評価し、大きいアクション、より少ない相関、および／または境界を選択できるストリームに沿った他の位置に相関する分割されたセグメントの境界を定義できる位置を識別する時間を有する。
【０１７４】
いくつかの実施形態は、さらに、分割されたセグメントの境界を識別するのを助ける時間相関アナライザ２６４４を含む。時間相関アナライザ２６４４は、シーン変化および／または大きいアクションを示す可能性があり、したがって複雑性が通常は高まる、あるピクチャから次のピクチャへのデータレートの大きいスパイクを検出することができる。それに加えておよび／またはその代わりに、いくつかの実施形態は、複雑度アナライザ２６２２のＭＰＥＧ２エンコーダを利用して、ＭＰＥＧ２エンコーダがシーン変化を検出したコンテンツ・ストリームに沿った位置を示す、ＭＰＥＧ２エンコーダから出力されたＧＯＰ構造の遷移を識別する。通常、ＭＰＥＧ２エンコーダは、相対的によいシーン検出を含み、そのようなシーン検出は、分割されたセグメントの境界を識別するのに使用することができる。
【０１７５】
さらに、時間相関アナライザ２６４４は、いくつかの実装で、さらに、テレシネ境界をも維持するフレーム境界を識別する。時間相関アナライザは、フレームレートの変化、例えば、元々はビデオ用に記録されたコンテンツ（例えば、米国テレビジョン用の約３０フレーム毎秒を含むテレビジョン・コンテンツ）対元々は映画フィルム用に記録されたコンテンツ（例えば、２４フレーム毎秒を含むコンテンツ）からの変化を識別するテレシネ検出アルゴリズムを含むことができる。当技術分野で既知の通り、テレビジョン・コンテンツへの映画フィルム・コンテンツの変換は、フィールドの繰り返しを使用する。したがって、時間相関アナライザのいくつかの実装は、テレシネ境界（telecine boundaries）を維持しながら（例えば、フィールドの分割を避けながら）分割されたセグメントの境界を定義することを試みる。いくつかの例で、時間相関アナライザは、別々のＭＰＥＧエンコーダを利用したり、あるいは一部のＭＰＥＧエンコーダがテレシネ境界を検出する際に、イメージ複雑度アナライザからなるＭＰＥＧエンコーダを利用したりする。
【０１７６】
図２２、２３、および２６を参照すると、決定された分割セグメントの境界に基づいて、ダイサ２６４２は、コンテンツを分割されたセグメント２３３１〜２３３６に分割する。次に、これらの分割されたセグメントは、エンコーディングのためにエンコーダ処理ユニット２２３０〜２２３２に転送される。グループ化されたセグメントがエンコードされたならば、エンコードされたコンテンツは、スプライサ２２３６に転送され、スプライサ２２３６は、エンコードされた分割されたセグメントを単一のストリーム２２４６に組み合わせる。
【０１７７】
エンコーディング・プロセッサ・ユニット２２３０〜２２３２は、いくつかの実施形態で、複数の異なる動作モードのうちの１つで動作させることができる。例えば、動作の１つのモードは、結果の品質にかかわりなく、定義されたエンコーディング方式を満足するようにエンコーディング・プロセッサ・ユニットをセットする。動作の代替のモードは、それ未満ではエンコーディング・プロセッサ・ユニットがエンコーディング方式パラメータを無視し、信号品質レベルを維持し、したがって１つまたは複数のデコーダ・バッファ・モデルを満足することに失敗する可能性がある限度または閾値品質レベルを定義する。次に、このシステムは、引き返し、エンコードされたコンテンツのうちで信号品質レベルを満足できないおよび／またはデコーダ・モデルを満足できない区域に対処するために、セグメント・ベースの再エンコードを使用し、ここで、この再エンコーディングは、品質を改善するためのエンコーディング・レートの調整、バッファ・レベル・パラメータを満足することを試みるトランスレーティング、および／または他のエンコーディング技法もしくは技法の組合せ、を含むことができる。
【０１７８】
いくつかの実施形態は、部分的に、セグメント・ベースの再エンコーディングを提供し、この再エンコーディングは、結果のエンコードされたコンテンツを改善し、エンコードされたコンテンツがコンテンツ全体の完全な再エンコードを実行することを必要とせずに、１つまたは複数の要求されるエンコーディング標準規格を満足することを可能にし、エンコーディング・レートをコンテンツ・ストリームの全体を通して変更できるので全体的により良い品質をもたらす。さらに、いくつかの実施形態は、ストリーム全体を完全に再エンコードすることに頼ることを必要とせずに、ベース・エンコードが既に完了した後にコンテンツ内にカスタムＧＯＰ配置を組み込む能力を提供する。さらに、このカスタムＧＯＰ配置は、エンコードされたコンテンツの小さい部分を再エンコードすることによって実施することができる。
【０１７９】
カスタムＧＯＰ配置を可能にすることは、ユーザに、より高い柔軟性および結果のエンコードされた製品に対するより多くの制御を与え、処理時間およびオーバーヘッドを大幅に削減することができる。例えば、ユーザは、ベース・エンコードを開始し、そのエンコードの後に、追加のチャプタ・ポイントを含めることが有益であることを悟る場合があり、あるいは、ユーザが、チャプタ・ポイントを含めるのを忘れた場合がある。いくつかの本実施形態は、コンテンツ・ストリーム全体の再エンコーディングの苦労および時間の出費なしで、ベース・エンコードの後のチャプタ・ポイントの挿入および他のコンテンツ編成を可能にする。さらに、本実施形態は、チャプタ・ポイントの挿入または他のコンテンツ編成を可能にし、かつ／またはセグメント・ベースの再エンコードを介するカスタムＧＯＰ配置を提供すると同時に、それでも、エンコードされたコンテンツが、要求されるデコーダ・バッファ・モデルを満足するように、エンコードされたコンテンツのレベルを維持する。
【０１８０】
デジタル・ビデオ・ディスク（ＤＶＤ）作成など、コンテンツをエンコードする際に、ユーザは、しばしば、例えばチャプタ・ポイントをそのポイントまたは位置に挿入できるように、特定の場所にＧＯＰを定義し、かつ／または位置決めすることを望む。いくつかの従来のシステムでは、ユーザは、エンコーダが指定された位置にＧＯＰを組み込めるようにするために、ベース・エンコードの前にチャプタ・ポイントの位置を指定しなければならなかった。従来のシステムでベース・エンコードの前に要求されるＧＯＰ構造および／またはチャプタ・ポイントを定義できないと、通常、ユーザが、引き返し、ＧＯＰおよび／またはチャプタ・ポイントを定義し、コンテンツ・スティーム全体の完全に新しいフル・エンコードを実装することが必要になる。
【０１８１】
しかし、いくつかの本実施形態は、ユーザが、セグメント・ベースの再エンコードを使用して、ＧＯＰ構造、チャプタ・ポイント、他の編成入力を使用し、かつ／または他の形でエンコードされたコンテンツを変更すると同時に、それでも、初期ベース・エンコードおよび／または後続エンコードの後にデコーダ標準規格を満足することを可能にする。したがって、いくつかの実施形態は、データ・セット全体を再エンコードする必要なしに、ベース・エンコードおよび／または後続エンコードの後に引き返して、新しいＧＯＰを組み込む機構を提供する。エンコードの後に、またはコンテンツが以前にエンコードされた状態で、ユーザは、チャプタ・ポイント、ＧＯＰ構造、および／または他のコンテンツ編成を位置決めすべき、エンコードされたストリームに沿った位置を識別することができ、このシステムは、要求されたＧＯＰ、チャプタ・ポイント、および／または他の編成を挿入するためにセグメント・ベースの再エンコードを実装することができる。したがって、いくつかの実施形態は、エンコーディングが行われた後の、ＧＯＰの作成、チャプタ・ポイントの挿入、および／または他の編成を可能にする。いくつかの例で、ＧＯＰ構造の変更および／またはチャプタ・ポイントの挿入は、ＢフレームまたはＰフレームのＩフレームへの変換または昇格を含み、効果的に、ＧＯＰ構造を切り詰めるか延長し、所望する位置の付近から始まる新しいＧＯＰを作成する。
【０１８２】
図２８に、チャプタ・ポイントの挿入および／またはＧＯＰ構造の変更のいくつかの実施形態によるプロセス２８２０の単純化された流れ図を示す。ステップ２８２２で、チャプタ挿入の位置またはＧＯＰ構造が改められなければならないポイントを識別する。いくつかの例で、チャプタ挿入ポイントは、ユーザによって定義される。ステップ２８２４で、このプロセスは、定義された挿入ポイントから離れた候補再エンコード・スタート・ポイントのピクチャまたはフレームを識別する。通常、所望するチャプタ・ポイントを組み込み、ＧＯＰ構造を再定義するために、再エンコード・スタート・ポイント・ピクチャは、チャプタ挿入ポイントがピクチャ参照によって妨げられなくなるように、セグメント再エンコードがピクチャの間の参照を調整できるようにするために、所望する位置からある距離で選択される。しばしば、このシステムは、挿入ポイントで新しいＧＯＰ構造を定義し、したがって、Ｉピクチャが所望する挿入ポイントに存在するようにピクチャ・タイプを再定義する。
【０１８３】
ステップ２８２６で、候補スタート・ポイント・ピクチャを評価する。通常、この評価は、図８のプロセス８２０で実行される評価に類似する。ステップ２８３０で、候補スタート・ポイント・ピクチャが有効なスタート・ポイント・ピクチャであるかどうかを決定する。候補スタート・ポイントが有効であるときには、このプロセスはステップ２８３６に継続する。その代わりに、候補スタート・ポイントが有効ではないときには、ステップ２８３２に入り、ここで、代替の候補スタート・ポイントを識別し、このプロセスは、評価のためにステップ２８２６に戻る。
【０１８４】
有効なスタート・ポイント・ピクチャが識別されるときに、このプロセスは、ステップ２８３６に進み、ここで、候補エンド・ポイント・ピクチャを識別する。やはり、通常、候補エンド・ポイントは、識別されたスタート・ポイント・ピクチャおよび候補エンド・ポイント・ピクチャが定義された挿入ポイントにまたがるように、定義された挿入ポイントからある距離で選択される。ステップ２８４０で、候補エンド・ポイント・ピクチャを評価する。この評価は、いくつかの実施形態で、図８のプロセス８２０で実行される評価に類似する。ステップ２８４２で、候補エンド・ポイント・ピクチャが有効なエンド・ポイント・ピクチャであるかどうかを決定する。候補エンド・ポイントが有効ではないときには、ステップ２８４４に入り、ここで、代替の候補エンド・ポイントを識別し、このプロセスは、ステップ２８４０に戻る。その代わりに、候補エンド・ポイントが有効であるときには、ステップ２８５０に入り、ここで、セグメント再エンコードを開始して、識別されたスタート・ポイントとエンド・ポイントとの間で定義されるセグメントを再エンコードする。ステップ２８５２で、所望するＧＯＰ再構成および／またはチャプタ・ポイントを、例えば、定義された挿入ポイント付近でピクチャ・タイプを変更することによって、セグメント再エンコード中に所望する位置の付近に挿入する。いくつかの実施形態で、プロセス２８２０は、複数の潜在的なスタート・ポイントおよびエンド・ポイントを識別することができ、ユーザが、その複数のスタート・ポイントおよびエンド・ポイントのうちのどれを使用しなければならないかを選択することを可能にすることができる。このプロセスは、チャプタ・ポイント挿入および／またはＧＯＰ調整のそれぞれについて繰り返される。
【０１８５】
さらに、いくつかの実施形態は、それでも要求されるデコーダ・バッファ・モデルを満足しながら、ポータブル・ストレージ媒体に格納されるコンテンツを制限するなど、定義されたビット・バジェット・パラメータを満足するためにコンテンツをエンコードすることを可能にする。ビット・バジェットを満足する際に、いくつかの実施形態は、初期エンコードまたはベース・エンコードを開始することができ、ここで、このエンコーディングは、実質的に任意の関連するエンコーディング方式に基づくものとすることができ、１つまたは複数のデコーダ・バッファ・モデルを満足することを試みて、固定ビットレート・エンコーディングまたは可変ビットレート・エンコーディングを含むことができる。初期エンコードの後に、後続のセグメント再エンコードを上で説明したように開始して、エラーおよび／または１つまたは複数の要求されるデコーダ・モデルを満足することの失敗に対処することができる。それに加えておよび／またはその代わりに、トータル・ビット・カウントを、エンコードされたコンテンツについて決定することができる。このトータル・ビット・カウントを、所望するまたは最大のビット・カウントまたはビット・バジェットと比較することができる。トータル・ビット・カウントが、ビット・バジェットを超える場合には、トータル・ビット・カウントが所望するビット・バジェットを満足すると同時に要求されるデコーダ・バッファ・モデルを満足するためのエンコードされたコンテンツの品質を維持するように、１つまたは複数のセグメントに利用されるビットを減らすためにコンテンツをより低いレベルで再エンコードできる１つまたは複数の区域またはセグメントを識別するために、エンコードされたコンテンツを評価することができる。
【０１８６】
いくつかの実施形態で、初期エンコードされたコンテンツのビット・カウントがおおむね第１の固定された量までに制限されるように、初期エンコーディングを実装することができる。例えば、エンコードされ、５Ｇバイトなどの制限された記憶容量を有するポータブル光学ストレージ媒体に格納されるビデオ・ストリームを、エンコードされたコンテンツが、エラーのマージンおよびヘッドルームを提供するための事前定義の量（例えば、１０から２０％）だけ最大値（例えば、５Ｇバイト）より少ないトータル・ビット・カウントを有するように、初期エンコーディングを介してエンコードすることができる。
【０１８７】
初期エンコーディングの後に、セグメント再エンコーディングの使用を介して、いくつかの実施形態は、次に、１つまたは複数の特定のセグメントのビットレートを高めることができ、したがって、品質を改善し、使用可能なオーバーヘッドの一部またはすべて（例えば、追加の１Ｇバイト）を使用する。さらに、いくつかの実施形態は、さらに、他のセグメントのレートを高めることを可能にするためにいくつかのセグメントのビットレートを減らすために、いくつかのセグメントのセグメント・ベースの再エンコーディングを可能にする。さらに、要求されるデコーダ・バッファ・モデルおよび／または標準規格を満足するエンコードされたコンテンツを達成するために、オーバーヘッド記憶領域を超えるものが必要となる場合に、本実施形態は、バッファ・モデルまたは標準規格に関していくらかのヘッドルームを有する区域を識別するためにコンテンツを評価し、トータル・ビット・カウントを減らすためおよび／または許容できるビットレートを超える区域からビットを解放するためにこれらの区域の再エンコードを実装し、１つまたは複数のバッファ・モデルを満足することに失敗するセクションを再エンコードするためにこの解放された容量を使用することができる。したがって、このシステムは、以前の方法と比較して、ビデオの総合品質を改善する。
【０１８８】
いくつかの実施形態は、さらに、コンテンツ・ストリームの長さにまたがる可変ビットレートを可能にする。多数の従来のエンコーディング・システムは、固定ビットレートを使用する。これらの固定ビットレート・エンコーダが、定義されたビット・カウント限度を超えなかったコンテンツをエンコードするためには、これらのシステムは、使用可能な時間またはメモリ・スペースの量を計算し、ビット・カウント限度内になるはずのビットレートを計算し、その固定ビットレートを用いてコンテンツ・ストリーム全体をエンコードした。固定ビットレートエンコーディングは、しばしば、コンテンツのいくつかの部分が他の部分と大きく異なる品質を有することをもたらす。
【０１８９】
さらに、いくつかの実施形態は、デコードから生じる信号品質がより小さい変動を有するように、エンコードされたコンテンツを適切な範囲に収める（moderate）試みにおいて、セグメント・ベースの再エンコーディングを利用することができる。多くの例で、ビデオ・コンテンツを見る人は、わずかに低い全体的品質を有するがより小さいまたはより少ない品質変動を有するコンテンツよりも、コンテンツが、品質において、相対的に重大なまたは大きい変化を有するときに、より低い品質の区域に、より容易に気付く。いくつかの実施形態は、品質の全体的な向上を達成しながら、可変ビットレートを適用し、努力する試みにおいて、エンコードされたコンテンツのうちで相対的に品質が高い区域（例えば、ＰＳＮＲ値を比較することによって）の品質を下げ、品質のより低いエンコードされたコンテンツのセクションに解放された容量を生かし、コンテンツ・ストリームに沿って品質レベルを平らにしし、かつ／またはコンテンツのあらかじめ定められた量内での信号品質の大きい変化を制限することができる。
【０１９０】
いくつかの実施形態は、トランスコーディングを通してコンテンツのストリーム全体のビットの再割振りをも提供する。エンコードされたコンテンツを、例えば信号品質（例えば、ＰＳＮＲ）に基づいて評価して、ストリームのうちで、トランスコーディングが品質に悪影響を及ぼさずにまたは最小限の影響でビットの解放を提供する部分を識別することができる。ストリームのうちでトランスコーディングされる部分は、動きベクトルが多様である部分、粗い量子化を有する区域、マクロブロック効果、および冗長性を有する区域の識別、ならびに他の類似する方法など、他の方法を介して識別することもできる。
【０１９１】
それに加えておよび／またはその代わりに、いくつかの実施形態は、いくつかの実装で、ＩフレームをＰフレームまたはＢフレームに変換することによってビットを解放する。この変換は、例えば定義されたＢフレームおよび／またはＰフレームに対するＩフレームの比率のゆえに、ある種の応用例、プロトコル、および／または標準規格に対して制限される可能性がある。ビット・カウントのさらなる削減を、いくつかの実施形態で、コンテンツの事前フィルタリングを介して達成することができる。いくつかの実装では、コンテンツが、中央値フィルタリング、空間フィルタリング、時間フィルタリング、ノイズ・フィルタリング、および／または他の関連するフィルタリングもしくは複数のフィルタリングの組合せなどであるがこれらに限定されない１つまたは複数のフィルタリング技法を使用してフィルタリングされる。フィルタリングは、それに加えておよび／またはその代わりに、セグメント・ベースの再エンコーディング中に適用することができ、これは、ユーザが、ストリーム全体にフィルタを適用することを回避し、その代わりに選択された１つまたは複数のセグメント（例えば、コンテンツのうちですばやいアクションまたはすばやいシーン変化を有する部分）にフィルタリングを適用することを可能にする。さらに、フィルタリングを、ビット・カウントを減らすために少なくともいくつかのセグメントの追加フィルタリングを誘導するために、より高いレベルまたはより困難なレベルでの再エンコード中に実装することができる。いくつかの例で、フィルタリングおよび／または適用されるフィルタリングのレベルは、所望される結果を達成するために、ユーザによって調整可能および／または選択可能である。
【０１９２】
フィルタリングおよび／または再エンコーディングを適用すべきセグメントを識別する際に、コンテンツの品質を、例えば動きベクトル（１つまたは複数）、限定作用素（quantifiers）、および／またはその組合せに基づいて評価することができる。明確に編成されたまたは順序付けられたベクトルは、よいエンコーディングを示す傾向があり、ランダムなおよび／または悪く順序付けられたベクトルは、不正確なエンコーディングを示す傾向がある。しかし、通常、いくつかの実施形態は、雨、風雨（weather）、雲、ズームイン、および類似物を含むビデオ・コンテンツなど、の一部のコンテンツは、エンコードするのが難しい可能性があり、動きベクトルおよび／または限定作用数値を使用してそれほど効果的には検出できないので、動きベクトルに排他的に頼ることはしない。
【０１９３】
図２９に、要求されるビット・バジェットを満足するかそれ未満になるようにトータル・ビット・カウントを調整するのに使用されるプロセス２９２０の単純化された流れ図を示す。ステップ２９２２で、結果のエンコードされたストリームが事前定義のビット・バジェット（例えば、４Ｇビット）を満足するように、コンテンツ・ストリームをエンコードして、初期エンコードまたはベース・エンコード完了する。ステップ２９２４で、エンコードされたストリームを評価して、エンコードされたストリームのセグメントが１つまたは複数のデコーダ・モデルに失敗するかどうかを決定する。上で示したように、エンコードされたストリームの評価は、ストリームがエンコードされている間におよびフル・エンコードの前に開始することができる。
【０１９４】
ステップ２９２６で、１つまたは複数のバッファ・モデルの違反として識別されたセグメントのビットレートを減らし、それらが要求されるバッファ・モデル（１つまたは複数）を満足するように再エンコードする。ステップ２９３０で、トータル・ビット・カウントを識別し、プロセス２９２０は、トータル・カウントが定義された最大ビット・カウントを超えるかどうかを決定する。トータル・ビット・カウントが最大ビット・カウントを超えない場合には、プロセス２９２０は終了する。
【０１９５】
ステップ２９３０で、トータル・ビットが最大値を超えると決定されるときには、このプロセスはステップ２９３４にスキップし、ここで、最大のマージンだけバッファ・モデル閾値を超える品質を有するセグメントを識別する。いくつかの例で、事前定義の時間長（distance）またはフレーム数以内のセグメントが、再調査され、その時間長またはフレーム数以内で最大のマージンを有するセグメントが、選択される。ステップ２９３６で、最大の品質マージンを有する識別されたセグメントを、追加ビットを解放するためにより低いビットレートで再エンコードする。その後、プロセス２９２０は、ステップ２９３０に戻って、トータル・ビット・カウントが要求される最大カウント未満であるかどうかを決定する。プロセス２９２０のいくつかの代替構成では、失敗したセグメントの再エンコードは、失敗したセグメントを再エンコードするのに十分な量の容量が解放されるまで、実行されない。
【０１９６】
図３０に、コンテンツ・ストリーム上の品質変化を平滑化しまたは制限するのに使用されるプロセス３０２０の単純化された流れ図を示す。ステップ３０２２で、最低の品質レベルまたは第１の閾値限度未満の品質レベルを有する１つまたは複数のセグメントを識別する。ステップ３０２４で、このプロセスは、高い品質レベルを有し、かつ／または最低の品質を有する１つまたは複数のセグメントの品質レベルを第２の閾値だけ超える品質レベルを有し、ステップ３０２２で識別された１つまたは複数のセグメントから事前定義の範囲内またはフレーム数以内にある１つまたは複数のセグメントが識別されるかどうかを決定する。事前定義の範囲は、バッファ・フィル・レベル、バッファ・レベル・シフティング、事前定義の個数のＧＯＰ、データ転送のレート、および／または他のそのような要因など、多数の要因に依存するものとすることができる。ステップ３０２６で、高い品質レベルを有する識別されたセグメントのうちの１つまたは複数を、より低いビットレートで再エンコードする。ステップ３０３０で、低い品質を有する識別された１つまたは複数のセグメントを、高められたビットレートで再エンコードする。
【０１９７】
ステップ３０３２で、このプロセスは、トータル・ビット・カウントが最大トータル・ビット・カウントを超えるかどうかを決定する。トータル・ビット・カウントが最大値を超える場合には、ステップ３０３４に入り、ここで、より低い品質のセグメントの事前定義の範囲内またはフレーム数以内の、高い品質または別のセグメントの品質を超える品質を有する追加のセグメントがあるかどうかを決定する。高い品質レベルを有するセグメントがあるときには、ステップ３０３６でそのセグメントをより低いビットレートで再エンコードし、このプロセスは、ステップ３０３２に戻る。相対的に高い品質レベルを有するセグメントがない場合には、ステップ３０４０に入り、ここで、第１の閾値未満の品質を有する再エンコードされたコンテンツは、削除され、利用されず、このプロセスは終了する。
【０１９８】
ステップ３０３２で、トータル・ビット・カウントが最大値を超えないと決定されるときには、このプロセスは、ステップ３０４２に入り、ここで、トータル・ビット・カウントが最大ビット・カウントから限度以内であるかどうかを決定する。トータル・カウントが限度以内ではない場合には、このプロセスは、ステップ３０２２に戻って、エンコードされた品質を一様にし、かつ／または改善するために再エンコードすべき追加のセグメントをさらに識別し、そうでない場合には、このプロセスは終了する。
【０１９９】
ビット・バジェットを再分配するためのコンテンツの再エンコーディングおよび／またはコンテンツの品質の調整は、いくつかの実施形態を介してユーザ対話なしで実装することができる。しかし、いくつかの実施形態で、低品質セグメントの品質を高めることを可能にするために高品質セグメントの品質を下げるためのビットのシフトを開始する前に、いくつかの実施形態は、品質を調整するのに有益である可能性がある区域を識別し、またはマークするタイムラインをユーザのために生成する。次に、このシステムは、ユーザが、複数の調整がある場合に調整を選択し、所望されるときに調整を実装することを可能にする。それに加えておよび／またはその代わりに、このシステムを、事前定義の品質測定値またはスケール（いくつかの例でユーザによって選択することができる）に基づいてセグメントおよび／またはフレームの品質を識別し、ラベルを付けるタイムラインを生成するように構成することができる。ラベルを付けられた品質に基づいて、このシステムを、手動操作を可能にするように構成することができ、この手動操作では、ユーザが、コンテンツのストリームを評価し、再エンコードおよび／または品質調整の区域を定義することができる。
【０２００】
上で紹介したように、いくつかの実施形態は、ハードウェア、ソフトウェア、ファームウェア、および／またはその組合せを介して実装することができる。さらに、いくつかの実施形態は、シリアル・デジタル・ケーブルを介するソース（例えば、ＳＭＰＴＥ２９２Ｍ）などのソースから、加速されたレート（例えば、コンテンツが受け取られるレート付近）のビジュアル・ビデオ・コンテンツなど、圧縮されていない高品位コンテンツをエンコードすることができる。エンコーディングは、いくつかの実装で、リアルタイム・レートで実行することができ、ファイル形式（例えば、ＡＶＩ、Ｑｕｉｃｋｔｉｍｅ、生フレーム、および類似物）の高品位コンテンツのトランスコーディングを提供することができる。いくつかのシステムは、標準規格の変化および新しいエンコーディング・フォーマットに適合可能になるように構成され、品質の調整および／または修正と特徴（feature）の品質向上とを可能にする。いくつかの実施形態は、コモディティ・コンポーネントを利用して実装され、プロセッサの速度向上および機能を活用するために簡単に適合可能である。
【０２０１】
本発明を、本明細書でその特定の実施形態および応用例によって説明してきたが、特許請求の範囲に記載の本発明の範囲から逸脱せずに、当業者は、多数の修正形態および変形形態を作ることができるであろう。
【図面の簡単な説明】
【０２０２】
【図１】いくつかの実施形態によるエンコーディング・システムを示す単純化されたブロック図である。
【図２】図１のエンコーディング・システムを実装し、かつ／あるいはエンコーディングおよび／または再エンコーディングの一部またはすべてを実行するためにいくつかの実施形態で利用することができるコンピュータ・システムを示す単純化されたブロック図である。
【図３】１つまたは複数の、所望されるデコーダ・モデルを満足するエンコードされたコンテンツを達成するためにエンコーディングを実装する、いくつかの実施形態によるプロセスを示す単純化された流れ図である。
【図４】いくつかの実施形態によるハイポセティカル・リファレンス・デコーダ（ＨＲＤ）を示す単純化されたブロック図である。
【図５】セグメント再エンコードを実行しなければならないかどうかを決定するプロセスを示す単純化された流れ図である。
【図６】エンコードされたコンテンツを評価するプロセスを示す単純化された流れ図である。
【図７】複数のピクチャまたはフレームを含むコンテンツのストリームの一部の単純化されたタイムライン表現を示す図である。
【図８】本実施形態のいくつかの実装によるセグメント再エンコード・スタート・ポイントおよびセグメント再エンコード・エンド・ポイントを識別するのに使用されるプロセスを示す単純化された流れ図である。
【図９】再エンコードに対してバッファ・モデル評価を決定し、実装するのに使用されるプロセスを示す単純化された流れ図である。
【図１０】リーキー・バケット・モデルの単純化されたグラフィカル表現を示す図である。
【図１１】可変ビットレートによるリーキー・バケット・モデルの単純化されたグラフィカル表現を示す図である。
【図１２】ユーザがコンテンツをエンコードし、エンコードされたコンテンツを再検討し、かつ／または１つもしくは複数のセグメントの再エンコーディングを実装し、制御することを可能にする、いくつかの実施形態によるグラフィカル・ユーザ・インターフェースを示す図である。
【図１３】ソース・コード・コントロール・ウィンドウの単純化されたグラフィカル表現を示す図である。
【図１４】ムービー・コントロール・ウィンドウの単純化されたグラフィカル表現を示す図である。
【図１５】いくつかの実施形態によるタイムライン・ウィンドウの単純化されたグラフィカル表現を示す図である。
【図１６】タイム・ライン・ツールバーの拡大されたビューの単純化されたグラフィカル表現を示す図である。
【図１７】ステータス・バーの拡大されたビューの単純化されたグラフィカル表現を示す図である。
【図１８】ベース・エンコードの後の、入力タブ・セッティング・ウィンドウが表示された、セッティング・ウィンドウを示す図である。
【図１９】ベース・エンコードの後の、ビデオ・タブ・セッティング・ウィンドウが表示された、セッティング・ウィンドウを示す図である。
【図２０】セグメント・タブ・セッティング・ウィンドウが表示された、セッティング・ウィンドウを示す図である。
【図２１】ｅｘｐｒｅｓｓＱＣタブ・セッティング・ウィンドウが表示された、セッティング・ウィンドウを示す図である。
【図２２】いくつかの実施形態によるエンコーディング・システムを示す単純化されたブロック図である。
【図２３】分割されたセグメントに分割されたコンテンツのストリームを示す単純化されたブロック図表現である。
【図２４】いくつかの実施形態によるダイサの例の実装を示す単純化されたブロック図である。
【図２５】図２２のエンコーディング・システムで実装できる例のホスト・システムを示す単純化されたブロック図である。
【図２６】いくつかの実施形態による図２２のエンコーディング・システムの一部を示すブロック図である。
【図２７】図２６の複雑度アナライザを介して生成できる、１にスケーリングされたコンテンツ・ストリームの複雑度プロファイルまたはマッピングを示す単純化されたグラフィカル表現である。
【図２８】チャプタ・ポイントの挿入および／またはグループ・オブ・ピクチャ（ＧＯＰ）構造の変更のいくつかの実施形態によるプロセスを示す単純化された流れ図である。
【図２９】所望されるビット・バジェットを満足するかそれ未満になるようにトータル・ビット・カウントを調整するのに使用されるプロセスを示す単純化された流れ図である。
【図３０】コンテンツ・ストリーム上の品質変化を平滑化しまたは制限するのに使用されるプロセスを示す単純化された流れ図である。
【図１】
0005404038.tif 000006
【図２】
0005404038.tif 000007
【図３】
0005404038.tif 000008
【図４】
0005404038.tif 000009
【図５】
0005404038.tif 000010
【図６】
0005404038.tif 000011
【図７】
0005404038.tif 000012
【図８】
0005404038.tif 000013
【図９】
0005404038.tif 000014
【図１０】
0005404038.tif 000015
【図１１】
0005404038.tif 000016
【図１２】
0005404038.tif 000017
【図１３】
0005404038.tif 000018
【図１４】
0005404038.tif 000019
【図１５】
0005404038.tif 000020
【図１６】
0005404038.tif 000021
【図１７】
0005404038.tif 000022
【図１８】
0005404038.tif 000023
【図１９】
0005404038.tif 000024
【図２０】
0005404038.tif 000025
【図２１】
0005404038.tif 000026
【図２２】
0005404038.tif 000027
【図２３】
0005404038.tif 000028
【図２４】
0005404038.tif 000029
【図２５】
0005404038.tif 000030
【図２６】
0005404038.tif 000031
【図２７】
0005404038.tif 000032
【図２８】
0005404038.tif 000033
【図２９】
0005404038.tif 000034
【図３０】
0005404038.tif 000035