UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36

Steps to reproduce the problem:
Attempt to copy video to WebGL texture when the video source is a cross-origin mp4, has the correct headers, but the initial response is a redirect.

What is the expected behavior?
No DOMException. The behavior should be the same regardless of whether or not the initial response is a redirect, and there should be no difference between using an MP4 with video.src= or an adaptive stream buffered via MSE.

What went wrong?
I'm working on an issue reported to JW Player that began in Chrome 70 with media delivered by JW Player for a VR/360 experience.

Content requests to content.jwplatform.com/videos/yKPSMwWc-2048.mp4 are redirected to videos-f.jwpsrv.com/content/conversions/Z3KUO9jB/videos/yKPSMwWc-25660671.mp4?token=0_5be20c0a_0x45c16ea3d6d7738edfa75ee2d44eb7142b6e11ad

Both the redirect response and the 200 response have "access-control-allow-origin: *" in the response headers. However, I only get the DOMException described in this ticket when setting video.src to the url that redirects, not the one that returns status 206. The crossorigin attribute is not required on the video element. The only difference I see between the two requests to the actual media asset is that Origin request header is null after a redirect. It is not when setting video.src to the asset.

Here's a page you can use to reproduce. I cobbled it together with mediocre WebGL skills. The video won't actually render to the canvas properly, but at least you can see each example - the first video/canvas throwing this exception when gl.texImage2D is called, and the other running along fine (with some warnings because I am bad at webgl).

"DOMException: Failed to execute 'texImage2D' on 'WebGLRenderingContext': The video element contains cross-origin data, and may not be loaded."

The impact to JW Player and our publishers is that they cannot setup a 360 video player using an mp4 source of a specific quality because the redirect breaks webGL. They are forced to use an adaptive stream or serve the content themselves.

Here's a working example using an adaptive source from the same origin with the same type of redirects on the stream manifest:
https://content.jwplatform.com/previews/Y0VTj4t8-ZapyjVIm

Did this work before? Yes 69

Does this work in other browsers? Yes

Chrome version: 70.0.3538.77  Channel: stable
OS Version: OS X 10.14.0
Flash Version: 

Found a similar issue from 2014 https://bugs.chromium.org/p/chromium/issues/detail?id=336618#c16