> Well, its really starting to look like a cable length issue.
Don't know if for sure it is a cable problem, but you are certainly making the case that this is an opportunistic intermittent problem
> I *think* my PCs are DVI-A only (ATI Radeon 9800Pros), although hopefully they are DVI-I.
I have the ATI R9800Pro. It is DVI-I(DVI-D/DVI-A). All PC video cards with DVI port will have at least DVI-D and most often DVI-I, otherwise it would be much simpler for them to just use a standard D15 analog VGA port, which many cards do for one of the ports.
> I have also fired off an email to BlueJeans; not sure if there is anything they can suggest but figured it was worth a try.
I've heard stories of Blue Jeans sending a replacement cable for diagnostic purposes.
> Its just sooo odd that the majority of the information I found on the net that suggest cable length issues suggest dropouts and sparkles, yet I don't have either of those symptoms.
The highest bandwidth lines in the HDMI/DVI cable are the TMDS lines. If there is a cable problem the problem will most likely manifest itself on those lines. Due to the way TMDS is transmitted, this often results in very visible problems like sparkling, streaking, loss of video, full static, etc.
The DDC line used for negotiation is a much much lower bandwidth application and less subject (but not immune) to subpar cable issues. It is basically an i2c bus with 100 kHz clock.
> But something I want to point out is another thread I found which would seem to indicate that colorspace is transmitted coninuously, not only during initial communication between devices.
I don't think I said whether the colorspace was transmitted continuously or not. I said the colorspace is negotiated at the startup and Hot Plug Detect events (for most designs)
There are multiple aspects of the colorspace. The negotiation of what colorspace to use involves the DDC line. The source device interrogates the sink device for capabilities (EDID data) and figures out what video timings, colorspace, etc. to use. The EDID data is available at any time, but the design of most devices would only do the negotiation at startup time. So yes, in a sense the "colorspace" in this case is constantly available, but I would say it is selectively used in most designs and effectively only a startup/HPD issue.
After the negotiation the signal is sent on the TMDS lines. So you ask how does the sink device figure out what the source device has decided to use, RGB or YCbCr? Well there is something called an AVI (Auxiliary Video Information) InfoFrame. If AVI InfoFrame is missing the colorspace is assumed RGB. Otherwise, AVI InfoFrame contains information like Colorspace, Aspect Ratio, Pixel Repetition, etc. This InfoFrame packet is continuously being transmitted for HDMI sources. For DVI sources, it is optional. I cannot say for sure whether Oppo DVI implementation is definitely sending AVI InfoFrame, but it doesn't need to for everything to work since DVI is RGB only and AVI InfoFrames are optional for DVI/RGB only devices.
If an AVI InfoFrame is being sent, it is possible that the AVI InfoFrame is being corrupted, but even then I don't think it would be causing your issue because there is a checksum for the AVI InfoFrame and the fallback for corrupted AVI InfoFrame should be RGB or no video.
Another reason why you see many more references to sparkles or streaks is the video TMDS data does not use error correction or checksums. If there is an error, you see it on the screen very obviously. If your cable is having issues, it is most likely it'll happen on the high bandwidth connections and for data that doesn't use ECC. Video data fits the bill, and that is a big reason the problem reports are skewed the way they are.
> I am really starting to dislike "stright digital" connections. At least I can run composite, S-video, component, and VGA signals for hundreds of feet and still get a solid picture. In my case, I am trying to go a measly 30'. That really isn't very long when you take the time to "dress out" a cable so its hidden from view (in my case, inwall).
I think a big issue with HDMI is the added complexity of negotiation. The negotiation is necessary to maintain backward compatibility and to allow optional features. Also HDCP can complicate things even more. With analog, for the most part, both source and sink know exactly what they should be sending so everything is assumed and fixed in the initial design. Even if it isn't you are often forced to manually configure source and sink so they are expecting the same signals. There are examples of analog designs with autonegotiation, but usually not in AV applications.
When there is negotiation, you need to make sure both sides are on the same page and this is really an order of magnitude greater complexity then the fixed assumption model. It shouldn't be, but all specs in reality have areas that are left to interpretation, and even if they didn't, these things are implemented by people and they can make mistakes. If you tell someone, everytime you hear my voice, raise your right hand, then the likelihood of anyone making a mistake is low. Now if you instead tell them, if you hear "right", raise your right hand, if you hear "left", raise your left hand, then the chance of mistakes greatly increases. Besides the listener needing to make a decision of left or right hand, what happens when they hear a sound that isn't left or right?
Anyway, I hope that isn't too much information. You seem to have an engineering background and can pick things up pretty quick. I hope you find a solution to your problem or at least identify the culprit.
I've found with the complexity of the HDMI systems it is easy to come to the wrong conclusion because negotiations are 2-way and the problem can be on either side, or in the middle. Only by process of elimination coupled with understanding of how things are being implemented underneath the hoods can hope to achieve a definitive conclusion. I do agree that debugging analog AV systems is a simpler process.
