[Prototyping] vdr-plugin-seduatmo: ein ganz krasser Plan!

Nachdem es die letzten Tage nur ein Plugin Container war, welcher vorne auf dem softhddevice grabbed , hinten auf den LEDs ein lustiges Lauflicht spielt, wissen wir seit gestern Abend das es geht, und zwar so richtig performant!

Wir haben ein paar Sachen getestet, den Code von Softhddevice und dfatmo analysiert, und auch mit johns geschrieben und beim Plaudern kam dann das Thema auf Skalierung . Daraus ist dann die Idee gewachsen das ganze Thema in Hardware mit vdpau auf der Graka erschlagen zu wollen.

Man muss sich vorstellen man hat ein LED Setup von sagen wir 30x16 LED rundherum, das sagen wir dem softhddevice und bekommen ein fertiges Bild runterskaliert auf unserere LED Geometrie zugeschnitten, wir brauchen grundsätzlich nur noch die (Rand)Pixel ausgeben. Das grabben dieses Miniaturbildes ist dann natürlich extrem performant.

Wir haben dazu gestern ein Patch für Softhddevice gebaut und das ganze ausprobiert: und ich muss sagen das funktioniert prima und benötigt (ohne weitere Verarbeitung, nur 1:1 auf den Stripe geschoben) an der Stelle 0% CPU. – Somit haben wir nur noch die 6% mehr CPU, die durch den Stream auf dem UART entstehen.

Wie gesagt ist es bis hierher nur eine Machbarkeitsstudie, man kann noch nichts einstellen, alles ist hart einkompiliert, gestern ging auch nur oben und unten (die Seiten noch nicht): aber es funktioniert tadellos!

An dieser Stelle hier auch ganz besonderen Dank an Jörg. Auch wenn er meist etwas im Hintergrund bleibt: ohne sein geniales Coding sind solche Projekte nicht möglich!

Christian

Zitat von TheChief

Sehr schön, weiter so....meine Hardware dürfte dann nächste Woche auch ankommen....hoffe ich. Dann steh ich Euch zur Verfügung.

was wir eigentlch ein wenig hoffen ist jemanden abzuholen der dann wiederum uns abholt. Der mit uns testet, der ein SEDU testsetup hat und der extreeeem viel praktische Erfahrung mit Ambilight hat. Jemand der weiß welche der unzähligen Knöpfe nicht nur ‘nice to-‘ sondern ‘must have‘ sind. Der sich auch mit diesem Gamma und Weißabgleichsgedöns bestens auskennt. Wir müssen ja nicht jede pitfall hier mitnehmen.

Alternativ sammeln wir auch Informationen gern hier im Thread.

Christian

Zitat von tecfreak

Was haltet ihr von der Idee auch standardisierte Hardware/Protokoll zu unterstützen (DMX) und mit dem Plugin zusätzlich als Client am OLA Server anzudocken?

ist jetzt in erster Linie nicht so das Ziel, momentan geht's schlicht und ergreifend um den Usecase ambilight mit vdr/sedu/softhddevice

Aktuell schreiben wir direkt auf den UART, es schwebt aber auch noch der Gedanke im Raum das Plug als Client am boblight anzudocken. Das sehen wir aber, aktuell gibt mehr als genug andere Baustellen.

Christian

Zitat von Pesi

P.S.: Das mit dem runter rechnen auf ein kleineres Bild, bei dem praktisch direkt jedes Pixel gleich eine Zone ist, ist echt ne geniale Idee!

Ahh, der Meister persönlich

ja, geht aber leider nur auf der Randsseite - nach innen werden wir für den Farbmix mindestens eine weitere Zone dazu nehmen müssen (das beantwortet auch die Frage von solipsists), sonst wirkts zu unruhig. Desweiteren könnte es sein das wir evtl die Auflösung noch mal verdreifachen müssen um 1/3 des Nachbarpix zur Harmonisierung mit reinzunehmen (bei boblight heißt das blurring) das sollte aber das Konzept nicht in Frage stellen, das ist alles in so einem kleinen Bereich das man das nicht mal bemerkt...

Christian

Zitat von TheChief

Wie funktioniert das im Moment? Angenommen ich hätte 160x90 LEDs rund um den Fernseher...wird dann ein Bild in der Grösse 160x90 Pixel gegrabbt und dann die Farben an den Rändern ausgewertet und ausgegeben?

so zumindest ist der Plan - kann sein das wir da noch ne konfigvariable einbauen für PIX die hinter einem extrem breiten Rahmen verschwinden, aber ja: so dachten wir

Christian

nein, es wird eine automatische Erkennung für 16:10 und 4:3 geben, die dann in HD und SD gleichermaßen gut funktioniert. Wir bekommen das Bild so wie es ausgegeben wird: also mit OSD und mit eventuellem autocrop, halt genau das was du auf dem Bildschirm siehst wenn du softhd benutzt. - das macht an der Stelle vieles einfacher weil wir keine getrennten Routinen zu SD/HD benötigen.

Das xbmc addon macht die Erkennung meines Wissens auch jetzt schon, dfatmo macht auch sowas in der Art - ich weiß aber nicht genau wie es technisch bei denen funktiniert. - Denke das ist direkt der zweite Schritt direkt nachdem es überhaupt zufriedenstellend funktiniert.

Christian

desweiteren erwägen wir auf ein im LEDstyles.de Forum entwickeltes Protokoll anstelle von Standard miniDMX zu setzen. - bei diesem Protokoll handelt es sich von der Userseite um eine Syntax ähnlich zu miniDMX, deahalb wird auch fast jede existierende SW ohne Patche benutzbar sein. Auf dem Controller benötigt es aber eine andere Firmware die ich seit gestern teste. Der Hauptvorteil dieses tpm2 Protokolls ist die Entlastung der seriellen Schnittstelle, je nach Szenario um fast 50% durch Einsparung infolge einer dynamischen Streamlänge - bei meinem 92LED Setup werden hier anstelle von miniDMX 512 Nutzbyte nur noch 276 Nutzbyte in den Stream geschickt, damit werden bei gleichem Informationsgehalt nur ca 54% der Daten transportiert...

Ich bin damit noch am testen, das was wir bisher sehen sieht aber sehr gut aus.

Christian

Zitat von TheChief

Ich lass mich überraschen. Eventuell hab ich ja morgen die Hardware schon. Gibts eigentlich ein git oder ähnliches für das Plugin?

wir haben ein cvs bei uns im WAN, genauso wie für die anderen Plugins von Jörg