We are having some technical issues with Viblast player and our streaming process. Our process work like this:
First, our web server will send a URL with token (A) to client.
- client's player will send URL A to token server, this server will check client IP address and token after that it responses with status code 302 (redirect) and a Streaming URL (B) in Location header.
- client's player continue to send URL B to streaming server.
This process works pretty OK in our player on android and IOS apps. But viblast player in browser can not get the streaming URL from redirect responses.
It will send URL A and receive the response from URL B instead of URL B.
Is this a problem with your player or browsers or our process ?
Redirect 302 is automatically handled by the browser, so the described process should works on the fly.
Can you confirm that your streams are CORS enabled?
My streams are CORS enabled. I think because redirect 302 is automatically handled by the browser so Viblast player can't get the streaming URL but only the response of it.
Thank you for your support.
We are having the same issues. We request a signed URL from our Server (A) and use a 302 to a signed cloudfront distribution to retrieve the m3u8 files. Instead of the Cloudfront distribution URL the viblast player attempts to use the original Server A URL to retrieve chunks.
example (not real data):
this returns a 302 to something like www.urlB.com/123.m3u8
the player then tries to get the chunked files using something like this:
it should instead be using this url www.urlB.com/chunklist_wDEF_bXYZ.m3u8
One of the previous comments describes exactly the player behaviour:
>I think because redirect 302 is automatically handled by the browser so Viblast player can't get the streaming URL but only the response of it.
Thus, Viblast Player will continue to fetch the resources from their original URLs, as redirects are handled by the user agent. In your case the user agent is the browser itself. You can read more about http code 302 here.
yes it does do the redirect I can see it in the console to the www.urlB.com address which gets the M3u8 file. However instead of using the new 302 URL it continues to use the old one.
I use this same server for iOS native video player and have no issues with it at all. it is just that the URL doesn't change to the 302 URL to request new chunks. It seems a little odd to have it all go to the wrong URL just to be redirected to the correct CF distribution after authentication has already occurred.
As I mentioned in the previous comment - the 302 response is handled by the internal implementation of the user-agent.
Native iOS applications have different user-agent and their implementation is different from the browser's implementation. That is the reason why you do not have issues with them.
To solve the issue, you have to configure your server to return 302 for all requests (including segments' requests).