- From: David Holroyd via GitHub <sysbot+gh@w3.org>
- Date: Thu, 21 Jun 2018 14:18:05 +0000
- To: public-web-and-tv@w3.org
> I note that this thread started with Non-Linear Editors. If someone can elaborate on scenarios there and why frame numbers are needed there, that would be great! Supposing they are, does the application need to know the exact frame being rendered during media playback or is is good enough if that number is only exact when the media is paused/seeked? We also perform media manipulation server-side on the basis of users choosing points in the media timeline in a browser-based GUI. Knowing exactly what the user is seeing when the media is paused is critical. Challenges that we've found with current in-browser capabilities include, - Allowing the user to reliably review the points in time previously selected - _Expected behaviour_ - browser will seek to a previously selected time-point and the user will see the same content as when they made their selection - _Actual behaviour_ - in some cases, in some browsers, the frame the users sees may be off-by-one - Another way of describing the above is just to observe that, with playback paused, _sometimes_ executing `video.currentTime = video.currentTime` in the js console will change the displayed video frame! - Matching results that server-side processing with what the user requested in the browser - _Expected behaviour_ - the point on the media timeline 'chosen' by the user is reflected by back-end processing - _Actual behaviour_ - it seems challenging to relate a `currentTime` value from the browser to a point on the media timeline within server-side components - To make the above more concrete, if you wanted to run _ffmpeg_ on the server-side and have it make a jpg of video frame that the user is currently looking at, how would you transform the value of `currentTime` (or any other proposed mechanism) into a `select` video filter. (Substitute _ffmpeg_ with your preferred media framework as desired :) We currently do frame-stepping by giving the js knowledge (out of band) of the frame-rate and seeking in frame-sized steps. Users also want to be able to step backwards and forwards by many frames at a time (e.g. hold 'shift' to skip faster). That's currently implemented by just seeking in larger steps. -- GitHub Notification of comment by dholroyd Please view or discuss this issue at https://github.com/w3c/media-and-entertainment/issues/4#issuecomment-399119704 using your GitHub account
Received on Thursday, 21 June 2018 14:18:08 UTC