media: Report initial video height to UMA

tools/metrics/histograms/histograms.xml

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 this name is only ever a prefix
to an actually recorded histogram name.

[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 changes?  Won't that result in
weirdly weighted data, where videos with many frame size changes report many
more samples to this metric?

[xhwang, 2017/04/18 05:52:37]

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...

[Ilya Sherman, 2017/04/18 05:58:54]

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.

[xhwang, 2017/04/18 06:39:50]

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.

[DaleCurtis, 2017/04/18 17:46:22]

we could use a base::flat_set to ensure we only report a given height once; this
avoids the overcounting issue.

[Ilya Sherman, 2017/04/19 00:35:10]

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 this name is only ever a prefix
to an actually recorded histogram name.

[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 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.

[xhwang, 2017/04/18 05:52:36]

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?

[Ilya Sherman, 2017/04/18 05:58:54]

It makes a fairly significant difference, yes.  What's the reason to disprefer
UMA_HISTOGRAM_CUSTOM_ENUMERATION?

[xhwang, 2017/04/18 06:39:50]

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 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."/>