[question / request] Set ffmpegdirect proxy via #KODIPROP in strm / m3u files

[enerdude]

As my title indicates, is it possible to set this on a per stream basis otherwise one needs to change the setting everytime in addon settings.

I also to refer to an old discussion: https://forum.kodi.tv/showthread.php?tid=248440

[phunkyfish]

It should be possible to set this as a KODIPROP, although that use case is not currently supported. Let me take a look.

Can you test something on Kodi 22 if I figure out how to do it?

[phunkyfish]

https://github.com/xbmc/inputstream.ffmpegdirect/pull/310

Will let you know once testbuilds are available, it can take a while to build.

[phunkyfish]

Testbuilds: https://jenkins.kodi.tv/blue/organizations/jenkins/xbmc%2Finputstream.ffmpegdirect/detail/PR-310/1/artifacts

[enerdude]

Testbuilds: https://jenkins.kodi.tv/blue/organizations/jenkins/xbmc%2Finputstream.ffmpegdirect/detail/PR-310/1/artifacts

Thanks, will test and let you know

[enerdude]

Ok seems to work fine. What I tried:

EXTINF:-1,Example HLS stream

KODIPROP:inputstream=inputstream.ffmpegdirect

KODIPROP:mimetype=application/vnd.apple.mpegurl

KODIPROP:inputstream.ffmpegdirect.manifest_type=hls

KODIPROP:inputstream.ffmpegdirect.http_proxy_host=127.0.0.1

KODIPROP:inputstream.ffmpegdirect.http_proxy_port=8081

https://example.com/index.m3u8 using latest Kodi 22 nightly build using the above ffmpegdirect you compiled.

I have a question:

For Kodi to pass the proxy parameters to ffmpegdirect via the '|' pipe, I assume a new compile of Kodi is needed? e.g.

EXTINF:-1,Example HLS stream

https://example.com/index.m3u8|httpproxy=http://username:password@127.0.0.1:8081

This will also mean that e.g. inputstream.adaptive will also be compatible with a proxy when used in this way?

At the moment "httpproxy=http://username:password@127.0.0.1:8081" is sent as header value, e.g. httpproxy: http://username:password@127.0.0.1:8081

[phunkyfish]

Nope, it should work wth the | already. The ffmpeg property is called http_proxy and not httproxy.

This is only for ffmpegdirect. I'm not sure what adaptive supports.

[enerdude]

Nope, it should work wth the | already.

No it does not, tried it again. It adds a header to the request like this: http_proxy: http://127.0.0.1:8081 where 127.0.0.1:8081 is the proxy I specified

It is also clear from the abovementioned kodi forum thread that it is an issue since 2015 already and could be a security risk as proxy details is sent via headers to remote server.

Where should I open an issue for this?

[phunkyfish]

So it doesn’t use the proxy at all and just adds a header instead?

what’s wrong with using the kodiprops?

[phunkyfish]

I think I see where the value get's treateed the wrong way. Let me update the PR and give you some new testbuilds.

[phunkyfish]

Ok, can you try these testbuilds and see if it works via a |?

https://jenkins.kodi.tv/blue/organizations/jenkins/xbmc%2Finputstream.ffmpegdirect/detail/PR-310/3/artifacts

[enerdude]

Ok, can you try these testbuilds and see if it works via a |?

https://jenkins.kodi.tv/blue/organizations/jenkins/xbmc%2Finputstream.ffmpegdirect/detail/PR-310/3/artifacts

Ok should I test like this?

http://www.somewhere.com/playlist.m3u8|http_proxy=http://127.0.0.1:8080

[enerdude]

So it doesn’t use the proxy at all and just adds a header instead?

what’s wrong with using the kodiprops?

I guess nothing. I was also wondering...what is default behaviour if I put an entry in m3u playlist and don't specify input.ffmpegdirect in the #KODIPROP, will it use inputstream.adaptive by default? (I think this is my experience so far)

Also, I will have to open a issue for adaptive to also add proxy support?

[enerdude]

Ok should I test like this?

http://www.somewhere.com/playlist.m3u8|http_proxy=http://127.0.0.1:8080

I tested this way as well as changing it to httpproxy but both are still added as headers. Like I said I can use the KODIPROPS way, I just thought it would be a more uniform way to do via the "|", then adaptive can also get sent the proxy info without the need for seperate #KODIPROP

[phunkyfish]

Ffmpeg supports a http proxy. Adaptive issues a different library so I don’t know if it can support a proxy at all.

[phunkyfish]

Can you try one more test build:

https://jenkins.kodi.tv/blue/organizations/jenkins/xbmc%2Finputstream.ffmpegdirect/detail/PR-310/6/artifacts

This one simply add a log line to see if http_proxy is correctly set from a | symbol. When you test it see if there is a log line starting with XXX.

[enerdude]

https://jenkins.kodi.tv/blue/organizations/jenkins/xbmc%2Finputstream.ffmpegdirect/detail/PR-310/6/artifacts

I'm getting a blank page without download links

[phunkyfish]

Apologies, here is the fixed link:

https://jenkins.kodi.tv/blue/organizations/jenkins/xbmc%2Finputstream.ffmpegdirect/detail/PR-310/5/artifacts

[enerdude]

Ok so different results depending on #KODIPROPS:

With this:

EXTINF:-1,Video test (test Kodi 22 pipe)

KODIPROP:inputstream=inputstream.ffmpegdirect

KODIPROP:mimetype=application/vnd.apple.mpegurl

KODIPROP:inputstream.ffmpegdirect.manifest_type=hls

https://example.com/index.m3u8|http_proxy=http://127.0.0.1:8081&Referer=https://example.xyz

proxy works fine but when I stop the stream it makes a HEAD request to the manifest (https://example.com/index.m3u8) with the proxy set as a header (http_proxy: http://127.0.0.1:8081)

if I do the following:

EXTINF:-1,Video test (test Kodi 22 pipe)

KODIPROP:inputstream=inputstream.ffmpegdirect

https://example.com/index.m3u8|http_proxy=http://127.0.0.1:8081&Referer=https://example.xyz

it does not use the proxy at all, it puts the proxy as header and referer as header when doing manifest requests but no proxy header or referer header when doing video segment requests

If I do:

EXTINF:-1,Video test (test Kodi 22 pipe)

https://example.com/index.m3u8|http_proxy=http://127.0.0.1:8081&Referer=https://example.xyz

it does not use the proxy at all and puts proxy as header and referer as header for all requests (manifest and segments)

In this last case since I did not put an #KODIPROP I think it plays the hls stream using inputstream.adaptive because it does not understand the proxy but understands the referer. So normal behaviour of playing a link when nothing is mentioned should be adaptive by default if I'm correct.

[enerdude]

In between my analysis of the proxy setting I saw lots of "ping" requests e.g. https://jenkins.kodi.tv/sse-gateway/ping with a Referer of https://jenkins.kodi.tv/blue/organizations/jenkins/xbmc%2Finputstream.ffmpegdirect/detail/PR-310/5/artifacts/

I guess these background requests is normal for testing since Kodi is nightly build and inputstream.ffmpegdirect is also a test version

[phunkyfish]

Any log statement starting with XXX?

only the first example you gave is valid for ffmpegdirect. At a minimum those 3 props must be set for any ffmpegdirect call. I can look into why it moves into the header when stopping if you feel that’s important, OR you can just stick with KODIPROPs method of setting the proxy.

only this first example should prompt the log line starting with XXX.

[enerdude]

only the first example you gave is valid for ffmpegdirect. At a minimum those 3 props must be set for any ffmpegdirect call

Ok but why does Kodi usually do 2 HEAD requests when starting a stream, is it not to determine the mimetype and / or manifest type, I mean lots of people creating m3u files don't know what mimetype is? Or am I wrong?

[phunkyfish]

It’s the addon that does those requests not kodi. Correct, it’s to figure out what type of stream it is.

[enerdude]

It’s the addon that does those requests not kodi. Correct, it’s to figure out what type of stream it is.

Ok I meant addon. But why do I need 3 props instead of 1, if the HEAD statements can do the job - or am I missing something?

[phunkyfish]

There should be less requests if they are provided. If they are not I’d need to look into it. I’m not sure if http proxy affects this in any way.

[enerdude]

Of course there should be less requests if they are provided. I'm just trying to establish what is "normal" behaviour, meaning all people creating playlists might not provide mimetype but their url is still played correctly. So adding the proxy should not make a difference?