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
}
}
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"
}
},
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 如果追加器类型为文件,则在此处指定日志文件和路径 |
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
}
}
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
}
}
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. 服状态文件的位置 |
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的服务的协议 |
相关推荐
在提供的压缩包文件`jwplayer6`中,可能包含了JWPlayer的最新版代码和配置示例,这将帮助开发者快速集成和调试播放器,实现与crtmpserver的无缝对接。 **总结** crtmpserver与JWPlayer的结合,为构建高效、灵活的...
4. 示例脚本:包含示例的配置文件和脚本,帮助用户快速了解和应用`crtmpserver`的基本用法。 5. FAQ和常见问题解答:解决用户在使用过程中可能遇到的问题。 **Windows平台的部署** 在Windows平台上部署`...
安装完成后,你需要配置crtmpserver的配置文件`rtmp.conf`,定义监听端口、虚拟主机、应用程序路径、日志设置等。配置完成后,启动服务器: ```bash /path/to/crtmpserver/sbin/crtmpserver ``` **五、crtmpserver...
为了使用`crtmpserver`和`remp`,开发者需要熟悉相关技术和工具,如服务器配置、网络编程、数据库操作等。同时,为了保证流媒体服务的稳定运行,还需要关注带宽、存储、计算资源的合理分配,以及网络安全问题。 总...
嵌入式八股文面试题库资料知识宝典-华为的面试试题.zip
训练导控系统设计.pdf
嵌入式八股文面试题库资料知识宝典-网络编程.zip
人脸转正GAN模型的高效压缩.pdf
少儿编程scratch项目源代码文件案例素材-几何冲刺 转瞬即逝.zip
少儿编程scratch项目源代码文件案例素材-鸡蛋.zip
嵌入式系统_USB设备枚举与HID通信_CH559单片机USB主机键盘鼠标复合设备控制_基于CH559单片机的USB主机模式设备枚举与键盘鼠标数据收发系统支持复合设备识别与HID
嵌入式八股文面试题库资料知识宝典-linux常见面试题.zip
面向智慧工地的压力机在线数据的预警应用开发.pdf
基于Unity3D的鱼类运动行为可视化研究.pdf
少儿编程scratch项目源代码文件案例素材-霍格沃茨魔法学校.zip
少儿编程scratch项目源代码文件案例素材-金币冲刺.zip
内容概要:本文深入探讨了HarmonyOS编译构建子系统的作用及其技术细节。作为鸿蒙操作系统背后的关键技术之一,编译构建子系统通过GN和Ninja工具实现了高效的源代码到机器代码的转换,确保了系统的稳定性和性能优化。该系统不仅支持多系统版本构建、芯片厂商定制,还具备强大的调试与维护能力。其高效编译速度、灵活性和可扩展性使其在华为设备和其他智能终端中发挥了重要作用。文章还比较了HarmonyOS编译构建子系统与安卓和iOS编译系统的异同,并展望了其未来的发展趋势和技术演进方向。; 适合人群:对操作系统底层技术感兴趣的开发者、工程师和技术爱好者。; 使用场景及目标:①了解HarmonyOS编译构建子系统的基本概念和工作原理;②掌握其在不同设备上的应用和优化策略;③对比HarmonyOS与安卓、iOS编译系统的差异;④探索其未来发展方向和技术演进路径。; 其他说明:本文详细介绍了HarmonyOS编译构建子系统的架构设计、核心功能和实际应用案例,强调了其在万物互联时代的重要性和潜力。阅读时建议重点关注编译构建子系统的独特优势及其对鸿蒙生态系统的深远影响。
嵌入式八股文面试题库资料知识宝典-奇虎360 2015校园招聘C++研发工程师笔试题.zip
嵌入式八股文面试题库资料知识宝典-腾讯2014校园招聘C语言笔试题(附答案).zip
双种群变异策略改进RWCE算法优化换热网络.pdf