Jump to content

Errors und Klötzchenbildung bei SD-Sendern in DVB-S2


GBWebmaster

Recommended Posts

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.

Link to post
  • Replies 96
  • Created
  • Last Reply

Top Posters In This Topic

  • Derrick

    33

  • GBWebmaster

    22

  • Griga

    13

  • nuts

    12

Top Posters In This Topic

Posted Images

 

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 ;)

Link to post
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.

Link to post

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 ;)

Link to post

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.

Link to post
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).

Link to post

 

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.

Link to post
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).

Link to post

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.

Link to post

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 :mad:

 

Was die samples betrifft: Ich sehe überhaupt keine artefakte. Auch nicht mit dem DVBViewer.

Link to post

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.

Link to post

Zunächst ein mal, bitte verwende andere uploads.

 

Ist der gleiche Anbieter wie Du ihn benutzt hast.

 

Selten so eine hinterhältige site gesehen :mad:

 

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.

Link to post

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.

Link to post

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.

Link to post

Ist der gleiche Anbieter wie Du ihn benutzt hast.

 

 

War auch mein Gedanke wo ich die Schnipsel gezogen hatte.

Asche über mein haupt :shocked:

 

..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 ;)

Link to post
  • 3 months later...

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.

Link to post
  • 2 weeks later...

 

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.

Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...