I did reinstall some old version and I can confirm 

    works with 58.0.3018.3
    fails with 58.0.3026.3

+hubbe, I wonder if this is related to fixing the cache; if so this is about to hit M57 too. It's possible our previous twitter issues were resolved because the cache was disabled.

Tagging with appropriate labels. Lets avoid regressing Twitter again unless we're sure its not our fault. hubbe@ PTAL.

(to confirm the fix to the cache is in the regression range).

Yes, my CL is in range.
However, this seems to be an MSE video player, so my change cannot affect it.
On my linux box it does play on ToT, but colors are all messed up.

Interesting, thanks. Lets confirm Twitter always using MSE now; may need a custom build to disable MSE. If they are then we can focus on any MSE changes that may have caused this.

regis.caspar: Can you check Chrome beta (57.0.2987.88 or higher) and see if you can repro this issue? I can drop the M-57 label if not.

+twitter engineers as FYI.

URGENT - PTAL ASAP.

A friendly reminder that M57 Stable is launch is coming soon! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch by Monday (03/06), 5:00 PM PST in order to make into the desktop Stable final build cut. Thank you!

Know that this issue shouldn't block the release?  Remove the ReleaseBlock-Stable label or move to M58.

Thank you.

+dalecur (sorry I don't see the whole nickname), 57.0.2987.88 beta (64-bit) is working as expected.

Great, dropping the RBS for M57 and then bumping to M58.

Removing network label (Of course, feel free to add it back if turns out to be an issue with the network stack).

Assigning to matt for additional triage.

No repro on current linux local tip-of-tree, nor on per-revision official bisect between 58.0.3018.3 and 58.0.3026.3 on linux64.

Current linux local tip-of-tree appears to successfully be using MSE.

regis.caspar@, can you still reproduce this on any M58 build, and if so, please provide a log from chrome://media-internals -> "Save Log" (attach it here or send it privately to wolenetz@google.com if you prefer). I suspect this is *not* related to MSE, since I could not reproduce it. That log will help identify what kind of playback it is (src= vs MSE, any may contain entries describing why the issue occurs for you).

A couple other attempts:

With (a) local build hacked to return false always for MediaSource.IsTypeSupported() queries (effectively disabling all mime types for MSE),
and, separately, (b) local build hacked to not expose MediaSource interface to javascript:

each attempt's playback fails to be supported on linux64 (it's trying an HLS m3u8 with regular src=), and no audio or video plays.

So it appears a repro log (see #12) will help the most, since I can't repro with MSE or without MSE.

@wolenetz I'm currently abroad. But I will provide what you asked when back home (end of next week).

Just to update the behavior of this wrt 'Needs-triage-Mobile' label added in Comment# 9.

Tested this on:
================ 
Chrome version: latest M-58(58.0.3029.23/3029@198).
Devices tested: Samsung Galaxy S2 tablet and Moto G Handset.
Platform tested:(Android 6.0.1; SM-T815Y Buid/MMB29K) and (Android 6.0.0 XT1068 MotoG Build/MBP24.65-34-3) 

Issue is not reproducible on Android as per the above test on Tablet and Handset.
Thank You.

@wolenetz I did test again using 1st post url and current dev version: 58.0.3029.19 dev (linux) and the video playback is working as expected. So this is fixed. Thanks everyone.

regis.caspar@ thanks for checking again. Resolving WontFix. I suspect this was a website, media, or repro environment problem, rather than a Chrome problem, since I'm unaware of any related Chrome changes and couldn't repro the problem.