Use this streamproxy for VU+ / Openatv?

[jbleyel]

Hi Erik,
do you have any problems with that?
The original VU code of this is very old.

[eriksl]

No, in the contrary, I'd like it very much. For the simple reason we can have a uniform interface, easier for the Android/Apple apps developers.

[jbleyel]

Hi Erik,
I see only 2 open points.

1. changes will affect after reboot
2. authentication like the original VU code

Do you see any way to fix these 2 open points.
I can try to help coding but i don't have a build environment for debugging or testing.

[eriksl]

What do you mean by #1? Streamproxy has a file monitor on /etc/enigma2/settings and /etc/enigma2/streamproxy.conf. If either one is changed, streamproxy restarts.

I also don't understand #2? It's a veeeery long time ago that I saw the code of transtreamproxy.

[jbleyel]

Okay ..

1. DONE
2. I mean the OWF authentication and streaming authentication should be not mixed.
   In my case:
   I want streaming authentication enabled but no http authentication for the openwebif.
   OR i want streaming authentication via SID (sessionid) created by OWF.

[eriksl]

Does transtreamproxy understand this OWIF "sid"? I can't remember, but it may have been added.

2a This is interesting. I was going to try it, but the OWIF config doesn't allow me. When I set HTTP authentication to "no", the option for "Enable authentication for streaming" disappears. Streamproxy does parse the enigma2/settings file though and uses the setting config.OpenWebif.auth. Currently it does not know of the config.OpenWebif.auth_for_streaming option. I could add support for it.

2b Streamproxy uses the same http basic authentication realm as OWIF (if not changed in the meantime), so once the user has logged in with OWIF, he doesn't have to login to streamproxy (as long as the basic auth request is fulfilled, any proper browser will do this). So at the moment I don't see the requirement for passing a "session id"?

[jbleyel]

This sid is a something like a logon token and you don't need to check the auth logon if done this by openwebif already.
Schmmelreiter has also reintegrated your OWF changes.

[eriksl]

Reverted it. That is two hours of work I spent tonight for adapting streamproxy down the drain.

Ok, he broke it, he can keep the pieces. If you and anudanan want your problems fixed, have him do it.

There is more than OWIF and Schimmelreiter's version of streamproxy, which apparently can't be fixed to act sensibly.

The "token" ID assumes streaming is always initiated from OWIF and that is simply not true, nor will I limit streamproxy to be only operational in combination with OWIF.

[jbleyel]

Sorry, i'm not too deep in this hole thing.
All what i want is only one stable streaming / transcoding solution.
Too many different implementations will increase the complexity and this is not helpful.
We should work together and not against.

[eriksl]

A blunt revert seriously makes my motivation go away very quickly.

So now I reverted Schimmelreiter's revert on our OE as patch, so my work isn't lost.

Now it's up to Schimmelreiter for a proposal to either keep this situation or fix it in a constructive way.

[jbleyel]

That's exactly my concern. He has investigate a lot and spend many time. There is probably not THIS single solution but it should work on all distros with all possible use case at the end of the day.

[eriksl]

You seem to forget the time I spent...

Anyway, I am not going to spend much time on neither streamproxy nor any other streaming/transcoding solution.

This is functionality that should be in enigma itself (like the Xtrend patch does for their transcoding). Once that is done, all issues regarding authentication are gone and OWIF is no longer necessary to set up a service. In the ideal case, all images will start using that code and drop their own streaming/transcoding solutions. It should not be rocket science to make the interface compatible with all of them.

Now only find the time.

[eriksl]

I have some plans to make a.o. the "session cookie" authentication working (which never worked before between OWIF and streamproxy). That will also fix the other authentication issues we're now having between OWIF and streamproxy, I think. Most of the work I'll do myself, in streamproxy, but for OWIF I could do with some help, as I am not that familiar with either OWIF or Python.

• the modification to web.py -> allow all local access as a patch in OpenPLi OE will be removed
• the url web/stream will remain unmodified for DMM streamproxy and possibly transtreamproxy use
• another url, let's say web/stream2 will be added to OWIF, for streamproxy's purpose, it should be always allowed access from localhost and it will, additionally to the existing web/stream url, also supply the audio track that enigma has selected (from auto language selection or from storage in lamedb), so streamproxy can know which audio track to supply to the encoder. This will finally solve the problem of wrong audio tracks transcoded. Also this will disconnect authentication from the process of streaming.
• yet another url, let's say web/authenticate will serve as the authentication function from web/stream. This will allow streamproxy to implement multiple authentication schemes, associated with OWIF or independent.

I already add some code to OpenPLi enigma2 to facilitate this, a.o. I added an alternative "converter" called "streaming2" that implements the addition of the selected audio stream. I don't think the code is very good, it copies most of the streaming converter, I guess that could be done better.

For testing with OWIF I copied the "stream" controller+adapter in stream.py to stream2.py and make a few small changes there (call converter Stream2 instead of Stream and add the selected audio track to the output). I also made a dummy "authenticate" page in the "web" controller.

Altogether it works but it's ugly. I would be very grateful if one of you OWIF developers would implement the OWIF part in a proper way. Do you think that's possible?

[jbleyel]

Hi Erik,
what you mean with "session cookie"?
Please think about non browser usage.

I will check the OWF modifications and probably we don't need a second stream.py.
We can remove the stream2.py later on if stream.py works for you too.

[eriksl]

What I mean with "session cookie" is the construct that OWIF uses to pass it outside the browser, the "-sid:" thing. I am going to make sure that it will end up in OWIF no matter if streamproxy uses it's own authentication or not, by requesting the authentication page from OWIF with the "-sid" authentication present.

I was proposing a separate stream page for two reasons:

• apparently DMM's streamproxy uses it to implement authentication and that's why it needs to have obligatory authentication from OWIF. As I was told ;-) On the other hand streamproxy needs to be able to request the stream page without any authentication. I don't think we can mitigate that into one page.
• I am not sure if existing externals (like DMM's streamproxy and VU+ transtreamproxy) can handle the extra keyword+pid on the output line, I don't want to break them.

But if you think it can be done in another way, please don't hesitate.

[jbleyel]

Okay. understud.
Then we should start with the stream2.py to get it work and don't break anything else.