->DVB-T2 Pilotbetrieb in Berlin

Anzeige

AW: DVB-T2 Pilotbetrieb in Berlin

Du kennst aber die Gestalter die nichts zum Thema sagen wollen oder können aber trotzdem auftauchen um zu wimmeln ?
Wenn du anderen die Beurteilung überlassen willst, warum tauchst du hier auf. Um zu trollen ? Dann macht weiter..

 

AW: DVB-T2 Pilotbetrieb in Berlin

Aha! Ich habe mal meinen PES-Parser auf den Stream losgelassen und der mosert in zeitlicher Nähe zu den "Grauaussetzern":

Und im TS sehe ich immer wieder solche Sequenzen (Hexadezimal-Darstellung):

Code:

47 41 2D 32 00 [COLOR=red][B]40[/B][/COLOR] 00 00 01 E0 00 00
47 41 F4 30 00 [COLOR=red][B]40[/B][/COLOR] 00 00 01 E0 00 00
47 40 65 37 00 [COLOR=red][B]40[/B][/COLOR] 00 00 01 E0 00 00

Da ist ein leeres Adaptation Field (5. Byte in jeder Zeile) und danach beginnt die Payload, welche nach meinem Wissensstand laut Norm mit dem ersten Byte eines PES Packet Headers beginnen muss. Da steht aber ein Byte (0x40) zu viel, was da IMHO nicht hingehört.

Gibt es da eine Erweiterung des Standards, oder produziert der Multiplexer fehlerhafte Streams? Kann ich mir gar nicht vorstellen, dass da so ein grober Bug durchrutschen kann, denn das sollte eigentlich jeder Transport Stream Analyzer entdecken...

Edit: Ich ahne es: Die 0x40 soll vermutlich zum adaptation_field gehören und dort mit dem Bit "random_access_indicator" (eben 0x40) anzeigen, dass der Decoder im folgenden PES-Packet aufsetzen kann. Dummerweise ist die adaptation_field_length aber auf 0 gesetzt statt auf 1. Es ist also das Byte vor 0x40 fehlerhaft, das müsste 0x01 sein. Wie kann ein solcher Bug eigentlich bei einem professionellen Multiplexer durchrutschen...?

Edit 2: So, jetzt mal im gespeicherten Transport Stream mit einem Hex-Editor mittels Suchen & Ersetzen überall die Sequenz "00 40 00 00 01 E0" in "01 40 00 00 01 E0" geändert und nu spielt der MPC den Stream einwandfrei ab. Tststs...

 

AW: DVB-T2 Pilotbetrieb in Berlin

So, mit einem kleinen Hack im Treiber für den DVB-T2 Stick wird der Stream bei mir jetzt "live-gefixt".

Es ist übrigens tatsächlich nur der Fall betroffen, dass das adaptation_field nur den Wert 0x40 enthält, dann ist die adaptation_field_length 0 statt 1. In allen anderen Fällen, wo ein adaptation_field enthalten ist, hat es eine korrekte Längenangabe.

Da scheint es im Multiplexer eine gesonderte Behandlung für den Fall zu geben, dass nur random_access angezeigt werden soll, und in dieser Behandlung steckt dann offenbar ein Bug.

Hat jemand eine Idee, ob und wo man das mal melden könnte, um sicherzustellen, dass das bekannt ist und gefixt wird...?

 

AW: DVB-T2 Pilotbetrieb in Berlin

MEDIA BROADCAST GmbH
Störungshotline für leitungsgebundene Übertragungen und Rundfunk:
Telefon: 0800 330 5010 24-Std.-Service (aus Deutschland)
Telefon: +49 (0)6081 100 4270 24-Std.-Service (international)
E-Mail: service.hotline@media-broadcast.com

 

AW: DVB-T2 Pilotbetrieb in Berlin

Habe die Bildfehler bis jetzt immer auf den Decoder geschoben, aber das erklärt alles - interessanter Muxer-Bug. Hätte jetzt erstmal darauf getippt, dass die 0x40 daher kommt, dass (warum auch immer) das pointer_field eingefügt wird, das bei den SI-Daten zum Einsatz kommt.

 

AW: DVB-T2 Pilotbetrieb in Berlin

Habe eine dreiminütige Aufnahme eines s/w Film von arte HD hochgeladen. Dazu noch den Sat-Stream als Vergleich.

Die ts-Fehler sind aber mit dabei, verursacht bei mir ja auch keine Probleme.

jruhe

 

AW: DVB-T2 Pilotbetrieb in Berlin

Hast du den Hack auf -10 oder -8 gestellt ? Eigentlich live mag das nicht und nimmt fast immer +hack.

 

AW: DVB-T2 Pilotbetrieb in Berlin

Der Videostream von arte HD (Service 3) ist jetzt irgendwie kaputt, und der Audiostream scheint komplett zu fehlen. Da braucht der Live-Encoder wohl mal einen Reset...

Übrigens scheint die Ausstrahlung der HEVC-Streams bisher gänzlich ohne "Filler Data" auszukommen. Oder mein "Stripping Tool" hat einen Bug...

 

AW: DVB-T2 Pilotbetrieb in Berlin

So, ich habe jetzt endlich herausbekommen, wo der Sony-Demodulator die L1-pre Signalling data "versteckt". Die Ingenieure waren so freundlich und haben für jedes neue Feld ein neues Register angefangen, sodass der Software etwas "Bitschieberei" erspart bleibt. Das machte es natürlich unmöglich, die richtigen Register mit einer Suche nach feldübergreifenden erwarteten Bitfolgen zu finden...

Die rekonstruierten Originaldaten (die CRC_32 in den letzten 4 Bytes stimmt):

Code:

0x00, 0x8A, 0x10, 0x00, 0x01, 0x77, 0x00,
0x13, 0xE3, 0x00, 0x72, 0x01, 0x30, 0x72,
0x1E, 0x56, 0x02, 0x03, 0xF0, 0x20, 0x9F,
0x17, 0x54, 0x95, 0x44

Die interessantesten Details:

P2 Type: T2_SISO
FFT: 32k-EXT
Guard Interval: 1/16
Pilot Pattern: PP4
CELL_ID: 0x7201
NETWORK_ID: 0x3072
T2_SYSTEM_ID: 0x1E56
T2_VERSION: 1.3.1

Die L1-post signalling data habe ich noch nicht zu 100% rekonstruiert, aber dessen mutmaßliche Register geben diese weiteren Details preis:

PLP_ID: 0x00
PLP_FEC_TYPE: 64K LDPC
PLP_COD: 2/3
PLP_MOD: 64-QAM

Also kurz zusammengefasst sind die derzeitigen Übertragungsparameter auf Kanal 42 in Berlin:

DVB-T2, PP4, 64-QAM, 2/3 FEC, 1/16 GI, 32K-ext FFT

 

AW: DVB-T2 Pilotbetrieb in Berlin

Also 27,74 Mbit/s
Quelle: DVB-T(2)/-H Merkmale / DVB-T(2)/-H Characteristics