Frame accurate seeking of HTML5 MediaElement
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). The `currentTime` property takes a time, not a frame number or an SMPTE timecode. 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). Plus that framerate may actually vary over time. Also, 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. Digging around, I've found a number of discussions and issues around the topic, most notably: 1. An long thread from 2011 on Frame accuracy / SMPTE, which led to improvements in the precision of seeks in browser implementations: https://lists.w3.org/Archives/Public/public-whatwg-archive/2011Jan/0120.html 2. A list of use cases from 2012 for seeking to specific frames. Not sure if these use cases remain relevant today: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22678 3. 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": https://www.w3.org/Bugs/Public/show_bug.cgi?id=8278#c3 4. A
Posted by tidoust on Jun 11, 2018, 1:58 PM
Tags
Related issues
- struct's lifetime requirements can be bypassed via covariant field assignment
- Proposal to Reorganize the Moderation Team and Review Moderation Policies
- Progressive FPS degradation appears to be related to dota2.com — blocking the domain prevents the performance loss
- proposal: container/...: generic collection types
- Better Custom Endpoint BYOK
- A concrete policy for backward compatibility until Godot 5.0
Raise real-world problems, find people facing the same issue, and discuss solutions.4,000 issues0 comments
github (Other)
struct's lifetime requirements can be bypassed via covariant field assignment
Proposal to Reorganize the Moderation Team and Review Moderation Policies
Progressive FPS degradation appears to be related to dota2.com — blocking the domain prevents the performance loss
proposal: container/...: generic collection types
Better Custom Endpoint BYOK
A concrete policy for backward compatibility until Godot 5.0
New MTP models not supported
Tracking: 429 / Capacity Issues
Frame accurate seeking of HTML5 MediaElement
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). The `currentTime` property takes a time, not a frame number or an SMPTE timecode. 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). Plus that framerate may actually vary over time. Also, 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. Digging around, I've found a number of discussions and issues around the topic, most notably: 1. An long thread from 2011 on Frame accuracy / SMPTE, which led to improvements in the precision of seeks in browser implementations: https://lists.w3.org/Archives/Public/public-whatwg-archive/2011Jan/0120.html 2. A list of use cases from 2012 for seeking to specific frames. Not sure if these use cases remain relevant today: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22678 3. 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": https://www.w3.org/Bugs/Public/show_bug.cgi?id=8278#c3 4. A
Comments (0)
No comments yet. Start the discussion.