Posts by zapf2000

    I tested this device and sent it back after 4 hours of test.

    I bought it because it was advertised with MPEG4:2:2 decoding. This feature works only on low symbol rates. symbol rates higher than 9000 make problems and cause a complete freeze of the device. The whole user interface is very unstable and support at GTMedia forum is very bad. Lots of software bugs and no solution provided. Also bad: the LNB power supply has not enough power to drive my USALS motor properly. Link to Android smartphone is also not working. Keep your hands away from this device.

    This is an awesome plugin. Can you give me the source code? Of course without the login credentials. If you use intel CPU with GPU on chip, you can use the VAAPI and FFMPEG to transcode. It can handle H265 on hardware, even yuv422. some distributed libva's cannot handle it, but if you compile the lib from intels github repository, it's working fine. Transcoding H264 yuv422 to yuv420 takes about 50% of one CPU core on my AMD Ryzen 12 Core.

    Well, not completely correct. If you have a 4K Stream it is mostly H265 (not H264!) and nearly all GPU's can handle H265 yuv4:2:2 in hardware. Only H264 yuv4:2:2 has this problem. But as you said, nearly all 4k feeds use BISS-2, which is the show blocker. I also use the transcoding method for years, but I didn't find a way yet to automize the restream via STB.

    The point is that I also like to watch the feed on TV without PC connected to TV via HDMI, so I like to stream it back to STB and let the STB do the jandling with TV. In my case: STB is in a different room than PC, but there is a WIFI connection available.

    Any updates on the server ? i'm looking forward to it ,

    i have contacted free dvb to give us the access to their API but they didn't respond

    Freedvb has the fastest autoroll biss service and that's what sells their boxes (Hellobox).. you will need to give them something in return.. probably help to improve their softwares.

    i think forever has the best AU biss service

    Well, having the API key would be great and would save a lot of costs for a high performance server.

    The next problem I see is that the receiver hardware is not powerful enough to decode MPEG4:2:2 (MPEG4 10Bit Profile), which most of the feeds are using.

    Also NVIDIA, INTEL or AMD GPU's can't decode it on hardware. So a possible solution would be to use an existing computer (in private LAN) to transcode MPEG4:2:2 to MPEG4:2:0 on CPU. So stream the biss decoded http stream to computer in LAN, transcode it and send it back to Enigma2 box to watch the feed. it would also be possible to serve it to others via sub second latency media server (ovenmediaengine for example), but therefore we need support for webRTC or LLHLS on the box. Does someone know an Enigma2 programmer?

    c8.pngi think a cleaner implementation would be as suggested by zapf2000 . extract crypt8's using enigma2 plugin and then send it to the server. how compute intensive is getting c8 from raw .ts ? can an average e2 box do it without much fuss?

    this is an approach...i guess if the SR is 7199 or 7200 or 7202 wil be considered the same. Regarding the ability to get c8 from raw ts not sure how to do that in python too, need to study the cpp code to understand

    Getting c8 from raw ts is very easy. In the pic you see a part of a raw scrambled ts stream. "47h" indicates the start of the TS package. "07 D1" is the PID. The "9" indicates that the package is scrambled (even/odd depends on the bit which is set). "68 B8 18 EB F2 76 EC BE" is the c8 key. Lenght of one package is 188 Bytes.

    OK, so I think we can switch to operational issues. First question: how do we analyze the TS easily? Perhaps it's possible to analyze TS inside Oscam directly by using the DVBAPI without recording it first and use an external parser for that. I know nothing about the DVBAPI. Is there a documentation? I'll ask the streamboard guys directly, if it's possible to implement the parsing routine and export C8 directly out of OSCAM. That would help to process it automatically on the BISS Server.

    Another aspect is the Softcam.key file. Why write the BISS key into Softcam.key file and restart Oscam?

    We could also use a pipeline instead of the Softcam file, which provides the current key dynamically. That requires a patch for the emulator.

    Practically you only define the BISS server URL in oscam config and the rest is all done automatically. This solution would not reqiure an enigma image. It could work on every Oscam server, which sees the transport stream.

    But as i said before... I don't know if DVBAPI provides a function to read TS.

    By the way, the BISS Autokey function of some receivers base on the FreeDVB BISS API. When you have an API key, you can easily obtain the CW via API....

    although my understanding of biss implementation and hacks is rather limited, a couple of things to note

    ask the server for all known keys for the feed.. "0070:11017:V:7199"

    blind scans on different receivers almost always throw up frequency and SR values a bit off from the "real" ones. for instance, the unique hash mentioned above could actually be of the feed on frequency 11015 Mhz with SR 7200. these variations need to be taken into account when the receiver askes server for a key


    i think a cleaner implementation would be as suggested by zapf2000 . extract crypt8's using enigma2 plugin and then send it to the server. how compute intensive is getting c8 from raw .ts ? can an average e2 box do it without much fuss?

    It takes nearly no CPU power to get C8 out of TS, because the TS package is only parsed and cut to get the 8 Bytes out of the 184 Bytes payload in TS.

    I found an old code snippet written in perl, which does the job.