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
