This is not peppy only.
https://crosbolt.teams.x20web.corp.google.com/prod/crosbolt/index.html?tab=time_series&sku_filter=&show_all=false&test=video_PlaybackPerf.vp9.4k&metric=hw_video_dropped_frames_vp9_4k&num_versions=30
https://screenshot.googleplex.com/GM6TWac7zia.png

Because there is no peppy available, I run bisect using samus
https://crosperf.googleplex.com/b/09d85c93-1920-443f-808e-3bda6e4557c5
And found it has the same root cause as the regression of video_PlaybackPerf.vp9.hfr/hw_video_dropped_frames_vp9_1080p_hfr

Miguel. PTAL.

Issue 921346 has been merged into this issue.

kcwu@, akahuan@, hiroh@, do you see regressions other than for VP9 decode?

It seems like the issues are limited to VP9 and Broadwell or earlier,
I can disable those 

Since the same version, 11534.0.0
h264 test has a different looking of regression. I don't know it's the same root cause or not.

https://crosbolt.teams.x20web.corp.google.com/prod/crosbolt/time_series/video_PlaybackPerf.h264/hw_video_dropped_frames_percent_h264_1080p.html?sku_filter=&from_version=73.11490.0.0&to_version=73.11580.0.0
https://screenshot.googleplex.com/2BOiE7S7kUE.png
That regression is low probability. If it happened, it will drop about 55% frames.

oh, vp8 and vp9 have the same issue as described in comment 6.

Working on a CL to restrict |use_reduced_number_of_allocations_|,
so VP8/9 + oldish platforms (earlier than SkyLake) would not use it.

 crrev.com/c/1409353

Oops, based on #6 and #7, I'll disable  |use_reduced_number_of_allocations_|, for all codecs for old platforms.

Hmm, this is not only for old platforms.
The link in c#2 [1] shows the regression happens on akali. akali is KBL device.

[1] https://crosbolt.teams.x20web.corp.google.com/prod/crosbolt/index.html?tab=time_series&sku_filter=&show_all=false&test=video_PlaybackPerf.vp9.4k&metric=hw_video_dropped_frames_vp9_4k&num_versions=30

Oops, my comment #10 is totally wrong.

All the devices where the regression happens in the link are old platforms.

Hmn, some vp9 videos used in performance tests in autotest do not have audio. crbug.com/921969
We should investigate using tast tests. I am sure all the videos have audio there. 
https://crosbolt.teams.x20web.corp.google.com/prod/crosbolt/time_series/tast.video.PlaybackPerfVP92160P30FPS/tast_hw_video_dropped_frames_percent_vp9_2160p_30fps.html?num_versions=30&sku_filter=

miguel, could you investigate this issue using tast tests? I guess this is the shortage of buffers for media pipeline. If you don't find out the way of resolving the regression on old intel platform, I will review crrev.com/c/1409353 tomorrow.
You can run tast test by the following command in chromeos chroot.
~/trunk/src/scripts $ tast run ${DUT_IP} video.PlaybackPerfVP92160P30FPS