Media APIs/Record and Download Use Cases

From Web and TV IG
< Media APIs
Revision as of 18:30, 20 February 2013 by Ashimura (Talk | contribs)

Jump to: navigation, search

About this Task Force

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.

**This is an initial draft. Your idea and feedback are welcomed.**

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 Web & TV IG session:

  • There is a proposal in Webapps to take the 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.
  • 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.
  • Network-local in this case means something accessible via HTTP (even device-locally served) or abstracted e.g. through a Gallery Intent (e.g. 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.

A summary of the discussion on this agenda topic:

  • 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.
  • However the current options for locally caching large amounts of content (e.g. videos) are limited to use of the Indexed Database API, perhaps with support of a filesystem abstraction library such as the idb.filesystem.js.
  • 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.
  • There is interest in this topic, and a task force will be proposed.

Dashboard

Use Cases

Download and Go

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.

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.

Status: WIP

Category: TBD, per Template for Use Cases. It is unclear whether the following requirements can be met with current specifications or implementations.

Requirements:

  • Download
  • Content protection
    • Ability to store video content in a protected format, as applicable.
    • Ability to view previously stored protected video content, e.g. via the HTML5 Encrypted Media Extensions
  • Storage
    • An adequately-sized storage medium; at least enough to store several full movies, e.g. 32GB
    • A method of accessing the storage medium to save videos, e.g.
  • Playback

Watch and Record

Description: Using a web browser, a user watches a video and records it at the same time.

Need/justification: Ability to record a video while watching is a basic thing that many users will expect.

Status: WIP

Category: TBD, per Template for Use Cases. It is unclear whether the following requirements can be met with current specifications or implementations.

Requirements:

  • Recording while watching
    • Ability to store video content accessed via the HTML5 video element, while the video is being presented in the browser.
  • Content protection
    • Ability to store video content in a protected format, as applicable.
  • Storage
    • An adequately-sized storage medium; at least enough to store several full movies, e.g. 32GB
    • A method of accessing the storage medium to save videos, e.g.

etc...

  • add a new use case!

Specification Proposals

  • TBD


Participants

  • Bryan Sullivan, AT&T (moderator)
  • Paul Gausman, AT&T
  • Mark Vickers, Comcast
  • Craig Smithpeters, Cox Communications, Inc.
  • Olivier Thereaux, BBC
  • Yosuke Funahashi, Tomo-digi
  • Giuseppe Pascale (Opera)
  • Glenn Adams (for Cox Communciations, Inc.)
  • Sheau Ng (Comcast-NBCUniversal)
  • Kaz Ashimura, W3C
  • [add your name here if you wish to participate in this TF]

Discussion & Calls

  • This TF primarily conducts its work on the public mailing list at public-web-and-tv@w3.org (archive) by prefixing the email subject with the TF identifier [download].
  • Face-to-face meetings or conference calls may be organized, if necessary.