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

On 2015-03-04 16:41, Jon Piesing wrote:
>> -----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.

No, we deliberately ignored you ;) More seriously, I was personally 
hoping someone else would come up with a better answer than what I had 
in mind. Well, that's still possible, folks!


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

I guess part of what standby means in practice will remain out of scope 
of any W3C spec. For instance, the Push API is meant to run on mobile 
devices in low consumption mode, relying on the device's usual push 
mechanism, even if the browser is not running. I don't know how that 
spec will be implemented in practice but it seems reasonable to think it 
will use as little power as possible (well, some radio system must 
remain active in the case of the Push API, of course).

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

Note the Service Workers spec does not handle the standby mode in 
itself, only when combined with other specs. In other words, as the 
abstract of the spec says, "the service worker is a generic entry point 
for event-driven background processing in the Web Platform that is 
extensible by other specifications".

Events can be triggered by a running Web app (defined in the Service 
Workers spec and not what you're looking for), by the Push API (incoming 
messages are delivered to a registered Service Worker), or by the 
Background Synchronization spec (synchronization events are dispatched 
to the underlying Service Worker code), and I think that's about it for now.

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

Right. If there's no push service running in standby mode on TVs, which 
indeed seems like a reasonable assumption, the Push API is of no use. I 
mentioned it because, as things stand, it would seem to provide a more 
precise control over the time when the "wake up" notification is 
processed, but I agree that's not what you will want to use in the end.

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

Right. Then it might be a good idea for this CG to reach out to the 
WebApps WG to wonder whether Background Synchronization could be somehow 
adjusted for TV needs, whether a third extension spec on top of Service 
Worker to provide a proper alarm mechanism that could have enough 
permissions to run possibly long tasks seems doable, or whether we need 
something else entirely.

Francois.

Received on Wednesday, 4 March 2015 17:37:40 UTC