TT S2-3200 und DiabloCam

[Derrick]

Es wurde mit der dem TT-API beiliegenden BDA-API-Demo gecheckt, ob TS Pakete verloren gehen. Das war nicht der Fall (der DVBViewer zeigt ja auch keine Diskontinuitäten an).

Wenn das das einzige ist, was sie gecheckt haben, ist der test für die tonne. Im prinzip gehen pakete überhaupt nicht verloren. Sie können allerdings schon beim empfang als fehlerhaft aussortiert werden. Für die anwendung fehlen sie dann -> discontinuities. Im CAM gibt es diese möglichkeit nicht. Alles was reingeht, kommt auch wieder raus. Klar können da fehler drin sein, aber es fehlt nichts.

 

Beobachtungen:

Im Falle des Ausbleibens von Bild und Ton zeigt der DVBSource-Filter wirre Daten an, z.B. einen Videostream mit sehr sprunghaften Datenraten und Timestamps.

Hier würde ich vermuten, dass das modul einen verwürfelten stream nicht korrekt entwürfelt oder vielleicht auch nur das scrambling flag auf entschüsselt setzt. Dann wird der source filter in die irre geleitet. Auflösung und AR könnten noch vom vorherigen sender stammen. Bitrate kann gemessen werden. PTS könnten von fake PES_headern stammen oder von ein paar richtigen paketen und die PCR ist nicht verschlüsselt.

 

Du könntest ja mal versuchen, ein kurzes stück davon aufzunehmen.

[CiNcH]

Also die Aufnahmen sind auch komplett verhunzt. Meist wird zwar was geschrieben, aber um das genau anlysieren zu können fehlt mir in diesem Bereich das Wissen. Vielleicht könnte man am ehensten was in einem TS-Dump erkennen!?

 

Komisch ist halt, dass der -debug Parameter da Einfluss hat und das Schalten mit einer S-1500 und gleichem Treiber absolut stabil ist.

[Derrick]

Mit aufnahme meine ich TS. Dass man den nicht gucken kann, ist mir schon klar Es müssten allerdings die gleichen verhältnisse hinterm cam herrschen. Ob das z.b. mit dem analyzer von transedit der fall ist, weiss ich nicht, da dabei der cam-kram ignoriert wird. Vielleicht mit dem videorecorder plugin..

[CiNcH]

Werde das heute Abend mal mit dem VideoRec-Plugin anschauen und ggfs. einen kleinen TS-Dump nach fehlgeschlagenem Schalten hochladen.

[Derrick]

Eine aufnahme ist wohl nicht nötig. Ich kann den fall mit meinem schrottmodul Matrix Reborn und meiner Canal Digitaal karte gut simulieren. Gehe ich damit z.b. auf einen spanischen C+ kanal, erscheint der stream als clear, obwohl das natürlich nicht stimmt. Der source filter lässt sich wie oben beschrieben täuschen. Nur audio wird anscheinend wegen der festen framestruktur verworfen.

 

Hier ein bild vom source filter. Vorher war Das Erste eingestellt (720x576, 16:9, 25fps). Die streamrate ist von einem taquillakanal. Ebenso die PCR. PTS werden offensichtlich falsch erkannt. Den stream habe ich mit netstreaming plugin zum TSReader gestreamt. Grün ist clear Der tsreaser lässt sich bei den streams nicht hinters licht führen, da dauernd geparst wird.

 

Das sind allerdings nur die symptome. Warum dein modul einen sender, für den eine berechtigung vorhanden ist, falsch entschlüsselt, muss noch geklärt werden.

[CiNcH]

Hmmm, also das Problem besteht bei mir ja auch beim Schalten auf unverschlüsselte Kanäle. D.h. die Streams sind da "clear", der DVB Source nimmt sie trotzdem nicht. Außerdem ist es nicht reproduzierbar, einmal geht das Tunen einer Frequenz, einmal nicht...

Edited April 10, 2008 by CiNcH

[CiNcH]

Die Analyse mit dem TSReader werde ich auch mal machen. Ich nehme an, du verwendest da die TCP/UDP-Input-Source!? Werde ich am Abend mal probieren...

 

[EDIT]

Aha, du hast das HTTP-Source-Plugin verwendet . Na mal schauen. URL wird wohl die IP sein, auf der das netstream plugin horcht!?

Edited April 10, 2008 by CiNcH

[CiNcH]

So, sehr interessant...

 

 

So wie es aussieht, liegen die Daten vollständig an nur keiner kann was damit anfangen. Das VideoRec-Plugin scheint PAT/PMT korrekt auszulesen und zeigt die Kanäle auf dem Transponder an.

 

Hier der TS-Dump von RTL II mit VideoRec-Plugin:

http://bleedingme.dyndns.org/RTL2_04-10_17-50-15.txt

http://bleedingme.dyndns.org/RTL2_04-10_17-50-15.ts

 

Achtung! Das ist mein privater Server. Der läuft momentan nicht 24/7 und die Anbindung ist nicht die schnellste. Sind aber eh nur 11 MB.

Edited April 10, 2008 by CiNcH

[Lars_MQ]

Alles bis auf die PMT. ziemlich schlecht.

[CiNcH]

Hmm, VideoRec-Plugin zeigt ja die Kanäle bzw. die Streams der Kanäle, also muss es PAT/PMT irgendwie haben!? Oder klaut der die Infos wo anders?

 

Wie man sieht hat PAT auch CRC-Fehler bzw. alle Pakete haben das, die der TSReader identifizieren konnte.

Edited April 10, 2008 by CiNcH

[CiNcH]

Ich frage mich die ganze Zeit, welchen Einfluss der -debug Parameter haben könnte. Es ist damit definitiv sehr viel stabiler. Evtl. dass der PMT ein paar ms später an den Treiber geschickt wird!? Aber dann müssten zumindest die FTA's problemlos gezappt werden können, wenn 'Send only encrypted Channels to CI' aktiviert ist, das ist aber nicht der Fall.

 

Auf dem ORF-Transponder erkennt der TSReader sogar, dass Komponenten verschlüsselt sind (rot), auch wenn er sonst mit dem Stream nichts anfangen kann.

 

So wie es aussieht, klappt nur fast genau jeder 2. Frequenzwechsel.

[Lars_MQ]

welche viewer version verwendest Du denn zum testen? die betas haben alle -debug automatisch aktiviert.

[CiNcH]

Die 26 Beta, wo du das deaktiviert hast (bzw. bei der Version, die du mir gemailt hast...). Das ist keine Einbildung, das ist 100% sicher und reproduzierbar, dass der -debug Parameter hilft .

 

Kann man davon ausgehen, dass die ES-Komponenten fehlerfrei anliegen, wenn der TSReader erkennt, dass die verschlüsselt sind?

Edited April 10, 2008 by CiNcH

[Derrick]

Sehr merkwürdig.. ..es sind keine zufälligen fehler, weil alle ts_packet_header intakt sind. Die PMT ist unleserlich und anscheinend gescrambelt. Die PAT stimmt auch nicht. Komisch ist, dass fast alles falsch ist, aber die transport stream_id stimmt. Bei video und audio sind die pes_packet_header zumindest zum teil ok sind (audio z.b. 00 00 01 C0).

 

Mein vorläufiger eindruck ist, dass das modul alles im pes_mode gescrambelt hat (normal ist ts). Das würde auch die korrekte TID (0x0441) erklären, weil die vorne steht und jede section mit payload start indicator 1 anfängt. Nochmal geguckt und siehe da, der beginn der PMT stimmt auch noch. Sehr witzig

 

Vielleicht kann man dem modul ne andere firmware verpassen

[CiNcH]

Aber das ist doch unverständlich wieso das Modul mit der S-1500 keinerlei Probleme bereitet (selber Treiber, selbes CI, unterschied ist das Frontend) und dass der -debug Parameter beim DVBViewer etwas bewirkt. Firmware hab ich schon alles durch.

Edited April 10, 2008 by CiNcH

[Derrick]

..vielleich sabotiert @Lars dein cam Ich habe keine ahnung, ausser dass es nicht zufällig scheint, was das modul macht.

[CiNcH]

Ja, und TT auch, mit dem TT-Media Center ist das Phänomen nämlich dasselbe .

[CiNcH]

http://www.digitalfernsehen.de/news/news_290306.html

 

Nun wisst ihr auch, wieso ich Alternativen teste, auch wenn ich hoffe, dass das AlphaCrypt weiterhin funktionieren wird, was ich für wahrscheinlich halte, da man mittlerweile schon mit Angabe des AlphaCrypts ohne Probleme ein Abo abschließen kann. Aber vielleicht ist Premiere auch nur so in Abonöten, dass das akzeptiert wird.

Edited April 15, 2008 by CiNcH