Hallo zusammen, bezüglich FPGA's hab ich nicht wirklich den großen Durchblick und bevor ich viel Geld und noch mehr Arbeit in eine Entwicklungsumgebung stecke, würde ich gerne wissen, ob sich folgendes überhaupt mit einem Low-Cost FPGA realisieren läßt. Ich möchte mir ein Ambilight nachbauen - ähnlich dem Atmolight-Projekt für den LinuxVDR http://www.vdr-wiki.de/wiki/index.php/Atmo-plugin#Selbstgebaute_LED-Module oder dem Elektor-Projekt http://www.elektor.de/jahrgang/2008/februar/tv-light.349909.lynkx Leider entsprechen beide nicht unbedingt dem was ich gerne hätte und deswegen kam mir der Gedanke selbst so ein Projekt auf die Beine zu stellen. System ist ein HTPC (Windows XP) mit HDTV Display (1080p) Die mittleren Farbwerte im oberen, linken und rechten Bildschirmbereich werden ermittelt und LED's entsprechend der ermittelten Farbe angesteuert werden. Das Problem ist: Wie komme ich an die Farbinformation? 1. Ansatz: Programmieren in C und die Werte über die USB-Schnittstelle an einen µC der die LED Ansteuerung übernimmt Vorteil: Sehr günstig, Nachteil: CPU des HTPC wird belastet, Verfluchte WinAPI Programmierung. Evtl. sogar zu langsam 2. Ansatz: wie in der Elektor: Analoges RGB Signal abgreifen über nen ADC auf nen µC und dann wieder LED-Ansteuerung. Dieser Ansatz gefällt mir am wenigsten, habe ihn deshalb auch noch nicht weiter verfolgt. 3. Ansatz: Deswegen hab ich den ganzen Text hier überhaupt geschrieben ;)) Die digitalen DVI-Signale vom zweiten GraKa-Ausgang (Clone) werden von nem FPGA eingelesen, gefiltert und Mittelwert gebildet. Die LED-Ansteuerung wird dann direkt vom FPGA oder von einem µC vorgenommen. Das Problem hier ist, dass bei einer Auflösung von 1920 x 1080 der DVI-Takt zwischen 200 und 225 MHz liegt (3 paralle Datenleitungen). Ich denke dass ist schon ne Menge Holz für einen Standard FPGA. Was denkt ihr? Läßt sich sowas mit einem FPGA der Klasse XC3Sxxx realisieren? Nicht dass ich diese hohe Auflösung für das Ambilight bräuchte, für dominate Farben erkennen und paar Filter würden mir auch wesentlich weniger Pixel reichen, aber leider krieg ich die Bilder nur in der dicken Auflösung geliefert. Wenn da jemand nen Tip hat, wie ich die Auflösung für den FPGA reduziere, immer her damit. Bei 640 x 480 liegt das DVI-Signal nur noch mit 25MHz an. Hoffe ich habe mich einigermaßen verständlich ausgedrückt. Danke schon mal für die rege Teilnahme ;) Schimmelhirn
Warum nicht einfach nur jedes vierte Pixel nehmen- Dann sinds nurnoch 50Mhz. Da du eh n mittelwert bildest dürfte das nicht auffallen....
Das mit deinem Takt stimmt glaub ich nicht ganz. Bei 1920x1080/60Hz hast du ja einen Pixeltakt von >= 120MHz. Dabei sinds aber noch 24 Leitungen (24Bit pro Pixel). Wieviel an Blanking hinzukommt weiß ich allerdings nicht. Aber diese Taktrate sollte mit nem FPGA durchaus zu machen sein. Wenn du wirklich nur 3 Leitungen (serialisiertes R,G,B) dann liegt der Takt im GHz Bereich, da hast du keine Chance. Noch 2 Probleme: Wenn das Signal HDCP verschlüsselt ist, wirds nichts. Das ganze auf eine einzige Auflösung zu optimieren stell ich mir nicht so schwer vor, da man diese Timingparameter exakt im FPGA nachbauen kann. Für unterschiedliche Auflösungen und Bildwiederholraten stell ich mir das aber schon schwer vor.
Hab mir grad mal DVI angesehen- das ist ja seriell- du brauchst also auf jeden fall MGT's. Also Virtex2P Virtex4 Virtex5. Für den Aufwand kannst dir auch den größten mit Aurea kaufen....
Ich hab mir die Spec von DVI schon angesehen. Bei der maximal möglichen Auflösung (etwas mehr als 1920 x 1080) liegt der Takt bei 225MHz. Die drei Farben werden je über eine separates differentielles Signal seriell übertragen. Teilweise ist das Signal HDCP verschlüsselt, ich dachte aber das der HTPC das encodieren übernimmt und ein unverschlüsseltes Signal an den TV sendet... Ich hab auch schon daran gedacht, nur jedes vierte oder achte Pixel zu nehmen, aber wie bekomme ich dann die Pixelposition heraus? ich möchte ja 3 Mittelwerte in drei unterschiedlichen Bildschirmbereichen errechnen...
>Bei der maximal möglichen Auflösung (etwas mehr als 1920 x 1080) liegt >der Takt bei 225MHz Nein Die Daten werden seriell übertragen: [Wikipedia] Eine Single-Link-Verbindung überträgt maximal 3,7 Gbit/s. Bei 24 bit pro Pixel entspricht dies 165 MegaPixel/s [/wikipedia]
hmm, was hab ich denn dann gestern Nacht gelesen? - ich kann jetzt auch nix mehr zu den 225MHz finden... naja war spät gestern ;) - dann Dank ich mal für den Hinweis Wenns nur 165MHz sind, umso besser... Sind so schon mehr als genug Daten...
@ Schimmelhirn (Gast) >Wenns nur 165MHz sind, umso besser... Sind so schon mehr als genug >Daten... Was soll denn der Unsinn mit dem Umweg über DVI/VGA? Um ein paar LEDs anzusteuern braucht man nur einen kleinen uC mit bissel PWM. Die Daten bekommt man problemlos per USB übertragen (FTDI232). Du machst dir Sorgen über die Belastung eines PCs mit Windows XP, der ein paar Bytes über USB schicken soll? Sehr lustig ;-) Das fällt dreimal unter ferner liefen. MfG Falk
Die Daten kommen mit 3,7Gbit/s- das kann nur der V5 V2P,V4 können nur bis 3,625Gbit/s Ein V2P kostet als Einzelstück ca 500€ Vom Layout mal ganz abgesehen.... Nimm das Analogsignal und werte das aus- ist viiiiiel einfacher...
@Falk, Sicher, die Daten bekomm ich locker übertragen, das Problem ist: Wie komm ich an die Daten? Um die Pixelwerte des Desktop in C/C++ auszulesen brauchts 1.Ahnung von WinAPI Programmierung, 2. bin ich nicht sicher ob es auch mit optimierten Code schnell genug geht. Wenn, wird es sehr eng. Ich muss ja alle spätestens alle 40ms neue Daten an den µC senden. Bei normalem SD-TV kann das auch noch gut funktionieren, aber mit HDTV (HDCP) kommen auch die aktuellen CPU-Monster leicht ins schwitzen. Btw - ich hab dann auch nochmal was zu HDCP gelesen: HDCP verschlüsselte Inhalte kann ich weder analog (wird einfach abgeschaltet) noch digital auslesen. Damit bleibt eigentlich nur noch Ansatz 1. Trotzdem Danke für die Hinweise!
> Ahnung von WinAPI Programmierung Ich bin mir ziemlich sicher, ein bisschen WinAPI zu lernen ist nen Faktor 10 schneller, als sich "mal eben" in FPGA Entwicklung einzuarbeiten und nen 165 Mhz Digitalsignal zu verwursten. > bin ich nicht sicher ob es auch mit optimierten Code schnell genug geht Wieso soll es das nicht? Die Latenz von USB von Host zu Client sollte sehr klein sein und den Mittelwert von ein paar Pixeln zu bilden wird deine CPU auch nicht eben überfordern. Das HDCP Problem stellt sich allerdings weiterhin, weil ein legaler Decoder dich nicht auf die digitalen Daten zugreifen lassen wird.
@ Schimmelhirn (Gast) >Sicher, die Daten bekomm ich locker übertragen, das Problem ist: Wie >komm ich an die Daten? Von nix ist nix. Schau mal hier. http://www.madrix.de/ Was die Software kostet weiss ich nicht. Einen DMX-Empfänger zu bauen ist aber recht einfach. >Um die Pixelwerte des Desktop in C/C++ auszulesen brauchts 1.Ahnung von >WinAPI Programmierung, Kochkurs an der VHS bringt dich dem Ziel auch nicht näher ;-) > 2. bin ich nicht sicher ob es auch mit >optimierten Code schnell genug geht. Wenn, wird es sehr eng. Ich muss ja >alle spätestens alle 40ms neue Daten an den µC senden. Hallo? Hast du überhaupt ANSATZWEISE Ahnung wovon du da redest? 40ms sind für einen PC eine EWIGKEIT! Vielleicht kaufst du dir doch besser ein Ambilight im Laden. >Bei normalem SD-TV kann das auch noch gut funktionieren, aber mit HDTV >(HDCP) kommen auch die aktuellen CPU-Monster leicht ins schwitzen. Und wozu HDTV wenn du sowieso nut eine Handvoll Pixel auswertest? Leute gibts . . . MFG Falk
>Hallo? Hast du überhaupt ANSATZWEISE Ahnung wovon du da redest? 40ms >sind für einen PC eine EWIGKEIT! >Vielleicht kaufst du dir doch besser ein Ambilight im Laden. Hörst du nicht zu oder magst du nur nicht? Die Auswertung der Pixeldaten im PC dauert so lang. da sind 40ms für die Auswertung eines 1980x1200 seeehr flott. Windows bremst hier erheblich. Wenn du Schlauberger nen Codeschnipsel über hast, mit dem innerhalb von 40ms NUR die Pixeldaten von drei 320x240 Bildschirmausschnitten ausgelesen werden (noch ohne Bildverarbeitung), sollte ich mir das Ambilight vllt. wirklich im Laden kaufen. Ansonsten lass solche Kommentare bitte. >Und wozu HDTV wenn du sowieso nut eine Handvoll Pixel auswertest? >Leute gibts . Danke. Weil ich nunmal HDTV schaue und die Pixel deshalb NUR ALS 1920x1080 vorliegen. Oder wie soll ich deiner Meinung nach ein Downscaling machen? >Kochkurs an der VHS bringt dich dem Ziel auch nicht näher ;-) Aber Spass machen tuts. Die Sache mit dem FPGA zu realiseren wäre ja auch ne Sache gewesen die Spass machen könnte?? >> Ahnung von WinAPI Programmierung >Ich bin mir ziemlich sicher, ein bisschen WinAPI zu lernen ist nen >Faktor 10 schneller, als sich "mal eben" in FPGA Entwicklung >einzuarbeiten und nen 165 Mhz Digitalsignal zu verwursten. FPGA Entwicklung hätte aber Faktor 100 mehr Spass gemacht als WinAPI. Wieso sollte mir ein 165MHz Digitalsignal Angst machen? Wenn es Spass macht dann kann man doch auch mal den umständlichen Weg wählen? >> bin ich nicht sicher ob es auch mit optimierten Code schnell genug geht >Wieso soll es das nicht? Die Latenz von USB von Host zu Client sollte >sehr klein sein und den Mittelwert von ein paar Pixeln zu bilden wird >deine CPU auch nicht eben überfordern. Zwar nicht die CPU aber Windows. Deswegen mach ich mir doch Gedanken über eine Alternativlösung mittels FPGA. Glaubt ihr ernsthaft ich hätte darüber noch nicht nachgedacht???
@ Schimmelhirn (Gast) >Hörst du nicht zu oder magst du nur nicht? Die Auswertung der Pixeldaten >im PC dauert so lang. Wie programmierst du ? GWBAsic 1.0 auf nem 8086? Ach nee, war ja ne WinXP Kiste. > da sind 40ms für die Auswertung eines 1980x1200 >seeehr flott. Bitte? Eine 2 GHz CPU + dicke Grafikarte (selbst die Onboard Dinger haben heut schon einiges zu bieten) machen das in 10ms, wenns schlecht programmiert ist. > Windows bremst hier erheblich. Was wäre die Welt ohne faule Ausreden ;-) > Wenn du Schlauberger nen >Codeschnipsel über hast, mit dem innerhalb von 40ms NUR die Pixeldaten >von drei 320x240 Bildschirmausschnitten ausgelesen werden (noch ohne >Bildverarbeitung), sollte ich mir das Ambilight vllt. wirklich im Laden >kaufen. Tu das. Der Hinweis war Ernst gemeint. > Ansonsten lass solche Kommentare bitte. Nö. >Danke. Weil ich nunmal HDTV schaue und die Pixel deshalb NUR ALS >1920x1080 vorliegen. Oder wie soll ich deiner Meinung nach ein >Downscaling machen? Ohje. Logischerweise muss eine gescheite Software(tm) möglichst direkt auf die komprimierten MPEG/whatever Daten zugreifen, damit daraus direkt die handvoll Pixel für das Ambilight berechnet werden kann. Aus den 1920x1080 wieder runterrechenen ist Sülze. >Aber Spass machen tuts. Die Sache mit dem FPGA zu realiseren wäre ja >auch ne Sache gewesen die Spass machen könnte?? Aber nicht ohne minimale Grundlagen. Da hab ich bei dir so einige Zweifel. >Wieso sollte mir ein 165MHz Digitalsignal Angst machen? Nur Kinder und Naive sagen sowas. >Wenn es Spass macht dann kann man doch auch mal den umständlichen Weg >wählen? Man kann auch von Berlin über Tokio nach München fahren. Alles machbar. >>deine CPU auch nicht eben überfordern. >Zwar nicht die CPU aber Windows. Deswegen mach ich mir doch Gedanken >über eine Alternativlösung mittels FPGA. Glaubt ihr ernsthaft ich hätte >darüber noch nicht nachgedacht??? Naja . . . Als brauchbare Hardwarealternative würde ich es sehen, wenn man auf seiner Grafikkarte parallel zum DVI/HDTV ein normales VGA-Signal ausgibt. Das kann man relativ leicht per uC oder FPGA soweit analysieren, als dass man eine 8x8 Matrix oder so ansteuern kann. Ist zwar auch wieder viel Aufwand, den man mit gescheiter Dekodersoftware nicht hätte, wäre aber IMO noch passabel. HDTV ist vollkommener Overkill. MFG Falk
@Schimmelhirn: Das ist ganz gut machbar. Ich kenne etwas ähnliches was im industriellen Umfeld zur Bildanalyse von DVI-Signal eingesetzt wird. Und das wesentlich Komplexer als Du es machen willst. Was Du brauchst ist ein DVI-Receiver. Sowas gibt es z.B. von Crontel oder Silicon Image. Die Bildanalyse in dem Gerät macht ein Lattice-Baustein. Ein ECP. Also kein High-End Modell. Kosten als einzelnes Exemplar bei Lattice nichtmal 100$. Vielleicht wäre das was für Dein Projekt.
>Als brauchbare Hardwarealternative würde ich es sehen, wenn man auf >seiner Grafikkarte parallel zum DVI/HDTV ein normales VGA-Signal >ausgibt. Das kann man relativ leicht per uC oder FPGA soweit >analysieren, als dass man eine 8x8 Matrix oder so ansteuern kann. Ist >zwar auch wieder viel Aufwand, den man mit gescheiter Dekodersoftware >nicht hätte, wäre aber IMO noch passabel. HDTV ist vollkommener >verkill. Super Idee! Nur geht das nicht. Desktop klonen mit unterschiedlichen Auflösung funktioniert unter Windows nicht. Punkt. >>Hörst du nicht zu oder magst du nur nicht? Die Auswertung der Pixeldaten >>im PC dauert so lang. >Wie programmierst du ? GWBAsic 1.0 auf nem 8086? Ach nee, war ja ne >WinXP Kiste. >> da sind 40ms für die Auswertung eines 1980x1200 >>seeehr flott. >Bitte? Eine 2 GHz CPU + dicke Grafikarte (selbst die Onboard Dinger >haben heut schon einiges zu bieten) machen das in 10ms, wenns schlecht >programmiert ist. >> Windows bremst hier erheblich. >Was wäre die Welt ohne faule Ausreden ;-) >> Wenn du Schlauberger nen >>Codeschnipsel über hast, mit dem innerhalb von 40ms NUR die Pixeldaten >>von drei 320x240 Bildschirmausschnitten ausgelesen werden (noch ohne >>Bildverarbeitung), sollte ich mir das Ambilight vllt. wirklich im Laden >>kaufen. >Tu das. Der Hinweis war Ernst gemeint. >> Ansonsten lass solche Kommentare bitte. >Nö. Mehr als schlaue Sprüche ohne Hintergrundwissen kann ich hier nicht erkennen. >Ohje. Logischerweise muss eine gescheite Software(tm) möglichst direkt >auf die komprimierten MPEG/whatever Daten zugreifen, damit daraus direkt >die handvoll Pixel für das Ambilight berechnet werden kann. Aus den >1920x1080 wieder runterrechenen ist Sülze. Na du bist ja der Guru schlechthin. Und wie soll ich an die Daten rankommen? Wie es theoretisch am besten funtioniert kann ich hier auch groß rumerzählen... Man kann unter Windows nicht auf den Videospeicher direkt zugreifen. Es gibt in der WinAPI die eine oder andere Funtkion (getPixel, BitBlt) mit der man die Pixelwerte des Desktops auslesen kann, ist halt leider nicht sehr fix. Über DirectX muss ich mich noch entsprechend schlau machen. vllt. geht da noch was. >>Aber Spass machen tuts. Die Sache mit dem FPGA zu realiseren wäre ja >>auch ne Sache gewesen die Spass machen könnte?? > >Aber nicht ohne minimale Grundlagen. Da hab ich bei dir so einige >Zweifel. wie kommst du drauf dass ich keine minimalen Grundlagen hätte? Weil ich gefragt habe ob sowas mit einem FPGA realisiert werden kann? Du bist etwas überheblich wie ich finde. >>Wieso sollte mir ein 165MHz Digitalsignal Angst machen? > >Nur Kinder und Naive sagen sowas. ahso, der HF-Crack hat gesprochen. Ein FPGA-Anfänger hat selbstverständlich null Schimmer von HF und EMV. Entschuldige bitte meine Naivität...
>Das ist ganz gut machbar. Ich kenne etwas ähnliches was im industriellen >Umfeld zur Bildanalyse von DVI-Signal eingesetzt wird. Und das >wesentlich Komplexer als Du es machen willst. Was Du brauchst ist ein >DVI-Receiver. Sowas gibt es z.B. von Crontel oder Silicon Image. Die >Bildanalyse in dem Gerät macht ein Lattice-Baustein. Ein ECP. Also kein >High-End Modell. Kosten als einzelnes Exemplar bei Lattice nichtmal >100$. Danke für den konstruktiven Vorschlag. Werde mich diesbzüglich mal schlaumachen.
Das auslesen der Daten unter Windows hängt ja schon allein sehr stark davon ab, was du für einen Videorenderer verwendest (schonmal nen Screenshot von nem Overlay gemacht? Ist nur schwarz drauf...). Und wie gesagt: Spätestens wenn du mal Video's mit HDCP anschauen willst, ist sowieso Schluss. Wenn du andere Quellen hast, wäre eine elegante Möglichkeit, eine FFDShow Erweiterung zu bauen. Da sind bereits diverse Filter drin, es sollte also nicht so schwer sein, einen eigenen hinzuzubauen. Aber nachdem du ja sogar mehr Ahnung hast als Falk, was erzähl' ich dir eigentlich ;) Beste Grüße, Bartl
@ Schimmelhirn (Gast) >Super Idee! Nur geht das nicht. Desktop klonen mit unterschiedlichen >Auflösung funktioniert unter Windows nicht. Punkt. Pech. >Mehr als schlaue Sprüche ohne Hintergrundwissen kann ich hier nicht >erkennen. Der blinde sollte nicht über die Farbe urteilen. >Na du bist ja der Guru schlechthin. Und wie soll ich an die Daten >rankommen? Wie bereits gesagt, dass müsst die Software zur Videowoedergabe direkt eingebaut bekommen. Schon klar, das ist alles andere als trivial. >direkt zugreifen. Es gibt in der WinAPI die eine oder andere Funtkion >(getPixel, BitBlt) mit der man die Pixelwerte des Desktops auslesen >kann, ist halt leider nicht sehr fix. Das ist fast so unsinnig wie die HDTV Dekodierung in Hardware. >wie kommst du drauf dass ich keine minimalen Grundlagen hätte? Weil ich Deine Sprache verrät dich. >gefragt habe ob sowas mit einem FPGA realisiert werden kann? Du bist >etwas überheblich wie ich finde. Warum? Weil ich deinen Wissenstand als eher niedrig einschätze? Bist wohl nicht sehr kritikfähig? >ahso, der HF-Crack hat gesprochen. Ein FPGA-Anfänger hat >selbstverständlich null Schimmer von HF und EMV. Entschuldige bitte >meine Naivität... Damit untermauerst du meine Aussage. Vielen Dank. MFG Falk
>Das auslesen der Daten unter Windows hängt ja schon allein sehr stark >davon ab, was du für einen Videorenderer verwendest (schonmal nen >Screenshot von nem Overlay gemacht? Ist nur schwarz drauf...). >Und wie gesagt: Spätestens wenn du mal Video's mit HDCP anschauen >willst, ist sowieso Schluss. >Wenn du andere Quellen hast, wäre eine elegante Möglichkeit, eine >FFDShow Erweiterung zu bauen. Da sind bereits diverse Filter drin, es <sollte also nicht so schwer sein, einen eigenen hinzuzubauen. Mit ffdshow hab ich mich noch nicht auseinander gesetzt. Wird nachgeholt. Danke für den Hinweis. >Aber nachdem du ja sogar mehr Ahnung hast als Falk, was erzähl' ich dir <eigentlich ;) darum gings gar nicht. Ich kann Überheblichkeit aber nur bis zu einem bestimmten Punkt ertragen.
Also ich kommentiere nun zum letzten mal. Und das ist gut so. >>gefragt habe ob sowas mit einem FPGA realisiert werden kann? Du bist >>etwas überheblich wie ich finde. > >Warum? Weil ich deinen Wissenstand als eher niedrig einschätze? Bist >wohl nicht sehr kritikfähig? Das hat weniger mit meiner Kritikfähigkeit zu tun, als mit deinem Ton. >>wie kommst du drauf dass ich keine minimalen Grundlagen hätte? Weil ich >Deine Sprache verrät dich. Und das Fehlen welcher Grundlagen meinst du erkannt zu haben? Was muss man denn deiner Meinung nach mitbringen um mit der FPGA-Entwicklung beginnen zu dürfen? Sind hier in dem Forum Anfänger einfach nicht erwünscht, oder warum muss man sich hier für seine Gedankenexperimente rechtfertigen?
Ich sage zwar nichts Neues, aber mit Softwarelösung fährst Du auf jeden Fall besser und flexibler. Ich weiß ja nicht, welche Software Du verwendest, aber diverse Player (VLC, ...) haben Plug Ins, die man auch selber programmieren kann. Und ich vermute, dass es nicht schwerer ist, als FPGA programmieren. Nur als Idee: den gesammten Frame (1080p) brauchst Du gar nicht zu prozessieren -- nur Randbereiche (vermute ich, da ich Ambilight nur aus Werbung kenne) und da muss die Rechenkraft eines modernen Prozessors locker ausreichen. Zur Lösung mit einem FPGA: klar ist es machbar. Mit einem DVI Receiver ist es problemlos möglich. Die Daten zu verarbeiten ist eigentlich auch nicht soo kompliziert, nur als Anfänger würde ich mich da nicht trauen was anzufangen. Dazu kommt noch Layout der Platine, falls Du eine selber machen möchtest... Ja, ein Spartan neuerer Generation reicht vollkommen aus. Ich habe selber viel mit HD zu tun und mit dem Prozessing im FPGA und sage Dir schon jetzt, dass es nicht einfach ist. Ich möchte Dir auch keine Angst machen, bedenk aber alle Aspekte sehr genau (wer weiß, wie viele Clocks man später braucht, ein Takt ist um -30 Grad und der andere um +145 Grad geschoben, dann kommt noch SRAM / SDRAM hizu...) NAch einer Weile wirst Du den Tag verfluchen, als Du Dich dafür entschieden hast statt einer fertigen Lösung ;-)) Solltest Du Hilfe brauchen, hier wird Dir sicherlich geholfen :-) Viel Spaß, Grüße, Kest
Hallo, habe mich auch mal mit den eingangs erwähnten Ambilight-Ansätzen auseinandergesetzt. Grundsätzlich stört mich aber an allen Bauvorschlägen, dass man nicht gemütlich im Wohnzimmer sitzen kann und wie beim 'Original' eine normale (verschlüsselte) HD-DVD schauen kann. Bei den genannten Lösungen hockt man entweder auf einem unbequemen Stuhl vor dem PC-Monitor im Arbeitszimmer oder man kann nur analoges (unverschlüsseltes) PAL-Material auf dem Sofa im Wohnzimmer betrachten. Gibt es nicht die Möglichkeit die nötigen Farbinformationen direkt an der Panel-Ansteuerung des TFT-Monitors bzw. des Flat-TV abzugreifen?. Die Datenrate dürfte doch dort geringer sein, da der ganze Verschlüsselungs- Overhead der DVI bzw. HDMI-Schnittstelle fehlt und die tatsächliche Bildwiederholungsrate bei den trägen TFTs doch eher gering ist. Gibt es eigendlich einen Standard, wie die Panels angesteuert werden bzw. wo findet man Infos darüber? Bei der guten alten Analog-Glotze hätte man ja einfach die RGB-Ansteuerung an der Röhre anzapfen können, ohne irgendwelche evt. vorhandene Eingangssignale zu beachten und umständlich zerlegen zu müssen, die Schaltung hätte dann immer das genommen was man sieht ... und so sollte es doch eigendlich auch sein :-). Grüße Frank
Gab es da nicht mal Ansätze von M$ die Daten von der DVD bis zum analogen Lichtsignal zu verschlüsseln ? Nur mal so ... Nimm dir einen RGB Sensor und schau was der so im Fernsehen sieht. Den RGB-Wert schmeisst du dann halt hinter deinen Fernseher ...
... an Sensoren habe ich auch schon gedacht oder ein billiges Kameramodul mit interner RGB-Verarbeitung, was den Bildschirm film ... jedoch hat man hier den Nachteil, daß die Sache nur bei Dunkelheit im Raum funktioniert, da man ja sonst das Umgebungslicht und nicht das Fernsehbild analysiert. Die Frage ist auch wie man dieses Meßequipment plazieren soll, ohne das es einem vor/im Bild hängt ... nee, ist auch keine wirkliche Lösung.
Verschlüsselte Filme sind mit einem Nachrüstgerät schwierig auszuwerten. Es müßte ins HDMI-Signal eingeschleift werden, den Schlüssel mit der Quelle aushandeln es entschlüsseln für die Ambilightinformationen und dann wieder verschlüsseln (oder auch unverschlüsselt) an das TV-Gerät weitergeben. Bei DVI (unverschlüsselt) wäre das deutlich einfacher. Ich habe mir das TVdelight gekauft. www.umic.eu -> Produkte -> TVBL Es kann RGB,sVideo und FBas und wird einfach ins Scart-Signal eingeschleift. Wenn der TV die HDMI-Signale analog auf dem Scart raus gibt geht es auch mit HDMI. Es arbeitet mit 4 unabhängigen LED-Streifen. Die Wellenlänge der LEDs kann sogar per Windossoftware über USB an die Farben des TV angepasst werden. Somit stimmen dann die Farben genau überein. (Phosporabgleich, Gamma- und Helligkeitskorrektur)
Hallo ich versteh nich warum ihr es euch alles so umständlich macht. ich habe mir vor kurzem ein Ambilight bestellt (Kommpletttes Paket) und ich kann mich über nix beschweren ist echt gut. Kannst ja mal nachschauen vielleicht überzeugt es dich genau wie mich. www.arfx.de
Es geht ja hier wie fast immer um den Bastelspaß und eine möglichst universelle Lösung. ARFX ist sicher gut, kostet aber eine Menge und kann nicht mit jedem Video-Renderer benutzt werden. Overlay z.B. geht nicht, und der macht bei meinem DVB Viewer aber das beste Bild.
Ich hab mir ehrlich nicht den kompletten Thread durchgelesen, aber vor einiger Zeit habe ich schon eine Eigene Ambilight realisation gesehen: http://fun3md.blogspot.com/2009/07/atmolight-clone-project.html Greets.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.