Empfehlung Videoplayer auf dem PI?

  • Hallo zusammen,

    ich werde mir demnächst einen Videoplayer auf meinem Raspberrypi installieren. Jedoch habe ich dies noch nie gemacht und hoffe nun auf eure Erfahrunen / Empfehlungen. Welchen OpenSource Viedeoplayer ist am einfachsten zu implementieren?

    Meine Linux-Distribution für den Bastelrechner wurden auch neue Funktionen hinzugefügt. Hat jemand hierzu Infos?

    Zusätzlich möchte ich gerne auch die Möglichkeit haben, auch "spezielle" Formate abspielen zu können. So ist mir wichtig, das die Software Videos mit den Codecs H.264, Mpeg-2 und Vc-1 beschleunigt wiedergeben kann.

  • Wenn ich das noch richtig im Kopf habe, hat der neue Raspian für Raspberry den VLC-Media Player von Haus aus. Der ist wohl unumstritten die Nummer 1. Der kann alle Formate abspielen- Naja fast. Manches geht aber mit einigen Tricks auch so. Zum Beispiel stellen Blue-Rays ein Problem dar, wegen den Lizenzen. Aber es soll auch gehen, wenn man diverse Codecs sich holt. Aber das ist mir zu viel Pfuscherei. Wenn du kein neues Raspian aufspielen willst, weil da Anwendungen laufen, die nur mit der Version gehen, hab dir ein Link dagelassen, der einiges erklärt. Weiß jetzt nicht, ob der da auch eine Variante für Raspian hat. Notfalls gibt es auch den beim Hersteller selbst. (Ist halt alles englisch, deswegen habe ich dir mal einen Deutschen geschickt)

  • Welchen OpenSource Viedeoplayer ist am einfachsten zu implementieren?

    Wer durch 'nen Blasrohr drauf guckt, wird möglicherweise auch nur den VLC sehen und den deshalb auch für die beste Wahl unter Linux halten. Nun ja, für mich ist der unter Debian nur fehlerbehafteter instabiler Programmschrott. Wie das bei anderen Distributionen ist, weiss ich leider nicht. Wie auch immer, ich würde auf jeden Fall einen Blick auf den smplayer werfen, der auf all unseren Systemen den VLC ersetzt hat. und seitdem ist der Störfall-Frust Vergangenheit, der hier bei VLC ständiger Begleiter war.

  • Zusätzlich möchte ich gerne auch die Möglichkeit haben, auch "spezielle" Formate abspielen zu können. So ist mir wichtig, das die Software Videos mit den Codecs H.264, Mpeg-2 und Vc-1 beschleunigt wiedergeben kann.

    Der schon installierte omxplayer kann H.264. MPEG2 benötigt ein Key (oder ähnlich) und VC-1 weiss ich nicht.

  • in dem aktuellen Raspbian Desktop ist der VLC-Player enthalten. Ich habe es hier mal kurz angetestet und war zunächst begeistert. Allerdings fehlen mir echte Langzeittests, um ein abschließendes Urteil abgeben zu können.

    Ansonsten ist das ebenfalls in Raspbian integrierte Kommandozeilenprogramm omxplayer interessant, von dem ich bestätigen kann, dass es wirklich stabil läuft. Dafür gibt es auch GUI-Wrapper wie den tboplayer oder meinen ... :stumm:

    • Offizieller Beitrag

    Nun ja, für mich ist der unter Debian nur fehlerbehafteter instabiler Programmschrott.

    Nicht nur da. Die Zeiten in denen VLC das Maß aller Dinge war sind seit Jahren vorbei. Auf dem Pi macht der OMXplayer am meisten sinn - hat Hardwareschleunigung und kennt alle Formate. Unter Windows ist mpc-hc mein ständiger Begleiter

  • Nicht nur da. Die Zeiten in denen VLC das Maß aller Dinge war sind seit Jahren vorbei. Auf dem Pi macht der OMXplayer am meisten sinn - hat Hardwareschleunigung und kennt alle Formate. Unter Windows ist mpc-hc mein ständiger Begleiter


    Bei dem neuem Raspbian bekommt das Linux-Betriebssystem einen verbesserten VLC-Player, der Hardwarebeschleunigung unterstützt.

    Jetzt ist natürlich die Frage in wie gut der OMXplayer gegenüber dem VLC-Player ist.

  • Das macht den Player aber nicht besser. Die Bildqualität bei gleichem Ausgangsmaterial ist in der Standardkonfiguration bei z.B. VLC vs. MPC-HC sichtbar schlechter.

    Okay werde mir diesen Player mal runter laden und testen.

    Danke für die guten Argumente. Hast mich überzeugt :)

  • Danke für die ganzen Antworten.

    Wenn ich das richtig entnehmen kann, hat der VLC auf dem Pi nicht so gute Karten, wie auf Windows.

    Beim Pi sollte man den Omx nehmen (wusste gar nicht, das da was schon drauf ist) oder aber auch smplayer.

    Aber wenn Omx schon drauf ist, dann muss ich ja extra nichts installieren. Werde wohl dann auch den zuerst mal ausprobieren. Vielleicht reicht mir das ja aus.

    Soll ja nur abspielen können.

    Noch eine kleine Frage vielleicht, kann der Omx die typischen Befehle? Möchte da ein kleines Programm erstellen, wo dann zufällig ein Musikstück abgespielt wird, das ist aber nur ein Nebenprojekt.

  • Noch eine kleine Frage vielleicht, kann der Omx die typischen Befehle? Möchte da ein kleines Programm erstellen, wo dann zufällig ein Musikstück abgespielt wird, das ist aber nur ein Nebenprojekt.

    Der omxplayer ist ein reines Konsolenprogramm, den man mit entsprechenden Kommandozeilenparametern konfiguriert. Während der Medienwiedergabe kann man ihn aus anderen Programmen heraus via D-Bus steuern (z.B. Play/Pause, Vor- und Rücklauf, ...) oder ganz ohne weiteres Programm über Tastensteuerung. Dies kann mitunter durchaus reichen, aber manchmal wünscht man sich eben ein Programm mit einer GUI: Deshalb mache ich jetzt doch noch einmal unverhohlen Werbung für meinen yamuplay, ein Python3-Script, das USB-Sticks mit Mediadateien beim Anstecken über udev automatisch erkennt, eine Playlist verwaltet und zum Abspielen den omxplayer verwendet, inkl D-Bus-Ansteuerung.

  • Sorry, ich muss hier auch mal offtopic fragen. Wenn ich es richtig verstanden habe, dann muss jedes Programm die D-Bus Funktionalität implementieren und es gibt keine Automagi, die es allen Programmen per Standard ermöglicht drauf zu zugreifen? Wenn ja, wie verbreitet ist D-Bus? In den Anleitungen bin ich jetzt eher selten über D-Bus gestolpert.

  • Servus kle und daxb,

    also D-Bus ("Desktop-Bus") scheint unter Linux etwas ganz Ähnliches zu sein wie Dynamic Data Exchange (DDE) unter Windows (was dort später durch OLE ersetzt wurde): Ein Verfahren zur Interprozesskommunikation (u.a. Datenaustausch, aber auch Steuerung) zwischen verschiedenen Programmen. Bei meinem yamuplay.py habe ich es nicht "zu Fuß" implementiert, sondern über die eingebundene Python-Bibliothek python-omxplayer-wrapper von Will Price auf github. Diese Bibliothek nutzt offenbar D-Bus, um den omxplayer zu steuern. Mit anderen Worten: Ich kenne mich damit nicht wirklich aus ;)

    Allerdings nutzt mindestens auch der Audacious-Mediaplayer noch D-Bus... Bei VLC weiß ich es im Augenblick nicht.

    Der oben verlinkte Wikipedia-Artikel beschreibt es eigentlich schön, dass dieses Protokoll geschaffen wurde, um unter Linux eine standardisierte, desktop-unabhängige "Interprozesskommunikation" (ich stehle mal das Wort) bereitzustellen.

    Auch weiß ich nicht, ob es Programme gibt, die über Bluetooth Kommandos empfangen, um damit über D-Bus eine andere Software zu steuern. Solche Sachen sind relativ spezifisch und es wird so etwas nicht "von der Stange" geben. Aber ich kann mir gut vorstellen, dass ein auf bestimmte definierte Komponenten zugeschnittenes Programm erstellt werden kann, das so etwas macht:

    Code
    _____________     ____________     ____________________
    | Bluetooth |<--->| Programm |<--->| externe Software |
    _____________     ____________     ____________________

    in meinen yamuplay müsste man (Achtung: Unwort!) "nur" eine BT-Schnittstelle einbauen, die dann den omxplayer (wie gehabt) über den python-omxplayer-wrapper per D-Bus steuert. Beide Komponenten wären theoretisch programmiertechnisch sauber zu trennen.

    Aber automagisch geht da gar nichts.

    In der Dokumentation von (halb-)fertigen Softwareprodukten wird D-Bus vermutlich eher selten erwähnt, da es den 0815-Anwender höchstens peripher interessieren dürfte. Die Software wird gemäß Anleitung installiert und die Interna sind ziemlich egal. Auch in meiner PDF-Anleitung zu yamuplay gehe ich darauf kaum ein.

  • Danke für die Erklärung schlizbäda! D-Bus wiki hatte ich schon gelesen. Hintergrund meiner Frage: Ich kenne nur die Interprozesskommunikation wie sie unter AmigaOS mittels (A)Rexx funktioniert, wo sie auch recht verbreitet ist. Das funktioniert recht einfach. Programm X hat einen Rexx Message Port mit diversen Befehlen, die man über diesen Port ansprechen kann. Damit kann man wie bei D-Bus teilweise Funktionalität erweitern. Voraussetzung ist aber das Programme das eben unterstützten.

    Bei den Amiga Programmen steht die Beschreibung des ARexx Ports immer in der Anleitung. Teilweise sogar mit diversen Beispiel Skripten. Wäre daher schön, wenn zumindest ein Link zur D-Bus Beschreibung in den Manpages zu finden wäre. Oder gibt es eine andere einfache Möglichkeit die Information zu erhalten?

  • Hintergrund meiner Frage: Ich kenne nur die Interprozesskommunikation wie sie unter AmigaOS mittels (A)Rexx funktioniert, wo sie auch recht verbreitet ist. Das funktioniert recht einfach.

    (A)Rexx sieht für mein Verständnis eher wie eine Script-Programmiersprache aus, die u.a. Kommandos für eine Interprozesskommunikation enthält und dabei die implementierten Routinen des Betriebssystems (AmigaOS) nutzt. Auf Linux übertragen ist D-Bus dagegen lediglich eine Bibliothek der implementierten Routinen des Betriebssystems und es gibt dafür Programmierschnittstellen bzw. besser bekannt auf neudeutsch als API. Der Scriptsprache auf dem Amiga entspricht auf dem RPi unter Linux eine Sprache wie Python oder auch C oder whatever. Hier muss man aber immer erst die API einbinden (import in Python, #include in C/C++).

    Da (A)Rexx beide Teile kombiniert, ist es (vermutlich) relativ einfach anzuwenden...

    Ich sah D-Bus Kommandos im github Projekt Bluetooth Audio for (headless) Raspbian systems von Bernhard Bablok.

    Es geht um Connect von Bluetooth-Geräten. (signal handler etc.)

    Hast Du dieses Programm mal getestet?

    Es leitet ja anscheinend die Audiodaten, die über ALSA kommen, auf eine Bluetooth-Audiosenke (BT-Lautsprecher, -Kopfhörer etc.) um. Wobei mir auf die Schnelle noch nicht klar ist, wofür hier genau D-Bus benötigt wird. Anscheinend wird D-Bus von der Komponente bluez bereitgestellt und in diesem Programm genutzt. Ich muss aber gestehen, den Code weder getestet, noch tiefer betrachtet zu haben...

    So, genug Klugscheiß, eigentlich kenne ich mich mit den Details von D-Bus nicht wirklich aus! :stumm:

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!