JP2011083008A - メディアサンプルを処理する方法 - Google Patents

Abstract

【課題】非整数フレームレートを有することから生じる可能性のある、ある量のドリフトをタイムコードが含むメディアサンプルから、真の時間を確認することが可能なタイムコーディングシステム、方法、およびデータ構造を提供する。
【解決手段】メディアサンプルに関連する、タイムコードと真の時間との時間差を記述するオフセットパラメータの使用を組み込む。ＳＭＰＴＥなどの現行のタイムコーディングパラダイムと共に組み込むことができ、かつそれと互換に使用する。別の実施形態では、フレームのフィールドレベルでタイムコーディングを行うことが可能となる。これにより、真の時間の計算を行って、フレームの個々のフィールドに関連する真の時間を確認する。
【選択図】図３

Description

（関連出願）
本出願は、２０００年８月１５日出願の米国仮出願第６０／２２５４９８号に由来し、その優先権を主張するものであり、その開示は、参照により本明細書に組み込まれる。

（技術分野）
本発明は、メディアサンプルをタイムコーディングする方法、システム、およびデータ構造に関する。

（発明の背景）
タイミング情報を記録および使用する概念は、マルチメディアアプリケーションのニーズにとって基本的なものである。ピクチャ、ビデオ、テキスト、グラフィックス、およびサウンドは、メディアストリームの各サンプルに関連する時間の何らかの理解と共に記録する必要がある。このことは、ユーザに対してメディアストリームを再生するときにメディアの元のタイミングを保持するための情報を搬送し、メディアストリーム内の特定の位置を識別し、さらには科学的記録または履歴を作成するためにメディアサンプルに関連する時間を記録する目的で、様々なマルチメディアストリームを互いに同期するのに有用である。例えば、オーディオやビデオが一緒に記録されるが、別々のメディアデータのストリームとして処理される場合、２つ（または３つ以上）のストリームの同期を調整するためにタイミング情報が必要である。

通常、メディアストリーム（記録したオーディオトラック、あるいは記録したビデオまたはフィルムショット）は、タイミング情報にそれぞれ（暗示的または明示的に）関連付けられるメディアサンプルのシーケンスとして表される。このことの良い例はビデオや映画である。ビデオや映画は、通常は画像すなわちフレームのシーケンスとして作成される。フレームはそれぞれ、特定の短い時間間隔（例えば、通常は映画フィルムの各フレームについて１／２４秒）についてのカメラビューを表す。毎秒当たり、記録の過程で使用したのと同じフレーム数（フレームレートと呼ばれる）でこのピクチャのシーケンスが再生されるとき、閲覧者に対して、シーンに描写される物体が自然に移動しているかのような錯覚を生み出すことができる。

同様に、サウンドはしばしば、オーディオ波形を定期的にサンプリングし、デジタルサンプルのシーケンスを（例えば毎秒当たり４８０００サンプルを使用して）作成し、デジタル圧縮符号化またはパケットネットワーク伝送（インターネット伝送など）などの次の処理のためにこれらのサンプルの組をフレームと呼ばれる処理単位（例えば１フレーム当たり６４サンプル）にグループ化することによって記録される。次いでオーディオデータの受信機は、受信したオーディオのフレームを再度組み上げ、それを復号化し、得られるデジタルサンプルのシーケンスを、電気音響技術を使用してサウンドに戻す。

ビデオと、関連するオーディオコンテンツとを同期するなど、複数のメディアサンプルのストリームを整合させるために、タイミング情報を適切に記録および制御することが必要である。サンプルの推移が経時的に自然に表示されないメディアの使用でさえ、しばしばマルチメディアシステムでタイミング情報を使用することが必要となる。例えば、静止画像（写真、絵画、または文書など）を、あるオーディオ（画像の内容または歴史の説明など）と共に表示すべき場合、静止画像（時間的に１つのフレームまたはサンプルだけからなる実体）の表示タイミングを、関連するオーディオトラックのタイミングと整合させる必要のあることがある。

このようなタイミング情報の有用性の他の例には、写真を撮影した日付または時刻を記録できること、またはメディアストリーム内の編集点または閲覧点（例えばカメラがローリングを開始してから５分後）を指定できることが含まれる。

上記の各ケースでは、メディアストリームのサンプルまたは時間的なサンプルのグループは、フレーム、すなわち基本的処理単位として識別することができる。フレームが時間的に複数のサンプルからなる場合、フレームに関して表されるタイミング情報が、最初のサンプル、最後のサンプル、または中間のサンプルの時間など、フレーム内のある基準点の時間に対応するという規約を確立することができる。

ある場合には、フィールドと呼ばれるさらに小さい処理単位にフレームをさらに細分することができる。この一例は、インタレース化スキャンビデオを使用する場合である。この場合、ピクチャ中の交互の線のサンプリングが分離され、それによって各ピクチャの線の半分がある瞬間に第１フィールドとしてサンプリングされ、次いで短時間の後に、ピクチャの線の他の半分が第２フィールドとしてサンプリングされる。例えば、線１、３、５などをピクチャの第１フィールドとしてサンプリングすることができ、次いでピクチャの線０、２、４などを短時間の後に（例えば１／５０秒後）第２フィールドとしてサンプリングすることができる。このようなインタレース化スキャンビデオでは、各フレームは、一般に２つのフィールドに分離することができる。

同様に、データ圧縮またはパケットネットワーク伝送のための、オーディオ波形の６４サンプルのグループ化をフレームと見て、かつそのフレーム内の８つのサンプルの各グループをフィールドと見ることができる。この例では、各フレーム内に８つのフィールドがあり、フィールドはそれぞれ８つのサンプルを含むことになる。

当技術分野で周知のサンプル化メディアストリームを使用するいくつかの方法では、フレームまたはフィールドが、重複する数組のサンプル、または重複する数組のサンプルの変換からなることがある。この挙動の２つの例は、重複直交変換［１）ＨｅｎｒｉｑｕｅＳａｒｍｅｎｔｏ Ｍａｌｖａｒ，ＳｉｇｎａｌＰｒｏｃｅｓｓｉｎｇ ｗｉｔｈ Ｌａｐｐｅｄ Ｔｒａｎｓｆｏｒｍｓ、Ｂｏｓｔｏｎ、ＭＡ、Ａｒｔｅｃｈ Ｈｏｕｓｅ、１９９２；２）Ｈ．Ｓ．Ｍａｌｖａｒ ａｎｄ Ｄ．Ｈ．Ｓｔａｅｌｉｎ、「Ｔｈｅ ＬＯＴ：ｔｒａｎｓｆｏｒｍｃｏｄｉｎｇ ｗｉｔｈｏｕｔ ｂｌｏｃｋｉｎｇ ｅｆｆｅｃｔｓ」、ＩＥＥＥ Ｔｒａｎｓａｃｔｉｏｎｓ ｏｎ Ａｃｏｕｓｔｉｃｓ，Ｓｐｅｅｃｈ，ａｎｄ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｉｎｇ、ｖｏｌ．３７、ｐｐ．５５３−５５９、Ａｐｒ．１９８９；３）Ｈ．Ｓ．Ｍａｌｖａｒ、Ｍｅｔｈｏｄ ａｎｄ ｓｙｓｔｅｍ ｆｏｒａｄａｐｔｉｎｇ ａ ｄｉｇｉｔｉｚｅｄ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｉｎｇｓｙｓｔｅｍ ｆｏｒ ｂｌｏｃｋ ｐｒｏｃｅｓｓｉｎｇ ｗｉｔｈ ｍｉｎｉｍａｌ ｂｌｏｃｋｉｎｇａｒｔｉｆａｃｔｓ、Ｕ．Ｓ．Ｐａｔｅｎｔ Ｎｏ．４，７５４，４９２、Ｊｕｎｅ １９８８］や、オーディオ冗長度コーディング［１）Ｊ．Ｃ．Ｂｏｌｏｔ、Ｈ．Ｃｒｅｐｉｎ、Ａ．Ｖｅｇａ−Ｇａｒｃｉａ：「Ａｎａｌｙｓｉｓｏｆ Ａｕｄｉｏ Ｐａｃｋｅｔ Ｌｏｓｓ ｉｎｔｈｅ Ｉｎｔｅｒｎｅｔ」、Ｐｒｏｃｅｅｄｉｎｇｓｏｆ ｔｈｅ ５ｔｈ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｗｏｒｋｓｈｏｐ ｏｎ Ｎｅｔｗｏｒｋ ａｎｄ Ｏｐｅｒａｔｉｎｇ ＳｙｓｔｅｍＳｕｐｐｏｒｔ ｆｏｒ Ｄｉｇｉｔａｌ Ａｕｄｉｏ ａｎｄＶｉｄｅｏ、ｐｐ．１６３−１７４、Ｄｕｒｈａｍ、Ａｐｒｉｌ １９９５；２）Ｃ．Ｐｅｒｋｉｎｓ、Ｉ．Ｋｏｕｖｅｌａｓ、Ｏ．Ｈｏｄｓｏｎ、Ｖ．Ｈａｒｄｍａｎ、Ｍ．Ｈａｎｄｌｅｙ、Ｊ．Ｃ．Ｂｏｌｏｔ、Ａ．Ｖｅｇａ−Ｇａｒｃｉａ、Ｓ．Ｆｏｓｓｅ−Ｐａｒｉｓｉｓ：「ＲＴＰＰａｙｌｏａｄ ｆｏｒ Ｒｅｄｕｎｄａｎｔ Ａｕｄｉｏ Ｄａｔａ」、ＩｎｔｅｒｎｅｔＥｎｇｉｎｅｅｒｉｎｇ ＴａｓｋＦｏｒｃｅ Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ ＲＦＣ２１９８，１９９７］を使用することである。このような場合であってもやはり、時間をサンプルのフレームまたはフィールドと関連付ける規約を確立することは可能である。

ある場合には、正確なクロック信号で制御される固定ステップの時間ですべてのサンプルが作成される典型的なオーディオ処理などのように、サンプリングパターンが時間的に非常に規則的となる。しかし別の場合には、シーケンス中の隣接するサンプル間の時間が、シーケンス中の位置ごとに異なる可能性がある。

このような挙動の一例は、パケット損失を伴うパケットネットワークを介してオーディオを送信するときである。これにより、一部のフレームがデコーダで受信されないのに、他のフレームは、パケットの元の相対的タイミングで使用するように再生すべきことになる可能性がある。このような挙動の別の例は低ビットレートビデオカンファレンシングである。低ビットレートビデオカンファレンシングでは、毎秒当たり送信されるフレーム数が、シーン中の動きの量に応じてしばしば変化する（変化が小さいと、変化が大きい場合よりも送信するデータが少なくなり、ビット／秒単位の全チャネルデータレートは通常固定されているからである）。

基礎となるサンプリング構造が、基本フレームまたはフィールド処理単位サンプリングレートである（しかし、ある処理単位はスキップされる可能性がある）と理解される場合、時間表現での別のカウント単位として処理単位を識別できることは有用である。これを設計に組み込む場合、処理単位のスキップが生じたことは、カウント単位の値が欠けていることによって確認することができる（例えば、処理単位のカウントが１、２、３、４、６、７、８、９、．．．続く場合、カウント番号５が欠けていることは明らかである）。

基礎となるサンプリング構造が、サンプリングが非常に不規則であるので基本処理単位サンプリングレートが存在しないようなものである場合、必要なのは、単に各処理単位についての真の時間の良好な表現だけである。しかし通常は、このような場合、処理単位の位置の基準とすることができる共通時間クロックが少なくとも存在すべきである。

（規則的なサンプリング時間、または不規則なサンプリング時間の）いずれの場合にも、マルチメディアシステムが、メディアコンテンツの各処理単位のサンプルまたはフレームまたはフィールドについてのタイミング情報を記録および使用することは有用である。

異なるタイプのメディアでは、異なるサンプリングレートが必要となる可能性がある。しかしタイミング情報が同じ精度で常に格納されている場合、ある量の丸め誤差が、時間を表すために使用する方法によって導入される可能性がある。各サンプルに関連する記録時間を、丸め誤差をほとんどまたは全く伴わずにシステムで正確に表すことが望ましい。例えば、メディアストリームが毎秒当たり３００００／１００１フレームで運用され（北米規格ＮＴＳＣ放送ビデオの典型的なフレームレート−毎秒約２９．９７フレーム）、システムで使用する時間値の精度を部分的に１０−６秒以内にすべき場合、人間の観点からはこの時間値は非常に正確であるかもしれないが、システム内の処理要素にとっては、厳密に規則的なサンプルタイミング（例えば１サンプル当たり１００１／３００００秒）が厳密に規則的ではないように見える可能性がある（例えば、サンプル間の３３３６６クロック増分カウントの後に、３３３６７の増分が続き、次いで３３３６７の増分、次いで再び３３３６６の増分が続く場合）。これにより、システムでメディアサンプルを適切に処理する方法を決定するのが困難となる。

時間を表す方法を見つける際の別の問題は、完全に理想的な「ウォールクロック（ｗａｌｌｃｌｏｃｋ）」で測定されることになる真の時間に対して、表示が「ドリフト」する可能性があることである。例えば、厳密に規則的な、１サンプル当たり１００１／３００００秒のサンプルタイミングをシステムで用い、かつサンプル間で３３３６７の増分である増分時間間隔ですべてのサンプルが表される場合、このようなサンプルのロングシーケンスに対して使用される全時間は、真の時間間隔よりも幾分長くなり、１日当たり合計約１フレーム時間となり、１年の期間の後、５分を超える誤りが蓄積されることになる。

したがって、ドリフトを、サンプリング時間のタイムコード表現中の何らかの誤りと定義する。ドリフトは、（補正しない場合）サンプルのシーケンスが推移するにつれて大きさが増大する傾向がある。

タイミング情報を表す方法の一例は、ＳＭＰＴＥ １２Ｍ設計［Ｓｏｃｉｅｔｙ ｏｆ Ｍｏｔｉｏｎ Ｐｉｃｔｕｒｅ ａｎｄＴｅｌｅｖｉｓｉｏｎ Ｅｎｇｉｎｅｅｒｓ、ＲｅｃｏｍｍｅｎｄｅｄＰｒａｃｔｉｃｅ １２Ｍ：１９９９］から得られる（以後「ＳＭＰＴＥタイムコード」と呼ぶ）。ＳＭＰＴＥタイムコードは通常、米国のＮａｔｉｏｎａｌＴｅｌｅｖｉｓｉｏｎ Ｓｔａｎｄａｒｄｓ Ｃｏｍｍｉｔｔｅｅ（ＮＴＳＣ）テレビジョン伝送フォーマット、または欧州のＰｈａｓｅ Ａｌｔｅｒｎａｔｉｎｇ Ｌｉｎｅ（ＰＡＬ）テレビジョン伝送フォーマットで規定されるタイミングを有するテレビジョンビデオデータ用に使用される。

ＳＭＰＴＥタイムコードに関する背景
ＳＭＰＴＥタイムコードは、当初はテレビジョン業界や映画業界でビデオテープ技術を扱う際に使用するために開発された同期信号方法である。ビデオテープで当初直面した問題は、ビデオまたはサウンドトラックの編集用の装置を同期するための「フレームアキュレット（ｆｒａｍｅａｃｃｕｒａｔｅ）な」方式が存在しなかったことである。初期にはいくつかの方法が利用されたが、すべったり延びたりする、テープ固有の特性のために、フレームの正確な同期の達成は限られたものであった。ＳＭＰＴＥタイムコードの導入により、このフレーム精度が実現され、追加の機能が組み込まれた。ＳＭＰＴＥに関する追加の情報源には、ＣｉｐｈｅｒＤｉｇｉｔａｌ Ｉｎｃ．による「ＴｈｅＴｉｍｅ Ｃｏｄｅ Ｈａｎｄｂｏｏｋ」が含まれる。ここには、この問題の完全な扱い方や、ＡＮＳＩ規格ＳＭＰＴＥ １２Ｍ−１９８６を含む付録が与えられている。加えて、Ｇａｒｙ Ｄａｖｉｓ ａｎｄ Ｒａｌｐｈ Ｊｏｎｅｓｆｏｒ Ｙａｍａｈａによる「ＴｈｅＳｏｕｎｄ ＲｅｉｎｆｏｒｃｅｍｅｎｔＨａｎｄｂｏｏｋ」と題するテキストには、タイムコード理論と応用例に関するセクションが含まれている。

ＳＭＰＴＥタイムコードの主な目的は、様々な装置を同期することである。タイムコード信号は、他のすべてが基準とするシステムワイドクロックを提供するようにフォーマットされる。信号は通常、ビデオ信号で直接符号化され、または標準オーディオ装置を介して配布される。ＳＭＰＴＥタイムコードではビデオの術語を数多く参照するが、オーディオ専用応用例のために使用されることもある。

多くの応用例では、タイムコード源が信号を供給し、一方システム内の残りの装置は、それに同期し、追従する。タイムコード源は専用タイムコードジェネレータでよく、または（しばしばそうであるが）主機能に加えてタイムコードを供給する１つの生成装置でよい。この一例は、あるトラックに対するタイムコードと、別のトラックに対して生成するためのサウンドを供給しているマルチトラックオーディオテープデッキである。ビデオテープは、タイムコードを記録および再生するために、しばしばキュートラック、またはそのオーディオサウンドトラックのうちの１つを同様に利用する。

他の応用例、すなわちビデオでは、この装置は、複数のタイムコード源を１つに同期するために、タイムコードを内部で使用する。一例は、いくつかの事前記録したシーンからのタイムコードと同期するビデオエディタである。各シーンが互いに組み合わされて最終的な製品が作成されるとき、それぞれのタイムコードは、最終的な製品に記録される新しいタイムコードと同期される。

ＳＭＰＴＥタイムアドレス
ＳＭＰＴＥタイムコードは、ビデオ信号の各フレームに対する固有のアドレスを供給する。このアドレスは、２４時間クロックおよびビデオフレームレートに基づく、時、分、秒、およびフレームを以下のフォーマットで表す８桁の数である。
ＨＨ：ＭＭ：ＳＳ：ＦＦ

これらのフィールドの値は、ＨＨに関しては００から２３の範囲で変化し、ＭＭに関しては００から５９、ＳＳに関しては００から５９、ＦＦに関しては００から２４または２９の範囲で変化する（ただし２４は、ＰＡＬ２５フレーム／秒ビデオに対する最大値であり、２９は、ＮＴＳＣ ３００００／１００１フレーム／秒ビデオに対する最大値である）。慣例により、一日の最初のフレームは００：００：００：０１とマークされるとみなし、最後のフレームは００：００：００：００とマークされるとみなす（このフレームの１つ前のフレームは、ＰＡＬの場合２３：５９：５９：２４とマークされ、ＮＴＳＣの場合２３：５９：５９：２９とマークされる）。このフォーマットは、公称クロック時間や、シーンまたはプログラム素材の公称期間を表し、このフォーマットにより、近似時間計算が容易になり、直接的になる。

ＳＭＰＴＥフレームレート
フレームはＳＭＰＴＥタイムコード内の測度の最小の単位であり、フィルムまたはビデオの個々の「ピクチャ」に対する直接的な基準である。レートは、動きのレンディションが得られるようにピクチャが表示される、毎秒当たりの時間数である。ＳＭＰＴＥタイムコードで一般に使用する標準的フレームレート（フレーム／秒）には２つある。それは、毎秒当たり２５フレームのフレームレートと、毎秒当たり３００００／１００１フレーム（毎秒当たり約２９．９７フレーム）のフレームレートである。毎秒当たり２５フレームのレートは、ＳＭＰＴＥＥＢＵ（ＰＡＬ／ＳＥＣＡＭカラーおよび白黒）とも呼ばれる欧州のビデオに基づいている。毎秒当たり３００００／１００１フレーム（大雑把に毎秒３０フレームと呼ばれることもある）は、米国のＮＴＳＣカラービデオ放送に基づいている。毎秒当たり２９．９７フレームを使用する場合、ＳＭＰＴＥタイムコードを使用する方法には２つある。それは「非ドロップ」と「ドロップフレーム」である。

フレーム値は、フィルムまたはビデオのフレームごとに１カウント増加し、それによってユーザが、イベントの時間間隔を１秒の１／２５または１００１／３００００にすることが可能となる。

ＳＭＰＴＥタイムコードもまた、厳密な毎秒当たり３０フレーム／秒のフレームレートのために使用されることがある。しかしユーザは、これを使用することと、わずかに低速な、米国のＮＴＳＣカラー放送ビデオの毎秒当たり３００００／１００１フレームのレートとを区別するように注意しなければならない（調節因子１０００／１００１は、現代のカラービデオと、モノクロームビデオを毎秒当たり３０フレームで放送するための以前の設計との間の互換性を実現するようにテレビジョン信号が調節される方法に由来する）。

したがって、ＳＭＰＴＥタイムコードは、ビデオピクチャに関するパラメータＨｏｕｒｓ、Ｍｉｎｕｔｅｓ、Ｓｅｃｏｎｄｓ、およびＦｒａｍｅｓのそれぞれの整数の数を記録することからなる。フレーム番号の各増分は、ＮＴＳＣシステムでの時間の増分１００１／３００００秒と、ＰＡＬシステムでの時間の増分１／２５秒を表すと理解される。

しかし、ＮＴＳＣシステムでの毎秒当たりのフレーム数（３００００／１００１）は整数でないので、ＳＭＰＴＥ１２Ｍタイムコードの時間表現と真の「ウォールクロック」時間との間のドリフトの問題がある。このドリフトは、ＳＭＰＴＥ「ドロップフレーム」カウントと呼ばれる特別なフレームカウント方法によって著しく低減することができる。ＳＭＰＴＥドロップフレームカウントを使用しないと、ＳＭＰＴＥタイムコードの値Ｈｏｕｒｓ、Ｍｉｎｕｔｅｓ、およびＳｅｃｏｎｄｓと、真の「ウォールクロック」で測定される値との間のドリフトにより、１日当たり８６秒を超えるエラーが累積することになる。ＳＭＰＴＥドロップフレームカウントを使用するとき、ドリフトの蓄積量は、約１０００分の１に低減することができる（しかし、ドリフトはまだ完全には解消されず、残りのドリフトはまだ２フレームサンプリング期間を超える）。

ＳＭＰＴＥタイムコードは、ビデオ製作業界で非常に広く用いられている（例えば、ＳＭＰＴＥタイムコードは、多くのビデオテープレコーダの設計に組み込まれている）。したがって、一般的などんなメディアタイムコード設計でもこのＳＭＰＴＥタイムコードと最大限に互換であるなら、非常に有用である。このような互換性を達成することができる場合、これにより、メディアタイムコード用に設計された装置が、具体的にはＳＭＰＴＥタイムコードを使用するように設計された他の装置と共に良好に動作することが可能となる。

この文書中では、以下の術語を使用する。タイムコードは、メディアサンプル、フレーム、またはフィールドに関連する時間を表すのに使用されるデータを含む。タイムコードのデータを、タイムベースとタイムスタンプの２つの別々のタイプに分離することは有用である。タイムスタンプは、特定の処理単位（サンプル、フレーム、またはフィールド）についてのタイミングを表すのに使用される情報を含む。タイムベースは、タイムスタンプで使用される測度単位の基礎を確立する情報を含む。言い換えれば、タイムベースは、タイムスタンプを適切に解釈するのに必要な情報である。メディアストリームについてのタイムベースは通常、サンプルの全シーケンス、または少なくとも非常に大きな１組のサンプルついてのタイムベースと同じままである。

例えば、ＳＭＰＴＥタイムコードを、以下のものからなるタイムベースを有するものとして解釈することができる。
・システムがＮＴＳＣであるか、それともＰＡＬであるかについての知識（または表示）、および
・システムがドリフトを部分的に補償するためにＳＭＰＴＥ「ドロップフレーム」カウントを使用するかどうかについての知識（または表示）

上記が与えられると、タイムスタンプは、特定のビデオフレームごとのパラメータＨｏｕｒｓ、Ｍｉｎｕｔｅｓ、Ｓｅｃｏｎｄｓ、およびＦｒａｍｅｓの表現からなる。

本発明は、様々なメディアに関連する改良型のタイミングシステム、方法、および構造を提供することに関連する問題から生まれたものである。本発明はまた、現在使用されているタイムコード、具体的にはＳＭＰＴＥタイムコードと互換の、改良型のタイミングシステム、方法、および構造を提供することに関連する問題から生まれたものでもある。

（発明の概要）
いくつかの実施形態において、非整数フレームレートを有することから生じる可能性のある、ある量のドリフトをタイムコードが含むメディアサンプルから、真の時間を確認することが可能なタイムコーディングシステム、方法、およびデータ構造を説明する。本発明の方法は、メディアサンプルに関連する、タイムコードと真の時間との時間差を記述するオフセットパラメータの使用を組み込む。本発明の手法は、ＳＭＰＴＥなどの現行のタイムコーディングパラダイムと共に組み込むことができ、かつそれと互換に使用することができる。別の実施形態では、フレームのフィールドレベルでタイムコーディングを行うことが可能となる。これにより、真の時間の計算を行って、フレームの個々のフィールドに関連する真の時間を確認することが可能となる。

加えて、他の実施形態では、非整数フレームレートでサンプリングされるメディアサンプルに関連する可能性があるドリフトを低減することを対象とする新規なカウント補償方法が提供される。

秒パラメータおよびフレームパラメータを有する例示的タイムコードカウンタを示す図である。 オフセットパラメータ、秒パラメータ、およびフレームパラメータを有する例示的タイムコードカウンタを示す図である。 一実施形態による方法でのステップを記述する流れ図である。 一実施形態による方法でのステップを記述する流れ図である。 フィールドの概念を、メディアサンプルフレームに関するフィールドとして示す図である。 フィールドカウンタパラメータ、オフセットパラメータ、秒パラメータ、およびフレームパラメータを有する例示的タイムコードカウンタを示す図である。 フィールドの概念を、メディアサンプルフレームに関するフィールドとして２：３プルダウンに関連して示す図である。 一実施形態による方法でのステップを記述する流れ図である。 一実施形態による方法でのステップを記述する流れ図である。

（好ましい実施形態の詳細な説明）
概要
様々なメディアで使用するためのタイミングシステム、方法、および構造を説明する。様々な実施形態により、メディアサンプルに関連するタイムコードで「真の時間」に対する正確な基準を提供することができる手段が提供される。以下で説明する様々な実施形態は、特定のサンプル、フレーム、またはフィールドに関連する真の時間を確認するために既存のタイムコードと共に使用することができるオフセットパラメータを組み込む。

以下の説明では、まず一実施形態による例示的タイムベースの説明から始め、次いで本発明の一実施形態に関連する例示的タイムスタンプパラメータを説明する。

タイムコード設計のためのタイムベースパラメータ
以下の表１に、一実施形態によるタイムコードで用いるためのタイムベースを指定する一設計で使用される、例示的な完全な１組のパラメータを示す。

これらのパラメータの一部は、ヘッダでのみ指定することができ、または特定のシステム設計に関して特定の値に固定することができる。あるいは、これらのパラメータの一部または全部は、タイムスタンプごとに送信することができる。（フィールドベースのタイムコードがシステムで不要な場合、ＢａｓｅＦＰＦパラメータを取り除くことができ、ＢａｓｅＦＰＦパラメータは暗示値１を有することができる。）

これらのパラメータを使用して、重要な派生パラメータを以下のように定義する。
ＭａｘＦＰＳ＝ｃｅｉｌ（ＢａｓｅＵＰＳ／（ＢａｓｅＦＰＦ・ＢａｓｅＵＰＦ））

上式で、ｃｅｉｌ（ｘ）は、引数ｘの数学関数として定義され、非負値のｘについて、ｘが整数である場合はｘに等しく、そうでない場合はｘより大きい最小の整数に等しい。

表１に示すパラメータとＭａｘＦＰＳパラメータは、意味的には以下のように定義される。
・ＭａｘＤａｙｓ：タイムコード期間が定義される最大日数

・ＢａｓｅＵＰＳ：毎秒当たりのタイムベース中の基本時間単位数（クロックチックと呼ぶ）（例えば、毎秒当たり１２００００チックまたは毎秒当たり５０チック）。このパラメータは一般の整数値を有することができる。このパラメータはまた、特定の固定整数定数を一般の整数値で割ったものとして定義することもできる。整数定数は、３００００の整数倍にすることができる。このパラメータはまた、少なくとも１つが３００００の整数倍である１つまたは複数の値を有することもできる。

・ＢａｓｅＵＰＦ：フィールドカウント増分ごとに加えられる基本時間単位数（クロックチックと呼ぶ）（例えば、１フィールド当たり２００２チックまたは１フィールド当たり１チック）。このパラメータは一般的な整数値を有することができる。このパラメータはまた、少なくとも１つが１００１の整数倍である複数の値のうちの１つを有することもできる。

・ＢａｓｅＦＰＦ：フレームごとに定義されるフィールド数（例えば、インタレース化ビデオ中の１フレーム当たり２フィールド、または１つの順次走査ビデオの１フレーム当たり１フィールド）。メディアサンプルがそれぞれ等しい数のフィールドに分割されない場合、ＢａｓｅＦＰＦパラメータは１である。このパラメータは一般的な整数値を有することができる。

・ＣｏｕｎｔＣｏｍｐ：フレームカウント増分を補償して、真の「ウォールクロック」時間とタイムコードタイムスタンプとの間の経時的なドリフトを低減または解消するために適用する方法を示す。これは、以下のように定義される。

・「００」：カウント補償なし。ドリフトがもしあれば、それはタイムコードのＯｆｆｓｅｔパラメータ中に蓄積する。フレームパラメータは、単に０からＭａｘＦＰＳ−１までカウントし、次いで０から再び開始する。

・「０１」：ＳＭＰＴＥ「ドロップフレーム」カウント補償。連続するフレーム増分についてのタイムスタンプが１分のマークを通過するごとに、値が００、１０、２０、３０、４０、および５０である場合を除き、フレームパラメータカウントを、０ではなく２から開始する。フレームパラメータは常にＭａｘＦＰＳ−１までカウントする。この補償を実施した後に残るドリフトは、Ｏｆｆｓｅｔパラメータ中に蓄積する。

・「１０」：「トップドロップ」カウント補償。経時的なドリフトを解消するため、フレームパラメータをある時には０からＭａｘＦＰＳ−１までカウントし、ある時には０からＭａｘＦＰＳ−２までしかカウントしない（トップカウントを抜かす）。トップドロップカウント補償は恐らく最も直感的な方法である。例えば、基本フレームレートが毎秒当たり７．３フレームである場合、ある時には１秒に７フレームカウントし、ある時には８フレームカウントすることになる（したがってフレームカウントは、ある時には０から６までカウントし、ある時には７までカウントすることになる）。

・「１１」：「ボトムドロップ」カウント補償。経時的なドリフトを解消するため、フレームパラメータを、ある時には０からＭａｘＦＰＳ−１までカウントし、ある時には１からＭａｘＦＰＳ−１までしかカウントしない（ボトムカウントを抜かす）。このカウント方法は、トップドロッピングと同様であるが、この場合は、スキップするのはフレームパラメータの最高値ではなく、フレームパラメータ値０である。

ＢａｓｅＵＰＳ／（ＢａｓｅＦＰＦ・ＢａｓｅＵＰＦ）が整数である場合、ＣｏｕｎｔＣｏｍｐは「００」に等しい（この場合、ドリフトが累積しないからである）。ＢａｓｅＵＰＳ／（ＢａｓｅＦＰＦ・ＢａｓｅＵＰＦ）が１未満である場合、ＣｏｕｎｔＣｏｍｐは「０１」や「１１」とは等しくない（この場合、フレームパラメータが０を超えることができないからである）。ＣｏｕｎｔＣｏｍｐの使用法に関するより詳しい情報を以下に与える。

タイムコード設計のためのタイムスタンプパラメータ
表２に、上記の表１で定義されるタイムベースを使用する特定のタイムスタンプの、例示的な完全な１組のパラメータを示す。これらのパラメータの一部は、ヘッダでのみ指定することができ、または特定のシステム設計に関して特定の値に固定することができる。あるシステム設計では、未送信パラメータの一部についての値を格納または推測する受信機に応じて、あるパラメータを他のパラメータよりも頻繁に送信することも望ましい。（システムでフィールドベースのタイムコードが不要である場合、フィールドパラメータを除去することができ、フィールドパラメータは暗示値０を有することができる。）

上記の表中の情報を使用した、秒単位の真の（実数値の）「ウォールクロック」時間への変換は、以下のように定義することができる。
ｔ＝６０・（６０・Ｈｏｕｒｓ＋Ｍｉｎｕｔｅｓ）＋Ｓｅｃｏｎｄｓ＋（ＢａｓｅＵＰＦ・（ＢａｓｅＦＰＦ・Ｆｒａｍｅｓ＋Ｆｉｅｌｄｓ）＋Ｏｆｆｓｅｔ）／ＢａｓｅＵＰＳ

タイムコード定義の最大範囲を指定するのにＨｏｕｒｓとＭａｘＤａｙｓだけを使用するのではなく、タイムスタンプ定義がＤａｙパラメータも指定し、かつＨｏｕｒｓが０から２３の範囲に制限されるようにこのタイムコード定義を直接的に拡張することができる。あるいは、タイムコードは、ＤａｙＯｆＭｏｎｔｈ、Ｍｏｎｔｈ、およびＹｅａｒも含むことができ、タイムベースは、Ｙｅａｒパラメータの範囲を（暗示的または明示的に）指定することができる。しかし、この最後のタイプの定義は、うるう日、うるう秒などをどのように補償するかが問題となるので、より複雑になる。

不連続は、各サンプルについて表される時間値の差が、そのサンプル間の真の時間間隔の正確な表現として解釈することができない２つの連続するサンプル間の接合である。（これは、タイムコード値を変更せずにストリームを接合するときを示すのに有用である。）

表２に示すパラメータは、意味的には以下のように定義される。
・Ｄｉｓｃｏｎｔ：特定のサンプルと、隣接するサンプルとの間の境界に不連続が存在するかどうかを指定する。このパラメータにより、それぞれがそれ自体のタイムスタンプを有する２つのメディアサンプルのストリームを接合することが可能となるので、編集目的でこのパラメータを含めることは有用である。このパラメータは以下のように定義される。
○「００」：不連続は示されない（隣接するサンプルタイムコードに関して示されるのでない限り）
○「０１」：このサンプルと次のサンプルの間が不連続
○「１０」：前のサンプルとこのサンプルの間が不連続
○「１１」：前のサンプル、現サンプル、および次のサンプルの間が不連続
あるいは、Ｄｉｓｃｏｎｔパラメータは、値「１」が前のサンプルと現サンプルとの間の不連続を示すという規約（または値「１」が前のサンプルと次のサンプルとの間の不連続を示すという規約）を共に用いて、単一のビットにすることもできる。

・Ｈｏｕｒｓ：３６００を掛けたときに、タイムスタンプの成分として加えるべき（秒単位の）時間量を指定する整数パラメータ。

・Ｍｉｎｕｔｅｓ：６０を掛けたときに、タイムスタンプの成分として加えるべき（秒単位の）時間量を指定する整数パラメータ。

・Ｓｅｃｏｎｄｓ：タイムスタンプの成分として加えるべき時間の秒数を指定する整数パラメータ。

・Ｆｒａｍｅｓ：ＢａｓｅＵＰＦとＢａｓｅＦＰＦを掛け、ＢａｓｅＵＰＳで割ったときに、タイムスタンプの成分として加えるべき（秒単位の）時間量を指定する整数パラメータ。Ｆｒａｍｅｓパラメータは、メディアサンプルフレームごとに増分され、増分値がＭａｘＦＰＳ−１を超えた場合に０に設定され、ＣｏｕｎｔＣｏｍｐパラメータで示されるようにドリフトに対して調節される。ＦｒａｍｅｓパラメータはＭａｘＦＰＳ−１を超えることはない。

・Ｆｉｅｌｄｓ：ＢａｓｅＵＰＦを掛け、ＢａｓｅＵＰＳで割ったときに、タイムスタンプの成分として加えるべき（秒単位の）時間量を指定する整数パラメータ。Ｆｉｅｌｄｓパラメータは、メディアサンプルフィールドごとに増分され、増分値がＭａｘＦＰＳ−１を超過した場合に０に設定される。

・Ｏｆｆｓｅｔ：ＢａｓｅＵＰＳで割ったときに、タイムスタンプの成分として加えるべき（秒単位の）時間量を指定する整数パラメータ。Ｏｆｆｓｅｔパラメータは、他のパラメータで表される時間と、メディアフィールドサンプルの真の「ウォールクロック」時間との正確な差を指定するのに使用される。

フレームレートカウント補償
フレーム／秒単位のメディアサンプルレートが整数でないときはいつでも（すなわち、ＢａｓｅＵＰＳ／（ＢａｓｅＦＰＦ・ＢａｓｅＵＰＦ）が整数でないときはいつでも）、サンプリングシーケンスが進行するにつれて、Ｈｏｕｒｓ、Ｍｉｎｕｔｅｓ、およびＳｅｃｏｎｄｓパラメータと、Ｆｒａｍｅｓカウントとの間のドリフトに対して調節することが必要となる可能性がある。Ｏｆｆｓｅｔパラメータを使用して、ある量のドリフトを補償することができるが、この目的でＯｆｆｓｅｔパラメータを使用することに伴う２つの問題がある。
・過大なドリフトが累積することが可能な場合、Ｏｆｆｓｅｔパラメータで表すことができる値の範囲を超過する可能性があり、
・過大なドリフトが累積することが可能な場合、通常の「ウォールクロック」時間でのサンプルの適切な近似的な配置としてのＨｏｕｒｓ、Ｍｉｎｕｔｅｓ、およびＳｅｃｏｎｄｓパラメータの通常の解釈が失われ始める
ことである。

ＣｏｕｎｔＣｏｍｐパラメータは、ドリフトに関してカウントプロセスを補償する方法を示す。

蓄積したドリフトを表すのに必要なＯｆｆｓｅｔの値を含むＤｒｉｆｔと呼ばれる変数を定義する場合、カウントプロセスがＣｏｕｎｔＣｏｍｐ変数と関係するので、カウントプロセスを指定することができる。Ｏｆｆｓｅｔの値は、この基本サンプリングタイミングの変更を示すべきでない場合に、Ｄｒｉｆｔと等しく設定することができる。（しかし望むなら、サンプルの異なるタイミングを示すために、ＯｆｆｓｅｔをＤｒｉｆｔ以外のある値に設定することができる。そのうちの２つの例を以下に与える）。

次いで、Ｆｉｅｌｄｓパラメータの増分ごとのカウントプロセスおよびドリフト補償は、以下のＣ＋＋プロセス定義で定義することができる。あるフィールドサンプルをスキップした（送信しなかった）場合、紛失したサンプルからの時間ギャップを示すために、後続のサンプルのＦｉｅｌｄｓパラメータが１つの追加の時間だけ増分される。以下のＣ＋＋コードの断片では、すべてのパラメータが任意長の整数変数を使用して処理されると仮定する（すなわち、パラメータは、表中に指定した範囲を超える値を一時的に取ることができる）

カウント補償の他の同様の方法は、Ｈｏｕｒｓ、Ｍｉｎｕｔｅｓ、Ｓｅｃｏｎｄｓ、およびＦｒａｍｅパラメータで表される時間と、フレームの真の「ウォールクロック」時間との間の蓄積したドリフトの計算に基づく方法であって、蓄積したドリフトの値が少なくともＢａｓｅＦＰＦ・ＢａｓｅＵＰＦの値のあるしきい値を超過したとき、いくつかのフレームカウントをスキップする方法として定義することができる。

例１
ＳＭＰＴＥ非ドロップカウントを用いたＮＴＳＣ（毎秒当たり約２９．９７フレーム）の状況で以下の例を与える。

ＳＭＰＴＥＮＴＳＣ非ドロップタイムコードは、実質的な変更を行うことなく、タイムコードデータ構造フィールドＣｏｕｎｔＣｏｍｐ、Ｈｏｕｒｓ、Ｍｉｎｕｔｅｓ、Ｓｅｃｏｎｄｓ、およびＦｒａｍｅｓで表すことができる。タイムコードの他のパラメータは以下のように指定すべきである。
ＭａｘＤａｙｓ ＝１；
ＣｏｕｎｔＣｏｍｐ＝’００’； （カウント補償なし）
ＢａｓｅＵＰＦ ＝１００１；
ＢａｓｅＵＰＳ ＝３００００（フレームベースのタイムスタンプの場合），ｏｒ６００００（フィールドベースの場合）；
ＢａｓｅＦＰＦ ＝１（フレームベースのタイムスタンプの場合），ｏｒ２（フィールドベースの場合）；
Ｆｉｅｌｄｓ ＝０（フレームベースのタイムスタンプの場合）， ｏｒ０，ｏｒ１ （フィールドベースの場合）；

Ｏｆｆｓｅｔパラメータは、「フレームレートカウント補償」と題するセクションで計算されるドリフトの値に設定すべきである。（当初０に設定され、次いでＳｅｃｏｎｄｓの値が増分するごとに、３０（フレームベース）または６０（フィールドベース）だけ増分される。）
次いで、ＳＭＰＴＥタイムコードは、そのパラメータ値が変更されずに保持されているので、ＣｏｕｎｔＣｏｍｐ、Ｈｏｕｒｓ、Ｍｉｎｕｔｅｓ、Ｓｅｃｏｎｄｓ、およびＦｒａｍｅｓパラメータから直接抽出できることに留意されたい。

一例として、以下について考慮する。

米国のビデオ用システムは、当初は３０フレーム／秒となるように設計されていた。しかし、ビデオ技術の進歩（すなわちカラーテレビジョンの発明）により、これがわずかに変更された。このフレームレートは１０００／１００１倍に変更された。したがって現在では、米国規格のビデオの１秒当たりのフレーム数は、３００００／１００１すなわち〜２９．９７である（したがって、上記で毎秒あたり２９．９７フレームという数字を用いた）。

このことは、カウント中のタイムコード、または時、分、秒、およびフレームの標識が付けられたタイムコードがある場合で、ある時間量が経過した後に単に０−２９を反復的にカウントする場合、タイムコードが表すと思われる時間と、真の時間との間のドリフト、あるいはあるフレームと、ずっと後に到着する別のあるサンプルとの間の時間差が存在することになることを意味する。３０ｆ／ｓ（フレーム／秒）が存在するとき、正確なクロックで測定する真の時間と、タイムコードが時、分、および秒、ならびにフレームによって表している時間との間で累積する著しいドリフトが存在する。

例示的タイムコードカウンタ１００を「秒」列および「フレーム」列で示す図１を考慮する。「秒」列は、秒単位の時間の測度を表す。「フレーム」列は、カウントしたフレームの測度を表す（この例では、話を簡単にするために「時」および「分」を省略した）。フレームカウントで表される真の時間差は、１００１／３００００秒／フレームである。タイムコードは０で開始する（時、分、および秒が０）。フレームカウントは１である。個々のフレームが（例えばタイムコードエンコーダ中を）通過するとき、個々のフレームはカウントされ、それらにタイムスタンプを割り当てることができる。この例での最初のフレームには、（秒，フレーム）に関してタイムスタンプ（ｓ＝０，ｆ＝１）が割り当てられる。次の増分では、秒は依然として０であるが、このときフレームカウントは２である。すなわち（ｓ＝０，ｆ＝２）である。１秒当たりに非整数の数のフレームが存在するので、ドリフトがタイムスタンプ中に累積し始める。

フレームがカウントアップされるとき、フレームカウンタは２９までカウントアップし、次いでｓ＝１およびｆ＝０となるようにロールオーバする。ｓ＝０およびｆ＝０とｓ＝１およびｆ＝０の間の公称時間差が理想的には１秒となるべきであるとみなす。しかしこれは事実ではない。実際には３０個の１００１／３００００秒の増分、すなわち３０００１／３００００秒であり、これは１秒よりわずかに長い。したがって、経過した実際の時間間隔は、タイムスタンプパラメータからわかる時間間隔よりもわずかに長い。したがって、ｓ＝１、ｆ＝０の点は、実際には３００３０／３００００秒の時間が経過した後に生じる。差３０／３００００秒が、オフセットの使用により補償することができるドリフトである。

今説明している実施形態では、フレームカウンタの増分によって示される時間差を理解していることが非常に望ましい。カウントクロック中に存在する毎秒当たりの単位数が理解される。今の場合には、１／３００００秒の単位でカウントを行っている。この値は、上記のＵＰＳ（単位／秒）パラメータで表される。したがって、ＵＰＳパラメータは３００００に設定される。次に、フレームカウンタの増分による、この単位で示される時間差を決定することができる。この値はＵＰＦパラメータで表現される。この例では、ＵＰＦパラメータは１００１である。すなわち、フレームカウンタの増分ごとに、１００１単位の１／３００００秒が経過する。したがって、フレームカウンタの増分は、１００１／３００００秒と関連する。

これらの２つのパラメータが与えられると、フレームカウントにＵＰＦ／ＵＰＳを掛けることによって真の時間差を確認することができる。すなわち、
（フレームカウント）×（ＵＰＦ／ＵＰＳ）＝フレームカウントで示される真の時間差

最初の期間（ｓ＝０）では、秒パラメータを取り、次いでそれに（フレームカウント）×（ＵＰＦ／ＵＰＳ）を加えることによって真の時間を計算することができる。すなわち、
真の時間＝ｓ＋（フレームカウント）×（ＵＰＦ／ＵＰＳ）、ただしｓ＝０

システムが次の秒（すなわちｓ＝１）にロールオーバするとき、この計算はもはや有効ではない。というのは、非整数フレームレートを整数カウンタと関連付けるために、経過した時間差を補償しなければならないからである。この例では、ここでオフセットパラメータが使用される。

図２に、例示的タイムコードカウンタ２００を「秒」列、「フレーム」列、およびオフセット列で示す。以下の例では、オフセットパラメータのために使用する特定の値が、特定の非整数フレームレートと関連する。フレームレートが変化するとき、オフセットパラメータのこの値も変化する可能性がある。したがって、記載の例が特定の環境に対する特定の解決策を構成することを理解されたい。したがって、条件が指定される場合を除き、特許請求の範囲に記載された対象がその特定の例だけを包含すると解釈すべできではない。

オフセットパラメータはやはり同じ単位（単位／秒）であり、その結果同じクロックを参照する。オフセットパラメータは当初０に設定される。秒カウンタがその次の値（すなわち１）にロールオーバするとき、オフセットパラメータは３０だけ増分される。このとき、真の時間を計算するための式は以下のように与えられる。
真の時間＝ｓ＋（フレームカウント×ＵＰＦ＋オフセット）／ＵＰＳ

したがって、ｓ＝１、ｆ（フレームカウント）＝０、およびオフセット＝３０のときに真の時間を計算すると、１＋（０＋３０／３００００）＝３００３０／３００００秒が得られる。次に、オフセットパラメータを加えることにより、従来のカウント方法（ＳＭＰＴＥタイムコード）を使用できるが、サンプルに関連する正確な時間も計算することができる。

オフセットは、真のフレームレートの関数として選択される。真のフレームレートは、一般に毎秒当たり、ある分数の数であることを想起されたい。この逆が、秒／フレームの数である。

上記の例が数秒続くとき、ｓ＝２、ｆ＝０の点に到達する。ここで、オフセットをさらに３０だけ増分し、その結果オフセットは６０になる。事実上は、オフセットは時間がさらに経過するにつれて増加する。しかし各ケースでは、オフセットは、従来のＳＭＰＴＥタイムコードで有するパラメータからサンプルに関連する真の時間を得る方法を知らせることを行っている。

しかし、本発明の技法の応用例は、フレームレートが分数である場合だけに限定すべきではない。具体的には、１秒当たりに整数の数のフレームが存在する場合（例えば２５フレーム／秒である欧州のシステムでは）、ドリフトは存在しないので、オフセットを常に０にすることができる。しかし、オフセットを使用して、ＳＭＰＴＥタイムコードで提示される公称時間とは異なる可能性がある時間を示す能力はまた、例えば元のサンプルのサンプリングがＳＭＰＴＥタイムコードで表される公称時間で示されるタイミングと異なることを示す能力を提供することなど、他の用途も有する。

ＳＭＰＴＥなどの古いスタイルのタイムコードに関連する問題の大部分は、タイムコードに関連するクロックに対する真の時間の位置の明確な理解がないことである。上述の原理を使用して、オフセットパラメータを提供し、個々のフレーム、またはフレームの一部（下記参照）に関連する真の時間を確認するのに使用することができる。

図３は、記載の一実施形態による方法でのステップを記述する流れ図である。この方法は、適切などんなハードウェア、ソフトウェア、ファームウェア、またはそれらの組合せでも実装することができる。図示する例では、この方法はソフトウェアで実装される。

ステップ３００では、１つまたは複数のメディアサンプルを提供する。メディアサンプルは適切などんなメディアサンプルでもよい。加えて、メディアサンプルは適切などんなフォーマットでも提供することができる。例えば、ほんの２つの例を挙げれば、メディアサンプルはフレームまたはフィールドを含むことができる。ステップ３０２では、タイムコードにオフセットパラメータを提供するように構成されるタイムコードエンコーダを提供する。前述のように、オフセットパラメータを使用することは、真の時間の厳密な理解を有さない古いタイムコードを使用することが可能となり、ある意味では、古いタイムコードデータからサンプルに関連する真の時間を確認するのに使用することができるパラメータを追加することが可能となるという点で有利である。

ステップ３０４では、タイムコードエンコーダを使用してメディアサンプルを処理する。このステップは、サンプルのうちの１つまたは複数に、オフセットパラメータを有するタイムコードを提供することによって実施することができる。サンプルを処理した後、ステップ３０６では、受信機にメディアサンプルを供給する。このステップは、適切などんな方式でも実施することができ、必ずしもタイムコードがメディアサンプルに供給されると同時に実施する必要はない。例えば、特定のムービーが最初に生成されるときにタイムコードを供給することができる。ステップ３０６は、ムービーを受信することに関連するであろう様々な実体、すなわちエディタ、ベンダなどにムービーが配布されるときに実施される可能性がある。

ステップ３０８では、オフセットパラメータを伴うタイムコードを有するメディアサンプルを受信する。このステップは、適切などんな方式でも実施することができる。例えば、このステップは、サンプルを編集することに関連するエディタにメディアサンプルを供給することによって実施することができる。ステップ３１０では、オフセットパラメータを使用して、１つまたは複数のサンプルに関連する時間を計算する。計算される時間は、ドリフトのない時間であることが望ましい。

図４は、タイムコード中にオフセットパラメータを供給する一方法を記述する流れ図である。以下に述べる方法は、ある点ではステップ３０４に装飾を施したものである。ステップ４００では、複数のメディアサンプルを提供する。ステップ４０２では、オフセットパラメータを有するタイムコードを提供する。ステップ４０４では、第１メディアサンプルを取得する。次いでステップ４０６は、オフセットパラメータを有するタイムコードをメディアサンプルに組み込む。ステップ４０８では、所定の条件が生じたかどうかを判定する。適切などんな条件も使用することができる。上記の例では、タイムコード中の秒カウンタが循環したかどうかに条件が関連付けられた。以下のある例では、定められた数のフレームが抜かされた場合に、所定の条件が生じる。

ステップ４０８で条件が生じなかったと判定した場合、ステップ４１０では、次のタイムコード（オフセットパラメータを含むことも含まないこともある）を取得し、ステップ４０４に戻る。一方ステップ４０８で条件が生じたと判定した場合、ステップ４１２でオフセットパラメータを調節し、ステップ４１０に戻って次のタイムコードを取得する。処理される特定のタイプのメディアが与えられるならば、オフセットパラメータの調節は適切などんな方式でも行うことができる。上記の例では、所定の量だけオフセットパラメータを増分することによってオフセットパラメータは調節される。ある状況では、オフセットパラメータを減分することが可能である。この例を以下で与える。

オフセットパラメータを調節した後、ステップ４１０では、次のタイムコード（調節したオフセットパラメータを含むことが好ましい）を取得し、ステップ４０４に戻る。

このようにして、複数のメディアサンプルに、そのサンプルに関連する時間測度を確認するのに使用することができるオフセットパラメータを提供することができる。この時間測度は、非整数フレームレートとの関連のために必然的にあるドリフトを含むタイムコードに関連する時間測度よりも正確な時間測度とすることができることが望ましい。

例２
ＳＭＰＴＥドロップカウントを用いたＮＴＳＣ（毎秒当たり約２９．９７フレーム）の状況で以下の例を与える。

米国のＮＴＳＣカラービデオは、２９．９７フレーム／秒で動作する。３０フレーム／秒のプログラム素材と同期させる場合、毎秒当たり余分な０．０３フレームが存在し、毎時間当たり合計３．６秒、すなわち余分なフレームが１０８個となる。同期の問題を引き起こす可能性のあるこのドリフトを低減するために、ドロップフレームタイムコードが開発された。ドロップフレームタイムコードは、タイムコードのシーケンス中のある特定のタイムコードを「抜かす」ことによってこのことを行う。ＳＭＰＴＥドロップフレームタイムコードで使用される調節方法は、１０分毎（００、１０、２０、３０、４０、５０分）を除く各分で２つのタイムコード値を抜かさなければならなかった。一例は、０１：２２：５９：２９から、まず０１：２３：００：００に、次いで０１：２３：００：０１、０１：２３：００：０２と増加するではなく、直接０１：２３：００：０２まで増加することである。コード０１：２３：００：００と０１：２３：００：０１は抜かされる。これにより、かなりの期間にわたってタイムコードが真の時間と非常に近い状態で動作することが可能となる。

ＳＭＰＴＥ ＮＴＳＣドロップフレームタイムコードは、本質的な変更を行わずに、タイムコードデータ構造フィールドＣｏｕｎｔＣｏｍｐ、Ｈｏｕｒｓ、Ｍｉｎｕｔｅｓ、Ｓｅｃｏｎｄｓ、およびＦｒａｍｅｓで表すことができる。タイムコードの他のパラメータは、以下のように指定すべきである。
ＭａｘＤａｙｓ ＝１；
ＣｏｕｎｔＣｏｍｐ＝’０１’（ＳＭＰＴＥドロップフレームカウント）；
ＢａｓｅＵＰＦ ＝１００１；
ＢａｓｅＵＰＳ ＝３００００（フレームベースのタイムスタンプの場合），ｏｒ６００００（フィールドベースの場合）；
ＢａｓｅＦＰＦ ＝１（フレームベースのタイムスタンプの場合），ｏｒ２（フィールドベースの場合）；
Ｆｉｅｌｄｓ ＝０（フレームベースのタイムスタンプの場合），ｏｒ０，ｏｒ１（フィールドベースの場合）；

次いでＯｆｆｓｅｔｓパラメータは、上記のＣ＋＋コードで計算されるドリフトの値に設定すべきである（すなわち、最初は０に設定し、次いで、上記の擬似Ｃコード中に示される時間的位置での２つのフレームカウントドロップと共にＳｅｃｏｎｄｓの値の増分が行われるのでない限り、Ｓｅｃｏｎｄｓの値の増分ごとに３０（フレームベース）または６０（フィールドベース）だけ増分する。上記の場合は、その代わりに１９７２（フレームベース）または３９４４（フィールドベース）だけ減分すべきである）。

ＳＭＰＴＥタイムコードのパラメータ値は変更されずに保持されているので、ＳＭＰＴＥタイムコードを後でＣｏｕｎｔＣｏｍｐ、Ｈｏｕｒｓ、Ｍｉｎｕｔｅｓ、Ｓｅｃｏｎｄｓ、およびＦｒａｍｅパラメータから直接抽出することができる。

次いで、ドロップフレームカウントでのオフセットパラメータを決定することは、抜かした値を補償するためにオフセットパラメータを調節することを除き、本質的には上記の例とほぼ同様に行われる。具体的には、秒カウンタが初期カウント（すなわち２９から０に）にロールオーバするごとに、オフセットは３０だけ増分される。しかし、値のドロップが行われたときにオフセットパラメータを調節するための特定の規則が存在する。具体的には、フレームカウントがスキップされるとき、オフセットが３０だけ増分される代わりに、所定の値、この場合は１９７２だけ減分される。

オフセットパラメータを減分するのに使用される値は、以下のように決定される。秒カウンタがロールオーバしたとき、通常は３０を加える。しかし２つのフレームカウントが抜かされたことを補償しなければならない。これにより、負のオフセットは２００２／３００００となる。したがって、所定の値は２００２−３０＝１９７２である。

例３
ＳＭＰＴＥタイムコードを用いたＰＡＬ（毎秒当たり５０フィールド）の状況で以下の例を与える。ＳＭＰＴＥＰＡＬタイムコードは、本質的な変更を行わずに、タイムコードデータ構造フィールドＣｏｕｎｔＣｏｍｐ、Ｈｏｕｒｓ、Ｍｉｎｕｔｅｓ、Ｓｅｃｏｎｄｓ、およびＦｒａｍｅｓで表現することができる。タイムコードの他のパラメータは、以下のように指定すべきである。
ＭａｘＤａｙｓ ＝１；
ＣｏｕｎｔＣｏｍｐ＝’００’；（カウント補償なし）
ＢａｓｅＵＰＦ ＝１；
ＢａｓｅＵＰＳ ＝２５（フレームベースのタイムスタンプの場合）， ｏｒ ５０ （フィールドベースの場合）；
ＢａｓｅＦＰＦ ＝１（フレームベースのタイムスタンプの場合）， ｏｒ ２ （フィールドベースの場合）；
Ｆｉｅｌｄｓ ＝０（フレームベースのタイムスタンプの場合），ｏｒ０，ｏｒ１（フィールドベースの場合）；

次いでオフセットパラメータは、上記のＣ＋＋コードで記述されるプロセスで計算されるドリフトの値に設定すべきである（この場合常に０）。

次いで、ＳＭＰＴＥタイムコードのパラメータ値は変更されずに保持されているので、ＳＭＰＴＥタイムコードを後にＣｏｕｎｔＣｏｍｐ、Ｈｏｕｒｓ、Ｍｉｎｕｔｅｓ、Ｓｅｃｏｎｄｓ、およびＦｒａｍｅｓパラメータから直接抽出できることに留意されたい。

例４
米国でフィルムが放送されるとき、フィルム素材自体は、一般には毎秒当たり２４フレームで撮影される。しかし放送は、一般には毎秒当たり３００００／１００１フレームで行われる。したがって、ビデオの個々のフィールドを周期的に反復することによってコンテンツを調節する「２：３プルダウン」と呼ばれる（「３：２プルダウン」とも呼ばれる）周知の慣行がある。この実施形態の一目標は、毎秒当たり２４フレームで撮影されたビデオが毎秒当たり３００００／１００１フレーム／秒で放送されるとき、適切に構成された受信機がビデオの各フレームを含む個々のフィールドと、その元のフィルムフレームとの元の関連を確認することができ、かつその個々のフィールドの近似的相対タイミングを確認することができるようにそのビデオをタイムスタンプする方式を提供することである。

例えば図５と、以下の説明について考慮する。ビデオフレームは例えば、一方をＦ１と呼び、他方をＦ２と呼ぶ２つのフィールドを有することができる。ビデオフレームが毎秒当たり２４フレームで撮影されるとき、これらのフィールドはそれぞれ、同時に撮影される（この２つのフィールドを含むフレームは同時に撮影されたからである）。すなわち、元のビデオ中にＦ１およびＦ２に関連するタイムコードがショットとして存在する場合、同じタイムコード値を有するべきである。

しかし２：３プルダウンプロセスは、これらのフィールドが同報通信されるときにこれらのフィールドを所定の方式で反復し、異なる時刻にフィールドを同報通信する。例えば、フィールドＦ１が一般に時刻１で同報通信され、その後に異なる時刻２でフィールドＦ２が同報通信され、その後にさらに異なる時刻３でフィールドＦ１が同報通信される。共通のフレームの個々のフィールドが反復されるとき、これらは、実際には同時にサンプリングされるが、異なる時刻に同報通信されることを銘記されたい。

１００１／１０００倍に伸び、ＮＴＳＣビデオで使用するために「２：３プルダウン」を使用して変換された２４ピクチャ／秒フィルムの各フィールドについてのタイムコードは、オフセットパラメータを介して、ＮＴＳＣフィールド指向同報通信に関する変換後インタレース化タイミングの基礎となるピクチャの、伸びたタイミングと順次サンプリングの性質を示すように生成することができる。

毎秒当たり２４ピクチャのフィルム素材は通常、各ピクチャを走査して、交互の線の２つのフィールドを生成し、４つのピクチャのシーケンスごとに、第２ピクチャおよび第４のピクチャの第１フィールドおよび第２フィールドを送信した後に第１フィールドの送信を反復し、それによって４つのフィルムフレーム２４フレーム／秒ピクチャごとに、３００００／１００１フレーム／秒ビデオの１０個のフィールドに変換される。これにより、全体のタイミングが１０００／１００１倍に遅れ、フィルムをインタレース化ビデオのフィールドとして表示することが可能となる。しかし、どのフィールドがそのサンプリングしたタイミング中で実際に一緒に属しているかを識別することによって、基礎となる非インタレース化ピクチャを回復できることは有用である。

理想的には、特定のフィールドがその他の関連するフィールドと全く同時にサンプリングされたという表示を行うべきである。記載のこの実施形態によれば、ビデオの各フィールドについて、フィルムを同報通信する際にフィールド反復が行われた実際の時間を示す方法がある。このことは、前述のフィールドカウンタおよびオフセットパラメータを使用して行われる。しかし、これを行う方法についての特定の議論を行う前に、以下のことについて考慮する。

人間の目は、ディスプレイが約６０回／秒未満のレートでリフレッシュされる場合、ディスプレイの輝度に応じてフリッカを知覚することができる。表示されるフリッカレートが非常に高速である場合、目にはそれが知覚されない。

動きを表そうとすることと、フリッカを除去しようとすることの間には興味深い兼ね合いがある。テレビジョンの初期の時代には、動きを表示するためにディスプレイを何回か再ペイントしなければならないと定められた。動きを表示するのにディスプレイ全体を再ペイントしなければならないことを回避するために、インターリーブドディスプレイの概念が開発された。この概念は、ある時にビデオの線の半分を表示し、次いで１／６０秒後に他の半分の線を表示するものである。このようにすることにより、閲覧者は動きを正常に知覚し、かつフリッカをなくすることができる。

しかしこの手法を使用すると、１秒当たりに取得する実際の全ピクチャは３０個だけである。より正確には、１秒当たりに６０個の半ピクチャを得ることになる。したがって、ディスプレイ上に垂直方向に表示されるものを見る場合、上端の線を０とカウントし、次の線を１とカウントし、以下同様にカウントする場合、時刻１には線０、２、４、６、８などを見ることになり、次いで１／６０秒後に１、３、５、７、９などを見ることになる。

ビデオのフレームは、ディスプレイ上の線の組全体を含む。ビデオのフィールドは、上記で指摘したように、ディスプレイ上の偶数の線の組、または奇数の線の組のどちらかを含む。一実施形態によれば、単にフレームに関する時間タグではなく、特定の各フィールドに関する時間タグを有する能力を与えるタイムコード表現が提供される。次いで、個々のフィールドの他の共通にサンプリングされるフィールドとは異なる時間で、その個々のフィールドが同報通信されるにもかかわらず、この時間タグを処理して、その個々のフィールドがサンプリングされた実際の時間を提供することができる。このことは、フレームに関するタイムコード表現だけしか提供することができないＳＭＰＴＥ技法に勝る改良である。

個々のフィールドをタイムスタンプする方法の例として、図６について考慮する。図６は、例示的タイムコードカウンタ６００を示す。この特定のタイムコードカウンタでは、図示した構成要素には、フレームカウンタ６０２、秒カウンタ６０４、オフセットカウンタ６０６、およびフィールドカウンタ６０８が含まれる。ＳＭＰＴＥタイムコードカウンタ中に見られる他の標準の構成要素（すなわち時、分）は、この解説では省略した。

この例では、ビデオの１フレーム当たりに２つのフィールドがある。各フィールドは、ビデオ中の偶数の線、または奇数の線のどちらかに関連する。したがって、フィールドカウンタ６０８は、０と１の間をカウントすることによって各フィールドをカウントする。これは、ある点ではフレームカウンタがフレームをカウントする方式と同様である。具体的には、フィールドカウンタ６０８は、フレームのサブユニットとしてフィールドカウントを処理するように構成される。

したがってフィールドベースのタイムコードを構築したい場合、この例では、フレームごとに２つのフィールドが存在する。これは、毎秒当たりの単位数が２倍になることを意味する。各フレームが１００１／３００００秒ではなく、各フィールドがその時間量の半分、すなわち１００１／６００００秒であることを述べる必要があるからである。したがって、フレーム中に、フレームの第１フィールドの後に第２フィールドが１００１／６００００秒生じる、２つのフィールドが存在する。

このことは事実である。再び図６について考慮する。フレームカウンタ６０２が増分するごとに、フィールドカウンタ６０８は２回増分される。すなわち、「０：０：０：０」（すなわち第１行）の後、フィールドカウンタは増分され、その結果タイムコード値は「１：０：０：０」となる。したがって、フィールドに関連する真の時間を計算するために、上記のようにフレームカウンタだけを使用してその時間を計算する代わりに、真の時間は以下の式によって与えられる。
ｔ＝ｓ＋（（ｆｉｅｌｄ＿ｃｏｕｎｔｅｒ＋ＦＰＦ＊ｆｒａｍｅ＿ｃｏｕｎｔｅｒ）ＵＰＦｉｅｌｄ＋ｏｆｆｓｅｔ）／ＵＰＳ

この式は、例えば毎秒当たり３００００／１００１フレームでビデオを受信する受信機を、望ましくは２４フレーム／秒フィルムに関連する元のタイミング情報を抽出するようにプログラムするのに使用することができる。このことは、期間を１００１／１０００倍にわずかに伸ばすことが必要な可能性があるが、オフセット因子のないオペレーションと同様に、送信されるフィールドの規則的な間隔の特性をひずませることはない。

この手法では、フレーム中に整数個のフィールドがあることを認識し、かつフレームカウンタだけではなく、フィールドに関連する真の時間を計算するのに使用することができる情報を提供する各フィールド自体のタイムスタンプを各フィールドが搬送することを可能にする、提供される追加のフィールドカウンタが存在する。

ＳＭＰＴＥ非ドロップカウントを用いるＮＴＳＣでの毎秒当たり２３．９７６フレーム
毎秒当たり２４０００／１００１（約２３．９７６）フレームに伸びたときの、基礎となるピクチャサンプリングタイミングは、基礎となるＳＭＰＴＥ非ドロップタイムコードとして、以下のように示すことができる。
ＭａｘＤａｙｓ ＝１；
ＣｏｕｎｔＣｏｍｐ＝’００’；（カウント補償なし）
ＢａｓｅＵＰＦ ＝２００２；
ＢａｓｅＵＰＳ ＝１２００００；
ＢａｓｅＦＰＦ ＝２；
Ｆｉｅｌｄｓ ＝０ｏｒ１（フィールドベース）；

まず、５成分配列をＺ［５］＝｛０，−２００２，１００１，−１００１，−３００３｝と定義する。次に、Ｏｆｆｓｅｔを、最初に送信するフィールドに関してＤｒｉｆｔ＋Ｚ［０］に設定し、２番目のフィールドに関してＤｒｉｆｔ＋Ｚ［１］、３番目に関してＤｒｉｆｔ＋Ｚ［２］（これは２番目に送信するピクチャの第１フィールドである）、４番目に関してＤｒｉｆｔ＋Ｚ［３］、５番目に関してＤｒｉｆｔ＋Ｚ［４］、６番目に関してＤｒｉｆｔ＋Ｚ［５］、次いで７番目に関してＤｒｉｆｔ＋Ｚ［０］に、８番目に関してＤｒｉｆｔ＋Ｚ［１］などとなる。ただし、Ｄｒｉｆｔは、フィールドごとに、上記のＣ＋＋コードで説明したように計算される（最初は０であり、次いでＳｅｃｏｎｄｓパラメータが増分されるごとに１２０だけ増分される）。

基礎となるピクチャサンプリングタイミングを表すための上記の手法の一例として、図７について考慮する。図７は、毎秒当たり２４フレームで撮影されたが、２：３プルダウンを使用して毎秒当たり３００００／１００１フレームで同報通信されたビデオのグラフィック表現を示す。ｙ軸は、個々のフレームの垂直軸を表し、第１フィールドを表す「トップフィールド」と、第２フィールドを表す「ボトムフィールド」に分割される。ｘ軸は時間軸であり、各フレームからの個々のフィールドが、その３００００／１００１フレーム／秒プルダウン構成で受信されるときの時間を表す。

この例では、フレームＡ、Ｂ、Ｃ、およびＤと呼ぶ、ビデオの４つのフレームがある。描画されるグラフィック表現を得るために、フィルムの１つのフレームを取り（例えばフレームＡ）、「トップフィールド」内の線を送信する。このフィールドを７００で示す。次いで送信されていない線（すなわち「ボトムフィールド」７０２）を送信する。次いで次のフレーム（フレームＢ）を処理し、トップフィールド７０４、次いでボトムフィールド７０６を送信し、次いでトップフィールド７０４を反復することによって３つのフィールドを送信する。次に、フレームＣについてのボトムフィールド７０８を送信し、その後にフレームＣについてのトップフィールド７１０を送信する。最後に、ボトムフィールド７１２、次いでトップフィールド７１４を送信し、次いでボトムフィールド７１２を反復することによって、フレームＤについての３つのフィールドを送信する。

次いでフレームの２つのフィールドと別のフレームの３つのフィールドを交互の、このプロセスを反復する。単一フレームを含むフィールド中の線すべては、同時にサンプリングされる。しかし、これらの線またはフィールドは、別々の時間に送信される。この結果は、例えばムービーをショットとして視聴している場合に通常持続するよりも、２４フレーム／秒フレームが１つおきに長く持続し、残りのフレームが、元のタイミングが示すよりも幾分短い時間表示され、平均してプログラムの全期間がほぼ正しく生成されるということである。

具体的には、このプロセスは、２４フレーム／秒で４フレーム時間（間隔１／２４秒が４つ＝０．１６６６６６）を提供する。このとき、１０個のビデオのフィールド１０＊（１００１／６００００）＝１００１０／６００００＝０．１６６８３３３３を有する。この２つの値はほぼ等しく、１００１／１０００倍しか違わない。

しかし問題がある。具体的には、２：３プルダウン形式のビデオを受信し、それがサンプリングされた元の時間に戻したい場合、上述の実施形態の以前にはそれを行うことができなかった。すなわち、サンプルの実際の同報通信時間（各フィールドが異なるタイムスタンプを有する）を認識しようとするのではなく、サンプルの元のタイミング（例えば、同じフレームの個々のフィールドが同じタイムスタンプを有する）を認識したいのである。

したがって、理想的には、必要なもの、実際には前述の実施形態が供給するものは、各フィールドが異なる時間に送信された場合であっても、フィールドの真のサンプル時間を有し、またはフィールドの真のサンプル時間を確認するのに使用することができる、そのフィールドのそれぞれに関するタイムスタンプである。

この実施形態は、基本的に不正確な１組の時間間隔（すなわち、ビデオの個々のフィールドの同報通信時間と一致する１組の時間間隔）を示すのではなく、１００１／１０００倍だけわずかに伸びた元のフィルムフレームに関連する時間を各フィールドが表すような、フィールドにタイムコードを付加する方法を提供する。したがって、ビデオ受信機は、物事が互いに相対的に正しい時間でサンプリングされるとき、データをその元の形式に戻す方法を認識することができる。

このことを行う方法の例として、以下の式と、図６と、以下の例について考慮する。

ｔ＝ｓ＋（（ｆｉｅｌｄ＿ｃｏｕｎｔｅｒ＋ＦＰＦ＊ｆｒａｍｅ＿ｃｏｕｎｔｅｒ）ＵＰＦｉｅｌｄ＋ｏｆｆｓｅｔ）／ＵＰＳ
この場合、ＵＰＦｉｅｌｄ＝２００２（普通なら計算することになる、各時間の間の中間の時間を表示できる必要があるからである）、ＵＰＳ＝１２００００（２４フレーム／秒と３０フレーム／秒との間の相互作用のため）、およびＦＰＦ＝２である。

第１フィールドでは、ｓ＝０、ｆｉｅｌｄ＿ｃｏｕｎｔｅｒ＝０、ｆｒａｍｅ＿ｃｏｕｎｔｅｒ＝０、およびｏｆｆｓｅｔ＝Ｚ［０］すなわち０である。したがって、予想されるのは時間ｔ＝０である。第２フィールド（第１フィルムフレームの第２フィールド）でも、フィールドが第１フィールドと同時にキャプチャされたので、時間ｔ＝０が予想される。この場合、ｓ＝０、ｆｉｅｌｄ＿ｃｏｕｎｔｅｒ＝１、ｆｒａｍｅ＿ｃｏｕｎｔｅｒ＝０、およびｏｆｆｓｅｔ＝Ｚ［１］すなわち−２００２である。この値を上記の式で用いると、予想されるように、ｔ＝０＋（（１＋２＊０＊２００２−２００２）／１２００００＝０となる。第３フィールド（第２フィルムフレームの第１フィールド）では、時間ｔ＝１００１／２４０００が予想され、次のフィルムフレーム内にあることが示される。この場合、ｓ＝０、ｆｉｅｌｄ＿ｃｏｕｎｔｅｒ＝０、ｆｒａｍｅ＿ｃｏｕｎｔｅｒ＝１、およびｏｆｆｓｅｔ＝Ｚ［２］すなわち１００１である。この値を上記の等式で用いると、予想されるように、ｔ＝０＋（（０＋２＊１）＊２００２＋１００１）／１２００００＝３００３／１２００００＝１００１／２４０００となる。

ＳＭＰＴＥ非ドロップカウントを用いるＮＴＳＣでの毎秒当たり２３．９７６フレーム
毎秒２４０００／１００１（約２３．９７６）フレームに伸びたときの、基礎となるピクチャサンプリングタイミングは、基礎となるＳＭＰＴＥ非ドロップタイムコードとして、以下のように示すことができる。
ＭａｘＤａｙｓ ＝１；
ＣｏｕｎｔＣｏｍｐ＝’０１’；（ＳＭＰＴＥドロップフレームカウント補償）
ＢａｓｅＵＰＦ ＝２００２；
ＢａｓｅＵＰＳ ＝１２００００；
ＢａｓｅＦＰＦ ＝２；
Ｆｉｅｌｄｓ ＝０ｏｒ１（フィールドベース）；

５成分配列Ｚ［５］＝｛０，−２００２，１００１，−１００１，−３００３｝を定義する。Ｏｆｆｓｅｔを、最初に送信するフィールドに関してＤｒｉｆｔ＋Ｚ［０］に設定し、２番目のフィールドに関してＤｒｉｆｔ＋Ｚ［１］、３番目に関してＤｒｉｆｔ＋Ｚ［２］に（これは２番目に送信するピクチャの第１フィールドである）、４番目に関してＤｒｉｆｔ＋Ｚ［３］に、５番目に関してＤｒｉｆｔ＋Ｚ［４］に、６番目に関してＤｒｉｆｔ＋Ｚ［５］に、次いで７番目に関してＤｒｉｆｔ＋Ｚ［０］に、８番目に関してＤｒｉｆｔ＋Ｚ［１］などとなる。ただし、Ｄｒｉｆｔは、上記のＣ＋＋コードで示したように計算される（すなわち、最初は０であり、次いで、Ｓｅｃｏｎｄｓパラメータの増分が時間的位置での２つのフレームカウントドロップと共に行われるのでなければ、Ｓｅｃｏｎｄｓパラメータが増分するごとに１２０だけ増分される。共に行われる場合、その代わりにＤｒｉｆｔが７８８８だけ減分される）。

効果的には、上述の各実施形態は共に、異なるフォーマット（この場合、毎秒当たり３００００／１００１フレーム）に伸ばされたフレームのタイムスタンプを処理して、これらのフィールドの元の互いの関連を、適切な相対サンプリング時間で、元のタイミングを１００１／１０００倍にわずかに調節して提供することができるような、個々のフィールドをタイムスタンプするための方法を提供する。これらの実施形態によれば、共通フレームを含むフィールドは、その実際の同報通信時間に関連する時間値ではなく、同じサンプリングした時間値に評価される。

他のタイムコードに対する設計の改良
上述の実施形態は、他のタイムコードを明らかに改善することができる特徴を有する。この特定の例を以下に与える。

ＳＭＰＴＥタイムコードに対する改良
ビデオ製作業界で広く使用されているタイムコードは、ＳＭＰＴＥタイムコードとして知られており、通常は表３に示すのと同等の方式で表される。ＳＭＰＴＥタイムコードは非常に一般的に使用されているので、ＳＭＰＴＥタイムコードを用いたインターワーキング（ｉｎｔｅｒｗｏｒｋｉｎｇ）は、ビデオ製作環境で不可欠である。

ＮＴＳＣｖｓＰＡＬが０である場合、ＢａｓｅＵＰＦ＝１００１、ＢａｓｅＵＰＳ＝３００００であり、そうでない場合、ＢａｓｅＵＰＦ＝１、ＢａｓｅＵＰＳ＝２５である。ＢａｓｅＦＰＦは暗示的に１であるが、ＳＭＰＴＥタイムコードは、実際には典型的にインタレース化スキャンビデオ（１フレーム当たり２つのインタレース化フィールドを有する）と共に使用される。

ＳＭＰＴＥタイムコードは、真の時間と１：１の対応はなく、したがってＳＭＰＴＥタイムコードと真の時間との間の変換は、正確に表現することができない。ＤｒｏｐＦｌａｇフラグは、カウント補償なしと、前述のＳＭＰＴＥドロップフレームカウント補償との間の選択を示す。

このタイムコードの欠点は、以下のように列挙される。
・このタイムコードは、真の「ウォールクロック」時間と正確に関係付けられず、正確には知られていない時間（時間的解像度が増加したフレームだけにしか知られていない）にスタートし、このタイムコードが増加するにつれて「ウォールクロック」時間に対する「ドリフト」（「ドロップフレーム」カウントを使用することによって低減されるが、解消はされないドリフト）が累積する。

・インタレース化ビデオ環境ではインタレース化ビデオに対する単一フィールド時間増分が主に使用されるにもかかわらず、このタイムコードではそれが指定されない。

・Ｈｏｕｒｓ、Ｍｉｎｕｔｅｓ、Ｓｅｃｏｎｄｓ、Ｆｒａｍｅｓ、およびＤｒｏｐＦｌａｇパラメータのすべてを有するわけではないＳＭＰＴＥタイムコードが「ウォールクロック」時間に直接変換される場合、容易に、かつあいまいさなしに時間測度をＳＭＰＴＥタイムコードに戻すことができない。

・このタイムコードと同等なＢａｓｅＵＰＦおよびＢａｓｅＵＰＳが可能なのは１対の固定値だけであるので、このタイムコードは、あるフレームレートを正確に表すことができない。

・このタイムコードは、主に１フレーム当たり２つのインタレース化フィールドを有するビデオに適用されるにもかかわらず、フィールドカウントパラメータの表現を含まない（かつ、このタイムコードのＢａｓｅＵＰＳは、各フレームの２つのインタレース化フィールドのタイミングを正確に表すのに十分な時間的正確さを有さない）。

一方、上述の設計は、ＳＭＰＴＥタイムコードを変更せずにＳＭＰＴＥタイムコード搬送をすることができると共に、サンプルの時間と真の「ウォールクロック」時間との間の厳密な関係を表すこともできる。上述の設計がＳＭＰＴＥ時間と互換であることにより、上述の設計はビデオ製作業界で広く使用することができ、ＳＭＰＴＥタイムコードを使用することにより生じる時間的なあいまいさも補正される。

ＭＰＥＧ−２：２０００ Ｎ３４３８ Ｄｒａｆｔ Ａｍｅｎｄ．１に対する改良
ＭＰＥＧ−２：２０００ Ｎ３４３８ Ｄｒａｆｔ Ａｍｅｎｄｍｅｎｔ１［［Ｉｎｔｅｒｎａｔｉｏｎａｌ ＳｔａｎｄａｒｄｉｚａｔｉｏｎＯｒｇａｎｉｚａｔｉｏｎ ａｎｄＩｎｔｅｒｎａｔｉｏｎａｌ ＥｌｅｃｔｒｏｔｅｃｈｎｉｃａｌＣｏｍｍｉｓｓｉｏｎ Ｊｏｉｎｔ Ｔｅｃｈｎｉｃａｌ Ｃｏｍｍｉｔｔｅｅ Ｎｕｍｂｅｒ１ Ｗｏｒｋｉｎｇ Ｇｒｏｕｐ Ｎｕｍｂｅｒ １１Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ ｄｏｃｕｍｅｎｔＮ３４３８ Ｖｉｄｅｏ Ｅｌｅｍｅｎｔａｒｙ Ｓｔｒｅａｍ ＳｕｐｐｌｅｍｅｎｔａｌＩｎｆｏｒｍａｔｉｏｎ：Ｊｕｎｅ ２０００］は、表４に示すのと同等なタイムコードフォーマットを含んでいる。

同等なタイムスタンプは以下のように計算される。
ｔ＝（６０・（６０・Ｈｏｕｒｓ＋Ｍｉｎｕｔｅｓ）＋Ｓｅｃｏｎｄｓ＋Ｏｆｆｓｅｔ／２７００００００

このタイムコードに関連する欠点は以下の通りである。
・このタイムコードにはフレームカウンタまたはフィールドカウンタの概念がなく、絶対時間の概念しかない。

・このタイムコードにはフレーム間隔またはフィールド間隔に関連する時間増分の概念がない。

・このタイムコードにはフレームカウンタがないので、フレームのドロップフレームカウントを表すことができない。

・このタイムコードはＳＭＰＴＥタイムコードを直接搬送することができない。

・ＳＭＰＴＥタイムコードがこのフォーマットのタイムスタンプに変換される場合、それをＳＭＰＴＥタイムコードに容易に戻すことができない。

・このタイムコードと同等なＢａｓｅＵＰＳ（定数２７００００００）は固定値を有するので、このタイムコードは、あるフレームレートを正確に表すことができない。

当業者には明らかであろうが、上述の実施形態により、これらの欠点を改善することができる。

ＩＴＵ−Ｔ Ｈ．２６３＋フレームタイムに対する改良
Ｈ．２６３＋［Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｕｎｉｏｎ−ＴｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓＳｔａｎｄａｒｄｉｚａｔｉｏｎ Ｓｅｃｔｏｒ、ＩＴＵ−ＴＲｅｃｏｍｍｅｎｄａｔｉｏｎ Ｈ．２６３ｖｅｒｓｉｏｎ ２：１９９８）では、表５に示すのと同等の方式で時間が表される。

同等なタイムスタンプは以下のように計算される。
ｔ＝Ｆｒａｍｅｓ・（ＣｌｏｃｋＤｖｉｓｏｒ・（１０００＋ＣｌｏｃｋＢａｓｅＡｄｄ１））／１８０００００

このタイムコードに関連する欠点は以下の通りである。
・このタイムコードはＳＭＰＴＥタイムコードを直接搬送しない。

・ＳＭＰＴＥタイムコードがこのフォーマットのタイムスタンプに変換される場合、それをＳＭＰＴＥタイムコードに容易に戻すことができない。

・このタイムコードと同等なＢａｓｅＵＰＳ（定数１８０００００）は固定値を有するので、このタイムコードは、あるフレームレートを正確に表すことができない。

・このタイムコードにはフィールドカウンタがなく、したがってフレームをフィールドに分割するためのタイムスタンプを示すことができない。

当業者は理解するであろうが、上述の本発明の手法により、これらの欠点のうち１つまたは複数を改善することができる。

ＭＰＥＧ−４ビジュアルＶＯＰ時間に対する改良
ＭＰＥＧ−４ビジュアル規格［Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｓｔａｎｄａｒｄｓ Ｏｒｇａｎｉｚａｔｉｏｎ ａｎｄ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｅｌｅｃｔｒｏｔｅｃｈｎｉｃａｌ Ｃｏｍｍｉｓｓｉｏｎ、ＩｎｔｅｒｎａｔｉｏｎａｌＳｔａｎｄａｒｄ １４４９６−２：１９９９］では、表６に示すのと同等の方式でタイムコードを表す。

同等なタイムスタンプは以下のように計算される。
ｔ＝６０・（６０・Ｈｏｕｒｓ＋Ｍｉｎｕｔｅｓ）＋Ｓｅｃｏｎｄｓ＋ＡｄｄＳｅｃ＋Ｏｆｆｓｅｔ）／ＢａｓｅＵＰＳ

ＦｉｘｅｄＲａｔｅＦｌａｇが１であるとき、サンプルの隣接するあらゆる組のタイムスタンプ間の時間差は、ＦｉｘｅｄＩｎｃｒｅｍｅｎｔに等しくなければならない。

このタイムコードに関連する欠点は以下の通りである。
・ＦｉｘｅｄＲａｔｅＦｌａｇが０であるとき、このタイムコードにはフレームカウンタの概念がなく、絶対時間の概念しかない。

・ＦｉｘｅｄＲａｔｅＦｌａｇが１であるとき、このタイムコードは、スキップされたサンプルを示すことができず、サンプルの各対の間に示される時間量に関して柔軟性がない。

・このタイムコードではフレームカウントを掛けるためにＢａｓｅＵＰＦを使用しないので、１秒の間隔中のサンプルタイムスタンプの位置を表すのに必要なビット数が、（例えばＨ．２６３＋設計とは対照的に）ＢａｓｅＵＰＦを使用した場合に必要なビット数よりも大きくなる。ＢａｓｅＵＰＦを代わりに使用した場合、フレーム時間増分を表すのに必要なのは、各サンプルと共に１だけ増分する少数のビットを使用するフレームカウンタまたはフィールドカウンタを有することだけであり、２つの単純な増分により、スキップされたフレームサンプルを示すことができる。

・このタイムコードには、フレーム間隔に関連する時間増分という概念がない。

・このタイムコードはフレームカウンタがないので、フレームのドロップフレームカウントを表すことができない。

・このタイムコードはＳＭＰＴＥタイムコードを直接搬送することができない。

・ＳＭＰＴＥタイムコードがこのフォーマットのタイムスタンプに変換される場合、それをＳＭＰＴＥタイムコードに容易に戻すことができない。

当業者は理解するであろうが、上述の本発明の手法により、これらの欠点のうち１つまたは複数を改善することができる。

タイムコードオブジェクト（ＴＣＯ）ドラフトに対する改良
テレビジョン、オーディオ、およびフィルム製品で使用するためのタイムコードのドラフト仕様に関する「タイムコードオブジェクト」の予備設計が、ビデオ製作業界で配布された［ＢｒｏｏｋｓＨａｒｒｉｓ、Ｐｒｏｐｏｓｅｄ ＳＭＰＴＥＳｔａｎｄａｒｄ Ｓ２２．ＴＣＯｘ１−１９９９Ｎｏｖｅｍｂｅｒ １８、１９９９］。配布された設計はドラフト形式であり、いくつかの誤りが含まれているように思われるが、本質的には表７に示すものと同等であると思われる。

これは、フレームカウンタ、フィールド表示、およびウォールクロック時間の表現を含む。これは、いくつかの特定のサンプリングレートのうちから選択することによるサンプリングレートの指定を用いる。これは、ＳＭＰＴＥ「ドロップフレーム」カウントを使用するか、それとも「１０００日補償カウント」と呼ばれる、１０００日の期間に特定のカウントパターンを使用することによってドリフトエラーを低減する特定のカウント方法を使用するかについての標識を含む。この「１０００日補償カウント」は、ドリフト蓄積の計算を使用しない（その代わり、ＳＭＰＴＥ１２Ｍタイムコードの「ドロップフレーム」方法と同様であるが、より複雑な固定カウントパターンを使用する）特定のカウント方法である。これは、うるう日、うるう秒、および時間帯を処理するためのある特定の用意を含む。これは、単位／秒単位の一般のタイムベースに基づいて、フレームベースのタイムコードを真のウォールクロック時間と関係付けるためにフレームベースのタイムコードをオフセットする方法を含まない。これは、「ウォールクロック」日付パラメータおよび時間パラメータを含むが、（サンプリングレートとカスタマイズ可能な関係を有する単位／秒単位ではなく）ネットワークタイムプロトコル（ＮＴＰ）［ＩｎｔｅｒｎｅｔＥｎｇｉｎｅｅｒｉｎｇ ＴａｓｋＦｏｒｃｅ Ｒｅｑｕｅｓｔ Ｆｏｒ Ｃｏｍｍｅｎｔｓ ｎｕｍｂｅｒ１３０５］単位で表される。ＮＴＰ単位時間では、約２−３２秒の固定測度単位を使用し（すなわちそれに等価なＢａｓｅＵＰＳは、固定値２３２を有する。この数は、３００００や２５などの従来のタイムベースサンプリング単位の整数倍ではない）、したがってこれらの表現では、共通サンプリングレートとは非互換の固定精度を使用し、丸め誤差を含み、サンプリングタイミングには基づかない。これは、時間のＳＭＰＴＥ１２Ｍ表現と、タイムコードのＮＴＰ時間パラメータで表された時間との間のドリフトのために、常にＳＭＰＴＥ１２Ｍタイムコードを変更なしで搬送できるわけではない。このタイムコードオブジェクト設計の欠点には、以下のことが含まれる。

・このタイムコード設計では、選択された特定のサンプリングレートの列挙を使用してサンプリングレートを指定するだけであり、毎秒当たりのＢａｓｅＵＰＳ単位数および１フレーム当たりのＢａｓｅＵＰＦ数を使用して、時間の一般的な表現を指定しない。

・毎秒当たりのカスタム化ＢａｓｅＵＰＳ単位数を使用して、丸め誤差なしにサンプルの真の時間を表すことができない（真の時間は、毎秒当たり固定の増分数を有するＮＴＰ単位でのみ表される）。

・（ＮＴＰを使用した）時間の表現と、従来のＳＭＰＴＥ １２Ｍタイムコードとの間の変換は、明確ではない。ＳＭＰＴＥ １２Ｍタイムコードで見出されるＨｏｕｒｓ、Ｍｉｎｕｔｅｓ、およびＳｅｃｏｎｄｓパラメータと同じ値に直接対応する表現を含まないからである（そのＮＴＰ時間は、従来のＳＭＰＴＥ１２Ｍ時間とＮＴＰ時間との間のドリフトのために、従来のＳＭＰＴＥ １２Ｍタイムコードで見出されるＨｏｕｒｓ、Ｍｉｎｕｔｅｓ、およびＳｅｃｏｎｄｓパラメータの値に直接基づかないからである）。

・このタイムコード設計は、蓄積したドリフトの直接的計算に基づいて補償をカウントする方法を含まない。その代わりに、特定の「１０００日カウント」を使用してドリフトを低減するための、新しく、複雑で、特別なカウント方法を定義する。

当業者は理解するであろうが、上述の本発明の手法により、これらの欠点のうち１つまたは複数を改善する。

カウント補償
別の実施形態によれば、経時的なドリフトをなくするための様々な方法が提供される。第１実施形態を「トップドロップ」カウントと呼び、第２実施形態を「ボトムドロップ」カウントと呼ぶ。

トップドロップカウント
記載の一実施形態によれば、時、分、秒、およびフレームカウントによって表される時間と、サンプルの真の「ウォールクロック」時間との間のドリフトを計算し、過剰なドリフトを防止するために時々最大フレーム番号をスキップすることによって、メディアサンプルフレームカウント時間表現と、真の「ウォールクロック」時間との間のドリフトを補償する方法が提供される。例えば、蓄積したドリフトがフレームカウント増分で表される時間を超過したときはいつでも、最大フレーム番号をスキップすることができる。

図８は、１つのトップドロップカウント方法による方法でのステップを記述する流れ図である。この方法は、適切などんなハードウェア、ソフトウェア、ファームウェア、またはそれらの組合せでも実装することができる。図示する例では、この方法はソフトウェアで実装される。

ステップ８００では、フレームカウント増分に関連する時間値を決定する。メディアサンプルがタイムコード化されるとき、メディアサンプルの各フレームがそれに関連する時間の増分を有する、上記の例を想起されたい。例えば、各フレームカウント増分には、１／２４秒の増分を構成することができる。このステップでは、フレームカウント増分に関連する時間値を決定する。ステップ８０２では、メディアサンプルに関連するタイムコードと、メディアサンプルに関連する真の「ウォールクロック」時間または真のサンプル時間との間の蓄積したドリフトを計算する。ステップ８０４では、蓄積したドリフトがフレームカウント増分で表される時間を超過したとき、最大フレーム番号をスキップする。

例えば、以下について考慮する。経時的なドリフトをなくするために、（前述の）Ｆｒａｍｅｓパラメータは、ある時には０からＭａｘＦＰＳ−１までカウントされ、ある時には０からＭａｘＦＰＳ−２までしかカウントされない（トップカウントを抜かす）。（ＭａｘＦＰＳは上記で定義される）。基本フレームレートが毎秒当たり７．３フレームである場合、ある時には１秒に７フレームカウントされ、ある時には８フレームカウントされる（したがってフレームカウントは、ある時には０から６までカウントされ、ある時には０から７までカウントされることになる）。

ボトムドロップカウント
記載の一実施形態によれば、時、分、秒、およびフレームカウントによって表される時間と、サンプルの真の「ウォールクロック」時間との間のドリフトを計算し、過剰なドリフトを防止するために時々最大フレーム番号をスキップすることによって、メディアサンプルフレームカウント時間表現と、真の「ウォールクロック」時間との間のドリフトを補償する方法が提供される。例えば、蓄積したドリフトがフレームカウント増分で表される時間を超過したときはいつでも、最小フレーム番号をスキップすることができる。

図９は、１つのボトムドロップカウント方法による方法でのステップを記述する流れ図である。この方法は、適切などんなハードウェア、ソフトウェア、ファームウェア、またはそれらの組合せでも実施することができる。図示する例では、この方法はソフトウェアで実装される。

ステップ９００では、フレームカウント増分に関連する時間値を決定する。このステップは、上記のステップ８００と本質的に同じである。ステップ９０２では、メディアサンプルに関連するタイムコードと、メディアサンプルに関連する真の「ウォールクロック」時間または真のサンプル時間との間の蓄積したドリフトを計算する。このステップは、上記のステップ８０２と本質的に同じである。ステップ９０４では、蓄積したドリフトがフレームカウント増分で表される時間を超過したとき、最小フレーム番号をスキップする。

例えば、以下について考慮する。経時的なドリフトをなくするために、（前述の）Ｆｒａｍｅｓパラメータは、ある時には０からＭａｘＦＰＳ−１までカウントされ、ある時には１からＭａｘＦＰＳ−１までしかカウントされない（ボトムカウントを抜かす）。このカウント方法は、上記のトップドロッピング方法と同様であるが、この場合、Ｆｒａｍｅｓパラメータの最高値ではなく、Ｆｒａｍｅｓパラメータ値０がスキップされる。

結論
上述の様々な実施形態により、メディアサンプルに関連するタイムコードで、「真の時間」に対する正確な基準を提供することができる手段が提供される。これらの実施形態は、既存のタイムコード設計のフィールドを変更を行わずに含め、しかし場合によっては設計の機能を向上させるために１つまたは複数の追加のパラメータを追加することにより、その既存のタイムコードパラダイムと互換性を有することができる。加えて、新しいカウント補償方法の形態で改良を達成することができる。

本発明を構造的特徴および／または手順に特有の術語で説明したが、頭記の特許請求の範囲で定義される本発明は、説明した特定の特徴またはステップに必ずしも限定されないことを理解されたい。むしろ、この特定の機能およびステップを、特許請求の範囲に記載された本発明を実施する好ましい形態として開示する。

Claims (5)

1. メディアサンプルを処理する方法であって、
   １つまたは複数のメディアサンプルを提供するステップであって、前記１つまたは複数のメディアサンプルのうちの個々のメディアサンプルがタイムコードを有するステップと、
   前記メディアサンプルのうちの１つまたは複数に関連する表現時間を、以下の式
   時間＝ｘ＋（フレームカウント＊ＵＰＦ＋オフセット）／ＵＰＳ
   に従って計算するステップであって、上式で、
   ｘは、前記メディアサンプルに関連する時間の測度であり、前記メディアサンプルのタイムコードから確認され、
   「フレームカウント」は、前記メディアサンプルのフレーム番号に関連する値であり、
   「ＵＰＦ」は、フィールドカウント増分ごとに加えられる基本時間単位数を含み、
   「オフセット」は、前記メディアサンプルに関連する前記タイムコードによって表される時間と、表現時間との差を指定し、
   「ＵＰＳ」は、単位時間当たりのタイムベース中の基本時間単位数を含む
   ステップと
   を備えたことを特徴とする方法。
2. 請求項１記載の方法において、「ｘ」は、全秒数として、あるいは時、分、および秒を表すパラメータとしてＳＭＰＴＥタイムコードで表される全秒数によって指定される秒数に関連することを特徴とする方法。
3. 請求項１記載の方法において、「オフセット」は、前記メディアサンプルの真のフレームレートの関数として選択されることを特徴とする方法。
4. 請求項３記載の方法において、前記真のフレームレートは、単位時間当たり分数の数のフレームを含むことを特徴とする方法。
5. 請求項４記載の方法において、前記単位時間は秒を含むことを特徴とする方法。

Images