Jump to content

Erik Slagter

Member Since 3 Oct 2008
Offline Last Active Yesterday, 19:53

#996241 streamproxy and choosing audio streams of movies

Posted by Erik Slagter on 8 January 2019 - 20:33

No, the hardware can only transcode one audio track. Otherwise I'd definitely have it send all audio channels.


But as you can see, as friend Schimmelreiter is the king of the OWIF, it's not going to happen. Because OpenPLi, as usual, does it "all wrong". I am sorry.

#996221 streamproxy and authentication

Posted by Erik Slagter on 8 January 2019 - 20:14

I have resolved it this way:


- added a patch to our OE that reverts the revert from Schimmelreiter; for our OWIF package, there is no need to have authentication on the web/stream page and we don't use nor care about legacy implementations.

- kept the changes in streamproxy so it no longer tries to authenticate to that page


Problem solved.


You'll need to both the adapted OWIF and the streamproxy for this to work, from our develop branch. It's not going into the release. But I think there will be a 7.1 pretty soon and that will have the changes.


I am not going to discuss with Schimmelreiter, because he is always "right", there is simply no sense in discussion. I am going to spare me the time plus irritation and have myself a nice fun night.

#991265 Duo4K resolution problem

Posted by Erik Slagter on 1 January 2019 - 13:02

If I was you, I go a shop and purchase a new HDMI cable compatible with 2.0a (latest HDMI version) and test it.

Since you have now a 4K box you perhaps use a too old version HDMI cable and it gives trouble to the box so the box decrease the resolution to match the cable specification that you use.

The only difference between HDMI cables is the maximum (reliable!) bandwidth supported. The HDMI interface cannot detect what HDMI cable is attached. This also means that if you have a very cheap and very old HDMI cable, it might be able to carry UHD@60, if it's really short. If it's too long, you'll start to see pixelation or unable to sync. EDID is negotiated over a very slow I2C line (100 kHz) which will always work.

#989917 streamproxy and authentication

Posted by Erik Slagter on 30 December 2018 - 12:31

There are basically two kinds of transcoding interface, the one that originally showed up in Xtrend receivers, but now also can be found in Mut@nt and Zgemma receivers, which Wanwizard calls here "xtrend" style, but I'd rather call it "enigma" style, because the complete interface is inside enigma itself, with a patch from the Xtrend developers at the time. The other interface was first found in VU+ receivers, which WanWizard therefor calls "vu+"  style, but which I call "broadcom" style, because apparently it's supplied this way by Broadcom in their SDK. All other vendors are using this interface.


For the "enigma" style interface you don't need an external interface, the handling of fetching the stream from the demux and pushing it into the encoder is done inside the driver and enigma only needs to fetch the encoded stream from the encoder. For the "broadcom" style, we need to have enigma tune to the service, set up the demux, fetch the raw data from there, push it into the encoder and then fetch it from the encoder's output. This in theory could have been integrated into enigma itself, but I am not enough familiar with enigma to do that, so I made the code into a separate binary. If there are volunteers, please step forward, it would be appreciated.


The machines marked as "broadcom" style transcoding have the streamproxy installed and started automatically. The other transcoding capable machines have the streamproxy in the feed, so the users can install it themselves if they want to. The streamproxy does support "enigma" style machine as well, but not natively, it just forwards the session to enigma. The reason why this may be useful is because some smartphone apps do support the "broadcom" style interface and not always the "enigma" style transcoding. Also, it supplies a universal interface to all transcoding capable machines.


Without using streamproxy, "enigma" style machines support transcoding by adding a few parameters to a normal streaming request, on port 8001.


Streamproxy by default (configurable...) listens on port 8002 and 8003, where by default, requests are handled as transcoding requests. Using both port 8002 and 8003 is a historic compatibility thing, where the original VU+ "transtreamproxy" required live trancoding requests to be on 8002 and file transcoding requests on 8003. Streamproxy does not enforce that, both ports act the same way.


In compatibility mode (usually used), only a serviceref is passed and depending on the configuration, that service is transcoded (service can be live or file). There is also a native mode where, on any of all configured ports, you can explicitly request for streaming, transcoding, live or file. This is the preferred interface, but nobody is using it.


So, now you know everything.

#985185 Offline decoding questions

Posted by Erik Slagter on 21 December 2018 - 11:22

Oscam cannot know if a request for an ECM is for recording or offline decoding.


The offline decoding delay is measured in milliseconds, so a value of 10000 would be a good starting point.


I think you have a flaw in your reasoning, you think that the decrypting is done by the softcam. That is not the case.


This is how DVB decryption works:

- provider sends (encrypted) EMM packets to subscriber cards to specify what programs should be decrypted and during which period

- provider scrambles (note the use of this word instead of "encrypts") the streams using a control word (actually 2 of them, but let's keep it simple here)

- provider encrypts the control word and probably adds some metadata to it, into an ECM

- provider sends the ECM frequently, about once a second, that's why it takes some time after zapping before you actually have a picture

- enigma builds and sends a caPMT structure from the PMT to inform the CI and/or softcam of the new service + ECM pid(s)

- with the caPMT the CI can start descrambling the service, enigma doesn't do anything to it, it just instructs the SoC to pass the CI output to the demuxer -> audio/video decoders

- with the caPMT the softcam can start fetching the ECMs, hand them to the subscriber card, the card returns a control word and the control word is sent to the descrambler (in the demuxer); also enigma does nothing here

- both a CI and a descrambler in the demuxer (from SoC) will only descramble packets that have one of the "scrambled" bits active. So that's no problem.

- the problem is that for this to work, the current control word always needs to be in the descrambler, because the softcam can never know which parts of the file are still scrambled and even it would, there would be too much delay having the ECM converted into a control words and setup the descrambler.


So, offline decryption of a file that only has parts still scrambled, will only ever work if all ECMs present in the file are handed to the softcam and resolved into control words.


I believe I explained that earlier on, but apparently not good enough.

#980513 Openpli 7 error trying to install autobouquetsmaker

Posted by Erik Slagter on 12 December 2018 - 17:07

Apparently. It seems to be fixed now after some work by WanWizard and me but we're not exactly sure how.

#978609 ServiceInfo Extended PID info

Posted by Erik Slagter on 10 December 2018 - 09:25

I do like it. Why does the list need to be short? I don't see the need for it to be called with another colour key. Most people aren't using this screen anyway, because they don't understand it anyway.

#978221 New STB 4k support

Posted by Erik Slagter on 9 December 2018 - 11:36

The final word on FCC. I will not implement it because I have too little information on how it works and should be implemented (properly, not reverse engineered from the VU+ image). When VU+ (or someone else with thorough knowledge on this subject) can inform me, I will implement it.


I think if the hardware supports a certain feature, we should make it available to the end user, whether we like the feature or not.


FYI, hd51 (from Mutant, Ax, whatever) have the bcm7251 SoC, the Gigablue and the VU+Uno(SE) have bcm7252 and the Ultimo4k has bcm7444. That is interesting, because the 7251 is a "budget" SoC, the 7252 is "mainline" and 7244 is "high end". That has implications. There are certain things a 7251 simply can't do, you should consider that.

#974877 OpenPLi-compatible receiver with FBC-tuner and SCART?

Posted by Erik Slagter on 1 December 2018 - 11:45

At least SCART can output component video (RGB), cinch is composite which is even worse (far worse) quality.

#970389 OpenPli 7 news and information

Posted by Erik Slagter on 24 November 2018 - 10:59

Do you mean Lcd4Linux?


I will consider it, but it won't be for the upcoming release, because I always need to some adjustments to get it working in OpenPLi.

#966165 Gstreamer plugin VP9 decoder not available!

Posted by Erik Slagter on 16 November 2018 - 14:48

I have sent a request for VP9 support on capable machines. Now we wait.

#964993 Gstreamer plugin VP9 decoder not available!

Posted by Erik Slagter on 14 November 2018 - 19:42

Ok, fair point there. Mostly it works quickest if we supply a patch.


BTW I very much doubt if all of these codecs are actually supported. It looks like ATV just added them all without checking. But we could try to get VP9 added for the UHD models after the solo4k (the solo4k doesn't have VP9 support).

#961137 serviceapp - gstplayer and exteplayer3

Posted by Erik Slagter on 7 November 2018 - 18:07

Who is talking about sumo?

Sumo is already an old branch from the OE core.

So apparently you did.

I'm talking about pyro and the develop branch!
That can not be so difficult to understand, right?

Your words...

No matter ...
I am out

Yeah, good plan, go waste someone else's time with your nonsense and hostility.

#943286 Unicable / simultaneous recordings

Posted by Erik Slagter on 5 October 2018 - 08:39

For me this should be escalated to the driver manufacturer and they should fix it at the driver level (too). Because from what I read here it is supposed to work as ethernet (CSMA-CD) and this should be done at the driver level, since higher you cannot detect collisions.

No it's not (completely) supposed to work like this. Ethernet has always a at least one layer above it for error detection and correction. The collision detection is only there to prevent a situation where packets get sent over and over again unnecessarily.


DiSEqC has, for each version, a counterpart that enables two-way communication (e.g. 2.0 from 1.0, 2.1 from 1.1 etc.). Most devices do actually implement the two-way communication, but enigma2 doesn't use it at all. I am afraid it's a vicious circle; DMM never bothered to implement it's functionality in enigma2, so other vendors didn't bother to add this functionality (probably...) in their drivers. May be the hardware isn't even capable.


Anyway, SCR is not the same as DiSeqC, it only uses most of it's signalling. The good news is that at least JESS (but probably Unicable as well) support inherently two-way communication, but in a different way than DiSEqC. AFAIK there is a command to query the currently assigned user bands, so I guess that's what one should use to check communications. But here also counts the same as for DiSEqC, probably the drivers or even hardware don't support actually reading DiSEqC. Even if only vendor doesn't support it, there would be a problem.


So enigma defaults to the "second best practice", where one sends the command, checks for LOCK and if it doesn't come, try again a few times until time out. It's not beautiful but it is very robust. As said the retransmission of the SEC commands take place a higher level than the SCR handling, so we shouldn't be modifiying code there (SCR). If not already there, I think we should modify the retry pattern into an exponentional backoff one, as described earlier. We could add to the pattern a random fragment, which would make the pattern even more efficient.

#933919 Playback controls

Posted by Erik Slagter on 14 September 2018 - 11:23

My OK button resumes playing as well. It configured it that way because when your fast-forwarding (with picture, which I rarely do), if you see the point you're looking for, you need to react quickly, or it's far beyond that point. In my experience it's way faster to grab the OK button than have to search for the play button.


So, littlesat, stop saying it's not necessary. Let's establish it IS valuable to have. Then who is going to implement it, is another discussion.