Just a little insight (as the author of that article).
The genius Athoik in SatDreamGr team was very into creating this solution after my idea and I'm really thankful to him for that!
T2-MI is a challenge in Enigma2 and involves understanding how this encapsulation type works but more importantly how the decapsulation works. As described the stream is enclosed in a pid of the transponder (99% of these transmissions use pid 4096).
So what we needed is something to read this pid, use it as source, process it (decapsulate it) and then read the contents and finally output them.
So the chain is (very roughly)
1. reception of the transponder (input)
2. isolation of the pid
3. decapsulation/analysis of the pid
4. content decoding
5. content output
As you can see, this is more complex than simply receiving a transponder and output the pids directly. The satellite tuners read a TS transponder, decode the pids and output the content directly for viewing. So, we needed something to intervene in this chain that permorms steps 2, 3 and 4.
Initially I opted to try newspaperman's T2-MI decoder. This worked but was very CPU consuming, which means in real time we had lots of glitches. Granted, not everything was tried to reduce the CPU load, perhaps it could work better with some tweaking.
Athoik then came up with a better solution that involved astra-sm's internal t2mi_decap process (please correct me if I'm wrong I may not remember exactly). That was much better since the astra-sm took over the processing and that reduced the load which resulted to a glitch free picture.
So, in order to automate the processes for user facilitation (and not the need of telnet commands), Athoik introduced pid caching to enigma2. This way he managed to virtually assign any pid to a service even if not registered in the pat, and stream from that. This became our source. Afterwards astra-sm takes over and outputs the decapsulated data. The only drawback is that astra-sm will not output to enigma2 directly as normal channels but only as streams, so everything had to be done manually.
Now, the question is
Can a T2-MI decapsulation become direct in Enigma2?
The answer is: YES
Is it an easy task?
NO!
First what should be used is a standalone decapsulator (I'm not sure if T2mi_decap binary can be used independantly from astra-sm) which will act as an Enigma2 process with the minimal CPU load possible! (If possible)
Then Enigma2 needs to be patched and rewritten so that a pid option can be added to ScanSetup to add pid caching to any service reference without the use of Dreamboxedit and other editors.
Afterwards the T2-MI reception options need to be added to DVB-S/S2 that means T2-MI system, PLP ID etc, as manual options or auto discovery (even more complex).
Then any satellite.xml needs to be rewritten with the above options, which means lamedb patching as well. This is the same that happened with multistreams where the MIS options were added which took a lot of Enigma2 patching.
This (and is described very simply) is A TON of work, and besides, who will do it and why?
So, my suggestion is take what has been offered already and be patient. This is a hobby from people that offered their time, knowledge and expertise and on top of that other third parties already benefited from by doing all of the above in closed source receivers (you name who....).
t2mi.png 39.76KB
13 downloads
