httpHeaders are not set correctly

[Bonfra04]

The VideoPlayerController.network constructor accepts an httpHeaders paramether; Setting, for example, the User-Agent to something specific is not reflected in the HTTP request made by the controller.

As an example, invoking the constructor like this:

VideoPlayerController.networkUrl(uri,
    httpHeaders: {"User-Agent": "FOOBAR"}
);

results anyway in an HTTP call with User-Agent set to NSPlayer/12.00.19041.5007 WMFSDK/12.00.19041.5007

[jakky1]

I tried to support http headers.
Because currently I am not sure whether it can work normally,
so I implement it in a new branch on github.

Please try it with the following dependency:

 dependencies:   
     video_player_win:
       git:
         url: https://github.com/jakky1/video_player_win.git
         ref: support_http_headers

If http headers not set, the package works in the same way as before.
If http headers set, it works in a new way.

Known issues:

1. If http headers set, .m3u8 url cannot be played.
2. If http headers really sent to http server ??
3. If http headers set, can network video be played normally every time ?? ( HELP ! test WANTED )
4. If http headers set, can network video be played behind http proxy ?? ( HELP ! test WANTED )

Please let me know if it works well :)

[Bonfra04]

Hi, thanks a lot. I can confirm that the headers are correctly set.

About the known issues you highlighted:

1. Do you think this will be a possibility or does Media Foundation impose some limits about custom headers with m3u8 files?
2. For an easy test you can try using a URL generated by https://webhook.site/ in the network constructor. It will log every request along with the headers; I can confirm that this verification method shows all the headers I'm setting.
3. You know any way I can help with this? I tried using a system proxy but the traffic doesn't seem to pass through it.

Thanks again for the quick intervention :)

[jakky1]

Do you think this will be a possibility or does Media Foundation impose some limits about custom headers with m3u8 files?

in normal way, IMFMediaEngineEx connects to the http server by itself, so it can read the header returned by the http server, including the header Content-Type.
However, in this way, there is no way to add headers.

So I pass a IMFByteStream ( class MyHttpByteStream in package ) into IMFMediaEngineEx and implement the connect / read / seek methods.
In this way I can connect server by myself, including adding headers,
but cannot tell IMFMediaEngineEx what the Content-Type is.
I think the IMFMediaEngineEx always parse the file as media file in this case, so it cannot play m3u8.

You know any way I can help with this? I tried using a system proxy but the traffic doesn't seem to pass through it.

You can look into my_http_bytestream.cpp in package.
And search the following code:

    hSession = WinHttpOpen(L"A WinHTTP Example Program/1.0",
        WINHTTP_ACCESS_TYPE_AUTOMATIC_PROXY,
        WINHTTP_NO_PROXY_NAME,
        WINHTTP_NO_PROXY_BYPASS, 0);

According to WinHttpOpen readme,
I thought WINHTTP_ACCESS_TYPE_AUTOMATIC_PROXY should auto read system proxy settings and handle all of this...
If you are willing to try to solve this problem, you can start here.

You can read the definition about WINHTTP_ACCESS_TYPE_AUTOMATIC_PROXY and WINHTTP_ACCESS_TYPE_AUTOMATIC_PROXY in the link.

If the proxy is secured, WINHTTP_FLAG_SECURE_DEFAULTS maybe helps.

[njzimpli]

fyi: work fine on ref: support_http_headers.

[jakky1]

fyi: work fine on ref: support_http_headers.

@njzimpli ,
Thanks for the feedback.
Are you using PC in intranet of company, and pass through company proxy ?
Or connect to any public proxy on the internet ?
Or no proxy ?

I will release the solution if anyone report it works with company proxy in intranet.

I also hope that when anyone sees this message, they can help test it out. Thanks :)

[Bonfra04]

Hi, sorry for the late response. I had to completely reset my OS and a lot of other things.

So I was able to create a stable testing environment using a docker container to setup a proxy:
docker run -d --name tinyproxy -p 8888:8888 vimagick/tinyproxy
this way if I set the system proxy to the host where the proxy is running (I used another laptop) all the traffic goes trough there.

I can confirm that this way video playback works perfectly even using a proxy. (So yea in the end it was my machine configured in some buggy way, after the complete rest everything works as you expected)

I tried many other freely available proxy online but none of them is configured to allow for direct-streaming of requests - they all wait for the full response to arrive before forwarding it to the client so won't work even on a normal browser or any other application trying to play an mp4 from the internet