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

TimingMediaController prototype (was: Re: Sequencer prototype)

From: Francois Daoust <fd@w3.org>
Date: Thu, 18 Jun 2015 17:40:44 +0200
Message-ID: <5582E67C.8010903@w3.org>
To: Ingar Mæhlum Arntzen <ingar.arntzen@gmail.com>
CC: public-webtiming@w3.org
Hi Ingar,

On 2015-06-18 16:47, Ingar Mæhlum Arntzen wrote:
> Hi Francois
> Great that you have some code-activity going on. I will likely join your
> efforts by contributing some code for timing object and sequencer (from
> the MediaScape repository) in the not so distant future.

Cool! :)

> Regarding your sequencer prototoype - this is actually NOT what I had in
> mind for the HTMLSequencerObject.

Sorry for the naming confusion. In my defense, I did feel that something 
was wrong there ;)

I updated the name to TimingMediaController throughout the code. That is 
awful but at least shows that this is intended to be a type of 
MediaController and leaves the "sequencer" name for its real intended use.

> What you are proposing is, as you say, something similar to a
> mediacontroller, except it takes the HTMLTimingObject as source of
> timing/control.
> If you simplify your prototype to support only one media element (not
> multiple), you'll effectively get a primitive version of the sync
> wrapper that we are using to allow media elements to be directed by
> HTMLTimingObject. This corresponds to task 2 TimingEnabled
> HTMLMediaElement [1]

Task 2 was indeed what I was shooting for ;)

> Given such a wrapper, if you then want to sync multiple media elements,
> no media controller is required, just connect each media element with
> the same timing object (!)

I see your point about extending media elements directly and about 
exposing the TimingObject more prominently since it has other usages.

I guess I started from an opposite perspective: given how a developer 
would do single-device media synchronization today, using a 
MediaController, what would be the minimal amount of changes needed to 
enable cross-device synchronization? With a TimingMediaController, the 
developer would only need to change the code that creates the media 
controller, but the rest would remain intact. If media synchronization 
is all that's needed, learning about timing objects is not even needed.

> In contrast, the HTMLSequencerObject is task 3 and has nothing to do
> with audio/video. It works exclusively on timed data, i.e., objects tied
> to (time)intervals.
> object1 -> [23.3, 37.8]
> object2 -> [14.2, 38.1]
> ...
> The sequencer will only let you know when these objects become valid or
> invalid, with reference to the HTMLTimingObject
> With
> object 1 = {
>    video : "http://videohost/videoID",
>    timingsrc : "time://timinghost/timingID"
> }

Now I get it, thanks for the clarification and sorry again for the 

> you may implement a handler for the "onvalid" event that instantiates a
> video element (dynamically) on your page (whenever the sequencer tells
> you it should be valid), and then connect a timing object to the video
> element dynamically if needed. The timing object connected to the video
> may or may not be the same timing object that drives the sequencer.
> Finally,
> the following lines in your api reveals an anti-pattern in my opinion.
> // Attach video controls to the sequencer
> playButton.onclick = function () { sequencer.play(); };
> pauseButton.onclick = function () { sequencer.pause(); };
> The sequencer should NOT support any control. Any control operations
> should go to the timing object. You are doing this correctly in your
> code, so my only concern here is that by additionally providing
> redundant control features on the sequencer you are obscuring where the
> actual control point is.

As said above, I "obscured" things on purpose to keep Web developers in 
known grounds, but I do see your point. I also understand why you might 
prefer to deprecate the concept of MediaController entirely. I don't 
think one approach necessarily excludes the other. I'll create wrapper 
code as suggested.

Received on Thursday, 18 June 2015 15:40:53 UTC

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