Include <audio> in protocol for Remote Playback API

[chrisn]

Item 4 under Scope of Work says "for the specific case of remotely playing a <video> element". Is there any reason not to include <audio>, as the receiving side of the Remote Playback API could be implemented on a headless device, for example.

[anssiko]

I believe this text:

[...] for the specific case of remotely playing a <video> element with a src or sources URL media source on a presentation display.

... was added to clarify the scope vis-à-vis what is noted in out of scope (MSE, EME):

Out of Scope

[...]

• Protocols that implement the Remote Playback API for HTML media that uses Media Source Extensions or Encrypted Media Extensions are not in scope.

We can do a simple corrections to the charter to address this issue without the formal charter amendment process. Please feel free to propose text.

[chrisn]

Many thanks, Anssi. I propose the following:

... for the specific case of remotely playing a <video> or <audio> element with a src or sources URL media source on a presentation display or remote playback device.

The intent is for remote audio playback to be in scope for the CG. Note that I'm not suggesting any change with respect to MSE or EME.

[anssiko]

Since both src and sources are not not video-specific, but properties of a media element, I'd say this clarification can be considered a simple correction that we can make easily.

@mfoltzgoogle does the proposed text sound fine? (I think you authored the original part of the text.)

[mfoltzgoogle]

SGTM.

[anssiko]

Fixed with a21e396. This is a simple correction, and as such no voting required for this charter change. If anyone has concerns with this correction, please reopen this issue.