Hallo zusammen! Ich würde gern HDMI 3D-Signale im Frame-Packed Format (beide Augen in einem Frame, eins oben, eins unten) in Frame-sequential (doppelte Bildfrequenz, linkes rechtes Auge abwechselnd) wandeln. In meinem jugendlichen Leichtsinn dachte ich mir, das wäre doch mal eine gute Entschuldigung mir ein kleines FPGA dev-board zum spielen zuzulegen. Dann fiel mir ein dass HDMI broken-by-design ist und der ganze Mist immer HDCP-verschlüsselt ist. Andererseits interessiere ich mich ja garnicht für den Inhalt des Bildes, sondern bloss für hsync und vsync. Diese werden allerdings bei DVI/HDMI nicht getrennt übertragen, sondern sind nur ein anderes Muster auf einem TMDS-Kanal (blau glaube ich). In der Hoffnung, dass sich hier schonmal jemand etwas eingehender mit DVI/HDMI/HDCP auseindergesetzt hat hier also die Fragen: 1. Ist das oben beschriebene überhaupt möglich ohne HDCP zu knacken? d.h. werden die HSYNC und VSYNC bytes auf dem TMDS Kanal auch verschlüsselt? Falls nicht: wie funktioniert das re-keying bzw. fliegt mir die Verschlüsselung um die Ohren, wenn ich aus einem Frame zwei mache? 2. Welche boards kommen für so ein Projekt in Frage? Ich vermute die Antwort ist "keines" wenn man das HDMI-Kabel direkt an den FPGA anstöpseln möchte, aber vielleicht gibt es ja eins mit externen SerDes chips?
Hi! Die Übertragung von H-Sync und V-Sync ist unterschiedlich, je nachdem ob du nun gerade "nichts" überträgst (also weder Datenpakete noch Video) oder ob du irgendwelche Pakete schickst. Soweit ich mich noch an meine aktive HDMI-Zeit erinnern kann wird das Sync-Signal aber immer unverschlüsselt und auf dem Blauen Kanal geschickt. Ohne HDCP-Dekodierung wirst du die Bilder aber trotzdem nicht auseinander bekommen. Ich könnte mir gut vorstellen, daß bei dem Umpacken die HDCP-Verschlüsselung und die Entschlüsselung irgendwann mal asynchron laufen werde. Dann gibts nur noch Schnee. Zusätzlich sollten die ganzen 3D-Format Infodaten (damit der Empfänger weiß welches 3D-Format er bekommt) in irgendwelchen Paketen im Datenstrom drin sein...verschlüsselt, wenn ich mich nicht irre. Ebenso Audiodaten. Abgesehen davon wirst du Datenraten und Speichermengen brauchen, die kein "kleines dev-board" so einfach stemmen kann. Gibt aber ne schöne App-Note (Nummer hab ich leider nicht im Kopf) von Xilinx zu HDMI/DVI auf nem Spartan 3E oder sowas. Die hatten aber auch ein Custom-made Board mit TMDS-Treiberbausteinen und viel Routingaufwand. Das lief wohl mit einem speziellen Speedgrade des Bausteins bis 1080i60. Wird also für 3D etwas knapp. Und Virtex Boards sind schon eher teuer.
hans schrieb: > Soweit ich mich noch an meine > aktive HDMI-Zeit erinnern kann wird das Sync-Signal aber immer > unverschlüsselt und auf dem Blauen Kanal geschickt. na das lässt doch schonmal hoffen... > Ohne HDCP-Dekodierung wirst du die Bilder aber trotzdem nicht > auseinander bekommen. Ich könnte mir gut vorstellen, daß bei dem > Umpacken die HDCP-Verschlüsselung und die Entschlüsselung irgendwann mal > asynchron laufen werde. Dann gibts nur noch Schnee. sowas hatte ich befürchtet, konnte es aber aus der spec nicht auf Anhieb rauslesen. Weisst du an welcher stelle sich encoder und decoder synchronisieren? Nach jeder Zeile wär okay, nach jedem Frame eher fatal. > Zusätzlich sollten die ganzen 3D-Format Infodaten (damit der Empfänger > weiß welches 3D-Format er bekommt) in irgendwelchen Paketen im > Datenstrom drin sein...verschlüsselt, wenn ich mich nicht irre. Ebenso > Audiodaten. Dafür könnte man ja so einen EDID fixer davorschalten, um dem Abspieler vorzugaukeln, dass ein 3D-fähiges Endgerät dranhängt. Die 120Hz-Beamer an die ich als Ausgabe denke sind glaube ich recht stupide und erwarten einfach nur 1280x720@120Hz. Da das noch der "alte" Standard hergibt würde ich wetten, dass die noch keine spezielle 3D-Signalisierung brauchen. > Abgesehen davon wirst du Datenraten und Speichermengen brauchen, die > kein "kleines dev-board" so einfach stemmen kann. Warum Speichermengen? zwischenspeichern wollte ich eigentlich nix... Datenraten: Pixelclock ist 1280*720*120Hz=110MHz, ich hatte gehofft, dass ein aktueller (bezahlbarer) FPGA das stemmen kann, hab mich allerdings ein paar Jahre nicht mehr damit beschäftigt. > Gibt aber ne schöne > App-Note (Nummer hab ich leider nicht im Kopf) von Xilinx zu HDMI/DVI > auf nem Spartan 3E oder sowas. Die hatten aber auch ein Custom-made > Board mit TMDS-Treiberbausteinen und viel Routingaufwand. Das lief wohl > mit einem speziellen Speedgrade des Bausteins bis 1080i60. Wird also für > 3D etwas knapp. Und Virtex Boards sind schon eher teuer. gefunden, guter Hinweis, danke!
Felix Maibaum schrieb: >> Gibt aber ne schöne >> App-Note (Nummer hab ich leider nicht im Kopf) von Xilinx zu HDMI/DVI >> auf nem Spartan 3E oder sowas. Die hatten aber auch ein Custom-made >> Board mit TMDS-Treiberbausteinen und viel Routingaufwand. ist übrigens XAPP460. Beeindruckend ist, dass sie ohne externe SERDES auskommen (TMDS-Treiber brauchen sie trotzdem)
Mit einem EDID Fix wird das glaube ich nichts. Die 3D-Datenbeschreibung ist meines Wissens nach in einem Datenpaket im HDMI-Datenstrom. Zwischenspeichern wirst du müssen, da du bei dem Wandeln von "zwei Bilder übereinander in einem Frame" in "zwei Einzelbilder" mindestens einmal neue Sync-Pulse zwischen den beiden Einelbildern einfügen musst. Da müssen dann auf jedenfall Teile der Bilddaten zwischengespeichert werden. Zusätzlich solltest du noch die nicht sichtbaren Bildbereiche mit einrechnen. Brutto hast du also deutlich mehr als 1280x720 Pixel. Die genaue Zahl hab ich jetzt aber nicht im Kopf. Müsste ich in Tabelle nachgucken. Ansonsten synchronisiert sich das HDCP-Zeug einmal am Anfang der Verbindung. Danach müssen Sender und Empfänger pixelsynchron laufen. Prinzipiell hast du rückgekoppelte Schieberegister im Empfänger und im Sender. Beim Aufbau der Verbindung werden beide über einen Schlüsselaustausch und viel Mathematik mit einem identischen Wert vorgeladen. Jeden Takt, in dem Video- oder sonstige Paketdaten übertragen werden, wird der Schieberegisterinhalt eine Stelle weitergeschoben. Der Sender verschlüsselt damit das aktuelle Byte, der Dekoder entschlüsselt es dann wieder. Ein Pixel Abweichung und du siehst schön bunten Schnee auf deinem Bildschirm. Evtl. erkennt dein Empfänger dann beschädigte Datenpakete und resynchronisiert sich. Aber das dauert ziemlich lange (2-3 Sekunden).
Cool, dann muss ich ja jetzt nurnoch HDCP knacken... Schade. Ich finde es wird langsam mal Zeit, dass ein paar Geräteschlüssel geleakt werden... Aber danke für das Hintergrundwissen! Auch wenn ich mir jetzt eine andere Entschuldigung für ein neues Spielzeug suchen muss. -Felix
Auch wenn der Thread inzwischen uralt ist, eine kleine Korrektur: Man muss nichts zwischenspeichern. Beim Framepack-Format sind zwischen den beiden Bildern 25 ungenutzte Zeilen. Das entspricht genau der normalen Dauer eines HSYNC-Impulses. Das Timing ist bei Framepack exakt das gleiche wie bei frame sequential, nur dass jeder zweite HSYNC einfach ausgelassen wird. Ich hab da allerdings nicht selber an die Leitungen gefasst, ich verbiege nur Grafikkarten bis sie etwas rausschicken, was nach framepack aussieht. Und noch eine kleine Ergänzung: Bisher hab ich nur einen einzigen bildschirm getestet, aber der hat sich automatisch auf framepack eingestellt, auch ohne besondere Metadaten. Das framepack-Timing ist einzigartig, das kann man (und darf man laut HDMI1.4a-Spezifikation!) erkennen, ohne die mitgeschickten metadaten auswerten zu müssen. Gruß, Kiste
Bitte 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.