73 replies to this topic

[Dimitrij]

-support primarily galaxy4k lunix3-4k gbquad4k gbue4k

-and all arm box, e.g. vuuno4k vuuno4kse vusolo4k vuultimo4k vuduo4k vuduo4kse

-maybe not need hisilicon box

 

-support develop/8.x OpenPLi image

 

Attached Files

•  enigma2-plugin-systemplugins-advancedtranscodingsetup_openpli7_armv7ahf-vfp.ipk   61.18KB   31 downloads

[WanWizard]

What does that exactly do?

[Dimitrij]

Original OpenPLi transcoding not work for lunix3-4k gbquad4k gbue4k.

This same as TransCodingSetup

+

https://github.com/o...filestreamproxy

[WanWizard]

Wouldn't it then not be better to fix is, instead of work around it using a plugin?

 

You can't compare OE-A transcoding with PLi transcoding, it works completely different.

[Dimitrij]

 

Wouldn't it then not be better to fix is, instead of work around it using a plugin?

How to do it?

https://forums.openp...dpost&p=1259097

https://forums.openp...dpost&p=1259117

[WanWizard]

I've asked Erik to have a look, I think he has the most knowledge of Enigma streaming and transcoding.

 

If Dags needs to do something or supply something, I can pass that on, but I need to the point information.

[Dimitrij]

This conversation has been going on for many years.

I offer a simple alternative solution for individual users.

Edited by Dimitrij, 14 May 2022 - 18:41.

[Erik Slagter]

Well the starting point is that nobody needs a plugin to use transcoding, not on VU+ not on any other manufacturers' STB. The reason we ship a plugin is that the Open Web Interface "needs" it, it depends on certain values being in the configuration to determine whether the receiver can transcoding and what port (...) to use. Some us don't use transcoding via the OWIF (like me), in that case you can leave out the plugin.

 

So the question is (again), what does the plugin do exactly?

 

If it really does some hardware configuration that's now not in streamproxy or enigma, it should be added there. I can do that, no problem. I have always tried to have both up to date for all supported STBes, but I lack information to do so completely. Various manufacturers need different ways to start transcoding and they're not telling me...

[Dimitrij]

https://github.com/o...nstreamproxy.bb

https://github.com/o...cipes-transcode

[WanWizard]

That looks like a copy of the original VU+ transtreamproxy, which would suggest that Gigablue uses VU+ compatible transcoding?

[Dimitrij]

That looks like a copy of the original VU+ transtreamproxy, which would suggest that Gigablue uses VU+ compatible transcoding?

Gigablue/VU+/Lunix3-K in oe-alliance use same "git://github.com/oe-mirrors/filestreamproxy.git;protocol=http;branch=transtreamproxy"

[WanWizard]

Since we support VU+ in our code, it shouldn't be too difficult to extend that to Gigablue and Qviart (and then probably Xsarius too).

[Dimitrij]

They've already been added, but it doesn't work.

https://github.com/e...c/stbtraits.cpp

[Erik Slagter]

This is not about a plugin, but about a mechanism (to set up the transcoder and stream the data to the user application). The plugin (in any form) only does useless stuff.

 

Okay, so let me explain the whole story - again.

 

VU+ uses a mechanism that is 1:1 copied from Broadcom. It's a bit dumb because it needs video data to be pumped around like this:

 

tuner+demux -> encoder -> user application (socket)

 

Every -> is a copy process.

 

Also VU+/Broadcom require a strange setup where the video data is fed into the encoder, but at the same time (!) another thread needs to be spawned and perform a specific blocking operating system call. If you don't do that or do it too soon or too late, transcoding won't start, there will be no data from the encoder. Of course this isn't documented anywhere and I had to find out using reverse engineering. From the way the original (VU+) transtreamproxy source, this isn't evident.

 

Anyway, we have had it sort of working now for some time.

 

We have been using the "transtreamproxy" from VU+ for some time, but it's horrendously badly written and will only work (unmodified) on VU+ receivers. That's where I created the streamproxy that has a compatibility layer for quite a lot of settopboxes. It also even works on "Xtrend" transcoding receivers.

 

Then there is (or I should say "was") Xtrend that presented a different, more elegant interface to transcoding. It's possible to link a pair of tuner+demux directly to the encoder. The only thing you need to do is fetch data from the encoder and send it to the user application (socket). No useless data copying or weird dances to get the transcoding started. As it was so simple, existing enigma code could be used to send the data from the encoder to the user, there are already functions for that. That's why it was implemented inside Enigma itself. Having the transcoding inside Enigma has quite a bit of advantages, one of them being that Enigma knows everything about a service, like available sound pids, the corresponding languages and what language is preferred by the user. Also authentication is simple also including OWIF access, as opposed to using an external program like streamproxy or transtreamproxy, where it's a nightmare.

 

So adding VU+/Broadcom transcoding support to Enigma is the way to go.

 

I have been thinking for years and years how to achieve that and something like 2 years ago I started the implementation. It needs quite a bit changes in Enigma because the VU+ encoder must be addressed very specifically, it's not as simple as the "Xtrend" encoder. Also there needs to be an extra thread to copy the data to the encoder, which is not required for "Xtrend" transcoding. Synchronising this thread to other Enigma code appeared to be "difficult" as starting a "copy data" thread is normally a "fire and forget" action in Enigma, but in this case Enigma must act on certain conditions presented in the "copy data" thread.

 

The result is that VU+ transcoding now more or less works, but it has impact on normal recordings, because Enigma uses the same mechanism there. It's not easy to separate the two (otherwise I would have done it for sure). After quite some debugging and changes I think the normal recording is now more or less stable again, but it seems occasionaly there are still problems on some MIPS receivers (not on ARM, which is strange...)

 

So the idea is to stop with streamproxy altogether and to add support for all the STB's in Enigma. I have been busy with that for some time, specifically, to start with, GigaBlue. I have spent a lot of time to get it working, but I simply can't. There is no information at all on how GigaBlue transcoding differs from how VU+ and Broadcom do it.

 

So if anywone wants to have GigaBlue transcoding support, I am all for it. It will be in Enigma, not in streamproxy or even transtreamproxy and someone will tell me how to get it working.

 

Until then, there is nothing I can do.

[WanWizard]

Given the fact that the OE copy of the transstreamproxy seem to work on Gigablue / Xsarius / Qviart broadcoms,. and the source of that proxy is available, it should be possible to find the differences?

[arn354]

gb-transcoding for BCM is identical to vu-transcoding. Simply handle them as vu.

[WanWizard]

That's what I thought...

[Dimitrij]

 

So the idea is to stop with streamproxy altogether and to add support for all the STB's in Enigma. I have been busy with that for some time, specifically, to start with, GigaBlue. I have spent a lot of time to get it working, but I simply can't. There is no information at all on how GigaBlue transcoding differs from how VU+ and Broadcom do it.

So what's the problem?

The era of the BCM t is over.

The end user just wants to buy a receiver, install the openPli image and everything works.

In fact, everything is not оk, no CI+ no trancoding and etc.. etc...

What do we want to achieve in the end?

 

P.S.Erik, I can understand you.

I will never grow up to your level of knowledge.

Perfect/flawless code is beauty.

But...

Edited by Dimitrij, 20 May 2022 - 21:23.

[Erik Slagter]

Given the fact that the OE copy of the transstreamproxy seem to work on Gigablue / Xsarius / Qviart broadcoms,. and the source of that proxy is available, it should be possible to find the differences?

 

Believe me I tried. I spent about 100 hours on it and I can't lay my finger on it. I think that is enough.

 

So what we need is someone who is willing to spend even more time on it or just knows what the actual interface is. It seems to me that GB could be giving us that information.

 

What we also need is a buddy that can help brainstorm on how to implement this properly in Enigma. Instead of just me spending lot of time and then the only feedback being "you broke everything".

[Erik Slagter]

BTW I am not against providing the VU+ transtreamproxy in a package for those who can't get it working with our own tools (streamproxy and enigma). But there will be no support at all and it should be clearly marked as such (and also that it's not a plugin).