Amx / crestron ndi driver

[Simos]

HI,
I 'd like to develop an AMX/CRestron driver to capture/send and process NDI device discovery and routing commands via AMX/CRESTRON.
E.g. So I can remotely switch which NDI source a Projector displays (Equipped with an NDI decoder).

Is the Protocol available at the Network/Transport Level to implement this?
This would convert the AV Market to NDI overnight, so I hope it is.

Cheers
Simo

[livepad]

HI,
I 'd like to develop an AMX/CRestron driver to capture/send and process NDI device discovery and routing commands via AMX/CRESTRON.
E.g. So I can remotely switch which NDI source a Projector displays (Equipped with an NDI decoder).

Is the Protocol available at the Network/Transport Level to implement this?
This would convert the AV Market to NDI overnight, so I hope it is.

Cheers
Simo

Sienna NDI Router has been used with both Crestron and AMX controllers at numerous large installations all over the world including The Ford Foundation building, the International Olympic Committee HQ and the new Goldman Sachs building in London.

In all cases, the systems integrators created custom integration between the AMX or Crestron and one of the native control protocols supported by the NDI Router (it supports ProBel SWP-08, BlackMagic VideoHub protocol and HTTP REST protocol).

I believe that Extron supports BMD VideoHub natively so that one is easy, but its not clear whether there are commercially available off the shelf drivers for AMX and Crestron and one of the above protocols. So perhaps there is a market for a standard control module.

You are absolutely right that this capability transforms the AV market to NDI - and whilst the human control surfaces in these installations are still commonly AMX and Crestron, the cameras, scan converters and other video capture, display end points and routing systems (and of course Vision Mixers) are now more commonly NDI.

http://www.sienna-tv.com/ndi/ndirouter.html

[Simos]

Thanks for the reply And I understand there are several 3rd party NDI software packages that do NDI routing that have their own API so any Automation solution can can then communicate with the 3rd party software to send the routing software their route commands... be it AMX, Crestron, Arduino.. hell anything that has the capability to open a udp/TCP socket and send the required bytes / protocol in the Appropriate format and order ( protocol) to make the software do an NDI route Change....(html rest api/ telnet/ssh etc etc)........


My point is if NDI made this part of the NDI protocol open at a byte level like so many other AV devices, we wouldnt need the 3rd party software....And it wouldnt matter what brand or type of NDI decoder you had. If its NDI compliant the device will understand the route command.


We,d open a UDP/TCP connection from AMX Crestron, Arduino..what ever...direct to the NDI decoder and send the correct bytes (protocol) that NDI decoders require to make the NDI decoder switch its soruce NDI stream to the Ip address Or name of another NDI source......

We do this now to communicate and send route commands to every other vendors sdi/hdmi/ matrices.. we don't need an intermediary.

AMX / Crestron /whatever drivers start with the protocol of byte order made public by the vendor. You dont need an amx/crestron driver to control a device, it's just a nice to have.


ALot of AMX programmers prefer not use the drivers and just send raw ints/chars/longs/HEX/Decimal/ascii/html/xml..what ever is specified by the vendor of a product to be controlled..

But without a known protocol..you can't do it.... I guess I could use Wireshark and work it out for myself.. but I'd prefer not to.

[livepad]

We do this now to communicate and send route commands to every other vendors sdi/hdmi/ matrices.. we don't need an intermediary.

NDI is not a matrix. Its the equivalent of a single SDI or HDMI *Cable*
You need an intermediary to create your 'matrix' before you can control it.

[Simos]

NDI is not a matrix. Its the equivalent of a single SDI or HDMI *Cable*
You need an intermediary to create your 'matrix' before you can control it.

Depends on how you open your mind to it.....

AN NDI endpoint understands a common set of data being sent to them to switch to another stream via the SDK, so I'd argue that the act of a "Matrix / Router" is now native to NDI.. if you choose to access that feature
set built into every NDI endpoint.

You can send Route commands to an NDI endpoint via the SDK , so your software becomes the matrix and NDI facilitates this by design.
You do not need an intermediary if you create your custom GUI in Windows / Linux / Android using the NDI SDK to do so.

Open up the SDK lower to the route protocol at the Network / byte layer to allow Traditional AV Logic controllers (AMX/CRESTRON/EXTRON/KRAMER/BARCO etc etc etc ) to access this feature and a multi $billion dollar commercial EDU AV industry
switches to NDi instead of the multitude of other proprietary Video over IP solutions currently owning that market.

[livepad]

You can send Route commands to an NDI endpoint via the SDK.

Actually you don't send an NDI route command to an endpoint in the way you are suggesting.
The routing is done using a virtual source (created by the illusive intermediary you are determined not to allow).
You might be able to send a 'connect to a source' command to specific devices that have a completely different API (such as a REST message for some NDI Monitors. eg NewTek on Windows and Sienna on Linux) - but this has nothing to do with the NDI API.

[Simos]

Actually you don't send an NDI route command to an endpoint in the way you are suggesting.
The routing is done using a virtual source (created by the illusive intermediary you are determined not to allow).
- but this has nothing to do with the NDI API.

I feel we are both talking about opposite ends of the OSI Model in regards to how NDI ( public API SDK) handles calls and then deeper under the hood of the .DLL (where it converts those words to a deeper API {not public}and then bytes of data)
and then transmits that data across a network with a common payload that all NDI complying devices will understand and process that payload (be it video or metadata built into the NDI standard e.g. ability for the endpoint to change its stream source.


In a Nut shell: (I want NDI to take over the world)
What I am asking is available right now in higher level programming environments in Windows, Linux and android via the NDI SDK

What I am explaining will make the same subset of route commands available to lower level programming environments
in common AV controllers in the land of EDU and commercial AV, used to dealing with raw bytes, bitwise operations and byte order of complex protocols.
All Without having to stick a windows or Linux box in between to act as a protocol translator running the NDI libraries.


(AMX,CRESTRON, etc etc)


This is not a new concept, not hard to achieve and NDI are listening .Watch this space.