Re: TimingMediaController prototype (was: Re: Sequencer prototype)

Oh. When I read the sequencer.play() line I still hadn't realised that it
wasn't a sequencer ;)

The play command of course makes more sense on (a wrapped) media element :)
. Ideally though we would not have to use the built-in controls of the
media element (as they would be limited to the timeline of the media
element), but rather have independent controls that binds directly to the
timing object.

About the mediacontroller - I read recently on a post by the media task
force that chrome was rumoured to drop the current media controller. A
deprecated media controller would imply that there is no support for sync
of media elements. A nice gap for the timing object to fill :)

Ingar


2015-06-18 17:40 GMT+02:00 Francois Daoust <fd@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
> confusion.
>
>
>> 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.
>
> Thanks,
> Francois.
>