The event loop often runs at a different frequency than the underlying video, so frames will span multiple loops.There will be buffering and jitter in the intermediate thread hops. The JS event loop will run in a different thread than the one painting pixels on the screen.There are a number of implementation constraints that are going to make it challenging to provide a completely accurate instantaneous frame number or presentation timestamp in a modern browser during video playback. For video editing use cases, remote playback is not as relevant (except maybe to render the final output). Remote playback cases are always going to be best effort to keep the video element in sync with the remote playback state. It would be good to precisely identify what does not work today, what minimal updates to media elements could solve the issue, and what these updates would imply from an implementation perspective. I'm raising this issue to collect practical use cases and requirements for the feature, and gauge interest from media companies to see a solution emerge. There have probably been other discussions around the topic. Media elements should support a rational time value for seek() whatwg/html#609 A proposal from 2016 to add a rational time value for seek() to solve rounding issues (still open as of June 2018):.A question from 2013 on whether there was interest to expose 'versions of currentTime, fastSeek(), duration, and the TimeRanges accessors, in frames, for video data':.Not sure if these use cases remain relevant today: A list of use cases from 2012 for seeking to specific frames.An long thread from 2011 on Frame accuracy / SMPTE, which led to improvements in the precision of seeks in browser implementations:.

Plus that framerate may actually vary over time.Īlso, internal rounding of time values may mean that one seeks to the end of the previous frame instead of the beginning of a specific video frame.ĭigging around, I've found a number of discussions and issues around the topic, most notably: Conversion from/to times to/from frame numbers is doable but supposes one knows the framerate of the video, which is not exposed to Web applications (a generic NLE would thus not know about it). The currentTime property takes a time, not a frame number or an SMPTE timecode. I've heard a couple of companies point out that one of the problems that makes it hard (at least harder than it could be) to do post-production of videos in Web browsers is that there is no easy way to process media elements on a frame by frame basis, whereas that is the usual default in Non-Linear Editors (NLE).

Subtitle workshop 4 cannot render media