Re: HTMLTimingObject - reference point

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.

In the context of DVB/HbbTv CSS this may well be more of a requirement
though.

Would you agree Oskar?

Ingar

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

> Hi all.
>
> Oskar van Deventer of TNO has indicated an unclarity in the
>  HTMLTimingObject draft spec.
>
> Oskar has been involved in sync activities of DVB CSS and HbbTV 2.0. He is
> now working with Media Orchestration in the context of MPEG, where the
> HTMLTimingObject is one of the considered technologies.
>
> The unclarity refers to a "reference point", a concept discussed in DVB
> CSS but not in the timing object spec.
>
> To indicate the issue, consider the following use case: A user agent
> (STB/TV) receives a media stream and seeks to maintain a HTMLTimingObject
> as a representation of the current playback position. To do this timestamps
> need to be extracted from the stream data. The question is, what exactly
> defines current playback position? The last block currently decoded? Or,
> perhaps do we rather mean when pixels hit the screen?
>
> This is the reference point, and dis-agreement on reference point may be a
> source of (small) sync errors. In DVB CSS the reference point is defined as
> when pixels hit screen, or when audio is output from speakers. Since
> timestamps can not be extracted at these locations, they must instead be
> extracted earlier in the processing chain and then adjusted according to
> expected downstream latency.
>
> The HTMLTimingObject draft currently does not define a reference point.
>
> My suggestion is that we simply adopt the definition used by DVB CSS and
> update the draft spec to reflect this.
>
> This implies that the HTMLTimingObject (director of playback) ideally
> represents the effects of timed operations (rather than their initiation).
> It follows that components that take direction from the timing object and
> has a non-negligible latency for operations to take effect, must issue
> operations slightly in advance (according to expected latency).
>
> If there are no objections, I'll go ahead and update the spec shortly.
>
> Thank you Oskar for bringing this issue to our attention.
>
>
> Best,
>
> Ingar
>
>
>
>
>
>