duddsig Posted September 28, 2016 Share Posted September 28, 2016 Griga's Maßnahmen für die Aufnahmen waren nach ersten Tests erfolgreich. Habe ich mir schon gedacht, daß er da was macht. Ging aber ganz schön schnell. ...und speichert den vollständigen Stream. Das dürfte es erklären. Habe wie gesagt mal den Doctor nachschauen lassen, dabei fiel mir auf, daß sogar der Vidiotext noch mit drin war. Quote Link to comment
Derrick Posted September 28, 2016 Share Posted September 28, 2016 Er braucht es, selbst wenn er es nicht braucht, weil sonst Längenangaben in den Videodaten nicht mehr zutreffen. Das fängt schon beim PES-Header an. Eine sehr gute Fehlerbehandlung könnte allerdings einiges von den Folgen unsichtbar machen. Nö, braucht er nicht. jedenfalls nicht wegen deiner Begründung. Du weisst auch, dass bei video "0" der normalfall bei PES_packet_length ist. So auch hier. Ein error concealment ist es sicher auch nicht, denn auch beim besten willen und hinsehen, kann ich keine artefakte entdecken. Der TSDoctor warnt sogar, wenn bei video längenangaben in den PES_packet_headern erkannt werden. Dann wird gefragt, ob das tool die auf 0 setzen soll. In der sog. fehlerhaften aufnahme wird vom Doc zwar wegen der disconties gewarnt, aber die "reparierte" datei korrigiert einfach die continuity counter. Danach ist davon auch im Hexeditor keine spur mehr von den fehlern zu entdecken. Sehen tut man die wie gesagt sowieso nicht. Es ist einfach ein kuriosität des encoders beim playout von diesen sendern. Und wenn es bei der live-wiedergabe ruckelt, liegt das vielleicht am source filter Quote Link to comment
Griga Posted September 28, 2016 Share Posted September 28, 2016 Du weisst auch, dass bei video "0" der normalfall bei PES_packet_length ist. Hatte ich wohl zeitweilig vergessen. Es gibt jedoch mehrere glaubwürdige Zeugenaussagen, die deiner Theorie widersprechen, und an die halte ich mich. Quote Link to comment
Derrick Posted September 28, 2016 Share Posted September 28, 2016 Wie auch immer.. Live habe ich diese sender nicht, aber wenn der stream mit den disconties alle 2, 3 s wirklich fehlerhaft wäre, liesse sich das auch nicht bei der wiedergabe einer aufnahme verbergen. Was ist denn, wenn live gestreamt wird? Da ist der source filter ja nicht involviert Quote Link to comment
duddsig Posted September 29, 2016 Share Posted September 29, 2016 Nur noch zur Ergänzung. Bei mir sind Fehler sichtbar, ich weiß aber nicht ob es jeder ist. Es ist allerdings wirklich so, daß nach der Behandlung durch den Doc, die Fehler immer noch sichtbar sind. Ein erneuter Durchlauf beim Doc propagiert Fehlerfreiheit. Quote Link to comment
Griga Posted September 29, 2016 Share Posted September 29, 2016 Was ist denn, wenn live gestreamt wird? Der Live Streamingserver des RS wirft sämtliche Pakete mit Scrambled Flag weg, sehe ich gerade. D.h. der Client erhält in dem hier behandelten Fall unvollständige Videodaten und wird dann auch Störungen zeigen. Was FFmepg bei transkodierten Streams macht, bleibt auszuprobieren. Auch hier muss also noch dafür gesorgt werden, dass die besagten Pakete nicht mehr rausgeworfen werden, nachdem ein gültiger PES Header erkannt wurde (ein Zeichen dafür, dass die Entschlüsselung läuft - ohne sind die Header ungenießbar). Quote Link to comment
Derrick Posted September 29, 2016 Share Posted September 29, 2016 Auch hier muss also noch dafür gesorgt werden, dass die besagten Pakete nicht mehr rausgeworfen werden.. Reine betriebsblindheit Ich habe noch mal die test samples von @GBWebmaster betrachtet. In dem kurzen schnipsel sind 53 discontitnuity errors im video stream, weil die gescrambelten packets geblockt werden. Spiele ich das sample im DVBViewer ab, sehe ich etwa bei fehler 6 artefakte im bild. Das ist die einzige stelle, die ich sehe, aber es könnten ev. mehr sein, weil der inhalt zu dunkel ist, um alles genau sehen zu können. Filter im DVBViewer: LAV Dasselbe stück zeigt keinerlei artefakte beim abspielen sowohl mit MPC-HC x64 als auch VLC. Schickt man den file durch den TSDoctor, zeigt die "reparierte" aufnahme auch im DVBViewer keine artefakte mehr. Ich habe die schnpsel noch mal hier hochgeladen mit der TSDoc-reparatur (fixed). Fixed ist etwas kleiner, weil der doc die SI-tabellen ausdünnt. Quote Link to comment
duddsig Posted September 29, 2016 Share Posted September 29, 2016 Schickt man den file durch den TSDoctor, zeigt die "reparierte" aufnahme auch im DVBViewer keine artefakte mehr. Bei Deinem Beispiel ist das wirklich so. Das sichbare Artefakt ist an der Stelle wo es dunkel wird. In der behandelten Datei sehe ich es auch nicht mehr. Habe es gerade noch mal mit einer frischen Aufnahme probiert, bei mir sind die Artefakte nach Erzeugung einer neuen Datei noch sichtbar vorhanden. Habe aber die Standardvoreinstellungen benutzt. Hast Du was verändert an diesen? Hier das Beispiel von mir. Die Artefakte sind bei diesem Beispiel an verschiedenen Stellen sichtbar (Microsoftdecoder von Win7). Quote Link to comment
GBWebmaster Posted September 29, 2016 Author Share Posted September 29, 2016 Mit der Anpassung von Griga sieht es bei mir wie bei @nuts sehr vielversprechend aus ... Nur als Hinweis: Solltet ihr noch Testmaterial benötigen, dürft ihr Euch gerne melden. Quote Link to comment
Derrick Posted September 29, 2016 Share Posted September 29, 2016 Hier das Beispiel von mir. Die Artefakte sind bei diesem Beispiel an verschiedenen Stellen sichtbar (Microsoftdecoder von Win7). Zunächst ein mal, bitte verwende andere uploads. Selten so eine hinterhältige site gesehen Was die samples betrifft: Ich sehe überhaupt keine artefakte. Auch nicht mit dem DVBViewer. Quote Link to comment
nuts Posted September 29, 2016 Share Posted September 29, 2016 Für die Vergleichbarkeit bei den Artefakten würde ich den LAV Videodekoder im Software-Modus empfehlen, sonst sind Unterschiede womöglich auch auf die GPU zurückzuführen. Quote Link to comment
duddsig Posted September 29, 2016 Share Posted September 29, 2016 Zunächst ein mal, bitte verwende andere uploads. Ist der gleiche Anbieter wie Du ihn benutzt hast. Selten so eine hinterhältige site gesehen War auch mein Gedanke wo ich die Schnipsel gezogen hatte. Was die samples betrifft: Ich sehe überhaupt keine artefakte. Auch nicht mit dem DVBViewer. Sie sind nicht so massiv, aber sichtbar zumindest mit dem MS-Decoder. Mit dem LAV sehe ich in diesem Fall tatsächlich auch keine. Mit dem CyberLink ist es gleich mal ganz schlimm. Da bleibt gleich mal das Bild ganz stehen bei der unbehandelten Datei. Bei der behandelten sehe ich wieder Artefakte. Quote Link to comment
nuts Posted September 29, 2016 Share Posted September 29, 2016 Der MS Dekoder verwendet bestimmt DXVA. Sieht es mit LAV und aktiviertem DXVA native anders aus? Der Cyberlink verhält sich da ganz komisch, ich meine mir hatten das intern auch schonmal. Den zu debuggen bringt aber eh nix. Quote Link to comment
duddsig Posted September 29, 2016 Share Posted September 29, 2016 Der MS Dekoder verwendet bestimmt DXVA. Ja, da keine Sytemlast. Sieht es mit LAV und aktiviertem DXVA native anders aus? War genau so eingestellt. Mit meiner Testdatei keine Artefakte. Der Cyberlink verhält sich da ganz komisch, ich meine mir hatten das intern auch schonmal. Den zu debuggen bringt aber eh nix. Na ja, war halt mal interressant wie unterschiedliche Decoder damit umgehen. Quote Link to comment
Derrick Posted September 29, 2016 Share Posted September 29, 2016 Ist der gleiche Anbieter wie Du ihn benutzt hast. War auch mein Gedanke wo ich die Schnipsel gezogen hatte. Asche über mein haupt ..je mehr tests ich mache, um so unübersichtlicher wird es. Streaming zu meinem Samsung smart tv zeigt an mehreren stellen artefakte. Der MPC-HC x64 zeigt überhaupt keine artefakte. Fazit: Die sonderbehandlung der verschlüsselten pakete mit 182 bytes adaptation field kann ja nicht schaden. Besser allerdings, wenn die firmware der grauen CI-module verbessert wird. Und am besten, wenn Sky mal am encoder drehen würde Quote Link to comment
duddsig Posted January 1, 2017 Share Posted January 1, 2017 Und am besten, wenn Sky mal am encoder drehen würde Sie haben gedreht. Habe mir gerade einen Aufnahmeschnipsel von gestern angesehen. Den habe ich vorsorglich durch den Doc gejagt, was aber nicht nötig war, weil die Aufnahme 0 Fehler hatte. Zum Vergleich noch eine Aufnahme von Anfang Dez gesichtet, da war der Fehler auch schon weg. Sky hat ja den Uplink oder/und Playout nach Italien umverlegt, da haben sie das wohl gleich mit erledigt. Quote Link to comment
CiNcH Posted January 13, 2017 Share Posted January 13, 2017 Ich habe mal in unser internes Archiv durchsucht. Vor ein paar Jahren (2012) gab es den Fall bereits, und damals hatte ich das Problem im DVBViewer Filter gelöst - er toleriert unter bestimmten Bedingungen die Scrambling Flags. Kann ich mich noch gut dran erinnern. War damals bei ORF HD Sendern so mit dem großen Adaptation Field und dem kleinen Payload. Muss die applikation schlechte programmierung von CAMs kompensieren? Der Problemkandidat ist das AlphaCrypt und keine schlecht programmierte Firmware (passiert auch mit der originalen von Mascom), sondern ein Problem des Descramblers, der einfach bei Paketen mit Payload < 8Byte, welche per Standard unverschlüsselt sind, die TSC-Bits nicht zurücksetzt. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.