Re: Proposal HTMLSequencerObject [via Multi-device Timing Community Group]

Hi webtiming members.


We’ve not had much feedback yet on the proposed HTMLSequencerObject.


You'll find one comment here
https://www.w3.org/community/webtiming/2015/05/12/proposal-htmlsequencerobject/

I guess the main question is if this sequencer object (improved track
element) requires standardisation at all.


Here's my view. I don’t see any definitive arguments for standardisation.
Clearly, using a sequencer implementation provided by a public library
works fine. For example, we are using an implementation provided by Motion
Corporation (integrating directly with Shared Motion).

However, there are two softer arguments for standardisation that I would
like to point out. I'm curious to know what you think of these.

1) The sequencer is a central piece of the programming model*.

Standardisation of the sequencer concept would likely back up the
programming model and help programmers understand how to use it
effectively. For instance, in order to make a timed canvas presentation,
the programmer must know to connect timed-canvas operations (e.g. JSON
script) to a sequencer, and then to implement canvas operations in
sequencer callbacks.

*As mentioned before, we are arguing against the current video-centric
programming model, where video playback is used as (master) timing source
for other timed (slave) components (e.g., track elements). For one thing,
this model has weak support for media that includes multiple video
elements, or no video at all. Instead, we advocate a timing-centric
programming model, where the HTMLTimingObject is used as master timing
source. In this model all objects are mapped onto a common timeline, and
navigation/playback along this timeline defines which objects are valid at
different times. Of course, this also includes video, implying that videos
may be organised sequentially back-to-back, or that multiple videos may be
played simultaneously, or that certain segments on the timeline may have no
video at all. In any case, the sequencer implements the central function of
enabling/disabling timed objects at the correct time.

2) The sequencer provides unification of solutions from different
domains**.

By investing in a common sequencer, the confusion of a large selection of
similar, yet not identical solutions could be avoided. Also, one could
avoid a variety of half-hearted implementations, intended for specific data
formats or application scenarios. Instead, a strong sequencer
implementation can provide correctness, high precision, efficiency, and a
common API, useful for all things timed. The generic sequencer would
support any kind of navigation/playback supported by the HTMLTimingObject.
Additionally, support for dynamic mutation of sequencer data (during
operation) would allow integration with live data sources. This would
further support application scenarios with live authoring (during
playback), still without requiring any standardisation of data formats.
Such direct support for authoring completes the full circle and boosts the
programming model even more.

**It is clear that the sequencer is not a novel idea. Similar logic is part
of many frameworks from different domains. For example, the existing track
element provides a simple example, SMIL and Flash likely include similar
constructs, and the WebAudio API sequences audio samples. Indeed, any
framework that supports some kind of playback have at least rudimentary
logic for sequencing. A core inspiration behind the HTMLSequencerObject is
the possibility of providing a unified solution that can be used across
domains.


Best,

Ingar Arntzen




2015-05-12 13:27 GMT+02:00 W3C Community Development Team <
team-community-process@w3.org>:

> The timing group aims to improve the current timing model of the Web. The
> core
> idea of the group is to provide a new HTMLTimingObject for precise temporal
> control, and to modify/extend HTMLMediaElements and HTMLTrackElements so
> that
> they may interface directly with the HTMLTimingObject.
>
> This proposes HTMLSequencerObject as an improvement on the
> HTMLTrackElement.
>
> https://www.w3.org/community/webtiming/htmlsequencerobject/
>
> This document is not a draft specification, but mainly a presentation of
> the
> rationale behind this proposal. We invite feedback particularly on the
> following
> discussion points:
>
>         Should we, as suggested, advocate the introduction of a new
> HTMLSequencerObject and keep the existing HTMLTrackElement for backward
> compatibility? Or should we rather advocate changes to the original
> HTMLTrackElement.
>         Is HTMLSequencerObject an appropriate name? Does the term
> “sequencer” have
> too much baggage from the context of music and audio processing? Other
> possible
> names may include : HTMLTrackObject, HTMLSchedulerObject, other
> suggestions?
>         What would be reasonable as next step, a draft specification for
> the
> HTMLSequencerObject, or a bug report for the HTMLTtrackElement?
>
>
>
>
>
> ----------
>
> This post sent on Multi-device Timing Community Group
>
>
>
> 'Proposal HTMLSequencerObject'
>
>
> https://www.w3.org/community/webtiming/2015/05/12/proposal-htmlsequencerobject/
>
>
>
> Learn more about the Multi-device Timing Community Group:
>
> https://www.w3.org/community/webtiming
>
>
>
>