リモート再生 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/

Copyright © 2024 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.

要約

本仕様は、HTMLMediaElement を拡張し、ウェブページからメディアのリモート再生を制御可能にするAPIを定義します。

この文書の状態

このセクションは、本書の公開時点での状態を示します。W3C の現行出版物の一覧と、この技術報告書の最新版は W3C技術報告書インデックス （https://www.w3.org/TR/）で確認できます。

本文書はSecond Screen Working Groupによって、 Recommendation trackを用いたCandidate Recommendation Draftとして公開されました。

本文書はグループが外部のプレゼンテーション型ディスプレイでウェブコンテンツを表示した経験に基づいており、必要に応じてPresentation API仕様[PRESENTATION-API]からパターンや設計上の配慮事項を再利用しています。

この文書はまだ作業中であり変更される可能性がありますが、Working GroupはAPIのインターフェースが安定していると考えています。issue trackerに記載された残りの問題の大半は現段階で軽微なものと見なされていますが、Issue #41は例外です。

Issue #41 では、リモート再生デバイスが対応すべきメディア再生機能のセットについて議論されています。これらの機能がリモート再生中に利用された際の相互運用性問題を特定するため、グループは今後さらに開発者フィードバックや実装経験を求め、受けたフィードバックに基づき仕様の明確化を行います。

その他の問題や懸念については、バグをファイルしたり、メーリングリストにメールを送信できます。スペルミスのような小さな編集上の修正であれば、プルリクエストでの提案も歓迎します。

Working Groupはどなたにも本文書のレビューを呼びかけており、W3C内の関係グループと連携して、アクセシビリティ、国際化、プライバシー、セキュリティ、技術アーキテクチャ原則について水平レビューを行う予定です。

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

Second Screen Working GroupはCandidate Recommendation期間中にRemote Playback APIのテストスイートを作成し、実装レポートを準備します。本仕様がProposed Recommendationへ進むには、各機能について2つの独立した相互運用可能な実装が実証されなければなりません（詳細はCandidate Recommendation exit criteriaセクションを参照）。

Candidate Recommendationとしての公開は、W3Cおよびそのメンバーによる支持を意味しません。Candidate Recommendation Draftは先行するCandidate RecommendationからWorking Groupが次のCandidate Recommendation Snapshotに含める意図のある変更内容を統合したものです。

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

本文書は、 W3C Patent Policyの下で運営されるグループによって作成されました。 W3Cは、グループの成果物に関して行われた公開特許開示リストを維持しています。また、そのリストには特許の開示方法も記載されています。自身が本質的請求(Essential Claim(s))を含むと信じる特許について実際に知識を持つ個人は、W3C Patent Policy第6節に従ってその情報を開示しなければなりません。

本文書は2023年11月3日付 W3Cプロセス文書によって管理されています。

1. 適合性

非規範的と記載されたセクションだけでなく、この仕様内のすべての執筆ガイドライン、図、例、および注記は規範的ではありません。それ以外の内容はすべて規範的です。

本文書における MAY、MUST、MUST NOT、RECOMMENDED、SHOULD というキーワードは、 BCP 14 [RFC2119] [RFC8174] で示されているとおり、ここで示すようにすべて大文字で現れた場合のみ、同じ意味で解釈されます。

この仕様は、単一のプロダクト、すなわちその中で定義されているインターフェースを実装するユーザーエージェントに適用される適合基準を定めます。

この仕様で定義されたAPIをECMAScriptで公開する実装は、Web IDL仕様 [WEBIDL] で定義された ECMAScript バインディングに従って一貫して実装しなければなりません (MUST)。

2. はじめに

このセクションは規範的ではありません。

本仕様は、接続されたテレビやプロジェクター、オーディオ専用スピーカーなどのリモート再生デバイスをWebで利用可能にし、有線（HDMI、DVIなど）や無線技術（Miracast、Chromecast、DLNA、AirPlay など）で接続された再生デバイスも考慮しています。

画面サイズが小さい、またはスピーカーが小さいデバイスは、例えば会議室の同僚や自宅の家族・友人など、多くの人へのメディアコンテンツ再生に適していません。外部のより大きな/より大きな音量の リモート再生デバイス でメディアコンテンツを再生することで、再生されるメディアの体験とインパクトを高めることができます。

基本的に、本仕様はブラウジングコンテキストとして動作するページが、選択されたリモート再生デバイス上で特定のメディア要素のリモート再生を開始・制御できるようにします。リモート再生の開始や制御方法はユーザーエージェント側に委ねており、様々な手段で接続されるリモート再生デバイスに対応できるようになっています。例えば リモート再生デバイスがHDMIやMiracastで接続された場合、同じUAがブラウジングコンテキストとしてリモートメディアをレンダリングします。ただし、メディアを同じデバイスで再生せず、OSが提供する手段で外部のリモート再生デバイスを利用できます。この場合、ブラウジングコンテキストとメディアプレイヤーは同じUA上で動作し、OSがプレイヤーの出力をリモート再生デバイスへルーティングします。これは一般的にメディアミラーリングケースと呼ばれ、この仕様はこの方法で接続されたリモート再生デバイスには何の要件も課しません。

リモート再生デバイスがメディアを再生でき、ブラウジングコンテキストと通信はできるがメディア自体を取得できない場合、ブラウジングコンテキストがメディアデータを取得してリモート再生デバイスに渡す必要があります。これは一般的にメディアリモーティングケースと呼ばれます。

リモート再生デバイスがメディアを取得・再生でき、かつブラウジングコンテキストとも通信できる場合は、ブラウジングコンテキストがリモートメディアを取得・レンダリングする必要はありません。この場合、UAはプロキシとして必要なデータ（メディアソースなど）を渡し、リモート再生デバイス自体でメディアを再生するようリクエストします。これは一般的にメディアフリンギングケースと呼ばれます。この接続方法は、今後リモート再生デバイスが実装可能なメッセージ伝送標準プロトコルを定めることで拡張できるでしょう。

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

3. ユースケースと要件

このセクションは規範的ではありません。

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

4. 例

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

4.1 リモート再生デバイスの利用可否監視例

例 1 
<!-- player.html -->
<!-- リモート再生に対応したカスタムコントロール付きビデオ要素 -->
<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 動画のリモート再生開始例

例 2 
<!-- player.html -->
<script>
  deviceBtn.onclick = () => {
    // ユーザーにリモート再生デバイスの選択を促します。
    videoElem.remote.prompt()
      // UIを更新し、接続状態を監視します。
      .then(updateRemotePlaybackState);
      // ユーザーが選択UIをキャンセル、またはスクリーンが見つからなかった場合は何もしません。
  };
<script>

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

例 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' であることをユーザーに示す。
    // 例えば、ビデオ要素はコントロールだけが必要なので非表示にする。
    videoElem.style.display = "none";

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

  function switchToLocalUI() {
    // ビデオ要素を表示する。
    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はNotSupportedErrorで拒否されなければなりません。

5.2.1.1 可用性コールバックのセット

ユーザーエージェントは、各メディア要素に対して watchAvailability() メソッドを通じて登録された可用性コールバックの集合を必ず管理しなければならない。 各RemotePlaybackオブジェクトの 可用性コールバックの集合 は、タプルの集合 (callbackId, callback) として表され、最初は空である。

  1. callbackId は、同一ブラウジングコンテキスト内でwatchAvailability()から返されるIDの中で一意な正の整数、
  2. callback は RemotePlaybackAvailabilityCallback オブジェクト。

各RemotePlaybackオブジェクトは1つのメディア要素につき1つだけ作られるため、メディア要素の可用性コールバックのセットは、その要素のRemotePlaybackオブジェクトのremoteプロパティで参照されるオブジェクトの可用性コールバックセットと同一です。

全RemotePlayback オブジェクトの全可用性コールバックセットの合成集合は、グローバル可用性コールバックセットと呼ばれます。

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

ユーザーエージェントは利用可能なリモート再生デバイスリスト（list of available remote playback devices）を維持しなければなりません (MUST)。このリストにはリモート再生 デバイスが含まれ、実装依存の発見メカニズムにより構成されます。このアルゴリズムがまだ未実行の場合は空リスト、そうでない場合は利用可能なリモート再生デバイス一覧監視アルゴリズムの最新の結果となります。

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

グローバル可用性コールバックセットが空でないとき、ユーザーエージェントは連続的にリモート再生デバイス一覧監視を実行しなければなりません (MUST)。これによりページ側が登録済みコールバック経由で最新可用値を維持でき、利用可能機器がある時のみリモート再生を案内できます。

注

ユーザーエージェントは可能な限りリモート再生デバイス一覧監視を回避すべきです。これは 省電力の非機能要件を満たすためです。たとえば、全てのremote付きメディア要素持つページがバックグラウンドになり、かつ全ページの可用性コールバックセットが空の場合などです。

一部のリモート再生デバイスは、機能・セキュリティ・ハードウェアの制約により再生できるメディアリソースが限られる場合があります。たとえば、特定フォーマットのみを扱うセットトップボックスやスマートTV、ネットワークスピーカーなどです。そのようなデバイスが、特定メディアリソースのリモート再生が十分に保証できる場合、そのデバイスは当該リソースに対する互換リモート再生デバイスと呼びます。

注

ユーザーエージェントはtrack要素のsrclang 属性をヒントとして利用し、テキストトラックデータの言語から互換リモート再生デバイスの特定を補助できます。

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

選択中のリモート再生デバイスでリモート再生を開始する際に使われるメディアリソースをリモート再生ソースと呼び、リモート再生ソースは可用性ソース集合のメンバーである必要があります (MUST)。

可用性ソース集合からリモート再生ソースを選択する仕組みは実装依存ですが、ユーザーエージェントは可用性ソース集合内の全リソースを候補として評価すべきです (SHOULD)。

注
選択デバイスに対するリモート再生ソースの選択アルゴリズムは、ユーザーエージェントおよびサポートされているリモート再生デバイスタイプによって変わる。たとえばメディアミラーリングの場合は、HTMLMediaElementの リソース選択アルゴリズムをそのまま使える。ただしメディアリモーティングやメディアフリンギングの場合は、選択リソースは選択デバイスの取得／再生能力にも依存する。

ユーザーエージェントがリモート再生デバイスに適切なリモート再生ソースを判定できない場合、推奨される動作として、ユーザーエージェントは可用性ソースセット内のすべてのリソースについてのメタデータ（たとえば、拡張MIMEタイプなど）をリモート再生デバイスへ送信し、デバイス側で自身のリソース選択アルゴリズムを実行できるようにし、リモート再生ソースを選択させる。

メディア要素に対して、利用可能なリモート再生デバイスのリストが空であるか、いずれもその可用性ソースセットのいずれのソースとも互換性がない場合、リモート再生は利用不可である。それ以外の場合、リモート再生は利用可能である。リモート再生が利用不可の場合にfalse、利用可能の場合にtrueとなるboolean値を、そのメディア要素の可用性と呼ぶ。

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

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

watchAvailability() メソッドが呼び出されたとき、ユーザーエージェントは以下の手順を実行しなければならない:

入力
callback ― 可用性情報を受け取るコールバック。
出力
promise ― Promise 型。
  1. promise に新しい Promise を設定する。
  2. promise を返し、以下の手順を継続する:
  3. disableRemotePlayback 属性が media element に存在する場合、promise をInvalidStateError で拒否し、以降の手順を中止する。
  4. ユーザーエージェントが利用可能なリモート再生デバイスのリストを監視できない場合（たとえば、ユーザーがこの機能を無効にしているなど）、ブラウジングコンテキストの存続期間全体にわたる場合は、次の手順を並行して実行する：
    1. promiseを fulfill する。
    2. タスクをキューすることで、callback を 引数 false で呼び出す。
    3. 残りの手順をすべて中止する。
  5. ユーザーエージェントが継続的なリモート再生デバイスのリスト監視はできないが、 リモート再生開始時の短時間だけ可能な場合：
    1. promise を NotSupportedError で拒否する。
    2. 以降の手順を中止する。
  6. callbackId をこのブラウジングコンテキスト でこれまで返したcallbackIds と一意となる正の整数とする。
  7. タプル (callbackId, callback) を作り、 このmedia elementの 可用性コールバックセット に追加する。
  8. callbackIdでpromiseをfulfillし、次の手順を並行して実行する:
    1. タスクをキューすることで、可用性の現在値を引数としてcallbackを呼び出す（対象のメディア要素）。
    2. ユーザーエージェントが利用可能なリモート再生デバイスのリストを監視していない場合は、 リスト監視アルゴリズムを実行する。
注

callbackId を割り当てる単純な方法は、 各ブラウジングコンテキスト ごとにカウンターを用意し、手順6で増やすことです。

注
ユーザーのフィンガープリント防止のため、 ブラウザプロファイルやリモート再生デバイスの永続情報を使ったcallbackId の割り当ては避けることが望まれます。
5.2.1.4 利用可能なリモート再生デバイスのリストの監視

可用性コールバックセットが空でない、または リモート再生の開始リクエストが保留中の場合、ユーザーエージェントは 利用可能なリモート再生デバイスリストを監視（monitor the list of available remote playback devices）しなければならない。手順は以下のとおり：

  1. 利用可能なリモート再生デバイスを取得し（実装依存）、newDevicesとする。
  2. ブラウジングコンテキスト内の全media elementについて：
    1. disableRemotePlayback 属性が mediaElement に存在する場合は残りの手順をスキップして次へ。
    2. newAvailabilityValue に、newDevices を用いて算出した可用性の値を代入する。
    3. 現在の可用性がnewAvailabilityValueと異なる場合、その要素のすべての(callbackId, callback) について
      1. タスクをキューし、callback を newAvailabilityValue で呼び出す。
  3. 利用可能なリモート再生デバイスのリストを newDevicesの値に設定する。
5.2.1.5 リモート再生デバイス可用性の監視停止

cancelWatchAvailability() メソッドが呼ばれた場合、ユーザーエージェントは以下を実行しなければならない:

入力
id ― コールバック識別子
出力
promise ― Promise 型。
  1. promise に新しい Promise を設定する。
  2. promise を返し、以下の手順を継続する:
  3. disableRemotePlayback 属性がmedia element に存在する場合、 promise を InvalidStateError で拒否し、残りを中止する。
  4. パラメータ id が undefined の場合、 可用性コールバックセット をクリアする。
  5. そうでなければ、id が可用性コールバックセット の callbackId に一致する場合、そのエントリを除去する。
  6. それ以外の場合、promise を NotFoundError で拒否し、残りを中止する。
  7. 可用性コールバックセット が空 かつ 未処理の リモート再生開始 要求がなければ、 省電力のためリモート再生デバイスのリスト監視 タスクをキャンセルする。
  8. promise を解決する。
注
リモート再生デバイス可用性の監視や、 選択済可用性ソース集合 とのリモート再生デバイスの互換性の判定方法はユーザーエージェント次第です。

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

prompt() メソッドが呼び出されたとき、ユーザーエージェントは以下の手順を実行しなければならない:

入力
なし。ただしアルゴリズムはメディア要素、その remote プロパティおよび 可用性ソース集合を参照する。
出力
Promise
  1. promise を新しいPromiseとして作成する。
  2. promise を返し、以降の手順を並列で続ける。
  3. disableRemotePlayback 属性が メディア要素に設定されている場合、promise をInvalidStateErrorで拒否し、残りの手順を中止する。
  4. 同じメディア要素または 同じブラウジングコンテキスト内で、以前の prompt()の呼び出しで未解決のPromiseが存在する場合、ユーザーエージェントはpromiseをOperationError例外で拒否してもよい（MAY）。そして以降の手順を中止する。
    注
    ここでの理由は、ユーザーエージェントがメディア要素または ブラウジングコンテキストに対してモーダルなダイアログを表示する場合があるため。同一箇所の2回目以降の prompt()ではUIを表示できないことがある。
  5. 文書のアクティブウィンドウが 一時的なアクティベーションを持たなければ、 promiseをInvalidAccessError例外で拒否し、これ以降を中止する。
  6. （オプション）ユーザーエージェントが予めこのメディア要素のリモート再生が決して実現できないことを知っている場合（現在のstateや 利用可能なリモート再生デバイス一覧の有無にかかわらず）、promise をNotSupportedErrorで拒否して残りを中止してもよい。
    注
    例えば、ユーザーエージェントがメディアフリンギングしかサポートしない場合で、メディア要素のソースがURLでなければ、リモート再生デバイスに渡せないケースが該当する。
  7. ユーザーエージェントが利用可能なリモート再生デバイスのリストを表示する必要があり、かつ利用可能なリモート再生デバイスのリストを監視していない場合、リストの監視手順を並行して実行する。
  8. リモート再生が利用不可状態から変わらず、ユーザー許可要求が完了する前にそのままになる場合、 promiseをNotFoundErrorで拒否して以降を中止する。
  9. リモート再生状態の変更をユーザーに許可要求する。
    注
    許可を求めるUI例としては、新しいリモート再生デバイスの選択、ローカル／リモートデバイスの切り替え、リモート再生デバイスからの切断などが考えられる。
    注
    ユーザーが既に画面ミラーリングなど別用途でリモート再生デバイスを選んでいる場合、UIを省略して即次の手順に進めてもよい。
  10. ユーザーが リモート再生デバイス device をリモート再生開始に選択した場合、ユーザーエージェントは次の手順を行う必要がある (MUST):
    1. remote オブジェクトの state を connecting に設定する。
    2. promise を解決する。
    3. タスクをキューし、connectingという名前のイベントを remote プロパティで持つメディア要素で発火する（バブルしない、キャンセル不可、デフォルト動作なし）。
    4. リモート再生デバイスとの接続確立 を当該deviceとメディア要素で行う。
    注

    ユーザーがリモート再生デバイスを選ぶことは、そのデバイス利用への明示的許可を与えることになる。

  11. そうでなくユーザーがリモート再生デバイス device との接続解除を選んだ場合、ユーザーエージェントは次の手順を実行しなければならない (MUST):
    1. promiseを解決する。
    2. リモート再生デバイスとの切断 アルゴリズムをこのdevice で実行する。
  12. それ以外の場合は、ユーザーがデバイス利用に許可しなかったと見なされるため、promiseをNotAllowedErrorで拒否し、ユーザーエージェントのUIを閉じる。
注
UI・デバイス選択の詳細実装はユーザーエージェント依存である。たとえば、ユーザーにはダイアログ表示によるデバイス選択（許可）もキャンセル（不許可）もできる。多くの場合、デバイスはユーザーフレンドリーな名前・ロケール・文字方向情報を広告し、ユーザーエージェントはそれに合わせて表示が推奨される。

5.2.3 state 属性

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

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

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

ユーザーエージェントが リモート再生デバイスとの接続確立 を行うときは、以下の手順を実行しなければなりません (MUST):

入力
remote: 接続する RemotePlayback オブジェクト
device: 接続先の リモート再生デバイス
  1. remote の state が "connecting" でない場合、残りの手順を中止する。
  2. remote を device に接続要求する。この手順の詳細はユーザーエージェント依存です。
  3. 接続が正常に完了した場合、タスクをキューし 以下を実行する:
    1. remote の state を "connected" に設定する。
    2. connect という名前のイベントを remote で発火する。
    3. 現在の メディア要素状態 を リモート再生状態 と同期させる。この手順の実装はユーザーエージェント依存です。
  4. 接続に失敗した場合、タスクをキューし 以下を実行する:
    1. remote の remote playback state を "disconnected" に設定する。
    2. disconnect という名前のイベントを remote で発火する。

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

ユーザーエージェントがユーザーにUIを表示している（つまりデフォルトコントロールを使っている）場合、 リモート再生状態が "connected" であることをアイコン等で伝えるべきです (SHOULD)。

注
ユーザーエージェントが リモート再生デバイス との接続・ リモート再生ソース 選択・再生開始に使う仕組みは実装依存です。 通常、双方向のメッセージングを行い、コマンド転送や再生状態受信で メディア要素状態 と リモート再生状態 の同期をとる（メディアミラーリング時を除く）必要があるでしょう。
注
ユーザーエージェントは リモート再生デバイス に可能ならロケールや文字方向情報を渡すことが推奨されます。これにより リモート再生デバイス はユーザーの嗜好を反映する ロケール属性・インターフェースに調整できるほか、デフォルトトラックやHTTP Accept-Languageヘッダーなども設定できます。
注
リモート再生状態が "connected" で、その内容が リモート再生デバイス でレンダリングされている間はメディア要素の出力は行うべきではありません。

5.2.5 ブラウザによるリモート再生の開始

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

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

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

注
ブラウザによるリモート再生開始を実装するユーザーエージェントは、どの メディア要素が再生可能かや、バックグラウンド再生最適化など、他のメディア再生関連ポリシーとの連携を考慮すべきである。

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

HTMLMediaElement インターフェースは、リモート再生デバイスとの 接続が確立されると、リモート再生されるメディアと連携する。

state が "connected" である RemotePlayback オブジェクトの場合、以下の条件で ローカル再生状態、メディア要素状態、 リモート再生状態 が関連付けられる:

いずれかのコマンドの送信に失敗した場合、ユーザーエージェントはリモート再生デバイスから切断を実行してもよい（MAY）。

注

リモート再生デバイスは、ユーザーエージェントが持つ再生エンジンの機能の一部のみを実装することがあり、HTMLMediaElementのAPIの中にはリモート再生時の利用に適さないものもある。この場合、リモート再生でサポートされないメディアコマンドを実行した後は、ローカル再生状態が、 できるだけ実際のリモート再生状態に近く反映されるべきである。

例えば fastSeek() をサポートしていないリモート再生デバイスに接続中に呼び出すと、 seeking 属性は false のままとなり、seeking イベントも発火しなくてよい。

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

ユーザーエージェントが リモート再生デバイスから切断 を行うとき、その手順は以下の通りでなければならない (MUST):

入力
remote：停止対象のRemotePlaybackオブジェクト
device：切断先の リモート再生デバイス
  1. remote の state が disconnected なら、残りの手順を中止。
  2. タスクをキュー し、以下のステップを実行する:
    1. remote を device から切断要求する。この手順の具体的な実装はユーザーエージェント依存。
    2. remote の state を disconnected に変更。
    3. disconnect という名前のイベントを remote で発火。
    4. 現在の メディア要素状態 を ローカル再生状態 と同期させる。このステップの実装はユーザーエージェント依存。

再生中にリモート再生デバイスが突然切断（例：電源断やネットワーク切断など）された場合、ユーザーエージェントは、リモート再生デバイスから切断の手順の前に利用可能なリモート再生デバイスのリストを監視の手順を実行するべきである (SHOULD)。 これにより、可用性コールバックセット内のコールバック呼び出しが disconnect イベントが発火する前に行われるため、ページ側で再開できないことをUIで案内できる。

注
ユーザーエージェントがリモート再生デバイスに停止要求を出しても、実際に再生が止まるかはユーザーエージェント・リモートデバイス実装による。場合によっては、ユーザーエージェント側が単にリモートデバイスから切断し、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 インスタンスを返します。

5.3.1 disableRemotePlayback 属性

一部のページではメディア要素の リモート再生を無効化 したい場合があります。たとえば、PresentationRequest で発表用画面にドキュメント全体を提示したいケース等です。この用途に対応するため、 audio と video 要素のコンテンツ属性に新しく disableRemotePlayback 属性が追加されています。

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

5.3.2 リモート再生の無効化

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

disableRemotePlayback 属性が メディア要素 に付与されたとき、ユーザーエージェントは リモート再生を無効化する手順を必ず実行します:

  1. RemotePlayback のメソッドが返す保留中のPromiseを InvalidStateError で拒否する。
  2. メディア要素の 可用性コールバックセット をクリアする。
  3. その state が disconnected でなければ、 メディア要素が接続または接続中のリモート再生デバイス についてリモート再生デバイスからの切断アルゴリズムを実行する。

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

このセクションは規範的ではありません。

6.1 個人を特定できる情報

callbackを watchAvailability() メソッド経由で発火すると、 リモート再生デバイスの有無に関する1ビットの情報が局所 ネットワークを通じて発見される。この情報は他の 情報と組み合わせてユーザーを指紋化するのに利用される可能性がある。ただし、この情報は ユーザーのローカルネットワークの文脈にも依存するため、リスクは 最小限である。また設計上、リモート再生デバイスの人が読める名前はページには公開されない。

このAPIは、利用可能なリモート再生デバイスのリストを監視することを可能にする。ユーザーエージェントが リモート再生デバイスとメディア要素のリソース の互換性および可用性をどのように判断するかは実装依存である。ユーザーエージェントが メディアリソース を特定の種類のデバイスにマッチさせて可用性を確認する場合、 この機能はユーザーの リモート再生デバイスの情報をユーザーの同意なく推定するために利用できる。

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

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

オリジンの表示

リモート再生デバイスの利用許可を求められた際、 リモート再生状態変更 の手順中、ユーザーエージェントは要求元のオリジンを明示すべきである。

リモート再生を要求するオリジンを表示することで、 特に子ナビゲーブル から要求が発生した場合、ユーザーがどのコンテンツからの要求か理解できる。例えば、埋め込みコンテンツは 不要なリモート再生開始を誘うクリックをユーザーに促す可能性がある。

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

6.3 デバイスアクセス

Remote Playback APIはディスプレイの「ローカル」の意味を抽象化し、 ネットワークアクセス可能なディスプレイもローカルディスプレイとして扱う。Remote Playback APIは いかなるディスプレイへもページがアクセスするにはユーザーの許可が必要となり、 第三者に見られる表示デバイスで意図しないコンテンツが表示されるなどの 問題を軽減する。

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

本仕様は ローカル再生デバイスとリモート再生デバイス 間の通信プロトコルは定義しないが、ユーザーエージェントは両者間のメッセージ の機密性や真正性をある程度保証すべきである。

6.5 セキュアコンテキスト

Remote Playback APIは[SECURE-CONTEXTS]に限定されていない。 なぜならこのAPIは通常、ユーザーエージェントが ブラウジングコンテキスト に関係なく全てのメディアで提供する機能をWebアプリケーションに公開するためである。 ユーザーエージェントは[SECURE-CONTEXTS] にAPIの利用を制限でき、その場合はセキュアでないコンテキストでは 利用可能なリモート再生デバイスのリストを監視アルゴリズムで常に空のリストを返すことになる。

A. 勧告候補終了基準

本仕様を提案勧告へ進めるには、各機能について少なくとも二つの独立した相互運用可能な 実装が存在する必要がある。個々の機能は別々の製品によって実装されていてよく、 全ての機能を単一の製品が実装する必要はない。さらに、実装は メディアリモート及びメディアフリングのケースにも 対応している必要があり、同一製品内または別製品間で満たしてもよい。

これらの基準の目的上、次の用語を定義する：

独立
各実装は異なる事業者によって開発され、他の資格を満たす実装のコードを 共有・再利用・派生してはならない。本仕様の実装に関係しない コードの断片はこの要件から除外される。
相互運用可能
公式テストスイートの該当テストケースをパスすること。
実装
次を満たすユーザーエージェント：
  1. 仕様を実装していること
  2. 一般公開されていること。実装は出荷製品やβ版、プレビューリリース、 "nightly build"等の公開バージョンでよい。非出荷製品のリリースは 少なくとも1か月以上その機能を実装し、安定性を示している必要がある。
  3. 実験的でないこと（テストスイート通過のみを目的としたバージョンや 今後通常利用を想定しないものではないこと）。

B. 参考文献

B.1 規範的参照

[dom]
DOM Standard. Anne van Kesteren. WHATWG. Living Standard. URL: https://dom.spec.whatwg.org/
[HTML]
HTML Standard. Anne van Kesteren; Domenic Denicola; Ian Hickson; Philip Jägenstedt; Simon Pieters. WHATWG. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[PRESENTATION-API]
Presentation API. Mark Foltz; Dominik Röttsches. W3C. 16 October 2023. W3C Candidate Recommendation. URL: https://www.w3.org/TR/presentation-api/
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC8174]
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174
[WEBIDL]
Web IDL Standard. Edgar Chen; Timothy Gu. WHATWG. Living Standard. URL: https://webidl.spec.whatwg.org/

B.2 参考情報

[SECURE-CONTEXTS]
Secure Contexts. Mike West. W3C. 10 November 2023. W3C Candidate Recommendation. URL: https://www.w3.org/TR/secure-contexts/
[url]
URL Standard. Anne van Kesteren. WHATWG. Living Standard. URL: https://url.spec.whatwg.org/