HDMI EDID Decoder
Decode captures from successive HDMI hops and compare identity, timings, audio, HDR, and checksums.
Hardware / AVHDMI and EDID Troubleshooting in Real Signal Chains
HDMI faults are rarely random: the source is selecting from a capability advertisement that has been filtered, merged, cached, or damaged somewhere in the chain. Stop swapping cables by instinct; capture what each hop says, reduce the path, and make one controlled change at a time.
EDID is an offer, not the picture
Extended Display Identification Data is the sink's compact answer to a source asking, “What may I send?” The 128-byte base block identifies the display and lists core timings; CTA extension blocks carry the HDMI-era detail: additional video modes, audio formats, speaker allocation, vendor data, and HDR static metadata. The source reads that offer over the display data channel, chooses an output, and then brings up the protected or unprotected link. EDID does not prove that a cable can sustain the chosen bandwidth, that HDCP authentication will succeed, or that the display will render every advertised mode correctly. It is capability metadata, not a link test.
That distinction prevents bad diagnoses. A clean 4K image that blanks every few minutes points toward signal integrity, clock recovery, or HDCP reauthentication, not automatically toward malformed EDID. A source that never exposes 4K, HDR, or a lossless audio option is different: first inspect the offer it received. The HDMI EDID Decoder reads pasted hex or a local EDID file entirely in the browser and lays out identity, timings, CTA audio and HDR data, and checksum status. It reads the evidence; it neither rewrites EDID nor predicts the source's final choice.
Every intermediary becomes the sink
Connect a player directly to a television and the television supplies the EDID. Insert an AVR and the player now interrogates the AVR. The receiver normally combines its own audio capabilities with the display's video capabilities, but “combines” is implementation policy, not transparent forwarding. Add a splitter, matrix, capture device, soundbar, KVM, or copper/fibre extender and each can cache, trim, replace, or synthesize the advertisement. A firmware update or an output powered on in a different order can therefore change the source's menu without changing either endpoint.
Fan-out equipment has an especially awkward job. Two sinks may disagree on resolution, refresh rate, chroma, colour depth, HDR, or audio. Many splitters present a lowest-common-denominator EDID so both outputs work; others copy output one, expose a fixed table, or merge imperfectly. None can make a 1080p SDR display accept 4K HDR merely because the other output can. Before blaming the source, record which output owns EDID, whether hot-plug detection follows one port or all ports, and what happens when a dormant sink wakes. Power sequencing is part of the topology.
Capability mismatches have recognizable shapes
A chain falling back to 1080p often lacks the expected 4K timing in the presented CTA blocks, or advertises a 4K mode whose bandwidth the physical path cannot hold. HDR needs more than the words “4K capable”: the relevant transfer functions and static metadata must survive the chain, while colour depth, chroma format, refresh rate, and link bandwidth still have to fit together. A source may sensibly choose 4K SDR, 4K at reduced chroma, or a lower refresh rate when the complete combination is not advertised. Treat mode labels as shorthand; compare the actual timing and colour parameters.
Audio fails along a different seam. A television's EDID may advertise only formats it can render or return over ARC/eARC, while an AVR can decode considerably more. If a matrix copies the television's audio block instead of the receiver's, the player may offer stereo PCM and nothing else. Conversely, forcing an AVR-rich EDID into a path terminating at television speakers can create silence. Read audio descriptors and speaker allocation at the exact capture point. “The receiver supports it” is irrelevant when the player has never been told so.
Localize the loss, one link at a time
Write the chain down in order, including adapters and control-dependent branches. Then establish a known-good baseline: one source, one short certified cable, one display, conservative settings, all devices cold-started. Confirm that the desired mode exists and remains stable. Add the next component only. After each insertion, capture the EDID visible to the source, note the negotiated output, and run long enough to separate a handshake failure from a marginal high-bandwidth link. Changing cable, AVR mode, source format, and power order together destroys the evidence.
Compare captures rather than screenshots of settings menus. Start with manufacturer identity and block checksums: the wrong identity reveals a fixed table or emulator; a failed checksum makes the rest suspect because the block may be truncated or corrupt. Then compare preferred timing, video data blocks, audio formats, speaker map, and HDR metadata. Direct-to-display versus through-AVR is the useful first pair. Through-AVR versus through-extender is the next. The hop after which a capability disappears owns the investigation, even if its front panel insists that it supports the feature.
Use emulation as a scalpel
An EDID emulator can hold a known advertisement steady when the real sink powers down, copy a proven display EDID, or present a deliberately constrained capability set. That makes it excellent for diagnosis: if a copied direct-display EDID restores HDR through an otherwise unchanged chain, you have isolated negotiation policy from raw transport. It is also useful operationally in matrices where changing displays would otherwise retrigger every source. But an emulator cannot add bandwidth, HDCP support, decoding capability, or pixels. Forcing an attractive mode through incapable hardware merely trades an absent menu option for a black screen.
Preserve the original capture, label the physical point and date, and make overrides reversible. Prefer the smallest truthful change: remove one unsupported audio format or cap one timing rather than installing a maximal “everything” template. After programming, capture again and decode what the source actually sees. If the override appears correct but the link still drops, move back to cable length, connector quality, equalization, power, firmware, and HDCP. EDID was then only the invitation; the transport failed after accepting it.
AV-over-IP adds a second topology
In AV-over-IP, the logical route and the Ethernet route coexist. Encoders, decoders, controllers, and virtual matrices may still proxy or synthesize EDID, so the same capture-at-each-boundary method applies. Now multicast reachability, VLAN membership, IGMP behavior, QoS, MTU, and control-plane addressing can break a route whose EDID looks perfect. Keep the questions separate: can the source see the intended sink capability, and can the encoded media and control traffic cross the intended network path?
Document subnets before tracing streams. The CIDR/Subnet Calculator computes IPv4 or IPv6 boundaries and splits locally; it does not know the VLAN or routing policy you intended. The What is my IP? reports the address this site observes, useful for checking an egress or VPN but not for discovering private endpoint addresses. Neither replaces switch telemetry. They keep address assumptions honest while EDID captures keep capability assumptions honest.