W3C home > Mailing lists > Public > public-tvapi@w3.org > March 2015

Re: tvapi-ACTION-24: use of Media Capture to realize recording requirements

From: Francois Daoust <fd@w3.org>
Date: Wed, 04 Mar 2015 10:40:12 +0100
Message-ID: <54F6D2FC.20905@w3.org>
To: Jon Piesing <Jon.Piesing@tpvision.com>, Paul Higgs <paul.higgs@ericsson.com>, "public-tvapi@w3.org" <public-tvapi@w3.org>
Hi Jon, all,

On 2015-02-24 16:26, Jon Piesing wrote:
> Dear Paul, all,
> Since I've not participated in this group before, I apologise in advance
> if I've mis-understood something ....
> I have a question about the proposal below to use the MediaStream
> Recording API for recording in a TV context. How would this work if the
> device was in standby at the time the recording needed to happen?
> Something would need to cause the device to wake up from standby, start
> the UA and load the page containing the calls to that API. I've had a
> quick look at the device API work and cannot see an API there to
> schedule a device to wake from standby. The OIPF browser group that I
> chaired created such an API but it would need to be supported by some
> kind of security model which OIPF never properly addressed. IMHO such an
> API would not be safe to make available to an arbitrary web page.

That's a good question. The Web Applications Working Group might be a 
better group to look at here. In particular, trying to map this use case 
to on-going efforts there as a way to precise gaps and specific needs:

1. Within Web browsers, Service Workers provide the basic foundation to 
handle the "standby" mode:

2. The Push API could provide a mechanism to send a "wake up" 
notification to the device from a server:

3. If scheduling is to be a client-side only activity, Background 
Synchronization (early work at this stage) could perhaps be used, 
although it is not designed to be an exact alarm API:

Code running in a Service Worker is not meant to run for a long period 
of time (whereas recording may last for a few hours), so effectively 
needs to open up something where recording takes place. I think it is 
possible to open a Web app from a Service Worker but there will be 
restrictions such as "provided the user clicks on a notification first" 
which does not really work well with scheduling recording. To be 
investigated further but that probably won't work out of the box.

See a related issue on Service Workers:

... and "On push message" in "The offline cookbook" by Jake Archibald 
for a concrete example:


> Have I missed something?
> Regards
> Jon Piesing
> TP Vision
> ------------------------------------------------------------------------
> *From:* Paul Higgs [paul.higgs@ericsson.com]
> *Sent:* 19 February 2015 21:38
> *To:* public-tvapi@w3.org
> *Subject:* tvapi-ACTION-24: use of Media Capture to realize recording
> requirements
> Hi
> During the February 17 TV Control API conference call, I took an action
> [1] to review the MediaStream Recording API [2] for its relevance and
> use in fulfilling the requirements around recording [3]
> It is possible to see that an TVTuner defined in the TV Control API can
> “output” via a MediaStream which can then me recorded through the
> MediaRecorder API. In order to do this, the MediaRecorder constructor
> requires the mime type of the TVTuner output, so a “readonly attribute
> DOMString  mimeType” attribute should be added to the TVTuner interface.
> At a period denoted by the timeSlice property, the ondataavailable event
> handler is trigger, an argument to which is the recorded data. The
> application implementing this handler would then need to write the
> capture stream data to a file (perhaps via the File API [4]). The
> MediaStream Recording API also has the ability to throw a
> “MediaRecorderErrorEvent” with name=OutOfMemory
> What this means is that there is no native recording functionality in
> the device implementing TVManager.  Instead one of the applications
> running on the terminal is the “recording scheduler” (how that
> application gets and manages data is probably application specific).
> Note that this requires the UA support some form of “background
> application”.
> In essence, the requirement mapping table should, for each of the
> [recording.*] requirements, state “not supported, realized through the
> webapp and MediaStream Recording API”
> [1] http://www.w3.org/community/tvapi/track/actions/24
> [2] http://www.w3.org/TR/mediastream-recording/
> [3]
> https://www.w3.org/community/tvapi/wiki/Main_Page/Technical_Requirement#Program_Recording_Requirements
> [4] http://www.w3.org/TR/FileAPI/
> Description: Ericsson <http://www.ericsson.com/>
> Technical Solutions Manager
> Ericsson Inc
> *Ericsson*
> 6 Concourse Parkway, suite 400
> Atlanta, GA 30328, United States of America
> Phone +1 (650) 580-1731
> paul.higgs@ericsson.com
> www.ericsson.com
> Description: http://www.ericsson.com/current_campaign
> <http://www.ericsson.com/current_campaign>
> Legal entity: Ericsson AB, registered office in Kista, Sweden. This
> Communication is Confidential. We only send and receive email on the
> basis of the terms set out at www.ericsson.com/email_disclaimer
> <http://www.ericsson.com/email_disclaimer>
Received on Wednesday, 4 March 2015 09:40:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:45:13 UTC