SRS Config 一 基础配置

Config

srs 流媒体服务配置官方文档已经很详细了,本文仅记录部分配置过程

srs.conf同级目录下 新建 self.conf

仿照srs.conf 添加基础配置

1 rtmp 

RTMP是直播的事实标准,这么多年以来一直是使用最广泛的直播协议。

然而Adobe公司没有一直更新RTMP协议,也没有提交给标准组织比如RFC,因此很多新功能都没有支持,比如HEVC或Opus。 直到2023.03,终于Enhanced RTMP项目建立,开始支持了HEVC和AV1, SRS和OBS已经支持了基于Enhanced RTMP的HEVC编码。

在流的制作方面,最近几年,SRT、WebRTC和SRT增长迅速,很多设备都支持了SRT和RIST协议。你也可以用WebRTC做直播。

在流的分发上,HLS是使用最广泛的协议,所有CDN和设备都支持,比如PC,iOS,Android或平板电脑。当然HLS延迟比较大(3~5s+), 你可以选择HTTP-FLV,HTTP-TS或者WebRTC,如果需要降低延迟。

至今为止,在内容制作领域,RTMP还是使用最广泛的协议。比如你可以用OBS推流到B站、视频号或快手。如果要对接一个广播设备, 或者推流到某个平台,那么RTMP是最好的选择,几乎都会支持。


full config

vhost __defaultVhost__ {
    # whether enable min delay mode for vhost.
    # for min latency mode:
    # 1. disable the publish.mr for vhost.
    # 2. use timeout for cond wait for consumer queue.
    # @see https://github.com/ossrs/srs/issues/257
    # default: off (for RTMP/HTTP-FLV)
    # default: on (for WebRTC)
    min_latency off;

    # whether enable the TCP_NODELAY
    # if on, set the nodelay of fd by setsockopt
    # Overwrite by env SRS_VHOST_TCP_NODELAY for all vhosts.
    # default: off
    tcp_nodelay off;

    # the default chunk size is 128, max is 65536,
    # some client does not support chunk size change,
    # vhost chunk size will override the global value.
    # Overwrite by env SRS_VHOST_CHUNK_SIZE for all vhosts.
    # default: global chunk size.
    chunk_size 128;
    
    # The input ack size, 0 to not set.
    # Generally, it's set by the message from peer,
    # but for some peer(encoder), it never send message but use a different ack size.
    # We can chnage the default ack size in server-side, to send acknowledge message,
    # or the encoder maybe blocked after publishing for some time.
    # Overwrite by env SRS_VHOST_IN_ACK_SIZE for all vhosts.
    # Default: 0
    in_ack_size 0;
    
    # The output ack size, 0 to not set.
    # This is used to notify the peer(player) to send acknowledge to server.
    # Overwrite by env SRS_VHOST_OUT_ACK_SIZE for all vhosts.
    # Default: 2500000
    out_ack_size 2500000;
    
    # the config for FMLE/Flash publisher, which push RTMP to SRS.
    publish {
        # about MR, read https://github.com/ossrs/srs/issues/241
        # when enabled the mr, SRS will read as large as possible.
        # Overwrite by env SRS_VHOST_PUBLISH_MR for all vhosts.
        # default: off
        mr off;
        # the latency in ms for MR(merged-read),
        # the performance+ when latency+, and memory+,
        #       memory(buffer) = latency * kbps / 8
        # for example, latency=500ms, kbps=3000kbps, each publish connection will consume
        #       memory = 500 * 3000 / 8 = 187500B = 183KB
        # when there are 2500 publisher, the total memory of SRS at least:
        #       183KB * 2500 = 446MB
        # the recommended value is [300, 2000]
        # Overwrite by env SRS_VHOST_PUBLISH_MR_LATENCY for all vhosts.
        # default: 350
        mr_latency 350;

        # the 1st packet timeout in ms for encoder.
        # Overwrite by env SRS_VHOST_PUBLISH_FIRSTPKT_TIMEOUT for all vhosts.
        # default: 20000
        firstpkt_timeout 20000;
        # the normal packet timeout in ms for encoder.
        # Overwrite by env SRS_VHOST_PUBLISH_NORMAL_TIMEOUT for all vhosts.
        # default: 5000
        normal_timeout 7000;
        # whether parse the sps when publish stream.
        # we can got the resolution of video for stat api.
        # but we may failed to cause publish failed.
        # @remark If disabled, HLS might never update the sps/pps, it depends on this.
        # Overwrite by env SRS_VHOST_PUBLISH_PARSE_SPS for all vhosts.
        # default: on
        parse_sps on;
        # When parsing SPS/PPS, whether try ANNEXB first. If not, try IBMF first, then ANNEXB.
        # Overwrite by env SRS_VHOST_PUBLISH_TRY_ANNEXB_FIRST for all vhosts.
        # default: on
        try_annexb_first on;
        # The timeout in seconds to disconnect publisher when idle, which means no players.
        # Note that 0 means no timeout or this feature is disabled.
        # Note that this feature conflicts with forward, because it disconnect the publisher stream.
        # Overwrite by env SRS_VHOST_PUBLISH_KICKOFF_FOR_IDLE for all vhosts.
        # default: 0
        kickoff_for_idle 0;
    }
    
    # for play client, both RTMP and other stream clients,
    # for instance, the HTTP FLV stream clients.
    play {
        # whether cache the last gop.
        # if on, cache the last gop and dispatch to client,
        #   to enabled fast startup for client, client play immediately.
        # if off, send the latest media data to client,
        #   client need to wait for the next Iframe to decode and show the video.
        # set to off if requires min delay;
        # set to on if requires client fast startup.
        # Overwrite by env SRS_VHOST_PLAY_GOP_CACHE for all vhosts.
        # default: on
        gop_cache off;

        # Limit the max frames in gop cache. It might cause OOM if video stream has no IDR frame, so we limit to N
        # frames by default. Note that it's the size of gop cache, including videos, audios and other messages.
        # Overwrite by env SRS_VHOST_PLAY_GOP_CACHE_MAX_FRAMES for all vhosts.
        # default: 2500
        gop_cache_max_frames 2500;

        # the max live queue length in seconds.
        # if the messages in the queue exceed the max length,
        # drop the old whole gop.
        # Overwrite by env SRS_VHOST_PLAY_QUEUE_LENGTH for all vhosts.
        # default: 30
        queue_length 10;

        # about the stream monotonically increasing:
        #   1. video timestamp is monotonically increasing,
        #   2. audio timestamp is monotonically increasing,
        #   3. video and audio timestamp is interleaved/mixed monotonically increasing.
        # it's specified by RTMP specification, @see 3. Byte Order, Alignment, and Time Format
        # however, some encoder cannot provides this feature, please set this to off to ignore time jitter.
        # the time jitter algorithm:
        #   1. full, to ensure stream start at zero, and ensure stream monotonically increasing.
        #   2. zero, only ensure stream start at zero, ignore timestamp jitter.
        #   3. off, disable the time jitter algorithm, like atc.
        # @remark for full, correct timestamp only when |delta| > 250ms.
        # @remark disabled when atc is on.
        # Overwrite by env SRS_VHOST_PLAY_TIME_JITTER for all vhosts.
        # default: full
        time_jitter full;
        # vhost for atc for hls/hds/rtmp backup.
        # generally, atc default to off, server delivery rtmp stream to client(flash) timestamp from 0.
        # when atc is on, server delivery rtmp stream by absolute time.
        # atc is used, for instance, encoder will copy stream to master and slave server,
        # server use atc to delivery stream to edge/client, where stream time from master/slave server
        # is always the same, client/tools can slice RTMP stream to HLS according to the same time,
        # if the time not the same, the HLS stream cannot slice to support system backup.
        #
        # @see http://www.adobe.com/cn/devnet/adobe-media-server/articles/varnish-sample-for-failover.html
        # @see http://www.baidu.com/#wd=hds%20hls%20atc
        #
        # @remark when atc is on, auto off the time_jitter
        # Overwrite by env SRS_VHOST_PLAY_ATC for all vhosts.
        # default: off
        atc off;
        # whether use the interleaved/mixed algorithm to correct the timestamp.
        # if on, always ensure the timestamp of audio+video is interleaved/mixed monotonically increase.
        # if off, use time_jitter to correct the timestamp if required.
        # @remark to use mix_correct, atc should on(or time_jitter should off).
        # Overwrite by env SRS_VHOST_PLAY_MIX_CORRECT for all vhosts.
        # default: off
        mix_correct off;

        # whether enable the auto atc,
        # if enabled, detect the bravo_atc="true" in onMetaData packet,
        # set atc to on if matched.
        # always ignore the onMetaData if atc_auto is off.
        # Overwrite by env SRS_VHOST_PLAY_ATC_AUTO for all vhosts.
        # default: off
        atc_auto off;

        # set the MW(merged-write) latency in ms.
        # SRS always set mw on, so we just set the latency value.
        # the latency of stream >= mw_latency + mr_latency
        # the value recomment is [300, 1800]
        # @remark For WebRTC, we enable pass-by-timestamp mode, so we ignore this config.
        # default: 350 (For RTMP/HTTP-FLV)
        # Overwrite by env SRS_VHOST_PLAY_MW_LATENCY for all vhosts.
        # default: 0 (For WebRTC)
        mw_latency 350;

        # Set the MW(merged-write) min messages.
        # default: 0 (For Real-Time, min_latency on)
        # default: 1 (For WebRTC, min_latency off)
        # default: 8 (For RTMP/HTTP-FLV, min_latency off).
        # Overwrite by env SRS_VHOST_PLAY_MW_MSGS for all vhosts.
        mw_msgs 8;

        # the minimal packets send interval in ms,
        # used to control the ndiff of stream by srs_rtmp_dump,
        # for example, some device can only accept some stream which
        # delivery packets in constant interval(not cbr).
        # @remark 0 to disable the minimal interval.
        # @remark >0 to make the srs to send message one by one.
        # @remark user can get the right packets interval in ms by srs_rtmp_dump.
        # Overwrite by env SRS_VHOST_PLAY_SEND_MIN_INTERVAL for all vhosts.
        # default: 0
        send_min_interval 10.0;
        # whether reduce the sequence header,
        # for some client which cannot got duplicated sequence header,
        # while the sequence header is not changed yet.
        # Overwrite by env SRS_VHOST_PLAY_REDUCE_SEQUENCE_HEADER for all vhosts.
        # default: off
        reduce_sequence_header on;
    }
}

listen              1935;
max_connections     1000;
#srs_log_tank        file;
#srs_log_file        ./objs/srs.log;
daemon              on;

2 http-server

SRS内嵌了一个web服务器,支持api和简单的文件分发。

部署和使用SRS的内嵌http服务器,参考:Usage: HTTP

SRS的内置HTTP服务器已经参考GO的HTTP模块重写,满足商用要求,可以当作web服务器使用。参考:#277

备注:SRS只支持源站HTTP分发,边缘还是需要用Web服务器比如NGINX、SQUID或ATS等。

Use Scenario

它的定位很简单:智能手机上的摄像头。

Nginx/Apache/lighthttpd等众多HTTP server大佬就是专业的单反,老长老长镜头了。 难道有了单反智能手机上就不能有摄像头?不会吧!而且必须有。所以不是要和nginx拼个你死我活, 定位不一样,就像fms内嵌apache一样(不过fms嵌得很烂),真的有必要而且方便。

为何srs不内嵌一个nginx呢?智能手机上能内嵌一个单反长镜头么?我去,那是怪物吧。 nginx14万行代码,巨大无比,srs才2万行,如何能内嵌呢?最核心的原因是:srs需要提供http的api, 方便外部管理和调用;这点往往都毫无异议,但是提到srs要内嵌web服务器,就都炸开锅啦。 OK,其实就是http的api稍微扩展点,支持读文件后发送给客户端。

srs会一如既往的保持最简单,http的代码不会有多少行,功能不会有几个,就支持简单的文件分发就足够了。可以:

  • 只需要部署一个服务器就可以分发RTMP和HLS。
  • SRS对于HLS/HDS/DASH的支持会更完善。
  • SRS可以支持点播,动态转封装等。
  • SRS依然可以用nginx作为反向代理,或者禁用这个选项,使用nginx分发。

实际上,RTMP协议本身比HTTP复杂很多,所以st来做http分发,没有任何不可以的地方,更何况只是做部分。所以,淡定~

full  config

# embeded http server in srs.
# the http streaming config, for HLS/HDS/DASH/HTTPProgressive
# global config for http streaming, user must config the http section for each vhost.
# the embed http server used to substitute nginx in ./objs/nginx,
# for example, srs runing in arm, can provides RTMP and HTTP service, only with srs installed.
# user can access the http server pages, generally:
#       curl http://192.168.1.170:80/srs.html
# which will show srs version and welcome to srs.
# @remeark, the http embeded stream need to config the vhost, for instance, the __defaultVhost__
# need to open the feature http of vhost.
http_server {
    # whether http streaming service is enabled.
    # Overwrite by env SRS_HTTP_SERVER_ENABLED
    # default: off
    enabled on;
    # the http streaming listen entry is <[ip:]port>
    # for example, 192.168.1.100:8080
    # where the ip is optional, default to 0.0.0.0, that is 8080 equals to 0.0.0.0:8080
    # @remark, if use lower port, for instance 80, user must start srs by root.
    # Overwrite by env SRS_HTTP_SERVER_LISTEN
    # default: 8080
    listen 8080;
    # the default dir for http root.
    # Overwrite by env SRS_HTTP_SERVER_DIR
    # default: ./objs/nginx/html
    dir ./objs/nginx/html;
    # whether enable crossdomain request.
    # for both http static and stream server and apply on all vhosts.
    # Overwrite by env SRS_HTTP_SERVER_CROSSDOMAIN
    # default: on
    crossdomain on;
    # For https_server or HTTPS Streaming.
    https {
        # Whether enable HTTPS Streaming.
        # Overwrite by env SRS_HTTP_SERVER_HTTPS_ENABLED
        # default: off
        enabled on;
        # The listen endpoint for HTTPS Streaming.
        # Overwrite by env SRS_HTTP_SERVER_HTTPS_LISTEN
        # default: 8088
        listen 8088;
        # The SSL private key file, generated by:
        #       openssl genrsa -out server.key 2048
        # Overwrite by env SRS_HTTP_SERVER_HTTPS_KEY
        # default: ./conf/server.key
        key ./conf/server.key;
        # The SSL public cert file, generated by:
        #       openssl req -new -x509 -key server.key -out server.crt -days 3650 -subj "/C=CN/ST=Beijing/L=Beijing/O=Me/OU=Me/CN=ossrs.net"
        # Overwrite by env SRS_HTTP_SERVER_HTTPS_CERT
        # default: ./conf/server.crt
        cert ./conf/server.crt;
    }

这里只引入部分 

http_api {
    enabled         on;
    listen          1985;
}
http_server {
    enabled         on;
    listen          8080;
    dir             ./objs/nginx/html;
}

3 webrtc

如果需要支持webrtc 需要配置 否则不需要加入rtc部分

full 配置

rtc_server {
    # Whether enable WebRTC server.
    # Overwrite by env SRS_RTC_SERVER_ENABLED
    # default: off
    enabled on;
    # The udp listen port, we will reuse it for connections.
    # Overwrite by env SRS_RTC_SERVER_LISTEN
    # default: 8000
    listen 8000;
    # For WebRTC over TCP directly, not TURN, see https://github.com/ossrs/srs/issues/2852
    # Some network does not support UDP, or not very well, so we use TCP like HTTP/80 port for firewall traversing.
    tcp {
        # Whether enable WebRTC over TCP.
        # Overwrite by env SRS_RTC_SERVER_TCP_ENABLED
        # Default: off
        enabled off;
        # The TCP listen port for WebRTC. Highly recommend is some normally used ports, such as TCP/80, TCP/443,
        # TCP/8000, TCP/8080 etc. However SRS default to TCP/8000 corresponding to UDP/8000.
        # Overwrite by env SRS_RTC_SERVER_TCP_LISTEN
        # Default: 8000
        listen 8000;
    }
    # The protocol for candidate to use, it can be:
    #       udp         Generate UDP candidates. Note that UDP server is always enabled for WebRTC.
    #       tcp         Generate TCP candidates. Fail if rtc_server.tcp(WebRTC over TCP) is disabled.
    #       all         Generate UDP+TCP candidates. Ignore if rtc_server.tcp(WebRTC over TCP) is disabled.
    # Note that if both are connected, we will use the first connected(DTLS done) one.
    # Overwrite by env SRS_RTC_SERVER_PROTOCOL
    # Default: udp
    protocol udp;
    # The exposed candidate IPs, response in SDP candidate line. It can be:
    #       *           Retrieve server IP automatically, from all network interfaces.
    #       $CANDIDATE  Read the IP from ENV variable, use * if not set.
    #       x.x.x.x     A specified IP address or DNS name, use * if 0.0.0.0.
    # @remark For Firefox, the candidate MUST be IP, MUST NOT be DNS name, see https://bugzilla.mozilla.org/show_bug.cgi?id=1239006
    # @see https://ossrs.net/lts/zh-cn/docs/v4/doc/webrtc#config-candidate
    # Overwrite by env SRS_RTC_SERVER_CANDIDATE
    # default: *
    candidate *;
}

vhost rtc.vhost.srs.com {
    rtc {
        # Whether enable WebRTC server.
        # Overwrite by env SRS_VHOST_RTC_ENABLED for all vhosts.
        # default: off
        enabled on;
        # Whether support NACK.
        # default: on
        nack on;
        # Whether support TWCC.
        # default: on
        twcc on;
        # The timeout in seconds for session timeout.
        # Client will send ping(STUN binding request) to server, we use it as heartbeat.
        # default: 30
        stun_timeout 30;
        # The role of dtls when peer is actpass: passive or active
        # default: passive
        dtls_role passive;
        # Whether enable transmuxing RTMP to RTC.
        # If enabled, transcode aac to opus.
        # Overwrite by env SRS_VHOST_RTC_RTMP_TO_RTC for all vhosts.
        # default: off
        rtmp_to_rtc off;
        # Whether enable transmuxing RTC to RTMP.
        # Overwrite by env SRS_VHOST_RTC_RTC_TO_RTMP for all vhosts.
        # Default: off
        rtc_to_rtmp off;
    }
}

这里只引入部分

rtc_server {
    enabled on;
    listen 8000; # UDP port
    # @see https://ossrs.net/lts/zh-cn/docs/v4/doc/webrtc#config-candidate
   # candidate $CANDIDATE;
    candidate 192.168.1.116;
}

vhost __defaultVhost__ {
    ...
    rtc {
        enabled     on;
        # @see https://ossrs.net/lts/zh-cn/docs/v4/doc/webrtc#rtmp-to-rtc
        rtmp_to_rtc on;
        # @see https://ossrs.net/lts/zh-cn/docs/v4/doc/webrtc#rtc-to-rtmp
        rtc_to_rtmp off;
    }
   ...
}

 关于candidate 开启rtmp_to_rtc on 不进行推流 当前candiata $CANDIDATE配置可不用更改

(webrtc localhost播放流 )

推流弹框https

配置浏览器https支持,由于webrtc需要https,本地测试配置证书又很麻烦,需要修改下浏览器配置。

在谷歌浏览器地址栏输入:chrome://flags/#unsafely-treat-insecure-origin-as-secure

 启用功能,输入框中输入你对应的地址 http://192.168.1.116:8080,多个用英文逗号隔开。在这里配置后。浏览器会在访问这个地址的时候,会以https的方式去访问http网站。

webrtc 推流

需要 配置好candidate 192.168.1.116

通过srs工具或者obs推流

obs 推流
1 设置推流地址 

2 设置采集来源

设置本地文件媒体

设置窗口来源

localhost 这里为192.168.1.116

3 开始直播

播放webrtc 流

4 rtmp->webrtc

  rtmp_to_rtc on;

rtc {
        enabled     on;
        # @see https://ossrs.net/lts/zh-cn/docs/v4/doc/webrtc#rtmp-to-rtc
        rtmp_to_rtc on;
        # @see https://ossrs.net/lts/zh-cn/docs/v4/doc/webrtc#rtc-to-rtmp
        rtc_to_rtmp off;
    }

6 DVR

DVR的计划即决定什么时候关闭flv文件,打开新的flv文件,主要的录制计划包括:

  • session:按照session来关闭flv文件,即编码器停止推流时关闭flv,整个session录制为一个flv。
  • segment:按照时间分段录制,flv文件时长配置为dvr_duration和dvr_wait_keyframe。注意:若不按关键帧切flv(即dvr_wait_keyframe配置为off),所以会导致后面的flv启动时会花屏。
  • time_jitter: 时间戳抖动算法。full使用完全的时间戳矫正;zero只是保证从0开始;off不矫正时间戳。
  • dvr_path: 录制的路径,规则参考下一章。

参考conf/dvr.segment.confconf/dvr.session.conf配置实例。

# dvr

    dvr {
        enabled      on;
        dvr_path     ./objs/nginx/html/[app]/[stream].[timestamp].mp4;
        dvr_plan     segment;
           # the filter for dvr to apply to.
        #       all, dvr all streams of all apps.
        #       <app>/<stream>, apply to specified stream of app.
        # for example, to dvr the following two streams:
        #       live/stream1 live/stream2
        # default: all
        dvr_apply       all;
        # the dvr plan. canbe:
        #       session reap flv/mp4 when session end(unpublish).
        #       segment reap flv/mp4 when flv duration exceed the specified dvr_duration.
        # @remark The plan append is removed in SRS3+, for it's no use.
        # default: session

                # the duration for dvr file, reap if exceed, in seconds.
        #       segment apply it.
        #       session,append ignore.
        # default: 30
        dvr_duration    30;
        # whether wait keyframe to reap segment,
        # if off, reap segment when duration exceed the dvr_duration,
        # if on, reap segment when duration exceed and got keyframe.
        #       segment apply it.
        #       session,append ignore.
        # default: on
        dvr_wait_keyframe       on;
        # about the stream monotonically increasing:
        #   1. video timestamp is monotonically increasing,
        #   2. audio timestamp is monotonically increasing,
        #   3. video and audio timestamp is interleaved monotonically increasing.
        # it's specified by RTMP specification, @see 3. Byte Order, Alignment, and Time Format
        # however, some encoder cannot provides this feature, please set this to off to ignore time jitter.
        # the time jitter algorithm:
        #   1. full, to ensure stream start at zero, and ensure stream monotonically increasing.
        #   2. zero, only ensure stream start at zero, ignore timestamp jitter.
        #   3. off, disable the time jitter algorithm, like atc.
        # apply for all dvr plan.
        # default: full
        time_jitter             full;

        # on_dvr, never config in here, should config in http_hooks.
        # for the dvr http callback, @see http_hooks.on_dvr of vhost hooks.callback.srs.com
        # @see https://ossrs.net/lts/zh-cn/docs/v4/doc/dvr#http-callback
        # @see https://ossrs.net/lts/zh-cn/docs/v4/doc/dvr#http-callback
    }

这里设置 30S自动切片 等待关键帧  生成路径及命名规则

 dvr_path     ./objs/nginx/html/[app]/[stream].[timestamp].mp4; 年月日方式更直观

按流和年月日分目录,时间作为文件名: dvr_path /data/[vhost]/[app]/[stream]/[2006]/[01]/[02]/[15].[04].[05].[999].flv; => dvr_path /data/ossrs.net/live/livestream/2015/01/03/10.57.30.776.flv;

至此 self.conf

# main config for srs.
# @see full.conf for detail config.

listen              1935;
max_connections     1000;
#srs_log_tank        file;
#srs_log_file        ./objs/srs.log;
daemon              on;
http_api {
    enabled         on;
    listen          1985;
}
http_server {
    enabled         on;
    listen          8080;
    dir             ./objs/nginx/html;
}
rtc_server {
    enabled on;
    listen 8000; # UDP port
    # @see https://ossrs.net/lts/zh-cn/docs/v4/doc/webrtc#config-candidate
    candidate 192.168.1.116;
}
vhost __defaultVhost__ {
    hls {
        enabled         on;
    }
    http_remux {
        enabled     on;
        mount       [vhost]/[app]/[stream].flv;
    }
    rtc {
        enabled     on;
        # @see https://ossrs.net/lts/zh-cn/docs/v4/doc/webrtc#rtmp-to-rtc
        rtmp_to_rtc on;
        # @see https://ossrs.net/lts/zh-cn/docs/v4/doc/webrtc#rtc-to-rtmp
        rtc_to_rtmp off;
    }

    play{
        gop_cache_max_frames 2500;
    }

    # dvr

    dvr {
        enabled      on;
        dvr_path     ./objs/nginx/html/[app]/[stream].[timestamp].mp4;
        dvr_plan     segment;
           # the filter for dvr to apply to.
        #       all, dvr all streams of all apps.
        #       <app>/<stream>, apply to specified stream of app.
        # for example, to dvr the following two streams:
        #       live/stream1 live/stream2
        # default: all
        dvr_apply       all;
        # the dvr plan. canbe:
        #       session reap flv/mp4 when session end(unpublish).
        #       segment reap flv/mp4 when flv duration exceed the specified dvr_duration.
        # @remark The plan append is removed in SRS3+, for it's no use.
        # default: session

                # the duration for dvr file, reap if exceed, in seconds.
        #       segment apply it.
        #       session,append ignore.
        # default: 30
        dvr_duration    30;
        # whether wait keyframe to reap segment,
        # if off, reap segment when duration exceed the dvr_duration,
        # if on, reap segment when duration exceed and got keyframe.
        #       segment apply it.
        #       session,append ignore.
        # default: on
        dvr_wait_keyframe       on;
        # about the stream monotonically increasing:
        #   1. video timestamp is monotonically increasing,
        #   2. audio timestamp is monotonically increasing,
        #   3. video and audio timestamp is interleaved monotonically increasing.
        # it's specified by RTMP specification, @see 3. Byte Order, Alignment, and Time Format
        # however, some encoder cannot provides this feature, please set this to off to ignore time jitter.
        # the time jitter algorithm:
        #   1. full, to ensure stream start at zero, and ensure stream monotonically increasing.
        #   2. zero, only ensure stream start at zero, ignore timestamp jitter.
        #   3. off, disable the time jitter algorithm, like atc.
        # apply for all dvr plan.
        # default: full
        time_jitter             full;

        # on_dvr, never config in here, should config in http_hooks.
        # for the dvr http callback, @see http_hooks.on_dvr of vhost hooks.callback.srs.com
        # @see https://ossrs.net/lts/zh-cn/docs/v4/doc/dvr#http-callback
        # @see https://ossrs.net/lts/zh-cn/docs/v4/doc/dvr#http-callback
    }
}

<think>我们正在讨论SRS Antenna Switching技术,这是种在5G NR和LTE-Advanced Pro中用于提升下行链路性能的关键技术。根据用户提供的引用[1],我们可以知道SRS(Sounding Reference Signal,探测参考信号)Antenna Switching的基本工作原理:终端在配置SRS资源上发送SRS信号,网络侧通过接收这些信号来测量上行信道,并利用信道互易性(TDD系统中上下行信道相同)推断下行信道状态,从而为下行传输选择合适的预编码码本(Precoding Matrix Indicator, PMI)。然而,在FDD系统中,由于上下行频率不同,信道互易性不成立,因此网络需要通过CSI-RS(Channel State Information Reference Signal)和终端上报的PMI来获取下行信道信息。 下面我将详细解释SRS Antenna Switching的技术参数和工作原理: ### SRS Antenna Switching的工作原理 1. **核心目标**: 通过终端发送的SRS信号,让基站(gNB)获取终端多个发射天线的上行信道状态信息(CSI)。在TDD系统中,由于上下行信道互易性,基站可以利用这些信息推断下行信道状态,从而优化下行波束成形(Beamforming)和预编码。 2. **工作流程**: a. **网络配置**:基站通过RRC信令为终端配置个或多个SRS资源集(SRS Resource Set),其中每个资源集包含1~4个SRS资源(对应不同天线端口)。 b. **终端发送SRS**:终端按照配置的时频资源,轮流使用不同发射天线端口发送SRS信号(例如:先使用天线端口0发送,再切换到天线端口1发送)。 c. **信道测量与码本选择**:基站接收SRS信号后,通过信道估计算法得到上行信道矩阵$H_{\text{UL}}$。在TDD系统中,利用$H_{\text{DL}} = H_{\text{UL}}^T$(信道互易性)计算下行信道矩阵,并据此选择最优预编码码本(PMI)。 d. **下行调度优化**:基站在后续下行传输中使用选定的PMI进行预编码,提升下行传输速率和可靠性。 3. **FDD系统的替代方案**: 在FDD系统中,网络通过以下步骤获取下行CSI: - 基站发送CSI-RS信号; - 终端测量下行信道并计算PMI; - 终端通过PUCCH/PUSCH上报PMI给基站; - 基站根据PMI选择下行预编码矩阵。 ### 二、关键参数配置 根据3GPP规范(TS 38.214),SRS Antenna Switching的主要参数包括: 1. **天线端口数(nrofSRS-Ports)**: - 支持1T2R(1发2收)、1T4R、2T4R等模式(其中T表示发射天线数,R表示接收天线数)。 - 例如:1T4R表示终端有4根接收天线,但每次SRS发送时只能使用1根发射天线(通过天线切换实现多端口探测)。 2. **SRS资源集配置(usage)**: - 当`usage`字段设置为`antennaSwitching`时,该SRS资源集专用于天线切换。 - 每个SRS资源集中的资源数量必须大于等于终端发射天线端口数(例如:4天线切换需配置≥4个SRS资源)。 3. **切换时序(时域配置)**: - SRS资源在时域上按符号(Symbol)或时隙(Slot)间隔排列,确保天线切换有足够时间(通常需满足射频切换延迟要求)。 - 例如:在1T4R模式下,4个SRS资源可能分布在连续4个符号上。 4. **频域配置(带宽与梳状结构)**: - SRS信号采用梳状频谱结构(Comb-2/Comb-4),在指定带宽(Bandwidth Part, BWP)内跳频发送。 ### 三、数学原理 设终端有$N_t$根发射天线,基站有$N_r$根接收天线。 - 终端在第$k$个SRS资源上使用天线端口$p_k$发送SRS信号$s_k$。 - 基站接收信号为: $$ \mathbf{y}_k = \mathbf{H}_{\text{UL},k} \mathbf{s}_k + \mathbf{n}_k $$ 其中$\mathbf{H}_{\text{UL},k} \in \mathbb{C}^{N_r \times 1}$是上行信道向量(单端口发送),$\mathbf{n}_k$为噪声。 - 通过多次测量($k=1,2,\dots,K$),基站可重构完整上行信道矩阵: $$ \mathbf{H}_{\text{UL}} = \begin{bmatrix} \mathbf{H}_{\text{UL},1} & \mathbf{H}_{\text{UL},2} & \cdots & \mathbf{H}_{\text{UL},K} \end{bmatrix}^T $$ 在TDD系统中,下行信道矩阵为$\mathbf{H}_{\text{DL}} = \mathbf{H}_{\text{UL}}^H$(共轭转置)。 ### 四、性能增益与限制 - **增益**: - 提升下行MIMO频谱效率(最高可提升50%以上); - 减少终端CSI反馈开销(TDD模式下无需PMI上报)。 - **限制**: - 天线切换引入额外时延(需多个SRS时隙); - 对终端射频硬件要求较高(切换速度需满足符号级同步)。 --- ### 📚 参考文献支持 1. 3GPP TS 38.214: NR Physical layer procedures for data[^1] 2. srsLTE开源项目文档(UE侧SRS处理逻辑)[^2] --- §§ 相关问题§§ 1. SRS Antenna Switching在Massive MIMO中如何应用? 2. 如何优化SRS资源配置以减少切换时延? 3. TDD与FDD系统中SRS的设计差异有哪些? 4. srsLTE源码中如何实现SRS天线切换?</think>### 📡 **SRS Antenna Switching 技术详解** SRS(Sounding Reference Signal,探测参考信号)Antenna Switching 是5G NR和LTE-Advanced Pro中用于提升下行链路性能的关键技术,其核心是通过终端(UE)动态切换天线端口发送SRS信号,帮助基站(gNB)获取多天线信道状态信息。以下是其工作原理和关键参数: --- ### 、**工作原理** 1. **信道状态获取**: - UE在配置SRS资源上轮流切换发射天线端口(如1T2R:1根发射天线切换至2根接收天线)。 - 基站通过接收的SRS信号测量**上行信道响应** $H_{\text{UL}}$。 - **TDD系统**中,利用信道互易性($H_{\text{DL}} \approx H_{\text{UL}}^T$)直接推导下行信道状态,优化下行预编码码本(Precoding Matrix Indicator, PMI)[^1]。 - **FDD系统**因上下行频段分离,需依赖CSI-RS和终端上报的PMI获取下行信道信息[^1]。 2. **天线切换流程**: ```mermaid graph LR A[基站配置SRS资源] --> B[UE切换天线端口发送SRS] B --> C[基站测量上行信道] C --> D{TDD or FDD?} D -->|TDD| E[利用信道互易性生成下行码本] D -->|FDD| F[通过CSI-RS+PMI反馈获取下行码本] ``` 3. **数学表达**: 设基站接收信号为: $$ \mathbf{y} = \mathbf{H}_{\text{UL}} \mathbf{s} + \mathbf{n} $$ 其中: - $\mathbf{s}$:UE发送的SRS序列, - $\mathbf{n}$:噪声向量。 基站通过最小二乘估计信道矩阵: $$ \hat{\mathbf{H}}_{\text{UL}} = \mathbf{y} \mathbf{s}^H (\mathbf{s} \mathbf{s}^H)^{-1} $$ 在TDD系统中,下行预编码矩阵$ \mathbf{W}_{\text{DL}} $由$ \hat{\mathbf{H}}_{\text{UL}}^T $优化生成。 --- ### 二、**关键技术参数** 根据3GPP规范(TS 38.214),主要参数包括: 1. **天线配置模式**: | 模式 | 含义 | 适用场景 | |---------|--------------------------|-----------------------| | 1T2R | 1发2收(切换2端口) | 基础MIMO增强 | | 1T4R | 1发4收(切换4端口) | 高频段信道探测 | | 2T4R | 2发4收(同时激活双端口) | 高阶MU-MIMO调度 | 2. **SRS资源配置**: - **时频资源**:在BWP(Bandwidth Part)内分配Comb梳状结构和周期(4~320符号)。 - **端口数**:每个SRS资源支持1~4个天线端口(由RRC信令配置)。 - **切换时序**:射频切换延迟需满足符号级同步(通常≤3 μs)。 3. **性能增益**: - **频谱效率**:TDD系统中下行吞吐量提升15%~40%(信道互易性优势)[^1]。 - **开销优化**:减少CSI-RS资源占用,尤其适用于Massive MIMO场景。 --- ### 三、**系统实现(以srsLTE为例)** 在开源项目srsLTE中(引用[2]): 1. **UE侧处理流程**: ```cpp // 示例:SRS资源配置(C++14语法) srsran::srs_cfg_t srs_cfg; srs_cfg.antenna_ports = {0, 1}; // 配置天线端口0和1 srs_cfg.type = SRSRAN_SRS_CONFIG_ANT_SWITCH; // 指定为Antenna Switching srs_cfg.nrof_ports = 2; // 1T2R模式 srs_ue.set_srs_config(&srs_cfg); // 应用配置 ``` 2. **基站侧操作**: - 解析SRS信号,计算信道矩阵$ \hat{\mathbf{H}}_{\text{UL}} $。 - TDD模式下直接生成预编码码本: $$ \mathbf{W}_{\text{DL}} = \text{eigen\_beamform}(\hat{\mathbf{H}}_{\text{UL}}^T) $$ --- ### ⚠️ **技术限制与挑战** 1. **FDD系统的瓶颈**: - 无法利用信道互易性,依赖CSI-RS反馈,增加上行信令开销[^1]。 2. **硬件要求**: - 终端需支持快速射频切换(如GaAs开关),增加成本。 3. **同步精度**: - 时延敏感场景(URLLC)需符号级对齐,否则导致信道估计偏差。 --- ### 🔍 **优化方向** 1. **混合SRS策略**: - 结合宽带SRS(全带宽探测)和子带SRS(重点频段优化)。 2. **AI辅助码本选择**: - 利用ML预测最优PMI,减少计算时延。 ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值