Over to triage team.

Tested on Pixel 2 on reported Android 8.1.0 Build/OPM2.171019.029.B1 using Chrome #68.0.3430.2 (Dev) #66.0.3359.158 (Stable) #68.0.3432.0 (Canary) #60.0.3072.0 and observed that behavior of the video played is same on all the Chrome channels.

Screen cast of the behavior in Chrome and FireFox can be found here - https://drive.google.com/drive/folders/18HzLSL0dENY_kZ5LnL153UFefDd8g7AA?usp=sharing

Steps followed:
1. Launched Chrome.
2. Navigated to the URL provided - https://twitter.com/TheRealStanLee/status/996572052017430529
3. Played the video.

kbr@ -- Could you please confirm the behavior observed. Also, please verify and compare the video by playing in Chrome Stable at your end.

Other Observations - 
Video seems to play better in FireFox and Chrome Desktop. (Screen cast of FireFox is attached above)

Thanks!

Looking at it again, I can confirm that the skipping of this video happens on Chrome Stable on Android, too. Tested on another phone, and the skipping happens there, too, so it's not one particular phone.

Maybe the issue is that this is a high-resolution video and the browser can't keep up with the display of its video frames. Still, the browser should keep the audio playing smoothly and drop video frames as necessary.

I've seen this on other Twitter videos that have an audio track, so it isn't an isolated incident. It should still be considered high priority, especially because Firefox behaves better.

Un-marking R-B-S and recategorizing for better analysis by the Media team.

This is an HLS playback, so this is the Android OS level player and not Chrome's media pipeline. =>tguilbert in case there's something we can do about it.

Not sure why they're using HLS when they have a perfectly good MSE player on desktop; which I thought they were using on mobile in the past.

We used to have some twitter contacts, but retention policy seems to have eaten them :( +johnpallett for outreach since they shouldn't be using hls.

Here's another example which was just tweeted this morning. Navigate to the link, tap the video to play. The audio begins skipping ahead almost immediately.

https://twitter.com/Pat_Hg/status/1011972241440038912?s=17

It plays back fine in Firefox 61.0 for Android.

The Twitter Lite PWA is one of my main uses of Chrome on Android at this point; I've uninstalled their native app. This bug severely impacts the user experience and it's definitely possible to work around because it doesn't affect Firefox.

Marking this ReleaseBlock-Stable for M70. We should devote the time to fixing it.

I think they're using HLS.js on Firefox mobile but using src=hls in Chrome per source inspection, which would mean this isn't fixable by us. We need Twitter to stop attempting to use raw HLS in Chrome.

Ping @johnpallett for out-reach.

Actually digging in with Firefox dev tools I can see the src= is m3u8 as well; so that does suggest this is a bug in Chrome or at least it is something we can workaround.

Specifically the URL is https://video.twimg.com/ext_tw_video/1011970692114472960/pu/pl/rwvD2WlxKFN7-soV.m3u8?tag=3

For some reason the URL plays directly in Chrome, but not in Firefox, so not sure what's going on there.

Removing ?tag=3 allows it to play in Firefox.

Ah, but Firefox implements its own HLS demuxer and renderer, so this may still be something we can't fix in Chrome.

https://dxr.mozilla.org/mozilla-central/source/mobile/android/geckoview/src/main/java/org/mozilla/gecko/media (See *Hls*)

Can or should Chrome be handling these HLS streams rather than handing them off directly to Android? Since Firefox renders these correctly it seems to me that Chrome should.

Supporting HLS/DASH etc in the browser is non-trivial and something we've historically decided against; you can see further discussion on this at  issue 761506 . As an example, Shakaplayer, our JS based library for such support is a medium sized (4-10 SWE) dev team. Recreating that in C++ for Chrome isn't a trivial task or one to be done without consideration.

There's talk of using things like go/permafills to put an HLS JS library like Shakaplayer in Chrome, but that project isn't far enough along yet for us to do that. It'd probably be something looked at next year at the earliest.

TL;DR: The 180x320 playlist variant has some encoding issues.


I logged the reported media time vs elapsed time, and found that there were some sporadic 0.6s jumps in the media time.

I used an HLS analyzer tool. It reported that for the 180x320 resolution, most audio track segments are 2.4s while the video track's are 2.9s (compared to a declared length of 3.0s). The 3s reported duration vs 2.4s audio duration accounts for the 0.6s jumps in media time.
For comparison, the 360x640 and 720x1280 variants had most segments around 2.9s for both audio and video.

Compare the playback of the 180x320:
https://video.twimg.com/ext_tw_video/996571991380443136/pu/pl/180x320/E4rzTFWN4Sp_C7g8.m3u8

To the 720x1280 variant:
https://video.twimg.com/ext_tw_video/996571991380443136/pu/pl/720x1280/GIeK7hmZ9UY7UXvu.m3u8


That being said, Firefox still plays the low-res m3u8 smoothly. This might be because they stitch segments together.

Link to HLS analyzer script:
https://github.com/epiclabs-io/hls-analyzer

Attached: example outputs for the 1st segments.

Deleted: 180_320_hls_analysis.jpg 69.5 KB

	180_320_hls_analysis.jpg 69.5 KB View Download

Deleted: 720_1280_hls_analysis.png 73.1 KB

	720_1280_hls_analysis.png 73.1 KB View Download

-RBS, +ED since it appears to be an encoding issue.

AFAICT, Twitter has switched to using MP4 instead of HLS.