Frequent play/pause events should not affect MediaCapabilities decodingInfo results |
||||
Issue descriptionChrome 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 } }
,
Dec 13 2017
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?
,
Dec 20 2017
Back to fbeaufort@ for more info :)
,
Jan 4 2018
fbeaufort@, ping :)
,
Jan 4 2018
I tried to reproduce without much success sadly ;( Dropped Frames 31/758
,
Jan 4 2018
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
,
Jan 4 2018
No worries. We have some theory about what happened. Let us know if it comes back! |
||||
►
Sign in to add a comment |
||||
Comment 1 by mlamouri@chromium.org
, Dec 6 2017