Collect UKM on video bytes transferred |
|||
Issue descriptionThis will help to understand which technical approaches to pursue to reduce the number of bytes transferred on behalf of data saver users. This might not be straightforward because video is often not carried with content-type video/*. For example, some sites carry video in text/plain. One approach would be to record bytes per content-type encountered on the page. Another (harder) would be to trace through Chrome how bytes are used. Still another would be to try to infer type from content-type and file extension. I think I prefer the first.
,
Mar 14 2018
,
Mar 14 2018
I'm not really sure how to measure bytes like Youtube or DASH considering they won't look like video bytes. Is there a way to get this information reliably?
,
Mar 27 2018
Media Engagament Index described in https://docs.google.com/document/d/1_278v_plodvgtXSgnEJ0yjZJLg14Ogf-ekAFNymAJoU/edit#heading=h.c1rqulonmckg may be relevant.
,
May 15 2018
Talked to Ryan, still on his plate but still need to resolve what byte size is feasible wrt network stack having no visibility into Shaka player loads.
,
May 15 2018
I believe the path I would like to use is reporting total bytes played on the page (not limited to network bytes), as the layering makes it very tricky to make this decision correctly. The way many videos are played from blob URLS means that trying to figure out where those bytes came from is near impossible.
,
May 15 2018
These bytes would be aggregated over all frames and bucketed similar to network and cached bytes.
,
May 18 2018
We'll go ahead and use total data use with a holdback to analyze data savings. |
|||
►
Sign in to add a comment |
|||
Comment 1 by bengr@chromium.org
, Mar 14 2018