Ton/Bild-Versatz bei zusammgefügten Videoteilen

[tricho]

Hallo,
ich habe folgendes Problem:
Ich nehme mit meinem Sat-Receiver eine Sendung in HD auf. Ich erhalte dann einen TS-Stream, der in 4GB Stücke unterteilt ist (was ich leider nicht unterbinden kann), die in chronologischer Folge nummeriert sind (00.ts - 01.ts - 02.ts etc.).
In Avidemux hänge ich die in der entsprechenden Reihenfolge aneinander, schneide evtl. Überhang hinten oder vorn weg und speicher es ab als mp4 mit h264 Kompression.
Gelangt man beim Abspielen an die Grenze eines der ursprünglichen TS-Teilstücke gibts einen Aussetzer in Ton und Bild (sehr kurz). Das Video läuft dann weiter, jedoch läuft der Ton deutlich versetzt hinter dem Video her. Im Verlaufe von 15-20 Minuten verringert sich der Versatz bis dann irgendwann die Grenze zum nächsten Teilstück kommt und das Spiel geht von vorne los.

Das ganze hat nichts mit der Kompression zu tun oder dem Ausgabe-Container. Das gleiche Ergebnis gibts auch im Copy-Modus und bei der Ausgabe in TS.
Was hilft ist allerdings folgendes: Wenn ich den Teil zwischen dem letzten I-Frame vor der Zusammfügestelle und dem ersten I-Frame danach komplett rausschneide habe ich zwar einen deutlicheren Aussetzer im Video, danach läuft der Ton jedoch sauber mit.

Außerdem bekommen ich neuerdings eine Meldung die ich nicht genau verstehe: "Diese Video verwendet Nicht-IDR-Frames für den Direktzugriff. Der Zähler für...Trotzdem fortsetzen?". Heißt das schneiden an I-Frames geht garnicht mehr???

Ich verwende übrigens Avidemux V 2.7.5 Nightly-200415 unter Win10...Kann es sein das die obige Meldung ganz neu ist? In früheren Versionen hab ich die noch nie gesehen obwohl ich vergleichbares Video-Material geschnitten habe.

Beste Grüße

[eumagga0x2a]

Ich nehme mit meinem Sat-Receiver eine Sendung in HD auf. Ich erhalte dann einen TS-Stream, der in 4GB Stücke unterteilt ist (was ich leider nicht unterbinden kann), die in chronologischer Folge nummeriert sind (00.ts - 01.ts - 02.ts etc.).

Wenn die Teilstücke ziemlich nah an 4 GiB und wirklich fortlaufend nummeriert sind wie oben angegeben, sollte Avidemux beim Öffnen des ersten von sich aus das automatische Laden von allen darauffolgenden Teilstücken vorschlagen. Dann werden sie intern wie eine einzige Datei behandelt, wodurch die bemängelten, je nach Aufbau des Streams unumgänglichen Aussetzer vermieden werden.

Wie groß sind denn die Teilstücke auf Bit genau und wie lauten die genauen Dateinamen einer Beispielaufnahme?

Ebenfalls würde admlog.txt vom Laden des ersten Teilstücks nicht schaden.

In Avidemux hänge ich die in der entsprechenden Reihenfolge aneinander, schneide evtl. Überhang hinten oder vorn weg und speicher es ab als mp4 mit h264 Kompression.
Gelangt man beim Abspielen an die Grenze eines der ursprünglichen TS-Teilstücke gibts einen Aussetzer in Ton und Bild (sehr kurz). Das Video läuft dann weiter, jedoch läuft der Ton deutlich versetzt hinter dem Video her. Im Verlaufe von 15-20 Minuten verringert sich der Versatz bis dann irgendwann die Grenze zum nächsten Teilstück kommt und das Spiel geht von vorne los.

Wie unten erwähnt, die Aussetzer sollten sich vorm Neukodieren einfach wegschneiden lassen (geht nicht in Copy Mode). In Zweifel bitte so ein Beispiel-Video über WeTransfer, Mega, Dropbox oder Google Drive zur Verfügung stellen. Besonders das sich verringernde A/V-Versatz ist sehr ungewöhnlich.

Was hilft ist allerdings folgendes: Wenn ich den Teil zwischen dem letzten I-Frame vor der Zusammfügestelle und dem ersten I-Frame danach komplett rausschneide habe ich zwar einen deutlicheren Aussetzer im Video, danach läuft der Ton jedoch sauber mit.

Aussetzer im Video sollte nur im Kopiermodus vorkommen, nicht beim Neukodieren. Wenn es trotzdem dazu kommt, müsste ich mir das an einem Beispiel ansehen (nicht so leicht bei 4 GiB großen Fragmenten!). Beim Neukodieren muss man auch nicht so großzügig die Stelle wegschneiden, zwei Frames würden reichen.

Außerdem bekommen ich neuerdings eine Meldung die ich nicht genau verstehe: "Diese Video verwendet Nicht-IDR-Frames für den Direktzugriff. Der Zähler für...Trotzdem fortsetzen?". Heißt das schneiden an I-Frames geht garnicht mehr???

Wenn ein besserer Wortlaut helfen würde, bitte vorschlagen. In heutigen DVB-T/C/S-Übertragungen werden so gut wie keine IDR-Frames, an denen man eben sauber schneiden kann, verwendet. "I-Frame" ist eine nicht mehr zeitgemäße Vereinfachung, die ganz wesentliche Eigenschaften verwischt, die fürs Schneiden ohne Neukodieren von entscheidender Bedeutung sind.

Wie die Meldung schon sagt, sind die "I-Frames" in einem solchen Videostream zwar für sich genommen vollständig, also nicht von anderen Frames abhängig, und es wird garantiert, dass von so einem "I-Frame" beginnend Video stets ohne Pixelsalat gestartet werden kann, jedoch benötigen nachfolgende Frames Referenzbilder aus dem Stream vor solchen "I-Frames" (recovery frames), um sauber dekodiert werden zu können. Dazu laufen alle Zähler (frame_num und eben POC) weiter statt wie bei einem IDR-Frame auf Null gestellt zu werden.

Schneidet man jetzt ein Stück des Streams weg, ergibt dies (fast zu 100%) verwaiste Frames, denen die zur Dekodierung notwendige Infos nun fehlen sowie Zähler, die wilde Sprünge machen. Eine besondere Art von solchen Inkonsistenzen verträgt FFmpeg sehr schlecht, davor versucht Avidemux zu warnen.

Ich verwende übrigens Avidemux V 2.7.5 Nightly-200415 unter Win10...

Sehr gut, seit dem letzten Release sind etliche wichtige Bugs, besonders im Blick auf die Handhabung von mp4, behoben worden.

Kann es sein das die obige Meldung ganz neu ist?

Für HEVC ganz, ganz neu. Für H.264 wurde der entsprechende Check im Sommer letzten Jahres implementiert, ist also im letzten Release enthalten.

In früheren Versionen hab ich die noch nie gesehen obwohl ich vergleichbares Video-Material geschnitten habe.

Das bedeutet nicht, dass das Problem nicht existierte. Man entdeckte es aber erst, wenn man das Video im Kopiermodus gespeichert und in einem FFmpeg-basierten Videoplayer wie VLC abspielte. FFmpeg kommt schwer aus dem Tritt, wenn sich POC unerwartet verringert. Andere Implementierungen (zum Beispiel, der standardmäßig mitgelieferte Videoplayer von Windows 10) kümmert es gar nicht.

[tricho]

Hallo,
Danke für die Antwort.

Wie groß sind denn die Teilstücke auf Bit genau und wie lauten die genauen Dateinamen einer Beispielaufnahme?

Ich hab mir mal einige Files angeschaut. Die sind zwischen 4.096.222.208 Bytes und 4.097.281.024 Bytes groß bis auf das letzte in der jeweiligen Reihe, dass selbstverständlich kleiner ist. Und ja, die sind genau wie angegeben durchnummeriert (000.ts 001.ts ....). Aber Avidemux öffnet die bei mir schon längere Zeit nicht mehr selbsständig bzw fragt nach (das ging bei irgendeiner früheren Version, liegt aber schon eine Weile zurück...hab nicht drauf geachtet). Ich muß die immer einzeln aneinander hängen über Ctrl-A.

Admlog häng ich an.

Und nur zum Verständniss: ts laden - h264 Kompression drüberlaufen lassen - als mp4 abspeichern = neukodieren oder??

Ich hab mir nochmal so eine Stelle im VLC angeschaut (in der mp4 Datei) und bemerkt ich habs verwechselt ..der Ton kommt vor dem Video, läuft also etwas voraus (ca. 0.5 Sek.). Irgendwann gehts dann wieder zusammen. Auch wenn man vor und zurückspringt passt es oft wieder. Bei zwei Hardware-Playern ist das bei mir das gleiche (LG BD-Player oder der Sat-Receiver), allerdings hilft das Vor und zurückspringen nicht immer. Um die Sache zuverkomplizieren tritt der Versatz beim Abspieln in Avidemux NICHT auf. Nur ein kurzer Ruckler und es geht normal weiter. Der MediaPlayer Classic bügelt auch einfach drüber und gut ist's....  Scheint also auch der Player eine Rolle zuspielen...wird langsam unübersichtlich!!!

Ich hab mal zwei solche Nahtstellen quasi rausoperiert und im copy-Modus wieder als ts-Datei abgespeichert (hat etwa 550 MB). Sollte dann nicht neucodiert sein, oder?  Im VLC-Player ist der Versatz deutlich erkennbar. Nützt Dir das was als Datei? Ich könnte Dir eine private Nachricht mit einem Drive-Link schicken!

Wenn ein besserer Wortlaut helfen würde, bitte vorschlagen. In heutigen DVB-T/C/S-Übertragungen werden so gut wie keine IDR-Frames, an denen man eben sauber schneiden kann, verwendet.

Was die Warnung betrifft: Ist keinerlei Kritik an der Formulierung gewesen und letztlich hab ich's dann doch richtig Verstanden...nur ändern kann man doch eigentlich nichts, oder gibts eine Alternative in der Vorgehensweise?

Beste Grüße

[eumagga0x2a]

Ich hab mir mal einige Files angeschaut. Die sind zwischen 4.096.222.208 Bytes und 4.097.281.024 Bytes groß

So doof, sie sind also rund 3,81 GiB groß – kein Wunder, dass Avidemux, das Größen von 256 MiB (±1 MiB), 512 MiB (±1 MiB), 1 GiB (von nun an ±8 MiB), 2 GiB oder 4 GiB erwartet, sie ignoriert. Diese häufig vorkommenden und bei 4 GiB auch technisch begründeten (maximale Dateigröße von FAT32) Werte dienen als Indiz dafür, dass die Dateien automatisch abgespaltene Fragmente eines einzigen Streams sind.

Gibt es keine Möglichkeit, die Fragmentgröße beim Receiver zu konfigurieren? 1.000.000 * 1024 *4 ergibt technisch keinen Sinn.

Aber Avidemux öffnet die bei mir schon längere Zeit nicht mehr selbsständig bzw fragt nach (das ging bei irgendeiner früheren Version, liegt aber schon eine Weile zurück...hab nicht drauf geachtet).

Früher hat Avidemux alles im Demuxer angehängt (zum Anhängen vorgeschlagen), also wie eine einzige Datei behandelt, was passend zur ersten MPEG-TS Datei fortlaufend benannt war. Die Ergebnisse waren dementsprechend völlig kaputt. Ich hatte die Funktion daher zunächst komplett deaktiviert, dann wieder eingeschaltet, geschützt durch die grobe Dateigrößen-Heuristik.

Das Problem ist, dass jeder Fehler bei der Wahl der Strategie fatal für das Ergebnis ist.

Ich muß die immer einzeln aneinander hängen über Ctrl-A.

Man müsste die Fragmente binär (also wie mit

Code Select Expand

cat 000.ts 001.ts 002.ts > komplett.ts

unter Linux) zur einer Datei vereinigen (nichts anderes tut virtuell der MpegTS-Demuxer in Avidemux) und diese Datei dann laden.

Admlog häng ich an.

Danke, das Log bestätigt die Sachlage.

Und nur zum Verständniss: ts laden - h264 Kompression drüberlaufen lassen - als mp4 abspeichern = neukodieren oder??

Ja.

Um die Sache zuverkomplizieren tritt der Versatz beim Abspieln in Avidemux NICHT auf. Nur ein kurzer Ruckler und es geht normal weiter.

Eventuell admlog.txt genau von diesem Vorgang zeigen?

Ich hab mal zwei solche Nahtstellen quasi rausoperiert und im copy-Modus wieder als ts-Datei abgespeichert (hat etwa 550 MB). Sollte dann nicht neucodiert sein, oder?

Nein, nicht ein weiteres Mal neukodiert, aber wirklich hilfreich wäre ein binär geschnittenes (nicht mit Avidemux!) kurzes (~100 MiB) Stück vor dem Ende der originalen 001.ts und ein vergleichbar kleines Stück vom Anfang von 001.ts. Hat Windows jetzt nicht dieses Subsystem for Linux? Es ist ein Jammer, dass es unter Windows standardmäßig keine Werkzeuge wie head, tail, cat, dd, grep usw. gibt...

Code Select Expand

tail -c 100M 000.ts > dasEnde.ts
head -c 100M 001.ts > derAnfang.ts

Nützt Dir das was als Datei? Ich könnte Dir eine private Nachricht mit einem Drive-Link schicken!

Ja, bitte schicken. Ich weiß nicht, ob die Datei was nützt, aber keine Datei nützt garantiert gar nichts 

Wenn ein besserer Wortlaut helfen würde, bitte vorschlagen. In heutigen DVB-T/C/S-Übertragungen werden so gut wie keine IDR-Frames, an denen man eben sauber schneiden kann, verwendet.

Was die Warnung betrifft: Ist keinerlei Kritik an der Formulierung gewesen

Ein Blick von außen ist immer hilfreich.

nur ändern kann man doch eigentlich nichts, oder gibts eine Alternative in der Vorgehensweise?

Im Bezug auf die Eignung bestimmter Keyframe-Paare als Schnittpunkte – nein, denke ich. Ganz anders sieht es im Bezug auf die Handhabung von Stream-Fragmenten aus. Notfalls könnte man die Fragmentgröße doch konfigurierbar machen, wenn schon ein richtiger Check außer Reichweite ist.

[dosdan]

So doof, sie sind also rund 3,81 GiB groß – kein Wunder, dass Avidemux, das Größen von 256 MiB (±1 MiB), 512 MiB (±1 MiB), 1 GiB (von nun an ±8 MiB), 2 GiB oder 4 GiB erwartet, sie ignoriert. Diese häufig vorkommenden und bei 4 GiB auch technisch begründeten (maximale Dateigröße von FAT32) Werte dienen als Indiz dafür, dass die Dateien automatisch abgespaltene Fragmente eines einzigen Streams sind.

Wie wäre es mit einem Klickfeld für die benutzerdefinierte Eingabegröße zum automatischen Anhängen in den Einstellungen, um sie an solche Geräte anzupassen?

(What about including a click-box Custom Auto-Append input size in Preferences to suit such devices?  This is so 3.81GiB, +/- 8MiB, could be entered as custom filesize to trigger auto-appending and would then be added to the current list of searched-for sizes.)

Dan.

[odin]

Gelangt man beim Abspielen an die Grenze eines der ursprünglichen TS-Teilstücke gibts einen Aussetzer in Ton und Bild (sehr kurz).

Kenne das Problem auch von einem Technisat Receiver, der das FAT Dateisystem verwendet, und deshalb  4 GB  1 GB Teile erzeugt. Er trennt leider auch nicht "sauber", sondern mitten im Stream.
Ruckler lassen sich vermeiden, wenn man die Teile ausserhalb von avidemux hintereinander hängt. Unter Windows Eingabeaufforderung z.B. so:
copy /b "file1.ts" + "file2.ts"  "MERGED.mts"

Um das "copy" zu vereinfachen, hatte ich mir eine kurze .BAT Datei erstellt, die solche Teildateien im aktuellen Verzeichnis zusammenfügt:

Code Select Expand

@echo off
set "DESTPATH=."
set "FIRST=-"
SET "FILES="

REM iterate over list and generate list of files (maybe max. 128 char???)
SETLOCAL EnableDelayedExpansion
for /f "usebackq delims=" %%F in (`dir /b /on *0??._*.ts`) do (
IF "!FIRST!" == "-" SET "FIRST=%%~nF"
set FILES=!FILES!+"%%~F"
)

copy /b %FILES:~1% "%DESTPATH%\%FIRST% _MERGED_.mts"


Tonversatz kenne ich eigentlich nur von MS-Windows "Filme & TV" App. VLC dagegen macht alles richtig.

[eumagga0x2a]

Kenne das Problem auch von einem Technisat Receiver, der das FAT Dateisystem verwendet, und deshalb 4 GB Teile erzeugt. Er trennt leider auch nicht "sauber", sondern mitten im Stream.

4 GB (GiB) Teilstücke sollte Avidemux von sich aus zusammenfügen.

Ruckler lassen sich vermeiden, wenn man die Teile einfach hintereinander hängt.

Genau, es ist ja auch ein zusammenhängender Datenstrom.

Unter Windows Eingabeaufforderung z.B. so:
copy /b file1.ts file2.ts  MERGED.mts

Danke, funktioniert es so tatsächlich? Ich frage, weil https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/copy suggeriert, dass "+" vor der zweiten Datei nötig wäre, und zum Ausprobieren bräuchte man Windows...

Wie wäre es mit einem Klickfeld für die benutzerdefinierte Eingabegröße zum automatischen Anhängen in den Einstellungen, um sie an solche Geräte anzupassen?

@Dan: Ist in den letzten Nightlies bereits implementiert.

(This feature has been already implemented.)

[odin]

copy /b file1.ts file2.ts  MERGED.mts

Danke, funktioniert es so tatsächlich? Ich frage, weil https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/copy suggeriert, dass "+" vor der zweiten Datei nötig wäre, und zum Ausprobieren bräuchte man Windows...

Sorry, mein Fehler. Muss natürlich mit "+" sein, ansonsten kommt 'Syntaxfehler'.
Hatte in meinem eigenen Skript das "+" übersehen:  set FILES=!FILES!+"%%~F"
Funktioniert mit und auch ohne Leerzeichen:

Code Select Expand

>copy /b 1.txt+2.txt 12.txt
>copy /b 1.txt + 2.txt 12.txt


[eumagga0x2a]

Alles klar, danke.

Klappt das automatische Zusammenfügen im MPEG-TS-Demuxer von Avidemux in dem Fall nicht? Wäre es dann bitte möglich, Blick in admlog.txt zu werfen?

[odin]

Klappt das automatische Zusammenfügen im MPEG-TS-Demuxer von Avidemux in dem Fall nicht? Wäre es dann bitte möglich, Blick in admlog.txt zu werfen?

Zumindest mit einer 1 Jahr alten avidemux-Version hat das nicht funktioniert. Lag evtl. am ungewöhnlichen Namesformat wie:
     2.000._The Big Lebowski.ts
     ...
     2.014._The Big Lebowski.ts
Die führende 2 ist die Sequ.Nr. der Aufnahme.
Muss mich auch noch mal korrigieren: Die einzelnen Files haben nicht 4 GB, sondern vermutl. ca. 1 GB.
An's Log komme ich erst in paar Monaten.

[eumagga0x2a]

Zumindest mit einer 1 Jahr alten avidemux-Version hat das nicht funktioniert. Lag evtl. am ungewöhnlichen Namesformat wie:
     2.000._The Big Lebowski.ts
     ...
     2.014._The Big Lebowski.ts
Die führende 2 ist die Sequ.Nr. der Aufnahme.

Ja, definitiv, das würde auch in den letzten Nightlies nicht klappen. Der Code, der nach sequenziell benannten Dateien sucht (in ADM_splitSequencedFile), beginnt vom letzten Punkt im Dateinamen und berücksichtigt nur Ziffern, die direkt davor stehen, also "foo00000.bar", "foo00001.bar", "foo00002.bar" und so weiter. "foo00000h.bar", "foo00000.h.bar"  oder "00000foo.bar" wird nicht erkannt.

[tricho]

Hallo,
ich will mich mal zurückmelden. Seit dem Nightly April 15 ist die Auswahl-Box in Avidemux ja eingebaut und ich hab es mit dem oben erwähnten Video ausprobiert und es läuft sauber durch. Also herzlichen Dank für dieses Feature.
Eine Frage dazu wäre noch: Wie genau muss man den Wert einstellen? Ich habe die etwas unterschiedlich großen Teilstücke berücksichtigt und dann auf einen Wert mittig +- 2MB eingestellt und das hat funktioniert. Aber wie viel Toleranz hat das Verfahren?

An Odin
so etwas ähnliches gabs doch schon unter DOS .... ist mir nicht klar gewesen, das dass immer noch geht.
Danke

[eumagga0x2a]

Die willkürlich festgelegte Toleranz beträgt bei Fragmentgröße bis 1000 MiB 1 MiB, sonst 8 MiB.

[extracool]

ja, das mit den mehreren 4GB dateien hatte ich auch. die aussetzer im ton kommen daher, dass ein ts-stream einfach komplett unabhängig vom inhalt als datei 1 endet und dann als datei 2 fortgesetzt wird. ton und bilddaten werden dabei irgendwo getrennt. der recorder kann damit umgehen, aber der pc nicht. die synchronistation wird erst beim ersten lesbaren frame wieder fortgesetzt. Aber - das kann man recht einfach umgehen, indem man die sequenzen als dateien wieder zusammensetzt.

das habe ich aber so gelöst: besorge dir total commander (unter ghisler.com) und installiere es. das programm ist kostenlos nutzbar.

benenne nun die zusammengehörenden dateien um. benenne die dateien zb. beispiel so um: entferne die sequenznummer und setze sie nun ganz hinten an. (also z.b. aufnahme 001.ts wird zu aufnahme.ts.001, aufnahme 002.ts wird zu aufnahme.ts.002 usw.). alle dateien müssen nun im selben verzeichnis sein. positioniere nun den total commander auf die erste datei. oben aus dem menü wählst du nun Dateien - Dateien zusammenfügen.

Nun werden die Dateien zusammengefügt. Das Kopieren erfolgt auf den Ordner, welcher auf der rechten Seite gewählt ist.

Sehr wichtig: Schaue darauf, dass das Dateisystem des Ziellaufwerks unbedingt NTFS, oder exFAT ist. Nur diese Laufwerke können Dateien über 4GB grösse speichern. (Fat, Fat32 unterliegen den Beschränkungen von 2GB bzw 4GB maximaldateigrösse).

Da die Dateien nun wieder vereint sind, wird auch der Stream nicht unterbrochen, und damit kommt es auch zu keinen Tonausfällen oder Bildrucklern.

Viel Erfolg!