You may want to visit the thread in the manufacturer's section on IP that covers this in more detail.

Alan

 Digital Coaxial audio is a very hearty signal and can be distributed via distribution amplifiers or even a Composite video matrix over coax for hundreds of feet without issues. The problem that no one has seemed to address is the restrictions on digital audio outputs when HDCP is in play. I know in my area that when an HDMI cable is connected to the Cable Box the digital audio outputs are restricted to stereo audio. This product is a great solution for video distribution where multichannel audio is not needed. I have been told that this is not a limitation of the hardware and will most likely be addressed via firmware in the future. 

 My suggestion would be to use players with multichannel analog outputs the the surround receivers. If you centralize everything in racks this should be a really simple task as you can split the signal 3 or 4 times without the need for distribution amplifiers. Just be aware that if you use a receiver that dead shorts the inputs when it is powered down you will need a DA. Even if the equipment is remotely located you can use line level cable that is very inexpensive to distribute the signal.

this is the first i've heard of that.  Cox communications/Scientific Atlanta Explorer HD 8300 here in Phoenix, what company/cable box are you using?

Ya even though the 8300s are giant POSes they still actually output everything on every port

Actually it doesn't :). I had read that page multiple times and saw the same confusing mix of "lossless" and "virtually lossless" there that I see peppered in these posts. To someone who understands the science, it seems jarring to see the the play with the terminology that way. Just stay with nearly lossless and you are good to go.

Minor nit but do you mean patent pending technology or patented? I have seen a similar approach to video compression by another company who says their scheme is patent pending and I am curious who is going to get there first :).


I plan to be there. Will you have any test BD discs so that we can see the actual frequency response of the device or will you just be playing movies?

yeah they do, but it's a POS indeed.  not to go way off topic, but i have literally seen a poor Cox monkey wait 45 minutes for one of these abominations to activate.  it's happened to me too, but i just figured i did something wrong.  needless to say, the guy asked me for a job.

Name the test BD disc(s) you prefer (preferably with a link to where they are readily available), and I will do my best to purchase them in the next week. You are also welcome to BYOB (bring your own blu-ray)!

is this still slated to ship next month?

I'd suggest everyone buy a few and try it out. You still offer a 30 day trial right?

WTF does anyone have to loose?

Joe Kane's DVE BD disc would do. Thank you for the openness by the way. Shows that you are willing to prove your merits :).

Is Ethernet available as well as HDMI? Or is this RJ-45 just passing HDMI?

Alan

Their solution is 100% "Ethernet." See what happens Stamp when you ask people to skip over the explanation of what is really going on? :D

The product takes video over HDMI, extracts the video data, compresses it and transmits it over IP protocol similarly to how you want video on the web. The packets are then transmitted over Gigabit Ethernet. Since the data looks like any other Ethernet traffic, a standard switch can be used just the same.

They require managed switch as to allow you to change the routing (but otherwise, should work with any switch). And use multicast (broadcast) streaming as to eliminate having to send a bunch of parallel streams to every receiver.

The reverse happens in the receiver where data is received, decompressed and then output as real-time video over HDMI.

So the notion of HDMI only exists at the end-points. This is VERY different approach from current HDMI "baluns" where the HDMI signal is transformed physically in how it goes down the cat-5//cat-6, but otherwise, is left intact. There is total isolation here and the constraints are the same as any other data connection to and from the switch, not any baggage from HDMI spec.

I know the 2960 is layer 2 and believe the rest of your posted switches are as well. So how do you recommend the network be configured for these vlans? What device is actually doing the vlan switching? Do you recommend core switches for this? Or are you saying that the layer 2 switches posted above are sufficient and somehow manage the vlans?

Also, do you find that bringing a product like this to the CE market that requires a HUGE amount of network understanding causes additional problems and calls from dealers that need networking help?

Do you like the 2960 because of the CLI or would one of the ESW switches work?

Thanks.

The recommendation is to put their gear on a separate vLan. Obviously they are using Ethernet protocol to send the compressed data to the receiver and require a managed network to insure QoS. But can this signal also carry standard Internet as well. That has not been made clear, though it's implicit in the technology.

"There is total isolation here and the constraints are the same as any other
data connection to and from the switch, not any baggage from HDMI spec"

Is there an NIC on the JAP receiver that would allow you access to standard Ethernet or is a second managed switch required for this? Again, standard on just about every 1.4 compliant product I am aware is all of the above. JAP?

Any number of 1.4 compliant solutions--Crestron DM and all manor of baulins-- will provide uncompressed video, uncompressed Dolby HD digital audio, control and Ethernet--as in Internet. With JAP you get companded video ( indistinguishable from uncompressed digital video), PCM audio and? The HDMI protocol is more than digital video and uncompressed 5.1 ch audio.


The issue is not a managed switch, vLans, QoS, nor the particular mode of data transfer. Uncompressed Dolby HD is not part of the data stream. Companded video is part of the data stream. What of the rest of the HDMI protocol? Getting workable video to the far end is the main goal. But what else has JAP left out?

You might want to remind readers that multi-cast or broadcasts do not cross vLans. This is damned well going to be a problem if you are expecting to get control protocols from your processor on the AV vLan on to the display on the JAP vLan. Given the prevalence of NICs on displays forgive me for breaking into the unpaid advertising love fest with a few pertinent questions.

And please note that once more JAP is once more playing fast and lose with admitting HDCP compliance. Their solution DOES NOT allow source and display to "see" each other and negotiate the handshake. Rather the source sees the JAP transmitter and the JAP receiver the transmitter and the destination. The handshake is negotiated between receiver and destination, not by source and destination. My gut suggests that JAP was not the first to look at this mode of data transfer for HDMI. They were merely the only ones to conclude that this mode of negotiation was legal.

JAP has been intentionally cagey on the legality of their solution. Till they do I suggest caution. Caveat emptor.

Alan

I can get you intouch with smart guys @ Cox if you like. I have never had a client need to call cox for anything. If you need support or a new install regardless you get a cox employee and not a 3rd party idiot. I send an email to the guy and what ever i need gets done in a few hours. Its awesome

Each transmitter resides on its own vlan. When a receiver gets set to that vlan it displays what ever is being broadcasted on that vlan.

the Dell switches to me work the best