[ddci2] Patch um CAMs dynamisch mit jedem Device verwenden zu können

  • Beiliegender Patch ermöglicht es dem ddci2-Plugin, die CAMs dynamisch zur Laufzeit jedem beliebigen Device zuzuordnen (anstatt wie bisher fest dem Ersten). Genau genommen hätte das schon von Anfang an so sein können, denn ich habe nichts geändert ausser in DdCiAdapter::Assign() immer 'true' zurückzuliefern und alle Referenzen auf ein Device zu entfernen, an das der DdCiAdapter beim Start "drangehängt" wurde. Also keinerlei "Magie" von meiner Seite ;-).


    Solange ddci2 nicht MTD(*)-fähig ist hat man damit zumindest die Flexibilität, es mit jedem Device im System (auch SAT>IP) betreiben zu können.


    Danke an User 3PO für das geduldige Testen, da ich selber keine entsprechende Hardware hier habe.


    (*)MTD: "Multi Transponder Decryption", also die Fähigkeit, mit einem CAM mehrere Kanäle von *unterschiedlichen* Transpondern entschlüsseln zu können (was wegen eventueller PID-Überschneidungen nicht ganz trivial ist).


    Das Plugin funktioniert übrigens auch mit VDR 2.3.2 ;-).


    Klaus

  • Hallo,
    das klingt ja gut!


    Geht DDCI2 jetzt eigentlich mit jeder DVB-Karte oder nur mit denen von DD? Dass las sich mal so.
    Also Octopus Bridge und dann NUR ein CI dran. Dass das teuer ist, ist klar...


    Danke für deine unermüdlichen Bemühungen um VDR und natürlich auch für die 2.3.2!


    MfG,
    Stefan

    Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, FF-SD C-2300, nvidia Slim-GT218 512MB PCIe x1 | v2.0 64Bit
    VDR3: in Rente

    VDR4: MSI G31M2 v2, Digitainer2-Geh., t6963c 6" gLCD, E5200, 2GB, 750GB F1, GT730, 2x TT DVB-S2-3200) easyVDR 2.3
    VDR5: Gigabyte
    GA-G31M-S2L (Intel E2140, Zotac GT220 512MB + Zalman VNF100, Digitainer2-Geh., t6963c 6 " gLCD, 750GB F1, Sundtek DVB-C + Satelco DVB-C) easyVDR 1.0
    VDR6:
    Intel E5200, GT630 passiv, F1 750 GB, t6963c gLCD, 2x TT 3200 | easyVDR 2.3 64bit
    VDR-User #1068 
    www.easyvdr.de 

  • Hi,


    @real-schorsch und deti die man hier schon lange nicht mehr gesehen hat haben damals MTD in der Reelbox umgesetzt allerdings mehr oder weniger in hardware auf dem Netceiver. DigitalDevices hat auch eine Software Lösung für MTD, allerdings geben Sie die nur für Windows raus was sehr schade ist.


    Reference: 2x DVB-C Tuner + MTD ohne Digital Devices?


    CU
    9000h

    Es ist eagl in wlehcer Reiehnfogle die Bchustebaen in Woeretrn vokrmomen. Huapstache der estre und leztte Bchustbae sitmmen.

  • DigitalDevices hat auch eine Software Lösung für MTD, allerdings geben Sie die nur für Windows raus was sehr schade ist.

    Das stimmt so nicht, rausgeben wäre wohl schon möglich, macht aber wenig Sinn, weil nicht nutzbar, da Änderungen am Kernel nötig wären, die niemals durchgehen würden. Ob das jetzt am globalen Linux Kernel scheitert oder nur an der DVB Ecke kann ich nicht sagen. Windows gibt Entwicklern hier offensichtlich mehr Freiheit solche Dinge in den Treibern umzusetzen ...


    kls


    Super Sache die Anpassung.


    Regards
    Frank

    HowTo: APT pinning

  • fnu : Wieso wären dafür Änderungen am Kernel nötig?


    Ich schätze mal, MTD ließe sich in das bestehende ddci2-Plugin relativ einfach einbauen.
    Wenn es nur darum geht, die PIDs entsprechend vor- und zurückzumappen, dann liefe das darauf hinaus, daß das Plugin (so wie es ein anderes "unaussprechliches" macht ;-) für jedes Device ein "virtuelles" CAM anlegt, das die Daten eines Transponders entgegennimmt, die PIDs mappt, die Daten an das physikalische CAM schickt und wieder empfängt und letztlich die PIDs zurückmappt. Wenn mir jemand (@real-schorsch?) sagt, was genau gemappt werden muß, dann würde mich diese Aufgabe tatsächlich reizen ;-).
    Die Video- und Audio-PIDs sind soweit klar. Mir geht es dabei um PIDs in den CA-Descriptoren, EMMs oder was es sonst so gibt.
    Oder steckt da noch mehr dahinter?


    Vielleicht noch ein Wort zur "Legalität": es wird hierbei eine Kette aus CI-Adapter, CAM und Smartcard in völliger Compliance mit dem DVB-Standard verwendet. Also gehe ich mal davon aus, daß es OK ist, dies hier diskutieren. Das ddci2-Plugin schiebt lediglich Daten hin und her und macht selber keinerlei Entschlüsselung.


    Klaus

  • Das klinkt doch gut :)


    Dies stört wirklich "immer" etwas wenn nur ein dvb device mit einem cam nur sein device bedienen kann und die anderen aus der Wäsche gucken.


    Bin gespannt ob dies dann auch für andere devices möglich ist. Z.b die technotrend ci dvb devices


    BTW? Gibt es eigentlich ein ci für die S2-6400?


    Grüße
    Christian

    ------
    Hardware: ASUS E35M1-I Deluxe, 4GB RAM, ATI on Board (fuer Kodi), TT S2-6400 FF, Samsung 500GB 2,5"
    VDR: MLD5

  • fnu : Wieso wären dafür Änderungen am Kernel nötig?

    Ja, das war immer das Ziel das in DDCI2 einzubauen, da hast Du recht. Dies galt IIRC auch immer als machbar, aber eben ausserhalb der Treiber.


    Ich bezog mich auf den Vergleich mit den Windows Treibern von DD, dort ist MTD in den Treibern drin, was aber unter Linux wohl so nicht (einfach) umgesetzt werden kann. Insofern müssig drüber zu klagen, DD würde es nicht rausgeben ...


    Gruß
    Frank

    HowTo: APT pinning

    Dieser Beitrag wurde bereits 1 Mal editiert, zuletzt von fnu ()

  • Ich schätze mal, MTD ließe sich in das bestehende ddci2-Plugin relativ einfach einbauen.
    Wenn es nur darum geht, die PIDs entsprechend vor- und zurückzumappen, dann liefe das darauf hinaus, daß das Plugin (so wie es ein anderes "unaussprechliches" macht ;-) für jedes Device ein "virtuelles" CAM anlegt, das die Daten eines Transponders entgegennimmt, die PIDs mappt, die Daten an das physikalische CAM schickt und wieder empfängt und letztlich die PIDs zurückmappt. Wenn mir jemand (@real-schorsch?) sagt, was genau gemappt werden muß, dann würde mich diese Aufgabe tatsächlich reizen ;-).
    Die Video- und Audio-PIDs sind soweit klar. Mir geht es dabei um PIDs in den CA-Descriptoren, EMMs oder was es sonst so gibt.
    Oder steckt da noch mehr dahinter? ...


    Nun, wie Du schon richtig bemerkt hast, ist "einfach" eben "relativ". ;)


    Im Grunde genommen braucht man "nur" die ganzen Streams zu zerlegen, dann zum Entschlüsseln durch das CAM schicken und hinterher wieder zusammenzubauen, quasi multiplexen --> decodieren --> demultiplexen.


    Damit würde dann das CAM nur einen einzigen Stream sehen, was die eventuelle Restriktion der Provider aushebeln würde.


    Das größte Problem ist aber vermutlich der CI Slot selber, denn kann, laut Spezifikation, nur max. 9 Mbyte/sec.


    Dann müsste "man" "nur" noch die Restriktionen von CI+ aushebeln und da wird es schon schwieriger. Wobei "schwieriger" nicht bedeutet, dass es unmöglich ist.... ;)

  • PaulPanther
    Mit anderen CIs kann das nicht funktionieren, weil die per Hardware mit einem Tuner verknüpft sind. Bisher gibt es nur das DD-CI, welches man direkt ansprechen kann.


    Lars

  • morgen zusammen,


    kann mich noch daran erinnern, dass es bei der entwicklung des mld auf dem netceiver ziemliche probleme
    mit den modulen gab. letztendlich wurden dazu nur drei freigegeben, auch wenn es mehrere modulkandidaten
    gegeben hat. die waren aber alles so dermassen neben der cam-spezifikation, dass darauf verzichtet wurde.
    des weiteren war es beim alphacrypt moeglich, theoretisch mehr als vier parallele streams zu verarbeiten
    (meine mich an acht erinnern zu koennen - nagelt mich aber bitte nicht fest)


    hier der entsprechende auszug aus der cam_menu.c des mcli-plugins zeile 89ff




    gruss
    beinhart

  • PaulPanther
    Mit anderen CIs kann das nicht funktionieren, weil die per Hardware mit einem Tuner verknüpft sind. Bisher gibt es nur das DD-CI, welches man direkt ansprechen kann.


    Lars

    Danke für die Info aber schade. Seh ich das richtig das die ddci's nur mit den DD Karten laufen oder gibt es die auch als standalone und kann die x beliebig einem Device zuordnen? Z.b zur 6400

    ------
    Hardware: ASUS E35M1-I Deluxe, 4GB RAM, ATI on Board (fuer Kodi), TT S2-6400 FF, Samsung 500GB 2,5"
    VDR: MLD5

  • @jasmin hatte ja schon mal angefangen mit MTD ddci2 branch devel_mtd.


    Wobei das (soweit ich sehe) lediglich ein "Mäntelchen" ist und noch keinerlei echte MTD-Funktionalität enthält.


    Mir gefällt der Ansatz auch insofern nicht so ganz, weil da für jedes Device ein (virtueller) cCiCamSlot angelegt wird. Das hat zur Folge, daß z.B. im Setup/CAM-Menü alle diese CAMs separat auftauchen, und VDR bei der Suche nach einem geeigneten CAM um einen Kanal zu entschlüsseln diese alle durchprobiert, obwohl es letztlich immer die gleiche Smartcard ist und ein Versuch reichen würde.


    Mir schwebt da eher sowas vor:


    - für jedes physikalische Interface gibt es einen cCiAdapter
    - für jedes physikalische CAM gibt es einen cCiCamSlot
    - wenn ein cCiCamSlot MTD kann, dann legt er zur Laufzeit in cCiCamSlot::Assign() einen virtuellen cCiCamSlot an, der die eigentliche Arbeit übernimmt
    - im Setup/CAM-Menü erscheinen nur die physikalischen CAMs (bzw. cCiCamSlots)


    Dazu muss ich zwar an der bestehenden cCiCamAdapter/cCiCamSlot wohl an einigen Stellen was ändern, aber letztlich wäre das dann auch aus Anwendersicht klarer.


    Aber erstmal möchte ich genau wissen, an welchen Stellen die Daten (PIDs etc.) für MTD genau gemappt werden müssen.


    Klaus

  • Hab ich im Prinzip schon mehrfach, wird z.B. leider auch niemals beim Octopus Net zum Einsatz kommen. Wie gesagt das scheitert eher an den Kernel/DVB Leuten denn an DD bzw. deren Entwicklern.


    ddci2 war und ist der Weg der zum Ziel am VDR führen kann. Eine nötige Änderung für DDCI2 an den Treibern konnte ja umgesetzt werden, ein bestimmter Modus, Name fällt mir grad nicht ein ...


    Regards
    fnu

    HowTo: APT pinning

  • Nein, diese Remote-CI-Funktion gibt es IMHO nicht. vdr-plugin-satip ist aber in der Lage diese anzusprechen und Sender zu entschlüsseln.


    Regards
    fnu

    HowTo: APT pinning

  • Wenn MTD sich allein dadurch realisieren lässt, daß die Daten (also die PIDs) entsprechend gemappt werden, dann sollte das mit ddci2 rein im Plugin machbar sein (mit den paar Änderungen an der Adapter/CamSlot-Architektur, die ich weiter oben erwähnt habe). Ich kann mir eigentlich nicht vorstellen, daß es dazu Änderungen auf Treiberseite bedarf, denn der Datenfluß zu und vom CAM funktioniert ja bereits.


    Klaus