OTR-Verwaltung++ - durch Patches erweiterte OTR-Verwaltung - Betatest

[monarc99]

So wieder Zuhause ...

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.

Ja genau, das meine ich. Wenn er nur kopiert - also von Keyframe zu Keyframe - schneidet er korrekt und braucht dafür auch die richtigen Timecodes. Wenn er smartrendert, ist es auch genau, nur versetzt. Problematisch wird es, wenn er es mischt.
z.B. er soll von 200-249 smartrendern. Dann liefert er mir 200-247 (um 2 versetzt) und findet dann das Keyframe im Stream (er ist ja 2 Frames voraus) und verschluckt dann bei mir die Frames 248 und 249. Er liefert das Keyfram 250 und das nächste im Stream 254 (nach dts).
Er zählt richtig (50 Frames), er schaltet aber - meiner Meinung nach - wenn er das nächste Keyframe findet, den Smart Rendering Code ab. Und liefert dann 2 falsche Frames. So meine Beobachtung - ohne den Code zu kennen.

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.

Also in die Cutlists gehören die richtigen Timecodes. Alles andere ist Unsinn. Ich hab vor meiner Reise ein wenig damit gespielt, dass ich die Cutlist Angaben ein wenig korrigiere, bevor sie in die vcf für VD geschrieben werden.
z.B. Keyframes auslesen und wenn das Intervall an einem Keyframe startet, die richtigen Werte übertragen. Wenn er mit Smart Rendering anfängt, die Werte korrigieren, bevor sie ins vcf wandern.
Klappte ganz gut, nur bei den gemischten Parts (smart rendering+kopieren) muss ich noch kucken. Noch keine Zeit gehabt.

mfg,
monarc

[JanS]

Ja genau, das meine ich. Wenn er nur kopiert - also von Keyframe zu Keyframe - schneidet er korrekt und braucht dafür auch die richtigen Timecodes. Wenn er smartrendert, ist es auch genau, nur versetzt. Problematisch wird es, wenn er es mischt.
z.B. er soll von 200-249 smartrendern. Dann liefert er mir 200-247 (um 2 versetzt) und findet dann das Keyframe im Stream (er ist ja 2 Frames voraus) und verschluckt dann bei mir die Frames 248 und 249. Er liefert das Keyfram 250 und das nächste im Stream 254 (nach dts).
Er zählt richtig (50 Frames), er schaltet aber - meiner Meinung nach - wenn er das nächste Keyframe findet, den Smart Rendering Code ab. Und liefert dann 2 falsche Frames. So meine Beobachtung - ohne den Code zu kennen.

Also ich habe mal mit einer deiner Cutlists von Cutlist.at Big_Buck_Bunny...avi geschnitten. Da ist ja ein Cut ab Frame 200 und einer Länge von 50 Frames drin, d.h. es sollten die Frames 200 bis 249 sein. 250 ist das nächste Keyframe. Das intern-VDub von OTR-Verwaltung (also 1.10.2 und x264vfw) liefert dann Frames 198 bis 247 und nichts weiter. Er hört korrekt nach 50 Frames auf und nimmt das Keyframe 250 nicht mit dazu, nur dass der neukodierte Bereich um zwei Frames verschoben ist.

Am Ende der Werbung werden so natürlich zwei Frames mit hinzugenommen, die zur Werbung gehören, wenn die Werbung in obigem Beispiel bis 199 ginge. Darum auch die Frage, ob man jeden Abschnitt zwei Frames später beginnen lässt. Aber wenn VirtualDub bei dir andere Ergebnisse liefert, macht sowas auch keinen Sinn. Dann muss man halt immer zwei Frames Abstand zur Werbung halten.

[monarc99]

Also ich habe mal mit einer deiner Cutlists von Cutlist.at Big_Buck_Bunny...avi geschnitten. Da ist ja ein Cut ab Frame 200 und einer Länge von 50 Frames drin, d.h. es sollten die Frames 200 bis 249 sein. 250 ist das nächste Keyframe. Das intern-VDub von OTR-Verwaltung (also 1.10.2 und x264vfw) liefert dann Frames 198 bis 247 und nichts weiter. Er hört korrekt nach 50 Frames auf und nimmt das Keyframe 250 nicht mit dazu, nur dass der neukodierte Bereich um zwei Frames verschoben ist.

Am Ende der Werbung werden so natürlich zwei Frames mit hinzugenommen, die zur Werbung gehören, wenn die Werbung in obigem Beispiel bis 199 ginge. Darum auch die Frage, ob man jeden Abschnitt zwei Frames später beginnen lässt. Aber wenn VirtualDub bei dir andere Ergebnisse liefert, macht sowas auch keinen Sinn. Dann muss man halt immer zwei Frames Abstand zur Werbung halten.

Ich lasse ihn 2 Frame später beginnen, wenn er bei keinem Keyframe startet. Problem ist dann allerdings die 2 Frames vor einem nächsten Keyframe. Sobald er das nächste Keyframe einliest (was für ihn bedeutet, dass der Smart Rendering Part vorbei ist), wechselt VD in den Copy Modus und liest die nächsten 2 Frames ab dem Keyframe.

sprich bei obigen Beispiel dann: 200 - 247 250 254

Ich habs jetzt nochmal geändert, so dass er auch hinten 2 Frames weglässt, wenn er auf ein Keyframe trifft. Dafür füge ich dann 2 weitere Intervalle mit jeweils 1 Frame Dauer in die vcf ein.

VD produziert dann: 200 - 247 247 247
An die Frames 248 und 249 komme ich nicht ran, aber so hat man wenigstens keine Werbeblitzer (hoffentlich ^^)

Problem ist, dass ich die Keyframes brauche. Ich lese diese mit ffmsindex aus. Das gibt es zwar auch für Linux bzw. kann man es auch dort kompilieren, aber noch ist mir kein static Build gelungen, was man beifügen könnte.
Deshalb bin ich erstmal auf wine+ffmsindex.exe ausgewichen.

Generell wäre es auch für das Cutinterface nicht schlecht, diese zu wissen. Wir springen ja in 25 Frame Sprüngen durch das Video, weil min_key=25 ist. Ich habe aber gesehen, dass das ganz schlecht fürs Schneiden ist. Der x264 Encoder setzt ja freiwillig an Szenenwechsel Keyframes, solange er nicht durch min_key daran gehindert wird. Und das passiert leider sehr häufig. Sprich ich würde bei OTR früher oder später anfragen, ob man min_key auf 1 setzen kann, damit die Dateien schneidbarer werden.
Die Idee mit den 25 Frame Sprüngen ist dann natürlich Essig.

Hier mal meine aktuelle Version, mit den Änderungen für VD und avidemux3 drin.
https://github.com/monarc99/otr-verw...ive/monarc.zip

mfg
monarc

[Taxi]

Hier ist ein Bug:
Datei: Life_13.01.28_23-05_vox_55_TVOON_DE.mpg.HQ.avi.otrkey
Cutlist: 9787069
Geschnitten mit der neuen Methode gibt es einen Ruckler bei Sekunde 9, mit der alten nicht.

[monarc99]

Hier ist ein Bug:
Geschnitten mit der neuen Methode gibt es einen Ruckler bei Sekunde 9, mit der alten nicht.

Das ist der Smart Rendering Bug von VD ... den kann ich nicht ungeschehen machen, nur versuchen zu vertuschen.
Der tritt auch auf, wenn ein Wechsel zwischen Smart Rendering und reinem Kopieren stattfindet. Dann hat VD auf 2 Frames keinen Zugriff. In der alten Methode werden diese beiden Frames einfach übersprungen.
Wenn in OTR-V aber separat der AC3 Stream durch mkvmerge geschnitten wird, darf ich das nicht zulassen, weil das Video sonst mit der Anzahl der Schnitte immer asyncer wird.

Ich habs nochmal geändert: https://github.com/monarc99/otr-verw...ive/monarc.zip

1) die Vertuschung etwas unauffälliger gemacht ... trotzdem merkt man einen kleinen Ruckler, wenn verhindert wird, dass VD Frames verliert.
2) wenn kein AC3 Stream geschnitten wird, werden die problematischen Frames jetzt übersprungen: (also teilweise die alte Methode)

• bei einigen Situationen (z.B. oben die beiden Filme am Anfang) würde VD selbst diese Frames überspringen. OTR-V zementiert dieses Verhalten jetzt nur. Man merkt einen kleinen Sprung im Video, dass lässt sich aber nicht ändern. (alte Methode)
• bei anderen Situationen würde es dazu kommen, dass VD falsche Frames einbaut (die bekannten Werbeblitzer). Hier wird jetzt von OTR-V das Cutlist Segment gekürzt, um den Smart Rendering Bug einzudämmen.

Obige beiden Regeln gelten aber nur, wenn kein AC3 Stream geschnitten wird, zu dem das Video sync bleiben muss.
Auch muss man beachten, dass eine ungenaue Cutlist nicht auf einmal genau wird und OTR-V in den Cutlisten die richtigen Frameangaben/Timecodes erwartet. Was z.B. CA und Coldcut nach meinen sehr kurzen Tests probematisch ist, weil sie vermutlich den B-Frame Delay nicht miteinberechnen. Bei Cutana und SuperOTR sieht es scheinbar besser aus.

Probiert mal aus, wie es klappt. Vorallem wie die Schnitte sind, wenn die Cutlist von der einen oder anderen Software gemacht wurden.
Da muss man dann entweder die Autoren ansprechen oder wenn keiner mehr dran arbeitet, in OTR-V irgendwas einbauen.

mfg,
monarc

[JanS]

Hallo monarc,

ich habe jetzt das Cutinterface eingebaut (und noch einige Fehler korrigiert, die mir aufgefallen sind). Allerdings sind deine neuesten Änderungen noch nicht drin (Avidemux3 und deine Frame-Korrekturen sowie VirtualDub 1.10.3 fehlen). Ich bin mit dieser Version aber auch so zufrieden. Dann muss man halt zwei Frames Abstand halten, wenn man nicht an Keyframes schneidet.

Das Problem ist ja eigentlich kein Bug in VirtualDub, sondern eine Unstimmigkeit zwischen den VfW-Codecs und VirtualDub. Ich glaube nicht, dass in VirtualDub noch eine Extra-Behandlung für einzelne Codecs eingebaut wird. Man könnte eine zwei Frame-Korrektur in OTR-V einbauen und dieselbe Korrektur auch für den ac3-Cut verwenden. Ich bin aber eher am überlegen, ob man eine Cut-Variante mit GStreamer hinkriegen könnte. Deshalb werde ich mir über Lösungen mit VirtualDub nicht mehr den Kopf zerbrechen.

Zu dieser Version: Mein Workflow sieht jetzt folgendermaßen aus:
1. Ich schneide die gewünschten Dateien mit der Option 'Beste Cutlist'
2. Ergebnisse überprüfen. Falls ich mit etwas nicht zufrieden bin, muss ich nur dran denken, die Datei nicht in den Müll zu verschieben. Dann wird auch die Cutlist nicht gelöscht.
3. Die Dateien, mit denen ich nicht zufrieden war, auswählen und manuell cutten. Das Cutinterface lädt automatisch eine lokale Cutlist, falls eine da ist. Dort kann ich die Cuts auswählen und korrigieren.
4. Ergebnis wieder überprüfen und gegebenenfalls Cutlist hochladen.

Das Cutinterface lässt sich als Alternative zu Avidemux und VirtualDub auswählen. Ich war so frei, es als Standard zu definieren. Auch das ac3-Muxen lässt sich jetzt in den Einstellungen abstellen.

Zur Bedienung des Cutinterfaces:
Ich habe ein Button hinzugefügt, mit dem Cutlists (lokale und vom Server) laden kann. Zur Korrektur kann man rechts einen Cut auswählen. Dann werden die Marker A und B mit Anfang und Ende des Cuts belegt. Die Tasten Bild-hoch / -runter springen zu den Markern A/B. Pfeil-rechts / -links springt ein Frame nach rechts / links. Pfeil-hoch / -runter springt (in der Regel) zum nächsten / letzten Keyframe. 'Pos 1' / 'Ende' setzen die Marker A / B auf die neuen Positionen. Dabei ist zu beachten, dass die Frames beider Marker mit rausgeschnitten werden (im Gegensatz zum CC beispielsweise). Nicht vergessen: Die korrigierten Positionen mit 'Entf' übernehmen. Hat man keinen Cut ausgewählt, wird mit 'Entf' ein neuer Cut hinzugefügt. Die ausgeschnittenen Bereich sind unter dem Slider orange markiert. Der Bereich der Marker ist rot markiert. Zum Abschluss natürlich auf Schneiden clicken.

Mit der Checkbox oben rechts kann man in eine Art Vorschau-Modus kommen, in dem die Cuts schon mal anschauen kann (abgesehen von irgendwelchen Unstimmigkeiten mit dem VfW-Codec). In den Conclusions kann man nun für jede manuell geschnittene Datei einzeln wählen, ob man die Cutlist hochladen will, für den Fall, dass man mit einzelnen nicht zufrieden war.

Darüber hinaus habe ich noch einige kleine Fehler beseitigt. Ich habe jetzt keine Bugs mehr finden können.

Viele Grüße
Jan

PS: Da das Forum nicht so große Dateien erlaubt, fehlen in dem zip-File das intern-VDub und der Plugin und der media-Ordner. Um eine lauffähige Version zu erhalten, kann man es zum Beispiel über einen alten Ordner kopieren. Dann muss man aber daran denken in den Einstellungen das Cutinterface auszuwählen, wenn man es verwenden will.

Anhang 6954

[monarc99]

Hi JanS,

ich habe jetzt das Cutinterface eingebaut (und noch einige Fehler korrigiert, die mir aufgefallen sind). Allerdings sind deine neuesten Änderungen noch nicht drin (Avidemux3 und deine Frame-Korrekturen sowie VirtualDub 1.10.3 fehlen).

Ich habe mal dein Cutinterface mit in meine Version eingebaut. Meine Merge-Version ist noch ein wenig mit Vorsicht zu geniessen (Restalkohol und so ^^), aber sollte funktionieren.

https://github.com/monarc99/otr-verw...ive/monarc.zip
- mit benn/janS's Cutinterface
- auch Schnittlisten von Avidemux2.6 (unter Linux als Avidemux3 genannt) erstellen möglich (wer das möchte)
- Virtualdub 1.10.3 Update
- Frame-Korrekturen um Werbeblitzer bei VD einzudämmen

Abhängigkeiten:
für Cutinterface wird gstreamer, gnolin benötigt (und vielleicht noch was? janS?)
für Avidemux3: avidemux3 und mkvmerge. (Avidemux3 möchte kein H264 in AVIs, deshalb wandelt OTR-V die AVIs vorher automatisch mit mkvmerge in MKV um.)

Ich bin aber eher am überlegen, ob man eine Cut-Variante mit GStreamer hinkriegen könnte. Deshalb werde ich mir über Lösungen mit VirtualDub nicht mehr den Kopf zerbrechen.

Ja, an VD würde ich jetzt nicht mehr rumbasteln. Wie würde denn das im groben Aussehen mit Gstreamer? Würde das komplett (intern) mit Gstreamer gehen oder brauchst man da noch zusätzlich was.

Das Cutinterface lässt sich als Alternative zu Avidemux und VirtualDub auswählen. Ich war so frei, es als Standard zu definieren. Auch das ac3-Muxen lässt sich jetzt in den Einstellungen abstellen.

Ich habe es bei mir in der Auswahlliste im Preferenz Window auch noch nach oben gerückt, so dass ganz oben als erstes steht.
Mit weitem Abstand eignen sich jetzt das Cutinterface und Avidemux 2.6 (bei mir unter Linux als binary avidemux3_qt4) am besten, um die Cutlisten zu erstellen.
Schneiden weiterhin nur VD. Avidemux2.6 eigent sich noch nicht.

Zur Bedienung des Cutinterfaces:
Ich habe ein Button hinzugefügt, mit dem Cutlists (lokale und vom Server) laden kann. Zur Korrektur kann man rechts einen Cut auswählen. Dann werden die Marker A und B mit Anfang und Ende des Cuts belegt. Die Tasten Bild-hoch / -runter springen zu den Markern A/B. Pfeil-rechts / -links springt ein Frame nach rechts / links. Pfeil-hoch / -runter springt (in der Regel) zum nächsten / letzten Keyframe. 'Pos 1' / 'Ende' setzen die Marker A / B auf die neuen Positionen. Dabei ist zu beachten, dass die Frames beider Marker mit rausgeschnitten werden (im Gegensatz zum CC beispielsweise). Nicht vergessen: Die korrigierten Positionen mit 'Entf' übernehmen. Hat man keinen Cut ausgewählt, wird mit 'Entf' ein neuer Cut hinzugefügt. Die ausgeschnittenen Bereich sind unter dem Slider orange markiert. Der Bereich der Marker ist rot markiert. Zum Abschluss natürlich auf Schneiden clicken.

Kannst du denn noch irgendwo einen Help Button unterbringen. So dass ein Fenster aufspringt und ne Kurz-Anleitung ausspuckt. Ist nicht schwer zu bedienen, aber wer zum ersten Mal damit arbeitet, tut sich etwas schwer.

Dabei ist zu beachten, dass die Frames beider Marker mit rausgeschnitten werden (im Gegensatz zum CC beispielsweise).

Ja, das hat mich irritiert. Bei VD und Avidemux wird das Frame bei B dringelassen. Ist aber nicht schlimm, man sollte nur drauf aufmerksam gemacht werden.

Mit der Checkbox oben rechts kann man in eine Art Vorschau-Modus kommen, in dem die Cuts schon mal anschauen kann.
Darüber hinaus habe ich noch einige kleine Fehler beseitigt. Ich habe jetzt keine Bugs mehr finden können.

Ich habe es manchmal, dass die Pfeil-Hoch und -Runter Tasten nicht reagieren. Während die [KEY>>] Buttons immer gehen.
Auch wenn man den Vorschau-Modus aktiviert, funktioniert das Keyframe springen nicht mehr richtig. Beim Big_Buck_Bunny zeigt er mir dann Frames an, die keine Keyframes sind.

Aber ansonsten bin ich vom Cutinterface begeistert. Schön, dass man jetzt auch Cutlisten in OTR-Verwaltung nachkorrigieren kann.

mfg,
monarc

[JanS]

Abhängigkeiten:
für Cutinterface wird gstreamer, gnolin benötigt (und vielleicht noch was? janS?)

Das ist richtig, nichts weiter. Bei GStreamer am Besten alle Plugin-Sammlungen installieren. Die Dekoder befinden sich im FFMPEG-Paket, die Demuxer in der Good-Sammlung, die Parser in der Bad-Sammlung ...

Ja, an VD würde ich jetzt nicht mehr rumbasteln. Wie würde denn das im groben Aussehen mit Gstreamer? Würde das komplett (intern) mit Gstreamer gehen oder brauchst man da noch zusätzlich was.

Ich tüftel gerade an ein paar Elementen für GStreamer 1.0. Einen einzelnen Cut aus einer Datei rausschneiden mit SmartRendering kann ich schon. Für mehrere Cuts (auch aus verschiedenen Dateien) arbeite ich gerade an etwas, das aber noch einige Arbeit braucht (die Muxer mögen das nicht so). Es gibt zwar auch eine einfachere Lösung, aber ich bin mir da nicht so sicher, ob da nicht mal ein paar unerwünschte Frames reinrutschen können. Die GStreamer Elemente ändern sich ja auch ständig. Bei meinen eigenen Elementen, weiß ich wie so etwas kontrollieren kann. Man würde dann nur GStreamer 1.0 und Gtk 3 brauchen (also den zukünftigen Standard für Linux).

Kannst du denn noch irgendwo einen Help Button unterbringen. So dass ein Fenster aufspringt und ne Kurz-Anleitung ausspuckt. Ist nicht schwer zu bedienen, aber wer zum ersten Mal damit arbeitet, tut sich etwas schwer.

Ich werd versuchen, diese Woche noch mal Zeit dafür zu finden.

Ich habe es manchmal, dass die Pfeil-Hoch und -Runter Tasten nicht reagieren. Während die [KEY>>] Buttons immer gehen.
Auch wenn man den Vorschau-Modus aktiviert, funktioniert das Keyframe springen nicht mehr richtig. Beim Big_Buck_Bunny zeigt er mir dann Frames an, die keine Keyframes sind.

Im Vorschau-Modus könnte es daran liegen, dass die GNonLin-Pakete da was durcheinander bringen, vor allem an den Schnittgrenzen. Dass die Pfeil-Hoch und -Runter Tasten nicht reagieren, habe ich bei mir noch nicht erlebt. Wo ist der Fokus, wenn es mal nicht geht? Auf einem der Buttons, in der Liste, auf dem Slider?

Gruß
Jan

[monarc99]

Wohin hast du denn das Zip entpackt? So wie es momentan implementiert ist, muss die erweiterte Version komplett im Homeverzeichnis liegen - wegen dem wine Verzeichnis.

Ändere mal die Rechte auf deinen Benutzer um.

in der Konsole:

chown username:username -R otr-verwaltung/

mfg,
monarc

[drraven]

Ich tüftel gerade an ein paar Elementen für GStreamer 1.0. Einen einzelnen Cut aus einer Datei rausschneiden mit SmartRendering kann ich schon. Für mehrere Cuts (auch aus verschiedenen Dateien) arbeite ich gerade an etwas, das aber noch einige Arbeit braucht (die Muxer mögen das nicht so). Es gibt zwar auch eine einfachere Lösung, aber ich bin mir da nicht so sicher, ob da nicht mal ein paar unerwünschte Frames reinrutschen können. Die GStreamer Elemente ändern sich ja auch ständig. Bei meinen eigenen Elementen, weiß ich wie so etwas kontrollieren kann. Man würde dann nur GStreamer 1.0 und Gtk 3 brauchen (also den zukünftigen Standard für Linux).

Hallo JanS.

Kann man sich den aktuellen Stand schon mal ansehen? Habe viele Dateien die aus nur einem einzelnen Cut bestehen. Eine Möglichkeit Standard AVI und HQ AVI mit dem gleichen Programm unter Linux zu schneiden klingt sehr verlockend

Gruß
Raven