Add DroppedFrameCount and DecodedFrameCount to UKM per watch time interval. |
|||||||
Issue descriptionToday we have Media.DroppedFrameCount UMA which is the "count of dropped frames between pipeline start and stop". This provides an aggregated view of dropped frame count over all playbacks on all platforms using any video decoder, where a lot of information are lost. For example, it cannot answer questions like: - dropped frame count comparison between software vs hardware decoders - dropped frame count comparison between h264 vs vp9 - dropped frame count comparison between clear vs encrypted playback - dropped frame count comparison between <video> and flash (may need extra UMA for the latter) Here are some brainstorming ideas: - We should report average dropped frame per minute, or per 100 decoded frames. - We can at least follow the current model of Media.WatchTime API that slice the metric by SRC/MSE/EME, and/or SW/HW.
,
Mar 29 2017
+strobe: See #1. Is dropped_frame/decoded_frame percentage a reasonable metric to collect? Or do you have better suggestions?
,
Apr 19 2017
ppergame: Any comments on #2?
,
May 3 2017
Hmm, well, we have pretty detailed logs that let us know certain trends, both aggregated and on an individual playback level. For instance, dropped frames are much more common during the start of playback, and (duh) they're more common at the start of playback. This is possible because we report the dropped frame accumulation on a regular basis throughout the playback - at every "interesting event" like a format change, or every thirty seconds. We don't collect dropped/decoded explicitly, but we do know the framerate of the media that's playing, so we can usually compute it.
,
Sep 30 2017
dalecurtis: I heard that you plan to add number of decoded/dropped frames to UKM for each playback session. Is that right? If so, I don't think we need to work on this UMA any more. If there's a bug tracking that I can close this one.
,
Oct 2 2017
Yes, but no bug tracking it yet.
,
Dec 8 2017
We have UKM decoded/dropped frames from MediaCapabilities right now, so going to hold off on adding these in for WatchTime just yet. We'll look at this again in Q1 after we've evaluated the value of those UKMs.
,
Dec 12 2017
,
Dec 14 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/74612b7459881f9194f4d404e4f6688efe0bd8f5 commit 74612b7459881f9194f4d404e4f6688efe0bd8f5 Author: Dale Curtis <dalecurtis@chromium.org> Date: Thu Dec 14 20:56:19 2017 Plumb UKM PlayerID for WatchTime and VideoDecodeStats recording. This uses the player ID assigned to every MediaMetricsProvider per WebMediaPlayerImpl instance to correlate metrics like watch time, video decoder stats, and more. A new Media.WebMediaPlayerState UKM event is added which tracks the player id and final pipeline status. Later on we can add other one-time lazily-generated metrics like time to first frame, or time to load, etc. The player id value is then added to both the existing UKM events for watch time and decoder stats. Also later on we can use this to move more of the metrics logged through MediaInternals today to the metrics provider. BUG= 706276 , 794263 TEST=updated unittests. TBR=bauerb Change-Id: I59ecad7f858b228f1fddb4eb8215b127e606ca93 Reviewed-on: https://chromium-review.googlesource.com/822168 Commit-Queue: Dale Curtis <dalecurtis@chromium.org> Reviewed-by: Daniel Cheng <dcheng@chromium.org> Reviewed-by: Steven Holte <holte@chromium.org> Reviewed-by: Chrome Cunningham <chcunningham@chromium.org> Cr-Commit-Position: refs/heads/master@{#524167} [modify] https://crrev.com/74612b7459881f9194f4d404e4f6688efe0bd8f5/chrome/browser/browsing_data/browsing_data_remover_browsertest.cc [modify] https://crrev.com/74612b7459881f9194f4d404e4f6688efe0bd8f5/media/blink/watch_time_reporter_unittest.cc [modify] https://crrev.com/74612b7459881f9194f4d404e4f6688efe0bd8f5/media/blink/webmediaplayer_impl.cc [modify] https://crrev.com/74612b7459881f9194f4d404e4f6688efe0bd8f5/media/blink/webmediaplayer_impl_unittest.cc [modify] https://crrev.com/74612b7459881f9194f4d404e4f6688efe0bd8f5/media/mojo/interfaces/media_metrics_provider.mojom [modify] https://crrev.com/74612b7459881f9194f4d404e4f6688efe0bd8f5/media/mojo/interfaces/watch_time_recorder.mojom [modify] https://crrev.com/74612b7459881f9194f4d404e4f6688efe0bd8f5/media/mojo/services/BUILD.gn [modify] https://crrev.com/74612b7459881f9194f4d404e4f6688efe0bd8f5/media/mojo/services/media_metrics_provider.cc [modify] https://crrev.com/74612b7459881f9194f4d404e4f6688efe0bd8f5/media/mojo/services/media_metrics_provider.h [add] https://crrev.com/74612b7459881f9194f4d404e4f6688efe0bd8f5/media/mojo/services/media_metrics_provider_unittest.cc [modify] https://crrev.com/74612b7459881f9194f4d404e4f6688efe0bd8f5/media/mojo/services/video_decode_perf_history.cc [modify] https://crrev.com/74612b7459881f9194f4d404e4f6688efe0bd8f5/media/mojo/services/video_decode_perf_history.h [modify] https://crrev.com/74612b7459881f9194f4d404e4f6688efe0bd8f5/media/mojo/services/video_decode_perf_history_unittest.cc [modify] https://crrev.com/74612b7459881f9194f4d404e4f6688efe0bd8f5/media/mojo/services/video_decode_stats_recorder.cc [modify] https://crrev.com/74612b7459881f9194f4d404e4f6688efe0bd8f5/media/mojo/services/video_decode_stats_recorder.h [modify] https://crrev.com/74612b7459881f9194f4d404e4f6688efe0bd8f5/media/mojo/services/watch_time_recorder.cc [modify] https://crrev.com/74612b7459881f9194f4d404e4f6688efe0bd8f5/media/mojo/services/watch_time_recorder.h [modify] https://crrev.com/74612b7459881f9194f4d404e4f6688efe0bd8f5/media/mojo/services/watch_time_recorder_unittest.cc [modify] https://crrev.com/74612b7459881f9194f4d404e4f6688efe0bd8f5/tools/metrics/ukm/ukm.xml
,
Dec 15 2017
Tentatively marking as fixed since we can correlate dropped frames from MediaCapabilities reports now with a playback. |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by dalecur...@chromium.org
, Mar 29 2017