MediaStreamRecorder needs a way to specify a targeted framerate |
||||||
Issue descriptionChrome Version : 73.0.3644.0 OS Version: OS X 10.14.1 URLs (if applicable) : https://gist.github.com/surma/7b27c177b3f599b4e6d7c92991615862 What steps will reproduce the problem? 1. Open the HTML file from the gist above 2. Wait ~5 seconds 3. Play the video What is the expected result? The red square should move smoothly What happens instead of that? The red square jumps and looks janky Please provide any additional information below. Attach a screenshot if possible. MediaStreamRecorder has no way to specify a targeted framerate, but seems to just record the video in real time. If the individual frames for my video take longer to generate than I have time per frame, the video is not going to look like the author intended. The only viable workaround is to generate each frame ahead of time, buffer them, and then try to play back the buffer at the intended frame rate. The more we target lower end devices, this strategy becomes less and less viable.
,
Dec 21
Able to reproduce the issue on reported chrome version 73.0.3644.0 also on latest chrome 73.0.3647.0 using Mac 10.14.0, Ubuntu 17.10 and Windows 10. Same behavior is seen on M60(60.0.3112.113) hence considering it as non-regression and marking it as Untriaged. Thanks..!
,
Dec 21
,
Jan 3
,
Jan 3
https://codepen.io/miguelao/full/BvYZNV MediaRecorder -- just records, this problem could be circumvented in two ways: - the MediaStreamTrack feeding to it may support constraining its frameRate [1], something like: var theTrack = theStream.getVideoTracks()[0]; theTrack.applyConstraints({ advanced: [{frameRate: 20}]}); var theRecorder = new MediaRecorder(theStream); - MediaRecorder might be dropping frames because the default target bitrate is too low for the current input bandwidth; it can be reconfigured var theRecorder = new MediaRecorder(stream, {bitsPerSecond : 10000000}); In the demo configuration: <canvas> ---<MediaStreamTrack>----> MediaRecorder either the WebCanvasCaptureHandler [2] (used to retrieve the data from the <canvas>) or the MediaStream will have to get the data out of the GPU where in all likelihood <canvas> is working; this process is slow and janky by definition (see e.g. Issue 897727). [1] https://w3c.github.io/mediacapture-main/#dom-mediatracksupportedconstraints-framerate [2] https://cs.chromium.org/chromium/src/third_party/blink/public/platform/web_canvas_capture_handler.h?dr=C&g=0&l=18
,
Jan 3
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by phanindra.mandapaka@chromium.org
, Dec 20