IP Stream Representation in MOS for News Workflows


Mark Gilbert, CTO Gallery SIENNA



The MOS Protocol includes a mechanism to communicate the intent to playout or present a media resource as part of a news story in a rundown.


Traditionally these resources have been media files, played out from a video server.  In order to identify these files, the common practice has been to use a URL or UNC path, such as file://  http:// or the UNC path form \\server-share\folder\file. Alongside the main media resource identifier, it is common to provide one or more proxy representations of the media for preview in the editorial process, by devices which are not able to play the primary media representation.


With the increasing availability of high speed connections to field journalism and other locations, it has become common to include outside broadcast external media sources within a live news rundown.  Historically this has arrived within a news broadcast facility and is presented as a router output (or a switcher input) and the story either includes no specific MOS item for the media - or it includes some sort of macro to select a switcher or router source.


As interest in IP Video grows, and it is included in media workflows, a demand arises to provide an analogy between selection of a file based media source, and selection of an arbitrary IP Video stream. Unlike the blind selection of a router or switcher source (which merely presents whatever a human has connected to that source), we can now begin to explicitly select real time IP Video media sources by name or path, in the same way we might choose any file on disk.   Hence we have the opportunity to pass a link to an IP Video source as a MOS Item, which is handed off to MOS Automation, and within a live bulletin, the automation can negotiate the IP Video stream (from its pre-defined source) and connect it to air.


The new breed of IP Video sources which are typically RTP UDP Multicast streams or TCP connections require a method of identifying the source which can be encapsulated into a MOS Item. Of course IP Video sources are nothing new - we have had RTSP describing RTP for many years, although RTSP was not widely adopted by the mainstream broadcast industry, and it seems unlikely it will become the mechanism for identifying modern broadcast video IP Streams.


Q1 - So - how can we represent IP Video streams in MOS Items in a way which is useful to automation ?


Source identification is something which each IP Video standard is still defining, but ultimately it seems that some sort of URL type analogy will be desirable, and we must ensure that MOS has the capability to pass those identifications around the workflow.

At the same time, considering the workflow it seems appropriate to seek ways to provide proxy representations of IP Video streams for use in desktop editorial systems which may not be able to connect directly to the native IP source.  As an example - a SMPTE2022-6 uncompressed HD IP Video stream might be a 1.5 to 3Gbps stream and a typical newsroom computer writing a script is unlikely to be able to connect to such a source, which requires a 10GBit network connection and probably additional hardware to decode.


Q2 - So - what sort of proxy representation can these sources present ?


Next, we will consider how the move towards IP Video streams alongside media files presents new opportunities to enhance the workflow by taking advantage of the fact that these IP Video streams are presented by intelligent systems, capable of interactivity in contrast to a dumb file on a disk.  So can we begin to building mechanism to allow a MOS item to provide an interactive link to the source of the IP Video stream ?  A simple example would be to present a GUI for the stream - an indeed this could be related to the provision off a proxy representation - but the GUI could do much more than show what the stream represents.  For example - if the stream was from an IP based robotic camera - the GUI could move the camera.  if the stream was from a field journalists mobile phone, the GUI could provide a way for the studio to communicate back to the journalist by typing prompts or presenting a script.


Q3-  So - can we find a way to present a GUI to represent an IP Video source within a MOS Item


Clearly the obvious solution to Q3 is to have the IP Video source present an HTTP based user interface, and indeed many devices like IP Video cameras already do this.  It seems obvious that these GUIs should be advertised within the MOS item somehow.


At present there are a few commonly discussed broadcast IP Video protocols and each may have its own answers.  The author is very familiar with one specific protocol  - NDI and less familiar with the others.  So, in the following section we will delve into specific answers to the questions posed in relation to specific protocols.


Common Broadcast IP Video Protocols, with broad categorisation:

SMPTE 2022 :  UDP Multicast RTP of compressed or uncompressed video and audio. Includes AIMS, TR03, TR04

ASPEN : UDP Multicast RTP of  uncompressed or compressed Transport Streams

Sony NMI :

NDI : TCP compressed video with uncompressed audio



Separate Documents will be created to answer the 3 questions in the context of different IP Video Protocols.


- IP Stream Representation and Proxies for NDI Protocol

- IP Stream Representation and Proxies for SMPTE 2022 Protocol

- IP Stream Representation and Proxies for ASPEN Protocol

- IP Stream Representation and Proxies for NMI Protocol