[Prototyp] RPI Ausgabeplugin

clausmuus · 11. Juni 2014

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

Claus

nimbusfx · 12. Juni 2014

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

Alles anzeigen

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 · 13. Juni 2014

Zitat von 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)) :

Alles anzeigen

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 · 14. Juni 2014

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 · 14. Juni 2014

Zitat von 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?

Alles anzeigen

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 · 8. August 2014

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

neumann2k · 9. August 2014

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 · 9. August 2014

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 · 9. August 2014

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 · 10. August 2014

Zitat von 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 · 10. August 2014

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 · 11. August 2014

Zitat von 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.

Zitat von 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 · 11. August 2014

Zitat von 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 · 11. August 2014

Zitat von 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 · 12. August 2014

Zitat von 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 · 12. August 2014

Zitat von 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 · 12. August 2014

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 ??

Spoiler anzeigen

Frounts · 12. August 2014

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 · 12. August 2014

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 · 12. August 2014

vdr-wiki

[Prototyp] RPI Ausgabeplugin

Jetzt mitmachen!

Teilen