W3C home > Mailing lists > Public > public-web-and-tv@w3.org > June 2018

Re: [media-and-entertainment] Frame accurate seeking of HTML5 MediaElement

From: Aaron Boushley via GitHub <sysbot+gh@w3.org>
Date: Wed, 20 Jun 2018 17:18:56 +0000
To: public-web-and-tv@w3.org
Message-ID: <issue_comment.created-398828984-1529515135-sysbot+gh@w3.org>
Throwing my hat in the ring here with a couple alternative use cases. As background my company manages a large amount of police body camera video. We support redaction of video via the browser, as well as playback of evidence via the browser.

For the redaction and evidence playback use cases our customers want the ability to step through a video frame-by-frame. If you assume a constant framerate and are able to determine that framerate out of band then you can get something that approximates frame-by-frame seek. However there are many scenarios (be it rounding of the `currentTime` value, or encoder delay that renders a frame a few ms late) that can result in a frame being skipped (which is a big worry for our customers). There are hacks around this (rendering frames on the server and shipping down frame by frame view) but all the info we need is already in the browser, it would be great if we had the ability to progress through a video frame by frame.

For redaction we have a use case that is similar to the subtitles sync issue. When users are in the editing phase of redaction we do a preview of what will be redacted where we need JS controlled objects to be synced with the video as tightly as we can. In this use case it's slightly easier than subtitles because when playing back at normal speed (or 2x or 4x) redaction users are usually ok with some slight de-sync. If they see something concerning they usually pause the video and then investigate it frame-by-frame.

Some of the suggested solutions, like `currentFrameTime`, could be extended to enable the frame-by-frame use case.

GitHub Notification of comment by boushley
Please view or discuss this issue at https://github.com/w3c/media-and-entertainment/issues/4#issuecomment-398828984 using your GitHub account
Received on Wednesday, 20 June 2018 17:18:58 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 20 June 2018 17:18:59 UTC