Video preloading under Mobile Emulation differs from real device |
|||||
Issue descriptionFrom this WebPageTest bug referencing the data collected as part of the HTTP Archive crawl (which uses Dev tools mobile emulation to fetch mobile sites): https://github.com/WPO-Foundation/webpagetest/issues/988 Using Chrome and an emulated browser (as HTTPArchive does), I sometimes see the webpage behave differently than the way it behaves on a true mobile device. For example, www.aol.com: If I run it on a Moto G4 (WiFi connection): https://www.webpagetest.org/result/171115_10_6c8e5e488a1e0d819c1292cb8801ca52/1/details/#waterfall_view_step1 I see the m3u8 manifest file at request 136, and then no further video requests. If I run the same test on Chrome - emulating the G4: https://www.webpagetest.org/result/171115_WX_1dd98b419a47198ff2383c34a61517a1/1/details/#waterfall_view_step1 The same M3u8 manifest is downloaded (request 137), and then I immediately see 2 more manifests for different bitrates (138, 143) and then sequential .ts segments (00001, 00002, etc.) - several MB worth of video. This indicates to me that the mobile emulation is allowing more video to download than actually happens on a device.
,
Nov 16 2017
phulce@, I'm not sure whom is the best person to investigate, could you please help triage? :)
,
Nov 16 2017
chcunningham, do you have any ideas on this?
,
Nov 16 2017
Yeah, this is unfortunately to be expected. Android Chrome supports HLS playback natively while desktop chrome does not. On desktop, AOL is using HLS.js, which implements HLS in javascript on top of MSE. This means the JS app (rather than the internal android player) is doing the fetching of video segments on desktop and those requests show up in the network panel. We can't use the same code paths in emulation because they rely on android OS APIS. We regret that support between android and desktop is not the same here, but we have no plans to add HLS to desktop at this point.
,
Nov 17 2017
@chcunningham -- Super helpful, thanks. ------------ I checked HLS.js's feature detection and there appears to be no problems there, so it's just that their fetch behavior is different. So I suppose this ends up being an inconsistency/bug between real HLS and HLS.js. +cc the HLS.js maintainer
,
Nov 17 2017
Also I'm adding a line to the devtools docs to document this difference: https://github.com/google/WebFundamentals/pull/5297/files
,
Nov 17 2017
One thing I'm trying to track down is if the HLS case still preloads the video and WPT just isn't showing it since it is done through the OS libraries or if there is a difference in the preloading behavior as well. Unfortunately the aol.com page changed out the content before I could clone it to try to reproduce it.
,
Nov 17 2017
+tguilbert@ to comment on typical android HLS preload behavior |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by paulir...@chromium.org
, Nov 16 2017