[Prototyp] RPI Ausgabeplugin

Mir fällt dazu nur folgendes ein:

strings libvdr-rpihddevice.so.2.0.0  | grep -i libav

Bei mir ergibt es folgendes:

libavcodec.so.53
libavformat.so.53
LIBAVCODEC_53

Hallo,

hat. jemand von euch eine Idee wie mann das rpihddevice unter openelec zum laufen kriegen koennte ?

gruss,

Franz

Zitat von francescosoft

hat. jemand von euch eine Idee wie mann das rpihddevice unter openelec zum laufen kriegen koennte ?

Auf MLD umsteigen:-)?
xbmc mit vdr schien mir überdimensioniert für den RPI, MLD ist doch deutlich schlanker. Ist mir klar, dass die Frage damit nicht beantwortet ist…
steiniplatte

Zitat von francescosoft

hat. jemand von euch eine Idee wie mann das rpihddevice unter openelec zum laufen kriegen koennte ?

Warum sollte man das denn wollen? OpenELEC ist nur dafür gedacht XBMC zu starten, aber das willst du ja gar nicht.

Gerald

Auf Openelec laeuft XBMC besser als auf raspbian oder andere distris.

Ich moechte das Plugin gerne zusammen mit XBMC nutzen, d.h. eine umschalt moeglichkeit zwischen XBMC und rpihddevice, aehnlich wie das in Yavdr ist.

Gruss,

Franz

Zitat von francescosoft

Auf Openelec laeuft XBMC besser als auf raspbian oder andere distris.

Ich moechte das Plugin gerne zusammen mit XBMC nutzen, d.h. eine umschalt moeglichkeit zwischen XBMC und rpihddevice, aehnlich wie das in Yavdr ist.

Gruss,

Franz

Alles anzeigen

Hi Franz.
Also ich alle möglichen Distris für den Raspberry durch. Ich muss zugeben das OpenELEC sehr gut läuft. Ich hatte mich auch lange mit OpenELEC beschäftigt und eine funktionierende VDR Version ins Initramfs rein gebastelt. Aber der Aufwand ist sehr groß. Außerdem besteht OpenELEC aus einer minimalinstallation was natürlich das System sehr schnell macht, wenn du dann anfängst zusätzliche Dienste wie bsp den VDR mit einzupflanzen werden natürlich auch diverse andere Hintergrunddienste und Pakete mit installiert.

Ich habe mich nach sehr langem rumtesten dann letztendlich dazu entschlossen mein System auf Raspbian aufzubauen. Dazu hab ich erst mal das System entkernt. Also alle unnötigen Dienste wie bsp den ganzen grafischen Schnickschnack rausgeworfen. So wurde das Grundsystem schonmal nurnoch halb so groß! Dann hab ich mir XBMC und VDR selbst gebruzzelt und mir eine umschaltmöglichkeit der zwei Systeme per Fernbedienung gebastelt und seitdem läuft es (auch dank dieses Plugins) sehr stabil und vor allem auch sehr flott!!! Als Tip kann ich bei XBMC noch die Gotham Version vorschlagen, die ist zwar noch nicht ganz stabil, aber sie arbeitet noch ein Stück schneller als die 12er Version.

Meiner Meinung nach lohnt sich der Aufwand nicht an dem OpenELEC System rumzubasteln. Raspbian ist da zum basteln doch schon mehr geeignet

Gruß Patrick

Danke Patrick

Vielen Dank fuer den ausfuehrlichen bericht

Ich habe bei Openelec ja schon den vdr drinn ueber das Plugin das sie mitliefern, wollte nu rpihddevice hinzufuegen und ein umschalt script basteln

Ich verwende zurzeit XBIAN was auch ziemlich flott ist aber in XBMC ist es hallt immer noch nicht so schnell wie Openelec und ich habe dazu noch 2 Tage gebraucht um alles richtig aufzusetzen

Ich bin mir zwar nicht sicher aber ich denke alle abhaengigkeiten fuer das Plugin muessten schon dabei sein und da der vdr auch schon da ist auf Openelec waehre es vielleicht einen versuch wert...

Leider denke ich das meine kentnisse hierzu nicht mehr reichen

Ich wuerde mich freuen wenn ich irgendwo hilfe finden wuerde

Gruss,

Franz

Oh. Wusste garnicht das es da ein VDR Plugin gibt. Hab mir alles selbst zusammen gebrutzelt
Mach doch mal nen eigenen Thread auf.
Vielleicht weiß ja jemand wie man ein Plugin für OpenELEC erstellen kann.

Zitat von vectra130

Mach doch mal nen eigenen Thread auf.
Vielleicht weiß ja jemand wie man ein Plugin für OpenELEC erstellen kann.

Ich denke gar nicht, dass das soooo kompliziert ist das Plugin in OpenELEC hinein zu bekommen.
Das vdr-addon (kein Plugin) enthält ja jetzt schon ein paar VDR-Plugins. Da hätte man ja schon Beispiele wie es geht. Schwieriger wird es schon mit dem Umschalten. Zwar hat gerade Heute ein OE-Dev den Window-Manager Fluxbox hinzugefügt, aber die Developer-Version benutzt aktuell gar keinen Window-Manager.
Da wird das schon etwas komplizierter.

Gerald

Hi Thomas,

Zitat von reufer

Die Struktur param wird ein paar Zeilen zuvor gelesen - solange du diese nicht wieder zurück in den Decoder schreibst, ändert sich an der effektiven Anzahl der Buffer gar nichts.

Du hast absolut recht. Das habe ich aber jetzt erst kapiert. Wenn ich nun die Werte wie im vompclient auf Videobuffers=100 und Audiobuffers=2 setze, dann habe ich nach dem Start vom VDR auf dem initialen Sender kein Bild. Nach dem Umschalten sieht aber alles völlig ruckelfrei aus:

diff -u omx.c.ori omx.c

--- omx.c.ori   2013-12-30 17:33:33.000000000 +0100
+++ omx.c       2014-02-08 18:11:57.381064265 +0100
@@ -168,7 +168,7 @@
                break;
 
        case 11:
-               if (ilclient_setup_tunnel(&m_tun[eVideoSchedulerToVideoRender], 0, 1000) != 0)
+               if (ilclient_setup_tunnel(&m_tun[eVideoSchedulerToVideoRender], 0, 0) != 0)
                        esyslog("rpihddevice: failed to setup up tunnel from scheduler to render!");
                if (ilclient_change_component_state(m_comp[eVideoRender], OMX_StateExecuting) != 0)
                        esyslog("rpihddevice: failed to enable video render!");
@@ -299,6 +299,7 @@
 
        // set up the number and size of buffers for audio render
        m_freeAudioBuffers = 2; //64;
+       m_freeVideoBuffers = 100;
 
        OMX_PARAM_PORTDEFINITIONTYPE param;
        OMX_INIT_STRUCT(param);
@@ -306,8 +307,9 @@
        if (OMX_GetParameter(ILC_GET_HANDLE(m_comp[eAudioRender]),
                        OMX_IndexParamPortDefinition, &param) != OMX_ErrorNone)
                esyslog("rpihddevice: failed to get audio render port parameters!");
-       param.nBufferSize = 160 * 1024;
        param.nBufferCountActual = m_freeAudioBuffers;
+       OMX_U32 tempmax = 50000;
+       param.nBufferSize=max(param.nBufferSize, tempmax);
        if (OMX_SetParameter(ILC_GET_HANDLE(m_comp[eAudioRender]),
                        OMX_IndexParamPortDefinition, &param) != OMX_ErrorNone)
                esyslog("rpihddevice: failed to set audio render port parameters!");
@@ -317,7 +319,12 @@
        if (OMX_GetParameter(ILC_GET_HANDLE(m_comp[eVideoDecoder]),
                        OMX_IndexParamPortDefinition, &param) != OMX_ErrorNone)
                esyslog("rpihddevice: failed to get video decoder port parameters!");
-       m_freeVideoBuffers = param.nBufferCountActual;
+        param.nBufferCountActual = m_freeVideoBuffers;
+        tempmax = 200000;
+        param.nBufferSize=max(param.nBufferSize, tempmax);
+        if (OMX_SetParameter(ILC_GET_HANDLE(m_comp[eVideoDecoder]),
+                        OMX_IndexParamPortDefinition, &param) != OMX_ErrorNone)
+                 esyslog("rpihddevice: failed to set video decoder port parameters!");
 
        dsyslog("rpihddevice: started with %d video and %d audio buffers",
                m_freeVideoBuffers, m_freeAudioBuffers);

Könnte das die Lösung sein?

Viele Grüße

Tim

Danke für die neue Version.
Werde ich Morgen gleich testen.
Wie mache ich ein update der userland-Tools? Geht das über den PacketManager?

mfg Thomas

Danke! Hab's gleich in die MLD übernommen. Zum testen werde ich aber heute leider nicht mehr kommen.

Claus

Super. Danke fürs Update.
Kurze Verständnisfrage: wofür brauch ich das Image Grabbing?

Zitat von vectra130

Kurze Verständnisfrage: wofür brauch ich das Image Grabbing?

Für ein Screenshot vom TV Bild inklusive OSD...

Viele Grüße, Uwe

PS: Vielen Dank für das Update

Installation unter Raspbian problemlos, Grabbing funktioniert.

Kann es sein, dass deinterlacing deaktiviert ist?