[Prototyp] RPI Ausgabeplugin

clausmuus · June 11, 2014 at 9:30 AM

Aber läuft Dein TV denn auch auf 50Hz, oder eventuell mit 60Hz?

Claus

nimbusfx · June 12, 2014 at 8:26 PM

Also der PC-Modus ist aus, mehr kann ich am TV glaub' ich nicht einstellen.

Code

pi@pi01 ~ $ /opt/vc/bin/tvservice -m CEA
Group CEA has 21 modes:
           mode 1: 640x480 @ 60Hz 4:3, clock:25MHz progressive 
           mode 2: 720x480 @ 60Hz 4:3, clock:27MHz progressive 
           mode 3: 720x480 @ 60Hz 16:9, clock:27MHz progressive 
           mode 4: 1280x720 @ 60Hz 16:9, clock:74MHz progressive 
  (prefer) mode 5: 1920x1080 @ 60Hz 16:9, clock:74MHz interlaced 
           mode 7: 720x480 @ 60Hz 16:9, clock:27MHz x2 interlaced 
           mode 14: 720x480 @ 60Hz 4:3, clock:54MHz x2 progressive 
           mode 15: 720x480 @ 60Hz 16:9, clock:54MHz x2 progressive 
           mode 16: 1920x1080 @ 60Hz 16:9, clock:148MHz progressive 
           mode 17: 720x576 @ 50Hz 4:3, clock:27MHz progressive 
           mode 18: 720x576 @ 50Hz 16:9, clock:27MHz progressive 
           mode 19: 1280x720 @ 50Hz 16:9, clock:74MHz progressive 
  (native) mode 20: 1920x1080 @ 50Hz 16:9, clock:74MHz interlaced 
           mode 22: 720x576 @ 50Hz 16:9, clock:27MHz x2 interlaced 
           mode 29: 720x576 @ 50Hz 4:3, clock:54MHz x2 progressive 
           mode 30: 720x576 @ 50Hz 16:9, clock:54MHz x2 progressive 
           mode 31: 1920x1080 @ 50Hz 16:9, clock:148MHz progressive 
           mode 35: 720x480 @ 60Hz 4:3, clock:108MHz x4 progressive 
           mode 36: 720x480 @ 60Hz 16:9, clock:108MHz x4 progressive 
           mode 37: 720x576 @ 50Hz 4:3, clock:108MHz x4 progressive 
           mode 38: 720x576 @ 50Hz 16:9, clock:108MHz x4 progressive

Display More

Mode 20 und Mode 31 hab ich versucht.

Bei den 720p-Sendern ist es gefühlt seltener. Könnte es auch an einer zu langsamen SD-Karte liegen?

reufer · June 13, 2014 at 6:27 AM

Quote from nimbusfx

Bei den 720p-Sendern ist es gefühlt seltener. Könnte es auch an einer zu langsamen SD-Karte liegen?

Das glaube ich kaum. Wenn du keine Meldung im Log siehst, und der Fehler zudem nur bei Live-TV auftritt, würde ich mal folgenden Patch versuchen:

Diff

diff --git a/omxdevice.c b/omxdevice.c
index fec8cfd..a8229c7 100644
--- a/omxdevice.c
+++ b/omxdevice.c
@@ -32,7 +32,7 @@ int cOmxDevice::s_speeds[2][8] = {
 
 // speed correction factors for live mode, taken from omxplayer
 int cOmxDevice::s_speedCorrections[5] = {
-   	S(0.990f), S(0.999f), S(1.000f), S(1.001), S(1.010)
+   	S(0.995f), S(0.999f), S(1.000f), S(1.001), S(1.005)
 };
 
 cOmxDevice::cOmxDevice(void (*onPrimaryDevice)(void)) :

Display More

Im Live-Mode "dehne" ich den Takt, um ihn dem DVB-Strom anzugleichen, damit weder die Daten ausgehen, noch die Buffer überlaufen. Das geschieht in zwei Stufen, und zwar +/- 0.1% und +/- 1%. Könnte sein, dass manche Verstärker damit nicht klar kommen, der Patch reduziert die grosse Korrektur auf +/- 0.5%.

Gruss
Thomas

nimbusfx · June 14, 2014 at 12:09 PM

Mmh, mit Patchen hatte ich bisher noch nie zu tun. Kannst Du vielleicht kurz beschreiben, was ich genau machen muss?

Nach dem, was ich gelesen habe:
- Deinen Quellcode in eine Datei.patch speichern
- die omxdevice.c in ein Unterverzeichnis "a" kopieren
- Unterverzeichnis "b" anlegen
- "patch -i Datei.patch"
- die erstellte Datei an den ursprünglichen Ort der omxdevice.c kopieren
- das Plugin neu bauen und installieren

Halbwegs richtig oder völlig falsch?

googles · June 14, 2014 at 12:25 PM

Quote from nimbusfx

Mmh, mit Patchen hatte ich bisher noch nie zu tun. Kannst Du vielleicht kurz beschreiben, was ich genau machen muss?

Nach dem, was ich gelesen habe:
- Deinen Quellcode in eine Datei.patch speichern
- die omxdevice.c in ein Unterverzeichnis "a" kopieren
- Unterverzeichnis "b" anlegen
- "patch -i Datei.patch"
- die erstellte Datei an den ursprünglichen Ort der omxdevice.c kopieren
- das Plugin neu bauen und installieren

Halbwegs richtig oder völlig falsch?

Display More

Falsch.
mit dem oben geposteten Code eine patch Datei erstellen (Name egal)
ins Verzeichnis kopieren und
patch -p1 -i Datei ausführen.
ober einfacher wird sein einfach omxdevice.c zu öffnen zur zeile 32 und die zeile händisch zu ändern.
Fals nämlich die patch datei mit einem falschen editor erstellt wird kommt auch nur Müll raus.

mfg Thomas

Copperhead · August 8, 2014 at 12:54 PM

Ich weiß nicht, wie viele Arch Linux ARM (VDR4Arch) verwenden, aber für diejenigen habe ich vdr-rpihddevice paketiert.

neumann2k · August 9, 2014 at 11:09 AM

Vielen Dank für das rpihddevice-plugin. Ich habe es erfolgreich unter rapsbian laufen. Läuft astrein ohne Fehler. Zwei Fragen dazu an den Entwickler:

1. Das OSD ist ein wenig langsam, siehst Du hier noch Verbesserungspotenzial, oder ist der ARM dafür einfach zu schwach?
2. Wenn ich den Pi über Nacht an lasse, ist am nächsten Tag kein Output mehr am TV zu sehen. Hab noch nicht per SSH nachgeschaut, muss den Pi dann
resetten.

clausmuus · August 9, 2014 at 2:24 PM

Der VDR schaltet bei nicht Gebrauch doch nach 3 Stunden den RPI aus. Danach hilft nur ein Trennen vom Stromanschluss und neu starten.

Claus

Niel · August 9, 2014 at 11:09 PM

Hallo!

Das Abschalten habe ich meinem RPi abgewöhnt. Er rennt 24/7.

Das Bild ist bei mir nur nach dem EPG-Scan weg. Einmal Kanal umschalten und alles ist wieder gut.

Grüße

Niel

neumann2k · August 10, 2014 at 7:40 AM

Quote from clausmuus

Der VDR schaltet bei nicht Gebrauch doch nach 3 Stunden den RPI aus. Danach hilft nur ein Trennen vom Stromanschluss und neu starten.

Schon so lange dabei, trotzdem nicht daran gedacht. Vielen Dank.

decembersoul · August 10, 2014 at 9:04 PM

Ich benutze MLD in der aktuellen Version, hatte das selbe Problem aber auch mit der vorherigen Version.

Ich kann kein Kika HD sehen. Das Bild ist alle 5-10 Sekunden für ca 1 Sekunde weg.
Bin ich der einzige der das Problem hat?
Das Problem tritt sowohl auf wenn ich den Stream vom Streamdev schaue oder eine Aufnahme via NFS schaue.

Ich habe zwar ein RasPi mit "nur" 256 MB, ich hatte mir aber auch einen 512 geliehen und hatte damit das selbe Problem. Daher schließe ich die HW aus.

reufer · August 11, 2014 at 4:43 PM

Quote from neumann2k

1. Das OSD ist ein wenig langsam, siehst Du hier noch Verbesserungspotenzial, oder ist der ARM dafür einfach zu schwach?

Potential gäbe es, mit OpenVG , allerdings kann ich nicht abschätzen, wie hoch der Gewinn wäre. Allerdings nutze ich auch nur einfache Skins, wie z.B. Enigma-NG. Für komplexe Skins dürfte das Raspi auch mit Highlevel-OSD an seine Grenzen kommen, dann hätte man die selben Probleme wie mit XBMC. Für mich momentan jedenfalls kein Problem, mir gefallen die schlichten Skins mit Abstand am besten.

Quote from neumann2k

2. Wenn ich den Pi über Nacht an lasse, ist am nächsten Tag kein Output mehr am TV zu sehen. Hab noch nicht per SSH nachgeschaut, muss den Pi dann
resetten.

Ich habe auf meiner Liste noch einen Punkt zu dem Thema - es gibt tatsächlich noch ein Problem im Dauerbetrieb, gerade bei HD-Sendern. Aber das muss bis nach der "Sommerpause" warten...

Gruss
Thomas

reufer · August 11, 2014 at 4:45 PM

Quote from decembersoul

Ich kann kein Kika HD sehen. Das Bild ist alle 5-10 Sekunden für ca 1 Sekunde weg.

War das schon immer so? Ich dachte, das Problem vor einiger Zeit gefixt zu haben... Ich gehe davon aus, dass dein Display mit 50Hz läuft?

Gruss
Thomas

neumann2k · August 11, 2014 at 9:13 PM

Quote from reufer

Potential gäbe es, mit OpenVG , allerdings kann ich nicht abschätzen, wie hoch der Gewinn wäre. Allerdings nutze ich auch nur einfache Skins, wie z.B. Enigma-NG. Für komplexe Skins dürfte das Raspi auch mit Highlevel-OSD an seine Grenzen kommen, dann hätte man die selben Probleme wie mit XBMC. Für mich momentan jedenfalls kein Problem, mir gefallen die schlichten Skins mit Abstand am besten.

Ich benutze das VDR Classic Skin. Allerdings ist halt bei jedem Menüaufruf eine kurze Gedenkpause zu bemerken. Trotzdem ist das PLUGIN sehr schön. Vielen Dank dafür.

decembersoul · August 12, 2014 at 8:24 AM

Quote from reufer

War das schon immer so? Ich dachte, das Problem vor einiger Zeit gefixt zu haben... Ich gehe davon aus, dass dein Display mit 50Hz läuft?

Gruss
Thomas

Ich habe den RasPi gestern mal an meinem anderen TV angeschlossen. Erstaunlich. Dort habe ich keine Probleme.
Ich glaube beide laufen auf 60Hz. Sind beides LG TV's. Aber unterschiedliche.
Heute müsste mein zweiter (neuer) RasPi kommen. Dann kann ich es noch mal weiter testen.

reufer · August 12, 2014 at 8:45 AM

Quote from decembersoul

Ich glaube beide laufen auf 60Hz.

60Hz sind aber denkbar ungeeignet, egal ob mit dem Raspi oder einem "grossen" VDR. Selbst wenn es ohne Ruckeln läuft, richtig flüssig wird das nie.

Gruss
Thomas

decembersoul · August 12, 2014 at 9:30 AM

Das Stimmt und verwundert mich auch etwas.
Mein "richtiger" VDR hat sich verabschiedet.
Habe den RasPi erst seit ein paar Tagen im Produktivbetrieb und da waren noch ein paar andere Baustellen.

Da ich es beim TV nicht einstellen kann muss ich es wohl beim VDR einstellen.

Wenn ich es richtig sehe, dann muss ich den hdmi_mode richtig setzen oder?
Welchen nehme ich da am besten?

hdmi_mode=31 ??

Display Spoiler

hdmi_mode=1 VGA
hdmi_mode=2 480p 60Hz
hdmi_mode=3 480p 60Hz H
hdmi_mode=4 720p 60Hz
hdmi_mode=5 1080i 60Hz
hdmi_mode=6 480i 60Hz
hdmi_mode=7 480i 60Hz H
hdmi_mode=8 240p 60Hz
hdmi_mode=9 240p 60Hz H
hdmi_mode=10 480i 60Hz 4x
hdmi_mode=11 480i 60Hz 4x H
hdmi_mode=12 240p 60Hz 4x
hdmi_mode=13 240p 60Hz 4x H
hdmi_mode=14 480p 60Hz 2x
hdmi_mode=15 480p 60Hz 2x H
hdmi_mode=16 1080p 60Hz
hdmi_mode=17 576p 50Hz
hdmi_mode=18 576p 50Hz H
hdmi_mode=19 720p 50Hz
hdmi_mode=20 1080i 50Hz
hdmi_mode=21 576i 50Hz
hdmi_mode=22 576i 50Hz H
hdmi_mode=23 288p 50Hz
hdmi_mode=24 288p 50Hz H
hdmi_mode=25 576i 50Hz 4x
hdmi_mode=26 576i 50Hz 4x H
hdmi_mode=27 288p 50Hz 4x
hdmi_mode=28 288p 50Hz 4x H
hdmi_mode=29 576p 50Hz 2x
hdmi_mode=30 576p 50Hz 2x H
hdmi_mode=31 1080p 50Hz
hdmi_mode=32 1080p 24Hz
hdmi_mode=33 1080p 25Hz
hdmi_mode=34 1080p 30Hz
hdmi_mode=35 480p 60Hz 4x
hdmi_mode=36 480p 60Hz 4xH
hdmi_mode=37 576p 50Hz 4x
hdmi_mode=38 576p 50Hz 4x H
hdmi_mode=39 1080i 50Hz reduced blanking
hdmi_mode=40 1080i 100Hz
hdmi_mode=41 720p 100Hz
hdmi_mode=42 576p 100Hz
hdmi_mode=43 576p 100Hz H
hdmi_mode=44 576i 100Hz
hdmi_mode=45 576i 100Hz H
hdmi_mode=46 1080i 120Hz
hdmi_mode=47 720p 120Hz
hdmi_mode=48 480p 120Hz
hdmi_mode=49 480p 120Hz H
hdmi_mode=50 480i 120Hz
hdmi_mode=51 480i 120Hz H
hdmi_mode=52 576p 200Hz
hdmi_mode=53 576p 200Hz H
hdmi_mode=54 576i 200Hz
hdmi_mode=55 576i 200Hz H
hdmi_mode=56 480p 240Hz
hdmi_mode=57 480p 240Hz H
hdmi_mode=58 480i 240Hz
hdmi_mode=59 480i 240Hz H

Frounts · August 12, 2014 at 9:52 AM

Da Du MLD verwendest, auch im Webinterface. Mode 31 ist OK.
Achtung: Wenn das suspend-addon verwendet wird, gibs noch einen Bug nach dem Aufwecken. Danach ist die Anzeige wieder auf 60Hz.
LG Fr.

wolfgang6444 · August 12, 2014 at 6:23 PM

Hallo,

ich weiss, dass ist alles noch im Prototypenstadium. Trotzdem interessiert mich das als Alternative zu dem von mir bisher genutzten vompclient.
Ich wuerde das gerne mal probieren, habe aber noch keinen richtigen "EInstiegspunkt" gefunden.
Gibt es irgendwo ein basic howto z.B. mit Antworten u.A. auf folgende Fragen:

1) Was unterscheidet das rphidevice von vompclient? Vermutlich ein reines Ausgabedevice zum Steuern des servers und zur Darstellung des Bildes vom server?
2)Wie verbindet sich das mit dem server? Was muss auf dem server installiert sein? Wie finden sich server und client? config-files?
3)Wie funktioniert das mit der Fernbedienung? LIRC auf dem RASPI?

Danke fuer Eure Hilfe bei diesen sehr elementaren Fragen?

Gruss

Wolfgang

Moorviper · August 12, 2014 at 7:42 PM

vdr-wiki

[Prototyp] RPI Ausgabeplugin

Participate now!

Users Viewing This Thread