[rpihddevice] mplayer Plugin Patch für omxplayer

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:

#!/bin/bash
export IFS="
"
 
omxplayer --key-config /etc/vdr/plugins/omxplayer/key.conf $1
killall -9 omxplayer.bin


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:

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

Nutze:

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

Wie kann ich das beheben ?

MfG
bobmeier

Hallo,

brauch ich noch ein Patch, für aktuellen VDR ?

Im Makefile ist WITHOUT_MP3=1 aktiviert, so dass nur das Mplayer-Plugin erstellt werden soll.

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:

void cMPlayerPlayer::SetMPlayerVolume(bool force)
{
........     
  	mpPrevVolume=mpVolume;     
 	// } Diese Klammer ist nach der Anwendung des Patches zuviel im Code        
   }
........
}

Gruß Sig

Hallo,

gibt es zu diesem Patch irgendwo neuere Informationen oder ein Update?

Gruß Sig

Video spielt astrein, jedoch habe ich kein Audio. Wenn ich die mplayer.sh ohne den VDR starte, funktioniert auch der Ton. Jemand dazu eine Idee?

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.

Zitat von Dr. Seltsam

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.

Zitat von Dr. Seltsam

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.

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?

Hat jemand den Effekt Video aber kein Audio? Beim omxplayer OHNE vdr ist auch Ton dabei.

Zitat von reufer

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

Alles anzeigen

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).

Zitat von te36

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

Zitat von reufer

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

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.