OSSC Pro: P-LM 576i passthrough gives distorted image

[Zacabeb]

When using pure LM and setting the output to passthrough with a 576i source sampled at default DTV timings, the output is scrambled including the menus. It basically appears as if some samples are missing and others are repeated in their place, unlike the normal 2:1 sample repetition of 576i/480i. This was observed with firmware 0.74 running the output through a Yamaha RX-V685 with image processing disabled, connected to a Sony KDL-40W3000 TV.

Note: This is partially resolved with firmware 0.75.

• This topic was modified 8 months, 3 weeks ago by Zacabeb. Reason: Added a note about fix made in firmware 0.75

[BuckoA51]

If you bypass the AVR does the issue go away?

[Zacabeb]

I bypassed the AVR and indeed it was the culprit. If I don’t misremember it accepted a passthrough signal from the OSSC Classic though at 576i so there is probably some difference in the signal it doesn’t like.

I don’t know how many people will use passthrough mode on the OSSC Pro, but it might be worth looking into nonetheless if the problem starts showing up across more modes.

[marqs]

Can’t reproduce this on my setup. Are you certain your AVR works with Classic in same mode?

[Zacabeb]

Yes, I tried it with the OSSC Classic to verify and it works fine (unmodded v1.6 with 0.90a firmware). So there’s some difference in the signal between it and the OSSC Pro that confuses the AVR.

Edit: Using 576i passthrough in A-LM mode, the AVR is perfectly happy.

[Zacabeb]

I figured I’d show what the error looks like. Eight R, G, B or Y, Cb, Cr samples are repeated twice and then eight samples are discarded. With a 480i signal I get no picture at all in P-LM mode with passthrough. Adjusting sync and backporch lengths does not make any difference. The HDMI TRX in the receiver just does not like the signal.

Also, the receiver’s OSD cannot be displayed, revealing that the problem occurs in the receiver and not the display. The receiver’s OSD is rendered in an FPGA and sent across with blanking, then superimposed by the HDMI TRX, as we’ll see later.

Note that the screenshot below is a photo as I don’t have a capture card.

Those stripes remind me of the original DOOM. Right-click or press and hold on your phone/tablet to open in a new tab to view the horror in detail.

So, what’s inside the receiver? Pretty much the same components as in all Japanese mid-range receivers at the time (2018-19). The main HDMI TRX is a Panasonic MN864787, which follows the HDMI 2.0 standard. This is accompanied by a Panasonic MN864788A HDMI switch. Finally, an Altera Cyclone IV FPGA handles OSD rendering as well as very basic de-interlacing and scaling. It’s actually the same version of the Cyclone IV as in the OSSC Classic, only in a different package and with 32 MB SDRAM attached.

When picture processing is disabled, the video does not pass through the FPGA. Instead the OSD is scaled and sent to the HDMI TRX along with blanking, allowing it to be superimposed into signals the FPGA picture processing can’t handle.

Since I made a diagram, I figured I’d add some trivia to it. Note the two unpopulated HDMI ports, something Yamaha decided on to avoid the RX-V685 cannibalizing sales of the RX-A880, which is otherwise the exact same product internally (aside from the European version also having a DAB tuner.)

Right-click or press and hold on your phone/tablet to open in a new tab to view the diagram at full resolution.

I’ve tried running the OSSC Pro directly through an input of the HDMI TRX itself, so the HDMI switch IC is innocent. As mentioned before, it’s perfectly happy with the output of A-LM and Scaler modes.

It would be interesting to know if other receivers from the same era and with the same HDMI TRX (Yamaha, Denon, Marantz around 2018) are affected.

What sample repetition mode does the OSSC Pro use in P-LM passthrough mode with standard definition input?

[marqs]

I think I found the issue, if you can call it like that. VIC ID does not currently get assigned for P-LM passthru modes so if some receiver relies on it (which unfortunately some do) instead of actual pixel repetition bits elsewhere.

[Zacabeb]

The strange thing is that the receiver accepts the output of the OSSC Classic in passthrough mode. I tested inputting a 576i signal to the OSSC Classic and changing the VIC from 0 to 21, 22, 25, 26, (with Full TX setup enabled) but the HDMI TRX in the receiver doesn’t even seem to care about whether or not the VIC corresponds to the actual timings (thus I imagine that sending the appropriate VIC on the OSSC Pro wouldn’t make a difference).

It could be a bug in the HDMI TRX itself rather than the OSSC Pro, but it’s an interesting phenomenon. Since it has no issues with the OSSC Classic it must be triggered by some metadata that differs between passthrough output of the OSSC Classic and OSSC Pro (or between P-LM and A-LM passthrough on the OSSC Pro). It might be a non-issue since standard definition P-LM passthrough isn’t particularly important given A-LM is working fine, but the issue might happen with other timings as well.

I wouldn’t be surprised if the HDMI TRX is to blame since there seems to be all sorts of issues with those (Panasonic/Nuvoton in particular).

Edit:

I’ve done some more testing, including using the OSSC Classic routed through the OSSC Pro via HDMI. The results are the same.

What I found though is that if I enable picture processing in the receiver, I get a different error altogether. When the FPGA in the receiver does picture processing, the HDMI TRX first converts the input to YCbCr 4:2:2 8 bpc, then sends it to the FPGA. Now the picture gets another error instead; all the pixels are there but the Cr samples get replaced with Cb, with the chroma samples interleaved. This makes the OSSC Pro menu turn from blue to magenta with a red border on the left edge and a blue border on the right edge. Hmm.

The same effect occurred regardless of whether the OSSC Pro was set to output RGB or YCbCr.

So there probably is something about the pixel repetition the HDMI TRX doesn’t like. But this is where things get weird, since it accepts the output of the OSSC Classic in passthrough mode and doesn’t even care what the VIC is set to. Maybe the PR bits are set wrong in P-LM passthrough mode on the OSSC Pro?

• This reply was modified 9 months, 1 week ago by Zacabeb. Reason: More findings, more confusion

[marqs]

On Classic changing default VIC only overrides modes which do not have explicit VIC set (i.e. VIC=0). 576i and other SD passthru modes have VIC set so the option doesn’t do anything with them.

[Zacabeb]

Thanks. I think that has solved the mystery. 🙂

[Zacabeb]

I’ve tried it now with firmware 0.75 and the issue is partially resolved. The HDMI TRX doesn’t scramble the picture anymore, but the receiver still freaks out if processing the picture and the horizontal backporch is an odd number; the Pb and Pr samples are swapped. That happens with the OSSC Classic as well. Curiously it doesn’t happen in A-LM mode. But I consider that issue to be caused by the video path in my receiver (and other mid-range receivers) not being particularly good. 🙂

Something I observed was that when processing, my receiver is convinced the picture is 16:9 but when it passes through my TV considers it 4:3. This is probably more problems with how the receiver handles VICs.

Anyway, it makes me wonder if P-LM and A-LM could be given an option whether to send out a 4:3 or 16:9 VIC for passthrough and 2x modes?

[marqs]

Trying to indicate aspect ratio in HDMI metadata would just open a can of worms. Not only is the VIC implicitly carrying picture aspect information (which btw is supposed to indicate 4:3 with 576i passthru), but there is another field called Picture Aspect Ratio which is assumed to match implicit VIC aspect when set, but it doesn’t even have all aspect options covered by the VICs. How all this potentially conflicting metadata is decoded varies by receiver, thus I would not rely on automation. I’d prefer leaving VIC unset as well but as you saw, some receivers completely freak out without it.

[Author]

Posts