New issue
Advanced search Search tips

Issue 791987 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: Jan 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

Frequent play/pause events should not affect MediaCapabilities decodingInfo results

Project Member Reported by fbeaufort@chromium.org, Dec 5 2017

Issue description

Chrome Version: 64.0.3280.5
OS: Chromebook Pixelbook

What steps will reproduce the problem?
(1) Visit https://www.youtube.com/watch?v=1La4QzGeaaQ
(2) Select 4K
(3) Click frenetically on play/pause YouTube player button until video currentTime is more than 7 seconds
(4) Check out Media Capabilities decoding info

What is the expected result?
The 4K VP9 video playback should be marked as supported, smooth and power efficient (as this is what happens usually)

What happens instead?

Here's what I get from https://beaufortfrancois.github.io/sandbox/media-capabilities/decoding-info-2.html:

VIDEO/WEBM; CODECS=VP9
----------------------

NOT SMOOTH               | 3840x2160 (4K) | 4000 kbps | 60 fps | file        
NOT POWER EFFICIENT      | 3840x2160 (4K) | 4000 kbps | 60 fps | file        
NOT SMOOTH               | 3840x2160 (4K) | 4000 kbps | 60 fps | media-source
NOT POWER EFFICIENT      | 3840x2160 (4K) | 4000 kbps | 60 fps | media-source
NOT SMOOTH               | 3840x2160 (4K) | 2500 kbps | 60 fps | file        
NOT POWER EFFICIENT      | 3840x2160 (4K) | 2500 kbps | 60 fps | file        
NOT SMOOTH               | 3840x2160 (4K) | 2500 kbps | 60 fps | media-source
NOT POWER EFFICIENT      | 3840x2160 (4K) | 2500 kbps | 60 fps | media-source
NOT SMOOTH               | 3840x2160 (4K) | 1500 kbps | 60 fps | file        
NOT POWER EFFICIENT      | 3840x2160 (4K) | 1500 kbps | 60 fps | file        
NOT SMOOTH               | 3840x2160 (4K) | 1500 kbps | 60 fps | media-source
NOT POWER EFFICIENT      | 3840x2160 (4K) | 1500 kbps | 60 fps | media-source
NOT SMOOTH               | 3840x2160 (4K) |  700 kbps | 60 fps | file        
NOT POWER EFFICIENT      | 3840x2160 (4K) |  700 kbps | 60 fps | file        
NOT SMOOTH               | 3840x2160 (4K) |  700 kbps | 60 fps | media-source
NOT POWER EFFICIENT      | 3840x2160 (4K) |  700 kbps | 60 fps | media-source



And here are the raw results with https://github.com/beaufortfrancois/video-decode-stats:

$ node main.js 
12|3840x2160|60  :  DecodeStatsProto {
  framesDecoded: Long { low: 467, high: 0, unsigned: true },
  framesDropped: Long { low: 76, high: 0, unsigned: true },
  framesDecodedPowerEfficient: Long { low: 0, high: 0, unsigned: true } }

 
Owner: chcunningham@chromium.org
Assigning to chcunningham@ for investigation.
After looking at the debug logs while following the repro steps, I don't think these steps are actually contributing any stats to your media capabilities DB. For each play/pause we restart the timer that waits 2 seconds before trying assessing the framerate and collecting stats. If you pause/play in rapid fire, you never allow 2 seconds to fully elapse (it resets each time) so no stats are gathered and the DB remains as it was before playback. 

My theory is that your pixel book drops a signficant number of frames while playing 4k 60 vp9 (or at least, it did at some point when it was given 2+ seconds to collect some data) and the API is just surfacing that. 

If you simply play the video at 4k, and right-click stats-for-nerds and let the watch the ratio of dropped/decoded frames, what sort of values do you see? 

Assuming you see a smooth ratio (<10% dropped), next question would be: If you clear your browsing history from all time (clears the DB) and try the steps in the initial report, do you get a consistent repro of not-smooth?
Labels: Needs-Feedback
Owner: fbeaufort@chromium.org
Status: Unconfirmed (was: Untriaged)
Back to fbeaufort@ for more info :)
fbeaufort@, ping :)
I tried to reproduce without much success sadly ;(
Dropped Frames 31/758

Project Member

Comment 6 by sheriffbot@chromium.org, Jan 4 2018

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding requester "mlamouri@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Status: WontFix (was: Unconfirmed)
No worries. We have some theory about what happened. Let us know if it comes back!

Sign in to add a comment