Hallo, ich habe ein Problem mit allen h.264-Dateien mit einer Größe ab ca. 6 bis 7 GB oder größer.
es handelt sich dabei um Videos, welche ich an einem Toshiba-TV abspielen möchte, dieser kann jedoch kein DTS-Audio wiedergeben.
Ich stelle also Avidemux zum Wandeln des Videos so ein, dass der Video-Stream kopiert wird und das Audio rekodiert wird zu AC3.
Die Bitrate vom Audio-Wandler stelle ich dabei auf 192 KB/s.
Die Rekodierung läuft ohne Fehler durch(zumindest sehe ich in der GUI keine).
Spiele ich so ein gewandeltes Video danach allerdings im VLC ab oder versuche in Avidemux in der Datei an eine Stelle zu springen, geht das nicht mehr. Das Video wird stattdessen immer vom Anfang abgespielt. Auch der Toshiba-TV kann ein solches Video dann nicht mehr vorspulen o. an eine gewisse Stelle springen - auch hier geht das Video immer wieder von vorne los, wenn ich das versuche.
Handelt es sich hierbei um einen bekannten Bug oder muss ich in Avidemux vielleicht etwas bestimmtes einstellen, damit es geht?
Habe auch schon versucht, das Audio z.B. in MP3 zu wandeln, aber scheinbar liegt es an der Video-Bearbeitung, da es bei allen anderen Audio-Formaten genauso auftritt.
Mfg und Danke im Voraus
In welchen Container ist das ursprüngliche Video gepackt und in welchen das von Avidemux gespeicherte Video gepackt? (Solch wichtige Details wie mp4 als Container sollte man nicht nur im Titel sondern auch im Text nennen.) Für H.264 sollte es vorzugsweise Matroska (MKV) or MP4 sein, auf keinen Fall AVI. Kann im ursprünglichen Video trotz der Größe gespult werden? Bringt es was, MKV als Container zu wählen?
Das ursprüngliche Video ist in einem MKV-Container gepackt, das von Avidemux gespeicherte ebenfalls. Habe mich da im Titel vertan. Im ursprünglichen Video kann ich mit allen Programmen(Avidemux, VLC) vorzüglich spulen und springen wie ich will. Wie bereits vorher erwähnt, ist der Ziel-Container bereits MKV - werde grad mal MP4 als Ziel-Container testen.
Ich kann den Bug reproduzieren, die Funktion ADM_Composer::searchNextKeyFrameInRef schlägt fehl. Ich kann jedoch im betroffenen Video problemlos mit mpv navigieren.
mpv bringt mir nur nichts, da es mir hauptsächlich darum geht, die Videos auf meinem Toshiba-TV anzuschauen (auf dem sie, wie vorher beschrieben, ja dann auch nicht mehr spulbar sind). Ist halt doof, wenn man das Video stoppt muss man es sich nochmal von vorne angucken. Trotzdem danke für den Tipp mit MPV, den Player kannte ich noch gar nicht.
Ich teste gerade ob der Bug auf den Matroska-Demuxer beschränkt ist, von ihm kommt jedenfalls für jedes Frame des Videos ein ungültiger Zeitstempel, was zum Fehlschlagen der genannten Funktion führt.
mpv ist ein IMHO besserer Fork von MPlayer.
Ja, das ist ein Bug des Matroska-Demuxers. Dasselbe Video als MP4 ist problemlos navigierbar.
edit: Der Bug schlägt beim Muxen in MKV zu.
Versuche gerade, so ein Video in den MP4-Container zu stecken, aber egal, welchen Audio-Codec ich nehme, bekomme immer irgendeine andere Fehlermeldung. Wähle ich AC3, sagt er mir sowas wie "Only AAC, AC3 and ... supported for Audio", nehm ich MP3, kommt etwas von "Kann Audio-Encoder nicht konfigurieren, stellen sie sicher, dass der Stream kompatibel ist (Anzahl der Kanäle, Bitrate, Format)
Video lasse ich auf Copy.
Ist es mit 2.6.18? Auch mit MP4v2? Statt AC3 könnte man auch den für MP4 eigentlich vorgesehenen AAC wählen.
Okay, schlechte Nachrichten: Es nützt nichts, ein im Avidemux nicht navigierbares MKV-Video mit demselben Avidemux als MP4 zu speichern. Dieser Vorgang kann nur mit einer nicht von diesem Bug betroffenen Software (zum Beispiel ffmpeg) erfolgreich durchgeführt werden.
Quote from: eumagga0x2a on January 08, 2017, 08:45:34 PM
Ich teste gerade ob der Bug auf den Matroska-Demuxer beschränkt ist, von ihm kommt jedenfalls für jedes Frame des Videos ein ungültiger Zeitstempel, was zum Fehlschlagen der genannten Funktion führt.
Mein Irrtum, Zeitstempel sind nicht das Problem, so weit kommen wir gar nicht. Der Aufruf von getFlags (https://github.com/mean00/avidemux2/blob/master/avidemux/common/ADM_editor/src/ADM_edSearch.cpp#L206) liefert kein einziges Keyframe.
Die Nicht-Navigierbarkeit entsteht beim Speichern als MKV. Es sollte demnach helfen, das ursprüngliche, noch navigierbare Video als MP4 zu speichern. Probleme mit AC3 als Audio-Codec kann ich mit der aktuellen Avidemux-Version nicht nachvollziehen. Möglicherweise gibt es im Video noch weitere Audiotracks, die inkompatible Codecs aufweisen? "Audio" --> "Tonspur wählen".
Ich muss mit Nachdruck nach der verwendeten Avidemux-Version fragen. Während ich etliche betroffene .mkv videos (mit Avidemux als MKV remuxte Mitschnitte der öffentlich-rechtlichen Sender, h264 in 720p Auflösung) identifiziert habe, sind sie allesamt älteren Datums. Mit der aktuellen Version 2.6.18 habe ich einen 16GiB großen Transport Stream von etwa 2 Stunden 45 Minuten Dauer als ein einwandfrei navigierbares .mkv Video im Kopiermodus speichern können. Dieses .mkv Video ließ sich ebenfalls einwandfrei im Kopiermodus für Video als navigierbares MKV abspeichern.
Den Bug hat es sicherlich gegeben, und die Rettung der betroffenen Videos ist nicht ganz einfach, aber die aktuelle Version hat ihn nicht mehr. Die Frage ist nur, ob ein Workaround im Avidemux für die durch frühere Versionen ruinierten Videos entwickelt werden kann und ob der Aufwand gerechtfertigt ist.
Also hier trat der Bug mit den letzten 4 Versionen auf, auch aktuell bei Version 2.6.18. Bei mir ist das als MKV gepackte Video nach wie vor nicht spulbar. Nach dem Packen als MP4 kann ich es dann allerdings auch einwandfrei mit VLC spulen (wenn es auch dauert). Wie das nun am TV ausschaut weiss ich auch noch nicht. Werde heute abend aber weitere Tests durchführen, ich denke mal das direkte Speichern in MP4 klappte wirklich nicht wegen weiterer (inkompatibler) Tonspuren, habe es dann aber mit einem 2. Durchlauf hinbekommen - sollte aber auch in einem Durchlauf klappen dank deines Tipps mit dem Audio -> Tonspur wählen.
Dies war kein 1. April Witz, dann.
This was no April 1st joke, then.Quote from: Jan Gruuthuse on April 01, 2012, 12:36:48 PM
Looks like it. Tested: loaded 5.19:00 video (19.8 GB) several cuttings and saves. Loaded new video, and avidemux stayed stable.
QuoteGetestet: geladen 5.19: 00 Video (19.8 GB) mehrere Schnitte und speichern
Avidemux Demo, schnellen Vorlauf in 720p 5 1/2 Stunde Video:
Avidemux Demo, fast forward in 720p 5 1/2 hour video (https://www.youtube.com/watch?v=LcUGtoHHmXg)
Unser Youtube-Kanal: Avidemux Demo (https://www.youtube.com/channel/UC7ycUgCIuOlChtpiTFfLTmw)
Ich bedauere, aber ich kann keinen Bezug zum Thema erkennen.
Alle MKVs (h264, 720p, beliebige Länge), die mit den vor dem 8. September 2014 von RPM Fusion angebotenen Avidemux-Versionen 2014 erstellt wurden, zeigen fälschlicherweise 100 FPS statt 50 und sind nicht navigierbar. Alle MKVs (h264, 720p, beliebige Länge), die ab dem 26. September 2014 erstellt wurden, zeigen korrekt 50 FPS und sind einwandfrei navigierbar. Leider habe ich keine yum-Logs aus der Zeit mehr, um das Update zu identifizieren, das das Problem damals gelöst hat.
Mit der aktuellen Version kann ich das geschilderte Problem auch mit sehr langen h264-Quellvideos, die selbst navigierbar sind, nicht reproduzieren. Ich würde bitten, die von ffprobe und/oder MediaInfo ausgegebenen Infos zu einem der Quellvideos, das nach Verarbeitung in Avidemux 2.6.18 nicht navigierbar wird, zu posten (den Dateinamen und den Pfad gerne durch Sternchen ersetzen oder sonst wie unkenntlich machen).
Wenn nicht das ganze sehr lange Video sondern nur ein Teil davon gespeichert wird, beeinflusst das die Navigierbarkeit?
Einen Teil des Videos kann ich nicht speichern, da sich das Video nicht schneiden lässt. ich kann weder manuell noch über die GUI die Marker A o. B setzen, d.h. den A-Marker einzig und allein an den Beginn des Videos, den B-Marker sehe ich nicht mehr, da er irgendwo am rechten Rand verschwindet. Im sichtbaren Bereich kann ich den B-Marker jedenfalls nicht setzen und auch eine Zeit- bzw. Positionsangabe für den B-Marker kann ich nicht setzen.
Habe das Quell-Video unter Ubuntu-Mate 16.04.1 mal durch ffprobe aus den Repos (libav-tools installiert) durch gejagt:
http://paste.ubuntu.com/23782996/ (http://paste.ubuntu.com/23782996/)
Das Problem dürfte demnach beim Quellvideo liegen. Bitte Avidemux im Terminal starten und die Ausgabe beim Laden, beim Versuch, durch das Quellvideo mit Bild-Auf / Bild-Ab zu navigieren und einen Marker A/B zu setzen posten.
die Zeile:
... [getRecoveryFromSei] 18:40:21-647 Cannot decode SEI
tritt mehrere hunderttausend mal auf (im log gekürzt, sonst hätte ich 15MB hochladen müssen, die entspr. Stelle ist markiert, Zeile 524)
nachdem ich per bild_hoch/_runter-Taste versuche, im Film zu navigieren, hängt sich die gesamte GUI auf. Aus dem Grund musste ich das log ein wenig zusammen schustern, sollte aber alles wesentliche drin stehen.
http://paste.ubuntu.com/23788348/ (http://paste.ubuntu.com/23788348/)
Danke. Nicht das "gewandeltes Video" ist nicht navigierbar sondern bereits die Quelle. Ein 200 bis 300 MiB großes Stückchen vom Anfang von so einem Quellvideo wäre als Sample (http://avidemux.org/smif/index.php/topic,17418.0.html) nicht schlecht. Mal schauen, ob es mir gelingt, Mean dafür zu interessieren.
Aus dem Sample wird zwar leider nichts mehr - habe das besagte Video aus Versehen gelöscht :-[ Habe aber ein anderes Video angetestet welches 9 GB gross war und genau die selben Audio- und Video-Formate hatte, es lies sich in Avidemux wie in VLC einwandfrei spulen und war auch nach dem Wandeln ins AC3-Audio noch einwandfrei spulbar. Ich gehe somit davon aus, dass es wirklich an einem schlechten Quell-Video gelegen haben muss.
Ich sehe das hier als erledigt und sage Vielen Dank nochmal an alle Beteiligten für Eure Mühen!
Bei mir sind es wie gesagt sämtliche mit Avidemux als MKV im Copy-Modus gespeicherten h264 Transport Streams aus der Zeit vor Ende September 2014, die betroffen sind. ÃÅ"ber den Umweg MKV --> TS --> MP4 gelingt es wenigstens navigierbare (in Avidemux navigierbare) MP4 videos zu erzeugen, die jedoch einen großen A/V-Versatz (1s) aufweisen. Es sieht aus als müsse ich dranbleiben :-\