リモート再生 API

W3C 勧告候補草案

この文書の詳細
このバージョン:
https://www.w3.org/TR/2024/CRD-remote-playback-20240430/
最新の公開バージョン:
https://www.w3.org/TR/remote-playback/
最新の編集者草案:
https://w3c.github.io/remote-playback/
履歴:
https://www.w3.org/standards/history/remote-playback/
コミット履歴
実装報告:
https://www.w3.org/wiki/Second_Screen/Implementation_Status#Remote_Playback_API
編集者:
Mark Foltz (Google)
元編集者:
Mounir Lamouri (Google)
Anton Vayvod (Google)
フィードバック:
GitHub w3c/remote-playback (プルリクエスト, 新しい issue, 未解決の issue)
テストスイート
GitHub web-platform-tests/remote-playback
w3c-test.org/remote-playback/

概要

この仕様は、HTMLMediaElement を拡張し、Web ページからメディアのリモート再生を制御できるようにする API を定義します。

この文書のステータス

このセクションでは、この文書の公開時点におけるステータスについて説明します。現在の W3C 公開文書の一覧およびこの技術報告書の最新版は、 https://www.w3.org/TR/ にある W3C 技術 報告書索引で確認できます。

この文書は、Second Screen Working Group によって、 勧告トラックを使用した 勧告候補草案として公開されました。

この文書は、外部のプレゼンテーション型ディスプレイに Web コンテンツを表示してきたグループの経験に基づいており、適切な場合には Presentation API 仕様のパターンおよび設計上の考慮事項を 再利用しています [PRESENTATION-API]。

この文書は依然として作業中であり 変更される可能性がありますが、ワーキンググループは API の表面仕様は 安定していると考えています。issue トラッカーに記載されている残りの issue の大部分は、 Issue #41 を除き、 現段階では軽微なものとみなされています。

Issue #41 では、リモート再生デバイスがサポートすることを期待される メディア再生機能の一式について議論しています。グループは、これらの機能を リモート再生中に使用した際の相互運用性の問題を特定するため、 開発者からのさらなるフィードバックと実装経験を求め、受け取ったフィードバックに基づいて 仕様をさらに明確化します。

その他の issue や懸念事項については、バグを報告するか、 メーリング リストにメールを送信できます。誤字などの小規模な編集上の変更については、プルリクエストを 送信していただけると助かります。

ワーキンググループは、すべての方にこの文書のレビューを呼びかけており、 W3C の関連グループと協力して、 アクセシビリティ、国際化、プライバシー、セキュリティ、および技術 アーキテクチャ原則に関する水平レビューを実施します。

リスクありと特定された機能はありません。

Second Screen Working Group は、勧告候補期間中に Remote Playback API のテストスイートを開発し、 実装報告書を作成します。この仕様が 勧告案へ進むには、勧告候補の終了 基準セクションに詳述されているとおり、各機能について独立した相互運用可能な実装が 2 つ実証されなければなりません。

勧告候補としての公開は、 W3C およびそのメンバーによる承認を意味するものではありません。勧告候補草案には、 ワーキンググループが後続の勧告候補スナップショットに 含めることを意図している、以前の勧告候補からの 変更が統合されています。

これは草案文書であり、いつでも他の 文書によって更新、置換、または廃止される可能性があります。この文書を 作業中の文書以外のものとして引用することは適切ではありません。

この文書は、 W3C 特許 ポリシーの下で活動するグループによって作成されました。 W3C は、このグループの成果物に関連して行われた 特許開示の公開一覧 を維持しています。そのページには、 特許を開示するための手順も記載されています。個人が、 必須クレーム を含むとその個人が考える特許について実際の 知識を有する場合は、 W3C 特許ポリシーのセクション 6に従って その情報を開示しなければなりません。

この文書は、 2023年11月3日版 W3C プロセス文書に準拠します。

1. 適合性

非規範的と明示されているセクションに加え、この 仕様に含まれるすべてのオーサリングガイドライン、図、例、および注記は非規範的です。この仕様のそれ以外のすべては規範的です。

この文書におけるキーワード MAYMUSTMUST NOTRECOMMENDED、および SHOULD は、 ここに示すようにすべて大文字で表記されている場合に限り、 BCP 14 [RFC2119] [RFC8174] に記載されているとおりに解釈されるものとします。

この仕様では、単一の 製品、すなわち、この仕様に含まれるインターフェイスを実装する ユーザーエージェントに適用される適合基準を定義します。

ECMAScript を使用してこの仕様で定義される API を公開する実装は、 Web IDL 仕様で定義されている ECMAScript バインディングと整合する方法でそれらを実装しなければなりません [WEBIDL]。

2. はじめに

このセクションは非規範的です。

この仕様は、接続されたテレビ、プロジェクター、音声専用スピーカーなどの リモート再生デバイスを Web から利用可能にすることを目的としており、有線 (HDMI、DVI、または類似のもの)および無線技術(Miracast、 Chromecast、DLNA、AirPlay、または類似のもの)を使用して接続される再生デバイスを考慮しています。

画面サイズが限られているデバイスや音量の小さいスピーカーでは、 たとえば会議室の同僚のグループや、自宅の友人や家族など、 より多くの人に向けてメディアコンテンツを再生する能力が不足しています。 外部の、より大きな画面やより大きな音量を持つ リモート再生 デバイスでメディアコンテンツを再生することで、再生されるメディアの 知覚品質とインパクトを向上させることができます。

本質的に、この仕様により、 閲覧 コンテキストとして機能するページが、選択された リモート再生デバイス上で 特定のメディア要素のリモート再生を開始および制御できるようになります。 リモート処理をどのように開始および制御するかは UA に委ねられており、 多種多様な方法で接続できる リモート再生デバイスを使用できるようにしています。 たとえば、リモート再生 デバイスが HDMI または Miracast を使用して接続されている場合、閲覧 コンテキストとして機能する同じ UA がリモートメディアをレンダリングします。ただし、 同じデバイス上でメディアを再生する代わりに、外部の リモート 再生デバイスを使用するためにオペレーティングシステムが提供する任意の 手段を使用できます。この場合、閲覧 コンテキスト とメディアプレーヤーの両方が同じ UA 上で動作し、オペレーティングシステムを 使用してプレーヤーの出力を リモート再生デバイスへルーティングします。 これは一般に メディア ミラーリングのケースと呼ばれます。この仕様は、 このような方法で接続される リモート再生デバイスに要件を課しません。

リモート再生デバイスがメディアを再生でき、 閲覧 コンテキストと通信できるものの、メディアを取得できない場合、 閲覧 コンテキストはメディアデータを取得し、 レンダリングのために リモート再生デバイスへ渡す必要があります。これは 一般に メディアリモーティングのケースと呼ばれます。

リモート再生デバイスがメディアを取得して再生でき、 閲覧 コンテキストと通信できる場合、閲覧 コンテキストはリモート処理されるメディアを取得またはレンダリングする必要はありません。この 場合、UA は、メディアソースなどの必要なデータを渡すことにより、リモート再生 デバイスにメディア自体を再生するよう要求するプロキシとして機能します。 これは一般に メディア フリンギングのケースと呼ばれます。このようなディスプレイへの接続方法は、 リモート再生デバイスが実装することを選択できる、これらの種類のメッセージを配信するための 標準プロトコルを定義することで、将来的に 拡張できる可能性があります。

ここで定義される API は、上記のいずれかの 方法で リモート再生デバイスに接続する UA で使用することを意図しています。

3. ユースケースと要件

このセクションは非規範的です。

この仕様のユースケースと要件は、 こちらから利用できる別の文書にまとめられています。

4.

このセクションでは、Remote Playback API の主要な 機能の使用法を示すコード例を紹介します。これらの例では、 player.html はリモート再生を制御するプレーヤーページを実装し、 media.ext はリモートで再生されるメディアファイルです。 ページとメディアの両方は https://example.org ドメインから提供されます。詳細については、 コード例内のコメントを参照してください。

4.1 リモート再生デバイスの利用可能性を監視する例

<!-- player.html -->
<!-- リモート再生をサポートするカスタムコントロール付きの video 要素。 -->
<video id="videoElement" src="https://example.org/media.ext" />
<button id="deviceBtn" style="display: none;">デバイスを選択</button>
<script>
  // 少なくとも 1 台のリモート再生デバイスが利用可能な場合、「デバイスを選択」ボタンを表示します。
  const deviceBtn = document.getElementById("deviceBtn");
  const videoElem = document.getElementById("videoElement");

  function availabilityCallback(available) {
    // デバイスの利用可能性に応じて、デバイス選択ボタンを表示または非表示にします。
    deviceBtn.style.display = available ? "inline" : "none";
  }

  videoElem.remote.watchAvailability(availabilityCallback).catch(() => {
    // 利用可能性の監視はプラットフォームでサポートされていないため、
    // リモート再生デバイスの検出は remote.prompt() が呼び出された後にのみ行われます。
    // 簡単にするため、デバイスが利用可能であるものとします。または、
    // ボタンに第 3 の状態を実装することもできます。
    deviceBtn.style.display = "inline";
  });
</script>

4.2 動画のリモート再生を開始する例

<!-- player.html -->
<script>
  deviceBtn.onclick = () => {
    // ユーザーにリモート再生デバイスを選択するよう要求します。
    videoElem.remote.prompt()
      // UI を更新し、接続状態を監視します。
      .then(updateRemotePlaybackState);
      // それ以外の場合、ユーザーが選択 UI をキャンセルしたか、画面が見つかりませんでした。
  };
<script>

4.3 リモート再生状態の変化を監視する

<!-- player.html -->
<script>
  // リモート再生はユーザーエージェントによって開始される場合があるため、
  // UI を同期するために初期状態を確認します。
  if (videoElem.remote.state == "disconnected")
    switchToLocalUI();
  else
    switchToRemoteUI();

  videoElem.remote.onconnecting = switchToRemoteUI;
  videoElem.remote.onconnect = switchToRemoteUI;
  videoElem.remote.ondisconnect = switchToLocalUI;

  // 'connecting' と 'connected' の両方の状態を処理します。複数回呼び出しても
  // 何も行われません。
  function switchToRemoteUI() {
    // 状態が 'connecting' または 'connected' であることをユーザーに示します。
    // たとえば、コントロールだけが必要なため、video 要素を非表示にします。
    videoElem.style.display = "none";

    // リモート再生デバイスの利用可能性の監視を停止します。
    videoElem.remote.cancelWatchAvailability();
  };

  function switchToLocalUI() {
    // video 要素を表示します。
    videoElem.style.display = "inline";
    // デバイスの利用可能性の監視を再開します。
    videoElem.remote.watchAvailability(availabilityCallback);
  };
<script>

5. API

5.1 共通の慣用表現

ローカル 再生デバイスとは、閲覧 コンテキストが実行されているデバイスと、そのデバイスが備えるデフォルトの映像/音声出力 を合わせたものです。

注記
ローカル再生デバイスには、 外部ディスプレイやスピーカー/ヘッドフォンのような追加の出力が存在する場合があります。 使用する出力の切り替えがユーザーエージェントの外部で システムレベルで行われる限り、この仕様の目的上、その再生は ローカル 再生デバイス上で行われるものとみなされます。

リモート再生デバイス とは、ローカル再生デバイス以外で、 閲覧 コンテキストがメディアの再生に使用できる任意のデバイスです。

メディア 要素の状態とは、単一の メディア 要素について、 ページおよび/またはユーザーがユーザーエージェントの実装を通じて観測できる すべてのプロパティの集合です。便宜上、この仕様によって新たに導入される プロパティは メディア要素の状態 の一部とはみなしません。

たとえば、paused 属性や、メディア要素のデフォルトコントロール上で その状態を反映する一時停止/再開ボタンは、 メディア要素の状態の一部となります。

ローカル 再生状態とは、特定の メディア要素ローカル再生デバイス上で再生するための メディア要素の状態のユーザーエージェントによる実装です。

リモート 再生状態とは、特定の メディア要素を 特定の リモート再生デバイス上で再生するための メディア要素の状態のユーザーエージェントによる実装です。

注記

良好なユーザー体験のためには、メディア要素の 状態が、stateの変化時に予期せず変化しないことが重要です。 また、リモート 再生状態メディア要素の状態と同期していることも重要です。これにより、 リモート再生デバイス上でメディアが一時停止された場合、 ユーザーとページの双方から一時停止しているように見えます。

この仕様で言及されるタスクの タスク ソースは、 メディア要素イベントタスクソースです。

5.2 RemotePlayback インターフェイス

WebIDL[Exposed=Window]
interface RemotePlayback : EventTarget {
  Promise<long> watchAvailability(RemotePlaybackAvailabilityCallback callback);
  Promise<undefined> cancelWatchAvailability(optional long id);

  readonly attribute RemotePlaybackState state;

  attribute EventHandler onconnecting;
  attribute EventHandler onconnect;
  attribute EventHandler ondisconnect;

  Promise<undefined> prompt();
};

enum RemotePlaybackState {
  "connecting",
  "connected",
  "disconnected"
};

callback RemotePlaybackAvailabilityCallback = undefined(boolean available);

RemotePlayback オブジェクトにより、ページは リモート再生デバイスの利用可能性を検出し、 接続し、そのデバイス上での再生を制御できます。

RemotePlaybackState 列挙型は、リモート再生デバイスへの接続で取り得る 状態を表します。

RemotePlaybackAvailabilityCallback は現在の リモート再生デバイスの利用可能性を返します。

5.2.1 リモート再生デバイスの利用可能性の監視

RemotePlaybackAvailabilityCallback は、対応する メディア要素について ページが リモート再生デバイスの利用可能性を取得する方法です。ユーザー エージェントが、prompt() に対する保留中の要求なしに、 バックグラウンドで 利用可能な リモート再生デバイスのリストを監視できる場合、以下で定義する RemotePlaybackAvailabilityCallback の動作をユーザーエージェントは MUST 実装しなければなりません。それ以外の場合、 watchAvailability() が返す Promise は NotSupportedErrorMUST 拒否されなければなりません。

5.2.1.1 利用可能性コールバックの集合

ユーザーエージェントは、各 メディア要素watchAvailability() メソッドを通じて登録された 利用可能性 コールバックの集合MUST 追跡しなければなりません。各 RemotePlayback オブジェクトの 利用可能性 コールバックの集合は、初期状態では空の、次のタプルの集合として表されます。 (callbackId, callback)

  1. callbackId は、特定の 閲覧 コンテキスト内で watchAvailability() が返すすべての id の中で一意な正の整数です。
  2. callbackRemotePlaybackAvailabilityCallback オブジェクトです。

メディア 要素につき RemotePlayback オブジェクトは 1 つだけ存在するため、メディア 要素利用可能性 コールバックの集合は、その要素の remote プロパティによって参照される RemotePlayback オブジェクトの 利用可能性 コールバックの集合と同じ集合です。

閲覧 コンテキストが認識しているすべての RemotePlayback オブジェクトの すべての 利用可能性 コールバックの集合を結合した集合を、グローバルな 利用可能性コールバックの集合と呼びます。

5.2.1.2 利用可能なリモート再生デバイスのリスト

ユーザーエージェントは 利用可能なリモート 再生デバイスのリストMUST 保持しなければなりません。このリストには リモート 再生 デバイスが含まれ、実装固有の検出メカニズムに基づいて 構成されます。これは、利用可能なリモート再生 デバイスのリストを監視するアルゴリズムの最新の結果に設定され、 アルゴリズムがまだ実行されていない場合は空のリストに 設定されます。

ユーザーエージェントは、たとえばプラットフォームまたは電力 消費上の制約のために、利用可能なリモート再生デバイスのリストを 監視するアルゴリズムを継続的に実行することを MAY サポートしない場合があります。 この場合、watchAvailability() が返す Promise は NotSupportedErrorMUST 拒否されなければならず、 グローバルな利用可能性 コールバックの集合は空になり、利用可能な リモート再生デバイスのリストを監視するアルゴリズムは、 リモート再生を開始するアルゴリズムの一部としてのみ実行されます。

グローバルな 利用可能性コールバックの集合が空でない場合、 ユーザーエージェントは 利用可能な リモート再生デバイスのリストを継続的に MUST 監視しなければなりません。これにより、ページは 登録されたコールバックを通じて受け取った最後の値を追跡し、 利用可能なデバイスが存在する場合にのみリモート再生を提供できます。

注記

ユーザーエージェントは、 省電力の非機能要件を満たすため、可能な場合には 利用可能な リモート再生デバイスのリストを監視しないことが期待されます。たとえば、 グローバルな 利用可能性コールバックの集合が空の場合や、空でない 利用可能性コールバックの集合を持つ メディア要素を含む すべてのページがバックグラウンドにある場合、ユーザーエージェントは 監視アルゴリズムを実行しないことを選択できます。

一部の リモート再生デバイスは、 機能上、セキュリティ上、またはハードウェア上の制限により、 メディアリソースの 一部しか再生できない場合があります。例として、 特定の映像形式および/または音声形式のみをレンダリングできる セットトップボックス、スマートテレビ、ネットワーク接続スピーカーがあります。 リソースによって指定されたメディアのリモート再生がそのデバイス上で 成功することをユーザーエージェントが合理的に保証できる場合、そのようなデバイスを、 その メディアリソースに対する 互換性のあるリモート再生デバイス と呼びます。

注記

ユーザーエージェントは、 track 要素の srclang 属性を、テキストトラックデータの言語を示すヒントとして使用し、 互換性のあるリモート再生 デバイスの特定に役立てることができます。

ユーザーエージェントが 互換性のあるリモート 再生デバイスを見つけるために考慮した、 メディア 要素メディアリソースを、 利用可能性ソース集合と呼びます。

選択された リモート再生デバイス上で リモート 再生を開始するために使用される メディア 要素メディアリソースを、 リモート再生ソースと呼びます。リモート再生 ソースは、メディア要素の 利用可能性ソース 集合MUST 属していなければなりません。

利用可能性ソース集合から リモート再生ソースを選択する メカニズムは実装固有ですが、 ユーザーエージェントは 利用可能性ソース集合内のすべてのリソースを、 潜在的な リモート 再生ソースとして SHOULD 考慮するべきです。

注記
選択されたデバイスに対する リモート再生 ソースを選択するアルゴリズムは、ユーザーエージェントと、サポートされている リモート 再生デバイスの種類に依存します。たとえば、メディア ミラーリングの場合、ユーザーエージェントは単に HTMLMediaElement リソース選択アルゴリズムに従うことができます。しかし、 メディア リモーティングまたは メディアフリンギングを使用する場合、 最適なメディアソースは、選択された リモート再生 デバイスの取得能力と再生能力に依存する場合があります。

ユーザーエージェントが リモート再生デバイスに 適した リモート再生ソースを 判断できない場合、ユーザーエージェントは、利用可能性ソース 集合内のすべてのリソースに関するメタデータ(たとえば、 拡張 MIME タイプ)を リモート再生デバイスに送信し、 そのデバイス自身が リソース 選択アルゴリズムを実行して リモート 再生 ソースを選択できるようにすることが RECOMMENDED されます。

利用可能なリモート 再生 デバイスのリストが空であるか、そのどのデバイスも メディア 要素利用可能性ソース集合に含まれるどのソースとも 互換性がない場合、その メディア 要素に対するリモート再生は 利用不可です。それ以外の場合、リモート再生は 利用可能です。 リモート再生が 利用不可の場合は false利用可能の場合は true に設定される boolean を、その メディア要素利用可能性と呼びます。

ユーザーエージェントが 利用可能なリモート再生デバイスのリストの監視を停止した場合 (たとえばユーザー操作または省電力のため)、ページがユーザー体験を適切に更新できるよう、 グローバルな利用可能性 コールバックの集合内のすべてのコールバックを false で呼び出すことが SHOULD 望まれます。また、ユーザーエージェントが後で 利用可能なリモート再生デバイスのリストの監視を再開した場合に 利用可能性情報を正しく伝播できるよう、すべての メディア要素利用可能性の値も false に設定することが SHOULD 望まれます。

5.2.1.3 リモート再生デバイスの利用可能性 情報の取得

watchAvailability() メソッドが呼び出されたとき、ユーザーエージェントは次の手順を MUST 実行しなければなりません。

入力
callback、利用可能性情報とともに 呼び出されるコールバック。
出力
promisePromise
  1. promise を新しい Promise とします。
  2. promise を返し、以下の手順を実行します。
  3. disableRemotePlayback 属性が メディア要素に存在する場合、 promiseInvalidStateError で拒否し、残りのすべての手順を中止します。
  4. ユーザーエージェントが 閲覧 コンテキストの存続期間全体にわたって 利用可能な リモート再生デバイスのリストを監視できない場合 (たとえば、ユーザーがこの機能を無効にしたため)、次の手順を 並列に実行します。
    1. promise を解決します。
    2. callbackfalse を引数として呼び出すために、タスクを キューに入れます
    3. 残りのすべての手順を中止します。
  5. ユーザーエージェントが 利用可能な リモート再生デバイスのリストを継続的に監視できないものの、 リモート再生を開始するときに短時間であれば実行できる場合:
    1. promiseNotSupportedError 例外で拒否します。
    2. 残りのすべての手順を中止します。
  6. callbackId を、 閲覧 コンテキスト内でこれらの手順によって以前返された すべての callbackIds の中で一意な正の整数とします。この閲覧コンテキストは メディア 要素のものです。
  7. タプル (callbackId, callback) を作成し、 この メディア要素利用可能性 コールバックの集合に追加します。
  8. promisecallbackId で解決し、次の手順を 並列に実行します。
    1. callback を、 メディア 要素の現在の 利用可能性を引数として呼び出すために、 タスクを キューに入れます
    2. ユーザーエージェントが 利用可能な リモート再生デバイスのリストを監視していない場合、 利用可能な リモート再生 デバイスのリストを監視するアルゴリズムを実行します。
注記

callbackId 値を割り当てる単純なアルゴリズムとして、 各 閲覧 コンテキストごとにカウンターを保持し、 手順 6 でインクリメントする方法があります。

注記
ユーザーのフィンガープリントに使用できる情報が漏れることを避けるため、 ユーザーエージェントは、ブラウザープロファイルまたは リモート再生デバイスからの 永続的な情報を使用する callbackId を割り当てないことが期待されます。
5.2.1.4 利用可能なリモート再生デバイスのリストの監視

利用可能性コールバックの集合が 空でないか、 リモート再生を開始するための保留中の要求がある場合、 ユーザーエージェントは、次の手順を実行して 利用可能なリモート再生 デバイスのリストを監視MUST なければなりません。

  1. 利用可能なリモート再生デバイスを取得し(実装固有の メカニズムを使用)、newDevices を このリストとします。
  2. 閲覧 コンテキストが認識している各 メディア要素について:
    1. disableRemotePlayback 属性が mediaElement に存在する場合、 このタプルに対する残りのすべての手順を中止し、 次のタプルへ進みます。
    2. newAvailabilityValue を、 利用可能な リモート再生デバイスのリストの代わりに newDevices リストを使用して計算した メディア要素利用可能性の値に設定します。
    3. 現在の 利用可能性newAvailabilityValue と等しくない場合、 要素の 利用可能性 コールバックの集合に含まれる各 (callbackId, callback) について:
      1. callbacknewAvailabilityValue を引数として呼び出すため、 タスクを キューに入れます
  3. 利用可能な リモート再生デバイスのリストnewDevices の値に設定します。
5.2.1.5 リモート再生デバイスの利用可能性の監視を停止する

cancelWatchAvailability() メソッドが呼び出されたとき、ユーザーエージェントは次の手順を MUST 実行しなければなりません。

入力
id、コールバック識別子。
出力
promisePromise
  1. promise を新しい Promise とします。
  2. promise を返し、以下の手順を実行します。
  3. disableRemotePlayback 属性が メディア要素に存在する場合、 promiseInvalidStateError で拒否し、残りのすべての手順を中止します。
  4. パラメーター idundefined の場合、 利用可能性 コールバックの集合をクリアします。
  5. それ以外の場合、id利用可能性 コールバックの集合内のいずれかのエントリーの callbackId と一致するなら、そのエントリーを 集合から削除します。
  6. それ以外の場合、promiseNotFoundError で 拒否し、残りのすべての手順を中止します。
  7. 利用可能性コールバックの集合が 空になり、リモート 再生を開始する保留中の要求もない場合、省電力のため、 利用可能な リモート再生 デバイスのリストを監視する保留中のタスクがあればキャンセルします。
  8. promise を解決します。
注記
リモート再生 デバイスの利用可能性を監視し、選択された 利用可能性ソース 集合リモート 再生デバイスとの互換性を判断するために使用するメカニズムは、 ユーザーエージェントに委ねられます。

5.2.2 リモート再生状態を変更するようユーザーに促す

prompt() メソッドが 呼び出されたとき、ユーザーエージェントは次の手順を MUST 実行しなければなりません。

入力
なし。ただし、このアルゴリズムは メディア要素、 その remote プロパティ、およびその 利用可能性ソース集合を参照します。
出力
Promise
  1. promise を新しい Promise とします。
  2. promise を返し、これらの手順を 並列に 実行し続けます。
  3. disableRemotePlayback 属性が メディア要素に存在する場合、 promiseInvalidStateError で拒否し、残りのすべての手順を中止します。
  4. 同じ メディア 要素、または同じ 閲覧 コンテキストについてさえも、以前の prompt() 呼び出しから 未解決の Promise がすでに存在する場合、ユーザーエージェントは promiseOperationError 例外で MAY 拒否し、 残りのすべての手順を中止できます。
    注記
    ここでの理由は、ユーザーエージェントが メディア要素または 閲覧 コンテキストのいずれかに対してモーダルなダイアログを表示する場合があるためです。 その場合、2 回目の prompt() 呼び出しは UI を表示できません。
  5. 文書の アクティブ ウィンドウ一時的な アクティベーションを持たない場合、promiseInvalidAccessError 例外で拒否し、これらの手順を中止します。
  6. 任意で、ユーザーエージェントが、この特定の メディア要素のリモート再生が 事前に実行不可能であると分かっている場合(現在の state または 利用可能な リモート 再生デバイスのリストとは無関係に)、promiseNotSupportedError で拒否し、残りのすべての手順を中止します。
    注記
    この状況の一例は、ユーザーエージェントが メディアフリンギングのみをサポートしており、 メディア要素のソースが リモート再生デバイスに渡すことのできる URL ではない場合です。
  7. ユーザーエージェントが 利用可能なリモート 再生デバイスのリストを表示する必要があり、かつ 利用可能な リモート再生デバイスのリストを監視していない場合、 利用可能なリモート 再生デバイスのリストを監視する手順を 並列に 実行します。
  8. リモート再生が 利用不可であり、 ユーザー許可の要求が完了する前にもその状態が続く場合、 promiseNotFoundError 例外で拒否し、 残りのすべての手順を中止します。
  9. リモート再生 状態を変更するためのユーザー許可を要求します。
    注記
    許可を要求する UI の例としては、ユーザーが新しい リモート再生 デバイスを選択したり、ローカル再生デバイスと リモート再生デバイスを切り替えたり、リモート 再生デバイスから切断したりできるものが考えられます。
    注記
    ユーザーは、たとえばディスプレイの内容または現在のページを ミラーリングするなど、関連する目的のためにすでに リモート再生 デバイスを選択している場合があります。その場合、 ユーザーエージェントはデバイスを選択する UI を省略し、 直ちに次の手順へ進むことを選択できます。
  10. ユーザーが リモート再生を開始するための リモート再生デバイス device を選択した場合、ユーザーエージェントは次の手順を MUST 実行しなければなりません。
    1. remote オブジェクトの stateconnecting に設定します。
    2. promise を解決します。
    3. メディア 要素remote プロパティで、 connecting という名前の イベントを発火するため、 タスクを キューに入れます。このイベントはバブリングしてはならず、 キャンセル可能であってはならず、デフォルトアクションを持ちません。
    4. リモート 再生デバイスとの接続を確立します。 メディア要素に対して、 device を使用します。
    注記

    リモート再生 デバイスを選択することにより、ユーザーはそのデバイスを使用する 許可を与えます

  11. それ以外の場合、ユーザーが リモート 再生デバイス device から切断することを選択した場合、ユーザーエージェントは 次の手順を MUST 実行しなければなりません。
    1. promise を解決します。
    2. device に対して リモート再生 デバイスから切断するアルゴリズムを実行します。
  12. それ以外の場合、ユーザーはデバイスを使用する 許可を拒否したものとみなし、promiseNotAllowedError 例外で拒否し、ユーザーエージェントが表示した UI を非表示にします。
注記
UI とデバイス選択の実装の詳細は ユーザーエージェントに委ねられます。たとえば、ユーザーにダイアログを表示して、 利用可能なデバイスを選択(許可を 与える)させたり、選択をキャンセル(許可を 拒否する)させたりできます。多くの場合、利用可能なデバイスは、 ユーザー向けの名前に、その名前のロケールおよびテキスト方向 情報を付けて通知します。ユーザーエージェントには、 ロケールとテキスト方向が分かっている場合、それらを使用して このユーザー向けの名前を表示することが推奨されます。

5.2.3 state 属性

state 属性は、 RemotePlayback 接続の現在の状態を表します。 接続状態に応じて RemotePlaybackState の値のいずれかを取ります。

  • connecting は、 ユーザーエージェントが選択された リモート再生デバイスとの リモート 再生の開始を試みていることを意味します。これは、 prompt() が返した promise が解決されたときの初期状態です。この状態では メディア要素のローカル再生が継続し、メディアコマンドは引き続き ローカル再生状態に作用します。
  • connected は、 ローカル再生からリモート再生への移行が完了し、 すべてのメディアコマンドが リモート再生 状態に作用するようになったことを意味します。
  • disconnected は、 リモート再生が 開始されていない、開始に失敗した、または 停止されたことを意味します。すべてのメディアコマンドは ローカル 再生状態に作用します。リモート再生は prompt() の呼び出しによって開始できます。

5.2.4 リモート再生デバイスとの接続の確立

ユーザーエージェントが リモート再生デバイスとの接続を 確立する場合、次の手順を MUST 実行しなければなりません。

入力
remote、接続される RemotePlayback オブジェクト。
device、接続先の リモート 再生デバイス
  1. remotestate が "connecting" と等しくない場合、 残りのすべての手順を中止します。
  2. remote から device への接続を要求します。この手順の実装は ユーザーエージェント固有です。
  3. 接続が正常に完了した場合、次の手順を実行するために タスクをキューに入れます
    1. remotestate を "connected" に設定します。
    2. remoteconnect という名前の イベントを 発火します
    3. 現在の メディア要素の状態リモート再生状態と同期します。 この手順の実装は ユーザーエージェント固有です。
  4. 接続に失敗した場合、次の手順を実行するために タスクをキューに入れます
    1. remoteリモート再生 状態を "disconnected" に設定します。
    2. remotedisconnect という名前の イベントを 発火します

リモート再生状態が "connected" である間、 ユーザーエージェントはメディア要素のローカル音声および映像出力を SHOULD 一時停止するべきです。

ユーザーエージェントがメディア要素について ユーザーに ユーザーインターフェイスを公開している場合(すなわち、 デフォルトコントロールを使用している場合)、ユーザーエージェントは、 リモート再生状態が "connected" であることを、 アイコンまたはその他の手段によって SHOULD 示すべきです。

注記
ユーザーエージェントと リモート再生デバイスを接続し、 リモート再生 ソースを選択し、再生を開始するために使用されるメカニズムは、すべて ユーザーエージェントによる実装上の選択です。接続にはおそらく、 メディアコマンドをリモート再生デバイスへ送り、 メディア再生状態を受信できる双方向のメッセージング抽象化が必要です。これは メディア要素の状態リモート再生 状態を同期させるためです(メディアミラーリングを使用する場合を除きます)。
注記
ユーザーエージェントには、可能な場合、 リモート再生デバイスへ ロケールおよびテキスト方向情報を渡すことが推奨されます。これにより、 リモート再生デバイスは、 ユーザーの設定を反映するロケール固有の属性に合わせて、 ユーザーインターフェイスおよび動作機能を調整できます。たとえば、 リモート 再生 デバイスは、その情報を使用してユーザーエージェントと同じデフォルトの テキストトラックを選択したり、メディアリソースを取得する際に送信する HTTP Accept-Language ヘッダーを設定したりできます。
注記
ユーザーエージェントは、メディア要素が "connected" 状態であり、 そのコンテンツが リモート再生デバイス上で レンダリングされている間は、そのメディア要素からの出力をレンダリングするべきではありません。

5.2.5 ブラウザーによって開始されるリモート再生

ユーザーエージェントは、ブラウザーから リモート再生デバイスへの 接続MAY サポートできます。これは、 ユーザーに 公開されるユーザー インターフェイスに適切なメディアコントロールを追加するか、 ユーザーがシステム全体のディスプレイミラーリングを有効にした場合に行うことができます。 この機能を ブラウザーによって 開始されるリモート再生と呼びます。 ブラウザーによって開始されるリモート再生を サポートするユーザーエージェントは、たとえばブラウザー内のボタンをクリックするなどの ユーザージェスチャーによってユーザーがその意図を示した場合にのみ、 リモート再生を SHOULD 開始するべきです。

ユーザーエージェントが ブラウザーによって開始される リモート再生をサポートする場合、 state 属性は リモート再生デバイスへの 接続の現在の状態を MUST 反映しなければなりません。ブラウザーが リモート再生を開始または終了するときは、 リモート再生 デバイスとの接続を確立するアルゴリズムおよび リモート再生デバイスから 切断するアルゴリズムに従って、対応するイベントを MUST 発火しなければなりません。

新たに作成されたメディア要素で ブラウザーが リモート再生を開始する場合、 その state 属性の値を "connecting" に SHOULD 初期化し、その後 リモート再生 デバイスとの接続を確立する手順に従うべきです。

注記
ブラウザーによって開始されるリモート再生を実装するユーザーエージェントは、 どの メディア要素再生を許可されているか、 バックグラウンドメディア再生の最適化など、 メディア再生に影響する他のブラウザーポリシーとの相互作用を考慮するべきです。

5.2.6 メディアコマンドとメディア再生状態

リモート 再生 デバイスとの接続が確立されると、 HTMLMediaElement インターフェイスは直ちにリモートで 再生されるメディアと相互作用します。

RemotePlayback オブジェクトの state が "connected" のとき、 次の条件によって ローカル再生状態メディア要素の状態、および リモート再生状態の関係が定められます。

コマンドの送信に失敗した場合、ユーザーエージェントは リモート再生 デバイスから切断して MAY かまいません。

注記

リモート再生デバイスは、 ユーザーエージェントの再生エンジンが持つ機能の 一部のみを実装する場合があり、また一部の HTMLMediaElement API はリモート再生中に使用しても必ずしも 意味があるとは限りません。この場合、 リモート再生中にサポートされないメディアコマンドの後でも、 ローカル再生状態は実際の リモート再生状態を 可能な限り厳密に反映することが期待されます。

たとえば、リモート再生 デバイスfastSeek() をサポートしていない状態で接続中にこれを呼び出した後、 HTMLMediaElementseeking 属性は false のままであることが期待され、 seeking イベントは発火されません。

5.2.7 リモート再生デバイスからの切断

ユーザーエージェントが リモート 再生デバイスから切断する場合、次のことを MUST 行わなければなりません。

入力
remote、停止される再生を表す RemotePlayback オブジェクト。
device、切断元となる リモート 再生デバイス
  1. remotestatedisconnected の場合、残りのすべての手順を中止します。
  2. 次の手順を実行するために タスクをキューに入れます
    1. remotedevice から切断するよう要求します。この 手順の実装はユーザーエージェント固有です。
    2. remotestatedisconnected に変更します。
    3. remotedisconnect という名前の イベントを 発火します
    4. 現在の メディア要素の状態ローカル再生状態と同期します。この手順の実装は ユーザーエージェント固有です。

再生中にリモート再生デバイスが突然切断された場合 (たとえば、電源喪失やネットワーク切断によって)、 ユーザーエージェントは、リモート再生 デバイスから切断する手順の前に 利用可能な リモート再生デバイスのリストを監視する手順を SHOULD 実行するべきです。これにより、 利用可能性 コールバックの集合内のコールバックを disconnect イベントが発火される前に 呼び出すことができ、ページは再生の再開が不可能であることを示すよう 自身を更新できます。

注記
ユーザーエージェントから要求された場合でも、リモート再生デバイスが 実際にはメディアの再生を停止しないことがあります。これは ユーザーエージェントとリモート再生デバイスの実装に依存します。 この場合、リモート再生を停止するとは、ユーザーエージェントが 単にリモート再生デバイスから切断し、 メディア 要素disconnected 状態へ切り替わることを意味します。

5.2.8 イベントハンドラー

以下は、RemotePlayback インターフェイスを 実装するオブジェクトが、イベントハンドラー IDL 属性としてサポートしなければならない イベントハンドラー (および対応する イベント ハンドラーイベント型)です。

イベントハンドラー イベントハンドラーイベント型
onconnecting connecting
onconnect connect
ondisconnect disconnect

5.3 HTMLMediaElement の拡張

WebIDLpartial interface HTMLMediaElement {
  [SameObject] readonly attribute RemotePlayback remote;

  [CEReactions] attribute boolean disableRemotePlayback;
};

remote 属性は、 メディア要素に 関連付けられた RemotePlayback インスタンスを MUST 返さなければなりません。

5.3.1 disableRemotePlayback 属性

一部のページでは、メディア要素の リモート再生を無効にしたい場合があります。 たとえば、プレゼンテーション画面に文書全体を表示するために PresentationRequest を使用することを望む場合があります。このユースケースをサポートするため、 新しい disableRemotePlayback 属性が audio および video 要素のコンテンツ属性の一覧に追加されます。

各要素の disableRemotePlayback コンテンツ属性の値を 反映する、対応する disableRemotePlayback IDL 属性が HTMLMediaElement インターフェイスに追加されます。 disableRemotePlayback IDL 属性は、同名のコンテンツ属性を 反映MUST なければなりません。

5.3.2 リモート再生の無効化

disableRemotePlayback 属性が メディア 要素に存在する場合、ユーザーエージェントは メディア要素をリモートで再生したり、そのための UI を表示したりして MUST NOT はなりません。

disableRemotePlayback 属性が メディア 要素に追加されたとき、ユーザーエージェントは リモート再生を無効にするための次の手順を MUST 実行しなければなりません。

  1. RemotePlayback メソッドが返した 保留中のすべての Promise を InvalidStateError で拒否します。
  2. メディア要素の 利用可能性コールバックの集合を クリアします。
  3. その statedisconnected でない場合、メディア要素が接続中または接続しようとしている リモート 再生デバイスについて、リモート 再生デバイスから切断するアルゴリズムを実行します。

6. セキュリティとプライバシーに関する考慮事項

このセクションは非規範的です。

6.1 個人を特定できる情報

watchAvailability() メソッドを介して提供された callback を発火すると、 通常はローカル エリアネットワークを通じて検出される リモート再生デバイスの存在(または不存在)に関する 1 ビットの情報が明らかになります。これは他の 情報と組み合わせてユーザーのフィンガープリンティングに利用される可能性があります。しかし、この情報は ユーザーのローカルネットワークのコンテキストにも依存するため、リスクは 最小限に抑えられます。また、設計上、リモート 再生デバイスの人間が読める名前はページには公開されません。

この API により、利用可能なリモート再生 デバイスのリストを監視できます。ユーザーエージェントが リモート再生デバイスメディア 要素リソースとの互換性および 利用可能性をどのように判断するかは実装の詳細です。ユーザーエージェントが 利用可能性を判断するために メディアリソースを 特定の種類のデバイスと照合する場合、この機能を使用して、 ユーザーの同意なしにユーザーがどの リモート再生デバイスを所有しているかに関する情報を調べることができます。

ユーザーがブラウザー設定を通じてバックグラウンド監視を 無効にした場合、ユーザーエージェントは 利用可能なリモート 再生デバイスのリストを監視するべきではありません。

6.2 ユーザーインターフェイスのガイドライン

オリジンの表示

リモート再生 状態を変更する手順の中で、リモート 再生 デバイスを使用する許可をユーザーに求める場合、ユーザーエージェントは その要求がどのオリジンから来ているのかを明確にするべきです。

リモート再生を要求しているオリジンを表示することで、 ユーザーは、どのコンテンツが要求を行っているのかを理解しやすくなります。特に、 要求が 子 ナビゲータブルから開始された場合に有用です。たとえば、 埋め込まれたコンテンツが、望まないリモート再生を開始する要求を トリガーするためにクリックするようユーザーを誘導しようとする場合があります。

表示されるオリジンを示すことで、ユーザーは そのコンテンツが 潜在的に 信頼できるオリジン (例: https:)からのものであり、既知または想定されたサイトに対応しているかどうかを把握しやすくなります。

6.3 デバイスアクセス

Remote Playback API は、ディスプレイにとって「ローカル」が何を意味するかを 抽象化します。つまり、ネットワーク経由でアクセス可能なディスプレイを、 ローカルディスプレイであるかのように公開します。Remote Playback API は、 他人から見えるディスプレイに望まないコンテンツを表示するなど、 起こり得る問題を軽減するため、ページが任意のディスプレイにアクセスする際に ユーザーの許可を必要とします。

6.4 ローカル再生デバイスとリモート再生デバイス間のメッセージング

この仕様では、 ローカル再生デバイスリモート再生 デバイス間の通信プロトコルを規定しませんが、ユーザーエージェントは 両者間のメッセージの機密性と真正性について一定の保証を設けるべきです。

6.5 セキュアコンテキスト

Remote Playback API は [SECURE-CONTEXTS] に限定されません。これは、 ユーザーエージェントが通常、閲覧 コンテキストに関係なく、すべてのメディアに対してネイティブに 提供する機能を Web アプリケーションに公開するためです。 ユーザーエージェントは、セキュアでないコンテキストでは 利用可能なリモート 再生デバイスのリストを監視するアルゴリズムの一部として常に 空のリストを返すことで、この API を [SECURE-CONTEXTS] に限定できます。

A. 勧告候補の終了基準

この仕様が勧告案へ進むためには、各 機能について少なくとも 2 つの独立した相互運用可能な実装が 存在しなければなりません。各機能は異なる一組の 製品によって実装されてもよく、すべての機能を単一の 製品が実装する必要はありません。さらに、実装は メディアリモーティングおよび メディアフリンギングのケースを、 同一製品内または異なる製品内のいずれかで サポートしていることを実証しなければなりません。

これらの基準の目的上、以下の用語を定義します。

独立
各実装は異なる主体によって開発されなければならず、 適格な別の実装で使用されているコードを共有、再利用、または派生しては なりません。この仕様の 実装に関係しないコード部分は、この 要件の対象外です。
相互運用可能
公式テストスイート内の対応するテストケースに合格すること。
実装
次の条件を満たすユーザーエージェント:
  1. この仕様を実装していること。
  2. 一般公開されていること。実装は 出荷済み製品またはその他の一般公開バージョン(すなわち、ベータ バージョン、プレビューリリース、または「nightly build」)であってもかまいません。出荷されていない製品の リリースでは、安定性を実証するために、該当する機能を 少なくとも 1 か月間実装していなければなりません。
  3. 実験的なものではないこと(すなわち、テストスイートに 合格するためだけに特別に設計され、今後の通常利用を意図していない バージョンではないこと)。

B. 参考文献

B.1 規範的参考文献

[dom]
DOM 標準. Anne van Kesteren. WHATWG. 現行標準. URL: https://dom.spec.whatwg.org/
[HTML]
HTML 標準. Anne van Kesteren; Domenic Denicola; Ian Hickson; Philip Jägenstedt; Simon Pieters. WHATWG. 現行標準. URL: https://html.spec.whatwg.org/multipage/
[PRESENTATION-API]
Presentation API. Mark Foltz; Dominik Röttsches. W3C. 2023年10月16日. W3C 勧告候補. URL: https://www.w3.org/TR/presentation-api/
[RFC2119]
要件レベルを示すために RFC で使用する キーワード. S. Bradner. IETF. 1997年3月. 現行のベストプラクティス. URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC8174]
RFC 2119 キーワードにおける大文字と小文字の 曖昧性. B. Leiba. IETF. 2017年5月. 現行のベストプラクティス. URL: https://www.rfc-editor.org/rfc/rfc8174
[WEBIDL]
Web IDL 標準. Edgar Chen; Timothy Gu. WHATWG. 現行標準. URL: https://webidl.spec.whatwg.org/

B.2 参考情報

[SECURE-CONTEXTS]
セキュアコンテキスト. Mike West. W3C. 2023年11月10日. W3C 勧告候補. URL: https://www.w3.org/TR/secure-contexts/
[url]
URL 標準. Anne van Kesteren. WHATWG. 現行標準. URL: https://url.spec.whatwg.org/