Erik Slagter

The interface (API) is dictated mostly by how DMM (Dream Multimedia) created it in their implementations of enigma2 and the drivers. The other vendors will have to follow this design for existing functionality. For new features they can choose the interface (which will mostly be dictated by Broadcom anyway), which, in theory, other vendors will need to follow. We at OpenPLi are a bit more strict in this than other images builders, which tend to allow for all sorts of exception code for different vendors. We try to avoid that as much a possible.

This concept is the same for Broadcom, HiSillicon and any other SoC manufacturer. We don't care what SoC is inside, as long as it plays by the rules and then it will be no problem to build an image for it.

The API consists mainly of the well-known DVB4Linux API, which has been in the kernel for ages. Quite a bit of functionality is not covered there, though and has alternative access, like additional ioctls and /proc (/proc/stb/...) entries. AFAIK there are no driver implementations yet that use /sys.

If you want to know how it works and how it was designed, I can only suggest: "Use the source Luke"! The original implementation of Enigma2 by DMM wasn't really documented and everyone of us (image builders) have kept to that tradition. Let me warn you: it's not pretty.

Ik zou het liefst zien dat TS op zo'n moment even gaat inloggen (met telnet of ssh) op de ontvanger. Als dat al niet lukt (geen verkeer terug), dan is de ontvanger gewoon gecrasht. Daar kan enigma niks aan doen.

Als dat wel lukt, dan de output van "dmesg", kijken of daar een driver crash in zit (en dan ook kunnen we er nog niks aan doen).

Als dat ook niet het geval is, dán kan het aan enigma liggen. Ik denk aan

- OOM door teveel EPG (hoewel de UHD ontvanger heel veel RAM hebben en niet zo waarschijnlijk)

- een disk share (SMB/NFS) waarvan de server niet meer reageert

- netwerk probleem of bijv. een DNS server die het niet goed doet

I think the aspect ratio metadata is not exactly 16/9 or 4/3 (which is possible). Apparently other receivers act differently there. According to at least EBU AR should always be exactly 16/9 or 4/3.

AFAIK there is no AR metadata in the container (transport stream), the decoder has to rely on the elementrary stream (video stream) to be correct.

Enigma itself does no do anything with the AR metadata, because the transport stream is demuxed and decoded by the SoC's hardware.

Update. Yep. It's a budget receiver. Only two (fixed) tuners, no display and the same SoC as the hd60 and h9.

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

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.

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.

 

https://forums.openp...mgcamd-in-feed/

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.

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

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

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

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?

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.

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.

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.

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.

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.