- From: Mercurial notifier <cvsmail@w3.org>
- Date: Mon, 27 Feb 2012 16:36:25 +0000
- To: public-dap-commits@w3.org
changeset: 64:af279f9448d5
tag: tip
user: Robin Berjon <robin@berjon.com>
date: Mon Feb 27 17:36:19 2012 +0100
files: media-stream-capture/FPWD.html
description:
FPWD
diff -r f42d59a0cf6e -r af279f9448d5 media-stream-capture/FPWD.html
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/media-stream-capture/FPWD.html Mon Feb 27 17:36:19 2012 +0100
@@ -0,0 +1,1552 @@
+<!DOCTYPE html PUBLIC '-//W3C//DTD HTML 4.01 Transitional//EN' 'http://www.w3.org/TR/html4/loose.dtd'>
+<html lang="en" dir="ltr">
+<head>
+ <title>MediaStream Capture Scenarios</title>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
+
+
+
+ <style type="text/css">
+ /* ReSpec.js CSS optimizations (Richard Tibbett) - cut-n-paste :) */
+ div.example {
+ border-top: 1px solid #ff4500;
+ border-bottom: 1px solid #ff4500;
+ background: #fff;
+ padding: 1em;
+ font-size: 0.9em;
+ margin-top: 1em;
+ }
+ div.example::before {
+ content: "Example";
+ display: block;
+ width: 150px;
+ background: #ff4500;
+ color: #fff;
+ font-family: initial;
+ padding: 3px;
+ padding-left: 5px;
+ font-weight: bold;
+ margin: -1em 0 1em -1em;
+ }
+
+ /* Clean up pre.idl */
+ pre.idl::before {
+ font-size:0.9em;
+ }
+
+ /* Add better spacing to sections */
+ section, .section {
+ margin-bottom: 2em;
+ }
+
+ /* Reduce note & issue render size */
+ .note, .issue {
+ font-size:0.8em;
+ }
+
+ /* Add addition spacing to <ol> and <ul> for rule definition */
+ ol.rule li, ul.rule li {
+ padding:0.2em;
+ }
+ </style>
+ <style type="text/css">
+/*****************************************************************
+ * ReSpec CSS
+ * Robin Berjon (robin at berjon dot com)
+ * v0.05 - 2009-07-31
+ *****************************************************************/
+
+
+/* --- INLINES --- */
+em.rfc2119 {
+ text-transform: lowercase;
+ font-variant: small-caps;
+ font-style: normal;
+ color: #900;
+}
+
+h1 acronym, h2 acronym, h3 acronym, h4 acronym, h5 acronym, h6 acronym, a acronym,
+h1 abbr, h2 abbr, h3 abbr, h4 abbr, h5 abbr, h6 abbr, a abbr {
+ border: none;
+}
+
+dfn {
+ font-weight: bold;
+}
+
+a.internalDFN {
+ color: inherit;
+ border-bottom: 1px solid #99c;
+ text-decoration: none;
+}
+
+a.externalDFN {
+ color: inherit;
+ border-bottom: 1px dotted #ccc;
+ text-decoration: none;
+}
+
+a.bibref {
+ text-decoration: none;
+}
+
+code {
+ color: #ff4500;
+}
+
+
+/* --- WEB IDL --- */
+pre.idl {
+ border-top: 1px solid #90b8de;
+ border-bottom: 1px solid #90b8de;
+ padding: 1em;
+ line-height: 120%;
+}
+
+pre.idl::before {
+ content: "WebIDL";
+ display: block;
+ width: 150px;
+ background: #90b8de;
+ color: #fff;
+ font-family: initial;
+ padding: 3px;
+ font-weight: bold;
+ margin: -1em 0 1em -1em;
+}
+
+.idlType {
+ color: #ff4500;
+ font-weight: bold;
+ text-decoration: none;
+}
+
+/*.idlModule*/
+/*.idlModuleID*/
+/*.idlInterface*/
+.idlInterfaceID, .idlDictionaryID {
+ font-weight: bold;
+ color: #005a9c;
+}
+
+.idlSuperclass {
+ font-style: italic;
+ color: #005a9c;
+}
+
+/*.idlAttribute*/
+.idlAttrType, .idlFieldType, .idlMemberType {
+ color: #005a9c;
+}
+.idlAttrName, .idlFieldName, .idlMemberName {
+ color: #ff4500;
+}
+.idlAttrName a, .idlFieldName a, .idlMemberName a {
+ color: #ff4500;
+ border-bottom: 1px dotted #ff4500;
+ text-decoration: none;
+}
+
+/*.idlMethod*/
+.idlMethType {
+ color: #005a9c;
+}
+.idlMethName {
+ color: #ff4500;
+}
+.idlMethName a {
+ color: #ff4500;
+ border-bottom: 1px dotted #ff4500;
+ text-decoration: none;
+}
+
+/*.idlParam*/
+.idlParamType {
+ color: #005a9c;
+}
+.idlParamName {
+ font-style: italic;
+}
+
+.extAttr {
+ color: #666;
+}
+
+/*.idlConst*/
+.idlConstType {
+ color: #005a9c;
+}
+.idlConstName {
+ color: #ff4500;
+}
+.idlConstName a {
+ color: #ff4500;
+ border-bottom: 1px dotted #ff4500;
+ text-decoration: none;
+}
+
+/*.idlException*/
+.idlExceptionID {
+ font-weight: bold;
+ color: #c00;
+}
+
+.idlTypedefID, .idlTypedefType {
+ color: #005a9c;
+}
+
+.idlRaises, .idlRaises a.idlType, .idlRaises a.idlType code, .excName a, .excName a code {
+ color: #c00;
+ font-weight: normal;
+}
+
+.excName a {
+ font-family: monospace;
+}
+
+.idlRaises a.idlType, .excName a.idlType {
+ border-bottom: 1px dotted #c00;
+}
+
+.excGetSetTrue, .excGetSetFalse, .prmNullTrue, .prmNullFalse, .prmOptTrue, .prmOptFalse {
+ width: 45px;
+ text-align: center;
+}
+.excGetSetTrue, .prmNullTrue, .prmOptTrue { color: #0c0; }
+.excGetSetFalse, .prmNullFalse, .prmOptFalse { color: #c00; }
+
+.idlImplements a {
+ font-weight: bold;
+}
+
+dl.attributes, dl.methods, dl.constants, dl.fields, dl.dictionary-members {
+ margin-left: 2em;
+}
+
+.attributes dt, .methods dt, .constants dt, .fields dt, .dictionary-members dt {
+ font-weight: normal;
+}
+
+.attributes dt code, .methods dt code, .constants dt code, .fields dt code, .dictionary-members dt code {
+ font-weight: bold;
+ color: #000;
+ font-family: monospace;
+}
+
+.attributes dt code, .fields dt code, .dictionary-members dt code {
+ background: #ffffd2;
+}
+
+.attributes dt .idlAttrType code, .fields dt .idlFieldType code, .dictionary-members dt .idlMemberType code {
+ color: #005a9c;
+ background: transparent;
+ font-family: inherit;
+ font-weight: normal;
+ font-style: italic;
+}
+
+.methods dt code {
+ background: #d9e6f8;
+}
+
+.constants dt code {
+ background: #ddffd2;
+}
+
+.attributes dd, .methods dd, .constants dd, .fields dd, .dictionary-members dd {
+ margin-bottom: 1em;
+}
+
+table.parameters, table.exceptions {
+ border-spacing: 0;
+ border-collapse: collapse;
+ margin: 0.5em 0;
+ width: 100%;
+}
+table.parameters { border-bottom: 1px solid #90b8de; }
+table.exceptions { border-bottom: 1px solid #deb890; }
+
+.parameters th, .exceptions th {
+ color: #fff;
+ padding: 3px 5px;
+ text-align: left;
+ font-family: initial;
+ font-weight: normal;
+ text-shadow: #666 1px 1px 0;
+}
+.parameters th { background: #90b8de; }
+.exceptions th { background: #deb890; }
+
+.parameters td, .exceptions td {
+ padding: 3px 10px;
+ border-top: 1px solid #ddd;
+ vertical-align: top;
+}
+
+.parameters tr:first-child td, .exceptions tr:first-child td {
+ border-top: none;
+}
+
+.parameters td.prmName, .exceptions td.excName, .exceptions td.excCodeName {
+ width: 100px;
+}
+
+.parameters td.prmType {
+ width: 120px;
+}
+
+table.exceptions table {
+ border-spacing: 0;
+ border-collapse: collapse;
+ width: 100%;
+}
+
+/* --- TOC --- */
+.toc a {
+ text-decoration: none;
+}
+
+a .secno {
+ color: #000;
+}
+
+/* --- TABLE --- */
+table.simple {
+ border-spacing: 0;
+ border-collapse: collapse;
+ border-bottom: 3px solid #005a9c;
+}
+
+.simple th {
+ background: #005a9c;
+ color: #fff;
+ padding: 3px 5px;
+ text-align: left;
+}
+
+.simple th[scope="row"] {
+ background: inherit;
+ color: inherit;
+ border-top: 1px solid #ddd;
+}
+
+.simple td {
+ padding: 3px 10px;
+ border-top: 1px solid #ddd;
+}
+
+.simple tr:nth-child(even) {
+ background: #f0f6ff;
+}
+
+/* --- DL --- */
+.section dd > p:first-child {
+ margin-top: 0;
+}
+
+.section dd > p:last-child {
+ margin-bottom: 0;
+}
+
+.section dd {
+ margin-bottom: 1em;
+}
+
+.section dl.attrs dd, .section dl.eldef dd {
+ margin-bottom: 0;
+}
+
+/* --- EXAMPLES --- */
+pre.example {
+ border-top: 1px solid #ff4500;
+ border-bottom: 1px solid #ff4500;
+ padding: 1em;
+ margin-top: 1em;
+}
+
+pre.example::before {
+ content: "Example";
+ display: block;
+ width: 150px;
+ background: #ff4500;
+ color: #fff;
+ font-family: initial;
+ padding: 3px;
+ font-weight: bold;
+ margin: -1em 0 1em -1em;
+}
+
+/* --- EDITORIAL NOTES --- */
+.issue {
+ padding: 1em;
+ margin: 1em 0em 0em;
+ border: 1px solid #f00;
+ background: #ffc;
+}
+
+.issue::before {
+ content: "Issue";
+ display: block;
+ width: 150px;
+ margin: -1.5em 0 0.5em 0;
+ font-weight: bold;
+ border: 1px solid #f00;
+ background: #fff;
+ padding: 3px 1em;
+}
+
+.note {
+ margin: 1em 0em 0em;
+ padding: 1em;
+ border: 2px solid #cff6d9;
+ background: #e2fff0;
+}
+
+.note::before {
+ content: "Note";
+ display: block;
+ width: 150px;
+ margin: -1.5em 0 0.5em 0;
+ font-weight: bold;
+ border: 1px solid #cff6d9;
+ background: #fff;
+ padding: 3px 1em;
+}
+
+/* --- Best Practices --- */
+div.practice {
+ border: solid #bebebe 1px;
+ margin: 2em 1em 1em 2em;
+}
+
+span.practicelab {
+ margin: 1.5em 0.5em 1em 1em;
+ font-weight: bold;
+ font-style: italic;
+}
+
+span.practicelab { background: #dfffff; }
+
+span.practicelab {
+ position: relative;
+ padding: 0 0.5em;
+ top: -1.5em;
+}
+
+p.practicedesc {
+ margin: 1.5em 0.5em 1em 1em;
+}
+
+@media screen {
+ p.practicedesc {
+ position: relative;
+ top: -2em;
+ padding: 0;
+ margin: 1.5em 0.5em -1em 1em;
+ }
+}
+
+/* --- SYNTAX HIGHLIGHTING --- */
+pre.sh_sourceCode {
+ background-color: white;
+ color: black;
+ font-style: normal;
+ font-weight: normal;
+}
+
+pre.sh_sourceCode .sh_keyword { color: #005a9c; font-weight: bold; } /* language keywords */
+pre.sh_sourceCode .sh_type { color: #666; } /* basic types */
+pre.sh_sourceCode .sh_usertype { color: teal; } /* user defined types */
+pre.sh_sourceCode .sh_string { color: red; font-family: monospace; } /* strings and chars */
+pre.sh_sourceCode .sh_regexp { color: orange; font-family: monospace; } /* regular expressions */
+pre.sh_sourceCode .sh_specialchar { color: #ffc0cb; font-family: monospace; } /* e.g., \n, \t, \\ */
+pre.sh_sourceCode .sh_comment { color: #A52A2A; font-style: italic; } /* comments */
+pre.sh_sourceCode .sh_number { color: purple; } /* literal numbers */
+pre.sh_sourceCode .sh_preproc { color: #00008B; font-weight: bold; } /* e.g., #include, import */
+pre.sh_sourceCode .sh_symbol { color: blue; } /* e.g., *, + */
+pre.sh_sourceCode .sh_function { color: black; font-weight: bold; } /* function calls and declarations */
+pre.sh_sourceCode .sh_cbracket { color: red; } /* block brackets (e.g., {, }) */
+pre.sh_sourceCode .sh_todo { font-weight: bold; background-color: #00FFFF; } /* TODO and FIXME */
+
+/* Predefined variables and functions (for instance glsl) */
+pre.sh_sourceCode .sh_predef_var { color: #00008B; }
+pre.sh_sourceCode .sh_predef_func { color: #00008B; font-weight: bold; }
+
+/* for OOP */
+pre.sh_sourceCode .sh_classname { color: teal; }
+
+/* line numbers (not yet implemented) */
+pre.sh_sourceCode .sh_linenum { display: none; }
+
+/* Internet related */
+pre.sh_sourceCode .sh_url { color: blue; text-decoration: underline; font-family: monospace; }
+
+/* for ChangeLog and Log files */
+pre.sh_sourceCode .sh_date { color: blue; font-weight: bold; }
+pre.sh_sourceCode .sh_time, pre.sh_sourceCode .sh_file { color: #00008B; font-weight: bold; }
+pre.sh_sourceCode .sh_ip, pre.sh_sourceCode .sh_name { color: #006400; }
+
+/* for Prolog, Perl... */
+pre.sh_sourceCode .sh_variable { color: #006400; }
+
+/* for LaTeX */
+pre.sh_sourceCode .sh_italics { color: #006400; font-style: italic; }
+pre.sh_sourceCode .sh_bold { color: #006400; font-weight: bold; }
+pre.sh_sourceCode .sh_underline { color: #006400; text-decoration: underline; }
+pre.sh_sourceCode .sh_fixed { color: green; font-family: monospace; }
+pre.sh_sourceCode .sh_argument { color: #006400; }
+pre.sh_sourceCode .sh_optionalargument { color: purple; }
+pre.sh_sourceCode .sh_math { color: orange; }
+pre.sh_sourceCode .sh_bibtex { color: blue; }
+
+/* for diffs */
+pre.sh_sourceCode .sh_oldfile { color: orange; }
+pre.sh_sourceCode .sh_newfile { color: #006400; }
+pre.sh_sourceCode .sh_difflines { color: blue; }
+
+/* for css */
+pre.sh_sourceCode .sh_selector { color: purple; }
+pre.sh_sourceCode .sh_property { color: blue; }
+pre.sh_sourceCode .sh_value { color: #006400; font-style: italic; }
+
+/* other */
+pre.sh_sourceCode .sh_section { color: black; font-weight: bold; }
+pre.sh_sourceCode .sh_paren { color: red; }
+pre.sh_sourceCode .sh_attribute { color: #006400; }
+
+</style><link charset="utf-8" type="text/css" rel="stylesheet" href="http://www.w3.org/StyleSheets/TR/W3C-WD"></head>
+
+ <body style="display: inherit;"><div class="head"><p><a href="http://www.w3.org/"><img src="http://www.w3.org/Icons/w3c_home" alt="W3C" height="48" width="72"></a></p><h1 class="title" id="title">MediaStream Capture Scenarios</h1><h2 id="w3c-working-draft-27-february-2012"><acronym title="World Wide Web Consortium">W3C</acronym> Working Draft 27 February 2012</h2><dl><dt>This version:</dt><dd><a href="http://www.w3.org/TR/2012/WD-capture-scenarios-20120227/">http://www.w3.org/TR/2012/WD-capture-scenarios-20120227/</a></dd><dt>Latest published version:</dt><dd><a href="http://www.w3.org/TR/capture-scenarios/">http://www.w3.org/TR/capture-scenarios/</a></dd><dt>Editor:</dt><dd><a href="mailto:travis.leithead@microsoft.com?subject=MediaStream%20Capture%20Scenarios%20Feedback">Travis Leithead</a>, <a href="http://www.microsoft.com">Microsoft Corp.</a></dd>
+</dl><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2012 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.eu/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. <acronym title="World Wide Web Consortium">W3C</acronym> <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p><hr></div>
+ <div class="introductory section" id="abstract"><h2>Abstract</h2>
+ <p>
+ This document collates the target scenarios for the Media Capture task force. Scenarios represent
+ the set of expected functionality that may be achieved by the use of the MediaStream Capture API. A set of
+ un-supported scenarios may also be documented here.
+ </p>
+ <p>This document builds on the assumption that the mechanism for obtaining fundamental access to local media
+ capture device(s) is <code>navigator.getUserMedia</code> (name/behavior subject to this task force), and that
+ the vehicle for delivery of the content from the local media capture device(s) is a <code>MediaStream</code>.
+ Hence the title of this note.
+ </p>
+ </div><div id="sotd" class="introductory section"><h2>Status of This Document</h2><p><em>This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current <acronym title="World Wide Web Consortium">W3C</acronym> publications and the latest revision of this technical report can be found in the <a href="http://www.w3.org/TR/"><acronym title="World Wide Web Consortium">W3C</acronym> technical reports index</a> at http://www.w3.org/TR/.</em></p>
+ <p>
+ This document is intended to represent the consensus of the media capture task force on the set of scenarios
+ supported by the MediaStream Capture API.
+ </p>
+ <p>This document was published by the <a href="http://www.w3.org/2009/dap/">Device APIs Working Group</a> and <a href="http://www.w3.org/2011/04/webrtc/">Web Real-Time Communications Working Group</a> as a First Public Working Draft. This document is intended to become a <acronym title="World Wide Web Consortium">W3C</acronym> Recommendation. If you wish to make comments regarding this document, please send them to <a href="mailto:public-media-capture@w3.org">public-media-capture@w3.org</a> (<a href="mailto:public-media-capture-request@w3.org?subject=subscribe">subscribe</a>, <a href="http://lists.w3.org/Archives/Public/public-media-capture/">archives</a>). All feedback is welcome.</p><p>Publication as a Working Draft does not imply endorsement by the <acronym title="World Wide Web Consortium">W3C</acronym> Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.</p><p>This doument was produced by a group operating under the <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 <acronym title="World Wide Web Consortium">W3C</acronym> Patent Policy</a>. <acronym title="World Wide Web Consortium">W3C</acronym> maintains a public list of any patent disclosures (<a href="http://www.w3.org/2004/01/pp-impl/43696/status" rel="disclosure">Device APIs Working Group</a>, <a href="http://www.w3.org/2004/01/pp-impl/47318/status" rel="disclosure">Web Real-Time Communications Working Group</a>) made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential Claim(s)</a> must disclose the information in accordance with <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section 6 of the <acronym title="World Wide Web onsortium">W3C</acronym> Patent Policy</a>.</p></div><div class="section" id="toc"><h2 class="introductory">Table of Contents</h2><ul class="toc"><li class="tocline"><a class="tocxref" href="#introduction"><span class="secno">1. </span>Introduction</a></li><li class="tocline"><a class="tocxref" href="#scenarios"><span class="secno">2. </span>Scenarios</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#check-out-this-new-hat----photo-upload-with-audio-caption"><span class="secno">2.1 </span>"Check out this new hat!" (photo upload with audio caption)</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#variations"><span class="secno">2.1.1 </span>Variations</a></li></ul></li><li class="tocline"><a class="tocxref" href="#election-podcast-and-commentary--video-capture-and-chat"><span class="secno">2.2 </span>Election podcast and commentary (video capture and chat)</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#variations-1"><span class="secno">2.2.1 </span>Variations<a></li></ul></li><li class="tocline"><a class="tocxref" href="#find-the-ball-assignment--video-effects-and-upload-requirements"><span class="secno">2.3 </span>Find the ball assignment (video effects and upload requirements)</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#variations-2"><span class="secno">2.3.1 </span>Variations</a></li></ul></li><li class="tocline"><a class="tocxref" href="#video-diary-at-the-coliseum--multiple-webcams-and-error-handling"><span class="secno">2.4 </span>Video diary at the Coliseum (multiple webcams and error handling)</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#variations-3"><span class="secno">2.4.1 </span>Variations</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#recording-a-sports-event--simultaneous-capture-from-multiple-webcams"><span class="secno">2.4.1.1 </span>Recording a sports event (simultaneous capture from multiple webcams)</a></li><li class="tocline"><a class="tocxref" href="#picture-in-picture--capture-a-cmposed-video"><span class="secno">2.4.1.2 </span>Picture-in-picture (capture a composed video)</a></li></ul></li></ul></li><li class="tocline"><a class="tocxref" href="#conference-call-product-debate--multiple-conversations-and-capture-review"><span class="secno">2.5 </span>Conference call product debate (multiple conversations and capture review)</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#variations-4"><span class="secno">2.5.1 </span>Variations</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#showcase-demo-on-local-screen--screen-as-an-local-media-input-source"><span class="secno">2.5.1.1 </span>Showcase demo on local screen (screen as an local media input source)</a></li></ul></li></ul></li><li class="tocline"><a class="tocxref" href="#incident-on-driver-download-page--device-fingerprinting-with-malicious-intent"><span class="secno">2.6 </span>Incident on driver-download page (device fingerprinting with malicious intent)</a><ul class="toc"><li class="tocline"><a clas="tocxref" href="#variations-5"><span class="secno">2.6.1 </span>Variations</a></li></ul></li></ul></li><li class="tocline"><a class="tocxref" href="#requirements"><span class="secno">3. </span>Requirements</a></li><li class="tocline"><a class="tocxref" href="#concepts-and-definitions"><span class="secno">4. </span>Concepts and Definitions</a></li><li class="tocline"><a class="tocxref" href="#design-considerations-and-remarks"><span class="secno">5. </span>Design Considerations and Remarks</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#stream-initialization"><span class="secno">5.1 </span>Stream initialization</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#privacy"><span class="secno">5.1.1 </span>Privacy</a></li><li class="tocline"><a class="tocxref" href="#issues"><span class="secno">5.1.2 </span>Issues</a></li></ul></li><li class="tocline"><a class="tocxref" href="#stream-re-initialization"><span class="secno">5.2 </span>Stream re-initialization</a><ul class="toc"><li lass="tocline"><a class="tocxref" href="#issues-1"><span class="secno">5.2.1 </span>Issues</a></li></ul></li><li class="tocline"><a class="tocxref" href="#preview-a-stream"><span class="secno">5.3 </span>Preview a stream</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#issues-2"><span class="secno">5.3.1 </span>Issues</a></li></ul></li><li class="tocline"><a class="tocxref" href="#stopping-local-devices"><span class="secno">5.4 </span>Stopping local devices</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#issues-3"><span class="secno">5.4.1 </span>Issues</a></li></ul></li><li class="tocline"><a class="tocxref" href="#pre-processing"><span class="secno">5.5 </span>Pre-processing</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#examples"><span class="secno">5.5.1 </span>Examples</a></li><li class="tocline"><a class="tocxref" href="#issues-4"><span class="secno">5.5.2 </span>Issues</a></li></ul></li><li class="tocline"><a class="tocxref" href="#post-processing"><pan class="secno">5.6 </span>Post-processing</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#web-platform-post-processing-toolbox"><span class="secno">5.6.1 </span>Web platform post-processing toolbox</a></li><li class="tocline"><a class="tocxref" href="#time-sensitivity-and-performance"><span class="secno">5.6.2 </span>Time sensitivity and performance</a></li><li class="tocline"><a class="tocxref" href="#examples-1"><span class="secno">5.6.3 </span>Examples</a></li></ul></li><li class="tocline"><a class="tocxref" href="#device-selection"><span class="secno">5.7 </span>Device Selection</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#privacy-1"><span class="secno">5.7.1 </span>Privacy</a></li><li class="tocline"><a class="tocxref" href="#issues-5"><span class="secno">5.7.2 </span>Issues</a></li></ul></li><li class="tocline"><a class="tocxref" href="#change-user-selected-device-capabilities"><span class="secno">5.8 </span>Change user-selected device capabilities</a><ul class=toc"><li class="tocline"><a class="tocxref" href="#issues-6"><span class="secno">5.8.1 </span>Issues</a></li></ul></li><li class="tocline"><a class="tocxref" href="#multiple-active-devices"><span class="secno">5.9 </span>Multiple active devices</a></li><li class="tocline"><a class="tocxref" href="#capturing-a-media-stream"><span class="secno">5.10 </span>Capturing a media stream</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#dvr-scenarios"><span class="secno">5.10.1 </span>DVR Scenarios</a></li><li class="tocline"><a class="tocxref" href="#issues-7"><span class="secno">5.10.2 </span>Issues</a></li></ul></li><li class="tocline"><a class="tocxref" href="#selection-of-a-capture-method"><span class="secno">5.11 </span>Selection of a capture method</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#format-detection"><span class="secno">5.11.1 </span>Format detection</a></li></ul></li><li class="tocline"><a class="tocxref" href="#programmatic-activation-of-camera-app"><span class="ecno">5.12 </span>Programmatic activation of camera app</a></li><li class="tocline"><a class="tocxref" href="#take-a-picture"><span class="secno">5.13 </span>Take a picture</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#issues-8"><span class="secno">5.13.1 </span>Issues</a></li></ul></li><li class="tocline"><a class="tocxref" href="#picture-tracks"><span class="secno">5.14 </span>Picture tracks</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#issues-9"><span class="secno">5.14.1 </span>Issues</a></li></ul></li><li class="tocline"><a class="tocxref" href="#caption-tracks"><span class="secno">5.15 </span>Caption Tracks</a></li></ul></li><li class="tocline"><a class="tocxref" href="#acknowledgements"><span class="secno">6. </span>Acknowledgements</a></li><li class="tocline"><a class="tocxref" href="#references"><span class="secno">A. </span>References</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#normative-references"><span class="secno">A.1 </span>Normativereferences</a></li><li class="tocline"><a class="tocxref" href="#informative-references"><span class="secno">A.2 </span>Informative references</a></li></ul></li></ul></div>
+
+
+
+
+ <div id="introduction" class="informative section">
+ <!--OddPage--><h2><span class="secno">1. </span>Introduction</h2><p><em>This section is non-normative.</em></p>
+ <p>
+ One of the goals of the joint task force between the Device and Policy working group and the Web Real Time
+ Communications working groups is to bring media capture scenarios from both groups together into one unified
+ API that can address all relevant use cases.
+ </p>
+ <p>
+ The capture scenarios from WebRTC are primarily driven from real-time-communication-based scenarios, such as
+ capturing live chats, teleconferences, and other media streamed from over the network from potentially
+ multiple sources.
+ </p>
+ <p>
+ The capture scenarios from DAP represent "local" capture scenarios that providing access to a user agent's
+ camera and other related experiences.
+ </p>
+ <p>
+ Both groups include overlapping chartered deliverables in this space. Namely in DAP,
+ <a href="http://www.w3.org/2009/05/DeviceAPICharter">the charter specifies a recommendation-track deliverable</a>:
+ </p><ul>
+ <li>
+ <dt>Camera API</dt>
+ <dd>an API to manage a device's camera e.g. to take a picture</dd>
+ </li>
+ </ul>
+ <p></p>
+ <p>
+ And <a href="http://www.w3.org/2011/04/webrtc-charter.html">WebRTC's charter scope</a> describes enabling
+ real-time communications between web browsers that will require specific client-side technologies:
+ </p><ul>
+ <li>API functions to explore device capabilities, e.g. camera, microphone, speakers (currently in scope
+ for the <a href="http://www.w3.org/2009/dap/">Device APIs & Policy Working Group</a>)</li>
+ <li>API functions to capture media from local devices (camera and microphone) (currently in scope for the
+ <a href="http://www.w3.org/2009/dap/">Device APIs & Policy Working Group</a>)</li>
+ <li>API functions for encoding and other processing of those media streams,</li>
+ <li>API functions for decoding and processing (including echo cancelling, stream synchronization and a
+ number of other functions) of those streams at the incoming end,</li>
+ <li>Delivery to the user of those media streams via local screens and audio output devices (partially
+ covered with HTML5)</li>
+ </ul>
+ <p></p>
+ <p>
+ Note, that the scenarios described in this document specifically exclude declarative capture scenarios, such as those where media capture can be
+ obtained and submitted to a server entirely without the use of script. Such scenarios generally involve the use
+ of a UA-specific app or mode for interacting with the capture device, altering settings and completing the
+ capture. Such scenarios are currently captured by the DAP working group's <a href="http://dev.w3.org/2009/dap/camera/">HTML Media Capture</a>
+ specification.
+ </p>
+ <p>
+ The scenarios contained in this document are specific to scenarios in which web applications require direct access
+ to the capture device, its settings, and the capture mechanism and output. Such scenarios are
+ crucial to building applications that can create a site-specific look-and-feel to the user's interaction with the
+ capture device, as well as utilize advanced functionality that may not be available in a declarative model.
+ </p>
+ <p>
+ Some of the scenarios described in this document may overlap existing
+ <a href="http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-06">usage scenarios</a>
+ defined by the <a href="http://datatracker.ietf.org/wg/rtcweb/">IETF RTCWEB Working Group</a>. This document
+ is specifically focused on the capture aspects of media streams, while the linked document is geared toward
+ networking and peer-to-peer RTC scenarios.
+ </p>
+ </div>
+
+ <div class="section" id="scenarios">
+ <!--OddPage--><h2><span class="secno">2. </span>Scenarios</h2>
+ <p>
+ In this section, scenarios are presented first as a story that puts the scenario into perspective, and then
+ as a list of specific capture scenarios included in the story.
+ </p>
+
+ <div class="section" id="check-out-this-new-hat----photo-upload-with-audio-caption">
+ <h3><span class="secno">2.1 </span>"Check out this new hat!" (photo upload with audio caption)</h3>
+ <p>
+ Amy logs in to her favorite social networking page. She wants to tell her friends about a new hat she recently
+ bought for an upcoming school play. She clicks a "select photo" drop-down widget on the site, and choses the
+ "from webcam" option. A blank video box appears on the site followed by a notice from the browser to "allow the
+ use of the webcam". She approves it (just like she did the last time she used her camera on this site), and immediately sees her own image as viewed by her webcam. She then hears
+ an audio countdown starting from "3", giving her time to adjust herself in the video frame so that her hat is
+ clearly visible. After the countdown reaches "0", the captured image is displayed along with some controls with
+ which to resize/crop the image. She crops the image so that it just showcases her hat. She then clicks a button
+ allowing her to record an "audio caption". A small box with an audio meter appears, immediately followed by
+ another prompt from her browser to "allow the use of the microphone". After approving it, she sees an indicator
+ showing that the microphone is listening, and then begins describing the features of her new hat. While she
+ speaks she sees that the microphone is picking up her voice because the audio meter is reacting to her voice.
+ She stops talking and after a moment the web page asks her to confirm that she's done with her caption. She
+ confirms that she is finished, and then clicks on "check in" which uploads her new picture and audio caption to
+ the social networking site's server.
+ </p>
+ <ol>
+ <li>Browser requires webcam and microphone permissions (one-time-use example)</li>
+ <li>Local webcam video preview</li>
+ <li>Image capture from webcam</li>
+ <li>Image resizing after capture (scenario out of scope)</li>
+ <li>Local microphone preview via equalizer visualization</li>
+ <li>Local microphone stops capturing automatically after a period of silence</li>
+ <li>Upload captured image and audio to server</li>
+ </ol>
+
+ <div class="section" id="variations">
+ <h4><span class="secno">2.1.1 </span>Variations</h4>
+ <p>TBD</p>
+ </div>
+ </div>
+
+ <div class="section" id="election-podcast-and-commentary--video-capture-and-chat">
+ <h3><span class="secno">2.2 </span>Election podcast and commentary (video capture and chat)</h3>
+ <p>
+ Every Wednesday at 6:45pm, Adam logs into his video podcast web site for his scheduled 7pm half-hour broadcast
+ "commentary on the US election campaign". These podcasts are available to all his subscribers the next day, but
+ a few of his friends tune-in at 7 to listen to the podcast live. Adam selects the "prepare podcast" option,
+ is notified by the browser that he previously approved access to his webcam and microphone, and situates himself in front of the
+ webcam, using the "self-view" video window on the site. While waiting for 7pm to arrive, the video podcast site
+ indicates that two of his close friends are now online. He approves their request to listen live to the podcast.
+ Finally, at 7pm he selects "start podcast" and launches into his commentary. While capturing locally, Adam switches
+ between several tabs in his browser to quote from web sites representing differing political views. Half-hour later, he wraps up his
+ concluding remarks, and opens the discussion up for comments. One of his friends has a comment, but has
+ requested anonymity, since the comments on the show are also recorded. Adam enables the audio-only setting for
+ that friend and directs him to share his comment. In response to the first comment another of Adam's friends
+ wants to respond. This friend has not requested anonymity, and so Adam enables the audio/video mode for that
+ friend, and hears the rebuttal. After a few back-and-forths, Adam sees that his half-hour is up, thanks his
+ audience, and clicks "end podcast". A few moments later that site reports that the podcast has been uploaded.
+ </p>
+ <ol>
+ <li>Browser persisted webcam and microphone permissions</li>
+ <li>Local webcam video preview</li>
+ <li>Approval/authentication before sending/receiving real-time video between browsers</li>
+ <li>Remote connection video + audio preview</li>
+ <li>Video capture from local webcam + microphone</li>
+ <li>Capture combined audio from local microphone/remote connections</li>
+ <li>Persisting the capture while in a background tab</li>
+ <li>Disabling video on a video+audio remote connection</li>
+ <li>Switching a running video+audio capture between local/remote connection without interruption</li>
+ <li>Adding an video+audio remote connection to a running video capture</li>
+ <li>Upload of video/audio capture to server while capture is running</li>
+ </ol>
+
+ <div class="section" id="variations-1">
+ <h4><span class="secno">2.2.1 </span>Variations</h4>
+ <p>TBD</p>
+ </div>
+ </div>
+
+ <div class="section" id="find-the-ball-assignment--video-effects-and-upload-requirements">
+ <h3><span class="secno">2.3 </span>Find the ball assignment (video effects and upload requirements)</h3>
+ <p>
+ Alice is finishing up a college on-line course on image processing, and for the assignment she has to write
+ code that finds a blue ball in each video frame and draws a box around it. She has just finished testing her
+ code in the browser using her webcam to provide the input and the canvas element to draw the box around each
+ frame of the video input. To finish the assignment, she must upload a video to the assignment page, which
+ requires uploads to have a specific encoding (to make it easier for the TA to review and grade all the
+ videos) and to be no larger than 50MB (small camera resolutions are recommended) and no longer than 30
+ seconds. Alice is now ready; she enables the webcam, a video preview (to see herself), changes the camera's
+ resolution down to 320x200, starts a video capture, and holds up the blue ball, moving it around to show that
+ the image-tracking code is working. After recording for 30 seconds, Alice uploads the video to the assignment
+ upload page using her class account.
+ </p>
+ <ol>
+ <li>Image frames can be extracted from local webcam video</li>
+ <li>Modified image frames can be inserted/combined into a video capture</li>
+ <li>Assign (and check for) a specific video capture encoding format</li>
+ <li>Local webcam video preview</li>
+ <li>Enforce (or check for) video capture size constraints and recording time limits</li>
+ <li>Set the webcam into a low-resolution (320x200 or as supported by the hardware) capture mode</li>
+ <li>Captured video format is available for upload prerequisite inspection.</li>
+ </ol>
+
+ <div class="section" id="variations-2">
+ <h4><span class="secno">2.3.1 </span>Variations</h4>
+ <p>TBD</p>
+ </div>
+ </div>
+
+ <div class="section" id="video-diary-at-the-coliseum--multiple-webcams-and-error-handling">
+ <h3><span class="secno">2.4 </span>Video diary at the Coliseum (multiple webcams and error handling)</h3>
+ <p>
+ Albert is on vacation in Italy. He has a device with a front and rear webcam, and a web application that lets
+ him document his trip by way of a video diary. After arriving at the Coliseum, he launches his video diary
+ app. There is no internet connection to his device. The app asks Albert which of his microphones and
+ webcams he'd like to use, and he activates both webcams (front and rear). Two video elements appear side-by-side
+ in the app. Albert uses his device to capture a few still shots of the Coliseum using the rear camera, then
+ starts recording a video, selecting the front-facing webcam to begin explaining where he is. While talking,
+ he selects the rear-facing webcam to capture a video of the Coliseum (without having to turn his device
+ around), and then switches back to the front-facing camera to continue checking in for his diary entry.
+ Albert has a lot to say about the Coliseum, but before finishing, his device warns him that the battery is
+ about to expire. At the same time, the device shuts down the cameras and microphones to conserve battery power.
+ Later, after plugging in his device at a coffee shop, Albert returns to his diary app and notes that his
+ recording from the Coliseum was saved.
+ </p>
+ <ol>
+ <li>Web app presents multiple webcams and microphones for activation</li>
+ <li>Local video previews from two separate webcams simultaneously</li>
+ <li>Image capture from webcam (high resolution)</li>
+ <li>Video capture from local webcam + microphone</li>
+ <li>Switching a running video+audio capture between two local webcams without interruption</li>
+ <li>Use of battery status to automatically manage video and audio capture</li>
+ <li>Recording termination (error recovery) when camera(s) stop.</li>
+ </ol>
+
+ <div class="section" id="variations-3">
+ <h4><span class="secno">2.4.1 </span>Variations</h4>
+ <div class="section" id="recording-a-sports-event--simultaneous-capture-from-multiple-webcams">
+ <h5><span class="secno">2.4.1.1 </span>Recording a sports event (simultaneous capture from multiple webcams)</h5>
+ <p>Albert's day job is a sports commentator. He works for a local television station and records the local
+ hockey games at various schools. Albert uses a web-based front-end on custom hardware that allows him to connect
+ three cameras covering various angles of the game and a microphone with which he is running the commentary.
+ The application records all of these cameras at once. After the game, Albert prepares the game highlights. He
+ likes to highlight great plays by showing them from multiple angles. The final composited video is shown on the
+ evening news.
+ </p>
+ <ol>
+ <li>Capture from three cameras + microphone at the same time (to separate captures)</li>
+ </ol>
+ </div>
+ <div class="section" id="picture-in-picture--capture-a-composed-video">
+ <h5><span class="secno">2.4.1.2 </span>Picture-in-picture (capture a composed video)</h5>
+ <p>While still on his Italy vacation, Albert hears that the Pope might make a public appearance at the vatican. Albert
+ arrives early to claim a spot, and starts his video diary. He activates both front and rear cameras so that he can
+ capture both himself and the camera's view. He then sets up the view in his video diary so that the front-facing camera
+ displays in a small frame contained in one corner of the larger rear-facing camera's view rectangle (picture-in-picture).
+ Albert excitely describes the sense of the crowd around him while simultaneously capturing the Pope's appearance. Afterward,
+ Albert is happy that he didn't miss the moment by having to switch between cameras.
+ </p>
+ <ol>
+ <li>Preview two webcams at the same time</li>
+ <li>Combining two webcams + microphone into one capture</li>
+ </ol>
+ </div>
+ </div>
+ </div>
+
+ <div class="section" id="conference-call-product-debate--multiple-conversations-and-capture-review">
+ <h3><span class="secno">2.5 </span>Conference call product debate (multiple conversations and capture review)</h3>
+ <p>
+ As part of a routine business video conference call, Amanda initiates a connection to the five other field
+ agents in her company via the company's video call web site. Amanda is the designated scribe and archivist;
+ she is responsible for keeping the meeting minutes and also saving the associated meeting video for later
+ archiving. As each field agent connects to the video call web site, and after granting permission, their
+ video feed is displayed on the site. After the five other field agents checkin, Amanda calls the meeting to
+ order and starts the meeting recorder. The recorder captures all participant's audio, and selects a video
+ channel to record based on dominance of the associated video channel's audio input level. As the meeting
+ continues, several product prototypes are discussed. One field agent has created draft product sketch that
+ he shows to the group by sending the image over his video feed. This image spurs a fast-paced debate and
+ Amanda misses several of the participant's discussion points in the minutes. She calls for a point of order,
+ and requests that the participants wait while she catches up. Amanda pauses the recording, rewinds it by
+ thirty seconds, and then re-plays it in order to catch the parts of the debate that she missed in the
+ minutes. When done, she resumes the recording and the meeting continues. Toward the end of the meeting, one
+ field agent leaves early and his call is terminated.
+ </p>
+ <ol>
+ <li>Approval/authentication before sending/receiving real-time video between browsers</li>
+ <li>Remote connection video + audio preview</li>
+ <li>Browser requires webcam(s) and microphone permissions before use</li>
+ <li>Local webcam video preview</li>
+ <li>Video capture from local webcam + microphone</li>
+ <li>Video capture from remote connections (audio + video)</li>
+ <li>Capture combined audio from local microphone/remote connections</li>
+ <li>Comparing audio input level from among various local/remote connections</li>
+ <li>Switching a running video+audio capture between local webcam/remote connections without interruption</li>
+ <li>Send an image through a remote [video] connection</li>
+ <li>Pause/resume video+audio capture</li>
+ <li>Rewind captured video and re-play</li>
+ <li>Remote connection termination and removal of video+audio preview</li>
+ </ol>
+
+ <div class="section" id="variations-4">
+ <h4><span class="secno">2.5.1 </span>Variations</h4>
+ <div class="section" id="showcase-demo-on-local-screen--screen-as-an-local-media-input-source">
+ <h5><span class="secno">2.5.1.1 </span>Showcase demo on local screen (screen as an local media input source)</h5>
+ <p>During the video conference call, Amanda invites a member of the product development team to demonstrate a
+ new visual design editor for the prototype. The design editor is not yet finished, but has the UI elements in
+ place. It currently only compiles on that developer's computer, but Amanda wants the field agents' feedback
+ since they will ultimately be using the tool. The developer is able to select the screen as a local media
+ source and send that video to the group as he demonstrates the UI elements.
+ </p>
+ <ol>
+ <li>Video capture from local screen/display</li>
+ </ol>
+ </div>
+ </div>
+ </div>
+
+ <div class="section" id="incident-on-driver-download-page--device-fingerprinting-with-malicious-intent">
+ <h3><span class="secno">2.6 </span>Incident on driver-download page (device fingerprinting with malicious intent)</h3>
+ <p>
+ While visiting a manufacturer's web site in order to download drivers for his new mouse, Austin unexpectedly
+ gets prompted by his browser to allow access to his device's webcam. Thinking that this is strange (why is
+ the page trying to use my webcam?), Austin denies the request. Several weeks later, Austin reads an article
+ in the newspaper in which the same manufacturer is being investigated by a business-sector watchdog agency
+ for poor business practice. Apparently this manufacturer was trying to discover how many visitors to their
+ site had webcams (and other devices) from a competitor. If that information could be discovered, then the
+ site would subject those users to slanderous advertising and falsified "webcam tests" that made it appear
+ as if their competitor's devices were broken in order to convince users to purchase their own brand of webcam.
+ </p>
+ <ol>
+ <li>Browser requires webcam(s) and microphone permissions before use</li>
+ </ol>
+
+ <div class="section" id="variations-5">
+ <h4><span class="secno">2.6.1 </span>Variations</h4>
+ <p>TBD</p>
+ </div>
+ </div>
+ </div>
+
+ <div class="section" id="requirements">
+ <!--OddPage--><h2><span class="secno">3. </span>Requirements</h2>
+ <p>
+ TBD
+ </p>
+ </div>
+
+ <div class="section" id="concepts-and-definitions">
+ <!--OddPage--><h2><span class="secno">4. </span>Concepts and Definitions</h2>
+ <p>
+ This section describes some terminology and concepts that frame an understanding of the design considerations
+ that follow. It is helpful to have a common understanding of some core concepts to ensure that the prose is
+ interpreted uniformly.
+ </p>
+ <dl>
+ <dt><code>MediaStream</code> vs "media stream" or "stream"</dt>
+ <dd>In some cases, I use these terms interchangeably; my usage of the term "media stream" or "stream" is intended as
+ a generalization of the more specific <code>MediaStream</code> interface as currently defined in the
+ WebRTC spec. Generally, a stream can be conceptually understood as a tube or conduit between sources (the stream's
+ generators) and destinations (the sinks). Streams don't generally include any type of significant buffer, that is,
+ content pushed into the stream from a source does not collect into any buffer for later collection. Rather, content
+ is simply dropped on the floor if the stream is not connected to a sink. This document assumes the non-buffered view
+ of streams as previously described.
+ </dd>
+ <dt><code>MediaStream</code> format</dt>
+ <dd>As stated in the WebRTC specification, the content flowing through a <code>MediaStream</code> is not in
+ any particular underlying format:</dd>
+ <dd><blockquote>[The data from a <code>MediaStream</code> object does not necessarily have a canonical binary form; for
+ example, it could just be "the video currently coming from the user's video camera". This allows user agents
+ to manipulate media streams in whatever fashion is most suitable on the user's platform.]</blockquote></dd>
+ <dd>This document reinforces that view, especially when dealing with capturing of the <code>MediaStream</code> content
+ and the potential interaction with the <a href="http://dvcs.w3.org/hg/webapps/raw-file/tip/StreamAPI/Overview.htm">Streams API</a>.
+ </dd>
+ <dt>Shared devices, devices with manipulatable state, and virtualization</dt>
+ <dd>
+ <p>A shared device (in this document) is a media device (camera or microphone) that is usable by more than
+ one application at a time. When considering sharing a device (or not), an operating system must evaluate
+ whether applications consuming the device will have the ability to manipulate the state of the device. A shared device
+ with manipulatable state has the side-effect of allowing one application to make changes to a device that will then
+ affect other applications who are also sharing.
+ </p>
+ <p>To avoid these effects and unexpected state changes in applications, operating systems may virtualize a
+ device. Device virtualization (in a simplistic view) is an abstraction of the actual device, so that the abstraction
+ is provided to the application rather than providing the actual device. When an application manipulates the state
+ of the virtualized device, changes occur only in the virtualized layer, and do not affect other applications that
+ may be sharing the device.
+ </p>
+ <p>Audio devices are commonly virtualized. This allows many applications to share the audio device and manipulate its
+ state (e.g., apply different input volume levels) without affecting other applications.
+ </p>
+ <p>Video virtualization is more challenging and not as common. For example, the Microsoft Windows operating system does
+ not virtualize webcam devices, and thus chooses not to share the webcam between applications. As a result, in order
+ for an application to use the webcam either 1) another application already using the webcam must yield it up or 2)
+ the requesting application may be allowed to "steal" the device.
+ </p>
+ </dd>
+ </dl>
+ <p></p>
+ </div>
+
+ <div class="section" id="design-considerations-and-remarks">
+ <!--OddPage--><h2><span class="secno">5. </span>Design Considerations and Remarks</h2>
+
+ <div class="section" id="stream-initialization">
+ <h3><span class="secno">5.1 </span>Stream initialization</h3>
+ <p>A web application must be able to initiate a request for access to the user's webcam(s) and/or microphone(s).
+ Additionally, the web application should be able to "hint" at specific device characteristics that are desired by
+ the particular usage scenario of the application. User consent is required before obtaining access to the requested
+ stream.</p>
+ <p>When the media capture devices have been obtained (after user consent), they must be associated with a
+ <code>MediaStream</code> object, be active, and populated with the appropriate tracks.
+ The active capture devices will be configured according to user preference; the
+ user may have an opportunity to configure the initial state of the devices, select specific devices, and/or elect
+ to enable/disabled a subset of the requested devices at the point of consent or beyond—the user remains in control).
+ </p>
+ <p>It is recommended that the active <code>MediaStream</code> be associated with a browser UX in order to ensure that
+ the user:
+ </p><ul>
+ <li>is made aware that their device's webcam and/or microphone is active (for this reason many webcams include a
+ light or other indicator that they are active, but this is not always the case--especially with most microphones embedded in
+ consumer devices)</li>
+ <li>has a UX affordance to easily modify the capture device settings or shut off the associated capture device if necessary</li>
+ </ul>
+ Such a browser UX should be offered in a way that maintains visible even when a browser's tab (performing the capture)
+ is sent to the background. For the purposes of many common scenarios (especially involving real-time communications), it is not
+ recommended that the browser automatically shut down capture devices when the capturing browser tab is sent to the background.
+ If such a scenario is desired by the application author, the tab switch may be detected via other browser events (e.g., the
+ <a href="http://www.w3.org/TR/page-visibility/">page visibility event</a>) and the <code>MediaStream</code> can be stopped via <code>stop()</code>.
+ <p></p>
+ <div class="section" id="privacy">
+ <h4><span class="secno">5.1.1 </span>Privacy</h4>
+ <p>Specific information about a given webcam and/or microphone must not be available until after the user has
+ granted consent. Otherwise "drive-by" fingerprinting of a UA's devices and characteristics can be obtained without
+ the user's knowledge—a privacy issue.</p>
+ <p>In addition, care must be taken that webcam and audio devices are not able to record and stream data without the
+ user's knowledge. Explicit permission should be granted for a specific activity of a limited duration. Configuration
+ controls should be possible to enable age-limits on webcam use or other similar techniques.</p>
+ </div>
+
+ <div class="section" id="issues">
+ <h4><span class="secno">5.1.2 </span>Issues</h4>
+ <ol>
+ <li>What are the privacy/fingerprinting implications of the current "error" callback? Is it sufficiently "scary"
+ to warrant a change? Consider the following:
+ <ul>
+ <li>If the user doesn’t have a webcam/mic, and the developer requests it, a UA would be expected to invoke
+ the error callback immediately.</li>
+ <li>If the user does have a webcam/mic, and the developer requests it, a UA would be expected to prompt for
+ access. If the user denies access, then the error callback is invoked.</li>
+ <li>Depending on the timing of the invocation of the error callback, scripts can still profile whether the
+ UA does or does not have a given device capability.</li>
+ </ul>
+ </li>
+ <li>In the case of a user with multiple video and/or audio capture devices, what specific permission is expected to
+ be granted for the "video" and "audio" options presented to <code>getUserMedia</code>? For example, does "video"
+ permission mean that the user grants permission to any and all video capture devices? Similarly with "audio"? Is
+ it a specific device only, and if so, which one? Given the privacy point above, my recommendation is that "video"
+ permission represents permission to all possible video capture devices present on the user's device, therefore
+ enabling switching scenarios (among video devices) to be possible without re-acquiring user consent. Same for
+ "audio" and combinations of the two.
+ </li>
+ <li>When a user has only one of two requested device capabilities (for example only "audio" but not "video", and both
+ "audio" and "video" are requested), should access be granted without the video or should the request fail?
+ </li>
+ <li>Enabling control configuration of webcam based on age (parental control)</li>
+ <li>Phishing and other attacks using webcam, audio (possible issue to note)</li>
+ </ol>
+ </div>
+ </div>
+
+ <div class="section" id="stream-re-initialization">
+ <h3><span class="secno">5.2 </span>Stream re-initialization</h3>
+
+ <p>After requesting (and presumably gaining access to media capture devices) it is entirely possible for one or more of
+ the requested devices to stop or fail (for example, if a video device is claimed by another application, or if the user
+ unplugs a capture device or physically turns it off, or if the UA shuts down the device arbitrarily to conserve battery
+ power). In such a scenario it should be reasonably simple for the application to be notified of the situation, and for
+ the application to re-request access to the stream.
+ </p>
+ <p>Additional information might also be useful either in terms of <code>MediaStream</code> state such as an error object,
+ or additional events like an <code>error</code> event (or both).
+ </p>
+
+ <div class="section" id="issues-1">
+ <h4><span class="secno">5.2.1 </span>Issues</h4>
+ <ol>
+ <li>How shall the stream be re-acquired efficiently? Is it merely a matter of re-requesting the entire
+ <code>MediaStream</code>, or can an "ended" mediastream be quickly revived? Reviving a local media stream makes
+ more sense in the context of the stream representing a set of device states, than it does when the stream
+ represents a network source. The WebRTC editors are considering moving the "ended" event from the
+ <code>MediaStream</code> to the <code>MediaStreamTrack</code> to help clarify these potential scenarios.
+ </li>
+ <li>What's the expected interaction model with regard to user-consent? For example, if the re-initialization
+ request is for the same device(s), will the user be prompted for consent again? Minor glitches in the stream
+ source connection should not revoke the user-consent.
+ </li>
+ <li>How can tug-of-war scenarios be avoided between two web applications both attempting to gain access to a
+ non-shared device at the same time? Should the API support the ability to request exclusive use of the
+ device?
+ </li>
+ </ol>
+ </div>
+ </div>
+
+ <div class="section" id="preview-a-stream">
+ <h3><span class="secno">5.3 </span>Preview a stream</h3>
+ <p>The application should be able to connect a media stream (representing active media capture device(s) to one or more sinks
+ in order to use/view the content flowing through the stream. In nearly all digital capture scenarios, "previewing"
+ the stream before initiating the capture is essential to the user in order to "compose" the shot (for example,
+ digital cameras have a preview screen before a picture or video is captured; even in non-digital photography, the
+ viewfinder acts as the "preview"). This is particularly important for visual media, but also for non-visual media
+ like audio.
+ </p>
+ <p>Note that media streams connected to a preview output sink are not in a "capturing" state as the media stream has
+ no default buffer (see the <a>Stream</a> definition in section 4). Content conceptually "within" the media stream
+ is streaming from the capture source device to the preview sink after which point the content is dropped (not
+ saved).
+ </p>
+ <p>The application should be able to affect changes to the media capture device(s) settings via the media stream
+ and view those changes happen in the preview.
+ </p>
+ <p>Today, the <code>MediaStream</code> object can be connected to several "preview" sinks in HTML5, including the
+ <code>video</code> and <code>audio</code> elements. (This support should also extend to the <code>source</code>
+ elements of each as well.) The connection is accomplished via <code>URL.createObjectURL</code>. For RTC scenarios,
+ <code>MediaStream</code>s are connected to <code>PeerConnection</code> sinks.
+ </p>
+ <p>An implementation should not limit the number or kind of sinks that a <code>MediaStream</code> is connected
+ to (including sinks for the purpose of previewing).</p>
+ <div class="section" id="issues-2">
+ <h4><span class="secno">5.3.1 </span>Issues</h4>
+ <ol>
+ <li>Audio tag preview is somewhat problematic because of the acoustic feedback problem (interference that can
+ result from a loop between a microphone input that picks up the output from a nearby speaker). There are
+ software solutions that attempt to automatically compensate for these type of feedback problems. However, it
+ may not be appropriate to require implementations to all support such an acoustic feedback prevention
+ algorithm. Therefore, audio preview could be turned off by default and only enabled by specific opt-in.
+ Implementations without acoustic feedback prevention could fail to enable the opt-in?
+ </li>
+ </ol>
+ </div>
+ </div>
+
+ <div class="section" id="stopping-local-devices">
+ <h3><span class="secno">5.4 </span>Stopping local devices</h3>
+ <p>End-users need to feel in control of their devices. Likewise, it is expected that developers using a media stream
+ capture API will want to provide a mechanism for users to stop their in-use device(s) via the software (rather than
+ using hardware on/off buttons which may not always be available).
+ </p>
+ <p>Stopping or ending a media stream source device(s) in this context implies that the media stream source device(s)
+ cannot be re-started. This is a distinct scenario from simply pausing the video/audio tracks of a given media stream.
+ </p>
+ <div class="section" id="issues-3">
+ <h4><span class="secno">5.4.1 </span>Issues</h4>
+ <ol>
+ <li>Is there a scenario where end-users will want to stop just a single device, rather than all devices participating
+ in the current media stream? In the WebRTC case there seems to be, e.g. if the current connection cannot handle both
+ audio and video streams then the user might want to back down to audio, or the user just wants to drop down to audio
+ because they decide they don't need video. But otherwise, e.g. for local use cases, mute seems more likely and less
+ disruptive (e.g. in terms of CPU load which might temporarily affect recorded quality of the remaining streams).
+ </li>
+ </ol>
+ </div>
+ </div>
+
+ <div class="section" id="pre-processing">
+ <h3><span class="secno">5.5 </span>Pre-processing</h3>
+ <p>Pre-processing scenarios are a bucket of scenarios that perform processing on the "raw" or "internal" characteristics
+ of the media stream for the purpose of reporting information that would otherwise require processing of a known
+ format (i.e., at the media stream sink—like Canvas, or via capturing and post-processing), significant
+ computationally-expensive scripting, etc.
+ </p>
+ <p>Pre-processing scenarios will require the UAs to provide an implementation (which may be non-trivial). This is
+ required because the media stream's internal format should be opaque to user-code. Note, if a future
+ specification described an interface to allow low-level access to a media stream, such an interface would enable
+ user-code to implement many of the pre-processing scenarios described herein using post-processing techniques (see
+ next section).
+ </p>
+ <p>Pre-processing scenarios provide information that is generally desired <i>before</i> a stream need be connected to a
+ sink or captured.
+ </p>
+ <p>Pre-processing scenarios apply to both real-time-communication and local capture scenarios. Therefore, the
+ specification of various pre-processing requirements may likely fall outside the scope of this task force. However,
+ they are included here for scenario-completeness and to help ensure that a media capture API design takes them into
+ account.
+ </p>
+ <div class="section" id="examples">
+ <h4><span class="secno">5.5.1 </span>Examples</h4>
+ <ol>
+ <li>Audio end-pointing. As described in <a href="http://lists.w3.org/Archives/Public/www-archive/2011Mar/att-0001/microsoft-api-draft-final.html">a
+ speech API proposal</a>, audio end-pointing allows for the detection of noise, speech, or silence and raises events
+ when these audio states change. End-pointing is necessary for scenarios that programmatically determine when to
+ start and stop capturing an audio stream for purposes of hands-free speech commands, dictation, and a variety of
+ other speech and accessibility-related scenarios. The proposal linked above describes these scenarios in better
+ detail. Audio end-pointing would be required as a pre-processing scenario because it is a prerequisite to
+ starting/stopping a capture of the media stream itself.
+ </li>
+ <li>Volume leveling/automatic gain control. The ability to automatically detect changes in audio loudness and adjust
+ the input volume such that the output volume remains constant. These scenarios are useful in a variety of
+ heterogeneous audio environments such as teleconferences, live broadcasting involving commercials, etc.
+ Configuration options for volume/gain control of a media stream source device are also useful, and are explored
+ later on.
+ </li>
+ <li>Video face-recognition and gesture detection. These scenarios are the visual analog to the previously described
+ audio end-pointing scenarios. Face-recognition is useful in a variety of contexts from identifying faces in family
+ photographs, to serving as part of an identity management system for system access. Likewise, gesture recognition
+ can act as an input mechanism for a computer.
+ </li>
+ </ol>
+ </div>
+ <div class="section" id="issues-4">
+ <h4><span class="secno">5.5.2 </span>Issues</h4>
+ <ol>
+ <li>In general the set of audio pre-processing scenarios is much more constrained than the set of possible visual
+ pre-processing scenarios. Due to the large set of visual pre-processing scenarios (which could also be implemented
+ by scenario-specific post-processing in most cases), we may recommended that visual-related pre-processing
+ scenarios be excluded from the scope of our task force.
+ </li>
+ <li>The challenges of specifying pre-processing scenarios will be identifying what specific information should be
+ conveyed by the platform at a level at which serves the widest variety of scenarios. For example,
+ audio-end-pointing could be specified in high-level terms of firing events when specific words of a given language
+ are identified, or could be as low-level as reporting when there is silence/background noise and when there's not.
+ Not all scenarios will be able to be served by any API that is designed, therefore this group might choose to
+ evaluate which scenarios (if any) are worth including in the first version of the API.
+ </li>
+ <li>Similarly to gestures, speech recognition can also be used to control the stream itself. But both uses are about
+ interpreting the content to derive events, it may be that these capabilities should be addressed in some other spec.
+ The more generic capabilities (input level monitoring) or automatic controls based upon them (e.g. AGC) however are
+ useful to consider here. These might be simplified (initially) to boolean options (capture auto-start/pause and AGC).
+ Going beyond that, input level events (e.g. threshold passing) or some realtime-updated attribute (input signal level)
+ on the API would be very useful in capture scenarios.
+ </li>
+ </ol>
+ </div>
+ </div>
+
+ <div class="section" id="post-processing">
+ <h3><span class="secno">5.6 </span>Post-processing</h3>
+ <p>Post processing scenarios are a group of all scenarios that can be completed after either:</p>
+ <ol>
+ <li>Connecting the media stream to a sink (such as the <code>video</code> or <code>audio</code> elements</li>
+ <li>Capturing the media stream to a known format (MIME type)</li>
+ </ol>
+ <p>Post-processing scenarios will continue to expand and grow as the web platform matures and gains capabilities.
+ The key to understanding the available post-processing scenarios is to understand the other facets of the web
+ platform that are available for use.
+ </p>
+ <p>Note: Depending on convenience and scenario usefullness, the post-processing scenarios in the toolbox below
+ could be implemented as pre-processing capabilities (for example the Web Audio API). In general, this document
+ views pre-processing scenarios as those provided by the <code>MediaStream</code> and post-processing scenarios
+ as those that consume a <code>MediaStream</code>.</p>
+ <div class="section" id="web-platform-post-processing-toolbox">
+ <h4><span class="secno">5.6.1 </span>Web platform post-processing toolbox</h4>
+ <p>The common post-processing capabilities for media stream scenarios are built on a relatively small set of web
+ platform capabilities. The capabilities described here are derived from current <acronym title="World Wide Web Consortium">W3C</acronym> draft specifications, many
+ of which have widely-deployed implementations:
+ </p>
+ <ol>
+ <li>HTML5 <a href="http://dev.w3.org/html5/spec/Overview.html#the-video-element"><code>video</code></a> and
+ <a href="http://dev.w3.org/html5/spec/Overview.html#the-audio-element"><code>audio</code></a> tags. These elements are natural
+ candidates for media stream output sinks. Additionally, they provide an API (see
+ <a href="http://dev.w3.org/html5/spec/Overview.html#htmlmediaelement">HTMLMediaElement</a>) for interacting with
+ the source content. Note: in some cases, these elements are not well-specified for stream-type sources—this task
+ force may need to drive some stream-source requirements into HTML5.
+ </li>
+ <li>HTML5 <a href="http://dev.w3.org/html5/spec/Overview.html#the-canvas-element"><code>canvas</code></a> element
+ and the <a href="http://dev.w3.org/html5/2dcontext/">Canvas 2D context</a>. The <code>canvas</code> element employs
+ a fairly extensive 2D drawing API and will soon be extended with audio capabilities as well (<b>RichT, can you
+ provide a link?</b>). Canvas' drawing API allows for drawing frames from a <code>video</code> element, which is
+ the link between the media capture sink and the effects made possible via Canvas.
+ </li>
+ <li><a href="http://dev.w3.org/2006/webapi/FileAPI/">File API</a> and
+ <a href="http://www.w3.org/TR/file-writer-api/">File API Writer</a>. The File API provides various methods for
+ reading and writing to binary formats. The fundamental container for these binary files is the <code>Blob</code>
+ which put simply is a read-only structure with a MIME type and a length. The File API integrates with many other
+ web APIs such that the <code>Blob</code> can be used uniformly across the entire web platform. For example,
+ <code>XMLHttpRequest</code>, form submission in HTML, message passing between documents and web workers
+ (<code>postMessage</code>), and Indexed DB all support <code>Blob</code> use.
+ </li>
+ <li><a href="http://dvcs.w3.org/hg/webapps/raw-file/tip/StreamAPI/Overview.htm">Stream API</a>. A new addition to
+ the WebApps WG, the <code>Stream</code> is another general-purpose binary container. The primary differences
+ between a <code>Stream</code> and a <code>Blob</code> is that the <code>Stream</code> is read-once, and has no
+ length. The Stream API includes a mechanism to buffer from a <code>Stream</code> into a <code>Blob</code>, and
+ thus all <code>Stream</code> scenarios are a super-set of <code>Blob</code> scenarios.
+ </li>
+ <li>JavaScript <a href="http://wiki.ecmascript.org/doku.php?id=strawman:typed_arrays">TypedArrays</a>. Especially
+ useful for post-processing scenarios, TypedArrays allow JavaScript code to crack-open a binary file
+ (<code>Blob</code>) and read/write its contents using the numerical data types already provided by JavaScript.
+ There's a cool explanation and example of TypedArrays
+ <a href="http://blogs.msdn.com/b/ie/archive/2011/12/01/working-with-binary-data-using-typed-arrays.aspx">here</a>.
+ </li>
+ <li><a href="http://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html">Web Audio API</a>. A proposal
+ for processing and synthesizing audio in web applications. Additionally, that group publishes the <a href="http://www.w3.org/TR/audioproc/">
+ Audio Processing API</a> containing additional information.
+ </li>
+ </ol>
+ </div>
+ <p>Of course, post-processing scenarios made possible after sending a media stream or captured media stream to a
+ server are unlimited.
+ </p>
+ <div class="section" id="time-sensitivity-and-performance">
+ <h4><span class="secno">5.6.2 </span>Time sensitivity and performance</h4>
+ <p>Some post-processing scenarios are time-sensitive—especially those scenarios that involve processing large
+ amounts of data while the user waits. Other post-processing scenarios s are long-running and can have a performance
+ benefit if started before the end of the media stream segment is known. For example, a low-pass filter on a video.
+ </p>
+ <p>These scenarios generally take two approaches:</p>
+ <ol>
+ <li>Extract samples (video frames/audio clips) from a media stream sink and process each sample. Note that this
+ approach is vulnerable to sample loss (gaps between samples) if post-processing is too slow.
+ </li>
+ <li>Capture the media stream and extract samples from the captured native format. Note that this approach requires
+ significant understanding of the captured native format.
+ </li>
+ </ol>
+ <p>
+ Both approaches are valid for different types of scenarios.
+ </p>
+ <p>The first approach is the technique described in the current WebRTC specification for the "take a picture"
+ example.
+ </p>
+ <p>The second approach is somewhat problematic from a time-sensitivity/performance perspective given that the
+ captured content is only provided via a <code>Blob</code> today. A more natural fit for post-processing scenarios
+ that are time-or-performance sensitive is to supply a <code>Stream</code> as output from a capture.
+ Thus time-or-performance sensitive post-processing applications can immediately start processing the [unfinished]
+ capture, and non-sensitive applications can use the Stream API's <code>StreamReader</code> to eventually pack
+ the full <code>Stream</code> into a <code>Blob</code>.
+ </p>
+ </div>
+ <div class="section" id="examples-1">
+ <h4><span class="secno">5.6.3 </span>Examples</h4>
+ <ol>
+ <li>Image quality manipulation. If you copy the image data to a canvas element you can then get a data URI or
+ blob where you can specify the desired encoding and quality e.g.
+ <pre class="sh_javascript sh_sourceCode">canvas.toDataURL('image/jpeg', 0.6);
+// or
+canvas.toBlob(function(blob) {}, 'image/jpeg', 0.2);</pre>
+ </li>
+ <li>Image rotation. If you copy the image data to a canvas element and then obtain its 2D context you can then
+ call rotate() on that context object to rotate the displayed 'image'. You can then obtain the manipulated image
+ back via toDataURL or toBlob as above if you want to generate a file-like object that you can then pass around as
+ required.
+ </li>
+ <li>Image scaling. Thumbnails or web image formatting can be done by scaling down the captured image to a common
+ width/height and reduce the output quality.
+ </li>
+ <li>Speech-to-text. Post processing on a captured audio format can be done to perform client-side speech
+ recognition and conversion to text. Note, that speech recognition algorithms are generally done on the server for
+ time-sensitive or performance reasons.
+ </li>
+ </ol>
+ </div>
+ <p>This task force should evaluate whether some extremely common post-processing scenarios should be included as
+ pre-processing features.
+ </p>
+ </div>
+
+ <div class="section" id="device-selection">
+ <h3><span class="secno">5.7 </span>Device Selection</h3>
+ <p>A particular user agent may have zero or more devices that provide the capability of audio or video capture. In
+ consumer scenarios, this is typically a webcam with a microphone (which may or may not be combined), and a "line-in"
+ and or microphone audio jack. The enthusiast users (e.g., audio recording enthusiasts), may have many more available
+ devices.
+ </p>
+ <p>Device selection in this section is not about the selection of audio vs. video capabilities, but about selection
+ of multiple devices within a given "audio" or "video" category (i.e., "kind"). The term "device" and "available
+ devices" used in this section refers to one or a collection of devices of a kind (e.g., that provide a common
+ capability, such as a set of devices that all provide "video").
+ </p>
+ <p>Providing a mechanism for code to reliably enumerate the set of available devices enables programmatic control
+ over device selection. Device selection is important in a number of scenarios. For example, the user selected the
+ wrong camera (initially) and wants to change the media stream over to another camera. In another example, the
+ developer wants to select the device with the highest resolution for capture.
+ </p>
+ <p>Depending on how stream initialization is managed in the consent user experience, device selection may or may not
+ be a part of the UX. If not, then it becomes even more important to be able to change device selection after media
+ stream initialization. The requirements of the user-consent experience will likely be out of scope for this task force.
+ </p>
+ <div class="section" id="privacy-1">
+ <h4><span class="secno">5.7.1 </span>Privacy</h4>
+ <ol>
+ <li>As mentioned in the "Stream initialization" section, exposing the set of available devices before giving media stream
+ consent leads to privacy issues. Therefore, the device selection API should only be available after consent.
+ </li>
+ <li>Device selection should not be available for the set of devices within a given category/kind (e.g., "audio"
+ devices) for which user consent was not granted.
+ </li>
+ </ol>
+ </div>
+ <p>Device selection should be a mechanism for exposing device capabilities which inform the application of which device to
+ select. In order for the user to make an informed decision about which device to select (if at all), the developer's code would
+ need to make some sort of comparison between devices—such a comparison should be done based on device capabilities rather
+ than a guess, hint, or special identifier (see related issue below).
+ </p>
+ <p>Capture capabilities are an important decision-making point for media capture scenarios. However, capture capabilities
+ are not directly correlated with individual devices, and as such should not be mixed with the device capabilities. For
+ example, the capability of capturing audio in AAC vs. MP3 is not correlated with a given audio device, and therefore not a
+ decision making factor for device selection.
+ </p>
+ <div class="section" id="issues-5">
+ <h4><span class="secno">5.7.2 </span>Issues</h4>
+ <ol>
+ <li>The specification should provide guidance on what set of devices are to be made available—should it be the set of
+ potential devices, or the set of "currently available" devices (which I recommended since the non-available devices can't
+ be utilized by the developer's code, thus it doesn't make much sense to include them).
+ </li>
+ <li>A device selection API should expose device capability rather than by device identity. Device identity is a poor practice
+ because it leads to device-dependent testing code (for example, if "Name Brand Device", then…) similar to the problems that
+ exist today on the web as a result of user-agent detection. A better model is to enable selection based on capabilities.
+ Additionally, knowing the GUID or hardware name is not helpful to web developers as part of a scenario other than device
+ identification (perhaps for purposes of providing device-specific help/troubleshooting, for example).
+ </li>
+ <li>One strategy is to not return a set of devices, only the one that the user selected. Thus whether a device is "available"
+ (meaning known by the system, and able to be connected to at the current time) is something that could presented through the
+ browser UI and include other info (e.g. description of the device e.g. "front"/"back"/"internal"/"USB"/"Front Door"/...) as
+ known. Providing a list of cameras requires then that the app be capable of some decision making, and thus requires more info
+ which again is a privacy concern (resulting in a potential two-stage prompt: "Do you allow this app to know what cameras are
+ connected" then "Do you allow this app to connect to the 'front' camera?").
+ </li>
+ </ol>
+ </div>
+ </div>
+
+ <div class="section" id="change-user-selected-device-capabilities">
+ <h3><span class="secno">5.8 </span>Change user-selected device capabilities</h3>
+ <p>In addition to selecting a device based on its capabilities, individual media capture devices may support multiple modes of
+ operation. For example, a webcam often supports a variety of resolutions which may be suitable for various scenarios (previewing
+ or capturing a sample whose destination is a web server over a slow network connection, capturing archival HD video for storing
+ locally). An audio device may have a gain control, allowing a developer to build a UI for an audio blender (varying the gain on
+ multiple audio source devices until the desired blend is achieved).
+ </p>
+ <p>A media capture API should support a mechanism to configure a particular device dynamically to suite the expected scenario.
+ Changes to the device should be reflected in the related media stream(s) themselves.
+ </p>
+ <p>If a device supports sharing (providing a virtual version of itself to an app), any changes to the device's manipulatable state
+ should by isolated to the application requesting the change. For example, if two applications are using a device, changes to the
+ device's configuration in one app should not affect the other one.
+ </p>
+ <p>Changes to a device capability should be made in the form of requests (async operations rather than synchronous commands).
+ Change requests allow a device time to make the necessary internal changes, which may take a relatively long time without
+ blocking other script. Additionally, script code can be written to change device characteristics without careful error-detection
+ (because devices without the ability to change the given characteristic would not need to throw an exception synchronously).
+ Finally, a request model makes sense even in RTC scenarios, if one party of the teleconference, wants to issue a request that
+ another party mute their device (for example). The device change request can be propagated over the <code>PeerConnection</code>
+ to the sender asynchronously.
+ </p>
+ <p>In parallel, changes to a device's configuration should provide a notification when the change is made. This allows web
+ developer code to monitor the status of a media stream's devices and report statistics and state information without polling the
+ device (especially when the monitoring code is separate from the author's device-control code). This is also essential when the
+ change requests are asynchronous; to allow the developer to know at which point the requested change has been made in the media
+ stream (in order to perform synchronization, or start/stop a capture, for example).
+ </p>
+ <div class="section" id="issues-6">
+ <h4><span class="secno">5.8.1 </span>Issues</h4>
+ <ol>
+ <li>If changing a particular device capability cannot be virtualized, this media capture task force should consider whether that
+ dynamic capability should be exposed to the web platform, and if so, what the usage policy around multiple access to that
+ capability should be.
+ </li>
+ <li>The specifics of what happens to a capture-in-progress when device behavior is changed must be described in the spec.
+ </li>
+ </ol>
+ </div>
+ </div>
+
+ <div class="section" id="multiple-active-devices">
+ <h3><span class="secno">5.9 </span>Multiple active devices</h3>
+ <p>In some scenarios, users may want to initiate capture from multiple devices at one time in multiple media streams. For example,
+ in a home-security monitoring scenario, a user agent may want to capture 10 unique video streams representing various locations being
+ monitored. The user may want to collect all 10 of these videos into one capture, or capture all 10 individually (or some
+ combination thereof).
+ </p>
+ <p>While such scenarios are possible and should be supported (even if they are a minority of the typical web-scenarios), it should be
+ noted that many devices (especially portable devices) supports the media capture by way of dedicated encoder hardware, and such hardware
+ may only be able to handle one stream at a time). Implementations should be able to provide a failure condition when multiple video sources
+ are attempting to begin capture at the same time.
+ </p>
+ </div>
+
+ <div class="section" id="capturing-a-media-stream">
+ <h3><span class="secno">5.10 </span>Capturing a media stream</h3>
+ <p>In its most basic form, capturing a media stream is the process of converting the media stream into a known format during a
+ bracketed timeframe.
+ </p>
+ <p>Local media stream captures are common in a variety of sharing scenarios such as:
+ </p>
+ <ul>
+ <li>capture a video and upload to a video sharing site</li>
+ <li>capture a picture for my user profile picture in a given web app</li>
+ <li>capture audio for a translation site</li>
+ <li>capture a video chat/conference</li>
+ </ul>
+ <p>There are other offline scenarios that are equally compelling, such as usage in native-camera-style apps, or web-based capturing
+ studios (where tracks are captured and later mixed).
+ </p>
+ <p>The core functionality that supports most capture scenarios is a simple start/stop capture pair.
+ </p>
+ <p>Ongoing captures should report progress either via the user agent, or directly through an API to enable developers to build UIs
+ that pass this progress notification along to users.
+ </p>
+ <p>A capture API should be designed to gracefully handle changes to the media stream, and should also report (and perhaps even
+ attempt to recover from) failures at the media stream source during capture.
+ </p>
+ <p>Uses of the captured information is covered in the Post-processing scenarios described previously. An additional usage is the
+ possibility of default save locations. For example, by default a UA may store temporary captures (those captures that are
+ in-progress) in a temp (hidden) folder. It may be desirable to be able to specify (or hint) at an alternate default capture
+ location such as the users' common file location for videos or pictures.
+ </p>
+ <div class="section" id="dvr-scenarios">
+ <h4><span class="secno">5.10.1 </span>DVR Scenarios</h4>
+ <p>Increasingly in the digital age, the ability to pause, rewind, and "go live" for streamed content is an expected scenario.
+ While this scenario applies mostly to real-time communication scenarios (and not to local capture scenarios), it is worth
+ mentioning for completeness.
+ </p>
+ <p>The ability to quickly "rewind" can be useful, especially in video conference scenarios, when you may want to quickly go
+ back and hear something you just missed. In these scenarios, you either started a capture from the beginning of the conference
+ and you want to seek back to a specific time, or you were only streaming it (not saving it) but you allowed yourself some amount
+ of buffer in order to review the last X minutes of video.
+ </p>
+ <p>To support these scenarios, buffers must be introduced (because the media stream is not implicitly buffered for this scenario).
+ In the capture scenario, as long as the UA can access previous parts of the capture (without terminating it) then this scenario
+ could be possible.
+ </p>
+ <p>In the streaming case, this scenario could be supported by adding a buffer directly into the media stream itself, or by capturing
+ the media stream as previously mentioned. Given the complexities of integrating a buffer into the <code>MediaStream</code> proposal,
+ using capture to accomplish this scenario is recommended.
+ </p>
+ </div>
+ <div class="section" id="issues-7">
+ <h4><span class="secno">5.10.2 </span>Issues</h4>
+ <ol>
+ <li>There are few (if any) scenarios that require support for overlapping captures of a single media stream. Note, that the
+ <code>record</code> API (as described in early WebRTC drafts) implicitly supports overlapping capture by simply calling
+ <code>record()</code> twice. In the case of separate media streams (see previous section) overlapping recording makes sense. In
+ either case, initiating multiple captures should not be so easy so as to be accidental.
+ </li>
+ </ol>
+ </div>
+ </div>
+
+ <div class="section" id="selection-of-a-capture-method">
+ <h3><span class="secno">5.11 </span>Selection of a capture method</h3>
+ <p>All post-processing scenarios for captured data require a known [standard] format. It is therefore crucial that the media capture
+ API provide a mechanism to specify the capture format. It is also important to be able to discover if a given format is supported.
+ </p>
+ <p>Most scenarios in which the captured data is sent to the server for upload also have restrictions on the type of data that the server
+ expects (one size doesn't fit all).
+ </p>
+ <p>It should not be possible to change captures on-the-fly without consequences (i.e., a stop and/or re-start or failure). It is
+ recommended that the mechanism for specifying a capture format not make it too easy to change the format (e.g., setting the format
+ as a property may not be the best design).
+ </p>
+ <div class="section" id="format-detection">
+ <h4><span class="secno">5.11.1 </span>Format detection</h4>
+ <ul>
+ <li>If we wish to re-use existing web platform concepts for format capability detection, the HTML5 <code>HTMLMediaElement</code>
+ supports an API called <code>canPlayType</code> which allows developer to probe the given UA for support of specific MIME types that
+ can be played by <code>audio</code> and <code>video</code> elements. A capture format checker could use this same approach.
+ </li>
+ </ul>
+ </div>
+ </div>
+
+ <div class="section" id="programmatic-activation-of-camera-app">
+ <h3><span class="secno">5.12 </span>Programmatic activation of camera app</h3>
+ <p>As mentioned in the introduction, declarative use of a capture device is out-of-scope. However, there are some potentially interesting
+ uses of a hybrid programmatic/declarative model, where the configuration of a particular media stream is done exclusively via the user
+ (as provided by some UA-specific settings UX), but the fine-grained control over the stream as well as the stream capture is
+ handled programmatically.
+ </p>
+ <p>In particular, if the developer doesn't want to guess the user's preferred settings, or if there are specific settings that may not be
+ available via the media capture API standard, they could be exposed in this manner.
+ </p>
+ </div>
+
+ <div class="section" id="take-a-picture">
+ <h3><span class="secno">5.13 </span>Take a picture</h3>
+ <p>A common usage scenario of local device capture is to simply "take a picture". The hardware and optics of many camera-devices often
+ support video in addition to photos, but can be set into a specific "camera mode" where the possible capture resolutions are
+ significantly larger than their maximum video resolution.
+ </p>
+ <p>The advantage to having a photo-mode is to be able to capture these very high-resolution images (versus the post-processing scenarios
+ that are possible with still-frames from a video source).
+ </p>
+ <p>Capturing a picture is strongly tied to the "video" capability because a video preview is often an important component to setting up
+ the scene and getting the right shot.
+ </p>
+ <p>Because photo capabilities are somewhat different from those of regular video capabilities, devices that support a specific "photo"
+ mode, should likely provide their "photo" capabilities separately from their "video" capabilities.
+ </p>
+ <p>Many of the considerations that apply to video capture also apply to taking a picture.
+ </p>
+ <div class="section" id="issues-8">
+ <h4><span class="secno">5.13.1 </span>Issues</h4>
+ <ol>
+ <li>What are the implications on the device mode switch on video captures that are in progress? Will there be a pause? Can this
+ problem be avoided?
+ </li>
+ <li>Should a "photo mode" be a type of user media that can be requested via <code>getUserMedia</code>?
+ </li>
+ </ol>
+ </div>
+ </div>
+
+ <div class="section" id="picture-tracks">
+ <h3><span class="secno">5.14 </span>Picture tracks</h3>
+ <p>Another common scenario for media streams is to share photos via a video stream. For example, a user may want to select a photo and
+ attach the photo to an active media stream in order to share that photo via the stream. In another example, the photo can be used as a
+ type of "video mute" where the photo can be sent in place of the active video stream when a video track is "disabled".
+ </p>
+ <div class="section" id="issues-9">
+ <h4><span class="secno">5.14.1 </span>Issues</h4>
+ <ol>
+ <li>It may be desireable to specify a photo/static image as a track type in order to allow it to be toggled on/off with a video track.
+ On the other hand, the sharing scenario could be fulfilled by simply providing an API to supply a photo for the video track "mute"
+ option (assuming that there's not a scenario that involves creating a parallel media stream that has both the photo track and the current
+ live video track active at once; such a use case could be satisfied by using two media streams instead).
+ </li>
+ </ol>
+ </div>
+ </div>
+
+ <div class="section" id="caption-tracks">
+ <h3><span class="secno">5.15 </span>Caption Tracks</h3>
+ <p>The HTML5 <code>HTMLMediaElement</code> now has the ability to display captures and other "text tracks". While not directly applicable to
+ local media stream scenarios (caption support is generally done out-of-band from the original capture), it could be something worth adding in
+ order to integrate with HTML5 videos when the source is a PeerConnection where real-time captioning is being performed and needs to be displayed.
+ </p>
+ </div>
+
+ </div>
+
+ <div class="section" id="acknowledgements">
+ <!--OddPage--><h2><span class="secno">6. </span>Acknowledgements</h2>
+ <p>Special thanks to the following who have contributed to this document:
+ Harald Alvestrand,
+ Robin Berjon,
+ Stefan Hakansson,
+ Frederick Hirsch,
+ Randell Jesup,
+ Bryan Sullivan,
+ Timothy B. Terriberry,
+ Tommy Widenflycht.
+ </p>
+ </div>
+
+
+<div class="appendix section" id="references"><!--OddPage--><h2><span class="secno">A. </span>References</h2><div class="section" id="normative-references"><h3><span class="secno">A.1 </span>Normative references</h3><p>No normative references.</p></div><div class="section" id="informative-references"><h3><span class="secno">A.2 </span>Informative references</h3><p>No informative references.</p></div></div></body></html>
\ No newline at end of file
Received on Monday, 27 February 2012 16:36:38 UTC