C++ RTMP Server Documentation

Gavriloaie Eugen-Andrei

ttp h

.r t w ww : //

December 1, 2011

p m

co d.

ttp h

.r t w ww : //

p m

co d.

Contents
1 Introduction 1.1 What is crtmpserver? . . . . . . 1.2 Requirements . . . . . . . . . . 1.2.1 Machine/os requirements 1.2.2 Software requirements . 1.3 Compile the server . . . . . . . 1.3.1 Linux/BSD . . . . . . . 1.3.2 Win32 . . . . . . . . . . 1.3.3 ARM (linux or android) 1.4 Running the server . . . . . . . 1.4.1 Linux/BSD . . . . . . . 1.4.2 Win32 . . . . . . . . . . 1.4.3 ARM (linux or android) 1.5 Testing Sample Application . . . 1.5.1 Test RTMP . . . . . . . 1.5.2 Test RTSP . . . . . . . . 1.6 Stopping the Server . . . . . . . 1.6.1 Linux/BSD . . . . . . . 1.6.2 Win32 . . . . . . . . . . 1.6.3 ARM (linux or android) 5 5 6 6 6 7 7 7 7 8 8 8 8 8 8 9 9 9 9 9

ttp h

.r t w ww : //
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

p m
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

co d.

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

Conguration le 2.1 Main structure . . . . 2.2 logAppenders . . . . 2.3 applications . . . . . 2.4 application denition

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

10 11 12 13 14 16 16 16 16 16 17 17 17 17 17 18 18 18 3/22

Architecture 3.1 Layers . . . . . . . . . . . . . . . . . . . . 3.1.1 Machine layer . . . . . . . . . . . . 3.1.2 Operating System Layer . . . . . . 3.1.3 Networking layer . . . . . . . . . . 3.1.4 The components layer . . . . . . . 3.2 Components . . . . . . . . . . . . . . . . . 3.2.1 Utilities . . . . . . . . . . . . . . . 3.2.2 Netio . . . . . . . . . . . . . . . . 3.2.3 Protocols . . . . . . . . . . . . . . 3.2.4 Applications and protocol handlers 3.2.5 Streaming . . . . . . . . . . . . . . 3.2.6 Media formats . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

CONTENTS

CONTENTS

Interoperability 4.1 RPC . . . . . . . . . . . . . . . . . . . . . . . 4.2 CLI . . . . . . . . . . . . . . . . . . . . . . . 4.3 My rst application . . . . . . . . . . . . . . . 4.4 Customize Conguration File . . . . . . . . . . 4.5 Create a custom protocol and a protocol factory 4.6 Extending media le formats collection . . . . 4.7 Use Evostream as Client (Test it against itself) . Troubleshooting Extentions

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

19 19 19 19 19 19 19 19 20 21 22 22 22 22 22

5 6 7

Example Setups 7.1 Live streaming of a media le . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 A Powerful Live Streaming Setup . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3 A Full CentOS Build-Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4 Protecting your streams from webpage copy&paste ash code, listing or recording

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

ttp h

.r t w ww : //

p m

co d.

4/22

Chapter 1

Introduction
1.1 What is crtmpserver?
It started as a RTMP server. After a while, it evolved to a generic networking platform capable of handling multiple protocols. This way, RTMP (and friends), became just a fraction of what the platform can do. Here is a far-from-complete list of features (only main ones) 1. machine independent (x86,amd64,ARM,MIPS,PPC) 2. operating system independent (linux,*BSD,win32,android) 3. multiple network protocols support 4. applications support 5. RPC1 and CLI

6. generic support for multimedia le formats

ttp h

.r t w ww : //

p m

co d.

1 Remote

Procedure Call

5/22

Requirements

Chapter 1. Introduction

1.2 Requirements
1.2.1 Machine/os requirements
The server can run on one of the following: ARM (linux or android based) x86/amd64 (linux,*BSD,win32,solaris)

1.2.2

Software requirements

To build C++ RTMP Server you need the following: C and C++ compiler Development libraries and header les of OpenSSL (Under Win32 you must use OpenSSL v0.9.x, version 1.0.0 is not supported) Also, depending on the build method or target platform, you might need one or more of the next software packages: CMake (Link) Microsoft Visual C++ 2010 (Link) Netbeans (Link) Android NDK (Link) GNU Make (Link)

ttp h

.r t w ww : //

p m

co d.

6/22

Compile the server

Chapter 1. Introduction

1.3 Compile the server

1.3.1 Linux/BSD
Here are the steps necessary for getting the server up and running. For installing the dependencies please consult this. 1. check out the source code from svn repository:
1 $ s v n co u s e r n a m e anonymous h t t p s : / / s v n . r t m p d . com / c r t m p s e r v e r / b r a n c h e s / 1 . 0 c r t m p s e r v e r

Hit Enter key when prompted for password (this parameter is empty) 2. go to the builders directory
1 $ cd c r t m p s e r v e r / b u i l d e r s / cmake

3. make sure everything is clean by doing

1 $ sh c l e a n u p . sh

Note: This is necessary when updating the sources or you run into troubles like missing libraries reported by cmake 4. generate the makele using cmake
1 $ cmake .

Notice the space dot 5. start the actual building process

1 $ make

At this point, if no errors occurred, you should have a working binary.

1.3.2

Win32

Make sure that you have administrative privileges before doing the following steps. 1. Check out source code using SVN. You can use a Subversion client called TortoiseSVN to do this. Put the following values to the TortoiseSVN interface:

ttp h

URL2 of repository: https://svn.rtmpd.com/crtmpserver/branches/1.0 Checkout directory: <Your desired checkout folder>

.r t w ww : //

p m

co d.

Checkout Depth: Fully recursive Revision: Head revision Username: anonymous Password: <Leave this blank>

2. When source code has been checked out successfully, go to <checkout folder>/builders/VS2010 folder. Inside that folder, double click the VS2010.sln le. 3. Optional, build with OpenSSL support: (a) Download and install Visual C++ 2008 Redistributables(Link) and OpenSSL (Link) (b) If you install OpenSSL to another place than C:\OpenSSL-Win32, change OpenSSL include and lib path (in projects properties) 4. Compile the solution using Microsoft Visual C++.

1.3.3

ARM (linux or android)

Resource Locator

2 Uniform

7/22

Running the server

Chapter 1. Introduction

1.4 Running the server

1.4.1 Linux/BSD
If you are here from previous steps (compiling), you should already be in the right directory which is builders/cmake relative to the directory where the sources are located. Enter the following command:
1 $ . / crtmpserver / crtmpserver . / crtmpserver / crtmpserver . lua

If you dont see anything happening, that means you either run the daemon mode or something is wrong with the cong le (please refer to this page for further details). If everything went well and you are in console mode, you should see something like this:
+-----------------------------------------------------------------------------+ | Services| +---+---------------+-----+-------------------------+-------------------------+ | c | ip | port| protocol stack name | application name | +---+---------------+-----+-------------------------+-------------------------+ |tcp| 0.0.0.0| 1935| inboundRtmp| appselector| +---+---------------+-----+-------------------------+-------------------------+ |tcp| 0.0.0.0| 8081| inboundRtmps| appselector| +---+---------------+-----+-------------------------+-------------------------+ |tcp| 0.0.0.0| 8080| inboundRtmpt| appselector| +---+---------------+-----+-------------------------+-------------------------+ |tcp| 0.0.0.0| 6666| inboundLiveFlv| flvplayback| +---+---------------+-----+-------------------------+-------------------------+ |tcp| 0.0.0.0| 9999| inboundTcpTs| flvplayback| +---+---------------+-----+-------------------------+-------------------------+ |tcp| 0.0.0.0| 8989| inboundHTTPDBAccess| samplefactory| +---+---------------+-----+-------------------------+-------------------------+ |tcp| 0.0.0.0| 1111| inboundHttpXmlVariant| vptests| +---+---------------+-----+-------------------------+-------------------------+ |tcp| 0.0.0.0| 1112| inboundTxtCli| admin| +---+---------------+-----+-------------------------+-------------------------+ |tcp| 0.0.0.0| 6665| inboundLiveFlv| proxypublish| +---+---------------+-----+-------------------------+-------------------------+ |tcp| 0.0.0.0| 9997| inboundOggOverHttp| houseband| +---+---------------+-----+-------------------------+-------------------------+

1.4.2

1. Open a Command Prompt and in the terminal, cd to the checkout directory. 2. cd to builders\VS2010\Debug. If you compiled the solution in Release mode, cd to builders\VS2010\Release. 3. Enter this command:

ttp h
Win32

.r t w ww : //

p m

co d.

1.4.3

ARM (linux or android)

1.5 Testing Sample Application

1.5.1 Test RTMP
You can test your compilation by streaming media via RTMP. The application flvplayer is ready for your rst rtmp stream. 1. Put some test media le in the folder /application/vplayback/mediafolder. For simplicity, put flv les for the meantime. 2. Open a browser and type http://dl.dropbox.com/u/2918563/vplayback.swf in the URL3 2 to open the sample swf application. 8/22

Stopping the Server

Chapter 1. Introduction

3. If your server is up, the test media les will be listed in the Available FLVs area. 4. Double click on a le and wait for playback.

1.5.2

Test RTSP

1.6 Stopping the Server

1.6.1 Linux/BSD
From the Console Press Ctrl+C to send a quit signal. The server is shut down when
Shutting down the logger leaving you in the dark. Bye bye... :(

appears in the console. When running as Daemon Kill all crtmpserver processes

1.6.2

Win32

Whether the server is running as daemon or not, you can stop the server by pressing Ctrl+c to send a quit signal.

1.6.3

ARM (linux or android)

ttp h

.r t w ww : //

p m

co d.

9/22

Chapter 2

Conguration le
The conguration le is actually a lua script which must contain an object called configuration. This will be read by the server and used to fully congure the server. Besides this object called configuration you can have functions, include other lua libraries, etc. In the end, you have to make the configuration object available. The rest of this section will explain the structue of configuration object in great detail. But rst, lets take an bird-eye view.

ttp h

.r t w ww : //

p m

co d.

10/22

Main structure

Chapter 2. Conguration le

2.1 Main structure

1 2 3 4 5 6 7 8 9 10 11 12 13 configuration= { daemon= f a l s e , p a t h S e p a r a t o r = / , logAppenders= { c o n t e n t removed f o r c l a r i t y }, applications= { c o n t e n t removed f o r c l a r i t y } }

conguration structure key daemon type boolean mandatory yes description true means the server will start in daemon mode. false means it will start in console mode (nice for development) This value will be used by the server to compose paths (like media les paths). Examples: on UNIX-like systems this is / while on windows is \. Special care must be taken when you specify this values on windows because \ is an escape sequence for lua so the value should be "\\" Will hold a collection of log appenders. Each of log messages will pass through all the log appenders enumerated here. More details below Will hold a collection of loaded applications. Besides that, it will also hold few other values. More details below

pathSeparator

string(1)

yes

logAppenders

object

yes

applications

When the server starts, the following sequence of operations is performed: 1. The conguration le is loaded. Part of the loading process, is the verication. If something is wrong with the syntax please read this 2. daemon value is read. The server now will either fork to become daemon or continue as is in console mode 3. logAppenders is read. This is where all log appenders are congured and brought up to running state. Depending on the collection of your log appenders, you may (not) see further log messages 4. applications is taken into consideration. Up until now, the server doesnt do much. After this stage completes, all the applications are fully functional and the server is online and ready to do stuff

ttp h

.r t w ww : //
object yes

p m

co d.

11/22

logAppenders

Chapter 2. Conguration le

2.2 logAppenders
This section contains a list of log appenders. The entire collection of appenders listed in this section is loaded inside the logger at cong-time. All log messages will be than passed to all this log appenders. Depending on the log level, an appender may (not) log the message. Logging a message means saving it on the specied media (in the example below we have a console appender and a le).
1 2 3 4 5 6 7 8 9 10 11 12 13 14 logAppenders= { { name= c o n s o l e a p p e n d e r , t y p e = c o l o r e d C o n s o l e , l e v e l =6 }, { name= f i l e a p p e n d e r , t y p e = f i l e , l e v e l =6 , f i l e N a m e = / tmp / c r t m p s e r v e r . l o g } },

logAppenders structure key name type type string string mandatory yes yes description The name of the appender. Is usually used inside pretty print routines The type of the appender. It can be console, coloredConsole or file. console and coloredConsole will output to console. The difference between them is that coloredConsole will also apply a color to the message, depending on the log level. Quite useful when eye-balling the console. file log appender will output everything on the specied le The log level used. The values are presented just below. Any message having having a log level less or equal to this value will be logged. The rest are discarded. Example: setting level to 0, will only log FATAL errors. Setting it to 3, will only log FATAL, ERROR, WARNING and INFO If the type of appender is a file, this will contain the path of the le

level

leName

ttp h
Log levels Name Value 0 FATAL 1 ERROR 2 WARNING 3 INFO 4 DEBUG 5 FINE 6 FINEST

.r t w ww : //
number yes string yes

p m

co d.

Observation: When daemon mode is set to true, all console appenders will be ignored. (Read the explanation for daemon setting here)

12/22

applications

Chapter 2. Conguration le

2.3 applications
This section is where all the applications inside the server are placed. It holds the attributes of each application that the server will use to launch them. Each application may have specic attributes that it requires to execute its own functionality.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 applications= { r o o t D i r e c t o r y = a p p l i c a t i o n s , { }, { }, { } } settings for application 1 c o n t e n t removed f o r c l a r i t y

settings for application 2 c o n t e n t removed f o r c l a r i t y

settings for application 3 c o n t e n t removed f o r c l a r i t y

applications structure key rootDirectory type string mandatory true description The folder containing applications subfolders. If this path begins with a / or \ (depending on the OS1 ), than is treated as an absolute path. Otherwise is treated as a path relative to the run-time directory (the place where you started the server)

Following the rootDirectory, there is a collection of applications. Each application has its properties contained in an object. See details below

ttp h

.r t w ww : //

p m

co d.

1 Operating

System

13/22

application denition

Chapter 2. Conguration le

2.4 application denition

This is where the settings of an application are dened. We will present only the settings common to all applications. Later on, we will also explain the settings particular to certain applications

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56

{ name= f l v p l a y b a c k , p r o t o c o l = d y n a m i c l i n k l i b r a r y , d e s c r i p t i o n =FLV P l a y b a c k Sample , default =false , v a l i d a t e H a n d s h a k e =true , keyframeSeek =true , seekGranularity =1.5 , c l i e n t S i d e B u f f e r =12 , g e n e r a t e M e t a F i l e s =true , renameBadFiles =true , aliases= { simpleLive , vod , live , WeeklyQuest , SOSample , oflaDemo , chat , }, acceptors = { { a c c e p t o r 1 c o n t e n t removed f o r c l a r i t y }, { a c c e p t o r 2 c o n t e n t removed f o r c l a r i t y }, { a c c e p t o r n c o n t e n t removed f o r c l a r i t y }, }, externalStreams = { { s t r e a m 1 c o n t e n t removed f o r c l a r i t y }, { s t r e a m 2 c o n t e n t removed f o r c l a r i t y }, { s t r e a m n c o n t e n t removed f o r c l a r i t y }, }, authentication= { c o n t e n t removed f o r c l a r i t y }

ttp h

.r t w ww : //

p m

co d.

14/22

application denition

Chapter 2. Conguration le

application structure key name protocol description default type string string string boolean mandatory yes yes no no description Name of application. Type of application. The value dynamiclinklibrary means the application is a shared library. You can put a description of the application here. This ag designates the default application. The default application is responsible in analyzing the connect request and distribute the future connection to the correct application. Tells the server to validate the clients handshake before going further. This is optional with a default value of true. If this is true and the handshake fails, the connection is dropped. If this is false, handshake validation will not be enforced and all the connections are accepted no matter if they are correctly hand shaking or not. This instructs the streamer to seek only on key frames. In case of live streaming, this is discarded. The seek resolution/granularity value in seconds. Values are between 0.1 and 600. For example, if granularity is 10 seconds, and a seek to t=2:34 is desired, the seek will actually go to t=2:30. 60 seconds is recommended for full length movies and 1 second for video clips. The amount of client side buffer that will be maintained for each connection. Values are between 5 and 30 seconds. This will generate seek/meta les on application startup. If this ag is true and the media le cant be parsed, the media le will be renamed to *.bad. Otherwise it will be left alone. The application will also be known by this name. Acceptors hold the service that will be hosted to the server. An application can have its own acceptor, but this is not entirely required, and can be optional.

validateHandshake

boolean

no

keyframeSeek seekGranularity

boolean double

no no

clientSideBuffer generateMetaFiles renameBadFiles

double boolean boolean

no no no

aliases acceptors

object object

externalStreams authentication

h
key ip port protocol

ttp

object object

.r t w ww : //
no no no no mandatory yes yes yes

p m

co d.

acceptor structure type string string string description The IP where the service is located. 0.0.0.0 means all interfaces and all IPs. Port number that the service will listen to. The protocol stack handled by the ip:port combination.

15/22

Chapter 3

Architecture
3.1 Layers
3.1.1 3.1.2 Machine layer Operating System Layer

This layer is composed of libraries with functions that make the entire Evostream ecosystem compatible to any Operating System. OS1 -specic functions used in the whole solution are made transparent to current Operating System, avoiding any unexpected errors in compiling and running the system. With this layer, Evostream can compile and run on Linux, Windows, Mac, Solaris, and other Operating Systems.

3.1.3

This layer takes care of transporting the data in and out of the server. This layer has the Input/Output Handlers that handles the transfer of data. The network layer implements either of the 3 socket reactors depending on the Operating System:

ttp h

Networking layer

.r t w ww : //

p m

co d.

kqueue - BSD based OS2 1

epoll - Linux based OS3 1

select - win32 based OS4 1

1 Operating

System

16/22

Components

Chapter 3. Architecture

3.1.4

The components layer

3.2 Components
3.2.1 Utilities

Buffering Logging Lua Mempool Misc Tinyxml

3.2.2
kqueue epoll select

Netio

3.2.3

Protocols

These are communication protocols that are interconnected with each other to form a specic way of handling the transfer of data in and out of the server. There are Transport protocols and Endpoint protocols. Transport protocols are those that are used to transfer data further, and all protocol stack must end with an Endpoint protocol. Example is RTMPS with this order of protocols in the stack: [outside world] SSL5 HTTP6 RTMP, where SSL7 2 and HTTP8 3 are Transport protocols and RTMP is the Endpoint protocol. There should never be another protocol on top of the Endpoint protocol. Within a protocol stack are Near and Far protocols, each indicating its distance from the server. Near means a protocol that is on the right of a protocol in a stack (means the one closer to the server), whereas Far means the one on the left. In the example protocol stack RTMPS - [outside world] SSL9 2 HTTP10 3 RTMP , SSL11 2 is the Far protocol of HTTP12 3, and RTMP is its Near protocol of HTTP13 3. The protocol that is nearest to the server is the Near-endpoint (RTMP in this case), and the one closest to the outside world is the Far-enpoint (SSL14 2 in this case).

ttp h

.r t w ww : //

p m

co d.

Base Protocol The BaseProtocol class is the base class on which all protocols derive from. This is class is

Base Protocol Factory The BaseProtocolFactory class in the base class on which all protocol factory derive from.

Protocol Factory Evostream has a bank of protocols and protocol stacks that are all available applications to use. A BaseProtocolFactory class is used as a base class of all protocol factories. Atomic protocols are declared and protocol chains are spawned in the factory. Resources from the factory will then be exported for use by the applications.
5 Secure 6 Hyper

Sockets Layer Text Transfer Protocol

17/22

Components

Chapter 3. Architecture

Protocol Manager

3.2.4 3.2.5 3.2.6

v mkv mp3 mp4

Applications and protocol handlers Streaming Media formats

ttp h

.r t w ww : //

p m

co d.

18/22

Chapter 4

Interoperability
4.1 RPC 4.2 CLI 4.3 My rst application 4.4 Customize Conguration File 4.5 Create a custom protocol and a protocol factory 4.6 Extending media le formats collection

4.7 Use Evostream as Client (Test it against itself)

ttp h

.r t w ww : //

p m

co d.

19/22

Chapter 5

Troubleshooting
1. The conguration le got messed up so the server does not run correctly. You can double check the syntax of your conguration le for errors. It could take only one wrong syntax to cause runtime error. If you want to get the original copy of the conguration le from the repository, just delete your conguration le then update the source code. Dont forget to compile the source code after updating it. 2. Media les are not streaming. Make sure your server is running with no errors.

Meta and Seek les may be broken due to previous unexpected errors. Delete these les and try streaming your media again.

3. Evostream on Mac OSX is no part of this documentation.

Evostream is readily available on Mac OSX platform. Compiling, Running, and Stopping the server on your Mac can be done by following instructions on Linux/BSD. 4. On Microsoft Visual C++, errors in compilation indicates missing libraries or duplicate classes.

ttp h

Since the source code is updated regularly, there might be new denitions that need to be added on the project properties. To check these denitions, open the CMakeLists.txt located at /builders/cmake/ folder. Make sure that the pre-processor denitions in your project has the ones inside the ADD DEFINITIONS tag in the CMakeLists.txt. Dont forget to clean and build the solution.

.r t w ww : //

p m

co d.

20/22

Chapter 6

Extentions
Adding Gearman protocol support. here

ttp h

.r t w ww : //

p m

co d.

21/22

Chapter 7

Example Setups
7.1 Live streaming of a media le
This tutorial explains how to live stream a media le using ffmpeg and rtmpd. See here for details.

7.2 A Powerful Live Streaming Setup

Can the server be used in load-balancing mode? Yes, it can. More details here

7.3 A Full CentOS Build-Up

Here you can nd details about how to build and run everything on CentOS

7.4 Protecting your streams from webpage copy&paste ash code, listing or recording
This is where you can nd details of how to protect your streams. (by Rani)

ttp h

.r t w ww : //

p m

co d.

22/22