Unable to reproduce the issue on windows 10 using chrome reported version -69.0.3497.81,stable-69.0.3497.92 & canary-71.0.3550.0 as per steps in C#0.Once we run the app, please let us know where to check protocols for the video tags.

Please find the attached screencast for reference & let us know if we miss any steps to reproduce the issue from our end.
Thanks.!

Deleted: 881567-win.mp4 11.5 MB

	881567-win.mp4 11.5 MB View Download

First: thank you for taking the time to try to recreate the issue. In your video, in the network tab of dev tools, I do not see you showing the protocol column which would indicate h2 or spdy.  I just re-verified the problem with 69.0.3497.92.  The server in question: https://ltlcache-learntolive.netdna-ssl.com/ does not support SPDY so they are blaming the browser for some situations where the video hangs on repeat viewing.  If you load the same video directly (not using the <video> element) it will load and show the h2 protocol correctly in the network tab.  This only happens with the <video> element which is why I included the w3schools link.  This is a weird one and I appreciate your willingness to help me get it sorted.  It's very possible it has nothing to do with the video hanging but I at least need to chase down whether this is truly a bug or just a misreporting by dev tools.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Oh I should say you add the protocols by right clicking the columns at the top of the list and there will be a list of options.  Just add a check mark next to 'protocol' which should be the third item down.

Thanks again!

I'm still able to recreate this. Can someone verify?  I believe this is still potentially a bug.

I would love a work around if there is one that forces the html <video> element to use h2 or even h1.  This is currently preventing us from going all SSL (and getting green lock and allowing PWA install).

Can confirm we are having the same problem when using a different cloud provider.  Video hangs and assets won't download in some browsers, console shows ERR_SPDY_PROTOCOL_ERROR even though the CDN fully supports H2. For example https://difl3vniyrx1b.cloudfront.net/lesson-content/DEP_L3_S23_VID.mp4

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/60d5b1ea70d1fd7a8acd214c9b0a7661b20ee9e4

commit 60d5b1ea70d1fd7a8acd214c9b0a7661b20ee9e4
Author: Joey Arhar <jarhar@chromium.org>
Date: Mon Oct 08 19:08:35 2018

[DevTools] Replace "spdy" initiators with "h2"

SPDY in Chrome simply refers to HTTP/2 now:
https://groups.google.com/a/chromium.org/forum/#!topic/net-dev/iwUnvL0Ul6Q

Bug:  704146 ,  881567 
Change-Id: Ida5871c3a738755325413b3dd042af5d442497c1
Reviewed-on: https://chromium-review.googlesource.com/c/1268959
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Joey Arhar <jarhar@chromium.org>
Cr-Commit-Position: refs/heads/master@{#597641}
[modify] https://crrev.com/60d5b1ea70d1fd7a8acd214c9b0a7661b20ee9e4/content/browser/devtools/protocol/network_handler.cc
[modify] https://crrev.com/60d5b1ea70d1fd7a8acd214c9b0a7661b20ee9e4/third_party/blink/renderer/core/inspector/inspector_network_agent.cc

Chrome doesn't support SPDY anymore, only H2: https://groups.google.com/a/chromium.org/forum/#!topic/net-dev/iwUnvL0Ul6Q
Anything that was showing "spdy" in DevTools was actually loaded using h2. I just changed the labeling to always show "h2" instead of "spdy."

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4ac0119e24046a79368f4a347fa637ff8a0db767

commit 4ac0119e24046a79368f4a347fa637ff8a0db767
Author: Joey Arhar <jarhar@chromium.org>
Date: Wed Oct 10 19:17:41 2018

[DevTools] Remove duplicate ALPN information from blink::ResourceLoadInfo

npn_negotiated_protocol in ResourceLoadInfo is only used by DevTools and
doesn't get set when raw headers are unavailable, such as cross origin
requests. This resulted in a lack of information for cross origin
requests and subsequently being wrongly labeled as "spdy."
alpn_negotiated_protocol in blink::ResourceResponse always gets set, so
it should be used instead of the one in ResourceLoadInfo.

Bug:  704146 ,  881567 
Change-Id: Iedd33834bc5e0c22ff3bf620307b1538563d9141
Reviewed-on: https://chromium-review.googlesource.com/c/1272596
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Joey Arhar <jarhar@chromium.org>
Cr-Commit-Position: refs/heads/master@{#598441}
[modify] https://crrev.com/4ac0119e24046a79368f4a347fa637ff8a0db767/content/renderer/loader/web_url_loader_impl.cc
[modify] https://crrev.com/4ac0119e24046a79368f4a347fa637ff8a0db767/third_party/blink/renderer/core/inspector/inspector_network_agent.cc
[modify] https://crrev.com/4ac0119e24046a79368f4a347fa637ff8a0db767/third_party/blink/renderer/platform/exported/web_http_load_info.cc
[modify] https://crrev.com/4ac0119e24046a79368f4a347fa637ff8a0db767/third_party/blink/renderer/platform/loader/fetch/resource_load_info.h

Is it possible it was being reported correctly?  When our video hangs on our test client it is reporting "ERR_SPDY_PROTOCOL_ERROR" Could the error be incorrect as well or is it possibly really using SPDY only on the video element somehow?

Also it seems odd to be returning H2 for WasFetchedViaSPDY().  Is that function incorrectly named?

Yes, WasFetchedViaSPDY() is a misnomer. Based on the comment rch@ made in the forum post I linked to in my last comment, everything that says SPDY in chrome is actually H2. I would guess that when H2 was made it was very similar to SPDY so a lot of SPDY code was reused without any of the naming being changed.

+rch@ +mmenke@ Is there any plan to rename error messages or code from SPDY to H2 so people stop getting confused? Do you think that would be a good idea?