Re: HTMLTimingObject - reference point

Hi all.

I updated the timing object spec with new subsections

1.5 Media capture and playback
1.6 Reference point in capture and playback

,on the basis of this discussion.

http://webtiming.github.io/timingobject/#media-capture-and-playback

Ingar


2015-06-12 15:18 GMT+02:00 Ingar Mæhlum Arntzen <ingar.arntzen@gmail.com>:

>
> Hi Francois.
>
> I agree that the HTMLTimingObject spec does not say anything about how
> user agent intergrates timing objects with components for purposes of
> playback or capture. Strictly speaking, it follows as Francois indicates
> that it should not be part of the spec at all, and instead be a topic of
> other specs. At the same time, agreements on reference point across
> different specs such as Web Audio and Media players for playback, as well
> as getUserMedia and similar for capture would be nice. I guess we could
> express a wish for this by encouraging a particular convention - and - in
> lack of a better place include a section on this in the TimingObject spec?
>
> "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?"
>
> I suppose also that this topic has already been explored in the media
> element specs, for instance with respect to aligning audio and video?
> Maybe its not the most pressing issue for the timing group at this time?
>
> I don't have a strong opinion here.
>
> Ingar
>
>
> 2015-06-12 11:33 GMT+02:00 Francois Daoust <fd@w3.org>:
>
>> 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.
>>
>
>