Avidemux Forum

Hallo,
beim Versuch 2 Teildateien (mit einem Xoro HRT 7620 DVBT2 TV-Tuner aufgenommen, beide Dateiendung *.mts) bekomme ich wiederholt die folgende Fehlermeldung:

... gespeichertes Video unvollständig, Fehler ereignete sich bei 02:08:35,460 (55), etc

... kann eine Folge ungültiger Zeitstempel sein...

Habe nach der ersten Fehlermeldung, beim abschneiden des überstehenden Anfangs und Endes (ca 5 & 10 Min.), ebenso wie bei der Schnittstelle der beiden Teildateien auf frame-cut geachtet.

Auch der Versuch den USB-Stick (32GB) des TV-Tuners in NTFS zu formatieren, scheint nicht dauerhaft möglich zu sein (mehrmalig versucht!).

Die beiden files sollten ansonsten die gleichen Parameter aufweisen, da praktisch auf gleichem Gerät, gleicher SD-Karte unmittelbar in einer Session hintereinander aufgenommen wurden (mir ist dieses file splitting bisher nur von FAT32 bekannt)

Die zusammengefügte Datei endet dann auch tatsächlich bei ca 02:08'. Der ganze Film dauert aber ca 235 Minuten.

Heisst die Meldung
 ... "verwendet Nicht-IDR-frames" und "der Zähler .... wird nicht zurückgesetzt, etc"

daß die beiden Teile zusammenzufügen von Haus aus unmöglich ist?

Oder gibt es einen trick, oder sonst irgendseine Möglichkeit, die beiden files doch noch ordentlich zusammenzukleistern??

vielen Dank!

Bitte zunächst auf den letzten 2.8.2 Nightly aktualisieren, den Fehler beim Speichern im Kopiermodus reproduzieren, Avidemux schließen und admlog.txt aus %localappdata%\avidemux (ggf. komprimiert) an die Antwort anhängen bzw. über WeTransfer, Mega, Dropbox oder Google Drive bereitstellen.

Die Fehlermeldung enthält das Wort "kann" und nirgends "muss" – admlog.txt könnte helfen, die Ursache einzugrenzen.

Quote from: muxer-raven on December 26, 2022, 12:27:09 PMHeisst die Meldung
 ... "verwendet Nicht-IDR-frames" und "der Zähler .... wird nicht zurückgesetzt, etc"

daß die beiden Teile zusammenzufügen von Haus aus unmöglich ist?

Nein, diese Warnung hat damit nichts zu tun und kann ignoriert werden, sofern zum Abspielen keine Software, die auf FFmpeg basiert (also kein VLC und kein mpv), verwendet wird. Player, die zum Dekodieren von Video die Bibiliothek libavformat libavcodec (Teil von FFmpeg) benutzen, verstolpern sich an zurückgehenden POC-Werten statt die Diskontinuität zu erkennen und POC-Zähler zurückzusetzen.

Quote from: muxer-raven on December 26, 2022, 12:27:09 PMAuch der Versuch den USB-Stick (32GB) des TV-Tuners in NTFS zu formatieren, scheint nicht dauerhaft möglich zu sein (mehrmalig versucht!).

Was passiert dann? Wird das Dateisystem beschädigt? Das ist sehr leicht möglich, wenn der Stick ohne vorheriges "Aushängen" (darunter wird die logische Trennung des Dateisystems vom Betriebssystem gemeint) abgezogen wird.

Quote from: muxer-raven on December 26, 2022, 12:27:09 PMDie beiden files sollten ansonsten die gleichen Parameter aufweisen, da praktisch auf gleichem Gerät, gleicher SD-Karte unmittelbar in einer Session hintereinander aufgenommen wurden (mir ist dieses file splitting bisher nur von FAT32 bekannt)

Dann wäre es besonders spannend, ob die beiden Fragmente als eine Datei von Avidemux aufgefasst werden (sie sollten, falls der TV-Tuner denselben MPEG-TS-Datenstrom ohne Unterbrechungen in eine nächste Datei schreibt). Das Log wird es zeigen.

Quote from: muxer-raven on December 26, 2022, 12:27:09 PMOder gibt es einen trick, oder sonst irgendseine Möglichkeit, die beiden files doch noch ordentlich zusammenzukleistern??

Das hängt davon ab, was der Tuner da anstellt. Bestenfalls ist die Aufgabe mit dem Tool cat unter Linux in wenigen Sekunden (je nach Geschwindigkeit der involvierten Massenspeicher) erledigt.

cat Fragment1.mts Fragment2.mts > /Pfad/zum/GanzenVideo.mts

Hallo, vielen Dank für Deine Rückmeldung!

Quotesofern zum Abspielen keine Software, die auf FFmpeg basiert (also kein VLC

Doch, VLC ist hier der Standard-Player! Und MPC-HC die "zweite Hand".

QuoteWas passiert dann? Wird das Dateisystem beschädigt?

ist mir bisher nicht aufgefallen, ich dachte, wenn das Dateisystem beschädigt ist, funktioniert der Chip gar nicht mehr (zB am PC)?

Quoteohne vorheriges "Aushängen" .... abgezogen wird.

das funktionierte bisher immer in dem der Tuner beim abziehen des sticks ausgeschalten war. Mit anderen Dateien gabs nie Probleme.

Übrigens bemerkte ich beim abspielen der ersten file (Teil 1 sozusagen), daß es auch dort an einer bestimmten Stelle eine Diskontinuitöät gab. bei ca 02:08:xx also quasi der in der Fehlermeldung erwähnten Stelle....

QuoteTool cat unter Linux

ist mir zunächst leider ein böhmisches Dorf in den Karpaten ;-/

admlog.txt liegt vor, ABer wie kann ich das komprimieren??? (habs bisher immer nur umgekehrt gemacht, mit FIlzip, etc) Der im web gezeigte tip, aus rechtsklick-Menue 'compress to ...' ist bei mir anscheinend nicht existent (W10!)


ÜBrigens: kann man das nightly einfach übe die alte Version drüber installieren, oder sollte ma die erst deinstallieren?

wow, was für ein heck meck, aber voila: da ist sie....

Danke, das Log stammt jedoch von Avidmux 2.8.0, bitte wie gesagt zuerst auf den letzten verfügbaren 2.8.2 Nightly aktualisieren, die *.idx2-Dateien löschen, die erste .mts-Datei in cleo-0000.mts und die zweite in cleo-0001.mts umbenennen, die erste in Avidemux öffnen und die Streams neu indexieren lassen.

So wie Dateien jetzt benannt sind, werden sie von Avidemux auf keinen Fall als zusammenhängender Stream erkannt.

Quote from: muxer-raven on December 26, 2022, 08:58:53 PMkann man das nightly einfach übe die alte Version drüber installieren, oder sollte ma die erst deinstallieren?

Niemals drüber und niemals mehrere Instanzen gleichzeitig laufen lassen. Ich würde einfach die als ZIP gepackte Version nehmen und ausprobieren ohne die installierte anzufassen (allerdings wird 2.8.0 sowieso nicht unterstützt). Nur bloß nicht beide gleichzeitig ausführen.

so, 2.8.1 will 2.8.0 erst deinstallieren, das hab ich zugelassen, hoffe das war ok!?

Der Fehler ist nat. wieder aufgetreten, ich habe so langsam den Verdacht, es könnte tatsächlich am chip (32GB) liegen, habe jetzt für weitere Aufnahmen mal nen anderen hergenommen, für den Fall.
Allerdings bemerke ich am Tuner noch ne andere Macke: er geht nach programmiertem Ende der Aufnahme einfach nicht mehr aus.... ich hab nat. keine Ahnung, ob das mit einem defekten chip zutun haben könnte?

Genaueres erhoffe ich aus dem angehängten txt.zip.


edit:
bei einer 2. Filmdatei - diesmal ein Einzelstück! - hab ich den gleichen Fehler! oder ähnlichen: "das gespeicherte Video ist unvollständig"

Quote from: muxer-raven on December 27, 2022, 10:00:13 AMso, 2.8.1 will 2.8.0 erst deinstallieren, das hab ich zugelassen, hoffe das war ok!?

Nein, bitte wirklich mit dem aktuellsten Nightly benutzen, gerade im MPEG-TS-Demuxer gab es nach dem Release sehr wichtige Korrekturen. Allerdings auch so lassen Einträge wie

[ADM_Composer::DecodeNextPicture] 09:48:33-323 >>>>> PTS going backward by 7500 ms
[ADM_Composer::DecodeNextPicture] 09:48:33-323 Dropping frame!
[ADM_Composer::nextPictureInternal] 09:48:33-323 Next picture failed
[ADM_Composer::DecodeNextPicture] 09:48:33-324 >>>>> PTS going backward by 40 ms
[ADM_Composer::DecodeNextPicture] 09:48:33-324 Dropping frame!
[ADM_Composer::nextPictureInternal] 09:48:33-324 Next picture failed
[ADM_Composer::DecodeNextPicture] 09:48:33-324 >>>>> PTS going backward by 20 ms
[ADM_Composer::DecodeNextPicture] 09:48:33-324 Dropping frame!
[ADM_Composer::nextPictureInternal] 09:48:33-324 Next picture failed
[EditorCache::getAfter] 09:48:33-325 The next frame has a PTS <= the one we started from. We got timing 02:12:00,196
[EditorCache::getAfter] 09:48:33-325 We are looking for the one after 02:12:07,716
den Schluss zu, dass entweder der Stream einige Defekte aufweist oder dies an der Grenze der zwei Einzeldateien passiert und die Annahme, dass der Recorder beim Splitten der Aufnahme den Stream einfach nahtlos fortsetzt, falsch war.

Quote from: muxer-raven on December 27, 2022, 10:00:13 AMbei einer 2. Filmdatei - diesmal ein Einzelstück! - hab ich den gleichen Fehler! oder ähnlichen: "das gespeicherte Video ist unvollständig"

Ja, sieht nach beschädigtem Stream aus.

Sorry, habe 2.8.2 visuell mit 2.8.1 verwechselt (wenn man nicht doppelt + 3-fach & genau hinschaut, ist man der A****)!

Fehler korrigiert: habe jetzt erstmal nur eine Datei bearbeitet, die nicht gesplittet war (war nur <3,9 GB groß).
3,5h & längere Filme kommen ja nicht so oft.
Ergebnis: sehr gut!

'Defekter Stream': Wo auf der Strecke zwischen Antenne und SD-chip ist dieser Fehler denn anzusiedeln??

Quotean der Grenze der zwei Einzeldateien passiert

Daher hatte ich um die Nahtstelle herum nur mit ganzen keyframes geschnitten,

Quoteund die Annahme, dass der Recorder beim Splitten der Aufnahme den Stream einfach nahtlos fortsetzt, falsch war.

nervt mich auch schon wieder, daß man ständig in den Einstellungen des Tuners nachstellen muss, damit er wirklich NTFS formatiert: denn jedesmal, wenn ich nachschaue, ist wieder FAT32 eingestellt!
Ich weiss also gar nicht, ob die Filme wirklich auf nem NTFS-formatierten chip abgelegt werden....
Ich bezweifle es fast!

edit:
die logische Trennung des chip geschieht hier einfach, indem er vom abgeschalteten Tuner an- und abgesteckt wird. Hat bisher immer problemlos funktioniert

letzte Bitte: könnte mir jemand noch kurz erklären, wo auf der Strecke zwischen Antenne und SD-Speicher der stream korrumpiert wird? (oder wahrscheinlichst)
vielen Dank!

Bitte nicht Keyframes und IDR-Frames verwechseln. Während ein IDR-Frame immer auch ein Keyframe ist, sind Keyframes in üblichen DVB-Übertragungen meist ganz gewöhnliche Frames mit einer Besonderheit: sie garantieren, dass man beginnend von diesem Frame mit dem Dekorieren des Streams anfangen darf und dabei keine beschädigten Bilder rauskommen. Sie erlauben es nicht, einen Teil von Video aus der Mitte des Streams zu löschen und trotzdem einen einwandfreien Stream zu erhalten. Das Ergebnis ist praktisch immer mehr oder minder defekt, wobei Avidemux vor besonders schwerwiegenden Problemen auch warnt.

Warum man den Schnitt an Nicht-IDR-Frames nicht unterbindet? Weil dies den Kopiermodus in Avidemux zum großen Teil nutzlos machen würde: IDR-Frames sind in DVB-S/C/T-Streams rar gesät, wenn überhaupt (es können Minuten dazwischen liegen, aber auch Stunden oder Tage).

Zur Frage nach der Quelle der Defekte im aufgenommenen Stream: Es liegt wahrscheinlich an der Strategie, wie die Firmware im Receiver die Trennung des Streams in einzelne Dateien vornimmt. Für konkretere Aussagen müsste ich das Ende eines Teilstücks und den Beginn des nächsten untersuchen.