tools/metrics/histograms/histograms.xml - Issue 2814043005: media: Report initial video height to UMA

Unified Diff: tools/metrics/histograms/histograms.xml

Side-by-side diff isn't available for this file because of its large size.

Issue 2814043005: media: Report initial video height to UMA (Closed)

Patch Set: reabse and owner Created 3 years, 8 months ago

Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.

Jump to:

Index: tools/metrics/histograms/histograms.xml

diff --git a/tools/metrics/histograms/histograms.xml b/tools/metrics/histograms/histograms.xml

index f8ce2d3bf745ff971181508ece164e0d9741b4de..19518e7ef35432a93b564bc6d030107f04c2fd33 100644

--- a/tools/metrics/histograms/histograms.xml

+++ b/tools/metrics/histograms/histograms.xml

@@ -28408,6 +28408,22 @@ http://cs/file:chrome/histograms.xml - but prefer this file for new entries.

<summary>Pixel format used in HTML5 video. Emitted on video load.</summary>

</histogram>

+<histogram name="Media.VideoHeight.Average" units="pixels">

Ilya Sherman 2017/04/17 20:10:14 nit: Please add the attribute base="true", since t

xhwang 2017/04/18 05:52:37 Done.

+ <owner>media-dev@chromium.org</owner>

+ <summary>

+ The height of the video frame in an HTML5 video. Reported whenever a new

+ video frame size is available (e.g. during MSE config change).

Ilya Sherman 2017/04/17 20:10:14 Hmm, the average is updated whenever the size chan

xhwang 2017/04/18 05:52:37 See previous discussion on this in the code review

Ilya Sherman 2017/04/18 05:58:54 Could you please help me to understand how you pla

xhwang 2017/04/18 06:39:50 The original intention was to use this as the indi

DaleCurtis 2017/04/18 17:46:22 we could use a base::flat_set to ensure we only re

Ilya Sherman 2017/04/19 00:35:10 Sampling seems like a reasonable solution to me.

On 2017/04/18 17:46:22, DaleCurtis wrote: > On 2017/04/18 at 06:39:50, xhwang_slow wrote: > > On 2017/04/18 05:58:54, Ilya Sherman wrote: > > > On 2017/04/18 05:52:37, xhwang_slow wrote: > > > > On 2017/04/17 20:10:14, Ilya Sherman wrote: > > > > > Hmm, the average is updated whenever the size changes? Won't that > result in > > > > > weirdly weighted data, where videos with many frame size changes report > many > > > > > more samples to this metric? > > > > > > > > See previous discussion on this in the code review. We discussed about > > > > playback-time weighted resolution over the entire playback instance, but > felt > > > > that it's probably over-kill for our purpose. Also, even if we report a > > > > "playback-time weighted resolution" per playback, it's still not a fair > > > > comparison. For example, you could be watching 1080p for 2 hours in one > > > playback > > > > instance, and 480p for 2 minutes in another. Then reporting one sample of > 1080 > > > > and another sample of 480 won't really tell us the real story... > > > > > > > > So, this is really reporting all sizes we encountered during playbacks. I > > > > thought about s/Average/All, but Media.VideoHeight.All.All would be more > > > > confusing... > > > > > > Could you please help me to understand how you plan to use this metric? I > think > > > I'll be able to offer better guidance if I better understand your intended > use > > > for it. > > > > The original intention was to use this as the indication of "average video > resolution" across all playback instances. Ideally, we want to get something > like sum_over_all_playabacks(resolution * playback_time_on_this_resolution) / > sum_over_all_playabacks(playback_time). One way to do this is by sampling, e.g. > we report resolution every 1 or 10 minute. Will that be something you would > prefer? Or do you have better suggestions? Getting playtime involved would be > more complicated in terms of implementation. > > we could use a base::flat_set to ensure we only report a given height once; this > avoids the overcounting issue.

Sampling seems like a reasonable solution to me. (You'd probably want to randomize it a bit, in case some videos do something weird.) If your goal is just to see what heights are ever used, then reporting just once is okay too. But in that case it probably makes sense to rename the histogram to match the use case.

+ </summary>

+</histogram>

+<histogram name="Media.VideoHeight.Initial" units="pixels">

Ilya Sherman 2017/04/17 20:10:14 nit: Please add the attribute base="true", since t

xhwang 2017/04/18 05:52:37 Done.

+ <owner>xhwang@chromium.org</owner>

+ <summary>

+ The height of the first video frame in an HTML5 video. Reported when the

+ first video frame is available.

+ </summary>

+</histogram>

<histogram name="Media.VideoPersistence.AttemptResult"

enum="VideoPersistenceAttemptResult">

<owner>mlamouri@chromium.org</owner>

@@ -120470,6 +120486,15 @@ from previous Chrome versions.

<affected-histogram name="Media.VideoCaptureManager"/>

</histogram_suffixes>

+<histogram_suffixes name="MediaVideoCategories" separator=".">

+ <suffix name="All" label="All media with a video track."/>

+ <suffix name="EME" label="EME media with a video track."/>

+ <suffix name="MSE" label="MSE media with a video track."/>

+ <suffix name="SRC" label="SRC media with a video track."/>

+ <affected-histogram name="Media.VideoHeight.Average"/>

+ <affected-histogram name="Media.VideoHeight.Initial"/>

Ilya Sherman 2017/04/17 20:10:14 You are currently adding almost 1000 buckets-worth

xhwang 2017/04/18 05:52:36 When I said ~50 buckets, it's for UMA_HISTOGRAM_CU

Ilya Sherman 2017/04/18 05:58:54 It makes a fairly significant difference, yes. Wh

xhwang 2017/04/18 06:39:50 Because without seeing the real world data, it's h

Because without seeing the real world data, it's hard to come up with a good custom range. You can check the current Media.VideoVisibleWidth UMA (BTW, after I land the current CL, we can probably drop that), where most of the reports are concentrated in some buckets. Tweaks all the buckets based on some theoretical assumption ends up pointless to me. I didn't know 120 buckets vs 50 would make a big difference. So I played with it a bit more, I think I can do UMA_HISTOGRAM_CUSTOM_COUNTS(name, sample, 100, 10000, 50), which will give us the following ranges: 0, 100, 110, 121, 133, 146, 161, 177, 195, 215, 237, 261, 287, 316, 348, 383, 422, 464, 511, 562, 619, 681, 750, 826, 909, 1001, 1102, 1213, 1335, 1469, 1617, 1780, 1959, 2156, 2373, 2612, 2875, 3164, 3482, 3832, 4218, 4643, 5110, 5624, 6190, 6813, 7499, 8254, 9085, 10000, 2147483647 Note that 320p will be in [316, 348), 480p will be in [464, 511), 720p will be in [681, 750), and 1080p will be in [1001, 1102). It's probably hard to answer exact questions like what's the number of playbacks on 1080p+, but we should have good estimates. Dale/Ilya: Does this look good to you?

Ilya Sherman 2017/04/19 00:32:50 Thanks. To be clear, if 120 buckets gives signifi

On 2017/04/18 06:39:50, xhwang_slow wrote: > On 2017/04/18 05:58:54, Ilya Sherman wrote: > > On 2017/04/18 05:52:36, xhwang_slow wrote: > > > On 2017/04/17 20:10:14, Ilya Sherman wrote: > > > > You are currently adding almost 1000 buckets-worth of histograms, across > > these > > > 8 > > > > histograms of 120 buckets each. On the bug, you mentioned that you might > be > > > > able to use ~50 buckets per histogram. Is that still feasible? Reducing > > the > > > > number of buckets used for these by a factor of two seems worthwhile if > the > > > data > > > > provided would be comparably good. > > > > > > When I said ~50 buckets, it's for UMA_HISTOGRAM_CUSTOM_ENUMERATION. But > after > > I > > > played it more, I felt it's probably easier and cleaner to just use a normal > > > histogram. Then I played with the range and bucket number a bit more and > found > > > 120 buckets would give us the granularity we'd like to have. I can probably > > > tweak it more to use less buckets, but probably cannot reduce it to ~50. > > > > > > So, how sensitive are we on adding 1000 buckets-worth of histograms, vs, > say, > > > 500 buckets-worth of histograms. Will that make a huge difference? > > > > It makes a fairly significant difference, yes. What's the reason to disprefer > > UMA_HISTOGRAM_CUSTOM_ENUMERATION? > > Because without seeing the real world data, it's hard to come up with a good > custom range. You can check the current Media.VideoVisibleWidth UMA (BTW, after > I land the current CL, we can probably drop that), where most of the reports are > concentrated in some buckets. Tweaks all the buckets based on some theoretical > assumption ends up pointless to me. > > I didn't know 120 buckets vs 50 would make a big difference. So I played with it > a bit more, I think I can do > UMA_HISTOGRAM_CUSTOM_COUNTS(name, sample, 100, 10000, 50), which will give us > the following ranges: > > 0, 100, 110, 121, 133, 146, 161, 177, 195, 215, 237, 261, 287, 316, 348, 383, > 422, 464, 511, 562, 619, 681, 750, 826, 909, 1001, 1102, 1213, 1335, 1469, 1617, > 1780, 1959, 2156, 2373, 2612, 2875, 3164, 3482, 3832, 4218, 4643, 5110, 5624, > 6190, 6813, 7499, 8254, 9085, 10000, 2147483647 > > Note that 320p will be in [316, 348), 480p will be in [464, 511), 720p will be > in [681, 750), and 1080p will be in [1001, 1102). It's probably hard to answer > exact questions like what's the number of playbacks on 1080p+, but we should > have good estimates. > > Dale/Ilya: Does this look good to you?

Thanks. To be clear, if 120 buckets gives significantly better data, then using 120 buckets is fine. But if 50 buckets gives roughly comparable-quality data, then 50 buckets is definitely preferred.

+</histogram_suffixes>

<histogram_suffixes name="MediaWatchTimeCategories" separator=".">

<suffix name="Audio.All"

label="Watch time for all media with only an audio track."/>

« no previous file with comments | « media/blink/webmediaplayer_impl.cc ('k') | no next file » | no next file with comments »