How do I accept and interpret handshake data from a 3D television?

I am developing a small device that will send stereoscopic video frames to a 3D-enabled HDTV with data from two analog video inputs, but I cannot find anyone (or even anyone who knows someone) who knows how the handshake data are formatted that pass between, say, an HDTV that supports active-shutter 3D frame display and a modern gaming console. In fact I don't even know where to begin to look for such information. The rest of the project is basically complete, including the microcontroller for the HDMI connection (which yet remains un-programmed). We just need to understand how to send the output to the display.

If anyone has experience or knows someone who has experience regarding this subject, please respond. Blindly snooping this data and experimenting with them seems like a waste of time, as does sifting through the unnumbered U.S. patents with "3D" in the title.

Thank you so much in advance for any clues or advice!

Hi!
I think you will have to reverse engineer the protocol yourself. If you take on a project this size, i assume you have access to a decent logic analyzer and digital oscilloscope, probe the communication between the TV and console. I think this would be your best bet on data on the protocol, since most of these protocols can only be requested with a large sum of money and the signing of an NDA (non-disclosure agreement).
I also highly doubt that a microprocessor would be fast enough to send the frames to the tv, may i ask what you are using? I would personally use an FPGA or DSP for these kind of applications.
Yours sincerely,
Boi

I did some calculations for you, i took an very low quality 3d tv as an example , 720p, 120Hz and a very low 8bit color depth.
That makes one image the size of 720*1280=921600 pixels, with 8bit colordepth a total image size of 921600*8=7372800 bits. This at 120Hz produces a data flowrate of about 7372800*120~=885Mb/s. An avarage microcontoller (20Mhz) would never reach that rate, even without framebuffering.

An excellent point! It is true we would not ask a $20 16Mhz Arduino or what-have-you to process two analog signals into a stream of bits flying at incomprehensible speed down the wire. Fortunately for us, the processing of the data and the bandwidth are both solved issues. As for our solution, I will be happy to share it as soon as our guy who developed it can explain it to me in terms I can understand. (Insert self-deprecating sigh here)

Thank you for your input. It saddens me to learn that we may need to add months of development time to backwards-engineering a data protocol and even then may risk a lawsuit by producing an unlicensed accessory. I guess I will shoot off a few emails to the Big Companies' PR people to inquire about their partnership policies.

If you are curious about what our product is, I would be happy to send you a Personal Message describing it.

A ok, as a suggestion i think you should send an email to hdmi.org first, maybe they are in a good mood and will send you the protocol Anyways, i wish you good luck with your endevours!
And yes, i sure am interested in your project, sounds like an original and challenging project!