Videos nicht mehr Spulbar nach Bearbeitung bei Quellgröße ab 6 bis 7 GB / mp4

[eumagga0x2a]

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?

[schwalmi]

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/

[eumagga0x2a]

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.

[schwalmi]

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/

[eumagga0x2a]

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 nicht schlecht. Mal schauen, ob es mir gelingt, Mean dafür zu interessieren.

[schwalmi]

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!

[eumagga0x2a]

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