Release Notes:
The Recorder module is now capable of taking a compressed video stream as its input and if the destination compression settings are compatible with the input the recording will be carried out without video decompression or recompression.
In this mode the Recorder module is still capable of recording starting from positions not neccesaryly aligned to the key frames. In this case the Recorder will re-encode a small part of the input video in order to produce a file that starts with a key-frame. The rest of the video will be kept intact
This mode allows recording of compressed input stream with minimal CPU usage as no decoding or encoding is required. This mode also allows to avoid video quality loss due to re-encoding.
The playout module is now capable of taking compressed input video and re-multiplexing it according to the output settings like wrapping to MPEGTS, HLS or RTMP output without video decoding or re-encoding. Video decoding or re-encoding is only performed when the input video compression settings don't match the configured output specification thus allowing mixed pre-compressed and generic base-band workflows to co-exist for the same output.
The Program Channel module is now capable of preserving compressed video frames as read from the files or as received from the Background layer. In this mode of opertion video decompression is carried out only when reqired i.e. for graphich overlay or at clip boundaries whem the playlist clips are not aligned to key frame positons in the input compressed files.
The pre-compressed video can be consumed by a Playout or Recording module for further transmission or recording without re-compression.
Together, the Program Channel, Recorder and Playout modules in pre-compressed mode allow for “splicing” like workflows where video clips and streams are recombined or spliced without excessive CPU usage or quality loss due to recompression.
Technical information:
Most of the software components that take a video stream as their input are not capable or direct input of network live streams. The modules that support such an input mode include:
This feature elimitanes the need for a Capture service in order to receive a network stream in the corresponding module. For modules that support pre-compressed workflow this feature also allows input of pre-compressed live streams and operation without video decoding or re-encoding. It also allows direct monitoring or network streams in the Multiviewer.
Supported live stream formats include:
The input url format is compatible with ffmpeg input stream url.
Technical information:
There are a variety of Adaptive Streaming wire formats. Some are based on an MPEG-2 Transport Stream container such as HLS (HTTP Live Streaming: Apple) and others on a fragmented MP4 container such as HSS (HTTP Smooth Streaming: Microsoft) and HDS (HTTP Dynamic Streaming: Adobe); whereas DASH (Dynamic Adaptive Streaming over HTTP: MPEG) supports both containers. While different, they utilize common video and audio compression formats; namely: ISO/IEC 14496-10 (AVC) and ISO/IEC 14496-3 (AAC). Additional audio formats, such as Dolby Digital Plus and DTS-HD, may also be supported by these or a subset of these Adaptive Bit Rate (ABR) formats.
The Adaptive Transport Stream (ATS) format described in ANSI/SCTE 223 2018 specification allows for streaming/storage of adaptive streaming content originating as Transport Streams in a generic manner without restricting this to a particular adaptive streaming delivery technology (HSS/HLS/HDS).
The Playout module MPEG2TS generator is now capable of generation of a fully compliant continuous single program MPEG-2 Transport Stream which follows the HRD model and provides markers that identify conditioned points in the stream that are virtual segments that can be partitioned into segments used for ABR applications.
The virtual segment description is implemented following the ANSI/SCTE 223 2018 specification by injecting to the MPEG2 Transport stream af_descriptor metadata which is collectively called Encoder Boundary Points (EBP) data.
This feature allows for integration or the Program Channel and Playout modules into internet streaming workflows that require this feature.
EBP generation is enabled in the Playout module configuration by specifying target virtual segment duration in the “Insert EBP (sec)” field of the MPEG2 TS parameters page. In Multi-camera mode enabling this feature also turn on PCR synchronization between all Camera outputs allowing for output of perfectly synchronized multi-bitrate content with synchronized EBP virtual segments.
The Multiviewer video and audio signal loss detection and alarm feature has been extended to a full Fail Over switch feature. It is now possible to define window pair which will be monitored for the supported alarm types such as “video black”, “video frozen”, “audio loss” and “audio overload”. Using a hysteresis algorithm the best window will be selected and user defined actions will be generated on a condition that a certain window was selected. These actions can be used to trigger a cross point on an SDI router or to control the “On Air” program channel of a main/backup pair.
The Fail over switch provides indication or the “best” window selection status in the multiviewer window as well as allows for manual switch override and temporarily disabling the switch functionality.
Technical information:
In addition to transport stream level input quality checks such as signal presence and countinuity error counting EazyMuxer now allows for full input video and audio decoding and peforming additional quality checks on decoded video and audo. The quality checks include:
Based on these quality checks Eazymuxer produces input stream alarms that are reported to the logs and are made available via SNMP and XML-RPC API to other applications.
Automated TS fail over switching is now supported by means of Aggregate Sources. Aggregate Sources allow for taking two TS sources as input and switching between them based on the number of detected alarms. The best source is identified and used to produce the content of the Aggregate Source which, in turn, can be used as source for re-multiplexing or for pass-through to the sinks.
Technical information:
The Media-Database module now supports user authentication as well as user permissing settings using an external LDAP server.
The media-database access rights are defined with in the media-database for user groups and the system administrator assigns the groups which an LDAP user belongs to within the LDAP server. During authentication process the media-database forwards then authentication requests to an LDAP servers and retrieved the gorup information for each user in order to apply the correct access rights.
Both users locally defined with in the media-database and LDAP can co-exist at the same time. The LDAP users need only to be created within the LDAP server so the system administrator doesn't have to duplicate any of the user information.
Technical information:
Client applications including AirManager, MaConnect, NewsCut and RTClient are now capable of storing their configuration within a media-database service. Depending on their role within an organization different users require differently configured client applications so that they had access to different services and use different window layouts. Storing the configuration with in a media-database service allows each user to login using their own credentials and the client applications will be automatically configured according to their personal preferences or according to their role as defined by a system administrator.
Instead of opening each individual client applications the user now has an option to start the SKWorkspace desktop login with their credentials only once and start individual applications from the workspace with all the configuration settings applied based on the user.
The user is also not bound to a particular client workstation. When logging in to SKWorkspace from another workstation they will still receive the same configuration. Only the window layout will be saved locally on each workstation allowing to adjust the window configuration depending on the workstation's display resolution and other parameters.
Technical information:
Server side applications can now keep their “run” folder under the system %LOCALAPPDATA%. This allows server application without requiring write permission to the program installation folder and without running the server applications such as NeoVid, EazyMuxer and Web-Access as Administrator.
After upgrading to this version importing of the previous 2.10 configuration is supported but the contents of the “run” subfolder has to be manualy copied to the new location i.e. %LOCALAPPDATA%\SLNEO\Run.
In order to preserve compatibility with previous installations slection between the old run folder location under the program installation folder Program Files (x86) and new LOCALAPPDATA works as follows:
This algorithm ensures that the old location is used when the software is updated on existing installations and the new location if the software is installed on a clean system.
Technical information:
Playlist output can be directly displayed using HDMI and DP outputs of the system video card. Together with features specifically designed for high performance playback of diverse video content as well as video composition and output processing this allows to use the program channel playlists for playback to video walls and projectors for digilat signage and various information, decoration and entertainment screens.
The following features have been implemented specifically for this mode of operation:
Technical information:
The Program Channel module now supports the AB player mode. In this mode of operation the playlist automation controls two player outputs and allows to traditional AB style playback. The outputs can be monitored directly in AirManager using the Service Monitor displays and when displaying a preview of an AB player the Service Monitor presents playback controls to the operator which allow them to also send commands like play, stop and pause from the monitor window.
Technical information:
The prompter is an entirely new module which comes with Neovid server software package. The prompter runs in a web-browser and displays its output to the computer screen. Using an HDMI or DP output of the video card the signal can be converted to SDI or analog by means of an external mini-converter.
Supported features include:
Technical information:
SL NEO Media Server can now be integrated into NewsRoom worfflows with a new MOS Gateway module. The MOS Gateway interfaces with an NRCS sowtware and turns an SL NEO Media Server to a MOS device and allows the MediaDatabase, Program Channels, Graphics Lists and Prompter modules to interoperate via MOS protocol. Supported features include:
The MOS integration has been validated and is fully operational with Octopus Newsroom and Arion S-News.
Technical information:
The Playout service is now capable of direct input of subtiles coming from external sources and producing subtile data to the subtitle streams configured with in the Playout service configuration. Teletext, CEA-708/608 and Open captions are currently supported. Each configured subtitle stream can be configured to receive the subtitle data from its own source allowing for multilungual live subtitling.
The subtitle data source can be a simple TCP server socket to which the Playout service would connect and receive a simple character stream. The CCKeyboard application is bundled with the SL NEO distribution can be used for simple subtitle input from the keyboard or for testing of the technlogy. Other subtile providers including AI engines can be used as subtitle data sources as well.
The character stream may inctude control sequences to change the background and foreground color of the subtitles. The control sequeences should be in the same format as for the graphics composition text i.e. “{?fg:#RRGGBB?}” or “{?bg:#RRGGBB?}”.
Technical information:
Neovid built-in WEB-server is now capable of serving HLS streams from the Playout servic. HLS streams are served over HTTP on port 7904 and over HTTPS on port 7944 separately from the admin UI and REST API, so Firewalls can be configured to allow access exclusevily to the streaming ports from public networks.
Build-in HLS streaming is activated by selecting “Neovid” as the upload method in the Playout service configuration. This will direct the output HLS output to the run/buffer/xxxx subfolder from where is can be published via the Status page. On the status page the operator can publish each HLS Playout unders different keys that will produce urls like http://IP_ADDR:7904/stream/unique_key/stream.m3u8. Each url can be activated separatly without the Playout restart and different recepients can be given their own url in order to manage their access separately.
Each published URL can also be required to authenticate via an API key. The key is supplied via HTTP Cookie named “API-Key-Cookie” and the value would be an API key which will authenticate the use in a media-database which was selected during the API Key creation. In order for the access to be granted the user of the API key has be to a member of a group which in listed in the “Allowed Groups” for that url. If the “Allowed Groups” list is empty no authentication is required.
Technical information:
There is now a possibility to switch between capture sources when there are issues with the input detected.
The Capture module now inserts the “SIGNAL NOT PRESENT” ancillary packet when is inserts the black field during signal outages. When such a condition is detected by the Multviewer module is raises the “NO SIGNAL” alarm for the corresponding window. This alarm is different from the “STILL”/“BLACK” condition in that way that “NO SIGNAL” doesn't require video processing and because of that uses less computing resources. The “NO SIGNAL” alarm is also raised for the windows that use NVT streams from remote servers when the stream can't be opened. So, the alarm will be raised when the remote server is down or inaccessible.
The Fail-Over feature of the Multiviewr can be used to change the input of other modules that consume the output of the Capture module and use a different Capture module.
This redundancy mode requires two simultaneously operating Capture channels and a Multiviewer module to supervise the capture state and trigger swiching actions. It also allows switching between sources of different type such as SDI and IPTS or RTMP.
The Webcast, IPTS and NDI source typese allow setting the Cycle URL list. When a “SIGNAL NOT PRESENT” condition is detected the Capture module will automatically pick the next URL from the list and apply it to the input. This way the Capture will be cyclyng between these urls until one with the signal is opened.
The Cycle URL list is set via the “Cycle URL” property on the “Status” page and can be controller during runtime without changes to the module configuration or restarting the module.
This redundancy module doesn't require any additional modules to operate and at any given time only one input URL is connected
Technical information: