need go to WebRTC team.

cpaulin: can you reproduce this? If so, please assign this bug accordingly for fixing.

It seems we should get a test in place to prevent this from happening as well.

Question for the original reporter: 49.0.2623.75 is being rolled out to the stable channel [1]. Can you see if you can reproduce this bug with that newer version of Chrome?

Directly assigning bug to cpaulin@ per #2.

[1] http://googlechromereleases.blogspot.com/2016/03/stable-channel-update.html

Yes. This issue reproduces just the same way in Chrome 49.

krassx@ could you try with the latest Canary as well plz?
(51.0.2670.0 according to https://omahaproxy.appspot.com/)

Ok. Will try it and respond.

I have tried chrome canary 51.0.2670.0 on MAC OS and went to the media recorder manual test page at : https://cdn.rawgit.com/cricdecyan/mediarecorder/master/manualtest/index.html
I set the time slice to 1 second and I proceeded with the recording for 33 seconds. I got a recorded video of 33 seconds length that I could replay. See attachment.

Deleted: test (2).webm 4.4 MB

test (2).webm 4.4 MB Download

I tried this time on linux ToT chrome version 51.0.2671.0
As always, I used the manual test page at  https://cdn.rawgit.com/cricdecyan/mediarecorder/master/manualtest/index.html
I set the time slice to 1 second and I proceeded with the recording for about 31 seconds.
I got 31 dataavailable events and the resulting video is 31 seconds in length. See attachment.

Deleted: linux_tot_recording.webm 3.8 MB

linux_tot_recording.webm 3.8 MB Download

kjellander@- I cannot reproduce the problem see #7 and #8 above

Since you use tab capture it could be the case that you don't get a first frame until the tab content is updated - and the recorder is not started until we get the first frame. We can't repro this on our own, can you provide us with a test page? 

To ensure capture is started I subscribed to 'onstart' event of MediaRecorder and start all other actions once it fires.

Test you provided link to uses MediaRecroder with getUserMedia which deals with webcams, but my case is tabCapture API. I do all my test on Chrome 49 (as being stable to the moment).

Since tabCapture API is not available from content/page scripts all the media related code is packed into extension, so I am not sure there is a way for me to create some test page for your (like plnkr/codepen/etc). Just let me know which is the best way to do that.

It's me again with an update. I fixed this issue by switching back to VP8 codec (initially I used VP9). Now I get videos of correct length. Switching back to VP9, again, gives me variable lengths.

Adjusting summary and adding mflodman@ per #12. 

krassx@ - thanks for the follow up! Do you have a sample test page we can use to reproduce the issue? Alternatively, niklase@, is what was provided in #11 and #12 sufficient enough for you to clear the Needs-Feedback label? Or do you still need a test page?

cpaulin, can you check if it repros with VP9?

As I noted before I use tabCapture API which is not pavailable from page scripts. Do you want me to create sample extension that reproduces this issue? 

krassx@ did you try with the latest Canary?

rationale: http://crrev.com/1732083002, addressing
 http://crbug.com/589162 , used a better allocation
microalgorithm in order or VP9 encoding to not
fall behind.

krassx@ A sample extension would be great so we can reproduce this here

Update: On the lastest MAC OS Canary 51.0.2679.0, I am experiencing issues with VP9 recording, the video is choppy. I don't have any issues when encoding VP8.
What I observe is that even the video stream from gUM gets a significant smoothness hit when the recorder starts with VP9 encoding, as a consequence the video tag connected to the stream shows quite a bit of choppiness and this is reflected in the recorded video.
Such behaviors are not experienced when using VP8 encoding in media recorder. See attached videos.
I had freshly rebooted my laptop (MacBook Pro 15 inch), I only had VLC and Chrome Canary running.

Waiting for krassx@ extension example to reproduce original issue.

Deleted: testVP9.webm 820 KB

testVP9.webm 820 KB Download

VP8 video example added

Deleted: testVP8.webm 3.6 MB

testVP8.webm 3.6 MB Download

To clarify the issue: the video tag is not a playing back the recorded video, instead it is associated with the MediaStream from acquired from gUM. So it is interesting that the video tag is also affected by this issue.

I tried ToT linux build 51.0.2681.0 on my workstation and I get the same choppy video tag + choppy recorded video. I have 40 logical CPUs.

Looking at the chrome log, there is a cpuset failure followed with a great many  "Failed to reserve I420 output buffer" errors:

[1:18:0316/113915:WARNING:video_track_recorder.cc(306)] VP8E_SET_CPUUSED failed
[19057:19200:0316/113915:ERROR:video_capture_device_client.cc(140)] Failed to reserve I420 output buffer.

The cpuset warning originates from [1] with a value of kCpuUsed equal to 6 in my case.

[1] https://code.google.com/p/chromium/codesearch#chromium/src/content/renderer/media/video_track_recorder.cc&l=306

 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4e1da39cc90c4a335bb1fa777c7ab25f50d8f22f

commit 4e1da39cc90c4a335bb1fa777c7ab25f50d8f22f
Author: mcasas <mcasas@chromium.org>
Date: Wed Mar 16 22:52:51 2016

MediaRecorder: Tune complexity settings for VP9 encoding (second go)

This code was landed but -silly me- I was setting the complexity
_before_ creating the encoder :P

Also, the values the VP8E_SET_CPUUSED parameter are:
 - up to 8 for VP9 (and not up to 16, that's for VP8)
 - Real Time values are 5 - 8 [1]

BUG= 591342 ,  589162 

[1] https://code.google.com/p/chromium/codesearch#chromium/src/third_party/webrtc/modules/video_coding/codecs/vp9/vp9_impl.cc&sq=package:chromium&type=cs&l=35&rcl=1458143321

Review URL: https://codereview.chromium.org/1809853002

Cr-Commit-Position: refs/heads/master@{#381572}

[modify] https://crrev.com/4e1da39cc90c4a335bb1fa777c7ab25f50d8f22f/content/renderer/media/video_track_recorder.cc

Im hopeful that tomorrow's Canary should fix this issue. krassx@, cpaulin@ can you confirm?

I successfully tried it on Mac OS chrome version 51.0.2681.0 with VP9 codec.

Requesting merge to 50. This is not a crash but the behaviour for VP9 is pretty bad in it's current state (more or less unusable). The recent CL moves the initialization to the right place and is pretty small and safe. I verified fix on canary today.

Your change meets the bar and is auto-approved for M50 (branch: 2661)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b6043e42c8ef63014df33c7185baf4cdec051d2b

commit b6043e42c8ef63014df33c7185baf4cdec051d2b
Author: mcasas <mcasas@chromium.org>
Date: Thu Mar 17 22:13:40 2016

MediaRecorder: Tune complexity settings for VP9 encoding (second go)

This code was landed but -silly me- I was setting the complexity
_before_ creating the encoder :P

Also, the values the VP8E_SET_CPUUSED parameter are:
 - up to 8 for VP9 (and not up to 16, that's for VP8)
 - Real Time values are 5 - 8 [1]

BUG= 591342 ,  589162 

[1] https://code.google.com/p/chromium/codesearch#chromium/src/third_party/webrtc/modules/video_coding/codecs/vp9/vp9_impl.cc&sq=package:chromium&type=cs&l=35&rcl=1458143321

Review URL: https://codereview.chromium.org/1809853002

Cr-Commit-Position: refs/heads/master@{#381572}
(cherry picked from commit 4e1da39cc90c4a335bb1fa777c7ab25f50d8f22f)

TBR=niklase@chromium.org
NOTRY=true
NOPRESUBMIT=true

Review URL: https://codereview.chromium.org/1814973002

Cr-Commit-Position: refs/branch-heads/2661@{#275}
Cr-Branched-From: ef6f6ae5e4c96622286b563658d5cd62a6cf1197-refs/heads/master@{#378081}

[modify] https://crrev.com/b6043e42c8ef63014df33c7185baf4cdec051d2b/content/renderer/media/video_track_recorder.cc

FYI, copy of https://bugs.chromium.org/p/chromium/issues/detail?id=589162#c4

Got another CL prepared for landing on branch (note the
revert on #3) 
https://codereview.chromium.org/1814853006/
Will wait for a while to let the bots flip green.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9c8975a65c723c74578336102859840ab3fc09b3

commit 9c8975a65c723c74578336102859840ab3fc09b3
Author: mcasas <mcasas@chromium.org>
Date: Fri Mar 18 16:51:25 2016

MediaRecorder: Tune complexity settings for VP9 encoding

The first landing on this branch got reverted due to a silly
mistake: it needed a previous CL (the first go). Now both are
considered below.

--- description for the second CL -----------------------------
This code was landed but -silly me- I was setting the complexity
_before_ creating the encoder :P

Also, the values the VP8E_SET_CPUUSED parameter are:
 - up to 8 for VP9 (and not up to 16, that's for VP8)
 - Real Time values are 5 - 8 [1]

BUG= 591342 ,  589162 

[1] https://code.google.com/p/chromium/codesearch#chromium/src/third_party/webrtc/modules/video_coding/codecs/vp9/vp9_impl.cc&sq=package:chromium&type=cs&l=35&rcl=1458143321

--- description for the first CL ------------------------------

Review URL: https://codereview.chromium.org/1809853002

Cr-Commit-Position: refs/heads/master@{#381572}

VideoTrackRecorder: limit VP9 cpu usage and quality

Also this CL simplifies the way VideoTrackRecorderTests
deals with the expectations, in the same way as
MediaRecorderHandlerTest was simplified before in
https://codereview.chromium.org/1579693006

BUG= 589162 

Review URL: https://codereview.chromium.org/1732083002

Cr-Commit-Position: refs/heads/master@{#378085}

TBR=niklase@chromium.org
NOTRY=true
NOPRESUBMIT=true

Review URL: https://codereview.chromium.org/1814853006

Cr-Commit-Position: refs/branch-heads/2661@{#282}
Cr-Branched-From: ef6f6ae5e4c96622286b563658d5cd62a6cf1197-refs/heads/master@{#378081}

[modify] https://crrev.com/9c8975a65c723c74578336102859840ab3fc09b3/content/renderer/media/video_track_recorder.cc
[modify] https://crrev.com/9c8975a65c723c74578336102859840ab3fc09b3/content/renderer/media/video_track_recorder_unittest.cc

Renamed component Blink>MediaStreamRecording to Blink>MediaStream>Recording. Moving issues to the new component.