HDMI Transceiver 1080p?

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?

Am besten vielleicht über IRC oder so etwas.

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.

alles klar. Wann hast du Zeit?

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.

Strubi, das war 2014, da ist wohl eh keine Arbeit drauß entstanden.

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"