Seite 1 von 13 12311 ... LetzteLetzte
Ergebnis 1 bis 10 von 401

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

Hybrid-Darstellung

Vorheriger Beitrag Vorheriger Beitrag   Nächster Beitrag Nächster Beitrag
  1. #1
    Member
    Registriert seit
    Aug 2016
    Beiträge
    32

    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

  2. #2

    Registriert seit
    Jan 2009
    Beiträge
    1.728

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

    Zitat Zitat von EinApfelBaum Beitrag anzeigen
    Ich freue mich über jedes Feedback =)
    und natürlich auch über jede Unterstützung =)
    Finde ich prima
    Das ist viel Arbeit .... bin gespannt, wie es wird

  3. #3
    Member
    Registriert seit
    Aug 2016
    Beiträge
    32

    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

  4. #4
    Member
    Registriert seit
    May 2007
    Beiträge
    31

    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 Beitrag anzeigen
    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

  5. #5

    Registriert seit
    Jan 2009
    Beiträge
    1.728

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

    Zitat Zitat von EinApfelBaum Beitrag anzeigen
    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 Beitrag anzeigen
    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 Beitrag anzeigen
    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

  6. #6
    Member
    Registriert seit
    Aug 2016
    Beiträge
    32

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

    Moin,

    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:
    1. mp4_IN.mp4 --> mp4_IN.mkv
    2. avi_IN.avi --> avi_IN.mkv
    3. HQ_IN.avi --> HQ_IN.mkv
    4. 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.

  7. #7

    Registriert seit
    Jan 2009
    Beiträge
    1.728

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

    Zitat Zitat von EinApfelBaum Beitrag anzeigen
    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 Beitrag anzeigen
    An der GUI für das manuelle Schneiden arbeite ich gerade.
    Viel Spass

    Zitat Zitat von EinApfelBaum Beitrag anzeigen
    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 Beitrag anzeigen
    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

  8. #8
    Member
    Registriert seit
    Aug 2016
    Beiträge
    32

    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

  9. #9
    Member
    Registriert seit
    Sep 2012
    Beiträge
    20

    Exclamation DEB für Ubuntu 20.04

    Hallo, Danke für die schnelle Antwort und die Bereitstellung.

    Im Softwarecenter geht das DEB nicht : Installation schlug fehl: nicht unterstützt.
    per apt und dpkg fehlen die Abhängigkeiten (x264, ffsmlib2-4 und weitere glaube ich).
    Beim Schneiden stoppt das Programm bei Muxe Video stehen, die Datei ist in Cut zwar da, aber wird nicht umbenannt)

    Fehlerbericht meint dies:

    otrverwaltung3p crashed with TypeError in rename_by_schema(): argument of type 'builtin_function_or method' is not iterable

    Bei der Übergabe des Umbenennungsschemas schein was schief zu gehen, getroffene Einstellungen sind nach einem Neustart weg, sobald ich etwas tippen will kommt der Fehlerbericht von oben.

    Bei Drücken auf Decodieren und Schneiden (jedoch keine Cutlist vorhanden und nicht manuell geschnitten) kommt folgendes:

    otrverwaltung3p crashed with ValueError in cut(): list.remove(x): x not in list
    Geändert von pitpossum79 (29.05.2020 um 15:39 Uhr)

  10. #10
    Member
    Registriert seit
    Dec 2009
    Ort
    Germany
    Beiträge
    161
    Probiere bitte die neue Paketversion. Den Link habe ich aktualisiert (s.o.).
    Ich habe das Paket (auch das vorherige) per Doppelklick installiert -> Installation funktioniert.
    Es fehlten im ersten Paket in der Tat die Abhängigkeiten x264 und python3-psutil.

    Poste bitte im Fehlerfall nach Bedarf Screenshots und/oder Terminal Ausgaben. Ich benötige mehr Informationen.

    Edit: Ist gdebi-gtk bei Dir installiert? Das Programm öffnet sich bei mir, wenn ich auf eine deb-Datei doppelklicke.
    Geändert von loretotr (29.05.2020 um 15:21 Uhr)

Seite 1 von 13 12311 ... LetzteLetzte

Ähnliche Themen

  1. Warum fügt VDub beim Abspielen D-Frames hinzu?
    Von mchawk im Forum Virtualdub
    Antworten: 0
    Letzter Beitrag: 14.08.2015, 21:25
  2. Schneiden von HQ Aufnahmen unter Linux (OTRverwaltung)
    Von CDrewing im Forum HQ-& HDTV-Videos: Schnitt & Brennen
    Antworten: 4
    Letzter Beitrag: 19.12.2014, 17:20
  3. Werbe******/Layer - Blocker ... eine Unsitte von OTR-Usern
    Von gulliver im Forum Download via Mirror
    Antworten: 41
    Letzter Beitrag: 07.04.2007, 01:23
  4. Antworten: 8
    Letzter Beitrag: 06.02.2007, 20:43

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •