Forum: FPGA, VHDL & Co. hdmi 3D frame-packed zu frame sequential konvertieren mit FPGA und ohne HDCP?


von Felix (Gast)


Lesenswert?

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?

von hans (Gast)


Lesenswert?

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.

von Felix M. (sanktnelson)


Lesenswert?

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!

von Felix M. (sanktnelson)


Lesenswert?

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)

von hans (Gast)


Lesenswert?

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).

von felix (Gast)


Lesenswert?

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

von Kiste (Gast)


Lesenswert?

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
Noch kein Account? Hier anmelden.