-
AW: [TEST] MP4/MKV -> AVI framegenauer Schnitt mit OTR Verwaltung mittels Virtualdub
Hallo monarc
Ich habe soeben deine Version von OTR-Verwaltung getestet.
Verwendet habe ich folgende Dateien:
Alarm_fuer_Cobra_11_Die_Autobahnpolizei_12.08.10_0 3-05_rtl_45_TVOON_DE.mpg (HQ, mp4, avi)
Die_Kennedys_12.08.09_20-55_arte_45_TVOON_DE.mpg.HD.avi
System: kUbuntu 12.04
Das Schneiden und Umwandeln der Dateien mit den integrierten codecs hat problemlos funktioniert.
Allerdings kommt immer dann, wenn ich eine Datei schneide eine komische Musik. Das war bei der alten Version nicht so. Es handelt sich um eine typische Warteschleifen-Musik. Falls du weißt was ich meine: wie kann man das abschalten?
-
Liste der Anhänge anzeigen (Anzahl: 1)
AW: [TEST] MP4/MKV -> AVI framegenauer Schnitt mit OTR Verwaltung mittels Virtualdub
Hallo monarc99,
ich habe mal für meine persönlichen Bedürfnisse ein paar Änderungen vorgenommen, mit denen eine .ac3, die im selben Verzeichnis liegt wie die Video-Datei, automatisch mit mkvmerge mit dem Video zusammengemuxt wird. Es macht nicht mehr als man sonst von Hand machen würde, also ac3 splitten, eventuell von unterschiedlichen Cuts die Teile aneinanderhängen und dann die Audiodatei mit der vorher geschnittenen avi zusammenmuxen. Man kann die Funktion nicht abschalten oder sonstwie anpassen, weil ich nicht blicke, wie man die GUI verändert, aber für meine Zwecke reicht es.
Es sollte für alle Formate funktionieren, auch HQ, aber ich habe bisher nur HD getestet. Es ist auch nicht als Plugin implementiert, weil es ja automatisch bei allen Schnitten verwendet werden soll.
In dem Archiv sind nur die drei veränderten Dateien, die in die entsprechenden Verzeichnisse der Version vom 10.8.2012 kopiert werden müssen (bin/otrverwaltung, otrverwaltung/conclusions.py und otrverwaltung/actions/decodeorcut.py).
Falls jemand Verwendung dafür hat, viel Spaß damit.
Gruss, Jan.
Ach ja, die Wartemusik ist in dieser Version rauskommentiert.
Anhang 6634
-
AW: [TEST] MP4/MKV -> AVI framegenauer Schnitt mit OTR Verwaltung mittels Virtualdub
Hey super :)
Schaue ich mir gleich mal an. Funktioniert es denn auch, wenn der AC3 Stream fehlerhaft ist?
-
AW: [TEST] MP4/MKV -> AVI framegenauer Schnitt mit OTR Verwaltung mittels Virtualdub
Es hat dieselben Einschränkungen wie die sonst übliche Vorgehensweise mit mkvmerge. Wenn der Stream fehlerhaft ist, wird Audio/Video asynchron. Deshalb wird die MP3-Spur auch drin gelassen und man muss die Tonspur dann beim Anschauen umstellen. Bei den neueren HDs kann ich mich aber an keinen erinnern, bei dem das aufgetreten wäre. Nur bei den älteren von 2011, die ich vor kurzem noch mal geschnitten habe, waren einige dabei.
Ich glaube das Problem war, dass in der AC3-Spur die Timecodes nicht mitgespeichert sind. Wenn das richtig ist, ließe sich die Asynchronität nicht beheben, jedenfalls nicht automatisiert. Jedenfalls habe ich hier im Forum noch von keiner Lösung gelesen.
-
[TEST] MP4/MKV -> AVI framegenauer Schnitt mit OTR Verwaltung mittels Virtualdub
Zitat:
Ich glaube das Problem war, dass in der AC3-Spur die Timecodes nicht mitgespeichert sind. Wenn das richtig ist, ließe sich die Asynchronität nicht beheben, jedenfalls nicht automatisiert. Jedenfalls habe ich hier im Forum noch von keiner Lösung gelesen.
Ja, in den neuen AC3 sind jetzt Timecodes drin, weshalb mkvmerge sie synchron zusammen muxen kann. Allerdings repariert mkvmerge den AC3 Stream nicht - sprich wenn im AC3 1 Sek Ton fehlt - füllt sie mkvmerge nicht mit 1 sek Stille auf.
Es wäre ganz gut, wenn man den AC3 Stream erst reparieren würde, bevor man sie in MKV muxt. Weil sonst lauert in diesen MKV Dateien eine kleine Falle ... sie sind nur wegen dem MKV Container synchron.
Wenn man die Datei mal umwandeln will, erlebt man dann vielleicht eine unliebsame Überraschung.
mfg
monarc
-
AW: [TEST] MP4/MKV -> AVI framegenauer Schnitt mit OTR Verwaltung mittels Virtualdub
Hallo monarc99.
Ich habe Deine Version auch getestet. Nachdem x264vfw noch nicht in die normale otr-verwaltung integriert ist, scheint Deine Version bisher die einzige Möglichkeit zu sein unter Linux mit dem neuen Codec zu schneiden(?).
Ich selbst habe folgendes Problem: Laut terminal Ausgabe liest und schreibt Deine otr-verwaltung ihre Einstellungen weiterhin in ~/.config/otr-verwaltung, so dass Deine Voreinstellungen nicht greifen.
Wie machst Du denn das mit dem Wine-Verzeichnis? Müsste nicht ein WINEPREFIX gesetzt werden? Sonst würde doch weiterhin mit ~/.wine gearbeitet werden. Zumindest habe ich so (bis einschl. wine 1.3) meine Cut-Assistant Installationen voneinander getrennt.
Schöne Grüße
inqui
-
AW: [TEST] MP4/MKV -> AVI framegenauer Schnitt mit OTR Verwaltung mittels Virtualdub
Zitat:
Ist mir aber erst nachher aufgefallen, dass sich ein .wine Verzeichnis unbedingt im HOME Verzeichnis des Users liegen muss
Jap, danke.
Ich arbeite für alle anderen Wine-Geschichten _ausschließlich_ mit Wineprefixes. Tatsächlich existierte bei mir ~/.wine nicht :O -> kurz erstellt, alles gut :)
EDIT: Habe ich eben noch vergessen: Hast Du in Deiner Version schon die PAR für die US-Sender eingebaut? Ich glaube die sprache kam in einem anderen Thread schon drauf .. aufgrund der NTSC Auflösung dürfte die ja anders sein :O
Wäre super ... und danke für Deine Mühe und Deine Tips :)
-
AW: [TEST] MP4/MKV -> AVI framegenauer Schnitt mit OTR Verwaltung mittels Virtualdub
Zitat:
Zitat von
inqui
EDIT: Habe ich eben noch vergessen: Hast Du in Deiner Version schon die PAR für die US-Sender eingebaut? Ich glaube die sprache kam in einem anderen Thread schon drauf .. aufgrund der NTSC Auflösung dürfte die ja anders sein :O
Die gepatchte Version hier liest über mplayer den SAR Wert der originalen Datei aus und setzt ihn dann bei x264vfw wieder.
Sollte also mit allem funktionieren, was OTR so auf Lager hat.
Funktioniert aber nur, wenn man die von mir empfohlene x264vfw Version verwendet. Ich denke, wer ne ältere oder neuere x264vfw verwendet, wird Probleme bekommen. (deshalb auch die Idee VD+samt x264vfw beizulegen)
Da wird der Config_String von x264vfw manipuliert und x264vfw ist noch ein sehr aktives Projekt. Da kann sich der Aufbau schon von einer Version zur anderen sehr verändern.
Wir sind bisher ffdshow gewöhnt und das war praktisch über Jahre hinweg tot. Auch wenn die neue Versionen rausbringen, ändert sich da meinst nur sehr wenig. Die könnten schon mal 100 Versionen rausbringen, ohne dass sich der String veränderte.
mfg
monarc
-
AW: [TEST] MP4/MKV -> AVI framegenauer Schnitt mit OTR Verwaltung mittels Virtualdub
Zitat:
Die gepatchte Version hier liest über mplayer den SAR Wert der originalen Datei aus und setzt ihn dann bei x264vfw wieder.
Sollte also mit allem funktionieren, was OTR so auf Lager hat.
Sehr Cool! Danke! :)
Zitat:
Funktioniert aber nur, wenn man die von mir empfohlene x264vfw Version verwendet. Ich denke, wer ne ältere oder neuere x264vfw verwendet, wird Probleme bekommen
Was in Deiner Version ja kein Problem mehr sein dürfte :)
Vielen Dank jedenfalls das Du so viel Mühe reingesteckt hast. Klappt bei mir alles prima! :)
-
AW: [TEST] MP4/MKV -> AVI framegenauer Schnitt mit OTR Verwaltung mittels Virtualdub
Zitat:
Zitat von
inqui
Hallo monarc99.
Ich habe Deine Version auch getestet. Nachdem x264vfw noch nicht in die normale otr-verwaltung integriert ist, scheint Deine Version bisher die einzige Möglichkeit zu sein unter Linux mit dem neuen Codec zu schneiden(?).
Höchstens wenn man glaubt ohne wine nicht leben zu können......
-
AW: [TEST] MP4/MKV -> AVI framegenauer Schnitt mit OTR Verwaltung mittels Virtualdub
Zitat:
Höchstens wenn man glaubt ohne wine nicht leben zu können......
Hi,
naja, meine Experimente mit dem mencoder waren - zumindest was H264 angeht - eher wenig von Erfolg gekrönt. Das war bisher mit Wine (zumindest im Ergebnis) wesentlich zufriedenstellender :O
-
AW: [TEST] MP4/MKV -> AVI framegenauer Schnitt mit OTR Verwaltung mittels Virtualdub
Zitat:
Zitat von
inqui
Hi,
naja, meine Experimente mit dem mencoder waren - zumindest was H264 angeht - eher wenig von Erfolg gekrönt. Das war bisher mit Wine (zumindest im Ergebnis) wesentlich zufriedenstellender :O
Doch, doch, das geht.. Siehe mein Post im OTR-Verwaltungs-Thread (http://www.otrforum.comwww.otrforum....l=1#post356044)
-
AW: [TEST] MP4/MKV -> AVI framegenauer Schnitt mit OTR Verwaltung mittels Virtualdub
Die SAR Erkennung bei US Aufnahmen hat leichte Probleme, weil mplayer nur gerundete Werte liefert. Hab mal einen kleinen Hack rein, vielleicht klappt es so besser.
Wenn nicht, müsste die SAR Erkennung ganz umgeschrieben werden, nur leider keine Zeit für ^^
Änderungen:
+ Fix bei SAR Erkennung bei einigen US Sendungen
+ automatischer AC3 Schnitt und mux zu MKV von JanS aufgenommen
+ Wartesound auskommentiert
Zip:
https://github.com/monarc99/otr-verw...zipball/monarc
Sollte reichen, wenn man das Zip einfach über das alte Verzeichnis entpackt und die geänderten Dateien ersetzt. (Nicht getestet ;) )
Wer klug ist, macht vorher ne Kopie ^^
mfg
-
AW: [TEST] MP4/MKV -> AVI framegenauer Schnitt mit OTR Verwaltung mittels Virtualdub
Hallo monarc99,
mir ist noch ein Fehler in meinem AC3 muxen aufgefallen, der zu einem Abbrechen der Conclusions führen kann. In der Datei otrverwaltung/actions/decodeorcut.py muss die Zeile 639
Zitat:
return cut_video, ", None
heißen, statt
Zitat:
return cut_video, None, None
. Andernfalls wird in den Conclusions ac3_file auf None gesetzt und dann beim Verschieden in den Müll versucht zu überprüfen, ob None eine gültige Datei ist, was zum Abbruch führt (Die folgenden Verschiebe-Aktionen werden einfach nicht mehr ausgeführt).
Zum automatischen Fixen der AC3-Spur bei Fehlern habe ich bisher noch nichts gefunden (außer einem komplette Neukodieren). Ac3fix und ähnliches scheint es nur für Windows zu geben.
Gruß
Jan
-
AW: [TEST] MP4/MKV -> AVI framegenauer Schnitt mit OTR Verwaltung mittels Virtualdub
Zitat:
Zitat von
JanS
mir ist noch ein Fehler in meinem AC3 muxen aufgefallen, der zu einem Abbrechen der Conclusions führen kann. In der Datei otrverwaltung/actions/decodeorcut.py muss die Zeile 639 heißen, statt. Andernfalls wird in den Conclusions ac3_file auf None gesetzt und dann beim Verschieden in den Müll versucht zu überprüfen, ob None eine gültige Datei ist, was zum Abbruch führt (Die folgenden Verschiebe-Aktionen werden einfach nicht mehr ausgeführt).
Zum automatischen Fixen der AC3-Spur bei Fehlern habe ich bisher noch nichts gefunden (außer einem komplette Neukodieren). Ac3fix und ähnliches scheint es nur für Windows zu geben.
Ich habs mal übernommen. :)
Nun, wine ist ja sowieso schon für Virtualdub Pflicht. Also könntest du auch ein Windows Tool verwenden.
Hast du nicht mal auch an dem Videoeditor von benn etwas gemacht? Kann man das auch aufnehmen?
mfg,
monarc
-
AW: [TEST] MP4/MKV -> AVI framegenauer Schnitt mit OTR Verwaltung mittels Virtualdub
Zitat:
Zitat von
monarc99
Hast du nicht mal auch an dem Videoeditor von benn etwas gemacht? Kann man das auch aufnehmen?
Ich habe es so abgeändert, dass man damit auch eine bereits existierende Cutlist verändern kann (siehe http://www.otrforum.com/showthread.p...l=1#post354174 ). Der Ablauf könnte so aussehen, dass eine bereits existierende lokale Cutlist automatisch geladen wird, wenn der manuelle Cutmodus gestartet wird. Wenn man dann mit einer heruntergeladenen Cutlist nicht zufrieden war, könnte man die Cutlist gespeichert lassen und im nächsten Schritt dann die Datei manuell bearbeiten. Dazu müsste man das CutInterface allerdings noch in OTRVerwaltung einbauen. Das dürfte nur ein wenig Code vor und nach dem Aufrufen des Dialogs sein, aber bevor ich das mache, wäre es vielleicht sinnvoll, wenn du oder andere das CutInterface testen. Vor allem wäre die Frage, ob die Bedienbarkeit noch irgendwie verbessert werden muss.
Gruß,
Jan
-
AW: [TEST] MP4/MKV -> AVI framegenauer Schnitt mit OTR Verwaltung mittels Virtualdub
Zitat:
Zitat von
JanS
Das dürfte nur ein wenig Code vor und nach dem Aufrufen des Dialogs sein, aber bevor ich das mache, wäre es vielleicht sinnvoll, wenn du oder andere das CutInterface testen. Vor allem wäre die Frage, ob die Bedienbarkeit noch irgendwie verbessert werden muss.
Sorry, hat etwas gedauert, bis ich es zum Laufen bekomme habe. Erst mit neuen Libraries läuft es jetzt.
Was auf jeden Fall noch rein müsste, dass man größere Sprünge machen kann. Falls man die nächste Werbung suchen möchte, sind 10 Frame Sprünge etwas klein.
Ansonsten kann ich mich gut durch den Film bewegen. Klappt ganz gut :)
mfg,
monarc
-
Liste der Anhänge anzeigen (Anzahl: 1)
AW: [TEST] MP4/MKV -> AVI framegenauer Schnitt mit OTR Verwaltung mittels Virtualdub
Hallo monarc99,
stimmt, ich hab manchmal auch viel zu klicken gehabt. Aber mit dem Slider konnte man die grobe Position der Werbung auch ganz gut finden. Ich habe jetzt mal Buttons für 100er und 1000er Frame-Sprünge hinzugefügt. Was hältst du davon?
Gruß
Jan
Anhang 6909
-
AW: [TEST] MP4/MKV -> AVI framegenauer Schnitt mit OTR Verwaltung mittels Virtualdub
Zitat:
Zitat von
JanS
Hallo monarc99,
stimmt, ich hab manchmal auch viel zu klicken gehabt. Aber mit dem Slider konnte man die grobe Position der Werbung auch ganz gut finden. Ich habe jetzt mal Buttons für 100er und 1000er Frame-Sprünge hinzugefügt. Was hältst du davon?
Den Slider hatte ich bislang übersehen :peinlich:
Aber im Grunde habe ich sowas wie den Slider gesucht, nur noch per Tastensteuerung. Beim Slider springt er von Keyframe zu Keyframe, genau das was ich möchte.
Videocodec haben eine Szenenwechselerkennungsautomatik (schönes Wort ;) ) und erstellen dort Keyframes. Also ist die Stelle, an der ich schneiden will, in der Regel nicht weit von einem Keyframe entfernt.
Zum anderen lassen sich Keyframes am schnellsten decodieren, also ist die schnellste Möglichkeit sich durch eine Videodatei zu bewegen, von Keyframe zu Keyframe zu springen.
Jeder bedient es wahrscheinlich anders, mir ist es am liebsten, wie es bei Avidemux ist.
Cursor Tasten links/rechts -> 1 Frame vor und zurück.
Cursor Tasten Rauf/Runter -> nächstes/vorheriges Keyframe
Mit Rauf/Runter die grobe Stelle suchen und dann Frame für Frame weiter.
10/100 Frames weiter kann man mal brauchen, aber ich muss beim ersten Mal ja sowieso Frame für Frame durch die Szene, um die Szene kennen zulernen, ob sie am Ende der Werbung wiederholt wird.
Mein Vorschlag wäre:
Den '1000 Sprung Button' zu einem Button 'nächster/vorheriger Keyframe' umbauen und per Tastatur erreichbar machen.
Dann wäre zumindest ich zufrieden ;)
mfg
monarc
-
AW: [TEST] MP4/MKV -> AVI framegenauer Schnitt mit OTR Verwaltung mittels Virtualdub
Hmm,
dummerweise wurden bei GStreamer die Flags zum Springen zwischen Keyframes erst in Version 1.0 eingeführt. Ich wüsste jetzt keinen einfachen Weg das in 0.10 umzusetzen. Also müsste man den GStreamer-Code auf 1.0 umschreiben, was jetzt nicht so viel Arbeit wäre, abgesehen vom ganzen Umbenennen. Die Frage wäre, ob alle schon GStreamer 1.0 zur Verfügung haben? Für openSuse 11.4 gibt's das noch nicht. Welche Versionen hast du denn installiert?
Gruß
Jan
-
AW: [TEST] MP4/MKV -> AVI framegenauer Schnitt mit OTR Verwaltung mittels Virtualdub
Ich hab hier unter Mageia 2 Gstreamer 0.10.36-1.mga2 installiert. Und für mich sieht es aus, als ob der von Keyframe zu Keyframe springt, wenn man den Slider bewegt.
Mit dieser Datei getestet (einkodierte Framenummern zur besseren Unterscheidung):
http://dl.dropbox.com/u/7287363/Big_..._DE.mpg.HQ.avi
(c) copyright 2008, Blender Foundation / www.bigbuckbunny.org
Und mit Avidemux2.6 überprüft. Der zeigt die Frames, die cut.py per Slider anspringt, als Keyframes an.
mfg
Monarc
-
AW: [TEST] MP4/MKV -> AVI framegenauer Schnitt mit OTR Verwaltung mittels Virtualdub
Oh, ich habe mich wohl nicht präzise genug ausgedrückt. Mit dem Slider funktioniert es, weil es ein Flag dafür gibt zum nahesten Keyframe zu springen. Es gibt aber kein Flag dafür, zum folgenden bzw. zum vorherigen Keyframe zu springen. Wenn ich mich also bereits an einem Keyframe befinde und als Seek-Position sagen wir 10 Frames weiter angebe, mit GST_SEEK_FLAG_KEY_UNIT, dann springt er möglicherweise zum selben Keyframe zurück, weil das andere weiter weg ist. Erst mit den Flags GST_SEEK_FLAG_SNAP_BEFORE / _AFTER, die in GStreamer 1.0 eingeführt wurden, ist es möglich, anzugeben in welcher Richtung er nach dem Keyframe suchen soll.
Man könnte sich natürlich ein Index erstellen lassen, in dem alle Keyframe gelistet sind. Das dauert dann allerdings jeweils eine halbe Minute oder eine ganze und sollte ja eigentlich unnötig sein.
Gruß
Jan
-
AW: [TEST] MP4/MKV -> AVI framegenauer Schnitt mit OTR Verwaltung mittels Virtualdub
Hm, verstehe ... für Gstreamer 1.0 ist es noch zu früh, denke ich.
Der Max-Keyframe Abstand bei den HQ,HD,mp4 ist 250 Frames. Divx.avi müsste ich erst nachsehen.
Also wenn du 250 Frames in eine Richtung springst und auf Keyframe einstellst, solltest du zumindest bei einem anderen Keyframe landen. (vielleicht reicht auch schon ne kleinere Zahl)
So wird vielleicht nicht jedes Keyframe angesprungen und ein paar ausgelassen, aber auch nicht tragisch. Man sucht ja nicht Keyframes, sondern nur die Werbung.
mfg
monarc
-
Liste der Anhänge anzeigen (Anzahl: 1)
AW: [TEST] MP4/MKV -> AVI framegenauer Schnitt mit OTR Verwaltung mittels Virtualdub
Okay. Ich habe das mal eingebaut. Eigentlich sollte man meinen, dass bei einem Max-Keyframe Abstand von 250 das schon mit 126er Schritten funktioniert, aber man muss tatsächlich 250er Schritte verwenden, damit man nicht an einem Frame hängen bleibt. So überspringt man natürlich einige Keyframes und erhält unterschiedliche Keyframes, je nachdem ob man vorwärts oder rückwärts durchgeht. Aber du kannst es ja mal testen. Bei mir hat es jetzt mit HQ und Divx funktioniert. Die Tastenbelegung ist so wie du sie gewünscht hast.
Gruß
Jan
Anhang 6914
-
Liste der Anhänge anzeigen (Anzahl: 1)
AW: [TEST] MP4/MKV -> AVI framegenauer Schnitt mit OTR Verwaltung mittels Virtualdub
So, hat ein bisschen gedauert, weil das Debuggen so aufwendig war (immer diese Deadlocks). Ich habe ein kleines GStreamer-Element geschrieben, das die Suche nach den Keyframes umsetzt. Die einfache Variante konnte ich leider nicht umsetzen, weil ich dafür das ganze DecodeBin hätte neu schreiben müssen. Also habe ich die Suchvariante benutzt, die du beschrieben hast: Seeks in 25er Frame Abstände mit GST_SEEK_FLAG_KEY_UNIT, bis ein neues Keyframe kommt. Ich habe das für beide Richtungen genommen, da es keine Garantie gibt, dass die Demuxer für MP4 oder MKV ebenso wie Avi Demuxer das letzte Keyframe wählen oder nicht doch das naheste.
Bei HQ und HD scheint das sehr gut zu funktionieren, da die einen minimalen Abstand von 25 Frames zwischen Keyframes haben. Bei den Standard-Avis wird schon mal das eine oder andere Keyframe übersprungen, wenn mehrere dicht aneinander liegen. Ich habe in einer Datei mit Avidemux zum Beispiel mehrfach zwei Keyframes direkt hintereinander gefunden. Aber mir sind ehrlich gesagt nur die HQ und HD wichtig.
Weiter habe ich noch zwei kleine Verbesserungen eingebaut: Wenn man die Pfeiltasten benutzt, wechselt nicht mehr der Fokus zwischen den Buttons hin und her. Und die Zeitangabe wird jetzt komplett mit Integer-Methoden berechnet.
Viele Grüße
Jan
Anhang 6929
-
AW: [TEST] MP4/MKV -> AVI framegenauer Schnitt mit OTR Verwaltung mittels Virtualdub
Zitat:
Zitat von
JanS
Seeks in 25er Frame Abstände mit GST_SEEK_FLAG_KEY_UNIT, bis ein neues Keyframe kommt. Ich habe das für beide Richtungen genommen, da es keine Garantie gibt, dass die Demuxer für MP4 oder MKV ebenso wie Avi Demuxer das letzte Keyframe wählen oder nicht doch das naheste.
Bei HQ und HD scheint das sehr gut zu funktionieren, da die einen minimalen Abstand von 25 Frames zwischen Keyframes haben. Bei den Standard-Avis wird schon mal das eine oder andere Keyframe übersprungen, wenn mehrere dicht aneinander liegen. Ich habe in einer Datei mit Avidemux zum Beispiel mehrfach zwei Keyframes direkt hintereinander gefunden. Aber mir sind ehrlich gesagt nur die HQ und HD wichtig.
Also ich finde es funktioniert super bei avis und mkvs. Nur bei MP4 springt er mir manchmal genau um 25 Frames und ladet nicht bei einen Keyframe. ^^
Kann man gut an diesen Dateien testen, da sind die Framenummer einkodiert:
https://dl.dropbox.com/u/7287363/Big..._DE.mpg.HQ.avi
https://dl.dropbox.com/u/7287363/Big..._DE.mpg.HQ.mkv
https://dl.dropbox.com/u/7287363/Big..._DE.mpg.HQ.mp4
(c) copyright 2008, Blender Foundation / www.bigbuckbunny.org
MKVs funktionieren am Besten. Da bleibt er auch framegenau drauf.
Bei den AVIs liegt er früher oder später ein Frame daneben.
Bei den MP4 bleibt er schön drauf, nur scheint er manchmal Frames für Keyframes zu halten, die eigentlich keine sind. Zumindest erkennt Avidemux sie nicht als solche an.
mfg
monarc
-
AW: [TEST] MP4/MKV -> AVI framegenauer Schnitt mit OTR Verwaltung mittels Virtualdub
Hallo monarc99,
danke für die Dateien. Zum Testen sind die ideal. Dass die MKVs am Besten funktionieren ist kein Wunder. Der Container ist ideal für das Arbeiten mit Timecodes.
Bei der AVI ist mir aufgefallen, dass Keyframes immer exakt gefunden werden, das erste Frame nach einem Keyframe wiederholt wird. Bis zum nächsten Keyframe ist dann eine Differenz von ein oder zwei Frames zwischen den einkodierten Nummern und der berechneten Framenummer. Vor dem nächsten Keyframe werden dann entsprechend ein oder zwei Frames übersprungen.
Bei der MP4 ist mir aufgefallen, dass vor dem zweiten Keyframe ebenfalls zwei Frames übersprungen werden (also 248 und 249) und ab dann ein Versatz von zwei Frames das ganze Video über besteht. Vielleicht klappt deswegen auch die Suche nach Keyframes zwischen den ersten beiden nicht. Nach Frame 250 funktioniert die Suche bei mir jedenfalls richtig abgesehen von der Differenz von zwei Frames.
Woran das liegen könnte, kann ich jetzt so nicht nachvollziehen. Eventuell ist die Berechnung der Timestamps in den Demuxern oder Parsern in GStreamer nicht ganz sauber implementiert? Dann könnte man da nicht viel machen (außer die Plugins zu debuggen, was ich sicherlich nicht machen werde).
Edit: Ich habe mir die Dateien noch mal mit Avidemux 2.6.1 angeschaut: Das erste Frame der MP4 hat dort einen Timestamp von 80 Millisekunden. Geht man von konstanter Framerate aus, erhält man eine Differenz von zwei Frames für den ganzen Film. Die GStreamer Plugins scheinen davon auszugehen, dass das erste Frame Timecode 0 haben müsste, was zwischen den beiden ersten Keyframes zu Problemen führt.
Im AVI-File besteht zwischen dem ersten Frame und dem zweiten eine Zeitdifferenz von 120 Millisekunden statt 40, was auf eine ähnliche 2 Frame-Verschiebung für den ganzen Film hinausläuft. Mit dem Unterschied, das der Avi-Demuxer bei jedem Keyframe den gespeicherten Timestamp verwendet, der irgendwie um 80 Millisekunden von den anderen abweicht. Ist das vielleicht eine Differenz zwischen Timecodes im Stream (P/B-Frames) und im Container (Keyframes)?
Im Matroska-File hat das erste Frame den Timestamp 240 Millisekunden. Das führt aber scheinbar zu keinen Problemen, da GStreamer alle Timecodes vom Container verwenden kann und diese dann konstant um 240 Millisekunden verschiebt.
Ich habe mir auch mal ein HQ File von OTR angeschaut. Das hat ebenfalls 120-Millisekunden Abstand zwischen den ersten beiden Frames. Das Problem hätten wir also auch mit den OTR-Files.
-
AW: [TEST] MP4/MKV -> AVI framegenauer Schnitt mit OTR Verwaltung mittels Virtualdub
Zitat:
Zitat von
JanS
Edit: Ich habe mir die Dateien noch mal mit Avidemux 2.6.1 angeschaut: Das erste Frame der MP4 hat dort einen Timestamp von 80 Millisekunden. Geht man von konstanter Framerate aus, erhält man eine Differenz von zwei Frames für den ganzen Film. Die GStreamer Plugins scheinen davon auszugehen, dass das erste Frame Timecode 0 haben müsste, was zwischen den beiden ersten Keyframes zu Problemen führt.
Im AVI-File besteht zwischen dem ersten Frame und dem zweiten eine Zeitdifferenz von 120 Millisekunden statt 40, was auf eine ähnliche 2 Frame-Verschiebung für den ganzen Film hinausläuft. Mit dem Unterschied, das der Avi-Demuxer bei jedem Keyframe den gespeicherten Timestamp verwendet, der irgendwie um 80 Millisekunden von den anderen abweicht. Ist das vielleicht eine Differenz zwischen Timecodes im Stream (P/B-Frames) und im Container (Keyframes)?
Im Matroska-File hat das erste Frame den Timestamp 240 Millisekunden. Das führt aber scheinbar zu keinen Problemen, da GStreamer alle Timecodes vom Container verwenden kann und diese dann konstant um 240 Millisekunden verschiebt.
Diese Verschiebung am Anfang bei Avidemux 2.6 hat vielleicht interne (Editor-)Gründe und entspricht vielleicht nicht unbedingt den Files. Bei AVIs gibt es keine gespeicherten Timecodes und auch verschiedene Abstände zwischen Frames gibt es nicht, weil das wäre ja dann variable Framerate. Und das geht bei AVIs nicht. Auch bei den MKVs fangen die Timecodes laut mkvinfo bei 0 an (mkvinfo -s file.mkv).
Ich hab bei meiner OTR-V Version vor einiger Zeit eingebaut, dass man auch per Avidemux 2.6 die Schnittlisten erstellen kann. Und da wandele ich auch vorher jede Datei schnell in MKV um, weil es damit am Besten geht. Auch wäre das Schneiden dieser MKV mit VD kein Problem. Und auch mit das Cutinterface kann am besten mit MKV umgehen.
mfg
-
AW: [TEST] MP4/MKV -> AVI framegenauer Schnitt mit OTR Verwaltung mittels Virtualdub
Nun ja: Im H264-Bytestream, den der Avi-Demuxer von GStreamer ausspuckt, haben die Keyframes Timestamps und alle anderen Frames nicht. Woher der Demuxer die Timestamps holt, weiß ich nicht. Vielleicht berechnet er sie auch nur unter Annahme einer konstanten Framerate. Die Frage ist, woher die anderen Timestamps stammen. Die stimmen nämlich mit den Timestamps in Avidemux 2.6.1 überein. Und auch bei Avidemux 2.5 sind die ersten beiden Frames Humbug und erst danach beginnt der eigentliche Stream wieder mit denselben Timestamps. Deshalb habe ich mich gefragt, ob der H264-Stream selbst irgendwo eigene Timestamps speichert. Vielleicht muss ich einfach mal wieder GStreamer Quellcode wälzen :-(
Ansonsten ist mir das auch schon häufig aufgefallen, dass man lieber zwei Frames Abstand zur Werbung hält. Deshalb würde mich das nicht sonderlich stören. Gegen MKV hätte ich aber auch nichts. VirtualDub würde das allerdings wieder in ein AVI umwandeln, wenn ich das richtig sehe, oder?
Gruß
Jan
-
AW: [TEST] MP4/MKV -> AVI framegenauer Schnitt mit OTR Verwaltung mittels Virtualdub
Sooo,
ich habe jetzt mal ein bisschen Quellcode und Debugmessages in GStreamer recherchiert und bin jetzt einiges schlauer. In GStreamer 0.10 übernimmt der Decoder einfach die Timestamps die er vorgefertigt kriegt. Die stammen vermutlich vom Parser, der scheinbar die Pakete nach konstanter Framerate durchnummeriert. Dummerweise bleibt dabei der Timestamp des zweiten Frames irgendwo in den Tiefen der ffmpeg-Bibliotheken verschollen, so dass alle weiteren Timestamps um ein Frame daneben liegen.
In GStreamer 1.0 ist dieser Fehler beseitigt (wie könnte es anders sein). Dort erhalten nur die Keyframes einen gültigen Timestamp. Die anderen Timestamps werden von der Basisklasse für Videodekodierer nach der Dekodierung berechnet, wenn alle Frames in der richtigen Reihenfolge sind. Dann wird einfach jedes Mal die Dauer eines Frames hinzuaddiert.
Das halte für ein gewichtiges Argument, zu GStreamer 1.0 zu wechseln. Ich habe aber gerade gesehen, dass man dafür doch ein bisschen tüfteln müsste, weil die GNonLin-Plugins noch nicht auf Version 1.0 umgeschrieben worden sind. Aber da hätte ich schon ein, zwei Ideen.
Gruß
Jan
-
AW: [TEST] MP4/MKV -> AVI framegenauer Schnitt mit OTR Verwaltung mittels Virtualdub
Zitat:
Zitat von
JanS
Das halte für ein gewichtiges Argument, zu GStreamer 1.0 zu wechseln. Ich habe aber gerade gesehen, dass man dafür doch ein bisschen tüfteln müsste, weil die GNonLin-Plugins noch nicht auf Version 1.0 umgeschrieben worden sind. Aber da hätte ich schon ein, zwei Ideen.
Wie verbreitet ist denn Gstreamer 1.0 denn schon?
Bei Mageia wird es frühestens in Mageia 3 auftauchen.
mfg
Monarc
-
AW: [TEST] MP4/MKV -> AVI framegenauer Schnitt mit OTR Verwaltung mittels Virtualdub
Ich fürchte, GStreamer 1.0 ist noch gar nicht verbreitet. Zumindest auf openSUSE 12.2 musste ich es von Hand auswählen und für openSUSE 11.4 gibt es keine Binärpakete. Vor allem habe ich heute bemerkt, dass man auch auf Gtk3 umsteigen müsste, um GStreamer 1.0 in Python verwenden zu können (wegen dem GI repository System). Das kommt also wohl nicht in Frage.
Aber die Quellcode-Sichtungen haben mich noch auf eine andere Idee gebracht, die ich ausprobieren könnte. Der Fehler ist ja, dass ffmpeg die vorgegebenen Timecodes irgendwie falsch zuordnet. Wenn die Timecodes der P-/B-Frames wieder gelöscht werden, verwendet das Plugin einen anderen Algorithmus, um die Timecodes zu berechnen. Vielleicht funktioniert ja der richtig. Ansonsten gibt es noch einen anderen h264-Parser, der mehr Optionen bietet. Mal schauen, ob ich die Autoplugging-Elemente überzeugen kann, den zu verwenden.
Gruß
Jan
-
AW: [TEST] MP4/MKV -> AVI framegenauer Schnitt mit OTR Verwaltung mittels Virtualdub
Zitat:
Zitat von
JanS
Aber die Quellcode-Sichtungen haben mich noch auf eine andere Idee gebracht, die ich ausprobieren könnte. Der Fehler ist ja, dass ffmpeg die vorgegebenen Timecodes irgendwie falsch zuordnet. Wenn die Timecodes der P-/B-Frames wieder gelöscht werden, verwendet das Plugin einen anderen Algorithmus, um die Timecodes zu berechnen. Vielleicht funktioniert ja der richtig. Ansonsten gibt es noch einen anderen h264-Parser, der mehr Optionen bietet. Mal schauen, ob ich die Autoplugging-Elemente überzeugen kann, den zu verwenden.
Probiers aus ... aber im Vergleich zu anderen schlägt sich Gstreamer schon sehr gut.
Aber dass das mit AVI problemlos funktionieren wird, da hab ich meine Zweifel. Meines Wissens arbeitet der Algo, der die richtige Reihenfolge der Frames rausfinden soll, recht gut, aber stösst irgendwann an seine Grenzen. Deshalb hat man AVI auch aufgegeben und sich die Arbeit mit MKV gemacht.
mfg
monarc
-
Liste der Anhänge anzeigen (Anzahl: 1)
AW: [TEST] MP4/MKV -> AVI framegenauer Schnitt mit OTR Verwaltung mittels Virtualdub
Hallo monarc99,
es hat geklappt. Jetzt stimmen die Frameangaben sowohl bei MKV als auch bei AVI perfekt überein. Nur bei MP4 haben seltsamerweise die Keyframes falsche Timecodes. Bei allen anderen Frames stimmen die Timecodes. Ich frage mich, was der MP4 Demuxer da anstellt. Aber egal. MP4 werde ich eh nicht schneiden.
Nur im Wiedergabe-Modus und insbesondere, wenn man die Wiedergabe pausiert, passen die Timecodes nicht. Aber mit einem Frame vor oder zurück, also einem Seek, passt es wieder.
Bei AVI konnte ich jetzt keine Probleme mehr feststellen. Bei MKV ist mir aufgefallen, dass ein Deadlock auftreten kann, wenn man die Links- oder Rechts-Taste längere Zeit gedrückt hält, um einen längeren Bereich durch zu spulen. Ich habe es erstmal so umgestellt, dass erst dann ein Frame gesprungen wird, wenn man die Taste loslässt. Aber wenn man sehr schnell Rechts oder Links drückt, kann man den Deadlock immer noch hervorrufen.
Um ein Video schnell durch zu gehen, wird man jetzt aber ohnehin von Keyframe zu Keyframe springen und dort konnte ich mit einem gut platzierten Mutex das Problem vermeiden.
Wenn jetzt nicht noch irgendwo Bugs auftauchen, würde ich das Interface so in deine letzte Version von OTR-V einbauen. Wahrscheinlich nächstes Wochenende oder so.
Gruß
Jan
Anhang 6937
-
AW: [TEST] MP4/MKV -> AVI framegenauer Schnitt mit OTR Verwaltung mittels Virtualdub
Zitat:
Zitat von
JanS
Wenn jetzt nicht noch irgendwo Bugs auftauchen, würde ich das Interface so in deine letzte Version von OTR-V einbauen. Wahrscheinlich nächstes Wochenende oder so.
Ich habs mal kurz ausprobiert. Funktioniert gut, wirklich testen kann man es aber erst, wenn es eingebaut ist und man es täglich verwendet.
Das andere Problem ist, dass es jetzt fast zu gut funktioniert. Besser als Virtualdub selbst z.B. ... VD hat durch die VFW Schnittstelle bei der momentanen HQ/HD Kodierung und dem momentanen Decoder aus x264vfw einen 2 Frame Delay.
Sprich, wenn man will, dass er an Frame 100 schneiden soll, muss man ihm Frame 102 bei HD/HQ übergeben. Bei mp4 und divx das Frame 100 (muss ich aber nochmal überprüfen)
Verschiedene Win-Programme (CA, CC) lesen wohl auch über VFW die Dateien ein. Die schreiben praktisch die falschen Timecodes schon in die Cutlists. Wobei verschiedene ffdshow Decoder andere Delays erzeugen können, bis zu 5-6 Frames.
(je nach installierten VD/Decoder/Encoder Version kann da was anderes rauskommen)
Cutana und SuperOTR scheinen bei einer oberflächlichen Überprüfung die richtigen Werte in die Cutlists zu schreiben, müsste aber noch genauer untersucht werden.
OTR-Verwaltung erstellt Cutlisten momentan über Avidemux2.5 und VD ... beide mit einem 2-Frame Delay. Also auch Cutlists mit eigentlich falschen Werten.
Ich hab bei es mir lokal mal so eingestellt, dass über Avidemux2.5/6 und VD Cutlists mit den richtigen Werten erstellt werden. Und die Werte jeweils angepasst werden, wenn sie VD übergeben werden.
Bloß dann funktionieren natürlich die CA/CC Cutlists noch weniger, als sie durch den Smart Rendering Bug von VD es eh schon tun.
mfg
monarc
-
AW: [TEST] MP4/MKV -> AVI framegenauer Schnitt mit OTR Verwaltung mittels Virtualdub
Nun ja, ich denke, es sollte erst mal das Ziel sein, die richtigen Zeiten zu haben. Dann können wir überlegen, ob wir von Hand einen 2-Frame Delay einbauen, um die Austauschbarkeit mit CA und CC bei den hochgeladenen Cutlisten zu gewährleisten. Sowohl bei VirtualDub, als auch beim Dekoder gibt ja es einige Versionen, die bevorzugt benutzt werden, bzw. in der Vergangenheit empfohlen wurden.
-
AW: [TEST] MP4/MKV -> AVI framegenauer Schnitt mit OTR Verwaltung mittels Virtualdub
Ich würde sagen, es ist die einzige sinnvolle Möglichkeit, die richtigen Werte zu nehmen. Und in den Cutlists steht normalerweise auch die Schnittsoftware drin, da kann man dann vielleicht noch etwas tricksen.
Andere Frage, hast du in Gstreamer auch die Info, ob das aktuelle Frame ein IDR/I/P/B Frame ist und ob du die Info anzeigen kannst?
-
AW: [TEST] MP4/MKV -> AVI framegenauer Schnitt mit OTR Verwaltung mittels Virtualdub
In den vorgesehen Feldern bei den Buffern gibt es nur Flags für Delta Frames, das ist also das Gegenteil eines Keyframe-Flags. Zwischen P und B lässt sich nicht weiter unterscheiden. Theoretisch haben die Plugins die Möglichkeit zusätzliche Metadaten an die Buffer zu hängen. Als ich bei GStreamer 1.0 mal nachgeschaut habe, war dort aber nichts zu finden. Ich vermute deshalb, dass es bei 0.10 auch keine zusätzlichen Infos gibt. Man könnte aber theoretisch Elemente schreiben, die vor dem Dekodieren solche Informationen bestimmen und dann an den Buffer hängen.
-
AW: [TEST] MP4/MKV -> AVI framegenauer Schnitt mit OTR Verwaltung mittels Virtualdub
Es reicht, wenn man weiß, wo die Keyframes liegen, der Rest ist egal.
Wenn man direkt vor einen Keyframe schneidet (Frames 247-253, Keyframe bei 250)
Code:
.z.B.
B B P K P B B
B B P | K P B B
Also ab dem K (Keyframe) alles wegschneidet - Werbung z.B. - dann werden die letzten beiden Frames vor dem Keyframe vom Smart Rendering Code von Virtualdub falsch vom Decoder gelesen.
Also statt Frame 249 holt er dann z.B. Frame 254, der schon in der Werbung liegt ... diese beiden letzten Frames ist dann diese Werbung, die immer aufblitzt, obwohl man richtig geschnitten hat.
Deshalb immer 2 Frames entfernt von einem Keyframe schneiden, dann tritt das Problem nicht auf. Dafür sollte man aber wissen, wo sie sind.
Ich habe auch einen Bugreport bei VD eingereicht, muss man aber sehen, ob der Bug in VD irgendwann gefixt ist.
mfg
monarc
-
AW: [TEST] MP4/MKV -> AVI framegenauer Schnitt mit OTR Verwaltung mittels Virtualdub
Also meine Beobachtung mit dem Cutinterface sieht eher anders aus. VirtualDub selbst scheint auch in dem Fall, den du geschildert hast, framegenau zu schneiden (es gibt ja nichts einfacheres als Frames zu zählen). Gerade beim Schnitt an Keyframes läuft also alles richtig. Wenn aber ein Teil neu kodiert werden muss, dann beginnt dieser Teil zwei Frames zu früh und vor dem nächsten Keyframe fehlen zwei Frames.
Ich deute das ganze so: Das Cutinterface liefert die richtigen Zeiten und damit auch die exakten Frameangaben. VirtualDub selbst arbeitet auch perfekt framegenau. In dem Abschnitt, der neukodiert wird, macht sich der 2-Frame-Delay des VfW-Codecs bemerkbar, so dass die neukodierte Stelle um zwei Frames verschoben ist.
Was du beschreibst, würde ich darauf zurückführen, dass beim Erstellen der Cutlist auch ein VfW-Codec mit 2-Frame-Delay verwendet wurde. Dadurch liegt das Ende des ersten Abschnitts um zwei Frames zu weit hinten, so dass in deinem Beispiel das Keyframe und ein weiteres Frame mitkopiert werden (VirtualDub kopiert die Frames ja einfach). Da die Frames nicht nach PTS sondern DTS sortiert sind, kann es sein, dass das nächste Frame nach dem Keyframe ein B-Frame ist, je nach Topologie des Streams also das dritte oder vierte Frame nach dem Keyframe.
Am Beginn des nächsten Abschnitts haben sowohl die Cutlist als auch der VfW-Codec einen 2-Frame-Delay, so dass tatsächlich genau das Frame als erstes kodiert wird, das man haben wollte. Und dass vor dem nächsten Keyframe zwei Frames fehlen, wird den meisten gar nicht auffallen.
Die Frage ist, was man mit dieser Information nun anfängt. Man bräuchte eigentlich einen VfW-Codec, der auch richtig framegenau arbeitet. Als Workaround könnte man die Länge des herausgeschnittenen Bereichs um zwei Frames verlängern. Dann hätte man an beiden Stellen genau das ausgewählte Frame, wenn die Cutlist mit richtigen Timecodes erstellt wurde. Hat die Cutlist selbst einen 2-Frame-Delay, müsste man sie zusätzlich noch um zwei Frames nach vorne verschieben. Aber welche Variante sollte man dann hochladen? Mit den richtigen Zeiten werden alle, die VirtualDub verwenden, zwei unerwünschte Frames drin haben. Lädt man die Workaround-Zeiten hoch, muss man sie bei einem späteren Bearbeiten zurückkorrigieren, damit der Beginn der Schnitte nicht jedes Mal um zwei weitere Frames nach hinten verschoben wird.