Re: Sequencer prototype

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.

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

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]

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 (!)

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"
}

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.


[1] https://www.w3.org/community/webtiming/overview/

Hope this was clarifying.

Best, Ingar





As



2015-06-18 14:03 GMT+02:00 Francois Daoust <fd@w3.org>:

> Hi,
>
> Pursing my exploration of synchronization concepts and interfaces that
> could help Web developers who, like me, are not experts in synchronization
> issues, I implemented a first version of a "Sequencer" class to coordinate
> the playback of one or more media elements with a timing object.
>
> Ingar, I don't know if my sequencer matches what you had in mind with the
> HTMLMediaSequencer. If not, I'll just rename to something along the lines
> of "TimingObjectController".
>
> The source code is in the same Git repo as before, on GitHub:
> https://github.com/tidoust/timingservice
>
> The Sequencer class is defined in:
> https://github.com/tidoust/timingservice/blob/master/src/Sequencer.js
>
> From a Web developer perspective, the code needed to use a sequencer
> associated with a timing object that is in turn associated with an online
> timing service through some "SocketTimingProvider" class would look like:
>
> =====
> // Create the timing object
> // (SocketTimingProvider provided by the online timing service)
> var timingProvider = new SocketTimingProvider('ws://...');
> var timing = new TimingObject();
> timing.srcObject = timingProvider;
>
> // Create the sequencer that takes input from the timing object
> var sequencer = new Sequencer(timing);
>
> // Add video to the slaved media elements of a sequencer
> var video = document.getElementById('myvideo');
> sequencer.addMediaElement(video);
>
> // Attach video controls to the sequencer
> playButton.onclick = function () { sequencer.play(); };
> pauseButton.onclick = function () { sequencer.pause(); };
> =====
>
> The interface exposed by the Sequencer is voluntarily close to that of a
> MediaController (play, pause, currentTime, playbackRate). If browsers start
> implementing something similar, it would probably make sense to replace the
> call to "addMediaElement" with a more familiar "video.controller =
> sequencer;" and perhaps attach the video controls to the sequencer
> automatically under the hoods.
>
> It is "close to" but not exactly the same as the MediaController
> interface. In particular, the "readyState" attribute of the sequencer
> currently represents the state of the timing object, not that of the media
> elements. I'm not sure how to handle the whole part about buffering for the
> time being. This does not map well with the timing object approach.
>
>
> Check the "How to use" section in the README of the Git repo to try out a
> concrete example in your browser. The result depends on the browser and
> platform you will be using. It is somewhat good with video, less so with
> audio.
>
> This "so-so" outcome is due to the low-quality of this implementation (in
> other words, I do not doubt that one can do much better), but some of it is
> probably also due to the fact that controlling a video externally by
> adjusting its playback rate is inherently not very efficient.
>
> Thanks,
> Francois.
>
> PS: I also improved the clock synchronization mechanism. The whole code
> should still be regarded as "rough", though ;)
>
>