I am able to repro this issue. the video source is in https protocol instead of http. I am not sure if this is the reason.
This video is able to play in safari but not on Chrome.
Dale, can you take a look?

this seems a duplicate of 629695.

This is not a dupe of  issue 629695 . Able to repro on Linux ToT using the direct URL,

https://pbs.twimg.com/tweet_video/Cn0O_0xWYAAT_pj.mp4

but doesn't seem to have any issue on M52 beta. Possibly a network issue?

Takes a couple of reloads and fresh tabs to make the video loading fail.

Had to clear cache to get it to repro after closing browser. The log from ffmpeg/media is:

[mov,mp4,m4a,3gp,3g2,mj2 @ 0x17d9df89de00] moov atom not found
[1:1:0725/163516:ERROR:render_media_log.cc(25)] MediaEvent: PIPELINE_ERROR pipeline: read error

happens w/ or w/o multibuffer cache.

cc: twitter contact for directing to the right folk. It seems like you might have an intermittent serving bug, but we haven't fully diagnosed the issue yet.

For me it only happens when I use system-ffmpeg (that's like a manual hack to use that, so to speak). But otherwise I haven't encountered that when using a chromium compiled with the embedded ffmpeg(or how should I call it).

I've mentioned that in another issue here: https://bugs.chromium.org/p/chromium/issues/detail?id=629695#c6
(read from "The only downside for system-ffmpeg")

Still currently happens(with system-ffmpeg) on this tweet(video):
https://twitter.com/AnnaKendrick47/status/755485525448863744
(but if I restart chromium, it'll probably work again.)

However this issue would never happen(for me) if I weren't using system-ffmpeg. As far as I could tell it didn't happen before!


My current chrome://version  (if relevant)

Chromium	54.0.2815.0 (Developer Build) (64-bit)
Revision	ca0e8af2849a29419e472ad636d1afdfced87acf-refs/heads/master@{#408882}
OS	Linux 
JavaScript	V8 5.4.302
Flash	
User Agent	Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2815.0 Safari/537.36
Command Line	/usr/lib/chromium/chromium --disk-cache-dir=/tmp/chromiumcache --disable-sync-preferences --disable-plugins --cipher-suite-blacklist=0x0001,0x0002,0x0004,0x0005,0x0017,0x0018,0xc002,0xc007,0xc00c,0xc011,0xc016,0xff80,0xff81,0xff82,0xff83 --disable-component-extensions-with-background-pages --disable-background-networking --disable-internal-flash --disable-bundled-ppapi-flash --disable-default-apps --ssl-version-min=tls1 --disallow-autofill-sync-credential --disable-device-discovery-notifications --no-pings --disable-media-source --disable-ntp-other-sessions-menu --disable-prefixed-encrypted-media --disable-touch-adjustment --disable-views-rect-based-targeting --disable-webgl --disable-account-consistency --enable-async-dns --enable-deferred-image-decoding --enable-download-resumption --enable-drop-sync-credential --disable-material-design-ntp --disable-new-avatar-menu --disable-new-profile-management --enable-offline-auto-reload-visible-only --disable-offline-auto-reload --enable-offline-load-stale-cache --enable-one-copy --enable-panels --disable-password-generation --enable-permissions-bubbles --disable-extensions-on-chrome-urls --disable-pinch-virtual-viewport --disable-pinch --enable-quic --disable-save-password-bubble --enable-session-crashed-bubble --disable-settings-window --use-simple-cache-backend=off --disable-smooth-scrolling --disable-sync-app-list --disable-sync-synced-notifications --enable-tcp-fastopen --disable-touch-editing --enable-web-based-signin --disable-zero-copy --enable-harfbuzz-rendertext --enable-impl-side-painting --enable-lcd-text --num-raster-threads=4 --disable-origin-chip --disable-overlay-scrollbar --remember-cert-error-decisions=-1 --enable-search-button-in-omnibox-always --disable-spelling-auto-correct --tab-capture-downscale-quality=fast --tab-capture-upscale-quality=fast --touch-events=disabled --wallet-service-use-sandbox=0 --enable-gpu-vsync --show-component-extension-options --disable-gpu-rasterization --disable-hyperlink-auditing --enable-vertical-tabs --disable-audio-support-for-desktop-share --disable-gpu --wm-user-time-ms=1889495 --flag-switches-begin --flag-switches-end --window-depth=32 --x11-visual-id=97
Executable Path	/usr/lib/chromium/chromium
Profile Path	/home/z/.config/chromium/Default
Variations	ba3f87da-92cc81ec
f049a919-3f4a17df
43d0dd1e-3f4a17df
9e243dd-3f4a17df
64cbdfc2-3f4a17df
b7786474-d93a0620
7382e39a-3f4a17df
868bda90-3f4a17df
4ea303a6-3f4a17df
3d7e3f6a-2eb01455
f8c15c50-3f4a17df
9736de91-3f4a17df
30e679f-3f4a17df
ad6d27cc-3e870323
867c4c68-3f4a17df
d747916f-d747916f
fe05be5f-4ad60575
b0dc61a1-3f4a17df

Ok, I'll shut up now :) Let me know if I can test anything - willing to help.

I was able to reproduce the issue with a few reloads and a fresh cache on clean Linux builds. The original report is for Windows as well, so I think this applies everywhere, but only happens sometimes.

Same here, example at https://twitter.com/Monstein/status/776205634169548800

Win8.1 x64 on Beta Channel but I had that for ages on Dev, too.

Hey there, Chrome Community Manager here. Just wanted to chime in on the bug that we're seeing fresh reports about this since the M53 rollout on our community channels like Reddit (https://www.reddit.com/r/chrome/comments/54vo76/getting_this_browser_does_not_support_video/) and Twitter (https://twitter.com/search?f=tweets&vertical=default&q=this%20browser%20does%20not%20support%20video%20playback%20chrome&src=typd)

Escalating to Abhishek (Chrome Support Specialist) with more info to see if we can connect.

Hello Team,

Simple way to repro this issue was to scroll through https://twitter.com/gifs
Some gifs played while some failed with the error message.

Google Chrome	55.0.2869.0 (Official Build) dev (64-bit)
Revision	0
Platform	8838.0.0 (Official Build) dev-channel samus
ARC	        3294522
JavaScript	V8 5.5.266
Flash	        23.0.0.179-r1
User Agent	Mozilla/5.0 (X11; CrOS x86_64 8838.0.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2869.0 Safari/537.36

Looking at user feedback reports, this issue has been impacting our users over quite some time now. Is there any timeline on fixing this bug ?

The fact that this is an infinite-scroll page makes me suspect that it's running into the six-open-connections-per-site limit. Usually this only happens if the player doesn't close the streams as they scroll off the page. (By setting src to "" on the video tag.) But I could imagine that with a tall enough screen, this could happen fairly frequently on this page.

I'll take a closer look tomorrow and see if that's what's actually going on or not.

Not sure it this is related or not, but in debug mode I keep getting this error:

Received signal 11 SEGV_MAPERR 000000000008
#0 0x7f8244f19d2e base::debug::StackTrace::StackTrace()
#1 0x7f8244f1986f base::debug::(anonymous namespace)::StackDumpSignalHandler()
#2 0x7f824535a330 <unknown>
#3 0x7f822c0e250c WTF::StringImpl::is8Bit()
#4 0x7f822c11f7ad WTF::String::is8Bit()
#5 0x7f822ce38b1c blink::maybeEncodeTextContent()
#6 0x7f822ce390de blink::InspectorPageAgent::cachedResourceContent()
#7 0x7f822ce82240 blink::NetworkResourcesData::ResourceData::clearWeakMembers()
#8 0x7f822ce84e17 blink::TraceMethodDelegate<>::trampoline()
#9 0x7f8236ab686c blink::CallbackStack::Item::call()
#10 0x7f8236acdb43 blink::ThreadState::popAndInvokeThreadLocalWeakCallback()
#11 0x7f8236acdd17 blink::ThreadState::threadLocalWeakProcessing()
#12 0x7f8236ad3c48 blink::ThreadState::preSweep()
#13 0x7f8236ad45c3 blink::ThreadState::leaveSafePoint()
#14 0x7f82366d456e blink::SafePointScope::~SafePointScope()
#15 0x7f8236acf7bd blink::ThreadState::collectGarbage()
#16 0x7f8236ad1ec6 blink::ThreadState::runScheduledGC()
#17 0x7f8236ad434a blink::ThreadState::safePoint()
#18 0x7f82366d904c blink::GCTaskObserver::didProcessTask()
#19 0x7f8236a1c469 blink::scheduler::WebThreadBase::TaskObserverAdapter::DidProcessTask()
#20 0x7f82369e9eab blink::scheduler::TaskQueueManager::ProcessTaskFromWorkQueue()
#21 0x7f82369e7832 blink::scheduler::TaskQueueManager::DoWork()
#22 0x7f82369ef754 _ZN4base8internal13FunctorTraitsIMN5blink9scheduler16TaskQueueManagerEFvNS_9TimeTicksEbEvE6InvokeIRKNS_7WeakPtrIS4_EEJRKS5_RKbEEEvS7_OT_DpOT0_
#23 0x7f82369ef604 _ZN4base8internal12InvokeHelperILb1EvE8MakeItSoIRKMN5blink9scheduler16TaskQueueManagerEFvNS_9TimeTicksEbERKNS_7WeakPtrIS6_EEJRKS7_RKbEEEvOT_OT0_DpOT1_
#24 0x7f82369ef564 _ZN4base8internal7InvokerINS0_9BindStateIMN5blink9scheduler16TaskQueueManagerEFvNS_9TimeTicksEbEJNS_7WeakPtrIS5_EES6_bEEEFvvEE7RunImplIRKS8_RKSt5tupleIJSA_S6_bEEJLm0ELm1ELm2EEEEvOT_OT0_NS_13IndexSequenceIJXspT1_EEEE
#25 0x7f82369ef43c _ZN4base8internal7InvokerINS0_9BindStateIMN5blink9scheduler16TaskQueueManagerEFvNS_9TimeTicksEbEJNS_7WeakPtrIS5_EES6_bEEEFvvEE3RunEPNS0_13BindStateBaseE
#26 0x7f8244eea17b base::internal::RunMixin<>::Run()
#27 0x7f8244f1f691 base::debug::TaskAnnotator::RunTask()
#28 0x7f8244faf6ef base::MessageLoop::RunTask()
#29 0x7f8244faf934 base::MessageLoop::DeferOrRunPendingTask()
#30 0x7f8244fafbfe base::MessageLoop::DoWork()
#31 0x7f8244fc6953 base::MessagePumpDefault::Run()
#32 0x7f8244faf2a6 base::MessageLoop::RunHandler()
#33 0x7f8245054454 base::RunLoop::Run()
#34 0x7f824087420c content::RendererMain()
#35 0x7f8240c40b4e content::RunZygote()
#36 0x7f8240c411b0 content::RunNamedProcessTypeMain()
#37 0x7f8240c435e2 content::ContentMainRunnerImpl::Run()
#38 0x7f8240c401f2 content::ContentMain()
#39 0x7f8245da26bb ChromeMain
#40 0x7f8245da2652 main
#41 0x7f8232e6ff45 __libc_start_main
#42 0x7f8245da2555 <unknown>
  r8: 0000000000000000  r9: 00007fff209ee800 r10: 00007fff209ee870 r11: 0000000000000206
 r12: 00007f8245da252c r13: 00007fff209f0e10 r14: 0000000000000000 r15: 0000000000000000
  di: 0000000000000000  si: 00007fff209ee558  bp: 00007fff209ee290  bx: 0000000000000000
  dx: 00007fff209ee7e8  ax: 0000000000000000  cx: 00007fff209ee7e7  sp: 00007fff209ee290
  ip: 00007f822c0e250c efl: 0000000000010206 cgf: 0000000000000033 erf: 0000000000000004
 trp: 000000000000000e msk: 0000000000000000 cr2: 0000000000000008
[end of stack trace]

Twitter engineer here. We've investigated this issue on our side and realized that our CDN is sometimes returning 200 responses to requests that should be returning partial 206 responses (byte range requests that have If-Range headers that should cause a 206). We're tracking down this on our side, but were interested in seeing if it's expected behavior for chrome to fail to play content when receiving a 200 response when it expects a 206.

Doing some investigation, it seems like this issue has been sporadically reported in a number of different places of the years 
https://bugs.chromium.org/p/chromium/issues/detail?id=74852#c8
https://bugs.chromium.org/p/chromium/issues/detail?id=40344#c15
https://community.akamai.com/community/media-delivery/blog/2015/01/27/why-my-chrome-browser-cannot-play-mp4-video-file-from-edge

but never addressed in more than just a passing comment.

It depends on what range was requested.
If we request the range 0- and receive a 200 response, nothing bad happens.
If that request *also* specifies "accept-ranges: none", then we disable seeking.

If the request was for a different range, and we get a 200 response, video playback fails.

Looking through the spec (https://tools.ietf.org/html/rfc7233) I'm not sure I see how failing on a 200 response is alright to do, because a 200 response to a "Range: bytes=x-y" is a valid response.

Specifically:
3.1 "A server MAY ignore the Range header field."

3.1 "If all of the preconditions are true, the server supports the Range header field for the target resource, and the specified range(s) are valid and satisfiable (as defined in Section 2.1), the server SHOULD send a 206 (Partial Content) response with a payload containing one or more partial representations that correspond to the satisfiable ranges requested, as defined in Section 4."

Note the use of "MAY" and "SHOULD" there. There's nothing that says the server "MUST" return a 206 response, even in the case where it claims to support byte range requests with Accept-Ranges headers.

We definitely need to fix our CDN responses to return partial responses all the time when valid to do so, but I think chrome is also not adhering to spec here. It's a completely valid use case that the asset server side would change, causing If-Range header preconditions to fail, and the server to respond with a 200 response. In these cases, chrome now has out of date partial responses, but it shouldn't just drop the 200 response on the floor. For what it's worth, other browsers appear to handle these 200 responses without failing.

HTTP/1.1 doesn't say anything about video playback.

From a server perspective (and especially from a non-media aware CDN edge cache perspective), it is valid to respond to a range request with the full object and a 200 status code. Other browsers seem resilient to this behavior, and are able to playback video without error when they receive a 200 instead of a 206.

So even if the current behavior is not in direct violation of the spec, it results in a bad video playback experience.

Is there a downside to handling the 200 and continuing playback?

Allowing the server to return the whole file is *also* a bad video playback experience.  Imagine seeking to the end of a 1Gb HD movie and having to read the whole file in order to get there. Even worse: The user might be paying for their internet access by the megabyte.

Returning the whole file might be acceptable for small files, but it is absolutely unacceptable for large files. However, since we disable seeking for servers that don't claim to support ranges, we normally don't make ranged requests to servers that don't support it.

I can confirm this on Chrome 53.0.2785.143 (64-bit) under Linux 4.2.0 amd64. It comes in waves. Snooping on Chrome's stderr yields this gem exactly when the "browser cannot play videos" message appears:

[313:313:1011/170921:ERROR:render_media_log.cc(25)] MediaEvent: PIPELINE_ERROR demuxer: could not open

Hope this helps.

@hubbe completely agree that both are issues and bad video playback experience. We're tracking down the issue with our CDN and would like confirmation that the chrome team is aware of this issue from that perspective and either is triaging it, or is explicitly deciding to implement differently from other browsers.

You're correct that HTTP/1.1 doesn't say anything about video playback, however dropping the network socket on a response and accepting one valid response but not the other seems to be in violation of the specification regardless of the type of content received.

Re #24:

I haven't been able to prove this yet, but my working theory is that chrome is using up all the available connections. (6 per domain) When you try to open additional connections, the network layer just causes a delay until a socket becomes available. I suspect that something in the video pipeline times out during this delay.

FWIW, this issue repros in all browsers. We've seen it in Safari, IE, etc, so I doubt it's a Chrome specific behavior.

In our experience, we are able to play these assets reliably in other browsers.

You can see for yourself by scrolling through twitter.com/gifs

https://twitter.com/google/status/778718619198894080 this one still seems broken, I've tested it in the past and it was broken in Safari too.

https://twitter.com/google/status/778718619198894080 works for me in Chrome
on Mac :-)

Hmm, definitely failing on Chrome Linux 54.0.2840.41 beta (64-bit) and we have a long internal thread of other users experiencing similar failure. Maybe it depends on the CDN?

The URL given to the player on my side is https://pbs.twimg.com/tweet_video/Cs6QLluUAAAh-se.mp4

$ ffplay Cs6QLluUAAAh-se.mp4 
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f0e3c0008c0] Format mov,mp4,m4a,3gp,3g2,mj2 detected only with low score of 1, misdetection possible!
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f0e3c0008c0] moov atom not found
Cs6QLluUAAAh-se.mp4: Invalid data found when processing input

(Downloaded via wget FWIW, not Chrome)

Definitely failing on Chrome Windows 54.0.2840.59 Stable (32-bit)

 Issue 657827  has been merged into this issue.

Marking as external dependency since the clip is busted w/o any interaction from Chrome.

dalecur@- Not sure why you are saying that. I can download https://pbs.twimg.com/tweet_video/Cs6QLluUAAAh-se.mp4 (using Chrome right-click save as) and playback in Quicktime with no problem, but it fails to playback in the Chrome. That same URL plays back fine in Safari and Firefox.

It consistently fails to play for me in Chrome and only Chrome.

Is this what you got when you downloaded it:

$ md5sum Cs6QLluUAAAh-se.mp4
7d07cff9c4fb0db7c53c93b45c105a8b  Cs6QLluUAAAh-se.mp4

?

When I download the same url today, I get a different and larger file:

$ ls -al Cs6QLluUAAAh-se.mp4*
-rw-rw-r-- 1 hubbe eng  547614 Sep 21 15:11 Cs6QLluUAAAh-se.mp4
-rw-rw-r-- 1 hubbe eng 8936222 Sep 21 15:11 Cs6QLluUAAAh-se.mp4.1

7d07cff9c4fb0db7c53c93b45c105a8b  Cs6QLluUAAAh-se.mp4
c8d507c3c4014c81e3a5c5c4c2ef1121  Cs6QLluUAAAh-se.mp4.1

I have the same hash as hubbe, but redownloading does not help:
7d07cff9c4fb0db7c53c93b45c105a8b  Cs6QLluUAAAh-se.mp4

$ wget https://pbs.twimg.com/tweet_video/Cs6QLluUAAAh-se.mp4
--2016-10-20 11:37:34--  https://pbs.twimg.com/tweet_video/Cs6QLluUAAAh-se.mp4
Resolving pbs.twimg.com (pbs.twimg.com)... 104.244.43.167, 104.244.43.39
Connecting to pbs.twimg.com (pbs.twimg.com)|104.244.43.167|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 547614 (535K) [video/mp4]
Saving to: ‘Cs6QLluUAAAh-se.mp4’

100%[====================================================================================================================================================>] 547,614     --.-K/s   in 0.1s    

2016-10-20 11:37:34 (5.44 MB/s) - ‘Cs6QLluUAAAh-se.mp4’ saved [547614/547614]

$ md5sum Cs6QLluUAAAh-se.mp4 
7d07cff9c4fb0db7c53c93b45c105a8b  Cs6QLluUAAAh-se.mp4

Here's what is downloaded on our side.

Deleted: Cs6QLluUAAAh-se.mp4 534 KB

	Cs6QLluUAAAh-se.mp4 534 KB View Download

Interestingly, when I try to download through chrome, I see this:

Accept-Ranges:bytes
access-control-allow-origin:*
Age:155107
cache-control:max-age=604800, must-revalidate
Connection:Keep-Alive
Content-Length:547614
content-md5:fQfP+cT7DbfFPJO0XBBaiw==
Content-Range:bytes 0-547613/547614
content-type:video/mp4
Date:Thu, 20 Oct 2016 18:39:48 GMT
Expires:Fri, 04 Nov 2016 18:39:48 GMT
Keep-Alive:timeout=7, max=50
last-modified:Wed, 21 Sep 2016 22:11:28 GMT
Server:Apache
Via:1.1 varnish
X-Cache:HIT
x-connection-hash:e7e3e634af01e0bd1d7712da13a16936
X-Content-Type-Options:nosniff
x-response-time:1992
X-Served-By:cache-tw-sea2-6-TWSEA2

Note how it says the file is 547614 bytes. The 8936222 byte file that I downloaded with wget plays just fine in chrome, the 5471614 byte file does not.

I assume that the 8 Mb file had a different X-served-by, but I don't know what it was.

Something is definitely borked with that asset; we are investigating. I'm not convinced it is the same issue initially reported in this bug.

I suspect it's the same initially reported issue, note my comment c#5: "Had to clear cache to get it to repro after closing browser. The log from ffmpeg/media is: [mov,mp4,m4a,3gp,3g2,mj2 @ 0x17d9df89de00] moov atom not found"

That's the same error showing up with the other clip; that said I can't repro an invalid asset or playback failure anymore on that clip -- even after clearing my cache like I was originally.

This is not a bug. Greedy advertisers give you that message when you have ads and third-party cookies blocked. Try it on the Twitter @NFL Sunday Night stream. The video played just fine when I gave them what they wanted. Try it you'll see."This media could not be played" is a totally different message. I only get it on some videos on Twitter. Makes me wonder if the tweeter fully understands HTML5 video.

Could we steer this discussion back to the questions I had earlier that can be worked on in the chrome side of things. There are several things we're tracking down in the twitter serving of assets, however there's still the outstanding question of Chrome not properly handling 200 responses to range requests. If that's not going to be addressed, I think this issue needs to be closed out as a "won't fix" on the chrome side.

drichards@ as stated in c#43, that's likely not the issue tracked by this bug. I believe the issue you want to discuss is covered under  issue 505707 .

A bit more info:

The "This browser does not support video playback" reported happens randomly: you may watch a video, scroll the element out of view, into view again and it will fail.

The interesting part is that Reload Frame on the element plays it back normally, if it helps.

Looks like the serving issue is fixed now, but the video still doesn't play in Chrome. Safari plays correctly and so the downloaded file is actually a video now.

hubbe@ can you take a look?

$ wget https://pbs.twimg.com/tweet_video/Cn0O_0xWYAAT_pj.mp4
$ md5sum Cn0O_0xWYAAT_pj.mp4 
76a7334bfa7e5f24158eccffc2dd807b  Cn0O_0xWYAAT_pj.mp4
$ ls -al Cn0O_0xWYAAT_pj.mp4 
-rw-r----- 1 dalecurtis eng 3442676 Jul 20 07:48 Cn0O_0xWYAAT_pj.mp4

The total bytes seen by Chrome looks correct too:
total_bytes	3442676

Whoops, I forgot the bad download issue was for https://twitter.com/google/status/778718619198894080 -- that one is fixed and plays correctly in Chrome. The one which seems to still have issues is the one in c#0:

https://twitter.com/WilliamChyr/status/755776968621039616/photo/1

Actually, seems fixed in M-56. hubbe@ is there any change we should merge? You mention something fixed in issue 656134 for a similar issue.

We made a few fixes Twitter-side to the way we are serving content from origin to work around this issue since it didn't seem like a fix was imminent. That said, we still believe that there is out-of-spec behavior with the way that range requests are handled by Chrome's video player, so it would be great if you do indeed have a fix!

What platform are you running on? Every tweet in that timeline renders fine
for me in Chrome 55.0.2883.75 (64-bit) on Mac OS.

Josh

Depending on how your Chromium was compiled, it might not support h264 playback, which would mean that "This browser doesn't support video playback" might be entirely correct. (for that video)

Twitter videos play in the browser (not in Flash) and us h.264, so you will need that decoder to play them.

I think this has been fixed for a while.
Re-open if it is not.

Still getting this for every twitter video:

Version 57.0.2987.110 (64-bit)
MacOS

Your chrome is more than a year old, update it.