HD Extension: osdpip

Quacks · 29. Dezember 2008

Hi,

da für die EHD ein Picture in Picture Plugin verfügbar ist habe ich einmal versucht, dies auch mit meinem normalen VDR zu nutzen. Zum jetzigen Zeitpunkt komme ich soweit, das der PiP Rahmen gezeichnet wird, der Sener + EPG angezeigt wird und auch kurz einmal ein Livebild dort auftaucht. Allerdings bleibt dann nur der Rahmen sichtbar. Witzigerweise kann ich mir mid hdfbshot ja ein OSD Bild als PNG abspeichern. Dort taucht das Livebild dann allerdings auf. Sehr seltsam.....

Es sind einige Patches nötig, um das ganze fehlerfrei hinzukriegen. Zuerst muss der VDR um die Klasse cReelBoxBase erwitert werden. Dies macht der Patch vdr-1.7.z.osdpip.diff.

Danach muss noch das reelbox Plugin geändert werden. Hier muss der Pip-Kram aktiviert werden mit dem Patch vdr-reelbox-pip.diff. Hier ist daruaf zu achten, das das Framebuffer Device der eHD geladen ist und auch fest in der Datei VideoPlayerPipHd.c verdrahtet ist. Bei mir ist es /dev/fb3 und der Patch setzt dieses entsprechent um. Passt das Device nicht, bekomme ich zwar das EPG angezeigt, aber der Rahmen ist nicht vorhanden.

Zu guter Letzt muss das osdpip Plugin noch ein wenig angepasst werden. Dies erledigt dann der letzte Patch.

Für die Gentoo User habe ich entsprechende Ebuilds an üblicher Stelle abgelegt, die die Patcherei (abgesehen vom VDR) erledigen.

Wenn einer mitttesten und forschen möchte, ist er herzlich eingeladen. Die Patches laufen alle gegen das SVN-10261

Akualisierung: SVN 10288

Ich habe die Pacthes einmal aktualisiert und die Anmerkung von schorsch eingebaut. Damit läufts hier nun. Die Ebuilds sind ebenfalls angepasst.

ACHTUNG: Bei dem Reelbox Patch muss unbedingt das Framebuffer angepasst werden!

cu und guten Rutsch,

Quacks

Quacks · 29. Dezember 2008

Bei mir erzeugt das Plugin nun folgende Debugging Ausgaben:

vdr:

Code

------NEW-------*cPluginOsdpip::MainMenuAction-----NEW------
---*cPluginOsdpip::MainMenuAction, vor new cOsdPipObject---
VideoPlayerPipHd::Start()
SWDecoder construct
############ Framebuffer: 0xac8f6000
PiP Thread start
virtual void Reel::HdOsd::SetActive(bool) On=1
x: 60 y: 424
x: 70 y: 60
i: 0
PIP: 0
cOsdInfoWindow::Show() pipChannel: 0
VideoPlayerPipHd::SetDimensions()
Enable PiP out
PiP Queue overflow 216 201
PiP Queue overflow 219 204
PiP Queue overflow 232 217
PiP Queue overflow 269 254
PiP Queue overflow 275 260
PiP Queue overflow 277 262
PiP Queue overflow 1893 1878
PiP Queue overflow 2304 2289

Alles anzeigen

und im Logfile finde ich

Code

Dec 29 12:09:08 vdr vdr: [5271] ReelNG: cSkinReelDisplayChannel::~cSkinReelDisplayChannel()
Dec 29 12:09:09 vdr vdr: [5271] max. latency time 1 seconds
Dec 29 12:09:16 vdr vdr: [5271] connect from 192.168.20.10, port 57721 - accepted
Dec 29 12:09:16 vdr hde_fb: ---------- dev_open 1
Dec 29 12:09:16 vdr hde_fb: get_hd_data faff0000
Dec 29 12:09:16 vdr hde_fb: dev_mmap
Dec 29 12:09:16 vdr hde_fb: remap_pfn_range> 0xac8f6000, 0xd3600000, 2097152 (0x200000)
Dec 29 12:09:16 vdr hde_fb: dev_mmap SUCCESS

Quacks

stevie101 · 29. Dezember 2008

Cool, das probiere ich nachher mal aus.
Hatte mich auch mal daran gegeben, aber mit meinen Anpassungen immer nur einen SegFault beim Ausführen bekommen.

3PO · 29. Dezember 2008

Zitat

Original von Quacks
[...] Hier ist daruaf zu achten, das das Framebuffer Device der eHD geladen ist ...

Wie läd man denn den Framebuffer der eHD?

Quacks · 29. Dezember 2008

Zitat

Original von C-3PO
Wie läd man denn den Framebuffer der eHD?

Hi,

das hdshm Modul muss mit has_fb=1 geladen werden. Danach sollte mit dmesg eine solche Ausgabe auftauchen:

Code

hdshm_init_struct: Phys start e3000000, start f9000000, nc-start f9980000
hde_fb: init 1
hde_fb: init_fb_info

cu,

Quacks

stevie101 · 29. Dezember 2008

Hi Quarks,

Hab das gleiche Ergebnis wie Du, am Anfang kurz Bild und dann der Kasten.
Im Log steht, wie bei Dir oben angegeben, pipChannel : 0 und PIP :0, vielleicht ist das die Ursache

bratfisch · 29. Dezember 2008

Zitat

Original von stevie101
Im Log steht, wie bei Dir oben angegeben, pipChannel : 0 und PIP :0, vielleicht ist das die Ursache

Nö, sicher nicht.
Das sind bloß debug-Ausgaben, die ich vergessen habe wieder rauszunehmen...

Die beiden Ausgaben "pipChannel" und "PIP" an der Stelle sagen bloß in welchem der beiden "Fenster" zuletzt der Kanal umgeschaltet wurde - bei "0" ist's der Kanal im "Haupfenster", bei "1" ist's der im "PIP-Fenster"...

real_schorsch · 29. Dezember 2008

1) Das mit dem kurzen Auftauchen des Livebilds ist ein mistiges Problem der Skalierungslibs. das PiP im reelbox-PI nutzt sws_scale. Das gibt es aber in zwei Varianten, einmal als Legacy in libavacodecs und einmal in libswscale. Die Variante in avcodecs setzt den Alphachannel gleich richtig, die in swscale leider falsch (transparent). Beim Einblenden wird der Alpha manuell überschrieben (daher sieht man das Bild), danach ist es sichtbar (avcodec) oder nicht (swscale). Im Prinzip sollte es also reichen, die libswscale ganz rauszuwerfen. Oder in VideoPlayerPipHd.c::Show() das "if (alpha==255)" zu deaktivieren, damit der else-Zweig immer drankommt. Kostet dann aber etwas mehr CPU...

2) Zur Geschwindigkeit: Schaut mal, ob nach dem hdboot der PCI-Bereich der HDE in /proc/mtrr drinsteht:

Code

reg00: base=0x00000000 (   0MB), size= 512MB: write-back, count=1
reg01: base=0x1f800000 ( 504MB), size=   8MB: uncachable, count=1
reg02: base=0xe0000000 (3584MB), size= 128MB: write-combining, count=1    <--------- HDE

Wenn das nicht der Fall ist, läuft der Speicherzugriff auf den Frambuffer recht langsam und könnte die Ursache für die dauernden Überläufe sein.

stevie101 · 29. Dezember 2008

real_schorsch
Danke für die Tips.

Wenn ich den if(alpha) Zweig deaktiviere funktioniert es grundsätzlich mit Bild. Die CPU Load ist wie Du gesagt hast relativ hoch, ca.40%, ungefähr genauso wie mit dem Standard osdpip. Das Bild läuft hiermit etwas flüssiger allerdings sind leichte vertikale Streifen zu erkennen, Schrift lässt sich absolut nicht lesen.
Das Fenster ist für meinen Geschmack auch etwas klein.

Ach ja, die Karte ist wie beschrieben unter /proc/mtrr erkennbar.

IG88 · 30. Dezember 2008

hi,

ich hätte da mal eine allgemeine frage, wenn das pip in software dekodiert wird dann bedeutet das wohl auch das man kein hd-sender im pip sehen kann? (bei "normaler" vdr prozessorbestückung, also kein 2.666 GHz core2duo)

oder gibts da irgendwelche abkürzungen um an ein "unvollständiges" bild zu kommen (vieleicht sowas wie - nur jeden 4 makroklock zu dekodieren) - nach dem zusammenfalten zum pip sueht man ja eh nicht mehr viel

real_schorsch · 30. Dezember 2008

Es wird deswegen überhaupt in SW gemacht (und nicht im DeCypher), weil der zweite Decoder im DeCypher ein ziemliches Rumräumen der Speicherverwaltung verlangt (Zusatzpuffer für die Bilder, etc.). Kann man machen, allerdings habe ich den zweiten Decoder dann nicht wirklich stabil bekommen. Und das war mir dann doch zuviel Arbeit mit zweifelhafter Aussicht, daher die Lösung über die CPU. Nebenbei kann der DeCypher auch nur einen SD-Stream im zweiten Decoder verarbeiten, von daher kein Rückschritt.

Den gesparten Speicher nehmen wir lieber mal für ein HD-OSD her..

Das mit HDTV könnte man sicher irgendwie hintricksen, wahrscheinlich aber nur mühsam. Die Basis des jetzigen PiPs sind eine Handvoll Zeilen ffmpeg-Calls. Dank der vielen Rückreferenzierungen kann man auch nicht einfach nur I-Frames dekodieren.

Ergo: Wer will, kann es versuchen, ich machs nicht

rabi22 · 30. Dezember 2008

Hi Quacks,

in der Datei
VideoPlayerPipHd.c
des VDR-reelbox-Plugins musste ich noch ein
#include <stdlib.h>
mitaufnehmen, damit es kompiliert.
Evtl. kannst du das mit in den Patch aufnehmen.

Freu mich schon drauf, daß ganze zu testen

rabi22 · 1. Januar 2009

Funktioniert soweit wunderbar

2 Fragen/Anmerkungen:
Könnte man anstatt der weißen Schrift nicht DisplayChannelInfo der Skin aufrufen? Das fällt doch etwas aus dem Design-Rahmen

Zu dem FB-Device im vdr-reelbox-pip.diff:
Könnte man das nicht über eine Setup-Option einstellbar machen?
Oder ein autodetect z.B. über sysfs oder so....
Nur als Anregung.

real_schorsch · 1. Januar 2009

Das osdpip kommt eigentlich noch von der Lite und wurde seitdem nie mehr angefasst. Mir gefällt die krackelige Schrift auch nicht, aber für den Anfang reicht es ja mal.

Das mit dem Framebuffer kann man rausfinden (fbset -i schaffts auch), ich produziere aber immer nur "proof-of-concepts", die Verschönerung können dann die anderen machen

ALT255 · 1. Januar 2009

real_schorsch

bei mir erscheint 0xe00000000 nicht in /proc/mtrr.

Wie bekomme ich den Eintrag da hinein.

Habe hier ein x86-64 System.

real_schorsch · 1. Januar 2009

e0 muss es nicht sein, hängt davon ab, wo das Bios die Karte reingesetzt hat. Schau mal bei lspci -v nach der Startadresse (der 128MB-Bereich) und such die in den mtrrs.

ALT255 · 2. Januar 2009

Laut lspci ist es schon e0

lspci Ausschnitt:

Code

01:06.0 Multimedia controller: Micronas USA, Inc. Device 8100
        Subsystem: Micronas USA, Inc. Device 8100            
        Flags: bus master, medium devsel, latency 32, IRQ 5  
        Memory at ee006000 (32-bit, non-prefetchable) [size=4K]
        Memory at e0000000 (32-bit, non-prefetchable) [size=128M]
        Capabilities: [40] Power Management version 2

und
/proc/mtrr :

Code

reg00: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
reg02: base=0xc0000000 (3072MB), size= 256MB: write-back, count=1
reg03: base=0xcc000000 (3264MB), size=  64MB: uncachable, count=1
reg04: base=0x100000000 (4096MB), size=4096MB: write-back, count=1
reg05: base=0x200000000 (8192MB), size= 512MB: write-back, count=1
reg06: base=0x220000000 (8704MB), size= 256MB: write-back, count=1

real_schorsch · 2. Januar 2009

Könnte mal wieder ein 64Bit-Problem sein... Du hast aber schon die hdboot-Variante mit MTRR? "hdboot -h" hat dann eine Option -M, wenn man keine MTRRs ändern will.

ALT255 · 2. Januar 2009

Sieht zumindest so aus:

Code

Usage: hdboot <options>
       -r        Force warm reset
       -p <hex>  Manually set PCI BAR1 (DANGEROUS!!!)
       -i <file> Upload file (default: linux.bin)
       -e <hex>  Manually set kernel entry address (default: auto detect)
       -v        Verify DDR-RAM after upload
       -w <timeout>  Wait until kernel is up
       -c <string>   Commandline
       -M         Disable MTRR speedup

EDIT:

So wie es aussieht funktioniert es, wenn ich in der hdboot.c
mtrr.base=0xe0000000;
mtrr.size=0x8000000;
direkt setze.
Ist also wieder ein Variablen Problem bei 64Bit.

3PO · 10. Januar 2009

Habe es gerade mal installiert.

Funktioniert einwandfrei, kein Vergleich zu der früheren Version von osopip.

Die Krönung währe natürlich noch, wenn man via Fernbedienung noch die Ausgabe der graphTFT Plugins anzeigen lassen könnte.

Thx @ all

HD Extension: osdpip

Jetzt mitmachen!

Teilen

Benutzer online in diesem Thema