Asynchronität nach fehlerhaften Stellen im TS bei Weiterverarbeitung

[cpw]

Hallo zusammen,

mein Problem ist nicht ganz trivial, ich versuche mal, meine Vorgehensweise so verständlich wie möglich zu beschreiben:

Grundsätzlich reencode ich die Videospuren sämtlicher DVB-Aufnahmen (DVB-S aus einem yaVDR), um am Ende saubere, standardkonforme, ggf. deinterlacte, korrekt getaggte H.264-MKVs mit originaler Audiospur (in der Regel AC3 2.0 oder 5.1) zu erhalten. Das kostet zwar einiges an Rechenzeit, dafür löst es allerdings auch diverse Probleme auf diversen Abspielgeräten: U.a. macht der Deinterlacer im XBMC z.T. Probleme, Spulen und/oder Vor- und Zurückspringen in einem Original-TS kann manchmal problematisch sein etc. etc.

Das Ganze habe ich mit einem per Batch aufgerufenen PHP-Skript nahezu vollständig automatisiert, vom (per TSDoctor geschnittenen) TS bis zum fertigen MKV sind nur drei Schritte nötig: Kopieren des TS (bzw. auch mehrere auf einmal, beliebig viele) in ein "INPUT"-Verzeichnis, Aufrufen einer Batch-Datei und kurz danach Aufrufen eines im vorherigen Schritt generierten Encoding-Batches. Anschließend werden die Videos automatisch indiziert, demuxt, encodet und als MKV gemuxt. Die fertige MKV-Datei liegt dann in einem "OUTPUT"-Ordner.


Der komplette Ablauf ist wie folgt:

Zunächst schneide ich den aufgenommenen TS mit TSDoctor, dabei entferne ich für mich überflüssige Streams (Untertitel, ggf. weitere Audiospuren).

Alles weitere läuft nahezu vollständig automatisiert:

1. Zunächst wird DGIndexNV gestartet, um einen Index für das H.264-Video in der TS-Datei zu erstellen und den Audiostream zu demuxen. Dabei wird ein Logfile angelegt, aus dem ich später diverse Informationen parse (u.a. Auflösung und Framerate).

2. Anschließend rufe ich nochmals TSDoctor mit der CLI-Option "AUTOCHECK" auf, so dass ich aus dem hier generierten Logfile das Audio-Delay entnehmen kann. Interessanterweise ist dieser Schritt notwendig, da das Delay, das DGIndexNV im Schritt zuvor angibt, in der Regel nicht korrekt ist  -  das vom TSDoctor angegebene Delay stimmt offenbar immer.

3. Nun erzeuge ich ein AVISynth-Skript und lade hier die von DGIndexNV erzeugte DGI-Datei. Dieses Skript beinhaltet ggf. Deinterlacing (QTGMC), falls der ursprüngliche Name der TS-Datei "[interlaced]" beinhaltet  -  eine wirklich zuverlässige Möglichkeit einer automatischen Erkennung habe ich noch nicht gefunden.

4. Im vorletzten Schritt wird ein Batch erzeugt, das x264 und später mkvtoolnix mit passenden Parametern aufruft, um das Video zu encoden und später mit der (in Schritt 1 von DGIndexNV demuxten) AC3-Datei zu muxen.

5. Der letzte Schritt erzeugt eine "globale" Batch-Datei, die wiederum die einzelnen in Schritt 4 erzeugten Batches aufruft.


Führt man nun die letzte Batch-Datei aus, landen die fertigen MKVs in einem "OUTPUT"-Ordner.


Nun zum Problem:

Sind die ursprünglichen Aufnahmen fehlerfrei, funktioniert das alles ganz wunderbar; Im Output-Ordner landen perfekte, synchrone MKVs.

Problematisch wird es, falls die Aufnahme Fehler enthält, was leider seit der Umstellung von Astra 28,2° E auf einen UK-Spotbeam bei z.B. BBC und Channel 4 öfters passiert: Manche Fehler (nicht alle, "kleinere" sind offenbar kein Problem oder erzeugen nur minimale, nicht störende Delays) führen dazu, dass Bild und Ton im später erzeugten MKV ab der fehlerhaften Stelle asynchron sind  -  entweder die Videospur ist zu lang oder die Audiospur zu kurz.

Nach einigem Hin und Her hatte ich hier bis vor kurzem eine relativ simple, einigermaßen praktikable Lösung für dieses Problem: VideoReDo TVSuite konnte die Asynchronität mit einem "Quick Stream Fix" (mit Hinweisen auf entfernte Video- und Audio-Resync-Frames) beheben  -  die hieraus resultierende TS-Datei in mein Skript gesteckt ergab ein absolut korrektes, synchrones Resultat. Der einzige Wermutstropfen: Das Audio-Delay dieser Datei wird vom TSDoctor immer als 0 erkannt (Schritt 2), somit musste ich zunächst per TSDoctor ein Log der Original-Ausgabe erstellen, das Delay lesen und diesen Wert anschließend für mkvtoolnix manuell anpassen. Außerdem erzeugten diese gefixten Dateien im TSDoctor beim Öffnen die Meldung "PES Längenangabe im Videostream entdeckt", die man erst manuell wegklicken musste.

Das Problem: Das funktioniert so leider seit einigen Updates von VideoReDo nicht mehr  -  oder seit einigen Updates des TSDoctor, schwer zu sagen. Auf jeden Fall hilft ein "Quick Stream Fix" nichts mehr, das endgültige Resultat ist wieder ab/nach der fehlerhaften Stelle asynchron.

Mein absoluter Notbehelf: Zunächst asynchrones MKV erstellen, AC3-Stream demuxen, demuxtes AC3 in ein WAV umwandeln (respektive mehrere Mono-WAVs im Fall von 5.1), die fehlerhafte(n) Stelle(n) lokalisieren, Werte zwischen 50 und 500 ms raten, per Audacity Stille in entsprechender Länge einfügen, per AC WAV wieder zu AC3 wandeln, per mkvtoolnix muxen, feststellen dass das geratene Delay nicht passt, das Ganze wieder von vorne, bis es irgendwann passt... insbesondere bei AC3 5.1 mit sechs zu bearbeitenden Mono-WAVs und mehreren Fehlversuchen natürlich ein Heidenspaß...

Übrigens: Die Asynchronität tritt beim direkten Abspielen (z.B. per MPC-HC, VLC oder XBMC) des von TSDoctor erzeugten TS nicht auf, d.h. offenbar sorgt der TSDoctor mit einem Index/Flag/hastenichtgesehen im Container dafür, dass die gängigen Decoder in den Playern wissen, was zu tun ist, packt jedoch scheinbar die Streams selbst nicht an, so dass hier beim Demuxen und/oder späterem Muxen (neu encodeter Video- und originaler AC3-Stream) ein Problem entsteht.

Mittlerweile habe ich so ziemlich jede Option durch: Verwenden von TSDoctors eigenem TS-Re-/Demuxer, de-/remuxen des geschnittenen TS mit TsRemux, tsMuxeR und ffmpeg... hilft alles nichts, das Resultat ist immer asynchron  -  hier dann übrigens z.T. auch die remuxten TS-Dateien ohne weitere(s) Bearbeitung/Reencoding.

Irgendeine Idee? Grundsätzlich würde es vermutlich helfen, den AC3-Stream irgendwie passend mit Stille zu patchen  -  aber wie und womit? Der TSDoctor tut das ja offenbar nicht?


Gruß

Christian



Nachtrag:

Ich habe gerade nochmal den TS Remuxer (für TS in Verbindung mit dem tsMuxeR 2.6.12, für MKV mit MKVToolNix 7.2.0) probiert: Ja, offenbar fügt der AC3-Frames ein, allerdings viel zu viele, das Problem wird deutlich schlimmer. Aus ~300 ms Asynchronität werden ~1,5 Sekunden. Abgesehen davon nörgelt der TSDoctor beim Öffnen dieser remuxten Datei, dass eine PES-Längenangabe existiere.

[Djfe]

der Doc fixt normalerweise die Timecodes, sodass keine Probleme entstehen sollten (VLC etc. haben ja keine Probleme)

einfachste und deutlich schnellere Lösung:
mit TS Doctor Datei schneiden und fixen
Handbrake verwenden, AC3 durchschleifen und mkv als Container auswählen

->über synchronen Film freuen

Handbrake sollte wie der VLC und die anderen Player keine Probleme an


dass der TSD die Streams nicht anrührt ist gewissermaßen verständlich,
denn er arbeitet auf der Paketebene des TS-Streams

dekodiert/reencodiert wird gar nicht

es ist eine Designentscheidung, es wurde bewusst vermieden, weil es einen Qualitätsverlust bedeuten würde und weil sich TS als Archivformat durchaus eignet
außerdem beruht der Vorteil von TS ja gerade darauf, dass man einfach irgendwo etwas entfernen kann, ohne dass etwas asynchron wird oder die Datei nicht mehr abspielbar ist, denn der Container basiert ja auf Paketen

es werden nur gewisse unnötige Pakete entfernt (Garbage, abgewählte Streams, Stellen aus dem Schnitteditor, NALU-Filler, etc.)

sicherlich kann man auch durch den Doc Pakete einfügen lassen, um den Film synchron zu halten, ist aber nicht immer erfolgreich (wie bei dir)

Download:
https://handbrake.fr/

[cpw]

In der Tat ist Handbrakes Output hier synchron, d.h. ursächlich ist wohl der Decoder -  offenbar decodiert DGIndexNV an der fehlerhaften Stelle ein paar Frames zu viel, so dass das resultierende Video länger und der AC3-Stream dadurch zu kurz wird. Auffällig dabei ist auch, dass DGIndexNV an dieser Stelle Artefakt-Müll anzeigt, während im Handbrake-Resultat offenbar nur das letzte sauber dekodierbare Frame n mal wiederholt wird, also das Video "steht".

Handbrake hat allerdings zwei Probleme:

- QTGMC fürs Deinterlacing kann ich vergessen, dafür benötige ich AviSynth. Handbrake scheint mir auf primitives (Bob) und relativ nichtssagendes ("Fast", "Slow", "Slower") beschränkt zu sein.

- ich möchte fast wetten, dass der in Handbrake implementierte Decoder (ffmpeg?) Probleme mit MBAFF hat  -  leider habe ich im Moment kein Material für einen Test um das zu bestätigen oder zu widerlegen. Bei meinen letzten Versuchen (schon eine Weile her, den problematischen Ursprungs-TS habe ich leider nicht mehr) war DGIndexNV der einzige (framegenaue, also als "saubere" Quelle in AviSynth zu verwendende) brauchbare Decoder, der mit allem klar kam, was man ihm vorsetzte. Insbesondere z.B. manche Aufnahmen von BBC 1 HD machten mit allem anderen, das ich probiert habe (u.a. ffmpegsource/ffms2), Probleme.

Ich werde mich hier nochmal an Donald Graft (Entwickler der DG-Tools, u.a. DGIndex und DGIndexNV) wenden, möglicherweise weiß der Abhilfe.

Es ist schon eine Weile her, dass ich mich mit Videokompressions-Algorithmen befasst habe (der letzte war MPEG-2), d.h. über H.264/AVC habe ich nur sehr rudimentäre Kenntnisse, deshalb folgende Frage:

ProjectX "korrigierte" Fehler in MPEG-2-Streams durch stumpfes Droppen der kompletten beschädigten GOP, was für absolut synchronen Output sorgte. Wäre das so auch für H.264 machbar? Gibt es hier überhaupt noch "klassische" GOPs, die sich ohne Weiteres entfernen lassen, oder bekäme man hier Probleme, weil z.B. B-Frames sich GOP-übergreifend referenzieren können? Falls Ersteres: Diese Funktion (einstellbar in TSDs Optionen) könnte enorm hilfreich sein.



Gruß

Christian

[Djfe]

kann dir zu letzterem nichts sagen (hab keine wirkliche Ahnung von GOPs
aber die Reihenfolge wird auch im Log des TSD angezeigt, deshalb geh ich davon aus, dass das bei H264 auch noch so ist


Avisynth solltest du mit Handbrake verwenden können, einfach die Avisynth Datei öffnen (dafür brauchst du kein DGIndexNV)
Überblick über die HB Pipeline: https://trac.handbrake.fr/wiki/HandBrakeArchitecture

eventuell kannst du auch unter forum.handbrake.fr einen Feature Request für das Deinterlacing Skript machen

hab noch was ähnliches zum Thema QTGMC gefunden: https://forum.handbrake.fr/viewtopic.php?f=11&t=28017&p=129269


zur Erklärung vom Deinterlacing Filter in Handbrake siehe hier:
https://trac.handbrake.fr/wiki/DeinterlacingGuide


EDIT:
hab einen Thread gefunden zum Thema, es gab schonmal einen Feature Request,
aber da hat glaub ich keiner der Entwickler drauf geantwortet, kannst du ja nochmal pushen
https://forum.handbrake.fr/viewtopic.php?f=26&t=24263&p=112613&hilit=qtgmc#p112613

[cpw]

Avisynth solltest du mit Handbrake verwenden können, einfach die Avisynth Datei öffnen (dafür brauchst du kein DGIndexNV)

Nein, Handbrake öffnet keine AviSynth-Scripts, habe ich gerade ausprobiert ("Scan failed: Unrecognized file type"). Und selbst wenn das ginge: AviSynth benötigt einen Decoder als Source, und genau das ist der Knackpunkt: Der meiner Erfahrung nach einzige wirklich zuverlässige Decoder für H.264 (insbesondere für öfter mal "problematische" DVB-Streams) ist DGDecNV.

Sprich: Ließe sich ein AviSynth-Script in Handbrake öffnen, wäre das Resultat auch wieder asynchron, da offenbar der Decoder den Unterschied macht.

Überblick über die HB Pipeline: https://trac.handbrake.fr/wiki/HandBrakeArchitecture

Daraus geht hervor, dass Handbrake selbst einen Decoder implementiert  -  soweit ich sehe tatsächlich ffmpeg. Das ist zwar im Prinzip ein mächtiges, tolles Werkzeug für so ziemlich jedes verfügbare Audio- und Video-Format unter dieser Sonne, allerdings gerade für DVB-H.264 und MBAFF nicht unbedingt "Weapon of Choice", wie gesagt habe ich damit bereits experimentiert. Dafür hält er allerdings  -  anders als DGDecNV  -  offenbar bei Fehlern die Streams synchron bzw. dekodiert auch aus Müll die exakt korrekte Anzahl Video-Frames.

Ich habe jetzt Donald Graft nochmal angesprochen, mal schauen, ob der dazu was zu sagen hat.

[Djfe]

also ich glaub nicht, dass Handbrake Probleme mit H264 hat, weil x264 verwendet wird, der beste Decoder auf dem Markt, den ich kenne

zu MPEG2 kann ich aber nichts sagen, mag sein, dass der Dekoder Probleme bereitet, aber dafür gibt's ja: https://trac.ffmpeg.org/
dort kannst du Probleme/Bugs melden

wegen dem Deinterlacer, wenn du sowas vermisst, dann frag doch einfach die Entwickler, wie ich schon gesagt habe


ein Nachteil von Handbrake: H264 wird nur mit chroma-subsampling 4:2:0 unterstützt und alles bis high profile
4:2:2 soll bald hinzugefügt werden
für 4:4:4 (das höchste was möglich ist) gibt's noch keine Pläne

[Mam]

...weil x264 verwendet wird, der beste Decoder auf dem Markt, den ich kenne...

Och? den kennich gar nicht  !

(Das mag daran liegen, dass x264 gar kein Decoder ist, sondern ein Encoder...)

Code Auswählen Erweitern


x264 core:76 r1271 496d79d
Syntax: x264 [options] -o outfile infile [widthxheight]

Infile can be raw YUV 4:2:0 (in which case resolution is required),
  or YUV4MPEG 4:2:0 (*.y4m),
  or AVI or Avisynth if compiled with AVIS support (yes).
Outfile type is selected by filename:
.264 -> Raw bytestream
.mkv -> Matroska
.mp4 -> MP4 if compiled with GPAC support (yes)


[Djfe]

hups, hab das durcheinander gebracht

[cpw]

Nochmal explizit eine Frage @Cypheros, quasi als Feature Request: Wäre es mit vertretbarem Aufwand möglich, eine ("konfigurier"-, also irgendwo in den Optionen an- und abschaltbare) Funktion zu implementieren, die an fehlerhaften Stellen einfach die komplette GOP von I-Frame bis I-Frame droppt und die Audiospur(en) entsprechend passend schneidet?

Ich habe noch kein Tool gefunden, dass dies so für H.264 beherrscht.

[Cypheros]

Ja, im Prinzip schon aber bei H264 gibt es keine richtige GOP wie bei MPEG2. Es könnte von I-Frame zu I-Frame gemacht werden doch das sind dann etwa 1 bis 2 Sekunden, die dann jedes mal fehlen. Auch wäre das recht langsam, da der Stream zweimal durchgearbeitet werden müsste, einmal zur Fehlersuche und dann um die Fehler rauszuschneiden.

[cpw]

doch das sind dann etwa 1 bis 2 Sekunden, die dann jedes mal fehlen

Das ist klar, allerdings bestehen die ansonsten dekodierten Abschnitte in der Regel sowieso nur aus Artefakt-Müll.

Grundsätzlich habe ich bei meinen Astra 28,5E-Aufnahmen praktisch nur zwei Zustände: Entweder so ziemlich komplett zerhäckselt, dann hilft sowieso nix mehr, oder ca. zwei bis drei Fehler pro Stunde  -  ob da nun Artefakt-Schrott zu sehen ist oder diese Stelle einfach fehlt ist mir beim Anschauen egal. Letzteres wäre technisch vorteilhafter, da man damit vermutlich so ziemlich alle Synchronitäts-Probleme erschlagen könnte.

Auch wäre das recht langsam, da der Stream zweimal durchgearbeitet werden müsste

Primär interessant wäre eine solche Funktion ja für die Weiterverarbeitung, die in der Regel sowieso ein Reencoding beinhaltet. Da käme es mir auf ein paar Minuten (wenns denn überhaupt so lange dauert) mehr nicht an.

[Derrick]

Wenn du deine empfangsbedingungen nicht verbessern kannst, rate ich dir, nicht allzu viel mühe reinzustecken. Besser wird es doch nicht. Ich würde den TS behalten wie er ist. Beschneiden ist natürlich ok, werbung gibt es ja nicht bei freesat .. und suche den fehlertolerantesten filter, der am wenigsten verpixelt.