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

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:
  https://slightlyoff.github.io/ServiceWorker/spec/service_worker/

2. The Push API could provide a mechanism to send a "wake up" 
notification to the device from a server:
  https://w3c.github.io/push-api/

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:
  https://github.com/slightlyoff/BackgroundSync/blob/master/explainer.md

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:
  https://github.com/slightlyoff/ServiceWorker/issues/602

... and "On push message" in "The offline cookbook" by Jake Archibald 
for a concrete example:
  http://jakearchibald.com/2014/offline-cookbook/#on-push-message

Thanks,
Francois

>
> 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/>
>
> *PAUL HIGGS *
> 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