(2014-11-18, 11:02)wwortel Wrote: (2014-11-18, 01:17)dlake02 Wrote: So the .ts parts are pulled directly even though the processing of the main part of the app uses a proxy. Until I can find a way of using a proxy for the XBMC Player (the thing that actually renders the video), you cannot run the streams through a proxy.
Thanks for your comments. A stream from BBC's archive works though in XBMC and does go via the proxy. So in your opinion this behaviour is specific to .ts stream segments.
Will give it a try to enforce the proxy outside of xbmc.
The answer is "it depends."
For streams from the archive: these are geolocked for the metadata (i.e. to get to the source of the data) but the Beeb actually globally distribute on SOME of their CDN providers. So, once you have been able to access the metadata, you will probably be served from a Content Cache local to your actual location. This is true for both RTMP and HTTP (m3u8).
For live streams, again, the metadata is geolocked, so you will need to access this through an HTTP proxy as before. But the RTMP and HTTP streams are ALSO geo-locked. So, RTMP you will need to access through a SOCKS proxy or VPN; HTTP likewise. An m3u8 file consists of a manifext and then a sucession of .ts files pulled over HTTP.
The problem with both VPN and proxies is that it adds latency, sometimes to the point where streams break down. So, for ondemand, it is best to use an HTTP proxy for the metadata and then stream without a VPN or proxy from a local CDN (remember, we never designed the Internet to carry any of this type of traffic end-to-end !). For live streams, we have no choice but to go to the source.
Now some of the DNS spoofing systems reply with themselves as the address, so traffic is routed via the DNS spoof and this does work with the live streams.
The player and the Python logic in the apps are two totally separate items. What you set as a proxy in httpget is not connected in any way to the player code.