[Prototyp] RPI Ausgabeplugin

vectra130 · 13. Februar 2014

tehlers
Cooler Tip. Das wusste ich so auch nicht. Nutze auch XBmc und VDR. Werd ich mal in mein Skript einbauen und testen. Vielen Dank.

googles · 14. Februar 2014

Hallo Thomas

Die 0.0.8 läuft hier wirklich sehr gut.
Aber eine Frage bzgl. deinterlacing hätte ich doch noch.
Ist es auch möglich das Bild am Analogen Ausgang zu deinterlacen? Wie war das früher bei den Röhrenfernsehern wurde da das Bild deinterlaced oder konnten die das so darstellen?
Ich verwende nämlich einen alten Flat TV ohne digital eingänge nur Scart (Hats auch mal gegeben ) Ich habe bei bewegten Bildern streifen im Bild.
Im log steht:

Code

rpihddevice: using composite video output at 720x480i
...
rpihddevice: decoding video 720x576i, disabling deinterlacer

Und warum unterscheidet sich die Auflösung? Ich dachte SD ist SD. Kann man bei Composite die Auflösung auch einstellen?
Ich kenne mich mit dem Video Kram überhaupt nicht aus.

mfg Thomas

tehlers · 15. Februar 2014

Hi Thomas,

Zitat

Und warum unterscheidet sich die Auflösung? Ich dachte SD ist SD. Kann man bei Composite die Auflösung auch einstellen?

Kannst Du Dich denn nicht mehr an früher erinnern? Da ging es doch immer darum: PAL oder NTSC, 50hz (PAL, grosses Bild, flimmerig) oder 60hz (NTSC, kleines Bild, weniger flimmerig). Laut Wikipedia: http://de.wikipedia.org/wiki/Standard_Definition_Television ist 480i halt NTSC und 576i PAL.

Du solltest in jedem Fall auf PAL stellen, da das TV Signal mit 576i PAL kommt http://elinux.org/RPiconfig:

sdtv_mode defines the TV standard for composite output (default=0)

Code

sdtv_mode=0    Normal NTSC
sdtv_mode=1    Japanese version of NTSC – no pedestal
sdtv_mode=2    Normal PAL
sdtv_mode=3    Brazilian version of PAL – 525/60 rather than 625/50, different subcarrier

Viele Grüße

reufer · 15. Februar 2014

Hi Thomas

Zitat von googles

Ist es auch möglich das Bild am Analogen Ausgang zu deinterlacen? Wie war das früher bei den Röhrenfernsehern wurde da das Bild deinterlaced oder konnten die das so darstellen?

Interlacing wurde für die Röhre eingeführt, die alten analogen Videostandards (PAL/NTSC/SECAM) konnten gar kein progressives Signal übertragen. Der ganze Deinterlacing-Quatsch ist eigentlich nichts anderes als Vergangenheitsbewältigung.

Gruss
Thomas

googles · 15. Februar 2014

Danke für die Erklärung.
Früher hat es halt einfach funktioniert da hab ich mich nicht mit beschäftigt.
FF rein und gut war.
Mfg Thomas

GTRDRIVER · 15. Februar 2014

Hallo zusammen

reufer

Diff

1
diff --git a/omxdevice.c b/omxdevice.c
index a02a690..c7555f0 100644
--- a/omxdevice.c
+++ b/omxdevice.c
@@ -95,7 +95,7 @@ void cOmxDevice::SetVideoDisplayFormat(eVideoDisplayFormat VideoDisplayFormat)
            	VideoDisplayFormat == vdfLetterBox	? "LetterBox"	:
            	VideoDisplayFormat == vdfCenterCutOut ? "CenterCutOut" : "undefined");
 
-   	m_omx->SetDisplayMode(VideoDisplayFormat == vdfLetterBox, false);
+   	m_omx->SetDisplayMode(VideoDisplayFormat == vdfLetterBox, true);
 
    	cDevice::SetVideoDisplayFormat(VideoDisplayFormat);
 }

Alles anzeigen

Stell ich mich zu dumm an ?

Patch in eine Datei kopiert - sagen wir "scan.diff" und in´s Plugin Directory speichern.

Dann "patch -i scan.diff"

Läuft bei mir nicht durch - was mache ich falsch ?

CU
GTR

googles · 15. Februar 2014

Zitat von GTRDRIVER

Hallo zusammen

reufer

Diff

1
diff --git a/omxdevice.c b/omxdevice.c
index a02a690..c7555f0 100644
--- a/omxdevice.c
+++ b/omxdevice.c
@@ -95,7 +95,7 @@ void cOmxDevice::SetVideoDisplayFormat(eVideoDisplayFormat VideoDisplayFormat)
            	VideoDisplayFormat == vdfLetterBox	? "LetterBox"	:
            	VideoDisplayFormat == vdfCenterCutOut ? "CenterCutOut" : "undefined");
 
-   	m_omx->SetDisplayMode(VideoDisplayFormat == vdfLetterBox, false);
+   	m_omx->SetDisplayMode(VideoDisplayFormat == vdfLetterBox, true);
 
    	cDevice::SetVideoDisplayFormat(VideoDisplayFormat);
 }

Alles anzeigen

Stell ich mich zu dumm an ?

Patch in eine Datei kopiert - sagen wir "scan.diff" und in´s Plugin Directory speichern.

Dann "patch -i scan.diff"

Läuft bei mir nicht durch - was mache ich falsch ?

CU
GTR

Alles anzeigen

vermutlich wärst du schneller wenn dus händisch editierst.
Aber versuchs mal so:
patch -p1 -i scan.diff
mit p1 wird das erste Verzeichnis abgeschnitten da du ja shon im Ziel Verzeichnis bist.

mfg Thomas

Moorviper · 15. Februar 2014

Bei mir ist ServustvHD mit der 0.8er deutlich schlechter geworden
blankscrren und fast ständig verpixelungen und die cpu ist am anschlag

mit der 0.7 war da die cpu insgesammt mit sundtekstick bei 68% und hatte nur ab und zu (so innerhalb von 10 minuten mal kurz ne verpixelung)
gibts da ähnliche beobachtungen ??

GTRDRIVER · 15. Februar 2014

googles

Code

patching file omxdevice.c
patch unexpectedly ends in middle of line
Hunk #1 FAILED at 95.
1 out of 1 hunk FAILED -- saving rejects to file omxdevice.c.rej

Hab ich nen Brett vom´m Kopf ?

CU
GTR

googles · 15. Februar 2014

Hast du den patch mit einem falschen editor erstellt?
Du brachst einen Linux fähigen.
z.b. notepad++
oder du öffnest die datei omx.c und gehst in zeile 95 und änderst ein wort (Aber direkt am PI)

GTRDRIVER · 15. Februar 2014

googles

Hi - ist eigentlich nicht mein 1. Patch ....

Ich mach nix über Windows - alles direkt über SSH und Linux Tools direkt am PI....

CU
GTR

PS - aber du hast recht - es ist ja nur ein Wort - ich seh´s jetzt auch grad ....

googles · 15. Februar 2014

GTRDRIVER
Die Funktion hat aich auch ein bischen geändert kann sein dass patch das nicht mehr erkennt.

mfg Thomas

GTRDRIVER · 15. Februar 2014

Hallo zusammen

reufer:

Hab das jetzt mal getestet - funktioniert hervorragend (strecken)

googles:

Möglich - aber bei nur dieser einen Änderung gebe ich dir recht - hier ist manuelles ändern wesentlich sinnvoller.... -

DAs Ergebnis: die vielen alten PES Aufnahmen in 4:3 lassen sich nun auch problemlos abspielen ....

CU
GTR

PmK · 16. Februar 2014

Ich krieg beim compilieren mit vdr-2.1.4 folgenden fehler

Code

display.c: In static member function ‘static int cRpiDisplay::Snapshot(uint8_t*, int, int)’:
display.c:99:27: error: ‘DISPMANX_SNAPSHOT_PACK’ was not declared in this scope
make[1]: *** [display.o] Error 1

Woran kann das denn liegen?

seahawk1986 · 16. Februar 2014

Keine aktuelle Firmware und Header-Files für den Raspberry Pi installiert?
https://github.com/xbmc/xbmc/pull/3210#commitcomment-4267969

PmK · 16. Februar 2014

Hmm.. danke für den Tip. Die Installation ist zwar von Dezember aber vieleicht liegts ja daran...

vectra130 · 16. Februar 2014

Kann es sein das die Version 0.0.8 wesentlich träger beim zappen ist als die Version 0.0.7 ???
War leider so schlau und hab gleichzeitig den VDR neu mit Version 2.0.5 gebaut.
Weiß jetzt also auch nicht genau ob es am VDR oder am Plugin liegt.
Kann jemand mal seine Erfahrung nach dem Wechsel auf 0.0.8 mitteilen?
Danke

GTRDRIVER · 16. Februar 2014

Hallo

Hatte das 0.0.7. zwar nicht soooo lange laufen. Vor allem aber nicht weil es bei mir extrem instabil war...

Die aktuelle Version läuft derart stabil dass es schon fast unglaublich ist...

Zu den Umschaltzeiten kann ich nur sagen dass das hier mit SD super schnell ist. Bei Hd. Kommt das Bild erst 1-3 sec später je nach Kanal.

Cu

reufer · 16. Februar 2014

Zitat von vectra130

Kann es sein das die Version 0.0.8 wesentlich träger beim zappen ist als die Version 0.0.7 ???

Nein, das sollte definitiv nicht sein.

Gruss
Thomas

reufer · 16. Februar 2014

Zitat von PmK

Woran kann das denn liegen?

Vor etwa fünf Monaten wurden neue Flags für vc_dismpanx_snapshot() eingeführt - die userland-Tools müssen also entsprechend aktuell sein.

Gruss
Thomas

[Prototyp] RPI Ausgabeplugin

Jetzt mitmachen!

Teilen