Configuration file
配置文件
The configuration file is actually a lua script which must contain an object called configuration.
This will be read by the server and used to fully configure 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 first, let's take an bird-eye view.
配置文件實際上是一個Lua腳本，它包含至少一個configuration的對象，
從而為程序提供靈活的擴展和定制功能。
除了configuration對象外，還可以有函數，Lua庫等。
Main structure
主結構
{
daemon=false,
pathSeparator="/",
logAppenders=
{
-- content removed for clarity
},
applications=
{
-- content removed for clarity
}
}
| configuration structure | |||
|---|---|---|---|
| key | type | mandatory | description |
| daemon | boolean | yes | true means the server will start in daemon mode. false means it will start in console mode (nice for development) true 表示 服務以后台方式啟動; false 表示 服務以控制台模式啟動(以用於開發); |
| pathSeparator | string(1) | yes | This value will be used by the server to compose paths (like media files 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 “\\” 用來分隔路徑; 例如，在UNIX-like是 /, Windows是 \ ; |
| logAppenders | object | yes | Will hold a collection of log appenders. Each of log messages will pass through all the log appenders enumerated here. More details below 配置日志追加的容器 |
| applications | object | yes | Will hold a collection of loaded applications. Besides that, it will also hold few other values. More detailsbelow 配置加載各種應用的容器 |
When the server starts, the following sequence of operations is performed:
服務啟動時，將按順序執行下列操作:
-
The configuration file is loaded. Part of the loading process, is the verification.
If something is wrong with the syntax please read this
配置文件加載后，首先做的就是對配置文件進行校驗，
如果配置文件有錯誤，將會有錯誤提示並停止啟動，可進行修改后再啟動 -
daemon value is read. The server now will either fork to become daemon
or continue as is in console mode
讀取 daemon 值，判斷服務是以后台方式啟動還是以控制台方式啟動 -
logAppenders is read. This is where all log appenders are configured and brought up to running state.
Depending on the collection of your log appenders, you may (not) see further log messages
讀取日志追加器，用來配置日志記錄並啟動到運行狀態，
依據日志追加器，可以看到更多的日志信息 -
applications is taken into consideration. Up until now, the server doesn't do much.
After this stage completes, all the applications are fully functional and the server is online and ready to do stuff
最后的應用加載，只到這一步完成后，服務和應用才在線，並准備就緒。
日志追加器
logAppenders
This section contains a list of log appenders. The entire collection of appenders listed in this section
is loaded inside the logger at config-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 specified “media” (in the example below we have a console appender and a file).
這部分包含了一個日志追加器的列表。
整個日志追加器的添加是在加載時配置，
依據日志級別，追加器可以選擇是否有日志消息輸出到指定目的處；
logAppenders=
{
{
name="console appender",
type="coloredConsole",
level=6
},
{
name="file appender",
type="file",
level=6,
fileName="/tmp/crtmpserver.log"
}
},
| logAppenders structure | |||
|---|---|---|---|
| key | type | mandatory | description |
| name | string | yes | The name of the appender. Is usually used inside pretty print routines 追加器的名字. |
| type | string | yes | 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 specified file 追加器的類型 可以是控制台，帶顏色控制台或文件； 控制台和帶顏色控制台 都會將日志消息輸出到控制台， 不同之處在於帶顏色控制台會依據日志級別進行顏色標記； 文件類型則會將所有消息輸出到指定的文件； |
| level | number | yes | 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 日志的級別 可見下表中的級別定義； 只有小於或等於這個級別的日志消息會被記錄，高於這個級別則都被丟棄； 例如: 級別為0時，只記錄 FATAL 消息； 級別為3時，只記錄 FATAL, ERROR, WARNING, INFO 消息； |
| fileName | string | yes | If the type of appender is a file, this will contain the path of the file 如果追加器類型為文件，則在此處指定日志文件和路徑 |
| Log levels | |
|---|---|
| Name | Value |
| 0 | FATAL |
| 1 | ERROR |
| 2 | WARNING |
| 3 | INFO |
| 4 | DEBUG |
| 5 | FINE |
| 6 | FINEST |
Observation: When daemon mode is set to true, all console appenders will be ignored.
(Read the explanation for daemon setting here)
注意:
當使用后台模式時，所有的控制台追加消息將會被忽略。
應用
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 specific attributes that it requires to execute its own functionality.
這部分用來配置各種應用，並設置這些應用的屬性；
每個應用的屬性都對應了這個應用的指定功能；
applications=
{
rootDirectory="applications",
{
-- settings for application 1
-- content removed for clarity
},
{
-- settings for application 2
-- content removed for clarity
},
{
-- settings for application 3
-- content removed for clarity
}
}
| applications structure | |||
|---|---|---|---|
| key | type | mandatory | description |
| rootDirectory | string | true | The folder containing applications subfolders. If this path begins with a / or \ (depending on the OS), 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
rootDirectory 之后，是應用的集合；每個應用都定義了一個有特定屬性的對象；
細節如下所示；
應用定義
application definition
This is where the settings of an application are defined. We will present only the
settings common to all applications. Later on, we will also explain the settings particular to certain
applications Since revision 790 there is a new cool feature: mediaStorage; with this feature
basicaly an application may have multiple mediaFolder's and .seek/.meta files are now stored into
separate folder from media file that are streamed.
這些目錄用來定義應用.
自從790版本后，添加了一新的功能：mediaStorage;
這個功能能使應用可以有多個mediaFolder，
並且可以將.seek/.meta文件和媒體文件分開存儲在不同的文件夾中；
{
name="flvplayback",
protocol="dynamiclinklibrary",
description="FLV Playback Sample",
default=false,
validateHandshake=true,
enableCheckBandwidth=true,
-- this settings are now part of mediaStorage setting
-- keyframeSeek=true,
-- seekGranularity=1.5,
-- clientSideBuffer=12,
-- generateMetaFiles=true,
-- renameBadFiles=true,
aliases=
{
"simpleLive",
"vod",
"live",
"WeeklyQuest",
"SOSample",
"oflaDemo",
"chat",
},
acceptors =
{
{
-- acceptor 1
-- content removed for clarity
},
{
-- acceptor 2
-- content removed for clarity
},
{
-- acceptor n
-- content removed for clarity
},
},
-- new feature mediaStorage
mediaStorage = {
namedStorage1={
description="Main storage",
mediaFolder="/usr/main_storage/media", -- only this parameter IS MANDATORY
metaFolder="/usr/main_storage/metadata", -- if you have static large file to stream it is good to know that for a file around 500MB
-- it's .seek file has around 16MB; so it would be preffer to designate metafolder into a system
-- partition which has enough space... for no surprises... :)
statsFolder="/usr/main_storage/statsFolder",
enableStats=true,
clientSideBuffer=16,
keyframeSeek=false, -- should crtmpdserver DO SEEK ONLY IN key-frame (true/false)?
-- very useful to know in situations like play/pause/resume (meaning pause/seek/play)
seekGranularity=1,
generateMetaFiles=false,
renameBadFiles=false,
},
--[[{
-- here is another example of storage; it does not start with name={...}
description="Second storage of same application",
mediaFolder="/usr/second_storage/media/flv",
metaFolder="/usr/second_storage/metadata",
statsFolder="/usr/second_storage/statsFolder",
},]]--
},
externalStreams =
{
{
-- stream 1
-- content removed for clarity
},
{
-- stream 2
-- content removed for clarity
},
{
-- stream n
-- content removed for clarity
},
},
authentication=
{
-- content removed for clarity
}
}
| application structure | |||
|---|---|---|---|
| key | type | mandatory | description |
| name | string | yes | Name of application. 應用的名稱 |
| protocol | string | yes | Type of application. The value dynamiclinklibrary means the application is a shared library. 應用的類型 值為 dynamiclinklibrary 意即 應用是一個共享庫 |
| description | string | no | You can put a description of the application here. 應用的描述信息 |
| default | boolean | no | This flag designates the default application. The default application is responsible in analyzing the connectrequest and distribute the future connection to the correct application. 這個標志指定了默認應用； 默認應用負責分析連接請求並將連接分配到正確的應用 |
| validateHandshake | boolean | no | Tells the server to validate the client's 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. 通知服務器在進行下一步前要對客戶端的握手進行驗證； 這是一個可選項，其默認值為真。 如果這個值為真 且 握手失敗，服務器就放棄這個連接。 如果這個值為假，則不會進行強制的握手驗證，所有的連接都會被接受； |
| keyframeSeek | boolean | no | This instructs the streamer to seek only on key frames. In case of live streaming, this is discarded. 這個屬性指定了流生成器只在關鍵幀搜索， 如果是直播流，則忽略這個值 |
| seekGranularity | double | no | 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. 60seconds is recommended for full length movies and 1 second for video clips. 搜索的精細度，以秒為單位, 值域定義在 0.1 ~ 600; 例如： 如果粒度定義為10秒，並期望定位到 t= 2:34; 則實際上是會定位到 t= 2:30. 60秒被認定為完整的電影長度，1秒為電影片斷； |
| clientSideBuffer | double | no | The amount of client side buffer that will be maintained for each connection. Values are between 5 and30 seconds. 每個連接在客戶端的緩沖秒數，值定義在5 ~ 30 秒； |
| generateMetaFiles | boolean | no | This will generate seek/meta files on application startup. 在應用啟動前生成 seek/meta文件 |
| renameBadFiles | boolean | no | If this flag is true and the media file can't be parsed, the media file will be renamed to *.bad. Otherwise it will be left alone. 如果這上值為真且媒體文件是不能被解析的，則媒體文件被重命名為 *.bad， 否則這樣的文件將不做處理 |
| aliases | object | no | The application will also be known by this name. 應用的別名 |
| acceptors | object | no | 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. 接受器保持這個服務並讓服務器托管； 應用可以有它自己的接受器，但這個是可選的； |
| externalStreams | object | no | |
| authentication | object | no | |
| mediaFolder | string | yes | When define mediaStorage this field is mandatory as it points out physical location of media files. 當定義了 mediaStorage時，這個域用來指定媒體文件的物理位置； |
| metaFolder | string | no | It holds the location where .seek/.meta files created from files inside mediaFolder are stored. 指定用來存放 .seek/.meta文件的位置； |
| statsFolder | string | no | Location for stats files. 服狀態文件的位置 |
| acceptor structure | |||
|---|---|---|---|
| key | type | mandatory | description |
| ip | string | yes | The IP where the service is located. 0.0.0.0 means all interfaces and all IPs. 服務所在的IP, 0.0.0.0表示所有接口和所有IP; |
| port | string | yes | Port number that the service will listen to. 服務監聽的端口號 |
| protocol | string | yes | The protocol stack handled by the ip:port combination. 對應 ip:port的服務的協議 |