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

Re: HTMLTimingObject - reference point

From: Francois Daoust <fd@w3.org>
Date: Fri, 12 Jun 2015 11:33:45 +0200
Message-ID: <557AA779.4070504@w3.org>
To: Ingar Mæhlum Arntzen <ingar.arntzen@gmail.com>, public-webtiming@w3.org, oskar.vandeventer@tno.nl
Hi Ingar, Oskar,

On 2015-06-12 10:37, Ingar Mæhlum Arntzen wrote:
> Hi Oskar
>
> Again, about the "reference" point, I think this definition is more
> about establishing convention than a formal requirement. The timing
> object is open to different uses, and this should probably include the
> freedom to define reference point for media playback according to
> application specific conventions. However, in circumstances where
> components are developed by different developers and intended for reuse
> across application boundaries, universal convention is very useful. As
> interoperability is a major motivation for the HTMLTimingObject I think
> it makes sense to clarify convention regarding playback reference point.

I'm jumping in to note that HTML5 defines "current playback position":
http://www.w3.org/html/wg/drafts/html/master/semantics.html#current-playback-position

The definition does not link to the concept of a "reference point". The 
closest thing to expressing the relation between that position and the 
frame rendered on screen is a bit below in the spec:

[[
The video element represents the frame of video at the continuously 
increasing "current" position. When the current playback position 
changes such that the last frame rendered is no longer the frame 
corresponding to the current playback position in the video, the new 
frame must be rendered.
]]

Am I right to assume that the goal here would be to extend that 
definition to precise the mapping between position and actual 
audio/video output?


About establishing convention vs. formal requirement, I guess the 
question is whether the timing object specification will specify how 
user agents must integrate timing object with media elements. It does 
not say anything about that relation right now, so mandating a 
particular interpretation of a timing object's current position does not 
mean much, indeed.

This relationship may be defined in a separate spec as alluded to in the 
list of tasks the CG will work on. It may make sense to do that in the 
timing object spec directly though. I mean, the spec is not insanely big 
and modularization could take place later on if needed.

Thanks,
Francois.
Received on Friday, 12 June 2015 09:34:04 UTC

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