xbmc
[question / request] Set ffmpegdirect proxy via #KODIPROP in strm / m3u files
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
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?
https://github.com/xbmc/inputstream.ffmpegdirect/pull/310
Will let you know once testbuilds are available, it can take a while to build.
Testbuilds: https://jenkins.kodi.tv/blue/organizations/jenkins/xbmc%2Finputstream.ffmpegdirect/detail/PR-310/1/artifacts
Testbuilds: https://jenkins.kodi.tv/blue/organizations/jenkins/xbmc%2Finputstream.ffmpegdirect/detail/PR-310/1/artifacts
Thanks, will test and let you know
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:[email protected]: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:[email protected]:8081" is sent as header value, e.g. httpproxy: http://username:[email protected]:8081
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.
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?
So it doesn’t use the proxy at all and just adds a header instead?
what’s wrong with using the kodiprops?
I think I see where the value get's treateed the wrong way. Let me update the PR and give you some new testbuilds.
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, 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
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?
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
Ffmpeg supports a http proxy. Adaptive issues a different library so I don’t know if it can support a proxy at all.
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.
https://jenkins.kodi.tv/blue/organizations/jenkins/xbmc%2Finputstream.ffmpegdirect/detail/PR-310/6/artifacts
I'm getting a blank page without download links
Apologies, here is the fixed link:
https://jenkins.kodi.tv/blue/organizations/jenkins/xbmc%2Finputstream.ffmpegdirect/detail/PR-310/5/artifacts
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.
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
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.
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?
It’s the addon that does those requests not kodi. Correct, it’s to figure out what type of stream it is.
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?
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.
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?