ICAM Patch oscam-emu

[Leo888]

Gilt die Gegenfrage mir?
Wenn ja, beantwortet das nicht meine Frage. Braucht man ICAM nun für lokale Karten oder nicht? Wenn nicht, dann ist das hier eh schon mal der falsche Thread

 

[DarkStarXxX]

Natürlich braucht man das auch für Lokale Karten.

 

[Leo888]

Ok, dachte die laufen nur noch in der original Sky Kiste und da braucht man keine OSCAM und ICAM schon zweimal nicht
Dann wäre aber richtig, für lokale SKY Karte, denn den Rest habe ich noch in keiner ICAM Senderlist gesehen.

 

[DarkStarXxX]

Auch in der Sky Q steckt iCAM.

 

[Leo888]

OK, wusste ich nicht. Man lernt aber dazu.
Die letzte Karte die ich von dem Verein hatte, war noch mit "Pimiere" betitelt und war noch was wert.

 

[aabbc1]

aber nicht via Stream Relay oder Radegast. Das würde ja sonst einen Zeitverlust zum Live TV bedeuten.

 

[tem_invictus]

Die Theorie finde ich auch interessant. Kenne mich mit openATV nicht aus, aber vielleicht mal bei denen im Forum fragen, ob man den Buffer anpassen kann.

 

[ghost0815]

Gibt es bei openatv
usr/sbin/livestreamersrv?

 

[Alex]

Nein existiert nicht

 

[putschi]

Vielleicht mal bei VLC den Cache auf 0 setzen und gucken ob es dann auch auftritt? Aber vielleicht reicht auch der "delay" des Netzwerkes schon aus das keine kleinen Ruckler kommen.
Hab mich noch nie mit der Service App beschäftigt weil ich kein IPTV nutze. Vielleicht mal den Player auf 4xxx oder 5xxx (weißt die genauen Zahlen jetzt nicht) wechseln. Vielleicht sind die "extPlayer" ja schon anders und haben einen Cache?

Es wurde aber auch schon mal gesagt das diese Rückler kommen wenn sich die Tonspur ändert. Das ist meist bei Werbung oder am Ende eines Filmes zu merken. Könnte natürlich auch bei der Schalte in der Konferenz sein.

Wenn ich in VLC den Cache auf 0 setze, dann habe ich viele Ruckler. Da spielt aber auch noch die Latenz im Netzwerk eine Rolle. Service App habe ich heute auch das erste Mal gelesen. Muss ich mir mal anschauen.

Tonspur will ich nicht 100% ausschließen allerdings kommen halt auch Ruckler im Spiel. Und da wird sicherlich keine Tonspur gewechselt.

 

[adi22]

hi,
ist es sowas wie hier besprochen oder auch im bild?

Icam Tonaussetzer unter Sky

Hallo Hab eine Duo4K mit Vti und die Icam am laufen sowei so gut aber egal welche Binaries ich nehme ,habe ich am Anfang die Tonaussetzer unter Sky. Ich weiss auch ,da ich es schon probiert habe das es z.b. unter OpenAtv nicht ist. Da ich aber nicht auf VTI unbedingt verzichten möchte wollte...

www.digital-eliteboard.com

 

[putschi]

Jo, beschreibt die Sache schon ziemlich gut. Bild ruckelt aber auch. Der ruckelnde Ton ist aber besser zu vernehmen, da man ja auch mal nicht hinschaut. Bin nur dort auch verwirrt, dass es sich nur auf einige Receiver bezieht und andere problemlos funktionieren.

Weiterhin habe ich gerade mal eine Halbzeit Fußball aufgenommen und dort waren in der Wiedergabe - wie erwartet - keine Ruckler. Der Stream passt also, es ist nur ein Timing-Problem. Analogie aus Videospielen: Ich kann 60 FPS avg haben. Wenn aber ein paar Frames trotzdem > 16ms benötigen, habe ich Ruckler.

Ich habe auch schon einen Lösungsansatz. Streamrelay müsste den verschlüsselten Stream direkt entschlüsseln, aber zunächst noch n Milisekunden/Sekunden warten, bis die entschlüsselten Pakete an den Player geschickt werden. Werde das mal implementieren und testen.

 

[tem_invictus]

Auf jeden Fall probieren mit dem Streamrelay.

Ich denke aber die bessere Idee wäre es, dem Player zu sagen, ej Buffer mal bitte xx Sekunden oder MB, bevor du abspielst.
Wenn Streamrelay quasi buffert, dann wäre es für den Player ja immer noch "realtime" abspielen.

 

[putschi]

Ja, das wär sicherlich etwas eleganter. In OSCam Bzw streamrelay kann ich es aber deutlich einfacher umsetzen.

@icb Gibt es einen besonderen Grund, weswegen Du cluster_size auf get_internal_parallelism() und nicht auf get_suggested_cluster_size() setzt?
Edit: Sehe gerade, dass das Assignment schon aus oscam-emu stammt.

Ich denke der Part sollte auch überarbeitet werden:

        decrypt_packets(emu_fixed_key_data[data->connid].icam_csa_ks, packetCluster);
        if (odd_even_count > 1) // odd and even packets together cannot be decrypted in one step
        {
            decrypt_packets(emu_fixed_key_data[data->connid].icam_csa_ks, packetCluster);
        }

denn:

every call to decrypt_packets has a fixed CPU cost, so you should try to not run it with a few packets, when possible

Im worst case haben wir hier nur noch ein scrambled packet im packetCluster weil gerade von even auf odd gewechselt wurde. Also doppelte Laufzeit für ein zusätzliches packet.

wenn man sich das ffdecsa debug log vom v9-patch anschaut:

-- result: grouped 2 pkts, advanced 2 pkts <- odd/even switch
-- result: grouped 122 pkts, advanced 126 pkts
-- result: grouped 122 pkts, advanced 128 pkts
-- result: grouped 122 pkts, advanced 128 pkts
-- result: grouped 120 pkts, advanced 128 pkts
-- result: grouped 126 pkts, advanced 128 pkts
-- result: grouped 128 pkts, advanced 128 pkts
-- result: grouped 120 pkts, advanced 128 pkts
-- result: grouped 117 pkts, advanced 128 pkts
-- result: grouped 127 pkts, advanced 128 pkts
-- result: grouped 127 pkts, advanced 128 pkts
-- result: grouped 119 pkts, advanced 128 pkts
-- result: grouped 120 pkts, advanced 128 pkts
-- result: grouped 127 pkts, advanced 128 pkts
-- result: grouped 120 pkts, advanced 128 pkts
-- result: grouped 122 pkts, advanced 128 pkts
-- result: grouped 113 pkts, advanced 128 pkts
-- result: grouped 128 pkts, advanced 128 pkts
-- result: grouped 119 pkts, advanced 128 pkts
-- result: grouped 123 pkts, advanced 128 pkts
-- result: grouped 118 pkts, advanced 128 pkts

da ist also noch potential, da grouped nur zweimal dem cluster size entspricht! anders gesagt: mit 20 aufrufen von decrypt_packets() arbeiten wir 2558 packets ab.

hab beides (get_suggested_cluster_size() und das "bessere" odd/even handling) mal implementiert. hier das ffdecsa log:

-- result: grouped 30 pkts, advanced 30 pkts <- odd/even switch
-- result: grouped 124 pkts, advanced 140 pkts
-- result: grouped 128 pkts, advanced 130 pkts
-- result: grouped 128 pkts, advanced 138 pkts
-- result: grouped 128 pkts, advanced 135 pkts
-- result: grouped 125 pkts, advanced 140 pkts
-- result: grouped 128 pkts, advanced 138 pkts
-- result: grouped 128 pkts, advanced 137 pkts
-- result: grouped 128 pkts, advanced 131 pkts
-- result: grouped 128 pkts, advanced 135 pkts
-- result: grouped 128 pkts, advanced 134 pkts
-- result: grouped 123 pkts, advanced 140 pkts
-- result: grouped 128 pkts, advanced 130 pkts
-- result: grouped 128 pkts, advanced 128 pkts
-- result: grouped 121 pkts, advanced 140 pkts
-- result: grouped 128 pkts, advanced 139 pkts
-- result: grouped 128 pkts, advanced 128 pkts
-- result: grouped 128 pkts, advanced 138 pkts
-- result: grouped 128 pkts, advanced 128 pkts
-- result: grouped 128 pkts, advanced 139 pkts

mit 19 aufrufen von decrypt_packets() arbeiten wir 2568 packets ab. (den odd/even switch habe ich in beiden fällen aus der rechnung ausgenommen.)

teste bisher allerdings erst auf x64, da ich keine cross compiling toolchains am start habe. werde ich zu gegebener zeit dann machen.

jetzt erstmal noch den buffer part...

 

[el_malto]

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