[Kurzanleitung] Installation von Avidemux unter Buster 64

  • (Zurück zum Inhaltsverzeichnis)

    Die Anleitung findet man auch unter: http://www.deb-multimedia.org/, allerdings in Englisch.

    Wer nicht weiß wofür er Avidemux brauchen kann sollte die Finger von dieser Installation lassen.

    Es handelt sich um eine Videobearbeitung


    In der normalen Repository von Buster64 findet man Avidemux nicht, aber bei deb-multimedia.

    Dazu muss man die Repository erweitern:


    Als erstes braucht man den keyring von deb-multimedia:

    wget http://www.deb-multimedia.org/pool/main/d/deb-multimedia-keyring/deb-multimedia-keyring_2016.8.1_all.deb

    Dann installiert man sich dieses Archiv: sudo dpkg -i deb-multimedia-keyring_2016.8.1_all.deb

    Danach trägt man in /etc/apt/sources.list zusätzlich folgende Zeile ein:

    deb http://www.deb-multimedia.org buster main non-free

    Dann ein sudo apt update, kein, ich wiederhole: !!! kein !!! upgrade

    und dann ein sudo apt install avidemux.

    Danach sollte man den Eintrag in der /etc/apt/sources.list wieder auskommentieren,

    siehe RE: [Kurzanleitung] Installation von Avidemux unter Buster 64 (Sorry hyle )

    Ein sudo apt update nicht vergessen, danach ist alles wieder auf den alten Stand.


    Installiert wird avidemux-qt, hiermit kann man die Videos über die Zeit schneiden (00:41:17.020)

    bei der GTK-Version kann man Bildgenau schneiden (was erheblich präziser ist).


    MfG


    Jürgen


    Edit: Link auf meine Projektseite eingefügt.

    • Official Post

    Hallo Jürgen!


    Habe ich damit auch eine Chance, das unter einem "normalen" 32Bit Raspberry Pi OS zu installieren?


    Du musst das jetzt nicht testen, wenn Du nicht sicher bist, aber vielleicht kennst Du ja die Antwort, bevor ich es versuche. ;)


    Btw. Bildgenau kann zu Tondelays oder anderen Aussetzern führen, Keyframegenaues schneiden ist deshalb imho besser.

  • Habe ich damit auch eine Chance, das unter einem "normalen" 32Bit Raspberry Pi OS zu installieren?

    Ich habe das gerade auch unter armhf gefunden:

    http://www.deb-multimedia.org/…stable/main/binary-armhf/


    Mit der zusätzlichen Quelle wollte das Upgrade insgesamt 65 Pakete austauschen, was ich aber noch nicht gemacht habe.

    Im Moment läuft ein 2-Pass Testlauf, das Argon-Gehäuse schaltet mittlerweile den Lüfter ein, bei 56°C.


    Alle 4 CPUs krebsen bei ca. 100% Last herum und der Load (1 min.) steht bei ca. 10.5.

    Aber das System bleibt bedienbar, wie man sieht.


    Wenn man das Fenster von Avidemux in der Größe ändert, sieht man (aber nur im Bild), an welcher Stelle sich der Prozess befindet.


    MfG


    Jürgen

    • Official Post

    Danke! Meine momentane Situation lässt nur einen Test mit einem RPi 3B (ohne +) zu, da ich gerade heute meinen bisherigen (Test)-Rpi4 als produktiven Server gradiert habe. Der Weg dahin war die Hölle, aber das nur am Rande. Ich werde mir dann also einen neuen RPi4 besorgen und wenn es 64 Bit werden sollte, wovon ich jetzt mal ausgehe, dann macht der 8GB RAM auch Sinn.


    Das Endziel ist es für mich, den Win10 PC bestmöglich zu ersetzen. Das Einzige was mich bisher daran hinderte, war die Videobearbeitung mit Avidemux. Wenn das mit einem RPi möglich ist, dann gibt es für mich keinen (wirtschaftlichen) Grund, einen PC zu starten.

    • Official Post

    Ich habe das gerade mal am RPi 3B / Raspberry Pi OS (jungfräulich) durchgespielt. Erst funktionierte alles und ich konnte Avidemux starten und ein Video bearbeiten, ABER einen Neustart hat das System nicht überlebt.


    Jetzt will X nicht mehr starten.


    Kann auch sein, dass ich irgendetwas verkonfiguriert habe. Deshalb fange ich nochmals von vorne an. Vielleicht lässt sich der Fehler reproduzieren.

    • Official Post

    Vielleicht lässt sich der Fehler reproduzieren.

    Ja, lässt er sich. Das Problem tritt nach dem der Eintrag in die sources.list, bzw. nach dem darauffolgenden update und upgrade auf. Ein reboot startet dann nicht mehr in den Desktop.


    Einen erneuter Versuch wäre auf das upgrade zu Verzichten und nur die Paketlisten aktualisieren + danach gleich avidemux zu installieren. Was das dann allerdings noch mitinstalliert und wie das ausgeht weiß ich noch nicht. Danach müsste der Eintrag in die sources.list aber auch gleich wieder entfernt werden, sonst bekommt man den Fehler beim nächsten upgrade.

    Vielleicht teste ich das heute auch noch, mal sehen.

  • Danach müsste der Eintrag in die sources.list aber auch gleich wieder entfernt werden

    Habe ich jetzt mal gemacht und boote gleich neu.


    MfG


    Jürgen

  • Bin wieder da, ist ohne Probleme wieder hochgefahren.

    Aus irgendeiner Vorahnung hatte ich kein Upgrade gemacht.

    Warscheinlich weil ich es unbedingt sofort ausprobieren wollte,

    und keinen Bock auf eine lange Upgrade-Orgie hatte.


    MfG


    Jürgen


    Edit: Ich habe die Kurzanleitung angepasst.

  • Danke, geht in Ubuntu20.04 und endlich kann man dvb-t2 Aufnahmen schneiden seitdem projectX keine h265? sachen schneiden kann. Nun kann ca 10 GB freier Platz geschaffen werden für Filme die nie angeschaut werden :)


    *edit* hab kein upgrade gemacht und gleich die Zeile in source.list gelöscht:geek:

  • Beim mir ist alles auf "copy" gestellt (automatisch ohne etwas zu verändern in der Oberfläche) Ton und Video wird praktisch nicht umgewandelt nur kopiert und geschnitten. Ob avidemux Hardwarebeschleunigung nutzt kann ich nicht sagen. Aber seit neuestem kann vlc in Raspberry OS auf jedenfall Dvb-t2 aufnahmen abspielen und das VLC-Fenstern kann skaliert werden ohne zu ruckeln. Sie haben es jetzt wohl fertig gemacht, dass da die Hardwarbeschleunigung funktioniert :) :) Aber nur in Raspberry OS (noch nicht Ubuntu20.04). Was eben nicht geht ist der Videotext in VLC von dem geschnittenen dvb-t2 *.ts file.

    Wobei geschnitten in Ubuntu20.04 und abgspielt mit VLC in Raspberry OS, weil da die Hardwarbeschleunigung geht.

  • Reicht dafür ein RPi 3B, oder muss es ein RPi 4B sein?

    Für den 3B ist hyle zuständig, ich saß gerade vor einem 4B-8G.

    Aber ich denke mir mal das das größere RAM, der höhere Takt, 64Bit und eine SSD an einem USB3-Port

    einen gewissen Einfluß auf die Verarbeitungsgeschwindigkeit haben.


    Ich denke mir mal, das auch ein 3B ausreicht, dauert warscheinlich nur etwas länger,

    hier dauerte die Konvertierung eines 42 Minuten Films (720*576, 16:9) knapp 2 min (Mpeg-PS Muxer).



    Probiere es einfach mal aus.


    MfG


    Jürgen

    • Official Post

    Nun kann ca 10 GB freier Platz geschaffen werden

    Das ist doch gerade mal ein Film in HD. :shy:


    Reicht dafür ein RPi 3B, oder muss es ein RPi 4B sein?

    Beim muxen ist die Auslastung eines Kerns bei 100% sagt htop, aber das größere Problem ist der fehlende RAM. Der RPi 3B swapt und ist entsprechend langsam.


    Mpeg-PS Muxer

    Ich verwende ausschließlich Mpeg TS (ff) > https://de.wikipedia.org/wiki/MPEG-Transportstrom, weil ich den Eindruck habe, dass damit die Videos "fluffiger" vom DLNA-Server zum TV transportiert und ruckelfrei abgespielt werden.



    //Edit: Vergessen...

    kein

    Solltest Du vielleicht rot, groß und mit :!::!::!: schreiben. :cool:

  • Mir reicht hd und hätten sie nicht auf DVB-T2 umgeschaltet mit h265/x265 codec hätte ich auch keine RPI4 zu gelegt. Als der RPI4B raußkam hab ich den mit 1 GB Ram gekauft, da das Feature h265 super fand. Leider hat es nur in Liebrelec in Vollbild funktioniert. Hab seit über einem Jahr eine SSD angeschlossen über USB3 und die Swap-Partition ist 4GB groß und auch einigermaßen schnell :-). Der RPI4 ist mittlerweile mein Hauptrechner, weil er das Laptop um längen schlägt. Und jetzt funktioniert die GPU Hardwarebeschleunigung auch noch.... perfekt :)

  • Es kommt wohl drauf an, wie viel Ressourcen das jeweilige Videobearbeitungsprogramm benötigt. Bisher habe ich zum seltenen schneiden (kopieren) von 1280x720 ffmpeg in der Shell benutzt. Zum ermitteln der benötigen Zeiten Omxplayer. Das schafft ein RPi 3B ohne Probleme. Nur die CPU und I/O begrenzt da vermutlich die Geschwindigkeit. Hier liegt die CPU Benutzung unter 10% (ffmpeg bei 3-4%), bei Bearbeitung von HD mp4 auf dem Fritz.NAS (Festplatte).

    Quote

    Beim muxen ist die Auslastung eines Kerns bei 100% sagt htop, aber das größere Problem ist der fehlende RAM. Der RPi 3B swapt und ist entsprechend langsam.

    Danke hyle! Damit kann ich was anfangen.

  • Ich verwende ausschließlich Mpeg TS (ff)

    Macht Sinn, ich hatte vor ein paar Jahren damit experimentiert

    und auf den ersten und zweiten Blick keinen Unterschied gesehen.


    Zudem ich die Filme nur auf meinem Desktoprechner gesehen habe.


    Danke und MfG


    Jürgen

    • Official Post

    Danke

    Ich habe zu danken! :bravo2:


    Das Thema Installation von Avidemux schiebe ich nun schon eine ganze Weile vor mir her, weil ich bei einer Suche danach mal feststellte, dass sich dieses Programm (im Nachhinein vermeintlich) nicht über die Paketquellen installieren lässt. Das es dann doch relativ leicht funktioniert ist für mich eine riesige Erleichterung und damit der Weg frei für mein Endziel.

    Hast Du diese Anleitung eigentlich schon länger in der Schublade oder haben wir das dem Doctor und der anschließenden Konversation zu verdanken? :lol:

  • Auch dem Doctor aber eher einer gewissen PN die ich auf diesen Beitrag erhalten hatte,

    aber ich war schon länger an Avidemux dran.


    Das war mit einer der ersten Sachen, die ich bei Buster64 gesucht hatte, ohne Erfolg.


    Dann hatte ich mal vor ein paar Wochen versucht, Avidemux aus den Sourcen zusammenzubauen,

    was aber sehr aufwändig ist. Und nicht geklappt hat.

    Dann kamen die USB-Adapter und das Booten von SSD, das war dann erstmal wichtiger.


    Vorgestern kam mir die Idee, Avidemux in Zusammenhang mit arm64 bei DDG zu suchen, ein Beispiel hatte ich schon

    auf meinen RPi4Bs, den Firefox von Ubuntu 18.0.4, der funktioniert ja auch unter Buster64.


    Und wurde fündig, der Rest ist Geschichte und steht im ersten Artikel dieses Threads.

    Auch danke an hyle, den ersten Beta-Tester, der damit erstmal auf die Nase gefallen ist.


    MfG


    Jürgen