ICAM Patch oscam-emu

[mestorf]

vieleicht kann mir ja jemand helfen und sorry schonmal ich habe keinen Debugger o.ä. aktuell.

Wieso wurde 188 gewählt? Gibt es dazu eine Logik? Ohne jetzt einen Beweis, sondern nur algemeiner Eindruck anstatt 188 auf 100 finde ich läufts etwas weniger mit den anfänglichen mickro rukklern nach Senderwechsel auf einen icam sender. Was ist sehen kann ist, dass auch die Auslastung hochgeht, was sinn machen würde, da wohl weniger buffer verwendet wird z.b. bei Wert 10 läuft oscam bei 90% Auslastung unter top. Wenn ich aber den Wert z.b. auf 288 stelle, dann habe ich nur noch aussetzer und pixel bilder bei Auslastung von 1%.

Will nur verstehen woher der Wert kommt ob es überhaupt sinn mach hier noch weiter zu justieren. Danke

+            else if (data->key.icam_csa_used)
+            {
+                cur_dvb_buffer_size = 188 * cluster_size;
+                cur_dvb_buffer_wait = 188 * (cluster_size - 3);
+            }

 

[putschi]

188 bytes ist die typische "MPEG-TS packet size". Alles andere sind wohl eher Abweichungen.

Eher "willkürlich" erscheint mir die 3 in cur_dvb_buffer_wait gewählt zu sein. Sollte wohl eher relativ zur cluster_size gewählt und/oder vllt. sogar zur Laufzeit konfigurierbar sein.

Deine Beobachtung der Auslastung ist logisch. decrypt_packets() hat "fixed CPU cost". Man sollte es also immer mit möglichst vielen scrambled Packets aufrufen. Die Anzahl ist allerdings durch die cluster_size begrenzt. Wenn ich decrypt_packets() also mit weniger Packets als cluster_size aufrufe, muss ich es häufiger aufrufen um alle packets zu entschlüsseln.

Zu deiner zweiten Beobachtung: Der aktuelle Patch (v9) geht davon aus, dass alle Packets von decrypt_packets() descrambled wurden. (Mal abgesehen vom odd/even switch). Wenn Du also cur_dvb_buffer_size > 188 * cluster_size wählst, werden einige Packets eben nicht descrambled und stattdessen scrambled an den Decoder weitergeleitet. Das führt dann zu den beschriebenen "aussetzer und pixel bilder". Wobei diese natürlich sofort und dauerhaft vorkommen. Anders als die sporadischen Tonaussetzer und Bildfehler, die unser eigentliches Problem darstellen.

Idealerweise würde man natürlich jedes scrambled Packet direkt entschlüsseln und an den Decoder weiterleiten. Das schafft aber wohl kein Receiver. Die zweitbeste Strategie in Verbindung mit ffdecsa ist, immer auf cluster_size + min(cluster_size/10,5) aka get_suggested_cluster_size() packets zu warten. Das sagt zumindest die Implementation von get_suggested_cluster_size(). Und der Author steckt(e) wohl ziemlich tief in der Materie ;-) - würde also ungern widersprechen. get_suggested_cluster_size() berücksichtigt, dass einige Packets bereits clear ankommen (müssen). Wie bspw. PMT packets. Solche Packets werden von decrypt_packets() übersprungen. Wenn ich also decrypt_packets() nur mit cluster_size Packets aufrufe, verschenke ich etwas Rechenzeit.

Allerdings kommt es bei größerer cluster_size auch schneller zu timing Problemen. Selbst bei den aktuellen HiSilicon Receivern (bspw. Octagon SF8008) hat man ab und zu kleine Bildfehler. Daher wäre eigentlich ein kleiner Buffer notwendig. Kann man bspw. durch eine Aufnahme oder Timeshift simulieren. Bei Wiedergabe der laufenden Aufnahme/des Timeshifts sollten alle Bild- und Tonfehler weg sein. Insofern deine V15 das korrekte CW zeitnah liefert(e). So ein Buffer wäre halt auch in Streamrelay zu realisieren. Ist allerdings etwas kniffliger, da Streamrelay auch nicht einfach mehrere Sekunden an Daten an den Decoder send()en kann.

Alternativ könnte man vielleicht auch noch das Timing verbessern. Bin mir aber nicht sicher und habe aktuell auch keine Idee, wie das gehen könnte. Evtl. durch Berücksichtigung der PCR. Ein kleiner Buffer ist vermutlich die sicherere Variante.

 

[mestorf]

Ah cool danke! macht die size denn dann im stream überhaupt sinn? Bewegen wir uns, wenn icam, im module-emulator-streamserver.c benutzt werden soll noch im MPEG-TS Bereich?

 

[putschi]

Ja, Streamrelay bekommt vom Streamserver einen MPEG-TS mit den (laut PAT) zugehörigen Paketen des entsprechenden Senders mit variabler Bitrate. Und Sky DE nutzt die typische Packet size von 188 bytes

PS: Hab meinen vorherigen Post noch ein paar mal angepasst/erweitert.

Hier mal die Theorie:

Spoiler

producer thread, existing thread
 - sync recv() with packetSize
 - allocate memory, decrypt_buffer=malloc(get_suggested_cluster_size()*packetSize)
 - start send thread
 - loop
   - fill complete decrypt buffer, using blocking recv(conndata->connfd, decrypt_buffer+decryptOffset, get_suggested_cluster_size()*packetSize-decryptOffset)
   - advancedPackets = decrypt_packets() // some packets will be left scrambled
   - mutex_lock sendBuffer
     - append descrambled packest to sendBuffer, memcpy(sendBuffer + sendBufferLength,decrypt_buffer, advancedPackets*packetSize)
     - sendBufferLength+=advancedPackets*packetSize
   - mutex_unlock sendBuffer
   - move still scrambled packets to start of decrypt_buffer, memmov(decrypt_buffer, decrypt_buffer+advancedPackets*packetSize, get_suggested_cluster_size()*packetSize-advancedPackets*packetSize

consumer thread, new thread
 - wait until sendbuffer has PCR packets for n miliseconds (e.g. n=1500 (as in 1.5 sec or 40500000 PCR ticks))
 - loop
   - mutex_lock sendBuffer
     - send all packets until next PCR (maybe some more)
   - mutex_unlock sendBuffer
   - sleep (next PCR - current PCR) ticks, ~35ms/945000 PCR ticks most of the time

 

[rudi52001]

ICAM Patch v9 für oscam-emu.patch 11725 r.798 angepasst.

Newbie Frage - in welcher Datei ergänze/füge ich den Text ein?

 

[richard 52]

Das will ich auch gerne Wissen......??

 

[Redegast]

Das ist eine Patch Datei, wird zum bauen einer Oscam Binary gebraucht.

 

[el_malto]

@rudi52001 und @richard 52 SuFu oder Google nutzen.

 

[ghost0815]

@rudi52001 und @richard 52
Datei umbenennen
oscam_emu_icam_dvbapi_radegast_v9.patch.txt --->oscam_emu_icam_dvbapi_radegast_v9.patch

Den Patch in "oscam-svn" ablegen und dort dann einfach "patch -p1 < oscam_emu_icam_dvbapi_radegast_v9.patch"
danach ganz normal Oscam bauen....

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

oder mit Simplebuild 3 bauen

Befehle & Erklärungen zu "Simplebuild 3 / Toolchain Update Plugin (s3.TUP)"

Hi @ all, ich versuche hier mal alle Befehle für "Simplebuild 3 / Toolchain Update Plugin (s3.TUP)" aufzulisten und auch per Erläuterung verständlich zu machen. Ich eröffne diesen Thread, damit man nicht immer wie wild rumsuchen muss nach den jeweiligen Befehlen bzw. deren Erklärung...

www.digital-eliteboard.com

oder eine von denen nehmen

https://www.digital-eliteboard.com/resources/oscam-taeglich-aktuell-mit-icam-v9-support-arm-mipsel-dream_aarch64-x64.6769/

 

[Alex]

Es ist ja nicht so, dass es hier nicht auch HowTos gäbe in denen auch erklärt wird wie man patcht.
Aber einlesen muss man schon selbst

 

[putschi]

Recht interessant: VU+ Solo2 und VU+ Uno 4k SE verhalten sich anders als bspw. ein SF8008 beim Bereitstellen der MPEG-TS Packets. Ich habe mal gemessen, welche Zeit Streamrelay bei den drei Receivern per poll() auf neue Daten wartet. Bei SF8008 liegt die Zeit etwa bei ~90ms. Bei den VU+ Modellen schwankt es recht stark teils bis zu 900ms. Natürlich empfangen alle drei Receiver die gleiche Anzahl an Packets. Allerdings kann der SF8008 halt viel früher mit dem descramblen beginnen.

Auch interessant: Die Uno 4k SE ist deutlich schneller in ffdecsa als der SF8008.

Median über 10000 Iterationen decrypt_packets() beim SF8008: 2108us. Die Uno 4K SE benötigt nur 963us. Beide mit 128 Packets cluster size (PARALLEL_128_NEON).

 

[Token]

Solo2 = Broadcom Mips32el
Uno4KSE = Broadcom ARM
SF8008 = HiSi ARM
... sehr interessant, wie die unterschiedlichen CPU-Architekturen das Berechnen hinbekommen!

 

[adi22]

@putschi , du wolltest noch einen buffer bei deiner Vu 4k "reinbauen" ...hat es funktioniert?
falls ja, kannst du bitte die lösung posten?

danke, adi22

 

[dogfight76]

Buffer für ARM-Boxen ?
Im Sinne von zwischenspeichern ?


Gesendet von iPhone mit Tapatalk Pro

 

[putschi]

Korrekt. Mir war halt aufgefallen, dass Aufnahmen/Timeshift bei der Wiedergabe keine Tonprobleme auf Vu+ Uno 4k SE sowie auch Vu+ Solo 2 (Mipsel) hatten. Es scheint daher ein Timing-Problem zu sein, dass ich mit einem Buffer auch soweit lösen konnte. Der Patch ist allerdings etwas (zu) komplex und mit den Erkenntnissen aus meinem vorherigen Beitrag (ICAM Patch oscam-emu) lässt es sich vielleicht auch ohne diese Komplexität und möglicherweise komplett ohne weiteren Buffer lösen.

Wenn man diese Erkenntnisse weiterdenkt, werden bis zu cur_dvb_buffer_wait packets erst beim Bereitstellen der nächsten Packets descrambled. Auf den Vu+ Boxen (zumindest Solo2 und Uno 4k SE) kommen immer Vielfache von 1050 Packets an. Meist 2100 Packets. Dann ist Pause. Bei hohen Bitrates nur etwa 150ms. Bei niedriger Bitrate teilweise 900ms. Dann kommen die nächsten 2100 Packets. Und wieder eine Pause.

Wenn man 2100 Packets mal durch 128 (cluster_size auf der Uno 4k SE) teilt, merkt man, dass die Rechnung nicht aufgeht. 52 Packets bleiben übrig und werden erst nach der Pause descrambled. Also teilweise bis zu 900ms später.