forked from w3c/web-roadmaps
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathcontrol.html
45 lines (44 loc) · 5.75 KB
/
control.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Playback controls</title>
</head>
<body>
<header>
<h1>Playback controls</h1>
<p>Media content provides many opportunities for rich interactions with users, either on- or off-device.</p>
</header>
<main>
<section class="featureset well-deployed">
<h2>Well-deployed technologies</h2>
<p data-feature="Control of one local media element">All the basic interactions one expects from a media player (play, pause, playback rate, etc.) are available in JavaScript via the <a data-featureid="htmlmediaelement"><code>HTMLMediaElement</code> interface</a> defined in HTML.</p>
<p data-feature="Audio control">The <a data-featureid="webaudio">Web Audio API</a> defines a full-fledged audio processing API that gives precise control over the playback of audio content.</p>
<p data-feature="Control position in media timeline when sharing">Users often want to control the position at which to start a video (or an audio) feed when they share media content with friends on social networks. The <a data-featureid="media-frags">Media Fragments URI</a> specification defines a syntax for constructing media fragment URIs and explains how Web browsers can use this information to jump to the right position in the media timeline.</p>
</section>
<section class="featureset in-progress">
<h2>Specifications in progress</h2>
<p data-feature="Key-based control">A number of media-capable devices expose specific hardware keys and buttons to facilitate control of playing media; the <a data-featureid="mediakeys">Media Keys in DOM Level 3 events</a> specification exposes these interactions to Web-based players.</p>
<p data-feature="Virtual reality control">For immersive media experiences enabled by Virtual Reality headsets, media content needs to be adjusted based on the viewer’s head position, orientation and velocity. The work on the <a data-featureid="webxr">WebXR Device API</a> (formerly <em>WebVR</em>) specification addresses this need. The specification also exposes user input mechanisms used in such scenarios.</p>
</section>
<section class="featureset exploratory-work">
<h2>Exploratory work</h2>
<p data-feature="OS-wide media control">In any given Web application, media playback can be in competition with media playback from other applications, and the underlying operating system is in charge of determining which of these applications should have the media focus. The <a data-featureid="mediasession">Media Session</a> specification would expose these changes of focus to Web applications.</p>
<p data-feature="Tuner control">Devices which can access broadcast content need to offer ways to select which broadcast signal to play; the <a data-featureid="tvtuner">TV Control API</a> is an attempt to provide such an interface for broadcast TV and radio. The API also exposes the Electronic Program Guide when it is streamed with the media content, and explores ways to expose applications embedded in media streams as is common in interactive TV platforms (ATSC, HbbTV, Hybridcast). This work has been discontinued for lack of interest to the API as specified among potential implementers. Discussions on scope, use cases and requirements for these features have now moved to the <a href="https://www.w3.org/2011/webtv">Media and Entertainment Interest Group</a>.</p>
<p data-feature="Multi-device media control">The Multi-Device Timing Community Group is exploring media control across devices: its <a data-featureid="timing">Timing Object</a> specification enables coordinatinatgion of the playback of multiple video, audio and other data streams in close synchrony, within a single device and across devices, independently of the network topology. This proposal would replace and extend the <code>MediaController</code> interface, which was dropped from HTML for lack of implementations.</p>
<p data-feature="User Interface">Remote controllers and gamepads are commonly used to navigate <i>ten-foot user interfaces</i> on televisions. They usually feature 4-way keys, which make them particularly suitable for 2D navigation, where focus moves between focusable elements based on their position on the screen. This behavior can be achieved through JavaScript to some extent, but cannot cater for all cases and negatively impacts performance due to the need to access the DOM repeatedly. The <a data-featureid="spatial-navigation">Spatial navigation</a> proposal explores APIs and extensions to CSS for this navigation paradigm to be supported across browsers.</p>
<div data-feature="Autoplay">
<p>To preserve bandwidth, memory and battery on mobile, and prevent possibly unwanted media playback, browsers have put autoplay policies into place and may deny automated playback of media content. The <a data-featureid="autoplay">Autoplay Policy</a> is an early proposal to let applications know whether autoplay will succeed for a given media element.</p>
</div>
</section>
<section>
<h2>Features not covered by ongoing work</h2>
<dl>
<dt>360° video controls</dt>
<dd>To render 360° videos, applications can either rely on native support for 360° video codecs from web browsers and stick to integrated controls, or they can provide their own controls but then need to handle the underlying projection logic and adaptive streaming programmatically. Exposing controls for 360° videos on the <code>HTMLMediaElement</code> interface would allow applications to customize the user experience and still take advantage of native 360° video playback support when available.</dd>
</dl>
</section>
</main>
<script src="../js/generate.js"></script>
</body>
</html>