We actually see a decrease in Media.DroppedFrameCount on Dev Mac/Windows/CrOS, and for CrOS it's statistically significant when aggregating 7 days. Not much of that is VP9 60fps though, and the UMA doesn't distinguish. We have UKM data that could cover this, I'll investigate whether it's possible to query it by experiment group.

Note: due to the low usage of 4k60 content on dev channel, I was only able to query for 1080p60. Even with that, the error bars are very large.

I do not see a significant increase in dropped frames for VP9 1080p60 on CrOS dev using MojoVideoDecoder. The same is true for H.264 1080p60.

Mac does not have hardware VP9, but for H.264 the result is the same; no significant increase in dropped frames for H.264 1080p60 on Mac OS X dev using MojoVideoDecoder.

On Mac I was able to merge together all > 1080p60 playbacks to get a result, no significant increase in dropped frames there either.

Of course 4k is not very comparable to 1080p on CrOS. It looks like this will need to be tested manually.

Based on all of the charts, only machines that already had dropped frames had an increase in dropped frames. 4k is hit on panther, and 4k60 is hit harder, but CPU usage doesn't increase.

The best working theory I have is that the picture buffer return path has higher latency than GpuVideoDecoder, and also that there are very few output buffers on these devices, so it's leading to contention. This isn't a problem we usually have on other platforms.

I'll try to get test hardware and experiment with removing the sync point verification. We can't launch like that, but it could verify the cause.

There are not many synchronization tricks we can pull without access to the GpuChannel. Maybe it would be necessary to route returned frames via the GpuChannel while leaving everything else in the Mojo service.

Is it plausible to increase the number of output buffers on the affected devices in this case (4k), probably by one or two?

Thanks Dan!
Assign this issue to you because you have more expertise with MojoVD.

I'd still like an answer to the question in #3, is it plausible to slightly increase the number of 4K output buffers on these devices?

Yes, it could be an option, and adding more buffers could help make things smoother, but, as 4k buffers are very big, we'd need to test and measure this carefully, to weight the cost of additional memory usage against potential performance gains.

Gpu triage: marking assigned as this seems to have an owner.

I am unable to reproduce this result on peppy.

For the VP9 4k30 test file, looping in a tab with controls visible, I get 34% dropped frames with GpuVideoDecoder and 30% dropped frames with MojoVideoDecoder. This is consistent with my UKM data showing that MojoVideoDecoder has a lower dropped frame rate.

It's possible that the result depends on optimizations that an official build has that my build does not; I will experiment with a few more combinations.

Are the labs running in a setup where the output is enabled and is (only) the built-in LCD?

In the interest of reproducibility, I modified my test page to ignore all frames before the first loop. The numbers above were also from a release_with_dchecks build, so this time I'm including numbers from a no-dchecks build. This time I moved the mouse out of the tab so that the controls would not be visible.

For GpuVideoDecoder I get 29% dropped frames and for MojoVideoDecoder I get 26%. These numbers seem to be stable.

In any case I am suspicious of the video_PlaybackPerf.vp9.4k dropped frame rate result, at least on peppy.

Aka, could you double check on Braswell device?

Are the unexpected differences visible only on peppy now? Is this only on 4k, or also on lower resolutions?

OK, I will verify the braswell device.

Measured at Cyan R73-11381.0.0

                   GPU VD    Mojo VD
VP9 60FPS 4K        60.0%      60.0%
VP9 60FPS 1080p      2.8%       2.5%      
VP9 60FPS 720p       0.4%       0.4%
VP9 30FPS 4K        60.0%      60.0%
VP9 30FPS 1440p      4.0%       3.0% 
VP9 30FPS 1080p      0.1%       0.1%
H264 60FPS 4K        2.5%       4.4%
H264 60FPS 1080p       0%       0.1%
H264 30FPS 4K          0%         0%

I feel there is no much difference between GPU VD and Mojo VD.

I don't see that Cyan had a clear regression in the previous range. Can you test panther, guado, or peppy?

We could also just flip the MojoVideoDecoder flag again for a week or so, since we're not near a branch cut.

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

commit 81fab476d3b549bbdb52bcdef8caa36c9b2dbf8f
Author: Dan Sanders <sandersd@chromium.org>
Date: Wed Jan 16 22:51:19 2019

[media] Enable MojoVideoDecoder by default on CrOS.

When this flag was last flipped, there was a performance regression in
decoding on low-end devices. Reproduction has not been successful, so
flipping again. Results should be evaluated before the M73 branch cut.

Bug: 906994
Change-Id: I6f81a64cfda30be91523a6e8557c9227d04b187c
Reviewed-on: https://chromium-review.googlesource.com/c/1405284
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Commit-Queue: Dan Sanders <sandersd@chromium.org>
Cr-Commit-Position: refs/heads/master@{#623420}
[modify] https://crrev.com/81fab476d3b549bbdb52bcdef8caa36c9b2dbf8f/media/base/media_switches.cc