https://www.w3.org/2011/webtv/wiki/api.php?action=feedcontributions&feedformat=atom&user=BsullivaWeb and TV IG - User contributions [en]2024-03-29T13:19:34ZUser contributionsMediaWiki 1.41.0https://www.w3.org/2011/webtv/wiki/index.php?title=Main_Page/Cloud_Browser_TF/Cloud_Browser_TF_Participants&diff=4060Main Page/Cloud Browser TF/Cloud Browser TF Participants2016-02-03T16:37:55Z<p>Bsulliva: /* Participants */</p>
<hr />
<div>== Moderator ==<br />
* Alexandra Mikityuk, Deutsche Telekom<br />
== Participants ==<br />
* Oliver Friedrich, Deutsche Telekom<br />
* Louay Bassbouss, Fraunhofer FOKUS<br />
* Calin Ciordas, Irdeto<br />
* Dale Rochon, AT&T<br />
* John Luther, JW Player<br />
* Kumanan Yogaratnam, Espial<br />
* Paul Higgs, Ericsson<br />
* Bob Lund, CableLabs<br />
* Nilo Mitra, Ericsson<br />
* Kaz Ashimura, W3C<br />
* Harrison Hongseo Yun, Entrix (SK Telecom)<br />
* Andrzej Zawadzki, Opera Software<br />
* Yosuke Funahashi, W3C<br />
* Colin Meerveld, Activevideo<br />
* Bill Rose, Comcast<br />
* Julian Sitkevich, Viacom<br />
* Kumanan Yogaratnam, Espial Group Inc.<br />
* Bryan Sullivan, AT&T</div>Bsullivahttps://www.w3.org/2011/webtv/wiki/index.php?title=TV_Workshop_Mar_2014/Next_steps&diff=3246TV Workshop Mar 2014/Next steps2014-03-13T15:02:03Z<p>Bsulliva: /* Session 2 */</p>
<hr />
<div>Please enter ideas for issues and next steps to be discussed in the closing session.<br />
<br />
== Session 2 ==<br />
<br />
Bryan Sullivan (AT&T): Regarding HbbTV testing, most of the goals are shared with W3C. But W3C is contribution-driven which doesn't give it as much room to be exact. People pay HbbTV to provide tests which W3C doesn't have, but W3C should take good practices from HbbTV and discuss/follow-up on that. To progress this, AT&T will provide resources to help the Web & TV IG to take the next steps on its earlier testing requirements, by helping to organize TTWF actions on the tests for those requirements. This will include reaching out to HbbTV and the other SDOs doing TV/device certification, to incorporate their best practices for test development. As part of this, we will analyze the "impedance mismatches" with testing in other SDOs, to help clarify how and why W3C's testing differs and might converge in some ways.<br />
<br />
Daniel Davis (W3C): Regarding Hybridcast, what's lacking in the video element that means an object element is used instead?<br />
<br />
Kazuhiro Hoya (Fuji TV): Some challenges that we had in developing second-screen apps:<br />
* Developing: It's very hard and uses human resources - we need a framework;<br />
* Compatibility: There are a lot of TVs on the market. We need a better testing method.<br />
* UX: Pairing involves a lot of steps. Even using a QR code is too much for some users.<br />
<br />
== Session 3 ==<br />
<br />
Louay Bassbouss: The W3C Messaging API is missing a close event.<br />
<br />
Clarke Stevens: Second-screen solution issues:<br />
* Interoperability across vendors<br />
* Integration of second screen uses rather than 100 different apps.<br />
<br />
Mingmin Wang:<br />
* Could try to add some specific definition to HTML5 for better video experience.<br />
* Metadata specification for video is fragmented. Cable operators follow CableLabs ADI metadata standard, but internet video service providers use their own metadata format.<br />
<br />
Dave Raggett:<br />
* Mobile devices should prebuffer HTML5 videos when the user is on wifi or a 3G flat rate.<br />
* Use cases for tight synchronization of media and user experience across devices, and mechanisms to support this, e.g. playbackRate property or a means to reference a master clock<br />
* Social networks of people, devices and programs as an alternative to local discovery<br />
<br />
== Session 4 ==<br />
<br />
Jon Piesing:<br />
* Functionality in some APIs is not there yet. We end up with new shiny API and old but reliable API in parallel.<br />
* Error codes for video are not specific enough, e.g. they should specify DRM problem, parental control problem, etc.<br />
<br />
Jean-Pierre Evain:<br />
* There are some major gaps, in timed text for example. There's a lot of industry experience here that should be used. We should speak to broadcasters as they get direct feedback from their users.<br />
<br />
Kinji Matsumura:<br />
* Gaps and extensions were specific to our local market so not worth bringing back to W3C.<br />
<br />
Clarke Stevens:<br />
* Biggest issue with HTML5 is the disappointing testing effort.<br />
<br />
== Session 5 ==<br />
<br />
Louay Bassbouss:<br />
* .. For notification and application launch there is W3C Web Notifications, but it concentrates mostly only on local notifications. The notification is displayed outside the user agent. What we want is the notification to be displayed on another device, so we need an API to do that.<br />
<br />
== Session 6 ==<br />
<br />
David Singer: Should the web community be looking beyond just subtitling at wider accessible media support?<br />
<br />
Jan Lindquist: Should the TV Interest Group be pushing for a pluggable CDM component?<br />
<br />
== Session 7 ==<br />
<br />
Dong-Young Lee:<br />
* We need to standardize time synchronization for multi-screen apps.<br />
* Also, an abstraction layer to support various underlying technologies and protocols.<br />
<br />
== Other ==<br />
<br />
Pavel (Czech TV):<br />
* Better failure codes (as Jon mentioned)<br />
* More event notification<br />
<br />
Daniel (W3C):<br />
* Should W3C issue guidelines or advice to content authors on using WebVTT & TTML?<br />
* Is there a need for a "halfway house" DRM alternative - watermarking or email imprinting within media for dissuading, not preventing, piracy?<br />
<br />
Dave Raggett (W3C):<br />
* (In the discovery discussion) Wonders why no one has mentioned raw sockets API in sysapp. Is this because of lack of awareness?</div>Bsullivahttps://www.w3.org/2011/webtv/wiki/index.php?title=TV_Workshop_Mar_2014/Next_steps&diff=3245TV Workshop Mar 2014/Next steps2014-03-13T14:44:07Z<p>Bsulliva: /* Session 2 */</p>
<hr />
<div>Please enter ideas for issues and next steps to be discussed in the closing session.<br />
<br />
== Session 2 ==<br />
<br />
Bryan Sullivan (AT&T): Regarding HbbTV testing, most of the goals are shared with W3C. But W3C is contribution-driven which doesn't give it as much room to be exact. People pay HbbTV to provide tests which W3C doesn't have, but W3C should take good practices from HbbTV and discuss/follow-up on that. To progress ths, AT&T will provide resources to help the Web & TV IG to take the next steps on its earlier testing requirements, by helping to organize TTWF actions on the tests for those requirements. This will include reaching out to HbbTV and the other SDOs doing TV/device certification, to incorporate their best practices for test development.<br />
<br />
Daniel Davis (W3C): Regarding Hybridcast, what's lacking in the video element that means an object element is used instead?<br />
<br />
Kazuhiro Hoya (Fuji TV): Some challenges that we had in developing second-screen apps:<br />
* Developing: It's very hard and uses human resources - we need a framework;<br />
* Compatibility: There are a lot of TVs on the market. We need a better testing method.<br />
* UX: Pairing involves a lot of steps. Even using a QR code is too much for some users.<br />
<br />
== Session 3 ==<br />
<br />
Louay Bassbouss: The W3C Messaging API is missing a close event.<br />
<br />
Clarke Stevens: Second-screen solution issues:<br />
* Interoperability across vendors<br />
* Integration of second screen uses rather than 100 different apps.<br />
<br />
Mingmin Wang:<br />
* Could try to add some specific definition to HTML5 for better video experience.<br />
* Metadata specification for video is fragmented. Cable operators follow CableLabs ADI metadata standard, but internet video service providers use their own metadata format.<br />
<br />
Dave Raggett:<br />
* Mobile devices should prebuffer HTML5 videos when the user is on wifi or a 3G flat rate.<br />
* Use cases for tight synchronization of media and user experience across devices, and mechanisms to support this, e.g. playbackRate property or a means to reference a master clock<br />
* Social networks of people, devices and programs as an alternative to local discovery<br />
<br />
== Session 4 ==<br />
<br />
Jon Piesing:<br />
* Functionality in some APIs is not there yet. We end up with new shiny API and old but reliable API in parallel.<br />
* Error codes for video are not specific enough, e.g. they should specify DRM problem, parental control problem, etc.<br />
<br />
Jean-Pierre Evain:<br />
* There are some major gaps, in timed text for example. There's a lot of industry experience here that should be used. We should speak to broadcasters as they get direct feedback from their users.<br />
<br />
Kinji Matsumura:<br />
* Gaps and extensions were specific to our local market so not worth bringing back to W3C.<br />
<br />
Clarke Stevens:<br />
* Biggest issue with HTML5 is the disappointing testing effort.<br />
<br />
== Session 5 ==<br />
<br />
Louay Bassbouss:<br />
* .. For notification and application launch there is W3C Web Notifications, but it concentrates mostly only on local notifications. The notification is displayed outside the user agent. What we want is the notification to be displayed on another device, so we need an API to do that.<br />
<br />
== Session 6 ==<br />
<br />
David Singer: Should the web community be looking beyond just subtitling at wider accessible media support?<br />
<br />
Jan Lindquist: Should the TV Interest Group be pushing for a pluggable CDM component?<br />
<br />
== Session 7 ==<br />
<br />
Dong-Young Lee:<br />
* We need to standardize time synchronization for multi-screen apps.<br />
* Also, an abstraction layer to support various underlying technologies and protocols.<br />
<br />
== Other ==<br />
<br />
Pavel (Czech TV):<br />
* Better failure codes (as Jon mentioned)<br />
* More event notification<br />
<br />
Daniel (W3C):<br />
* Should W3C issue guidelines or advice to content authors on using WebVTT & TTML?<br />
* Is there a need for a "halfway house" DRM alternative - watermarking or email imprinting within media for dissuading, not preventing, piracy?<br />
<br />
Dave Raggett (W3C):<br />
* (In the discovery discussion) Wonders why no one has mentioned raw sockets API in sysapp. Is this because of lack of awareness?</div>Bsullivahttps://www.w3.org/2011/webtv/wiki/index.php?title=Media_APIs/Record_and_Download_Use_Cases&diff=2275Media APIs/Record and Download Use Cases2013-02-13T21:50:34Z<p>Bsulliva: /* Dashboard */</p>
<hr />
<div>== About this Task Force == <br />
<br />
The Recording and Downloading Media [download] task force (TF) is a subset of the Web and TV Interest Group. The goal of this TF is to discuss use cases and requirements for downloading, recording, and playing of locally stored/recorded media on the Web.<br />
<br />
'''**This is an initial draft. Your idea and feedback are welcomed.**'''<br />
<br />
== Background == <br />
<br />
This task force was initiated by a discussion in the TPAC 2012 on "Offline storage". Bryan Sullivan had suggested an agenda item for the [http://www.w3.org/2012/10/29-webtv-minutes.html Web & TV IG session]:<br />
* There is a proposal in Webapps to take the [http://dev.w3.org/2009/dap/file-system/file-dir-sys.html FileSystem API] off REC track. But there is no alternate proposal or effort to develop an explicit Gallery API. The Gallery API was dropped from DAP earlier when the FileSystem API was handed to Webapps, and gallery use cases expected to be implemented on top of them, e.g. with metadata extensions etc. <br />
* The ability to manage and access large amounts of locally stored content (local meaning on the device or in the local network) is key to enabling offline use cases. IMO this is one of the top 3 gaps in the current Web platform support for Web & TV (the other two are adaptive streaming and content protection). We either need to ensure that the File*/FileSystem APIs support these use cases, or that we have feasible support for network-local storage management/access from Web apps. <br />
* Network-local in this case means something accessible via HTTP (even device-locally served) or abstracted e.g. through a Gallery Intent (e.g. [http://www.w3.org/TR/2012/WD-gallery-20120712/ Pick Media Intent]) which allows the storage of media as well as "picking" something to play. But for local storage accessed directly through JavaScript APIs exposed by the Web browser/runtime (the preferred capability), we need either the earlier-envisioned functionality of the DAP FileSystem API, or Indexed DB APIs and storage support that supports in essence a high-performance/volume virtual filesystem managed by the browser.<br />
<br />
A summary of the discussion on this agenda topic:<br />
<br />
* Users want to download text, videos, etc content which needs to be locally cached, e.g. "download and go" or "download and view later" use cases.<br />
** Note: The Web & TV IG's [http://www.w3.org/TR/2011/NOTE-hnreq-20111201/ Requirements for Home Networking Scenarios] includes a use case for [http://www.w3.org/TR/2011/NOTE-hnreq-20111201/#control-of-content-recorders Control of Content Recorders] but not specifically for local storage on the end-user device. <br />
* However the current options for locally caching large amounts of content (e.g. videos) are limited to use of the [http://www.w3.org/TR/IndexedDB/ Indexed Database API], perhaps with support of a filesystem abstraction library such as the [http://ericbidelman.tumblr.com/post/21649963613/idb-filesystem-js-bringing-the-html5-filesystem-api idb.filesystem.js].<br />
* Defining the needed functionality (e.g. recording, downloading and playing from download ) first would enable other groups to determine the supporting technical approach, e.g. whether it's a database or file system API.<br />
* There is interest in this topic, and a task force will be proposed.<br />
<br />
== Dashboard ==<br />
<br />
=== Use Cases ===<br />
<br />
==== Download and Go ====<br />
<br />
Description: Using a web browser, a user downloads a series of videos onto a tablet, intending to use them to entertain the kids on a road trip.<br />
<br />
Need/justification: Accessing live video streams may not be possible (e.g. no network, or per content provider policy) or desirable (e.g. due to data usage or low QoE) when mobile or away from home. Nonetheless with video-capable devices, there will be a desire to be able to watch videos even in those circumstances.<br />
<br />
Status: WIP<br />
<br />
Category: TBD, per [http://www.w3.org/2011/webtv/wiki/Main_Page#Template_for_Use_Cases Template for Use Cases]. It is unclear whether the following requirements can be met with current specifications or implementations.<br />
<br />
Requirements:<br />
* Download<br />
** A method of referencing video sources for download, e.g. using anchor elements with [http://www.w3.org/TR/html5/single-page.html#downloading-resources the download attribute].<br />
* Content protection<br />
** Ability to store video content in a protected format, as applicable.<br />
** Ability to view previously stored protected video content, e.g. via the [https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html HTML5 Encrypted Media Extensions]<br />
* Storage<br />
** An adequately-sized storage medium; at least enough to store several full movies, e.g. 32GB<br />
** A method of accessing the storage medium to save videos, e.g.<br />
*** For local filesystem storage, the [http://dev.w3.org/2009/dap/file-system/file-writer.html File Writer API]<br />
*** For browser-internal storage, the [http://www.w3.org/TR/IndexedDB/ IndexedDB API]<br />
* Playback<br />
** A method of accessing the storage medium for video playback, e.g.<br />
*** The [http://www.w3.org/TR/FileAPI/ File API]<br />
*** [http://www.w3.org/TR/IndexedDB/ IndexedDB API]<br />
** Ability to view previously stored video content, e.g. via<br />
*** The [http://www.w3.org/TR/html5/single-page.html#the-video-element HTML5 video element] using a reference to a locally-stored file, provided through the [http://www.w3.org/TR/FileAPI/ File API]<br />
*** The [http://www.w3.org/TR/html5/single-page.html#the-video-element HTML5 video element] using a reference to a video stored in browser-internal storage, and accessed via the [http://www.w3.org/TR/IndexedDB/ IndexedDB API]<br />
** Ability to view previously stored protected video content, e.g. via the [https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html HTML5 Encrypted Media Extensions]<br />
<br />
----<br />
==== Watch and Record ====<br />
<br />
Description: Using a web browser, a user watches a video and records it at the same time.<br />
<br />
Need/justification: Ability to record a video while watching is a basic thing that many users will expect.<br />
<br />
Status: WIP<br />
<br />
Category: TBD, per [http://www.w3.org/2011/webtv/wiki/Main_Page#Template_for_Use_Cases Template for Use Cases]. It is unclear whether the following requirements can be met with current specifications or implementations.<br />
<br />
Requirements:<br />
* Recording while watching<br />
** Ability to store video content accessed via the [http://www.w3.org/TR/html5/single-page.html#the-video-element HTML5 video element], while the video is being presented in the browser.<br />
* Content protection<br />
** Ability to store video content in a protected format, as applicable.<br />
* Storage<br />
** An adequately-sized storage medium; at least enough to store several full movies, e.g. 32GB<br />
** A method of accessing the storage medium to save videos, e.g.<br />
*** For local filesystem storage, the [http://dev.w3.org/2009/dap/file-system/file-writer.html File Writer API]<br />
*** For browser-internal storage, the [http://www.w3.org/TR/IndexedDB/ IndexedDB API]<br />
<br />
----<br />
=== etc... ===<br />
* add a new use case!<br />
<br />
== Specification Proposals ==<br />
* TBD<br />
<br />
<br />
== Participants ==<br />
<br />
* Bryan Sullivan, AT&T (moderator)<br />
* Paul Gausman, AT&T<br />
* Mark Vickers, Comcast<br />
* Craig Smithpeters, Cox Communications, Inc.<br />
* Olivier Thereaux, BBC<br />
* Yosuke Funahashi, Tomo-digi<br />
* Giuseppe Pascale (Opera)<br />
* Glenn Adams (for Cox Communciations, Inc.)<br />
* [add your name here if you wish to participate in this TF]<br />
<br />
== Discussion & Calls ==<br />
<br />
* This TF primarily conducts its work on the public mailing list at [mailto:public-web-and-tv@w3.org public-web-and-tv@w3.org] ([http://lists.w3.org/Archives/Public/public-web-and-tv/ archive]) by prefixing the email subject with the TF identifier '''[download]'''.<br />
* Face-to-face meetings or conference calls may be organized, if necessary.</div>Bsullivahttps://www.w3.org/2011/webtv/wiki/index.php?title=Media_APIs/Record_and_Download_Use_Cases&diff=2214Media APIs/Record and Download Use Cases2012-11-27T22:54:37Z<p>Bsulliva: </p>
<hr />
<div>== About this Task Force == <br />
<br />
The Recording and Downloading Media [download] task force (TF) is a subset of the Web and TV Interest Group. The goal of this TF is to discuss use cases and requirements for downloading, recording, and playing of locally stored/recorded media on the Web.<br />
<br />
'''**This is an initial draft. Your idea and feedback are welcomed.**'''<br />
<br />
== Background == <br />
<br />
This task force was initiated by a discussion in the TPAC 2012 on "Offline storage". Bryan Sullivan had suggested an agenda item for the [http://www.w3.org/2012/10/29-webtv-minutes.html Web & TV IG session]:<br />
* There is a proposal in Webapps to take the [http://dev.w3.org/2009/dap/file-system/file-dir-sys.html FileSystem API] off REC track. But there is no alternate proposal or effort to develop an explicit Gallery API. The Gallery API was dropped from DAP earlier when the FileSystem API was handed to Webapps, and gallery use cases expected to be implemented on top of them, e.g. with metadata extensions etc. <br />
* The ability to manage and access large amounts of locally stored content (local meaning on the device or in the local network) is key to enabling offline use cases. IMO this is one of the top 3 gaps in the current Web platform support for Web & TV (the other two are adaptive streaming and content protection). We either need to ensure that the File*/FileSystem APIs support these use cases, or that we have feasible support for network-local storage management/access from Web apps. <br />
* Network-local in this case means something accessible via HTTP (even device-locally served) or abstracted e.g. through a Gallery Intent (e.g. [http://www.w3.org/TR/2012/WD-gallery-20120712/ Pick Media Intent]) which allows the storage of media as well as "picking" something to play. But for local storage accessed directly through JavaScript APIs exposed by the Web browser/runtime (the preferred capability), we need either the earlier-envisioned functionality of the DAP FileSystem API, or Indexed DB APIs and storage support that supports in essence a high-performance/volume virtual filesystem managed by the browser.<br />
<br />
A summary of the discussion on this agenda topic:<br />
<br />
* Users want to download text, videos, etc content which needs to be locally cached, e.g. "download and go" or "download and view later" use cases.<br />
** Note: The Web & TV IG's [http://www.w3.org/TR/2011/NOTE-hnreq-20111201/ Requirements for Home Networking Scenarios] includes a use case for [http://www.w3.org/TR/2011/NOTE-hnreq-20111201/#control-of-content-recorders Control of Content Recorders] but not specifically for local storage on the end-user device. <br />
* However the current options for locally caching large amounts of content (e.g. videos) are limited to use of the [http://www.w3.org/TR/IndexedDB/ Indexed Database API], perhaps with support of a filesystem abstraction library such as the [http://ericbidelman.tumblr.com/post/21649963613/idb-filesystem-js-bringing-the-html5-filesystem-api idb.filesystem.js].<br />
* Defining the needed functionality (e.g. recording, downloading and playing from download ) first would enable other groups to determine the supporting technical approach, e.g. whether it's a database or file system API.<br />
* There is interest in this topic, and a task force will be proposed.<br />
<br />
== Dashboard ==<br />
<br />
=== Use Cases ===<br />
<br />
==== Download and Go ====<br />
A user downloads a series of videos onto a tablet, intending to use them to entertain the kids on a road trip.<br />
<br />
=== Topics ===<br />
* add a new topic!<br />
<br />
<br />
== Specification Proposals ==<br />
* TBD<br />
<br />
<br />
== Participants ==<br />
<br />
* Bryan Sullivan, AT&T (moderator)<br />
* Paul Gausman, AT&T<br />
* Mark Vickers, Comcast<br />
* Craig Smithpeters, Cox Communications, Inc.<br />
* Olivier Thereaux, BBC<br />
* [add your name here if you wish to participate in this TF]<br />
<br />
== Discussion & Calls ==<br />
<br />
* This TF primarily conducts its work on the public mailing list at [mailto:public-web-and-tv@w3.org public-web-and-tv@w3.org] ([http://lists.w3.org/Archives/Public/public-web-and-tv/ archive]) by prefixing the email subject with the TF identifier '''[download]'''.<br />
* Face-to-face meetings or conference calls may be organized, if necessary.</div>Bsullivahttps://www.w3.org/2011/webtv/wiki/index.php?title=Media_APIs/Record_and_Download_Use_Cases&diff=2213Media APIs/Record and Download Use Cases2012-11-27T22:50:00Z<p>Bsulliva: </p>
<hr />
<div>== About this Task Force == <br />
<br />
The Recording and Downloading Media [download] task force (TF) is a subset of the Web and TV Interest Group. The goal of this TF is to discuss use cases and requirements for downloading, recording, and playing of locally stored/recorded media on the Web.<br />
<br />
'''**This is an initial draft. Your idea and feedback are welcomed.**'''<br />
<br />
== Background == <br />
<br />
This task force was initiated by a discussion in the TPAC 2012 on "Offline storage". Bryan Sullivan had suggested an agenda item for the [http://www.w3.org/2012/10/29-webtv-minutes.html Web & TV IG session]:<br />
* There is a proposal in Webapps to take the [http://dev.w3.org/2009/dap/file-system/file-dir-sys.html FileSystem API] off REC track. But there is no alternate proposal or effort to develop an explicit Gallery API. The Gallery API was dropped from DAP earlier when the FileSystem API was handed to Webapps, and gallery use cases expected to be implemented on top of them, e.g. with metadata extensions etc. <br />
* The ability to manage and access large amounts of locally stored content (local meaning on the device or in the local network) is key to enabling offline use cases. IMO this is one of the top 3 gaps in the current Web platform support for Web & TV (the other two are adaptive streaming and content protection). We either need to ensure that the File*/FileSystem APIs support these use cases, or that we have feasible support for network-local storage management/access from Web apps. <br />
* Network-local in this case means something accessible via HTTP (even device-locally served) or abstracted e.g. through a Gallery Intent (e.g. [http://www.w3.org/TR/2012/WD-gallery-20120712/ Pick Media Intent]) which allows the storage of media as well as "picking" something to play. But for local storage accessed directly through JavaScript APIs exposed by the Web browser/runtime (the preferred capability), we need either the earlier-envisioned functionality of the DAP FileSystem API, or Indexed DB APIs and storage support that supports in essence a high-performance/volume virtual filesystem managed by the browser.<br />
<br />
A summary of the discussion on this agenda topic:<br />
<br />
* Users want to download text, videos, etc content which needs to be locally cached, e.g. "download and go" or "download and view later" use cases.<br />
** Note: The Web & TV IG's [http://www.w3.org/TR/2011/NOTE-hnreq-20111201/ Requirements for Home Networking Scenarios] includes a use case for [http://www.w3.org/TR/2011/NOTE-hnreq-20111201/#control-of-content-recorders Control of Content Recorders] but not specifically for local storage on the end-user device. <br />
* However the current options for locally caching large amounts of content (e.g. videos) are limited to use of the [http://www.w3.org/TR/IndexedDB/ Indexed Database API], perhaps with support of a filesystem abstraction library such as the [http://ericbidelman.tumblr.com/post/21649963613/idb-filesystem-js-bringing-the-html5-filesystem-api idb.filesystem.js].<br />
* Defining the needed functionality (e.g. recording, downloading and playing from download ) first would enable other groups to determine the supporting technical approach, e.g. whether it's a database or file system API.<br />
<br />
== Dashboard ==<br />
<br />
=== Use Cases ===<br />
<br />
==== Download and Go ====<br />
A user downloads a series of videos onto a tablet, intending to use them to entertain the kids on a road trip.<br />
<br />
=== Topics ===<br />
* add a new topic!<br />
<br />
<br />
== Specification Proposals ==<br />
* TBD<br />
<br />
<br />
== Participants ==<br />
<br />
* Bryan Sullivan, AT&T (moderator)<br />
* Paul Gausman, AT&T<br />
* Mark Vickers, Comcast<br />
* Craig Smithpeters, Cox Communications, Inc.<br />
* Olivier Thereaux, BBC<br />
* [add your name here if you wish to participate in this TF]<br />
<br />
== Discussion & Calls ==<br />
<br />
* This TF primarily conducts its work on the public mailing list at [mailto:public-web-and-tv@w3.org public-web-and-tv@w3.org] ([http://lists.w3.org/Archives/Public/public-web-and-tv/ archive]) by prefixing the email subject with the TF identifier '''[download]'''.<br />
* Face-to-face meetings or conference calls may be organized, if necessary.</div>Bsullivahttps://www.w3.org/2011/webtv/wiki/index.php?title=Media_APIs/Record_and_Download_Use_Cases&diff=2212Media APIs/Record and Download Use Cases2012-11-27T22:37:29Z<p>Bsulliva: </p>
<hr />
<div>== About this Task Force == <br />
<br />
The Recording and Downloading Media [download] task force (TF) is a subset of the Web and TV Interest Group. The goal of this TF is to discuss use cases and requirements for downloading, recording, and playing of locally stored/recorded media on the Web.<br />
<br />
'''**This is an initial draft. Your idea and feedback are welcomed.**'''<br />
<br />
== Background == <br />
<br />
This task force was initiated by a discussion in the TPAC 2012 on "Offline storage". Bryan Sullivan had suggested an agenda item for the [http://www.w3.org/2012/10/29-webtv-minutes.html Web & TV IG session]:<br />
* There is a proposal in Webapps to take the [http://dev.w3.org/2009/dap/file-system/file-dir-sys.html FileSystem API] off REC track. But there is no alternate proposal or effort to develop an explicit Gallery API. The Gallery API was dropped from DAP earlier when the FileSystem API was handed to Webapps, and gallery use cases expected to be implemented on top of them, e.g. with metadata extensions etc. <br />
* The ability to manage and access large amounts of locally stored content (local meaning on the device or in the local network) is key to enabling offline use cases. IMO this is one of the top 3 gaps in the current Web platform support for Web & TV (the other two are adaptive streaming and content protection). We either need to ensure that the File*/FileSystem APIs support these use cases, or that we have feasible support for network-local storage management/access from Web apps. <br />
* Network-local in this case means something accessible via HTTP (even device-locally served) or abstracted e.g. through a Gallery Intent (e.g. [http://www.w3.org/TR/2012/WD-gallery-20120712/ Pick Media Intent]) which allows the storage of media as well as "picking" something to play. But for local storage accessed directly through JavaScript APIs exposed by the Web browser/runtime (the preferred capability), we need either the earlier-envisioned functionality of the DAP FileSystem API, or Indexed DB APIs and storage support that supports in essence a high-performance/volume virtual filesystem managed by the browser.<br />
<br />
A summary of the discussion on this agenda topic:<br />
<br />
* Users want to download text, videos, etc content which needs to be locally cached, e.g. "download and go" or "download and view later" use cases.<br />
** Note: The Web & TV IG's [http://www.w3.org/TR/2011/NOTE-hnreq-20111201/ Requirements for Home Networking Scenarios] includes a use case for [http://www.w3.org/TR/2011/NOTE-hnreq-20111201/#control-of-content-recorders Control of Content Recorders] but not specifically for local storage on the end-user device. <br />
* However the current options for locally caching large amounts of content (e.g. videos) are limited to use of the [http://www.w3.org/TR/IndexedDB/ Indexed Database API], perhaps with support of a filesystem abstraction library such as the [http://ericbidelman.tumblr.com/post/21649963613/idb-filesystem-js-bringing-the-html5-filesystem-api idb.filesystem.js].<br />
* Defining the needed functionality (e.g. recording, downloading and playing from download ) first would enable other groups to determine the supporting technical approach, e.g. whether it's a database or file system API.<br />
<br />
== Dashboard ==<br />
<br />
=== Use Cases ===<br />
<br />
==== Add a use case! ====<br />
An online gallery or photo-sharing service that shares stereo 3D images taken by 3D cameras, as well as 2D images.<br />
<br />
<br />
=== Topics ===<br />
* add a new topic!<br />
<br />
<br />
== Specification Proposals ==<br />
* TBD<br />
<br />
<br />
== Participants ==<br />
<br />
* Bryan Sullivan, AT&T (moderator)<br />
* Paul Gausman, AT&T<br />
* Mark Vickers, Comcast<br />
* Craig Smithpeters, Cox Communications, Inc.<br />
* Olivier Thereaux, BBC<br />
* [add your name here if you wish to participate in this TF]<br />
<br />
== Discussion & Calls ==<br />
<br />
* This TF primarily conducts its work on the public mailing list at [mailto:public-web-and-tv@w3.org public-web-and-tv@w3.org] ([http://lists.w3.org/Archives/Public/public-web-and-tv/ archive]) by prefixing the email subject with the TF identifier '''[download]'''.<br />
* Face-to-face meetings or conference calls may be organized, if necessary.</div>Bsullivahttps://www.w3.org/2011/webtv/wiki/index.php?title=Media_APIs/Record_and_Download_Use_Cases&diff=2211Media APIs/Record and Download Use Cases2012-11-27T22:25:51Z<p>Bsulliva: Created page with "== Background == This task force was initiated by a discussion in the TPAC 2012 on "Offline storage". Bryan Sullivan had suggested an agenda item for the [http://www.w3.org/201…"</p>
<hr />
<div>== Background == <br />
<br />
This task force was initiated by a discussion in the TPAC 2012 on "Offline storage". Bryan Sullivan had suggested an agenda item for the [http://www.w3.org/2012/10/29-webtv-minutes.html Web & TV IG session]:<br />
* There is a proposal in Webapps to take the [http://dev.w3.org/2009/dap/file-system/file-dir-sys.html FileSystem API] off REC track. But there is no alternate proposal or effort to develop an explicit Gallery API. The Gallery API was dropped from DAP earlier when the FileSystem API was handed to Webapps, and gallery use cases expected to be implemented on top of them, e.g. with metadata extensions etc. <br />
* The ability to manage and access large amounts of locally stored content (local meaning on the device or in the local network) is key to enabling offline use cases. IMO this is one of the top 3 gaps in the current Web platform support for Web & TV (the other two are adaptive streaming and content protection). We either need to ensure that the File*/FileSystem APIs support these use cases, or that we have feasible support for network-local storage management/access from Web apps. <br />
* Network-local in this case means something accessible via HTTP (even device-locally served) or abstracted e.g. through a Gallery Intent (e.g. [http://www.w3.org/TR/2012/WD-gallery-20120712/ Pick Media Intent]) which allows the storage of media as well as "picking" something to play. But for local storage accessed directly through JavaScript APIs exposed by the Web browser/runtime (the preferred capability), we need either the earlier-envisioned functionality of the DAP FileSystem API, or Indexed DB APIs and storage support that supports in essence a high-performance/volume virtual filesystem managed by the browser.<br />
<br />
A summary of the discussion on this agenda topic:<br />
<br />
* Users want to download text, videos, etc content which needs to be locally cached, e.g. "download and go" or "download and view later" use cases.<br />
** Note: The Web & TV IG's [http://www.w3.org/TR/2011/NOTE-hnreq-20111201/ Requirements for Home Networking Scenarios] includes a use case for [http://www.w3.org/TR/2011/NOTE-hnreq-20111201/#control-of-content-recorders Control of Content Recorders] but not specifically for local storage on the end-user device. <br />
* However the current options for locally caching large amounts of content (e.g. videos) are limited to use of the [http://www.w3.org/TR/IndexedDB/ Indexed Database API], perhaps with support of a filesystem abstraction library such as the [http://ericbidelman.tumblr.com/post/21649963613/idb-filesystem-js-bringing-the-html5-filesystem-api idb.filesystem.js].<br />
* Defining the needed functionality (e.g. recording, downloading and playing from download ) first would enable other groups to determine the supporting technical approach, e.g. whether it's a database or file system API.<br />
<br />
== Task Force Members ==<br />
<br />
* Paul Gausman, AT&T<br />
* Bryan Sullivan, AT&T <br />
<br />
Others that expressed an interest in the 2012 TPAC meeting:<br />
<br />
* Mark Vickers, Comcast<br />
* Craig Smithpeters, Cox Communications, Inc.<br />
* Olivier Thereaux, BBC<br />
<br />
== Goals ==<br />
<br />
== Logistics ==<br />
<br />
== Use Cases ==<br />
<br />
== Requirements ==</div>Bsulliva