I plan to check if any of the resources on the page either were loaded as <video> or <audio> tags (e.g. content::ResourceType is MEDIA). Or the response headers contain a MimeType of video/ or audio/.

I'm not familiar enough with media resource detection to know if this is a valid approach.

I would hook HTMLMediaElement::playInternal to set a bit on the Document for whether if a media element has played. Mounir/Anton know the media code better than I do though and might have better ideas.

BTW, when does the page size tracking log the page size to UMA?

Mounir/Anton: The context for this is we're exploring interventions for sites that use extreme amounts of data and want to have a sense of what different limits would imply about number of page views we'd affect. We're considering having a higher limit for pages that play media content. We would have a separate limit for just the video resources, but that seems impossible to do given MSE and what not, right?

The page size tracking UMA is logged when the tab is navigated elsewhere, the tab is closed, or the app is backgrounded on android (part of page_load_metrics framework).

I suppose adding a some sort of FirstMediaPlayedTime to the blink::WebPerformance and Document is an option to get it down to the observer.

It would still be nice to do some MIME-sniffing to determine what percent of the page is media in terms of bytes and what-not. I'm wondering if MIME + content::ResourceType isn't sufficient enough as a lot of places in chrome use MIME-sniffing or ResourecType. (ResourcePrefetchPredictor::GetResourceTypeFromMimeType and ContentURLRequestClassifier::GetContentType as examples)

bmcquade, csharrison: What are your thoughts on this?

If you don't need the first play time, you could use WebLoadingBehaviorFlag to propagate a boolean "played media" for a given page load. I am nervous about using a mime sniffing approach because it could be gamed via XHR style fetches.

ojan@, it is indeed not possible today to reliably figure out if a download is meant for MSE or not. I would like us to solve this problem but in the meantime, you would have to use other signals.

If a media is playing might be a bit flaky as in on mobile autoplay muted might be used more frequently than proper media playback.

I think the approach that csharrison/ojan mentions makes sense.

For this UMA, I will add a WebLoadingBehaviorFlag for played media and set that bool in HTMLMediaElement::playInternal.

Thanks for the pointers.

W.R.T. separate thresholds for media page loads in comment 3. My initially plan was to have a Data cap for pages without media and have a higher data cap for pages that have media playing. I don't think this is necessarily the best long term approach. After either cap is met, the user will be shown some UI that will ask if they want to continue loading requests for the page.

This is in code review here: https://codereview.chromium.org/2732293003/

I expect that once we actually want to throttle page loads, we will likely have to rely on this bit being plumbed to the ChromeDataUseEntry, so the page load can be flagged as containing media and given a bigger pool of data to use before we throttle the page load. It will  be challenging to try to assign every request as either media or not media because of XHR's for data.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/09fb15d21c53769e466ea5a80bd3a170082e7bfe

commit 09fb15d21c53769e466ea5a80bd3a170082e7bfe
Author: ryansturm <ryansturm@chromium.org>
Date: Thu Mar 16 00:14:55 2017

Adding UMA on page load size for pages with Media

This CL plumbs a renderer behavior (MediaPlayed) from blink/ when a
media element is played. An observer records page size UMA on pages that
saw at least one media element get played.

BUG= 698348 

Review-Url: https://codereview.chromium.org/2732293003
Cr-Commit-Position: refs/heads/master@{#457275}

[modify] https://crrev.com/09fb15d21c53769e466ea5a80bd3a170082e7bfe/chrome/browser/BUILD.gn
[modify] https://crrev.com/09fb15d21c53769e466ea5a80bd3a170082e7bfe/chrome/browser/page_load_metrics/metrics_web_contents_observer.cc
[modify] https://crrev.com/09fb15d21c53769e466ea5a80bd3a170082e7bfe/chrome/browser/page_load_metrics/metrics_web_contents_observer.h
[add] https://crrev.com/09fb15d21c53769e466ea5a80bd3a170082e7bfe/chrome/browser/page_load_metrics/observers/media_page_load_metrics_observer.cc
[add] https://crrev.com/09fb15d21c53769e466ea5a80bd3a170082e7bfe/chrome/browser/page_load_metrics/observers/media_page_load_metrics_observer.h
[add] https://crrev.com/09fb15d21c53769e466ea5a80bd3a170082e7bfe/chrome/browser/page_load_metrics/observers/media_page_load_metrics_observer_unittest.cc
[modify] https://crrev.com/09fb15d21c53769e466ea5a80bd3a170082e7bfe/chrome/browser/page_load_metrics/observers/page_load_metrics_observer_test_harness.cc
[modify] https://crrev.com/09fb15d21c53769e466ea5a80bd3a170082e7bfe/chrome/browser/page_load_metrics/observers/page_load_metrics_observer_test_harness.h
[modify] https://crrev.com/09fb15d21c53769e466ea5a80bd3a170082e7bfe/chrome/browser/page_load_metrics/page_load_metrics_initialize.cc
[modify] https://crrev.com/09fb15d21c53769e466ea5a80bd3a170082e7bfe/chrome/browser/page_load_metrics/page_load_metrics_observer.h
[modify] https://crrev.com/09fb15d21c53769e466ea5a80bd3a170082e7bfe/chrome/browser/page_load_metrics/page_load_tracker.cc
[modify] https://crrev.com/09fb15d21c53769e466ea5a80bd3a170082e7bfe/chrome/browser/page_load_metrics/page_load_tracker.h
[modify] https://crrev.com/09fb15d21c53769e466ea5a80bd3a170082e7bfe/chrome/test/BUILD.gn
[modify] https://crrev.com/09fb15d21c53769e466ea5a80bd3a170082e7bfe/tools/metrics/histograms/histograms.xml