HDMI protocol analyzer complains about: "Invalid combination" Q1/Q0, Y1/Y0, YQ1/YQ0
Closed this issue · 18 comments
First of all, let me send my personal warmest THANK YOU for creating this awsome HDMI framework. 😃 🙇♂️
You helped the MEGA65 project a lot with your work (https://www.mega65.org/ and see blog entry from @gardners blog: https://www.mega65.org/) and see also the Game Boy for MEGA65 project (https://github.com/sy2002/gbc4mega65/tree/develop) that I am doing together with @MJoergen: All of us are using your work. (Please double check if this AUTHORS mention is OK for you: https://github.com/sy2002/gbc4mega65/blob/develop/AUTHORS#L53)
**The good news first: Everything works like a charm. We do not experience any bugs or problems on any real TV or Monitor. And we tested some quity picky exemplars 😆 Even the old HDMI framegrabber works. **
BUT...
At the gbc4mega65 project, we use 720p @ 60 Hz and 48 kHz sound (and it works like a charm on every TV and monitor) but the HDMI protocol analyzer complains about: "Invalid combination" Q1/Q0, Y1/Y0, YQ1/YQ0. Looks like you are using a "reserved" bit combination: Please search for error in the attached TXT file (20210620100612.txt) to learn more. Here is a quick excerpt from the Analyzer's output:
Test ID 7-23 : Pixel Encoding - RGB to RGB - only Sink
- Verify that an AVI InfoFrame is transmitted on every two video fields.
Q1/Q0 = 10(Full Range), Y1/Y0 = 00(RGB).
Video Format = 1280x720(VIC04).
Invalid Combination : Error.
YQ1/YQ0 = 10(Reserved)
Error
- Verify that any transmitted AVI InfoFrame is correct and indicates RGB pixel Encoding.
Pass
Test ID 7-23 AVI InfoFrame : PASS
- Verify that transmitted video uses RGB pixel encoding.
Test ID 7-23 : FAIL
--
Test ID 7-24 : Pixel Encoding - RGB to RGB - only Sink
- Verify that an AVI InfoFrame is transmitted on every two video fields.
Q1/Q0 = 10(Full Range), Y1/Y0 = 00(RGB).
Video Format = 1280x720(VIC04).
Invalid Combination : Error.
YQ1/YQ0 = 10(Reserved)
Error
- Verify that any transmitted AVI InfoFrame is correct and indicates RGB pixel Encoding.
Pass
Test ID 7-24 AVI InfoFrame : PASS
- Verify that transmitted video uses RGB pixel encoding.
Test ID 7-24 : FAIL
Since everything works fine, I would not consider this issue very urgent - but on the other side, it would be "nicer", "better" if we were fully HDMI compliant.
P.S. FYI just in case you need them: Here are our timing settings: https://github.com/sy2002/gbc4mega65/blob/develop/MEGA65/vhdl/video/video_modes_pkg.vhd#L50
@sy2002 Thankyou for your kind words, I have great respect for the MEGA65 project and am very happy that my IP is helpful to you and the team.
And thankyou for this detailed report. I will investigate and correct this problem. I am very busy for the next 2 weeks but should be able to get to it after that.
@amb5l we have the HDMI protocol analyser all working again here, so please let me know if you want anything tested on it. I have a variety of FPGA boards here that I can load bitstreams on when the need arises.
Paul.
@amb5l Thank you for your support! I merged the fix into our codebase and now (over night, while I am sleeping) I will re-synthesize the Game Boy Color for MEGA65 core (gbc4mega65).
It takes ~2hrs ;-) So tomorrow, I will send the bitstream to @gardners to test it. Curious to learn, if it fixes the issue ;-)
(@MJoergen: FYI - if it works, I will also merge it to the MiSTer2MEGA65 framework.)
I'm on the road for a couple of days, but will test it on the analyser on my return.
@gardners Here is the bitstream that is supposed to solve "HDMI protocol analyzer complains about: "Invalid combination" Q1/Q0, Y1/Y0, YQ1/YQ0"
[EDIT: DELETED OLD BITSTREAM]
@amb5l The fix did not seem to work: We are still getting some invalid combination error (but this time another one as before):
Test ID 7-23 : Pixel Encoding - RGB to RGB - only Sink
- Verify that an AVI InfoFrame is transmitted on every two video fields.
Q1/Q0 = 10(Full Range), Y1/Y0 = 00(RGB).
Video Format = 1280x720(VIC04).
Invalid Combination : Error.
YQ1/YQ0 = 01(Full Range)
Pass
- Verify that any transmitted AVI InfoFrame is correct and indicates RGB pixel Encoding.
Pass
Test ID 7-23 AVI InfoFrame : PASS
- Verify that transmitted video uses RGB pixel encoding.
Test ID 7-23 : FAIL
--
Test ID 7-24 : Pixel Encoding - RGB to RGB - only Sink
- Verify that an AVI InfoFrame is transmitted on every two video fields.
Q1/Q0 = 10(Full Range), Y1/Y0 = 00(RGB).
Video Format = 1280x720(VIC04).
Invalid Combination : Error.
YQ1/YQ0 = 01(Full Range)
Error
- Verify that any transmitted AVI InfoFrame is correct and indicates RGB pixel Encoding.
Pass
Test ID 7-24 AVI InfoFrame : PASS
- Verify that transmitted video uses RGB pixel encoding.
Test ID 7-24 : FAIL
There are more details, please also have a look at the HDMI Analyzer's log file:
Analyzer-Output-210711.zip
OK sorry about this. A bit of trial and error is required. The latest commit (3dd4f8) to the fix-issue-1 branch uses the following:
- Y1/Y0 = 00b (RGB)
No change. Other possible values are 01b (YCbCr 4:2:2), 10b (YCbCr 4:4:4), 11b (YCbCr 4:2:0).
- Q1/Q0 = 00b (default, depends on video format).
Changed from 10b (full range). Other possible values are 01b (limited range) and 11b (reserved).
CTA 861 G states "A Source shall not send a non-zero Q value that does not correspond to the default RGB Quantization Range for the transmitted Picture unless the Sink indicates support for the Q bit in a Video Capabilities Data Block".
- YQ1/YQ0 = 01b (full range)
No change. Other possible values are 00b (limited range), 10b (reserved) and 11b (reserved).
CTA 861 G states "When transmitting any RGB colorimetry, the Source should set the YQ-field to match the RGB Quantization Range being transmitted (e.g., when Limited Range RGB, set YQ=0 or when Full Range RGB, set YQ=1) and the Sink shall ignore the YQ-field".
Commit b98fe3 tested on Nexys Video -> Asus PG348Q. All OK.
I merged the fix into the gbc4mega65 project, but regarding the LFEBL vs LFEPB question (see issue #4) I kept Paul's version (LFEBL), because I was not sure what to do.
So @gardners : Please take the bitstream from this comment and check with the HDMI analyzer: "Is the Invalid combination Q1/Q0, Y1/Y0, YQ1/YQ0" gone now?
Clarification: For not mixing up things, I did not try to fix issue #2 or issue #3 with this bitstream. Step by step... So I just focused on Adam's commit b98fe33 with the goal to fix the issue at hand.
Here is the bitstream:
[... EDIT: DELETED OLD BITSTREAM ... ]
IMPORTANT: Debug version with only 256 kB of Cartridge RAM. Test Super Mario or Tetris.
I'll try to squeak a bit of time today to look at this.
Paul.
Commit b98fe3 tested on QMTECH Wukong -> Asus PG348Q. All OK. Bit file attached. Press SW3 3 times to cycle from mode 0 to mode 3 (720p60).
hdmi_tpg_qmtech_wukong.zip
OK we still have error reports from the analyser (thank @gardners) relating to Y/Q/YQ. Let's try YQ = 00b even though that is not correct. Some developers out there have seen this issue with HDMI 1.x sinks not liking non-zero YQ values for RGB sources. See commit edc995.
Note there are other error reports to resolve. Future commits will work through these.
@amb5l Thank you. Just so that we are on the same page: You did receive this logfile from the analyzer?
20210714015124.txt
[ EDIT: Removed old bitstream ]
This comment contains a bitstream that attempts to fix both: Issue #1 and Issue #5:
#5 (comment)
@gardners I merged the fix. Here is the newest bitstream.
The bitstream that attempted to fix both - issue #1 and #issue #5 - seemed to have fixed issue #1:
See this logfile from the HDMI analyzer: #5 (comment)
It only complains about issue #5 (plus it still complains about issue #2, but this was expected, as we did not tackle issue #2, yet).
So I think it is fair to close this issue.