Application Programming Interfaces

viinex is designed as an SDK, so programming interfaces are of most importance to us.

viinex APIs come in three flavors.

First of all, there is an API for remote clients. This is perhaps the most important one. Remote clients include web pages (including single page web apps), mobile applications, and services. For all these use cases viinex’ API is available via HTTP and via WAMP.

HTTP transport for remote calls is commonly used, it is convenient in many aspects. Most of viinex objects expose endpoints which can be accessed over HTTP, when the object is published in viinex web server. HTTP API is described in detail in chapter 3 of our documentation.

However HTTP is not the only option. There’s another protocol called WAMP. If you’re unfamiliar with it — please refer to wamp-proto.org. It is a routed RPC solution, well suitable for real world Internet. One possible transport for WAMP is WebSocket. WAMP clients can register themselves on a special component, called WAMP router, and by doing so they make themselves available for RPC invocations. At the same time, clients can call remote procedures on other clients registered within the same WAMP router. viinex makes use of this: besides HTTP transport, it also can expose the API via WAMP. What’s especially good about it is that even when a viinex instance resides behind the NAT, — it still can be reached by the client, if it has registered itself in a WAMP router on the internet. Combined with WebRTC for media streaming, this makes viinex suitable for deployment in p2p scenarios, without the need for a VPN or setting up port forwarding. Viinex exposes the same functionality over WAMP as it does over HTTP.

Another API flavor that viinex provides is the programming interface for built-in scripts. viinex has a support for built-in scripts, which means that a JavaScript code can be embedded into viinex and run inside of its address space. This is used to enrich viinex’ default behavior with customizations needed in particular applications. The scripts which run inside of viinex can access viinex’ objects using the very same API which is exposed over HTTP and WAMP. That is literally the same API: the only difference is that in case with network protocols, a worker object should be linked with viinex HTTP server or WAMP client, while in case of the script, — the object should be linked with respective script instance within viinex process, without the need for a remote communication. To learn more on objects linking in viinex config, please refer to sections 2.5 and 2.6 of viinex documentation. Chapters 4 and 5 describe the usage of viinex API from within built-in scripts and via WAMP, respectively.

Last but not least, there is also a lower-level API available with viinex to implement custom media sources, codecs, as well as connect to viinex’ local instance to implement video analytics. That’s a different kind of API, directed towards the suppliers of video-related components rather than towards consumers of such. This API is available as an open-source component called `vnxvideo`, check out this GitHub repo.