Im DVBViewer forum gab es ein problem, das ich mithilfe des TSD lösen konnte :D
Es geht um diesen stream: http://www.dvbviewer.tv/forum/topic/56279-strange-problem-with-rstp-steaming-with-dvbviewer-as-client/?p=425485
Der grund für mein posting hier, ist dass der TSD streams als (teilweise) scrambled ansieht, obwohl im gesamten file kein einziges ts_packet verwürfelt ist. Hier der log:
Danke Derrick ;D
Schön, dass der TS-Doctor helfen konnte.
Die Jungs vom DVBViewer sind ja schon viele Jahre länger in Geschäft wie ich, da ist schon ein gutes Gefühl, dass der TS-Doctor etwas besser im Griff hat als der DVBViewer.
Trotzdem bin ich ein großer Fan vom DVBViewer. Weiter so...
..hääte ich gleich den richtigen analyzer genommen, wäre der TSD nicht nötig gewesen, aber wer rechnet denn mit sowas :o
Diese topic geht aber über die scheinbar scrambled streams. ;)
Hatte eher den Eindruck der zweite PCR-Stream hätte die Probleme bereitet.
Offenbar sind die meisten Pakete ja als "scrambled" markiert obwohl sie es nicht sind. Das ist für jede Software schwer zu erkennen.
ZitatDas ist für jede Software schwer zu erkennen.
Ich dachte, der TSD wertet das TSC (Transport Scrambling Control) field aus. Im ganzen file ist nicht ein einziges Paket als verschlüsselt markiert. Wieso saugt er sich Doc dann sogar noch %-Angaben aus dem Finger, oder woher stammt das? ???
Der Doc wertet das scrambling_control_bit schon aus, kann es aber problemlos ignorieren.
Wenn er das auswertet, warum werden die streams als scrambled angesehen? Da ist nix gescrambled.
Ok, so funktioniert das bei DVB-Stream:
Der Sender verschlüsselt Aufnahme und setzt das scrambling_control_bit.
Receiver empfängt die Pakete, die als "scrambled" markiert sind und weiß, dass diese erst entschlüsselt werden müssen.
Über Cam und Karte werden die Daten entschlüsselt und das Cam-Modul sollte nach der Entschlüsselung das scrambling_control_bit löschen, da die Daten ja nun entschlüsselt sind.
Das machen aber besonders "Softcams" nicht immer oder nicht sofort.
Die Auswertung ist also nix anderes als das scrambling_control_bit zu beachten.
Schreibe ich chinesisch? ??? Obwohl, das würde ja sofort auffallen ;)
Ich will von dir nicht erklärt haben, wie das scrambling flag funktioniert. Der TSDoctor schreibt Unsinn in den log!!
Zitat von: Derrick am April 05, 2015, 10:36:04
Schreibe ich chinesisch? ??? Obwohl, das würde ja sofort auffallen ;)
Nein, nicht chinesisch. Aber deutsch Lesen war auch noch nie Deine Stärke. Gewöhn Dir doch an, die Anworten der Leute bis zum Ende durchzulesen und nicht immer schon beim ersten Satz, der Dir nicht in den Kram passt, abzubrechen und zu meckern.
Les Dir seine Antwort mal richtig durch, vielleicht nascht auch Du dann irgendwann vom Baume der Erkenntnis...
bevor du dazwischenblubberst, lade dir erst mal das sample runter und gucke in den log. Vielleicht hast du dann ja eine erklärung, warum der tsdoc im log was von scrambled faselt :P
ein paar der Streams in der Datei sind verschlüsselt, ich kann dir aber nicht sagen, was da drin ist (scheinen eher unwichtig zu sein)
ich schätze, dass der Player einfach direkt aufgibt, als er merkt, dass der erste Stream in der Datei verschlüsselt ist (er gibt sich nicht die Mühe nachzusehen und festzustellen, dass die Datei unverschlüsselte Audio- und Video- und Untertitelstreams enthält
alle anderen werden vom jedenfalls TSD erkannt und ggf. übernommen (alles außer Bild, Ton und Untertiteln fliegt raus)
so lange der Typ aus dem Thread also keine Audiospur vermisst, sollte eigentlich alles da sein
außerdem müssen die Streams ja auch nicht vom FTA Sender kommen, sondern können auch zwischendurch eingefügt worden sein (bei der Übertragung vielleicht, eventuell hat auch ein Glied in der Übertragungskette die scrambled bits nicht korrekt entfernt und die Streams sind eigentlich lesbar, ka.)
hab den Thread nur überflogen, wenn ich was übersehe oder es mir genauer ansehen soll sag Bescheid ;)
Zitat..hab den Thread nur überflogen, wenn ich was übersehe oder es mir genauer ansehen soll sag Bescheid
..lass mal lieber. Dein 1. Satz ist schon falsch. Da ist nichts verschlüsselt, aber das habe ich hier bereits mehrmals wiederholt. :'(
OK, nochmal ganz langsam.
Der TS-Doctor checkt die einzelnen Streams in mehreren Stellen und überprüft das "Scrambled"-Flag. Das ist nur ein Bit !!!
Im Log erscheint die hochgerechnete Menge an "als verschlüsselt markierten" Paketen.
Ob die Pakete tatsächlich verschlüsselt sind oder das dumme Cam-Modul nur vergessen hat das Flag zu löschen, kann der TS-Doctor nicht herausfinden!!!!!!!
OK?
Auch wenn die Pakete nicht mehr verschlüsselt sind aber das "Scrambled"-Flag gesetzt ist, wertet der TS-Doctor dieses Paket als verschlüsselt und zeigt dies im Log an.
Zitat von: Cypheros am April 07, 2015, 01:18:36
OK, nochmal ganz langsam.
Gibs auf, Lesen ist echt nicht seine Stärke. Und wenn sein geliebtes Transedit ihm nicht sacht, dass da son dummes Bit in der Gegend rumhängt, dann glaubt er Dir eh nicht.
ZitatDer TS-Doctor checkt die einzelnen Streams in mehreren Stellen und überprüft das "Scrambled"-Flag. Das ist nur ein Bit !!!
Da tun sich ja Abgründe auf :o Siehe screen shot aus der Bibel (ISO 8138-1) ;)
Vielleicht können wir das Verfahren abkürzen, und Cypheros oder einer seiner Adepten zeigt mit einem Hexeditor ein einziges ts_packet aus dem sample, das verschlüsselt ist. Angeblich sind ja 60-70% der "unbekannten" Streams - es handelt sich MHP, was den TSD nicht zu interessieren braucht - verschlüsselt. Den log vom TSD habe ich eigentlich meist ignoriert, weil überladen und unübersichtlich. In diesen Fall habe ich eine Ausnahme gemacht und den fehler gesehen. Deshalb überhaupt meine Frage.
och Birne, nun mach doch endlich mal den Kopf zu, und, wenn Du schon mit irgendwelchen Definitionen rumsültzt, solltest Du sie vielleicht mal LESEN ! (aber ok, wir wissen ja nun zur Genüge, dass Dir dafür wohl einfach die Zeit fehlt) Aber so ist das nun mal mit Bibeln, jeder hat sie, keiner liest sie...
Bei genauerer Betrachtung hättest Du finden können:
Scrambling control 2 0xc0 '00' = Not scrambled.
For DVB-CSA only:[11]
'01' (0x40) = Reserved for future use
'10' (0x80) = Scrambled with even key
'11' (0xC0) = Scrambled with odd key
Also, nur weil etwas 2 Bit lang ist, müssen diese nicht auch wirklich benutzt sein! Hier ist es wohl eindeutig, nur das erste Bit ist aussagekräftig, OB etwas verschlüsselt ist, das zweite Bit spezifiert nur noch, WIE.
Und dazu gilt sogar noch das "Mischmaschverbot", das heißt, das vordere Bit MUSS 1 sein, wenn verschlüsselt.
..wo ist das verschlüsselte Paket?
Traut sich keiner? :D
Ich habe PID 0x0038 von dem Sample extrahiert (Anhang). Es sind exakt 10492 ts_packets. Laut log vom TSD sind davon 60% (PES WARNING: PID 0038 scrambled 60,00%) verschlüsselt. Das wären 6295 verschlüsselte Pakete. Ich sehe aber nur Nullen beim TSC.
/edit der zip ist zu gross, aber das kann ja jeder selber extrahieren ;)
OK, hab mir die Datei mal runtergeladen und angeschaut. Die Scrambled-Anzeige liegt nicht an den TS-Paketen.
Die Verschlüsselung wird auf PES-Paket-Ebene erkannt, da kein PES-Startcode 00 00 01 gefunden wird trotz Payload-Start, was auf verschlüsselte oder kaputte PES-Pakete hinweisen könnte.
Allerdings scheint es hier so zu sein, dass DSM- und ECM-Stream in der Aufnahme sind, die der TS-Doctor bisher nicht kannte und ignoriert hat.
$0038: DMS-CC(DDM)
$0039: DMS-CC(DDM)
$003A: DMS-CC(DDM)
$0037: DMS-CC(DDM)
$0036: DMS-CC(DDM)
$1F74: DMS-CC(DDM)
$0C81: PES
$00C8: PMT
$0C82: PES
$0000: PAT
$07D2: ECM
$089A: ECM
$1F73: AIT
$0836: ECM
$0C84: PES
Die nächste Version sollte diese Streamtypen im Log aufgelistet bevor sie gelöscht werden.
Zitat..was auf verschlüsselte oder kaputte PES-Pakete hinweisen könnte.
..zumindest im Konjunktiv. Obwohl eigentlich müsste das Urteil lauten, dass sich der TSD das aus den Fingern gesaugt hat.
Hoffentlich liest das auch dein Brüllaffe.. :D