All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=682152

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgwIq0tgoM


Bot(s) for this bug's original alert(s):

chromium-webrtc-rel-mac

The perf graphs for mac bots show a small but clear drop in unique frames and corresponding increase in repeated frames. Your cl https://codereview.chromium.org/2625823003 is on the list and seems to be the least unlikely. Can you have a look and see if it could possibly affect video?

There were an earlier and larger regression affecting mostly the same bots, see https://bugs.chromium.org/p/chromium/issues/detail?id=681832, which isn't resolved yet. It's possible that interacts with your change in some way.

Can you tell me what the test is doing?

Sure. The test sets up a webrtc video call, using a video stream including a bar code with the frame number in each frame, and then it analyzes the frames on the receiver.

Drop in unique frames and increase in max repeated, that means more frames are lost and there is (short) video freeze at the receiver.

Then I would say my CL is not related. My CL registers a pre-finalizer to blink::ResourceLoader and in theory that regresses Oilpan's performance very slightly, but I believe it's negligible.

Thanks!

Hi, mcasas.

I apologize for being a bit slow looking at this, but it now appears that the changes in the graph correlate closely with your MediaRecorder changes,

landed as #443165, reverted as #443251, relanded as #443400.

Can you investigate if the changes to video performance are expected or reasonable?

The CLs your mention make it possible for Media Recorder to select
the most-likely hardware accelerated encoder supported by the platform
(out of VP8, VP9, H264, in that order of preference).  Mac in particular
supports H264 accelerated, so it's very likely that MR has switched
to using it, producing nonetheless a similar webm file that should 
be treated accordingly.  IIUC, there is a ffmpeg/libavcodec script
hardcoded somewhere that might be responsible for the change, kjellander@
where was it?


https://blink.lc/chromium/commit/?id=904b7a6f6dffa9cee5ac930c37dd591c330d14c6
https://blink.lc/chromium/commit/?id=c104b1c42724791fc3dd69ebbea6e915cab8bedc

I don't think we need to worry too much about repeated frames going up from 1 to 2-3 on average. 
Looking historically at the metric it has been in this range before (but also as high as 8 for a long period), so I don't think this regression is severe enough to call for further investigation since it's the only stat regressing.