NDI Stream Representation in MOS

 

Sources offering NDI based streams already advertise themselves using Bonjour, which carries an IP address and port number on which to connect, in order to receive the stream.  The Bonjour record also includes a common name used to identify the stream.

This proposal has been made to repackage the bonjour representation of NDI into a URL format when the stream needs to be carried through MOS or otherwise communicated (e.g. via an email or instant message).

 

The URL form could be:    ndi://192.168.1.193:57623  which identifies the IP address and port of the stream.  This would be sufficient to carry a link through a MOS item using the existing <objPath> tag.

However - this has some limitations, since the port used by NDI may change with each start / stop of the providing service.  Consequently the common method of providing a persistent identification of an NDI is through its bonjour name.  In this way the name can be stored and then re associated with a live IP port at run time.

Real experience with NDI shows that the number of available IP sources is increasing exponentially and the proposal suggests that a UID mechanism should be used for NDI Sources, allowing explicit identification of the same source, even where there are duplicate or ambiguous advertised Bonjour sources available. This would also deal with the conflict resolution mechanism already  found in Bonjour which can tend to rename a source as (2) if an existing conflicting source exists.  This can lead to the bonjour name of a device changing from one day to the next, and causing confusion.  By including a source persistent UID in the bonjour advertisement, an NDI consumer can be sure that it is re-connecting to the same NDI source as last time.

 

In conclusion the MOS Item representation of the primary NDI IP Video source could be in the form:

ndi://UID=<source UID>

or

ndi://STREAM=192.168.1.193:57623

or

ndi://NAME=NDICam(marks phone)

 

Note that the string must be URL encoded, with escaped spaces etc.

 

Where the form of the URL is clearly identified with the prefix UID, STREAM or NAME.  Indeed Automation may take in the UID or NAME form and close to air, may replace this with the explicit STREAM form which would be passed to the device which will receive the NDI stream (vision mixer, baseband decoder etc).

Adding the UID tag to the bonjour advertisement is backwards compatible and requires no changes to the NDI code. It can be exploited by NDI-X (extended) systems which are familiar with the extension of the protocol, without compromising operations of standard NDI devices.

 

Proxy representation in NDI devices.

Unlike SMPTE 2022-6, NDI sources are modest bandwidth and do not require additional hardware to decode.  On that basis it may be reasonable to expect newsroom computer systems to use the primary IP representation to browse, monitor or check an NDI IP Video stream. However - this assumes an NDI-capable player is available on that system and is connected into the newsroom computer system somehow.  The proposal suggests that NDI devices optionally offer a proxy based view of the source, via HTTP so this can be accessed inside non NDI capable systems.  To limit load the HTTP proxy can be lower quality and lower (very low) frame rate. In additional to proxy viewing, this would also provide a convenient source for multi view type systems to maintain a lightweight connection to a very large number of NDI sources, without maintaining (or constantly starting and stopping) a formal NDI connection to each source. In the case of abstracted IP Video connections (such as via the NDI Relay protocol) this would also allow for a slow update representation of the source without requiring the abstracted connection to be hooked up each time an NDI consumer simply wanted to show a current thumbnail to represent the source (e.g. when a user is given a list of sources to choose from).

 

Hence the HTTP server could advertise and offer a URL such as http://192.168.1.193:57624/thumbnail.jpg which is refreshed as slow or fast as appropriate by the device and be updated on the NDI consumer as appropriate (for example, when the user selects the sources list)

 

This HTTP view could also be the GUI mentioned previously where an HTML page could be offered which interacts with the NDI source, indeed it may be that this is also the best way to provide a proxy, since an HTML page can be live with AJAX interactivity and this could indicate to the NDI IP Device that a higher frame rate of proxy may be appropriate whilst the GUI page is open and active.

 

NewTek's NDI Connect Pro already represents NDI Sources with an HTTP representation and may form the basis or a resource for adoption of the HTML

 

Bonjour Registration:

 

_ndi._tcp.

       MyNDIDevice

              192.168.1.193:50303

              groups=public

              UID=sienna.ndi.MyNDIDevice.2377560947845

              preview=http://192.168.1.193:50304/thumbnail.jpg

              GUI=http://192.168.1.193:50304/gui.html

              controlURL=http://192.168.1.193:50304/ndi_ptz.html

              controlProtocol=NDI_PTZ

 

Along with this, we would like to propose the beginnings of a set of standardised control protocols to be used with NDI devices, either over the NDI metadata channel, or via complementary dedicated protocol connections as shown above.

 

By offering a standardised method for NDI sources to become truly interactive over an NDI connection we massively differentiate the NDI IP Video stream from a traditional baseband video stream

 

Footnote:  This protocol has now been implemented in some of Sienna's tools. The Sienna NDI Monitor provides a menu item to 'capture' a URL representation of the current NDI stream, using the  ndi://NAME=NDICam(marks phone) representation.  The NDI Monitor app registers itself as a handler of of the ndi:// schema so later calls to the OS of an ndi:// URL will be forwarded to NDI Monitor which then interprets the URL and reconnects to the defined stream.  Support for the ndi:// is being implemented into Sienna AutomationX in order to handle MOS items with this format in the objPath, which will then be passed to any NDI compatible playout device supported by AutomationX, such as a NewTek IP Series or TriCaster, under macro control.  Using this mechanism a URL for an NDI stream can be captured and inserted into a MOS Item, then travel through the NCS workflow to automation where it is re-interpreted into an instruction for a device which can deliver that stream to air.