I have used Just Add Power with Cisco switches on a few jobs and it works very well and provides almost unlimited in/out possibilties, I'd be interested to hear more about the SVSi stuff even though in my world video distribution is almost obsolete with the advent of on demand streaming. I wrote a module to control cisco switches port vlan association several years ago, I wonder if it world be usable with SVSi stuff too, I would imagine it works the same as JAP.
I have used Just Add Power with Cisco switches on a few jobs and it works very well and provides almost unlimited in/out possibilties, I'd be interested to hear more about the SVSi stuff even though in my world video distribution is almost obsolete with the advent of on demand streaming. I wrote a module to control cisco switches port vlan association several years ago, I wonder if it world be usable with SVSi stuff too, I would imagine it works the same as JAP.
Im hoping since SVSi is now an AMX/Harmon thing it will be Netlinx native very soon.
Is AMX producing their own line of managed switches for this? Since it's video over IP you have to assign access ports of displays to the vlan of the source, well that's how JAP works and I can't imagine any other way that SVSi could achieve IP routing other that changing the display vlan to match the desired video source vlan.
Is AMX producing their own line of managed switches for this? Since it's video over IP you have to assign access ports of displays to the vlan of the source, well that's how JAP works and I can't imagine any other way that SVSi could achieve IP routing other that changing the display vlan to match the desired video source vlan.
AMX Managed Switches: I don't know really. I hope not. Selling our clients a rebranded box with a sticker over the old logo for 25% more than they can buy the exact same box of New Egg just doesn't fly as a business model IMHO... Commercial clients just aren't that dumb. Yes, We saw the SVSi product at Developers Conf this summer and it was obvious that the network had to be rock-solid. It, obviously, needs a well designed VLAN with (most importantly) the necessary trunk line bandwidth to traverse the network. I know a lot of the training has to do with this. I've designed some pretty heavy-lifting networks many times. So, hopefully, I won't have any issues dealing with this.
So far, it seems like a good solution and the video quality is hanging in there. I really want to get a couple boxes and play with it a bit. If it's a good solution I would love to start implementing it verses using the mega-switchers. The other issue that needs to be dealt with is audio distribution and how that gets broken out and what kind of latency/sync issues we'll need to handle.
JAP works by assigning each stream to it's own VLAN and then switching the VLAN assignment on the switch. SVSi uses IGMP to allow end point to subscribe and unsubscribe from streams.
JAP works by assigning each stream to it's own VLAN and then switching the VLAN assignment on the switch. SVSi uses IGMP to allow end point to subscribe and unsubscribe from streams.
JAP requires igmp snooping too if I recall to subsribe to the stream and I can't imagine SVSi does its thing over a flat network so I would think it has to do vlan switching too. Does AMX have any online tutorials yet?
JAP requires igmp snooping too if I recall to subsribe to the stream and I can't imagine SVSi does its thing over a flat network so I would think it has to do vlan switching too. Does AMX have any online tutorials yet?
IGMP Snooping is one of those unfortunate terms that sounds much more ominous than it is. I find a lot of Network know-it-somes fear turning it on because it sounds bad or don't know what it does. There are ways to use it for a somewhat network hack if you are able to "walk" the SNMP tables. But all it really is is a nice way for the switch to make sure an endpoint member of the stream share is still there and manage the pipeline better. I will be curious to see how SVSi handles this.
IGMP Snooping is one of those unfortunate terms that sounds much more ominous than it is. I find a lot of Network know-it-somes fear turning it on because it sounds bad or don't know what it does. There are ways to use it for a somewhat network hack if you are able to "walk" the SNMP tables. But all it really is is a nice way for the switch to make sure an endpoint member of the stream share is still there and manage the pipeline better. I will be curious to see how SVSi handles this.
I think it's the word "snooping" that makes people think it's an invasion of privacy, kinda like a nosy neighbor or worse our big brother (NSA) screening our packets for nefarious intentions.
I think it's the word "snooping" that makes people think it's an invasion of privacy, kinda like a nosy neighbor or worse our big brother (NSA) screening our packets for nefarious intentions.
I suppose it's a better term that "IGMP Flaming Stick In The Eye"
JAP requires igmp snooping too if I recall to subsribe to the stream and I can't imagine SVSi does its thing over a flat network so I would think it has to do vlan switching too. Does AMX have any online tutorials yet?
Through the use of certain protocols, the multicast traffic can be switched and routed to wherever it is needed without ever affecting your network performance. SVSi uses IGMP (Internet Group Management Protocol) for the control of AV traffic within a network. The two functions of IGMP used are: IGMP Snooping ? This is a form of port based packet inspection that identifies that the packets generated from an encoder are in fact multicast. IGMP Snooping Querier ? The querier acts as a central control mechanism (using the information gathered by IGMP Snooping) to direct multicast traffic to only the requested ports where decoders reside. If the AV network will span multiple subnets or VLANs, a second control can be implemented. PIM (Protocol Independent Multicast) allows for the sending of multicast across any subnet and/or VLAN where PIM is enabled.
So no, SVSi doesn't use VLANs for switching like JAP.
So no, SVSi doesn't use VLANs for switching like JAP.
thanks for the link. Through one link to another I ended up back at AMX and saw their line of Cisco switches which turns out to be the Cisco SG300 or 500 series which are the switches I've been using for the last few years. I recently updated the module I wrote for the 2960 switches to control JAP to control the SG300 just because one client didn't want wi-fi on 24/7 so I used the mod to turn off the POE ports that fed the access ports. The SG300/500 don't use the same IOS commands as the enterprise class of switches but are decent layer 3 switches with more settings and capabilities then I'll ever understand.
FYI, after much complaining Cisco corrected some of their DHCP issues on these switches where if you enter a mac in the static table but the client responded with a client id instead (usually 01 + mac) it wouldn't provide it an IP and if you assumed a 01 + MAC client ID and the client sent a MAC it wouldn't receive an IP. For over year if you wanted to setup static binds you would have to put all the devices on the network and 1st see how they responded before adding them to the static table, a real PITA especially if you had all the macs before hand. There were other issues but most of them have been corrected too.
thanks for the link. Through one link to another I ended up back at AMX and saw their line of Cisco switches which turns out to be the Cisco SG300 or 500 series which are the switches I've been using for the last few years.
Yea, you still need a layer three switch which is what you need for JAP, SVSi just does the streaming in a different (they claim better, but I've never seen a head to head comparison) way.
It seems to me using vlans would be better just to isolate broadcast domains to only interested parties (clients and servers) unless their intent is just using a single vlan for video dist on a dedicated switch and then using inter vlan routing (SVI) to allow for control from a another vlan on another switch that hosts the AMX master and UIs and any other non video streaming servers/clients. Otherwise why use a layer 3 switch?
I'd love to go to the training to play and learn but I don't see an opportunity to use these in the foreseeable future.
I'd love to go to the training to play and learn but I don't see an opportunity to use these in the foreseeable future.
My thinking is that I'd like to see this replace large frame video switching. i work in some situations where dealing with those big behemoths is costly and a pain. I'd like to see a solution that doesn't require a complete re-wire when the client wants to make a little change in the configuration or something that is more scaleable. I can put in a pretty beefy network for less than the cost of a big switcher system in many cases. If the quality and latency and reliability are up there, I'm pretty stoked about the possibilities.
My thinking is that I'd like to see this replace large frame video switching. i work in some situations where dealing with those big behemoths is costly and a pain. I'd like to see a solution that doesn't require a complete re-wire when the client wants to make a little change in the configuration or something that is more scaleable. I can put in a pretty beefy network for less than the cost of a big switcher system in many cases. If the quality and latency and reliability are up there, I'm pretty stoked about the possibilities.
They're also much easier to scale by just adding another switch more encoders or decoders. If you need 4 sources and 9 displays you don't need to get a 12 or 16 out switcher, you buy exactly what you need and then add exactly what you need down the road if needed.
It seems to me using vlans would be better just to isolate broadcast domains to only interested parties (clients and servers) unless their intent is just using a single vlan for video dist on a dedicated switch and then using inter vlan routing (SVI) to allow for control from a another vlan on another switch that hosts the AMX master and UIs and any other non video streaming servers/clients. Otherwise why use a layer 3 switch?
With SVSi the video all lives on a single VLAN.
The way SVSi explained it to me, and it's possible I'm regurgitating this incorrectly, is that the JAP method relies on making changes to the network switch itself anytime you need to make a video switch. SVSi's method of doing it only requires that the end point request a different stream from the switch and nothing changes on the switch itself.
Again, I've never seen a head-to-head comparison with JAP (which I have also used), but I have used SVSi and it certainly works as advertised.
Properly managed igmp snooping in the router/switch _should_ isolate the multicast streams to only deliver the single stream that a given client is accessing at any time.
Here's decent video discussing igmp. There's a lot of chatter going on which is why it would be best to have the video dist on its own broadcast segment or vlan. Itobviously doesnt have to be but it makes for a happier network which is the whole point of minimzing or isolating broadcast domains.
This whitepaper from Insight Media may also be of interest. Although it focusses on the AptoVision chips and ZeeVee implementation when they start talking about packet-switched 4K distribution networks, a lot of the theory applies to the SVSi gear albeit with different compression.
Nope. It'll work with a layer-3 switch with IGMP or a layer-2 if you want to do some VLAN switching (similar to JAP).
P.S. AVB changed it's name over to TSN (time-sensitive networking) to reflect the task groups shift in focus to general application of the tech.
FYI, the cisco SG300 or SG500 switches can be initially set to be layer 3 or 2. VLAN switching and igmp can be used in either layer but inter vlan routing (SVI, switch vlan interface) can only be done in layer 3 mode. There are other features that differ between the layer mode used too.
The training went well. (At least I passed the test anyway...)
Some things...
The class had quite a few AMXers, mostly integrators and a few NASA engineers. (And yes - they were indeed wearing pocket protection - i s@%*t you not..)
The technology seems pretty solid and well-thought-through. Most who were already using it said there were only one or two 'gotchas' that were specific with the SVSi side. (Basically a couple settings that one can often forget to click over after setup that trip you up) If there were any common trouble spots to implement it had to do with the IP Network infrastructure. They did provide pretty full service network config if you buy the hardware from them. It comes fully configed and ready to go. Didn't get any prices for it but by all counts there seemed to be some push-back from clients who can buy the same gear for less. But they then spend more time/resources getting it configured correctly - thus making the initial cost not seem so bad after all.
SVSi has its own control interface via either a in-wall keypad/touchpanel that is fairly programmable via Java Script. It's one of those things that for basic control it was fine, but for more complex integration it got weird fast. But, for the most part - basic control can be done without a control system. The matrixing is very simple and completely grainular. just grab what sources and endpoints you need, throw them on the network and start matrixing. It expands and contracts with no effort other than adding another box.
The video quality is good with little artifacting. Home Theater quality??? Not really. but, I'd install it as a distributed video solution with no shame at all.
On the AMX/SVSi/Harmon angle - You can tell they are getting used to the idea that they are now part of Harman and that AMX is going to have a big say in what they look like in the future. They don't seem to mind it much and look forward to it. But, there are those pregnant pauses in conversations as you can tell they're thinking hard on their feet just how to phrase things.
My takeaway is the system is really good and I can see abandoning the large frame switches for commercial video distribution. It's just much more simple to manage and much less hardware dependent. Plus, IT people seem to get it better. My big worry was audio-only issues, and they had a box for that. In fact, the streams can be fed directly into the QSC Audio DSP with no box needed inbetween.
While the control interface/API is not difficult, I do really hope they make the whole mess Netlinx Native. If not, I'll just write a module and call it good. One thing to pass on that we programmers should keep in mind: Yes-you can control the individual Encoders/Decoders from AMX. Each box does come with a serial and IR port to control whatever it is they are connected to. They also have a IP Passthrough as well. BUT - it is very much advised that you include their server box that acts as a gateway for control. To mainting a large number of IP ports on the AMX side can be a bit much. It's much easier to just talk to one box and let it act as the operator to get the message to the right box. Plus feedback is much more streamlined. There are two flavors of server (I think the model numbers were 8001 and 8002) The smaller only allows for 50 devices and 5 butts in the seat. The latter is unlimited/unlimeted.
In both cases neither box added that much to the overall bid. If you're doing over 50 sources/endpoints another box is not going to make a blip on the radar.
So, my overall reaction is very positive. I all works as promised and I cannot see any fatal gotchas lurking in the wings. They've deployed some enormous systems (well over 5000 sources/endpoints) and I've checked with the clients and they are all smiles. The staff are all young and hungry and positive.
I had someone from SVSi tell me a few weeks back that they had already made their stuff Netlinx Native. Is that not the case?
Well, the answer is no. but, perhaps I better define my terms. By Netlinx native I mean that when you plug in an SVSi box (encoder, decoder, etc...) it connects to an AMX master and shows up as a netlinx device.
So, having set this table, If that is what we are talking about, we were not shown any such thing. Here again, what was there was quite useable and nothing problematic. I hope what you say is true as I tend to like to feel like AMX does a pretty good job of managing the connection of stuff and the less I have to manage the comms in code, the better my day seems to go.
Well, the answer is no. but, perhaps I better define my terms. By Netlinx native I mean that when you plug in an SVSi box (encoder, decoder, etc...) it connects to an AMX master and shows up as a netlinx device.
So, having set this table, If that is what we are talking about, we were not shown any such thing. Here again, what was there was quite useable and nothing problematic. I hope what you say is true as I tend to like to feel like AMX does a pretty good job of managing the connection of stuff and the less I have to manage the comms in code, the better my day seems to go.
It's possible that the SVSi person I talked to had a different understanding of Netlinx native than you and I do.
I've used SVSi with AMX in the past and never had any issues controlling it. Trying to use the SVSi internal panel building application though, let's say I'll be happy to never do that again.
ericmedley
Posts: 4,177
Comments
Enjoy the BBQ!!!!!
AMX Managed Switches: I don't know really. I hope not. Selling our clients a rebranded box with a sticker over the old logo for 25% more than they can buy the exact same box of New Egg just doesn't fly as a business model IMHO... Commercial clients just aren't that dumb. Yes, We saw the SVSi product at Developers Conf this summer and it was obvious that the network had to be rock-solid. It, obviously, needs a well designed VLAN with (most importantly) the necessary trunk line bandwidth to traverse the network. I know a lot of the training has to do with this. I've designed some pretty heavy-lifting networks many times. So, hopefully, I won't have any issues dealing with this.
So far, it seems like a good solution and the video quality is hanging in there. I really want to get a couple boxes and play with it a bit. If it's a good solution I would love to start implementing it verses using the mega-switchers. The other issue that needs to be dealt with is audio distribution and how that gets broken out and what kind of latency/sync issues we'll need to handle.
JAP works by assigning each stream to it's own VLAN and then switching the VLAN assignment on the switch. SVSi uses IGMP to allow end point to subscribe and unsubscribe from streams.
My understanding is that this has already happened.
IGMP Snooping is one of those unfortunate terms that sounds much more ominous than it is. I find a lot of Network know-it-somes fear turning it on because it sounds bad or don't know what it does. There are ways to use it for a somewhat network hack if you are able to "walk" the SNMP tables. But all it really is is a nice way for the switch to make sure an endpoint member of the stream share is still there and manage the pipeline better. I will be curious to see how SVSi handles this.
I suppose it's a better term that "IGMP Flaming Stick In The Eye"
From here: http://svsiav.com/solutions/it-professional-qa/
So no, SVSi doesn't use VLANs for switching like JAP.
FYI, after much complaining Cisco corrected some of their DHCP issues on these switches where if you enter a mac in the static table but the client responded with a client id instead (usually 01 + mac) it wouldn't provide it an IP and if you assumed a 01 + MAC client ID and the client sent a MAC it wouldn't receive an IP. For over year if you wanted to setup static binds you would have to put all the devices on the network and 1st see how they responded before adding them to the static table, a real PITA especially if you had all the macs before hand. There were other issues but most of them have been corrected too.
Yea, you still need a layer three switch which is what you need for JAP, SVSi just does the streaming in a different (they claim better, but I've never seen a head to head comparison) way.
I'd love to go to the training to play and learn but I don't see an opportunity to use these in the foreseeable future.
My thinking is that I'd like to see this replace large frame video switching. i work in some situations where dealing with those big behemoths is costly and a pain. I'd like to see a solution that doesn't require a complete re-wire when the client wants to make a little change in the configuration or something that is more scaleable. I can put in a pretty beefy network for less than the cost of a big switcher system in many cases. If the quality and latency and reliability are up there, I'm pretty stoked about the possibilities.
With SVSi the video all lives on a single VLAN.
The way SVSi explained it to me, and it's possible I'm regurgitating this incorrectly, is that the JAP method relies on making changes to the network switch itself anytime you need to make a video switch. SVSi's method of doing it only requires that the end point request a different stream from the switch and nothing changes on the switch itself.
Again, I've never seen a head-to-head comparison with JAP (which I have also used), but I have used SVSi and it certainly works as advertised.
https://youtu.be/GGqcwdDW1a8
http://www.amx.com/products/categoryMinimalCompressionVideooverIP.asp
P.S. AVB changed it's name over to TSN (time-sensitive networking) to reflect the task groups shift in focus to general application of the tech.
FYI, the cisco SG300 or SG500 switches can be initially set to be layer 3 or 2. VLAN switching and igmp can be used in either layer but inter vlan routing (SVI, switch vlan interface) can only be done in layer 3 mode. There are other features that differ between the layer mode used too.
Some things...
The class had quite a few AMXers, mostly integrators and a few NASA engineers. (And yes - they were indeed wearing pocket protection - i s@%*t you not..)
The technology seems pretty solid and well-thought-through. Most who were already using it said there were only one or two 'gotchas' that were specific with the SVSi side. (Basically a couple settings that one can often forget to click over after setup that trip you up) If there were any common trouble spots to implement it had to do with the IP Network infrastructure. They did provide pretty full service network config if you buy the hardware from them. It comes fully configed and ready to go. Didn't get any prices for it but by all counts there seemed to be some push-back from clients who can buy the same gear for less. But they then spend more time/resources getting it configured correctly - thus making the initial cost not seem so bad after all.
SVSi has its own control interface via either a in-wall keypad/touchpanel that is fairly programmable via Java Script. It's one of those things that for basic control it was fine, but for more complex integration it got weird fast. But, for the most part - basic control can be done without a control system. The matrixing is very simple and completely grainular. just grab what sources and endpoints you need, throw them on the network and start matrixing. It expands and contracts with no effort other than adding another box.
The video quality is good with little artifacting. Home Theater quality??? Not really. but, I'd install it as a distributed video solution with no shame at all.
On the AMX/SVSi/Harmon angle - You can tell they are getting used to the idea that they are now part of Harman and that AMX is going to have a big say in what they look like in the future. They don't seem to mind it much and look forward to it. But, there are those pregnant pauses in conversations as you can tell they're thinking hard on their feet just how to phrase things.
My takeaway is the system is really good and I can see abandoning the large frame switches for commercial video distribution. It's just much more simple to manage and much less hardware dependent. Plus, IT people seem to get it better. My big worry was audio-only issues, and they had a box for that. In fact, the streams can be fed directly into the QSC Audio DSP with no box needed inbetween.
While the control interface/API is not difficult, I do really hope they make the whole mess Netlinx Native. If not, I'll just write a module and call it good. One thing to pass on that we programmers should keep in mind: Yes-you can control the individual Encoders/Decoders from AMX. Each box does come with a serial and IR port to control whatever it is they are connected to. They also have a IP Passthrough as well. BUT - it is very much advised that you include their server box that acts as a gateway for control. To mainting a large number of IP ports on the AMX side can be a bit much. It's much easier to just talk to one box and let it act as the operator to get the message to the right box. Plus feedback is much more streamlined. There are two flavors of server (I think the model numbers were 8001 and 8002) The smaller only allows for 50 devices and 5 butts in the seat. The latter is unlimited/unlimeted.
In both cases neither box added that much to the overall bid. If you're doing over 50 sources/endpoints another box is not going to make a blip on the radar.
So, my overall reaction is very positive. I all works as promised and I cannot see any fatal gotchas lurking in the wings. They've deployed some enormous systems (well over 5000 sources/endpoints) and I've checked with the clients and they are all smiles. The staff are all young and hungry and positive.
I had someone from SVSi tell me a few weeks back that they had already made their stuff Netlinx Native. Is that not the case?
Well, the answer is no. but, perhaps I better define my terms. By Netlinx native I mean that when you plug in an SVSi box (encoder, decoder, etc...) it connects to an AMX master and shows up as a netlinx device.
So, having set this table, If that is what we are talking about, we were not shown any such thing. Here again, what was there was quite useable and nothing problematic. I hope what you say is true as I tend to like to feel like AMX does a pretty good job of managing the connection of stuff and the less I have to manage the comms in code, the better my day seems to go.
It's possible that the SVSi person I talked to had a different understanding of Netlinx native than you and I do.
I've used SVSi with AMX in the past and never had any issues controlling it. Trying to use the SVSi internal panel building application though, let's say I'll be happy to never do that again.