Hallo, ich möchte gerne ein aus einem HDMI Datenstrom (kein HDCP!) die Audiosamples extrahieren. Am besten wäre eine Anbindung an I2S. Gibt es sowas? Ich habe im Moment nur etwas von Analog Devices gefunden (ADV7623 http://www.analog.com/en/audiovideo-products/analoghdmidvi-interfaces/adv7623/products/product.html) scheint aber als Privatperson nicht zu bekommen sein. Im Prinzip möchte ich so etwas wie einen AV-Receiver bauen. Das Projekt soll folgende Features besitzen: - Umschalten zwischen verschiedenen HDMI Quellen - Overlay Menüs? - Audiodaten sollen mit Hilfe der digitalen Signalverarbeitung bearbeitet werden können (DSP) - Bearbeitete Audiodaten sollen an den Audioverstärker weiter gereicht werden und brauchen nicht mehr beim HDMI Gerät ankommen Kann man so etwas überhaupt selbst bauen? Oder sollte ich auf http://www.allaboutadapters.com/hddodtsdihdo.html zurück greifen und einen HDMI Switch dazu nehmen?
Alle Chips mit HDMI sind für Normalos nicht wirklich gut erhältlich, weil die eigentlich immer nur mit dem HDPC-Key zusammen gekauft werden können... Ebay 371022087769 wäre als Bastelbasis wohl ganz gut. Entweder hat das Ding einen Extra SPDIF-Konverter (und damit I2S) oder man klebt einen SPDIF-Reciever dahinter...
Mir fällt spontan folgende Appnote ein: http://www.xilinx.com/support/documentation/application_notes/xapp495_S6TMDS_Video_Interface.pdf Wobei das wohl sinnvollerweise mit einem Abschied von I2S einhergeht, und man gleich alles im FPGA macht.
Das hier könnte interessant sein: http://hackaday.com/2014/01/25/reverse-engineering-an-hdmi-extender/ Dann aus dem Stream die benötigten Daten grabben.
http://www.analog.com/en/audiovideo-products/video-decoders/adv7441a/products/product.html der ist ohne HDCP und auf einigen Grabbern Namens SC500N1 verbaut.
Danke für die vielen Tipps. Ich glaube die Lösung von Moritz A. passt am besten zu meiner Projektidee, weil man mit den Xilinx FPGAs die TMDS Signale direkt verarbeiten kann. Ich habe auch schon ein Board gefunden: http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,400,1198&Prod=ZYBO ist ein SoC mit FPGA und ARM CPU. Leider finde ich keine Information ob man damit auch 1080p verarbeiten kann. Im Manual steht nur etwas von "Resolutions up to 720p (1280x720) have been tested." (http://www.digilentinc.com/Data/Products/ZYBO/ZYBO_RM_B_V5.pdf auf S.16) Kann mir da jemand weiterhelfen? Ich hatte noch ein anderes Board gefunden: http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,400,836&Prod=ATLYS Damit soll man wohl keine 1080p verarbeiten können. Leider findet man im Internet nicht sehr viel über dieses Thema. :-( 720p soll wohl damit gehen: http://www.instructables.com/id/Quick-Start-Test-Demo-Zybo-Xlinx-Zynq-7000-Image-F/?ALLSTEPS D.h. ich könnte mindestens 1080i verabreiten oder?
Es ist abhängig vom Speedgrade des FPGAs. Wenn ich von einem Spartan6 ausgehe, dann ist 1080p nur mit dem schnellsten, also den 3er, möglich. 1080p hat eine Pixel Clock von 108 MHz. Bei 10 Bit/Pixel sind das 1080 MBit/s pro TMDS Lane und das ist auch das Limit der IOs des Spartan6 Speedgrade 3. Intern hast du mit 108 MHz natürlich kein Problem. Du kannst natürlich auch Transceiver verwendet. Die gehen vom Spartan 6 bis zu 3.2 Gbit/s. Wobei hier das Design anspruchvoller wird, sofern man keine Erfahrung mit GTPs hat. Grüße
lulu schrieb: > Es ist abhängig vom Speedgrade des FPGAs. Wenn ich von einem Spartan6 > ausgehe, dann ist 1080p nur mit dem schnellsten, also den 3er, möglich. Xilinx sagt etwas anderes (XAPP 495) > 1080p hat eine Pixel Clock von 108 MHz. Bei 10 Bit/Pixel sind das 1080 > MBit/s pro TMDS Lane und das ist auch das Limit der IOs des Spartan6 > Speedgrade 3. Wie kommt diese Pixel Clock zu stande? 1920*1080*60 ist schon mehr als 108 Millionen. Außerdem überträgt man pro Farbe 8bit, also 24 in einer 8b10 Kodierung, also mit 30bit. Dazu kommen noch Blankings. Am Ende kommt man bei ca. 4.5Gbit/s raus. Weit mehr als der Spartan6 abkann. > Intern hast du mit 108 MHz natürlich kein Problem. Bei gutem Design sollte es intern auch mit den 150MHz die eigentlich ankommen hinhauen, ja. > Du kannst natürlich auch Transceiver verwendet. Die gehen vom Spartan 6 > bis zu 3.2 Gbit/s. Wobei hier das Design anspruchvoller wird, sofern man > keine Erfahrung mit GTPs hat. Immernoch zu wenig. Kann der außerdem TMDS Pegel? Die Spartan6 die GTPs haben sind übrigens ein gutes Stück teuerer.
Guest schrieb: >> Es ist abhängig vom Speedgrade des FPGAs. Wenn ich von einem Spartan6 >> ausgehe, dann ist 1080p nur mit dem schnellsten, also den 3er, möglich. > Xilinx sagt etwas anderes (XAPP 495) DS162 (V3.0) - Tabe 25 - hier kann man deutlich rauslesen, dass es 1080 MBit/s für den 3er SG sind, 1050 MBit/s für den 3N und 950 MBit/s für den 2er. Guest schrieb: >> 1080p hat eine Pixel Clock von 108 MHz. Bei 10 Bit/Pixel sind das 1080 >> MBit/s pro TMDS Lane und das ist auch das Limit der IOs des Spartan6 >> Speedgrade 3. > Wie kommt diese Pixel Clock zu stande? 1920*1080*60 ist schon mehr als > 108 Millionen. Außerdem überträgt man pro Farbe 8bit, also 24 in einer > 8b10 Kodierung, also mit 30bit. Dazu kommen noch Blankings. Am Ende > kommt man bei ca. 4.5Gbit/s raus. Weit mehr als der Spartan6 abkann. Sorry, der Pixel Clock von 108 MHz für 1080p war falsch. Der Pixel Clock ist definiert in der EIA-CEA-861-D Spezifikation und sollten für 1080p/60 148.5 MHz sein, für 1080p/30 sind es 74.25 MHz. Ersteres kann natürlich der Spartan 6 nicht. Guest schrieb: > 8b10 Kodierung Hier muss ich dich aber trotzdem korrigieren. Es ist keine 8B10B Kodierung (Fachausdruck!). Bei HDMI ist es eine Mischung aus "Control Period Coding", "TERC4 Coding" und "Video Data Coding". Es werden hier jeweils aus 2, 4 oder 8 Bit immer 10 Bit erzeut. Guest schrieb: >> Du kannst natürlich auch Transceiver verwendet. Die gehen vom Spartan 6 >> bis zu 3.2 Gbit/s. Wobei hier das Design anspruchvoller wird, sofern man >> keine Erfahrung mit GTPs hat. > Immernoch zu wenig. Kann der außerdem TMDS Pegel? Die Spartan6 die GTPs > haben sind übrigens ein gutes Stück teuerer. Nach Meiner Rechnung wären das 1.5 Gbit pro Kanal und das ist mit den GTPs möglich. Es war eine Frage der Realisierung und nicht des Preises.
lulu schrieb: > Guest schrieb: >>> Es ist abhängig vom Speedgrade des FPGAs. Wenn ich von einem Spartan6 >>> ausgehe, dann ist 1080p nur mit dem schnellsten, also den 3er, möglich. >> Xilinx sagt etwas anderes (XAPP 495) > DS162 (V3.0) - Tabe 25 - hier kann man deutlich rauslesen, dass es 1080 > MBit/s für den 3er SG sind, 1050 MBit/s für den 3N und 950 MBit/s für > den 2er. Ich bezog mich auf die (implizite) Aussage, dass sein Vorhaben möglich ist, aber gut, nimm es wie du willst. lulu schrieb: > Guest schrieb: >>> 1080p hat eine Pixel Clock von 108 MHz. Bei 10 Bit/Pixel sind das 1080 >>> MBit/s pro TMDS Lane und das ist auch das Limit der IOs des Spartan6 >>> Speedgrade 3. >> Wie kommt diese Pixel Clock zu stande? 1920*1080*60 ist schon mehr als >> 108 Millionen. Außerdem überträgt man pro Farbe 8bit, also 24 in einer >> 8b10 Kodierung, also mit 30bit. Dazu kommen noch Blankings. Am Ende >> kommt man bei ca. 4.5Gbit/s raus. Weit mehr als der Spartan6 abkann. > Sorry, der Pixel Clock von 108 MHz für 1080p war falsch. Der Pixel Clock > ist definiert in der EIA-CEA-861-D Spezifikation und sollten für > 1080p/60 148.5 MHz sein, für 1080p/30 sind es 74.25 MHz. Ersteres kann > natürlich der Spartan 6 nicht. Dann sind wir uns ja einig. Wie ist das denn bei "normalen" HDMI Geräten (Bluray Player, Spielekonsolen, Receiver, etc)? Die werden doch wohl alle 60Hz machen oder? (ernst gemeinte Frage) lulu schrieb: > Guest schrieb: >> 8b10 Kodierung > Hier muss ich dich aber trotzdem korrigieren. Es ist keine 8B10B > Kodierung (Fachausdruck!). Bei HDMI ist es eine Mischung aus "Control > Period Coding", "TERC4 Coding" und "Video Data Coding". Es werden hier > jeweils aus 2, 4 oder 8 Bit immer 10 Bit erzeut. Mag sein, habe HDMI nie selbst implementiert, jedenfalls werden doch 30bit übertragen oder? lulu schrieb: > Guest schrieb: >>> Du kannst natürlich auch Transceiver verwendet. Die gehen vom Spartan 6 >>> bis zu 3.2 Gbit/s. Wobei hier das Design anspruchvoller wird, sofern man >>> keine Erfahrung mit GTPs hat. >> Immernoch zu wenig. Kann der außerdem TMDS Pegel? Die Spartan6 die GTPs >> haben sind übrigens ein gutes Stück teuerer. > Nach Meiner Rechnung wären das 1.5 Gbit pro Kanal und das ist mit den > GTPs möglich. Es war eine Frage der Realisierung und nicht des Preises. Richtig, sind ja 3 Kanäle. Dann wäre das möglich, falls der GTP auch TMDS kann. Das weiß ich wie gesagt nicht. An den Threadstarter: Schonmal einen FPGA benutzt? Ansonsten würde ich davon die Finger lassen.
Alles was ich eigentlich machen wollte ist eine "Karte für den PCIe-Slot" bauen, die die HDMI Signale in einem PC verfügbar macht. Die Idee war einen PC als AV-Receiver zu nutzen und bei bedarf Signalverarbeitung (hauptsächlich Audio, Video evtl. skalieren) mit den Daten aus den HDMI-Kanälen durchzuführen. Dazu wollte ich einen FPGA verwenden, aber irgendwie drehe ich mich nur im Kreis, da ich keinen passenden FPGA (der auch bezahlbar ist) für das Projekt finden kann. Das SoC-Board von Digilent hat mir eigentlich sehr gut gefallen, aber man kann wohl auf dem Z-7010 keine PCIe-Schnittstelle umsetzen. HDMI geht mit 720p, steht zumindest im Manual. Was meint ihr, ist es möglich ein solches Projekt im Hobbybereich umzusetzen? Es gibt ja kommerzielle Karten und ich Frage mich echt wie die das machen? (http://www.amazon.de/Blackmagic-Design-BINTSPRO-Intensity-Pro/dp/B001CN9GEA) Ich hätte gerne folgende Features: - maximale Auflösung 1080p60 oder 720p - Audiodaten (LPCM) aus dem HDMI-Stream verarbeiten und ausgeben - Anbindung der Karte in Linux (eigener Treiber), um sie mit anderen Programmen zu nutzen
Guest schrieb: >An den Threadstarter: Schonmal einen FPGA benutzt? Ansonsten würde ich >davon die Finger lassen. Ja im Studium mit einem Xilinx-Board. Dazu kann ich nur sagen Learning By Doing! Es ging ja erstmal darum ob es überhaupt machbar ist. Außerdem denke ich, dass man sich in die Materie einarbeiten kann. Ich wollte mir nur zuerst eine Fachmeinung einholen, bevor ich mir irgendwelche Bauteile kaufe.
Karl schrieb: > Was meint ihr, ist es möglich ein solches Projekt im Hobbybereich > umzusetzen? Ich habe jetzt schon einige Jahre FPGA Design auf dem Buckel und was du dir vorstellst würd ich für mich >1 Jahr, eher 2 Jahre Freizeit einplanen. Es kommt drauf an, wieviel IP-Cores man bekommt, die man direkt verwenden kann. Aber du willst PCIe, HDMI evtl. sogar noch Speicher machen. Dazu noch einen PC Treiber mit DMA etc. Das zieht sich gewaltig. Karl schrieb: > Es gibt ja kommerzielle Karten und ich Frage mich echt wie > die das machen? > (http://www.amazon.de/Blackmagic-Design-BINTSPRO-Intensity-Pro/dp/B001CN9GEA) Die Kochen auch nur mit Wasser. Die machen es genauso wie du es dir vorstellst. Nur haben die zwei Vorteile: 1) Sie machen sich ein genau für diese Anwendung passende Hardware 2) Es arbeiten mehrere Leute dran.
lulu schrieb: > Karl schrieb: >> Was meint ihr, ist es möglich ein solches Projekt im Hobbybereich >> umzusetzen? > > Ich habe jetzt schon einige Jahre FPGA Design auf dem Buckel und was du > dir vorstellst würd ich für mich >1 Jahr, eher 2 Jahre Freizeit > einplanen. Darf ich in irgendeiner Form auf deine Erfahrung zurückgreifen? (evtl. E-Mail oder sonstiges) Das sollte eigentlich kein Freizeitprojekt werden sondern evtl. meine Masterthesis. lulu schrieb: > Es kommt drauf an, wieviel IP-Cores man bekommt, die man > direkt verwenden kann. Aber du willst PCIe, HDMI evtl. sogar noch > Speicher machen. Dazu noch einen PC Treiber mit DMA etc. Das zieht sich > gewaltig. Ich weiß jetzt nicht genau inwiefern diese IP-Cores direkt verwendet werden können, aber von Xilinx gibt es doch schon etwas für HDMI und PCIe: PCIe Tutorial: http://www.fpga4fun.com/PCI-Express.html PCIe Core von Xilinx: http://www.xilinx.com/products/intellectual-property/S6_PCI_Express_Block.htm HDMI bzw. TMDS von Xilinx: http://www.xilinx.com/support/documentation/application_notes/xapp495_S6TMDS_Video_Interface.pdf oder man verwendet für HDMI den ADV7612 (http://www.analog.com/en/audiovideo-products/analoghdmidvi-interfaces/adv7612/products/product.html) und ADV7511 (http://www.analog.com/en/audiovideo-products/analoghdmidvi-interfaces/adv7511/products/product.html) Baustein. lulu schrieb: > Die Kochen auch nur mit Wasser. Hihi da bin ich aber froh! Es ist nur so, dass man erstmal eine Weile im Internet suchen muss, bis man überhaupt etwas findet. lulu schrieb: > 1) Sie machen sich ein genau für diese Anwendung passende Hardware Genau das habe ich vor. lulu schrieb: > 2) Es arbeiten mehrere Leute dran. Da hoffe ich doch, dass ich das auch alleine schaffe. :-) Ich denke ich werde mich auf 720p bzw. 1080i erstmal beschränken müssen.
Hallo, ich will dir jetzt nicht zu Nahe treten und nimm meine Kommentare als Hilfestellung an. Es geht um deine Abschlussarbeit, die ein Erfolg werden sollte und nicht ein Desaster. Karl schrieb: > Das sollte eigentlich kein Freizeitprojekt werden sondern evtl. meine > Masterthesis. Für 1 Person ist dein Vorhaben für solch eine Arbeit zu umfangreich und du hast dafür nicht die notwendige Erfahrung. Wenn ich deine Punkte, die du dir vorstellst, zusammenfassen darf: 1) Hardwareentwicklung - FPGA Design (+ alles was dazugehört) - PCIe (im FPGA) dazu Clock Distribution (nicht trivial für PCIe) - HDMI (deine genannten Bausteine helfen dir sehr dabei, wenn du es nicht im FPGA machen willst) - Audio - DDR2/3 Pufferspeicher zwischen Video und PCIe (das wirst du mit ziemlicher sicherheit brauchen) - dazu geeignete Versorgungsspannung mit Schaltregler - Schaltplan + Multilayer Layout. Alleine das sind schon mind. 4 eher 6 Wochen vollzeit! Falls hier etwas nicht auf Anhieb funktioniert, und davon kannst du ausgehen, dann kannst du damit Wochen mit Fehlersuche verbringen. Daher mein Tipp: Wenn du sowas machen willst, dann verwende fertige Hardware. 2) Firmware-Entwicklung - Es gibt IP-Cores. Trotzdem wird man nicht darüber hinwegkommen sich oberflächlich bis tief einarbeiten zu müssen. Du hast hier viele Themengebiete genannt: PCIe, HDMI, Audio, Bildverarbeitung, ... - Du musst damit rechnen, dass der IP-Core nicht genau das macht, was du willst. Du musst ihn unter Umständen ändern und erweitern können. 3) PC Software Entwicklung - Linux ist für PC-Karten definitiv besser geeignet als Windows. Es ist machbar mit vertretbaren Aufwand einen Treiber für eine eigene Karte zu schreiben. Trotzdem brauchst du unbedingt fundierte Linux-Kenntnisse dafür. - Der Treiber muss für dein Projekt DMA-Fähig sein, um die notwendige Bandbreite zu schaffen. - Um Interrupts (von PCIe) wirst du auch nicht herumkommen. - Und dann kommt neben dem Treiber noch die Applikationsentwicklung Karl schrieb: > lulu schrieb: >> 2) Es arbeiten mehrere Leute dran. > Da hoffe ich doch, dass ich das auch alleine schaffe. :-) Im Rahmen der Masterarbeit denke ich, dass du dich mit diesem Projekt übernimmst. Meine Frage an dich: Was soll für dich der Schwerpunkt dieser Arbeit sein? 1) HDMI+Bildverarbeitung im FPGA+Audio etc.? Dann starte mit einem fertigen Board, dass die notwendigen Komponenten besitzt, so dass du dich um die Hardware keine Gedanken machen musst. z. B. das Atlys Board von Digilent (http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,400,836&Prod=ATLYS&CFID=5125210&CFTOKEN=9fdb9a17a1a05535-64C44F55-5056-0201-02C74C5816AD12E8) Du glaubst gar nicht, wie wertvoll es ist, sich auf die Hardware verlassen zu können. 2) PCIe, Linux Treiber + Applikation Wieder auf Basis eines fertiges Boards (z. B. http://www.xilinx.com/products/boards-and-kits/EK-S6-SP605-G.htm oder http://www.em.avnet.com/en-us/design/drc/Pages/Xilinx-Spartan-6-FPGA-LX75T-Development-Kit.aspx - beide Boards können nur PCIe x1 Gen1) Du kannst immer im FPGA Testdaten generieren. Somit kannst du dir deine komplette Linux Treiber+Applikation erstellen. Wenn du merkst, dass du sehr gut voran kommst, dann kannst du dir immer noch für diese Boards eine Adapter-Platine mit HDMI TX/RX entwickeln. Beides als gesamtes Projekt mit komplett eigener Hardware wirst du nicht schaffen. Grüße
Guest schrieb: > Der Pixel Clock ist definiert in der EIA-CEA-861-D Spezifikation > und sollten für 1080p/60 148.5 MHz sein confirmed > Immernoch zu wenig. Kann der außerdem TMDS Pegel? Die Spartan6 die > GTPs haben sind übrigens ein gutes Stück teuerer. teurer, als ein Transceiver und einen Core braucht man auch noch. Das tut sich eigentlich keiner an, der nicht wenigstens Stückzahlen von 1k aufwärts hat. > Nach Meiner Rechnung wären das 1.5 Gbit pro Kanal und das ist mit > den GTPs möglich. Es war eine Frage der Realisierung und die GTPs können direkt TMDS? > Dann wäre das möglich, falls der GTP auch > TMDS kann. Das weiß ich wie gesagt nicht. not confirmed > bis zu 30 Bit Es sind bis zu 48 bit
Hallo, eventuell ist sowas für dich interessant: http://hackaday.com/2014/01/25/reverse-engineering-an-hdmi-extender/ mixing kannste ja im pc machen ... mit x so dingern und jedemenge hacky software wird man fast beliebig mixen können ;)
BillX schrieb: > Hallo, > > eventuell ist sowas für dich interessant: > > http://hackaday.com/2014/01/25/reverse-engineering-an-hdmi-extender/ > > mixing kannste ja im pc machen ... mit x so dingern und jedemenge hacky > software wird man fast beliebig mixen können ;) Ein sehr interessanter Beitrag, aber leider für mein Projekt ungeeignet da man damit nur 18fps (http://danman.eu/blog/reverse-engineering-lenkeng-hdmi-over-ip-extender/) schafft. lulu schrieb: > ich will dir jetzt nicht zu Nahe treten und nimm meine Kommentare als > Hilfestellung an. Es geht um deine Abschlussarbeit, die ein Erfolg > werden sollte und nicht ein Desaster. Genau aus diesem Grund habe ich den Forumseintrag gestartet, um eine Fachmeinung zu bekommen. Ich habe bis jetzt noch mit keinem Professor gesprochen und wollte zuerst einmal herausfinden ob das Projekt überhaupt umsetzbar ist. lulu schrieb: > 2) PCIe, Linux Treiber + Applikation > Wieder auf Basis eines fertiges Boards (z. B. > http://www.xilinx.com/products/boards-and-kits/EK-S6-SP605-G.htm oder > http://www.em.avnet.com/en-us/design/drc/Pages/Xilinx-Spartan-6-FPGA-LX75T-Development-Kit.aspx > - beide Boards können nur PCIe x1 Gen1) > Du kannst immer im FPGA Testdaten generieren. Somit kannst du dir deine > komplette Linux Treiber+Applikation erstellen. Wenn du merkst, dass du > sehr gut voran kommst, dann kannst du dir immer noch für diese Boards > eine Adapter-Platine mit HDMI TX/RX entwickeln. Falls es zu so einer Arbeit kommt, fände ich diesen Teil interessanter. Wollte sowieso lieber mit Linux (hatte ich schon mit CUDA in meiner Bachelorarbeit verwendet) arbeiten, da ich dafür schon genug Examples für PCIe gefunden habe. lulu schrieb: > Du glaubst gar nicht, wie wertvoll es ist, sich auf die Hardware > verlassen zu können. Ein fertiges Board wollte ich sowieso verwendet, da zuerst die Software stehen sollte bevor man ein eigenes Board entwickelt. Das erschwert sonst nur die Fehlersuche (Hardware- oder Softwarefehler). @lulu dürfte ich dich in einem Chat ein paar Sachen fragen?
Karl schrieb: > @lulu dürfte ich dich in einem Chat ein paar Sachen fragen? wie kann ich dich kontaktieren?
Ich habe heute einen IRC-Channel auf irc.quakenet.org und das ist der Channel: #HDMIPCIe
Du kannst einfach diesen Webclient nutzen http://webchat.quakenet.org/ und dich im Channel einloggen.
Ich hänge micht mal hier dran: Laut der APP note von Xilinx geht kein 1080p60 mit 148 MHz. Dort werden die SERDES verwendet. http://www.xilinx.com/support/documentation/application_notes/xapp495_S6TMDS_Video_Interface.pdf Geht es es nun wie weiter vermutet, doch, wenn man die GTP verwendet? Ich nehme an, nicht, denn dann würde Xilinx es ja so bauen.
Moin, HDMI auf dem FPGA ist recht knifflig, und auf dem Spartan6 würde ich das ehrlich gesagt seinlassen. Wird eine rechte Frickelei, und ich bin ziemlich sicher, dass 150 MHz nicht zu schaffen sind. Beim Lattice ECP3 könnte das gerade noch gehen, aber: KÖNNTE. Ich hab's nur mit 720p60 probiert. Am besten die FAEs quälen. An Hardware fällt mir gerade nur das Versa Videoboard ein. Wenn man die HDMI-Cores mal erzeugt hat, läuft das vom Timing her erstaunlich gut, zumindest bei 74.25 MHz. Dann muss man sich nur noch mit dem Skew/Delay der einzelnen Kanäle beschäftigen. Den HDCP-Quatsch muss man nicht implementieren, aber man kann. Die Keys sind ja "offen" :-) Die Tools kosten halt ein bisschen Schotter, aber für akademische Zwecke würde ich auch mal schauen, was die FAEs so machen können. Das ganze aber noch auf PCIe zu streamen ist definitiv ne Nummer zu gross für ne Masterarbeit. Für obiges würde ich mir schon vorsichtig gerechnet ein halbes Jahr reservieren.
Was es doch nicht alles an aktiven Wächtern über vergangene Themen gibt! Ich habe schon meinen Grund, warum ich mich an den thread dranghänge - zumal ihn mir die Forensuche vorgeschlagen hat. @Strubi: Sprichst Du hierbei von überhaupt HDMI zu prozessieren oder es direkt über die Ausgänge zu machen, weil mit Chips wie diesem 7513 müsste es ja gehen. Beitrag "Re: HDMI Video-Mischer Experimental-Systen"
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.