- From: Francois Daoust <fd@w3.org>
- Date: Fri, 12 Jun 2015 11:33:45 +0200
- 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