W3C home > Mailing lists > Public > public-webtiming@w3.org > August 2015

Re: Media Element and Timing Objects

From: Francois Daoust <fd@w3.org>
Date: Wed, 19 Aug 2015 13:37:12 +0200
Message-ID: <55D46A68.1010404@w3.org>
To: Ingar Mæhlum Arntzen <ingar.arntzen@gmail.com>, public-webtiming@w3.org
On 2015-08-06 14:30, Ingar Mæhlum Arntzen wrote:
> Hi all.
> I have gone through section 9 describing how media elements may be extended with support for timing objects as an external timing source.
> http://webtiming.github.io/timingobject/#media-elements-and-timing-objects

FWIW, anchor has changed, so right link is now:

> Changes include:
> -  added introduction with explanatory text, defining "default playback mode" and "timed playback mode" for media elements

I like it :)

> - minor changes to existing text/procudures

I note that this part is mostly underspecified at present. The first rough procedures I had come up with were incorrect, yours do not say much as to how things are to happen in the media player.

In particular, the interaction between the user agent and the timing provider code is not trivial: by definition, timing provider code is JS code so must be bound to an event loop, whereas I would assume the internal media player runs (native code) in its own thread. What that means is that the internal media player cannot call the now() method of the timing provider object whenever it wants to, it must "queue a task" each time. One possibility would be to run the code of the timing provider object in a separate JavaScript realm as described in issue #10 (and as done for other reasons in WebRTC).

Anyway, I think we only need to realize that more work is needed on that part, but the spec is explicit enough about the intent to start reaching out to other people.

> - changed spec so that .currentTime of media element directed by timing object reports currentTime of internal media player, instead of position of the timing object.
> Would there any objections to this?

That works for me.

> The spec currently states that setting .currentTime on the mediaelement should be prohibited. This is the case for MediaControllers. An attractive (in my view) alternative would be to map setting of currentTime onto a request to the timing object. Following this approach, other media control commands such as play and pause could be mapped similarly.
> Would it be problematic to be inconsistent with the MediaController on this issue.?

I guess it would be interesting to understand why that is prohibited in the case of MediaControllers before. I do not know why.

Received on Wednesday, 19 August 2015 11:37:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:25:14 UTC