Re: [me-media-timed-events] Rewrite gap analysis and recommendations for sync (#38)

> Related to Nigel's feedback, I'm not sure it's accurate to say that `setTimeout` / `setInterval` schedule to points on a wall clock. For example, the HTML spec has a note: "This API does not guarantee that timers will run exactly on schedule. Delays due to CPU load, other tasks, etc, are to be expected."

That's right. I tried to keep things simple. That is inherent to the events mechanism on the Web platform: there is no guarantee that an event will be fired at any specific moment. You can control when the event enters the queue, not when it is fired. In addition, `setTimeout` / `setInterval` gives freedom to user agents to delay the schedule as they see fit.

I guess you could point out somewhere that there is no guarantee anywhere that events will fire at a specific point in time. That is true for `enter`, `exit`, `cuechange`, etc.

> In 5.2.1 we should link to the media timeline definition.

Done.

> In my draft, I separated `timeupdate` into its own section from polling with a timer loop, as these aren't quite the same. Can I add this change to your branch?

Sure!

> In 5.2.3, regarding `currentTime`, [as Nigel mentioned before](https://lists.w3.org/Archives/Public/public-web-and-tv/2019Feb/0041.html), the goal is to synchronize to points in time rather than frames.

There are different use cases with different goals. The goal is not always to synchronize to points in time rather than frames. The use case in 3.4 actually presents a case where synchronization needs to happen at frame boundaries. I make that distinction in 5.2 before that section. Section 5.2.3 looks at ways to detect frame boundaries when that is needed. It does not claim that this is always needed, but feel free to add some text!


-- 
GitHub Notification of comment by tidoust
Please view or discuss this issue at https://github.com/w3c/me-media-timed-events/pull/38#issuecomment-465718411 using your GitHub account

Received on Wednesday, 20 February 2019 19:23:00 UTC