- From: Snarkdoof via GitHub <sysbot+gh@w3.org>
- Date: Mon, 18 Jun 2018 14:18:30 +0000
- To: public-web-and-tv@w3.org
@tidoust It's a good point that the "internal" loop of Time Marches On does not trigger JS events every time, but increasing the loop speed of any loop (or doing more work in each pass) will use more resources. As I see it there are two main ways of timing things that are relevant to media on the web: 1: Put the "sequencer" logic (what's being triggered when) inside the browser and trigger events and 2: Put the "sequencer" logic in JS and trigger events If 1) is chosen, a lot more complexity is moved to a very tight loop that's frankly busy with more important stuff. It is also less flexible as arbitrary code cannot be run in this way (nor would we want it to!). 2) depends solely on exporting a timestamp with the currentTime (and preferably other media events too), which would allow a JS Timing Object to accurately export the internal clock of the media. As such, a highly flexible solution can be made using fairly simple tools, like the open timingsrc implementation. Why would we not want to choose a solution that is easier, more flexible and if anything, saves CPU cycles? cuechange also has a lot of other annoying issues, like not trigging when as skip event occurs (e.g. jumping "mid" subtitle), making it necessary to cut and paste several lines of code to check the active cues to behave as expected. -- GitHub Notification of comment by Snarkdoof Please view or discuss this issue at https://github.com/w3c/media-and-entertainment/issues/4#issuecomment-398069978 using your GitHub account
Received on Monday, 18 June 2018 14:18:32 UTC