Info: NULL-PACKETS bei KDG (genug Platz für weitere Sender)

[CAID1801]

@ aseidel

Mit TransEdit kann man die Werte auch sehr gut ablesen.

Wieso "auch"?

Die obige PAT Analyse von SAT-1 ist eine 101% exakte Kopie direkt aus TransEdit.

Für solche Analysen ist TransEdit vom Preis-Leistungsverhältnis immer noch unschalgbar. Selbst wer DVBViewer hasst, kann ihn ja in die Tonne werfen und die 15 Euro als "Kaufpreis" von TransEdit ansehen

Alle anderen Streamanalyser sind weitaus teurer. Von Scherzen wie Dongle geschützt ganz zu schweigen. OK, TS Reader ist preislich noch tragbar. Wenn man mit den Restriktionen leben kann, ist die kostenlose TS Reader LITE version auch OK.

Aber für solch einfache Analysen ist TransEdit unschlagbar. Schade nur, dass der Programmierer sich nicht an die Analyse der ECM/EMM Streams rantraut. Für uns Kabel User, die ja selbst freie Programme wie RTL pder SAt-1 nur verschlüsselt erhalten, ist TransEdit leider oft unbrauchbar ...


@ Knidel

Ein normaler Sat-Transponder (Symbolrate 27,5 MS/s) hat z.B. etwa 100 Kbit/s weniger Kapazität als im Kabel (bei 64QAM, SR 6,9 MS/s).
Aber da kommen diese Mengen an Nullbytes nicht her.

Yep!

20% Null-Packets auf einem 50 Mbps Transponder sind keider keine "etwa 100 Kbit/s " sondern rund 10.000 Kbps ... die sinnlos verschwendet werden.

Die einfachste Erklärung wird wohl sein: KDG hält sich hier einige Reserven frei. Sobald der nächste zahlungskräftige Shopping-Kanal seine Rechnung bezahlt hat, kann KDG ihn sofort auf einen Transponder aufschalten OHNE auch nur das geringste an den anderen Streams des Transponders ändern zu müssen.

OK, "sofort" muss bei KDG natürlich "am daraffolgenden Mittwoch" heissen

[CAID1801]

@ ALLE

Eine grosse Bitte an Euch:

Es wäre für die Mitleser äusserst hilreich, wenn wir nicht ständig die Begriffe "Null-Packets" und "Null-Bytes" durcheinander werfen würden.

"Null-Packets" sind etwas VÖLLIG anderes als ""Null Bytes"!

Hier ein Beispiel:

Code: Alles auswählen

47 1F FF 1E 67 6B 08 EB EB D4 D2 DD 62 ED 1D 81
62 A4 A5 93 9F D0 3F 34 50 4C 83 4C 46 2A 76 F9
36 AC 40 39 B7 71 E1 4D 64 6E 3C 2C AC 8C 8D 85
C5 85 85 15 95 B0 B1 B8 B2 F2 A2 26 B2 32 1E 17
1C 46 16 D6 F6 67 EF 8A CB C2 58 98 ED 68 F5 7F
13 4A C5 0B DB 37 1E 84 56 63 E2 CB C0 88 98 5C
C8 D8 74 58 52 01 5B DB AB BE A2 47 2A 2A BB 21
04 41 FC E7 03 3F F1 36 7C 50 0C 13 5C E3 0E 7E
FA 7C BC 94 29 A3 DD C4 4F 35 64 AC CC 1D 95 60
A1 8D 16 DF A0 65 A8 A6 5E 87 24 E3 38 8E F7 AD
5F FB F2 BE F4 B5 3F 3B DA 4F 7E D8 BE B4 61 2F
8F 76 43 3C 83 B6 A6 15 3B 36 9B 44

47 1F FF 1F 34 18 7A 91 D1 AE A8 37 08 A2 53 C6
2F A9 F8 4A D2 1D DE DC B3 F5 6A 65 4F B2 66 8C
02 91 E7 5E A5 E6 EB CD 88 DB 06 D8 88 44 6C FE
6C 19 98 21 AA C7 D6 1B 85 D5 29 81 1F CC BA 33
48 07 4B 6E 23 B2 AB 54 30 7C 5B 80 11 A8 FB B6
90 E5 36 E7 78 2B EF 05 53 E0 A1 A0 16 D4 BA 67
78 12 EF 0B 61 E3 31 44 F5 CC 4B 67 75 B0 EC 78
A5 39 27 FB C4 4E F9 64 DC 54 01 52 57 A9 CE BA
DF CC 3D B3 68 E8 43 14 3F BC D8 6F B0 54 CC 8A
65 44 72 64 6B 82 2D C8 70 D6 73 2B CF D3 5B 94
8F AD F5 0B D9 57 1E 18 96 45 EB 42 0E F9 F8 5C
72 18 5B 9D D9 AF B2 27 4C 12 62 63

DAS sind 2 echte Null-Packets.

0x47 = Start of Packet

0x1F 0xFF = PID 0x1FFF

0x1FFF ist laut DVB Spezifikation ein sogenanntes "Null-Packet", dessen einzige Aufgabe darin liegt, die Datenmenge eines -Mux auf den korrekten Wert auszugleichen, falls die echten Nutzdaten (Payload) zu wenig ist.

Das nächste Byte - im 1. Packet 0x1E, im 2. Packet 0x1F) ist der Kontinuitätszähler. Er läuft innerhalb jedes Streams für jede PID ständig von 00 bis 1F und ermöglicht so dem Stream Parser und Decoder festzustellen, ob ALLE Packets einer PID lückenlos empfangen wurden.

Ignorieren wir mal ein paar Status-Bits (Encrypted-Flag, Payload-Flag usw.) kann man sagen dass der grosse Rest der Bytes eines Null-Packets einfach Datenmüll sind.

So, nun sucht mal, wieviele "Null-Bytes" Ihr in den Null-Packets" findet.

Wer eines findet, darf's behalten


"Null-Bytes" gibt es schon - sogar eine ganze Menge aber aus völlig anderen Gründen. Im Gegensatz zu den von mir angesprochenen "Null-Packets" sind die "Null-Bytes" sogar fast immer unverzichtbar um die DVB Spezifikation zu erfüllen.

PS: Für TransEdit User:

Um Null-Packets dumpen zu können, müsst Ihr in TransEdit den Haken für "Payxload" entfernen - Null-Packets sind ja genau das Gegenteil von Payload

[nylz]

Hallo, wie schon in der Beschreibung beschrieben:

bei einigen Hardwaresystemen muss eine konstante Bitrate gegeben sein. Nicht alle Receiver können variable Daten empfangen.

Das ist schlichtweg der Grund dafür!

Übrigens sind gerade die KDG-Receiver, die billig zusammen gekloppt wurden, betroffen.

[CAID1801]

Hi nylz,

Das ist schlichtweg der Grund dafür!

Der "Grund" ist seit über 10 Jahren bekannt (DVB-Spezifikation)

Die DVB-Spezifikation zwingt aber in keinester Weise einen Provider TerraBytes von Nüll jeden Tag auszuliefern.

Statt des Mülls könnte KDG die betroffenen Transponder auch mit Payload auffüllen. Dieser Payload könnten z. B. Sender sein, die bei den meisten anderen Providern selbstverständlich geliefert werden, bei KDG aber fehlen.

Dreambox C 800 HD
(ja ich habe nur eine Box, aber ich habe noch ein Leben neben dem TV *G*)

Ja, absolut verständlich. Die Unmenge täglich erscheinender Updates von diversen Enigma 2 Versionen, OpenPLI, Experimental ...usw. usw... Releases für die Dreambox lassen ja echt keine Freizeit mehr um auch noch TV zu schauen
(Sorry, couldn't resist)

Aber hast schon recht. Ich merke auch gerade, dass ich seit gestern viel zu viel Zeit hier im KDGForum verbringe. Sollte ich schleunigst wieder ändern