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

> -----Original Message-----
> From: Francois Daoust [mailto:fd@w3.org]
> Sent: Wednesday 4 March 2015 10:40 AM
> To: Jon Piesing; Paul Higgs; public-tvapi@w3.org
> Subject: Re: tvapi-ACTION-24: use of Media Capture to realize recording
> requirements
> 
> Hi Jon, all,

Hi Francois,

Thank you for replying.  I was beginning to think there was some subtle problem where the email had only gone to the archive and not to the email list.

> 
> 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:
> 

Standby power consumption is important for TV sets. In some markets it is covered by regulation. In some markets, consumer magazines or web sites reviewing TV sets will measure it themselves as part of their review process.
There are many, many subtle variations on standby states for devices but in many of them the main processor of the device will not be running. Resuming from standby at a particular time will be handled by a micro-controller or by a low power core in the main chip which can be powered independently of the main processor. It's unlikely that a Wifi interface would be powered in most standby states.

> 1. Within Web browsers, Service Workers provide the basic foundation to
> handle the "standby" mode:
>   https://slightlyoff.github.io/ServiceWorker/spec/service_worker/

> 

I've gone back and re-read this spec. Can you add a little more detail about how you see this handling standby mode? It's not at all obvious to me.

> 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/

> 

I don't see how this would help in the many (significant majority?) of standby modes where the WiFi or Ethernet interfaces aren't powered. Have I missed something?

> 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

> 

That certainly is much closer however an exact alarm is unfortunately what I think would be needed if media capture was to be used in this way. The TV/STB would need to wake up a few minutes before the scheduled start of the recording. Waking up the TV/STB more than a few minutes before this will be wasting energy. Missing the start of the recording will give an unacceptable user experience.

> 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.

I agree. Scheduled recordings need to work without anyone present at the time of the recording.

Jon

> 
> 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_Require

> men
> > t#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 15:42:10 UTC