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

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

  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+

    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.

  9. #9

    Registriert seit
    Jan 2009
    Beiträge
    1.728

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

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

    1. Es muss allgemein erstmal funktionieren
    2. Nicht nur funktionieren, sondern auch wirklich framegenau sein
    3. 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.

  10. #10
    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

Seite 1 von 41 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
  •