ICAM Patch oscam-emu

[putschi]

Kennt sich hier jemand mit der DVB API aus? Wie bekommt man dort den TS raus? In der Theorie würde ich sagen: Frontend öffnen, mit ioctl den kanal einstellen und dann dvr öffnen und den TS lesen?

 

[einsmann]

Das wäre ja für VTI interessant oder?

 

[putschi]

Ja z.b. da man keinen http Stream mit ECMs benötigt, den die VTI Images ja scheinbar nicht liefern können.

 

[TuzlaDVB]

„Kanal einstellen“ hat mit der dvbapi im oscam erstmal nichts zu tun.
VTI kann sehr wohl http streams. Es packt nur keine ECMs rein. Würde jetzt also die dvbapi nach ecms filtern und dann das dcw an das relay schicken… Denk mal drüber nach.

 

[putschi]

VTI kann sehr wohl http streams. Es packt nur keine ECMs rein.

Das habe ich doch geschrieben.

Ich finde die Idee, den kompletten TS aus der DVB API zu holen zunächst einmal einfacher zu implementieren. Gefühlt ist dafür ja nur der HTTP Request Part im Streamrelay gegen ein paar DVB API Befehle zu tauschen und statt vom Socket lese ich den TS dann aus einer device file (/dev/dvb/adapterN/dvrX?!).

 

[Youtube18]

Ich finde die Idee, den kompletten TS aus der DVB API zu holen zunächst einmal einfacher zu implementieren.

Wofür wohl die Function dvbapi_write_cw ist ?
Oscam macht nichts mit dem TS Stream. Es wird das ECM aus via DVB API bezogen, das CW generiert und das an die DVB API zurückgeschrieben.
Den Rest macht dann der Receiver selbst in Hardware und es wird Bild.

Und das Bild via Hardware muss nun unter iCam selbst per Software erfolgen.

Gefühlt ist dafür ja nur der HTTP Request Part im Streamrelay gegen ein paar DVB API Befehle zu tauschen ...

Gefühlt muss man nur das CW am Ende, statt via dvbapi_write_cw wieder an den Receiver zu schieben, dem iCAM Teil passend geben und fertig bzw. so:

Würde jetzt also die dvbapi nach ecms filtern und dann das dcw an das relay schicken… Denk mal drüber nach.

Nur wenn das so einfach wäre, warum dann in der geleakten Version der Umweg über Radegast ?
Weil die geleakte Version eine Testversion war/ist, die schnell zum Testen zusammengestrickt wurde ?

... und statt vom Socket lese ich den TS dann aus einer device file (/dev/dvb/adapterN/dvrX?!).

Den Stream bekommst du via Netzwerk angeliefert, der wird entschlüsselt und auf einem neuen Port bereitgestellt.
Alles schon vorhanden und funktioniert, den Part muss man nicht neu erfinden.

 

[einsmann]

Nun die Frage.. wo. gibst es die geleakte bezüglich VTI!

 

[icb]

Zu kompletten TS in dvbapi verarbeiten: Also man müßte e2 den Sender tunen lassen. Oscam bzw. die dvbapi holt sich dann die ECM Daten und zusätzlich noch die Video/Audio Daten. Die werden dann entschlüsselt. Aber dann? Wie bekommt man die ausgegeben? Oscam könnte es selber machen. Aber e2 gibt ja (ohne Anpassungen an e2) schon die verschlüsselten Daten aus. Weiß gerade nicht, ob man parallel daneben von Oscam aus die entschlüsselten ausgeben kann, ohne das das Chaos gibt. Außerdem könnte man dann beispielsweise nicht mehr die Tonspur wechseln. Alternative man gibt die Daten dem Streamserver und der gibt sie dann an e2. Könnte gehen, aber wie bringt man e2 dazu im ersten Schritt nur auf den Sender zu tunen aber den Stream von Oscam auszugeben. Das funktioniert im Moment aus meiner Sicht nur, wenn das über die 2 Streams läuft. Und dann braucht man im dvbapi Teil nicht auch noch die Video/Audio Daten laden. (ich hoffe das ist einigermassen verständlich).

Was man machen kann ist, die beiden Streams erstmal so lassen und im dvbapi Teil das Codewort an den Streamserver zu übergeben. Dann hat man aber immer noch 2 Streams. Aber nicht mehr Radegast dazwischen. Das ist recht einfach umzusetzen und funktioniert schon so halb...

Warum Radegast? Weiß ich nicht. Vielleicht weil man erst davon ausgegangen ist, dass die Entschlüsselung zu langsam ist und unbedingt auf einer anderen Hardware stattfinden muss. Über Radegast kann man ja ein anderes Oscam (auf dem PC/Raspi oder so) dafür verwenden. Das geht mit der dvbapi glaube ich nicht oder nicht so einfach.

 

[putschi]

Ausgabe kann doch weiterhin über den http stream vom streamrelay erfolgen, allerdings müsste oscam dann tunen. Alternativ baut man dafür nen zusätzlichen Service (ähnlich wie den eingebauten Streamserver

Sie müssen registriert sein, um Links zu sehen.

und

Sie müssen registriert sein, um Links zu sehen.

), da es ja etwas außerhalb des Scopes von oscam liegt. Dieser würde dann tunen und den kompletten (verschlüsselten) TS inkl. ECMs wieder per HTTP ausgeben.

Ich würde gerne den kompletten TS inkl. ECMs holen, sonst müsste ich ECMs/CWs und Video/Audio selbst synchronisieren.

 

[adi22]

also MieseRatte hat die NP oscam und hat mal zu deinme code @icb gesagt man müsste "nur eine zeile ändern" - finde leider nicht mehr den genauen kommentar von ihm...

 

[Miese.Ratte]

Ihr denkt viel zu kompliziert. Wie funktioniert das Streamrelay an sich? Durch die spezielle Senderliste bringt man die Box bereits zum tunen. Darum muss man sich also nicht mehr kümmern.

Es kommt folglich vorne der Stream rein wie gehabt. Mit ECMs und allen PIDs. Also Ton, Video, Text, ECMs, EMMs und weiß der Fisch.

Das kommt auch am DVBAPI vorbei. Alles wie gewohnt. Das DVBAPI ermittelt das dCW. Immer noch alles wie gewohnt. Jetzt muss nur noch das dCW abgefischt und dessen Transfer an das CA-Device verhindert werden. Andernfalls wird das Signal per CSA "entschlüsselt" und ist im Ar***.

Sogar das ist bereits rudimentär vorhanden. PowerVU braucht das.

 

[putschi]

Es kommt folglich vorne der Stream rein wie gehabt. Mit ECMs und allen PIDs. Also Ton, Video, Text, ECMs, EMMs und weiß der Fisch.

Hab keine Box mit VTI oder eine Dreambox aber ich lese hier immer wieder, dass der Streamserver dort eben keine ECMs mitliefert und sich auch nicht so konfigurieren lässt.

 

[Miese.Ratte]

Vergiss die besonderen Einstellungen von OpenATV. Wenn man die nicht vornimmt, bekommt man exakt das gleiche Verhalten wie mit DreamOS und VTi.

Sonst denke bitte noch einmal nach, wie so ein Signal durch die Box läuft und entschlüsselt wird. Ganz ohne ECMs mag da keine Freude aufkommen, egal ob Dream, VU oder Peng.

 

[putschi]

Hier mal meine Theorie. Mangels Reader für 098D und Box mit VTI/DreamOS kann ich es nicht testen:

__u16 p = <ECM_PID>;
ioctl(demuxer_fd, DMX_ADD_PID, &p);

mit dem passenden fd müsste doch schonmal reichen um die ECMs mit in den Stream zu bekommen

oder mit

dvbapi_start_pmt_filter(demux_id);

einfach alles rein bei 098D. passiert aktuell aber nur bei powervu sendern.

Dann noch das Anfragen der CWs in dvbapi_process_input für 098D verhindern und es sollte funktionieren

 

[darkstar91]

du könntest es bei meiner box testen (DM820 also mipsel mit DreamOS) über teamviwer, hab auch einen PS mit 098D.