コンテンツ参照識別子

コンテンツ参照識別子( CRID ) は、 TV-Anytimeフォーラムによる標準化作業から生まれた概念です。これは、 World-Wide Webで使用されるUniform Resource Locator (URL)の概念とほぼ一致しています。

ブロードキャスト ストリーム内のコンテンツの単位は、 Web ページがWeb 上でグローバルに一意の URL によって参照されるのと同じように、グローバルに一意の CRID によって参照できます。

CRID の概念により、コンテンツの場所に関わらず、つまり、特定の放送情報 (時間、日付、チャンネル) や、ストリーミング サービスやインターネット サーバーからのファイルのダウンロードなど、ネットワーク経由でコンテンツを取得する方法を知らなくても、コンテンツを明確に参照できるようになります。

受信機は、これらの明確な参照を解決する、つまり、コンテンツを取得するためにそのコンテンツの場所を取得できる特定のデータに変換できる必要があります。これにより、その情報を知らなくても、さらには録画するコンテンツの期間を事前に知らなくても、録画プロセスを実行できます。クリックするだけで完全なシリーズ、まだスケジュールされていないプログラム、特定の基準でグループ化された一連のプログラムなど...

このフレームワークにより、特定のコンテンツへの参照 (CRID) と、そのコンテンツを取得するために必要な情報 (「ロケーター」と呼ばれる) を分離できます。各 CRID は、同じコンテンツの異なるコピーを表す 1 つ以上のロケーターにつながる場合があります。それらは、異なるチャンネルや日付で放送された、または異なる価格の同一のコピーである可能性があります。また、フォーマットや品質などの異なる技術的パラメータを持つ個別のコピーである可能性もあります。

また、CRID の解決プロセスの結果として別の CRID (たとえば、別のオペレータによって割り当てられた代替識別子を持つ別のネットワークでの参照) や CRID のセット (たとえば、元の CRID が TV シリーズを表す場合、解決プロセスによって各エピソードを表す CRID のリストが生成される) が提供される場合もあります。

上記から、特定のコンテンツが多くのグループ（それぞれが独特の品質で定義される可能性がある）に属することができる場合、多くの CRID が同じコンテンツを持つ可能性があると結論付けることができます。つまり、複数の CRID が同じロケータに解決される可能性があります。

CRID は、特定のコンテンツに対する普遍的、一意、排他的な識別子ではありません。CRID は、それを作成した機関、解決サービス プロバイダー、コンテンツ プロバイダーと密接に関連しているため、同じコンテンツでも、使用される分野に応じて異なる CRID を持つ場合があります (たとえば、コンテンツを放送する権利を持つテレビ事業者ごとに異なる CRID を持つ場合があります)。

CRID は URL とほぼ同じように指定されます。実際、CRID はいわゆるURIです。通常、コンテンツ作成者、放送局、または第三者は、DNS名と製品固有の名前を組み合わせて、グローバルに一意の CRID を作成します。つまり、CRID の構文は次のようになります。

crid://authority/data

権限フィールドは、 CRID を作成したエンティティを表し、その形式は DNS 名の形式です。データフィールドは、権限スコープ内のコンテンツを明確に識別する文字列を表します (権限自体によって割り当てられた文字列です)。

例えば、BBCが中国オリンピックの全番組のCRIDを作成したいとします。次のようなものになるかもしれません。

参照：://bbc.co.uk/olympics/2008/

これはグループ CRID、つまりコンテンツのグループを表す CRID になります。次に、女子砲丸投げ決勝などの特定のイベントを参照するには、メタデータ内で次のものを使用します。

参照：http://bbc.co.uk/olympics/2008/final/shotput/women

現在、^{[いつ? ] 4 種類の CRID が、一部の}一方向テレビ ネットワークで主要な役割を果たしています。プログラム CRID、シリーズ CRID、グループ CRID、および推奨 CRID です。CRID の最も重要な用途の 1 つは、最新のデジタル ビデオ レコーダー ( DVR、PVR )のいわゆるシリーズ リンク レコーディング機能 (SL) です。

一方、ロケータは、トランスポート ストリーム経由で受信されるか、ローカル ストレージにあるか、インターネット サーバーからファイルとしてダウンロードされるか、ストリーミング サービス経由で受信されるかに関係なく、受信機が特定のコンテンツを見つけて取得するために必要なすべての情報を含む文字列です。たとえば、DVB ロケータには、トランスポート ストリーム内の特定のコンテンツを識別するために必要なすべてのパラメータ (ネットワーク、トランスポート ストリーム、サービス、テーブル、イベントの識別子など) が含まれます。

TV-Anytime で確立されたロケータの形式は非常に一般的かつシンプルで、次の形式に対応します。

[トランスポートメカニズム]:[特定のデータ]

ロケータのフォーマットの最初の部分 (トランスポート メカニズム) は、各メカニズム (トランスポート ストリーム、ローカル ファイル、HTTP インターネット アクセスなど) に固有の文字列である必要があります。2 番目の部分は、特定のトランスポート メカニズムの範囲内でのみ一意である必要があり、メカニズム自体の規制を担当する組織によって標準化されます。たとえば、この標準に従うネットワークのトランスポート ストリーム内のコンテンツを識別する DVB ロケータは次のようになります。

dvb://112.4a2.5ec;2d22~20121212T220000Z—PT01H30M

これは、アドレス「112.4a2.5ec」（ネットワーク「112」、トランスポート ストリーム「4a2」、サービス「5ec」）で識別される DVB ネットワークで利用可能なチャンネルで、2012 年 12 月 12 日午後 10 時に 90 分間放送されるコンテンツ（文字列「2d22」で識別される）を示します。

位置解決プロセスとは、特定のコンテンツの CRID から始めて、そのコンテンツの 1 つまたは複数のロケータを取得する手順です。CRID の解決は、1 つまたは複数のロケータにすぐにつながる直接的なプロセスである場合もあれば、最初に 1 つまたは複数の中間 CRID が返され、最終的に 1 つまたは複数のロケータを取得するために同じ手順を実行する必要がある場合もあります。

この手順にはいくつかの情報要素が関係しており、その中にはそれぞれ解決権限レコード (RAR) と ContentReferencingTable という 2 つの構造があります。これらを繰り返し参照すると、受信者は CRID から 1 つまたは複数のロケータに移動し、コンテンツを取得できるようになります。

RAR テーブル

RAR テーブルは、CRID を送信する各機関の受信者に、対応する解決サービス プロバイダーに関する情報を提供する 1 つまたは複数のデータ構造です。特に、各機関からの CRID を解決するために情報を提供するために使用されるメカニズムに関する情報を提供します。つまり、各機関には、受信者がその特定の機関の CRID を解決するためにどこに行く必要があるかを示す 1 つまたは複数の RAR レコードが存在する必要があります。

たとえば、図のレコード (TV-Anytime で定義された XML スキーマに従って XML 構造で表現) には、「tve.es」と呼ばれる機関があり、その解決サービス プロバイダーはエンティティ「rtve.es」であり、URL「http://tva.rtve.es/locres/tve」で利用可能であり、これはその URL に解決情報があることを意味します。

これらの RAR レコードは、TV-Anytime 仕様にとって重要ではない不定形式で受信機に届きます。TV-Anytime 仕様は、受信機が接続されているネットワークの特定の転送メカニズムに依存します。配信ネットワークを規制する各標準ファミリ (DVB、ATSC、ISDB、IPTV など) では、このような手順が事前に定義されており、これらの標準に従って認定されたデバイスによって使用されます。

ContentReferencingTable テーブル

位置解決プロセスに関係する 2 番目の構造は、コンテンツの CRID が指定されると、受信者がそのコンテンツのインスタンスにアクセスできるようにする 1 つまたは複数のロケータ、または解決プロセスを進めることができる 1 つまたは複数の CRID を返す適切な解決テーブルです。

この図は、TV-Anytime で定義された XML スキーマの仕様に準拠した XML ドキュメントである、この 2 番目の構造の例を示しています。この中には、各解決ケースを説明する情報を構造化する複数のセクション (<Result> 要素) が含まれています。

最初のものは、「フレンズ」シリーズの複数のエピソード (2 つ) を含むグループ コンテンツに対応する CRID (crid://tv.com/Friends/all) がどのように解決されるかを宣言します。解決プロセスの結果として、2 つのエピソードのそれぞれに対応する 2 つの新しい CRID が提供されます。

2 番目の <Result> 要素は、第 1 シーズンの最初のエピソードの CRID を解決します。解決プロセスの結果は、2 つの DVB ロケータです。「acquire」属性の値が「any」であることは、いずれも有効であることを示します (2 番目は 1 週間後に放送される繰り返しです)。

3 番目の <Result> 要素は、2 番目のエピソードに関する情報を提供します。これは、まだ解決できないこと (「まだ解決できません」という値を持つ「ステータス」属性) を示しており、解決情報の要求を繰り返す必要がある日付を示しています。

プロセス

ユーザーが特定のコンテンツ（対応する CRID によって識別される）を選択して何らかのアクションを実行すると、受信機は位置解決プロセスを開始し、コンテンツのコピーにアクセスできるようにする特定の位置情報を取得します。

この手順は、主に受信者の接続性に依存します。受信者がブロードキャスト チャネル経由でのみ情報を受信できる単方向ネットワークと、受信者が外部 (通常はインターネット アクセス) と通信できる戻りチャネルもある双方向ネットワークを基本的に区別することができます。

放送チャンネルにのみ接続された受信機の場合、解像度情報はそのチャンネルから直接取得されるか、既存のローカル ストレージ システムで何らかの方法で利用できる必要があります。CRID を選択した後、受信機が最初に行う必要があるのは、解像度テーブルがどこにあるかに関する情報を確認することです。そのためには、選択した CRID の権限に関連付けられた RAR レコードを見つける必要があります。

その機関に対応する RAR レコードが見つかると、受信者は URL フィールドを参照して、解決情報を取得するためにアクセスする場所 (または、この場合は、リッスンする場所) を知ることができます。

そのアクセス ポイントを通じて受信される情報は、参照された各 CRID のメッセージ (たとえば、ContentReferencingTable の <Result> 要素) で構成されます。

CRID をさらにグローバルに利用できるようにするために、IETF はWeb 上での CRID の使用を規定するコメントの要求を公開します。これにより、現在のブラウザが Web サーバーを検索して CRID でコンテンツを要求しているのと同様に、消費者向けデバイスがコンテンツ プロバイダー サーバーに接続できるようになります。

2005 年 5 月に、この作業の開始として、Informational RFC No 4078 が公開されました。

長期的な目標は、携帯電話、PDA、デジタルテレビ 受信機、その他の消費者向けデバイスが、放送ストリームまたはIP ネットワーク経由でコンテンツを取得するために CRID を使用できるようにすることです。

• BBC 番組識別子

• RFC 4078 (PDF) 2011 年 10 月 27 日にアクセス
• RFC 4078 (TXT) 2011年10月27日アクセス
• ETSI TS 102 822-2 V1.4.1 (2007–11)、19 ページ、セクション 5:「TV-Anytime コンテンツ参照シナリオ」、2012 年 12 月 3 日にアクセス
• ETSI TS 102 822-4 V1.7.1 (2012–12)、13 ページ、セクション 8:「CRID」、2013 年 1 月 9 日にアクセス
• ETSI TS 102 323 V1.5.1 (2012-01)、27 ページ、セクション 6:「DVB ネットワークの CRID およびその他の URI」、2012 年 3 月 1 日にアクセス