W3C home > Mailing lists > Public > public-web-and-tv@w3.org > May 2013

RE: [apis] Download and Go use case

From: HU, BIN <bh526r@att.com>
Date: Thu, 16 May 2013 14:06:20 +0000
To: JC Verdié <jc.verdie@mstarsemi.com>
CC: Web & TV IG <public-web-and-tv@w3.org>
Message-ID: <179FD336116F754C876A9347238FE29A01039285@WABOTH9MSGUSR8L.ITServices.sbc.com>
JC,

Thank you, and I made the changes in [1] (and re-phrased it a little it).
Cheers

Bin

[1] http://www.w3.org/2011/webtv/wiki/Download#Download_and_Go


-----Original Message-----
From: JC Verdié [mailto:jc.verdie@mstarsemi.com] 
Sent: Wednesday, May 15, 2013 11:27 PM
To: HU, BIN
Cc: Web & TV IG
Subject: Re: [apis] Download and Go use case

Hi Bin

Yes you understood correctly :)

Regards
JC
 

On 15 mai 2013, at 22:24, "HU, BIN" <bh526r@att.com> wrote:

> Hello JC,
> 
> Thank you for your comments, and those are very valuable to improve our use cases and hence the requirement.
> 
> I have made the changes of your first 2 comments, i.e. transferring media and accounting the number of coexisting instances. Please see [1].
> 
> With regard to your 3rd comment, i.e. "+ a method for accessing to file access validity (including an offline clearance method)", I am not quite sure if I understand it correctly. Do you mean that the offline storage of the content should only be valid for a limited lifecycle, e.g. 24 hours? Once the time expires, the content storage should be cleared?
> 
> Thank you
> Bin
> 
> [1] http://www.w3.org/2011/webtv/wiki/Download#Download_and_Go

> 
> -----Original Message-----
> From: JC Verdié [mailto:jc.verdie@mstarsemi.com] 
> Sent: Wednesday, May 15, 2013 2:39 AM
> To: Web & TV IG
> Subject: [apis] Download and Go use case
> 
> Dear TF,
> 
> I have a few comments on the Download and Go use case [1]: Some content 
> providers (or content owners) do not allow multiple instances of the 
> same protected content to coexist. For instance if you rent a movie on 
> iTunes from your computer and decide to watch it on your iPad, you will 
> have to "transfer" it. The movie being now visible on the iPad but not 
> anymore on the computer. On the same vein of constraints, other media 
> can coexit in multiple but limited places (e.g. only X copies of the 
> same protected file). I appreciate that these constraints probably fall 
> in EME's basket but I feel uncomfortable with not seeing them in the use 
> case description.
> 
> I would suggest the following modifications on the use case (lines 
> starting with a +)
> 
> Requirements:
> 
> Download
> A method of referencing video sources for download, e.g. using anchor 
> elements with the download attribute.
> 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
> + Ability to transfer media in a single operation (not copy-then-delete)
> + Ability to account & verify the number of coexisting instances of the 
> media
> 
> 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.
> For local filesystem storage, the File Writer API
> For browser-internal storage, the IndexedDB API
> + a method for accessing to file access validity (including an offline 
> clearance method)
> 
> Playback
> A method of accessing the storage medium for video playback, e.g.
> The File API
> IndexedDB API
> Ability to view previously stored video content, e.g. via
> The HTML5 video element using a reference to a locally-stored file, 
> provided through the File API
> The HTML5 video element using a reference to a video stored in 
> browser-internal storage, and accessed via the IndexedDB API
> Ability to view previously stored protected video content, e.g. via the 
> HTML5 Encrypted Media Extensions
> 
> Regards,
> JC
> 
> 
> [1] http://www.w3.org/2011/webtv/wiki/Download#Download_and_Go

> 
> 
> 
> 
Received on Thursday, 16 May 2013 14:07:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:44:09 UTC