CORS failure when loading redirected MKV URLs that work with native HTML5 video / Shaka Player

[iptvsmartws]

Title

CORS failure when loading redirected MKV URLs that work with native HTML5 video / Shaka Player

Description

Hello,

I am using Libmedia AVPlayer in a browser-based video player to play remote MKV files.

Some MKV URLs work correctly, including multi-audio playback, seeking, and AC-3 decoding. However, other URLs fail because Libmedia loads the media through fetch/XHR with byte-range requests, and the remote server does not return the required CORS headers.

The same media URL works in my existing application when using native HTML5 playback or Shaka Player.

Environment

• Page origin: mywebsite
• Browser: Chromium / Microsoft Edge
• Target platform: browser and LG webOS Chromium
• Protocol: HTTP page loading an HTTP media URL, so this is not mixed-content blocking
• Player: Libmedia AVPlayer browser build
• Media container: MKV
• Audio codec: AC-3
• Requests use HTTP byte ranges

My AVPlayer bundle contains a small local patch for clearing the audio queue when switching audio tracks. The network loader was not intentionally modified.

Media URL behavior

The original URL has this structure:

http://example-provider.test/movie/<username>/<password>/<media-id>.mkv

The credentials and actual URL are intentionally redacted.

The server responds with a redirect similar to:

HTTP 302
Location: http://<origin-ip>:8080/movie/...

The final response does not include:

Access-Control-Allow-Origin: mywebsite

It may also fail to correctly answer the CORS preflight/range request.

Steps to reproduce

1. Create an AVPlayer instance in a page hosted on a different origin.
2. Load an MKV URL that redirects to another hostname or raw IP address.
3. The AVPlayer network loader sends requests similar to:

GET /movie/... HTTP/1.1
Range: bytes=0-
Origin: mywebsite

4. The browser blocks access to the response because the final server does not provide CORS headers.

Actual behavior

The request is blocked by the browser:

Access to fetch at '<redacted-media-url>' from origin
'mywebsite' has been blocked by CORS policy:
No 'Access-Control-Allow-Origin' header is present on the requested resource.

Depending on the URL, AVPlayer may initialize and detect the MKV, but later range requests or seek requests fail.

There may also be this warning:

can not support mse for codec: audio/mp4; codecs="ac-3"

However, this warning appears unrelated to the CORS problem because the working URLs can still use the Libmedia decoding pipeline.

A CORS error related to static.cloudflareinsights.com/beacon.min.js may also appear in the console, but that is Cloudflare Analytics and is unrelated to the media request.

Expected behavior

I would like to know the recommended Libmedia solution for loading this type of source, especially when:

• The URL redirects to another hostname or raw IP.
• The media server supports byte-range requests.
• The media server does not provide CORS headers.
• The request must remain direct from the browser so that the media provider sees the real client IP.
• A server-side proxy is not acceptable because it changes the source IP and transfers all video traffic through the proxy.

Questions

1. Does Libmedia support a custom network loader or request callback that can be supplied to AVPlayer?
2. Can AVPlayer reuse an existing native or Shaka networking layer?
3. Is there a supported way to configure redirect handling, request headers, credentials, or range requests?
4. Can Libmedia use a browser-native media transport while keeping Libmedia only for MKV demuxing and unsupported audio decoding?
5. If the final media server does not provide CORS headers, can you confirm that there is no client-side Libmedia solution and that the server must enable CORS or a proxy must be used?

I understand that mode: "no-cors" would return an opaque response, so Libmedia would probably be unable to read and demux the response bytes.

Proxy tests

I tested a Cloudflare Worker that adds CORS headers and forwards the Range header.

The browser-to-Worker CORS request succeeds, but the provider redirects the request to a raw IP address. Cloudflare then rejects that upstream request with error 1003.

I also tested simple Node.js and PHP streaming proxies. They can work in some environments, but:

• The provider sees the proxy IP instead of the real client IP.
• All media bandwidth passes through the proxy.
• It adds infrastructure cost and load.
• It is therefore not the desired production solution.

Any guidance about the intended Libmedia architecture for this case would be appreciated.