OTRVerwaltung3Plus - eine Portierung von OTRVerwaltung++ hinzu Python3 und Gtk3+

[gilbert]

so, das Verschieben in Müll und Archiv funktioniert bestens, war mein Fehler! Jedoch beim Umbennen, vorallem bei den Umlauten klappt es noch nicht so wie gewünscht (siehe Command Line 2) oder liegt es da wieder an einem Bedienungsfehler meiner seits

Mit Ubuntu 20.04 funktioniert die aktuelle Version der OTRVerwaltung3Plus bestens, also decodieren und schneiden (siehe Log im zitiertem Thread)

Letzendlich hat loretotr den absoluten Überblick - ich bin nur User zweiter Klasse

[PeGu]

@loretotr
Vielen Dank!
In den von dir verlinkten Thread gehört das ganze auch eigentlich.
(Danke fürs Verständnis; und ich hoffe, die Linux-Seite wird bald auch offiziell wieder agiler...)

[Guenni]

@guenni: In otrverwaltung3p/cutlists.py Zeile 123: self.log.debug(f"{response = }") bitte auskommentieren. Ist es das? Welche python-version läuft bei DIr?

@gilbert: Auch hier gefragt: Welche python-version läuft bei DIr?

Python(3) Version ist 3.7.3.

Ich habe das letzte Komma im Aufruf response = requests.post(... entfernt und mußte alle self.log.debug(f"... auskommentieren. Dann ist es endlich gestartet.

Ich war vor allem am Schneiden mit ffmpeg interessiert, weil es da mit x264 in rpiotrtool bestimmte (seltene) Problem gab. Dieser Fehler war jetzt mit ffmpeg-Schnitt nicht zu sehen (am Anfang der Datei), aber das Ende stimmte dafür überhaupt nicht (viel zu lang).

[loretotr]

<Link entfernt>, da neuerer Link verfügbar (s. unten)

Fixt die Verwendung von zu aktueller f-string Syntax (cutlists.py)

Da ich im Wiki schrieb das otrv ab Python 3.6 läuft, soll es auch so sein. Ich bitte um Entschuldigung. Ich habe dieses Paket unter Ubuntu 18.04 getestet (Installation und das Schneiden einer HQ Datei) und es funktioniert so weit.

Dieses Paket benötigt man nur, wenn man Python 3.6 oder 3.7 nutzt.

@gilbert: Ich hoffe, Du hast Dein ZorinOS noch nicht eingestampft. otrv sollte jetzt darauf laufen.

(...) ich bin nur User zweiter Klasse

Das ist definitiv nicht zutreffend. Bedenke bitte, das ich der Entwicker der otrv bin und mich daher gut mit den Interna des Programmes auskenne (oder auskennen sollte ). Daher supporte ich hier.

Edit:
Neue Version:
otr-verwaltung3p-dev-1.0.0b8.post1-1.deb
Behebt Fehler im Smartrendering des neuen HD-Formates (Audio-Versatz und andere Fehler beim Schneiden).

Edit 2020-07-23 20:25
Bekannte Fehler in otr-verwaltung3p-dev-1.0.0b8.post1-1.deb:
Der Versuch VirtualDub (a.k.a. vdub) zu verwenden generiert einen Fehler ähnlich: "Wine nicht gefunden"
Dies ist für die AUR-Pakete behoben, Debian/Ubuntu müssen warten. vdub sollte nicht mehr benötigt werden

[gilbert]

Das ist definitiv nicht zutreffend. Bedenke bitte, das ich der Entwicker der otrv bin und mich daher gut mit den Interna des Programmes auskenne (oder auskennen sollte ). Daher supporte ich hier.

Vielen Dank für Deine Geduld

Gerade schießt mir noch so eine andere Idee durch den Kopf:

Die Settings werden doch regelmäßig in einer Config-Datei gesichert und abgelegt.

1. Wie findest Du die Idee das Programm mit einer Export-/Importfunktion dieser Settings zu versehen, spart einem bei Neuinstallation die Eintragungen, Programmpfade, Speicherorte händisch zu suchen und einzutragen.

2. Zum Zusatzpaket vdub/wine wäre zugleich eine Importfunktion zu den jeweiligen Programmpfaden in dieser Config-Datei bequem und für Rookies eine massive Erleichterung

[Guenni]

@loretotr/gcurse:
Ich habe bei mir mal verschiedene Versionen deiner otrv3p auf dem Raspberry Pi installiert. Es funktioniert nur in Teilen (dekdodieren und Cutinterface funktionieren nicht), aber mir kam es auf das Schneiden an und das funktioniert. Ähnlich wie du suche ich immer noch nach Optimierungen beim neuen HD-Format. Ich habe gesehen, daß du mit verschiedenen Offsets experimentiert hast, finde das Ergebnis aber sehr unbefriedingend, weil das Scheiden damit nicht mehr exakt an den in der Cutlist vorgeschriebenen Stellen passiert. Das kann ich an den Ergebnissen deutlich sehen, wenn ich sie mit rpiotrtool-Schnitten vergleiche.

Wie du vielleicht weißt, verwende ich in rpiotrtool inzwischen nur noch x264 für das Rekodieren der kleinen Schnipsel. Das funktioniert auch mit dem neuen HD-Format sehr gut, aber bei ca. 5% der Dateien kommt es zu kleinen Fehlern: An der Schnittstelle tauchen plötzlich ältere Frames auf, die dort nichts zu suchen haben. Da es sich um eine Art "Dreckeffekt" handelt, der nur sehr sporadisch auftritt, ist die Ursache bzw. eine Abhilfe aber nur schwer zu finden. Gestern ist mir aber nun ein Durchbruch gelungen. Dazu muß ich etwas ausholen.

Auf dem Raspberry Pi gibt es (standardmäßig) nur drei hardwarebeschleunigte Videoplayer: VLC, omxplayer(GUI) und Kodi. VLC hat mit den Original-OTR-AVIs (HQ und HD) beim Abspielen Probleme (es "ruckelt", weil viele Frames fehlen). Konvertiere ich die Datei aber nach MKV, werden die Videos perfekt abgespielt. In omxplayerGUI lassen sich die OTR-Dateien (HQ, HD) zwar perfekt abspielen, aber wenn man vorwärts oder rückwärtsspringt, gibt es kleine Ruckler. Das sieht man besonders schön bei stark reduzierter Abspielgeschwindigkeit, die ich beim manuellen Schneiden mit omxplayerGUI verwende: das Bild springt nach dem Springen ein paar mal vor und zurück, bevor es sich beruhigt. Auch dieser Effekt verschwindet, wenn ich eine MKV-Kopie der OTR-Datei benutze. Es liegt also am Containerformat (Audio- und Videostreams bleiben ja unverändert) und am jeweiligen Demuxer, ob diese Probleme auftreten oder nicht. (omxplayer verwendet übrigens ffmpeg als Demuxer.) Ich hatte deshalb schon von Anfang an in rpiotrtool die Option eingebaut, von den OTR-Dateien MKV-Kopien herzustellen. Diese werden dann z. B. bei der Schnittvorschau automatisch verwendet (wenn sie vorhanden sind). Das war auch als Hilfe für User gedacht, die sich die ungeschnittenen Videos mit VLC (ist nun der Standardplayer) anschauen möchten.

Nun hatte ich gestern die "Erleuchtung": vielleicht kommt ja auch der in x264 integrierte Demuxer (ffms) manchmal mit dem OTR-AVI-Format nicht klar? Dann habe ich in die Schnittroutine eingebaut, daß beim Vorhandensein einer MKV-Kopie diese als Quelle verwendet wird statt der AVI-Datei. Damit habe ich dann eine problematische Datei (die ich mir samt Cutlist extra aufgehoben hatte) geschnitten und siehe da: Ohne MKV-Kopie blitzt ein falscher Frame am Beginn des Schnitts auf, mit MKV-Kopie ist der Schnitt perfekt. Das ganze ist absolut reproduzierbar. Wie es sich bei FFMPEG verhält, kann ich nicht testen, weil ich es nicht mehr verwende (außer für das alte AVI-Format).

Um die Programmlogik nicht durcheinanderzubringen, setze ich den Wechsel auf das MKV-Format erst recht spät an: Unmittelbar vor der Kommentarzeile:
# video part 3 - encode small parts - smart rendering part (1/2)
wird "filename" auf die MKV-Kopie gesetzt (sofern vorhanden). Diese wird dann also nur noch für das Erstellen der neu kodierten Schnipsel und für das Herausschneiden der großen Blöcke genutzt.

Um den User nicht zu zwingen, alle Dateien nach MKV zu konvertieren, habe ich nun in rpiotrtool eingebaut, daß beim Erkennen des neuen HD-Formates automatisch eine solche MKV-Kopie erzeugt wird. Dann dauert das Schneiden zwar ein bißchen länger, aber wenn es dann fehlerfrei ist, spielt das wohl keine Rolle. Und die Schnitte werden exakt da gesetzt, wo es die Cutlist vorgibt und nicht durch irgendwelche Offsets manipuliert.

Das wollte ich dir mal als Anregung für die Otrverwaltung3p geben. Vielleicht kannst du es ja mal selber testen. Ich habe es selber in otrv3p auf dem RPi mal probiert mit der gleichen MKV-Datei und x264, aber irgendwas stimmt hier beim Schneiden nicht. Am Ende erscheint ein Teil, der gar nicht erscheinen dürfte und der Ton ist komplett asynchron. Vielleicht hängt das ja auch wieder mit der Python3-Version zusammen. In rpiotrtool wird die gleiche Datei perfekt geschnitten und der Ton ist auch synchron.

Nachtrag: Ich habe das jetzt mal in die Version 1.0.0.b4 aus dem gcurse repository reingepatcht und da funktioniert das Schneiden (mit x264) genau wie mit rpiotrtool: ohne MKV-Kopie mit dem Fehler beim ersten Schnitt und mit MKV-Kopie ohne den Fehler. Auch das Ende stimmt hier und der Ton ist synchron.

[gilbert]

ich habe mal otr-verwaltung3p-dev-1.0.0b8-2 ausprobiert, im Gegensatz von otr-verwaltung3p-dev-1.0.0b8.post1-1.deb läuft diese Version auf ZorinOS aka Ubuntu 18.04 nicht:

otrverwaltung3p 
Traceback (most recent call last):
  File "/usr/bin/otrverwaltung3p", line 114, in <module>
    from otrverwaltung3p.actions import actions
  File "/usr/lib/python3/dist-packages/otrverwaltung3p/actions/actions.py", line 17, in <module>
    from otrverwaltung3p.actions import decodeorcut
  File "/usr/lib/python3/dist-packages/otrverwaltung3p/actions/decodeorcut.py", line 30, in <module>
    from otrverwaltung3p.conclusions import FileConclusion
  File "/usr/lib/python3/dist-packages/otrverwaltung3p/conclusions.py", line 21, in <module>
    from otrverwaltung3p.cutlists import Cutlist
  File "<fstring>", line 1
    (response = )
              ^
SyntaxError: invalid syntax

[Guenni]

@MACMUPPET; Bein Zusammenführen hast du sämtliche deutschen Sonderzeichen (ä,ö,ü,ß) vermurkst.

[loretotr]

@gilbert:
otr-verwaltung3p-dev-1.0.0b8-2.deb ist das 2. Paket der otr-verwaltung3p Version 1.0.0b8. Und 1.0.0b8 ist älter als 1.0.0b8.post1. Die Zahl nach dem letztem Bindestrich bezieht sich auf das deb-Paket und gehört nicht zur Versionsnummer der otr-verwaltung3p. Siehe https://github.com/EinApfelBaum/otr-...ung3p/releases: Die neueste Version steht immer oben.

@guenni:
Die otrv schneidet nur noch mit ffmpeg, da x264, warum auch immer, bei mir nicht korrekt schneidet. Ffmpeg ist mir auch lieber, da das Archlinux x264 ohne den ffms-Demuxer ausgeliefert wird.
Falls Du noch mit otrv experimentieren möchtest, bitte immer die neueste Version benutzen. Am besten

git clone --branch development --single-branch --shallow-since=2020-02-14 https://github.com/EinApfelBaum/otr-verwaltung3p.git

Diese Methode erspart den Download von ca. 250 Mb überflüssiger git history. Das kannst Du dann jederzeit mit git pull aktualisieren.

[Guenni]

@loretotr:

OK, danke für den Tip.

Wenn du nur noch mit ffmpeg schneidest, hast du dann immer noch gelegentlich Probleme mit dem neuen HD-Format? Ich dachte, du hättest sowas erwähnt.