Deep Dive into HDMI Resolution Troubleshooting

Using EDID data to debug my Yamaha A/V Receiver forcing an obscure 480p

I ran into an issue with my server where my Yamaha TSR-5810 (RX-V581) receiver connected to an Optoma projector would display a blank screen during the POST/BIOS phase. I immediately suspected that HP’s BIOS couldn’t handle the low resolution of 720x480 reported by the projector, with the main suspect being the vintage DisplayPort to HDMI 1080p converter I was using. The immeddiate diagnosis was that the HP’s BIOS couldn’t handle the low resolution of 720x480, as reported by the projector, and the main suspect was the vintage DisplayPort to HDMI 1080p converter I was using.

Author’s reproduction of HP’s generous idea for this Blank Page project

You can hardly blame HP for not handling the 720x480 (480p) resolution, considering any hardware of the last 20 years typically handles at least 1024 x 768. Nevertheless, the completely blank screen stumped me for an hour. The obvious initial suspect was the Displayport to HDMI converter, so I ordered a modern, 4k version, only to find that it produced the same issue. More head-scratching ensued.

Yamaha Customer Support

Eventually, by reducing the number of variables and connecting the PC directly to the projector, the BIOS menu showed at the princely 4k@60Hz resolution, to my sheer surprise. At this point, I assumed it was one of the not uncommon HDMI/EDID negotiation issues and hoped Yamaha Customer Service could offer a way to force and lock the displayed resolution — something I believed some of their models supported, but which, as they later clarified, was actually a video upscaling feature.

Yamaha CS did respond promptly, albeit with the expected “it’s not us, it’s you”:

The TSR-5810 only passes through video signals. It does not have the ability to change incoming video signals from one resolution to another. If you are seeing 720p on the projector, it’s because the PC is deciding to output that resolution.

, which I couldn’t but retribute with:

Frankly speaking, this cannot be true and is directly opposed to my experience. As I explained before, if I connect the projector directly to the PC, I am getting a 4k@60Hz right away. If I instead connect the PC via my receiver, I get 480p.

Yamaha receiver also failed to infer anything meaningful from the PC signal

However, the conversation carried on and I played along the “have you tried with other hardware” spiel. I connected my Dell display (of a 3440x1440 resolution) directly to the PC, which worked unsurprisingly, but also via the receiver, which somehow also worked fine.

Dell U3419W connected to PC (using the DisplayPort to HDMI 4K adapter)

So the conclusion was that the receiver had an issue specifically with my projector.

Dell U3419W connected to PC via the Receiver (using the DisplayPort to HDMI 4K adapter). Notice the reduced refresh rate.

I also found out that if I booted into a Linux GUI, I was actually able to change from 480p to 4k@60Hz manually. So with that in mind, I had no doubts this was an EDID negotiation issue between the receiver and the projector and not an actual hardware issue.

Debugging EDID

For the actual debugging of the problem, I resorted to the EDID information, which can be dumped by the edid-decode tool on the PC connected to a display.

Extended Display Identification Data (EDID) and Enhanced EDID (E-EDID) are metadata formats for display devices to describe their capabilities to a video source (e.g., graphics card or set-top box). The data format is defined by a standard published by the Video Electronics Standards Association (VESA). — Wikipedia1

EDID structure was extended by VESA committee multiple times, and our particular interest is in CTA EDID Timing Extension Block, i.e. the CEA-861, which provides support for all the advanced capabilities of the HDMI- or DisplayPort-equipped devices. This is, in essence, what makes all the modern devices automatically select optimal resolutions, color gamut and refresh rates, as well as the surround sound modes, without requiring any human intervention — when it works, that is. All this information is contained within several CTA Data Blocks, one of which is the VBD (Video Data Block). VBD, in turn, contains a list of SVDs (Short Video Descriptors), which basically reference the resolution and timing combinations predefined by VESA as Video Identification Codes (VICs) and supported by the display. Importantly, SVDs/VICs are listed in order of device preference.

Here’s an excerpt from the edid-decode tool that shows the timings of my Optoma projector connected to the PC, with the offender 480p resolution listed second:

Block 1, CTA-861 Extension Block:
  Revision: 3
  Underscans IT Video Formats by default
  Basic audio support
  Supports YCbCr 4:4:4
  Supports YCbCr 4:2:2
  Native detailed modes: 1
  Video Data Block:
    VIC  63:  1920x1080  120.000000 Hz  16:9    135.000 kHz    297.000000 MHz
    VIC   2:   720x480    59.940060 Hz   4:3     31.469 kHz     27.000000 MHz
    VIC   5:  1920x1080i  60.000000 Hz  16:9     33.750 kHz     74.250000 MHz
    VIC  20:  1920x1080i  50.000000 Hz  16:9     28.125 kHz     74.250000 MHz
    VIC  16:  1920x1080   60.000000 Hz  16:9     67.500 kHz    148.500000 MHz
    VIC  31:  1920x1080   50.000000 Hz  16:9     56.250 kHz    148.500000 MHz
    VIC  32:  1920x1080   24.000000 Hz  16:9     27.000 kHz     74.250000 MHz
    VIC  93:  3840x2160   24.000000 Hz  16:9     54.000 kHz    297.000000 MHz
    VIC  94:  3840x2160   25.000000 Hz  16:9     56.250 kHz    297.000000 MHz
    VIC  95:  3840x2160   30.000000 Hz  16:9     67.500 kHz    297.000000 MHz
    VIC  96:  3840x2160   50.000000 Hz  16:9    112.500 kHz    594.000000 MHz
    VIC  97:  3840x2160   60.000000 Hz  16:9    135.000 kHz    594.000000 MHz
    VIC  98:  4096x2160   24.000000 Hz 256:135   54.000 kHz    297.000000 MHz
    VIC  99:  4096x2160   25.000000 Hz 256:135   56.250 kHz    297.000000 MHz
    VIC 100:  4096x2160   30.000000 Hz 256:135   67.500 kHz    297.000000 MHz
    VIC 101:  4096x2160   50.000000 Hz 256:135  112.500 kHz    594.000000 MHz
    VIC 102:  4096x2160   60.000000 Hz 256:135  135.000 kHz    594.000000 MHz
    VIC   3:   720x480    59.940060 Hz  16:9     31.469 kHz     27.000000 MHz
    VIC   4:  1280x720    60.000000 Hz  16:9     45.000 kHz     74.250000 MHz
    VIC  19:  1280x720    50.000000 Hz  16:9     37.500 kHz     74.250000 MHz
    VIC  18:   720x576    50.000000 Hz  16:9     31.250 kHz     27.000000 MHz

As the plot thickened, I ran the edid-decode tool:

– with projector plugged in directly to PC (Linux framebuffer displays at 1080p),

– the projector plugged in via the receiver (Linux framebuffer displays at 480p),

– with projector disconnected but the receiver plugged in.

There were several interesting differences between these outputs, but most notably, between the Optoma plugged into the PC via the receiver and directly:

A diff of EDID reports: Optoma projector plugged into PC via receiver (left) and directly (right).

The Detailed Timing Descriptors section shows the currently used resolution and timings (frequencies). Notably, there’s a difference in the Monitor ranges reported by both configurations. My Optoma is a UHZ50 model, which supports frequencies as high as 240Hz at 1080p. When connected via the receiver, however, the monitor range gets reduced, which is expected since the receiver itself supports only up to 120Hz at 720p.

As mentioned, VICs in Video Data Block are listed in the order of preference. The first VIC reported as preferred by Optoma is 1080@120Hz. As established, the receiver cannot handle such high bitrate mode, so it decides to remove it from the list altogether. The next on the list of preferences reported by the projector is 480p, which is exactly why the devices settle on it. BINGO!


This primarily seems like Yamaha firmware bug: a better behavior than removing the VIC altogether would be swapping it with one that describes the same resolution but at the highest frequency supported by both devices. This is also an odd decision on Optoma end to make a very obscure 480p resolution the second preferred one. HP is also not without fault here, since their firmware should explicitly request a more suitable, reasonable 720p mode, instead of defaulting to first on the list, which they can’t even handle properly.

I reported all my findings to Yamaha CS, who in turn forwarded them to their design team, although this ~6 y/o device is unlikely to see an update fixing this somewhat unusual issue.

Discussions around the web

No comments yet