[rpihddevice] mplayer Plugin Patch für omxplayer

  • Hi, wie hier angekündigt ein erster Entwurf für einen Patch für das mplayer Plugin.


    Damit arbeitet das mplayer Plugin dann mit dem omxplayer.


    Es kann dann alles was der omxplayer abspielt auch über den VDR gestartet werden (inkl. VDR OSD während der Wiedergabe).


    Im Moment funktioniert folgendes:
    - springen 30 Sekunden zurück Taste :1
    - springen 30 Sekunden vor Taste :3
    - springen 10 Minuten zurück Taste :grün
    - springen 10 Minuten vor Taste :gelb


    Was fehlt noch.
    - Seek-Funktion.
    - richtige Implementierung der Lautstärkesteuerung (aktuell etwas rudimentär)
    - Fortschrittsanzeige im OSD des VDRs (da wird dann wohl auch ein Patch für den omxplayer fällig)


    hier noch eine passende mplayer.sh

    Shell-Script
    1. #!/bin/bash
    2. omxplayer --key-config /etc/vdr/plugins/omxplayer/key.conf $1
    3. killall -9 omxplayer.bin
    4. exit


    und die benötigte keymapdatei (Pfad siehe mplayer.sh)

    Code
    1. DECREASE_VOLUME:x
    2. INCREASE_VOLUME:y
    3. SEEK_BACK_SMALL:3
    4. SEEK_FORWARD_SMALL:4
    5. SEEK_BACK_LARGE:5
    6. SEEK_FORWARD_LARGE:6
    7. EXIT:q
    8. PAUSE:p


    Verbesserungsvorschläge sind willkommen.


    PS. lohnt sich ein Fork des mplayer Plugins?

  • Hi,


    das ist doch schon mal ein guter Anfang. Als Ergänzung würde ich in die mplayer.sh so definieren, damit auch Leerzeichen im Dateinamen mit übernommen werden:


    Shell-Script
    1. #!/bin/bash
    2. export IFS="
    3. "
    4.  
    5. omxplayer --key-config /etc/vdr/plugins/omxplayer/key.conf $1
    6. killall -9 omxplayer.bin
    7. exit


    Das mit dem Fork ist wahrscheinlich gar nicht so eine schlechte Idee. Ist wahrscheinlich einfacher, als den patch immer wieder anzupassen. Ich denke, dass der omxplayer ja hauptsächlich im Raspi vorkommt, so dass ggf. raspi-relevante Änderungen in dem Plugin vorgenommen werden können.

  • Hallo,


    beim kompilieren des mp3_0.10.2 Plugin mit mplayer-omxplayer-patch.diff bekomme ich folgende Fehlermeldung:


    Code
    1. player-mplayer.c: In member function 'virtual void cMPlayerPlayer::Action()':
    2. player-mplayer.c:447:20: warning: variable 'slavePatch' set but not used [-Wunused-but-set-variable]
    3. player-mplayer.c: At global scope:
    4. player-mplayer.c:588:11: error: expected constructor, destructor, or type conversion before ';' token
    5. player-mplayer.c:589:1: error: expected declaration before '}' token
    6. make[1]: *** [player-mplayer.o] Fehler 1



    Nutze:

    • vdr-2.0.5
    • 2014-01-07-wheezy-raspbian

    Wie kann ich das beheben ?



    MfG
    bobmeier

  • Zitat

    beim kompilieren des mp3_0.10.2 Plugin mit mplayer-omxplayer-patch.diff bekomme ich folgende Fehlermeldung:

    Der Eintrag ist zwar schon einige Monate alt, aber diese Fehlermeldung hatte ich heute immer noch.


    Nach dem Patch ist in dieser Funktion eine Klammer zuviel:

    Code
    1. void cMPlayerPlayer::SetMPlayerVolume(bool force)
    2. {
    3. ........
    4. mpPrevVolume=mpVolume;
    5. // } Diese Klammer ist nach der Anwendung des Patches zuviel im Code
    6. }
    7. ........
    8. }


    Gruß Sig

  • Habe den patch im raspian VDR mir rpihddevice 0.0.10 am laufen, Audio/Video Ausgang via HDMI. Habe noch nicht geschaut wie gut die Fernbedienungsbefehle funktioniert, weil im Moment stoert mich vor allem, dass der omxplayer alle Arten von Problemen hat, Dateien abzuspielen, die er nicht hat, wenn ich den VDR stoppe und nur den omxplayer standalone starte.


    All die folgenden Formate spielen prima ab, wenn man nur den omxplayer nimmt, aber wenn man den omxplayer unter dem plugin laufn lasst passiert folgendes:


    - mpeg4, 576i50 oder 720p50, keine Subtitel, spielen prima ab.


    - h264, 480p60 oder 720p60, keine Subtitle, spielen meistens korrekt


    - h264, 480p60 oder 720p60 mit externen (SRT) oder internen (.mkv) Subtitles, gibt dann folgende tollen Absturz:


    omxplayer.bin --key-config /var/lib/vdr/plugins/mplayer/key.conf
    <file>


    Output mode 16: 1920x1080@60 N:10
    ntsc_freq:1
    Video codec omx-h264 width 720 height 480 profile 100 fps 29.970030
    Audio codec mp3 channels 2 samplerate 48000 bitspersample 16
    Subtitle count: 1, state: on, index: 1, delay: 0
    V:PortSettingsChanged: 720x480@29.97 interlace:0 deinterlace:0 par:0.89
    layer:0
    omxplayer.bin: SubtitleRenderer.cpp:87: void BoxRenderer::render(): Assertion
    `!vgGetError()' failed.


    - h264, 720p24/1080p24 ohne subtitle mit bloss 2 kanaelen spielen wohl auch


    - h264, 720p*/1080p* mit subtitles oder mit > 2 kanaelen audio geben:


    Output mode 32: 1920x1080@24 :20
    ntsc_freq:1
    Video codec omx-mpeg4 width 1280 height 720 profile 0 fps 23.976025
    Audio codec ac3 channels 6 samplerate 48000 bitspersample 16
    Subtitle count: 0, state: off, index: 1, delay: 0
    V:PortSettingsChanged: 1280x720@23.98 interlace:0 deinterlace:0 par:1.00 layer:0
    COMXAudio::Decode timeout
    COMXAudio::Decode timeout
    ...
    Und das ist dann kein Bild kein Ton, bloss laufende Fehlermeldung und kein Absturz.


    Habe normalerweise gpu_mem 128 am laufen, aber gpu_mem 256 macht keinen Unterschied.


    Der omxplayer hat also sicherlich einen Schuss weg, aber nachdem die Probleme nur dann auftauchen, wenn man den unter dem VDR startet, hat das ja sicherlich was damit zu tun, dass der VDR/rpihddevice da noch irgendwelche Ressourcen auf der RPI GPU treibersoftware belegt. Am besten waere es also, wenn man dem mplayer modul beibringen koennte, dass es da alle offenen Resourcen schliesst, bevor es den omxplayer startet. Weiss leider nicht genau, was man da genau machen kann. Glaube ja auch dass das mplayer Modul da evtl. OSD noch verwenden will ? Eigentlich sollte das ja gehen, unter XBMC macht ja der XBMC ja auch noch GUI-OSD solange der omxplayer läuft *seufz*. Mal versuchen aktuellen omxplayer selbst zu compilieren...

  • wenn ich das richtig überblicke, fügt der Patch nur Funktionen für den slave-Modus hinzu. Aber m.E. braucht man den gar nicht bzw. es macht keinen Sinn: Wenn das OSD des vdr während der Wiedergabe ohnehin nicht da ist, sollte man die Fernsteuerung des vdr beim Starten des Players deaktivieren und erst bei Rückkehr zu vdr wieder aktivieren. Die komplette Fernsteuerung sollte sich doch über die lircrc lösen lassen, oder?
    Für mpv habe ich so eine Lösung kürzlich beschrieben.

    VDR 1: Silverstone LC20, Cougar A300/R, MSI C847MS-E33, passive Asus GT520, KNC One DVB-C, Cine CT V6, WD10EACS; Atric-IR-Einschalter. SW: yavdr 0.5 per SSD
    VDR 2: im Aufbau: ACT-620 mit Coba-NT, Asrock B75 Pro3-M, Celeron G540, Sundtek MediaTV Digital Home (DVB-C/T), passive Asus GT610. SW: Ubuntu 13.04 minimal (ohne grafische Oberfläche) per SSD

  • wenn ich das richtig überblicke, fügt der Patch nur Funktionen für den slave-Modus hinzu. Aber m.E. braucht man den gar nicht bzw. es macht keinen Sinn: Wenn das OSD des vdr während der Wiedergabe ohnehin nicht da ist, sollte man die Fernsteuerung des vdr beim Starten des Players deaktivieren und erst bei Rückkehr zu vdr wieder aktivieren. Die komplette Fernsteuerung sollte sich doch über die lircrc lösen lassen, oder?
    Für mpv habe ich so eine Lösung kürzlich beschrieben.


    Bin mit wegen des OSD nicht ganz sicher. Habe den originalen mplayer mit FF am Laufen, da gibts ein OSD beim seeken, weiss aber nicht, ob das vom plugin oder mplayer kommt. Glube vom plugin.


    Aber ja, wenn man die Probleme mit omxplayer vielleicht erstmal nur dadurch behebt, dass man da vom plugin aus kein OSD hat waere das fuer mich auch ok. Avber wie gesagt, der XBMC nimmt ja auch omxplayer als slave zum videoabspielen und legt sein eigenes OSD drueber. Muesste also eigentlich machbar sein.


    Wie soll denn Die Loesung an die Du denkst genau funktionieen ? Kenne leider mpv nicht. Und neben lirc-befehlen umsetzen macht das Plugin ja auch die Auswahl der Quelle ueber Menu...

  • soweit ich weiss, sind nur die FF-Karten und die PVR350 in der Lage, im external playmode das OSD separat vom Videostream anzuzeigen. Das liegt daran, dass sie separate devices für OSD und Video haben.
    Bei VDPAU ist das nicht der Fall, und beim Raspberry vermutlich auch nicht.


    Wenn man den omxplayer über lirc-Befehle steuern kann, dann sollte man diese in der lircrc definieren. Dann braucht man das mplayer-Plugin nur noch, um die abzuspielende Datei im OSD auszuwählen. Das mplayer-Plugin übergibt dann diese Datei als Parameter an das Startscript. Das Script übernimmt es dann, den vdr von der Fernbedienung abzukoppeln und den ausgewählten Film mit dem omxplayer zu starten. Während dieser läuft, steuert man mit der FB dann auch nur diesen Player und läuft nicht Gefahr, im Hintergrund ungewollt irgendein vdr-Kommando auszuführen. Der andere Vorteil der Steuerung per lircrc ist, dass man damit mehr Tasten belegen kann, als das mplayer-Plugin dafür vorsieht. Es bleiben nämlich einige Tasten immer für vdr selbst reserviert. Ich weiss, dass einige der vdr-Tasten, die das mplayer-Plugin für seine Steuerung vorsieht, deshalb in der Praxis gar nicht funktionieren können. Dazu gehört glaube ich z.B. die Audio-Taste - bin mir aber nicht ganz sicher.


    Kurzum: wenn der omxplayer per lircrc bedienbar ist, braucht man kein gepatchtes Plugin, sondern kommt anders besser zum Ziel.


    Meine mpv-Lösung hatte ich kürzlich im yavdr-Unterportal vorgestellt.

    VDR 1: Silverstone LC20, Cougar A300/R, MSI C847MS-E33, passive Asus GT520, KNC One DVB-C, Cine CT V6, WD10EACS; Atric-IR-Einschalter. SW: yavdr 0.5 per SSD
    VDR 2: im Aufbau: ACT-620 mit Coba-NT, Asrock B75 Pro3-M, Celeron G540, Sundtek MediaTV Digital Home (DVB-C/T), passive Asus GT610. SW: Ubuntu 13.04 minimal (ohne grafische Oberfläche) per SSD

  • soweit ich weiss, sind nur die FF-Karten und die PVR350 in der Lage, im external playmode das OSD separat vom Videostream anzuzeigen. Das liegt daran, dass sie separate devices für OSD und Video haben.
    Bei VDPAU ist das nicht der Fall, und beim Raspberry vermutlich auch nicht.

    OSD und Video sind beim Raspberry Pi auch getrennt: OSD geht über OpenVG und Video über OpenMAX.


    Allerdings gebe ich die Ressourcen erst beim Deinitialisieren des Plugins komplett frei, da ich nicht damit rechne, dass zwischendurch ein omxplayer läuft. Ehrlich gesagt war ich erstaunt, dass sowas überhaupt ansatzweise schon funktioniert hat…


    Da von meiner Seite kein Interesse an dieser Funktion besteht, werde ich hier keine Zeit investieren. Aber wenn jemand konkrete Vorschläge oder Patches hat, schau ich mir die gerne an.


    Gruss
    Thomas

  • ich habe keinen Pi und kenne das Plugin auch nicht aus eigener Benutzung, aber nach meinem Verständnis müsste es so gehen:
    in SetPlayMode muss der case pmExtern_THIS_SHOULD_BE_AVOIDED definiert werden. Da müsste dann das OpenMAX device geschlossen werden.
    Zugleich müsste zu Beginn von SetPlayMode jeweils geprüft werden, ob der angeforderte Playmode ungleich pmExtern_THIS_SHOULD_BE_AVOIDED ist, und wenn dies zutrifft, ob das OpenMAX device geöffnet ist. Ist dies nicht der Fall, müsste es zunächst geöffnet werden.


    Wenn ich mir den Patch zu Anfang dieses threads jetzt anschaue bin ich auch erstaunt. Eigentlich hätte ich erwartet, dass das ohne Implementierung des case pmExtern_THIS_SHOULD_BE_AVOIDED überhaupt nicht laufen kann.

    VDR 1: Silverstone LC20, Cougar A300/R, MSI C847MS-E33, passive Asus GT520, KNC One DVB-C, Cine CT V6, WD10EACS; Atric-IR-Einschalter. SW: yavdr 0.5 per SSD
    VDR 2: im Aufbau: ACT-620 mit Coba-NT, Asrock B75 Pro3-M, Celeron G540, Sundtek MediaTV Digital Home (DVB-C/T), passive Asus GT610. SW: Ubuntu 13.04 minimal (ohne grafische Oberfläche) per SSD

  • und da gibt es keine Konflikte zwischen dem vdr-Bild des Plugins und dem omxplayer? Der Wechsel zwischen omxplayer und TV-Bild und zurück klappt störungsfrei und stabil?

    VDR 1: Silverstone LC20, Cougar A300/R, MSI C847MS-E33, passive Asus GT520, KNC One DVB-C, Cine CT V6, WD10EACS; Atric-IR-Einschalter. SW: yavdr 0.5 per SSD
    VDR 2: im Aufbau: ACT-620 mit Coba-NT, Asrock B75 Pro3-M, Celeron G540, Sundtek MediaTV Digital Home (DVB-C/T), passive Asus GT610. SW: Ubuntu 13.04 minimal (ohne grafische Oberfläche) per SSD


  • http://www.vdr-portal.de/index.php?page=Attachment&attachmentID=37165&h=10a7cf7906ad9b0df0eddc884661f66420a206ef


    Hatte befuerchtet dass ich die OSD resourcen auch noch freigeben muss, aber mit bisher bloss ein wenig testen scheint der omxplayer auch happy zu sein, wenn das OSD vom rpihddevice nur ein redet bekommt bevor er gestartet wird. Koennte also gut sein, dass man da auch parallel noch OSD vom plugin aus machen koennte waehrend der omxplayer laeuft.


    Bei mir ist omxplayer immer abgestuerzt bei Dateien mit 6-Kanal Audio und vor allem auch bei Dateien mit Subtitels, Effektivitaet des patches sollte sich damit gut vergleichen lassen.


    Der patch veraendert auch nix am Verhalten des rpihddevices solange ein plugin nicht PlayMode = pmExtern_THIS_SHOULD_BE_AVOIDED benutzt, sollte also ungefaehrlich sein, ins rpihddevice zu patchen.


    Bitte mit "patch -l" anwenden, irgendwie sind da Veraenderungen am Whitespace reingekommen (-l ignoriert whitespace).

  • http://www.vdr-portal.de/index.php?page=…661f66420a206ef


    Hatte befuerchtet dass ich die OSD resourcen auch noch freigeben muss, aber mit bisher bloss ein wenig testen scheint der omxplayer auch happy zu sein, wenn das OSD vom rpihddevice nur ein redet bekommt bevor er gestartet wird. Koennte also gut sein, dass man da auch parallel noch OSD vom plugin aus machen koennte waehrend der omxplayer laeuft.

    Vom Prinzip her ist der Patch ok, ich kann die Funktionalität auch gerne implementieren, aber das will ich erst selber ausgiebig testen. Die Umsetzung werde ich aber ein wenig anders machen.


    Gruss
    Thomas

  • Vom Prinzip her ist der Patch ok, ich kann die Funktionalität auch gerne implementieren, aber das will ich erst selber ausgiebig testen. Die Umsetzung werde ich aber ein wenig anders machen.


    Gruss
    Thomas


    Ich halt nix haben Praxis C++ programmieren. Du schreiben besser selbst gerne :P


    Ansonsten: Ich weiss nicht was Du mit "ausgiebig testen" meinst: Gibt es da echte Dokumentation dazu was da mehrere konkurrierende Anwendungen gleichzeitig auf den Graphik-APIs des VC4 machen dürfen oder nicht ? Eg: Da "einfach" im patch mal das Reset auf der OSD API zu machen war ja bloss mal ausprobiert, scheint aber prima zu funktionieren: Der omxplayer spielt jetzt z.b. ein 1280x720p video ab, waehrend man gleichzeitig weiterhin das VDR OSD oben drauf sehen kann - und der VDR/rpihddevice melden/nutzen 1080p. Drei layers: video, omxplayer-OSD (eg: subtitles) und VDR-OSD. Richtig nett.


    Du hattest ja in einem vorherigen Posting wenig Begeisterung fuer die Funktionalitaet gezeigt, aber vom Konzept her finde ich das schon huebsch modular, gerade weil/wenn man das VDR-OSD oben drauf laufen hat. Wenn man da in das plugin a weng Arbeit investiert koennte man das schoen zum Launcher/Controller von anderen sinnvollen standalone/fullscreen Anwendungen machen. "Fim" z.b. zum Bilder anschauen.