|
Anzeige
|
HDMI Video aus FPGA
Gast
#5570736
Ist es möglich, mit einem FPGA direkt HDMI zu lesen und zu erzeugen, ohne einen Umwandler-Chip? Ich habe ein Entwicklungssystem mit einem Ausgang, würde fürs erste gerne auch einen Eingang haben, auf Dauer auch mehrere. Der Signalstandard scheint das Problem zu sein. Klar geht das. Du brauchst nur einen FPGA mit schnellen Outputs. Wenn es schnell gehen soll kannst du dir entsprechenden IP Core kaufen. Wenn du Zeit hast kannst den auch selbst entwickeln. :-) Moin, HDMI Ausgang wird schon noch leichter gehen, die Aufloesung/takt darf halt nicht zu hoch sein, wenn man nicht die speziellen SerDes Transceiver nehmen will/kann. Ansonsten braucht man gleich 4 Stueck von denen fuer ein HDMI Signal. Pegel/Impedanz kann man iirc irgendwie mit Koppel-Cs und Terminierungs-Rs halbwegs hinschummeln, wenns das FPGA nicht ootb kann. Bei einem HDMI Eingang wirds wohl hoechstens mit ziemlich kurzen Verbindungskabeln bei kleinen Aufloesungen gehen, oder man braucht eben einen extra Cable-Equalizer/Reclocker-Chip. Nach so ein paar Dezimetern HDMI-Kabel kommen keine "schoenen" Einsen und Nullen mehr an. Von so Sauereien wie HDCP will ich aber mal garnicht anfangen und auch Audio (de)Embedder sind bisschen mehr als 5 Flipflops und 3 Gatter. Gruss WK
Gast
#5571213
Ja, das geht. Allerdings je nach FPGA bisschen am Standard vorbeigeschrappt... Auf den Lattice ECP3 ist das mit den Serdes-Blöcken ganz gut zu machen, Output kaum ein Problem, Input etwas kniffliger, je nach Layout muss man sich um das Lane-Deskewing kümmern. Der Signalstandard ist gar nicht mal das Problem. TMDS bekommt man mit manchen FPGAs durchaus direkt erzeugt und auch "gelesen". Die Schwierigkeit sind eher die Leitungsreflektionen und das, was man sich so einfangen kann. Die HDMI-Verbindungen möchte man ja gerne steckbar haben, um Quellen zu tauschen und FPGA-Pins sind nicht so hot-plug-fähig. Daher benutzt man zumindest einen Buffer/Driver. Mit dem Digilent Atlys habe ich das schon gemacht. Dort ist allerdings das Problem, dass man mit den Ein/Ausgängen nicht auf die benötigte Taktfrequenz kommt. Dort geht nur 1080p30 oder 1080i60. HDMI Vollformat mit 60 frames oder TV mit 50Hz scheiden also aus. Machbar wäre das nur mit den GBT-Ports und eben sicherheitshalber den Buffern. Ich habe für zwei Anwendungen schon durchgerechnet, aber es ist im FPGA i.d.R. zu teuer. Das Silizum und so nötig die T-Versionen des Chips machen die Lösung pro Port um 5-10 Euro teuer und dafür kriegt man auch den externen Chip. Ist demonstriert und als Open Hardware veröffentlicht auf Basis eines Spartan-6. Sogar das ersetzen von Pixeln in HDCP encrypteten Links ist damit, auf legalem Weg, möglich: https://hackaday.com/2012/01/21/overlaying-video-on-encrypted-hdmi-connections/ In der Zwischenzeit gibt es einen Nachfolger der verwendeten Hardware. Gemäss Foto nutzen sie nun einen Artix-7: https://liliputing.com/2018/05/netv2-open-video-development-board-is-also-a-tool-in-a-legal-fight-against-drm-crowdfunding.html
Gast
#5573646
Christoph Z. schrieb: > Sogar das ersetzen von Pixeln in HDCP encrypteten Links ist > damit, auf legalem Weg, möglich: Na, ob das legal ist, sei mal dahin gestellt. Das Umgehen eines Schutzes kann auch strafbar sein und wie der Seite zu entnehmen ist, haben die ja auch eine Klage an der Backe. Fakt ist jedenfalls: Sobald Du die Videodaten im FPGA hast, ist ohnehin alles nöglich. Der Kopierschutz hält, wie in ähnlichen Fällen auch, nur die Privatanwender ab und nicht einmal das ist ja der Fall: In China gibt es schon responder-chips, welche die über I2C übermittelten Daten beantworten und emulieren, d.h. das HDCP-benutzende Gerät wird getäuscht und es bekommt vorgegaukelt, der Abspieler sei authentisch und lizensiert. Die responder kennen 40 einschlägige Schlüssel. Chips dieser Art werden auch schon in HDMI-Umschaltern verbaut, die in China auf dem Wochenmarkt vertickt werden. Andere arbeiten mit geklauten und recycleten oder duplizierten Decoder-Chips. Z.T. sind das sogar Geräte, die einige extra nach China imporitert haben, weil sie offiziell nicht an die Decoder-Chips gekommen sind, weil sie von der Lizensierungsgruppe nicht als "vertrauenswürdig" eingestuft wurden. Praktisch jeder zweite Videofreak hat so einen Verteiler daheim stehen und kann gucken, was er mag. Die Dinger kriegst du als Westler aber nicht so einfach in die Finger, weil die Händler Schiss haben, wegen der vielen Markenfälscherermittler, die sich auf den Märkten herumtreiben. Wenn du dort mit Langnasengesicht auftauchst, bekommst du einen Großteil deren Waren gar nicht zu Gesicht. Ein netter Arbeitskollege hilft da aber gerne weiter :-))) Man muss nur aufpassen, wenn man die in die EU importiert. Der Zoll kassiert die sofort ein, wenn er sie findet. Von HDCP versteht der Zoll zwar nichts, aber die Bundesnetzagentur fordert für alles, "was funkt", ein Zertifikat, was die ja nicht haben. Das gilt auch für viele andere nette Sachen, die man auf den Märkten und Elektroläden erstehen kann. Für die meisten Elektronikartikel aus dem Westen gibt es chinesische Kopien und Nachbauten, die z.T. genau so funktionieren, aber 1/10 kosten. Das geht von Videosystemen, Playstations, Stereoanlagen über Telefone hin zu Smartphones wie dem IPhone. Nachtrag: Selbverständlich bringe ich auf meinen Asienreisen nichts Illegales mit und verzolle auch immer anständig. :-) Andreas F. schrieb: > wie der Seite zu entnehmen ist, haben die ja > auch eine Klage an der Backe. Wo hast Du das gelesen? Ich lese da die haben eine Klage gegen das US-Justizministerium angestrengt. Das ist ja doch ein bißchen was anderes ... Christoph Z. schrieb: > Ist demonstriert und als Open Hardware veröffentlicht auf Basis eines > Spartan-6. Aber nicht für 1080p60. Der kann nur interlaced, also 1080i60 oder eben 1080p30. Für eine sinnvolle Verwendung als TV brauchst du wenigstens 50fps. Monitore arbeiten mit 60 oder 59.94. Ansonsten ginge nur HD in 720. Jürgen S. schrieb: > Aber nicht für 1080p60. Der kann nur interlaced, also 1080i60 oder eben > 1080p30. Prinzipiell ist es überhaupt kein Problem mit dem Spartan 6 1080p@60Hz zu empfangen, zu verarbeiten und auch wieder auszugeben. Oder beziehst du das auf das oben genannte HDCP Projekt? Moin, Tobias B. schrieb: > Prinzipiell ist es überhaupt kein Problem mit dem Spartan 6 1080p@60Hz > zu empfangen, zu verarbeiten und auch wieder auszugeben. sagt Radio Eriwan. Klar gehts prinzipiell. Aber ich hab' da eine Pixelclock von 148.5MHz, d.h. eine TMDS Bitclk von 1.485 GHz. Damit bin ich fuer IOSERDES auf den normal sterblichen IOs zu schnell. Also brauch' ich schonmal einen Spartan6 "T", und von den "T"ransceivern brauch ich gleich mal 4 (oder vielleicht nur 3, wenn ich arg auf Schmerzen steh' - vielleicht geht die Clock ueber ein normales LVDS IO Paerchen rein, aber wie das dann jemals synchron werden soll... Und dann sind die GTPs nun auch nicht grad' fuer TMDS gemacht,d.h. da muss dann sicherlich noch einiges an Symbolerkennung/Synchronisation/Decodierung selbergebastelt werden. Gruss WK Wenn man unbedingt User I/Os nehmen muss, würde ich auch empfehlen einen entsprechenden Chip zu nehmen der die Daten parallelisiert, bzw. serialisiert. Mit GTPs reicht die Bandbreite dicke aus. Mir ging es um die Aussage, dass das verlinkte HDCP Projekt auf einem Spartan 6 nicht mit FullHD bei 60 Hz nicht funktionieren soll. Prinzipiell spricht da nix dagegen, man muss sich halt beim Rein- und Raustakten der Daten Gedanken machen, aber das ist meiner Meinung nach wirklich das kleinste Problem. Edit: Ich merke gerade, dass mein Quatsch vollkommen am Thema vorbei geht. :-( Gedanklich war ich in diesem Thema: Beitrag "Video mit AC701"
Gast
#5578568
Tobias B. schrieb: >Mir ging es um die Aussage, dass das verlinkte HDCP Projekt auf einem >Spartan 6 nicht mit FullHD bei 60 Hz nicht funktionieren soll. Auf der dort beschriebenen Seite mit dem link zum TV-board steht es sogar explizit, dass das limit 1080i60 ist. > Gedanklich war ich in diesem Thema: > Beitrag "Video mit AC701" Der einen Chip drauf. Dergute W. schrieb: > Aber ich hab' da eine Pixelclock von 148.5MHz, d.h. eine TMDS Bitclk von > 1.485 GHz. Damit bin ich fuer IOSERDES auf den normal sterblichen IOs zu > schnell. Also brauch' ich schonmal einen Spartan6 "T", und von den > "T"ransceivern brauch ich gleich mal 4 (oder vielleicht nur 3, wenn ich > arg auf Schmerzen steh' Genau so ist es und wie ich weiter oben schon angedeutet hatte, habe ich genau die Thematik schon durchexerziert: Es lohnte sich beim S6 schon aus Kostengründen nicht, weil die T-Versionen in etwa das mehr kosten, was der Transceiver kostet. Der Vorteil wäre nur Platz und Pins. Mit den GTP wiederum geht es, jedoch direkt deshalb nicht, weil es mit den Reflektionen und Pegeln nicht hinhaut, jedenfalls nicht, wenn man über Distanzen gehen möchte, die zwischen Platinen und Gehäusewänden auftreten. Da braucht es eine entsprechende Terminierung zu den Pins und das ergibt unschöne Reflektionen oder miese Pegel. Ohne einen Buffer ist da nichts zu holen und der wiederum braucht Platz, kostet Geld und Chipfläche. Wenn man nur ein paar Farben darstellen möchte kriegt man leicht so eine Laborversion hin, wie sie kommuniziert wird. Auch HDCP direkt aus dem Signal auszudekodieren, um es zu ändern, zu bedienen, zu löschen, zu emulieren oder eben zu umgehen ist dann kein Problem. Wenn man aber das komplette Timing neu erzeugen muss und es nicht vom Eingang bekommt, dann darf man schon etwas an Fläche investieren. Taktadaption und -rekonstruktion, IO-matching sind dann gefragt, die im Chip miterledigt werden. Will man dann noch S/PDIF einfügen und das noch 8 kanalig, ist das dann richtig flächenfressend. Habe das Ganze fürs Nexys Video im Gebrauch. Beim Artix geht das schon einfacher ist aber trotzdem nicht die Gold-Lösung. Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
