Skip to content

Commit

Permalink
Add sections, update index
Browse files Browse the repository at this point in the history
  • Loading branch information
dondizon committed Jan 15, 2016
1 parent cf66303 commit daf0f20
Show file tree
Hide file tree
Showing 12 changed files with 2,948 additions and 32 deletions.
314 changes: 314 additions & 0 deletions _posts/2016-01-01-capabilities.md

Large diffs are not rendered by default.

1,070 changes: 1,070 additions & 0 deletions _posts/2016-01-01-configfiles.md

Large diffs are not rendered by default.

89 changes: 89 additions & 0 deletions _posts/2016-01-01-emsbasics.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,89 @@
---
title:
layout: post
date: 2016-01-01 00:00:00 +0000
categories: jekyll update
permalink: emsbasics
---

# EMS Basics

There are a number of things that are good to keep in mind when interacting with the EvoStream Media Server.

## Streams

**Stream directionality** is always from the perspective of the server itself. So when a pullstream is executed, you are always telling the server to go get a stream to bring into it. Conversely pushstream implies taking a stream that is already within the EMS and forcibly sending it to an external destination.

When you pull, push, or create a stream, the command is logged in the `config/pushPullSetup.xml` configuration file. This is the default behavior and allows commands to be persistent if you stop the server and then restart it. In other words, if you pull in two streams, and then stop the server, the next time you start the server it will try to reconnect those two streams.

The logging of commands can be skipped by changing the "keepAlive" parameter in pullstream and pushstream. By setting keepalive=0, the command will not be logged, and if the stream disconnects the server will not try to reconnect to it.

If you wish to "start clean" the pushPullSetup.xml file can simply be deleted prior to starting the EMS.

All in-bound streams have a `localStreamName` that is used to uniquely identify that stream. It is used in play requests and can be used to identify streams in some API calls. It is important to note that no two streams may have the same localStreamName. The EMS will return an error if you try to "pull" a second stream with a localStreamName that has already been used.

## Config Files

The Configuration files are described in better detail later in this document. This will section serve as more of an introduction to the configuration files used by the EvoStream Media Server.

### LUA

The EMS uses the LUA scripting language for many of its configuration files. LUA is an extremely powerful scripting language that allows you to do many things from executing programs to interacting with databases. Typically, the EMS configuration files only trivially use LUA. The configuration files are no more than a collection of statically defined LUA variables.

The use of LUA provides users with a unique ability to dynamically configure the EvoStream Media Server. For example, if you wanted to pull authentication information from a database that is regularly updated you would simply need to replace the contents of the _users.lua_ file with the LUA script to query your authentication database. The EMS will then automatically query your database for authentication details at runtime!

The LUA scripting language is easy to learn and has had excellent acceptance in the software community. The game World of Warcraft® relies heavily on the LUA scripting language. You will be able to clearly understand the contents of the EMS configuration files even if you have never seen a LUA script before.

### EMS Configuration Overview

**config.lua** – This is the main configuration file for the EMS. This file defines all of the startup parameters used by the server, including the location and names of all of the other configuration files. If you wish to change the name of any of the subsequent configuration files, you can do so here. This file is also just a command-line parameter to the EMS executable. The run-scripts provided with the EMS distribution use this file by default. If you want to change the location or name of this file you can simply modify the run scripts to use a different file.

If you modify this file and the server then fails to start, you have made an error. You can either roll-back your changes or you can use the `--use-implicit-console-appender` command line parameter to get extra debug information about what failed during startup.

**pushPullSetup.xml** – The most important thing to know about the pushPullSetup.xml file is that it **should not be modified manually**! This file is used for internal purposes only. If, during startup, the EMS detects that changes have been made to the pushPullSetup.xml file, it will rename the existing pushPullSetup.xml file and start with a fresh configuration.

Now that the disclaimer is out of the way, it is important to understand how this file is used. When a pullStream, pushStream, createHLSStream, createHDSStream, createMSSStream, createDASHStream, record, or launchProcess, or startWebRtc command is executed, that command is logged to this file (assuming the keepAlive flag is 1, which it is by default). When the EMS is started, it parses this file and attempts to recreate all of the connections. These configuration entries can be removed by issuing `removeConfig` commands, or by setting the keepAlive flag to 0 when the initial command is made.

**Note:** If you wish to have a "clean start" of the server, with no previous streams, you may delete this file before starting the EMS.

### EWS Configuration Overview

**webconfig.lua** – This is the main configuration file of the EvoStream Web Server (EWS). This file sets the locations of important web server files/folders such as the web root folder, server key & certificate, white list, black list, logs, etc. This is where other web server settings are defined, including HTTP port, group name aliasing, SSL mode, connection/memory limits, mime types, etc.

Some of the more critical settings and their defaults:

| Settings | Default Value | Notes |
| --- | --- | --- |
| Port | 8888 | - |
| webRootFolder | Linux Installer: /var/evo-webroot/Linux .tar: [EMSInstallDir]/evo-webrootWindows: C:\EvoStream\evo-webroot | - |
| hasGroupNameAliases | False | This parameter turns on or off (off is default) Group Name Aliasing, a powerful security feature. Group Name Aliasing does change the behavior of the EWS drastically, so please make sure to read up on Group Name Aliasing before enabling! |
| threadPoolSize | 4 | Depending on your planned HTTP load and use case, increasing the thread pool might be necessary. |

## Video Compression

The EvoStream Media Server requires that the video streams be encoded as H.264 data. H.264 has many different options and configurations. The EMS can support virtually every _valid_ H2.64 stream with a few exceptions:

**Widely Varying GOP Sizes** – The EMS works best when there are a consistent number of P-Frames per I-Frame. This is particularly true when creating file-based outbound streams like HLS.

## Production Logging

The EMS provides production logging through the Event Notification System which you can read more about below. The production logs allow you to track streaming sessions, data transfers, invalid requests and more. Logging can be done in XML, JSON or formatted for W3C.

- Log HTTP streaming sessions for HLS, DASH, MSS and HDS. Get a SINGLE log entry for the streaming session across the multiple file requests inherent to HTTP streaming.
- Log live stream and file accesses
- Log recording events
- Log both start and end record and streaming events to take action in real-time

## Debug Logging

The EMS provides system level logging which is turned on by default. This logging assists in integration and debugging efforts. The logs can be found in the `logs/` directory in either the main EMS distribution (from archive installation) or in the `/var/log/evostreamms/` directory when using the Linux installer and in C:\EvoStream\logs\ in Windows®.

### Log Accumulation

The EMS logs constantly while it is running, which may have negative impacts on disk usage over the course of time. This can be mitigated by either quieting the logs, or disabling logging all-together. To quiet logs, edit the `logLevel` configuration value in config.lua. 6 is the highest (most prolific) level of logging, 0 is the lowest.

To disable logging completely, remove or comment out any "file" type `logAppender` in the config.lua file. Alternatively, set logLevel to -1 to disable logging without removing the logAppender entry.

See the configuration section of this document for more information on manipulating the config.lua file.


34 changes: 34 additions & 0 deletions _posts/2016-01-01-eventnotification.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,34 @@
---
title:
layout: post
date: 2016-01-01 00:00:00 +0000
categories: jekyll update
permalink: eventnotification
---

## Event Notification System

The EMS Event Notification System provides an extremely powerful way of interacting with the EMS. At the basic level it allows you to easily understand and monitor the usage of your server. You can either poll and parse the log file, or simply subscribe to the HTTP based notifications sent out by the EMS. **The notifications mean that you can have a fully RESTful monitor, gathering metrics in real time!**

Beyond monitoring and gathering metrics, you can **use the Event Notification System to create custom stream processing.** If you want to automatically create HLS/HDS/MSS/DASH streams out of new inbound streams, simply call createHLSStream/createHDSStream/createMSSStream/createDASHStream in response to each "new inbound stream" event. If you want to close inbound streams when the associated outbound stream is lost, call shutdownStream when you receive an "outbound stream closed" event.

### List of Events

The API Definition.pdf document provides a list and full descriptions of each event. Please consult that document to learn more about the EMS Events.

### Configuring Event Notifications

Events can be sent to multiple destinations, or "sinks", at the same time. A "sink" can be either a file or a network destination. Multiple sinks can be enabled at the same time, allowing you to both log events and receive them in your web service(s). These sinks can be configured so that only the events you will be consuming will be generated. Event Sinks are configured in the `config/config.lua` file.

**Note:** Event Notifications are **off** by default. To use the Event Notification System, you must modify the EMS configuration file.

Please see the Configuration File section below for details on enabling the Event Notification System.

### Application vs. Server Events

The config.lua file has two eventLogger sections as follows:

1. Application-owned – This is lower in the file and is "inside" the application configuration section. It configures "application level" events. **This is the recommended configuration section to modify.**
2. Server-wide (or default) – This is higher in the file and is at the outer-most variable scope level. This section configures events that are outside the application or events which the application level fails to catch. This is typically only for system events like server startup, server shutdown and application load.


34 changes: 18 additions & 16 deletions _posts/2016-01-01-index-local.md
Original file line number Diff line number Diff line change
@@ -1,56 +1,58 @@
---
layout: post
title: "EMS User Guide"
title: "EMS User Guide (Local Test Only)"
date: 2016-01-01 00:01:00 +0000
categories: jekyll update
permalink: table_of_contents_local
---

1. Document Definitions
2. Purpose
3. EvoStream Media Server
- What is EMS?
- Why Use EMS?
- What are the Key Features and Benefits of the EMS?
- How Does the EMS Work?
- Where will EMS Run?
4. Installation and Startup
1. [Introduction](/introduction)
- Document Definitions
- Purpose
- EvoStream Media Server
- What is EMS?
- Why Use EMS?
- What are the Key Features and Benefits of the EMS?
- How Does the EMS Work?
- Where will EMS Run?
2. [Installation and Startup](/installation)
- Obtain a License
- Install EMS
- Other Installers
- Platform Verification
- Linux Limitations
- Distribution Content
5. Starting the Server
3. [Starting the Server](/startingserver)
- Linux Distributions (Linux apt/yum Installer)
- Linux, Mac OSX and BSD Distributions (.tar.gz Distribution)
- Windows Distribution
- Startup Success
- EMS Command Line Definition
6. EMS Basics
4. [EMS Basics](/emsbasics)
- Streams
- Config Files
- Video Compression
- Production Logging
- Debug Logging
7. Run-Time API
5. [Run-Time API](/runtimeapi)
- Accessing the Runtime API
- Configuring and Receiving Event Notifications
- API Definition
- My First Call API
- User Defined Variables
- EMS Demo.html
8. Event Notification System
6. [Event Notification System](/eventnotification)
- List of Events
- Configuring Event Notifications
- Application vs. Server Events
9. Security and Authentication
7. [Security and Authentication](/security)
- Stream Aliasing
- Group Name Aliasing
- Inbound Authentication
- Outbound Authentication
- Client Authentication
- Encoder/User Agents 3736
10. Protocol Support and Specifics
8. [Protocol Support and Specifics](/protocolsupport)
- Peer to Peer
- HTML5 Web Sockets

34 changes: 18 additions & 16 deletions _posts/2016-01-01-index.md
Original file line number Diff line number Diff line change
@@ -1,56 +1,58 @@
---
layout: post
title: "EMS User Guide"
date: 2016-01-01 00:01:00 +0000
date: 2016-01-01 01:01:01 +0000
categories: jekyll update
permalink: table_of_contents
---

1. Document Definitions
2. Purpose
3. EvoStream Media Server
- What is EMS?
- Why Use EMS?
- What are the Key Features and Benefits of the EMS?
- How Does the EMS Work?
- Where will EMS Run?
4. Installation and Startup
1. [Introduction](/ems_user_guide/introduction)
- Document Definitions
- Purpose
- EvoStream Media Server
- What is EMS?
- Why Use EMS?
- What are the Key Features and Benefits of the EMS?
- How Does the EMS Work?
- Where will EMS Run?
2. [Installation and Startup](/ems_user_guide/installation)
- Obtain a License
- Install EMS
- Other Installers
- Platform Verification
- Linux Limitations
- Distribution Content
5. Starting the Server
3. [Starting the Server](/ems_user_guide/startingserver)
- Linux Distributions (Linux apt/yum Installer)
- Linux, Mac OSX and BSD Distributions (.tar.gz Distribution)
- Windows Distribution
- Startup Success
- EMS Command Line Definition
6. EMS Basics
4. [EMS Basics](/ems_user_guide/emsbasics)
- Streams
- Config Files
- Video Compression
- Production Logging
- Debug Logging
7. Run-Time API
5. [Run-Time API](/ems_user_guide/runtimeapi)
- Accessing the Runtime API
- Configuring and Receiving Event Notifications
- API Definition
- My First Call API
- User Defined Variables
- EMS Demo.html
8. Event Notification System
6. [Event Notification System](/ems_user_guide/eventnotification)
- List of Events
- Configuring Event Notifications
- Application vs. Server Events
9. Security and Authentication
7. [Security and Authentication](/ems_user_guide/security)
- Stream Aliasing
- Group Name Aliasing
- Inbound Authentication
- Outbound Authentication
- Client Authentication
- Encoder/User Agents 3736
10. Protocol Support and Specifics
8. [Protocol Support and Specifics](/ems_user_guide/protocolsupport)
- Peer to Peer
- HTML5 Web Sockets

Loading

0 comments on commit daf0f20

Please sign in to comment.