Jump to content

Erik Slagter

Member Since 3 Oct 2008
Offline Last Active 14 Mar 2019 20:10

#1029505 Terrestrial T2 met de VU+ Duo2

Posted by Erik Slagter on 11 March 2019 - 19:00

En dan gaan we maar weer eens het verhaaltje afdraaien dat set-top-boxen alleen een CPU hebben voor de user interface. Daarvoor is die ruimschoots voldoende. Maar je kunt er geen software codecs mee draaien. Dat is helemaal niet nodig omdat de SoC decoders in hardware heeft die dat met heel weinig stroomverbruik kunnen zonder de CPU te belasten. Nadeel is dat je vast zit aan de codecs waar de SoC mee geleverd is, je kunt dus NIET later nog codecs toevoegen (zoals HEVC).

#1027225 Terrestrial T2 met de VU+ Duo2

Posted by Erik Slagter on 7 March 2019 - 20:05

Ja ik hoor ook overal dat ze "UHD" doen: 1080p50. Ik zeg UHD omdat volgens de EBU en gerelateerde organisatie (ben de naam even kwijt) 1080i50 de hoogste HD resolutie is en 1080p50 de laagste UHD resolutie. Toppunt van verwarring natuurlijk, al was het alleen maar omdat elke HD ontvanger die na samen met de VU+Solo2 uitkwam of daarna, gewoon 1080p50 kan weergeven. Lang leve de marketing.

#1016769 Duo4K diverse dingen

Posted by Erik Slagter on 14 February 2019 - 20:46

Ik zat er op te wachten wanneer Erik weer eens kwam met zijn cardshare uitlokkende vragen of antwoorden, en ja, daar is ie weer....

Je hoeft het niet te ondersteunen voor mij WanWizard, alleen beetje raar als een Hollander iets over MGcamd vraagt is het volgens Erik illegaal, en vragen ze het in het Engels word je wel gewoon geholpen, zie onderstaande.




Yep, ik heb er geen moeite mee om ferm achter die mening te blijven staan. Ik zal het nog maar eens herhalen, er is géén reden om mgcamd te gebruiken anders dan illegale zaken.


Ik heb niet de behoefte om dat soort dingen actief onmogelijk te maken, maar voor het bespreken van dit soort dingen schijnen er andere forums te zijn.


Ik vind eerlijk gezegd al dat "voor weinig" kijken erg demotiverend om m'n hobby uit te oefenen, al was het alleen maar omdat daardoor de providers steeks drastischere maatregel gaan treffen waardoor ik als legale kijker steeds meer moeite moet doen (als het al lukt) om op m'n open ontvanger te kijken waar ik voor betaal.


Wat ik ook demotiverend vind is dat we al gratis een image ter beschikking stellen, maar dat is kennelijk niet genoeg, de content moet ook nog gratis of voor "weinig".


En ja, dat geeft mij naar mijn bescheiden mening het recht om sceptisch te reageren op de zoveelste klacht dat wij mgcamd stukgemaakt zouden hebben. Wat nergens op slaat, die eer heeft mgcamd helemaal zelf door niet meer bijgewerkt te worden.

#1009401 help me for zgemma h9.2s

Posted by Erik Slagter on 29 January 2019 - 18:47

This IS a driver bug and it should not be worked around. Please revert.


Single tuner receivers need "zapping" for some reason, when streaming.

#1003873 MIS/PLS multistream through OpenPLI on VU+ Duo 4K

Posted by Erik Slagter on 20 January 2019 - 10:31

Yes apparently you are missing something. No problems here with recording tons of services / channels at the same time from C. I think you're using a CI module or a softcam that is limited.


The FBC S2x tuners support exactly that: S2x. No multistream or physical layer scrambling (yet, at least).

#1001961 streamproxy and authentication

Posted by Erik Slagter on 17 January 2019 - 17:51

Yes, I am planning improved OWIF / authentication support for 7.1. I'm already working on it. Which will also include proper audio track selection for live transcoding streams, did I already mention that?

#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.