I will bisect this using hana tomorrow.
https://chromeperf.appspot.com/report?sid=9a0744dd462b26c4cfe4842153b29d475697b354376cd9ee8b356d10a9159d40&start_rev=33900001055800000&end_rev=34930001088500000

After bisect, the bad CL is:
https://chromium-review.googlesource.com/c/chromium/src/+/1127142

Re #2: it's not the bad CL. I will bisect again.

There are regression on

sw_video_dropped_frames_vp8_4k on caroline:

https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICQjb6ZxAgM

sw_video_dropped_frames_h264_1080p_60fps on guado:

https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICQzdyBsQoM

The regression range for the above is 10894.0.0 - 10895.0.0. Pawel suggested we could see if reverting crrev.com/8b8a99818cc435403653b6ac259eca34b4b06f6a helps.

I choose 120 as threshold and verify 3 times.
After I bisect today, the bad CL is:
https://chromium-review.googlesource.com/c/chromium/src/+/1110670

Hi Mounir, 

can you take a look why the CL in #8 increases the frame drop at SW decoder?

We are aware of some perf regressions with VideoSurfaceLayer and are tracking down the source. How are you computing the dropped frames in this test? Are you only using the JS exposed value?

Also, the regression range seems to include the CL you pointed out and https://chromium.googlesource.com/chromium/src.git/+/0ed31e65e617e652db341160f90fb845fdd0fe5e If you are able to run the tests locally, would it be possible to tell us whether this CL changes the results?

Quick answer: 

I'm running autotest video_PlaybackPerf.h264.1080.60fps, and see the result: sw_video_dropped_frames_h264_1080p_60fps. 

The result with the CL in #8 is 209 frame dropped, and the previous CL is 6, 59, 11 frame dropped.

Step of run autotest:
$ test_that -b hana ${DUT_IP} video_PlaybackPerf.h264.1080.60fps
$ ssh "${DUT_IP}" "cat /usr/local/autotest/results/default/video_PlaybackPerf/results/results-chart.json" | jq '.sw_video_dropped_frames_h264_1080p_60fps.summary.value'

I'm looking how the autotest count the dropped frames.

Re #10, Yes, I think it just use JS exposed value.

https://chromium.googlesource.com/chromiumos/third_party/autotest/+/master/client/site_tests/video_PlaybackPerf/video_PlaybackPerf.py#154

I'm testing my bisector with following command
./diagnose_cros_autotest.py \
  --session=$S \
  --chromeos_root work/$S/cros.bisect.with-mirror \
  --chromeos_repo_mirror_dir /btrfs2/bisect-kit-repos/chromeos-mirror \
  --android_root work/$S/nyc-mr1-arc.with-mirror \
  --android_repo_mirror_dir /btrfs2/bisect-kit-repos/android-mirror \
  --chrome_root work/$S/cr.bisect.with-cache \
  --gclient_cache_dir /btrfs2/bisect-kit-repos/chromium \
  --old R69-10870.0.0 --new R69-10872.0.0 \
  --metric sw_video_dropped_frames_h264_1080p_60fps \
  --board hana --old_value 20 --new_value 160 --noisy=old=1/5,new=9/10 \
  video_PlaybackPerf.h264.1080.60fps \
  :lab:

And confirmed akahunag's finding in comment 8
11:25:18 INFO [821] 69.0.3482.0~69.0.3483.0/113 0.0013%; {u'skip': 4, u'old': 5} n=5,avg=19.200,median=10.000,min=1.000,max=67.000
11:25:18 INFO [822] 69.0.3482.0~69.0.3483.0/114 99.9961%; {u'new': 6, u'skip': 6} n=6,avg=189.333,median=195.000,min=165.000,max=217.000 <------------------
11:25:21 INFO 69.0.3482.0~69.0.3483.0/114 commit 9c99a16069 src 'Enable VideoSurfaceLayer and PictureInPicture flags by default.'

Any chance you could have a look at this again using 70.0.3538.0 (Canary) or ToT? lethalantidote@ has landed a CL that may help with this.

According to the link in comment 1, it is fixed.