mikrocontroller.net

Forum: FPGA, VHDL & Co. Projekt ähnlich Ambilight von Philips


Autor: Schimmelhirn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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#... 
oder dem Elektor-Projekt 
http://www.elektor.de/jahrgang/2008/februar/tv-lig...

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

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum nicht einfach nur jedes vierte Pixel nehmen- Dann sinds nurnoch 
50Mhz. Da du eh n mittelwert bildest dürfte das nicht auffallen....

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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....

Autor: Schimmelhirn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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]

Autor: Schimmelhirn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  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

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Schimmelhirn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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!

Autor: Bartholomäus Steinmayr (sam_vdp)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Schimmelhirn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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???

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Mathi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Schimmelhirn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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...

Autor: Schimmelhirn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Bartholomäus Steinmayr (sam_vdp)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  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

Autor: Schimmelhirn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Schimmelhirn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Kest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: DVI (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ...

Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... 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.

Autor: Gerd ... (elektron68)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Andre S. (spiegelei)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Renne (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
was ist eigentlich daraus geworden?

Autor: philleb (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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... Greets.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.