i'm the the colleague witness browser crash due to eaten memory with 1280x720x30fps on lenovo y510p 8G laptop (A strong i7 gaming machine)

thanks.

Able to reproduce the issue on latest Chrome stable i.e., 59.0.3071.109. Working on bisect to see if this is a regression started in M59 or exist earlier as well. 

Definitely this is a regression in M59, working on the bisect.

Please find the bisect result below :

You are probably looking for a change made after 456330 (known good), but no lat
er than 456331 (first known bad).
CHANGELOG URL:
The script might not always return single CL as suspect as some perf builds migh
t get missing due to failure.
  https://chromium.googlesource.com/chromium/src/+log/ac041cfab01f509ef22e0f6fedbad3b421bbe20a..9d369903d6cdd84aaaf70e2a73ada508e2b34eaa

So far I wasn't able to reproduce the issue on Windows 10, Mac and Linux


Note : I was only able to reproduce this issue on my Corp Windows 7 machine and was across all Channels i.e., Chrome beta(60.0.3112.40), Dev(61.0.3135.4) and Canary(61.0.3138.0)

Thanks for the bisect.
 
var ctx = canvas.getContext('2d', {alpha: false});
Changing this line in your demo as above should fix the problem for you. With the suspected CL, we started encoding alpha channel for VPX as well. Although you are not drawing any alpha channel, when you don't add {alpha: false}, capturer don't know what alpha contains. It adds an extra stress as we start encoding 120+120 fps. I am removing Release-Block-Stable based on that.

There isn't any extra allocated memory for alpha channel encoding[0]. I will look if something is wrong in vpx_encoder calls but it looks like we have more frames than we can process here as you explained. We cannot throw away frames in canvas capture as per spec, but maybe we can do in media recorder. 

[0] https://codereview.chromium.org/2691373005/diff/300001/content/renderer/media_recorder/video_track_recorder.cc

I have 3 step solution that will address this issue:
- When alpha is there, half the duration parameter that is set for encoding a frame. Since we are actually encoding N+N fps, this helps reducing the time spent in encoder. Tests show that encoder doesn't queue up way too many frames this way.
- Add a counter in media_recorder such that we limit the number of queued frames to a certain number. This will cover all edge cases.
- {alpha: false} usage doesn't seem to be popular. Canvas context defaults to RGBA, so we always assume to have alpha. We can go through the full alpha channel values in canvas capture and drop the alpha plane if all zeros.

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

commit 894d66f402ebb97afe82052fa834612feffa8e28
Author: Emircan Uysaler <emircan@chromium.org>
Date: Thu Jun 29 18:05:36 2017

Limit number of frames kept alive by VideoTrackRecorder

This CL addresses issues where we see increasing memory usage when
VideoTrackRecorder cannot keep up with the number of incoming frames.
- Limit the number of frames sent for encode to 30.
- Change duration when there is alpha encode to account for the double
load.

Bug:  735984 
Test: Added unittest and tested HTML demo given in the bug.
Change-Id: I470422ca2538eb46cd24d36560f3d35b4ae28d06
Reviewed-on: https://chromium-review.googlesource.com/546996
Commit-Queue: Emircan Uysaler <emircan@chromium.org>
Reviewed-by: Miguel Casas <mcasas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#483421}
[modify] https://crrev.com/894d66f402ebb97afe82052fa834612feffa8e28/content/renderer/media_recorder/video_track_recorder.cc
[modify] https://crrev.com/894d66f402ebb97afe82052fa834612feffa8e28/content/renderer/media_recorder/video_track_recorder.h
[modify] https://crrev.com/894d66f402ebb97afe82052fa834612feffa8e28/content/renderer/media_recorder/video_track_recorder_unittest.cc
[modify] https://crrev.com/894d66f402ebb97afe82052fa834612feffa8e28/content/renderer/media_recorder/vpx_encoder.cc

What's the status here? More work planned in M62?

There is more work planned but it should land before 62 cut.

Ok, bumping it to M62 then.

What's the current status of this?

Ping.

Current fix in #10 limits the number of frames sent to encode, and fixes the high memory usage. I kept the bug open because I want to add another layer where we keep the frames in a LIFO queue, see https://cs.chromium.org/chromium/src/content/renderer/media_recorder/video_track_recorder.cc?rcl=5814e9f72db71eccce938f8ee67756ce960a2c11&l=82. I haven't had time to work on this, updating labels accordingly.

I had another look at this. Changing the queue from FIFO to LIFO that I suggested as next step can be problematic with the current VEA encoder design. Since VEA posts the VideoFrame onto other threads and processes, they might be queuing up where VEA implementation is and canceling tasks from VideoTrackRecorder would be no use. It is a simpler and more controlled solution as it is. #10 limits the number of frames and solves the memory issue.