- From: Ingar Arntzen via GitHub <sysbot+gh@w3.org>
- Date: Mon, 18 Jun 2018 19:10:39 +0000
- To: public-web-and-tv@w3.org
In respons to @Snarkdoof's [post](https://github.com/w3c/media-and-entertainment/issues/4#issuecomment-398069978) about the two approaches to synchronizing cue events and @nigelmegitt's [response](https://github.com/w3c/media-and-entertainment/issues/4#issuecomment-398078643) > The strongest requirements statement we can make is that we do want to achieve adequate synchronisation (whatever "adequate" is defined as) with minimal additional resource usage. I don't have have any input on the question on resource consumption, but a point concerning maximization of precision: It is an important principle to put the synchronization as close as possible to what is being synchronized. Another way to put it is to say that the final step matters. In approach 1, with sequencing logic internally in the media element, the last step is transport of the cue events across threads to JS. In approach 2, with sequencing logic in JS, the final step is the firing of a timeout in JS. This seems precise down to 1 or 2 ms. Additionally the correctness of the timeout calculation depends on the correctness by which *currentTime* can be calculated in JS, which is also very precise (and could easily be improved). I don't know the relevant details of approach 1). I'm worried that the latency of the thread switch might unknown or variable, and perhaps different across architectures. If so, this would detract from precision, but I don't know how much. Do anyone know? Also, in my understanding a busy event loop in JS affects both approaches similarly. -- GitHub Notification of comment by ingararntzen Please view or discuss this issue at https://github.com/w3c/media-and-entertainment/issues/4#issuecomment-398163071 using your GitHub account
Received on Monday, 18 June 2018 19:10:49 UTC