OTRVerwaltung3Plus - eine Portierung von OTRVerwaltung++ hinzu Python3 und Gtk3+
Moin OTR-Gemeinde,
ich bin gerade dabei OTRVerwaltung++ zu portieren, damit uns OTRVerwaltung++ auch zukünftig unter Linux erhalten bleibt.
Denn Entschluss habe ich gefasst, als ich das Update auf Linux Mint 18 getätigt habe.
Nach dem Update ging in Sachen OTRVerwaltung++ erst mal nicht mehr viel.
Zuerst werde ich den Code auf python3 und Gtk3+ portieren.
Dann werden Schritt für Schritt die Funktionalitäten angepasst.
Das Dekodieren mit dem internen Dekoder konnte ich schon erfolgreichen testen.
Interessant wird es beim Schneiden der unterschiedlichen Formate.
Das ganze ist zu finden unter
https://github.com/EinApfelBaum/otr-verwaltung
(Ich habe das Repository von monarc99 geforkt und arbeite im Fork an der Portierung.)
Hinweis:
Dies ist noch keine fertige Release Version.
Zur Zeit befindet sich OTRVerwaltung3Plus in der Entwicklungsphase.
Ich versuche den Thread hier möglichst aktuell zu halten.
Ich freue mich über jedes Feedback =)
und natürlich auch über jede Unterstützung =)
Beste Grüße,
EinApfelBaum
AW: OTRVerwaltung3Plus - eine Portierung von OTRVerwaltung++ hinzu Python3 und Gtk3+
Zitat:
Zitat von
EinApfelBaum
Ich freue mich über jedes Feedback =)
und natürlich auch über jede Unterstützung =)
Finde ich prima :D
Das ist viel Arbeit .... bin gespannt, wie es wird :)
AW: OTRVerwaltung3Plus - eine Portierung von OTRVerwaltung++ hinzu Python3 und Gtk3+
Vielen Dank =)
Das Decodieren klappt schon mal soweit.
Vor allem das Schneiden wird einiges an Arbeit kosten.
Ich würde auch gerne von wine weg kommen und da avidemux nicht mehr in den Repositorys ist, werde ich auch dafür eine Alternative brauchen.
Gestern habe ich das erste Mal mit Mencode etwas herumgespielt.
Habe ich das richtig verstanden, dass ich .avi Dateien mit Cutlist via ffmpeg oder mencoder schneiden kann, egal ob HQ, HD oder normal ?
Nur für das manuelle Schneiden müsste ich dann ein externes Programm mit GUI heranziehen.
Grüße,
EinApfelBaum
AW: OTRVerwaltung3Plus - eine Portierung von OTRVerwaltung++ hinzu Python3 und Gtk3+
Das hört sich schonmal vielversprechend an. Danke für die Mühe!
OTR-Verwaltung++ benutze ich nur um schneiden zu lassen, somit kann ich zum aktuelle Stand noch nicht viel sagen.
Zitat:
Zitat von
EinApfelBaum
Ich würde auch gerne von wine weg kommen und da avidemux nicht mehr in den Repositorys ist, werde ich auch dafür eine Alternative brauchen.
Gestern habe ich das erste Mal mit Mencode etwas herumgespielt.
Habe ich das richtig verstanden, dass ich .avi Dateien mit Cutlist via ffmpeg oder mencoder schneiden kann, egal ob HQ, HD oder normal?
Nur für das manuelle Schneiden müsste ich dann ein externes Programm mit GUI heranziehen.
Ich benutze nur SmartMKVmerge zum schneiden aller AVIs. Da wird weder wine noch avidemux für gebraucht, nur ffmsindex, mkvmerge und das gepatchte x264 (intern-x264) ist nötig. Ob für das Schneiden von MP4 wine benötigt wird kann ich nicht sagen.
Gruß
Raven
AW: OTRVerwaltung3Plus - eine Portierung von OTRVerwaltung++ hinzu Python3 und Gtk3+
Zitat:
Zitat von
EinApfelBaum
Vielen Dank =)
Vor allem das Schneiden wird einiges an Arbeit kosten.
Ich würde auch gerne von wine weg kommen und da avidemux nicht mehr in den Repositorys ist, werde ich auch dafür eine Alternative brauchen.
wine wird für Virtualdub und für Smartmkvmerge gebraucht. Bei Smartmkvmerge aber nur, wenn man die fertig geschnittene MKV danach automatisch nach MP4 konvertieren will.
Da wird eac3to benötigt, weil sonst die eingemuxxten AC3 Streams nicht syncron waren.
Zitat:
Zitat von
EinApfelBaum
Gestern habe ich das erste Mal mit Mencode etwas herumgespielt.
Habe ich das richtig verstanden, dass ich [FONT=courier new].avi [FONT=arial]Dateien mit Cutlist via ffmpeg oder mencoder schneiden kann, egal ob HQ, HD oder normal ?
Du meinst Mencoder? Hab ich schon länger nicht mehr probiert, aber ich glaube nicht, dass das Smart Rendering beherrscht.
Du willst ja nicht nur auf Keyframes schneiden, sondern die Werbung framegenau raus schneiden. Du wirst also auch einige Frames neu kodieren müssen.
Zitat:
Zitat von
EinApfelBaum
Nur für das manuelle Schneiden müsste ich dann ein externes Programm mit GUI heranziehen.
Fürs Cutlist erzeugen brauchst du halt ne GUI ;)
AW: OTRVerwaltung3Plus - eine Portierung von OTRVerwaltung++ hinzu Python3 und Gtk3+
Moin,
Zitat:
Du meinst Mencoder? Hab ich schon länger nicht mehr probiert, aber ich glaube nicht, dass das Smart Rendering beherrscht.
Du willst ja nicht nur auf Keyframes schneiden, sondern die Werbung framegenau raus schneiden. Du wirst also auch einige Frames neu kodieren müssen.
Soweit ich das richtig gelesen habe, kann avidemux doch auch kein smart rendering, oder ?
Aktuell denke ich darüber nach, die neuere Version von avidemux (Version 2.6.14) zu benutzen.
Vor dem Schneiden wird dann der avi Container in ein mkv Container umgewandelt.
Gerade eben getestet:
Testdateien:
- mp4_IN.mp4 --> mp4_IN.mkv
- avi_IN.avi --> avi_IN.mkv
- HQ_IN.avi --> HQ_IN.mkv
- HD_IN.avi --> HD_IN.mkv
Alle Formate wurden in OTRverwaltung in mkv Container umgewandelt.
In mp4_IN.mkv, HQ_IN.mkv, sowie HD_IN.mkv konnte ich zwischen Keyframes schneiden, ohne Artefakte bei den Schnittstellen.
Da wären wahrscheinlich noch mehrere Tests nötig, um das 100% zu bestätigen.
Im ersten Test mit avi_IN.mkv waren an der Schnittstelle kleine Artefakte zu erkennen.
Da müsste man sich etwas überlegen.
Bei avidemux wäre es allerdings so, dass das Repository hinzugefügt werden muss, damit avidemux 2.6 über die Paketverwaltung installiert werden kann.
An der GUI für das manuelle Schneiden arbeite ich gerade.
Ich sehe gerade, dass beim SmartMKVMerge smart rendering implementiert ist ?
Hmm vielleicht sollte ich mich erst mal auf eine Schnittmethode konzentrieren.
AW: OTRVerwaltung3Plus - eine Portierung von OTRVerwaltung++ hinzu Python3 und Gtk3+
Zitat:
Zitat von
EinApfelBaum
Soweit ich das richtig gelesen habe, kann avidemux doch auch kein smart rendering, oder ?
Aktuell denke ich darüber nach, die neuere Version von avidemux (Version 2.6.14) zu benutzen.
In mp4_IN.mkv, HQ_IN.mkv, sowie HD_IN.mkv konnte ich zwischen Keyframes schneiden, ohne Artefakte bei den Schnittstellen.
Da wären wahrscheinlich noch mehrere Tests nötig, um das 100% zu bestätigen.
Im ersten Test mit avi_IN.mkv waren an der Schnittstelle kleine Artefakte zu erkennen.
Da müsste man sich etwas überlegen.
Bei avidemux wäre es allerdings so, dass das Repository hinzugefügt werden muss, damit avidemux 2.6 über die Paketverwaltung installiert werden kann.
Avidemux 2.6 kann meines Wissens kein Smart Rendering.
-> http://avidemux.org/smif/index.php/topic,17195.0.html
Avidemux 2.5 konnte Smart Copy, allerdings nur für Divx Dateien. Deshalb will OTRV alle Divx Dateien mit avidemux2 (also 2.5) schneiden.
Zitat:
Zitat von
EinApfelBaum
An der GUI für das manuelle Schneiden arbeite ich gerade.
Viel Spass :)
Zitat:
Zitat von
EinApfelBaum
Ich sehe gerade, dass beim SmartMKVMerge smart rendering implementiert ist ?
Ja, aber SMM ist praktisch nur ein Script und kein vollwertiges Schneideprogramm. Das funktioniert ganz gut, weil ich es auf die OTR Dateien akribisch eingestellt habe und weil alle Konsolen Tools, die es benötigt, OTRV unter Tools beiliegen. (als 32bit static Programme)
Die Methode ist allerdings nicht die schnellste und störanfällig. Wenn z.B. OTR die Kodierung ändern würde, müsste man SMM daran komplett anpassen. z.B. ein neues x264 binary kompilieren usw.
Zitat:
Zitat von
EinApfelBaum
Hmm vielleicht sollte ich mich erst mal auf eine Schnittmethode konzentrieren.
Ja, schau dich doch um, ob es inzwischen neues gibt.
Wurde hier noch was gemacht?
http://www.otrforum.com/showthread.p...os-unter-Linux
http://www.otrforum.com/showthread.p...Videoschneiden
AW: OTRVerwaltung3Plus - eine Portierung von OTRVerwaltung++ hinzu Python3 und Gtk3+
Zitat:
Zitat von
monarc99
Ah super, danke für die Links.:)
Ich werde so vorgehen, dass ich zunächst die GUI zum Laufen bekomme.
Alle bisherigen Schnittmethoden werde ich erst mal auskommentieren und nicht überarbeiten.
Es wird zunächst nur eine Schnittmethode geben.
Nach und nach kann dies dann erweitert werden.
AW: OTRVerwaltung3Plus - eine Portierung von OTRVerwaltung++ hinzu Python3 und Gtk3+
Zitat:
Zitat von
EinApfelBaum
Es wird zunächst nur eine Schnittmethode geben.
Nach und nach kann dies dann erweitert werden.
Das Problem ist halt. Egal welche Methode du anbietest, sie muss gut funktionieren. weil eventuell sehr viele Leute sie verwenden. Und ihre geschnittenen Filme auch aufheben und sie an vielen verschiedenen Geräten abspielen wollen.
Das heißt:
- Es muss allgemein erstmal funktionieren
- Nicht nur funktionieren, sondern auch wirklich framegenau sein
- die Schnittpunkte dürfen die Streamstruktur nicht zerstören
zu 1)
muss man nix sagen
zu 2)
der Schnitt muss halt auch dort passieren, wo man ihn in der GUI setzt. Und nicht erst am nächsten Keyframe oder 2-3 Frames daneben.
z.B. kannst du es mit dieser Datei testen -> https://dl.dropboxusercontent.com/u/..._DE.mpg.HQ.avi
Da sind pro Bild die Framenummern einkodiert. Und es gibt auch schon ein paar Probe-Cutlisten auf cutlist.at für die Datei. Wenn du also Frame 100-250 ausschneidest, sollte in der geschnittenen Datei das auch rauskommen.
zu 3)
das ist bei weitem das Schwierigste
Wenn du ne Datei schneidest und Smart Rendering verwendet wird, wird an diesem Schnittpunkt alter und neuer Stream aneinander gepappt. Und die beiden Streams sind nie 100% identisch vom Aufbau. Es kann also zu Problemen kommen (Bildmatsch, Decoderabsturz, manche Hardware Decoder hängen sich komplett auf und müssen vom Netz getrennt werden, usw...), wenn der Decoder diese Stelle dekodieren muss. (gilt hauptsächlich für H264, weil der Aufbau bei divx noch zu simpel war)
Jetzt gibts 2 Dinge:
einerseits kann man den Encoder, der fürs Smart Rendering verwendet wird, möglichst identisch einstellen, wie auch OTR ihre Streams kodiert.
z.B. bei SmartMKVMerge ist das beiliegende x264 binary auf den git commit identisch zu den Encodern, die OTR verwendet. Zum anderen werden die x264 Einstellungen, die OTR verwendet, komplett verwendet.
D.h. wenn man ne heutige OTR HQ/HD Datei mit SMM schneidet, kommen saubere Schnittpunkte raus. Ändert sich die OTR Kodierung oder du probierst es mit einer anderen Datei aus anderer Quelle, wird am Schnittpunkt mit SMM nur Bildfehler entstehen.
andererseits musst du testen, wie problemlos die Schnittpunkte bei deiner Schnittmethode sind, weil die Decoder sehr unterschiedlich robust sind.
z.B. ein Software Decoder (also CPU) in einem Player (vlc, mpv, mplayer usw..) den stört überhaupt nix. Da kannst du nen LKW im Stream parken und die spielen das noch ab.
Dagegen sind HW Decoder (in TVs, in Mediaplayer, oder Kodi mit Raspberry/Intel Nuc - die per Hardwarebeschleunigung spielen) extrem anfällig.
Das heißt, wenn du einen Schnittpunkt am PC einfach mit deinem Standard Videoplayer überprüfst und alles perfekt aussieht, heißt das noch lange nicht, dass der Schnittpunkt nicht jeden x-beliebigen HW Decoder zum Absturz bringen kann.
Du brauchst also ne Methode, um die Schnittpunkte zu testen.
Ich hab z.B. früher die Datei per mp4box nach MP4 konvertiert und dann unter Windows per Quicktime Player mir die Schnittpunkte angesehen. Sowohl mp4box als auch Quicktime (also alles was mit Apple zu tun hat) sind extrem pingelig und zeigen sofort Bildfehler, wenn irgendwas im Stream nicht stimmt. In letzter Zeit habe ich die Schnittpunkte auf meinem kleinen Intel Nuc (auf dem Libeelec/Kodi läuft) getestet, weil der VAAPI (HW-Decoder) noch eher Fehler im Stream zeigte, also Quicktime.
AW: OTRVerwaltung3Plus - eine Portierung von OTRVerwaltung++ hinzu Python3 und Gtk3+
Moin,
ich hebe den Thread mal aus der Versenkung.
Leider komme ich nicht so voran, wie ich es mir vorgestellt habe.
Die Größte Hürde ist bei mir das gstreamer/Cutinterface, bzw das Schneiden von Dateien.
Aktuell lassen sich die meisten Aktionen durchführen.
Ich nutze das Dekodieren und avi in mkv umwandeln fast täglich.
Bei einer frischen Linux Mint 18.1 Installation musste ich python3-libtorrent und mediainfo-gui.
Grüße,
EinApfelBaum