Eingaben
Beispiel
Füge EDID-Hex vom konkreten Punkt der HDMI-Kette ein und prüfe Timing/Y420, Audio/Lautsprecher, HDMI-Transport, HDR, DisplayID, Checksummen und Byte-Provenienz.
HDMI-EDID-Decoder
Dekodiert EDID-Hex oder lokale Dateien zu trust-qualifizierter Timing-, YCbCr-4:2:0-, Audio-, Lautsprecher-, HDMI-Transport-, HDR-, DisplayID-, Checksum- und Byte-Provenienz-Evidenz.
Nützlich, wenn HDMI-Kette, AVR, Matrix, Capture-Karte oder Display Fähigkeiten melden, die nicht zur Realität passen.
Was ein Display der Quelle wirklich erzählt
Jeder HDMI-Handshake beginnt damit, dass die Senke der Quelle ein EDID übergibt: eine kompakte binäre Selbstbeschreibung mit deklarierten Timings, Audioformat-Codes, statischen HDR-Metadaten und Identitätsdaten. Wenn ein Setup auf 1080p zurückfällt, ein Audioformat verliert oder nach einer Kettenänderung kein HDR mehr zeigt, kann die relevante Evidenz im empfangenen Blob liegen. Dieser Blob ist womöglich nicht der des Displays, denn AVRs, Matrizen, Splitter und EDID-Emulatoren können ihn mergen, beschneiden oder ersetzen.
Dieser Decoder akzeptiert striktes EDID-Hex oder eine lokale Binär- oder Textdatei und erstellt einen evidenzorientierten Bericht. Er deckt EDID-1.3-/1.4-Basisdaten, registrierte CTA-Videomodi, jedes Vorkommen eines Short Audio Descriptor, drei getrennte Lautsprecherkarten, HDMI-VSDB-Kontext, unterstützte HDMI-Forum-SCDS-Transportfelder wie FRL, DSC, VRR, ALLM, QMS und FVA, qualifizierte statische und dynamische HDR-Records, Dolby Video, HDR10+, SBTM sowie unterstützte DisplayID-1.3- und -2.x-Abschnitte ab. Nicht unterstützte, fehlerhafte, abgeschnittene, widersprüchliche oder wegen der Prüfsumme nicht vertrauenswürdige Daten bleiben ausdrücklich mit Byte-Provenienz markiert, statt zu einer positiven Fähigkeitsaussage zu werden.
Den Blob am richtigen Punkt der Kette dekodieren
Erfasse das EDID exakt an dem Punkt, den du untersuchst — am Display selbst, am Ausgang des AVR, hinter der Matrix —, denn jedes Gerät der Kette kann ein anderes präsentieren, und der falsche Blob beantwortet die falsche Frage. Prüfe zuerst Identität und Prüfsummen: Ein Herstellerstring, der nicht zum Display passt, oder eine scheiternde Prüfsumme sagt dir sofort, dass du auf einen Emulator, einen Override oder Korruption schaust.
Lies danach die strukturierte Evidenz der Reihe nach: Konformitätsbefunde, beworbene Videomodi, jedes Audiodeskriptor-Vorkommen, Lautsprecher- und Raumkarten, HDMI-Transport, HDR, DisplayID und zuletzt Abdeckung sowie rohe Byte-Evidenz. Die Darstellung trennt kodierte JOC- oder codec-abhängige Flags von pauschalen proprietären Wiedergabeaussagen, hält statisches und dynamisches HDR auseinander und zeigt negative oder fehlerhafte Felder, statt sie still aufzuwerten. Dekodiere Erfassungen einzeln und vergleiche bei Bedarf die teilungssicheren Zusammenfassungen manuell; eingebauter Side-by-Side-Vergleich, Quellmoduswahl und Signalketten-Feasibility-Analyse sind nicht implementiert.
Lokales Dekodieren und seine ehrlichen Grenzen
Die EDID-Route ist absichtlich frei von Drittanbieter-Code, und ihre Route-Policy deaktiviert Netzwerkzugriffe; Parsing, Darstellung, Zwischenablage und Downloads bleiben lokal. Der forensische Bildschirmbericht kann Identität und Rohevidenz zeigen. Standardmäßige JSON-, Markdown-, Zwischenablage-, redigierte Hex- und WebMCP-Ergebnisse verwenden eine ausdrückliche teilungssichere Projektion, die Identität, Topologie, Dateinamen, Rohwerte, unbekannte Hersteller-Nutzdaten und stabile Fingerprints weglässt. Exakte Originalbytes benötigen eine separate einmalige Bestätigung für sensitive Daten. Side-by-Side-Vergleich, Quellmoduswahl und End-to-End-Feasibility-Analyse sind nicht implementiert; der Bericht kann daher weder beweisen, welchen Modus eine Quelle wählt, noch ob die gesamte Signalkette ihn übertragen kann. Das Tool schreibt oder verändert kein EDID.
Häufige Fragen
Welche Größe müssen EDID-Daten haben?
EDID ist in 128-Byte-Blöcken organisiert: ein Basisblock plus optionale Extension-Blöcke, also 128, 256 oder mehr Bytes in vollständigen Vielfachen. Der Decoder erwartet ganze Blöcke und prüft jede Block-Prüfsumme.
Warum zeigt mein AVR andere EDID-Daten als der TV?
Weil Geräte in der Kette EDID aktiv verwalten: Ein AVR mergt seine Audiofähigkeiten in die Videofähigkeiten des Displays, Matrizen und Splitter präsentieren oft den kleinsten gemeinsamen Nenner oder eine feste Tabelle. Das ist normal — und genau der Grund, warum der Erfassungspunkt zählt.
Kann dieses Tool ein EDID ändern oder schreiben?
Nein. Es dekodiert nur, was du einfügst oder lädst — es programmiert keine Emulatoren, flasht keine Displays und setzt keine Treiber-Overrides. Nutze es, um zu verifizieren, was ein Override enthalten soll, und danach, was er tatsächlich enthält.
Was bedeutet ein Prüfsummen- oder Vertrauensfehler?
Jeder 128-Byte-EDID-Block muss modulo 256 auf null summieren; DisplayID hat zusätzlich eine eigene Abschnittsstruktur und Prüfungen. Ein Fehler kann auf Abschneiden, einen Copy-Paste-Fehler, fehlerhafte Längen, eine widersprüchliche Extension-Anzahl oder echte Korruption hinweisen. Der Bericht behält die Evidenz, unterdrückt oder qualifiziert aber Aussagen, die von nicht vertrauenswürdigen Bytes abhängen.
Warum fehlt eine Fähigkeit, obwohl das Display sie beherrscht?
Die Quelle sieht nur das EDID, das sie empfängt, nicht das Datenblatt des Displays. Ein Zwischengerät kann eine Deklaration entfernen, ein Override kann aktiv sein, der relevante Block kann fehlerhaft sein oder das Feld außerhalb der fest gepinnten öffentlichen Registry des Decoders liegen. Fehlende Evidenz beweist nicht, dass der Hardware die Funktion fehlt.
Vergleicht der Decoder Erfassungen oder wählt er einen Modus?
Nein. Er dekodiert jeweils nur eine aktive Quelle. Er vergleicht keine zwei EDIDs, modelliert keine Link-Budgets, berücksichtigt keine Kabel- oder Repeater-Grenzen, wendet keine Auswahl-Policy einer Quelle an und beweist keine End-to-End-Wiedergabe.
Enthält EDID private Daten, und was lässt sich sicher exportieren?
EDID kann Hersteller- und Produktidentität, Herstellungsdatum, seriennummernartige Werte, HDMI-Topologie, DisplayID-Identifikation und unbekannte Herstellerbytes tragen. Standardexporte und WebMCP lassen diese Felder über einen allowlist-basierten teilungssicheren Bericht weg. Redigiertes Hex ist Evidenztext und kein ladbares EDID; das exakte Original ist nur nach einer separaten einmaligen Bestätigung verfügbar.