693 replies to this topic

[SpaceRat]

For base webif trancoding now works with authetinfication. Streaming is whitout.

Yepp.

This is due to Erik's new solution:
The WebInterface now sees the actual client's real (outside) IP rather than the local 127.0.0.1 or ::ffff:127.0.0.1 from the proxy and thus doesn't allow it to bypass auth ...
So the streamproxy just needs to use inteface lo for connecting ...

Reason:
Actually, the setting "stream auth" does not influence "stream auth" at all but means "no password on local logins" and as the usual streamproxies connect using interface lo, the result is as the option says ...

[Erik Slagter]

Streaming is done with the internal stream proxy in enigma, in OpenPLi and that one doesn't check auth.

[SpaceRat]

Streaming is done with the internal stream proxy in enigma, in OpenPLi and that one doesn't check auth.

Well, it doesn't work without auth anymore.
And it did work (without auth/disabled stream auth) using the Vu+-style proxies ...

[Erik Slagter]

Time for a little bit of explanation, now the new streamproxy is active.

 

Previously:

- on 8001 (tcp4) enigma (internal streaming proxy) would listen for streaming requests

- on 8002 (tcp4) the vuplus "live" transcoding proxy would be listening

- on 8003 (tcp4) the vuplus file transcoding proxy would be listening

 

If you would pass a "file" request to port 8002, the live transcoding proxy would set up a connection to port 8003 and pump all data yet another time around.

 

Now:

- on 8001 (tcp4) still the internal enigma proxy is listening, no change there

- on 8002 (tcp4/6) now the streamproxy is running, it accepts both live and file requests, streaming and transcoding,

- on 8003 (tcp4/6) exactly the same as on port 8002

 

If you do a "classic" request on 8002 (i.e. only a service in the uri), you'll get the transcoded version, if you supply a file, you will get the file. Same goes for port 8003. The default is transcoding, but you can set the default action to streaming as well.

 

Then there is the "new" request style where you specify exactly what you want, explicitly.

1. /livestream?service=service
2. /live?service=service
3. /filestream?file=file
4. /file?=file

1 passes the service as broadcast

2 transcodes the service

3 passes the file as recorded

4 transcodes the file

 

Number 4 is compatible with the way vuplus does it (the other ones they don't implement explicitly).

 

So, with this scheme you should have compatibility with the existing situation and also have explicit behaviour using just one http port.

 

The internal streaming (not transcoding) proxy does not check any authentication, it relies on authentication being checked by the web interface.

The vuplus proxies handle authentication in a "pass through" manner, when the webif says "401 unauthorized" it passes the reply down to the client, which would retry with the proper authentication, which the proxy also passes on.

The streamproxy does also check authentication by itself, for two reasons: a) for people that are stubborn and still make their stb available to the internet, this at least reliefs enigma from the authentication burden, when a hacker runs a brute force attack, it would not cripple the receiver, as only one connection per two seconds is allowed. And it allows to use define group membership that is required for a user to be allowed to stream (see -g).

 

Authentication in streamproxy is handled like this:

 

- if no webif auth is configured in enigma, do nothing special

- otherwise check if the client supplies credentials for this realm

- if not, reply "401 unauthorized" to the client

- when the client supplies the credentials, decode and check them

- if not sufficient, deny the request

- if sufficient, pass the request on to the web interface (allocation of channel, demux etc.)

 

I have some interesting features in mind for the near future, one of them being already available: if you supply a "startfrom=h:m:s" parameter to a file streaming/transcoding uri, it will skip until that point (current limitation that no timestamp wraparound may occur in the file, these are rare anyway).

Edited by Erik Slagter, 7 April 2014 - 17:19.

[SpaceRat]

Now:
- on 8001 (tcp4) still the internal enigma proxy is listening, no change there
- on 8002 (tcp4/6) now the streamproxy is running, it accepts both live and file requests, streaming and transcoding,
- on 8003 (tcp4/6) exactly the same as on port 8002

BTW: It would be quite nice if you could rewrite the socket creation for the 8001 proxy in a way that it behaves Dual Stack too.

It's the very last port for which I need a 6tunnel-style proxy to make it listen on IPv6 also.

The next point would be to enable Enigma2 to connect to IPv6 stream servers (In case it doesn't already), that means, it should be able to tune in to this service
#SERVICE 4097:0:0:0:0:0:0:0:0:0:http%3A//listen.technobase.fm/tunein-aacplus-pls:Technobase FM (AAC)
even if "listen.technobase.fm" was IPv6-only.

[Erik Slagter]

BTW: It would be quite nice if you could rewrite the socket creation for the 8001 proxy in a way that it behaves Dual Stack too.

I think it would be more productive to change the webif so it can connect to an arbitrary port instead of just 8001 and 8002. If it would support the "new style" requests e.g. on port port 8002, you could leave port 8001 alone altogether.

[SpaceRat]

I think it would be more productive to change the webif so it can connect to an arbitrary port instead of just 8001 and 8002. If it would support the "new style" requests e.g. on port port 8002, you could leave port 8001 alone altogether.

I could, but that would be an OpenPLi-only solution (And you probably even don't backport it to OpenPLi 3.0, do you)?

[Erik Slagter]

The package is in the 4 feed only BUT it has so little dependencies, that I think you can easily install it on a 3 receiver. There won't be much use in "backporting" it, because the 3 feed is not being built anymore.

 

Any image is free to offer the streamproxy, it only takes the bb file and go.

[delavega]

transcoding is gone with the latest build

[Erik Slagter]

Not true. It has been replaced.

[delavega]

i cant see it anymore on the list of plugins

 

do i have to install it manually?

[Robinson]

I understand TranscodingSetup plugin has been removed but it was just setup and not transcoding itself.

Am I right, Erik?

Now, as far as I understand, as a result of that, various bitrates or framerates can't be selected now.

Are there any plans to introduce them using a different solution?

[Erik Slagter]

The "plugin" has been removed some time ago, I guess over a month ago.

 

There is no need for the plugin. The plugin only enables or disables transcoding, which is totally useless, and the port it listens on, which is also irrelevant.

 

Unless you're talking about the plugin from vuplus itself, which is NOT in our feed, you run that on your own responsibility. Most of the settings available there will crash the encoding engine or the receiver.

 

So, no plugin for transcoding. I've reported that before.

[Erik Slagter]

Are there any plans to introduce them using a different solution?

Yes exactly.

[christophecvr]

I understand TranscodingSetup plugin has been removed but it was just setup and not transcoding itself.

Am I right, Erik?

Now, as far as I understand, as a result of that, various bitrates or framerates can't be selected now.

Are there any plans to introduce them using a different solution?

The old transcoding plugin indeed has been removed, The only thing it could was enabling or disabling the transcoding possibility.

 

Currently the transcoding is working with vu's own proxy. The encoder stil must be set. This is done by a file which runs at boot time and is located into /etc/init.d : transcoding-setup.sh

 

File contents :

# This configures transcoding
#
# *** NOTE *** *** NOTE *** *** NOTE ***
#
# Changing any other entry (see /proc/stb/encoder/?) than listed here
# will ultimatily crash the encoder and/or the complete receiver.
# Simply don't do it.
#
# Using any other value than listed here
# will ultimatily crash the encoder and/or the complete receiver.
# Simply don't do it.
#
# This leaves only a very few settings to be configured, not worth
# a GUI plugin, so change them here.
#
# This file is marked as "config file" so it won't get overwritten
# on a package update.

# h264 profile, possible options: baseline/main/high, default=baseline
PROFILE="baseline"
# h264 level, possible options: 3.1/3.2/4.0, default=3.1
LEVEL="3.1"
# display size, possible options: 480p/576p/720p, default=480p
SIZE="480p"
# bitrate, default=2 Mbps (default), if unsure use this or -1 for high quality
BITRATE="2000000"
# max amount of b frames in a GOP, possible options: 0/1/2, default=0
BFRAMES="0"
# Frame rate
#FRAMERATE="25000"

cd /proc/stb/encoder
echo -n "enable" > enable

for encoder in 0 1
do
	if [ -d $encoder ]
	then
		cd $encoder
		echo -n "$PROFILE" > profile
		echo -n "$LEVEL" > level
		echo -n "$SIZE" > display_format
		echo -n "$BITRATE" > bitrate
		echo -n "$BFRAMES" > gop_frameb
#		echo -n "$FRAMERATE" > framerate
		cd ..
	fi
done

Edited by christophecvr, 8 April 2014 - 12:51.

[WanWizard]

Afaik the VU proxy has been removed (yesterday?) by Erik's new solution.

 

The problem with the configuration plugin (and also with changing the values in this config file) is that most changes will cause the driver to crash. So we removed it to avoid complaints here (as we can not fix crashing drivers).

[Erik Slagter]

The problem with the configuration plugin (and also with changing the values in this config file) is that most changes will cause the driver to crash. So we removed it to avoid complaints here (as we can not fix crashing drivers).

We never had this version of the plugin in the feed, actually. So if users have them, they have installed it from "somewhere else".

 

Our version only allowed "enable/disable" and "port number" to be set.

Edited by Erik Slagter, 8 April 2014 - 13:04.

[christophecvr]

I was was a bit fast with my previous message in sending it . Here the rest of the message.

 

First as You can se There is a commented extra option FRAMERATE. You may use it. If You for example Do wan't to watch or record an HD channel with the best and full quality possible trough encoding. You're network is fast enough (whatch out with wireless as this is often not so stable. Cable connections are normally ok)

 

You may uncomment the lines

FRAMERATE="25000"

echo -n $FRAMERATE ...

 

set for example :

 

SIZE="720p"

FRAMERATE="60000"

 

Will give You the max quality possible trough transcoder.

Unfortunately it is stil not the max possible quality for an HD channel which now with modern program's. Does has 1080p (if you're box is capable) The vuduo2 is.

 

After having changed that it's best to reboot the box. You may ass well just perform the comment trough telnet after changes are made:

sh /etc/init.d/transcoding-setup.sh But with such a change it may cause a box crash. The best is to reboot the box.

Just this last one is one off the reasons using a plugin to change these values is not so ok since sometimes adapting encoder settings may cause a crash. But it is always ok if you reboot.

Edited by christophecvr, 8 April 2014 - 13:07.

[delavega]

streaming from 8002 doesnt work anymore but the other works.

[christophecvr]

streaming from 8002 doesnt work anymore but the other works.

First do a fresh flash off box. The change over off old trancoding to the new way off vu did caused some problems trough upgrade in some cases. To solve this just reflash without autobackup. Backup only the channel settings. Not the box settings.