R3944Realms/srs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

AI: Add guide for Augment. (#4404)

Browse Source
This commit is contained in:
Winlin 2025-06-25 10:22:04 -04:00 committed by winlin
parent acb9b88566
commit 40df358e50
126 changed files with 20690 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

61
.augment-guidelines Normal file
View File

@ -0,0 +1,61 @@
# Augment Guidelines for SRS Repository
project:
name: "SRS (Simple Realtime Server)"
description: "A C++ streaming media server supporting RTMP, WebRTC, WHIP, WHEP, SRT, HLS, and HTTP-FLV"
type: "media-server"
architecture:
overview: |
Core C++ streaming server with protocol implementations and media processing capabilities.
Uses State Threads (ST) for high-performance coroutine-based networking.
key_directories:
- path: "trunk/src/"
description: "Main source code directory"
- path: "trunk/src/main/"
description: "Entry points including srs_main_server.cpp"
- path: "trunk/src/core/"
description: "Core platform abstractions and common definitions"
- path: "trunk/src/kernel/"
description: "Low-level codec implementations (AAC, H.264, FLV, MP4, RTC, etc.)"
- path: "trunk/src/protocol/"
description: "Protocol implementations (RTMP, HTTP, RTC, SRT, etc.)"
- path: "trunk/src/app/"
description: "High-level application logic and server components"
key_files:
- path: "trunk/src/main/srs_main_server.cpp"
description: "Main entry point and server initialization"
- path: "trunk/src/app/srs_app_server.hpp"
description: "Core server class definition"
- path: "trunk/src/core/srs_core.hpp"
description: "Core definitions and project metadata"
- path: "trunk/src/core/srs_core_autofree.hpp"
description: "Smart pointer definitions for memory management"
code_patterns:
memory_management:
- pattern: "srs_freep"
description: "Custom macro for freeing pointers"
- pattern: "srs_freepa"
description: "Custom macro for freeing arrays"
error_handling:
- pattern: "srs_error_t"
description: "Custom error handling system"
conditional_compilation:
- pattern: "#ifdef SRS_VALGRIND"
description: "Valgrind support"
key_components:
- name: "SrsServer"
description: "Main server class of live stream for RTMP/HTTP-FLV/HLS/DASH and HTTP-API"
- name: "SrsLiveSource"
description: "Central management of live stream sources for RTMP/HTTP-FLV/HLS/DASH"
build:
command: "cd trunk && make -j"
description: "Build the SRS server using parallel make in the trunk directory"
working_directory: "trunk"

43
.augmentignore Normal file
View File

@ -0,0 +1,43 @@
# Build artifacts
**/objs/**
**/build/**
**/*.o
**/*.a
**/*.so
**/*.dylib
# IDE files
**/.idea/**
**/.vscode/**
**/.run/**
# Generated files
**/*.exe
**/*.flv
**/*.mp4
**/*.ts
# 3rd party libraries
**/vendor/**
**/3rdparty/ffmpeg-4-fit/**
**/3rdparty/gperftools-2-fit/**
**/3rdparty/gprof/**
**/3rdparty/gtest-fit/**
**/3rdparty/httpx-static/**
**/3rdparty/libsrtp-2-fit/**
**/3rdparty/openssl-1.1-fit/**
**/3rdparty/patches/**
**/3rdparty/signaling/**
**/3rdparty/srt-1-fit/**
# Research files.
**/research/**
# Other files.
**/packaging/**
**/scripts/**
**/usr/**
**/.github/**
**/gdb/**
**/ide/**

159
trunk/3rdparty/srs-docs/blog/2022-02-10-GSoC.md vendored Normal file
View File

@ -0,0 +1,159 @@
---
slug: GSoC-2022
title: GSoC
authors: []
tags: [GSoC]
custom_edit_url: null
---
# GSoC
## Project Description
SRS is a simple, high efficiency and realtime video server, supports RTMP/WebRTC/HLS/HTTP-FLV/SRT.
<!--truncate-->
## Information for Students
### Getting Started
1. **Get to know SRS.** If you are a student interested in contributing to SRS, it is recommended to start by join to the SRS [Discord](https://discord.gg/DfJFjpxmC7) and exploring both the codebase and the development workflow. Feel free to contact us if you have any questions. Also do not hesitate to answer questions from other students on our [Discord](https://discord.gg/DfJFjpxmC7) channel if you know the answer to something.
2. **Find a project.** Listed on this page are mentored and un-mentored projects. Mentored projects are well-defined and mentor(s) have already volunteered. Un-mentored projects are additional ideas you may want to consider, but you will have to contact us to find a mentor. You can also propose your own project, if you can think of one that better fits your interest and skill level. If a project description is unclear or you have any questions, please get in touch with its mentor and/or join our [Discord](https://discord.gg/DfJFjpxmC7) channel at *#general*.
3. **Contact us.** If you decide on a project, get in touch with the community and let us know. If you want to work on a qualification task, let the respective mentor know so we can avoid duplicated efforts.
4. **Apply.** Students should apply definitely before deadline on April 19th. The "work" period begins on June 13th and ends in September. Take a look at [GSoC timeline](https://developers.google.com/open-source/gsoc/timeline) for additional information. Note, make sure you apply to Google before April 19th, even if you have not yet finished your qualification task. Please apply as soon as possible: Applications can be improved until the 19th but not afterwards!
> **Note**: A friendly reminder that while the application to GSoC is important for you and GSoC, SRS mentors will not base their decision solely on the GSoC application. We will judge applicants based on their qualification tasks to understand their abilities in coding, learning the tools, communication skills etc. So please do not worry about your application being perfect for us. Although it is very important to follow GSoC's application rules so they can pay you.
### Qualification Tasks
In order to get accepted you have to complete a small qualification task which in all cases include sending a patch to the development mailing list. SRS development can be quite challenging and the qualification task helps us figure out whether you are motivated enough and have the potential to deliver successfully.
The qualification tasks are usually shown in the project description. Contact the respective mentor(s) for assistance on getting a related qualification task or if you want to propose your own. You can also browse the [SRS Bug Issue](https://github.com/ossrs/srs) for qualification task ideas. In general qualification tasks should include submitting a patch to the [SRS Bug Issue](https://github.com/ossrs/srs) which passes review and is accepted into the SRS codebase. It will be common for such patches to need multiple iterations of submissions and reviews, so don't wait too long with the first submission! Note, please avoid picking a qualification task which another student is already working on, each student should work on a different qualification task.
### Development
If you are selected for a particular project then you are not only expected to present a working implementation but you should also submit your work for inclusion for the SRS codebase. This should be done at least 2-3 weeks before the end of the second work period by sending patches to the [SRS Bug Issue](https://github.com/ossrs/srs)&[Discord](https://discord.gg/DfJFjpxmC7) where the SRS community and your mentor will review your work. You will likely be asked to make some changes and resend improved versions. If you feel that no consensus is reached about how something should be done then follow the advice of your mentor.
In order to create good quality patches make sure to read the [Developer Documentation](../docs/v5/doc/getting-started).
### Contacting SRS
If you have questions or comments feel free to contact us via our mail, Discord one of the SRS GSoC admins:
* **Discord:** *#general*
* **SRS GSoC Admins:** Winlin (winlin in #general on [Discord](https://discord.gg/DfJFjpxmC7), winlinvip at gmail dot com ), Devin (Devin in *#general* on [Discord](https://discord.gg/DfJFjpxmC7), devin at ossrs dot io), LiuQi (Steven in *#general* on [Discord](https://discord.gg/DfJFjpxmC7), lq at chinaffmpeg dot org)
You may also contact a mentor directly if you have questions specifically related to one of the projects listed on this page.
## Mentored Project Ideas
This section lists well-defined projects that have one or more available mentors. If you are new to SRS, and have relatively little experience with multimedia, you should favor one of these ideas rather than propose your own. Contact the respective mentor(s) to get more information about the project and the requested qualification task.
### 1. Support Prometheus API
|Name of project|SRS support Prometheus API|
| :---- | :----- |
|Project Description|Prometheus is a common component of system monitoring, support Prometheus API, so that the monitoring system can display SRS service related properties in the form of charts, or audio and video frame rate, bit rate and other information.|
|Mentor|Haibo Chen(nmgchenhaibo@foxmail.com)|
|Backup Mentor|Junqin Zhang(chundonglinlin@163.com)|
|Skills needed|Familiar with HTTP protocol, understand HTTP server-client interaction process.|
|Expected size of project|180 hours|
|Difficulty|Beginner|
|Expected results|Use Prometheus client to be able to access and get the expected results.|
|Qualification Task|Complete the Prometheus API writing and testing.|
### 2. Configuration file yaml parsing
|Name of project|Configuration file support yaml parsing|
| :---- | :----- |
|Project Description|SRS current configuration file format is a private format, similar to nginx, yaml is a common way of configuration file, there are more people familiar with the use of.|
|Mentor|Junqin Zhang(chundonglinlin@163.com)|
|Backup Mentor|Haibo Chen(nmgchenhaibo@foxmail.com)|
|Skills needed|Familiar with yaml file format and its parsing method, skilled in C++ programming.|
|Expected size of project|175 hours|
|Difficulty|Beginner|
|Expected results|SRS existing configuration file can be converted to yaml parsing and execution.|
|Qualification Task|Implement the parsing of yaml files.|
### 3. CPU adaptation
|Name of project|SRS ported to RISC platform, CPU adaptation|
| :---- | :----- |
|Project Description|SRS underlying use of IO libraries, currently has been adapted to Intel, ARM and many other platforms. With the gradual development of RISC, the support for RISC can further enhance the support of SRS for multiple platforms.|
|Mentor|Winlin(winlinvip@gmail.com)|
|Backup Mentor|Zhihong Xiao(hondaxiao@tencent.com), Feng Yi(yifeng1983@gmail.com)|
|Skills needed|Familiar with RISC platform assembly instruction set, familiar with the principle of computer program execution.|
|Expected size of project|350 hours|
|Difficulty|Advanced|
|Expected results|Be able to run SRS on the RIST platform, and run all the functions of 4.0release normally.|
|Qualification Task|Implement st-thread stack saving on RISC platform, restore logic.|
### 4. DASH
|Name of project|DASH support SegmentTemplate Time mode|
| :---- | :----- |
|Project Description|The current SRS DASH only supports SegmentTemplate's Number mode, while the mainstream players are more recommended Time mode.|
|Mentor|Zhihong Xiao(hondaxiao@tencent.com)|
|Backup Mentor|Winlin(winlinvip@gmail.com), Steven Liu(lq@chinaffmpeg.org)|
|Skills needed|Familiar with DASH protocol, understand video to encapsulation, familiar with using C++ programming.|
|Expected size of project|280 hours|
|Difficulty|Intermediate|
|Expected results|Be able to use dash.js, VLC, ffplay and other common players for playback.|
|Qualification Task|Implement DASH SegmentTemplate Time mode.|
### 5. HLS LLHLS mode
|Name of project|HLS support LLHLS mode|
| :---- | :----- |
|Project Description|HLS is a live file slicing method proposed by APPLE, the current drawback is the long delay, LLHLS can greatly reduce the delay of HLS.|
|Mentor|Zhihong Xiao(hondaxiao@tencent.com)|
|Backup Mentor|Wei Shi(shiwei05@kuaishou.com)|
|Skills needed|Familiar with HLS, LLHLS, good ability to read standard documents, familiar with programming in C++.|
|Expected size of project|350 hours|
|Difficulty|Advanced|
|Expected results|Be able to play on a player that supports LLHLS and achieve latency within expectations.|
|Qualification Task|LLHLS coding, encapsulation, manifest file generation.|
### 6. Asynchronous DNS Resolution
|Name of project|Asynchronous DNS Resolution|
| :---- | :----- |
|Project Description|The IO used by SRS is coroutine IO, but the current DNS resolution is still synchronous resolution. Asynchronous DNS resolution can make better use of coroutine resources and avoid affecting other IO due to DNS blocking.|
|Mentor|Guanghua Chen（jinxue.cgh@alibaba-inc.com）|
|Backup Mentor|Zhihong Xiao （hondaxiao@tencent.com）|
|Skills needed|Familiar with DNS resolution process, familiar with programming in C++|
|Expected size of project|180 hours|
|Difficulty|Advanced|
|Expected results|Ability to perform asynchronous DNS resolution and pass the test.|
|Qualification Task|complete DNS asynchronous resolution and coroutine encapsulation.|
### 7. RIST push streaming protocol support
|Name of project|RIST push streaming protocol support|
| :---- | :----- |
|Project Description|RIST is a streaming protocol that has emerged in recent years. It has better features than traditional RTP streaming, such as better transmission control, etc.|
|Mentor|Zhihong Xiao （hondaxiao@tencent.com）|
|Backup Mentor|Xiaojun Zhou （279686030@qq.com）|
|Skills needed|Familiar with RIST push protocol, familiar with C++ programming.|
|Expected size of project|240 hours|
|Difficulty|Advanced|
|Expected results|Able to push RIST stream to SRS, and convert to RTMP/FLV/WebRTC etc.|
|Qualification Task|Completion of RIST protocol reception and trans-packaging into other protocols.|
### 8. Refactoring of official website document content
|Name of project|Refactoring of official website document content|
| :---- | :----- |
|Project Description|Sort out the existing wikis, articles, videos and other resources of SRS, and integrate them into the official website.|
|Mentor|Xiaowei Meng (542638787@qq.com)|
|Backup Mentor|Xiaosong Dai (kunkkaco@gmail.com)|
|Skills needed|Familiar with javascript, proficient in using SRS server, good in English.|
|Expected size of project|350 hours|
|Difficulty|Beginner|
|Expected results|Be able to easily get started with SRS by reading the documentation.|
|Qualification Task|Complete the display of official website documents, cases, blogs, and various sub-modules of the community.|
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/blog-en/22-02-10-GSoC)

77
trunk/3rdparty/srs-docs/blog/2022-02-17-WebRTC-Live.md vendored Normal file
View File

@ -0,0 +1,77 @@
---
slug: WebRTC-Live
title: SRS - Why and Why NOT use WebRTC for Live Streaming
authors: []
tags: [blog, webrtc, streaming]
custom_edit_url: null
---
# Why and Why NOT use WebRTC for Live Streaming?
Discussion with a friend Thegobot in [discord](https://discord.gg/yZ4BnPmHAd)
<!--truncate-->
## About send stream
For sending stream by H5, only WebRTC works, so it’s ok to use WebRTC if you only want to support H5.
If you also need to support mobile like iOS or Android, FFmpeg is better then WebRTC for live streaming. Also OBS/vmix for multiple scenes.
If you want to support theses live streaming encoders, WebRTC is a absolutely bad solution, because they doesn’t support it, like FFmpeg, OBS, vmix, etc. There is another protocol SRT designed by Haivision, used in many device and project in live streaming.
## About play stream
From the point view of H5, MSE is much better than WebRTC, used by almost all video platforms like YouTube, Twitch, etc.
Maybe there is bug, but it has nothing to do with HTTP-FLV, it’s about the codec not the muxing, it should exists in DASH or HLS also.
If you want to support mobile like iOS or Android, FFmpeg is better solution, for example, ijkplayer. You could use RTMP or HTTP-FLV, it’s stable.
So it depends on your clients, if all your clients is H5, it’s ok to use WebRTC(send)+MSE(play). I don’t think it’s a good idea to use WebRTC as player for live streaming, because the deliver for WebRTC is complex, you need more servers than live streaming.
Finally, about the latency, HTTP streaming is also low latency live streaming, about 1~3s. If want smaller than 1s? I think you’d better think about it, because it might cause the buffer empty and streaming pausing-resuming stuff.
Does 500ms live streaming is essential? And it’s better than 1~3s solution? I really really don’t think so.
## Known Issues
As I know, the issues for WebRTC in live streaming:
1. Slow startup for user to see the first decoded picture, maybe HTTP-FLV/HLS `<100ms`, while WebRTC `>1s`.
1. Not supported by CDN, while some CDN supports HTTP-FLV, but few support WebRTC, the cost is huge(you spend more money).
1. WebRTC needs more servers to deliver, for DTLS/SRTP encryption, QoS algorithm, UDP low performance for linux kernel. To build a WebRTC/UDP CDN, you spend more 10x money to buy servers. Please read [this post](https://github.com/ossrs/srs/blob/develop/trunk/doc/PERFORMANCE.md#performance) for more.
1. Mobile does not works well for WebRTC, especially mobile H5. While for mobile native, why not RTMP or HTTP-FLV, it’s much much simple.
1. Not used for the whole live streaming economy, especially the encoders, they prefer SRT which is also low latency 200~500ms.
1. Low quality for content, because WebRTC perfer low latency, so it drops packets when network is bad. It’s hard to support 8Mbps or higher live streaming.
1. Not friendly for DVR, if you want to DVR your live streaming published by WebRTC, very unhappy experience, please try it.
1. Audio transcoding cost, because WebRTC use Opus, which need to be transcoded to AAC for live streaming.
1. WebRTC stack is not stable, changed over and over, and it also develops more stack like WebTransport/WebCodec, or QUIC/WebAssembly which is smaller and more simple than WebRTC itself.
1. Last one, sometimes network administrator disable all UDP, er, I know there is something like TURN but …. why not use HTTP/HTTPS/WS/WSS which works perfect at everywhere and any devices.
If insist, please go on and give us more feedbacks in future.
## Cloud Service
At SRS, our goal is to establish a non-profit, open-source community dedicated to creating an all-in-one,
out-of-the-box, open-source video solution for live streaming and WebRTC online services.
Additionally, we offer a [Cloud](../cloud) service for those who prefer to use cloud service instead of building from
scratch. Our cloud service features global network acceleration, enhanced congestion control algorithms,
client SDKs for all platforms, and some free quota.
To learn more about our cloud service, click [here](../cloud).
## Conclusion
Ultimately, WebRTC is not designed for live streaming, the only scenario to use WebRTC for live streaming is publishing stream by H5, otherwise, consider about RTMP, HTTP-FLV, HLS or DASH.
For live streaming, rather than modern and new tech stack, it’s actually disaster to use WebRTC in mobile H5, and unnecessary for mobile native players.
## Contact
Welcome for more discussion at [discord](https://discord.gg/bQUPDRqy79).
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/blog-en/22-02-17-WebRTC-Live)

240
trunk/3rdparty/srs-docs/blog/2022-04-09-Oryx-Tutorial.md vendored Normal file
View File

@ -0,0 +1,240 @@
---
slug: Oryx-Tutorial
title: Oryx - How to Setup a Video Streaming Service by 1-Click
authors: []
tags: [turotial, srs, webrtc, streaming]
custom_edit_url: null
---
# How to Setup a Video Streaming Service by 1-Click
## Introduction
Streaming video is very popular in a variety of industries, and there are many tutorials for building a
media server, using [SRS](https://github.com/ossrs/srs) or [NGINX-RTMP](https://github.com/arut/nginx-rtmp-module)
that host stream does not rely on other service providers.
<!--truncate-->
But if we want to build a online video streaming service, it's much more than only a media server:
1. [Authentication](./2023-08-29-Oryx-Ensuring-Authentication-for-Live-Streaming-Publishing.md): Because the server is on the public internet with a public IPv4 address, how to do authentication? How to block all users except they have the correct token?
1. Multiple Protocols: Rather than publishing RTMP using OBS, you might need [WebRTC or H5 to publish live streaming](./2023-05-16-Stream-YouTube-Using-Web-Browser.md), or [OBS WHIP Server](./2023-12-12-Oryx-OBS-WHIP-Service.md) for it's easy to use. You might also use SRT with some broadcasting devices. How to convert RTMP/WebRTC/SRT to HLS?
1. [Restreaming](./2023-09-09-Oryx-Multi-Platform-Streaming.md): Restream to multiple platforms using Oryx for wider audience reach & increased engagement. Simple & efficient solution for live streaming on YouTube, Twitch, & Facebook.
1. [DVR or Recording](./2023-09-10-Oryx-Record-Live-Streaming.md): Discover how to effortlessly record live streams using Oryx in this step-by-step guide. Learn to configure Glob Filters for selective recording and integrate S3 cloud storage for seamless server-side recording, making live streaming accessible for all.
1. [Transcoding](./2023-10-21-Oryx-Live-Transcoding.md): Explore the benefits of efficient live streaming transcoding using Oryx and FFmpeg for reducing bandwidth and saving costs. Learn how to optimize streaming experiences for viewers with varying internet speeds and devices, and harness the power of Oryx for smoother, cost-effective streaming.
1. [Virtual Live Events](./2023-09-11-Oryx-Virtual-Live-Events.md): Discover the benefits of virtual live events and learn how to create seamless and engaging live streaming experiences using pre-recorded content. This blog post will guide you through the process of converting recorded videos into live broadcasts for various applications, such as e-commerce, education, and online speeches.
1. [IP Camera Streaming](./2023-10-11-Oryx-Stream-IP-Camera-Events.md): Discover how to effortlessly stream your RTSP IP camera to popular platforms like YouTube, Twitch, or Facebook using Oryx. Learn how this powerful tool simplifies the process, allowing you to connect multiple IP cameras and stream live to various platforms for an enhanced live streaming experience.
1. [AI Transcription](./2023-11-28-Oryx-Live-Streams-Transcription.md): Discover the future of live streaming with AI-powered transcription and real-time subtitles using OpenAI’s Whisper. Learn how to create accessible, multilingual content for diverse audiences, revolutionizing the live streaming experience. Embrace inclusivity and reach a wider audience with AI-enhanced live streams.
Literally it's not just a media server, and seems a bit complicated, right? Yep and No!
* Yep! Building a video streaming service is something really difficult, not easy. It requires video streaming engineering, also backend service technology like Nodejs or Go, and frontend skills to build a mgmt and homepage.
* No! Rather than build all from scratch, we could build a video streaming service based on some open source solution such as [Oryx](https://github.com/ossrs/oryx), and lightweight cloud service such as [DigitalOcean](https://digitalocean.com) or [AWS](https://console.aws.amazon.com), it's really simple to build your video streaming service.
In this tutorial, you will learn how to set-up a video streaming service, supports publishing by browser
without a plugin that is converting WebRTC to HLS, to deliver low latency (about 300ms) video streaming
using SRT, and to secure the service by authentication. Furthermore, this solution is open source and very
easy to get it done, via even 1-Click.
## Prerequisites
To complete this guide, you need:
1. OBS installed, following instructions [here](https://obsproject.com/) to download and install OBS.
1. A virtual private server (VPS) instance, such as [AWS Lightsail](https://lightsail.aws.amazon.com), [DigitalOcean Droplets](https://cloud.digitalocean.com/droplets), or another similar service.
1. Optionally, you may choose to utilize Oryx on your local network or personal computer. Ensure that [Docker](https://www.docker.com/) is installed for this purpose.
This guide will use placeholder `your_public_ipv4` and `your_domain_name` throughout for streaming URLs.
Please replace them with your own IP address or domain name.
## Step 1.1: Create an Oryx using AWS Lightsail
Sign up for an AWS account and sign in to [AWS Lightsail](https://lightsail.aws.amazon.com). Next, click the
`Create instance` button. Select the `Linux/Unix` platform and the `OS Only` blueprint. Finally, choose
`Ubuntu 20.04 LTS` as the instance image.
![](/img/blog-2022-04-09-21.png)
Next, click the `Add launch script` button and input the following script that will be executed to install
the Oryx once the instance has been created.
![](/img/blog-2022-04-09-22.png)
Please input the following script:
```bash
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/ossrs/oryx/HEAD/scripts/lightsail.sh)"
```
> Note: You can also access the instance and run the script manually. Please search for instructions on how
> to log in to a Lightsail instance.
Next, choose the instance plan, select the `2vCPUs 1GB` plan or a higher one, and click on `Create instance`.
Once the instance has been established, access the `Networking` tab and click `Attach static IP` to keep it
from changing. Within `IPv4 Firewall`, press the `Add rule` option, add an `All protocols` rule and click
the `Create` button:
![](/img/blog-2022-04-09-23.png)
Now, the Oryx is created! Open `http://your_public_ipv4/mgmt/` in the browser, click the `Submit` button
to set-up the administrator password for the first time.
## Step 1.2: Create an Oryx using Docker
If you prefer not to utilize AWS Lightsail, have an alternative VPS, or even a virtual machine or personal
computer locally available, highly recommend using Docker for a simple and efficient way to run Oryx on
VPS using just one command:
```bash
docker run --restart always -d -it --name oryx -v $HOME/data:/data \
-p 80:2022 -p 443:2443 -p 1935:1935 -p 8000:8000/udp -p 10080:10080/udp \
ossrs/oryx:5
```
After the Oryx is created, open `http://your_public_ipv4/mgmt/` in the browser, click the `Submit` button
to set-up the administrator password for the first time.
## Step 1.3: Create an Oryx using DigitalOcean Droplets
You can use DigitalOcean droplet to run Oryx just one-click. A droplet is a simple and scalable virtual machine
of DigitalOcean. An SRS Droplet is a droplet with Oryx installed, to power your video streaming service.
You could create `an SRS Droplet` by [clicking here](https://marketplace.digitalocean.com/apps/srs),
then click the `Create SRS Droplet` button, set-up the droplet `Region` and `Size`, then click `Create Droplet`
button at the bottom.
> Note: Recommend the size `2vCPUs 2GB` or slightly larger.
After the Oryx is created, open `http://your_public_ipv4/mgmt/` in the browser, click the `Submit` button
to set-up the administrator password for the first time.
## Step 2: Publish Stream using OBS
OBS is more simple to use, and SRS provides guide for OBS, please click `Scenarios > Streaming > RTMP: OBS or vMix`
or open URL `http://your_public_ipv4/mgmt/en/routers-scenario?tab=live` with `Server` and `StreamKey` for OBS,
please copy these config and paste to OBS:
![](/img/blog-2022-04-09-01.png)
> Note: There is also a guide for publishing streams by FFmpeg and WebRTC, however, it's a bit complex for
> WebRTC, and we will talk about it later.
After publishing an RTMP stream to SRS, you're able to play the stream by HTTP-FLV or HLS, by clicking the H5
player link, or play the URL by [VLC](https://www.videolan.org/).
> Note: The latency of VLC is huge, so please use [ffplay](https://ffmpeg.org/) to play the RTMP or HTTP-FLV
> if you wanna a low latency live streaming.
Now we have finished the basic live streaming publishing and playing, note that the `Stream Key` contains a
`secret` which is used for authentication. Without this secret, SRS will deny the publisher, so only people
who know about the secret could publish an RTMP stream.
While for players, the URL is public and no `secret` thing, because generally we don't need to do authentication
for players. However, SRS is planned to support more authentication algorithms, including token for players,
or limits for number of connections, or disconnecting connections if they exceed a period of duration.
## Step 3: Publish by WebRTC (Optional)
WebRTC or H5 is very convenient for users to share their camera, by just opening a H5 URL, to start live
streaming like what OBS does. Please follow [secure SRS with let's encrypt](https://blog.ossrs.io/how-to-secure-srs-with-lets-encrypt-by-1-click-cb618777639f)
tutorial.
Because WebRTC requires HTTPS, so you need a fully registered domain name, you could purchase a domain
name on [Namecheap](https://namecheap.com/) or [GoDaddy](https://godaddy.com/), however we will use
placeholder `your_domain_name` throughout this tutorial.
When you get a domain name, make sure a DNS record set-up for your server, please add an `A record` with
`your_domain_name` pointing to your server public IP address that is `your_public_ipv4` as we said, see
[Domains and DNS](https://docs.digitalocean.com/products/networking/dns/how-to/manage-records/#a-records).
Now please switch to `System / HTTPS / Let's Encrypt` and enter `your_domain_name`, then click `Submit`
button to request a free SSL cert from [Let's Encrypt](https://letsencrypt.org/):
![](/img/blog-2022-04-09-02.png)
When the HTTPS is ready, please open the URL `https://your_domain_name/mgmt` to access `Scenarios > Streaming > WebRTC: WHIP Browser`
and open the URL to publish using WebRTC:
![](/img/blog-2022-04-09-03.png)
> Remark: Please note that the website and stream URLs have changed to HTTPS, both HTTPS-FLV, HLS and WebRTC.
The bellow is a demo for publishing by WebRTC and playing by HTTP-FLV or HLS:
![](/img/blog-2022-04-09-04.png)
WebRTC is a bit more complex than RTMP or HLS, but using the feature by SRS, it's also very simple to set-up
the HTTPS website and WebRTC signaling API, and the demo pages for WebRTC publisher and player are also very
simple to use.
## Step 4: Low Latency Streaming by SRT (Optional)
For RTMP/FLV, the streaming latency is about `3~5s`, while `5~10s` for HLS. Which protocol to use if we want to
build a low latency live streaming service, say, less than 1s?
WebRTC? No! It's too complicated, and few devices support WebRTC. [WHIP](https://datatracker.ietf.org/doc/draft-ietf-wish-whip/)
is a possible choice for live streaming using WebRTC, but it's not a RFC right now(at 2022). It might take a long
time to apply WebRTC to the live streaming industry, especially if we get other choices, [SRT](https://www.srtalliance.org/)
and [RIST](https://www.rist.tv/) etc.
> Note: Whatever, Oryx allows you to use WebRTC for live streaming, to publish by WebRTC and play by
> RTMP/HLS/WebRTC.
It's also very easy to use SRT, by clicking `Scenarios > Streaming > SRT: OBS or vMix`, the guide is use
OBS to publish SRT stream, and play by ffplay. The latency of `OBS+ffplay` is about 300ms, the bellow is
a lower solution, by `vMix+ffplay`:
![](/img/blog-2022-04-09-05.png)
> Note: The end-to-end latency of SRT is 200ms to 500ms, good enough! Well, WebRTC is about 50ms to 300ms
> latency. WebRTC is even lower than SRT, but WebRTC also introduces more pause events and the streaming
> is not smooth as SRT.
SRT is supported by a lot of devices of the broadcasting industry, and softwares like OBS/vMix also support
SRT, so it's actually the most stable and easy way to get low latency live streaming.
Note that H5 does not support SRT, so you can't use Chrome to play a SRT stream, however, Oryx will
convert SRT to HTTP-FLV/HLS to ensure compability with general live streaming.
## Other Topics
Oryx also supports restreaming to other platforms, by forking multiple FFmpeg processes, each process
for a stream. It's a long story, so let's discuss it in a new tutorial.
Well DVR is another story, DVR means we convert live streaming to VoD files, so we must save the VoD files
to a cloud storage. So we're developing to support more cloud storage now.
We're also considering to integrate a CMS to Oryx, to allow users to publish the live streaming rooms,
or VoD files like a vlog, etc.
Oryx is a single node video streaming service, but SRS is a media server that supports clusters, like
[Origin Cluster](../docs/v4/doc/origin-cluster), [RTMP Edge Cluster](../docs/v4/doc/sample-rtmp-cluster) and
even [HLS Edge Cluster](../docs/v4/doc/sample-hls-cluster). The HLS Edge Cluster is based on NGINX, and SRS
could work well with NGINX, we will publish more tutorials about this topic if you wanna.
## Cloud Service
At SRS, our goal is to establish a non-profit, open-source community dedicated to creating an all-in-one,
out-of-the-box, open-source video solution for live streaming and WebRTC online services.
Additionally, we offer a [Cloud](../cloud) service for those who prefer to use cloud service instead of building from
scratch. Our cloud service features global network acceleration, enhanced congestion control algorithms,
client SDKs for all platforms, and some free quota.
To learn more about our cloud service, click [here](../cloud).
## Conclusion
In this tutorial, you build a video streaming service only by 1-Click, but with powerful features like
authentication, SRT and WebRTC etc. If you have further questions about SRS,
[the wiki](../docs/v6/doc/getting-started-oryx) is a good place to start.
## Contact
If you'd like to discuss with SRS, you are welcome to [discord](https://discord.gg/yZ4BnPmHAd).
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/blog-en/22-04-09-Oryx-Tutorial)

132
trunk/3rdparty/srs-docs/blog/2022-04-12-Oryx-HTTPS.md vendored Normal file
View File

@ -0,0 +1,132 @@
---
slug: Oryx-HTTPS
title: Oryx - How to Secure SRS with Let's Encrypt by 1-Click
authors: []
tags: [turotial, srs, https]
custom_edit_url: null
---
# How to Secure SRS with Let's Encrypt by 1-Click
## Introduction
As a CA(Certificate Authority), Let's Encrypt provides free and automatic TLS/SSL certificates, which enables encrypted
HTTPS for SRS Droplet. It's very easy to use, only by 1-Click.
HTTPS is required for publishing streams using WebRTC, and it improves security. If you want to support the video
streaming in any HTTPS website, such as a WordPress website, you must use HLS/FLV/WebRTC with HTTPS, or it will fail for
security reasons.
> Note that SRS droplet only supports a single domain name, which makes the problem simple. It is easy to use.
In this tutorial, you will learn how to configure the HTTPS for SRS droplets, and your certificate will be renewed automatically.
<!--truncate-->
## Prerequisites
To complete this guide, you will need:
1. An SRS Droplet with Oryx installed, please follow this [set-up a video streaming service](https://blog.ossrs.io/how-to-setup-a-video-streaming-service-by-1-click-e9fe6f314ac6) tutorial.
1. A fully registered domain name, you could purchase a domain name on [Namecheap](https://namecheap.com/) or [GoDaddy](https://godaddy.com/). For the demonstration purpose, however, we will use a placeholder `your_domain_name` throughout this tutorial.
This guide will also use placeholders `your_public_ipv4` and `your_domain_name` throughout. Please replace them with
your own IP address and domain name.
## Step 1 - DNS Records Setup
Make sure setup a DNS record for your server. Please add an `A record` with `your_domain_name` pointing to your server
public IP address, which is `your_public_ipv4` as we mentioned, see [Domains and DNS](https://docs.digitalocean.com/products/networking/dns/how-to/manage-records/#a-records).
Add a record like this:
```text
A your_domain_name your_public_ipv4
```
To check the domain name, your status should look like this:
```bash
ping your_domain_name
```
```text
Output
PING ossrs.io (your_public_ipv4): 56 data bytes
64 bytes from your_public_ipv4: icmp_seq=0 ttl=64 time=11.828 ms
64 bytes from your_public_ipv4: icmp_seq=1 ttl=64 time=16.553 ms
64 bytes from your_public_ipv4: icmp_seq=2 ttl=64 time=12.433 ms
```
If you visit `http://your_domain_name/mgmt`, you should see the Oryx console now.
![](/img/blog-2022-04-12-01.png)
Next, let's fetch our certificates.
## Step 2 - Obtaining an SSL Certificate
Now please switch to `System > HTTPS > Let's Encrypt` and enter `your_domain_name`, then click `Submit` button to request
a free SSL cert from [Let's Encrypt](https://letsencrypt.org/):
![](/img/blog-2022-04-12-02.png)
This runs `certbot` to fetch an SSL certificate. It will communicate with the Let's Encrypt server, then create a challenge
to verify that you control the domain that you're requesting a certificate for. All these are automatically done by Cloud
SRS.
If successful, please try reload your website using `https://your_domain_name/mgmt`. Pay attention to your browser's
security indicator, as demonstrated bellow:
![](/img/blog-2022-04-12-03.png)
> Note: You could request multiple domains separated by semicolon, after adding an A record for each domain, for example,
`domain.com;www.domain.com`, then both `https://domain.com` and `https://www.domain.com` are available.
Let's finish this tutorial by covering the certificate renewal process.
## Step 3 - About Certificate Auto-Renewal
Let's Encrypt's certificates are only valid for about 3 months. Oryx will start a timer to verify if it is due to
renew your certificates on a daily basis, and reload Nginx to apply the changes if neccessary.
You can check the renew log by:
```bash
docker logs platform |grep renew
```
```text
Output
Thread #crontab: auto renew the Let's Encrypt ssl
Thread #crontab: renew ssl updated=false, message is
Processing /etc/letsencrypt/renewal/lh.ossrs.io.conf
Certificate not yet due for renewal
The following certificates are not due for renewal yet:
No renewals were attempted.
```
If no errors, you're all set.
## Cloud Service
At SRS, our goal is to establish a non-profit, open-source community dedicated to creating an all-in-one,
out-of-the-box, open-source video solution for live streaming and WebRTC online services.
Additionally, we offer a [Cloud](../cloud) service for those who prefer to use cloud service instead of building from
scratch. Our cloud service features global network acceleration, enhanced congestion control algorithms,
client SDKs for all platforms, and some free quota.
To learn more about our cloud service, click [here](../cloud).
## Conclusion
In this tutorial, you set-up the DNS A Record, downloaded SSL Certificates for your domain, configured Nginx to apply
the certificate, and set-up automatic renewal.
## Contact
If you have further questions, please contact us by [discord](https://discord.gg/yZ4BnPmHAd).
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/blog-en/22-04-12-Oryx-HTTPS)

124
trunk/3rdparty/srs-docs/blog/2022-04-15-Oryx-WordPress-Plugin.md vendored Normal file
View File

@ -0,0 +1,124 @@
---
slug: WordPress-Plugin
title: Oryx - How to Publish Your SRS Livestream Through WordPress
authors: []
tags: [tutorial, wordpress, streaming]
custom_edit_url: null
---
# How to Publish Your SRS Livestream Through WordPress
## Introduction
After you have set up your own live streaming server through the [SRS Droplet](https://blog.ossrs.io/how-to-setup-a-video-streaming-service-by-1-click-e9fe6f314ac6)
you received multiple links to publish your stream. You can use the build in players or use the links in [VLC](https://www.videolan.org/)
for example for the various sources.
But what if you would like to embed your HTTP-FLV, HLS or WebRTC stream straight into your WordPress site?
In this tutorial, I will show you how you set up your WordPress and SRS Player plugin to stream right through your
website for viewers to watch.
<!--truncate-->
## Prerequisites
To complete this guide, you need:
1. OBS installed, following the instructions [here](https://obsproject.com/) to download and install OBS.
1. Having your SRS Server set up, following the instructions [here](https://blog.ossrs.io/how-to-setup-a-video-streaming-service-by-1-click-e9fe6f314ac6).
1. Having your WordPress website [set up](https://medium.com/@kindlepublishingservices/setting-up-a-wordpress-website-8ed1911d3831).
This guide will use placeholder `your_public_ipv4` and `your_domain_name` throughout for streaming URLs. Please replace
them with your own IP address or domain name.
## Step 1: Download the SRS WordPress Plugin
After you logged in your WordPress website, navigate to Plugins, click the `Add New` button.
![](/img/blog-2022-04-15-001.png)
Search for `SRS Player` or follow this [link](https://wordpress.org/plugins/srs-player/).
![](/img/blog-2022-04-15-002.png)
Click the `Install Now` button and after the Installing prompt, click Activate. The plugin should now be active.
## Step 2: Embed the WordPress Plugin shortcode into your post or page.
Copy the shortcode from your SRS server of the protocol you wish to embed.
![](/img/blog-2022-04-15-003.png)
Within WordPress, create a new Post or Page.
![](/img/blog-2022-04-15-004.png)
Create a new shortcode on your post or page.
![](/img/blog-2022-04-15-005.png)
![](/img/blog-2022-04-15-006.png)
![](/img/blog-2022-04-15-007.png)
Use the shortcode of the protocol you would like to embed by using one of the following shortcodes:
1. HLS `[srs_player url="https://your_public_ipv4/live/livestream.m3u8"]`
1. FLV `[srs_player url="https://your_public_ipv4/live/livestream.flv"]`
1. WebRTC `[srs_player url="webrtc://your_public_ipv4/live/livestream"]`
Click the Publish button and check your new page.
![](/img/blog-2022-04-15-008.png)
Your player should show up on your WordPress post or page.
> Note: Basic setup of the SRS server does not activate HTTPS. If your WordPress website is HTTPS, it will be unable to
> show the video coming from a HTTP server. Setting up HTTPS on your server requires additional steps, please follow
> [set-up HTTPS for SRS](./2022-04-12-Oryx-HTTPS.md) tutorial.
Step 3: Resize the player on your post or page.
By default the player has the size of the output size you determined in your OBS stream settings. This can cause your
WordPress layout to look off. To resize your player add `width="your chosen width"` in your shortcode.
For example, if I want my player to have a width of 320, your shortcode would look like this:
```text
[srs_player url="https://ip/live/livestream.m3u8" width="320"]
```
Your player should have a width of 320 and a height with the corresponding aspect ratio of your stream.
## Step 4: Set up your SRS server as HTTPS (optional)
If your WordPress website is protected by a SSL certificate and your initial setup of your SRS server is not, your video
will not play on your website.
Please follow [these instructions](./2022-04-12-Oryx-HTTPS.md) to
setup an SSL certificate for your SRS streaming server. After this setup your video will play on your website.
## Cloud Service
At SRS, our goal is to establish a non-profit, open-source community dedicated to creating an all-in-one,
out-of-the-box, open-source video solution for live streaming and WebRTC online services.
Additionally, we offer a [Cloud](../cloud) service for those who prefer to use cloud service instead of building from
scratch. Our cloud service features global network acceleration, enhanced congestion control algorithms,
client SDKs for all platforms, and some free quota.
To learn more about our cloud service, click [here](../cloud).
## Conclusion
In this tutorial you’ve learned to set up the SRS WordPress plugin and embedded a stream on your post or page. If you
have further questions about SRS, [the wiki](../docs/v4/doc/introduction) is a good place to start.
## Contact
If you’d like to discuss with SRS, you are welcome to [discord](https://discord.gg/yZ4BnPmHAd).
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/blog-en/22-04-15-WordPress-Plugin)

155
trunk/3rdparty/srs-docs/blog/2022-04-29-BT-aaPanel.md vendored Normal file
View File

@ -0,0 +1,155 @@
---
slug: BT-aaPanel
title: Oryx - How to Setup a Video Streaming Service with aaPanel
authors: []
tags: [tutorial, bt, aapanel, streaming]
custom_edit_url: null
---
# How to Setup a Video Streaming Service with aaPanel
## Introduction
[aaPanel](https://www.aapanel.com) is a simple website and server management tool. It is similar to [cpanel.net](https://cpanel.net/),
while aaPanel is free, open source and easy to develop plugins for media servers.
In this tutorial, you will learn how to deploy a live streaming media server, using aaPanel. If you have websites
deployed with aaPanel, it's also possible to deploy an extra media server to power your website with live streaming
service, for example, to enable live streaming feature for your WordPress website.
<!--truncate-->
## Prerequisites
To complete this guide, you should have:
1. A linux server, with aaPanel installed. Please use a CentOS 7+ or Ubuntu 20+ and install aaPanel on it by using [command here](https://www.aapanel.com/install.html).
2. **NGINX** based framework, if you also need to install websites. [Oryx](https://github.com/ossrs/oryx) requires **NGINX** to proxy to our backend services.
3. A DNS domain name, if you want to use HTTPS.
## Step 1: Install aaPanel
If you don't have aaPanel installed, please follow this [tutorial](https://www.aapanel.com/install.html). Highly
recommend install aaPanel on Ubuntu 20+:
```bash
wget -O install.sh https://download.bt.cn/install/install-ubuntu_6.0.sh && sudo bash install.sh ed8484bec
```
After installation, you will get a url, username and password for login, for example:
```text
==================================================================
Congratulations! Installed successfully!
==================================================================
aaPanel Internet Address: http://159.223.85.157:7800/a954fbf9
username: f6nka6v8
password: 4b43d253
```
Visit the url in a browser, as demonstrated below:
![](/img/blog-2022-04-29-en-001.png)
You might develop your website with WordPress, however it's optional. In the next step, let's set-up a media server with
aaPanel for live streaming.
## Step 2: Install Oryx
There are two ways to install Oryx. If you find the `Oryx` plugin in App Store, you could install it from
there, as shown in the following picture:
![](/img/blog-2022-04-29-en-002.png)
If not found in App Store, you could also download the latest version of the plugin in the oryx repository on
Github: [aapanel-oryx.zip](https://github.com/ossrs/oryx/releases/latest/download/aapanel-oryx.zip). Then
you could upload the zip file and install the plugin, as demonstrated below:
![](/img/blog-2022-04-29-en-003.png)
Both approaches will lead you to a installation guide, like this:
![](/img/blog-2022-04-29-en-004.png)
Please click on `Confirm to install` to continue the plugin installation. In the next step, we will set-up Oryx and
install some dependencies.
## Step 3: Setup Oryx
To set-up `Oryx`, please click the `Setting` button under `Operation` field:
![](/img/blog-2022-04-29-en-005.png)
Then click on `Install Oryx` to install the required softwares:
![](/img/blog-2022-04-29-en-006.png)
Oryx requires NGINX, Nodejs and Docker, please install all of them:
![](/img/blog-2022-04-29-en-007.png)
After installing all dependencies, continue to install Oryx:
![](/img/blog-2022-04-29-en-008.png)
When completion all the set-up, click on `Dashboard` and then visit the `Oryx Dashboard` via the link on the page:
![](/img/blog-2022-04-29-en-009.png)
Then set-up the admin password:
![](/img/blog-2022-04-29-en-010.png)
You could follow the tutorials to use Oryx:
![](/img/blog-2022-04-29-en-011.png)
Now we have a media server. In the next step, we publish a live stream to the server and play it through WordPress.
## Step 4: Publish and Play Live Stream
Please open the instruction page here: `Scenario > Streaming > OBS or vMix`
![](/img/blog-2022-04-29-en-012.png)
We recommend using OBS. You can download OBS from [here](https://obsproject.com/download), and configure it from
`Settings > Stream`:
![](/img/blog-2022-04-29-en-013.png)
Then, click on the `Start Streaming` to publish a live stream to your server. You could play the HTTP-FLV, HLS or WebRTC
either use a browser, or through WordPress:
```text
[srs_player url="http://159.223.85.157/live/livestream.m3u8"]
```
![](/img/blog-2022-04-29-en-014.png)
For details about WordPress shortcodes, please read this tutorial: [how to publish your SRS livestream through WordPress](https://blog.ossrs.io/publish-your-srs-livestream-through-wordpress-ec18dfae7d6f).
There is also a live demonstration here [SRS Player Demo](https://wp.ossrs.io/2022/04/25/srs-player/).
## Cloud Service
At SRS, our goal is to establish a non-profit, open-source community dedicated to creating an all-in-one,
out-of-the-box, open-source video solution for live streaming and WebRTC online services.
Additionally, we offer a [Cloud](../cloud) service for those who prefer to use cloud service instead of building from
scratch. Our cloud service features global network acceleration, enhanced congestion control algorithms,
client SDKs for all platforms, and some free quota.
To learn more about our cloud service, click [here](../cloud).
## Conclusion
In this tutorial, you create a live streaming service with aaPanel, publish a stream with OBS and then play it through a
browser or WordPress. If you have further questions about SRS, [the wiki](../docs/v4/doc/introduction)
is a good place to start.
## Contact
If you'd like to discuss with SRS community members, you are welcome to join us on [discord](https://discord.gg/yZ4BnPmHAd).
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/blog-en/22-04-29-BT-aaPanel)

366
trunk/3rdparty/srs-docs/blog/2022-05-16-Load-Balancing-Streaming-Servers.md vendored Normal file
View File

@ -0,0 +1,366 @@
---
slug: load-balancing-streaming-servers
title: SRS - Load Balancing Streaming Servers
authors: []
tags: [tutorial, cluster, load, dns, streaming]
custom_edit_url: null
---
# Load Balancing Streaming Servers
> Written by [Winlin](https://github.com/winlinvip), [Azusachino](https://github.com/azusachino), Benjamin
When our business workloads exceed streaming-server capacity, we have to balance those workloads. Normally, the problem can be solved by clustering. Clustering is not the only way to solve this problem, though. Sometimes the concept of Load Balancing can be linked to many emerging terms such as Service Discovery, but a LoadBalancer in cloud service is an indispensable requirement for solving the problem. In short, this problem is very complicated, and many people ask me about this frequently. Here I’m going to systematically discuss this issue.
<!--truncate-->
If you already have answers to the questions below and understand mechanisms behind, you may skip this article:
* Does SRS need NGINX, F5 or HAProxy as stream proxy? No, not at all. Who think the above three are needed are misunderstanding how streaming-server balances its loads. However, for HTTPS, we recommend using those proxies. And to reduce IP addresses for external service, we also recommend cloud LoadBalancer.
* How to discover SRS Edge nodes? How to discover Origin nodes? Edge nodes can be found through DNS and HTTP-DNS; Origin nodes should not be directly exposed to Clients for connection.
* What is special about WebRTC in terms of Service Discovery? Due to high CPU consumption, it’s easier to reach the threshold of Load Balancing. In single PeerConnection, streaming traffic changes dynamically, which makes it even harder to balance loads; For mobile devices, UDP switching between networks and IP drifting will introduce more problems.
* Comparing DNS and HTTP-DNS, which one is more suitable for streaming media server’s Service Discovery? The answer is of course HTTP-DNS. Because the load change of a streaming-server is greater than that of a Web server, we have to consider how it will affect the load when 1K more clients are added to both servers.
* Whether Load Balancing should only consider how to lower system load? The foremost target is to lower system load, or prevent the system from crashing; when the load is similar, we should also consider factors like nearby service and cost.
* Whether Load Balancing can be achieved by only adding one layer of server? Normally, a large scale CDN distribution system is layered, despite it is designed following static tree structure or dynamic MESH structure, and streaming capability is increased thanks to layering; meanwhile, we can use REUSEPORT strategy to enable node with more load by multi-processing, without adding layer.
* Whether Load Balancing can only be implemented by Clustering? Clustering is a very fundamental way to increase system capacity. Besides, we could combine business logic and Vhost to achieve system isolation, and diverging business and users via consistent hashing.
Well, let's discuss load and load balancing in detail.
# What is Load
Before addressing load balancing, let's define what is load. For a server, load is the consequence of increasing resource consumption, at the time of handling more requests from clients. Such an increase may cause the service to become unavailable when there is a serious imbalance.For example, all clients behave abnormally when CPU reaches 100%.
For streaming servers, load is caused by streaming clients consuming server resources. Load is generally evaluated from following perspectives:
* CPU, the computational resources consumed by the server. In general, we would classify the cases that consume huge amounts of CPU resources as computational-intensive scenarios, whereas the cases that consume large network bandwidth as I/O-intensive scenarios. Most of the time, live streaming is I/O-intensive, hence usually CPU is not the foremost bottleneck. Except in RTC, which is a both I/O- intensive and computational-intensive scenario. This is the main difference.
* Network bandwidth, network bandwidth is consumed when transmitting livestream. As mentioned, live streaming is an I/O-intensive scenario, hence bandwidth becomes a critical bottleneck.
* Disk, when there is no need to record and support HLS, disk is not a critical bottleneck. However, in case of recording and HLS are necessary, disk becomes a very critical bottleneck. Simply because the disk is the slowest. RAM drives are usually introduced to solve disk slowness because RAM is considerably more affordable nowadays.
* RAM is a less consumed resource in streaming servers, relatively speaking. Despite a lot of caches in place, RAM generally doesn't reach the limit before others. Therefore, RAM is also used heavily as Cache in streaming servers to exchange load on other resources. For example, in SRS, when optimizing CPU for live streaming, we use writev to cache and send a lot of data. The idea is to use RAM to trade for lower CPU load.
What are the consequences for high loads? It will directly lead to system issues, such as increased latency, lag, or even denial-of-service. Consequences of overload usually occur in the form of chain events. For example:
* CPU overload, which means the server can't support that many clients, will cause a chain of adverse events. On one hand, it will lead to queue stacking, which consumes a lot of memories. On the other hand, network throughput can't keep up as well, because the clients can't receive the data they need, consequently there is increasing latency and lag. All above issues will keep on adding even more CPU overloads, until the server crashes.
* Network bandwidth, when the system’s bandwidth limit is exceeded, such as the limit of the network card or system queue, all users cannot receive the data they need, and there will be lag. In addition, it will cause the queue to stack. More CPU will be required to process the stacked queue, which in return increases CPU load.
* Disk, if the disk load exceeds limit, system may hang further write operation. On servers that do write operation synchronously, it will lead to streams failing to transfer properly and logs piling up. On servers that do write operations asynchronously, it will lead to asynchronous queues to pile up. Note that SRS is currently writing synchronously and we’re working on enabling asynchronous writing in a multi-threaded fashion.
* RAM, the service process will be killed in case of Out-Of-Memory. RAM load increase is mainly caused by memory leaks, especially when there are many streams. For the sake of simplicity, SRS does not clean up and delete streams, hence worth your attention if there is continuous rising in memory load.
In light of those above, to reduce system load, the first and foremost step is to measure the load, aka focusing on overloads, this is also an issue that needs further clarification.
# What is Overload
When the load exceeds the system’s load capacity, overload happens. This is actually a complicated issue despite its simplistic description, for instance:
* Whether the CPU consumption reaches 100% means overload happens? No, because generally a server has multiple CPUs, hence a server with 8 CPUs reaches its CPU load limit when CPU consumption is 800%.
* Whether the CPU capacity will not be reached when the CPU consumption rate is below server’s capacity (such as 8-CPU server not reaching 800%)? No, because streaming servers might not use multiple CPU cores. For example, SRS server only uses one CPU, and its CPU capacity is 100%.
* Whether SRS server will not overload when SRS server CPU consumption rate does not reach 100%? No, because other processes also use CPU, SRS is not the only load that consumes CPU resources.
In conclusion, for CPU load and capacity, to know when overload happens, both streaming server’s available CPU resource and CPU resource in use must be identified and measured:
* For system total CPU resources, when the consumption rate reaches 80%, overload happens. For instance, an 8-CPU server, when CPU consumption rate reaches 640%, overload happens. Generally speaking, the total CPU load level is high when a system is busy. .
* For each SRS process, when CPU load reaches 80%, overload happens. For instance, an 8-CPU server total CPU usage reaches 120%, but SRS process only uses 80% of the CPU, other processes consume 40%, it is also overloaded.
Network bandwidth, whether it is overloaded, is considered over the following criteria. Streaming media bandwidth consumption is mainly due to code rate represented as Kbps or Mbps, which stands for bitrate or how much data is transmitted every second.
* One criteria is if server throughput is exceeded. For instance, when a cloud server public network throughput is 10Mbps, and each live stream’s average bitrate is 1Mbps, then the system overloads when there are 10 clients. If there are 100 clients publishing or viewing streams, each client can only transmit 100Kbps of data, consequently it results in severe latency and lag.
* Another criteria is whether the CPU's queue limit is exceeded. In UDP, the maximum size of a system queue is 256KB by default. In case there are many streams, the number and size of streaming packets might exceed the queue size. This will lead to packet loss even when the server throughput is not exceeded. More details can be seen at [performance optimization: RTC] (https://www.jianshu.com/p/6d4a89359352)
* The final criteria is the client's network throughput. Sometimes it is the poor network connectivity on the client side that results in client’s network throughput overload. Especially for live streams, the publisher’s upload throughput is the most important aspect to pay attention to. Some inexperienced publishers might have poor network connectivity, which leads to everyone lagging.
Disk, related to video recording, log splitting and STW problems caused by a slow disk :
* When there are multiple streams that require recording, disk will become the most critical bottleneck since it’s the slowest device. When designing a system, consideration must be given to address such problems. For example, a server has 64GB RAM. 32GB of RAM can be allocated to streaming service as temporary storage for media files. Another solution when having a small disk, is to use external services such as nodejs, with multithreading enabled, and then copy or store the files to the cloud storage. Please refer to [Oryx](https://github.com/ossrs/oryx) for the best practices.
* Server logs, abnormal situations might lead to large quantities of writing operations to log files. If not being divided and rotated properly, the size of log files will gradually increase, and eventually take up the entire disk space. SRS supports log-rotate, and docker allows setup with log-rotate too. The logs are usually extracted (the entire raw log can be extracted if there is not much), and sent to cloud-hosted log service for analysis. Local logs are only kept for a short period, e.g. 15 days.
* STW (Stop The World) issue. The write operations cause congestion and other disk operations are queued until the write operation completes. Especially when a network disk, such as a NAS, is mounted as a local drive. Then when the server performs data write operations, there are in fact many operations happening at the network layer, which consequently causes more delay. SRS servers should avoid using network disks completely, because each congestion will lead to a STW situation on a server and all other requests will be queued.
As for RAM, the main concerns are leakage and buffering. This is relatively simple, as can be solved by focusing on monitoring RAM usage for a system.
# Special for Media Server
In addition to general resource consumption, there are some additional factors that affect load or load balancing in a streaming server, including:
* Long connection: The live streaming and WebRTC streaming are both long. The longest live streaming may exceed 2 days. It's also common to have a meeting that lasts for a few hours. Therefore, the load of the streaming media servers has the characteristics of long connection, which will cause great disturbance to the load rebalancing. For example, the round-robin scheduling strategy may not be the most effective one.
* Stateful: There are many interactions between a streaming media server and its clients. There are some interim states, which makes the load balancing server unable to directly pass the request to a new server when there is a problem with the service, sometimes not even a request. The problem is especially evident in WebRTC, where DTLS and SRTP encrypt these states, making it impossible to switch servers at will.
* Correlation: There is no correlation between two web requests, and the failure of one will not affect the other. While in the live streaming, the push stream can affect all the playback. In WebRTC, the meeting may not continue, as long as one person fails to pull the stream or the transmission quality is too bad, even though the other streams are stable.
These are certainly not completely load and load balancing problems. For example, in order to solve the problem of some weak clients, WebRTC developed SVC and Simulcast. Some problems can be solved by the client's failed retry, such as the server can be forced to shut down when under high load, and then the clients will retry and migrate to the next server.
There is also a tendency to avoid streaming services and insteadly use slices such as HLS/DASH/CMAF, which then served via a web server and all of the above problems become irrelevant. However, the slicing protocol can actually only achieve 3 seconds delay at best, commonly more than 5 seconds. It is impractical to count on a slice server to accommodate 1 to 3 seconds delay, or even achieve the 500ms to 1 second low-latency in the live streaming, the RTC of 200ms to 500ms calls, and control scenarios within 100ms. These scenarios can only be implemented using a stream server, regardless of whether the TCP stream or UDP packet is transmitted.
We need to consider these issues when designing the system. For example, WebRTC should try to avoid coupling between streams and rooms, that is, the streams in a room must be distributed to multiple servers, rather than limited to one server. The more restrictions on these services, the more unfavorable it is for load balancing.
# SRS Overload
Let's talk about the load and overload conditions in SRS:
* SRS’s process. When the CPU usage exceeds 100%, overload happens. SRS has a single-process design, hence it cannot take advantage of multiple CPUs (which will be elaborated in the later section).
* Network bandwidth. It is usually the first resource that reaches overload. For example, CPU may still have a lot of free source, when the bandwidth throughput reaches 1Gbps in live streaming. RTC is slightly different, as it is computationally intensive too.
* Disk. Except when recording is only needed for very few streams, it is generally necessary to avoid disk usage so as to avoid consequent problems. Instead we could mount RAM-drives, or reduce the number of streams processed by each SRS. Please refer to [Oryx](https://github.com/ossrs/oryx) for best practices.
* Memory. It is generally less used, but we still care about the number of streams for some specific cases. For example, in case of CCTV monitoring when constant pushing and disconnecting happens, it is necessary to pay continuous attention to the increasing memory consumption by SRS. This issue can be circumvented by [Gracefully Quit](https://github.com/ossrs/srs/issues/413#issuecomment-917771521).
Special note for SRS single-process design. This is actually a choice. It is a trade-off for performance optimization. On one hand, multiprocessing can improve the processing capability. On the other hand, it is at the expense of increasing complexity of the system. Moreover it is hard to evaluate the overall load. For instance, what is an 8-core multiprocessing streaming server’s CPU overload threshold? Is it 640%? No, because the processes are not evenly consuming CPU resources. To even the process-consumption, we must implement process load balancing scheme, which is a more complicated problem.
At present, the single-process design of SRS can adapt to most scenarios. For live streaming, the Edge can use the multi-process `REUSEPORT` mechanism to listen on the same port to achieve multi-core consumption. RTC can use a certain number of ports. In cloud-native scenarios, using docker to run SRS, and you can also start multiple K8S Pods. These are options that require less effort.
> Note: Except for cloud services that are sensitive to budget, opt for customization is always an option, but at the cost of increasing complexity. To the best of my knowledge, several well-known cloud vendors have implemented multi-processed versions based on SRS. We are working together to open source the multiprocessing capability to improve the system load capacity in an affordable complexity range. For details, please refer to Threading #2188.
Now, we understand loads of streaming servers, it's time to think about how to balance those loads.
# Round Robin: Simple and Robust
Round Robin is a very simple load balancing strategy: every time a client requests a service, the scheduler finds the next server from the server list and returns to the client:
```cpp
server = servers[pos++ % servers.length()]
```
This strategy is more effective if each request is relatively balanced, for example, web requests are generally completed in a short time. In this way, it is very easy to add and delete servers, go online and offline, upgrade and isolate services.
Due to the characteristics of long connections in streaming media, the polling strategy is not useful enough, because some requests may be longer and some are shorter, which will cause load imbalance.Whereas, this strategy still works well if there are only a small number of requests.
In the Edge Cluster of SRS, the round-robin approach is also used when looking for the upstream Edge servers, with the assumption that the number of streams and the service time are relatively balanced. We consider this is a reasonable and appropriate assumption in open source applications. Essentially, this is the load balancing strategy for the upstream Edge servers, to solve the SRS origin overload problem when all the requests always go back to one server. As shown below:
![](/img/blog-2022-05-16-001.png)
In an SRS Origin Cluster, the Edge will also select an Origin server when pushing the stream for the first time, which uses the Round Robin strategy too. This is essentially the load balancing of the Origin server, which solves the problem of overloading the Origin server. As shown below:
![](/img/blog-2022-05-16-002.png)
In production business deployment, instead of simply using Round Robin, there is a scheduling service that collects the data from these servers, evaluates the load, and then picks an upstream edge server with lower load or higher service quality. As shown below:
![](/img/blog-2022-05-16-003.png)
Then how do we solve the load balancing problem of Edge? It relies on the Frontend Load Balancing strategy, which is the system on the frontend access point. We will talk about the commonly used methods below.
# Frontend Load Balancer: DNS or HTTP DNS
In the above Round Robin part, we focused on load balancing within the service, while the situation will be a bit different for servers that directly interfaces to the clients, generally called Frontend Load Balancer:
* If the entire streaming service has fewer nodes and is deployed centrally, the Round Robin is an OK choice. Viable options include set multiple resolution IPs in DNS, randomly select nodes when HTTP DNS returns, or select a server with a relatively light load.
* If there are multiple nodes, especially in distributed deployments, it is impossible to choose the Round Robin method, because, in addition to the load, the geographical location of the user also needs to be taken into consideration. Generally speaking, the "nearest" node should be selected. The same can be achieved with DNS and HTTP DNS, which is generally based on the user's exit IP, to obtain geographic location information from the geo-IP database.
In fact, there is no difference between DNS and HTTP DNS in terms of scheduling capabilities, and even lots of DNS and HTTP DNS systems have the same decision-making system, because they have to solve the same problem: how to use user’s IP, and other information (such as RTT or more detection data) to allocate more appropriate nodes. (usually the nearest one, also considering the cost)
DNS is the basis of the Internet. It can be considered as a name translator. For example, when we PING the server of SRS, it resolves `ossrs.io` into the IP address `182.92.233.108`. There is no load balancing capability here, because It's just a server, DNS is just name resolution here:
```bash
ping ossrs.io
PING ossrs.io (182.92.233.108): 56 data bytes
64 bytes from 182.92.233.108: icmp_seq=0 ttl=64 time=24.350 ms
```
What DNS does in streaming media load balancing is actually to return the IP of different servers according to the IP of the client, and the DNS system itself is also distributed. The DNS information can be recorded in the `/etc/hosts` file. If there is no such information, the IP of this domain name will be queried in LocalDNS (usually configured in the system or obtained automatically).
This means that DNS can withstand very large concurrency, because it is not a centralized DNS server providing resolution services, but a distributed system. This is why there is a TTL and expiration time when creating a new resolution. After modifying the resolution record, it will take effect after this time. In fact, it all depends on the policies of each DNS server, and there are some operations such as DNS hijacking and tampering, which sometimes cause load imbalance.
Therefore, HTTP DNS comes out. It can be considered that DNS is the basic network service provided by ISPs, while HTTP DNS can be implemented by streaming media platforms developers. It is a name service, or you can call an HTTP API to resolve, for example:
```bash
curl http://your-http-dns-service/resolve?domain=ossrs.io
{["182.92.233.108"]}
```
Since this service is provided by yourself, you can decide when to update the meaning of the name. Of course, you can achieve a more precise load-balancing, and also use HTTPS to prevent tampering and hijacking.
> Note: The your-http-dns-service of HTTP-DNS can use a set of IP or DNS domain name, because its load is relatively well balanced.
# Load Balancing by Vhost
SRS supports Vhost, which is generally used by CDN platforms to isolate multiple customers. Each customer can have its own domain name, such as:
```bash
vhost customer.a {
}
vhost customer.b {
}
```
If users push streams to the same IP server but use different vhosts, then they are different streams. When playback, they are also different streams, with different URL addresses, for example:
* `rtmp://ip/live/livestream?vhost=customer.a`
* `rtmp://ip/live/livestream?vhost=customer.b`
> Note: Of course, you can use the DNS system to map the ip to a different domain name, so that you can directly use the domain name in the URL.
In fact, Vhost can also be used for load balancing of multiple origin servers, because in Edge, different customers can be distributed to different origin servers, so that the capabilities of the origin server can be expanded without using `Origin Cluster`:
```bash
vhost customer.a {
cluster {
mode remote;
origin server.a;
}
}
vhost customer.b {
cluster {
mode remote;
origin server.b;
}
}
```
Different vhosts actually share the same Edge nodes, but `Upstream` and `Origin` can be isolated. And, of course, it can also be done with `Origin Cluster`. At this time, there are multiple origin server centers, which is a bit similar to the goal of `Consistent Hash`.
# Consistent Hash
In the scenario where Vhost isolates users, the configuration file can become much more complicated, and there is a simpler strategy to achieve this job, that is, `Consistent Hash`.
For example, Hash can be calculated based on the URL of the stream requested by the user, and then used to determine which `Upstream` or `Origin` to visit, with which can achieve the same isolation and load reduction.
In practice, there are already such solutions available online, so the scheme is definitely feasible. While, SRS does not implement this capability and you need to implement it by yourself.
In fact, Vhost or `Consistent Hash` can also be used along with Redirect to accomplish more complex load balancing.
# HTTP 302: Redirect
302 is `redirect`, which can actually be used for load balancing. For example, when access a server through scheduling, but if the server finds that its load is too high, then it can redirect the request to another server, as shown in the following figure:
![](/img/blog-2022-05-16-004.png)
> Note: Not only HTTP supports 302, RTMP also supports 302, and the SRS Origin Cluster is implemented in this way. While 302 here is mainly used for streaming service discovery, not for load balancing.
Since RTMP also supports 302, we can use 302 to achieve load rebalancing within the service. If the load of one `Upstream` is too high, the stream will be scheduled to other nodes with several 302 jumps.
Generally speaking, in `Frontend Server`, only HTTP streams support 302, such as HTTP-FLV or HLS. RTMP requires 302 support on the client side, which is infeasible because it is generally not supported.
In addition, UDP-based streaming media protocols also support 302, such as RTMFP (a Flash P2P protocol designed by Adobe), which also supports 302. And it's rarely used now.
WebRTC currently does not have a 302 mechanism, and generally relies on the proxy of `Frontend Server` to achieve load balancing of subsequent servers. QUIC as a future HTTP/3 standard, will definitely support the basic features like 302. WebRTC will gradually support WebTransport (based on QUIC), so this capability will also be available in the future.
# SRS: Edge Cluster
SRS Edge is essentially a `Frontend Server` and solves the following problems:
* Expand the capability of live streaming, such as supporting 100k viewers, we can scale the Edge Server horizontally.
* Solve the problem of nearby services, which plays the same role as CDN, and is generally deployed in the city where users are located.
* Edge uses the `Round Robin` when connected to the Upstream Edge to achieve Upstream's load balancing.
* The load balancing of Edge itself relies on a scheduling system, such as DNS or HTTP-DNS.
As shown below:
![](/img/blog-2022-05-16-005.png)
Special Note:
* Edge is an edge cluster for live streaming that supports RTMP and HTTP-FLV protocols.
* Edge does not support slices such as HLS or DASH, slices should be distributed by using Nginx or ATS.
* WebRTC is not supported, WebRTC has its own clustering mechanism.
Since Edge itself is a `Frontend Server`, it is generally not necessary to place Nginx or other LB in front of it in order to increase system capacity, because Edge itself is to solve the capacity problem, and only Edge can solve the problem of merging back to the origin.
> Note: Merging back to the origin means that the same stream will only be returned to the origin once. For example, if 1000 players are connected to the Edge, the Edge will only get 1 stream from the Upstream, rather than 1000 streams. This is different from the transparent Proxy.
Of course, sometimes we still need to place Nginx or LB in front, for example:
1. In order to support HTTPS-FLV or HTTPS-API. Nginx is better and supports HTTP/2.
2. Reduce external IP. For example, multiple servers only use one IP externally. At this time, a dedicated LB service is required to proxy multiple backend Edges.
3. Deploying on the cloud can only provide services through LB, which is limited by the design of cloud products, such as K8S's Service.
In addition, no other servers should be placed in front of Edge, and services should be provided directly by Edge.
# SRS: Origin Cluster
SRS Origin Cluster, different from the Edge Cluster, is mainly to expand the origin server’s capability:
* If there are massive streams, such as 10k streams, then a single origin server cannot handle it, and we need multiple origin servers to form a cluster.
* To solve the single-point problem of the origin server, we could switch to other regions when a problem occurs in any region if there are multi-region deployments.
* The performance problem of the slicing protocol, due to the large performance loss while writing to the disk, we could also use multiple origin servers to reduce the load in addition to using the RAM drives.
The SRS Origin Cluster should not be accessed directly and relies on Edge Cluster to provide external services, because two simple strategies:
* For stream discovery, the Origin Cluster will access an HTTP address to query stream, which is configured as another origin server by default, and could also be configured as a specialized service.
* RTMP 302 redirection, if the stream is not on the current origin server, it will be redirected to another origin server.
> Note: In fact, Edge could also access the stream query service before accessing the origin server, and initiate the connection after finding the one within the stream. But it's possible that the stream will be switched away, so there still requires a process of relocating the stream.
The whole process is quite simple, as shown below:
![](/img/blog-2022-05-16-006.png)
Since the stream is always on only one origin server, the `HLS` slice will also be generated by one origin without extra synchronization. Generally we could use shared storage, or use `on_hls` to send slices to the cloud storage.
> Note: Another way to achieve this: use the dual-stream hot backup. Usually there are two different streams, and we need to implement the backup mechanism. Generally this is very complicated for HLS, SRT and WebRTC. SRS does not support it.
From the aspect of load balancing, the origin cluster fits the job as a scheduler.
* Use `Round Robin` when the Edge returns to the origin server
* Query the specialized service of which origin server should be used
* Actively disconnect the stream when the load of the origin server is too high and force the client to re-push to achieve load balance
# SRS: WebRTC Cascade
The load of `WebRTC` is only on the origin servers. Load balancing at the edge has little relevance in WebRTC service model, because the ratio of publishing to viewing a stream in `WebRTC` is close to one, rather than the 1-to-10k difference in the `live-streaming` scenario. In other words, the edge is to solve the problem of massive viewing, and there is no need for load balancing at the edge when the publishing and viewing are similar (in the `live-streaming `scenario you can use edge for access and redirect).
Since `WebRTC` does not implement 302 redirect, there is no need to deploy edge (for access). For example, in a common `Load Balancing` scenario, when there are 10 SRS origin servers behind a VIP (i.e., the same VIP will be returned to the client), which SRS origin server will the client end up with? The answer is that it entirely depends on the `Load Balancing` strategy. At this time, it is impossible to add an edge to implement the _RTMP 302_ redirect like in the `live-streaming `scenario.
Therefore, the load balancing of `WebRTC` cannot be solved by `Edge` at all, whereas it relies on the `Origin Cluster`. Generally speaking, in `RTC`, this is called `Cascade`, that is, all nodes are equal, but connected with different levels of _Routing_ to increase the load capacity. As shown below:
![](/img/blog-2022-05-16-007.png)
This is an essential difference from the `Origin Cluster`. There is no media transmission between servers in the `Origin Cluster`, and _RTMP 302_ is used to instruct `Edge` redirecting to a specified origin server. The load of the origin server is predictable and manageable, as one origin server only owns a limited number of `Edge`s.
The `Origin Cluster` strategy is not suitable for `WebRTC`, because the client needs to connect directly to the origin server, and then the load of the origin server is not manageable at this time. For example, in a conference of 100 people, each stream will be subscribed by 100 people. At this time, users are distributedly connected to different origin servers. Hence, establishing connections among all the origin servers is required, in order to push one's own stream and get others’.
> Note: This example is a rather rare case. Generally speaking, a 100-person interactive conference will use the MCU mode, in which the server will merge different streams into one, or selectively forward several streams. The internal logic of such a server is very complicated.
In fact, one-to-one call is considered as the common `WebRTC` scenario, which accounts for about 80% of the business case. At this time, everyone publishes one stream and plays one stream. In a typical situation when there are many streams, the user can just connect to one origin server nearby. While the geographical locations of the users might not be the same, such as in different regions or countries, then the cascade between the origin servers should improve call quality.
Under the cascading architecture of origin servers, users access `HTTPS API` using `DNS` or `HTTP DNS` protocol. The `IP` of origin server is returned in `SDP`, so this is an opportunity for load balancing, which can return an origin server that is close to the user and has less load.
In addition, how to cascade multiple origin servers? If users are in a similar region, they can be dispatched to one origin server to avoid cascading. It saves internal transmission bandwidth (it is a well worthy and effective optimization when there are a large number of one-to-one calls in the same area). At the same time, this also increases the un-schedulability of loads, especially when a conference evolves into a multi-person one.
Therefore, in a conference, distinguishing one-to-one from multi-person conferences, or limiting the number of participants in it is actually very helpful for load balancing. It's easier to schedule and achieve load-balance if you are aware this is a one-to-one conference ahead of time. Unfortunately, project managers are generally not interested in this opinion.
> Remark: Note that the cascading feature has yet been implemented in SRS. Only the prototype has been implemented, and it has not been committed to the repository.
# TURN, ICE, QUIC, etc
In particular, let's talk about some `WebRTC`-related protocols, such as `TURN`, `ICE`, and `QUIC`.
`ICE` is not actually a transmission protocol, it is more like an identification protocol, generally referring to _Binding Request_ and _Response_, which will contain IP and priority information to identify the address and channel information for the selection of multiple channels, such as Who to choose when both 4G and WiFi are good enough. It is also used as the heartbeat of the session, and the client will always send `ICE` messages.
Therefore, `ICE` has no effect on load balancing, but it can be used to identify sessions, similar to `QUIC`'s _ConnectionID_, so it can play a role in identifying sessions when passing through Load Balancing, especially when the client's network switches.
The `TURN` protocol is actually a very unfriendly protocol for Cloud Native, because it needs to allocate a series of ports and use ports to distinguish users. This is practical in private networks, assuming that the ports are unlimited, while the ports on the cloud are often limited.
> Note: Of course, TURN can also multiplex a port without actually assigning a port, which limits the ability to use TURN to communicate directly but go through SFU, and there is no problem with SRS.
The real deal of `TURN` is to downgrade to the `TCP` protocol, because some enterprise firewalls do not support `UDP`, so they can only use `TCP`, and the client needs to use the `TCP` function of `TURN`. Of course, you can also use the `TCP` host directly. For example, _mediasoup_ supports it already, but `SRS` doesn't support it yet.
The _0RTT_ connection in `QUIC` is more friendly. The client caches the SSL `ticket-like` thing and can skip the handshake. For load balancing, `QUIC` is more effective because it has a _ConnectionID_. Then, when load balancing, even though the client changes the address and network, Load Balancer can still know which service on the backend handles it. But, of course, this actually makes the server load more difficult to transfer.
In fact, such a complex set of protocols and systems as `WebRTC` is quite messy and disgusting. Since the 100ms-level delay is a hard indicator, `UDP` and a complex set of congestion control protocols must be used, and encryption is also indispensable. Some people claim that Cloud Native's `RTC` is the future, which introduces more problems like port multiplexing, load balancing, long-connection and restart upgrades, as well as the structure that has been turned upside down, and `HTTP/3` and `QUIC` to spoil the game...
Perhaps for the load balancing of `WebRTC`, there is one word that is most applicable: there is no difficulty in the world, as long as you are willing to give up.
# SRS: Prometheus Exporter
The premise for `Load Balancing` is to know how to balance the load, which highly depends on data collection and calculation. [Prometheus](https://prometheus.io/) is for this purpose. It will continuously collect various data, and calculate these data according to its set of rules. Prometheus is essentially a time series database.
System load, which is also essentially a series of time series data, changes over time.
For example, Prometheus has a [node_exporter](https://github.com/prometheus/node_exporter), which provides the relevant timing information of the host node, such as CPU, disk, network, memory, etc., which can be used to compute service load.
Many services own a corresponding exporter. For example, [redis_exporter](https://github.com/oliver006/redis_exporter) collects Redis load data, [nginx-exporter](https://github.com/nginxinc/nginx-prometheus-exporter) collects Nginx load data.
At present, SRS has not implemented its own `srs-exporter`, but it will be implemented in the future. For details, please refer to [#2899](https://github.com/ossrs/srs/issues/2899).
## Cloud Service
At SRS, our goal is to establish a non-profit, open-source community dedicated to creating an all-in-one,
out-of-the-box, open-source video solution for live streaming and WebRTC online services.
Additionally, we offer a [Cloud](../cloud) service for those who prefer to use cloud service instead of building from
scratch. Our cloud service features global network acceleration, enhanced congestion control algorithms,
client SDKs for all platforms, and some free quota.
To learn more about our cloud service, click [here](../cloud).
## Contact
Welcome for more discussion at [discord](https://discord.gg/bQUPDRqy79).
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/blog-en/22-05-16-Load-Balancing-Streaming-Servers)

36
trunk/3rdparty/srs-docs/blog/2022-06-30-Video-Chat-Live.md vendored Normal file
View File

@ -0,0 +1,36 @@
---
slug: video-chat-live
title: SRS - Video Chat for Live Streaming
authors: []
tags: [tutorial, video, chat, streaming]
custom_edit_url: null
---
# Video Chat Live
This decade has seen rapid development in audio and video technology, from interactive entertainment and live e-commerce to online conferences and online education, with the recent rise of the metaverse, audio and video being one of the fundamental capabilities.
Starting from the live streaming with video chat scenario, we can understand the technologies involved in internet audio and video. By delving deeper into the relevant technical points of audio and video, we can build a complete audio and video technology system and quickly apply it to online businesses.
<!--truncate-->
On the way...
## Cloud Service
At SRS, our goal is to establish a non-profit, open-source community dedicated to creating an all-in-one,
out-of-the-box, open-source video solution for live streaming and WebRTC online services.
Additionally, we offer a [Cloud](../cloud) service for those who prefer to use cloud service instead of building from
scratch. Our cloud service features global network acceleration, enhanced congestion control algorithms,
client SDKs for all platforms, and some free quota.
To learn more about our cloud service, click [here](../cloud).
## Contact
Welcome for more discussion at [discord](https://discord.gg/bQUPDRqy79).
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/blog-en/22-06-30-Video-Chat-Live)

347
trunk/3rdparty/srs-docs/blog/2022-07-01-Coroutine-Native-SRT.md vendored Normal file
View File

@ -0,0 +1,347 @@
---
slug: coroutine-native-srt
title: SRS - Coroutine Native for SRT
authors: []
tags: [tutorial, video, srt, streaming]
custom_edit_url: null
---
# Coroutine Native SRT
> Written by [John](https://github.com/xiaozhihong), [Winlin](https://github.com/winlinvip)
Coroutines are core technologies for modern servers that significantly simplify the logic and facilitate maintenance. SRT is a new streaming protocol that is gradually taking over from RTMP. With its own I/O framework, SRT can mature only by becoming coroutine-native, the first and crucial step of SRS 5.0.
<!--truncate-->
Since the beginning of 2022, we have explored, discussed, and finally determined the media gateway as the fundamental direction of SRS 5.0, as detailed in [Definitions and Solutions of Core Issues with SRS 5.0](https://mp.weixin.qq.com/s/Rq3NuZKdMr2_Dmiki72RFw).
Though popular with live streaming/broadcasting push, SRT is not supported by web browsers. And that's where the media gateway comes into play. Specifically, it converts SRT into RTMP/HLS/WebRTC to deliver an ultra low-latency broadcasting solution that keeps SRT's powerful cross-border transfer capabilities.
The foundation lies in coroutine-native SRT, today's topic. It will have a far-reaching impact on SRS 5.0. For more information on its code, see [PR#3010](https://github.com/ossrs/srs/pull/3010).
First of all, let's talk about its background.
## Introduction
RTMP is widely used in the live push field. It is also one of the most compatible protocols with different live streaming origin servers.
With an increasing number of scenarios and the progress of live streaming, some of the acute problems have emerged:
1. TCP push performs poorly in terms of packet loss, RTT, and jitter for long-distance transfer.
1. RTMP doesn't support multiple audio tracks or new coding standards such as H.265 and AV1.
1. Adobe has abandoned RTMP, which has not been updated for years nor will it be updated in the future.
To solve these problems, the broadcasting field has widely adopted SRT push since 2018, and more and more push devices and platforms have followed suit.
At the end of 2019, SRT push became supported by SRS 4.0. However, there were several shortcomings:
1. SRT is implemented in SRS with multiple threads in an asynchronous manner, making it hard to troubleshoot program crashes due to exceptions.
1. SRT is implemented in SRS asynchronously, leading to complex code and maintenance.
1. SRT playback won't take effect after the HTTP callback, which is triggered by RTMP after the SRT push dependency turns to RTMP. There is no callback for playback.
1. SRT needs to be converted into RTMP first before it can be converted into WebRTC, causing a high latency.
The core cause of these problems is that SRT uses independent and asynchronous I/O and multiple threads that cannot be combined with the existing ST coroutines of SRS.
Therefore, SRT must become coroutine-native and fall into the same ST coroutine framework as SRS. This has been achieved in SRS 5.0. For more information on its code, see [PR#3010](https://github.com/ossrs/srs/pull/3010). This is an extremely important feature.
Before moving to the coroutine-native SRT, let's take a look at coroutine native itself, as exemplified by the coroutine-native TCP of ST.
## Coroutine Native TCP
To begin with, let's see the following logic of the non-coroutine-native code, that is, async code driven by epoll:
```cpp
int fd = accept(listen_fd); // Got a TCP connection.
int n = read(fd, buf, sizeof(buf));
if (n == -1) {
if (errno == EAGAIN) { // Not ready
return epoll_ctl(fd, EPOLLIN); // Wait for fd to be ready.
}
return n; // Error.
}
printf("Got %d size of data %p", n, buf);
```
> Note: The above is just a sample that helps better express the key logic. You can see epoll sample code for more details.
Generally speaking, read is a business logic, and the data that is read is business data. However, the underlying framework of epoll needs to be called here for fd processing during EAGAIN. As a result, the underlying logic and business logic are mixed, complicating maintenance.
> Note: Although NGINX has a packaged framework layer, async callback still exists. If the current function needs to be returned before the fd is ready, many statuses need to be stored and recovered. When the logic is complex, the state machine becomes complicated.
See the following code to see what a coroutine-native logic will be like in this case:
```cpp
st_netfd_t fd = st_accept(listen_fd); // Got a TCP connection
int n = st_read(fd, buf, sizeof(buf));
if (n == -1) {
return n; // Error.
}
printf("Got %d size of data %p", n, buf);
```
Obviously, there seems to be no EAGAIN. It may be that data is read or an error occurs. No matter what the case is, fd will always be ready. This means no need to store the status and no repeated read attempts, creating a very good experience when using the business logic.
Why is there no EAGAIN for `st_read` when epoll is still used? Well, there is, but it has been handled less obviously with the coroutine. Let's see the `st_readv` function:
```cpp
ssize_t st_read(_st_netfd_t *fd, void *buf, size_t nbyte) {
while ((n = read(fd->osfd, buf, nbyte)) < 0) {
if (errno == EINTR)
continue;
if (!_IO_NOT_READY_ERROR) // Error, if not EAGAIN.
return -1;
/* Wait until the socket becomes readable */
if (st_netfd_poll(fd, POLLIN) < 0) // EAGAIN
return -1;
}
return n;
}
```
During `EAGAIN`, `st_netfd_poll` is called, which switches the current coroutine and schedules the thread to execute the next coroutine. In addition, the current coroutine will be recovered at some point when the I/O event arrives or a timeout occurs.
> Note: Both the coroutine switch and recovery are implemented in the function and imperceptible to the code called at the upper layer. Therefore, there is no EAGAIN error message or return to the upper-layer function, and no need to store and resume the status.
In summary, do the following to make any protocol coroutine-native:
1. Call the API once, which will directly return upon success.
1. In the case of a failure, check for the error and return if the error is irrelevant to I/O wait.
1. Switch the current coroutine and run other coroutines until the arrival of a timeout or the fd event. In the former case, return an error; in the latter case, repeat the above steps.
With that, we can make SRT coroutine-native.
## Coroutine Native SRT
The `srt_recvmsg` function is used as an example. It resembles the `read` function of TCP and is as defined below:
```cpp
SRT_API int srt_recvmsg (SRTSOCKET u, char* buf, int len);
```
Implement `SrsSrtSocket::recvmsg` , another function similar to `st_read` :
```cpp
srs_error_t SrsSrtSocket::recvmsg(void* buf, size_t size, ssize_t* nread) {
while (true) {
int ret = srt_recvmsg(srt_fd_, (char*)buf, size);
if (ret >= 0) { // Receive message ok.
recv_bytes_ += ret;
*nread = ret;
return err;
}
// Got something error, return immediately.
if (srt_getlasterror(NULL) != SRT_EASYNCRCV) {
return srs_error_new(ERROR_SRT_IO, "srt_recvmsg");
}
// Wait for the fd ready or error, switch to other coroutines.
if ((err = wait_readable()) != srs_success) { // EAGAIN.
return srs_error_wrap(err, "wait readable");
}
}
return err;
}
```
As we can see, `wait_readable` implements coroutine switch and recovery just like `st_read` , but with the `st_cond_t` condition variable:
```cpp
srs_error_t SrsSrtSocket::wait_readable() {
srt_poller_->mod_socket(this, SRT_EPOLL_IN);
srs_cond_timedwait(read_cond_);
}
```
> Note: The `SRT_EPOLL_IN` event listened by epoll is modified before the fd becomes readable and the condition variable is triggered.
`SrsSrtPoller::wait` is the function that triggers the condition variable. Its implementation is as follows:
```cpp
srs_error_t SrsSrtPoller::wait(int timeout_ms, int* pn_fds) {
int ret = srt_epoll_uwait(srt_epoller_fd_, events_.data(), events_.size());
for (int i = 0; i < ret; ++i) {
if (event.events & SRT_EPOLL_IN) {
srt_skt->notify_readable();
}
}
}
void SrsSrtSocket::notify_readable() {
srs_cond_signal(read_cond_);
}
```
Now the SRT API becomes coroutine-native. The operation is similar for other APIs such as srt_sendmsg, srt_connnect, and srt_accept.
Let's compare coroutine native and the original callback.
## Coroutine Native PK Callback
After making the SRT coroutine-native, we succeeded in separating the business logic from the underlying code, thereby clarifying the upper-layer code logic.
Let's see the accept logic, where event processing is triggered by epoll to create the `srt_conn` data structure:
```cpp
while (run_flag) {
int ret = srt_epoll_wait(_pollid, read_fds, &rfd_num, write_fds);
for (int index = 0; index < rfd_num; index++) {
SRT_SOCKSTATUS status = srt_getsockstate(read_fds[index]);
srt_handle_connection(status, read_fds[index], "read fd");
}
}
void srt_server::srt_handle_connection(SRT_SOCKSTATUS status, SRTSOCKET input_fd) {
if (status == SRTS_LISTENING) {
conn_fd = srt_accept(input_fd, (sockaddr*)&scl, &sclen);
_handle_ptr->add_newconn(conn_fd, SRT_EPOLL_IN);
}
}
void srt_handle::add_newconn(SRT_CONN_PTR conn_ptr, int events) {
_push_conn_map.insert(std::make_pair(conn_ptr->get_path(), conn_ptr));
_conn_map.insert(std::make_pair(conn_ptr->get_conn(), conn_ptr));
int ret = srt_epoll_add_usock(_handle_pollid, conn_ptr->get_conn(), &events);
}
```
> Note: The created `srt_conn` is stored in the global data structure and continuously modified in the follow-up callback events.
The following is a coroutine-native business logic, which starts the processing coroutine after receiving the session:
```cpp
srs_error_t SrsSrtListener::cycle() {
while (true) {
srs_srt_t client_srt_fd = srs_srt_socket_invalid();
srt_skt_->accept(&client_srt_fd);
srt_server_->accept_srt_client(srt_fd);
}
}
srs_error_t SrsSrtServer::accept_srt_client(srs_srt_t srt_fd) {
fd_to_resource(srt_fd, &srt_conn);
conn_manager_->add(srt_conn);
srt_conn->start();
}
```
> Note: Although `srt_conn` is maintained by global variables, it is the coroutine-native execution logic—not callback logic or epoll processing—that is relevant.
In the callback logic, you need to view the epoll callback event before maintaining or understanding the code. What's worse, the `srt_conn` status is modified by different events, making it hard to understand the lifecycle of the object; while in the coroutine-native logic, its lifecycle is contained in the coroutine, it is processed in a coroutine after `srt_conn` is received, and further read and write operations are also performed in the coroutine.
Let's move on to the read processing logic of `srt_conn` , where the native read function of SRT is used and the callback is triggered by the epoll event:
```cpp
while (run_flag) {
int ret = srt_epoll_wait(_pollid, read_fds, &rfd_num, write_fds);
for (int index = 0; index < rfd_num; index++) {
SRT_SOCKSTATUS status = srt_getsockstate(read_fds[index]);
srt_handle_data(status, read_fds[index], "read fd");
}
}
void srt_handle::handle_srt_socket(SRT_SOCKSTATUS status, SRTSOCKET conn_fd) {
auto conn_ptr = get_srt_conn(conn_fd);
int mode = conn_ptr->get_mode();
if (mode == PUSH_SRT_MODE && status == SRTS_CONNECTED) {
handle_push_data(status, path, subpath, conn_fd);
}
}
void srt_handle::handle_push_data(SRT_SOCKSTATUS status, SRTSOCKET conn_fd) {
srt_conn_ptr = get_srt_conn(conn_fd);
if (status != SRTS_CONNECTED) { // Error.
close_push_conn(conn_fd);
return;
}
ret = srt_conn_ptr->read_async(data, DEF_DATA_SIZE);
if (ret <= 0) { // Error.
if (srt_getlasterror(NULL) != SRT_EASYNCRCV) {
return;
}
close_push_conn(conn_fd);
return;
}
srt2rtmp::get_instance()->insert_data_message(data, ret, subpath);
}
```
> Note: We need to process a variety of statuses in the callback, but the `srt_conn` status changes are determined by different callbacks, so it is not easy to determine the main processing logic of the session.
A coroutine-native version of the SRT business logic will be like:
```cpp
srs_error_t SrsMpegtsSrtConn::do_publishing() {
while (true) {
ssize_t nb = 0;
if ((err = srt_conn_->read(buf, sizeof(buf), &nb)) != srs_success) {
return srs_error_wrap(err, "srt: recvmsg");
}
if ((err = on_srt_packet(buf, nb)) != srs_success) {
return srs_error_wrap(err, "srt: process packet");
}
}
}
```
> Note: The lifecycle of `srt_conn` is clear, and its status is returned in the error within the cycle, which can be regarded as the main loop for this session. It will not enter the epoll loop of SRT due to read, and you can ignore the async event trigger and processing during maintenance.
Again, different information is required for code maintenance in different logics. In the async callback logic, you need to know the statuses of the current object, the modified statuses, and the impact of other async events from the callback function. While in the coroutine-native logic, these statuses are irrelevant, and the creation and execution of the coroutine are linear. Or we can say that these statuses are in the coroutine function callback.
> Note: The async callback status cannot be in the function callback, as the async callback stack cannot store the `srt_conn` status. In essence, it is a coroutine which stores the status of the epoll loop. While a coroutine is created according to each `srt_conn`, and the corresponding `srt_conn` status is stored in its stack.
In fact, the async callback status can only be stored in the global data structure, while the coroutine status can be stored in each local variable. The local variable of each function is unique to the coroutine and can be used as long as the coroutine doesn't end.
## What is the Next
The coroutine-native SRT still faces some problems and requires follow-up actions:
1. Directly convert SRT into WebRTC to lower the latency in live streaming.
1. Replace TCP with SRT for long-linkage transfer between some servers, such as cross-border RTMP forwarding.
1. Improve the SRT tool chain, such as [srs-bench](https://github.com/ossrs/srs-bench), to support stress testing of SRT streams.
Join the SRS open-source community to make a powerful streaming media server available for all.
## Cloud Service
At SRS, our goal is to establish a non-profit, open-source community dedicated to creating an all-in-one,
out-of-the-box, open-source video solution for live streaming and WebRTC online services.
Additionally, we offer a [Cloud](../cloud) service for those who prefer to use cloud service instead of building from
scratch. Our cloud service features global network acceleration, enhanced congestion control algorithms,
client SDKs for all platforms, and some free quota.
To learn more about our cloud service, click [here](../cloud).
## One More Thing
In case you may wonder, let me tell you the differences between a commercial video cloud SRT server and an open-source SRT server as well as the optimizations.
> Note: Some optimizations are not suitable for open-source projects, as open-source servers put more emphasis on protocol standardization and compatibility. Therefore, a commercial cloud computing server can be totally different from an open-source server. Even the Linux kernel of the commercial server will greatly differ from that of the open-source server.
Here, some of SRT's most troublesome problems are the high retransmission rate and poorer performance than TCP/QUIC when the bandwidth is limited. Tencent Cloud makes the following optimizations accordingly:
1. SRT retransmission disorder adaptation: When disordered packets are received, the system will wait for N packets before initiating the first retransmission according to the current degree of the disorder. The native SRT disorder has a fixed value, which can be adjusted to be more adaptive to the network disorder conditions.
1. SRT transfer parameter optimization: The retransmission rate is halved after the parameter optimization.
1. Addition of the BBR congestion control algorithm: The native SRT congestion control is weak, and the evaluated bandwidth fluctuates greatly, both of which are resolved by adding the BBR congestion control algorithm.
1. SRT multi-linkage transfer improved with bandwidth aggregation: The auto mode for live streaming is added to SRT, in addition to its native backup and broadcast modes. In this way, the bandwidths of multiple ENIs are aggregated for live streaming, with smart and dynamic linkage selection.
## Contact
Welcome for more discussion at [discord](https://discord.gg/bQUPDRqy79).
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/blog-en/22-07-01-Coroutine-Native-SRT)

170
trunk/3rdparty/srs-docs/blog/2022-09-05-WebRTC-Over-TCP.md vendored Normal file
View File

@ -0,0 +1,170 @@
---
slug: webrtc-over-tcp
title: SRS - Support WebRTC over TCP
authors: []
tags: [tutorial, video, webrtc, tcp]
custom_edit_url: null
---
# Support WebRTC over TCP
> Written by [Winlin](https://github.com/winlinvip), [李鹏](https://github.com/lipeng19811218)
In many networks, UDP is not available for WebRTC, so TCP is very important to make it highly reliable. SRS supports directly TCP transport for WebRTC, not TURN, which introduce a complex network layer and system. It also makes the LoadBalancer possible to forward TCP packets, because TCP is more stable than UDP for LoadBalancer.
<!--truncate-->
## Why Important?
About two years ago, SRS supported WebRTC. During these years, we have gotten lots of feedback. Some are very important and essential:
* UDP is not available, because firewall in company. There is a tool to detect the UDP port, see [#2843](https://github.com/ossrs/srs/issues/2843) for detail.
* There is a set of protocols and ports for media server, for example, RTMP(TCP/1935), HTTP-FLV/HLS(TCP/80/443), WebRTC(UDP/8000), SRT(UDP/10080) and HTTP-API(TCP/1985). All means cost for DevOps. How to deliver media over less ports? About reuse HTTP API and Stream, please read [#2881](https://github.com/ossrs/srs/issues/2881) for detail.
* UDP is permitted but there is loss, which might be caused by [system settings](https://www.jianshu.com/p/6d4a89359352). However TCP always works well, so it's also very good to have a choice to delivery WebRTC over TCP, see [#2852](https://github.com/ossrs/srs/issues/2852) for detail.
If we could deliver all media packets over HTTP like HTTP-FLV or HLS at TCP port 80 or 443, I think life should be easier, because HTTP is always available. The stream flow is like this:
```bash
Publisher --------RTC------> SRS --------RTC--------> Player
(over TCP/80) (over TCP/80)
```
> Note: Actually there is a HTTP API request and response for WebRTC, but here we ignore it. You're able to reuse the same TCP port for HTTP API, HTTP Stream and WebRTC over TCP.
Some experts might argue that `TURN` is also ok to solve this problem, it works like this:
```bash
Publisher -----> TURN ----> SRS -----> TURN -----> Player
(over TURN/3478). (over TURN/3478)
```
Obviously, TURN is not a good choice, because:
* Extra network server with dependencies. You need to deploy a network server, and update the debugging tools and systems for this network level.
* Extra protocol TURN, even though only few steps, but how to monitor and debug it? Especially need to work with other protocols, such as DTLS or SRTP over TURN.
* Delay and cost for a layer of network server and protocol stack. All these costs turn to CPU and bandwidth consuming.
In short, the best solution for WebRTC over TCP, is directly use TCP for WebRTC, not TURN. Please read detail of bellow RFC:
* SDP and ICE: [TCP Candidates with Interactive Connectivity Establishment (ICE)](https://www.rfc-editor.org/rfc/rfc6544)
* RTP over TCP: [Framing RTP and RTCP Packets over Connection-Oriented Transport](https://www.rfc-editor.org/rfc/rfc4571)
Next is about the status of SRS.
## What's Now?
SRS 5.0 has supported WebRTC over TCP:
* All HTTP API, HTTP Stream and WebRTC over TCP reuses one TCP port, such as TCP(443) for HTTPS.
* Support directly transport over UDP or TCP, no dependency of TURN, no extra system and resource cost.
* Works very well with [Proxy(Not Implemented)](https://github.com/ossrs/srs/issues/3138) and [Cluster(Not Implemented)](https://github.com/ossrs/srs/issues/2091), for load balancing and system capacity.
> Note: Please upgrade to `v5.0.60+`, please remember to check for both building or docker image.
First, we use TCP(8080) for WebRTC, which reuse port with HTTP Server:
```bash
docker run --rm -it -p 8080:8080/tcp \
-e CANDIDATE="192.168.3.82" \
-e SRS_HTTP_API_LISTEN=8080 \
-e SRS_RTC_SERVER_TCP_ENABLED=on \
-e SRS_RTC_SERVER_TCP_LISTEN=8080 \
-e SRS_RTC_SERVER_PROTOCOL=tcp \
registry.cn-hangzhou.aliyuncs.com/ossrs/srs:v5.0.60
```
* Publish WebRTC over TCP: [http://localhost:8080/rtc/v1/whip/?app=live&stream=livestream](http://localhost:8080/players/whip.html?autostart=true&api=8080)
* Play WebRTC over TCP: [http://localhost:8080/rtc/v1/whep/?app=live&stream=livestream](http://localhost:8080/players/whep.html?autostart=true&api=8080)
SRS allows coverting RTC to live streaming, so we use TCP(8080) for both WebRTC and HTTP live streaming:
```bash
docker run --rm -it -p 8080:8080/tcp \
-e CANDIDATE="192.168.3.82" \
-e SRS_VHOST_RTC_RTC_TO_RTMP=on \
-e SRS_HTTP_API_LISTEN=8080 \
-e SRS_RTC_SERVER_TCP_ENABLED=on \
-e SRS_RTC_SERVER_TCP_LISTEN=8080 \
-e SRS_RTC_SERVER_PROTOCOL=tcp \
registry.cn-hangzhou.aliyuncs.com/ossrs/srs:v5.0.60
```
* Publish WebRTC over TCP: [http://localhost:8080/rtc/v1/whip/?app=live&stream=livestream](http://localhost:8080/players/whip.html?autostart=true&api=8080)
* Play WebRTC over TCP: [http://localhost:8080/rtc/v1/whep/?app=live&stream=livestream](http://localhost:8080/players/whep.html?autostart=true&api=8080)
* Play HTTP FLV: [http://localhost:8080/live/livestream.flv](http://localhost:8080/players/srs_player.html?autostart=true)
* Play HLS: [http://localhost:8080/live/livestream.m3u8](http://localhost:8080/players/srs_player.html?stream=livestream.m3u8&autostart=true)
If not publishing by `localhost`, you must use HTTPS, so we use TCP(8088) for both WebRTC and HTTPS live streaming:
```bash
docker run --rm -it -p 8088:8088/tcp \
-e CANDIDATE="192.168.3.82" \
-e SRS_VHOST_RTC_RTC_TO_RTMP=on \
-e SRS_HTTP_API_LISTEN=8080 \
-e SRS_HTTP_API_HTTPS_ENABLED=on \
-e SRS_HTTP_API_HTTPS_LISTEN=8088 \
-e SRS_HTTP_SERVER_HTTTPS_ENABLED=on \
-e SRS_RTC_SERVER_TCP_ENABLED=on \
-e SRS_RTC_SERVER_TCP_LISTEN=8088 \
-e SRS_RTC_SERVER_PROTOCOL=tcp \
registry.cn-hangzhou.aliyuncs.com/ossrs/srs:v5.0.60
```
* Publish WebRTC over TCP: [webrtc://localhost:8088/live/livestream](https://localhost:8088/players/rtc_publisher.html?api=8088&autostart=true)
* Play WebRTC over TCP: [webrtc://localhost:8088/live/livestream](https://localhost:8088/players/rtc_player.html?api=8088&autostart=true)
* Play HTTP FLV: [https://localhost:8088/live/livestream.flv](https://localhost:8088/players/srs_player.html?schema=https&port=8088&autostart=true)
* Play HLS: [https://localhost:8088/live/livestream.m3u8](https://localhost:8088/players/srs_player.html?schema=https&port=8088&stream=livestream.m3u8&autostart=true)
> Note: You can also use IP to access the webpage. Note that because of self-signed cert files for HTTPS, you must click the blank of page and type string `thisisunsafe`
We configure SRS by environment variables, but you're also able to use configuration file:
```bash
rtc_server {
# 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;
}
```
We demostrate the reusing port of WebRTC and HTTP Stream, but you're able to use dedicated TCP ports for HTTP and WebRTC over TCP.
## Cloud Service
At SRS, our goal is to establish a non-profit, open-source community dedicated to creating an all-in-one,
out-of-the-box, open-source video solution for live streaming and WebRTC online services.
Additionally, we offer a [Cloud](../cloud) service for those who prefer to use cloud service instead of building from
scratch. Our cloud service features global network acceleration, enhanced congestion control algorithms,
client SDKs for all platforms, and some free quota.
To learn more about our cloud service, click [here](../cloud).
## Future Plan
We're developing SRS 5.0, and we might close features at the end of 2022.
## Contact
Welcome to join the SRS community by [discord](https://discord.gg/yZ4BnPmHAd).
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/blog-en/2022-09-05-WebRTC-Over-TCP)

135
trunk/3rdparty/srs-docs/blog/2022-11-25-DASH-Issues.md vendored Normal file
View File

@ -0,0 +1,135 @@
---
slug: why-dash-is-bad-solution-for-live-streaming
title: SRS - Why DASH Is Bad Solution for Live Streaming
authors: []
tags: [video, dash, live, streaming]
custom_edit_url: null
---
# Why DASH Is Bad Solution for Live Streaming
> Written by [John](https://github.com/xiaozhihong), [Winlin](https://github.com/winlinvip)
What is MPEG-DASH(Dynamic Adaptive Streaming over HTTP)? Because Apple HLS is not good enough, so some guys wanted to
fix it and created an even worse protocol, named DASH or MPEG-DASH.
Well, it's just a joke for any new technology, especially when it's new and there are some issues. However, it's really
true for DASH today, at 2022.11, because we're really suffering while maintaining it.
But, DASH is becoming more and more popular protocol for live streaming, and we believe that all issues will be fixed
in not very far future, so let's take a look about these issues.
<!--truncate-->
## Good News: Normal Scenario
DASH is available for both VoD and LIVE streaming, and it works for `NORMAL` use scenarios. Let's have a glance.
```bash
docker run --rm -it -p 8080:8080 -p 1935:1935 \
-e SRS_HTTP_SERVER_ENABLED=on -e SRS_VHOST_DASH_ENABLED=on \
ossrs/srs:5
```
Publish a live stream by RTMP to media server:
```bash
docker run --rm -it ossrs/srs:encoder ffmpeg -stream_loop -1 -re -i doc/source.flv \
-c copy -f flv rtmp://host.docker.internal/live/livestream
```
Finally you're able to play DASH by:
* VLC: `http://localhost:8080/live/livestream.mpd`
* FFmpeg: `ffplay http://localhost:8080/live/livestream.mpd`
* H5 [srs-player](http://localhost:8080/players/srs_player.html?stream=livestream.mpd&autostart=true)
It's very easy, right?!
## Bad News: Republishing
What's the issues of DASH?
If you open [srs-player](http://localhost:8080/players/srs_player.html?stream=livestream.mpd&autostart=true) and wait
for about serval minutes while stream is republished, you will find out that the player might be stuck.
Yep, it's maybe the problem of srs-player, which use [dash.js@v4.5.1](https://github.com/Dash-Industry-Forum/dash.js),
so let's choose another player.
What about VLC? Also fails when stream is republishing.
What about ffplay? Also fails.
All these issues are literally caused by republishing, that is, when you stop the stream, and then publish the stream,
players might be stuck.
> Note: Player will resume to play when refresh the page.
For HLS, the `EXT-X-DISCONTINUITY` is design for this situation, and all players work very well when stream republishing.
For DASH, the spec introduces a new Period, but it does work whatever. So SRS will regenerate a new MPD file, it makes
the dash.js happy, but doesn't work for VLC or ffplay.
## Bad News: MPD Mode
If use `SegmentTimeline` and use `$Time$` mode, there is bug for `VLC 3.0.17`, but `VLC 4.0` is ok. For more detail
information about this issue, please see [VLC#2845](https://code.videolan.org/videolan/vlc/-/merge_requests/2845).
If use `SegmentTemplate` without `SegmentTimeline`, player will guess the file name, but it literally fails while
streaming for a long time. SRS 4.0 uses this mode and there is some bugs about it, see [SRS#1864](https://github.com/ossrs/srs/issues/1864).
So SRS 5.0 fix this issue and use another mode.
SRS 5.0 use `SegmentTemplate` with `SegmentTimeline`, and use `$Number$` but not `$Time$` mode, because there is also
bug for `$Time$` mode for VLC as previous description.
Right now, at 2022.11, the best compatible mode is `SegmentTemplate` with `SegmentTimeline` and `$Number$` mode, which
is used for SRS 5.0. H5(dash.js) works well, but VLC/ffplay still have some issues.
## About HEVC
[Chrome 105+](https://caniuse.com/?search=HEVC) supports HEVC by default, see [this post](https://zhuanlan.zhihu.com/p/541082191).
You're able to play HEVC over mp4 directly by H5 video, or by MSE if HTTP-FLV/HTTP-TS/HLS etc. Please use [mpegts.js](https://github.com/xqq/mpegts.js)
to play HEVC over HTTP-FLV or HTTP-TS, see [SRS#465](https://github.com/ossrs/srs/issues/465#usage).
For DASH, the protocol does not limit to use H.264 or HEVC, because it use MP4 which can be play by MSE by Chrome 105+.
However, there still some extra work for media server, to support MP4 or DASH with HEVC. SRS 6.0 is still working on it,
for detail information please see [SRS#465](https://github.com/ossrs/srs/issues/465#status-of-hevc-in-srs).
## Publish by H5 then Delivery by DASH
If wants to publish live stream by H5, then delivery by MPEG-DASH, there is a solution:
```bash
Camera/Microphone --WebRTC---> SRS --DASH--> Viewers
```
Because the only way is to use WebRTC to access the camera and microphone for H5, so you must use WebRTC to ingest live
stream to media server such as SRS. Then SRS will covert WebRTC to RTMP, finally covert to MPEG-DASH, plese see [this post](../docs/v5/doc/getting-started#webrtc-for-live-streaming).
Note that SRS also support [WebRTC-HTTP ingestion protocol (WHIP)](https://datatracker.ietf.org/doc/draft-ietf-wish-whip/),
for example, [srs-unity](https://github.com/ossrs/srs-unity) uses WHIP to publish Unity camera stream.
## Cloud Service
At SRS, our goal is to establish a non-profit, open-source community dedicated to creating an all-in-one,
out-of-the-box, open-source video solution for live streaming and WebRTC online services.
Additionally, we offer a [Cloud](../cloud) service for those who prefer to use cloud service instead of building from
scratch. Our cloud service features global network acceleration, enhanced congestion control algorithms,
client SDKs for all platforms, and some free quota.
To learn more about our cloud service, click [here](../cloud).
## Conclusion
DASH is a relative new and good live streaming protocol. After about two years, SRS 5.0 has always been fixing bug and
now we think it's ready and stable to use DASH in your online product if you want.
## Contact
If you'd like to discuss with SRS, you are welcome to [discord](https://discord.gg/yZ4BnPmHAd)
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/blog-en/2022-11-25-DASH-Issues)

389
trunk/3rdparty/srs-docs/blog/2023-02-26-State-Threads-for-Internet-Applications.md vendored Normal file
View File

@ -0,0 +1,389 @@
---
slug: state-threads-for-internet-applications
title: SRS - State Threads for Internet Applications
authors: []
tags: [coroutine, network, server, performance, architecture]
custom_edit_url: null
---
# State Threads for Internet Applications
> Written by [thread-threads](https://github.com/ossrs/state-threads)
[State Threads](https://github.com/ossrs/state-threads) is an application library which provides a foundation for writing fast and highly scalable Internet
Applications on UNIX-like platforms. It combines the simplicity of the multithreaded programming paradigm, in which one
thread supports each simultaneous connection, with the performance and scalability of an event-driven state machine
architecture.
<!--truncate-->
## Definitions
### Internet Applications
An Internet Application (IA) is either a server or client network application that accepts connections from clients and
may or may not connect to servers. In an IA the arrival or departure of network data often controls processing (that is,
IA is a data-driven application). For each connection, an IA does some finite amount of work involving data exchange
with its peer, where its peer may be either a client or a server. The typical transaction steps of an IA are to accept
a connection, read a request, do some finite and predictable amount of work to process the request, then write a
response to the peer that sent the request. One example of an IA is a Web server; the most general example of an IA is
a proxy server, because it both accepts connections from clients and connects to other servers.
We assume that the performance of an IA is constrained by available CPU cycles rather than network bandwidth or disk
I/O (that is, CPU is a bottleneck resource).
### Performance and Scalability
The performance of an IA is usually evaluated as its throughput measured in transactions per second or bytes per second
(one can be converted to the other, given the average transaction size). There are several benchmarks that can be used
to measure throughput of Web serving applications for specific workloads (such as SPECweb96, WebStone, WebBench).
Although there is no common definition for scalability, in general it expresses the ability of an application to
sustain its performance when some external condition changes. For IAs this external condition is either the number of
clients (also known as "users," "simultaneous connections," or "load generators") or the underlying hardware system
size (number of CPUs, memory size, and so on). Thus there are two types of scalability: load scalability and system
scalability, respectively.
The figure below shows how the throughput of an idealized IA changes with the increasing number of clients (solid blue
line). Initially the throughput grows linearly (the slope represents the maximal throughput that one client can
provide). Within this initial range, the IA is underutilized and CPUs are partially idle. Further increase in the
number of clients leads to a system saturation, and the throughput gradually stops growing as all CPUs become fully
utilized. After that point, the throughput stays flat because there are no more CPU cycles available. In the real
world, however, each simultaneous connection consumes some computational and memory resources, even when idle, and this
overhead grows with the number of clients. Therefore, the throughput of the real world IA starts dropping after some
point (dashed blue line in the figure below). The rate at which the throughput drops depends, among other things, on
application design.
We say that an application has a good load scalability if it can sustain its throughput over a wide range of loads.
Interestingly, the SPECweb99 benchmark somewhat reflects the Web server's load scalability because it measures the
number of clients (load generators) given a mandatory minimal throughput per client (that is, it measures the server's
capacity). This is unlike SPECweb96 and other benchmarks that use the throughput as their main metric (see the figure
below).
![](/img/blog-2023-02-26-001.png)
System scalability is the ability of an application to sustain its performance per hardware unit (such as a CPU) with
the increasing number of these units. In other words, good system scalability means that doubling the number of
processors will roughly double the application's throughput (dashed green line). We assume here that the underlying
operating system also scales well. Good system scalability allows you to initially run an application on the smallest
system possible, while retaining the ability to move that application to a larger system if necessary, without
excessive effort or expense. That is, an application need not be rewritten or even undergo a major porting effort when
changing system size.
Although scalability and performance are more important in the case of server IAs, they should also be considered for
some client applications (such as benchmark load generators).
### Concurrency
Concurrency reflects the parallelism in a system. The two unrelated types are virtual concurrency and real concurrency.
Virtual (or apparent) concurrency is the number of simultaneous connections that a system supports.
Real concurrency is the number of hardware devices, including CPUs, network cards, and disks, that actually allow a
system to perform tasks in parallel.
An IA must provide virtual concurrency in order to serve many users simultaneously. To achieve maximum performance and
scalability in doing so, the number of programming entities than an IA creates to be scheduled by the OS kernel should
be kept close to (within an order of magnitude of) the real concurrency found on the system. These programming entities
scheduled by the kernel are known as kernel execution vehicles. Examples of kernel execution vehicles include Solaris
lightweight processes and IRIX kernel threads. In other words, the number of kernel execution vehicles should be
dictated by the system size and not by the number of simultaneous connections.
## Existing Architectures
There are a few different architectures that are commonly used by IAs. These include the Multi-Process, Multi-Threaded,
and Event-Driven State Machine architectures.
### Multi-Process Architecture
In the Multi-Process (MP) architecture, an individual process is dedicated to each simultaneous connection. A process
performs all of a transaction's initialization steps and services a connection completely before moving on to service
a new connection.
User sessions in IAs are relatively independent; therefore, no synchronization between processes handling different
connections is necessary. Because each process has its own private address space, this architecture is very robust.
If a process serving one of the connections crashes, the other sessions will not be affected. However, to serve many
concurrent connections, an equal number of processes must be employed. Because processes are kernel entities (and are
in fact the heaviest ones), the number of kernel entities will be at least as large as the number of concurrent
sessions. On most systems, good performance will not be achieved when more than a few hundred processes are created
because of the high context-switching overhead. In other words, MP applications have poor load scalability.
On the other hand, MP applications have very good system scalability, because no resources are shared among different
processes and there is no synchronization overhead.
The Apache Web Server 1.x ([Reference 1]) uses the MP architecture on UNIX systems.
### Multi-Threaded Architecture
In the Multi-Threaded (MT) architecture, multiple independent threads of control are employed within a single shared
address space. Like a process in the MP architecture, each thread performs all of a transaction's initialization steps
and services a connection completely before moving on to service a new connection.
Many modern UNIX operating systems implement a many-to-few model when mapping user-level threads to kernel entities.
In this model, an arbitrarily large number of user-level threads is multiplexed onto a lesser number of kernel
execution vehicles. Kernel execution vehicles are also known as virtual processors. Whenever a user-level thread
makes a blocking system call, the kernel execution vehicle it is using will become blocked in the kernel. If there
are no other non-blocked kernel execution vehicles and there are other runnable user-level threads, a new kernel
execution vehicle will be created automatically. This prevents the application from blocking when it can continue
to make useful forward progress.
Because IAs are by nature network I/O driven, all concurrent sessions block on network I/O at various points. As a
result, the number of virtual processors created in the kernel grows close to the number of user-level threads (or
simultaneous connections). When this occurs, the many-to-few model effectively degenerates to a one-to-one model.
Again, like in the MP architecture, the number of kernel execution vehicles is dictated by the number of simultaneous
connections rather than by number of CPUs. This reduces an application's load scalability. However, because kernel
threads (lightweight processes) use fewer resources and are more light-weight than traditional UNIX processes, an MT
application should scale better with load than an MP application.
Unexpectedly, the small number of virtual processors sharing the same address space in the MT architecture destroys
an application's system scalability because of contention among the threads on various locks. Even if an application
itself is carefully optimized to avoid lock contention around its own global data (a non-trivial task), there are
still standard library functions and system calls that use common resources hidden from the application. For example,
on many platforms thread safety of memory allocation routines (malloc(3), free(3), and so on) is achieved by using a
single global lock. Another example is a per-process file descriptor table. This common resource table is shared by
all kernel execution vehicles within the same process and must be protected when one modifies it via certain system
calls (such as open(2), close(2), and so on). In addition to that, maintaining the caches coherent among CPUs on
multiprocessor systems hurts performance when different threads running on different CPUs modify data items on the
same cache line.
In order to improve load scalability, some applications employ a different type of MT architecture: they create one or
more thread(s) per task rather than one thread per connection. For example, one small group of threads may be
responsible for accepting client connections, another for request processing, and yet another for serving responses.
The main advantage of this architecture is that it eliminates the tight coupling between the number of threads and
number of simultaneous connections. However, in this architecture, different task-specific thread groups must share
common work queues that must be protected by mutual exclusion locks (a typical producer-consumer problem). This adds
synchronization overhead that causes an application to perform badly on multiprocessor systems. In other words, in
this architecture, the application's system scalability is sacrificed for the sake of load scalability.
Of course, the usual nightmares of threaded programming, including data corruption, deadlocks, and race conditions,
also make MT architecture (in any form) non-simplistic to use.
### Event-Driven State Machine Architecture
In the Event-Driven State Machine (EDSM) architecture, a single process is employed to concurrently process multiple
connections. The basics of this architecture are described in Comer and Stevens [Reference 2]. The EDSM architecture
performs one basic data-driven step associated with a particular connection at a time, thus multiplexing many
concurrent connections. The process operates as a state machine that receives an event and then reacts to it.
In the idle state the EDSM calls select(2) or poll(2) to wait for network I/O events. When a particular file descriptor
is ready for I/O, the EDSM completes the corresponding basic step (usually by invoking a handler function) and starts
the next one. This architecture uses non-blocking system calls to perform asynchronous network I/O operations. For
more details on non-blocking I/O see Stevens [Reference 3].
To take advantage of hardware parallelism (real concurrency), multiple identical processes may be created. This is
called Symmetric Multi-Process EDSM and is used, for example, in the Zeus Web Server ([Reference 4]). To more
efficiently multiplex disk I/O, special "helper" processes may be created. This is called Asymmetric Multi-Process
EDSM and was proposed for Web servers by Druschel and others [Reference 5].
EDSM is probably the most scalable architecture for IAs. Because the number of simultaneous connections (virtual
concurrency) is completely decoupled from the number of kernel execution vehicles (processes), this architecture has
very good load scalability. It requires only minimal user-level resources to create and maintain additional connection.
Like MP applications, Multi-Process EDSM has very good system scalability because no resources are shared among
different processes and there is no synchronization overhead.
Unfortunately, the EDSM architecture is monolithic rather than based on the concept of threads, so new applications
generally need to be implemented from the ground up. In effect, the EDSM architecture simulates threads and their
stacks the hard way.
## State Threads Library
The State Threads library combines the advantages of all of the above architectures. The interface preserves the
programming simplicity of thread abstraction, allowing each simultaneous connection to be treated as a separate thread
of execution within a single process. The underlying implementation is close to the EDSM architecture as the state of
each particular concurrent session is saved in a separate memory segment.
### State Changes and Scheduling
The state of each concurrent session includes its stack environment (stack pointer, program counter, CPU registers)
and its stack. Conceptually, a thread context switch can be viewed as a process changing its state. There are no kernel
entities involved other than processes. Unlike other general-purpose threading libraries, the State Threads library is
fully deterministic. The thread context switch (process state change) can only happen in a well-known set of functions
(at I/O points or at explicit synchronization points). As a result, process-specific global data does not have to be
protected by mutual exclusion locks in most cases. The entire application is free to use all the static variables and
non-reentrant library functions it wants, greatly simplifying programming and debugging while increasing performance.
This is somewhat similar to a co-routine model (co-operatively multitasked threads), except that no explicit yield is
needed -- sooner or later, a thread performs a blocking I/O operation and thus surrenders control. All threads of
execution (simultaneous connections) have the same priority, so scheduling is non-preemptive, like in the EDSM
architecture. Because IAs are data-driven (processing is limited by the size of network buffers and data arrival
rates), scheduling is non-time-slicing.
Only two types of external events are handled by the library's scheduler, because only these events can be detected by
select(2) or poll(2): I/O events (a file descriptor is ready for I/O) and time events (some timeout has expired).
However, other types of events (such as a signal sent to a process) can also be handled by converting them to I/O
events. For example, a signal handling function can perform a write to a pipe (write(2) is reentrant/asynchronous-safe),
thus converting a signal event to an I/O event.
To take advantage of hardware parallelism, as in the EDSM architecture, multiple processes can be created in either a
symmetric or asymmetric manner. Process management is not in the library's scope but instead is left up to the
application.
There are several general-purpose threading libraries that implement a many-to-one model (many user-level threads to
one kernel execution vehicle), using the same basic techniques as the State Threads library (non-blocking I/O,
event-driven scheduler, and so on). For an example, see GNU Portable Threads ([Reference 6]). Because they are
general-purpose, these libraries have different objectives than the State Threads library. The State Threads library
is not a general-purpose threading library, but rather an application library that targets only certain types of
applications (IAs) in order to achieve the highest possible performance and scalability for those applications.
### Scalability
State threads are very lightweight user-level entities, and therefore creating and maintaining user connections
requires minimal resources. An application using the State Threads library scales very well with the increasing
number of connections.
On multiprocessor systems an application should create multiple processes to take advantage of hardware parallelism.
Using multiple separate processes is the only way to achieve the highest possible system scalability. This is because
duplicating per-process resources is the only way to avoid significant synchronization overhead on multiprocessor
systems. Creating separate UNIX processes naturally offers resource duplication. Again, as in the EDSM architecture,
there is no connection between the number of simultaneous connections (which may be very large and changes within
a wide range) and the number of kernel entities (which is usually small and constant). In other words, the State
Threads library makes it possible to multiplex a large number of simultaneous connections onto a much smaller number
of separate processes, thus allowing an application to scale well with both the load and system size.
### Performance
Performance is one of the library's main objectives. The State Threads library is implemented to minimize the number
of system calls and to make thread creation and context switching as fast as possible. For example, per-thread signal
mask does not exist (unlike POSIX threads), so there is no need to save and restore a process's signal mask on every
thread context switch. This eliminates two system calls per context switch. Signal events can be handled much more
efficiently by converting them to I/O events (see above).
### Portability
The library uses the same general, underlying concepts as the EDSM architecture, including non-blocking I/O, file
descriptors, and I/O multiplexing. These concepts are available in some form on most UNIX platforms, making the library
very portable across many flavors of UNIX. There are only a few platform-dependent sections in the source.
> Note: SRS updates [State Threads](https://github.com/ossrs/state-threads) to support modern CPU and OS, such as aarch64 and windows, please see [#22](https://github.com/ossrs/state-threads/issues/22) for detail.
### State Threads and NSPR
The State Threads library is a derivative of the Netscape Portable Runtime library (NSPR) [Reference 7]. The primary
goal of NSPR is to provide a platform-independent layer for system facilities, where system facilities include threads,
thread synchronization, and I/O. Performance and scalability are not the main concern of NSPR. The State Threads
library addresses performance and scalability while remaining much smaller than NSPR. It is contained in 8 source
files as opposed to more than 400, but provides all the functionality that is needed to write efficient IAs on
UNIX-like platforms.
## Conclusion
State Threads is an application library which provides a foundation for writing Internet Applications. To summarize,
it has the following advantages:
It allows the design of fast and highly scalable applications. An application will scale well with both load and number
of CPUs.
It greatly simplifies application programming and debugging because, as a rule, no mutual exclusion locking is
necessary and the entire application is free to use static variables and non-reentrant library functions.
The library's main limitation:
All I/O operations on sockets must use the State Thread library's I/O functions because only those functions perform
thread scheduling and prevent the application's processes from blocking.
## References
1. Apache Software Foundation, http://www.apache.org.
1. Douglas E. Comer, David L. Stevens, Internetworking With TCP/IP, Vol. III: Client-Server Programming And Applications, Second Edition, Ch. 8, 12.
1. W. Richard Stevens, UNIX Network Programming, Second Edition, Vol. 1, Ch. 15.
1. Zeus Technology Limited, http://www.zeus.co.uk.
1. Peter Druschel, Vivek S. Pai, Willy Zwaenepoel, Flash: An Efficient and Portable Web Server. In Proceedings of the USENIX 1999 Annual Technical Conference, Monterey, CA, June 1999.
1. GNU Portable Threads, http://www.gnu.org/software/pth/.
1. Netscape Portable Runtime, http://www.mozilla.org/docs/refList/refNSPR/.
Other resources covering various architectural issues in IAs
1. Dan Kegel, The C10K problem, http://www.kegel.com/c10k.html.
1. James C. Hu, Douglas C. Schmidt, Irfan Pyarali, JAWS: Understanding High Performance Web Systems, http://www.cs.wustl.edu/~jxh/research/research.html.
## Example
The example bellow demonstrate how to use ST to start 30K coroutines, each is able to serve a network connection:
```c
#include <stdio.h>
#include "st.h"
void* do_calc(void* arg){
int sleep_ms = (int)(long int)(char*)arg * 10;
for(;;){
printf("in sthread #%dms\n", sleep_ms);
st_usleep(sleep_ms * 1000);
}
return NULL;
}
int main(int argc, char** argv){
if(argc <= 1){
printf("Test the concurrence of state-threads!\n");
printf("Usage: %s <sthread_count>\n");
printf("eg. %s 10000\n", argv[0], argv[0]);
return -1;
}
if(st_init() < 0){
printf("st_init error!");
return -1;
}
int i;
int count = atoi(argv[1]);
for(i = 1; i <= count; i++){
if(st_thread_create(do_calc, (void*)i, 0, 0) == NULL){
printf("st_thread_create error!");
return -1;
}
}
st_thread_exit(NULL);
return 0;
}
```
First, please build [State Threads](https://github.com/ossrs/state-threads#linux-usage) on Linux as such:
```bash
mkdir -p ~/git && cd ~/git
git clone -b srs https://github.com/ossrs/state-threads.git
make linux-debug
```
Then, save the code as `huge_threads.c` and build:
```bash
gcc -I~/git/state-threads/obj -g huge_threads.c ~/git/state-threads/obj/libst.a -o huge_threads
```
Run the example:
```bash
./huge_threads 10000
10K report:
10000 threads, running on 1 CPU 512M machine,
CPU 6%, MEM 8.2% (~42M = 42991K = 4.3K/thread)
30K report:
30000 threads, running on 1CPU 512M machine,
CPU 3%, MEM 24.3% (4.3K/thread)
```
Another example is [SRS](https://github.com/ossrs/srs), which is a simple, high efficiency and realtime video server,
supports RTMP, WebRTC, HLS, HTTP-FLV, SRT, MPEG-DASH and GB28181.
## Cloud Service
At SRS, our goal is to establish a non-profit, open-source community dedicated to creating an all-in-one,
out-of-the-box, open-source video solution for live streaming and WebRTC online services.
Additionally, we offer a [Cloud](../cloud) service for those who prefer to use cloud service instead of building from
scratch. Our cloud service features global network acceleration, enhanced congestion control algorithms,
client SDKs for all platforms, and some free quota.
To learn more about our cloud service, click [here](../cloud).
## Contact
Welcome for more discussion at [discord](https://discord.gg/bQUPDRqy79).
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/blog-en/22-05-16-State-Threads-for-Internet-Applications)

206
trunk/3rdparty/srs-docs/blog/2023-03-07-Lets-Do-H265-Live-Streaming.md vendored Normal file
View File

@ -0,0 +1,206 @@
---
slug: lets-do-h265-live-streaming
title: SRS - H.265 Live Streaming Saving 50% Cost
authors: []
tags: [architecture, hevc, h265, codec, live]
custom_edit_url: null
---
# Let's Do H265 Live Streaming
> Written by [Winlin](https://github.com/winlinvip), [runner365](https://github.com/runner365), [yinjiaoyuan](https://github.com/yinjiaoyuan), [PieerePi](https://github.com/PieerePi), [qichaoshen82](https://github.com/qichaoshen82), [ZSC714725](https://github.com/ZSC714725), [bluestn](https://github.com/bluestn), [mapengfei53](https://github.com/mapengfei53), [chundonglinlin](https://github.com/chundonglinlin), [duiniuluantanqin](https://github.com/duiniuluantanqin), [panda1986](https://github.com/panda1986)
SRS 6.0 supports HEVC(H.265), for RTMP, HTTP-FLV, HTTP-TS, HLS, MPEG-DASH, WebRTC(Safari), DVR FLV, DVR MP4 and WordPress SrsPlayer, etc.
Generally, H.265 is 50% off than H.264, so you only need to pay 50% bills if H.265.
<!--truncate-->
Now, you're able to use HEVC(H.265) in live streaming.
## Why Important?
H.265 uses less bandwidth than H.264, which means lower bandwidth cost, or higher quality in same bandwidth.
Furthermore, if want 8K live streaming, you must use H.265, because H.264 doesn't support 8K resolution.
Please note that there are still some traps for H.265 live streaming.
## Status of H.265
The status of H.265, for different use scenarios.
Part 1, publisher or encoder for H.265.
* [x] Publish SRT stream by FFmpeg.
* [x] Publish SRT stream by OBS.
* [x] Publish RTMP stream by FFmpeg, patch is [here](https://github.com/ossrs/srs/issues/465#ffmpeg-tools)
* [x] Push WebRTC by Safari, should be enabled by user.
* [ ] Not supported: Chrome/Firefox push WebRTC stream.
* [ ] Not supported: OBS publish RTMP stream.
Part 2, play stream by FFmpeg/ffplay for H.265.
* [x] Play HTTP-TS by FFmpeg.
* [x] Play HLS by FFmpeg.
* [x] Play MPEG-DASH by FFmpeg.
* [x] Play SRT by FFmpeg.
* [x] Play HTTP-TS by ffplay.
* [x] Play HLS by ffplay.
* [x] Play MPEG-DASH by ffplay.
* [x] Play SRT by ffplay.
* [x] Play RTMP by FFmpeg, with [patch](https://github.com/ossrs/srs/issues/465#ffmpeg-tools).
* [x] Play HTTP-FLV by FFmpeg, with [patch](https://github.com/ossrs/srs/issues/465#ffmpeg-tools).
* [x] Play RTMP by fflay, with [patch](https://github.com/ossrs/srs/issues/465#ffmpeg-tools).
* [x] Play HTTP-FLV by ffplay, with [patch](https://github.com/ossrs/srs/issues/465#ffmpeg-tools).
Part 3, play stream by H5 MSE for H.265.
* [x] Play HTTP-TS by Chrome, using mpegts.js.
* [x] Play HTTP-FLV by Chrome, using mpegts.js.
* [x] Play WebRTC stream by Safari, should be enabled by user.
* [ ] Not supported: Play HLS by [hls.js](https://github.com/video-dev/hls.js).
* [ ] Not supported: Play MPEG-DASH by [dash.js](https://github.com/Dash-Industry-Forum/dash.js).
* [ ] Not supported: Play WebRTC by Chrome/Firefox.
Part 4, play stream by VLC for H.265.
* [x] Play HTTP-TS by VLC.
* [x] Play SRT by VLC.
* [x] Play HLS by VLC.
* [x] Play MPEG-DASH by VLC.
* [ ] Not supported: Play RTMP by VLC.
* [ ] Not supported: Play HTTP-FLV by VLC.
Part 5, other features for H.265.
* [x] DVR to FLV or MP4 file.
* [x] Parse HEVC metadata for HTTP-API.
* [x] Black box test support HEVC.
* [x] Patch FFmpeg in SRS dev-docker.
* [x] Support HEVC for [WordPress plugin SrsPlayer](https://github.com/ossrs/WordPress-Plugin-SrsPlayer).
* [ ] Not supported: Update [Oryx](https://github.com/ossrs/oryx) for HEVC.
* [ ] Not supported: Edge server supports publish HEVC stream to origin.
* [ ] Not supported: Edge server supprots play HEVC stream from origin.
* [ ] Not supported: HTTP Callback takes HEVC metadata.
* [ ] Not supported: Prometheus Exporter supports HEVC metadata.
* [ ] Not supported: Improve coverage for HEVC.
* [ ] Not supported: Supports benchmark for HEVC by [srs-bench](https://github.com/ossrs/srs-bench).
If native iOS or Android application, please use FFmpeg.
Appreciate the patch for [Chrome 105](https://zhuanlan.zhihu.com/p/541082191) to support HEVC for MSE, it makes the HEVC
live streaming possible.
MSE HEVC requires GPU hardware decoding, please open `chrome://gpu` then search `hevc`, and it should work if matched.
## Usage: Live
This is an example fo H.265 live streaming.
First, run SRS in docker:
```bash
docker run --rm -it -p 1935:1935 -p 8080:8080 ossrs/srs:6 \
./objs/srs -c conf/docker.conf
```
Use FFmepg to publish HEVC over RTMP, see [FFmpeg Tools](#ffmpeg-tools):
```bash
# For macOS
docker run --rm -it ossrs/srs:encoder ffmpeg -stream_loop -1 -re -i doc/source.flv \
-acodec copy -vcodec libx265 -f flv rtmp://host.docker.internal/live/livestream
# For linux
docker run --net=host --rm -it ossrs/srs:encoder ffmpeg -stream_loop -1 -re -i doc/source.flv \
-acodec copy -vcodec libx265 -f flv rtmp://127.0.0.1/live/livestream
```
> Note: Please change the ip `host.docker.internal` to your SRS's IP.
Done, please open links bellow in browser:
* [http://localhost:8080/live/livestream.flv](http://localhost:8080/players/srs_player.html?stream=livestream.flv)
* `http://localhost:8080/live/livestream.m3u8`
> Note: Please use VLC or ffplay to play HLS, because hls.js doesn't support it.
Please follow wiki of SRS to use other protocols.
## Usage: WebRTC
Right now, at 2023.03, only Safari support HEVC over WebRTC, neither Chrome nor Firefox supports it.
And, you should enable the HEVC for Safari by clicking `Develop > Experimental Features > WebRTC H265 codec`.
For detail usage, please follow [#465](https://github.com/ossrs/srs/issues/465#safari-webrtc).
Beside HEVC, WebRTC has better support for AV1, Safari/Chrome/Firefox supports AV1, please read [#1070](https://github.com/ossrs/srs/issues/1070) for detail.
Note that MSE doesn't support AV1.
> Note: Media Source Extensions (MSE) is H5 API for media streaming, on which mpegts.js, hls.js and dash.js bases. Please see [MDN: MSE](https://developer.mozilla.org/en-US/docs/Web/API/Media_Source_Extensions_API).
## FFmpeg Patch
FFmpeg 6 has supported HEVC over RTMP, if you want to build from code, please see
[FFmpeg Tools](../docs/v6/doc/hevc#ffmpeg-tools#ffmpeg-tools).
SRS dev-docker already patched FFmpeg, ffplay and ffprobe, so user can use it:
```bash
# For macOS
docker run --rm -it ossrs/srs:encoder ffmpeg -stream_loop -1 -re -i doc/source.flv \
-acodec copy -vcodec libx265 -f flv rtmp://host.docker.internal/live/livestream
# For linux
docker run --net=host --rm -it ossrs/srs:encoder ffmpeg -stream_loop -1 -re -i doc/source.flv \
-acodec copy -vcodec libx265 -f flv rtmp://127.0.0.1/live/livestream
```
Please see [FFmpeg Tools](../docs/v6/doc/hevc#ffmpeg-tools#ffmpeg-tools) for detail.
## Known Issues
The known issues for HEVC live streaming:
1. Safari HEVC WebRTC doesn't support converting to other protocols, such as RTMP.
2. Chrome/Firefox WebRTC doesn't support HEVC, no plan also.
3. All browsers support MSE except iOS, and note that HEVC MSE requires GPU hardware decoding.
4. For H5 player, only mpegts.js supports HEVC, neither hls.js nor dash.js support it.
On some use scenario, HEVC is available now, please evaluate it by yourself.
## Cloud Service
At SRS, our goal is to establish a non-profit, open-source community dedicated to creating an all-in-one,
out-of-the-box, open-source video solution for live streaming and WebRTC online services.
Additionally, we offer a [Cloud](../cloud) service for those who prefer to use cloud service instead of building from
scratch. Our cloud service features global network acceleration, enhanced congestion control algorithms,
client SDKs for all platforms, and some free quota.
To learn more about our cloud service, click [here](../cloud).
## Thanks
There are some developers that contributed to SRS HEVC feature:
* [runner365](https://github.com/runner365) The first patch for HEVC for RTMP, HLS and SRT.
* [yinjiaoyuan](https://github.com/yinjiaoyuan) Bug fixed.
* [PieerePi](https://github.com/PieerePi) Bug fixed.
* [qichaoshen82](https://github.com/qichaoshen82) Bug fixed.
* [ZSC714725](https://github.com/ZSC714725) Bug fixed.
* [bluestn](https://github.com/bluestn) Support HEVC for MP4 and GB28181.
* [mapengfei53](https://github.com/mapengfei53) Support HEVC for MP4.
* [chundonglinlin](https://github.com/chundonglinlin) Support HEVC for SRT.
* [duiniuluantanqin](https://github.com/duiniuluantanqin) Support HEVC for GB28181.
* [panda1986](https://github.com/panda1986) Supprot HEVC for WordPress SrsPlayer.
Really appreciated for [mpegts.js](https://github.com/xqq/mpegts.js), which supports HEVC for HTTP-FLV and HTTP-TS.
## Contact
Welcome for more discussion at [discord](https://discord.gg/bQUPDRqy79).
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/blog-en/23-03-07-Lets-Do-H265-Live-Streaming)

121
trunk/3rdparty/srs-docs/blog/2023-04-02-Secure-Your-HTTP-API.md vendored Normal file
View File

@ -0,0 +1,121 @@
---
slug: secure-your-http-api
title: SRS - How to Secure Your HTTP API
authors: []
tags: [api, security, http]
custom_edit_url: null
---
# How to Secure Your HTTP API
After you have built your SRS server, you can use HTTP API to access it by SRS console or other HTTP clients.
However, you should secure your HTTP API to prevent unauthorized access.
This article describes how to secure your HTTP API.
<!--truncate-->
## Usage
First of all, please upgrade SRS to 5.0.152+ or 6.0.40+, which supports HTTP API security.
Then, please enable the HTTP basic authentication by configuration `http_api.auth`:
```bash
# conf/http.api.auth.conf
http_api {
enabled on;
listen 1985;
auth {
enabled on;
username admin;
password admin;
}
}
```
Now, start SRS with the config:
```bash
./objs/srs -c conf/http.api.auth.conf
```
Or set up the username and password by environment variables:
```bash
env SRS_HTTP_API_ENABLED=on SRS_HTTP_SERVER_ENABLED=on \
SRS_HTTP_API_AUTH_ENABLED=on SRS_HTTP_API_AUTH_USERNAME=admin SRS_HTTP_API_AUTH_PASSWORD=admin \
./objs/srs -e
```
Now, you can access the following urls to verify it:
* Prompt for username and password: [http://localhost:1985/api/v1/versions](http://localhost:1985/api/v1/versions)
* URL with authentication: [http://admin:admin@localhost:1985/api/v1/versions](http://admin:admin@localhost:1985/api/v1/versions)
To clean up the username and password, you can access the HTTP API with the username only:
* [http://admin@localhost:1985/api/v1/versions](http://admin@localhost:1985/api/v1/versions)
> Note: Please note that we only secure the HTTP API, neither the HTTP server nor the WebRTC HTTP apis.
## SRS Console
SRS console is a web application to manage your SRS server.
When SRS server started, you can access the SRS console by the URL:
[http://localhost:8080/console/](http://localhost:8080/console/)
If you enable the HTTP API authentication, you should use URL with username and password to access the SRS console:
[http://admin:admin@localhost:8080/console/](http://admin:admin@localhost:8080/console/)
Or, the browser will prompt for username and password.
## For SRS 4.0
SRS 4.0 does not support HTTP API authentication, however there is a workaround to secure your HTTP API.
You can use the nginx to proxy the HTTP API, and enable the HTTP basic authentication by nginx.
Or write a Go HTTP proxy for SRS HTTP API.
```text
Browser ---HTTP-with-Authentication---> Nginx ---HTTP---> SRS 4.0
```
In this solution, you should also change the listen of SRS HTTP API to lo:
```bash
http_api {
enabled on;
listen 127.0.0.1:1985;
}
```
So that the HTTP API is only accessible by the localhost proxy server.
## About WebRTC API Security
SRS doesn't support HTTP API authentication for WebRTC,
instead, you should use the HTTP callback to verify the client.
Please see [WebRTC HTTP Callback](../docs/v5/doc/http-callback) and [Token Authentication](../docs/v5/doc/drm#token-authentication) for more details.
## Cloud Service
At SRS, our goal is to establish a non-profit, open-source community dedicated to creating an all-in-one,
out-of-the-box, open-source video solution for live streaming and WebRTC online services.
Additionally, we offer a [Cloud](../cloud) service for those who prefer to use cloud service instead of building from
scratch. Our cloud service features global network acceleration, enhanced congestion control algorithms,
client SDKs for all platforms, and some free quota.
To learn more about our cloud service, click [here](../cloud).
## Conclusion
GitHub Copilot and I wrote this article.
The code of this feature was written by SRS developers and GitHub Copilot.
## Contact
Welcome for more discussion at [discord](https://discord.gg/bQUPDRqy79).
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/blog-en/23-04-02-Secure-Your-HTTP-API)

92
trunk/3rdparty/srs-docs/blog/2023-04-08-Push-HEVC-via-RTMP-by-OBS.md vendored Normal file
View File

@ -0,0 +1,92 @@
---
slug: push-hevc-via-rtmp-by-obs
title: SRS - How to Push HEVC via RTMP by OBS
authors: []
tags: [hevc, rtmp, obs, live]
custom_edit_url: null
---
# How to Push HEVC via RTMP by OBS
> Written by [Winlin](https://github.com/winlinvip), [chundonglinlin](https://github.com/chundonglinlin)
OBS 29.1 supports HEVC via RTMP, so you can do HEVC live stream by OBS and SRS now.
There is a new specification for HEVC via RTMP, please see [Enhanced RTMP](https://github.com/veovera/enhanced-rtmp).
This specification defines a new codec ID for HEVC, which uses fourCC `hvc1`,
both OBS and SRS support it.
<!--truncate-->
> Note: Please see [#3495](https://github.com/ossrs/srs/pull/3495) and [#3464](https://github.com/ossrs/srs/issues/3464) for details.
Please note that SRS 6.0 had already HEVC(H.265) support for SRT, HTTP-TS, HLS, MPEG-DASH and WebRTC(Safari),
please refer to [H.265 Live Streaming Saving 50% Cost](./2023-03-07-Lets-Do-H265-Live-Streaming.md).
## Prerequisites
To use HEVC via RTMP, you must:
* Update SRS to 6.0.42+, or use the latest develop branch.
* Use OBS 29.1+. You can download the beta version from [here](https://github.com/obsproject/obs-studio/releases).
* For H5 player, SRS has already upgraded the [mpegjs.js](https://github.com/xqq/mpegts.js) to 1.7.3+
* FFmpeg 6 support HEVC via RTMP.
## Usage
First, run SRS in docker:
```bash
docker run --rm -it -p 1935:1935 -p 8080:8080 ossrs/srs:6 \
./objs/srs -c conf/hevc.flv.conf
```
Next, start OBS with the following settings in the `Settings > Stream` tab:
* Server: `rtmp://localhost/live`
* Stream Key: `livestream`
* Encoder: Please select the HEVC hardware encoder.
> Note: Please note that the HEVC software encoder is too slow to encode the video, so it causes the video laggy.
![](/img/blog-2023-04-08-001.png)
![](/img/blog-2023-04-08-002.png)
Now, open the web page to play the HTTP-FLV live stream:
[http://localhost:8080/live/livestream.flv](http://localhost:8080/players/srs_player.html).
You can also play the HLS, DASH or HTTP-TS live stream, after you enable the HLS or HTTP-TS in the config file.
## What's Next
Although SRS supports HEVC via WebRTC for Safari, but SRS doesn't support converting the HEVC via RTMP to WebRTC.
We're working on it now.
The OBS HEVC software encoder is too slow to encode the video, so it causes the video laggy.
## Cloud Service
At SRS, our goal is to establish a non-profit, open-source community dedicated to creating an all-in-one,
out-of-the-box, open-source video solution for live streaming and WebRTC online services.
Additionally, we offer a [Cloud](../cloud) service for those who prefer to use cloud service instead of building from
scratch. Our cloud service features global network acceleration, enhanced congestion control algorithms,
client SDKs for all platforms, and some free quota.
To learn more about our cloud service, click [here](../cloud).
## Conclusion
In this article, we introduced how to push HEVC via RTMP by OBS.
Although there are still some works to do, it's already a big step for HEVC live streaming.
We wrote this article with the help of GitHub Copilot.
## Contact
Welcome for more discussion at [discord](https://discord.gg/bQUPDRqy79).
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/blog-en/23-04-08-Push-HEVC-via-RTMP-by-OBS)

96
trunk/3rdparty/srs-docs/blog/2023-05-16-Stream-YouTube-Using-Web-Browser.md vendored Normal file
View File

@ -0,0 +1,96 @@
---
slug: how-to-stream-youtube-using-a-web-browser
title: SRS - How to Stream YouTube Using a Web Browser
authors: []
tags: [youtube, rtmp, rtmps, webrtc, srs, ffmpeg]
custom_edit_url: null
---
# How to Live Streaming on YouTube via RTMP or RTMPS Using a Web Browser
> Written by [Winlin](https://github.com/winlinvip) and GPT4
While Open Broadcaster Software (OBS) is a widely used solution for live-streaming to YouTube via RTMP or RTMPS, there is an alternative approach that leverages a web browser.
This method involves streaming your camera using WebRTC within a webpage, then employing Simple Realtime Server (SRS) to convert WebRTC to RTMP, and using FFmpeg to publish the RTMP stream to YouTube. For those who prefer RTMPS, FFmpeg can be utilized to extract the stream from SRS via RTMP, transcode it to RTMPS, and subsequently publish it to YouTube.
<!--truncate-->
## Step 1: Setting Up SRS
First, obtain SRS by cloning it from the GitHub repository:
```bash
git clone https://github.com/ossrs/srs.git
```
Then, compile SRS by executing:
```bash
./configure && make
```
Lastly, launch SRS with the command:
```bash
./objs/srs -c conf/rtc2rtmp.conf
```
To confirm the successful installation, access [http://localhost:8080](http://localhost:8080) in your web browser.
## Step 2: Streaming WebRTC to SRS
Open the webpage [http://localhost:8080/players/whip.html](http://localhost:8080/players/whip.html) to transmit your camera stream to SRS via WebRTC.
![](/img/blog-2023-05-16-001.png)
To preview the RTMP stream, utilize VLC to play `rtmp://localhost/live/livestream`.
## Step 3: Routing RTMP to YouTube
Access the YouTube live-streaming dashboard at [https://youtube.com/livestreaming/dashboard](https://youtube.com/livestreaming/dashboard).
Acquire the stream server (e.g., `rtmp://a.rtmp.youtube.com/live2`) and stream key (e.g., `9xxx-8yyy-3zzz-3iii-7jjj`).
![](/img/blog-2023-05-16-002.png)
Use FFmpeg to extract the RTMP stream from SRS and forward it to YouTube with this command:
```bash
ffmpeg -i rtmp://localhost/live/livestream -c copy \
-f flv rtmp://a.rtmp.youtube.com/live2/9xxx-8yyy-3zzz-3iii-7jjj
```
![](/img/blog-2023-05-16-003.png)
## Step 4: Routing RTMPS to YouTube
To transmit the stream via RTMPS, modify the RTMP URL from `rtmp://a.rtmp.youtube.com/live2/9xxx-8yyy-3zzz-3iii-7jjj` to the RTMPS URL, such as `rtmps://a.rtmp.youtube.com:443/live2/9xxx-8yyy-3zzz-3iii-7jjj`.
```bash
ffmpeg -i rtmp://localhost/live/livestream -c copy \
-f flv rtmps://a.rtmp.youtube.com:443/live2/9xxx-8yyy-3zzz-3iii-7jjj
```
## Cloud Service
At SRS, our goal is to establish a non-profit, open-source community dedicated to creating an all-in-one,
out-of-the-box, open-source video solution for live streaming and WebRTC online services.
Additionally, we offer a [Cloud](../cloud) service for those who prefer to use cloud service instead of building from
scratch. Our cloud service features global network acceleration, enhanced congestion control algorithms,
client SDKs for all platforms, and some free quota.
To learn more about our cloud service, click [here](../cloud).
## Conclusion
By adhering to these instructions, you can effectively live stream to YouTube via RTMP or RTMPS using a web browser.
This technique offers a practical alternative to OBS, enabling you to harness the power of WebRTC, SRS, and FFmpeg
for a smooth and efficient streaming experience.
## Contact
Welcome for more discussion at [discord](https://discord.gg/bQUPDRqy79).
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/blog-en/2023-05-16-Stream-YouTube-Using-Web-Browser)

174
trunk/3rdparty/srs-docs/blog/2023-05-22-Unlock-the-Power-of-SRS-Real-World-Use-Cases.md vendored Normal file
View File

@ -0,0 +1,174 @@
---
slug: unlock-the-power-of-srs-real-world-use-cases
title: SRS - Unlock the Power of SRS, Real-World Use Cases.
authors: []
tags: [srs, use-case]
custom_edit_url: null
---
Discover SRS, the all-in-one open-source media server solution for seamless live streaming, content creation, and AI integration, simplifying broadcasting across platforms like YouTube, Facebook, Twitch, and TikTok.
<!--truncate-->
You can also watch the video on YouTube: [Unlock the Power of SRS: Real-World Use Cases and Boosting Your Business with Simple Realtime Server.](https://youtu.be/WChYr6z7EpY)
## Introduction
![](/img/blog-2023-05-22-001.png)
Hello, I'm Winlin!
I founded SRS, which stands for Simple Realtime Server, or "SARS" for short.
SRS is an easy-to-use, efficient, real-time video server that supports various protocols like RTMP, WebRTC, HLS, HTTP-FLV, SRT, and MPEG-DASH.
In this video, I'll talk about some common ways people use SRS.
## Project Compare, an open-source media gateway server.
![](/img/blog-2023-05-22-002.png)
There are several well-known open-source media servers out there, like NginxRTMP for live streaming, Janus and Mediasoup for WebRTC, and of course, SRS for everything.
We started the SRS project back in 2013, initially supporting RTMP and HLS with latencies of 1-3 seconds and 5-10 seconds, respectively. SRS also worked with HTTP-FLV and HTTP-TS, which are similar to RTMP.
In 2020, we expanded our community and added support for WebRTC and SRT, allowing for sub-second latency. SRT latency is around 300-500 ms, while WebRTC latency is between 80-200 ms.
SRS acts as a media gateway, converting between RTMP, SRT, and WebRTC, so you don't need three separate servers.
We've also updated our documentation and website, which you can check out at ossrs.io. SRS has come a long way, but there's still more to do. We're building a global community on Discord, helping many developers and earning their gratitude.
Now, let me introduce you to some of the ways people use SRS.
## Live Origin Cluter, converting streams is essential.
![](/img/blog-2023-05-22-003.png)
The first use case is the origin cluster, which is a group of origin servers.
An origin server is a fundamental and essential server that works as an SRS gateway, receiving and converting streams from publishers.
Unlike Edge or Proxy servers that scale out the origin server, the origin server is critical. By default, an SRS server acts as an origin server, serving as a streaming hub that collects streams from various publishers.
You can send live streams via RTMP, SRT, or WebRTC to the origin server, which then converts them to HLS, HTTP-FLV, RTMP, SRT, and WebRTC.
You can also pull streams from the origin server, transcode, DVR, or forward them to other servers, and even deliver them to a CDN or create a CDN using SRS.
In short, this is a key feature of SRS.
## Vrtual Live Streaming, boosting business with virtual live streaming.
![](/img/blog-2023-05-22-004.png)
Are you a video blogger with lots of high-quality videos? Have you thought about setting up a live room to grow your business?
With Oryx, you can easily turn your video files into live streams and engage your audience without having to live-stream yourself.
Oryx lets you create virtual live-streaming 24/7 in just three steps: upload your videos, set up a live room (like a YouTube live room), and copy-paste the stream key to start live streaming.
It's easy, doesn't require any media streaming expertise, and Oryx can even restream your live streams to other platforms for free since it's open source.
## Video Blogger, empower video bloggers with live streaming.
![](/img/blog-2023-05-22-005.png)
If you own a WordPress site, you may have considered adding live streaming, which was previously not possible due to WordPress's limitations.
But now, with the SRS Player WordPress plugin, you can incorporate live streaming using HTTP-FLV, HLS, and WebRTC, as well as video-on-demand streaming via HTTP-MP4.
Simply embed the live-streaming player with a WordPress shortcode, which you can find in the Oryx console.
This powerful plugin makes live streaming accessible to everyone, even in WooCommerce, a widely-used e-commerce plugin for WordPress, showcasing the impact of open source technology.
## Unity WebRTC Streaming, make Unity work with WebRTC SFU.
![](/img/blog-2023-05-22-006.png)
SRS Unity shows how Unity developers can integrate live streaming with a WebRTC SDK that's compatible with SRS.
You can send the Unity Camera feed to SRS and play the stream in a browser, retrieve the stream from SRS and display it in a Unity game, or enable multiple Unity games to interact using WebRTC.
In this scenario, SRS serves as a WebRTC SFU server, which is essential for WebRTC Unity clients in a production setting.
WebRTC P2P isn't reliable in real-world situations, but an SFU server provides improved network quality, scalability, and support for WebRTC-RTMP conversion.
Plus, you can record WebRTC streams as video-on-demand files, and SRS works with the Unity WebRTC SDK, Unity AR, and VR.
## Remote Broadcasting & Content Creator, enables remote content creation in broadcasting.
![](/img/blog-2023-05-22-007.png)
SRS can be employed in the broadcast industry to develop a remote content creation system.
The original camera feed is sent to SRS and accessed remotely by an editor, who adds watermarks and logos to the edited stream.
With SRT, latency is around 300-500 ms, enabling real-time editing and switching between camera feeds.
Low latency ensures all streams are synchronized, making it a powerful tool for remote content creation.
You can edit from a distance without being on location and produce multiple streams at once, even generating HDR content using HEVC or AV1.
## Video & Audio AI Process, real-time AI processing makes more possibilities.
![](/img/blog-2023-05-22-008.png)
SRS is also useful in the AI field for video and audio processing. Receive streams from SRS and process them with AI models, like using deepfake for face swapping.
SRS is compatible with AI models for audio processing, as shown by the srs-k2 project, which demonstrates how to use SRS with k2-fsa for ASR (Kaldi 2.0, a popular open-source ASR toolkit).
The end-to-end latency of srs-k2 is around 400-800 ms, and it can be used in WebRTC for multi-language real-time communication systems. This allows for conversations with people in various languages and integration with the AIGC system.
## HEVC/AV1 for AV/AR/8K, reduce the cost significantly.
![](/img/blog-2023-05-22-009.png)
To cut your live-streaming expenses by half, think about using HEVC or AV1.
AV1 is a new, open-source, royalty-free video codec, but its hardware decoder isn't as common as HEVC. However, it's quickly gaining traction and looks promising for the future.
HEVC is a widely adopted codec in the industry, supported by OBS through RTMP and SRT. Send the HEVC stream to SRS using OBS, and play the stream with H5 player, mpegjs.js, VLC, or ffplay.
HEVC or AV1 is essential for 8K live-streaming and is becoming popular in the VR/AR field.
## Restream to Multiple Platforms, restream to multiple platforms without extra cost.
![](/img/blog-2023-05-22-010.png)
Do you want to broadcast your live streams on multiple platforms like YouTube, Facebook, Twitch, and TikTok?
The Oryx simplifies this task and doesn't use up your bandwidth since it takes care of the restreaming for you.
## SRS Prometheus Exporter, make SRS an operatable online product.
![](/img/blog-2023-05-22-011.png)
Prometheus, a well-known open-source monitoring system, is natively supported by SRS through its exporter, letting you keep an eye on the SRS server.
Visualize metrics with Grafana, and look forward to Prometheus and Grafana being integrated into the Oryx in the future.
To back the project, think about donating via OpenCollective.
## Cloud Service
At SRS, our goal is to establish a non-profit, open-source community dedicated to creating an all-in-one,
out-of-the-box, open-source video solution for live streaming and WebRTC online services.
Additionally, we offer a [Cloud](../cloud) service for those who prefer to use cloud service instead of building from
scratch. Our cloud service features global network acceleration, enhanced congestion control algorithms,
client SDKs for all platforms, and some free quota.
To learn more about our cloud service, click [here](../cloud).
## Support, contributions and donations are welcome.
![](/img/blog-2023-05-22-012.png)
Thanks for watching this video on SRS (Simple Realtime Server). If you found it helpful, please give it a thumbs up
and subscribe to our channel for more short videos like this. See you in the next one!
## Contact
Welcome for more discussion at [discord](https://discord.gg/bQUPDRqy79).
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/blog-en/2023-05-22-Unlock-the-Power-of-SRS-Real-World-Use-Cases)

105
trunk/3rdparty/srs-docs/blog/2023-06-15-Experience-Ultra-Low-Latency-Live-Streaming-with-OBS-WHIP.md vendored Normal file
View File

@ -0,0 +1,105 @@
---
slug: Experience-Ultra-Low-Latency-Live-Streaming-with-OBS-WHIP
title: SRS - Experience Ultra-Low Latency Live Streaming with OBS WHIP!
authors: []
tags: [srs, obs, whip]
custom_edit_url: null
---
# Ultra-Low Latency Streaming with OBS WHIP: New Features & Stable Performance!
OBS now features WHIP support, with the patch having been recently merged. This enables
various new functions and possibilities with OBS WHIP, as the latency drops from 1 second
to 200 milliseconds.
Without OBS WHIP, you can employ RTMP+WebRTC for live streaming, which results in a latency
of approximately 500ms. However, by using OBS WHIP, you can achieve low-latency live
streaming with a latency of around 200ms.
<!--truncate-->
Furthermore, even in situations with poor network connections or when streaming over the
internet, OBS WHIP maintains a consistently low and stable latency.
In this tutorial, I will demonstrate how to effortlessly utilize OBS WHIP with SRS in just
three simple steps.
The Oryx also supports OBS WHIP, enabling you to establish a WHIP service with just one click.
Refer to [Effortlessly Create a Public Internet WHIP Service for OBS](./2023-12-12-Oryx-OBS-WHIP-Service.md).
You can also watch the video on YouTube: [Ultra Low Latency Streaming with OBS WHIP](https://youtu.be/SqrazCPWcV0)
## Prerequisites
Please install the following software before proceeding:
- [OBS Studio](https://obsproject.com/download)
> Note: OBS WHIP has been merged into the master branch and will be released in OBS 30.
> You can download it from [here](https://github.com/obsproject/obs-studio/releases/tag/30.0.0-rc1).
## Step 1: Run SRS
Run the following command to start SRS:
```bash
CANDIDATE="192.168.1.10"
docker run --rm -it -p 1935:1935 -p 1985:1985 -p 8080:8080 \
--env CANDIDATE=$CANDIDATE -p 8000:8000/udp \
ossrs/srs:5 ./objs/srs -c conf/rtmp2rtc.conf
```
> Note: Please set the CANDIDATE to your own IP. About CANDIDATE, please read [CANDIDATE](../docs/v5/doc/webrtc#config-candidate)
For configuration details, refer to [this post](../docs/v5/doc/getting-started#webrtc-for-live-streaming).
## Step 2: Run OBS
Open OBS and click `Settings` to configure the following:
1. Open OBS and click **Settings**.
1. Click **Stream** on the left sidebar.
1. Select `WHIP` for **Service**.
1. Set the **Server** to `http://localhost:1985/rtc/v1/whip/?app=live&stream=livestream`.
1. Click **OK** to save the settings.
1. Click **Start Streaming** to start streaming.
1. If the latency is large, setup the OBS Output by: For OBS encoder, select the x264 encoder and in the advanced settings, set the GOP (Keyframe interval) to 1 s. Choose Preset as fast, Profile as baseline, and Tune as zerolatency.
![](/img/blog-2023-06-15-011.png)
## Step 3: Play the Stream
Open the following URL in your browser to play the stream:
[http://localhost:8080/players/whep.html](http://localhost:8080/players/whep.html)
![](/img/blog-2023-06-15-012.png)
## Cloud Service and Support
I tested the TRTC cloud service and it works great with OBS WHIP. If you're looking for
a WHIP cloud service that has 24/7 support, I definitely suggest trying TRTC. To see a
demo, click [here](https://tencent-rtc.github.io/obs-trtc/).
## Cloud Service
At SRS, our goal is to establish a non-profit, open-source community dedicated to creating an all-in-one,
out-of-the-box, open-source video solution for live streaming and WebRTC online services.
Additionally, we offer a [Cloud](../cloud) service for those who prefer to use cloud service instead of building from
scratch. Our cloud service features global network acceleration, enhanced congestion control algorithms,
client SDKs for all platforms, and some free quota.
To learn more about our cloud service, click [here](../cloud).
## Conclusion
In this tutorial, we explored the ultra-low latency live streaming capabilities of OBS WHIP and
demonstrated how to set it up with SRS in just three simple steps. OBS WHIP significantly reduces
latency, making it an excellent option for low-latency live streaming.
## Contact
If you're interested in discussing SRS, feel free to join us on [Discord](https://discord.gg/yZ4BnPmHAd).
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/blog-en/2023-06-15-Experience-Ultra-Low-Latency-Live-Streaming-with-OBS-WHIP)

116
trunk/3rdparty/srs-docs/blog/2023-08-29-Oryx-Ensuring-Authentication-for-Live-Streaming-Publishing.md vendored Normal file
View File

@ -0,0 +1,116 @@
---
slug: Ensuring-Authentication-in-Live-Streaming-Publishing
title: Oryx - Ensuring Authentication in Live Streaming Publishing
authors: []
tags: [live streaming, security, authentication]
custom_edit_url: null
---
# Ensuring Authentication in Live Streaming Publishing
In today's digital age, live streaming has become increasingly popular, with platforms like YouTube and
Twitch offering users the ability to broadcast their content in real-time. However, with this growing
popularity comes the need for enhanced security and authentication measures to protect both streamers
and viewers. In this comprehensive guide, we will delve into the importance of security and authentication
in live streaming, discuss the Oryx solution for secure publishing, and provide a step-by-step guide
on setting up the Oryx for your own live streaming service.
<!--truncate-->
## The Importance of Authentication in Live Streaming
When publishing a live stream on platforms like YouTube or Twitch, users need to obtain a stream key
and use broadcasting software like OBS to publish the live stream to the platform. Maintaining the
confidentiality of your stream key is essential, as anyone who obtains it can stream on your behalf,
potentially publishing prohibited content and resulting in your account being blocked by the platform.
For those looking to build their own live streaming service, ensuring security and authentication
becomes even more critical. This is where the Oryx comes in, offering a solution for secure
publishing through the use of a publish secret.
However, an overly complex security design can also lead to confusion and difficulty for users,
making the streaming platform challenging to use. Therefore, it is crucial to implement a secure
yet straightforward solution for authenticating live streaming publishing.
## The Oryx Solution for Secure Publishing
The Oryx is a powerful tool that helps users build their own live streaming service with enhanced
security and authentication features. By utilizing a publish secret, the Oryx ensures that only
authorized users can publish streams, preventing unauthorized access and protecting your content.
To set up the Oryx for secure publishing, follow these steps:
1. Create an Oryx with just one click. For detailed instructions, visit [How to Setup a Video Streaming Service by 1-Click](./2022-04-09-Oryx-Tutorial.md)
1. Upon creation, the Oryx will automatically generate a publish secret, such as `5181a08ee6eab86597e913e1f9e4c294`. You can set it from `System / Authentication / Update Stream Secret`.
1. Copy the OBS settings from `Scenarios / Streaming`, including the Server and StreamKey. For example, the Server might be `rtmp://135.98.31.15/live/`, and the StreamKey could be `livestream?secret=5181a08ee6eab86597e913e1f9e4c294`.
1. Open the HLS player to play the stream, such as `http://135.98.31.15/live/livestream.m3u8`.
For example, you will get the following URLs:
* Publish URL: `rtmp://135.98.31.15/live/livestream?secret=5181a08ee6eab86597e913e1f9e4c294`
* Play URL: `http://135.98.31.15/live/livestream.m3u8`
Note that the secret is not included in the play stream URL, preventing viewers from knowing the publish
secret and ensuring they can only watch the stream, not publish it.
## Supporting Multiple Streams
The Oryx allows users to support multiple streams by simply changing the resource name (stream name) as
needed. For example, change stream name from `livestream` to `movie`:
- Publish URL: `rtmp://135.98.31.15/live/movie?secret=5181a08ee6eab86597e913e1f9e4c294`
- Play URL: `http://135.98.31.15/live/movie.m3u8`
Or you can change `livestream` to `sport`:
- Publish URL: `rtmp://135.98.31.15/live/sport?secret=5181a08ee6eab86597e913e1f9e4c294`
- Play URL: `http://135.98.31.15/live/sport.m3u8`
You can use any name you prefer, for example, `the-10-years-anually-for-you`:
- Publish URL: `rtmp://135.98.31.15/live/the-10-years-anually-for-you?secret=5181a08ee6eab86597e913e1f9e4c294`
- Play URL: `http://135.98.31.15/live/the-10-years-anually-for-you.m3u8`
> Note: Please note that all streams share the same publish secret.
The Oryx allows for an unlimited number of simultaneous streams, with the only constraint being your
server's bandwidth capacity. Additionally, you have the freedom to choose any desired stream name.
## Limitations of the Oryx
Nevertheless, the Oryx has a few limitations.
As of now, it only supports authentication for publishing streams using a global secret applicable to
all streams. It does not provide individual secrets for each stream in an effort to maintain simplicity.
Additionally, unlike YouTube and Twitch, the Oryx does not support changing stream names, which use
different names for publishing and playing. This can be confusing and complex, as it requires an additional
system to manage the mapping of filenames.
Finally, the Oryx does not have authentication support for playing streams at the moment, making the
stream view public and accessible to anyone. If you would like to limit the playback of the stream, please
let us know. This feature is included in the milestone, but there is no specific timeline for its
implementation.
## Cloud Service
At SRS, our goal is to establish a non-profit, open-source community dedicated to creating an all-in-one,
out-of-the-box, open-source video solution for live streaming and WebRTC online services.
Additionally, we offer a [Cloud](../cloud) service for those who prefer to use cloud service instead of building from
scratch. Our cloud service features global network acceleration, enhanced congestion control algorithms,
client SDKs for all platforms, and some free quota.
To learn more about our cloud service, click [here](../cloud).
## Conclusion
In summary, security and authentication are vital aspects of live streaming, and the Oryx provides a
straightforward solution for those building their own streaming services. By following the steps outlined
in this guide, you can ensure that your live streaming service remains secure and accessible only to
authorized users.
## Contact
Welcome for more discussion at [discord](https://discord.gg/bQUPDRqy79).
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/blog-en/2023-08-29-Ensuring-Authentication-for-Live-Streaming-Publishing)

114
trunk/3rdparty/srs-docs/blog/2023-09-09-Oryx-Multi-Platform-Streaming.md vendored Normal file
View File

@ -0,0 +1,114 @@
---
slug: Multi-Platform-Streaming
title: Oryx - Maximize Audience Engagement - Effortlessly Restream Live Content Across Multiple Platforms with Oryx
authors: []
tags: [live streaming, multi-platform streaming, restreaming]
custom_edit_url: null
---
# Maximize Audience Engagement: Effortlessly Restream Live Content Across Multiple Platforms with Oryx
In today's digital world, live streaming has become an essential tool for businesses, content creators, and individuals to engage with their audiences. With the increasing popularity of various live streaming platforms like YouTube, Twitch, and Facebook, it has become crucial to stream your content on multiple platforms simultaneously to reach a wider audience. This blog will guide you through the process of live streaming to multiple platforms using Oryx.
<!--truncate-->
Oryx is a powerful and easy-to-use solution that allows you to live stream to multiple platforms with just a few clicks. It also enables you to stream to your own platform or even set up an intranet live stream within your company. Let's dive into the steps to set up live streaming on multiple platforms using Oryx.
### Step 1: Create Oryx by One Click
Creating an Oryx is simple and can be done with just one click if you use Digital Ocean droplet.
Please see [How to Setup a Video Streaming Service by 1-Click](./2022-04-09-Oryx-Tutorial.md) for detail.
You can also use Docker to create an Oryx with a single command line:
```bash
docker run --rm -it -p 80:2022 -p 443:2443 -p 1935:1935 \
-p 8080:8080 -p 8000:8000/udp -p 10080:10080/udp --name oryx \
-v $HOME/data:/data ossrs/oryx:5
```
After creating the Oryx, you can access it through `http://your-server-ip/mgmt` via a browser.
### Step 2: Publish a live stream to Oryx
You can use OBS or FFmpeg to publish a live stream to Oryx. You can also set up HTTPS and publish via WebRTC.
![](/img/blog-2022-04-09-01.png)
Once the stream is published, you can preview it using an H5 player or VLC.
Please see [How to Setup a Video Streaming Service by 1-Click](./2022-04-09-Oryx-Tutorial.md) for detail.
### Step 3: Forward to YouTube
To forward your stream to YouTube, copy the Stream URL and Stream key from your YouTube [Go live](https://studio.youtube.com/channel/UC/livestreaming) page.
![](/img/blog-2023-09-09-01.png)
Open the Oryx dashboard and click on `Scenarios > Forward > YouTube`. And click `Start Forward` in Oryx.
![](/img/blog-2023-09-09-02.png)
Your stream will now be published on YouTube.
![](/img/blog-2023-09-09-03.png)
### Step 4: Forward to Twitch
To forward your stream to Twitch, copy the Stream key from your Twitch [Dashboard](https://www.twitch.tv/dashboard/settings) under `Settings > Stream`.
![](/img/blog-2023-09-09-04.png)
Open the Oryx dashboard and click on `Scenarios > Forward > Twitch`. Click `Start Forward` in Oryx.
![](/img/blog-2023-09-09-05.png)
And your stream will be published on Twitch in the [Stream Manager](https://www.twitch.tv/dashboard/stream).
![](/img/blog-2023-09-09-06.png)
### Step 5: Forward to Facebook
To forward your stream to Facebook, copy the Stream key from your Facebook [Live Producer](https://www.facebook.com/live/producer?ref=OBS) page,
then click `Go live`, and select `Streaming software`.
![](/img/blog-2023-09-09-07.png)
![](/img/blog-2023-09-09-08.png)
Open the Oryx dashboard and click on `Scenarios > Forward > Facebook`. Click `Start Forward` in Oryx, and your stream will be published on Facebook.
![](/img/blog-2023-09-09-09.png)
![](/img/blog-2023-09-09-10.png)
![](/img/blog-2023-09-09-11.png)
### Step 6: Check Multiple Streaming Status
After publishing your stream on all platforms, you can check the multiple streaming status in the Oryx dashboard.
![](/img/blog-2023-09-09-12.png)
## Cloud Service
At SRS, our goal is to establish a non-profit, open-source community dedicated to creating an all-in-one,
out-of-the-box, open-source video solution for live streaming and WebRTC online services.
Additionally, we offer a [Cloud](../cloud) service for those who prefer to use cloud service instead of building from
scratch. Our cloud service features global network acceleration, enhanced congestion control algorithms,
client SDKs for all platforms, and some free quota.
To learn more about our cloud service, click [here](../cloud).
### Conclusion
Live streaming to multiple platforms is an effective way to reach a broader audience and increase engagement.
Oryx makes this process simple and efficient, allowing you to focus on creating quality content while it takes
care of the technical aspects. By following the steps outlined in this blog, you can easily set up live streaming
on multiple platforms like YouTube, Twitch, and Facebook, and take your content to the next level.
## Contact
Welcome for more discussion at [discord](https://discord.gg/bQUPDRqy79).
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/blog-en/2023-09-09-Multi-Platform-Streaming)

106
trunk/3rdparty/srs-docs/blog/2023-09-10-Oryx-Record-Live-Streaming.md vendored Normal file
View File

@ -0,0 +1,106 @@
---
slug: Record-Live-Streaming
title: Oryx - Effortless Live Stream Recording with Oryx - A Step-by-Step Guide to Server-Side Recording and AWS S3 Integration
authors: []
tags: [live streaming, record, dvr, srs]
custom_edit_url: null
---
# Effortless Live Stream Recording with Oryx: A Step-by-Step Guide to Server-Side Recording and AWS S3 Integration
## Introduction
With Oryx, you can easily record your live streaming and publish it on a web page for your audience
to access. In this blog, we will guide you through the process of recording live streaming to an MP4 file
using Oryx.
<!--truncate-->
Live streaming has become increasingly popular, and many content creators want to record their live streams
for later use or to provide their audience with video-on-demand (VoD) content. While there are various
methods to record live streams, such as using OBS, some embedded devices may not support recording or
may be difficult to control. In such cases, server-side recording can be a more efficient solution.
### Step 1: Create Oryx by One Click
Creating an Oryx is simple and can be done with just one click if you use Digital Ocean droplet.
Please see [How to Setup a Video Streaming Service by 1-Click](./2022-04-09-Oryx-Tutorial.md) for detail.
You can also use Docker to create an Oryx with a single command line:
```bash
docker run --rm -it -p 80:2022 -p 443:2443 -p 1935:1935 \
-p 8080:8080 -p 8000:8000/udp -p 10080:10080/udp --name oryx \
-v $HOME/data:/data ossrs/oryx:5
```
After creating the Oryx, you can access it through `http://your-server-ip/mgmt` via a browser.
### Step 2: Publish a live stream to Oryx
You can use OBS or FFmpeg to publish a live stream to Oryx. You can also set up HTTPS and publish via WebRTC.
![](/img/blog-2022-04-09-01.png)
Once the stream is published, you can preview it using an H5 player or VLC.
Please see [How to Setup a Video Streaming Service by 1-Click](./2022-04-09-Oryx-Tutorial.md) for detail.
## Step 3: Record the Live Stream by Oryx
Once your live stream is published, you can start recording it using Oryx. To do this, open the
`Scenarios > Record > Setup Record Rules` section and click the `Start Record` button.
![](/img/blog-2023-09-10-01.png)
The recording process will begin, and you can monitor the progress of your recording tasks.
![](/img/blog-2023-09-10-02.png)
## Step 4: Stop and Download MP4 File
When you want to stop recording, click the `Stop Record` button in the `Setup Record Rules` section. Wait for
a few seconds for the recording to stop. If the live stream is no longer being published, Oryx will
automatically stop the recording task after a few minutes (e.g., 5 minutes).
After the recording has stopped, Oryx will transmux the recorded file to MP4 format. You can then preview
and download the MP4 file for further use or distribution.
![](/img/blog-2023-09-10-03.png)
## How to Record Specific Streams?
See [How to Record a Specific Stream](../faq-oryx#how-to-record-a-specific-stream)
## How to Record to S3 Cloud Storage?
See [How to Record to S3 Cloud Storage](../faq-oryx#how-to-record-to-s3-cloud-storage)
## How to Merge to One Mp4 File?
See [Recording Doesn't Stop When the Stream is Stopped](../faq-oryx#recording-doesnt-stop-when-the-stream-is-stopped)
and [How to Quickly Generate a Recorded File](../faq-oryx#how-to-quickly-generate-a-recorded-file)
## Cloud Service
At SRS, our goal is to establish a non-profit, open-source community dedicated to creating an all-in-one,
out-of-the-box, open-source video solution for live streaming and WebRTC online services.
Additionally, we offer a [Cloud](../cloud) service for those who prefer to use cloud service instead of building from
scratch. Our cloud service features global network acceleration, enhanced congestion control algorithms,
client SDKs for all platforms, and some free quota.
To learn more about our cloud service, click [here](../cloud).
## Conclusion
Recording live streaming to an MP4 file is a valuable feature for content creators who want to provide
their audience with video-on-demand content. With Oryx, the process of recording, stopping, and
downloading your live streams is simplified, making it easy for you to manage and distribute your recorded
content. By following the steps outlined in this blog, you can quickly and efficiently record your live
streams and make them available for your audience to access whenever they want.
## Contact
Welcome for more discussion at [discord](https://discord.gg/bQUPDRqy79).
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/blog-en/2023-09-10-Record-Live-Streaming)

139
trunk/3rdparty/srs-docs/blog/2023-09-11-Oryx-Virtual-Live-Events.md vendored Normal file
View File

@ -0,0 +1,139 @@
---
slug: Virtual-Live-Events
title: Oryx - Virtual Live Events - Harness the Power of Pre-Recorded Content for Seamless and Engaging Live Streaming Experiences
authors: []
tags: [live streaming, virual live events, srs]
custom_edit_url: null
---
# Mastering Virtual Live Events: Harness the Power of Pre-Recorded Content for Seamless and Engaging Live Streaming Experiences
## Introduction
Virtual live events refers to converting recorded video files, devices, or network streams into live
broadcasts and pushing them to live streaming platforms. For example, in e-commerce live streaming,
you can pre-record product explanations and demonstrations. In educational live streaming, you can
pre-record lessons and play them in the live classroom. For online speeches and sharing, you can
play pre-recorded content in the live room.
Virtual live events allows streamers to have plenty of preparation time, making the content more polished.
It helps reduce anxiety for inexperienced streamers, prevents network issues, enables 24/7 live streaming,
reaches a wider audience, and offers more possibilities for live broadcasts.
<!--truncate-->
Oryx enables you to create virtual live events with just one click, broadcasting them to multiple platforms
like YouTube, Twitch, and Facebook. In this blog post, we'll walk you through the steps to create a virtual live
event using Oryx.
In today's fast-paced world, virtual live events are becoming increasingly popular due to the convenience
they offer. Whether it's a concert, a soccer game, or an online course, you can now create a virtual live
event with your video files, making them more interactive and accessible to a wider audience.
## Step 1: Create Oryx by One Click
Creating an Oryx is simple and can be done with just one click if you use Digital Ocean droplet.
Please see [How to Setup a Video Streaming Service by 1-Click](./2022-04-09-Oryx-Tutorial.md) for detail.
You can also use Docker to create an Oryx with a single command line:
```bash
docker run --rm -it -p 80:2022 -p 443:2443 -p 1935:1935 \
-p 8080:8080 -p 8000:8000/udp -p 10080:10080/udp --name oryx \
-v $HOME/data:/data ossrs/oryx:5
```
After creating the Oryx, you can access it through `http://your-server-ip/mgmt` via a browser.
## Step 2: Upload your video file
Once you've created your Oryx, open the dashboard and navigate to `Scenarios > VirtualLive > YouTube`.
Click on `Choose File`, select your video file, and then click `Upload File`.
![](/img/blog-2023-09-11-01.png)
## Step 3: Stream file to YouTube
To stream your file to YouTube, copy the Stream URL and Stream key from your YouTube [Go live](https://studio.youtube.com/channel/UC/livestreaming) page.
![](/img/blog-2023-09-11-02.png)
Open the Oryx dashboard and click on `Scenarios > VirtualLive > YouTube`. And click `Start Virtual Live` in Oryx.
![](/img/blog-2023-09-11-03.png)
Your stream will now be published on YouTube.
![](/img/blog-2023-09-11-04.png)
## Step 4: Check virtual live status
To monitor the status of your virtual live event, simply check the dashboard. You'll be able to see the status of all your virtual live events, ensuring that everything is running smoothly.
![](/img/blog-2023-09-11-05.png)
## Step 5: Stream file to Twitch
After uploading file, you can stream your file to Twitch, copy the Stream key from your
Twitch [Dashboard](https://www.twitch.tv/dashboard/settings) under `Settings > Stream`.
![](/img/blog-2023-09-11-06.png)
Open the Oryx dashboard and click on `Scenarios > VirtualLive > Twitch`. Click `Start Virtual Live` in Oryx.
![](/img/blog-2023-09-11-07.png)
And your stream will be published on Twitch in the [Stream Manager](https://www.twitch.tv/dashboard/stream).
![](/img/blog-2023-09-11-08.png)
## Step 5: Stream file to Facebook
After uploading file, you can stream your file to Facebook, copy the Stream key from your
Facebook [Live Producer](https://www.facebook.com/live/producer?ref=OBS) page,
then click `Go live`, and select `Streaming software`.
![](/img/blog-2023-09-11-09.png)
![](/img/blog-2023-09-11-10.png)
Open the Oryx dashboard and click on `Scenarios > VirtualLive > Facebook`. Click `Start Virtual Live` in Oryx, and your stream will be published on Facebook.
![](/img/blog-2023-09-11-11.png)
![](/img/blog-2023-09-11-12.png)
![](/img/blog-2023-09-11-13.png)
## (Optional) Upload Video File by Other Tools
You can also upload the video file to the `/data/upload` folder using tools like FTP or SCP. After that, choose
`Use server file`, enter the video file's path, and utilize it as a virtual live source.
This method enables you to upload very large files, particularly when webpage-based uploads fail. By using professional
upload tools, you can resume uploads or accelerate the process with multi-threading and other features.
## Cloud Service
At SRS, our goal is to establish a non-profit, open-source community dedicated to creating an all-in-one,
out-of-the-box, open-source video solution for live streaming and WebRTC online services.
Additionally, we offer a [Cloud](../cloud) service for those who prefer to use cloud service instead of building from
scratch. Our cloud service features global network acceleration, enhanced congestion control algorithms,
client SDKs for all platforms, and some free quota.
To learn more about our cloud service, click [here](../cloud).
## Conclusion
In conclusion, virtual live events provide a convenient and efficient way to broadcast pre-recorded content on
various platforms, making it more polished and accessible to a wider audience. By reducing anxiety for
inexperienced streamers and enabling 24/7 streaming, virtual live events offer numerous possibilities for
various industries. Oryx simplifies the process of creating and broadcasting these events, catering
to the increasing demand for such interactive experiences in today's fast-paced world.
## Contact
Welcome for more discussion at [discord](https://discord.gg/bQUPDRqy79).
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/blog-en/2023-09-11-Virtual-Live-Events)

138
trunk/3rdparty/srs-docs/blog/2023-10-11-Oryx-Stream-IP-Camera-Events.md vendored Normal file
View File

@ -0,0 +1,138 @@
---
slug: Stream-IP-Camera-Events
title: Oryx - Easily Stream Your RTSP IP Camera to YouTube, Twitch, or Facebook
authors: []
tags: [live streaming, virual live events, srs, ip camera, rtsp]
custom_edit_url: null
---
# Easily Stream Your RTSP IP Camera to YouTube, Twitch, or Facebook
## Introduction
Do you have an IP camera that supports only the RTSP protocol and want to stream it to YouTube, Twitch,
or Facebook? The simplest solution is to use Oryx. With just one click, you can stream your IP
camera to these platforms for continuous 24/7 streaming.
<!--truncate-->
How to change IP Camera's RTSP stream to RTMP/RTMPS for live streaming platforms? You can use OBS or
Oryx. OBS requires a device, while Oryx works on a cloud server and in the backend. See the
workflow below.
```bash
IP Camera ---RTSP---> OBS or Oryx ---RTMP/RTMPS---> YouTube, Twitch, or Facebook
```
Oryx helps you connect multiple IP cameras and stream live to various platforms, making your live
streaming experience stronger.
## Step 1: Create Oryx by One Click
Creating an Oryx is simple and can be done with just one click if you use Digital Ocean droplet.
Please see [How to Setup a Video Streaming Service by 1-Click](./2022-04-09-Oryx-Tutorial.md) for detail.
You can also use Docker to create an Oryx with a single command line:
```bash
docker run --rm -it -p 80:2022 -p 443:2443 -p 1935:1935 \
-p 8080:8080 -p 8000:8000/udp -p 10080:10080/udp --name oryx \
-v $HOME/data:/data ossrs/oryx:5
```
After creating the Oryx, you can access it through `http://your-server-ip/mgmt` via a browser.
## Step 2: Pull RTSP Stream from IP Camera
Once you've created your Oryx, open the dashboard and navigate to `Scenarios > Camera > YouTube`.
Click on `Live Stream Source`, input the RTSP url, and then click `Submit`.
![](/img/blog-2023-10-11-01.png)
## Step 2.1: (Optional) Enable Extra Silent Audio Track
If your camera only provides a video stream, you should enable an additional silent audio track,
otherwise, publishing to live platforms like YouTube will fail. Oryx can automatically generate
a silent audio track for you. Please choose the `Silent Audio Stream` option.
![](/img/blog-2023-10-11-14.png)
Oryx will automatically generate a silent audio track, when forwarding the RTSP stream.
## Step 3: Stream IP Camera to YouTube
To stream your file to YouTube, copy the Stream URL and Stream key from your YouTube [Go live](https://studio.youtube.com/channel/UC/livestreaming) page.
![](/img/blog-2023-10-11-02.png)
Open the Oryx dashboard and click on `Scenarios > Camera > YouTube`. And click `Start Camera Live` in Oryx.
![](/img/blog-2023-10-11-03.png)
Your stream will now be published on YouTube.
![](/img/blog-2023-10-11-04.png)
## Step 4: Check Camera Live Status
To monitor the status of your camera live event, simply check the dashboard. You'll be able to see the status of all your camera live events, ensuring that everything is running smoothly.
![](/img/blog-2023-10-11-05.png)
## Step 5: Stream IP Camera to Twitch
After setup RTSP stream, you can stream your IP Camera to Twitch, copy the Stream key from your
Twitch [Dashboard](https://www.twitch.tv/dashboard/settings) under `Settings > Stream`.
![](/img/blog-2023-10-11-06.png)
Open the Oryx dashboard and click on `Scenarios > Camera > Twitch`. Click `Start Camera Live` in Oryx.
![](/img/blog-2023-10-11-07.png)
And your stream will be published on Twitch in the [Stream Manager](https://www.twitch.tv/dashboard/stream).
![](/img/blog-2023-10-11-08.png)
## Step 5: Stream IP Camera to Facebook
After setup RTSP stream, you can stream your IP Camera to Facebook, copy the Stream key from your
Facebook [Live Producer](https://www.facebook.com/live/producer?ref=OBS) page,
then click `Go live`, and select `Streaming software`.
![](/img/blog-2023-10-11-09.png)
![](/img/blog-2023-10-11-10.png)
Open the Oryx dashboard and click on `Scenarios > Camera > Facebook`. Click `Start Camera Live` in Oryx, and your stream will be published on Facebook.
![](/img/blog-2023-10-11-11.png)
![](/img/blog-2023-10-11-12.png)
![](/img/blog-2023-10-11-13.png)
## Cloud Service
At SRS, our goal is to establish a non-profit, open-source community dedicated to creating an all-in-one,
out-of-the-box, open-source video solution for live streaming and WebRTC online services.
Additionally, we offer a [Cloud](../cloud) service for those who prefer to use cloud service instead of building from
scratch. Our cloud service features global network acceleration, enhanced congestion control algorithms,
client SDKs for all platforms, and some free quota.
To learn more about our cloud service, click [here](../cloud).
## Conclusion
In conclusion, streaming your RTSP IP camera to popular platforms like YouTube, Twitch, or Facebook has never
been easier, thanks to Oryx. With just a few simple steps, you can set up your IP camera for continuous
24/7 streaming on these platforms. By utilizing Oryx, you can also connect multiple IP cameras and stream
live to various platforms, enhancing your live streaming experience. So, go ahead and give Oryx a try, and
enjoy the convenience and flexibility it offers for your IP camera streaming needs.
## Contact
Welcome for more discussion at [discord](https://discord.gg/bQUPDRqy79).
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/blog-en/2023-10-11-Stream-IP-Camera-Events)

108
trunk/3rdparty/srs-docs/blog/2023-10-21-Oryx-Live-Transcoding.md vendored Normal file
View File

@ -0,0 +1,108 @@
---
slug: Live-Transcoding
title: Oryx - Efficient Live Streaming Transcoding for Reducing Bandwidth and Saving Costs
authors: []
tags: [live streaming, transcode, srs, ffmpeg]
custom_edit_url: null
---
# Efficient Live Streaming Transcoding for Reducing Bandwidth and Saving Costs
## Introduction
In today's digital world, live streaming has become an essential tool for businesses, content creators, and
individuals alike. With the increasing number of viewers tuning in to watch live streams, it's crucial to optimize
the streaming experience and cost for everyone, regardless of their internet speed or device capabilities. One
effective way to achieve this is through live streaming transcoding, a process that can help reduce bandwidth
and save costs without compromising on video quality. In this blog, we'll explore the benefits of using Oryx
for efficient live streaming transcoding and how it can lead to significant cost savings.
<!--truncate-->
Live streaming transcoding involves converting a live stream from Oryx using FFmpeg into various bitrates and
resolutions, before pushing it back to Oryx. This process allows for a reduction in bandwidth while maintaining
the same quality, simply by lowering the bitrate of the stream. As a result, the overall viewing bandwidth is
decreased, leading to cost savings for both the streamer and the viewer.
For instance, consider a live streaming scenario with 10,000 viewers all watching the same 2Mbps bitrate stream.
By transcoding the stream to 1Mbps, the required bandwidth is reduced to 10Gbps, resulting in a 50% cost saving.
This not only benefits the content provider but also ensures a smoother streaming experience for viewers with
varying internet speeds and devices.
Stay tuned as we delve deeper into the world of live streaming transcoding, and learn how to harness the power
of Oryx to optimize your streaming experience and save costs.
## Step 1: Create Oryx by One Click
Creating an Oryx is simple and can be done with just one click if you use Digital Ocean droplet.
Please see [How to Setup a Video Streaming Service by 1-Click](./2022-04-09-Oryx-Tutorial.md) for detail.
You can also use Docker to create an Oryx with a single command line:
```bash
docker run --restart always -d -it --name oryx -v $HOME/data:/data \
-p 80:2022 -p 443:2443 -p 1935:1935 -p 8000:8000/udp -p 10080:10080/udp \
ossrs/oryx:5
```
After creating the Oryx, you can access it through `http://your-server-ip/mgmt` via a browser.
## Step 2: Publish a Live Stream to Oryx
You can use OBS or FFmpeg to publish a live stream to Oryx. You can also set up HTTPS and publish via WebRTC.
![](/img/blog-2023-10-21-01.png)
Once the stream is published, you can preview it using an H5 player or VLC.
Please see [How to Setup a Video Streaming Service by 1-Click](./2022-04-09-Oryx-Tutorial.md) for detail.
## Step 3: Transcode the Live Stream to Lower Bitrate
Suppose you've sent an 8Mbps stream to Oryx using OBS, and you can't adjust the bitrate in OBS. This could
be because the stream is published by a vendor you can't control, or you need to record the original high-resolution
stream, or some devices like 4K/8K TVs require the high-resolution stream.
However, most of your viewers watch the live stream on mobile devices, and they don't need an 8Mbps stream. A 2Mbps
stream is sufficient for mobile devices, and their bandwidth may only support a 2Mbps bitrate. In this case, you can
use transcoding to convert the 8Mbps stream into a 2Mbps live stream.
![](/img/blog-2023-10-21-02.png)
After transcoding the stream, you can preview the 2Mbps version or forward it to another live streaming platform.
See [Easily Stream Your RTSP IP Camera to YouTube, Twitch, or Facebook](./2023-10-11-Oryx-Stream-IP-Camera-Events.md)
for more information. You can also pull the RTMP stream from Oryx and forward it elsewhere.
## Check Transcoding Status
You can check the transcoding status in the Oryx dashboard.
![](/img/blog-2023-10-21-03.png)
You can click the preview link to check the transcoded stream, or forward it to another live streaming platform.
See [Easily Stream Your RTSP IP Camera to YouTube, Twitch, or Facebook](./2023-10-11-Oryx-Stream-IP-Camera-Events.md)
for more information.
## Cloud Service
At SRS, our goal is to establish a non-profit, open-source community dedicated to creating an all-in-one,
out-of-the-box, open-source video solution for live streaming and WebRTC online services.
Additionally, we offer a [Cloud](../cloud) service for those who prefer to use cloud service instead of building from
scratch. Our cloud service features global network acceleration, enhanced congestion control algorithms,
client SDKs for all platforms, and some free quota.
To learn more about our cloud service, click [here](../cloud).
## Conclusion
In summary, we discussed the benefits of live streaming transcoding using Oryx and FFmpeg. Transcoding optimizes
streaming for viewers with different internet speeds and devices, reduces bandwidth usage, and saves costs. We
covered setting up Oryx and FFmpeg, creating a configuration file, and pushing transcoded streams back to
Oryx. Monitoring and adjusting settings is crucial for optimal viewer experience, and transcoding can also
convert high-resolution streams to lower resolutions for mobile devices.
## Contact
Welcome for more discussion at [discord](https://discord.gg/bQUPDRqy79).
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/blog-en/2023-10-21-Live-Transcoding)

132
trunk/3rdparty/srs-docs/blog/2023-10-26-Unlock-the-Power-of-HEVC-via-RTMP.md vendored Normal file
View File

@ -0,0 +1,132 @@
---
slug: unlock-the-power-of-hevc-via-rtmp
title: SRS - Unlock the Power of HEVC via RTMP - Boost Your Live Streaming with OBS and FFmpeg
authors: []
tags: [hevc, rtmp, obs, ffmpeg, live]
custom_edit_url: null
---
# Unlock the Power of HEVC via RTMP - Boost Your Live Streaming with OBS and FFmpeg
## Introduction
HEVC, or H.265, can reduce bandwidth usage by about 50% compared to the widely used H.264 codec, which has the
best compatibility. Over the past 10 years, HEVC has grown slowly because a new codec needs an ecosystem to
support it, including decoders and device hardware. Now, both RTMP and FLV support HEVC in OBS and FFmpeg,
which are the standard tools in the live streaming industry.
<!--truncate-->
In live streaming, all the necessary tools are ready for HEVC. For encoding, FFmpeg and OBS are the most commonly
used streaming tools. OBS 29+ supports RTMP with HEVC, while FFmpeg 6 supports RTMP with HEVC. For HTML5 players,
mpegts.js 1.7.3 already supports HEVC via HTTP-FLV or HTTP-TS. VLC and ffplay also support HEVC via HTTP-TS, SRT,
and HLS. For media servers, SRS 6 supports HEVC via RTMP, FLV, TS, HLS, SRT, WebRTC, and more.
In this tutorial, we introduce FFmpeg 6, which added HEVC support just a few months ago. This is a significant
development, as many tools that use FFmpeg can now utilize HEVC via RTMP without any patches.
> Note: If you are interested in learning about OBS support for HEVC via RTMP, please read
> [How to Push HEVC via RTMP by OBS](./2023-04-08-Push-HEVC-via-RTMP-by-OBS.md).
> Note: Please note that SRS 6.0 had already HEVC(H.265) support for RTMP, HTTP-FLV, SRT, HTTP-TS, HLS, MPEG-DASH
> and WebRTC(Safari), please refer to [H.265 Live Streaming Saving 50% Cost](./2023-03-07-Lets-Do-H265-Live-Streaming.md).
## Step 1: Run SRS Media Server
YouTube supports HEVC through RTMP, allowing you to directly publish HEVC via RTMP streams to YouTube using
OBS or FFmpeg. If you need to create your own live streaming platform, you can use the SRS media server, which
also supports HEVC via RTMP.
To run SRS, you can use Docker with the following command:
```
docker run --rm -it -p 1935:1935 -p 8080:8080 ossrs/srs:6 \
./objs/srs -c conf/docker.conf
```
To check if it started successfully, open your browser and visit
[http://localhost:8080](http://localhost:8080).
## Step 2: Publish by FFmpeg 6
If you have compiled FFmpeg 6 from source code using the instructions from this [post](../docs/v6/doc/hevc#ffmpeg-tools),
you can now utilize FFmpeg to publish RTMP HEVC streams:
```bash
ffmpeg -stream_loop -1 -re -i doc/source.flv -acodec copy \
-vcodec libx265 -f flv rtmp://localhost/live/livestream
```
Keep in mind that FFmpeg 6.0 does not support HEVC over RTMP until the following commit
[637c761b](https://github.com/FFmpeg/FFmpeg/commit/637c761be1bf9c3e1f0f347c5c3a390d7c32b282):
```
commit 637c761be1bf9c3e1f0f347c5c3a390d7c32b282
Author: Steven Liu <liuqi05@kuaishou.com>
Date: Mon Aug 28 09:59:24 2023 +0800
avformat/rtmpproto: support enhanced rtmp
add option named rtmp_enhanced_codec,
it would support hvc1,av01,vp09 now,
the fourcc is using Array of strings.
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
```
SRS offers Docker support for FFmpeg versions 4 and 5, which enable HEVC streaming through RTMP. You can
conveniently use Docker to directly publish your live stream.
```bash
# For macOS
docker run --rm -it ossrs/srs:encoder \
ffmpeg -stream_loop -1 -re -i doc/source.flv -acodec copy \
-vcodec libx265 -f flv rtmp://host.docker.internal/live/livestream
# For Linux
docker run --net=host --rm -it ossrs/srs:encoder \
ffmpeg -stream_loop -1 -re -i doc/source.flv -acodec copy \
-vcodec libx265 -f flv rtmp://127.0.0.1/live/livestream
```
> Note: If want to use OBS, please download OBS 29+ from [here](https://github.com/obsproject/obs-studio/releases),
> select the HEVC codec, please see [How to Push HEVC via RTMP by OBS](./2023-04-08-Push-HEVC-via-RTMP-by-OBS.md)
> for detail.
## Step 3: Play by HTML5 Player
To play HEVC streams in your web browser, you can utilize mpegts.js version 1.7.3+ for playing HTTP-FLV or
HTTP-TS.
The SRS player has mpegts.js integrated, so all you need to do is open the URL to play the HEVC stream:
* HTTP-FLV(by H5): [http://localhost:8080/live/livestream.flv](http://localhost:8080/players/srs_player.html?autostart=true)
When it comes to HLS streaming, hls.js doesn't support HEVC via TS. As a result, you should use VLC or ffplay
to play the HLS stream instead:
* HLS(by VLC or fflay): `http://localhost:8080/live/livestream.m3u8`
## Cloud Service
At SRS, our goal is to establish a non-profit, open-source community dedicated to creating an all-in-one,
out-of-the-box, open-source video solution for live streaming and WebRTC online services.
Additionally, we offer a [Cloud](../cloud) service for those who prefer to use cloud service instead of building from
scratch. Our cloud service features global network acceleration, enhanced congestion control algorithms,
client SDKs for all platforms, and some free quota.
To learn more about our cloud service, click [here](../cloud).
## Conclusion
In summary, using HEVC for live streaming has become more accessible thanks to essential tools like OBS, FFmpeg,
and SRS media server, making it simpler for users to benefit from the bandwidth savings provided by this codec.
By following the steps in this guide, you can create your own live streaming platform with HEVC and RTMP, and
play the streams using HTML5 players like mpegts.js, or VLC and ffplay for HLS streaming.
## Contact
Welcome for more discussion at [discord](https://discord.gg/bQUPDRqy79).
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/blog-en/23-10-26-Unlock-the-Power-of-HEVC-via-RTMP)

114
trunk/3rdparty/srs-docs/blog/2023-11-28-Oryx-Live-Streams-Transcription.md vendored Normal file
View File

@ -0,0 +1,114 @@
---
slug: live-streams-transcription
title: Oryx - Revolutionizing Live Streams with AI Transcription - Creating Accessible, Multilingual Subtitles for Diverse Audiences
authors: []
tags: [live, ai, transcription, asr, subtitles]
custom_edit_url: null
---
# Revolutionizing Live Streams with AI Transcription: Creating Accessible, Multilingual Subtitles for Diverse Audiences
## Introduction
In this blog, we're diving into an exciting advancement in live streaming: using Automatic Speech
Recognition (ASR) to create real-time subtitles. Have you ever wondered how live streams can be more
inclusive, especially for people with hearing disabilities or those who are non-native speakers?
The answer lies in an innovative technology that’s reshaping how we experience live content.
<!--truncate-->
We'll focus on a game-changing tool in ASR – OpenAI's Whisper. This isn't just any technology; it's
a powerful AI service that understands almost every language in the world and transcripts speech
with remarkable accuracy. Forget the old days of needing expensive professionals for live translation
and transcription. With OpenAI's Whisper, this process becomes automated, efficient, and cost-effective.
Designed for beginners, our guide will take you through integrating Whisper AI into your live streams
to recognize and transcribe speech. Then, we'll show you how to use FFmpeg, to overlay these subtitles
onto your stream. All of this is made simple using the Oryx, which seamlessly connects these
technologies with just one click.
Join us as we step into the AI-powered future of live streaming, where accessibility and inclusivity
are key, making your content enjoyable and accessible to a much wider audience.
## Step 1: Create Oryx by One Click
Creating an Oryx is simple and can be done with just one click if you use Digital Ocean droplet.
Please see [How to Setup a Video Streaming Service by 1-Click](./2022-04-09-Oryx-Tutorial.md) for detail.
You can also use Docker to create an Oryx with a single command line:
```bash
docker run --restart always -d -it --name oryx -v $HOME/data:/data \
-p 80:2022 -p 443:2443 -p 1935:1935 -p 8000:8000/udp -p 10080:10080/udp \
ossrs/oryx:5
```
After creating the Oryx, you can access it through `http://your-server-ip/mgmt` via a browser.
## Step 2: Publish a Live Stream to Oryx
You can use OBS or FFmpeg to publish a live stream to Oryx. You can also set up HTTPS and publish via WebRTC.
![](/img/blog-2023-11-28-01.png)
Once the stream is published, you can preview it using an H5 player or VLC.
Please see [How to Setup a Video Streaming Service by 1-Click](./2022-04-09-Oryx-Tutorial.md) for detail.
## Step 3: Setup OpenAI Secret Key for Whisper ASR
To use Whisper ASR, you must obtain a secret key from OpenAI. Please open the [API keys](https://platform.openai.com/api-keys)
page in your browser and click the `Create new secret key` button. Once the key is created, copy it and set it in Oryx.
Then, click the `Test OpenAI Service` button, as shown in the picture below.
![](/img/blog-2023-11-28-03.png)
If the test is successful, you can click the `Start Transcription` button to start the transcription process.
## Step 4: View Live Stream with Subtitles
When HLS segments are generated, Oryx uses FFmpeg to transcode the TS segment into an audio MP4 file.
It then utilizes OpenAI's Whisper service to convert this into an SRT subtitle. Following this, the subtitle
is overlaid onto the original TS file, resulting in the creation of a new live stream.
A link is available to play the newly generated live stream with subtitles. You can open this link directly
in your browser, as shown in the picture below.
![](/img/blog-2023-11-28-05.png)
Open the HLS stream link in the browser to view the live stream with subtitles.
![](/img/blog-2023-11-28-07.png)
You can also use the HTTP API to obtain ASR results for each HLS segment and perform actions like translation
or integration with your AI systems.
## HLS with WebVTT
You can enable Web Video Text Tracks (WebVTT) for HLS. First, enable WebVTT in `Transcript > Service Settings > WebVTT Subtitle`,
click the checkbox `Enable WebVTT Subtitle`.
Then, open the `Stream Operations` tab, you will get a HLS stream with WebVTT subtitles.
## Cloud Service
At SRS, our goal is to establish a non-profit, open-source community dedicated to creating an all-in-one,
out-of-the-box, open-source video solution for live streaming and WebRTC online services.
Additionally, we offer a [Cloud](../cloud) service for those who prefer to use cloud service instead of building from
scratch. Our cloud service features global network acceleration, enhanced congestion control algorithms,
client SDKs for all platforms, and some free quota.
To learn more about our cloud service, click [here](../cloud).
## Conclusion
Oryx is now integrated with OpenAI's Whisper and FFmpeg to transcript live streaming, enhancing the
audience experience by providing AI-driven subtitles. This shift from manual to automated transcription is
cost-effective and broadens global accessibility, overcoming language and hearing barriers. We're entering
a future where AI enhances digital inclusivity, enriching how we share and consume content online.
## Contact
Welcome for more discussion at [discord](https://discord.gg/bQUPDRqy79).
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/blog-en/23-11-28-Oryx-Live-Streams-Transcription)

101
trunk/3rdparty/srs-docs/blog/2023-12-12-Oryx-OBS-WHIP-Service.md vendored Normal file
View File

@ -0,0 +1,101 @@
---
slug: obs-whip-internet-service
title: Oryx - Effortlessly Create a Public Internet WHIP Service for OBS - A Comprehensive Guide to Sub-Second Streaming
authors: []
tags: [live, obs, whip, streaming]
custom_edit_url: null
---
# Effortlessly Create a Public Internet WHIP Service for OBS: A Comprehensive Guide to Sub-Second Streaming
## Introduction
Are you tired of struggling with complicated setups and technical jargon when trying to create a public
internet WHIP service for OBS? Look no further! In this comprehensive guide, we will walk you through the
process of effortlessly building your own WHIP service using the Oryx, all with just a single click.
Say goodbye to the complexities of security, authentication, and WebRTC, and embrace the future of sub-second
live streaming and seamless OBS-RTC room connections.
<!--truncate-->
Join us as we break down the barriers of online streaming and help you unlock the full potential of OBS's
WHIP support. Our easy-to-understand, step-by-step tutorial will empower you to create a secure and efficient
WHIP service, revolutionizing your online meeting and live streaming experience. Don't let technical
challenges hold you back any longer - dive into our guide and start streaming like a pro today!
## Step 1: Create Oryx by One Click
Creating an Oryx is simple and can be done with just one click if you use Digital Ocean droplet.
Please see [How to Setup a Video Streaming Service by 1-Click](./2022-04-09-Oryx-Tutorial.md) for detail.
You can also use Docker to create an Oryx with a single command line:
```bash
docker run --restart always -d -it --name oryx -v $HOME/data:/data \
-p 80:2022 -p 443:2443 -p 1935:1935 -p 8000:8000/udp -p 10080:10080/udp \
ossrs/oryx:5
```
After creating the Oryx, you can access it through `http://your-server-ip/mgmt` via a browser.
## Step 2: Get the WHIP URL from Oryx
Please download OBS version 30 or higher from [this link](https://github.com/obsproject/obs-studio/releases)
and proceed with the installation.
Open the Oryx, select `Scenarios > Streaming > WebRTC: WHIP OBS`, and follow the instructions to
get a WHIP URL for OBS.
![](/img/blog-2023-12-12-01.png)
Please copy the WHIP URL as we will use it in OBS. Be aware that the WHIP stream can be played using the
WHEP player or embedded into your WordPress website.
## Step 3: Publish WHIP via OBS to Oryx
Next, launch OBS and select `Settings > Stream`. Choose `WHIP` from the `Service` drop-down menu, and set
the WHIP URL into the `Server` field.
![](/img/blog-2023-12-12-02.png)
> Note: If the latency is large, setup the OBS Output by: For OBS encoder, select the x264 encoder and in the
> advanced settings, set the GOP (Keyframe interval) to 1 s. Choose Preset as fast, Profile as baseline, and
> Tune as zerolatency.
Now you can click the `Start Streaming` button to publish the WHIP stream to the Oryx.
## Step 4: Use WHEP to View the Stream
After publishing the stream, you can view it with a WebRTC HTML5 player. Access the WHEP player from the
Oryx dashboard.
![](/img/blog-2023-12-12-03.png)
Additionally, integrate the WHEP player within your WordPress website. Kindly adhere to the guidelines
provided on the Oryx dashboard.
## Cloud Service
At SRS, our goal is to establish a non-profit, open-source community dedicated to creating an all-in-one,
out-of-the-box, open-source video solution for live streaming and WebRTC online services.
Additionally, we offer a [Cloud](../cloud) service for those who prefer to use cloud service instead of building from
scratch. Our cloud service features global network acceleration, enhanced congestion control algorithms,
client SDKs for all platforms, and some free quota.
To learn more about our cloud service, click [here](../cloud).
## Conclusion
In conclusion, our comprehensive guide has provided you with a simple and efficient method to create a public
internet WHIP service for OBS using the Oryx. By following our easy-to-understand, step-by-step tutorial,
you can now effortlessly build your own WHIP service with just a single click, eliminating the need to grapple
with complex security, authentication, and WebRTC issues. With this newfound knowledge, you can revolutionize
your online meeting and live streaming experience, fully harnessing the power of OBS's WHIP support for
sub-second streaming and seamless OBS-RTC room connections.
## Contact
Welcome for more discussion at [discord](https://discord.gg/bQUPDRqy79).
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/blog-en/2023-12-12-Oryx-OBS-WHIP-Service)

103
trunk/3rdparty/srs-docs/blog/2023-12-15-SRS-Ten-Years.md vendored Normal file
View File

@ -0,0 +1,103 @@
---
slug: srs-ten-years
title: SRS 10th Anniversary and 2023 Year-end Review
authors: []
tags: [srs, community]
custom_edit_url: null
---
# SRS 10th Anniversary and 2023 Year-end Review
As we reach the end of 2023, it's time for an annual summary, which we can look back on and laugh at
our immaturity in the coming years.
<!--truncate-->
## SRS Server
SRS 5.0 will be officially released as a stable version in the next two weeks. After a year of feature
freeze and six months of stability improvement, 5.0 is now ready for production use.
5.0 started development in March 2021, with key changes as follows:
* ST (State-Threads): Supports Windows/RISCV/LOONGARCH/MIPS/AppleM1 chips and multi-threading capabilities.
* SRT: Rewritten based on ST, aligning APIs and callbacks, supporting direct IP streaming, upgrading libsrt, improving latency, and completing configuration options.
* WebRTC: Supports WHIP and WHEP protocols, TCP transmission, Unity, improved error reporting, MP3 to OPUS conversion, and native OPUS support in FFmpeg.
* WHIP: Supports WHIP protocol, adapts to Larix and OBS WHIP, improves security, and supports resource deletion.
* GB28181: Supports 2016/TCP protocol, stress testing tools, and regression testing.
* Live: Fixes RBSP parsing issues, compatibility with FFmpeg timecode, ignores empty NALUs, supports HLS pseudo-streams, HLS client kicking, and resolves DASH crash issues.
There are also some bug fixes. For a detailed list of changes, please refer to the official
website's Changelog.
Looking back, it seems not much has been done in two years.
## Oryx
Oryx is an integrated video cloud that includes multiple audio and video projects, centered around
audio and video application scenarios, and offers out-of-the-box solutions.
This year, Oryx was revamped, with major changes as follows:
* Transitioned from microservices architecture to monolithic application, reducing image size by 90%, increasing development speed by 10 times, and making microservices architecture the most misleading.
* Supports Docker and script installations, DigitalOcean and Lighthouse images, BT and aaPanel plugin installations, and HELM installations.
* Tests cover all installation methods, features, and APIs.
* Supports new scenarios such as virtual live streaming, AI-generated subtitles, transcoding, callbacks, HLS clusters, and stream pulling and pushing.
If SRS is simple and easy to use, Oryx truly simplifies building audio and video businesses.
## Community
SRS started as an open-source project in 2013, officially began building an open-source community in
2020, and expanded to a global community in 2022. This year, the community has grown rapidly and is
now self-sustaining.
The number of monthly paying users worldwide and OpenCollective subscribers has increased from around
5 to 41. It is expected that in three to five years, dedicated time can be invested in supporting community
development.
This year, we also began offering paid support to the community, with overseas users paying $5 per month,
which has been well received by users.
We maintain open-source projects while also benefiting from other audio and video open-source projects.
Therefore, we will donate half of our revenue to other audio and video open-source projects we depend on,
such as FFmpeg and OBS.
Additionally, we will continue to enhance the community's AI capabilities. For example, we use GPT to
automatically translate community Issues and Pull Requests, reducing communication barriers. We also
deployed AI Talk on the official website, making it easy for everyone to experience the new capabilities
of audio, video, and AI integration.
We are grateful for the global developer support and recognition of SRS, and our development will continue
to improve.
## Cloud Service
At SRS, our goal is to establish a non-profit, open-source community dedicated to creating an all-in-one,
out-of-the-box, open-source video solution for live streaming and WebRTC online services.
Additionally, we offer a [Cloud](../cloud) service for those who prefer to use cloud service instead of building from
scratch. Our cloud service features global network acceleration, enhanced congestion control algorithms,
client SDKs for all platforms, and some free quota.
To learn more about our cloud service, click [here](../cloud).
## Conclusion
No matter how the open-source wind blows, understanding the value of what we do will ensure longevity.
Numerous open-source projects provide a never-ending foundation for the global software ecosystem. Being
a contributor to this system is a programmer's pride.
Providing paid support to users is valuable. While some regions may not appreciate it as much, we can
offer more services where it is more recognized, such as overseas.
As for professional open-source and custom development, some community developers are already doing
this on Upwork, and flexible employment is a good option.
Lastly, regarding commercialization, at least SRS won't pursue it. SRS aims to become a widely used
audio and video open-source project globally, and commercialization would hinder this goal.
In the open-source community, there is no winter in sight.
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/blog-en/2023-12-15-SRS-Ten-Years)

142
trunk/3rdparty/srs-docs/blog/2024-01-06-HLS-5s-Low-Latency.md vendored Normal file
View File

@ -0,0 +1,142 @@
---
slug: hls-5s-low-latency
title: Oryx - Unlock Universal Ultra-Low Latency - Achieving 5-Second HLS Live Streams for All - No Special Equipment Needed
authors: []
tags: [hls, llhls, live-streaming, low-latency-streaming, low-latency-hls]
custom_edit_url: null
---
# Unlock Universal Ultra-Low Latency: Achieving 5-Second HLS Live Streams for All, No Special Equipment Needed
## Introduction
In the dynamic world of live streaming, latency is a critical factor that can make or break the viewer experience.
Traditionally, achieving low latency has been a challenge, especially when striving for broad compatibility across
devices and platforms. This is where HLS comes into play, a widely adopted format known for its reliability and
compatibility. However, HLS is often associated with higher latency about 30 seconds, which can be a drawback for
real-time interactions.
<!--truncate-->
Enter the realm of low-latency HLS streaming, a game-changer for live broadcasts. In this blog, we'll explore how
you can drastically reduce HLS stream latency to as low as 5 seconds. The best part? This can be achieved using
common, highly compatible technologies, without the need for specialized equipment. We'll delve into the use of
the Oryx, a powerful yet straightforward tool that simplifies the process, making ultra-low latency HLS
streaming accessible with just a click.
If you need even lower latencies and can compromise on compatibility, there are options. For latencies between
1 to 3 seconds, HTTP-FLV is a great choice. For ultra-low latencies of about 0.5 to 1 second, WebRTC is ideal.
Each technology is suitable for different requirements and content types.
In this blog, we aim to provide you with a comprehensive guide on choosing the right streaming technology for your
business, focusing on HLS for achieving the optimal balance between low latency and high compatibility. Whether
you're streaming a live sports event, an interactive webinar, or a real-time gaming session, understanding these
technologies will empower you to deliver the best possible live streaming experience to your audience.
## Key Points
To achieve the widest compatibility, we use the most common HLS protocol, not HTTP-FLV, WebRTC, or even the LLHLS
protocol, but the most standard HLS protocol.
However, we need to change some settings at critical points, such as:
* For OBS encoder, select the x264 encoder and in the advanced settings, set the `GOP (Keyframe interval)` to `1 s`. Choose `Preset` as `fast`, `Profile` as `baseline`, and `Tune` as `zerolatency`. These settings allow OBS to generate shorter segments while maintaining compatibility.
* For Oryx, enable the HLS low latency mode. This will generate HLS segments as short as possible, around 2 seconds each. The minimum delay for HLS is about two segments, allowing for an approximate 5-second delay.
* For HLS player, such as hls.js, set it to start playing from the last segment and configure the maximum buffer time. When the accumulated delay reaches a certain threshold, enable accelerated playback to maintain a stable low latency.
The entire workflow, from streaming to the server to the player, needs optimization to achieve a 5-second low
latency. Common mistakes in this process include:
* Inability to set the encoder, like OBS, with a large GOP, such as 10 seconds, or having an excessively large encoder buffer, leading to significant overall delay.
* The Oryx is not set to low latency mode. In normal mode, the generated segment durations are longer, or some servers may not produce segments of accurate duration, preferring larger segments instead.
* Using an incorrect player, such as VLC, which has significant delay regardless of the protocol used. Not all players are suitable; we have tested that both hls.js and mpegts.js players have low latency. In the future, we will test and ensure compatibility with more players.
Let's begin achieving a 5-second HLS latency with a few simple setup steps and clicks.
## Step 1: Create Oryx by One Click
Creating an Oryx is simple and can be done with just one click if you use Digital Ocean droplet.
Please see [How to Setup a Video Streaming Service by 1-Click](./2022-04-09-Oryx-Tutorial.md) for detail.
You can also use Docker to create an Oryx with a single command line:
```bash
docker run --restart always -d -it --name oryx -v $HOME/data:/data \
-p 80:2022 -p 443:2443 -p 1935:1935 -p 8000:8000/udp -p 10080:10080/udp \
ossrs/oryx:5
```
After creating the Oryx, you can access it through `http://your-server-ip/mgmt` via a browser.
## Step 2: Setup OBS for HLS Low Latency
I suggest using OBS to publish the stream. It's a popular and powerful streaming tool that's easy to set up.
You should configure OBS as follows:
![](/img/blog-2024-01-06-01.png)
Click the `Settings` button, then go to the `Output` tab and apply the following settings:
* Set the `Output Mode` to `Advanced`. The `Simple` mode does not work for low latency HLS.
* Set the `Video Encoder` to `x264`. Note that the hardware encoder may have a larger delay.
* Set the `Keyframe interval` to `1 s`. Please note that this is the most critical setting for achieving low latency.
* Set the `CPU Usage Preset` to `fast`. This setting is helpful for reducing the delay.
* Set the `Profile` to `baseline`. This setting is helpful for reducing the delay.
* Set the `Tune` to `zerolatency`. This setting is helpful for reducing the delay.
Next, open the `Stream` tab and follow the instructions provided by the Oryx to set the server and
stream key for publishing the stream.
## Step 3: Setup Oryx in HLS Low Latency Mode
Open the Oryx and navigate to `System > HLS Low Latency`. Enable the HLS low latency mode and
click the `Submit` button.
![](/img/blog-2024-01-06-02.png)
After that, you can obtain the publish server and stream key for OBS to stream to the Oryx.
![](/img/blog-2024-01-06-03.png)
Please configure OBS and begin publishing the RTMP stream to the Oryx.
## Step 4: Setup the HLS Player
Open the Oryx `Simple Player` in the browser, and you can see the HLS stream with a 5-second delay.
![](/img/blog-2024-01-06-04.png)
The Oryx has configured the HLS player using hls.js for low latency mode. We have applied the following
settings. If you need to use your own HLS player, please configure it similarly:
* Enable `enableWorker` by setting it to `true`. This improves performance and helps avoid lag or frame drops.
* Activate `lowLatencyMode` by setting it to `true`. This enables Low-Latency HLS part playlist and segment loading.
* Set `liveSyncDurationCount` to `0` to start playback from the last segment.
* Set `maxBufferLength` to `5` to set the maximum buffer length in seconds.
* Set `maxLiveSyncPlaybackRate` to `2` to catch up if the latency is large.
For detailed information, please refer to [this commit](https://github.com/ossrs/oryx/commit/a6b709f516da3c7f36f5c3c599142296148187ee#diff-06095ca53f7d88e4f592f1a432030f541adf2060cb2dfc6c4efd86cd9f074820R40).
## Cloud Service
At SRS, our goal is to establish a non-profit, open-source community dedicated to creating an all-in-one,
out-of-the-box, open-source video solution for live streaming and WebRTC online services.
Additionally, we offer a [Cloud](../cloud) service for those who prefer to use cloud service instead of building from
scratch. Our cloud service features global network acceleration, enhanced congestion control algorithms,
client SDKs for all platforms, and some free quota.
To learn more about our cloud service, click [here](../cloud).
## Conclusion
Harnessing the Oryx, OBS, and hls.js, we've made 5-second latency HLS streaming a reality, breaking barriers in live
broadcast low latency and compatibility. This advancement marks a new era for interactive and engaging
live events, available to all without specialized equipment, setting a new experience in the streaming world.
## Contact
Join us for further conversation on [Discord](https://discord.gg/bQUPDRqy79). If you'd like to help, please
feel free to support us through donations on [OpenCollective](https://opencollective.com/srs-server).
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/blog-en/2024-01-06-HLS-5s-Low-Latency)

179
trunk/3rdparty/srs-docs/blog/2024-01-31-Browser-Voice-Driven-GPT.md vendored Normal file
View File

@ -0,0 +1,179 @@
---
slug: browser-voice-driven-gpt
title: Oryx - Speak to the Future - Transform Your Browser into a Personal Voice-Driven GPT AI Assistant with Oryx
authors: []
tags: [ai, gpt, voice, srs, oryx, streaming]
custom_edit_url: null
---
# Speak to the Future: Transform Your Browser into a Personal Voice-Driven GPT AI Assistant with Oryx
Imagine engaging with GPT in your browser through voice alone, sharing this capability with friends, or accessing
it from any location. Picture an AI assistant that makes learning spoken English enjoyable and straightforward, or
that enables seamless conversation between you and a friend speaking a different language by translating everything
instantly. Discover how to turn these exciting possibilities into reality!
<!--truncate-->
Introducing a cutting-edge to technology: our easy to build, browser-based, voice-driven GPT AI assistant,
a transformative tool in interaction. Built with the user-friendly Oryx, which effortlessly enables
HTTPS with a single click, this AI assistant is accessible on any device equipped with a browser, including PCs and
mobile phones. Its convenience allows you to communicate with your private GPT AI assistant effortlessly, anytime
and anywhere, making it the perfect solution for hands-free use and quick input. Ideal for improving your spoken
English, acting as a real-time translator, or simply serving as a smart companion, this voice-driven AI assistant
works well through conversation.
## Step 1: Create Oryx by One Click
Creating an Oryx is simple and can be done with just one click if you use Digital Ocean droplet.
Please see [How to Setup a Video Streaming Service by 1-Click](./2022-04-09-Oryx-Tutorial.md) for detail.
You can also use Docker to create an Oryx with a single command line:
```bash
docker run --restart always -d -it --name oryx -v $HOME/data:/data \
-p 80:2022 -p 443:2443 -p 1935:1935 -p 8000:8000/udp -p 10080:10080/udp \
ossrs/oryx:5
```
After creating the Oryx, you can access it through `http://your-server-ip/mgmt` via a browser.
## Step 2: Setup HTTPS for Voice-Driven GPT
When integrating voice functionality into your browser-based GPT AI assistant, security becomes paramount.
Browsers require the use of HTTPS when accessing the microphone to capture voice inputs as part of their
security strategies. This might sound complex, but with Oryx, enabling HTTPS on your site is
straightforward and hassle-free. Here's how to secure your voice-driven AI assistant with HTTPS:
1. **DNS Configuration**: Begin by adding a DNS A record for your domain. This step directs your domain name to your Oryx server. To verify that the DNS setup is correct, try accessing your Oryx with your domain name via http, like `http://your_domain_name`. If the setup is correct, this should work without any issues.
2. **Enable HTTPS**: Navigate to the `System > HTTPS > Let's Encrypt` section in your Oryx dashboard. Here, you'll simply input your domain name and hit the `Submit` button. This process initiates the automatic generation and installation of a Let's Encrypt SSL certificate for your domain, making the setup of HTTPS as easy as a single click.
3. **Verification**: With HTTPS enabled, you can now access your Oryx site securely by using `https://your_domain_name`. This secure connection ensures the security of your interactions with the GPT AI assistant.
For more details, please see [Setup HTTPS for Oryx](./2022-04-12-Oryx-HTTPS.md). By following these
steps, you'll ensure that your voice-driven GPT AI assistant is not only innovative and useful but also secure
and compliant with browser security standards.
## Step 3: Setup OpenAI Secret Key in Live Room
To use AI services, you must obtain a secret key from OpenAI. Please open the [API keys](https://platform.openai.com/api-keys)
page in your browser and click the `Create new secret key` button. Once the key is created, copy it and set it in Oryx.
Next, as illustrated in the image below, navigate to `Scenarios > LiveRoom > Create Live Room` and press the
`Create` button to create a live room for conversing with the GPT AI assistant. Alternatively, select the link to
join an existing live room.
![](/img/blog-2024-01-31-01.png)
Next, configure the OpenAI secret key in `LiveRoom > AI Assistant > AI Provider`. Afterward, click on the
`Test OpenAI Service` button, and if no errors are detected during testing, click on `Update AI Assistant`.
![](/img/blog-2024-01-31-02.png)
All you need to set up! It's quite user-friendly.
## Step 4: Open GPT AI Assistant in Browser
Now, click the `Assistant Link` button to create a link. You can either click the link to open the browser-based,
voice-driven GPT AI assistant. You can also right-click the link to copy and share the URL with other devices or
friends. You can use this on your mobile device as well.
![](/img/blog-2024-01-31-03.png)
Upon opening the AI assistant webpage, press the `Allow` button to grant microphone access to the AI assistant.
![](/img/blog-2024-01-31-04.png)
Press the `Start Chatting` button to interact with it.
![](/img/blog-2024-01-31-05.png)
Your AI assistant is now prepared; let's explore how to communicate with her.
## Step 5: How to Interact with GPT AI Assistant
When using a browser-based voice-driven GPT AI assistant on a computer, such as an Apple Mac or a Windows PC,
click on the microphone icon on the webpage. Press and hold either the `SPACE` or `R` key to begin speaking,
and release the key to stop speaking.
![](/img/blog-2024-01-31-06.png)
When utilizing the AI assistant on a mobile device browser, like iPhone or Android, press and hold the microphone
for speaking, and release to finish speaking.
![](/img/blog-2024-01-31-07.png)
Once you've submitted your message to the AI assistant, please wait briefly. The AI assistant will respond to you
using text and voice as well.
> Note: Moreover, a text input feature permits you to enter text by typing or pasting from the clipboard. Upon using
voice input, the input text field auto-fills, enabling you to edit and resend it to the AI assistant.
![](/img/blog-2024-01-31-08.png)
That's it! Now, let me present some intriguing and practical real-world examples and how to do it via your
browser-based voice-driven GTP AI assistant.
## How to Create an English Speaking Coach with a Voice-Driven GPT AI Assistant
Once you've configured your voice-driven GPT AI assistant, you can update the bellow prompt at the setting webpage
`AI Assistant > AI Instructions > Instructions`. You can get an excellent language coach who is tireless, humble,
doesn't lose temper, and patiently accompanies you in your spoken language practice. After using it for a month,
I progressed from speaking word by word to speaking sentence by sentence.
```text
I want you to act as a spoken English teacher and improver.
I will speak to you in English and you will reply to me in English to practice my spoken English.
I want you to strictly correct my grammar mistakes, typos, and factual errors.
I want you to ask me a question in your reply.
Now let's start practicing, you could ask me a question first.
Remember, I want you to strictly correct my grammar mistakes, typos, and factual errors.
```
> Note: Discover additional prompts at [awesome-chatgpt-prompts](https://github.com/f/awesome-chatgpt-prompts?#perform-as-a-spoken-english-instructor-and-enhancer).
## How to Create a Simultaneous Translator for Multilingual Users
By sharing your voice-activated GPT AI assistant to more than one user, allowing them to converse with the same AI
assistant, then you get a simultaneous translator. You need to prompt the AI assistant to convert text into various
languages.
Please change the languages in the prompt to yours, updat the prompt at `AI Assistant > AI Instructions > Instructions`:
```text
I want you to act as a language translator.
I want you to translate my text in conversational tone.
I want you to strictly translate to English and Chinese.
Keep in mind that you must translate to English and Chinese.
Remember, never answer questions but only translate.
```
> Note: Discover additional prompts at [awesome-chatgpt-prompts](https://github.com/f/awesome-chatgpt-prompts).
## Cloud Service
At SRS, our goal is to establish a non-profit, open-source community dedicated to creating an all-in-one,
out-of-the-box, open-source video solution for live streaming and WebRTC online services.
Additionally, we offer a [Cloud](../cloud) service for those who prefer to use cloud service instead of building from
scratch. Our cloud service features global network acceleration, enhanced congestion control algorithms,
client SDKs for all platforms, and some free quota.
To learn more about our cloud service, click [here](../cloud).
## Conclusion
In wrapping up, the journey to creating a personal, browser-based, voice-driven GPT AI assistant with the SRS
Stack is remarkably straightforward. From setting up HTTPS for secure communication to integrating OpenAI's
powerful GPT capabilities, each step is designed to be user-friendly and accessible. Whether aiming to improve
language abilities, enable multi-language discussions, or simply enjoy the convenience of a voice-driven GPT
AI assistant, it offers numerous possibilities for living room and streaming hosts with AI assistance. In the future,
support for connecting live audience chats to the AI assistant will also be available. You can discover more
beneficial use cases for this GPT AI assistant in real-world.
## Contact
Welcome for more discussion at [discord](https://discord.gg/bQUPDRqy79).
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/blog-en/2024-01-31-browser-voice-driven-gpt)

109
trunk/3rdparty/srs-docs/blog/2024-02-21-Dubbing-Translating.md vendored Normal file
View File

@ -0,0 +1,109 @@
---
slug: dubbing-translating
title: Oryx - Revolutionize Video Content with Oryx - Effortless Dubbing and Translating to Multiple Languages Using OpenAI
authors: []
tags: [dubbing, translating, ai, gpt, voice, srs, oryx, multilingual]
custom_edit_url: null
---
# Revolutionize Video Content with Oryx: Effortless Dubbing and Translating to Multiple Languages Using OpenAI
## Introduction
In today's globalized world, content creation is no longer limited by geographical boundaries. As a result,
engaging a diverse, international audience has become increasingly important for video creators. Whether
you're a YouTuber, filmmaker, or e-learning content provider, being able to make your content accessible in
multiple languages can greatly enhance its impact. That's where Oryx comes in – with its advanced
multilingual dubbing and translation services powered by OpenAI, breaking language barriers is now simpler
and more cost-effective than ever.
<!--truncate-->
In this blog, we will discuss how Oryx supports dubbing and translating video files from one language to
another, such as converting a video with English speech to Chinese subtitles and speech. We will explore how
this technology can help you appeal to a broader audience and unlock the full potential of your content, all
while being incredibly easy to use and wallet-friendly. So, buckle up as we dive into the world of multilingual
video content with Oryx!
## Step 1: Create Oryx by One Click
Creating an Oryx is simple and can be done with just one click if you use Digital Ocean droplet.
Please see [How to Setup a Video Streaming Service by 1-Click](./2022-04-09-Oryx-Tutorial.md) for detail.
You can also use Docker to create an Oryx with a single command line:
```bash
docker run --restart always -d -it --name oryx -v $HOME/data:/data \
-p 80:2022 -p 443:2443 -p 1935:1935 -p 8000:8000/udp -p 10080:10080/udp \
ossrs/oryx:5
```
After creating the Oryx, you can access it through `http://your-server-ip/mgmt` via a browser.
## Step 2: Upload Video Source File
First, please upload the video source file, click the `Dubbing > Video Source > Upload local file > Upload File` to upload.
![](/img/blog-2024-02-21-01.png)
> Note: You can also use other tools to upload the file under the `/data` directory, and use the `Use server file` to directly use it.
## Step 3: Setup OpenAI Secret Key for Dubbing
To use AI services, you must obtain a secret key from OpenAI. Please open the [API keys](https://platform.openai.com/api-keys)
page in your browser and click the `Create new secret key` button. Once the key is created, copy it and set it in Oryx.
Next, configure the OpenAI secret key in `Dubbing Settings > ASR Settings`. Afterward, click on the
`Test OpenAI Service` button, and if no errors are detected during testing, click on `Update` button.
![](/img/blog-2024-02-21-02.png)
## Step 4: Setup the Language to Translate
Setup the video source language from `Dubbing Settings > ASR Settings > Language`, and set the target language
to translate in `Dubbing Settings > Multilingual Translation > Instructions` by setting the prompts, click on
`Update` button.
![](/img/blog-2024-02-21-03.png)
## Step 5: Start Dubbing and Download Translated Video
Click the `Start Dubbing` button, as bellow described.
![](/img/blog-2024-02-21-04.png)
If translated audio segment is longer than the original audio, you can click the `Rephrase` or `Merge next` to
make it shorter, as bellow described.
![](/img/blog-2024-02-21-05.png)
After all segments are ready, no red color background segments, you will be able to download the translated video,
click the `Download Dubbing Video` button.
![](/img/blog-2024-02-21-06.png)
## Cloud Service
At SRS, our goal is to establish a non-profit, open-source community dedicated to creating an all-in-one,
out-of-the-box, open-source video solution for live streaming and WebRTC online services.
Additionally, we offer a [Cloud](../cloud) service for those who prefer to use cloud service instead of building from
scratch. Our cloud service features global network acceleration, enhanced congestion control algorithms,
client SDKs for all platforms, and some free quota.
To learn more about our cloud service, click [here](../cloud).
## Conclusion
In conclusion, Oryx's support for dubbing and translating video files to multiple languages, including the
conversion of English speech to Chinese subtitles and speech, is a game-changing solution for content creators
looking to engage a wider audience. By leveraging the advanced capabilities of OpenAI services, Oryx ensures
an efficient, cost-effective, and user-friendly approach to video localization. This remarkable technology not only
breaks language barriers but also fosters cultural exchange and global communication, propelling your content into
new horizons and opening doors to endless possibilities.
## Contact
Welcome for more discussion at [discord](https://discord.gg/bQUPDRqy79).
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/blog-en/2024-02-21-dubbing-translating)

107
trunk/3rdparty/srs-docs/blog/2024-05-20-OCR-Video-Streams.md vendored Normal file
View File

@ -0,0 +1,107 @@
---
slug: ocr-video-streams
title: Oryx - Leveraging OpenAI for OCR and Object Recognition in Video Streams
authors: []
tags: [ocr, ai, gpt, srs, oryx]
custom_edit_url: null
---
# Leveraging OpenAI for OCR and Object Recognition in Video Streams using Oryx
## Introduction
In today's digital world, videos are everywhere. From social media clips to live broadcasts, we consume a
vast amount of video content daily. But have you ever wondered how we can make sense of all the information
in these videos? This is where AI comes in. With the help of artificial intelligence, we can now recognize
text, identify objects, and even describe scenes in video streams.
<!--truncate-->
One powerful tool that makes this process easy is Oryx. In this blog, we'll explore how Oryx can help you
perform OCR (Optical Character Recognition) on video streams, allowing you to extract valuable information
in real-time.
## Step 1: Create Oryx by One Click
Creating an Oryx is simple and can be done with just one click if you use Digital Ocean droplet.
Please see [How to Setup a Video Streaming Service by 1-Click](./2022-04-09-Oryx-Tutorial.md) for detail.
You can also use Docker to create an Oryx with a single command line:
```bash
docker run --restart always -d -it --name oryx -v $HOME/data:/data \
-p 80:2022 -p 443:2443 -p 1935:1935 -p 8000:8000/udp -p 10080:10080/udp \
ossrs/oryx:5
```
After creating the Oryx, you can access it through `http://your-server-ip/mgmt` via a browser.
## Step 2: Publish a Live Stream to Oryx
You can use OBS or FFmpeg to publish a live stream to Oryx. You can also set up HTTPS and publish via WebRTC.
![](/img/blog-2024-05-20-01.png)
Once the stream is published, you can preview it using an H5 player or VLC.
Please see [How to Setup a Video Streaming Service by 1-Click](./2022-04-09-Oryx-Tutorial.md) for detail.
## Step 3: Setup OpenAI Secret Key for OCR
To use OCR, you must obtain a secret key from OpenAI. Please open the [API keys](https://platform.openai.com/api-keys)
page in your browser and click the `Create new secret key` button. Once the key is created, copy it and set it in Oryx.
Then, click the `Test OpenAI Service` button, as shown in the picture below.
![](/img/blog-2024-05-20-02.png)
If the test is successful, you can click the `Start OCR` button to start the OCR process.
## Step 4: Setup AI Instructions for OCR
Once you've configured your GPT AI assistant, you can update the bellow prompt at the setting webpage
`Service Settings > AI Instructions > Instructions`.
![](/img/blog-2024-05-20-03.png)
To recognize text in video streams, you can use the following instructions:
```text
Recognize the text in the image. Output the identified text directly.
```
Please remember to restart the OCR after updating the AI settings.
## Step 5: View OCR Results by Callback
Once the OCR process is complete, you can view the results by setting up a callback URL in Oryx.
![](/img/blog-2024-05-20-04.png)
You can also view the last OCR result in the dashboard.
![](/img/blog-2024-05-20-05.png)
## Cloud Service
At SRS, our goal is to establish a non-profit, open-source community dedicated to creating an all-in-one,
out-of-the-box, open-source video solution for live streaming and WebRTC online services.
Additionally, we offer a [Cloud](../cloud) service for those who prefer to use cloud service instead of building from
scratch. Our cloud service features global network acceleration, enhanced congestion control algorithms,
client SDKs for all platforms, and some free quota.
To learn more about our cloud service, click [here](../cloud).
## Conclusion
In conclusion, using AI to recognize text and objects in video streams is a game-changer. It helps us quickly
and accurately extract valuable information from videos. Tools like Oryx make this process simple and efficient,
allowing you to publish live streams and get real-time OCR results with ease. Whether you're looking to identify
people, read text, or describe scenes, AI-powered OCR can transform how you interact with video content. By
leveraging these technologies, you can unlock new possibilities and insights from the videos you encounter
every day.
## Contact
Welcome for more discussion at [discord](https://discord.gg/bQUPDRqy79).
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/blog-en/24-05-20-OCR-Video-Streams)

444
trunk/3rdparty/srs-docs/blog/2024-06-15-SRS-Smart-Pointer.md vendored Normal file
View File

@ -0,0 +1,444 @@
---
slug: smart-pointer
title: SRS - Fix Memory Leaks with Smart Pointers
authors: []
tags: [srs, memory, smart-pointer]
custom_edit_url: null
---
# Fix Memory Leaks with Smart Pointers
After 8 years, we resolved the memory leak issue in SRS using our own implementation of basic Smart Pointers,
maintaining the project's manageability.
## Introduction
Each stream on the SRS server has a Source object that manages the stream's lifecycle. To keep the logic and code
simple, SRS did not release the Source object; with a large number of streams, such as constantly changing streaming
addresses, this led to continuous memory growth and leaks.
<!--truncate-->
Previously, the workaround was to restart the service late at night. SRS supports [Gracefully Quit](https://github.com/ossrs/srs/issues/1579#issuecomment-587414898),
which restarts the service when there are no connections, but this did not completely solve the problem.
To address this issue, we introduced Smart Pointers to manage the lifecycle of Source objects. We did not use C++ 11
because SRS needs to compile in various environments. Instead, we implemented a simplified version of Smart Pointers,
supporting only some features.
## Design
Before any work addressing this issue, we need refine the shared ptr of SRS, which is used in RTMP shared message,
GB sessions, and in future source objects.
Refer to [Using C++11’s Smart Pointers](https://public.websites.umich.edu/~eecs381/handouts/C++11_smart_ptrs.pdf),
there are three varieties of smart pointers:
* Shared ptr: Akin to `SrsSharedPtrMessage` used for RTMP message, and `SrsLazyObjectWrapper` for GB28181.
* Weak ptr: No such ptr in SRS before 5.0 version. We can avoid this by removing any circle reference of pointer.
* Unique ptr: The corresponding ptr is `SrsAutoFree` that free the ptr in the local scope.
If we carefully design and limit the usage of smart ptr, such as no cycle link that means we do not need weak ptr,
we can archive a simple and easy to maintain smart ptr for SRS. We also consider bellow features:
* Inheritance: Do not use inheritance with smart pointer, although we can write correct code, but it's complex to discuss.
* Comparing: Do not support comparing smart pointers, because we only need to manage the memory automatically.
* make_shared: Do not support this helper function, because we do not consider performance issue by new operator.
* shared_from_this: Do not support this helper template, because we do not need this feature.
* make_unique: Do not support this, because we allow naked new operator, and carefully code review is required.
Again, we don't want to switch to C++11 because I think the modern C++ 11/14/17/20 is really a horrible thing that
does not fix anything, but introduces a lot of bad grammar sugar. We do not want any grammar sugar, which is very
harmful for communication. We have experienced a lot of disaster of smart pointers and sugars, so we want to keep
the usage very simple:
1. No grammar sugar: No weak ptr, no make shared, no make unique, no inheritance, no comparing, no circle reference, no C++11/14/17/20/22 etc.
2. Follow the C++ standard API if any API is really required, do not invent new wheels, no new functions and names.
3. Carefully code review, programmer should take responsibility for code and memory issues.
In the other hand, we should not reinvent wheels especially for smart ptr, so we must use almost the same API of
C++ standard library. That is why we should learn from C++11 and refactor the similar smart ptrs in SRS.
Smart pointers might seem simple when they’re just about memory management, but when you delve into inheritance,
copying, comparison, performance, circular references, pointer conversion, creation, and the purism of "no naked new",
their capabilities become significantly richer. In reality, the main issues with C++ programs stem from programmers
messing around, and this purism along with various syntactic sugar makes it hard to notice when they are.
Most problems can be addressed with something as straightforward as an AK47, yet there's an obsession with acquiring
more advanced weaponry, which leads to a situation where, on the battlefield, you can’t even fire a shot due to jams
and blowbacks. This is because it’s very hard to spot when programmers are messing about in companies, with large
amounts of code being submitted, the usage of various new features, and tight deadlines.
The true gates of hell in C++ are not the limited old features of C, but its plethora of new features.
## Shared Ptr
We implemented a simple Shared Ptr that supports reference counting and automatic release, based on
[#6834ec2](https://github.com/ossrs/srs/commit/6834ec208d67fa47c21536d1f1041bb6d60c1834).
```cpp
template<class T>
class SrsSharedPtr
{
private:
// Pointer to the object.
T* ptr_;
// Reference count of the object.
uint32_t* ref_count_;
```
Usage is similar to std::shared_ptr, but it supports fewer interfaces:
```cpp
SrsSharedPtr<MyClass> ptr(new MyClass());
ptr->do_something();
SrsSharedPtr<MyClass> cp = ptr;
cp->do_something();
```
It also involves copy constructor, assignment, and move constructor, as well as some operator overloading.
For details, refer to the code and the unit test examples. Overall, this part is relatively simple to implement.
## Shared Resource
In addition to the Shared Ptr smart pointer, we also support Shared Resource, which mainly implements the
ISrsResource interface and can be released by the ResourceManager. Refer to [#6834ec2](https://github.com/ossrs/srs/commit/6834ec208d67fa47c21536d1f1041bb6d60c1834).
```cpp
template<typename T>
class SrsSharedResource : public ISrsResource
{
private:
SrsSharedPtr<T> ptr_;
```
In fact, Shared Resource and Shared Ptr have exactly the same interface, but we did not use inheritance; instead,
we used composition. Using it is the same as using Shared Ptr, but it can be managed by a Manager:
```cpp
SrsSharedResource<MyClass>* ptr = new SrsSharedResource<MyClass>(new MyClass());
(*ptr)->do_something();
ISrsResourceManager* manager = ...;
manager->remove(ptr);
```
In practical application scenarios, resources are often managed by a coroutine. For example, a GB SIP connection
will start a separate coroutine to serve this connection. Similarly, there are GB Media connections, GB Session
sessions, RTC TCP connections, etc. We created an Executor to implement this common logic:
```cpp
SrsExecutorCoroutine::SrsExecutorCoroutine(ISrsResourceManager* m, ISrsResource* r)
{
resource_ = r;
manager_ = m;
trd_ = new SrsSTCoroutine("ar", this, resource_->get_id());
}
SrsExecutorCoroutine::~SrsExecutorCoroutine()
{
manager_->remove(resource_);
srs_freep(trd_);
}
srs_error_t SrsExecutorCoroutine::cycle()
{
srs_error_t err = handler_->cycle();
manager_->remove(this);
return err;
}
```
Therefore, we can easily use the Executor to manage this type of Resource:
```cpp
SrsGbSipTcpConn* raw_conn = new SrsGbSipTcpConn();
SrsSharedResource<SrsGbSipTcpConn>* conn = new SrsSharedResource<SrsGbSipTcpConn>(raw_conn);
SrsExecutorCoroutine* executor = new SrsExecutorCoroutine(_srs_gb_manager, conn, raw_conn, raw_conn);
if ((err = executor->start()) != srs_success) {
srs_freep(executor);
return srs_error_wrap(err, "gb sip");
}
```
It is worth emphasizing that the Executor and Smart Ptr are not inherently related; they are designed as
a mechanism to solve a common scenario. Otherwise, multiple places would need to implement repetitive logic,
making it more complex. Additionally, since the Executor references ISrsResource, we use the Resource Ptr
pointer object instead of directly using the Shared Ptr pointer.
## GB28181
GB28181's SIP and Media are two separate protocols and transmission channels. This involves independent lifecycles
and management of objects. Refer to [#4080](https://github.com/ossrs/srs/pull/4080) for details, as illustrated in
the diagram below:
![](/img/blog-2024-06-15-01.png)
SIPTcpConn is the SIP object for GB, usually listening on TCP port 5060, responsible for device registration and
information collection. MediaTcpConn is the media transmission object for GB, transmitting PS streams. The GB
Session is created and managed by SIPTcpConn or MediaTcpConn objects.
In practice, Session, SIPTcpConn, and MediaTcpConn are managed as Shared Resource objects. The Session uses Shared
Resource to reference SIPTcpConn and MediaTcpConn. However, SIPTcpConn and MediaTcpConn reference the Session using
raw pointers, not Shared Resource, because we have not implemented Weak Ptr and do not support circular references.
## WebRTC over TCP
WebRTC over UDP is the default transport method. Since UDP is connectionless, SRS only needs an RTC Connection
object to manage the RTC session. For WebRTC over TCP, an additional TCP connection is added, managed by `SrsRtcTcpConn`.
Refer to [#4083](https://github.com/ossrs/srs/pull/4083).
`SrsRtcConnection` uses a Shared Resource to reference the `SrsRtcTcpConn` object, while `SrsRtcTcpConn` directly
references the raw pointer of `SrsRtcConnection` because the lifecycle of `SrsRtcConnection` is longer.
```cpp
class SrsRtcTcpConn
{
private:
// Since the session references this object, we should directly use the session pointer.
SrsRtcConnection* session_;
};
class SrsRtcTcpNetwork: public ISrsRtcNetwork
{
private:
SrsSharedResource<SrsRtcTcpConn> owner_;
};
```
Since we have not implemented `shared_from_this`, we need to pass the Shared Resource to `SrsRtcTcpConn`,
which is ultimately managed by the Executor and `SrsRtcConnection`. As `SrsRtcTcpConn` starts a coroutine to
serve this object, we use the Executor to manage it:
```cpp
resource = new SrsRtcTcpConn(new SrsTcpConnection(stfd2), ip, port);
SrsRtcTcpConn* raw_conn = dynamic_cast<SrsRtcTcpConn*>(resource);
SrsSharedResource<SrsRtcTcpConn>* conn = new SrsSharedResource<SrsRtcTcpConn>(raw_conn);
SrsExecutorCoroutine* executor = new SrsExecutorCoroutine(_srs_rtc_manager, conn, raw_conn, raw_conn);
if ((err = executor->start()) != srs_success) {
srs_freep(executor);
return srs_error_wrap(err, "start executor");
}
```
Before using Smart Ptr, we needed to release the references between `SrsRtcConnection` and `SrsRtcTcpConn` when
either object was destroyed. With Smart Ptr, this logic is no longer needed; simply releasing `SrsRtcTcpConn` will
automatically handle the cleanup.
## SRT Source
The SRT Source also involves cleanup, but it is relatively simple; just switch to using Shared Ptr. For details,
refer to [#4084](https://github.com/ossrs/srs/pull/4084).
```cpp
class SrsSrtSourceManager
{
public:
virtual srs_error_t fetch_or_create(SrsRequest* r, SrsSharedPtr<SrsSrtSource>& pps);
virtual void eliminate(SrsRequest* r);
};
SrsSharedPtr<SrsSrtSource> srt;
if ((err = _srs_srt_sources->fetch_or_create(r, srt)) != srs_success) {
return srs_error_wrap(err, "create source");
}
```
It is important to note that the Source actually manages the Consumer, so in the Consumer, we use the raw pointer
of the Source:
```cpp
class SrsSrtConsumer
{
private:
// Because source references to this object, so we should directly use the source ptr.
SrsSrtSource* source_;
};
```
Release the Source object when there is no streaming or playback:
```cpp
void SrsSrtSource::on_consumer_destroy(SrsSrtConsumer* consumer)
{
// Destroy and cleanup source when no publishers and consumers.
if (can_publish_ && consumers.empty()) {
_srs_srt_sources->eliminate(req);
}
}
void SrsSrtSource::on_unpublish()
{
// Destroy and cleanup source when no publishers and consumers.
if (can_publish_ && consumers.empty()) {
_srs_srt_sources->eliminate(req);
}
}
```
The logic for releasing the Live Source is slightly different (it will be the same in the future), but the use of
smart pointers is consistent.
## WebRTC Source
Similar to SRT, the WebRTC Source is also relatively simple and only needs to be modified to use a shared pointer.
For more details, refer to [#4085](https://github.com/ossrs/srs/pull/4085).
```cpp
class SrsRtcSourceManager
{
public:
virtual srs_error_t fetch_or_create(SrsRequest* r, SrsSharedPtr<SrsRtcSource>& pps);
virtual SrsSharedPtr<SrsRtcSource> fetch(SrsRequest* r);
virtual void eliminate(SrsRequest* r);
};
```
It is important to note that the Source actually manages the Consumer, so in the Consumer, we use the raw pointer
of the Source:
```cpp
class SrsRtcConsumer
{
private:
// Because source references to this object, so we should directly use the source ptr.
SrsRtcSource* source_;
};
```
The WebRTC Source Manager supports a `fetch` API, which might return a null pointer, for example:
```cpp
SrsSharedPtr<SrsRtcSource> source = _srs_rtc_sources->fetch(ruc->req_);
is_rtc_stream_active = (source.get() && !source->can_publish());
```
When there is no publishing or playing, release the Source object:
```cpp
void SrsRtcSource::on_consumer_destroy(SrsRtcConsumer* consumer)
{
// Destroy and cleanup source when no publishers and consumers.
if (!is_created_ && consumers.empty()) {
_srs_rtc_sources->eliminate(req);
}
}
void SrsRtcSource::on_unpublish()
{
// Destroy and cleanup source when no publishers and consumers.
if (!is_created_ && consumers.empty()) {
_srs_rtc_sources->eliminate(req);
}
}
```
The logic for releasing the Live Source is slightly different (it will be made the same in the future), but the
use of smart pointers is consistent.
## Live Source
Live Source is the most complex improvement, primarily because HTTP Streaming also uses Source. For more details,
refer to [#4089](https://github.com/ossrs/srs/pull/4089).
![](/img/blog-2024-06-15-02.png)
Therefore, we need to remove some unnecessary references to Source and instead get it from the manager:
```cpp
srs_error_t SrsLiveStream::do_serve_http(ISrsHttpResponseWriter* w, ISrsHttpMessage* r)
{
SrsSharedPtr<SrsLiveSource> live_source = _srs_sources->fetch(req);
if (!live_source.get()) {
return srs_error_new(ERROR_NO_SOURCE, "no source for %s", req->get_stream_url().c_str());
}
};
```
The manager is defined as follows. Note that it uses a Timer to check and release Source, which is different from the
logic in SRT/RTC. This will be unified in the future:
```cpp
class SrsLiveSourceManager : public ISrsHourGlass
{
public:
virtual srs_error_t fetch_or_create(SrsRequest* r, ISrsLiveSourceHandler* h, SrsSharedPtr<SrsLiveSource>& pps);
virtual SrsSharedPtr<SrsLiveSource> fetch(SrsRequest* r);
};
```
It is important to note that Source actually manages objects like Consumer/OriginHub/Edge, so we use raw pointers to
Source in these objects:
```cpp
class SrsEdgeIngester : public ISrsCoroutineHandler
{
private:
// Because source references this object, we should directly use the source ptr.
SrsLiveSource* source_;
};
class SrsEdgeForwarder : public ISrsCoroutineHandler
{
private:
// Because source references this object, we should directly use the source ptr.
SrsLiveSource* source_;
};
class SrsLiveConsumer : public ISrsWakable
{
private:
// Because source references this object, we should directly use the source ptr.
SrsLiveSource* source_;
};
class SrsOriginHub : public ISrsReloadHandler
{
private:
// Because source references this object, we should directly use the source ptr.
SrsLiveSource* source_;
};
```
The manager uses a timer to check and release Source:
```cpp
srs_error_t SrsLiveSourceManager::notify(int event, srs_utime_t interval, srs_utime_t tick)
{
srs_error_t err = srs_success;
std::map< std::string, SrsSharedPtr<SrsLiveSource> >::iterator it;
for (it = pool.begin(); it != pool.end();) {
SrsSharedPtr<SrsLiveSource>& source = it->second;
if (source->stream_is_dead()) {
const SrsContextId& cid = source->source_id();
srs_trace("cleanup dead source, id=[%s], total=%d", cid.c_str(), (int)pool.size());
pool.erase(it++);
} else {
++it;
}
}
return err;
}
```
This release logic is different from SRT/RTC, but it will be unified in the future. However, the use of smart
pointers is consistent.
## Conclusion
To simplify the process, SRS initially did not release the Source object. By introducing Smart Pointers, this issue
was finally resolved. By applying business constraints and combining raw pointers with Smart Pointers, we avoided the
complexity of multiple Smart Pointer functionalities. Overall, the complexity introduced by this change is manageable,
and future maintainability is also good.
## Contact
Welcome for more discussion at [discord](https://discord.gg/bQUPDRqy79).
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/blog-en/24-06-15-SRS-Smart-Pointer)

115
trunk/3rdparty/srs-docs/blog/2025-02-10-GSoC.md vendored Normal file
View File

@ -0,0 +1,115 @@
---
slug: GSoC-2025
title: GSoC-2025
authors: []
tags: [GSoC]
custom_edit_url: null
---
# GSoC
## Project Description
SRS is a simple, high efficiency and realtime video server, supports RTMP/WebRTC/HLS/HTTP-FLV/SRT.
<!--truncate-->
## Information for Students
### Getting Started
1. **Get to know SRS.** If you are a student interested in contributing to SRS, it is recommended to start by join to the SRS [Discord](https://discord.gg/DfJFjpxmC7) and exploring both the codebase and the development workflow. Feel free to contact us if you have any questions. Also do not hesitate to answer questions from other students on our [Discord](https://discord.gg/DfJFjpxmC7) channel if you know the answer to something.
2. **Find a project.** Listed on this page are mentored and un-mentored projects. Mentored projects are well-defined and mentor(s) have already volunteered. Un-mentored projects are additional ideas you may want to consider, but you will have to contact us to find a mentor. You can also propose your own project, if you can think of one that better fits your interest and skill level. If a project description is unclear or you have any questions, please get in touch with its mentor and/or join our [Discord](https://discord.gg/DfJFjpxmC7) channel at *#general*.
3. **Contact us.** If you decide on a project, get in touch with the community and let us know. If you want to work on a qualification task, let the respective mentor know so we can avoid duplicated efforts.
4. **Apply.** Students should apply definitely before deadline on April 8th. The "work" period begins on June 2th and ends in September. Take a look at [GSoC timeline](https://developers.google.com/open-source/gsoc/timeline) for additional information. Note, make sure you apply to Google before April 19th, even if you have not yet finished your qualification task. Please apply as soon as possible: Applications can be improved until the 19th but not afterwards!
> **Note**: A friendly reminder that while the application to GSoC is important for you and GSoC, SRS mentors will not base their decision solely on the GSoC application. We will judge applicants based on their qualification tasks to understand their abilities in coding, learning the tools, communication skills etc. So please do not worry about your application being perfect for us. Although it is very important to follow GSoC's application rules so they can pay you.
### Qualification Tasks
In order to get accepted you have to complete a small qualification task which in all cases include sending a patch to the development mailing list. SRS development can be quite challenging and the qualification task helps us figure out whether you are motivated enough and have the potential to deliver successfully.
The qualification tasks are usually shown in the project description. Contact the respective mentor(s) for assistance on getting a related qualification task or if you want to propose your own. You can also browse the [SRS Bug Issue](https://github.com/ossrs/srs) for qualification task ideas. In general qualification tasks should include submitting a patch to the [SRS Bug Issue](https://github.com/ossrs/srs) which passes review and is accepted into the SRS codebase. It will be common for such patches to need multiple iterations of submissions and reviews, so don't wait too long with the first submission! Note, please avoid picking a qualification task which another student is already working on, each student should work on a different qualification task.
### Development
If you are selected for a particular project then you are not only expected to present a working implementation but you should also submit your work for inclusion for the SRS codebase. This should be done at least 2-3 weeks before the end of the second work period by sending patches to the [SRS Bug Issue](https://github.com/ossrs/srs)&[Discord](https://discord.gg/DfJFjpxmC7) where the SRS community and your mentor will review your work. You will likely be asked to make some changes and resend improved versions. If you feel that no consensus is reached about how something should be done then follow the advice of your mentor.
In order to create good quality patches make sure to read the [Developer Documentation](../docs/v5/doc/getting-started).
### Contacting SRS
If you have questions or comments feel free to contact us via our mail, Discord one of the SRS GSoC admins:
* **Discord:** *#general*
* **SRS GSoC Admins:** Winlin (winlin in #general on [Discord](https://discord.gg/DfJFjpxmC7), winlinvip at gmail dot com ), Devin (Devin in *#general* on [Discord](https://discord.gg/DfJFjpxmC7), devin at ossrs dot io), LiuQi (Steven in *#general* on [Discord](https://discord.gg/DfJFjpxmC7), lq at chinaffmpeg dot org)
You may also contact a mentor directly if you have questions specifically related to one of the projects listed on this page.
## Mentored Project Ideas
This section lists well-defined projects that have one or more available mentors. If you are new to SRS, and have relatively little experience with multimedia, you should favor one of these ideas rather than propose your own. Contact the respective mentor(s) to get more information about the project and the requested qualification task.
### 1. YAML Configuration File Support
|Name of project|YAML Configuration File Support|
| :---- | :----- |
|Project Description|SRS currently uses a proprietary configuration format similar to NGINX. YAML is a widely adopted configuration format, familiar to many users.|
|Mentor|Junqin Zhang(chundonglinlin@163.com)|
|Backup Mentor|Haibo Chen(495810242@qq.com)|
|Required Skills|Familiar with yaml file format and its parsing method, skilled in C++ programming.|
|Difficulty|Beginner|
|Expected Outcome|Convert existing SRS configuration files to YAML format with proper parsing and execution.|
|Qualification Task|Implement YAML file parsing.|
### 2. HLS LLHLS mode
|Name of project|HLS support LLHLS mode|
| :---- | :----- |
|Project Description|HLS, developed by Apple, is a method for file-based live streaming with high latency. LLHLS significantly reduces this latency.|
|Mentor|Zhihong Xiao(hondaxiao@tencent.com)|
|Backup Mentor|Haibo Chen(495810242@qq.com)|
|Required Skills|Familiarity with HLS and LLHLS, strong ability to read standards documentation, proficient in C++ programming|
|Difficulty|Advanced|
|Expected Outcome|Achieve playback on LLHLS-supported players with expected latency.|
|Qualification Task|Complete LLHLS encoding, re-muxing, and manifest file generation.|
### 3. Coroutine-based DNS Resolution in SRS Network Library ST (State-Thread)
|Name of project|Coroutine-based DNS Resolution in SRS Network Library ST (State-Thread)|
| :---- | :----- |
|Project Description|ST (State-Thread) is a coroutine library with coroutine-based wrappers for common network interfaces. Currently, DNS resolution is not adapted to ST and needs full coroutine support.|
|Mentor|Zhihong Xiao (hondaxiao@tencent.com)|
|Backup Mentor|Winlin (winlinvip@gmail.com)|
|Required Skills|Familiarity with DNS resolution process, understanding of coroutine principles, proficient in C++ programming|
|Difficulty|Intermediate|
|Expected Outcome|Implement coroutine-based DNS resolution for all DNS operations in the code.|
|Qualification Task|Develop a DNS resolution interface based on State-Thread.|
### 4. HLS Support for CMAF
|Name of project|HLS Support for CMAF|
| :---- | :----- |
|Project Description|CMAF (Common Media Application Format) is an international standard proposed by industry leaders like Microsoft and Apple, approved in 2017. Implementing CMAF in SRS allows compatibility with more platforms.|
|Mentor|Zhihong Xiao(hondaxiao@tencent.com)|
|Backup Mentor|Steven Liu(lq@chinaffmpeg.org)|
|Required Skills|Familiarity with HLS, CMAF, MP4 standards, strong ability to read standards documentation, proficient in C++ programming|
|Difficulty|Advanced|
|Expected Outcome|Output CMAF-HLS manifests and corresponding packaging formats.|
|Qualification Task|Complete CMAF packaging and CMAF-HLS manifest file generation.|
### 5. Enhanced RTMP (V2)
|Name of project|Enhanced RTMP (V2)|
| :---- | :----- |
|Project Description|Implement Enhanced RTMP (V2) to support advanced streaming capabilities.|
|Mentor|Zhihong Xiao (hondaxiao@tencent.com)|
|Backup Mentor|Winlin (winlinvip@gmail.com)|
|Required Skills|Familiarity with Enhanced RTMP (V2) standard, strong ability to read standards documentation, proficient in C++ programming|
|Difficulty|Advanced|
|Expected Outcome|Support streaming, playback, and relay using Enhanced RTMP (V2).|
|Qualification Task|Implement Enhanced RTMP (V2) features and successfully achieve streaming, playback, and relay.|
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/blog-en/22-02-10-GSoC)

178
trunk/3rdparty/srs-docs/doc/arm.md vendored Normal file
View File

@ -0,0 +1,178 @@
---
title: ARM and CrossBuild
sidebar_label: ARM and CrossBuild
hide_title: false
hide_table_of_contents: false
---
# SRS for linux-arm
How to run SRS on ARM pcu?
* Run SRS on ARM: Client can play stream from ARM server.
## Why run SRS on ARM?
The use scenario:
* Run SRS on ARM server, see [#1282](https://github.com/ossrs/srs/issues/1282#issue-386077124).
* Crossbuild for ARM embeded device, see [#1547](https://github.com/ossrs/srs/issues/1547#issue-543780097).
## RaspberryPi
User is able to build and run SRS on RespberryPI. Please don't use crossbuild.
<a name="armv8-and-aarch64"></a>
## ARM Server: armv7, armv8(aarch64)
User is able to build and run SRS on ARM servers. Please don't use crossbuild.
```
./configure && make
```
Build SRS in ARM server docker, see [aarch64](https://github.com/ossrs/dev-docker/tree/aarch64#usage)
```
docker run -it --rm -v `pwd`:/srs -w /srs ossrs/srs:aarch64 \
bash -c "./configure && make"
```
For armv8 or aarch64, user should specify the arch, if the CPU arch is not identified automatically, see [#1282](https://github.com/ossrs/srs/issues/1282#issuecomment-568891854):
```bash
./configure --extra-flags='-D__aarch64__' && make
```
Run SRS:
```
./objs/srs -c conf/console.conf
```
Publish stream:
```
ffmpeg -re -i doc/source.flv -c copy -f flv rtmp://127.0.0.1:1935/live/livestream
```
Play stream：[http://localhost:8080/live/livestream.flv](http://localhost:8080/players/srs_player.html?autostart=true&stream=livestream.flv&port=8080&schema=http)
![image](https://user-images.githubusercontent.com/2777660/72774670-7108c980-3c46-11ea-9e8b-d4fb3a475ea2.png)
<a name="ubuntu-cross-build-srs"></a>
## Ubuntu Cross Build SRS: ARMv8(aarch64)
Build SRS in docker(Ubuntu20(xenial))：
```
cd ~/git/srs/trunk
docker run --rm -it -v `pwd`:/srs -w /srs ossrs/srs:ubuntu20 bash
```
Install toolchain(optional):
```
apt-get install -y gcc-aarch64-linux-gnu g++-aarch64-linux-gnu
```
Cross build SRS:
```
./configure --cross-build --cross-prefix=aarch64-linux-gnu-
make
```
Run SRS on [aarch64 docker](https://hub.docker.com/r/arm64v8/ubuntu):
```
cd ~/git/srs/trunk && docker run --rm -it -v `pwd`:/srs -w /srs \
-p 1935:1935 -p 1985:1985 -p 8080:8080 arm64v8/ubuntu \
./objs/srs -c conf/console.conf
```
Publish stream:
```
ffmpeg -re -i doc/source.flv -c copy -f flv rtmp://127.0.0.1:1935/live/livestream
```
Play stream：[http://localhost:8080/live/livestream.flv](http://localhost:8080/players/srs_player.html?autostart=true&stream=livestream.flv&port=8080&schema=http)
## Ubuntu Cross Build SRS: ARMv7
Cross build ST and OpenSSL on Ubuntu20.
Build SRS in docker(Ubuntu20(xenial))：
```
cd ~/git/srs/trunk
docker run --rm -it -v `pwd`:/srs -w /srs ossrs/srs:ubuntu20 bash
```
Install toolchain(optional), for example [Acqua or RoadRunner board](https://www.acmesystems.it/arm9_toolchain)
```
apt-get install -y gcc-arm-linux-gnueabihf g++-arm-linux-gnueabihf
```
Cross build SRS:
```
./configure --cross-build --cross-prefix=arm-linux-gnueabihf-
make
```
Run SRS on [ARMv7 docker](https://hub.docker.com/r/armv7/armhf-ubuntu):
```
cd ~/git/srs/trunk && docker run --rm -it -v `pwd`:/srs -w /srs \
-p 1935:1935 -p 1985:1985 -p 8080:8080 armv7/armhf-ubuntu \
./objs/srs -c conf/console.conf
```
Publish stream:
```
ffmpeg -re -i doc/source.flv -c copy -f flv rtmp://127.0.0.1:1935/live/livestream
```
Play stream：[http://localhost:8080/live/livestream.flv](http://localhost:8080/players/srs_player.html?autostart=true&stream=livestream.flv&port=8080&schema=http)
## Ubuntu Cross Build SRS: hisiv500(arm)
TBD.
## Use Other Cross build tools
SRS configure options for cross build:
```bash
./configure -h
Presets:
--cross-build Enable cross-build, please set bellow Toolchain also. Default: off
Cross Build options: @see https://ossrs.io/lts/en-us/docs/v7/doc/arm#ubuntu-cross-build-srs
--cpu=<CPU> Toolchain: Select the minimum required CPU. For example: --cpu=24kc
--arch=<ARCH> Toolchain: Select architecture. For example: --arch=aarch64
--host=<BUILD> Toolchain: Build programs to run on HOST. For example: --host=aarch64-linux-gnu
--cross-prefix=<PREFIX> Toolchain: Use PREFIX for tools. For example: --cross-prefix=aarch64-linux-gnu-
Toolchain options:
--static=on|off Whether add '-static' to link options. Default: off
--cc=<CC> Toolchain: Use c compiler CC. Default: gcc
--cxx=<CXX> Toolchain: Use c++ compiler CXX. Default: g++
--ar=<AR> Toolchain: Use archive tool AR. Default: g++
--ld=<LD> Toolchain: Use linker tool LD. Default: g++
--randlib=<RANDLIB> Toolchain: Use randlib tool RANDLIB. Default: g++
--extra-flags=<EFLAGS> Set EFLAGS as CFLAGS and CXXFLAGS. Also passed to ST as EXTRA_CFLAGS.
```
Winlin 2014.11
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/arm)

52
trunk/3rdparty/srs-docs/doc/client-sdk.md vendored Normal file
View File

@ -0,0 +1,52 @@
---
title: Client SDK
sidebar_label: Client SDK
hide_title: false
hide_table_of_contents: false
---
# Client SDK
The workflow of live streaming:
```
+---------+ +-----------------+ +---------+
| Encoder +-->---+ SRS/CDN Network +--->---+ Player |
+---------+ +-----------------+ +---------+
```
## EXOPlayer
The [EXOPlayer](https://github.com/google/ExoPlayer) is a Android player which support HTTP-FLV and HLS.
## IJKPlayer
[ijkplayer](https://github.com/Bilibili/ijkplayer) is a player from [bilibili](http://www.bilibili.com/), for both Android and iOS.
## FFmpeg
[FFmpeg](https://ffmpeg.org) is a complete, cross-platform solution to record, convert and stream audio and video.
## LIBRTMP
The [LIBRTMP](https://github.com/ossrs/librtmp) or [SRS-LIBRTMP](https://github.com/ossrs/srs-librtmp) only provides transport over RTMP.
## WebRTC
[WebRTC](https://webrtc.org/) is Real-time communication for the web.
## PC
Although the number of PC users are smaller, there are still some use scenarios for [OBS](https://obsproject.com).
> Remark: For publishing by OBS, the **Stream Key** should be filled by stream name.
![OBS](/img/doc-integration-client-sdk-001.png)
![OBS](/img/doc-integration-client-sdk-002.png)
Winlin 2017.4
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/client-sdk)

12
trunk/3rdparty/srs-docs/doc/cloud.md vendored Normal file
View File

@ -0,0 +1,12 @@
---
title: Cloud
sidebar_label: Cloud
hide_title: false
hide_table_of_contents: false
---
# Cloud
Migrated to [Cloud](/cloud)
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/cloud)

59
trunk/3rdparty/srs-docs/doc/delivery-hds.md vendored Normal file
View File

@ -0,0 +1,59 @@
---
title: HDS Delivery
sidebar_label: HDS Delivery
hide_title: false
hide_table_of_contents: false
---
# HDS Delivery
HDS is the Http Dynamic Stream of Adobe，similar to Apple [HLS](./hls.md).
For specification of HDS, read http://www.adobe.com/devnet/hds.html
## Build
We can disable or enable HDS when build SRS, read [Build](./install.md)
```
./configure --hds=on
```
## Player
The OSMF player can play HDS. For example, use VLC to play the following HDS:
```
http://ossrs.net:8081/live/livestream.f4m
```
## HDS Config
The vhost hds.srs.com of conf/full.conf describes the config for HDS:
```
vhost __defaultVhost__ {
hds {
# whether hds enabled
# default: off
enabled on;
# the hds fragment in seconds.
# default: 10
hds_fragment 10;
# the hds window in seconds, erase the segment when exceed the window.
# default: 60
hds_window 60;
# the path to store the hds files.
# default: ./objs/nginx/html
hds_path ./objs/nginx/html;
}
}
```
The config items are similar to HLS, read [HLS config](./hls.md#hls-config)
Winlin 2015.3
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/delivery-hds)

14
trunk/3rdparty/srs-docs/doc/delivery-hls.md vendored Normal file
View File

@ -0,0 +1,14 @@
---
title: HLS Delivery
sidebar_label: HLS Delivery
hide_title: false
hide_table_of_contents: false
---
# HLS Delivery
Migrated to [HLS](./hls.md).
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/delivery-hls)

14
trunk/3rdparty/srs-docs/doc/delivery-http-flv.md vendored Normal file
View File

@ -0,0 +1,14 @@
---
title: HTTP-FLV Delivery
sidebar_label: HTTP-FLV Delivery
hide_title: false
hide_table_of_contents: false
---
# HTTP-FLV Delivery
Migrated to [HTTP-FLV](./flv.md).
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/delivery-http-flv)

14
trunk/3rdparty/srs-docs/doc/delivery-rtmp.md vendored Normal file
View File

@ -0,0 +1,14 @@
---
title: RTMP Delivery
sidebar_label: RTMP Delivery
hide_title: false
hide_table_of_contents: false
---
# RTMP Delivery
Migrated to [RTMP](./rtmp.md).
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/delivery-rtmp)

131
trunk/3rdparty/srs-docs/doc/drm.md vendored Normal file
View File

@ -0,0 +1,131 @@
---
title: DRM
sidebar_label: DRM
hide_title: false
hide_table_of_contents: false
---
# DRM
DRM use to protect the content, can use many strategys:
* Referer Anti-suck: Check the referer(PageUrl) of RTMP connect params, which is set by flash player.
* Token Authentication: Check the token of RTMP connect params, SRS can use http-callback to verify the token.
* FMS token tranverse: Edge server will verify each connection on origin server.
* Access Server: Adobe Access Server.
* Publish Authentication: The authentication protocol for publish.
<a name='refer-authentication'></a>
<a name='refer-autisuck'></a>
## Referer Anti-suck
SRS support config the referer to anti-suck.
When play RTMP url, adobe flash player will send the page url in the connect params PageUrl,
which is cannot changed by as code, server can check the web page url to ensure the user is ok.
While user use client application, the PageUrl can be any value, for example,
use srs-librtmp to play RTMP url, the Referer anti-suck is not work.
To config the referer anti-suck in srs:
```bash
# the vhost for anti-suck.
vhost refer.anti_suck.com {
# refer hotlink-denial.
refer {
# whether enable the refer hotlink-denial.
# default: off.
enabled on;
# the common refer for play and publish.
# if the page url of client not in the refer, access denied.
# if not specified this field, allow all.
# default: not specified.
all github.com github.io;
# refer for publish clients specified.
# the common refer is not overrided by this.
# if not specified this field, allow all.
# default: not specified.
publish github.com github.io;
# refer for play clients specified.
# the common refer is not overrided by this.
# if not specified this field, allow all.
# default: not specified.
play github.com github.io;
}
}
```
> Remark: SRS3 use new style config for referer, which is compatible with SRS1/2.
The bellow protocols support referer:
* RTMP: Both publisher and player.
## Token Authentication
The token authentication similar to referer, but the token is put in the url, not in the args of connect:
```
rtmp://vhost/app/stream?token=xxxx
http://vhost/app/stream.flv?token=xxxx
http://vhost/app/stream.m3u8?token=xxxx
http://vhost/rtc/v1/whip/?app=live&stream=livestream&token=xxx
http://vhost/rtc/v1/whep/?app=live&stream=livestream&token=xxx
```
SRS will pass the token in the http-callback. read [HTTP callback](./http-callback.md)
Token is robust then referer, can specifies more params, for instance, the expire time. For example:
1. When user access the web page, web application server can generate a token in the URL, for example, `token = md5(time + id + salt + expire) = 88195f8943e5c944066725df2b1706f8`
1. The RTMP URL to publish is, for instance, `rtmp://192.168.1.10/live/livestream?time=1402307089&expire=3600&token=88195f8943e5c944066725df2b1706f8`
1. Config the http callback of SRS `on_publish http://127.0.0.1:8085/api/v1/streams;` , read [HTTP callback](./http-callback.md#config-srs)
1. When user publishing stream, SRS will callback the url with token to verify, if invalid, the http callback can return none zero which indicates error.
> Note: You're able to verify the play.
## TokenTraverse
The FMS token tranverse is when user connect to edge server,
the edge server will send the client info which contains token
to origin server to verify. It seems that the token from client
tranverse from edge to origin server.
FMS edge and origin use private protocol, use a connection to fetch data,
another to transport the control message, for example, the token tranverse
is a special command, @see https://github.com/ossrs/srs/issues/104
Recomment the token authentication to use http protocol;
the token tranverse must use RTMP protocol, so many RTMP servers do not
support the token tranverse.
SRS supports token tranverse like FMS, but SRS always create a new connection
to verify the client info on origin server.
THe config for token tranverse, see `edge.token.traverse.conf`：
```bash
listen 1935;
vhost __defaultVhost__ {
cluster {
mode remote;
origin 127.0.0.1:19350;
token_traverse on;
}
}
```
## Access Server
SRS does not support.
## Publish Authentication
SRS does not support.
Winlin 2015.8
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/drm)

267
trunk/3rdparty/srs-docs/doc/dvr.md vendored Normal file
View File

@ -0,0 +1,267 @@
---
title: DVR
sidebar_label: DVR
hide_title: false
hide_table_of_contents: false
---
# DVR
SRS supports DVR RTMP stream to FLV/MP4 file. Although the bellow using FLV as example, but MP4 is also available.
When FFmpeg/OBS publish RTMP stream to SRS, SRS will write the stream to FLV/MP4 file. The workflow is:
```text
+------------+ +-------+ +---------------+
+ FFmpeg/OBS +---RTMP-->--+ SRS +---DVR-->--+ FLV/MP4 File +
+------------+ +-------+ +---------------+
```
Many users want more features about DVR, please consider use [Oryx](./getting-started-oryx.md#dvr) instead,
for example:
* Oryx supports S3 cloud storage, move the final MP4 file to S3 cloud storage.
* Oryx supports glob filters, to only record specified streams, not all streams.
* Oryx supports merge multiple publishing sessions to one MP4 file.
In facts, DVR feature can be very complicated, SRS only support basic DVR feature, while Oryx will continue
to improve the DVR features.
## Build
DVR is always enabled for SRS3+.
For information about the dvr option, read [Build](./install.md)
## Config
The difficult of DVR is about the flv name, while SRS use app/stream+random name.
User can use http-callback to rename, for example, when DVR reap flv file.
Config for DVR:
```bash
vhost yourvhost {
# DVR RTMP stream to file,
# start to record to file when encoder publish,
# reap flv/mp4 according by specified dvr_plan.
dvr {
# whether enabled dvr features
# default: off
enabled on;
# 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
dvr_plan session;
# the dvr output path, *.flv or *.mp4.
# we supports some variables to generate the filename.
# [vhost], the vhost of stream.
# [app], the app of stream.
# [stream], the stream name of stream.
# [2006], replace this const to current year.
# [01], replace this const to current month.
# [02], replace this const to current date.
# [15], replace this const to current hour.
# [04], replace this const to current minute.
# [05], replace this const to current second.
# [999], replace this const to current millisecond.
# [timestamp],replace this const to current UNIX timestamp in ms.
# @remark we use golang time format "2006-01-02 15:04:05.999" as "[2006]-[01]-[02]_[15].[04].[05]_[999]"
# for example, for url rtmp://ossrs.net/live/livestream and time 2015-01-03 10:57:30.776
# 1. No variables, the rule of SRS1.0(auto add [stream].[timestamp].flv as filename):
# dvr_path ./objs/nginx/html;
# =>
# dvr_path ./objs/nginx/html/live/livestream.1420254068776.flv;
# 2. Use stream and date as dir name, time as filename:
# 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;
# 3. Use stream and year/month as dir name, date and time as filename:
# 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;
# 4. Use vhost/app and year/month as dir name, stream/date/time as filename:
# dvr_path /data/[vhost]/[app]/[2006]/[01]/[stream]-[02]-[15].[04].[05].[999].flv;
# =>
# dvr_path /data/ossrs.net/live/2015/01/livestream-03-10.57.30.776.flv;
# 5. DVR to mp4:
# dvr_path ./objs/nginx/html/[app]/[stream].[timestamp].mp4;
# =>
# dvr_path ./objs/nginx/html/live/livestream.1420254068776.mp4;
# @see https://ossrs.io/lts/en-us/docs/v4/doc/dvr#custom-path
# @see https://ossrs.io/lts/en-us/docs/v4/doc/dvr#custom-path
# segment,session apply it.
# default: ./objs/nginx/html/[app]/[stream].[timestamp].flv
dvr_path ./objs/nginx/html/[app]/[stream].[timestamp].flv;
# 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.io/lts/en-us/docs/v4/doc/dvr#http-callback
# @see https://ossrs.io/lts/en-us/docs/v4/doc/dvr#http-callback
}
}
```
The plan of DVR used to reap flv file:
* session: When start publish, open flv file, close file when unpublish.
* segment: Reap flv file by the dvr_duration and dvr_wait_keyframe.
* time_jitter: The time jitter algorithm to use.
* dvr_path: The path of dvr, the rules is specified at below.
The config file can also use `conf/dvr.segment.conf` or `conf/dvr.session.conf`.
## Apply
The dvr apply is a filter which enable or disable the dvr of specified stream.
This feature is similar to nginx control module, but stronger than nginx.
User can use [http raw api](./http-api.md) to control when to dvr specified stream.
Please read [351](https://github.com/ossrs/srs/issues/459#issuecomment-134983742).
The following exmaple dvr `live/stream1`和`live/stream2`, the config:
```
vhost xxx {
dvr {
dvr_apply live/stream1 live/stream2;
}
}
```
About the RAW API to control DVR, read [319](https://github.com/ossrs/srs/issues/319) and [wiki](./http-api.md#raw-dvr).
## Custom Path
We can custom the dvr path(dir and filename) by rules:
* Use date and time and stream info as dir name, to avoid too many files in a dir.
* Use date and time and stream info as filename, for better search.
* Provides the data/time and stream info variables, use brackets to identify them.
* Keep SRS1.0 rule, supports write to a specified dir and uses timestamp as filename. If no filename specified(dir specified only), use `[stream].[timestamp].flv` as filename to compatible with SRS1.0 rule.
About the data and time variable, refer to go time format string, for example, use an actual year 2006 instead YYYY, it's a good design:
```
2006-01-02 15:04:05.999
```
The variables of dvr:
1. Year, [2006], replace this const to current year.
1. Month, [01], replace this const to current month.
1. Date, [02], replace this const to current date.
1. Hour, [15], replace this const to current hour.
1. Minute, [04], repleace this const to current minute.
1. Second, [05], repleace this const to current second.
1. Millisecond, [999], repleace this const to current millisecond.
1. Timestamp, [timestamp],replace this const to current UNIX timestamp in ms.
1. Stream info, refer to transcode output, variables are [vhost], [app], [stream]
For example, for url `rtmp://ossrs.net/live/livestream` and time `2015-01-03 10:57:30.776`:
1. No variables, the rule of SRS1.0(auto add `[stream].[timestamp].flv` as filename):
* dvr_path ./objs/nginx/html;
* =>
* dvr_path ./objs/nginx/html/live/livestream.1420254068776.flv;
1. Use stream and date as dir name, time as filename:
* 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;
1. Use stream and year/month as dir name, date and time as filename:
* 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;
1. Use vhost/app and year/month as dir name, stream/date/time as filename:
* dvr_path /data/[vhost]/[app]/[2006]/[01]/[stream]-[02]-[15].[04].[05].[999].flv;
* =>
* dvr_path /data/ossrs.net/live/2015/01/livestream-03-10.57.30.776.flv;
1. Use app as dirname, stream and timestamp as filename(the SRS1.0 rule):
* dvr_path /data/[app]/[stream].[timestamp].flv;
* =>
* dvr_path /data/live/livestream.1420254068776.flv;
## Http Callback
Enable the `on_dvr` of `http_hooks`:
```
vhost your_vhost {
dvr {
enabled on;
dvr_path ./objs/nginx/html/[app]/[stream]/[2006]/[01]/[02]/[15].[04].[05].[999].flv;
dvr_plan segment;
dvr_duration 30;
dvr_wait_keyframe on;
}
http_hooks {
enabled on;
on_dvr http://127.0.0.1:8085/api/v1/dvrs;
}
}
```
The log of api-server for api dvrs：
```
[2015-01-03 15:25:48][trace] post to dvrs, req={"action":"on_dvr","client_id":108,"ip":"127.0.0.1","vhost":"__defaultVhost__","app":"live","stream":"livestream","cwd":"/home/winlin/git/srs/trunk","file":"./objs/nginx/html/live/livestream/2015/1/3/15.25.18.442.flv"}
[2015-01-03 15:25:48][trace] srs on_dvr: client id=108, ip=127.0.0.1, vhost=__defaultVhost__, app=live, stream=livestream, cwd=/home/winlin/git/srs/trunk, file=./objs/nginx/html/live/livestream/2015/1/3/15.25.18.442.flv
127.0.0.1 - - [03/Jan/2015:15:25:48] "POST /api/v1/dvrs HTTP/1.1" 200 1 "" "SRS(Simple RTMP Server)2.0.88"
```
For more information, read about [HttpCallback](./http-callback.md)
## Bug
The bugs of dvr:
* The dir and filename rules: [#179](https://github.com/ossrs/srs/issues/179)
* The http callback for dvr: [#274](https://github.com/ossrs/srs/issues/274)
* The MP4 format support: [#738](https://github.com/ossrs/srs/issues/738)
* How to DVR multiple segments to a file? Read [#776](https://github.com/ossrs/srs/pull/776).
## Reload
The changing of dvr and reload will restart the dvr, that is, to close current dvr file then apply new config.
Winlin 2015.1
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/dvr)

151
trunk/3rdparty/srs-docs/doc/edge.md vendored Normal file
View File

@ -0,0 +1,151 @@
---
title: Edge Cluster
sidebar_label: Edge Cluster
hide_title: false
hide_table_of_contents: false
---
# Edge Server
SRS edge dedicates to support huge players for a small set of streams.
![](/img/doc-main-concepts-edge-001.png)
Note: The edge server need to serve many clients, the SRS performance is ok.
Use Scenarios for Edge:
* CDN/VDN RTMP cluster, for many clients to upload(publish) or download(play).
* Small cluster, but many clients to publish. Forward is not ok for all stream is forwarded,
while edge is ok for it only fetch when user play the specified stream.
* The BGP server is costly, while the edge is cheap. Use multiple levels edge
to ensure the BGP server low bandwidth.
Note: Edge can fetch stream from or push stream to origin. When user play
a stream on edge, edge will fetch from origin. When user publish stream to
edge, edge will push to origin.
Note: Always use Edge, except you actually know the forward. The forward will
always forward stream to multiple servers; while the edge only fetch or push
stream to a server and switch to next when error.
## Concepts
When a vhost set mode to remote, the vhost in server is edge.
When a vhost set mode to local, the vhost in server is origin.
Edge is used to cache the stream of origin.
When user publish stream to the edge server, edge will forward the stream
to origin. For example, the origin server is in beijing, a user at shanghai needs
to pubish stream to origin server, we can add a edge server at shanghai, when
user publish stream to shanghai edge server, the edge server will forward stream to
beijing.
When user play the stream on edge, edge will fetch from origin when it has not
cache it yet. When edge already cached the stream, edge will directly delivery
stream to client. That is, when many clients connect to edge, there is only one
connection to origin for each stream. This is the CDN(content delivery network).
For example, the origin server is at beijing, there are 320 edge servers on other
provience, each edge server serves 2000 clients. There are 640,000 users play this
stream, and the bandwidth of CDN consumed 640Gbps; the origin server only serves 320
connections from all edge servers.
The edge server is design for huge cluster. Futhermore, the SRS edge can config with
multiple origin servers, SRS will switch to next when current origin server crash, and
the end user never disconnect when edge switch origin server.
## Config
Config the edge in vhost:
```bash
vhost __defaultVhost__ {
# The config for cluster.
cluster {
# The cluster mode, local or remote.
# local: It's an origin server, serve streams itself.
# remote: It's an edge server, fetch or push stream to origin server.
# default: local
mode remote;
# For edge(mode remote), user must specifies the origin server
# format as: <server_name|ip>[:port]
# @remark user can specifies multiple origin for error backup, by space,
# for example, 192.168.1.100:1935 192.168.1.101:1935 192.168.1.102:1935
origin 127.0.0.1:1935 localhost:1935;
# For edge(mode remote), whether open the token traverse mode,
# if token traverse on, all connections of edge will forward to origin to check(auth),
# it's very important for the edge to do the token auth.
# the better way is use http callback to do the token auth by the edge,
# but if user prefer origin check(auth), the token_traverse if better solution.
# default: off
token_traverse off;
# For edge(mode remote), the vhost to transform for edge,
# to fetch from the specified vhost at origin,
# if not specified, use the current vhost of edge in origin, the variable [vhost].
# default: [vhost]
vhost same.edge.srs.com;
# For edge(mode remote), when upnode(forward to, edge push to, edge pull from) is srs,
# it's strongly recommend to open the debug_srs_upnode,
# when connect to upnode, it will take the debug info,
# for example, the id, source id, pid.
# please see https://ossrs.io/lts/en-us/docs/v4/doc/log
# default: on
debug_srs_upnode on;
}
}
```
The origin can specifies multiple servers.
## Example
The example below specifies how to config a origin and edge.
The config of origin, see `origin.conf`：
```bash
listen 19350;
pid objs/origin.pid;
srs_log_file ./objs/origin.log;
vhost __defaultVhost__ {
}
```
The config of edge, see `edge.conf`：
```bash
listen 1935;
pid objs/edge.pid;
srs_log_file ./objs/edge.log;
vhost __defaultVhost__ {
cluster {
mode remote;
origin 127.0.0.1:19350;
}
}
```
## HLS Edge
The edge is for RTMP, that is, when publish stream to origin, only origin server output
the HLS, all edge server never output HLS util client access the RTMP stream on edge.
That is, never config HLS on edge server, it's no use. The HLS delivery must use squid or
traffic server to cache the HTTP origin server.
## Transform Vhost
The design of CDN stream system, always use `up.xxxx` and `down.xxxx` to operate them, for example, user publish to cdn by host `up.srs.com` and play by `down.srs.com`.
SRS can config the edge mode to transform the host to origin, use the config `vhost down.srs.com` for up edge server.
For more information, read the config of edge server.
Winlin 2015.4
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/edge)

177
trunk/3rdparty/srs-docs/doc/exporter.md vendored Normal file
View File

@ -0,0 +1,177 @@
---
title: Prometheus Exporter
sidebar_label: Exporter
hide_title: false
hide_table_of_contents: false
---
# Prometheus Exporter
The observability of SRS is about metrics(Prometheus Exporter), tracing(APM) and logging(Cloud Logging).
## Introduction
For detail specs, please read [OpenTelemetry](https://opentelemetry.io/docs/concepts/observability-primer).
![](/img/doc-2022-10-30-001.png)
> Note: Please see [Metrics, tracing, and logging](https://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html)
The architecture for Prometheus exporter:
```
+-----+ +-----------+ +---------+
| SRS +--Exporter-->--| Promethus +-->--+ Grafana +
+-----+ (HTTP) +-----------+ +---------+
```
There is special config for exporter.
## Config
The config for exporter is bellow. Highly recommend using environment variables to enable it:
```bash
# Prometheus exporter config.
# See https://prometheus.io/docs/instrumenting/exporters
exporter {
# Whether exporter is enabled.
# Overwrite by env SRS_EXPORTER_ENABLED
# Default: off
enabled off;
# The http api listen port for exporter metrics.
# Overwrite by env SRS_EXPORTER_LISTEN
# Default: 9972
# See https://github.com/prometheus/prometheus/wiki/Default-port-allocations
listen 9972;
# The logging label to category the cluster servers.
# Overwrite by env SRS_EXPORTER_LABEL
label cn-beijing;
# The logging tag to category the cluster servers.
# Overwrite by env SRS_EXPORTER_TAG
tag cn-edge;
}
```
Let's start SRS exporter to export metrics to Prometheus.
## Usage for SRS Exporter
Build and start `SRS 5.0.86+`：
```bash
./configure && make
env SRS_ENV_ONLY=on SRS_EXPORTER_ENABLED=on SRS_LISTEN=1935 \
./objs/srs -e
```
> Note: We use envrionment variables to config SRS, without config file. However, you're able to use config file `conf/prometheus.conf` to start the demo.
> Note: Please open [http://localhost:9972/metrics](http://localhost:9972/metrics) to verify SRS.
Then, use FFmpeg to push a live stream to SRS:
```bash
docker run --rm -it ossrs/srs:encoder ffmpeg -re -i doc/source.flv -c copy \
-f flv rtmp://host.docker.internal/live/livestream
```
Next, run [node_exporter](https://github.com/prometheus/node_exporter) to collect the node data:
```bash
docker run --rm -p 9100:9100 prom/node-exporter
```
> Note: Highly recommend downloading from [here](https://github.com/prometheus/node_exporter/releases) and startting by binary file.
> Note: Please open [http://localhost:9100/metrics](http://localhost:9100/metrics) to verify it.
Finally, create a `prometheus.yml` for prometheus:
```yml
scrape_configs:
- job_name: "node"
metrics_path: "/metrics"
scrape_interval: 5s
static_configs:
- targets: ["host.docker.internal:9100"]
- job_name: "srs"
metrics_path: "/metrics"
scrape_interval: 5s
static_configs:
- targets: ["host.docker.internal:9972"]
```
> Note: We set the `scrape_interval` to `5s`, which is default to `1m` or one minute.
Start Prometheus by：
```bash
docker run --rm -v $(pwd)/prometheus.yml:/etc/prometheus/prometheus.yml \
-p 9090:9090 prom/prometheus
```
Please ope [Prometheus: Targets](http://localhost:9090/targets), or [Prometheus: Graph](http://localhost:9090/graph) to query the input bitrate:
```sql
rate(srs_receive_bytes_total[10s])*8
```
This query is used to query the input bitrate, which is the bitrate of stream:
![](/img/doc-2022-10-30-002.png)
Normally we use Grafana to render the graph.
## Usage for Grafana
First, start Grafana in docker:
```bash
docker run --rm -it -p 3000:3000 \
-e GF_SECURITY_ADMIN_USER=admin \
-e GF_SECURITY_ADMIN_PASSWORD=12345678 \
-e GF_USERS_DEFAULT_THEME=light \
grafana/grafana
```
Please access Grafana console by [http://localhost:3000/](http://localhost:3000/)
> Note: Please input username `admin` and password `12345678` then click login.
Run command to [add](https://grafana.com/docs/grafana/latest/developers/http_api/data_source/#create-a-data-source) a Prometheus DataSource:
```bash
curl -s -H "Content-Type: application/json" \
-XPOST http://admin:12345678@localhost:3000/api/datasources \
-d '{
"name": "prometheus",
"type": "prometheus",
"access": "proxy", "isDefault": true,
"url": "http://host.docker.internal:9090"
}'
```
Run command to [import](https://grafana.com/docs/grafana/latest/developers/http_api/dashboard/#create--update-dashboard) the HelloWorld dashboard:
```bash
data=$(curl https://raw.githubusercontent.com/ossrs/srs-grafana/main/dashboards/helloworld-import.json 2>/dev/null)
curl -s -H "Content-Type: application/json" \
-XPOST http://admin:12345678@localhost:3000/api/dashboards/db \
--data-binary "{\"dashboard\":${data},\"overwrite\":true,\"inputs\":[],\"folderId\":0}"
```
> Note: For other dashboards, please see [srs-grafana](https://github.com/ossrs/srs-grafana/tree/main/dashboards).
Then open [Dashboards](http://localhost:3000/dashboards) in browser, you will see the imported dashboard:
![](/img/doc-2022-10-30-003.png)
There are more other dashboards, please get them in [srs-grafana](https://github.com/ossrs/srs-grafana/tree/main/dashboards).
![](/img/doc-2022-10-30-004.png)
Any patch is welcome.
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/exporter)

368
trunk/3rdparty/srs-docs/doc/ffmpeg.md vendored Normal file
View File

@ -0,0 +1,368 @@
---
title: FFMPEG
sidebar_label: FFMPEG
hide_title: false
hide_table_of_contents: false
---
# Live Streaming Transcode
SRS can transcode RTMP streams and output to any RTMP server, typically itself.
## Use Scenario
The important use scenario of FFMPEG:
* One in N out: Publish a high resolution video with big bitrate, for intance, h.264 5Mbps 1080p. Then use FFMPEG to transcode to multiple bitrates, for example, 1080p/720p/576p, the 576p is for mobile devices.
* Support multiple screen: The stream published by flash is in h264/vp6/mp3/speex codec. Use FFMPEG to transcode to HLS(h264+aac) for IOS/Android.
* Stream filters: For example, add logo to stream. SRS supports all filters from FFMPEG.
* Snapshot: Please read [snapshot by transcoder](./snapshot.md#transcoder)
## Workflow
The workflow of SRS transcoding:
1. Encoder publishes RTMP to SRS.
1. SRS forks a process for FFMPEG when transcoding is configured.
1. The forked FFMPEG transcodes the stream and publishes it to SRS or other servers.
## Transcode Config
The SRS transcoding feature can apply on vhost, app or a specified stream.
```bash
listen 1935;
vhost __defaultVhost__ {
# the streaming transcode configs.
transcode {
# whether the transcode enabled.
# if off, donot transcode.
# default: off.
enabled on;
# the ffmpeg
ffmpeg ./objs/ffmpeg/bin/ffmpeg;
# the transcode engine for matched stream.
# all matched stream will transcoded to the following stream.
# the transcode set name(ie. hd) is optional and not used.
engine example {
# whether the engine is enabled
# default: off.
enabled on;
# input format, can be:
# off, do not specifies the format, ffmpeg will guess it.
# flv, for flv or RTMP stream.
# other format, for example, mp4/aac whatever.
# default: flv
iformat flv;
# ffmpeg filters, follows the main input.
vfilter {
# the logo input file.
i ./doc/ffmpeg-logo.png;
# the ffmpeg complex filter.
# for filters, @see: http://ffmpeg.org/ffmpeg-filters.html
filter_complex 'overlay=10:10';
}
# video encoder name. can be:
# libx264: use h.264(libx264) video encoder.
# png: use png to snapshot thumbnail.
# copy: donot encoder the video stream, copy it.
# vn: disable video output.
vcodec libx264;
# video bitrate, in kbps
# @remark 0 to use source video bitrate.
# default: 0
vbitrate 1500;
# video framerate.
# @remark 0 to use source video fps.
# default: 0
vfps 25;
# video width, must be even numbers.
# @remark 0 to use source video width.
# default: 0
vwidth 768;
# video height, must be even numbers.
# @remark 0 to use source video height.
# default: 0
vheight 320;
# the max threads for ffmpeg to used.
# default: 1
vthreads 12;
# x264 profile, @see x264 -help, can be:
# high,main,baseline
vprofile main;
# x264 preset, @see x264 -help, can be:
# ultrafast,superfast,veryfast,faster,fast
# medium,slow,slower,veryslow,placebo
vpreset medium;
# other x264 or ffmpeg video params
vparams {
# ffmpeg options, @see: http://ffmpeg.org/ffmpeg.html
t 100;
# 264 params, @see: http://ffmpeg.org/ffmpeg-codecs.html#libx264
coder 1;
b_strategy 2;
bf 3;
refs 10;
}
# audio encoder name. can be:
# libfdk_aac: use aac(libfdk_aac) audio encoder.
# copy: donot encoder the audio stream, copy it.
# an: disable audio output.
acodec libfdk_aac;
# audio bitrate, in kbps. [16, 72] for libfdk_aac.
# @remark 0 to use source audio bitrate.
# default: 0
abitrate 70;
# audio sample rate. for flv/rtmp, it must be:
# 44100,22050,11025,5512
# @remark 0 to use source audio sample rate.
# default: 0
asample_rate 44100;
# audio channel, 1 for mono, 2 for stereo.
# @remark 0 to use source audio channels.
# default: 0
achannels 2;
# other ffmpeg audio params
aparams {
# audio params, @see: http://ffmpeg.org/ffmpeg-codecs.html#Audio-Encoders
# @remark SRS supported aac profile for HLS is: aac_low, aac_he, aac_he_v2
profile:a aac_low;
bsf:a aac_adtstoasc;
}
# output format, can be:
# off, do not specifies the format, ffmpeg will guess it.
# flv, for flv or RTMP stream.
# image2, for vcodec png to snapshot thumbnail.
# other format, for example, mp4/aac whatever.
# default: flv
oformat flv;
# output stream. variables:
# [vhost] the input stream vhost.
# [port] the intput stream port.
# [app] the input stream app.
# [stream] the input stream name.
# [engine] the tanscode engine name.
output rtmp://127.0.0.1:[port]/[app]?vhost=[vhost]/[stream]_[engine];
}
}
}
```
The configuration applies to all streams of this vhost, for example:
* Publish stream to: rtmp://dev:1935/live/livestream
* Play the origin stream: rtmp://dev:1935/live/livestream
* Play the transcoded stream: rtmp://dev:1935/live/livestream_ff
The output URL contains some variables:
* [vhost] The input stream vhost, for instance, dev.ossrs.net
* [port] The input stream port, for instance, 1935
* [app] The input stream app, for instance, live
* [stream] The input stream name, for instance, livestream
* [engine] The transcode engine name, which follows the keyword engine, for instance, ff
Add the app or app/stream when you need to apply transcoding to it:
```bash
listen 1935;
vhost __defaultVhost__ {
# Transcode all streams of app "live"
transcode live {
}
}
```
Or for streams:
```bash
listen 1935;
vhost __defaultVhost__ {
# Transcode stream name is "livestream" and app is "live"
transcode live/livestream{
}
}
```
## Transcode Rulers
All params of SRS transcode are for FFMPEG, and SRS renames some parameters:
| SRS | FFMPEG | Exammple | Description |
| ------ | --------- | ---- | ----- |
| vcodec | vcodec | ffmpeg ... -vcodec libx264 ... | The codec to use. |
| vbitrate | b:v | ffmpeg ... -b:v 500000 ... | The bitrate in kbps (for SRS) or bps (for FFMPEG) at which to output the transcoded stream. |
| vfps | r | ffmpeg ... -r 25 ... | The output framerate. |
| vwidth/vheight | s | ffmpeg ... -s 400x300 -aspect 400:300 ... | The output video size, the width x height and the aspect set to width:height. |
| vthreads | threads | ffmpeg ... -threads 8 ... | The number of encoding threads for x264. |
| vprofile | profile:v | ffmpeg ... -profile:v high ... | The profile for x264. |
| vpreset | preset | ffmpeg ... -preset medium ... | The preset for x264. |
| acodec | acodec | ffmpeg ... -acodec libfdk_aac ... | The codec for audio. |
| abitrate | b:a | ffmpeg ... -b:a 70000 ... | The bitrate in kbps (for SRS) and bps (for FFMPEG) for output audio. For libaacplus：16-72k. No limit for libfdk_aac. |
| asample_rate | ar | ffmpeg ... -ar 44100 ... | The audio sample rate. |
| achannels | ac | ffmpeg ... -ac 2 ... | The audio channel. |
There are more parameters for SRS:
* vfilter：Parameters added before the vcodec, for the FFMPEG filters.
* vparams：Parameters added after the vcodec, for the video transcode parameters.
* aparams：Parameters added after the acodec and before the -y, for the audio transcode parameters.
These parameters will generated by the sequence:
```bash
ffmpeg -f flv -i <input_rtmp> {vfilter} -vcodec ... {vparams} -acodec ... {aparams} -f flv -y {output}
```
The actual parameters used to fork FFMPEG can be found in the log by the keywords `start transcoder`:
```bash
[2014-02-28 21:38:09.603][4][trace][start] start transcoder,
log: ./objs/logs/encoder-__defaultVhost__-live-livestream.log,
params: ./objs/ffmpeg/bin/ffmpeg -f flv -i
rtmp://127.0.0.1:1935/live?vhost=__defaultVhost__/livestream
-vcodec libx264 -b:v 500000 -r 25.00 -s 768x320 -aspect 768:320
-threads 12 -profile:v main -preset medium -acodec libfdk_aac
-b:a 70000 -ar 44100 -ac 2 -f flv
-y rtmp://127.0.0.1:1935/live?vhost=__defaultVhost__/livestream_ff
```
## FFMPEG Log Path
When an FFMPEG process is forked, SRS will redirect the stdout and stderr to the log file, for instance, `./objs/logs/encoder-__defaultVhost__-live-livestream.log`. Sometimes the log file is very large, so users can add parameters to vfilter to tell FFMPEG to generate less verbose logs:
```bash
listen 1935;
vhost __defaultVhost__ {
transcode {
enabled on;
ffmpeg ./objs/ffmpeg/bin/ffmpeg;
engine ff {
enabled on;
vfilter {
# -v quiet
v quiet;
}
vcodec libx264;
vbitrate 500;
vfps 25;
vwidth 768;
vheight 320;
vthreads 12;
vprofile main;
vpreset medium;
vparams {
}
acodec libfdk_aac;
abitrate 70;
asample_rate 44100;
achannels 2;
aparams {
}
output rtmp://127.0.0.1:[port]/[app]?vhost=[vhost]/[stream]_[engine];
}
}
}
```
That is, add the parameter `-v quiet` to FFMPEG.
## Copy Without Transcode
Set the vcodec/acodec to copy, FFMPEG will demux and mux without transcoding, like the forward of SRS. Users can copy video and transcode audio, for example, when flash is publishing the stream with h264+speex.
```bash
listen 1935;
vhost __defaultVhost__ {
transcode {
enabled on;
ffmpeg ./objs/ffmpeg/bin/ffmpeg;
engine ff {
enabled on;
vcodec copy;
acodec libfdk_aac;
abitrate 70;
asample_rate 44100;
achannels 2;
aparams {
}
output rtmp://127.0.0.1:[port]/[app]?vhost=[vhost]/[stream]_[engine];
}
}
}
```
Or, copy video and audio:
```bash
listen 1935;
vhost __defaultVhost__ {
transcode {
enabled on;
ffmpeg ./objs/ffmpeg/bin/ffmpeg;
engine ff {
enabled on;
vcodec copy;
acodec copy;
output rtmp://127.0.0.1:[port]/[app]?vhost=[vhost]/[stream]_[engine];
}
}
}
```
## Drop Video or Audio
FFMPEG can drop video or audio streams by configuring vcodec to vn and acodec to an. For example:
```bash
listen 1935;
vhost __defaultVhost__ {
transcode {
enabled on;
ffmpeg ./objs/ffmpeg/bin/ffmpeg;
engine vn {
enabled on;
vcodec vn;
acodec libfdk_aac;
abitrate 45;
asample_rate 44100;
achannels 2;
aparams {
}
output rtmp://127.0.0.1:[port]/[app]?vhost=[vhost]/[stream]_[engine];
}
}
}
```
The configuration above will output pure audio in the aac codec.
## Other Transcoding Configuration
There are lots of vhost in conf/full.conf for transcoding, or refer to FFMPEG:
* mirror.transcode.srs.com
* drawtext.transcode.srs.com
* crop.transcode.srs.com
* logo.transcode.srs.com
* audio.transcode.srs.com
* copy.transcode.srs.com
* all.transcode.srs.com
* ffempty.transcode.srs.com
* app.transcode.srs.com
* stream.transcode.srs.com
* vn.transcode.srs.com
## FFMPEG Transcoding Streams by Flash Encoder
Flash web pages can encode and publish RTMP streams to the server, and the audio codec must be speex, nellymoser or pcma/pcmu.
Flash will disable audio when no audio is published, so FFMPEG may cannot discover the audio in the stream and will disable the audio.
## FFMPEG
FFMPEG links:
* [ffmpeg.org](http://ffmpeg.org)
* [ffmpeg CLI](http://ffmpeg.org/ffmpeg.html)
* [ffmpeg filters](http://ffmpeg.org/ffmpeg-filters.html)
* [ffmpeg codecs](http://ffmpeg.org/ffmpeg-codecs.html)
Winlin 2015.6
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/ffmpeg)

51
trunk/3rdparty/srs-docs/doc/flv-vod-stream.md vendored Normal file
View File

@ -0,0 +1,51 @@
---
title: FLV Vod Streaming
sidebar_label: FLV Vod Streaming
hide_title: false
hide_table_of_contents: false
---
# FLV vod streaming
## HTTP VOD
I recomment:
* Vod stream should always use HTTP protocol, never use RTMP.
SRS can dvr RTMP live stream to flv file, and provides some tools for vod stream,
but user should use other HTTP server to delivery flv file as vod stream.
* In a word, SRS does not support vod, only support live.
The workflow of flv vod stream:
* SRS dvr live stream to flv file, or upload flv vod file, to the HTTP root dir: `objs/nginx/html`
* HTTP server must support flv?start=offset, for example, flv module of nginx, or use experiment SRS HTTP server.
* Use `research/librtmp/objs/srs_flv_injecter` inject the keyframe offset to metadata of flv.
* Flash player play http flv url, for instance, `http://192.168.1.170:8080/sample.flv`
* When user seek, for instance, seek to 300s.
* Player use the keyframe offset in metadata to calc the offset of 300s, for instance, 300s offset=`6638860`
* Start new request, url is `http://192.168.1.170:8080/sample.flv?start=6638860`
Note: SRS HTTP server is experiment, do not limit the bandwidth.
Note: SRS provides flv view tool `research/librtmp/objs/srs_flv_parser`, to list the seconds:offsets in metadata.
## SRS Embeded HTTP server
SRS supports http-api, so SRS can also parse HTTP protocol(partial HTTP right now),
so SRS also implements a experiment HTTP server.
SRS HTTP server is rewrite, table and partial HTTP protocol support,
ok for online service.
For some emebeded device, for instance, arm linux, user can use SRS HTTP server,
for arm is not easy to build some server.
## Config
Read [HTTP Server](./http-server.md#config)
Winlin 2015.1
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/flv-vod-stream)

213
trunk/3rdparty/srs-docs/doc/flv.md vendored Normal file
View File

@ -0,0 +1,213 @@
---
title: HTTP-FLV
sidebar_label: HTTP-FLV
hide_title: false
hide_table_of_contents: false
---
# HTTP-FLV
HTTP-FLV is a live streaming protocol, sometimes simply called FLV, which is used to transmit live streams in FLV
format over an HTTP connection.
Unlike file downloads, live streams have an indefinite or uncertain length, so they are usually implemented using
the HTTP Chunked protocol. Similar to HTTP-FLV, there are also HTTP-TS and HTTP-MP3. TS is mainly used in broadcasting
and television, while MP3 is mainly used in the audio field.
Different from HLS, which is essentially an HTTP file download, HTTP-FLV is a streaming protocol. CDN support for
HTTP file downloads is well-developed, making HLS more compatible than HTTP-FLV. However, HTTP-FLV has lower latency
than HLS, typically achieving a delay of around 3 to 5 seconds, while HLS latency is generally 8 to 10 seconds or more.
In terms of protocol implementation, RTMP and HTTP-FLV are very similar. RTMP is based on the TCP protocol, and
HTTP-FLV is based on HTTP, which is also a TCP protocol. Therefore, their characteristics are very similar. RTMP
is generally used for streaming and live production because most live production devices support RTMP. For playback
and consumption, HTTP-FLV or HLS is used because playback devices have better support for HTTP.
HTTP-FLV is highly compatible, supported by almost all platforms and browsers except for the native iOS browser.
You can refer to [MSE](https://caniuse.com/?search=mse) for more information. To support the iOS browser, you can
consider using HLS or WASM. Note that for native iOS apps, the ijkplayer can be used as a playback option.
## Usage
SRS supports HTTP-FLV distribution, you can use [docker](./getting-started.md) or [build from source](./getting-started-build.md):
```bash
docker run --rm -it -p 1935:1935 -p 8080:8080 ossrs/srs:5 \
./objs/srs -c conf/http.flv.live.conf
```
Use [FFmpeg(click to download)](https://ffmpeg.org/download.html) or [OBS(click to download)](https://obsproject.com/download) to push the stream:
```bash
ffmpeg -re -i ./doc/source.flv -c copy -f flv rtmp://localhost/live/livestream
```
Open the following page to play the stream (if SRS is not on your local machine, please replace localhost with the server IP):
* HLS by SRS player: [http://localhost:8080/live/livestream.flv](http://localhost:8080/players/srs_player.html)
## Config
The configuration for HTTP-FLV is as follows:
```bash
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;
# 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;
}
vhost __defaultVhost__ {
# http flv/mp3/aac/ts stream vhost specified config
http_remux {
# whether enable the http live streaming service for vhost.
# Overwrite by env SRS_VHOST_HTTP_REMUX_ENABLED for all vhosts.
# default: off
enabled on;
# the fast cache for audio stream(mp3/aac),
# to cache more audio and send to client in a time to make android(weixin) happy.
# @remark the flv/ts stream ignore it
# @remark 0 to disable fast cache for http audio stream.
# Overwrite by env SRS_VHOST_HTTP_REMUX_FAST_CACHE for all vhosts.
# default: 0
fast_cache 30;
# Whether drop packet if not match header. For example, there is has_audio and has video flag in FLV header, if
# this is set to on and has_audio is false, then SRS will drop audio packets when got audio packets. Generally
# it should work, but sometimes you might need SRS to keep packets even when FLV header is set to false.
# See https://github.com/ossrs/srs/issues/939#issuecomment-1348740526
# TODO: Only support HTTP-FLV stream right now.
# Overwrite by env SRS_VHOST_HTTP_REMUX_DROP_IF_NOT_MATCH for all vhosts.
# Default: on
drop_if_not_match on;
# Whether stream has audio track, used as default value for stream metadata, for example, FLV header contains
# this flag. Sometimes you might want to force the metadata by disable guess_has_av.
# For HTTP-FLV, use this as default value for FLV header audio flag. See https://github.com/ossrs/srs/issues/939#issuecomment-1351385460
# For HTTP-TS, use this as default value for PMT table. See https://github.com/ossrs/srs/issues/939#issuecomment-1365086204
# Overwrite by env SRS_VHOST_HTTP_REMUX_HAS_AUDIO for all vhosts.
# Default: on
has_audio on;
# Whether stream has video track, used as default value for stream metadata, for example, FLV header contains
# this flag. Sometimes you might want to force the metadata by disable guess_has_av.
# For HTTP-FLV, use this as default value for FLV header video flag. See https://github.com/ossrs/srs/issues/939#issuecomment-1351385460
# For HTTP-TS, use this as default value for PMT table. See https://github.com/ossrs/srs/issues/939#issuecomment-1365086204
# Overwrite by env SRS_VHOST_HTTP_REMUX_HAS_VIDEO for all vhosts.
# Default: on
has_video on;
# Whether guessing stream about audio or video track, used to generate the flags in, such as FLV header. If
# guessing, depends on sequence header and frames in gop cache, so it might be incorrect especially your stream
# is not regular. If not guessing, use the configured default value has_audio and has_video.
# For HTTP-FLV, enable guessing for av header flag, because FLV can't change the header. See https://github.com/ossrs/srs/issues/939#issuecomment-1351385460
# For HTTP-TS, ignore guessing because TS refresh the PMT when codec changed. See https://github.com/ossrs/srs/issues/939#issuecomment-1365086204
# Overwrite by env SRS_VHOST_HTTP_REMUX_GUESS_HAS_AV for all vhosts.
# Default: on
guess_has_av on;
# the stream mount for rtmp to remux to live streaming.
# typical mount to [vhost]/[app]/[stream].flv
# the variables:
# [vhost] current vhost for http live stream.
# [app] current app for http live stream.
# [stream] current stream for http live stream.
# @remark the [vhost] is optional, used to mount at specified vhost.
# the extension:
# .flv mount http live flv stream, use default gop cache.
# .ts mount http live ts stream, use default gop cache.
# .mp3 mount http live mp3 stream, ignore video and audio mp3 codec required.
# .aac mount http live aac stream, ignore video and audio aac codec required.
# for example:
# mount to [vhost]/[app]/[stream].flv
# access by http://ossrs.net:8080/live/livestream.flv
# mount to /[app]/[stream].flv
# access by http://ossrs.net:8080/live/livestream.flv
# or by http://192.168.1.173:8080/live/livestream.flv
# mount to [vhost]/[app]/[stream].mp3
# access by http://ossrs.net:8080/live/livestream.mp3
# mount to [vhost]/[app]/[stream].aac
# access by http://ossrs.net:8080/live/livestream.aac
# mount to [vhost]/[app]/[stream].ts
# access by http://ossrs.net:8080/live/livestream.ts
# @remark the port of http is specified by http_server section.
# Overwrite by env SRS_VHOST_HTTP_REMUX_MOUNT for all vhosts.
# default: [vhost]/[app]/[stream].flv
mount [vhost]/[app]/[stream].flv;
}
}
```
> Note: These settings are only for playing HLS. For streaming settings, please follow your protocol, like referring to [RTMP](./rtmp.md#config), [SRT](./srt.md#config), or [WebRTC](./webrtc.md#config) streaming configurations.
The important settings are explained below:
* `has_audio`: If there is an audio stream or not. If your stream doesn't have audio, set this to `off`. Otherwise, the player might wait for audio.
* `has_video`: If there is a video stream or not. If your stream doesn't have video, set this to `off`. Otherwise, the player might wait for video.
## Cluster
SRS supports HTTP-FLV cluster distribution, which can handle a large number of viewing clients. Please refer to [HTTP-FLV Cluster](./sample-http-flv-cluster.md) and [Edge](./edge.md).
## Crossdomain
SRS supports HTTP CORS by default. Please refer to [HTTP CORS](./http-server.md#crossdomain).
## Websocket FLV
You can convert HTTP-FLV to WebSocket-FLV stream. Please refer to [videojs-flow](https://github.com/winlinvip/videojs-flow).
For HTTP to WebSocket conversion, please refer to [mse.go](https://github.com/winlinvip/videojs-flow/blob/master/demo/mse.go).
## HTTP FLV VOD Stream
For HTTP FLV on-demand streaming, please refer to: [v4_CN_FlvVodStream](./flv-vod-stream.md).
## HTTP and HTTPS Proxy
SRS works well with HTTP/HTTPS proxies such as [Nginx](https://github.com/ossrs/srs/issues/2881#nginx-proxy), [HTTPX](https://github.com/ossrs/srs/issues/2881#httpx-proxy), [CaddyServer](https://github.com/ossrs/srs/issues/2881#caddy-proxy), etc. For detailed configuration, please refer to [#2881](https://github.com/ossrs/srs/issues/2881).
## HTTPS FLV Live Stream
SRS supports converting RTMP streams to HTTPS FLV streams. When publishing RTMP streams, a corresponding HTTP address is mounted in the SRS HTTP module (according to the configuration). Users can access this HTTPS FLV file, and the RTMP stream is converted to FLV for distribution.
Please refer to [HTTPS Server](./http-server.md#https-server) or the `conf/https.flv.live.conf` configuration file.
## HTTP TS Live Stream
SRS supports converting RTMP streams to HTTP TS streams. When publishing RTMP streams, a corresponding HTTP address is mounted in the SRS HTTP module (according to the configuration). Users can access this HTTP TS file, and the RTMP stream is converted to TS for distribution.
Please refer to the `conf/http.ts.live.conf` configuration file.
## HTTP Mp3 Live Stream
SRS supports discarding video from RTMP streams and converting audio streams to MP3 format. A corresponding HTTP address is mounted in the SRS HTTP module (according to the configuration). Users can access this HTTP MP3 file, and the RTMP stream is converted to MP3 for distribution.
Please refer to the `conf/http.mp3.live.conf` configuration file.
## HTTP Aac Live Stream
SRS supports discarding video from RTMP streams and converting audio streams to AAC format. A corresponding HTTP address is mounted in the SRS HTTP module (according to the configuration). Users can access this HTTP AAC file, and the RTMP stream is converted to AAC for distribution.
Please refer to the `conf/http.aac.live.conf` configuration file.
## Why HTTP FLV
Why use HTTP FLV? HTTP FLV streaming is becoming more popular. The main advantages are:
1. In the field of real-time Internet streaming media, RTMP is still dominant. HTTP-FLV has the same latency as RTMP, so it can meet latency requirements.
2. Firewall penetration: Many firewalls block RTMP but not HTTP, so HTTP FLV is less likely to have strange issues.
3. Scheduling: RTMP has a 302 feature, but it's only supported in the player's ActionScript. HTTP FLV supports 302, making it easier for CDNs to correct DNS errors.
4. Fault tolerance: SRS's HTTP FLV can have multiple sources, just like RTMP, supporting multi-level hot backup.
5. Universality: Flash can play both RTMP and HTTP FLV. Custom apps and mainstream players also support HTTP FLV playback.
6. Simplicity: FLV is the simplest streaming media encapsulation, and HTTP is the most widely used protocol. Combining these two makes maintenance much easier than RTMP.
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.net&path=/lts/doc/en/v7/flv)

272
trunk/3rdparty/srs-docs/doc/forward.md vendored Normal file
View File

@ -0,0 +1,272 @@
---
title: Forward
sidebar_label: Forward
hide_title: false
hide_table_of_contents: false
---
# Forward For Small Cluster
SRS is design for live server, the forward is a important feature, used to
forward stream on server to other live servers.
Note: The information about edge, read [Edge](./edge.md),
the best solution for large cluster and huge concurrency.
Note: The edge is for both play and publish.
Note: Use edge first, except need to copy a stream to multiple servers in a time.
The forward is used for fault backup, the origin can forward a stream to multiple origin servers,
the edge can use multiple origin server for backup.
For the usage of forward, read [Usage: Forward](./sample-forward.md)
## Keywords
The forward defined some roles:
* master: The master server which forward stream to slave server.
* slave: The slave server which accept stream from master.
Although the origin/edge can be master/slave, but it is too complex, it is strongly recomments that
the forward(master/slave) only for origin, never use edge to forward stream.
## Config
Please refer to the vhost `same.vhost.forward.srs.com` of `full.conf`:
```
vhost __defaultVhost__ {
# forward stream to other servers.
forward {
# whether enable the forward.
# default: off
enabled on;
# forward all publish stream to the specified server.
# this used to split/forward the current stream for cluster active-standby,
# active-active for cdn to build high available fault tolerance system.
# format: {ip}:{port} {ip_N}:{port_N}
destination 127.0.0.1:1936 127.0.0.1:1937;
# when client(encoder) publish to vhost/app/stream, call the hook in creating backend forwarder.
# the request in the POST data string is a object encode by json:
# {
# "action": "on_forward",
# "server_id": "vid-k21d7y2",
# "client_id": "9o7g1330",
# "ip": "127.0.0.1",
# "vhost": "__defaultVhost__",
# "app": "live",
# "tcUrl": "rtmp://127.0.0.1:1935/live",
# "stream": "livestream",
# "param": ""
# }
# if valid, the hook must return HTTP code 200(Status OK) and response
# an int value specifies the error code(0 corresponding to success):
# {
# "code": 0,
# "data": {
# "urls":[
# "rtmp://127.0.0.1:19350/test/teststream"
# ]
# }
# }
# PS: you can transform params to backend service, such as:
# { "param": "?forward=rtmp://127.0.0.1:19351/test/livestream" }
# then backend return forward's url in response.
# if backend return empty urls, destanition is still disabled.
# only support one api hook, format:
# backend http://xxx/api0
backend http://127.0.0.1:8085/api/v1/forward;
}
}
```
## Dynamic Forward
SRS support dynamic forwarding, to query the forwarding config from your backend API.
So you must write a backend server, which is an HTTP server, or web server. It accepts HTTP requests from SRS, and then
responses the content with configs for SRS to do forward. It works like this:
```text
+------+
Client ---Push-RTMP-->--+ SRS +---HTTP-Request---> Your Backend Server
| | +
+ +--<---Forward-Config----+
| |
+ +----Push-RTMP----> RTMP Server
+------+
```
First, config the `backend` of forward:
```
vhost __defaultVhost__ {
forward {
enabled on;
backend http://127.0.0.1:8085/api/v1/forward;
}
}
```
While client publishing to SRS, SRS will request your HTTP backend server, with request body:
```json
{
"action": "on_forward",
"server_id": "vid-k21d7y2",
"client_id": "9o7g1330",
"ip": "127.0.0.1",
"vhost": "__defaultVhost__",
"app": "live",
"tcUrl": "rtmp://127.0.0.1:1935/live",
"stream": "livestream",
"param": ""
}
```
If your backend server responses with RTMP urls, SRS will start forwarding to the RTMP server:
```json
{
"code": 0,
"data": {
"urls":[
"rtmp://127.0.0.1:19350/test/teststream"
]
}
}
```
> Note: If urls is empty array, SRS won't forward it.
For more details about dynamic forwarding, please read [#1342](https://github.com/ossrs/srs/issues/1342).
## For Small Cluster
Forward can also used to build a small cluster:
```bash
+-------------+ +---------------+
+-->+ Slave(1935) +->--+ Player(3000) +
| +-------------+ +---------------+
| +-------------+ +---------------+
|-->+ Slave(1936) +->--+ Player(3000) +
publish forward | +-------------+ +---------------+
+-----------+ +--------+ | 192.168.1.6
| Encoder +-->-+ Master +-->-|
+-----------+ +--------+ | +-------------+ +---------------+
192.168.1.3 192.168.1.5 +-->+ Slave(1935) +->--+ Player(3000) +
| +-------------+ +---------------+
| +-------------+ +---------------+
+-->+ Slave(1936) +->--+ Player(3000) +
+-------------+ +---------------+
192.168.1.7
```
The below sections is the example for this small cluster.
### Encoder
Use FFMPEG as encoder to publish stream to master:
```bash
for((;;)); do\
./objs/ffmpeg/bin/ffmpeg -re -i doc/source.flv \
-c copy -f flv rtmp://192.168.1.5:1935/live/livestream; \
done
```
### SRS-Master Server
The SRS master server(192.168.1.5) config:
```bash
listen 1935;
pid ./objs/srs.pid;
max_connections 10240;
vhost __defaultVhost__ {
forward {
enabled on;
destination 192.168.1.6:1935 192.168.1.6:1936 192.168.1.7:1935 192.168.1.7:1936;
}
}
```
The RTMP play url on master is: `rtmp://192.168.1.5/live/livestream`
The master will forward stream to four slaves on two servers.
### SRS-Slave Server
The slave server can use different port to run on multiple cpu server.
The slave on the same server must use different port and pid file.
For example, the slave server 192.168.1.6, start two SRS servers, listen at 1935 and 1936.
The config file for port 1935 `srs.1935.conf`:
```bash
listen 1935;
pid ./objs/srs.1935.pid;
max_connections 10240;
vhost __defaultVhost__ {
}
```
The config file for port 1936 `srs.1936.conf`:
```bash
listen 1936;
pid ./objs/srs.1936.pid;
max_connections 10240;
vhost __defaultVhost__ {
}
```
Start these two SRS processes:
```bash
nohup ./objs/srs -c srs.1935.conf >/dev/null 2>&1 &
nohup ./objs/srs -c srs.1936.conf >/dev/null 2>&1 &
```
The player random access these streams:
* `rtmp://192.168.1.6:1935/live/livestream`
* `rtmp://192.168.1.6:1936/live/livestream`
The other slave server 192.168.1.7 is similar to 192.168.1.6
### Stream in Service
The stream in service:
| Url | Server | Port | Clients |
| ---- | ----- | ----- | ------- |
| rtmp://192.168.1.6:1935/live/livestream | 192.168.1.6 | 1935 | 3000 |
| rtmp://192.168.1.6:1936/live/livestream | 192.168.1.6 | 1936 | 3000 |
| rtmp://192.168.1.7:1935/live/livestream | 192.168.1.7 | 1935 | 3000 |
| rtmp://192.168.1.7:1936/live/livestream | 192.168.1.7 | 1936 | 3000 |
This architecture can support 12k clients.
User can add more slave or start new ports.
## Forward VS Edge
The forward is not used in cdn, because CDN has thousands of servers, thousands of streams.
The forward will always forward all stream to slave servers.
CDN or large cluster must use edge, never use forward.
## Other Use Scenarios
Forward used for transcoder, we can transcode a h.264+speex stream to a vhost, while this vhost forward
stream to slave. Then all stream on slave is h.264+aac, to delivery HLS.
Winlin 2014.11
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/forward)

15
trunk/3rdparty/srs-docs/doc/gb28181.md vendored Normal file
View File

@ -0,0 +1,15 @@
---
title: GB28181
sidebar_label: GB28181
hide_title: false
hide_table_of_contents: false
---
# GB28181
On the way.
## Candidate
On the way.

203
trunk/3rdparty/srs-docs/doc/getting-started-build.md vendored Normal file
View File

@ -0,0 +1,203 @@
---
title: Build
sidebar_label: Build
hide_title: false
hide_table_of_contents: false
---
# Build
You can build SRS from source code, but [docker](./getting-started.md) is highly recommend.
## Live Streaming
SRS supports live streaming.
Get SRS source, recommend [Ubuntu20](./install.md):
```
git clone -b develop https://github.com/ossrs/srs.git
```
Build SRS in `srs/trunk`:
```
cd srs/trunk
./configure
make
```
Run SRS server:
```
./objs/srs -c conf/srs.conf
```
Check SRS by [http://localhost:8080/](http://localhost:8080/) or:
```
# Check the process status
./etc/init.d/srs status
# Check the SRS logs
tail -n 30 -f ./objs/srs.log
```
Publish stream by [FFmpeg](https://ffmpeg.org/download.html) or [OBS](https://obsproject.com/download) :
```bash
ffmpeg -re -i ./doc/source.flv -c copy -f flv rtmp://localhost/live/livestream
```
> Note: The file `./doc/source.flv` is under the source repository of SRS.
Play stream by:
* RTMP (by [VLC](https://www.videolan.org/)): `rtmp://localhost/live/livestream`
* H5(HTTP-FLV): [http://localhost:8080/live/livestream.flv](http://localhost:8080/players/srs_player.html?autostart=true&stream=livestream.flv&port=8080&schema=http)
* H5(HLS): [http://localhost:8080/live/livestream.m3u8](http://localhost:8080/players/srs_player.html?autostart=true&stream=livestream.m3u8&port=8080&schema=http)
## WebRTC
SRS supports WebRTC for video chat.
Get SRS source, recommend [Ubuntu20](./install.md):
```
git clone -b develop https://github.com/ossrs/srs.git
```
Build SRS in `srs/trunk`:
```
cd srs/trunk
./configure
make
```
Run SRS server:
```
CANDIDATE="192.168.1.10"
./objs/srs -c conf/srs.conf
```
> Note: Please replace the IP with your server IP.
> Note: About CANDIDATE, please read [CANDIDATE](./webrtc.md#config-candidate)
Check SRS by [http://localhost:8080/](http://localhost:8080/) or:
```
# Check the process status
./etc/init.d/srs status
# Check the SRS logs
tail -n 30 -f ./objs/srs.log
```
If SRS runs on localhost, push stream to SRS by [WebRTC: Publish](http://localhost:8080/players/rtc_publisher.html?autostart=true&stream=livestream&port=8080&schema=http)
> Note: If not localhost, browser(WebRTC) requires HTTPS, please see [WebRTC using HTTPS](./getting-started.md#webrtc-using-https) for detail.
Play stream of SRS by [WebRTC: Play](http://localhost:8080/players/rtc_player.html?autostart=true&stream=livestream&schema=http)
> Note: If use different streams, you're able to do video chat application.
## WebRTC for Live Streaming
SRS supports converting live streaming to WebRTC.
Get SRS source, recommend [Ubuntu20](./install.md):
```
git clone -b develop https://github.com/ossrs/srs.git
```
Build SRS in `srs/trunk`:
```
cd srs/trunk
./configure
make
```
Run SRS server:
```
CANDIDATE="192.168.1.10"
./objs/srs -c conf/rtmp2rtc.conf
```
> Note: Please replace the IP with your server IP.
> Note: About CANDIDATE, please read [CANDIDATE](./webrtc.md#config-candidate)
> Note: If convert RTMP to WebRTC, please use [`rtmp2rtc.conf`](https://github.com/ossrs/srs/issues/2728#rtmp2rtc-cn-guide)
Publish stream by [FFmpeg](https://ffmpeg.org/download.html) or [OBS](https://obsproject.com/download) :
```bash
ffmpeg -re -i ./doc/source.flv -c copy -f flv rtmp://localhost/live/livestream
```
> Note: The file `./doc/source.flv` is under the source repository of SRS.
Play stream by:
* WebRTC: [http://localhost:1985/rtc/v1/whep/?app=live&stream=livestream](http://localhost:8080/players/whep.html?autostart=true)
* H5(HTTP-FLV): [http://localhost:8080/live/livestream.flv](http://localhost:8080/players/srs_player.html?autostart=true&stream=livestream.flv&port=8080&schema=http)
* H5(HLS): [http://localhost:8080/live/livestream.m3u8](http://localhost:8080/players/srs_player.html?autostart=true&stream=livestream.m3u8&port=8080&schema=http)
## WebRTC using HTTPS
If not localhost, for example, to view WebRTC on pad or mobile phone, when SRS is running on remote server.
Get SRS source, recommend [Ubuntu20](./install.md):
```
git clone -b develop https://github.com/ossrs/srs.git
```
Build SRS in `srs/trunk`:
```
cd srs/trunk
./configure
make
```
Run SRS server:
```
CANDIDATE="192.168.1.10"
./objs/srs -c conf/https.rtc.conf
```
> Note: Please replace the IP with your server IP.
> Note: About CANDIDATE, please read [CANDIDATE](./webrtc.md#config-candidate)
> Remark: Please use your HTTPS key and cert file, please read
> **[HTTPS API](./http-api.md#https-api)**
> and **[HTTPS Callback](./http-callback.md#https-callback)**
> and **[HTTPS Live Streaming](./flv.md#https-flv-live-stream)**,
> however HTTPS proxy also works perfect with SRS such as Nginx.
Push stream to SRS by [WebRTC: Publish](https://192.168.3.82:8088/players/rtc_publisher.html?autostart=true&stream=livestream&api=1990&schema=https)
Play stream of SRS by [WebRTC: Play](https://192.168.3.82:8088/players/rtc_player.html?autostart=true&stream=livestream&api=1990&schema=https)
> Note: For self-sign certificate, please type `thisisunsafe` to accept it.
> Note: If use different streams, you're able to do video chat application.
## Cross Build
Normally you're able to build SRS on both ARM or MIPS servers.
If need to cross-build SRS for embed devices, pelase read [ARM and CrossBuild](./arm.md).
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/getting-started-build)

22
trunk/3rdparty/srs-docs/doc/getting-started-k8s.md vendored Normal file
View File

@ -0,0 +1,22 @@
---
title: K8s
sidebar_label: K8s
hide_title: false
hide_table_of_contents: false
---
# K8s
We recommend using the HELM method to deploy SRS, see [srs-helm](https://github.com/ossrs/srs-helm). Of course,
SRS also supports direct deployment with K8s, refer to [SRS K8s](./k8s.md).
Actually, HELM is based on K8s and deploys K8s pods, which can be managed with kubectl. However, HELM offers a
more convenient way to manage and install applications, so SRS will mainly support HELM in the future.
Compared to Docker, HELM and K8s are mainly for medium to large scale deployments. If your business is not that
big, we recommend using Docker or Oryx directly. Generally, if you have less than a thousand streams, please
do not use HELM or K8s.
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/getting-started-k8s)

424
trunk/3rdparty/srs-docs/doc/getting-started-oryx.md vendored Normal file
View File

@ -0,0 +1,424 @@
---
title: Oryx
sidebar_label: Oryx
hide_title: false
hide_table_of_contents: false
---
# Oryx
Oryx(SRS Stack) is a video cloud solution that is lightweight, open-source, and based on Go,
Reactjs, SRS, FFmpeg, WebRTC, etc.
## Introduction
Oryx, an open-source out-of-the-box audio and video solution, is built entirely based on various scenarios.
Common examples include push-pull streaming scenarios that support different protocols and can be embedded into
websites like WordPress.
In recording scenarios, it supports merging multiple streams, setting filters, and recording specific streams only.
For forwarding and virtual live streaming, files and other streams can be sent to different platforms or to Oryx
itself. With AI automatic subtitles, OpenAI's capabilities can be utilized to automatically recognize and embed
subtitles into the video stream. One-click automatic HTTPS makes it easy to enable HTTPS capabilities.
More diverse scenarios will be available in the future.
## FAQ
If you encounter issues while using Oryx, please read the [FAQ](../../../faq-oryx) first.
## Usage
Please select your platform.
> Remark: Please choose the Ubuntu 20 system, as other systems may encounter some strange issues.
### Docker
Strongly recommend running Oryx with docker:
```bash
docker run --restart always -d -it --name oryx -v $HOME/data:/data \
-p 80:2022 -p 443:2443 -p 1935:1935 -p 8000:8000/udp -p 10080:10080/udp \
ossrs/oryx:5
```
Then you can open [http://localhost](http://localhost) to use Oryx.
For more details, please refer to [Oryx Docker](https://github.com/ossrs/oryx#usage).
### HELM
Strongly recommend running Oryx with HELM:
```bash
helm repo add srs http://helm.ossrs.io/stable
helm install srs srs/oryx --set persistence.path=$HOME/data \
--set service.http=80 --set service.https=443 --set service.rtmp=1935 \
--set service.rtc=8000 --set service.srt=10080
```
Then you can open [http://localhost](http://localhost) to use Oryx.
### Script
For Ubuntu 20+, you can download the [linux-oryx-en.tar.gz](https://github.com/ossrs/oryx/releases/latest/download/linux-oryx-en.tar.gz)
and install it.
### AWS Lightsail
Oryx supports AWS Lightsail, which is a virtual private server (VPS) service offered by AWS. Please
follow [How to Establish a Video Streaming Service with a Single Click](../../../blog/Oryx-Tutorial).
### DigitalOcean Droplet
Easily set up an Oryx with just one click. For more information, check out
[How to Establish a Video Streaming Service with a Single Click](../../../blog/Oryx-Tutorial).
### aaPanel
Oryx offers a BaoTa plugin, for usage instructions refer to the [Oryx aaPanel Plugin](../../../blog/BT-aaPanel).
## Changelog
For the update log of the Oryx, please refer to [CHANGELOG](https://github.com/ossrs/oryx/blob/main/DEVELOPER.md#changelog).
For specific features supported by a particular version, you can view the CHANGELOG in the version release, see [Releases](https://github.com/ossrs/oryx/releases).
## Features
About the features of Oryx and comparison with SRS，for more details please read [Features](https://github.com/ossrs/oryx?tab=readme-ov-file#features).
### Compare to SRS
Comparing Oryx and SRS, both offer media streaming capabilities at a similar level.
However, Oryx provides a more powerful and feature-rich experience for end users,
eliminating the need to write any code. Users can directly utilize Oryx for your
media services needs.
| Comparison | Oryx | SRS | Notes |
|----------------|-------------------|---------------|-----------------------------------------------------------------|
| License | MIT | MIT | SRS is licenced under MIT, Oryx is MIT. |
| Live Streaming | Yes | Yes | Both support RTMP, HLS, and HTTP-FLV protocols. |
| WebRTC | Yes | Yes | WebRTC is supported by both. |
| Auto HTTPS | Yes | No | Oryx supports automatic request and update HTTPS certs. |
| Console | Enhanced | HTTP API | Oryx offers a more powerful console. |
| Authentication | Yes | HTTP Callback | Oryx has built-in authentication, while SRS uses callbacks. |
| DVR | Enhanced | File-based | Oryx supports DVR to file and cloud storage. |
| Forwarding | Enhanced | Basic | Oryx can forward to multiple platforms via various protocols. |
| Virtual Live | Yes | No | Oryx provides advanced virtual live streaming capabilities. |
| WordPress | Yes | No | Oryx offers a WordPress plugin and step-by-step guidelines. |
| Transcoding | Yes | No | Oryx supports live stream transcoding. |
| Transcription | Yes | No | Convert live speech to subtitle and overlay to video stream. |
| Live Room | Yes | No | Support live room feature. |
| Dubbing | Yes | No | Support dubbing VoD videos. |
### Streaming and Authentication
Oryx support enhanced streaming with authentication, based on SRS callback. Oryx generate and save
the stream token to Redis, and verify the stream token when user publish stream via RTMP, SRT, or WHIP/WebRTC.
Oryx also proxies and secures all the HTTP API of SRS, so only authenticated user can access the HTTP API
and the console.
### DVR
Oryx support DVR or Recording, to convert live stream to file, then save to local disk or cloud storage.
We also support merge multiple republish session to one DVR file, and support set filters for recording specified
streams.
See [A Step-by-Step Guide to Server-Side Recording and AWS S3 Integration](../../../blog/Record-Live-Streaming) for details.
### Automatic HTTPS
Oryx support automatic HTTPS, just by one click, you can enable HTTPS for your Oryx. Oryx will
automatically request and update the HTTPS certificate from [Let's Encrypt](https://letsencrypt.org/). Automatic HTTPS
allows WHIP or publish by webpage, and also support WebRTC, and access user's microphones.
See [How to Secure SRS with Let's Encrypt by 1-Click](../../../blog/Oryx-HTTPS) for details.
### Virtual Live Events
You can use prerecorded videos to simulate live events. You can do 7x24 live stream with only 1 video file. You can
also pull stream to your live room, to make the live stream powerful. You can even pull your IP camera stream to your
live room.
See [Harness the Power of Pre-Recorded Content for Seamless and Engaging Live Streaming Experiences](../../../blog/Virtual-Live-Events) and
[Easily Stream Your RTSP IP Camera to YouTube, Twitch, or Facebook](../../../blog/Stream-IP-Camera-Events).
### Restream
With Oryx, you can restream to multiple platforms, like YouTube, Twitch, Facebook, etc. Oryx will
automatically select a stream to forward, so you can publish multiple streams as fault-tolerant or backup
stream, when a stream is down, Oryx will switch to another one.
See [Effortlessly Restream Live Content Across Multiple Platforms with Oryx](../../../blog/Multi-Platform-Streaming) for details.
### AI Transcription
Oryx supports AI transcription, which is powered by OpenAI, to convert live speech to text and overlay to
the video stream as a new live stream. With this feature, allows you to engage more audiences, especially for people
with hearing disabilities or those who are non-native speakers.
See [Creating Accessible, Multilingual Subtitles for Diverse Audiences](../../../blog/live-streams-transcription) for details.
### Transcode
Oryx suppport transcoding live stream, to decrease the bitrate and save bandwidth and cost, or filter the
live stream content to make it better.
See [Efficient Live Streaming Transcoding for Reducing Bandwidth and Saving Costs](../../../blog/Live-Transcoding) for details.
## AI Products
We are implementing various AI tools and products in the Oryx, and here is the latest status. We will continue
to update this document.
1. AI Transcript: Implement voice-to-text by connecting to OpenAI's Whisper, and overlay the text captions onto the live broadcast, enabling automatic subtitles for streaming.
* Status: Completed and available in the Oryx. Refer to [Creating Accessible, Multilingual Subtitles for Diverse Audiences](../../../blog/live-streams-transcription).
1. Streamer AI Asssistant: Easily create a personal, voice-driven GPT AI assistant with Oryx for enhanced language learning, multi-language chats, and convenient assistance in any setting. Perfect for interactive streaming and daily tasks. It offers numerous possibilities for living room and streaming hosts with AI assistance.
* Status: Beta version available in the Oryx. Refer to [Speak to the Future - Transform Your Browser into a Personal Voice-Driven GPT AI Assistant with Oryx](../../../blog/browser-voice-driven-gpt).
1. VoD Translation: Translate English videos into Chinese for English learning or create multilingual videos, frequently used in education and e-commerce.
* Beta version available in the Oryx. Refer to [Revolutionize Video Content with Oryx - Effortless Dubbing and Translating to Multiple Languages Using OpenAI](../../../blog/dubbing-translating).
1. Stream OCR: Extract text from images in live streams, enabling real-time text recognition and translation for a variety of applications.
* Beta version available in the Oryx. Refer to [Oryx - Leveraging OpenAI for OCR and Object Recognition in Video Streams](../../../blog/ocr-video-streams).
If you are interested in our AI products, feel free to join our [Discord](https://discord.gg/yZ4BnPmHAd) server to discuss with us.
## HTTP API
You can open the `System > OpenAPI` to get the Bearer token and try the HTTP API.
You can click the button on the web to request a HTTP API, you can also use the curl or js code to request the
HTTP API. Please follow the instructions on the web, for example, use curl to request the HTTP API:
```bash
curl http://localhost/terraform/v1/mgmt/versions
```
Or with the Bearer token:
```bash
curl http://localhost/terraform/v1/hooks/srs/secret/query \
-X POST -H 'Authorization: Bearer xxxxxx' \
-H 'Content-Type: application/json' --data '{}'
```
> Note: You can open the `System > OpenAPI` to get the Bearer token and try the HTTP API.
> Note: The web may use JWT token, but you can also use Bearer token to request the HTTP API.
In addition to the sample APIs listed on this page, users can perform all web-based actions through the
HTTP API. To identify the requests and responses for each API, open Google Chrome, navigate to
`View > Developer > Developer Tools` click on the `Network` tab, and examine the relevant API interactions.
Oryx also proxy the [SRS HTTP API](./http-api.md), which prefix with `/api/v1/` such as:
```bash
curl http://localhost/api/v1/versions
```
Or with the Bearer token:
```bash
curl http://localhost/api/v1/vhosts/ \
-X GET -H 'Authorization: Bearer xxxxxx' \
-H 'Content-Type: application/json'
```
> Note: You can open the `System > OpenAPI` to get the Bearer token and try the HTTP API.
Please read the detail about the API from the [SRS HTTP API](./http-api.md).
## HTTP Callback
HTTP Callback refers to the Oryx running within a Docker container, initiating an HTTP request to
a target URL. For instance, the following process illustrates that when OBS publishs an RTMP stream to Oryx,
the Oryx informs your server about the event by sending an HTTP request to the target URL.
```bash
+-----------------------+
+ +
+-------+ + +-----------+ + +--------------+
+ OBS +--RTMP->--+-----+ Oryx +-----+----HTTP--->-----+ Your Server +
+-------+ + +-----------+ + (Target URL) +--------------+
+ +
+ Docker +
+-----------------------+
```
All HTTP requests should be:
* `Content-Type: application-json`
All responses should use:
* `Status: 200 OK` and `{"code": 0}` for success.
* Otherwise, error or fail.
See examples in [HTTP Callback](../docs/v7/doc/http-callback#go-example)
### HTTP Callback: Connectivity Check
Occasionally, you might need to verify if the network is accessible and determine the appropriate target URL to
use. By using the curl command inside the Docker container, you can simulate this request and confirm if the
target URL can be accessed by curl or the Oryx.
First, install curl in Oryx:
```bash
docker exec -it oryx apt-get update -y
docker exec -it oryx apt-get install -y curl
```
Then, simulate an HTTP request to your server:
```bash
docker exec -it oryx curl http://your-target-URL
```
You can use any target URL to test, such as:
* Intranet IP: `http://192.168.1.10/check`
* Internet IP: `http://159.133.96.20/check`
* URL via HTTP: `http://your-domain.com/check`
* URL via HTTPS: `https://your-domain.com/check`
Keep in mind that you should test the connection to the target URL within the Oryx Docker, and avoid
running the curl command from a different server.
### HTTP Callback: on_publish
For HTTP callback `on_publish` event:
```json
Request:
{
"request_id": "3ab26a09-59b0-42f7-98e3-a281c7d0712b",
"action": "on_publish",
"opaque": "mytoken",
"vhost": "__defaultVhost__",
"app": "live",
"stream": "livestream",
"param": "?secret=8f7605d657c74d69b6b48f532c469bc9"
}
Response:
{
"code": 0
}
```
* Allow publishing if response success.
* Reject publishing if response error.
### HTTP Callback: on_unpublish
For HTTP callback `on_unpublish` event:
```json
Request:
{
"request_id": "9ea987fa-1563-4c28-8c6c-a0e9edd4f536",
"action": "on_unpublish",
"opaque": "mytoken",
"vhost": "__defaultVhost__",
"app": "live",
"stream": "livestream"
}
Response:
{
"code": 0
}
```
* Ignore any response error.
### HTTP Callback: on_record_begin
For HTTP callback `on_record_begin` event:
```json
Request:
{
"request_id": "80ad1ddf-1731-450c-83ec-735ea79dd6a3",
"action": "on_record_begin",
"opaque": "mytoken",
"vhost": "__defaultVhost__",
"app": "live",
"stream": "livestream",
"uuid": "824b96f9-8d51-4046-ba1e-a9aec7d57c95"
}
Response:
{
"code": 0
}
```
* Ignore any response error.
### HTTP Callback: on_record_end
For HTTP callback `on_record_end` event:
```json
Request:
{
"request_id": "d13a0e60-e2fe-42cd-a8d8-f04c7e71b5f5",
"action": "on_record_end",
"opaque": "mytoken",
"vhost": "__defaultVhost__",
"app": "live",
"stream": "livestream",
"uuid": "824b96f9-8d51-4046-ba1e-a9aec7d57c95",
"artifact_code": 0,
"artifact_path": "/data/record/824b96f9-8d51-4046-ba1e-a9aec7d57c95/index.mp4",
"artifact_url": "http://localhost/terraform/v1/hooks/record/hls/824b96f9-8d51-4046-ba1e-a9aec7d57c95/index.mp4"
}
Response:
{
"code": 0
}
```
* The `uuid` is the UUID of record task.
* The `artifact_code` indicates the error code. If no error, it's 0.
* The `artifact_path` is the path of artifact mp4 in the container.
* The `artifact_url` is the URL path to access the artifact mp4.
* Ignore any response error.
### HTTP Callback: on_ocr
For HTTP callback `on_ocr` event:
```json
Request:
{
"request_id": "d13a0e60-e2fe-42cd-a8d8-f04c7e71b5f5",
"action": "on_ocr",
"opaque": "mytoken",
"vhost": "__defaultVhost__",
"app": "live",
"stream": "livestream",
"uuid": "824b96f9-8d51-4046-ba1e-a9aec7d57c95",
"prompt": "What is in the image?",
"result": "The image shows a scene featuring a character from a film, likely set in a military or high-tech environment."
}
Response:
{
"code": 0
}
```
* The `uuid` is the UUID of OCR task.
* The `prompt` the AI model used for OCR.
* The `result` is the OCR result.
* Ignore any response error.
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/getting-started-oryx)

190
trunk/3rdparty/srs-docs/doc/getting-started.md vendored Normal file
View File

@ -0,0 +1,190 @@
---
title: Docker
sidebar_label: Docker
hide_title: false
hide_table_of_contents: false
---
# Docker
Please run SRS with docker.
## Live Streaming
SRS supports live streaming.
Run SRS using docker:
```bash
docker run --rm -it -p 1935:1935 -p 1985:1985 -p 8080:8080 ossrs/srs:5
```
> Note: The available images is [here](https://hub.docker.com/r/ossrs/srs/tags).
Use docker of FFmpeg to publish:
```bash
docker run --rm -it ossrs/srs:encoder ffmpeg -stream_loop -1 -re -i doc/source.flv \
-c copy -f flv rtmp://host.docker.internal/live/livestream
```
Or publish stream by [FFmpeg](https://ffmpeg.org/download.html) or [OBS](https://obsproject.com/download) :
```bash
ffmpeg -re -i ./doc/source.flv -c copy -f flv rtmp://localhost/live/livestream
```
> Note: The file `./doc/source.flv` is under the source repository of SRS.
Play stream by:
* RTMP (by [VLC](https://www.videolan.org/)): `rtmp://localhost/live/livestream`
* H5(HTTP-FLV): [http://localhost:8080/live/livestream.flv](http://localhost:8080/players/srs_player.html?autostart=true&stream=livestream.flv&port=8080&schema=http)
* H5(HLS): [http://localhost:8080/live/livestream.m3u8](http://localhost:8080/players/srs_player.html?autostart=true&stream=livestream.m3u8&port=8080&schema=http)
## WebRTC
SRS supports WebRTC for video chat.
Run SRS using docker:
```bash
CANDIDATE="192.168.1.10"
docker run --rm -it -p 1935:1935 -p 1985:1985 -p 8080:8080 -p 1990:1990 -p 8088:8088 \
--env CANDIDATE=$CANDIDATE -p 8000:8000/udp \
ossrs/srs:5
```
> Note: Please replace the IP with your server IP.
> Note: About CANDIDATE, please read [CANDIDATE](./webrtc.md#config-candidate)
If SRS runs on localhost, push stream to SRS by [WebRTC: Publish](http://localhost:8080/players/rtc_publisher.html?autostart=true&stream=livestream&port=8080&schema=http)
> Note: If not localhost, browser(WebRTC) requires HTTPS, please see [WebRTC using HTTPS](./getting-started.md#webrtc-using-https) for detail.
Play stream of SRS by [WebRTC: Play](http://localhost:8080/players/rtc_player.html?autostart=true&stream=livestream&schema=http)
> Note: If use different streams, you're able to do video chat application.
## WebRTC for Live Streaming
SRS supports coverting live streaming to WebRTC.
Run SRS using docker:
```bash
CANDIDATE="192.168.1.10"
docker run --rm -it -p 1935:1935 -p 1985:1985 -p 8080:8080 \
--env CANDIDATE=$CANDIDATE -p 8000:8000/udp \
ossrs/srs:5 ./objs/srs -c conf/rtmp2rtc.conf
```
> Note: Please replace the IP with your server IP.
> Note: About CANDIDATE, please read [CANDIDATE](./webrtc.md#config-candidate)
> Note: If convert RTMP to WebRTC, please use [`rtmp2rtc.conf`](https://github.com/ossrs/srs/issues/2728#rtmp2rtc-en-guide)
Use docker of FFmpeg to publish:
```bash
docker run --rm -it ossrs/srs:encoder ffmpeg -stream_loop -1 -re -i doc/source.flv \
-c copy -f flv rtmp://host.docker.internal/live/livestream
```
Or publish stream by [FFmpeg](https://ffmpeg.org/download.html) or [OBS](https://obsproject.com/download) :
```bash
ffmpeg -re -i ./doc/source.flv -c copy -f flv rtmp://localhost/live/livestream
```
> Note: The file `./doc/source.flv` is under the source repository of SRS.
Play stream by:
* WebRTC: [http://localhost:1985/rtc/v1/whep/?app=live&stream=livestream](http://localhost:8080/players/whep.html?autostart=true)
* H5(HTTP-FLV): [http://localhost:8080/live/livestream.flv](http://localhost:8080/players/srs_player.html?autostart=true&stream=livestream.flv&port=8080&schema=http)
* H5(HLS): [http://localhost:8080/live/livestream.m3u8](http://localhost:8080/players/srs_player.html?autostart=true&stream=livestream.m3u8&port=8080&schema=http)
## WebRTC using HTTPS
When pushing stream to SRS, if not localhost, for example, to view WebRTC on pad or mobile phone, when SRS is running on remote server.
> Note: If only need to play WebRTC stream, HTTP is ok. If wants to push stream, and not localhost, you need HTTPS.
Run SRS using docker:
```bash
CANDIDATE="192.168.1.10"
docker run --rm -it -p 1935:1935 -p 1985:1985 -p 8080:8080 -p 1990:1990 -p 8088:8088 \
--env CANDIDATE=$CANDIDATE -p 8000:8000/udp \
ossrs/srs:5 ./objs/srs -c conf/https.docker.conf
```
> Note: Please replace the IP with your server IP.
> Note: About CANDIDATE, please read [CANDIDATE](./webrtc.md#config-candidate)
> Remark: Please use your HTTPS key and cert file, please read
> **[HTTPS API](./http-api.md#https-api)**
> and **[HTTPS Callback](./http-callback.md#https-callback)**
> and **[HTTPS Live Streaming](./flv.md#https-flv-live-stream)**,
> however HTTPS proxy also works perfect with SRS such as Nginx.
Push stream to SRS by [WebRTC: Publish](https://192.168.3.82:8088/players/rtc_publisher.html?autostart=true&stream=livestream&api=1990&schema=https)
Play stream of SRS by [WebRTC: Play](https://192.168.3.82:8088/players/rtc_player.html?autostart=true&stream=livestream&api=1990&schema=https)
> Note: For self-sign certificate, please type `thisisunsafe` to accept it.
> Note: If use different streams, you're able to do video chat application.
## SRT for Live Streaming
SRS supports publishing by SRT for live streaming, and play by SRT or other protocols.
First, start SRS with Docker:
```bash
docker run --rm -it -p 1935:1935 -p 1985:1985 -p 8080:8080 -p 10080:10080/udp \
ossrs/srs:5 ./objs/srs -c conf/srt.conf
```
Publish stream by [FFmpeg](https://ffmpeg.org/download.html) or [OBS](https://obsproject.com/download) :
```bash
ffmpeg -re -i ./doc/source.flv -c copy -pes_payload_size 0 -f mpegts \
'srt://127.0.0.1:10080?streamid=#!::r=live/livestream,m=publish'
```
Play stream by [ffplay](https://ffmpeg.org/download.html) or [OBS](https://obsproject.com/download)
```bash
ffplay 'srt://127.0.0.1:10080?streamid=#!::r=live/livestream,m=request'
```
## Multiple Streams
You can send multiple streams to SRS by using different URLs. There's no need to change any settings;
just change the URL for the stream you're publishing and playing. It's very easy and straightforward.
* `rtmp://ip/live/livesteam`
* `rtmp://ip/live/livesteamN`
* `rtmp://ip/liveN/livestreamN`
* `rtmp://ip/whatever/doesnotmatter`
* `srt://ip:10080?streamid=#!::r=anyM/streamN,m=publish`
* `http://ip:1985/rtc/v1/whip/?app=anyM&stream=streamN`
* `http://ip:1985/rtc/v1/whep/?app=anyM&stream=streamN`
* `http://ip:8080/anyM/streamN.flv`
* `http://ip:8080/anyM/streamN.m3u8`
* `https://ip:8080/anyM/streamN.flv`
* `https://ip:8080/anyM/streamN.m3u8`
SRS uses a configuration at the virtual host (vhost) level. All applications(app) and streams within the
same vhost share this configuration. For more information, please refer to the [RTMP URL](./rtmp-url-vhost.md)
documentation.
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/getting-started)

59
trunk/3rdparty/srs-docs/doc/git.md vendored Normal file
View File

@ -0,0 +1,59 @@
---
title: Git
sidebar_label: Git
hide_title: false
hide_table_of_contents: false
---
# Git Usage
How to use stable version of SRS? How to update code?
## Checkout Branch
Some features are introduced in SRS2.0, the SRS1.0 does not support.
The wiki url specifies the version of SRS supports it.
To checkout SRS1.0 branch:
```
git pull && git checkout 1.0release
```
To checkout SRS2.0 branch:
```
git pull && git checkout 2.0release
```
To checkout SRS3.0 branch:
```
git pull && git checkout 3.0release
```
To checkout SRS4.0 branch:
```
git pull && git checkout 4.0release
```
To checkout SRS5.0 branch(if no 5.0release branch, it's develop):
```
git pull && git checkout develop
```
## SRS Branches
The release branch is more stable than develop.
* 3.0release, stable release branch.
* 4.0release, stable release branch.
* develop(5.0), not stable.
Winlin 2014.11
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/git)

14
trunk/3rdparty/srs-docs/doc/gperf.md vendored Normal file
View File

@ -0,0 +1,14 @@
---
title: GPERF
sidebar_label: GPERF
hide_title: false
hide_table_of_contents: false
---
# GPerf
No English version, please read [v4_CN_GPERF](./gperf.md) or [SRS性能(CPU)、内存优化工具用法](https://www.jianshu.com/p/6d4a89359352)
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/gperf)

14
trunk/3rdparty/srs-docs/doc/gprof.md vendored Normal file
View File

@ -0,0 +1,14 @@
---
title: GPROF
sidebar_label: GPROF
hide_title: false
hide_table_of_contents: false
---
# Gprof
Please read [SRS性能(CPU)、内存优化工具用法](https://www.jianshu.com/p/6d4a89359352)
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/gprof)

333
trunk/3rdparty/srs-docs/doc/hevc.md vendored Normal file
View File

@ -0,0 +1,333 @@
---
title: HEVC
sidebar_label: HEVC
hide_title: false
hide_table_of_contents: false
---
# HEVC
HEVC, also known as H.265, is the next-generation encoding after H.264 and belongs to the same generation of codecs
as AV1. H.265 can save about half the bandwidth compared to H.264, or provide double the clarity and image quality at
the same bandwidth.
However, the problem with H.265 is that it's not yet widely supported by clients. Almost all devices support H.264,
including low-performance phones or boxes, which have dedicated chips for H.264 support. Although H.265 has been
developed for almost ten years, there are still not enough devices that support it. In specific scenarios, like when
the device clearly supports H.265, you can choose H.265; otherwise, stick with H.264.
Additionally, the support for H.265 in transport protocols is gradually improving, but not all protocols support it
yet. MPEG-TS was the first to support H.265, and since SRT and HLS are based on TS, they also support it. RTMP and
HTTP-FLV only started supporting HEVC and AV1 in March 2023 with the [Enhanced RTMP](https://github.com/veovera/enhanced-rtmp)
project. As for WebRTC, only Safari supports it currently, and Chrome is said to be in development.
SRS 6.0 officially supports the H.265 feature. If you want to use the H.265 function, please switch to the SRS
6.0 version. Please refer to [#465](https://github.com/ossrs/srs/issues/465) for the detailed research and development process.
## Overview
The architecutre for SRS to support H.265(or HEVC):
```text
FFmpeg --RTMP(h.265)---> SRS ----RTMP/FLV/TS/HLS/WebRTC(h.265)--> Chrome/Safari
```
For live streaming:
* [Chrome 105+](https://caniuse.com/?search=HEVC) supports HEVC by default, see [this post](https://zhuanlan.zhihu.com/p/541082191).
* You're able to play mp4 directly by H5 video, or by MSE if HTTP-FLV/HTTP-TS/HLS etc.
* Please use [mpegts.js](https://github.com/xqq/mpegts.js) to play HTTP-TS with HEVC.
* There is a plan for mpegts.js to support HTTP-FLV with HEVC, see [mpegts.js#64](https://github.com/xqq/mpegts.js/issues/64)
* [OBS 29+](https://github.com/obsproject/obs-studio/releases/tag/29.1.3) supports HEVC over RTMP.
* FFmpeg or ffplay supports libx265
* FFmpeg 6 supports HEVC over RTMP, see [637c761b](https://github.com/FFmpeg/FFmpeg/commit/637c761be1bf9c3e1f0f347c5c3a390d7c32b282) for detail.
* FFmpeg 4 or 5, need some patch for HEVC over RTMP/FLV, see **[FFmpeg Tools](#ffmpeg-tools)** bellow.
* SRS also supports HEVC.
* We have merged HEVC support into SRS 6.0
* The original supports for HEVC is [srs-gb28181/feature/h265](https://github.com/ossrs/srs-gb28181/commits/feature/h265) by [runner365](https://github.com/runner365)
> Note: To check if your Chrome support HEVC, please open `chrome://gpu` and search `hevc`.
For WebRTC:
* Chrome does not support HEVC right now(2022.11), but supports AV1, please see [#2324](https://github.com/ossrs/srs/pull/2324)
* Safari supports HEVC if user enable it, please see this [section](#safari-webrtc)
* SRS also only supports AV1, because Chrome does not support HEVC yet.
## Usage
Please make sure your SRS is `6.0.4+`, build with h265:
```bash
docker run --rm -it -p 1935:1935 -p 8080:8080 ossrs/srs:6 \
./objs/srs -c conf/hevc.flv.conf
```
> Note: Besides environment variables, you can also use `conf/hevc.flv.conf` or `conf/hevc.ts.conf` config files.
> Note: Recommend `conf/hevc.ts.conf` because TS is better for HEVC.
Build and patch FFmpeg, see [FFmpeg Tools](#ffmpeg-tools):
```bash
# For macOS
docker run --rm -it ossrs/srs:encoder ffmpeg -stream_loop -1 -re -i doc/source.flv \
-acodec copy -vcodec libx265 -f flv rtmp://host.docker.internal/live/livestream
# For linux
docker run --net=host --rm -it ossrs/srs:encoder ffmpeg -stream_loop -1 -re -i doc/source.flv \
-acodec copy -vcodec libx265 -f flv rtmp://127.0.0.1/live/livestream
```
> Note: Please change the ip `host.docker.internal` to your SRS's IP.
Play the HEVC live streams by:
* HTTP-FLV(by H5): [http://localhost:8080/live/livestream.flv](http://localhost:8080/players/srs_player.html?autostart=true)
* HLS(by VLC or fflay): `http://localhost:8080/live/livestream.m3u8`
> Note: Please enable MPEG-DASH by `SRS_VHOST_DASH_ENABLED=on` then use VLC/ffplay to play stream `http://localhost:8080/live/livestream.mpd`
> Note: Please enable HTTP-TS by `SRS_VHOST_HTTP_REMUX_MOUNT=[vhost]/[app]/[stream].ts` then use H5/VLC/ffplay to play stream `http://localhost:8080/live/livestream.ts`
> Note: Please enable DVR MP4 by `SRS_VHOST_DVR_ENABLED=on SRS_VHOST_DVR_DVR_PATH=./objs/nginx/html/[app]/[stream].[timestamp].mp4` if want to covert live stream to MP4 file.
> Note: The detail about available protocols and tools for HEVC, please see [Status of HEVC in SRS](#status-of-hevc-in-srs).
> Note: The H5 player uses [mpegts.js](https://github.com/xqq/mpegts.js).
## Status of HEVC in SRS
The status of protocols and HEVC:
* [x] PUSH HEVC over RTMP by FFmpeg. [v6.0.2](https://github.com/ossrs/srs/commit/178e40a5fc3cf0856ace914ae61696a73007f5bf)
* [x] PUSH HEVC over SRT by FFmpeg. [v6.0.20](https://github.com/ossrs/srs/pull/3366)
* [x] PUSH HEVC over RTMP by OBS. [#3464](https://github.com/ossrs/srs/issues/3464) https://github.com/obsproject/obs-studio/pull/8522
* [x] PUSH HEVC over SRT by OBS. [v6.0.20](https://github.com/ossrs/srs/pull/3366)
* [x] PUSH HEVC over GB28181. [v6.0.25](https://github.com/ossrs/srs/pull/3408)
* [x] PULL HEVC over RTMP by FFmpeg, with [patch](#ffmpeg-tools) for FFmpeg. [v6.0.2](https://github.com/ossrs/srs/commit/178e40a5fc3cf0856ace914ae61696a73007f5bf)
* [x] PULL HEVC over HTTP-FLV by FFmpeg, with [patch](#ffmpeg-tools) for FFmpeg. [v6.0.2](https://github.com/ossrs/srs/commit/178e40a5fc3cf0856ace914ae61696a73007f5bf)
* [x] PULL HEVC over HTTP-TS by FFmpeg [v6.0.4](https://github.com/ossrs/srs/commit/70d5618979e5c8dc41b7cd87c78db7ca2b8a10e8)
* [x] PULL HEVC over HLS by FFmpeg [v6.0.11](https://github.com/ossrs/srs/commit/fff8d9863c3fba769b01782428257edf40f80a12)
* [x] PULL HEVC over MPEG-DASH by FFmpeg [v6.0.14](https://github.com/ossrs/srs/commit/edba2c25f13c0fa915bd8e8093a4005df6077858)
* [x] PULL HEVC over SRT by FFmpeg. [v6.0.20](https://github.com/ossrs/srs/pull/3366)
* [x] PUSH HEVC over WebRTC by Safari. [v6.0.34](https://github.com/ossrs/srs/pull/3441)
* [x] PULL HEVC over WebRTC by Safari. [v6.0.34](https://github.com/ossrs/srs/pull/3441)
* [ ] PUSH HEVC over WebRTC by Chrome/Firefox
* [ ] PULL HEVC over WebRTC by Chrome/Firefox
* [x] Play HEVC over HTTP-TS by [mpegts.js](https://github.com/xqq/mpegts.js), by Chrome 105+ MSE, **NO WASM**. [v6.0.1](https://github.com/ossrs/srs/commit/7e02d972ea74faad9f4f96ae881d5ece0b89f33b)
* [x] Play pure video(no audio) HEVC over HTTP-TS by [mpegts.js](https://github.com/xqq/mpegts.js). [v6.0.9](https://github.com/ossrs/srs/commit/d5bf0ba2da30698e18700b210d2b12eed5b21d29)
* [x] Play HEVC over HTTP-FLV by [mpegts.js](https://github.com/xqq/mpegts.js), by Chrome 105+ MSE, **NO WASM**. [v6.0.1](https://github.com/ossrs/srs/commit/7e02d972ea74faad9f4f96ae881d5ece0b89f33b)
* [ ] Play HEVC over HLS by [hls.js](https://github.com/video-dev/hls.js)
* [ ] Play HEVC over MPEG-DASH by [dash.js](https://github.com/Dash-Industry-Forum/dash.js)
* [x] Play HEVC over HTTP-TS by ffplay, by offical release. [v6.0.4](https://github.com/ossrs/srs/commit/70d5618979e5c8dc41b7cd87c78db7ca2b8a10e8)
* [x] PULL HEVC over RTMP by ffplay, with [patch](#ffmpeg-tools) for FFmpeg. [v6.0.2](https://github.com/ossrs/srs/commit/178e40a5fc3cf0856ace914ae61696a73007f5bf)
* [x] Play HEVC over HTTP-FLV by ffplay, with [patch](#ffmpeg-tools) for FFmpeg. [v6.0.2](https://github.com/ossrs/srs/commit/178e40a5fc3cf0856ace914ae61696a73007f5bf)
* [x] Play pure video(no audio) HEVC by ffplay.
* [x] Play HEVC over HLS by ffplay. [v6.0.11](https://github.com/ossrs/srs/commit/fff8d9863c3fba769b01782428257edf40f80a12)
* [x] Play HEVC over MPEG-DASH by ffplay. [v6.0.14](https://github.com/ossrs/srs/commit/edba2c25f13c0fa915bd8e8093a4005df6077858)
* [x] Play HEVC over SRT by ffplay. [v6.0.20](https://github.com/ossrs/srs/pull/3366)
* [x] Play HEVC over HTTP-TS by VLC, by official release. [v6.0.4](https://github.com/ossrs/srs/commit/70d5618979e5c8dc41b7cd87c78db7ca2b8a10e8)
* [x] Play HEVC over SRT by VLC, by official. [v6.0.20](https://github.com/ossrs/srs/pull/3366)
* [x] Play pure video(no audio) HEVC by VLC.
* [ ] Play HEVC over RTMP by VLC.
* [ ] Play HEVC over HTTP-FLV by VLC.
* [x] Play HEVC over HLS by VLC. [v6.0.11](https://github.com/ossrs/srs/commit/fff8d9863c3fba769b01782428257edf40f80a12)
* [x] Play HEVC over MPEG-DASH by VLC. [v6.0.14](https://github.com/ossrs/srs/commit/edba2c25f13c0fa915bd8e8093a4005df6077858)
* [x] DVR HEVC to MP4/FLV file. [v6.0.14](https://github.com/ossrs/srs/commit/edba2c25f13c0fa915bd8e8093a4005df6077858)
* [x] HTTP API contains HEVC metadata.
* [ ] HTTP Callback takes HEVC metadata.
* [ ] Prometheus Exporter supports HEVC metadata.
* [ ] Improve coverage for HEVC.
* [x] Add regression/blackbox tests for HEVC.
* [ ] Supports benchmark for HEVC by [srs-bench](https://github.com/ossrs/srs-bench).
* [x] Support patched FFmpeg for SRS dockers: [CentOS7](https://github.com/ossrs/dev-docker/commit/0691d016adfe521f77350728d15cead8086d527d), [Ubuntu20](https://github.com/ossrs/dev-docker/commit/0e36323d15544ffe2901d10cfd255d9ef08fb250) and [Encoder](https://github.com/ossrs/dev-docker/commit/782bb31039653f562e0765a0c057d9f9babd1d1f).
* [x] Update [WordPress plugin SrsPlayer](https://github.com/ossrs/WordPress-Plugin-SrsPlayer) for HEVC.
* [ ] Update [srs-cloud](https://github.com/ossrs/srs-cloud) for HEVC.
* [ ] Edge server supports publish HEVC stream to origin.
* [ ] Edge server supprots play HEVC stream from origin.
* [ ] [HEVC: Error empty SPS/PPS when coverting RTMP to HEVC.](https://github.com/ossrs/srs/issues/3407)
> Note: We're merging HEVC support to SRS 6.0, the original supports for HEVC is [srs-gb28181/feature/h265](https://github.com/ossrs/srs-gb28181/commits/feature/h265) by [runner365](https://github.com/runner365)
## FFmpeg Tools
The FFmpeg in `ossrs/srs:encoder` or `ossrs/srs:6` is built with libx265 and patched with HEVC over RTMP support. So you're able to directly use:
```bash
docker run --rm -it --net host ossrs/srs:encoder \
ffmpeg -re -i doc/source.flv -acodec copy -vcodec libx265 \
-f flv rtmp://localhost/live/livestream
```
If you want to build from code, please read the bellow instructions. Before build FFmpeg, we must build
[libx264](https://www.videolan.org/developers/x264.html):
```bash
git clone https://code.videolan.org/videolan/x264.git ~/git/x264
cd ~/git/x264
./configure --prefix=$(pwd)/build --disable-asm --disable-cli --disable-shared --enable-static
make -j10
make install
```
And then [libx265](https://www.videolan.org/developers/x265.html):
```bash
git clone https://bitbucket.org/multicoreware/x265_git.git ~/git/x265_git
cd ~/git/x265_git/build/linux
cmake -DCMAKE_INSTALL_PREFIX=$(pwd)/build -DENABLE_SHARED=OFF ../../source
make -j10
make install
```
Keep in mind that FFmpeg 6.0 does not support HEVC over RTMP until the following commit
[637c761b](https://github.com/FFmpeg/FFmpeg/commit/637c761be1bf9c3e1f0f347c5c3a390d7c32b282):
```
commit 637c761be1bf9c3e1f0f347c5c3a390d7c32b282
Author: Steven Liu <liuqi05@kuaishou.com>
Date: Mon Aug 28 09:59:24 2023 +0800
avformat/rtmpproto: support enhanced rtmp
add option named rtmp_enhanced_codec,
it would support hvc1,av01,vp09 now,
the fourcc is using Array of strings.
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
```
So, if you are using FFmpeg 6, you can build FFmpeg without any patch, directly by the following commands:
```bash
git clone -b master https://github.com/FFmpeg/FFmpeg.git ~/git/FFmpeg
cd ~/git/FFmpeg
env PKG_CONFIG_PATH=~/git/x264/build/lib/pkgconfig:~/git/x265_git/build/linux/build/lib/pkgconfig \
./configure \
--prefix=$(pwd)/build \
--enable-gpl --enable-nonfree --enable-pthreads --extra-libs=-lpthread \
--disable-asm --disable-x86asm --disable-inline-asm \
--enable-decoder=aac --enable-decoder=aac_fixed --enable-decoder=aac_latm --enable-encoder=aac \
--enable-libx264 --enable-libx265 \
--pkg-config-flags='--static'
make -j10
```
Push HEVC over RTMP to SRS:
```bash
./ffmpeg -stream_loop -1 -re -i ~/srs/doc/source.flv -acodec copy -vcodec libx265 \
-f flv rtmp://localhost/live/livestream
```
Play HEVC over RTMP by ffplay:
```bash
./ffplay rtmp://localhost/live/livestream
```
It works like magic!
If you want to use HEVC over RTMP in FFmpeg 4.1 or 5.1, please read the following instructions. Please clone FFmepg
and checkout to 5.1:
> Note: The [specfication](https://github.com/ksvc/FFmpeg/wiki) and [usage](https://github.com/ksvc/FFmpeg/wiki/hevcpush)
to support HEVC over RTMP or FLV. There is a [patch for FFmpeg 4.1/5.1/6.0](https://github.com/runner365/ffmpeg_rtmp_h265)
from [runner365](https://github.com/runner365) for FFmpeg to support HEVC over RTMP or FLV. There is also a
[patch](https://github.com/VCDP/CDN/blob/master/FFmpeg_patches/0001-Add-SVT-HEVC-FLV-support-on-FFmpeg.patch)
from Intel for this feature.
```bash
git clone -b n5.1.2 https://github.com/FFmpeg/FFmpeg.git ~/git/FFmpeg
```
Then, patch for [HEVC over RTMP/FLV](https://github.com/runner365/ffmpeg_rtmp_h265):
```bash
git clone -b 5.1 https://github.com/runner365/ffmpeg_rtmp_h265.git ~/git/ffmpeg_rtmp_h265
cp ~/git/ffmpeg_rtmp_h265/flv.h ~/git/FFmpeg/libavformat/
cp ~/git/ffmpeg_rtmp_h265/flv*.c ~/git/FFmpeg/libavformat/
```
Finally, follow the previous instructions to build FFmpeg.
## MSE for HEVC
[MSE](https://caniuse.com/?search=mse) is a base technology for [mpegts.js](https://github.com/xqq/mpegts.js), [hls.js](https://github.com/video-dev/hls.js/) and [dash.js](https://github.com/Dash-Industry-Forum/dash.js).
Now [Chrome 105+](https://caniuse.com/?search=HEVC) supports HEVC by default, see [this post](https://zhuanlan.zhihu.com/p/541082191), which means, MSE(Chrome 105+) is available for HEVC.
You can verify this feature, by generating a HEVC mp4 file:
```bash
ffmpeg -i ~/git/srs/trunk/doc/source.flv -acodec copy \
-vcodec libx265 -y source.hevc.mp4
```
> Note: Please make sure your FFmpeg is 5.0 and libx265 is enabled.
Open `source.hevc.mp4` in Chrome 105+ directly, it should works.
You can also move the file to SRS webserver:
```bash
mkdir -p ~/git/srs/trunk/objs/nginx/html/vod/
mv source.hevc.mp4 ~/git/srs/trunk/objs/nginx/html/vod
```
Then open by [srs-player](http://localhost:8080/players/srs_player.html?app=vod&stream=source.hevc.mp4&autostart=true)
## Safari WebRTC
Safari supports WebRTC, if you enable it by:
* English version: `Develop > Experimental Features > WebRTC H265 codec`
* Chinese version: `Development > Experimental Features > WebRTC H265 codec`
Then open the url in safari, to publish or play WebRTC stream:
* Play [http://localhost:1985/rtc/v1/whep/?app=live&stream=livestream&codec=hevc](http://localhost:8080/players/whep.html?autostart=true&codec=hevc)
* Publish [http://localhost:1985/rtc/v1/whip/?app=live&stream=livestream&codec=hevc](http://localhost:8080/players/whip.html?autostart=true&codec=hevc)
Please follow other section to publish HEVC stream.
## Thanks for Contributors
There is a list of commits and contributors about HEVC in SRS:
* [H265: For #1747, Support HEVC/H.265 in SRT/RTMP/HLS.](https://github.com/ossrs/srs-gb28181/commit/3ca11071b45495e82d2d6958e5d0f7eab05e71e5)
* [H265: For #1747, Fix build fail bug for H.265](https://github.com/ossrs/srs-gb28181/commit/e355f3c37228f3602c88fed68e8fe5e6ba1153ea)
* [H265: For #1747, GB28181 support h.265 (#2037)](https://github.com/ossrs/srs-gb28181/commit/b846217bc7f94034b33bdf918dc3a49fb17947e0)
* [H265: fix some important bugs (#2156)](https://github.com/ossrs/srs-gb28181/commit/26218965dd083d13173af6eb31fcdf9868b753c6)
* [H265: Deliver the right hevc nalu and dump the wrong nalu. (#2447)](https://github.com/ossrs/srs-gb28181/commit/a13b9b54938a14796abb9011e7a8ee779439a452)
* [H265: Fix multi nal hevc frame demux fail. #2494](https://github.com/ossrs/srs-gb28181/commit/6c5e6090d7c82eb37530e109c230cabaedf948e1)
* [H265: Fix build error #2657 #2664](https://github.com/ossrs/srs-gb28181/commit/eac99e19fba6063279b9e47272523014f5e3334a)
* [H265: Update mpegts demux in srt. #2678](https://github.com/ossrs/srs-gb28181/commit/391c1426fc484c990e4324a4ae2f0de900074578)
* [H265: Fix the stat issue for h265. (#1949)](https://github.com/ossrs/srs-gb28181/commit/b4486e3b51281b4c227b2cc4f58d2b06db599ce0)
* [H265: Add h265 codec written support for MP4 format. (#2697)](https://github.com/ossrs/srs-gb28181/commit/3175d7e26730a04b27724e55dc95ef86c1f2886e)
* [H265: Add h265 for SRT.](https://github.com/runner365/srs/commit/0fa86e4f23847e8a46e3d0e91e0acd2c27047e11)
We will merge some of these commits to SRS 6.0, but not all commits.
* [PULL HEVC over WebRTC by Safari. v6.0.34](https://github.com/ossrs/srs/pull/3441)
* [GB: Support H.265 for GB28181. v6.0.25 (#3408)](https://github.com/ossrs/srs/pull/3408)
* [H265: Support HEVC over SRT. v6.0.20 (#465) (#3366)](https://github.com/ossrs/srs/pull/3366)
* [H265: Support DVR HEVC stream to MP4. v6.0.14](https://github.com/ossrs/srs/pull/3360)
* HLS: Support HEVC over HLS. v6.0.11
* [HEVC: The codec information is incorrect. v6.0.5](https://github.com/ossrs/srs/issues/3271)
* FFmpeg support libx265 and HEVC over RTMP/FLV: [CentOS7](https://github.com/ossrs/dev-docker/commit/0691d016adfe521f77350728d15cead8086d527d), [Ubuntu20](https://github.com/ossrs/dev-docker/commit/0e36323d15544ffe2901d10cfd255d9ef08fb250) and [Encoder](https://github.com/ossrs/dev-docker/commit/782bb31039653f562e0765a0c057d9f9babd1d1f).
* [H265: Support HEVC over HTTP-TS. v6.0.4](https://github.com/ossrs/srs/commit/70d5618979e5c8dc41b7cd87c78db7ca2b8a10e8)
* [H265: Support parse multiple NALUs in a frame. v6.0.3](https://github.com/ossrs/srs/commit/f316e9a0de3a892d25f2d8e7efd28ee9334f5bd6)
* [H265: Support HEVC over RTMP or HTTP-FLV. v6.0.2](https://github.com/ossrs/srs/commit/178e40a5fc3cf0856ace914ae61696a73007f5bf)
* [H265: Update mpegts.js to play HEVC over HTTP-TS/FLV. v6.0.1](https://github.com/ossrs/srs/commit/7e02d972ea74faad9f4f96ae881d5ece0b89f33b)
## Known Issues
1. HEVC over Safari WebRTC, only support WebRTC to WebRTC, doesn't support converting to RTMP.
2. Chrome/Firefox does not support HEVC, no any plan as I know.
3. Almost all browsers supports MSE, except iOS. HEVC over MSE requires hardware decoder.
4. Apart from mpegts.js, other H5 players such as hls.js/dash.js doesn't support HEVC.
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/hevc)

499
trunk/3rdparty/srs-docs/doc/hls.md vendored Normal file
View File

@ -0,0 +1,499 @@
---
title: HLS
sidebar_label: HLS
hide_title: false
hide_table_of_contents: false
---
# HLS
HLS is the best streaming protocol for adaptability and compatibility. Almost all devices in the world support HLS,
including PCs, Android, iOS, OTT, SmartTV, and more. Various browsers also support HLS well, including Chrome, Safari,
Firefox, Edge, and mobile browsers.
If your users are diverse, especially if their devices have lower performance, HLS is the best choice. If you want
to be compatible with more devices, HLS is the best choice. If you want to distribute your live stream on any CDN
and globally, HLS is the best choice.
Of course, HLS is not perfect; its main issue is high latency, usually around 30 seconds. Although it can be optimized
to about 8 seconds, different players' behavior may vary. Compared to other streaming protocols, the optimized latency
is still high. So if you care about live streaming latency, please use RTMP or HTTP-FLV protocols.
The main application scenarios of HLS include:
* Cross-platform: The main live streaming solution for PCs is HLS, which can be played using the hls.js library. So if you choose one protocol for PC/Android/iOS, it's HLS.
* Strict stability requirements on iOS: HLS is the most stable on iOS, with stability comparable to RTMP and HTTP-FLV.
* Friendly CDN distribution: HLS is based on HTTP, so CDN integration and distribution are more complete than RTMP. HLS can switch between various CDNs.
* Fewer simple issues: HLS is a very simple streaming protocol, well supported by Apple. Android's support for HLS will also improve.
HLS is the core protocol of SRS and will be continuously maintained and updated, constantly improving support for HLS.
SRS converts RTMP, SRT, or WebRTC streams into HLS streams, especially WebRTC, where SRS implements audio transcoding
capabilities.
## Usage
SRS has built-in HLS support, which you can use with [docker](./getting-started.md) or [compile from source](./getting-started-build.md):
```bash
docker run --rm -it -p 1935:1935 -p 8080:8080 ossrs/srs:5 \
./objs/srs -c conf/hls.conf
```
Use [FFmpeg(click to download)](https://ffmpeg.org/download.html) or [OBS(click to download)](https://obsproject.com/download) to stream:
```bash
ffmpeg -re -i ./doc/source.flv -c copy -f flv rtmp://localhost/live/livestream
```
Open the following page to play the stream (if SRS is not on your local machine, replace localhost with the server IP):
* HLS by SRS player: [http://localhost:8080/live/livestream.m3u8](http://localhost:8080/players/srs_player.html?stream=livestream.m3u8)
> Note: Please wait about 10 seconds before playing the stream, otherwise it will fail, as it takes some time to generate the first segment.
## Config
The config for HLS:
```bash
vhost __defaultVhost__ {
hls {
# whether the hls is enabled.
# if off, do not write hls(ts and m3u8) when publish.
# Overwrite by env SRS_VHOST_HLS_ENABLED for all vhosts.
# default: off
enabled on;
# the hls fragment in seconds, the duration of a piece of ts.
# Overwrite by env SRS_VHOST_HLS_HLS_FRAGMENT for all vhosts.
# default: 10
hls_fragment 10;
# the hls m3u8 target duration ratio,
# EXT-X-TARGETDURATION = hls_td_ratio * hls_fragment // init
# EXT-X-TARGETDURATION = max(ts_duration, EXT-X-TARGETDURATION) // for each ts
# Overwrite by env SRS_VHOST_HLS_HLS_TD_RATIO for all vhosts.
# default: 1.0
hls_td_ratio 1.0;
# the audio overflow ratio.
# for pure audio, the duration to reap the segment.
# for example, the hls_fragment is 10s, hls_aof_ratio is 1.2,
# the segment will reap to 12s for pure audio.
# Overwrite by env SRS_VHOST_HLS_HLS_AOF_RATIO for all vhosts.
# default: 1.2
hls_aof_ratio 1.2;
# the hls window in seconds, the number of ts in m3u8.
# Overwrite by env SRS_VHOST_HLS_HLS_WINDOW for all vhosts.
# default: 60
hls_window 60;
# the error strategy. can be:
# ignore, disable the hls.
# disconnect, require encoder republish.
# continue, ignore failed try to continue output hls.
# Overwrite by env SRS_VHOST_HLS_HLS_ON_ERROR for all vhosts.
# default: continue
hls_on_error continue;
# the hls output path.
# the m3u8 file is configured by hls_path/hls_m3u8_file, the default is:
# ./objs/nginx/html/[app]/[stream].m3u8
# the ts file is configured by hls_path/hls_ts_file, the default is:
# ./objs/nginx/html/[app]/[stream]-[seq].ts
# @remark the hls_path is compatible with srs v1 config.
# Overwrite by env SRS_VHOST_HLS_HLS_PATH for all vhosts.
# default: ./objs/nginx/html
hls_path ./objs/nginx/html;
# the hls m3u8 file name.
# we supports some variables to generate the filename.
# [vhost], the vhost of stream.
# [app], the app of stream.
# [stream], the stream name of stream.
# Overwrite by env SRS_VHOST_HLS_HLS_M3U8_FILE for all vhosts.
# default: [app]/[stream].m3u8
hls_m3u8_file [app]/[stream].m3u8;
# the hls ts file name.
# we supports some variables to generate the filename.
# [vhost], the vhost of stream.
# [app], the app of stream.
# [stream], the stream name of stream.
# [2006], replace this const to current year.
# [01], replace this const to current month.
# [02], replace this const to current date.
# [15], replace this const to current hour.
# [04], replace this const to current minute.
# [05], replace this const to current second.
# [999], replace this const to current millisecond.
# [timestamp],replace this const to current UNIX timestamp in ms.
# [seq], the sequence number of ts.
# [duration], replace this const to current ts duration.
# @see https://ossrs.net/lts/zh-cn/docs/v4/doc/dvr#custom-path
# @see https://ossrs.net/lts/zh-cn/docs/v4/doc/delivery-hls#hls-config
# Overwrite by env SRS_VHOST_HLS_HLS_TS_FILE for all vhosts.
# default: [app]/[stream]-[seq].ts
hls_ts_file [app]/[stream]-[seq].ts;
# the hls entry prefix, which is base url of ts url.
# for example, the prefix is:
# http://your-server/
# then, the ts path in m3u8 will be like:
# http://your-server/live/livestream-0.ts
# http://your-server/live/livestream-1.ts
# ...
# Overwrite by env SRS_VHOST_HLS_HLS_ENTRY_PREFIX for all vhosts.
# optional, default to empty string.
hls_entry_prefix http://your-server;
# the default audio codec of hls.
# when codec changed, write the PAT/PMT table, but maybe ok util next ts.
# so user can set the default codec for mp3.
# the available audio codec:
# aac, mp3, an
# Overwrite by env SRS_VHOST_HLS_HLS_ACODEC for all vhosts.
# default: aac
hls_acodec aac;
# the default video codec of hls.
# when codec changed, write the PAT/PMT table, but maybe ok util next ts.
# so user can set the default codec for pure audio(without video) to vn.
# the available video codec:
# h264, vn
# Overwrite by env SRS_VHOST_HLS_HLS_VCODEC for all vhosts.
# default: h264
hls_vcodec h264;
# whether cleanup the old expired ts files.
# Overwrite by env SRS_VHOST_HLS_HLS_CLEANUP for all vhosts.
# default: on
hls_cleanup on;
# If there is no incoming packets, dispose HLS in this timeout in seconds,
# which removes all HLS files including m3u8 and ts files.
# @remark 0 to disable dispose for publisher.
# @remark apply for publisher timeout only, while "etc/init.d/srs stop" always dispose hls.
# Overwrite by env SRS_VHOST_HLS_HLS_DISPOSE for all vhosts.
# default: 120
hls_dispose 120;
# whether wait keyframe to reap segment,
# if off, reap segment when duration exceed the fragment,
# if on, reap segment when duration exceed and got keyframe.
# Overwrite by env SRS_VHOST_HLS_HLS_WAIT_KEYFRAME for all vhosts.
# default: on
hls_wait_keyframe on;
# whether use floor for the hls_ts_file path generation.
# if on, use floor(timestamp/hls_fragment) as the variable [timestamp],
# and use enhanced algorithm to calc deviation for segment.
# @remark when floor on, recommend the hls_segment>=2*gop.
# Overwrite by env SRS_VHOST_HLS_HLS_TS_FLOOR for all vhosts.
# default: off
hls_ts_floor off;
# the max size to notify hls,
# to read max bytes from ts of specified cdn network,
# @remark only used when on_hls_notify is config.
# Overwrite by env SRS_VHOST_HLS_HLS_NB_NOTIFY for all vhosts.
# default: 64
hls_nb_notify 64;
# Whether enable hls_ctx for HLS streaming, for which we create a "fake" connection for HTTP API and callback.
# For each HLS streaming session, we use a child m3u8 with a session identified by query "hls_ctx", it simply
# work as the session id.
# Once the HLS streaming session is created, we will cleanup it when timeout in 2*hls_window seconds. So it
# takes a long time period to identify the timeout.
# Now we got a HLS stremaing session, just like RTMP/WebRTC/HTTP-FLV streaming, we're able to stat the session
# as a "fake" connection, do HTTP callback when start playing the HLS streaming. You're able to do querying and
# authentication.
# Note that it will make NGINX edge cache always missed, so never enable HLS streaming if use NGINX edges.
# Overwrite by env SRS_VHOST_HLS_HLS_CTX for all vhosts.
# Default: on
hls_ctx on;
# For HLS pseudo streaming, whether enable the session for each TS segment.
# If enabled, SRS HTTP API will show the statistics about HLS streaming bandwidth, both m3u8 and ts file. Please
# note that it also consumes resource, because each ts file should be served by SRS, all NGINX cache will be
# missed because we add session id to each ts file.
# Note that it will make NGINX edge cache always missed, so never enable HLS streaming if use NGINX edges.
# Overwrite by env SRS_VHOST_HLS_HLS_TS_CTX for all vhosts.
# Default: on
hls_ts_ctx on;
# whether using AES encryption.
# Overwrite by env SRS_VHOST_HLS_HLS_KEYS for all vhosts.
# default: off
hls_keys on;
# the number of clear ts which one key can encrypt.
# Overwrite by env SRS_VHOST_HLS_HLS_FRAGMENTS_PER_KEY for all vhosts.
# default: 5
hls_fragments_per_key 5;
# the hls key file name.
# we supports some variables to generate the filename.
# [vhost], the vhost of stream.
# [app], the app of stream.
# [stream], the stream name of stream.
# [seq], the sequence number of key corresponding to the ts.
# Overwrite by env SRS_VHOST_HLS_HLS_KEY_FILE for all vhosts.
hls_key_file [app]/[stream]-[seq].key;
# the key output path.
# the key file is configed by hls_path/hls_key_file, the default is:
# ./objs/nginx/html/[app]/[stream]-[seq].key
# Overwrite by env SRS_VHOST_HLS_HLS_KEY_FILE_PATH for all vhosts.
hls_key_file_path ./objs/nginx/html;
# the key root URL, use this can support https.
# @remark It's optional.
# Overwrite by env SRS_VHOST_HLS_HLS_KEY_URL for all vhosts.
hls_key_url https://localhost:8080;
# Special control controls.
###########################################
# Whether calculate the DTS of audio frame directly.
# If on, guess the specific DTS by AAC samples, please read https://github.com/ossrs/srs/issues/547#issuecomment-294350544
# If off, directly turn the FLV timestamp to DTS, which might cause corrupt audio stream.
# @remark Recommend to set to off, unless your audio stream sample-rate and timestamp is not correct.
# Overwrite by env SRS_VHOST_HLS_HLS_DTS_DIRECTLY for all vhosts.
# Default: on
hls_dts_directly on;
# on_hls, never config in here, should config in http_hooks.
# for the hls http callback, @see http_hooks.on_hls of vhost hooks.callback.srs.com
# @see https://ossrs.net/lts/zh-cn/docs/v4/doc/delivery-hls#http-callback
# @see https://ossrs.io/lts/en-us/docs/v4/doc/delivery-hls#http-callback
# on_hls_notify, never config in here, should config in http_hooks.
# we support the variables to generate the notify url:
# [app], replace with the app.
# [stream], replace with the stream.
# [param], replace with the param.
# [ts_url], replace with the ts url.
# for the hls http callback, @see http_hooks.on_hls_notify of vhost hooks.callback.srs.com
# @see https://ossrs.net/lts/zh-cn/docs/v4/doc/delivery-hls#on-hls-notify
# @see https://ossrs.io/lts/en-us/docs/v4/doc/delivery-hls#on-hls-notify
}
}
```
> Note: These settings are only for playing HLS. For streaming settings, please follow your protocol, like referring to [RTMP](./rtmp.md#config), [SRT](./srt.md#config), or [WebRTC](./webrtc.md#config) streaming configurations.
Here are the main settings:
* enabled: Turn HLS on/off, default is off.
* hls_fragment: Seconds, specify the minimum length of ts slices. For the actual length of ts files, please refer to the detailed description of [HLS TS Duration](#hls-ts-duration).
* hls_td_ratio: Normal slice duration multiple. For the actual length of ts files, please refer to the detailed description of [HLS TS Duration](#hls-ts-duration).
* hls_wait_keyframe: Whether to slice by top, i.e., wait for the keyframe before slicing. For the actual length of ts files, please refer to the detailed description of [HLS TS Duration](#hls-ts-duration).
* hls_aof_ratio: Pure audio slice duration multiple. For pure audio, when the ts duration exceeds the configured ls_fragment multiplied by this factor, the file is cut. For the actual length of ts files, please refer to the detailed description of [HLS TS Duration](#hls-ts-duration).
* hls_window: Seconds, specify the HLS window size, i.e., the sum of ts file durations in the m3u8, which determines the number of ts files in the m3u8. For more details, refer to [HLS TS Files](#hls-ts-files).
* hls_path: The path where the HLS m3u8 and ts files are saved. Both m3u8 and ts files are saved in this directory.
* hls_m3u8_file: The file name of the HLS m3u8, including replaceable `[vhost]`, `[app]`, and `[stream]` variables.
* hls_ts_file: The file name of the HLS ts, including a series of replaceable variables. Refer to [dvr variables](./dvr.md#custom-path). Also, `[seq]` is the ts sequence number.
* hls_entry_prefix: The base url of TS. Optional, default is an empty string; when not empty, it is added in front of ts as the base url.
* hls_acodec: Default audio codec. When the stream codec changes, the PMT/PAT information will be updated; the default is aac, so the default PMT/PAT information is aac; if the stream is mp3, this parameter can be set to mp3 to avoid PMT/PAT changes.
* hls_vcodec: Default video codec. When the stream codec changes, the PMT/PAT information will be updated; the default is h264. If it is a pure audio HLS, it can be set to vn, which can reduce the time for SRS to detect pure audio and directly enter pure audio mode.
* hls_cleanup: Whether to delete expired ts slices that are not in the hls_window. You can turn off ts slice cleanup to implement time-shifting and storage, using your own slice management system.
* hls_dispose: When there is no stream, the HLS cleanup expiration time (seconds). When the system restarts or exceeds this time, all HLS files, including m3u8 and ts, will be cleaned up. If set to 0, no cleanup will be done.
* hls_nb_notify: The length of data read from the notify server.
* on_hls: When a slice is generated, callback this url using POST. Used to integrate with your own system, such as implementing slice movement.
* on_hls_notify: When a slice is generated, callback this url using GET. Used to integrate with the system, you can use the `[ts_url]` variable to implement pre-distribution (i.e., download a ts slice once).
## HLS TS Duration
How is the duration of HLS TS segments determined? It depends on the configuration and the characteristics of the stream.
If there is video, the segment duration is `max(hls_fragment*hls_td_ratio, gop_size*N)`, which is the maximum value of `hls_fragment` and `gop_size`. The `gop_size` is determined by the encoder, for example, OBS can set the GOP size in seconds, while FFmpeg uses the number of frames combined with the frame rate to calculate seconds.
For example, if the stream's frame rate is 25 and the GOP is 50 frames, then the `gop_size` is 2 seconds:
* If `hls_fragment` is 10 seconds, the final TS segment duration is 10 seconds.
* If `hls_fragment` is 5 seconds, the final TS segment duration is 6 seconds, with 3 GOPs.
* If `hls_fragment` is 5 seconds and `hls_td_ratio` is 2, the final TS segment duration is 10 seconds.
If `hls_wait_keyframe off` is configured, the GOP size is no longer considered, and the TS segment duration is determined by `hls_fragment` regardless of the GOP size. For example, if the GOP is 10 seconds:
* If `hls_fragment` is 10 seconds, the final TS segment duration is 10 seconds.
* If `hls_fragment` is 5 seconds, the final TS segment duration is 5 seconds.
* If `hls_fragment` is 3 seconds and `hls_td_ratio` is 2, the final TS segment duration is 6 seconds.
> Note: Turning off `hls_wait_keyframe` can reduce segment size and latency, but some players may experience screen artifacts when starting playback with a non-keyframe.
For audio-only HLS, the segment duration is determined by `hls_fragment*hls_aof_ratio`:
* If `hls_fragment` is 10 seconds and `hls_aof_ratio` is 1.2, the final TS segment duration is 12 seconds.
* If `hls_fragment` is 5 seconds and `hls_aof_ratio` is 1, the final TS segment duration is 5 seconds.
Note that if the segment duration is unusually long, exceeding a certain size (usually 3 times the maximum segment length), it will be discarded.
## HLS TS Files
The number of TS files in the m3u8 is determined by the TS duration and `hls_window`. When the total duration of TS files exceeds `hls_window`, the first segment in the m3u8 is discarded until the total TS duration is within the configured range.
SRS ensures the following formula:
```bash
hls_window >= sum(duration of each ts in m3u8)
```
For example, if `hls_window` is 60 seconds and `hls_fragment` is 10 seconds, and the actual TS segment duration is 10 seconds, there will be 6 TS files in the m3u8. The actual TS segment duration may be larger than `hls_fragment`, see [HLS TS Duration](#hls-ts-duration) for details.
## HTTP Callback
You can set up an `on_hls` callback in the `http_hooks` section, not in the HLS section.
Note: HLS hot backup can be implemented based on this callback, see [#351](https://github.com/ossrs/srs/issues/351).
Note: HLS hot backup must ensure that the slices on both servers are exactly the same, because the load balancer or edge may fetch slices from both servers. Ensuring that the slices on both servers are exactly the same is a very complex streaming media issue. However, through the callback and business system, you can achieve a simple and reliable HLS hot backup system by choosing slices from both servers.
## HLS Authentication
SRS supports HLS client playback and online user statistics. By default, it will enable `hls_ctx` and `hls_ts_ctx`. This way, HLS and other protocols can implement authentication playback and data statistics through callbacks. For example, when playing HLS, you can use the `on_play` callback to return an error and reject client playback.
```bash
vhost __defaultVhost__ {
hls {
enabled on;
hls_ctx on;
hls_ts_ctx on;
}
}
```
However, this feature will cause HLS cache to fail on CDN because each playback will have a different ctx_id, similar to a session ID function. Therefore, in [HLS Cluster](./nginx-for-hls.md), you must disable these two options.
## HLS Dispose
If the stream is stopped, the HLS client can still play the previous content because the slice files still exist.
Sometimes during a live broadcast, you may need to temporarily stop the stream, change encoding parameters or streaming devices, and then restart the stream. Therefore, SRS should not delete HLS files when stopping the stream.
By default, SRS will clean up the HLS slice files after the `hls_dispose` configured time. This time is set to 120 seconds (2 minutes) by default.
```bash
vhost __defaultVhost__ {
hls {
enabled on;
hls_dispose 120;
}
}
```
If you need to clean up faster, you can shorten this cleanup time. However, this configuration should not be too short. It is recommended not to be less than `hls_window`, otherwise, it may cause early cleanup when restarting the stream, making the HLS stream inaccessible to the player.
## HLS in RAM
If you need to increase the number of concurrent HLS streams, you can try distributing HLS directly from memory without writing to disk.
You can mount memory as a disk directory and then write HLS slices to the memory disk:
```bash
mkdir -p /ramdisk &&
mount -o size=7G -t tmpfs none /ramdisk
```
> Note: To unmount the memory disk, use the command `unmount /randisk`.
> Note: If you don't have many streams and don't need much disk space, you can write HLS slices to the `/tmp` directory, which is a memory disk by default.
Then configure `hls_path` or create a soft link to the directory.
## HLS Delivery Cluster
To deploy an HLS distribution cluster and edge distribution cluster for your own CDN to handle a large number of viewers, please refer to [Nginx for HLS](./nginx-for-hls.md).
## HLS Low Latency
How to reduce HLS latency? The key is to reduce the number of slices and the number of TS files in the m3u8. SRS's default configuration is 10 seconds per slice and 60 seconds per m3u8, resulting in a latency of about 30 seconds. Some players start requesting slices from the middle position, so there will be a delay of 3 slices.
You can adjust the following three settings to reduce latency to about 6-8 seconds:
* Reduce the GOP size, e.g., set OBS's GOP to 1 second or FFmpeg's GOP to the number of FPS frames.
* Reduce the encoder's delay, for example, set OBS to `Profile` as `baseline` and choose `Tune` as `zerolatency`.
* Reduce `hls_fragment`, e.g., set it to 2 seconds or 1 second.
* Reduce `hls_window`, e.g., set it to 10 seconds or 5 seconds.
* Use low-latency players like hls.js, ijkplayer, or ffplay, and avoid high-latency players like VLC.
Refer to the configuration file `conf/hls.realtime.conf`:
```bash
vhost __defaultVhost__ {
hls {
enabled on;
hls_fragment 2;
hls_window 10;
}
}
```
> Note: If you can't adjust the encoder's OGP size, consider setting `hls_wait_keyframe off` to ignore GOP, but this may cause screen artifacts. Test your device's compatibility.
Of course, you can't reduce it too much, as it may cause insufficient buffering for the player or skipping when the player's network is poor, possibly resulting in playback failure. The lower the latency, the higher the chance of buffering. HLS latency cannot be less than 5 seconds, especially considering CDN and player compatibility.
Even after adjusting, the HLS delay won't be less than 5 seconds, and the LLHLS protocol can't reduce it further. This is because LLHLS only tries to solve the impact of the initial GOP during playback. In the above settings, we also reduced the GOP's impact through the encoder's configuration. However, network jitter and player strategy are reasons for the higher HLS delay, and they can't be solved.
If you need latency within 5 seconds, consider using protocols like [HTTP-FLV](./flv.md), [SRT](./srt.md), or [WebRTC](./webrtc.md).
## ON HLS Notify
You can configure `on_hls_notify` for CDN pre-distribution. This should be set in `http_hooks` rather than in the HLS configuration.
## HLS Audio Corrupt
HLS might have loud noise issues, which is caused by the sampling rate of AAC causing a small error when switching between FLV (tbn=1000) and TS (tbn=90000). SRS3 uses the number of samples to calculate the exact timestamp, for more details, refer to [HLS Loud Noise](https://github.com/ossrs/srs/issues/547#issuecomment-294350544).
> Note: To solve the HLS loud noise problem, you need to manually disable `hls_dts_directly` (set to off).
After SRS3 is corrected, it is found that some audio streams have problems with their timestamps, causing the timestamps calculated from the AAC sample count to be incorrect. Therefore, the configuration item `hls_dts_directly` is provided to force the use of the original timestamp, refer to [HLS Force Original Timestamp](https://github.com/ossrs/srs/issues/547#issuecomment-563942711).
## HLS Audio Only
SRS supports distributing HLS pure audio streams. When the RTMP stream has no video and the audio is AAC (you can use transcoding to convert to AAC, refer to [Usage: Transcode2HLS](./sample-transcode-to-hls.md)), SRS only slices the audio.
If the RTMP stream already has video and audio, and you need to support pure audio HLS streams, you can use transcoding to remove the video, refer to: [Transcoding: Disable Stream](./ffmpeg.md#%E7%A6%81%E7%94%A8). Then distribute the audio stream.
Distributing pure audio streams does not require special configuration, just like HLS distribution.
## HLS and Forward
Forward streams are not distinguished from ordinary streams. If the forward stream's VHOST is configured with HLS, the HLS configuration will be applied for slicing.
Therefore, you can transcode the original stream to ensure that the stream meets the h.264/aac standard, and then forward it to multiple VHOSTs configured with HLS for slicing. This supports hot backup for multiple source stations.
## HLS and Transcode
HLS requires the RTMP stream encoding to be h.264+aac/mp3, otherwise, HLS will be automatically disabled, and you may see RTMP streams but not HLS streams (or the HLS streams you see are from previous streams).
Transcoding the RTMP stream allows SRS to access any encoded RTMP stream and then convert it to the h.264/aac/mp3 encoding required by HLS.
When configuring Transcode, if you need to control the ts length, you need to [configure the ffmpeg encoding gop](http://ffmpeg.org/ffmpeg-codecs.html#Options-7), for example:
```bash
vhost hls.transcode.vhost.com {
transcode {
enabled on;
ffmpeg ./objs/ffmpeg/bin/ffmpeg;
engine hls {
enabled on;
vfilter {
}
vcodec libx264;
vbitrate 500;
vfps 20;
vwidth 768;
vheight 320;
vthreads 2;
vprofile baseline;
vpreset superfast;
vparams {
g 100;
}
acodec libaacplus;
abitrate 45;
asample_rate 44100;
achannels 2;
aparams {
}
output rtmp://127.0.0.1:[port]/[app]?vhost=[vhost]/[stream]_[engine];
}
}
}
```
This FFMPEG transcoding parameter specifies the gop duration as 100/20=5 seconds, fps frame rate (vfps=20), and gop frame count (g=100).
## HLS Multiple Bitrate
SRS currently does not support HLS adaptive bitrate, as it generally requires transcoding a single stream into multiple streams and requires GOP alignment. You can use FFmpeg to achieve this, refer to [How to generate multiple resolutions HLS using FFmpeg for live streaming](https://stackoverflow.com/a/71985380/17679565).
## Apple Examples
Apple's HLS example files:
https://developer.apple.com/library/ios/technotes/tn2288/_index.html
## HLS Encryption
SRS3 supports slice encryption, for specific usage, refer to [#1093](https://github.com/ossrs/srs/issues/1093#issuecomment-415971022).
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/hls)

533
trunk/3rdparty/srs-docs/doc/http-api.md vendored Normal file
View File

@ -0,0 +1,533 @@
---
title: HTTP API
sidebar_label: HTTP API
hide_title: false
hide_table_of_contents: false
---
# HTTP API
SRS provides HTTP api, to external application to manage SRS, and support crossdomain for js.
Once HTTP API enabled, you can use [srs-console](http://ossrs.net/console/) to connect to your SRS server.
The workflow is:
```text
+-------------------------+ +-------+
+ Chrome/Your Application +--HTTP-API-->--+ SRS +
+-------------------------+ +-------+
```
You can use Chrome or your application, to request the HTTP API of SRS to get the state of SRS.
## Goals
The HTTP API of SRS follows the simple priciple:
* Only provides API in json format, both request and response are json.
* Please use [srs-console](https://github.com/ossrs/srs-console) to access API.
* When error, response in HTTP status or code in json.
## Build
SRS always enable the http api, read [configure](./install.md)
```bash
./configure && make
```
## Config
The config also need to enable it:
```bash
listen 1935;
# system statistics section.
# the main cycle will retrieve the system stat,
# for example, the cpu/mem/network/disk-io data,
# the http api, for instance, /api/v1/summaries will show these data.
# @remark the heartbeat depends on the network,
# for example, the eth0 maybe the device which index is 0.
stats {
# the index of device ip.
# we may retrieve more than one network device.
# default: 0
network 0;
# the device name to stat the disk iops.
# ignore the device of /proc/diskstats if not configed.
disk sda sdb xvda xvdb;
}
# api of srs.
# the http api config, export for external program to manage srs.
# user can access http api of srs in browser directly, for instance, to access by:
# curl http://192.168.1.170:1985/api/v1/reload
# which will reload srs, like cmd killall -1 srs, but the js can also invoke the http api,
# where the cli can only be used in shell/terminate.
http_api {
# whether http api is enabled.
# default: off
enabled on;
# the http api listen entry is <[ip:]port>
# for example, 192.168.1.100:1985
# where the ip is optional, default to 0.0.0.0, that is 1985 equals to 0.0.0.0:1985
# default: 1985
listen 1985;
# whether enable crossdomain request.
# default: on
crossdomain on;
# the HTTP RAW API is more powerful api to change srs state and reload.
raw_api {
# whether enable the HTTP RAW API.
# Overwrite by env SRS_HTTP_API_RAW_API_ENABLED
# default: off
enabled off;
# whether enable rpc reload.
# Overwrite by env SRS_HTTP_API_RAW_API_ALLOW_RELOAD
# default: off
allow_reload off;
# whether enable rpc query.
# Always off by https://github.com/ossrs/srs/issues/2653
#allow_query off;
# whether enable rpc update.
# Always off by https://github.com/ossrs/srs/issues/2653
#allow_update off;
}
# the auth is authentication for http api
auth {
# whether enable the HTTP AUTH.
# Overwrite by env SRS_HTTP_API_AUTH_ENABLED
# default: off
enabled on;
# The username of Basic authentication:
# Overwrite by env SRS_HTTP_API_AUTH_USERNAME
username admin;
# The password of Basic authentication:
# Overwrite by env SRS_HTTP_API_AUTH_PASSWORD
password admin;
}
# For https_api or HTTPS API.
https {
# Whether enable HTTPS API.
# default: off
enabled on;
# The listen endpoint for HTTPS API.
# default: 1986
listen 1986;
# The SSL private key file, generated by:
# openssl genrsa -out server.key 2048
# 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"
# default: ./conf/server.crt
cert ./conf/server.crt;
}
}
vhost __defaultVhost__ {
}
```
The `http_api` enable the HTTP API, and `stats` used for SRS to stat the system info, including:
* network: Used for heartbeat to report the network info, where heartbeat used to report system info.
* disk: Used to stat the specified disk iops. You can use command `cat /proc/diskstats` to get the right disk names, for instance, xvda.
## Start
Start SRS: `./objs/srs -c http-api.conf`
Access api, open the url in web browser:
* [http://127.0.0.1:1985/api/v1](http://127.0.0.1:1985/api/v1)
* [https://127.0.0.1:1986/api/v1](https://127.0.0.1:1986/api/v1)
> Remark: Please use your server ip instead.
## Performance
The HTTP api supports 370 request per seconds, please test by AB(Apache Benchmark).
## Access Api
Use web brower, or curl, or other http library.
SRS provides api urls list, no need to remember:
* code, an int error code. 0 is success.
* urls, the url lists, can be access.
* data, the last level api serve data.
Root directory:
```bash
# curl http://192.168.1.102:1985/
"urls": {
"api": "the api root"
}
```
Go on:
```bash
# curl http://192.168.1.102:1985/api/v1/versions
"major": 0,
"minor": 9,
"revision": 43,
"version": "0.9.43"
```
Or:
```bash
# curl http://192.168.1.102:1985/api/v1/authors
"primary_authors": "xxx",
"contributors_link": "https://github.com/ossrs/srs/blob/master/AUTHORS.txt",
"contributors": "xxx"
```
The Api of SRS is self-describes api.
## Error Code
SRS response error in both HTTP status or HTTP body.
For example, SRS response HTTP error, where HTTP status not 200:
```
winlin:~ winlin$ curl -v http://127.0.0.1:1985 && echo ""
< HTTP/1.1 404 Not Found
< Connection: Keep-Alive
< Content-Length: 9
< Content-Type: text/plain; charset=utf-8
< Server: SRS/2.0.184
<
Not Found
```
For example, SRS response code not 0 when HTTTP Status 200:
```
winlin:~ winlin$ curl -v http://127.0.0.1:1985/api/v1/tests/errors && echo ""
< HTTP/1.1 200 OK
< Connection: Keep-Alive
< Content-Length: 12
< Content-Type: application/json
< Server: SRS/2.0.184
<
{"code":100}
```
User should handle these two error style.
## Crossdomain
SRS HTTP API supports js crossdomain, so the html/js can invoke http api of srs。
SRS support two main CROS styles:
* OPTIONS: JQuery can directly access the CROS, where the brower will send an OPTIONS first, then the API request.
* JSONP: JQuery/Angularjs can send JSONP CROS request to SRS API, where specifes the function name by QueryString `callback`.
* JSONP-DELETE: JSONP only support GET, so we use the `method` in QueryString to override the HTTP method for JSONP.
For example, the JSONP crossdomain request:
```
GET http://localhost:1985/api/v1/vhosts/?callback=JSON_CALLBACK
JSON_CALLBACK({"code":0,"server":13449})
GET http://localhost:1985/api/v1/vhosts/100?callback=JSON_CALLBACK&method=DELETE
JSON_CALLBACK({"code":0})
```
## HTTPS API
SRS supports HTTPS API by turn the `https` on:
```
http_api {
enabled on;
listen 1985;
https {
# Whether enable HTTPS API.
# default: off
enabled on;
# The listen endpoint for HTTPS API.
# default: 1990
listen 1990;
# The SSL private key file, generated by:
# openssl genrsa -out server.key 2048
# 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"
# default: ./conf/server.crt
cert ./conf/server.crt;
}
}
```
> Remark: Please use your HTTPS key and cert file.
> Note: To enable the HTTPS live streaming, please read [HTTPS FLV Live Stream](./flv.md#https-flv-live-stream)
## HTTP and HTTPS Proxy
SRS works well with HTTP/HTTPS proxies such as [Nginx](./http-server.md#nginx-proxy), [HTTPX](./http-server.md#httpx-proxy),
[CaddyServer](./http-server.md#caddy-proxy), and so on.
## Server ID
Each response of api contains a `server` field, which identify the server. When ServerID changed, SRS already restarted, all information before is invalid.
## API Navigation
SRS provides the Navigation of APIs.
User can access the `http://192.168.1.102:1985/api/v1`, where:
| API | Example | Description |
| --- | -------- | --------- |
| server | 4481 | The identity of SRS |
| versions | /api/v1/versions | the version of SRS |
| summaries | /api/v1/summaries | the summary(pid, argv, pwd, cpu, mem) of SRS |
| rusages | /api/v1/rusages | the rusage of SRS |
| self_proc_stats | /api/v1/self_proc_stats | the self process stats |
| system_proc_stats | /api/v1/system_proc_stats | the system process stats |
| meminfos | /api/v1/meminfos | the meminfo of system |
| authors | /api/v1/authors | the license, copyright, authors and contributors |
| features | /api/v1/features | the supported features of SRS |
| requests | /api/v1/requests | the request itself, for http debug |
| vhosts | /api/v1/vhosts | manage all vhosts or specified vhost |
| streams | /api/v1/streams | manage all streams or specified stream |
| clients | /api/v1/clients | manage all clients or specified client, default query top 10 clients |
| configs | /api/v1/configs | RAW API for CUID the configs |
| publish | /rtc/v1/publish/ | The push stream API for WebRTC |
| play | /rtc/v1/play/ | The play stream API for WebRTC |
## WebRTC Publish
In order to push stream over WebRTC to SRS, SRS supports [WHIP](https://datatracker.ietf.org/doc/draft-ietf-wish-whip/).
The request is defined as:
```text
POST /rtc/v1/whip/?app=live&stream=livestream
Body in SDP, the Content-type is application/sdp:
v=0
......
a=ssrc:2064016335 label:c8243ce9-ace5-4d17-9184-41a2543101b5
```
SRS responses the SDP answer as the HTTP response:
```text
v=0
......
a=candidate:1 1 udp 2130706431 172.18.0.4 8000 typ host generation 0
```
> Note: The HTTP Status is 201, not 200, according to WHIP specification.
Please also see examples at [srs.sdk.js](https://github.com/ossrs/srs/blob/develop/trunk/research/players/js/srs.sdk.js) and [srs-unity: Publisher](https://github.com/ossrs/srs-unity#usage-publisher).
## WebRTC Play
In order to pull stream over WebRTC from SRS, SRS also supports [WHEP](https://datatracker.ietf.org/doc/draft-murillo-whep/).
The request is defined as:
```text
POST /rtc/v1/whep/?app=live&stream=livestream
Body in SDP, the Content-type is application/sdp:
v=0
......
a=ssrc:2064016335 label:c8243ce9-ace5-4d17-9184-41a2543101b5
```
> Note: Although WHIP is defined to push stream to SRS, but you're able to use it for pulling stream from SRS. There is another [WHEP](https://datatracker.ietf.org/doc/draft-murillo-whep/) for players, but not a RFC draft.
SRS responses the SDP answer as the HTTP response:
```
v=0
......
a=candidate:1 1 udp 2130706431 172.18.0.4 8000 typ host generation 0
```
> Note: The HTTP Status is 201, not 200, according to WHIP specification.
Please also see examples at [srs.sdk.js](https://github.com/ossrs/srs/blob/develop/trunk/research/players/js/srs.sdk.js) and [srs-unity: Player](https://github.com/ossrs/srs-unity#usage-player).
## Summaries
User can get the system summaries, for instance, the memory, cpu, network, load usage.
Please access the url `http://192.168.1.170:1985/api/v1/summaries`
## Vhosts
SRS provides http api to query all vhosts.
The http api vhost url: `http://192.168.1.102:1985/api/v1/vhosts`
To process specified vhost by id, for instance `http://192.168.1.102:1985/api/v1/vhosts/3756`
## Streams
SRS provides http api to query all streams.
The http api stream url: `http://192.168.1.102:1985/api/v1/streams`
Parameters in query string:
* `?start=N`: The start index, default is 0.
* `?count=N`: The max number of result, default is 10.
To process specified stream by id, for instance `http://192.168.1.102:1985/api/v1/streams/3756`
## Clients
SRS provides http api to query clients.
The http api client url: `http://192.168.1.102:1985/api/v1/clients`
Parameters in query string:
* `?start=N`: The start index, default is 0.
* `?count=N`: The max number of result, default is 10.
To process specified client by id, for instance `http://192.168.1.102:1985/api/v1/clients/3756`
## Kickoff Client
SRS provides HTTP RESTful api to kickoff user:
```
DELETE /api/v1/clients/{id}
```
User can get the id of client to kickoff:
```
GET /api/v1/clients
```
User can get the id of publish client from streams api:
```
GET /api/v1/streams
or GET /api/v1/streams/6745
```
The client cid is the info from stream api `stream.publish.cid`:
```
1. GET http://192.168.1.170:1985/api/v1/streams/6745
2. Response stream.publish.cid:
stream: {
publish: {
active: true,
cid: 107
}
}
3. DELETE http://192.168.1.170:1985/api/v1/clients/107
```
Remark: User can use [HTTP REST Tool](http://ossrs.net/srs.release/http-rest/index.html) to send a request.
Remark: User can use linux tool `curl` to start HTTP request. For example:
```
curl -v -X GET http://192.168.1.170:1985/api/v1/clients/426 && echo ""
curl -v -X DELETE http://192.168.1.170:1985/api/v1/clients/426 && echo ""
```
## Persistence Config
This feature is disabled by SRS 4.0.
## HTTP RAW API
SRS supports powerful HTTP RAW API, while other server only support `Read API`, for instance, to get the stat of server. SRS supports `Write API`, which can `Reload` or change server state.
<b>Remark:</b> User must enable the HTTP RAW API, in config section `http_api` to enable the `http_api.raw_api.enabled`, or SRS will response error code 1061.
```
http_api {
enabled on;
listen 1985;
raw_api {
enabled on;
allow_reload on;
}
}
```
The supported HTTP RAW APi of SRS is:
* `Raw`: To query the HTTP RAW API config.
* `Reload`: To reload the SRS.
### Raw
| Key | DESC |
| ---- | ---- |
| feature | Query the HTTP RAW API info. |
| url | `/api/v1/raw?rpc=raw` |
| curl | `curl http://127.0.0.1:1985/api/v1/raw?rpc=raw` |
| config | No config |
| params | No params|
### RAW Reload
| Key | DESC |
| ---- | ---- |
| feature | Reload is the same to `killall -1 srs` to reload the config |
| url | `/api/v1/raw?rpc=reload` |
| curl | `curl http://127.0.0.1:1985/api/v1/raw?rpc=reload` |
| params | No params |
### Other RAW APIs
Other RAW APIs are disabled by SRS 4.0.
## Authentication
Starting from version `5.0.152+` or `6.0.40+`, SRS supports HTTP API authentication, which can be enabled by configuring `http_api.auth`.
```bash
# conf/http.api.auth.conf
http_api {
enabled on;
listen 1985;
auth {
enabled on;
username admin;
password admin;
}
}
```
Otherwise, you can use environment variables to enable it:
```bash
env SRS_HTTP_API_ENABLED=on SRS_HTTP_SERVER_ENABLED=on \
SRS_HTTP_API_AUTH_ENABLED=on SRS_HTTP_API_AUTH_USERNAME=admin SRS_HTTP_API_AUTH_PASSWORD=admin \
./objs/srs -e
```
Then, you can access the following urls to verify it:
- Prompt for username and password: http://localhost:1985/api/v1/versions
- URL with authentication: http://admin:admin@localhost:1985/api/v1/versions
To clean up the username and password, you can access the HTTP API with the username only:
- http://admin@localhost:1985/api/v1/versions
> Note: authentication is only enabled for the HTTP APIs, neither for the HTTP server nor the WebRTC HTTP APIs.
Winlin 2015.8
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/http-api)

426
trunk/3rdparty/srs-docs/doc/http-callback.md vendored Normal file
View File

@ -0,0 +1,426 @@
---
title: HTTP Callback
sidebar_label: HTTP Callback
hide_title: false
hide_table_of_contents: false
---
# HTTPCallback
SRS supports HTTP callback to extends SRS. The workflow is:
```text
+--------+ +--------+ +-----------------------+
| FFmpeg |-->--+ SRS |--HTTP-Callback-->--+ Your Business Server |
+--------+ +--------+ +-----------------------+
```
When FFmpeg/OBS publish or play a stream to SRS, SRS will call your business server to notify the event.
## Usage
First, run SRS with HTTP callback enabled:
```bash
./objs/srs -c conf/http.hooks.callback.conf
```
Start the demo HTTP callback server, which is your business server:
```bash
go run research/api-server/server.go
```
Publish a stream to SRS, with the params:
```bash
ffmpeg -re -i doc/source.flv -c copy -f flv rtmp://localhost/live/livestream?k=v
```
Your business server will got the HTTP event:
```text
Got action=on_publish, client_id=3y1tcaw2, ip=127.0.0.1, vhost=__defaultVhost__, stream=livestream, param=?k=v
```
Note that the `k=v` can be used for authentication, for token authentication based on HTTP callbacks,
read [Token Authentication](./drm.md#token-authentication)
## Compile
SRS always enable http callbacks.
For more information, read [Build](./install.md)
## Configuring SRS
An example [conf/http.hooks.callback.conf](https://github.com/ossrs/srs/blob/develop/trunk/conf/http.hooks.callback.conf)
is available, demonstrating the configuration of common callback events for direct use.
The config for HTTP hooks is:
```bash
vhost your_vhost {
http_hooks {
# whether the http hooks enable.
# default off.
enabled on;
# when client(encoder) publish to vhost/app/stream, call the hook,
# the request in the POST data string is a object encode by json:
# {
# "action": "on_publish",
# "client_id": "9308h583",
# "ip": "192.168.1.10", "vhost": "video.test.com", "app": "live",
# "stream": "livestream", "param":"?token=xxx&salt=yyy", "server_id": "vid-werty",
# "stream_url": "video.test.com/live/livestream", "stream_id": "vid-124q9y3"
# }
# if valid, the hook must return HTTP code 200(Status OK) and response
# an int value specifies the error code(0 corresponding to success):
# 0
# support multiple api hooks, format:
# on_publish http://xxx/api0 http://xxx/api1 http://xxx/apiN
# @remark For SRS4, the HTTPS url is supported, for example:
# on_publish https://xxx/api0 https://xxx/api1 https://xxx/apiN
on_publish http://127.0.0.1:8085/api/v1/streams http://localhost:8085/api/v1/streams;
# when client(encoder) stop publish to vhost/app/stream, call the hook,
# the request in the POST data string is a object encode by json:
# {
# "action": "on_unpublish",
# "client_id": "9308h583",
# "ip": "192.168.1.10", "vhost": "video.test.com", "app": "live",
# "stream": "livestream", "param":"?token=xxx&salt=yyy", "server_id": "vid-werty",
# "stream_url": "video.test.com/live/livestream", "stream_id": "vid-124q9y3"
# }
# if valid, the hook must return HTTP code 200(Status OK) and response
# an int value specifies the error code(0 corresponding to success):
# 0
# support multiple api hooks, format:
# on_unpublish http://xxx/api0 http://xxx/api1 http://xxx/apiN
# @remark For SRS4, the HTTPS url is supported, for example:
# on_unpublish https://xxx/api0 https://xxx/api1 https://xxx/apiN
on_unpublish http://127.0.0.1:8085/api/v1/streams http://localhost:8085/api/v1/streams;
# when client start to play vhost/app/stream, call the hook,
# the request in the POST data string is a object encode by json:
# {
# "action": "on_play",
# "client_id": "9308h583",
# "ip": "192.168.1.10", "vhost": "video.test.com", "app": "live",
# "stream": "livestream", "param":"?token=xxx&salt=yyy",
# "pageUrl": "http://www.test.com/live.html", "server_id": "vid-werty",
# "stream_url": "video.test.com/live/livestream", "stream_id": "vid-124q9y3"
# }
# if valid, the hook must return HTTP code 200(Status OK) and response
# an int value specifies the error code(0 corresponding to success):
# 0
# support multiple api hooks, format:
# on_play http://xxx/api0 http://xxx/api1 http://xxx/apiN
# @remark For SRS4, the HTTPS url is supported, for example:
# on_play https://xxx/api0 https://xxx/api1 https://xxx/apiN
on_play http://127.0.0.1:8085/api/v1/sessions http://localhost:8085/api/v1/sessions;
# when client stop to play vhost/app/stream, call the hook,
# the request in the POST data string is a object encode by json:
# {
# "action": "on_stop",
# "client_id": "9308h583",
# "ip": "192.168.1.10", "vhost": "video.test.com", "app": "live",
# "stream": "livestream", "param":"?token=xxx&salt=yyy", "server_id": "vid-werty",
# "stream_url": "video.test.com/live/livestream", "stream_id": "vid-124q9y3"
# }
# if valid, the hook must return HTTP code 200(Status OK) and response
# an int value specifies the error code(0 corresponding to success):
# 0
# support multiple api hooks, format:
# on_stop http://xxx/api0 http://xxx/api1 http://xxx/apiN
# @remark For SRS4, the HTTPS url is supported, for example:
# on_stop https://xxx/api0 https://xxx/api1 https://xxx/apiN
on_stop http://127.0.0.1:8085/api/v1/sessions http://localhost:8085/api/v1/sessions;
# when srs reap a dvr file, call the hook,
# the request in the POST data string is a object encode by json:
# {
# "action": "on_dvr",
# "client_id": "9308h583",
# "ip": "192.168.1.10", "vhost": "video.test.com", "app": "live",
# "stream": "livestream", "param":"?token=xxx&salt=yyy",
# "cwd": "/usr/local/srs",
# "file": "./objs/nginx/html/live/livestream.1420254068776.flv", "server_id": "vid-werty",
# "stream_url": "video.test.com/live/livestream", "stream_id": "vid-124q9y3"
# }
# if valid, the hook must return HTTP code 200(Status OK) and response
# an int value specifies the error code(0 corresponding to success):
# 0
on_dvr http://127.0.0.1:8085/api/v1/dvrs http://localhost:8085/api/v1/dvrs;
# when srs reap a ts file of hls, call the hook,
# the request in the POST data string is a object encode by json:
# {
# "action": "on_hls",
# "client_id": "9308h583",
# "ip": "192.168.1.10", "vhost": "video.test.com", "app": "live",
# "stream": "livestream", "param":"?token=xxx&salt=yyy",
# "duration": 9.36, // in seconds
# "cwd": "/usr/local/srs",
# "file": "./objs/nginx/html/live/livestream/2015-04-23/01/476584165.ts",
# "url": "live/livestream/2015-04-23/01/476584165.ts",
# "m3u8": "./objs/nginx/html/live/livestream/live.m3u8",
# "m3u8_url": "live/livestream/live.m3u8",
# "seq_no": 100, "server_id": "vid-werty",
# "stream_url": "video.test.com/live/livestream", "stream_id": "vid-124q9y3"
# }
# if valid, the hook must return HTTP code 200(Status OK) and response
# an int value specifies the error code(0 corresponding to success):
# 0
on_hls http://127.0.0.1:8085/api/v1/hls http://localhost:8085/api/v1/hls;
# when srs reap a ts file of hls, call this hook,
# used to push file to cdn network, by get the ts file from cdn network.
# so we use HTTP GET and use the variable following:
# [server_id], replace with the server_id
# [app], replace with the app.
# [stream], replace with the stream.
# [param], replace with the param.
# [ts_url], replace with the ts url.
# ignore any return data of server.
# @remark random select a url to report, not report all.
on_hls_notify http://127.0.0.1:8085/api/v1/hls/[server_id]/[app]/[stream]/[ts_url][param];
}
}
```
Description about some fields:
* `stream_url`: The stream identify without extension, such as `/live/livestream`.
* `stream_id`: The id of stream, by which you can query the stream information.
> Note: The callbacks for streaming are `on_publish` and `on_unpublish`, while the callbacks for playback are `on_play` and `on_stop`.
> Note: Before SRS 4, there were `on_connect` and `on_close`, which are events defined by RTMP and only applicable to RTMP streams. These events overlap with streaming and playback events, so their use is not recommended.
> Note: You can refer to the hooks.callback.vhost.com example in the conf/full.conf configuration file.
## Protocol
The detail protocol, for example, `on_publish`:
```text
POST /api/v1/streams HTTP/1.1
Content-Type: application-json
Body:
{
"server_id": "vid-0xk989d",
"action": "on_publish",
"client_id": "341w361a",
"ip": "127.0.0.1",
"vhost": "__defaultVhost__",
"app": "live",
"tcUrl": "rtmp://127.0.0.1:1935/live?vhost=__defaultVhost__",
"stream": "livestream",
"param": "",
"stream_url": "video.test.com/live/livestream",
"stream_id": "vid-124q9y3"
}
```
> Note: You can use wireshark or tcpdump to verify it.
## Heartbeat
SRS will send heartbeat to the HTTP callback server. This allows you to monitor the health of SRS server.
Enable this feature by:
```bash
# heartbeat to api server
# @remark, the ip report to server, is retrieve from system stat,
# which need the config item stats.network.
heartbeat {
# whether heartbeat is enabled.
# Overwrite by env SRS_HEARTBEAT_ENABLED
# default: off
enabled off;
# the interval seconds for heartbeat,
# recommend 0.3,0.6,0.9,1.2,1.5,1.8,2.1,2.4,2.7,3,...,6,9,12,....
# Overwrite by env SRS_HEARTBEAT_INTERVAL
# default: 9.9
interval 9.3;
# when startup, srs will heartbeat to this api.
# @remark: must be a restful http api url, where SRS will POST with following data:
# {
# "device_id": "my-srs-device",
# "ip": "192.168.1.100"
# }
# Overwrite by env SRS_HEARTBEAT_URL
# default: http://127.0.0.1:8085/api/v1/servers
url http://127.0.0.1:8085/api/v1/servers;
# the id of device.
# Overwrite by env SRS_HEARTBEAT_DEVICE_ID
device_id "my-srs-device";
# whether report with summaries
# if on, put /api/v1/summaries to the request data:
# {
# "summaries": summaries object.
# }
# @remark: optional config.
# Overwrite by env SRS_HEARTBEAT_SUMMARIES
# default: off
summaries off;
}
```
By enable the `summaries`, you can get the SRS server states, such as `self.pid` and `self.srs_uptime`, so you
can use this to determine whether SRS restarted.
> Note: About fileds of `summaries`, see [HTTP API: summaries](./http-api.md#summaries) for details.
## Go Example
Write Go code to handle SRS callback, for example, handling `on_publish`:
```go
http.HandleFunc("/api/v1/streams", func(w http.ResponseWriter, r *http.Request) {
b, err := ioutil.ReadAll(r.Body)
if err != nil {
http.Error(w, err.Error(), http.StatusInternalServerError)
}
fmt.Println(string(b))
res, err := json.Marshal(struct {
Code int `json:"code"`
Message string `json:"msg"`
}{
0, "OK",
})
if err != nil {
http.Error(w, err.Error(), http.StatusInternalServerError)
}
w.Write(res)
})
_ = http.ListenAndServe(":8085", nil)
```
## Nodejs Koa Example
Write Nodejs/Koa code to handle SRS callback, for example, handling `on_publish`:
```js
const Router = require('koa-router');
const router = new Router();
router.all('/api/v1/streams', async (ctx) => {
console.log(ctx.request.body);
ctx.body = {code: 0, msg: 'OK'};
});
```
## PHP Example
Write PHP code to handle SRS callback, for example, handling `on_publish`:
```php
$body = json_decode(file_get_contents('php://input'));
printf($body);
echo json_encode(array("code"=>0, "msg"=>"OK"));
```
## HTTP Callback Events
SRS can call HTTP callbacks for events:
* `on_publish`: When a client publishes a stream, for example, using flash or FMLE to publish a stream to the server.
* `on_unpublish`: When a client stops publishing a stream.
* `on_play`: When a client starts playing a stream.
* `on_stop`: When a client stops playback.
* `on_dvr`: When reap a DVR file.
* `on_hls`: When reap a HLS file.
For events `on_publish`和`on_play`:
* Return Code: SRS requires that the response is an int indicating the error, 0 is success.
Notes:
* Event: When this event occurs, call back to the specified HTTP URL.
* HTTP URL: Can be multiple URLs, split by spaces, SRS will notify all one by one.
* Data: SRS will POST the data to specified HTTP API.
SRS will disconnect the connection when the response is not 0, or HTTP status is not 200.
## SRS HTTP Callback Server
SRS provides a default HTTP callback server, using golang native http framework.
To start it:
```bash
cd research/api-server && go run server.go 8085
```
```bash
#2023/01/18 22:57:40.835254 server.go:572: api server listen at port:8085, static_dir:/Users/panda/srs/trunk/static-dir
#2023/01/18 22:57:40.835600 server.go:836: start listen on::8085
```
> Remark: For SRS4, the HTTP/HTTPS url is supported, see [#1657](https://github.com/ossrs/srs/issues/1657#issuecomment-720889906).
## HTTPS Callback
HTTPS Callback is supported by SRS4, only change the callback URL from `http://` to `https://`, for example:
```
vhost your_vhost {
http_hooks {
enabled on;
on_publish https://127.0.0.1:8085/api/v1/streams;
on_unpublish https://127.0.0.1:8085/api/v1/streams;
on_play https://127.0.0.1:8085/api/v1/sessions;
on_stop https://127.0.0.1:8085/api/v1/sessions;
on_dvr https://127.0.0.1:8085/api/v1/dvrs;
on_hls https://127.0.0.1:8085/api/v1/hls;
on_hls_notify https://127.0.0.1:8085/api/v1/hls/[app]/[stream]/[ts_url][param];
}
}
```
## Response
If success, you must response `something` to identify the success, or SRS will reject the client, which enable you to reject the illegal client, please read [Callback Error Code](./http-api.md#error-code).
> Note: The `on_publish` callback also could be used as advanced security, to `allow` or `deny` a client by its IP, or token in request url, or any other information of client.
Where `something` means:
* HTTP/200, which is HTTP success.
* `AND` response and int value 0, or JSON object with field code 0.
Like this:
```
HTTP/1.1 200 OK
Content-Length: 1
0
```
OR:
```
HTTP/1.1 200 OK
Content-Length: 11
{"code": 0}
```
You could run the example HTTP callback server by:
```
cd srs/trunk/research/api-server && go run server.go 8085
```
And you will finger out what's the `right` response.
## Snapshot
The HttpCallback can used to snapshot, please read [snapshot](./snapshot.md#httpcallback)
Winlin 2015.1
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/http-callback)

308
trunk/3rdparty/srs-docs/doc/http-server.md vendored Normal file
View File

@ -0,0 +1,308 @@
---
title: HTTP Server
sidebar_label: HTTP Server
hide_title: false
hide_table_of_contents: false
---
# HTTP Server
SRS Embeded a HTTP web server, supports api and simple HTTP file for HLS.
To deploy SRS HTTP server, read [Usage: HTTP](./sample-http.md)
The SRS Embeded HTTP server is rewrite refer to go http module, so it's ok to use srs as http server. Read [#277](https://github.com/ossrs/srs/issues/277)
> Remark: The SRS HTTP server is just a origin HTTP server, for HTTP edge server, please use NGINX, SQUID and ATS.
SRS also works well with HTTP reverse proxy servers, like [NGINX](#nginx-proxy) and [Caddy](#caddy-proxy).
## Use Scenario
The SRS Embeded HTTP server is design to provides basic HTTP service,
like the camera of mobile phone.
SRS should provides HTTP api, which is actually a embeded HTTP server.
Actually, RTMP is more complex than HTTP, so HTTP server on st is absolutely ok.
The HTTP Server in SRS1.0 is an experiment, and I will enhance it in the future.
## Config
Config the HTTP port and root.
```bash
# 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.
# default: off
enabled on;
# the http streaming port
# @remark, if use lower port, for instance 80, user must start srs by root.
# default: 8080
listen 8080;
# the default dir for http root.
# default: ./objs/nginx/html
dir ./objs/nginx/html;
}
```
And, each vhost can specifies the dir.
```bash
vhost your_vhost {
# http static vhost specified config
http_static {
# whether enabled the http static service for vhost.
# default: off
enabled on;
# the url to mount to,
# typical mount to [vhost]/
# the variables:
# [vhost] current vhost for http server.
# @remark the [vhost] is optional, used to mount at specified vhost.
# @remark the http of __defaultVhost__ will override the http_stream section.
# for example:
# mount to [vhost]/
# access by http://ossrs.net:8080/xxx.html
# mount to [vhost]/hls
# access by http://ossrs.net:8080/hls/xxx.html
# mount to /
# access by http://ossrs.net:8080/xxx.html
# or by http://192.168.1.173:8080/xxx.html
# mount to /hls
# access by http://ossrs.net:8080/hls/xxx.html
# or by http://192.168.1.173:8080/hls/xxx.html
# default: [vhost]/
mount [vhost]/hls;
# main dir of vhost,
# to delivery HTTP stream of this vhost.
# default: ./objs/nginx/html
dir ./objs/nginx/html/hls;
}
}
```
Remark: The `http_stream` of SRS1 renamed to `http_server` in SRS2, which specifies the global HTTP server config, used to delivery http static files, for dvr files(HLS/FLV/HDS/MPEG-DASH).
Remark: The `http` of vhost of SRS1 renamed to `http_static`, similar to global `http_server` for HTTP static files delivery. While the `http_remux` introduced in SRS2 is dynamic remux RTMP to HTTP Live FLV/Mp3/Aac/HLS/Hds/MPEG-DASH stream.
## HTTPS Server
SRS supports HTTPS, just enable it in the configuration. By default, it uses a sub-signed certificate. If you need
to use a CA-issued certificate, please replace the relevant files. The related configuration is as follows:
```bash
http_server {
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;
}
}
```
## Crossdomain
SRS has CORS (Cross-Origin Resource Sharing) support enabled by default. The related configuration is as follows:
```bash
http_server {
# 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;
}
```
## MIME
Only some MIME is supported:
| File ext name | Content-Type |
| ------------- | ----------- |
| .ts | Content-Type: video/MP2T;charset=utf-8 |
| .m3u8 | Content-Type: application/x-mpegURL;charset=utf-8 |
| .json | Content-Type: application/json;charset=utf-8 |
| .css | Content-Type: text/css;charset=utf-8 |
| .swf | Content-Type: application/x-shockwave-flash;charset=utf-8 |
| .js | Content-Type: text/javascript;charset=utf-8 |
| .xml | Content-Type: text/xml;charset=utf-8 |
| Others | Content-Type: text/html;charset=utf-8 |
## Method
Supported HTTP method:
* GET: Query API, or download file.
## Paths
HTTP/HTTPS API:
* `/api/` SRS HTTP API
* `/rtc/` SRS WebRTC API
HTTP/HTTPS Stream:
* `/{app}/{stream}` HTTP Stream mounted by publisher.
The bellow is some reverse proxy to work with SRS.
> Note: Generally, a proxy can be used to route API and Stream together based on the path.
## Nginx Proxy
The config for NGINX as file [nginx.conf](https://github.com/ossrs/srs/blob/develop/trunk/conf/nginx.proxy.conf):
```
worker_processes 1;
events {
worker_connections 1024;
}
http {
include /etc/nginx/mime.types;
server {
listen 80;
listen 443 ssl http2;
server_name _;
ssl_certificate /usr/local/srs/conf/server.crt;
ssl_certificate_key /usr/local/srs/conf/server.key;
# For SRS homepage, console and players
# http://r.ossrs.net/console/
# http://r.ossrs.net/players/
location ~ ^/(console|players)/ {
proxy_pass http://127.0.0.1:8080/$request_uri;
}
# For SRS streaming, for example:
# http://r.ossrs.net/live/livestream.flv
# http://r.ossrs.net/live/livestream.m3u8
location ~ ^/.+/.*\.(flv|m3u8|ts|aac|mp3)$ {
proxy_pass http://127.0.0.1:8080$request_uri;
}
# For SRS backend API for console.
# For SRS WebRTC publish/play API.
location ~ ^/(api|rtc)/ {
proxy_pass http://127.0.0.1:1985$request_uri;
}
}
}
```
## Caddy Proxy
The config for [CaddyServer](https://caddyserver.com/docs/getting-started) with automatic HTTPS, use the config file `Caddyfile`.
For HTTP server, note that to set the default port:
```
:80
reverse_proxy /* 127.0.0.1:8080
reverse_proxy /api/* 127.0.0.1:1985
reverse_proxy /rtc/* 127.0.0.1:1985
```
For HTTPS server, please enable a domain name:
```
example.com {
reverse_proxy /* 127.0.0.1:8080
reverse_proxy /api/* 127.0.0.1:1985
reverse_proxy /rtc/* 127.0.0.1:1985
}
```
Start the CaddyServer:
```
caddy start -config Caddyfile
```
## Nodejs KOA Proxy
The nodejs koa proxy also works well for SRS, please use [koa-proxies](https://www.npmjs.com/package/koa-proxies) based by [node-http-proxy](https://github.com/nodejitsu/node-http-proxy), here is an example:
```js
const Koa = require('koa');
const proxy = require('koa-proxies');
const BodyParser = require('koa-bodyparser');
const Router = require('koa-router');
const app = new Koa();
app.use(proxy('/api/', {target: 'http://127.0.0.1:1985/'}));
app.use(proxy('/rtc/', {target: 'http://127.0.0.1:1985/'}));
app.use(proxy('/*/*.(flv|m3u8|ts|aac|mp3)', {target: 'http://127.0.0.1:8080/'}));
app.use(proxy('/console/', {target: 'http://127.0.0.1:8080/'}));
app.use(proxy('/players/', {target: 'http://127.0.0.1:8080/'}));
// Start body-parser after proxies, see https://github.com/vagusX/koa-proxies/issues/55
app.use(BodyParser());
// APIs that depends on body-parser
const router = new Router();
router.all('/', async (ctx) => {
ctx.body = 'Hello World';
});
app.use(router.routes());
app.listen(3000, () => {
console.log(`Server start on http://localhost:3000`);
});
```
Save it as `index.js`, then run:
```
npm init -y
npm install koa koa-proxies koa-proxies koa-bodyparser koa-router
node .
```
## HTTPX Proxy
Well [httpx-static](https://github.com/ossrs/go-oryx/tree/develop/httpx-static#usage) is a simple HTTP/HTTPS proxy written by Go:
```
go get github.com/ossrs/go-oryx/httpx-static
cd $GOPATH/bin
./httpx-static -http=80 -https=443 \
-skey /usr/local/srs/etc/server.key -scert /usr/local/srs/etc/server.crt \
-proxy=http://127.0.0.1:1985/api/v1/ \
-proxy=http://127.0.0.1:1985/rtc/v1/ \
-proxy=http://127.0.0.1:8080/
```
> Please make sure the path `/` is the last one.
Winlin 2015.1
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/http-server)

26
trunk/3rdparty/srs-docs/doc/ide.md vendored Normal file
View File

@ -0,0 +1,26 @@
---
title: IDE
sidebar_label: IDE
hide_title: false
hide_table_of_contents: false
---
# IDE
SRS supports JetBrains [CLion](http://www.jetbrains.com/clion/)
## VSCode
See [VSCode: Usage](https://github.com/ossrs/srs/blob/develop/.vscode/README.md) for example.
## JetBrains
The clion of JetBrains, please open `trunk/ide/srs_clion/CMakeLists.txt`
Read [http://www.jetbrains.com/clion/](http://www.jetbrains.com/clion/)
Winlin 2015.10
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/ide)

109
trunk/3rdparty/srs-docs/doc/ingest.md vendored Normal file
View File

@ -0,0 +1,109 @@
---
title: Ingest
sidebar_label: Ingest
hide_title: false
hide_table_of_contents: false
---
# Ingest
Ingest is used to ingest file(flv, mp4, mkv, avi, rmvb...),
stream(RTMP, RTMPT, RTMPS, RTSP, HTTP, HLS...) and device,
encode or passthrough then publish as RTMP to SRS.
Ingest actually use FFmpeg, or your tool, to encode or remux
to suck known data to RTMP to SRS.
How to deploy ingest, read [Ingest](./sample-ingest.md)
## Use Scenario
The main use scenarios:
* Virtual Live Stream: Convert vod file to live stream.
* Input RTSP IP Camera: Many IP Camera supports to pull in RTSP, user can ingest the RTSP to RTMP to SRS.
* Directly ingest device, use the FFmpeg as encoder actually.
* Ingest HTTp stream to RTMP for some old stream server.
In a word, the Ingest is used to ingest any stream supported by FFMPEG to SRS.
SRS server is support encoder to publish stream, while ingest can enable SRS to act like a client to pull
stream from other place.
## Build
Config SRS with option `--with-ingest`, read [Build](./install.md)
The ingest tool of SRS can use FFMPEG, or use your own tool.
## Config
The config to use ingest:
```bash
vhost your_vhost {
# ingest file/stream/device then push to SRS over RTMP.
# the name/id used to identify the ingest, must be unique in global.
# ingest id is used in reload or http api management.
ingest livestream {
# whether enabled ingest features
# default: off
enabled on;
# input file/stream/device
# @remark only support one input.
input {
# the type of input.
# can be file/stream/device, that is,
# file: ingest file specifies by url.
# stream: ingest stream specifeis by url.
# device: not support yet.
# default: file
type file;
# the url of file/stream.
url ./doc/source.flv;
}
# the ffmpeg
ffmpeg ./objs/ffmpeg/bin/ffmpeg;
# the transcode engine, @see all.transcode.srs.com
# @remark, the output is specified following.
engine {
# @see enabled of transcode engine.
# if disabled or vcodec/acodec not specified, use copy.
# default: off.
enabled off;
# output stream. variables:
# [vhost] current vhost which start the ingest.
# [port] system RTMP stream port.
output rtmp://127.0.0.1:[port]/live?vhost=[vhost]/livestream;
}
}
}
```
The word after ingest keyword is the id of ingest, the id must be unique.
The `type` specifies the ingest type:
* file: To ingest file to RTMP, SRS will add `-re` for FFMPEG.
* stream: To ingest stream to RTMP.
* device: Not support yet.
The `engine` specifies the transcode engine and output:
* enabled: Whether transcode, remux when off.
* output：The output RTMP url. The vhost and port is variable.
* others is same to [FFMPEG](./ffmpeg.md)
Note: Engine is copy, when:
* The enabled is off.
* The vcodec and acodec is not specified.
## Ingest File list
SRS does not ingest a file list, a wordaround:
* Use script as the ingest tool, which use ffmpeg to copy file to RTMP stream one by one.
Read https://github.com/ossrs/srs/issues/55
Winlin 2014.11
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/ingest)

66
trunk/3rdparty/srs-docs/doc/install.md vendored Normal file
View File

@ -0,0 +1,66 @@
---
title: Build and Install
sidebar_label: Build and Install
hide_title: false
hide_table_of_contents: false
---
# Install
You can directly use the release binaries, or build SRS step by step. See: [Github: release](http://ossrs.net/srs.release/releases/) or [Mirror of China: release](http://www.ossrs.net/srs.release/releases/)
## OS
* <strong>Ubuntu20</strong> is recommended.
* Use [srs-docker](https://github.com/ossrs/dev-docker/tree/dev) to build SRS.
* Use [srs-docker](https://github.com/ossrs/dev-docker) to run SRS.
## Iptables and Selinux
Sometimes the stream play failed, but without any error message, or server cann't connect to. Please check the iptables and selinux.
Turn off <code>iptables</code>:
```bash
# disable the firewall
sudo /etc/init.d/iptables stop
sudo /sbin/chkconfig iptables off
```
Disable the <code>selinux</code>, to run `getenforce` to ensure the result is `Disabled`:
1. Edit the config of selinux: `sudo vi /etc/sysconfig/selinux`
1. Change the SELINUX to disabled: `SELINUX=disabled`
1. Rebot: `sudo init 6`
## Build and Run SRS
It's very easy to build SRS:
```
./configure && make
```
Also easy to start SRS:
```bash
./objs/srs -c conf/srs.conf
```
Publish RTMP, please read: [Usage: RTMP](./rtmp.md)
For service management, please read [Service](./service.md)
Run SRS in docker, please read [srs-docker](https://github.com/ossrs/dev-docker#usage)
## ARM
It's also ok to directly build on ARM server.
For ARM/MIPS or crossbuild, please read [here](./arm.md)
Winlin 2014.11
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/install)

177
trunk/3rdparty/srs-docs/doc/introduction.md vendored Normal file
View File

@ -0,0 +1,177 @@
---
title: Introduction
sidebar_label: Introduction
hide_title: false
hide_table_of_contents: false
---
# Introduction
> Remark: SRS6 is developing and not stable.
SRS is a open-source ([MIT Licensed](../../../license)), simple, high-efficiency, real-time video server supporting RTMP,
WebRTC, HLS, HTTP-FLV, SRT, MPEG-DASH, and GB28181. SRS media server works with clients like [FFmpeg](https://ffmpeg.org),
[OBS](https://obsproject.com), [VLC](https://www.videolan.org), and [WebRTC](https://webrtc.org) to provide
the ability to [receive and distribute streams](./getting-started.md) in a typical publish (push) and
subscribe (play) server model. SRS supports widely used internet audio and video protocol conversions,
such as converting [RTMP](./rtmp.md) or [SRT](./srt.md) to [HLS](./hls.md), [HTTP-FLV](./flv.md), or
[WebRTC](./webrtc.md).
SRS is primarily used in the Live streaming and WebRTC fields. In the live streaming domain, SRS supports typical
protocols such as RTMP, HLS, SRT, MPEG-DASH, and HTTP-FLV. In the WebRTC field, SRS supports protocols like WebRTC,
WHIP, and WHEP. SRS facilitates protocol conversion for both Live streaming and WebRTC. As a media server, SRS
typically works alongside other open-source projects such as FFmpeg, OBS, and WebRTC. Oryx as an out-of-the-box
media solution, incorporating numerous open-source projects and tools, please refer to the [introduction](./getting-started-oryx.md#introduction)
of Oryx.
SRS provides an [HTTP API](./http-api.md) open interface to query system and stream status. It also supports
[HTTP Callback](./http-callback.md) for callback capabilities, actively notifying your system and implementing
stream authentication and business customization (such as dynamic DVR). SRS also supports the official
[Prometheus Exporter](./exporter.md) for integration with cloud-native monitoring systems, offering powerful
observability. SRS supports session-level [traceable logs](./log.md), greatly reducing system maintenance costs.
If you are new to audio, video, and streaming media or new to SRS, we recommend reading [Getting Started](./getting-started.md)
and [Learning Path](/guide). Please take the time to read the following documentation, as reading and
familiarizing yourself with the documentation is a basic requirement of the community. If you encounter any
problems, please first search in the [FAQ](../../../faq), then in [Issues](https://github.com/ossrs/srs/issues) and
[Discussions](https://github.com/ossrs/srs/discussions) to find answers to almost all questions.
SRS is developed using ANSI C++ (98) and only uses basic C++ capabilities. It can run on multiple platforms
such as Linux, Windows, and macOS. We recommend using Ubuntu 20+ for development and debugging. The image
we provide [ossrs/srs](https://hub.docker.com/r/ossrs/srs) is also built on Ubuntu 20 (focal).
> Note: To solve the long connection and complex state machine problems in complex streaming media processing,
> SRS uses [ST(State Threads)](https://github.com/ossrs/state-threads) coroutine technology (similar
> to [Goroutine](https://go.dev/doc/effective_go#goroutines)) and continuously enhances and maintains
> ST's capabilities, supporting multiple platforms such as Linux, Windows, macOS, and various CPU
> architectures like X86_64, ARMv7, AARCH64, M1, RISCV, LOONGARCH, and MIPS.
## Features
Functionality is often a major concern for people and the richness of features is an important reason for choosing a
project. You can view the detailed feature list at [Features](https://github.com/ossrs/srs/blob/develop/trunk/doc/Features.md#features).
We have listed the main features' versions, along with related Issue and PR links.
Additionally, in the detailed description of [Milestones](/product), the supported features for each major version
are introduced.
> Note: If you want to see the Issues for each milestone, you can check them at [Milestones](https://github.com/ossrs/srs/milestones).
Please note that although not many, SRS still marks some features as [Deprecated](https://github.com/ossrs/srs/blob/develop/trunk/doc/Features.md#features).
You can search for 'Deprecated' or 'Removed' on the page. We will also explain in detail why we are removing a
particular feature.
If you want to know about the features we are currently working on, you can join our [Discord](/contact#discussion)
and [Blog](../../../blog). Once new features are completed, we will post articles on Discord and Blog, so stay tuned.
## Who's using SRS?
SRS users are spread all over the world, and we welcome everyone to showcase their SRS applications
in [SRS Use Cases](https://github.com/ossrs/srs/discussions/3771).
## Governance
We welcome everyone to participate in the development and maintenance of SRS. We recommend starting by
resolving issues from [Contribute](https://github.com/ossrs/srs/contribute) and [submitting PRs](/how-to-file-pr).
All contributors will be showcased in [Contributors](https://github.com/ossrs/srs#authors).
SRS is a non-commercial open-source community where active developers have their own jobs and contribute to SRS's
development in their spare time.
Since the SRS system is highly efficient, we can spend minimal time making continuous improvements, delivering
feature-rich and stable high-quality products. Customizing based on SRS is also easy.
We are a global open-source community with developer communities both domestically and abroad. We welcome developers
to join us:
* Great sense of accomplishment: Your code can impact global users, change the audio and video industry, and transform various sectors as SRS is widely used.
* Solid technical progress: You can interact with top audio and video developers worldwide, master high-quality software development skills, and mutually enhance technical capabilities.
SRS currently uses the following techniques and rules to ensure high quality and efficiency:
* Long-term discussions on architecture and solutions. For significant features and plans, extensive discussions are required, such as the 7-year discussion on [HEVC/H.265](https://github.com/ossrs/srs/issues/465) support.
* Careful and thorough code reviews. Each pull request must be approved by at least two TOCs and developers and pass all Actions before merging.
* Comprehensive unit tests (over 500), code coverage (around 60%), black-box testing, etc., ensuring ample testing time with one year of development and one year of testing.
* Full pipeline: Each pull request has a pipeline, and each release is automatically completed by the pipeline.
We welcome you to join us. For more information, please visit [Contribute](https://github.com/ossrs/srs/contribute)
and submit a pull request as required.
## Milestone
SRS releases a major version approximately every two years, with one year for development and one year
for stability improvement. For more details, please refer to [Milestone](/product).
If you want to use SRS online, it's recommended to use the stable version. If you want to use new features, use
the development version.
SRS has branches based on versions, such as:
* [develop](https://github.com/ossrs/srs/tree/develop) SRS 6.0, development branch, unstable, but with the most new features.
* [5.0release](https://github.com/ossrs/srs/tree/5.0release#releases) SRS 5.0, currently stable, depending on the branch's status.
* [4.0release](https://github.com/ossrs/srs/tree/4.0release#releases) SRS 4.0, currently the stable branch, and will become more stable over time.
To determine if a branch is stable, check the Releases tag, such as [SRS 4.0](https://github.com/ossrs/srs/tree/4.0release#releases):
* 2022-06-11, Release v4.0-r0, this is a stable release version.
* 2021-12-01, Release v4.0-b0, this is a relatively stable beta version, also known as a public test version.
* 2021-11-15, Release v4.0.198, this version is an unstable development version.
> Note: In addition to beta versions, there are alpha versions, such as `v5.0-a0`, which are less stable internal
> test versions compared to beta.
> Note: Each alpha, beta, and release version will correspond to a specific version number, such as `v5.0-a0`
> corresponding to `v5.0.98`.
For SRS, generally, once it reaches the beta version, it can be used online.
## Strategy
SRS doesn't develop client-side applications because there are already mature and large open-source communities like
FFmpeg, OBS, VLC, and WebRTC. SRS collaborates with these communities and uses their products.
In addition to the SRS server, they also work on Oryx and WordPress plugins, with the main goal of creating
simpler application methods for different industries, including:
* [Oryx](https://github.com/ossrs/oryx): Oryx(SRS Stack) is an out-of-the-box, single-machine video cloud solution that includes FFmpeg and SRS. It's designed for users who aren't familiar with command lines and allows them to set up audio and video applications through Tencent Cloud images or BaoTa with mouse operations.
* [WordPress-Plugin-SrsPlayer](https://github.com/ossrs/WordPress-Plugin-SrsPlayer): This plugin is for the publishing industry, such as personal blogs and media websites, making it easy for users to utilize audio and video capabilities.
* [srs-unity](https://github.com/ossrs/srs-unity): This project is for the gaming industry, integrating Unity's WebRTC SDK to use audio and video capabilities.
SRS will continue to improve its toolchain. Developers may not use SRS but might have used the SB stress testing tool:
* [srs-bench](https://github.com/ossrs/srs-bench): An audio and video stress testing tool that supports RTMP, FLV, WebRTC, GB28181, etc., with plans for future improvements.
* [state-threads](https://github.com/ossrs/state-threads): A C coroutine library that can be considered a C version of Go. It's a small but powerful server library that will be continuously improved.
* [tea](https://github.com/ossrs/tea): This project explores eBPF for network simulation in weak network conditions and load balancing.
SRS aims to continuously improve audio and video toolchains, solutions, and scenario-based capabilities, making it
possible for various industries to utilize audio and video capabilities.
## Sponsors
SRS is committed to building a non-profit open-source project and community. We provide special community
support for friends who sponsor SRS. Please see [Sponsor](/contact#donation).
Audio and video developers often face challenges, and they might be used to the close support from cloud
service providers. When joining an open-source community, it might feel unfamiliar.
Don't panic when encountering issues. Most problems have solutions that can be found in the [FAQ](../../../faq)
or the documentation [Docs](./getting-started.md).
You can also join the Discord channel through [Support](/contact) to communicate with other developers.
However, please follow community guidelines, or you won't receive help.
As developers, we must learn to read documentation, investigate issues, and then discuss them within the community.
For advanced developers, we suggest becoming a `Backer/Sponsor`. See [Support](/contact#donation).
SRS has no commercial plans. We are currently working hard to build a global, active developer community.
The value of open-source will grow, and community support will increase.
## About Oryx
Oryx is a lightweight, open-source video cloud solution based on Go, Reactjs, SRS, FFmpeg, WebRTC,
and more. For more details, please refer to [Oryx](./getting-started-oryx.md).
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/introduction)

579
trunk/3rdparty/srs-docs/doc/k8s.md vendored Normal file
View File

@ -0,0 +1,579 @@
---
title: K8s Guide
sidebar_label: K8s Guide
hide_title: false
hide_table_of_contents: false
---
# K8S
> Cloud+Docker+K8S enable everyone to build live video streaming cluster and service.
Why should you use [k8s](https://docs.kubernetes.io/docs/concepts/overview/what-is-kubernetes) to build your SRS cluster?
* Simple: It's really simple and convenient, let's figure it out by [QuickStart](./k8s.md#quick-start).
* Declarative deployment: We declare a desired SRS cluster and it'll always be there, without starting and migrating service, watchdog and SLB configuration.
* Expand easily: K8S allows you to expand infrastructure automatically, and you can expand your business cluster easily by change the number of Pods.
* Rolling Update: K8S allows deployment update, rollback and gray release with zero downtime.
* XXX: Coming soon...
This tutorial highlights how to build SRS cluster for a variety of scenarios in [ACK(AlibabaCloud Container Service for Kubernetes)](https://www.alibabacloud.com/product/kubernetes).
1. [Deploy to Cloud Platforms](./k8s.md#deploy-to-cloud-platforms): Clone template project and use actions to deploy.
2. [Quick Start](./k8s.md#quick-start): Deployment an SRS origin server in ACK.
3. [SRS Shares Volume with Nginx](./k8s.md#srs-shares-volume-with-nginx): SRS is able to deliver simple HTTP content, or work with Nginx, SRS delivers RTMP/HTTP-FLV and write HLS to a share volume, then Nginx reads and delivers HLS.
4. [SRS Edge Cluster for High Concurrency Streaming](./k8s.md#srs-edge-cluster-with-slb): SRS edge cluster, which is configured and updated automatically, to provide services for huge players.
5. [SRS Origin Cluster for a Large Number of Streams](./k8s.md#srs-origin-cluster-for-a-large-number-of-streams): SRS origin cluster is designed to serve a large number of streams.
6. [SRS Cluster Update, Rollback, Gray Release with Zero Downtime](./k8s.md#srs-cluster-update-rollback-gray-release-with-zero-downtime): K8S allows deployment update, rollback and gray release with zero downtime.
7. [Useful Tips](./k8s.md#useful-tips)
1. [Create K8S Cluster in ACK](./k8s.md#create-k8s-cluster-in-ack): Create your own k8s cluster in ACK.
2. [Publish Demo Streams to SRS](./k8s.md#publish-demo-streams-to-srs): Publish the demo streams to SRS.
3. [Cleanup For DVR/HLS Temporary Files](./k8s.md#cleanup-for-dvrhls-temporary-files): Remove the temporary files for DVR/HLS.
4. [Use One SLB and EIP for All Streaming Service](./k8s.md#use-one-slb-and-eip-for-all-streaming-service): Use one SLB for RTMP/HTTP-FLV/HLS streaming service.
5. [Build SRS Origin Cluster as Deployment](./k8s.md#build-srs-origin-cluster-as-deployment): Rather than StatefulSet, we can also use deployment to build Origin Cluster.
6. [Managing Compute Resources for Containers](./k8s.md#managing-compute-resources-for-containers): Resource requests and limits, and how pods requests are scheduled and limits are run.
7. [Auto Reload by Inotify](./k8s.md#auto-reload-by-inotify): SRS supports auto reload by inotify watching ConfigMap changes.
## Deploy to Cloud Platforms
SRS provides a set of template repository for fast deploy:
* [General K8s](https://github.com/ossrs/srs-k8s-template)
* [TKE(Tencent Kubernetes Engine)](https://github.com/ossrs/srs-tke-template)
* [ACK(Alibaba Cloud Container Service for Kubernetes)](https://github.com/ossrs/srs-ack-template)
* [EKS(Amazon Elastic Kubernetes Service)](https://github.com/ossrs/srs-eks-template)
* [AKS(Azure Kubernetes Service)](https://github.com/ossrs/srs-aks-template)
## Quick Start
Assumes you have access to a k8s cluster:
```bash
kubectl cluster-info
```
Let's take a look at a single SRS origin server in k8s.
![SRS: Single Origin Server](/img/doc-advanced-guides-k8s-001.png)
**Step 1:** Create a [k8s deployment](https://v1-14.docs.kubernetes.io/docs/concepts/workloads/controllers/deployment) for SRS origin server:
```bash
cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
name: srs-deployment
labels:
app: srs
spec:
replicas: 1
selector:
matchLabels:
app: srs
template:
metadata:
labels:
app: srs
spec:
containers:
- name: srs
image: ossrs/srs:3
ports:
- containerPort: 1935
- containerPort: 1985
- containerPort: 8080
EOF
```
**Step 2:** Create a [k8s service](https://v1-14.docs.kubernetes.io/docs/concepts/services-networking/service) which exposing live video streaming service by [SLB](https://www.alibabacloud.com/product/server-load-balancer) with [EIP](https://www.alibabacloud.com/product/eip):
```bash
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Service
metadata:
name: srs-service
spec:
type: LoadBalancer
selector:
app: srs
ports:
- name: srs-service-1935-1935
port: 1935
protocol: TCP
targetPort: 1935
- name: srs-service-1985-1985
port: 1985
protocol: TCP
targetPort: 1985
- name: srs-service-8080-8080
port: 8080
protocol: TCP
targetPort: 8080
EOF
```
**Step 3:** Done, you could get the EIP and play with SRS now.
Please use `kubectl get svc/srs-service` to get the EIP:
```
NAME TYPE CLUSTER-IP EXTERNAL-IP
srs-service LoadBalancer 172.21.12.131 28.170.32.118
```
Then you can publish and play with `28.170.32.118`:
* Publish RTMP to `rtmp://28.170.32.118/live/livestream`
* Play RTMP from `rtmp://28.170.32.118/live/livestream`
* Play HTTP-FLV from [http://28.170.32.118:8080/live/livestream.flv](http://ossrs.net/players/srs_player.html?app=live&stream=livestream.flv&server=28.170.32.118&port=8080&autostart=true&vhost=28.170.32.118&schema=http)
* Play HLS from [http://28.170.32.118:8080/live/livestream.m3u8](http://ossrs.net/players/srs_player.html?app=live&stream=livestream.m3u8&server=28.170.32.118&port=8080&autostart=true&vhost=28.170.32.118&schema=http)
![ACK: SRS Done](/img/doc-advanced-guides-k8s-002.png)
## SRS Shares Volume with Nginx
This chapter will show you how SRS is going to provide HTTP Service with Nginx based on K8S.
SRS can distribute RTMP and HTTP-FLV, and write HLS segments to shared Volume, the Nginx Container can read Volume and distribute HLS. Of course SRS can distribute HLS too, but the next scenarios are better to use Nginx :
* 80 port is already used by nginx, SRS can share Volume with Nginx
* Nginx support HTTPS, after configure certificate, it can serve the HLS files generated by SRS through HTTPS protocol.
* Nginx or other Web server, can provide authenticate to serve HLS segments in a secure way.
* SRS now only support a part of HTTP/1.1。 Nginx Open Source version 1.9.5 or higher has built-in support for HTTP/2
the difference of traditional package deployment vs K8S:
| |ECS|K8S|comment|
|:--|:--|:--|:--|
|resources|Manually|Automatically|From the traditional deployment, the resources SLB、EIP and ECS, you need to buy and configure one by one yourself, use k8s the mentioned resources can be acquired and configured automatically.|
|deployment|Package|Image|From the K8s deployment, the pod’s docker image can easily rollback, and can keep the dev environment in touch with the prod, and the image can be cached on the node. So with docker image, you will get the required high efficiency、high density、high portability、resource isolation.|
|migration|Manually|Automatically|From the traditional deployment way, when change ECS, you need to apply the new machine resource, modify SLB, and install application by yourself. Based on K8S, it can auto complete the service migration, update SLB, configure liveness, readiness and startup probes.|
The following architecture of the K8s deployment:
![ack-srs-shares-volume-with-nginx](/img/doc-advanced-guides-k8s-003.png)
Step 1: Create a k8s deployment for SRS and Nginx, the srs container will write the HLS segment to the shared Volume
```
cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
name: srs-deploy
labels:
app: srs
spec:
replicas: 1
selector:
matchLabels:
app: srs
template:
metadata:
labels:
app: srs
spec:
volumes:
- name: cache-volume
emptyDir: {}
containers:
- name: srs
image: ossrs/srs:3
imagePullPolicy: IfNotPresent
ports:
- containerPort: 1935
- containerPort: 1985
- containerPort: 8080
volumeMounts:
- name: cache-volume
mountPath: /usr/local/srs/objs/nginx/html
readOnly: false
- name: nginx
image: nginx
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
volumeMounts:
- name: cache-volume
mountPath: /usr/share/nginx/html
readOnly: true
- name: srs-cp-files
image: ossrs/srs:3
imagePullPolicy: IfNotPresent
volumeMounts:
- name: cache-volume
mountPath: /tmp/html
readOnly: false
command: ["/bin/sh"]
args:
- "-c"
- >
if [[ ! -f /tmp/html/index.html ]]; then
cp -R ./objs/nginx/html/* /tmp/html
fi &&
sleep infinity
EOF
```
> Note: Nginx’s default directory is /usr/share/nginx/html, please be awared, and change it to your own directory
> Note: To share HLS segments, both SRS and Nginx are mounted to the emptyDir Volume at different paths, the emptyDir volume is initially empty and will be emptied as the pod is destoryed.
> Note: Since the shared emptyDir Volume is initially empty, we start a srs-cp-files container, and copied the SRS default files, please refer to [#1603](https://github.com/ossrs/srs/issues/1603).
Step 2: create a [k8s Service](https://kubernetes.io/docs/concepts/services-networking/service/), using SLB to provide external streaming service.
```
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Service
metadata:
name: srs-origin-service
spec:
type: LoadBalancer
selector:
app: srs
ports:
- name: srs-origin-service-80-80
port: 80
protocol: TCP
targetPort: 80
- name: srs-origin-service-1935-1935
port: 1935
protocol: TCP
targetPort: 1935
- name: srs-origin-service-1985-1985
port: 1985
protocol: TCP
targetPort: 1985
- name: srs-origin-service-8080-8080
port: 8080
protocol: TCP
targetPort: 8080
EOF
```
> Note: We expose ports for external services through k8s LoadBalancer Service, where RTMP(1935)/FLV(8080)/API(1985) is served by SRS and HLS(80) is served by Nginx.
> Note: Here we choose ACK to create SLB and EIP automatically, or you can specify SLB manually, refer to [Use One SLB and EIP for All Streaming Service](./k8s.md#ack-srs-buy-slb-eip).
Step 3: Great job. You can publish and play streams now. the HLS stream can by played from SRS(8080) or Nginx(80).
* Publish RTMP to rtmp://28.170.32.118/live/livestream or Publish Demo Streams to SRS.
* Play RTMP from rtmp://28.170.32.118/live/livestream
* Play HTTP-FLV from http://28.170.32.118:8080/live/livestream.flv
* Play HLS from http://28.170.32.118:8080/live/livestream.m3u8
* Play HLS from http://28.170.32.118/live/livestream.m3u8
> Note: Please replace the above EIP with your own, and use 'kubectl get svc/srs-origin-service’ to check your EIP
## SRS Edge Cluster for High Concurrency Streaming
This chapter will show you how to build Edge Cluster for high concurrency streaming based on k8s.
Edge Cluster realizes merging the request of origin source. When there are many players, but request for a same stream, the Edge server still only request one stream from origin. So you can scale up the Edge Cluster to facilitate more clients requests. This is CDN’s important capability:high concurreny.
> Note: Edge Cluster can be classified as RTMP Edge Cluster or HTTP-FLV Edge Cluster depending on the player’s stream protocol, for more details, can refer to the related Wiki.
For self-host origin, without so many play requests, why is it not recommended to use SRS Single Origin mode, and instead use Edge Cluster mode? look at the related scenarios:
* Avoid overloading of origin. Even if it’s a bit push and play scene, in the case of many CDN requests for one origin stream, may be result in one stream has many request connections. Use Edge cluster can protect origin from too many requests, and transfer the danger to edge.
* Can easily scale up multi Edge Clusters with different SLB exported, and to avoid interference of multiple CDNs, can execute traffic limit on sperate SLB. Use many Edge Clusters can ensure some CDN is available when Origin is down.
* Can let Edge Cluster to handle stream distribution, and let Origin focus on Slice segments、 DVR、 Authentication functions.
the difference of traditional package deployment vs K8S:
| | ECS | K8S | comment |
| :----: | :---- | :---- | :---- |
| Resources | Manually |Automatically| From the traditional deployment, the resources SLB、EIP and ECS, you need to buy and configure one by one yourself, use k8s the mentioned resources can be acquired and configured automatically. |
| Deployment | Package |Image| From the K8s deployment, the pod’s docker image can easily rollback, and can keep the dev environment in touch with the prod, and the image can be cached on the node. <br/>So with docker image, you will get the required high efficiency、high density、high portability、resource isolation. |
| Watchdog | Manually |Automatically| When srs exited abnormally, the event should be monitored and auto restarted, you need do it by yourself from the traditional way.<br/>K8s provides liveness probes and ensuring automatically recovered when anormaly appears. |
| Migration | Manually |Automatically| From the traditional deployment way, when change ECS, you need to apply the new machine resource, modify SLB, and install application by yourself.<br/>Based on K8S, it can auto complete the service migration, update SLB, configure liveness, readiness and startup probes. |
| Configure | File |Volume| From the traditional deployment way, you need to configure ECS manually.<br/>K8s stores configuration data in ConfigMap, the data can be added to a specific path in the Volume, and consumed by the Pods. Allow you to decouple ECS scale up. |
| Scale Up | Manually |Automatically| From the traditional deployment way, you need to deploy and configure for the new applied ECS. <br/>Based on K8s, just modify the Replicas is ok, you can also enable auto scale. |
| Service Discovery | Manually |Automatically| From the traditional deployment way, when the Origin’s ip changed, you need to configure the new ip in Edge's config file.<br/>Use K8s, it will discover and notify the change to the Edge. |
| SLB | Manually |Automatically| From the traditional deployment way, when add a new Edge server, you need to update SLB config manually.<br/>Based on K8s, it will get updated automatically. |
The following architecture of The K8s deployment:
![avatar](/img/doc-advanced-guides-k8s-004.png)
Step 1: Create Deployment and Service for SRS origin and Nginx origin.
* srs-origin-deploy: create a [k8s deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) of stateless application, which contains SRS Server(with origin config)、Nginx containers and a shared volume for containers to mount. The srs container will write the HLS segment to the shared [volume](https://kubernetes.io/docs/concepts/storage/volumes/).
* srs-origin-service: create a k8s ClusterIP [Service](https://kubernetes.io/docs/concepts/services-networking/service/) to provide Origin service, which can only be accessed inside the cluster.
* srs-http-service: create a k8s LoadBalancer [Service](https://kubernetes.io/docs/concepts/services-networking/service/) to provide the SLB based HTTP distribution service of HLS segments powered by Nginx.
```
cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
name: srs-origin-deploy
labels:
app: srs-origin
spec:
replicas: 1
selector:
matchLabels:
app: srs-origin
template:
metadata:
labels:
app: srs-origin
spec:
volumes:
- name: cache-volume
emptyDir: {}
containers:
- name: srs
image: ossrs/srs:3
imagePullPolicy: IfNotPresent
ports:
- containerPort: 1935
- containerPort: 1985
- containerPort: 8080
volumeMounts:
- name: cache-volume
mountPath: /usr/local/srs/objs/nginx/html
readOnly: false
- name: nginx
image: nginx
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
volumeMounts:
- name: cache-volume
mountPath: /usr/share/nginx/html
readOnly: true
- name: srs-cp-files
image: ossrs/srs:3
imagePullPolicy: IfNotPresent
volumeMounts:
- name: cache-volume
mountPath: /tmp/html
readOnly: false
command: ["/bin/sh"]
args:
- "-c"
- >
if [[ ! -f /tmp/html/index.html ]]; then
cp -R ./objs/nginx/html/* /tmp/html
fi &&
sleep infinity
---
apiVersion: v1
kind: Service
metadata:
name: srs-origin-service
spec:
type: ClusterIP
selector:
app: srs-origin
ports:
- name: srs-origin-service-1935-1935
port: 1935
protocol: TCP
targetPort: 1935
---
apiVersion: v1
kind: Service
metadata:
name: srs-http-service
spec:
type: LoadBalancer
selector:
app: srs-origin
ports:
- name: srs-http-service-80-80
port: 80
protocol: TCP
targetPort: 80
- name: srs-http-service-1985-1985
port: 1985
protocol: TCP
targetPort: 1985
EOF
```
> Note: The Origin server only can be accessed inside the cluster, for it’s service type is ClsterIP, the Edge Server can connect to the remote Origin Server through the internal domain srs-origin-service.
> Note: For share HLS segments, both SRS and Nginx are mounted to the [emptyDir Volume](https://kubernetes.io/docs/concepts/storage/volumes/#emptydir) at different paths, the emptyDIr volume is initially empty and the data in the emptyDir is deleted when the pod is removed.
> Note: As the emptyDir is initially empty, so we start a srs-cp-files container, which will copy srs’s cached files to the shared volume. please refer[1603](https://github.com/ossrs/srs/issues/1603)
> Note: The srs-http-service provide HLS distribution service with Nginx’s 80 port exported, and provide API service with SRS’s 1985 port exported.
> Note: Here we choose ACK to create SLB and EIP automatically, or you can specify SLB manually, refer to [Use One SLB and EIP for All Streaming Service](./k8s.md#ack-srs-buy-slb-eip)
Step 2: Create Deployment and Service for SRS edge.
* srs-edge-config: create a k8s [ConfigMap](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/), which stores configuration of SRS Edge Server.
* sts-edge-deploy: create a [k8s deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/), which will deploy a stateless application, and running multi replicas of SRS Edge Server.
* srs-edge-service: create a [k8s Service](https://kubernetes.io/docs/concepts/services-networking/service/), using SLB to provide external streaming service
```
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ConfigMap
metadata:
name: srs-edge-config
data:
srs.conf: |-
listen 1935;
max_connections 1000;
daemon off;
http_api {
enabled on;
listen 1985;
}
http_server {
enabled on;
listen 8080;
}
vhost __defaultVhost__ {
cluster {
mode remote;
origin srs-origin-service;
}
http_remux {
enabled on;
}
}
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: srs-edge-deploy
labels:
app: srs-edge
spec:
replicas: 3
selector:
matchLabels:
app: srs-edge
template:
metadata:
labels:
app: srs-edge
spec:
volumes:
- name: config-volume
configMap:
name: srs-edge-config
containers:
- name: srs
image: ossrs/srs:3
imagePullPolicy: IfNotPresent
ports:
- containerPort: 1935
- containerPort: 1985
- containerPort: 8080
volumeMounts:
- name: config-volume
mountPath: /usr/local/srs/conf
---
apiVersion: v1
kind: Service
metadata:
name: srs-edge-service
spec:
type: LoadBalancer
selector:
app: srs-edge
ports:
- name: srs-edge-service-1935-1935
port: 1935
protocol: TCP
targetPort: 1935
- name: srs-edge-service-8080-8080
port: 8080
protocol: TCP
targetPort: 8080
EOF
```
Note: The Edge Server’s configuration is stored in [ConfigMap](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/) of srs-edge-config, and [mount](https://kubernetes.io/docs/concepts/storage/volumes/#configmap) it to the /usr/local/srs/conf path, the srs.conf will appear in the directory.
Note: The Edge Server has been configured to work in cluster mode:remote, it will connect to the Origin Server through domain:srs-origin-service.
Note: The srs-edge-service provide RTMP service with SRS’s 1935 port exported, and provide HTTP-FLV service with SRS’s 80 port.
Note: we choose ACK to create SLB and EIP automatically, or you can specify SLB manually, refer to [Use One SLB and EIP for All Streaming Service](./k8s.md#ack-srs-buy-slb-eip).
Step 3: Now, you made it. you can push retmp stream to the edge, and pull hls stream from Nginx, pull RTMP, HTTP-FLV from SRS.
* Publish RTMP to rtmp://28.170.32.118/live/livestream or [Publish Demo Streams to SRS](./k8s.md#ack-srs-publish-demo-stream-to-edge).
* Play RTMP from `rtmp://28.170.32.118/live/livestream`
* Play HTTP-FLV from [http://28.170.32.118:8080/live/livestream.flv](http://ossrs.net/players/srs_player.html?app=live&stream=livestream.flv&server=28.170.32.118&port=8080&autostart=true&vhost=28.170.32.118&schema=http)
* Play HLS from [http://28.170.32.118/live/livestream.m3u8](http://ossrs.net/players/srs_player.html?app=live&stream=livestream.m3u8&server=28.170.32.118&port=80&autostart=true&vhost=28.170.32.118&schema=http)
> Note: Please change the EIP in the stream address to yourself. you can exec 'kubectl get svc/srs-http-service' or 'kubectl get svc/srs-edge-service’ command to check your EIP address.
> Note: If the SLB and EIP are created automatically, the HLS and RTMP/HTTP-FLV’s EIP are different. you can choose to specify the SLB manually, and both services can use the same SLB, for details please refer to [Use One SLB and EIP for All Streaming Service](./k8s.md#ack-srs-buy-slb-eip).
## SRS Origin Cluster for a Large Number of Streams
Coming soon...
## SRS Cluster Update, Rollback, Gray Release with Zero Downtime
Coming soon...
## Useful Tips
There are some useful tips for you.
1. [Create K8S Cluster in ACK](./k8s.md#create-k8s-cluster-in-ack): Create your own k8s cluster in ACK.
1. [Publish Demo Streams to SRS](./k8s.md#publish-demo-streams-to-srs): Publish the demo streams to SRS.
1. [Use One SLB and EIP for All Streaming Service](./k8s.md#use-one-slb-and-eip-for-all-streaming-service): Use one SLB for RTMP/HTTP-FLV/HLS streaming service.
1. [Build SRS Origin Cluster as Deployment](./k8s.md#build-srs-origin-cluster-as-deployment): Rather than StatefulSet, we can also use deployment to build Origin Cluster.
1. [Managing Compute Resources for Containers](./k8s.md#managing-compute-resources-for-containers): Resource requests and limits, and how pods requests are scheduled and limits are run.
1. [Auto Reload by Inotify](./k8s.md#auto-reload-by-inotify): SRS supports auto reload by inotify watching ConfigMap changes.
### Create K8S Cluster in ACK
Coming soon...
### Publish Demo Streams to SRS
Coming soon...
### Use One SLB for All Streaming Service
Coming soon...
### Build SRS Origin Cluster as Deployment
Coming soon...
### Managing Compute Resources for Containers
Coming soon...
### Auto Reload by Inotify
Coming soon...
Winlin 2020.02
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/k8s)

66
trunk/3rdparty/srs-docs/doc/learning-path.md vendored Normal file
View File

@ -0,0 +1,66 @@
---
title: Learning Path
sidebar_label: Learning Path
hide_title: false
hide_table_of_contents: false
---
# Learning Path
A learning path for newcomers, please be sure to follow the documentation.
## Quick Preview
First, It takes about 5 to 15 minutes to see what live streaming and WebRTC look like, as the following picture shown:。
![](/img/doc-learning-path-001.png)
> Note: This may seem easy, even if you can open two pages directly from the SRS website, but you must build it yourself with SRS, not just open the online demo page.
How do you do it？Please refer to [Getting Started](./getting-started.md)。
The first step in approaching something new is to have an intuitive experience and feel for it. Although it seems simple, it involves almost the whole chain of things in the audio/video field：
- FFmpeg, a powerful audio/video client that supports publish and pull streaming, codecs encoding and decoding , as well as various processing capabilities.
- Chrome (or browser), H5 is the most convenient client, very convenient for demo and learning, SRS’s features basically have H5 demo.
- Audio and video protocols: RTMP, HTTP-FLV, HLS and WebRTC.
- SRS server, deploying audio and video cloud by itself, or providing cloud services for audio and video, SRS is essentially a kind of server for video cloud.
> Note: The above diagram is still missing the mobile end, in fact, the mobile end is just a kind of end, and there is no new protocol, you can also download the SRS live streaming client, experience the above push stream and play, you can also enter your server's stream address to play.
## Deeper
Second, understand each typical scenario of audio and video applications, about five core scenarios, which takes about 3~7 days in total:
Typical audio and video business scenarios, including but not limited to:
- All-platform live streaming. The Encoders (FFmpeg/OBS) above can publish RTMP to SRS; an SRS Origin (no need Cluster), which is muxed into HTTP-FLV streams and HLS; Players can choose HTTP-FLV or HLS streams to play according to the platform's player.
- WebRTC call services, one-to-one calls, multi-person calls, conference rooms, etc. WebRTC is the key and core capability introduced in SRS4. From 1 to 3 seconds latency at the beginning, to 100 to 300 milliseconds latency now, it is definitely not a change of numbers, but an essential change.
- Monitoring and broadcasting business to the cloud. In addition to using FFmpeg to actively pull streams to SRS, you can also use the SRT protocol of the broadcasting industry to publish streams, or the GB28181 protocol of the surveillance industry to publish streams, SRS can converts it to the Internet protocols for playing.
- Low latency live streaming and interactive live streaming. Convert RTMP to WebRTC for playing to reduce the latency of palying, and can also use the WebRTC to publish stream. In the future will support WebTransport live streaming.
- Large-Scale Business, if business grows rapidly, you can use SRS Edge Cluster to support massice Players, or use SRS Origin Cluster to support massive Encoders, of course, you can migrate your business to the video cloud smoothly too. In the future, SRS will also support WebRTC cluster.
Each scenario can build a typical application.
## For Details
Third, Understand the technical points, application scenarios, code and problem solving, about 3 to 6 months.
- [Video Columns](./introduction.md#effective-srs), includes environment building, code analysis, and explanations from professional teachers at Voice Academy.
- [Solution Guides](./introduction.md#solution-guides)，share and explore the application of SRS in different scenarios.
- [Deployment Guides](./introduction.md#deployment-guides), how to deploy to implement different specific functions.
- [Cluster Guides](./introduction.md#cluster-guides), when business grows rapidly, how to scale single server to cluster, and how to serve users in different regions.
- [Integration Guides](./introduction.md#integration-guides), How to integrate with existing systems, how to authenticate users, security and anti-stealing chain mechanisms, etc.
- [Develop Guides](./introduction.md#develop-guide), Concurrent principles, code analysis, high performance server framework, performance optimization, etc.
If you can thoroughly understand SRS, it's really not difficult.
Author：winlinvip
Origin Link：https://www.jianshu.com/p/2662df9fe078
From：jianshu.com
The copyright belongs to the author. For commercial reproduction, please contact the author for authorization, and for non-commercial reproduction, please cite the source.
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/learning-path)

73
trunk/3rdparty/srs-docs/doc/log-rotate.md vendored Normal file
View File

@ -0,0 +1,73 @@
---
title: Log Rotate
sidebar_label: Log Rotate
hide_title: false
hide_table_of_contents: false
---
# LogRotate
SRS always writes log to a single log file `srs.log`, so it will become very larger. We can use rotate the log to zip or remove it.
1. First, move the log file to another tmp log file:```mv objs/srs.log /tmp/srs.`date +%s`.log```
1. Then, send signal to SRS. SRS will close the previous file fd and reopen the log file:```killall -s SIGUSR1```
1. Finally, zip or remove the tmp log file.
## Use logrotate
Recommend to use [logrotate](https://www.jianshu.com/p/ec7f1626a3d3) to manage log files.
1. Install logrotate:
```
sudo yum install -y logrotate
```
1. Config logrotate to manage SRS log file:
```
cat << END > /etc/logrotate.d/srs
/usr/local/srs/objs/srs.log {
daily
dateext
compress
rotate 7
size 1024M
sharedscripts
postrotate
kill -USR1 \`cat /usr/local/srs/objs/srs.pid\`
endscript
}
END
```
> Note: Run logrotate manually by `logrotate -f /etc/logrotate.d/srs`
## CopyTruncate
For SRS2, we could use [copytruncate](https://unix.stackexchange.com/questions/475524/how-copytruncate-actually-works),
**but it's strongly not recommended** because the logs maybe dropped, so it's only a workaround for server not supported
SIGUSR1 such as SRS2.
> Yes, SRS3 surely supports copytruncate and it's not recommended.
The config is bellow, from [PR#1561](https://github.com/ossrs/srs/pull/1561#issuecomment-571408173) by [wnpllrzodiac](https://github.com/wnpllrzodiac):
```
cat << END > /etc/logrotate.d/srs
/usr/local/srs/objs/srs.log {
daily
dateext
compress
rotate 7
size 1024M
copytruncate
}
END
```
Winlin 2016.12
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/log-rotate)

525
trunk/3rdparty/srs-docs/doc/log.md vendored Normal file
View File

@ -0,0 +1,525 @@
---
title: Log
sidebar_label: Log
hide_title: false
hide_table_of_contents: false
---
# SRS Log System
SRS can log to console or file, with level, session oriented log and tracable log.
## LogTank
The tank is the container for log, to where write log:
There are two tank of SRS log, config the `srs_log_tank` to:
* console: Write log to console. Before config parsed, write log to console too.
* file: Default. Write log to file, and the `srs_log_file` specified the path of log file, which default to `./objs/srs.log`
The log specified config:
```bash
# the log tank, console or file.
# if console, print log to console.
# if file, write log to file. requires srs_log_file if log to file.
# default: file.
srs_log_tank file;
```
## LogLevel
The level is specified by `srs_log_level_v2` and control which level of log to print:
* trace: Lots of log, which hurts performance. SRS default to disable it when compile.
* debug：Detail log, which huts performance. SRS default to disable it when compile.
* info: Important log, less and SRS enable it as default level.
* warn: Warning log, without debug log.
* error: Error level.
The level in config file:
```bash
# The log level for logging to console or file. It can be:
# verbose, info, trace, warn, error
# If configure --log-level_v2=off, use SRS 4.0 level specs which is v1, the level text is:
# Verb, Info, Trace, Warn, Error
# If configure --log-level_v2=on, use SRS 5.0 level specs which is v2, the level text is:
# TRACE, DEBUG, INFO, WARN, ERROR
# Note: Do not support reloading, for SRS5+
# Overwrite by env SRS_LOG_LEVEL or SRS_SRS_LOG_LEVEL
# default: trace
srs_log_level trace;
# The log level v2, rewrite the config srs_log_level if not empty, it can be:
# trace, debug, info, warn, error
# If configure --log-level_v2=off, use SRS 4.0 level specs which is v1, the level text is:
# Verb, Info, Trace, Warn, Error
# If configure --log-level_v2=on, use SRS 5.0 level specs which is v2, the level text is:
# TRACE, DEBUG, INFO, WARN, ERROR
# Overwrite by env SRS_LOG_LEVEL_V2 or SRS_SRS_LOG_LEVEL_V2
srs_log_level_v2 info;
```
> Note: For SRS 5.0+, the `--log-level_v2` is default to `on`, which means we use the new log level by default.
Notes:
* Enable all high level, for example, enable trace/warn/error when set level to trace.
* The trace and debug level is disabled when compile. Modify the `srs_kernel_log.hpp` when need to enable this.
* Recomment to use `info` level.
## Log of tools
The feature Transcode/Ingest use external tools, for instance, FFMPEG. SRS use isolate log file for the external tools.
Set the tools log to `/dev/null` to disable the log:
```bash
# the logs dir.
# if enabled ffmpeg, each stracoding stream will create a log file.
# "/dev/null" to disable the log.
# default: ./objs
ff_log_dir ./objs;
```
## Log Format
SRS provides session oriented log, to enalbe us to grep specified connection log:
```bash
[2014-04-04 11:21:29.183][trace][2837][104][11] rtmp get peer ip success. ip=192.168.1.179
```
The log format is:
* <strong>[2014-04-04 11:21:29.183]</strong> Date of log. The ms is set by the time cache of SRS_TIME_RESOLUTION_MS to avoid performance issue.
* <strong>[trace]</strong> Level of log. Trace is ok, warn and error maybe something is wrong.
* <strong>[2837]</strong> The pid of process(SrsPid). The session id maybe duplicated for multiple process.
* <strong>[104]</strong> The session id(SrsId), unique for the same process. So the pid+session-id is used to identify a connection.
* <strong>[11]</strong> The errno of system, optional for warn and error.
* <strong>rtmp get peer ip success.</strong> The description of log.
The following descript how to analysis the log of SRS.
### Tracable Log
SRS can get the whole log when we got something, for example, the ip of client, or the stream for client and time to play, the page url.
Event for the cluster, SRS can find the session oriented directly. We can get the session of server, and the source id for the session, and the upnode session log util the origin server and the publish id.
The client also can get the pid and session-id of the connection on server. For example:
A client play stream: rtmp://dev:1935/live/livestream
![All id for client](/img/doc-guides-log-001.png)
We can get the server ip `192.168.1.107`, the pid `9131` and session id `117`. We can grep on this server directly by keyword "\[9131\]\[117\]":
```bash
[winlin@dev6 srs]$ grep -ina "\[12665\]\[114\]" objs/edge.log
1307:[2014-05-27 19:21:27.276][trace][12665][114] serve client, peer ip=192.168.1.113
1308:[2014-05-27 19:21:27.284][trace][12665][114] complex handshake with client success
1309:[2014-05-27 19:21:27.284][trace][12665][114] rtmp connect app success. tcUrl=rtmp://dev:1935/live, pageUrl=http://ossrs.net/players/srs_player.html?vhost=dev&stream=livestream&server=dev&port=1935, swfUrl=http://ossrs.net/players/srs_player/release/srs_player.swf?_version=1.21, schema=rtmp, vhost=__defaultVhost__, port=1935, app=live
1310:[2014-05-27 19:21:27.486][trace][12665][114] set ack window size to 2500000
1311:[2014-05-27 19:21:27.486][trace][12665][114] identify ignore messages except AMF0/AMF3 command message. type=0x5
1312:[2014-05-27 19:21:27.501][trace][12665][114] ignored. set buffer length to 800
1313:[2014-05-27 19:21:27.501][trace][12665][114] identify ignore messages except AMF0/AMF3 command message. type=0x4
1314:[2014-05-27 19:21:27.518][trace][12665][114] identity client type=play, stream_name=livestream, duration=-1.00
1315:[2014-05-27 19:21:27.518][trace][12665][114] identify client success. type=Play, stream_name=livestream, duration=-1.00
1316:[2014-05-27 19:21:27.518][trace][12665][114] set output chunk size to 4096
1317:[2014-05-27 19:21:27.518][trace][12665][114] source url=__defaultVhost__/live/livestream, ip=192.168.1.113, cache=1, is_edge=1, id=-1
1318:[2014-05-27 19:21:27.518][trace][12665][114] dispatch cached gop success. count=0, duration=0
1319:[2014-05-27 19:21:27.518][trace][12665][114] create consumer, queue_size=30.00, tba=0, tbv=0
1322:[2014-05-27 19:21:27.518][trace][12665][114] ignored. set buffer length to 800
1333:[2014-05-27 19:21:27.718][trace][12665][114] update source_id=115
1334:[2014-05-27 19:21:27.922][trace][12665][114] -> PLA time=301, msgs=12, okbps=1072,0,0, ikbps=48,0,0
```
While the source id is 115(`source_id=115`), then find this session:
```
[winlin@dev6 srs]$ grep -ina "\[12665\]\[115\]" objs/edge.log
1320:[2014-05-27 19:21:27.518][trace][12665][115] edge connected, can_publish=1, url=rtmp://dev:1935/live/livestream, server=127.0.0.1:19350
1321:[2014-05-27 19:21:27.518][trace][12665][115] connect to server success. server=127.0.0.1, ip=127.0.0.1, port=19350
1323:[2014-05-27 19:21:27.519][trace][12665][115] complex handshake with server success.
1324:[2014-05-27 19:21:27.561][trace][12665][115] set ack window size to 2500000
1325:[2014-05-27 19:21:27.602][trace][12665][115] drop unknown message, type=6
1326:[2014-05-27 19:21:27.602][trace][12665][115] connected, version=0.9.119, ip=127.0.0.1, pid=12633, id=141
1327:[2014-05-27 19:21:27.602][trace][12665][115] set output chunk size to 60000
1328:[2014-05-27 19:21:27.602][trace][12665][115] edge change from 100 to state 101 (ingest connected).
1329:[2014-05-27 19:21:27.603][trace][12665][115] set input chunk size to 60000
1330:[2014-05-27 19:21:27.603][trace][12665][115] dispatch metadata success.
1331:[2014-05-27 19:21:27.603][trace][12665][115] update video sequence header success. size=46
1332:[2014-05-27 19:21:27.603][trace][12665][115] update audio sequence header success. size=4
1335:[2014-05-27 19:21:37.653][trace][12665][115] <- EIG time=10163, okbps=0,0,0, ikbps=234,254,231
```
We can finger out the upnode server session info `connected, version=0.9.119, ip=127.0.0.1, pid=12633, id=141`, then to grep on the upnode server:
```
[winlin@dev6 srs]$ grep -ina "\[12633\]\[141\]" objs/srs.log
783:[2014-05-27 19:21:27.518][trace][12633][141] serve client, peer ip=127.0.0.1
784:[2014-05-27 19:21:27.519][trace][12633][141] complex handshake with client success
785:[2014-05-27 19:21:27.561][trace][12633][141] rtmp connect app success. tcUrl=rtmp://dev:1935/live, pageUrl=, swfUrl=, schema=rtmp, vhost=__defaultVhost__, port=1935, app=live
786:[2014-05-27 19:21:27.561][trace][12633][141] set ack window size to 2500000
787:[2014-05-27 19:21:27.561][trace][12633][141] identify ignore messages except AMF0/AMF3 command message. type=0x5
788:[2014-05-27 19:21:27.602][trace][12633][141] identity client type=play, stream_name=livestream, duration=-1.00
789:[2014-05-27 19:21:27.602][trace][12633][141] identify client success. type=Play, stream_name=livestream, duration=-1.00
790:[2014-05-27 19:21:27.602][trace][12633][141] set output chunk size to 60000
791:[2014-05-27 19:21:27.602][trace][12633][141] source url=__defaultVhost__/live/livestream, ip=127.0.0.1, cache=1, is_edge=0, id=131
792:[2014-05-27 19:21:27.602][trace][12633][141] dispatch cached gop success. count=241, duration=3638
793:[2014-05-27 19:21:27.602][trace][12633][141] create consumer, queue_size=30.00, tba=44100, tbv=1000
794:[2014-05-27 19:21:27.602][trace][12633][141] ignored. set buffer length to 65564526
795:[2014-05-27 19:21:27.604][trace][12633][141] set input chunk size to 60000
798:[2014-05-27 19:21:32.420][trace][12633][141] -> PLA time=4809, msgs=14, okbps=307,0,0, ikbps=5,0,0
848:[2014-05-27 19:22:54.414][trace][12633][141] -> PLA time=86703, msgs=12, okbps=262,262,0, ikbps=0,0,0
867:[2014-05-27 19:22:57.225][trace][12633][141] update source_id=149
```
And the source id 149(`source_id=149`), that is the session id of encoder:
```
[winlin@dev6 srs]$ grep -ina "\[12633\]\[149\]" objs/srs.log
857:[2014-05-27 19:22:56.919][trace][12633][149] serve client, peer ip=127.0.0.1
858:[2014-05-27 19:22:56.921][trace][12633][149] complex handshake with client success
859:[2014-05-27 19:22:56.960][trace][12633][149] rtmp connect app success. tcUrl=rtmp://127.0.0.1:19350/live?vhost=__defaultVhost__, pageUrl=, swfUrl=, schema=rtmp, vhost=__defaultVhost__, port=19350, app=live
860:[2014-05-27 19:22:57.040][trace][12633][149] identify client success. type=publish(FMLEPublish), stream_name=livestream, duration=-1.00
861:[2014-05-27 19:22:57.040][trace][12633][149] set output chunk size to 60000
862:[2014-05-27 19:22:57.040][trace][12633][149] source url=__defaultVhost__/live/livestream, ip=127.0.0.1, cache=1, is_edge=0, id=-1
863:[2014-05-27 19:22:57.123][trace][12633][149] set input chunk size to 60000
864:[2014-05-27 19:22:57.210][trace][12633][149] dispatch metadata success.
865:[2014-05-27 19:22:57.210][trace][12633][149] update video sequence header success. size=46
866:[2014-05-27 19:22:57.210][trace][12633][149] update audio sequence header success. size=4
870:[2014-05-27 19:23:04.970][trace][12633][149] <- CPB time=8117, okbps=4,0,0, ikbps=320,0,0
```
Encoder => Origin => Edge => Player, the whole link log we got directly!
### Reverse Tracable Log
The tracable is finger log from the player to the origin. The reverse tracable log is from the origin to the edge and player.
For example, there is a origin and a edge, to grep the log on origin by keyword `edge-srs`:
```
[winlin@dev6 srs]$ grep -ina "edge-srs" objs/srs.origin.log
30:[2014-08-06 09:41:31.649][trace][21433][107] edge-srs ip=192.168.1.159, version=0.9.189, pid=21435, id=108
```
We get all edge srs which connectted to this origin, this edge ip is 192.168.1.159, pid is 21435, session id is 108. Then grep the log on the edge:
```
[winlin@dev6 srs]$ grep --color -ina "\[108\]" objs/srs.log
29:[2014-08-06 10:09:34.579][trace][22314][108] edge pull connected, can_publish=1, url=rtmp://dev:1935/live/livestream, server=127.0.0.1:1936
30:[2014-08-06 10:09:34.591][trace][22314][108] complex handshake success.
31:[2014-08-06 10:09:34.671][trace][22314][108] connected, version=0.9.190, ip=127.0.0.1, pid=22288, id=107
32:[2014-08-06 10:09:34.672][trace][22314][108] out chunk size to 60000
33:[2014-08-06 10:09:34.672][trace][22314][108] ignore the disabled transcode:
34:[2014-08-06 10:09:34.672][trace][22314][108] edge change from 100 to state 101 (pull).
35:[2014-08-06 10:09:34.672][trace][22314][108] input chunk size to 60000
36:[2014-08-06 10:09:34.672][trace][22314][108] got metadata, width=768, height=320, vcodec=7, acodec=10
37:[2014-08-06 10:09:34.672][trace][22314][108] 46B video sh, codec(7, profile=100, level=32, 0x0, 0kbps, 0fps, 0s)
38:[2014-08-06 10:09:34.672][trace][22314][108] 4B audio sh, codec(10, profile=1, 2channels, 0kbps, 44100HZ), flv(16bits, 2channels, 44100HZ)
39:[2014-08-06 10:09:34.779][trace][22314][107] update source_id=108[108]
46:[2014-08-06 10:09:36.853][trace][22314][110] source url=__defaultVhost__/live/livestream, ip=192.168.1.179, cache=1, is_edge=1, source_id=108[108]
50:[2014-08-06 10:09:44.949][trace][22314][108] <- EIG time=10293, okbps=3,0,0, ikbps=441,0,0
53:[2014-08-06 10:09:47.805][warn][22314][108][4] origin disconnected, retry. ret=1007
```
On this edge, we finger out there is 2 connections which connected on the source, by keyword `source_id=108`:
```
39:[2014-08-06 10:09:34.779][trace][22314][107] update source_id=108[108]
46:[2014-08-06 10:09:36.853][trace][22314][110] source url=__defaultVhost__/live/livestream, ip=192.168.1.179, cache=1, is_edge=1, source_id=108[108]
```
There are 2 connections connected on this source, 107 and 110.
### Any Tracable Log
For SRS support tracalbe and reverse tracable log, so we can got the whold stream delivery log at any point.
For example, a cluster has a origin and an edge, origin ingest stream.
When I know the stream name, or any information, for example, we can grep the keyword `type=Play` for all client to play stream on origin server:
```
[winlin@dev6 srs]$ grep -ina "type=Play" objs/srs.origin.log
31:[2014-08-06 10:09:34.671][trace][22288][107] client identified, type=Play, stream_name=livestream, duration=-1.00
```
We got session id 107 which play the stream on origin:
```
[winlin@dev6 srs]$ grep -ina "\[107\]" objs/srs.origin.log
27:[2014-08-06 10:09:34.589][trace][22288][107] RTMP client ip=127.0.0.1
28:[2014-08-06 10:09:34.591][trace][22288][107] complex handshake success
29:[2014-08-06 10:09:34.631][trace][22288][107] connect app, tcUrl=rtmp://dev:1935/live, pageUrl=http://www.ossrs.net/players/srs_player.html?vhost=dev&stream=livestream&server=dev&port=1935, swfUrl=http://www.ossrs.net/players/srs_player/release/srs_player.swf?_version=1.23, schema=rtmp, vhost=__defaultVhost__, port=1935, app=live, args=(obj)
30:[2014-08-06 10:09:34.631][trace][22288][107] edge-srs ip=192.168.1.159, version=0.9.190, pid=22314, id=108
31:[2014-08-06 10:09:34.671][trace][22288][107] client identified, type=Play, stream_name=livestream, duration=-1.00
32:[2014-08-06 10:09:34.671][trace][22288][107] out chunk size to 60000
33:[2014-08-06 10:09:34.671][trace][22288][107] source url=__defaultVhost__/live/livestream, ip=127.0.0.1, cache=1, is_edge=0, source_id=105[105]
34:[2014-08-06 10:09:34.672][trace][22288][107] dispatch cached gop success. count=307, duration=4515
35:[2014-08-06 10:09:34.672][trace][22288][107] create consumer, queue_size=30.00, tba=44100, tbv=25
36:[2014-08-06 10:09:34.672][trace][22288][107] ignored. set buffer length to 1000
37:[2014-08-06 10:09:34.673][trace][22288][107] input chunk size to 60000
40:[2014-08-06 10:09:44.748][trace][22288][107] -> PLA time=10007, msgs=0, okbps=464,0,0, ikbps=3,0,0
41:[2014-08-06 10:09:47.805][warn][22288][107][104] client disconnect peer. ret=1004
```
The soruce id is 105, specified by `source_id=105`:
```
[winlin@dev6 srs]$ grep --color -ina "\[105\]" objs/srs.origin.log
16:[2014-08-06 10:09:30.331][trace][22288][105] RTMP client ip=127.0.0.1
17:[2014-08-06 10:09:30.331][trace][22288][105] srand initialized the random.
18:[2014-08-06 10:09:30.332][trace][22288][105] simple handshake success.
19:[2014-08-06 10:09:30.373][trace][22288][105] connect app, tcUrl=rtmp://127.0.0.1:1936/live?vhost=__defaultVhost__, pageUrl=, swfUrl=, schema=rtmp, vhost=__defaultVhost__, port=1936, app=live, args=null
21:[2014-08-06 10:09:30.417][trace][22288][105] client identified, type=publish(FMLEPublish), stream_name=livestream, duration=-1.00
22:[2014-08-06 10:09:30.417][trace][22288][105] out chunk size to 60000
23:[2014-08-06 10:09:30.418][trace][22288][105] source url=__defaultVhost__/live/livestream, ip=127.0.0.1, cache=1, is_edge=0, source_id=-1[-1]
24:[2014-08-06 10:09:30.466][trace][22288][105] got metadata, width=768, height=320, vcodec=7, acodec=10
25:[2014-08-06 10:09:30.466][trace][22288][105] 46B video sh, codec(7, profile=100, level=32, 0x0, 0kbps, 0fps, 0s)
26:[2014-08-06 10:09:30.466][trace][22288][105] 4B audio sh, codec(10, profile=1, 2channels, 0kbps, 44100HZ), flv(16bits, 2channels, 44100HZ)
33:[2014-08-06 10:09:34.671][trace][22288][107] source url=__defaultVhost__/live/livestream, ip=127.0.0.1, cache=1, is_edge=0, source_id=105[105]
38:[2014-08-06 10:09:40.732][trace][22288][105] <- CPB time=10100, okbps=3,0,0, ikbps=332,0,0
```
This source is the ingest stream source, we got the root source.
And we got 107 which is srs edge connection, by keyword `edge-srs`:
```
30:[2014-08-06 10:09:34.631][trace][22288][107] edge-srs ip=192.168.1.159, version=0.9.190, pid=22314, id=108
```
Find the log on edge, the session id is 108:
```
[winlin@dev6 srs]$ grep --color -ina "\[108\]" objs/srs.log
29:[2014-08-06 10:09:34.579][trace][22314][108] edge pull connected, can_publish=1, url=rtmp://dev:1935/live/livestream, server=127.0.0.1:1936
30:[2014-08-06 10:09:34.591][trace][22314][108] complex handshake success.
31:[2014-08-06 10:09:34.671][trace][22314][108] connected, version=0.9.190, ip=127.0.0.1, pid=22288, id=107
32:[2014-08-06 10:09:34.672][trace][22314][108] out chunk size to 60000
33:[2014-08-06 10:09:34.672][trace][22314][108] ignore the disabled transcode:
34:[2014-08-06 10:09:34.672][trace][22314][108] edge change from 100 to state 101 (pull).
35:[2014-08-06 10:09:34.672][trace][22314][108] input chunk size to 60000
36:[2014-08-06 10:09:34.672][trace][22314][108] got metadata, width=768, height=320, vcodec=7, acodec=10
37:[2014-08-06 10:09:34.672][trace][22314][108] 46B video sh, codec(7, profile=100, level=32, 0x0, 0kbps, 0fps, 0s)
38:[2014-08-06 10:09:34.672][trace][22314][108] 4B audio sh, codec(10, profile=1, 2channels, 0kbps, 44100HZ), flv(16bits, 2channels, 44100HZ)
39:[2014-08-06 10:09:34.779][trace][22314][107] update source_id=108[108]
46:[2014-08-06 10:09:36.853][trace][22314][110] source url=__defaultVhost__/live/livestream, ip=192.168.1.179, cache=1, is_edge=1, source_id=108[108]
50:[2014-08-06 10:09:44.949][trace][22314][108] <- EIG time=10293, okbps=3,0,0, ikbps=441,0,0
53:[2014-08-06 10:09:47.805][warn][22314][108][4] origin disconnected, retry. ret=1007
```
We got the edge source 108, and there are 2 clients connected on this source 107 and 110, specified by keyword `source_id=108`:
```
[winlin@dev6 srs]$ grep --color -ina "\[107\]" objs/srs.log
18:[2014-08-06 10:09:34.281][trace][22314][107] RTMP client ip=192.168.1.179
19:[2014-08-06 10:09:34.282][trace][22314][107] srand initialized the random.
20:[2014-08-06 10:09:34.291][trace][22314][107] complex handshake success
21:[2014-08-06 10:09:34.291][trace][22314][107] connect app, tcUrl=rtmp://dev:1935/live, pageUrl=http://www.ossrs.net/players/srs_player.html?vhost=dev&stream=livestream&server=dev&port=1935, swfUrl=http://www.ossrs.net/players/srs_player/release/srs_player.swf?_version=1.23, schema=rtmp, vhost=__defaultVhost__, port=1935, app=live, args=null
22:[2014-08-06 10:09:34.532][trace][22314][107] ignored. set buffer length to 800
23:[2014-08-06 10:09:34.568][trace][22314][107] client identified, type=Play, stream_name=livestream, duration=-1.00
24:[2014-08-06 10:09:34.568][trace][22314][107] out chunk size to 60000
25:[2014-08-06 10:09:34.568][trace][22314][107] source url=__defaultVhost__/live/livestream, ip=192.168.1.179, cache=1, is_edge=1, source_id=-1[-1]
26:[2014-08-06 10:09:34.579][trace][22314][107] dispatch cached gop success. count=0, duration=0
27:[2014-08-06 10:09:34.579][trace][22314][107] create consumer, queue_size=30.00, tba=0, tbv=0
28:[2014-08-06 10:09:34.579][trace][22314][107] ignored. set buffer length to 800
39:[2014-08-06 10:09:34.779][trace][22314][107] update source_id=108[108]
54:[2014-08-06 10:09:47.805][trace][22314][107] cleanup when unpublish
55:[2014-08-06 10:09:47.805][trace][22314][107] edge change from 101 to state 0 (init).
56:[2014-08-06 10:09:47.805][warn][22314][107][9] client disconnect peer. ret=1004
```
The 107 is a client which trigger the edge to fetch stream from origin. Find 110:
```
[winlin@dev6 srs]$ grep --color -ina "\[110\]" objs/srs.log
40:[2014-08-06 10:09:36.609][trace][22314][110] RTMP client ip=192.168.1.179
41:[2014-08-06 10:09:36.613][trace][22314][110] complex handshake success
42:[2014-08-06 10:09:36.613][trace][22314][110] connect app, tcUrl=rtmp://dev:1935/live, pageUrl=http://www.ossrs.net/players/srs_player.html?vhost=dev&stream=livestream&server=dev&port=1935, swfUrl=http://www.ossrs.net/players/srs_player/release/srs_player.swf?_version=1.23, schema=rtmp, vhost=__defaultVhost__, port=1935, app=live, args=null
43:[2014-08-06 10:09:36.835][trace][22314][110] ignored. set buffer length to 800
44:[2014-08-06 10:09:36.853][trace][22314][110] client identified, type=Play, stream_name=livestream, duration=-1.00
45:[2014-08-06 10:09:36.853][trace][22314][110] out chunk size to 60000
46:[2014-08-06 10:09:36.853][trace][22314][110] source url=__defaultVhost__/live/livestream, ip=192.168.1.179, cache=1, is_edge=1, source_id=108[108]
47:[2014-08-06 10:09:36.853][trace][22314][110] dispatch cached gop success. count=95, duration=1573
48:[2014-08-06 10:09:36.853][trace][22314][110] create consumer, queue_size=30.00, tba=44100, tbv=25
49:[2014-08-06 10:09:36.853][trace][22314][110] ignored. set buffer length to 800
51:[2014-08-06 10:09:45.919][trace][22314][110] -> PLA time=8759, msgs=21, okbps=461,0,0, ikbps=3,0,0
52:[2014-08-06 10:09:46.247][warn][22314][110][104] client disconnect peer. ret=1004
```
The 110 is a flash player client.
### System info
The system info and port listen at:
```bash
[winlin@dev6 srs]$ ./objs/srs -c console.conf
[winlin@dev6 srs]$ cat objs/srs.log
[2014-04-04 11:39:24.176][trace][0][0] config parsed EOF
[2014-04-04 11:39:24.176][trace][0][0] log file is ./objs/srs.log
[2014-04-04 11:39:24.177][trace][0][0] srs 0.9.46
[2014-04-04 11:39:24.177][trace][0][0] uname: Linux dev6 2.6.32-71.el6.x86_64
#1 SMP Fri May 20 03:51:51 BST 2011 x86_64 x86_64 x86_64 GNU/Linux
[2014-04-04 11:39:24.177][trace][0][0] build: 2014-04-03 18:38:23, little-endian
[2014-04-04 11:39:24.177][trace][0][0] configure: --dev --with-hls --with-nginx
--with-ssl --with-ffmpeg --with-http-callback --with-http-server --with-http-api
--with-librtmp --with-bwtc --with-research --with-utest --without-gperf --without-gmc
--without-gmp --without-gcp --without-gprof --without-arm-ubuntu12 --jobs=1
--prefix=/usr/local/srs
[2014-04-04 11:39:24.177][trace][0][0] write pid=4021 to ./objs/srs.pid success!
[2014-04-04 11:39:24.177][trace][100][16] server started, listen at port=1935, type=0, fd=6
[2014-04-04 11:39:24.177][trace][100][16] server started, listen at port=1985, type=1, fd=7
[2014-04-04 11:39:24.177][trace][100][16] server started, listen at port=8080, type=2, fd=8
[2014-04-04 11:39:24.177][trace][101][16] listen cycle start, port=1935, type=0, fd=6
[2014-04-04 11:39:24.177][trace][102][11] listen cycle start, port=1985, type=1, fd=7
[2014-04-04 11:39:24.177][trace][103][11] listen cycle start, port=8080, type=2, fd=8
[2014-04-04 11:39:26.799][trace][0][11] get a signal, signo=2
[2014-04-04 11:39:26.799][trace][0][11] user terminate program
```
It means:
* <strong>The log file path</strong>：[2014-04-04 11:39:24.176][trace][0][0] log file is ./objs/srs.log
* <strong>SRS version</strong>：[2014-04-04 11:39:24.177][trace][0][0] srs 0.9.46
* <strong>Compile info</strong>：[2014-04-04 11:39:24.177][trace][0][0] uname: Linux dev6 2.6.32-71.el6.x86_64
#1 SMP Fri May 20 03:51:51 BST 2011 x86_64 x86_64 x86_64 GNU/Linux
* <strong>Compile date</strong>：[2014-04-04 11:39:24.177][trace][0][0] build: 2014-04-03 18:38:23, little-endian
* <strong>Build options</strong>：[2014-04-04 11:39:24.177][trace][0][0] configure: --dev --with-hls --with-nginx
--with-ssl --with-ffmpeg --with-http-callback --with-http-server --with-http-api --with-librtmp
--with-bwtc --with-research --with-utest --without-gperf --without-gmc --without-gmp
--without-gcp --without-gprof --without-arm-ubuntu12 --jobs=1 --prefix=/usr/local/srs
* <strong>PID file</strong>：[2014-04-04 11:39:24.177][trace][0][0] write pid=4021 to ./objs/srs.pid success!
* <strong>Listen at port 1935（RTMP）</strong>：[2014-04-04 11:39:24.177][trace][100][16] server started, listen at port=1935, type=0, fd=6
* <strong>Listen at port 1985（HTTP接口）</strong>：[2014-04-04 11:39:24.177][trace][100][16] server started, listen at port=1985, type=1, fd=7
* <strong>Listen at port 8080（HTTP服务）</strong>：[2014-04-04 11:39:24.177][trace][100][16] server started, listen at port=8080, type=2, fd=8
* <strong>Ready for connections</strong>：[2014-04-04 11:39:24.177][trace][101][16] listen cycle start, port=1935, type=0, fd=6
### Session oriented log
SRS provides session oriented log.
For example, SRS running for 365 days, served 10000000 clients, how to find a specified client log?
We need something to grep, for instance, we know the stream url: `rtmp://192.168.1.107:1935/live/livestream`, then we can find the keyword to grep by research the publish log:
```bash
[2014-04-04 11:56:06.074][trace][104][11] rtmp get peer ip success. ip=192.168.1.179,
send_to=30000000us, recv_to=30000000us
[2014-04-04 11:56:06.080][trace][104][11] srand initialized the random.
[2014-04-04 11:56:06.082][trace][104][11] simple handshake with client success.
[2014-04-04 11:56:06.083][trace][104][11] rtmp connect app success.
tcUrl=rtmp://192.168.1.107:1935/live, pageUrl=, swfUrl=rtmp://192.168.1.107:1935/live,
schema=rtmp, vhost=__defaultVhost__, port=1935, app=live
[2014-04-04 11:56:06.288][trace][104][11] set ack window size to 2500000
[2014-04-04 11:56:06.288][trace][104][11] identify ignore messages except AMF0/AMF3
command message. type=0x5
[2014-04-04 11:56:06.288][trace][104][11] identify client success.
type=publish(FMLEPublish), stream_name=livestream
```
The keyword to grep:
* Use keyword `identify client success`, then `type=publish`, then `livestream`.
* Or, use keyword `identify client success. type=publish`, then `livestream`.
* We can grep all `identify client success. type=publish`, and research the result.
For example:
```bash
[winlin@dev6 srs]$ cat objs/srs.log|grep -ina "identify client success. type=publish"
20:[2014-04-04 11:56:06.288][trace][104][11] identify client success. type=publish, stream_name=livestream
43:[2014-04-04 11:56:18.138][trace][105][11] identify client success. type=publish, stream_name=winlin
65:[2014-04-04 11:56:29.531][trace][106][11] identify client success. type=publish, stream_name=livestream
86:[2014-04-04 11:56:35.966][trace][107][11] identify client success. type=publish, stream_name=livestream
```
There are some publish stream, and we can grep specified streamname.
```bash
[winlin@dev6 srs]$ cat objs/srs.log|grep -ina "identify client success. type=publish"|grep -a "livestream"
20:[2014-04-04 11:56:06.288][trace][104][11] identify client success. type=publish, stream_name=livestream
65:[2014-04-04 11:56:29.531][trace][106][11] identify client success. type=publish, stream_name=livestream
86:[2014-04-04 11:56:35.966][trace][107][11] identify client success. type=publish, stream_name=livestream
```
We can filter the result by time, for example, we use session id 104 to grep by keyword `\[104\]\[`:
```bash
[winlin@dev6 srs]$ cat objs/srs.log |grep -ina "\[104\]\["
14:[2014-04-04 11:56:06.074][trace][104][11] rtmp get peer ip success. ip=192.168.1.179,
send_to=30000000us, recv_to=30000000us
15:[2014-04-04 11:56:06.080][trace][104][11] srand initialized the random.
16:[2014-04-04 11:56:06.082][trace][104][11] simple handshake with client success.
17:[2014-04-04 11:56:06.083][trace][104][11] rtmp connect app success.
tcUrl=rtmp://192.168.1.107:1935/live, pageUrl=, swfUrl=rtmp://192.168.1.107:1935/live,
schema=rtmp, vhost=__defaultVhost__, port=1935, app=live
18:[2014-04-04 11:56:06.288][trace][104][11] set ack window size to 2500000
19:[2014-04-04 11:56:06.288][trace][104][11] identify ignore messages except AMF0/AMF3
command message. type=0x5
20:[2014-04-04 11:56:06.288][trace][104][11] identify client success.
type=publish(FMLEPublish), stream_name=livestream
21:[2014-04-04 11:56:06.288][trace][104][11] set output chunk size to 60000
22:[2014-04-04 11:56:06.288][trace][104][11] set chunk_size=60000 success
23:[2014-04-04 11:56:07.397][trace][104][11] <- time=225273, obytes=4168, ibytes=7607, okbps=32, ikbps=59
24:[2014-04-04 11:56:07.398][trace][104][11] dispatch metadata success.
25:[2014-04-04 11:56:07.398][trace][104][11] process onMetaData message success.
26:[2014-04-04 11:56:07.398][trace][104][11] update video sequence header success. size=67
27:[2014-04-04 11:56:08.704][trace][104][11] <- time=226471, obytes=4168, ibytes=36842, okbps=13, ikbps=116
28:[2014-04-04 11:56:09.901][trace][104][11] <- time=227671, obytes=4168, ibytes=67166, okbps=9, ikbps=152
29:[2014-04-04 11:56:11.102][trace][104][11] <- time=228869, obytes=4168, ibytes=97481, okbps=6, ikbps=155
30:[2014-04-04 11:56:11.219][trace][104][11] clear cache/metadata/sequence-headers when unpublish.
31:[2014-04-04 11:56:11.219][trace][104][11] control message(unpublish) accept, retry stream service.
32:[2014-04-04 11:56:11.219][trace][104][11] ignore AMF0/AMF3 command message.
33:[2014-04-04 11:56:11.419][trace][104][11] drop the AMF0/AMF3 command message, command_name=deleteStream
34:[2014-04-04 11:56:11.420][trace][104][11] ignore AMF0/AMF3 command message.
35:[2014-04-04 11:56:12.620][error][104][104] recv client message failed. ret=207(Connection reset by peer)
36:[2014-04-04 11:56:12.620][error][104][104] identify client failed. ret=207(Connection reset by peer)
37:[2014-04-04 11:56:12.620][warn][104][104] client disconnect peer. ret=204
[winlin@dev6 srs]$
```
Then we got the log for this session, and client closed connection by log: `36:[2014-04-04 11:56:12.620][error][104][104] identify client failed. ret=207(Connection reset by peer)`.
## Daemon
When default SRS only print less log? Because SRS default use `conf/srs.conf` in daemon mode and print to log file.
When enable daemon, then no need to start by nohup:
```bash
# whether start as deamon
# default: on
daemon on;
```
Use `conf/console.conf` to not start in daemon and log to conosle.
```bash
# no-daemon and write log to console config for srs.
# @see full.conf for detail config.
listen 1935;
daemon off;
srs_log_tank console;
vhost __defaultVhost__ {
}
```
Startup command:
```bash
./objs/srs -c conf/console.conf
```
To startup with default config `conf/srs.conf`:
```bash
[winlin@dev6 srs]$ ./objs/srs -c conf/srs.conf
[2014-04-14 12:12:57.775][trace][0][0] config parse complete
[2014-04-14 12:12:57.775][trace][0][0] write log to file ./objs/srs.log
[2014-04-14 12:12:57.775][trace][0][0] you can: tailf ./objs/srs.log
[2014-04-14 12:12:57.775][trace][0][0] @see https://ossrs.io/lts/en-us/docs/v4/doc/log
```
Winlin 2014.10
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/log)

222
trunk/3rdparty/srs-docs/doc/low-latency.md vendored Normal file
View File

@ -0,0 +1,222 @@
---
title: Low Latency
sidebar_label: Low Latency
hide_title: false
hide_table_of_contents: false
---
# Low Latency Live Stream
The RTMP and HLS can cover all requires for internet live stream,
read [DeliveryHLS](./hls.md),
while RTMP is designed for low latency live stream.
The deploy for low latency, read [Usage: Realtime](./sample-realtime.md)
## Use Scenario
The low latency use scenario:
* Live show.
* Video meeting.
* Other, for example, monitor, education.
## Latency
RTMP is design for low latency:
* Adobe flash player is good at play RTMP stream.
* RTMP is stable enough for longtime publish and play on PC.
* Low latency, about 0.8-3s.
* For RTMP is base on TCP, the latency maybe very large for network issue.
## HLS LowLatency
HLS has a bigger delay than RTMP, usually more than 5 seconds. If not set up properly, it can be over 15 seconds.
If you want to reduce the HLS delay, please check out [HLS LowLatency](./hls.md#hls-low-latency).
## Benchmark
We use the clock of mobile phone to test the latency,
read [RTMP latency benchmark](http://blog.csdn.net/win_lin/article/details/12615591)
When netowork is ok:
* RTMP can ensure 0.8-3s latency.
* The RTMP cluster add 0.3s latency for each level.
* The latency of nginx-rtmp is larger than SRS, maybe the cache or multiple process issue.
* The gop cache always make the latency larger, but SRS can disable the gop cache.
* The bufferTime of flash client should set to small, see NetStream.bufferTime.
## Min-Latency
When min-latency is enabled, SRS will diable the mr(merged-read) and use timeout cond wait, to send about 1-2 video packets when got it.
We can got 0.1s latency for vp6 video only stream, read [#257](https://github.com/ossrs/srs/issues/257#issuecomment-66773208). The config:
```
vhost mrw.srs.com {
# whether enable min delay mode for vhost.
# for min latence 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
min_latency off;
}
```
For example to deploy realtime stream, read [wiki]([EN](./sample-realtime.md), [CN](./sample-realtime.md)).
## Merged-Read
The perfromance of RTMP read is very low, because we must read 1byte chunk type, then chunk header, finally payload. So SRS 1.0 only supports 1000 publisher, and 2700 player. SRS 2.0 supports 4500 publisher, and 10000 player.
To improve the read performance, SRS2.0 introduced the merged-read, which read Nms packets from socket then parsed in buffer. The config:
```
# the MR(merged-read) setting for publisher.
vhost mrw.srs.com {
# 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.
# 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 atleast:
# 183KB * 2500 = 446MB
# the value recomment is [300, 2000]
# default: 350
mr_latency 350;
}
}
```
That is, when merged-read enabled, the read buffer of SRS is `latency` ms, the latency also increase to this value.
For low latency, user should disable merged-read, SRS will recv and parse the packet immediately.
## Merged-Write
SRS always use merged-write to send packets. This algorithm can improve about 500% performance, for example, SRS 1.0 writev a packet which supports 2700 clients, while SRS 2.0 writev multiple packets and supports 10000 clients.
User can config the merged write pacets in ms, recomment to use default value:
```
# the MW(merged-write) settings for player.
vhost mrw.srs.com {
# for play client, both RTMP and other stream clients,
# for instance, the HTTP FLV stream clients.
play {
# 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]
# default: 350
mw_latency 350;
}
}
```
User can config this to 100ms for very low latency.
## GOP-Cache
The gop is the gop between two I frame.
SRS use gop-cache to cache the last gop for the live stream,
when client play stream, SRS can send the last gop to client
to enable the client to start play immediately.
Config of srs:
```bash
# the listen ports, split by space.
listen 1935;
vhost __defaultVhost__ {
# 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.
# default: on
gop_cache off;
}
}
```
Read about the min.delay.com in `conf/full.conf`.
## Low Latency config
Recoment to use the bellow config for low latency application:
```bash
# the listen ports, split by space.
listen 1935;
vhost __defaultVhost__ {
tcp_nodelay on;
min_latency on;
play {
gop_cache off;
queue_length 10;
mw_latency 100;
}
publish {
mr off;
}
}
```
## Benchmark Data
SRS: 0.9.55
Encoder: FMLE, video(h264, profile=baseline, level=3.1, keyframe-frequency=5seconds), fps=15, input=640x480,
output(500kbps, 640x480), no audio output.
Network: Publish to aliyun qindao server.
SRS config:
```bash
listen 1935;
vhost __defaultVhost__ {
enabled on;
play {
gop_cache off;
}
hls {
enabled on;
hls_path ./objs/nginx/html;
hls_fragment 5;
hls_window 20;
}
}
```
Latency: RTMP 2s, HLS 24s.
Read: ![RTMP-HLS-latency](/img/doc-main-concepts-low-latency-001.png)
## Edge Benchmark Data
SRS RTMP cluster almost not add more latency.
Read ![Edge-latency](/img/doc-main-concepts-low-latency-002.png)
Winlin 2015.8
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/low-latency)

55
trunk/3rdparty/srs-docs/doc/nginx-exec.md vendored Normal file
View File

@ -0,0 +1,55 @@
---
title: Nginx RTMP EXEC
sidebar_label: Nginx RTMP EXEC
hide_title: false
hide_table_of_contents: false
---
# Exec
## NGINX RTMP EXEC
SRS only support some exec introduced by NGINX RTMP:
1. exec/exec_publish: Support.
1. exec_pull: Not support.
1. exec_play: Not support.
1. exec_record_done: Not support.
> Note: You could use [HTTP Callback](./http-callback.md) to start FFmpeg on your backend server. It's much better solution.
## Config
The config for SRS EXEC list bellow, you can refer to `conf/exec.conf`.
```
vhost __defaultVhost__ {
# the exec used to fork process when got some event.
exec {
# whether enable the exec.
# default: off.
enabled off;
# when publish stream, exec the process with variables:
# [vhost] the input stream vhost.
# [port] the intput stream port.
# [app] the input stream app.
# [stream] the input stream name.
# [engine] the tanscode engine name.
# other variables for exec only:
# [url] the rtmp url which trigger the publish.
# [tcUrl] the client request tcUrl.
# [swfUrl] the client request swfUrl.
# [pageUrl] the client request pageUrl.
# @remark empty to ignore this exec.
publish ./objs/ffmpeg/bin/ffmpeg -f flv -i [url] -c copy -y ./[stream].flv;
}
}
```
Winlin 2015.8
[ne]: https://github.com/arut/nginx-rtmp-module/wiki/Directives#exec
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/nginx-exec)

270
trunk/3rdparty/srs-docs/doc/nginx-for-hls.md vendored Normal file
View File

@ -0,0 +1,270 @@
---
title: HLS Cluster
sidebar_label: HLS Cluster
hide_title: false
hide_table_of_contents: false
---
# Nginx for HLS
Edge Cluster is designed to solve the problem of many people watching, and it can support a large number of people watching live streams. Please note:
* SRS Edge only supports live streaming protocols, such as RTMP or HTTP-FLV, etc. Refer to [RTMP Edge Cluster](./sample-rtmp-cluster.md).
* SRS Edge does not support sliced live streams like HLS or DASH. Essentially, they are not streams but file distribution.
* SRS Edge does not support WebRTC stream distribution, as this is not the design goal of Edge. WebRTC has its own clustering method, refer to [#2091](https://github.com/ossrs/srs/issues/2091).
This article describes the edge cluster for HLS or DASH slices, which is based on NGINX implementation, so it is also called NGINX Edge Cluster.
## Oryx
The NGINX edge cluster can work together with the Oryx to achieve HLS distribution. For more details, please refer to [Oryx HLS CDN](https://github.com/ossrs/oryx/tree/main/scripts/nginx-hls-cdn).
## NGINX Edge Cluster
The NGINX edge cluster is essentially a reverse proxy with caching, also known as NGINX Proxy with Cache.
```text
+------------+ +------------+ +------------+ +------------+
+ FFmpeg/OBS +--RTMP-->-+ SRS Origin +--HLS-->--+ NGINX +--HLS-->--+ Visitors +
+------------+ +------------+ + Servers + +------------+
+------------+
```
You only need to configure the caching strategy of NGINX, no additional plugins are needed, as NGINX itself supports it.
```bash
http {
# For Proxy Cache.
proxy_cache_path /tmp/nginx-cache levels=1:2 keys_zone=srs_cache:8m max_size=1000m inactive=600m;
proxy_temp_path /tmp/nginx-cache/tmp;
server {
listen 8081;
# For Proxy Cache.
proxy_cache_valid 404 10s;
proxy_cache_lock on;
proxy_cache_lock_age 300s;
proxy_cache_lock_timeout 300s;
proxy_cache_min_uses 1;
location ~ /.+/.*\.(m3u8)$ {
proxy_pass http://127.0.0.1:8080$request_uri;
# For Proxy Cache.
proxy_cache srs_cache;
proxy_cache_key $scheme$proxy_host$uri$args;
proxy_cache_valid 200 302 10s;
}
location ~ /.+/.*\.(ts)$ {
proxy_pass http://127.0.0.1:8080$request_uri;
# For Proxy Cache.
proxy_cache srs_cache;
proxy_cache_key $scheme$proxy_host$uri;
proxy_cache_valid 200 302 60m;
}
}
}
```
> Note: You can configure the cache directory `proxy_cache_path` and `proxy_temp_path` to be accessible directories.
> Note: Generally, do not modify the `location` configuration unless you know what it means. If you want to change it, make sure it runs first before making changes.
You must not configure it as a pure Proxy, as this will pass the load through to SRS, and the number of clients the system supports will still be limited by SRS.
After enabling Cache, no matter how much load NGINX has, SRS will only have one stream. In this way, we can expand multiple NGINX to support a large number of concurrent viewers.
For example, a 1Mbps HLS stream, with 1000 clients playing on NGINX, the bandwidth of NGINX would be 1Gbps, while SRS would only have 1Mbps.
If we expand to 10 NGINX, each with 10Gbps bandwidth, the total system bandwidth would be 100Gbps, capable of supporting 100,000 concurrent viewers, with SRS bandwidth consumption only at 10Mbps.
How to verify that the system is working properly? This is where Benchmark comes in.
## Benchmark
How to stress test this system? You can use [srs-bench](https://github.com/ossrs/srs-bench#usage), which is very convenient to use and can be started directly with Docker:
```bash
docker run --rm -it --network=host --name sb ossrs/srs:sb \
./objs/sb_hls_load -c 500 \
-r http://your_server_public_ipv4/live/livestream.m3u8
```
And you can also stress test RTMP and HTTP-FLV:
```bash
docker run --rm -it --network=host --name sb ossrs/srs:sb \
./objs/sb_http_load -c 500 \
-r http://your_server_public_ipv4/live/livestream.flv
```
> Note: Each SB simulated client concurrency is between 500 and 1000, depending on the CPU not exceeding 80%. You can start multiple processes for stress testing.
Now let's get our hands on creating an HLS cluster.
## Example
Now let's use Docker to build an HLS distribution cluster.
First, start the SRS origin server:
```bash
./objs/srs -c conf/hls.origin.conf
```
Then, start the NGINX origin server:
```bash
nginx -c $(pwd)/conf/hls.edge.conf
```
Finally, push the stream to the origin server:
```bash
ffmpeg -re -i doc/source.flv -c copy \
-f flv rtmp://127.0.0.1/live/livestream
```
Play HLS:
* SRS origin server: http://127.0.0.1:8080/live/livestream.m3u8
* NGINX edge: http://127.0.0.1:8081/live/livestream.m3u8
Start the stress test and get HLS from NGINX:
```bash
docker run --rm -it --network=host --name sb ossrs/srs:sb \
./objs/sb_hls_load -c 500 \
-r http://192.168.0.14:8081/live/livestream.m3u8
```
However, the pressure on SRS is not significant, and the CPU consumption is all on NGINX.
The NGINX edge cluster successfully solved the HLS distribution problem. If you also need to do low-latency live streaming and distribute HTTP-FLV, how to do it? What if you want to support HTTPS HLS or HTTPS-FLV?
NGINX has no problem at all. Now let's see how to work with the SRS Edge Server to implement HTTP-FLV and HLS distribution through NGINX.
## Work with SRS Edge Server
The NGINX edge cluster can also work with the SRS Edge Server to achieve HLS and HTTP-FLV distribution.
```text
+------------+ +------------+
| SRS Origin +--RTMP-->--+ SRS Edge +
+-----+------+ +----+-------+
| | +------------+
| +---HTTP-FLV->--+ NGINX + +-----------+
| + Edge +--HLS/FLV-->--+ Visitors +
+-------HLS--->-------------------------+ Servers + +-----------+
+------------+
```
It's very simple to implement. All you need to do is deploy an SRS on the NGINX server and have NGINX work in reverse proxy mode.
```bash
# For SRS streaming, for example:
# http://r.ossrs.net/live/livestream.flv
location ~ /.+/.*\.(flv)$ {
proxy_pass http://127.0.0.1:8080$request_uri;
}
```
In this way, HLS is managed by NGINX for caching and back-to-source, while FLV is cached and back-to-source by SRS Edge.
Although this architecture is good, in fact, NGINX can directly serve as an HLS origin server, which can provide even higher performance. Is it possible? No problem at all. Let's see how to use NGINX to distribute HLS completely.
## NGINX Origin Server
Since HLS is just a regular file, it can also be directly used with NGINX as an HLS origin server.
In a super high-concurrency NGINX Edge cluster, a small data center-level cluster can also be formed, with centralized back-to-source from a specific NGINX, which can support even higher concurrency.
Using NGINX to distribute HLS files is actually very simple, you only need to set the root:
```bash
# For HLS delivery
location ~ /.+/.*\.(m3u8)$ {
root /usr/local/srs/objs/nginx/html;
add_header Cache-Control "public, max-age=10";
}
location ~ /.+/.*\.(ts)$ {
root /usr/local/srs/objs/nginx/html;
add_header Cache-Control "public, max-age=86400";
}
```
> Note: Here we set the cache time for m3u8 to 10 seconds, which needs to be adjusted according to the size of the segment.
> Note: Since SRS currently supports HLS variant and implements HLS playback statistics, it is not as efficient as NGINX. See [#2995](https://github.com/ossrs/srs/issues/2995)
> Note: SRS should set `Cache-Control` because the segment service can dynamically set the correct cache time to reduce latency. See [#2991](https://github.com/ossrs/srs/issues/2991)
## Debugging
How to determine if the cache is effective? You can add a field `upstream_cache_status` in the NGINX log and analyze the NGINX log to determine if the cache is effective:
```bash
log_format main '$upstream_cache_status $remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;
```
The first field is the cache status, which can be analyzed using the following command, for example, to only view the cache status of TS files:
```bash
cat /var/log/nginx/access.log | grep '.ts HTTP' \
| awk '{print $1}' | sort | uniq -c | sort -r
```
You can see which ones are HIT cache, so you don't need to download files from SRS, but directly get files from NGINX.
You can also directly add this field to the response header, so you can see in the browser whether each request has HIT:
```bash
add_header X-Cache-Status $upstream_cache_status;
```
> Note: Regarding the cache effective time, refer to the definition of the field [proxy_cache_valid](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache_valid), in fact, if the source station specifies `Cache-Control`, it will override this configuration.
## aaPanel Configuration
If you are using aaPanel, you can add a new site, and then write the following configuration in the site's configuration:
```bash
# For Proxy Cache.
proxy_cache_path /tmp/nginx-cache levels=1:2 keys_zone=srs_cache:8m max_size=1000m inactive=600m;
proxy_temp_path /tmp/nginx-cache/tmp;
server {
listen 80;
server_name your.domain.com;
# For Proxy Cache.
proxy_cache_valid 404 10s;
proxy_cache_lock on;
proxy_cache_lock_age 300s;
proxy_cache_lock_timeout 300s;
proxy_cache_min_uses 1;
location ~ /.+/.*\.(m3u8)$ {
proxy_pass http://127.0.0.1:8080$request_uri;
# For Proxy Cache.
proxy_cache srs_cache;
proxy_cache_key $scheme$proxy_host$uri$args;
proxy_cache_valid 200 302 10s;
}
location ~ /.+/.*\.(ts)$ {
proxy_pass http://127.0.0.1:8080$request_uri;
# For Proxy Cache.
proxy_cache srs_cache;
proxy_cache_key $scheme$proxy_host$uri;
proxy_cache_valid 200 302 60m;
}
}
```
> Note: Generally, when adding a new site in aaPanel, it listens to port 80, and the domain server_name is the domain name you fill in yourself. Other configurations are the same as the aaPanel settings. Alternatively, you can also add the above cache and location configurations to the site settings in aaPanel.
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/nginx-for-hls)

424
trunk/3rdparty/srs-docs/doc/origin-cluster.md vendored Normal file
View File

@ -0,0 +1,424 @@
---
title: Origin Cluster
sidebar_label: Origin Cluster
hide_title: false
hide_table_of_contents: false
---
# OriginCluster
The SRS origin cluster is a group of origin servers intended for handling a large number of streams.
The new origin cluster is designed as a collection of proxy servers that load balance and proxy to a
set of origin servers. For more information, see [Discussion #3634](https://github.com/ossrs/srs/discussions/3634).
If you prefer to use the old origin cluster, please switch to a version before SRS 6.0.
## Introduction
You can deploy multiple SRS origin servers, to handle a large number of streams. The proxy server is
used as a load balancer for these origin servers:
```text
+--------------------+
+-------+ SRS Origin Server +
+ +--------------------+
+
+-----------------------+ + +--------------------+
+ SRS Proxy(Deployment) +------+-------+ SRS Origin Server +
+-----------------------+ + +--------------------+
+
+ +--------------------+
+-------+ SRS Origin Server +
+--------------------+
```
The origin cluster also enhances the scalability of the origin server. For instance, with 200 backend
SRS origin servers, it can support 100 WebRTC streamers, each with 200 viewers, totaling 20,000 connections.
If you deploy this cluster on a server with a large number of CPU cores, it becomes a very powerful
media server.
> Note: You are also able to deploy multiple proxy servers, or proxy to other media servers, or work
> with edge cluster, see [Design](#design) for details.
The proxy server support almost all protocols of SRS, including RTMP, HTTP-FLV, HLS, WebRTC, and SRT.
Please see [Protocols](#protocols) for details.
## Build
To build the proxy server, you need to have Go 1.18+ installed. Then, you can build the proxy
server by below command, and get the executable binary `./srs-proxy`:
```bash
git clone https://github.com/ossrs/proxy-go.git
cd proxy-go && make
```
> Note: You can also download the dependencies by running `go mod download` before building.
We will support the Docker image in the future, or integrate the proxy server into the Oryx
project.
## RTMP Origin Cluster
To use the RTMP origin cluster, you need to deploy the proxy server and the origin server.
First, start the proxy server:
```bash
env PROXY_RTMP_SERVER=1935 PROXY_HTTP_SERVER=8080 \
PROXY_HTTP_API=1985 PROXY_WEBRTC_SERVER=8000 PROXY_SRT_SERVER=10080 \
PROXY_SYSTEM_API=12025 PROXY_LOAD_BALANCER_TYPE=memory ./srs-proxy
```
> Note: Here we use the memory load balancer, you can switch to `redis` if you want to run more
> than one proxy server.
Then, deploy three origin servers, which connects to the proxy server via port `12025`:
```bash
./objs/srs -c conf/origin1-for-proxy.conf
./objs/srs -c conf/origin2-for-proxy.conf
./objs/srs -c conf/origin3-for-proxy.conf
```
> Note: The origin servers are independent, so it's recommended to deploy them as Deployments
> in Kubernetes (K8s).
Now, you're able to publish RTMP stream to the proxy server:
```bash
ffmpeg -re -i doc/source.flv -c copy -f flv rtmp://localhost/live/livestream
```
And play the RTMP stream from the proxy server:
```bash
ffplay rtmp://localhost/live/livestream
```
Or play HTTP-FLV stream from the proxy server:
```bash
ffplay http://localhost:8080/live/livestream.flv
```
Or play HLS stream from the proxy server:
```bash
ffplay http://localhost:8080/live/livestream.m3u8
```
Or play the WebRTC stream via [WHEP player](http://localhost:8080/players/whep.html) from proxy server.
You can also use VLC or other players to play the stream in proxy server.
## WebRTC Origin Cluster
To use the WebRTC origin cluster, you need to deploy the proxy server and the origin server.
First, start the proxy server:
```bash
env PROXY_RTMP_SERVER=1935 PROXY_HTTP_SERVER=8080 \
PROXY_HTTP_API=1985 PROXY_WEBRTC_SERVER=8000 PROXY_SRT_SERVER=10080 \
PROXY_SYSTEM_API=12025 PROXY_LOAD_BALANCER_TYPE=memory ./srs-proxy
```
> Note: Here we use the memory load balancer, you can switch to `redis` if you want to run more
> than one proxy server.
Then, deploy three origin servers, which connects to the proxy server via port `12025`:
```bash
./objs/srs -c conf/origin1-for-proxy.conf
./objs/srs -c conf/origin2-for-proxy.conf
./objs/srs -c conf/origin3-for-proxy.conf
```
> Note: The origin servers are independent, so it's recommended to deploy them as Deployments
> in Kubernetes (K8s).
Now, you're able to publish WebRTC stream via [WHIP publisher](http://localhost:8080/players/whip.html) to the proxy server.
And play the WebRTC stream via [WHEP player](http://localhost:8080/players/whep.html) from proxy server.
Or play the RTMP stream from the proxy server:
```bash
ffplay rtmp://localhost/live/livestream
```
Or play HTTP-FLV stream from the proxy server:
```bash
ffplay http://localhost:8080/live/livestream.flv
```
Or play HLS stream from the proxy server:
```bash
ffplay http://localhost:8080/live/livestream.m3u8
```
You can also use VLC or other players to play the stream in proxy server.
## SRT Origin Cluster
To use the SRT origin cluster, you need to deploy the proxy server and the origin server.
First, start the proxy server:
```bash
env PROXY_RTMP_SERVER=1935 PROXY_HTTP_SERVER=8080 \
PROXY_HTTP_API=1985 PROXY_WEBRTC_SERVER=8000 PROXY_SRT_SERVER=10080 \
PROXY_SYSTEM_API=12025 PROXY_LOAD_BALANCER_TYPE=memory ./srs-proxy
```
> Note: Here we use the memory load balancer, you can switch to `redis` if you want to run more
> than one proxy server.
Then, deploy three origin servers, which connects to the proxy server via port `12025`:
```bash
./objs/srs -c conf/origin1-for-proxy.conf
./objs/srs -c conf/origin2-for-proxy.conf
./objs/srs -c conf/origin3-for-proxy.conf
```
> Note: The origin servers are independent, so it's recommended to deploy them as Deployments
> in Kubernetes (K8s).
Now, you're able to publish SRT stream to the proxy server:
```bash
ffmpeg -re -i ./doc/source.flv -c copy -pes_payload_size 0 -f mpegts \
'srt://127.0.0.1:10080?streamid=#!::r=live/livestream,m=publish'
```
And play the SRT stream from the proxy server:
```bash
ffplay 'srt://127.0.0.1:10080?streamid=#!::r=live/livestream,m=request'
```
Or play the RTMP stream from the proxy server:
```bash
ffplay rtmp://localhost/live/livestream
```
Or play HTTP-FLV stream from the proxy server:
```bash
ffplay http://localhost:8080/live/livestream.flv
```
Or play HLS stream from the proxy server:
```bash
ffplay http://localhost:8080/live/livestream.m3u8
```
Or play the WebRTC stream via [WHEP player](http://localhost:8080/players/whep.html) from proxy server.
You can also use VLC or other players to play the stream in proxy server.
## Config
The proxy server is configured by environment variables. The supported environment variables for proxy
backend server are:
* `PROXY_HTTP_API`: The HTTP API port, proxy to SRS origin server. Default: `11985`
* `PROXY_HTTP_SERVER`: The HTTP streaming server, proxy to SRS origin server. Default: `18080`
* `PROXY_RTMP_SERVER`: The RTMP server, proxy to SRS origin server. Default: `11935`
* `PROXY_WEBRTC_SERVER`: The WebRTC server, proxy to SRS origin server, via UDP protocol. Default: `18000`
* `PROXY_SRT_SERVER`: The SRT server, proxy to SRS origin server. Default: `20080`
The following environment variables are about the proxy server itself:
* `PROXY_SYSTEM_API`: The system API port, allow origin server register services to proxy servers. Default: `12025`
* `PROXY_STATIC_FILES`: The files directory for static web server, like the players. Default: `../trunk/research`
* `PROXY_LOAD_BALANCER_TYPE`: The load balancer type, `memory` or `redis`. Default: `redis`
For the Redis load balancer, you need to set the following environment variables:
* `PROXY_REDIS_HOST`: The Redis host. Default: `127.0.0.1`
* `PROXY_REDIS_PORT`: The Redis port. Default: `6379`
* `PROXY_REDIS_PASSWORD`: The Redis password. Default to empty, no password.
* `PROXY_REDIS_DB`: The Redis DB. Default: `0`
For debugging, the proxy server will proxy to a default origin server, you can set the following
environment variables:
* `PROXY_DEFAULT_BACKEND_ENABLED`: Whether to enable the default backend origin server. Default: `off`
* `PROXY_DEFAULT_BACKEND_IP`: The default backend IP. Default: `127.0.0.1`
* `PROXY_DEFAULT_BACKEND_RTMP`: The default backend RTMP port. Default: `1935`
* `PROXY_DEFAULT_BACKEND_HTTP`: The default backend HTTP port. Default: `8080`
* `PROXY_DEFAULT_BACKEND_RTC`: The default backend WebRTC port via UDP. Default: `8000`
* `PROXY_DEFAULT_BACKEND_SRT`: The default backend SRT port. Default: `10080`
* `PROXY_DEFAULT_BACKEND_API`: The default backend API port. Default: `1985`
> Note: The default backend origin server, is designed for any RTMP server like nginx-rtmp, it does not
> require the origin server to register to the proxy server.
## Design
The proxy works with SRS origin servers, and the stream flow operates as follows:
```text
Client ----> Proxy Server ---> Origin Servers
Client ---> LB --> Proxy Servers --> Origin Servers
OBS/FFmpeg --RTMP--> K8s(Service) --Proxy--> SRS(pod A)
Browsers --FLV/HLS/SRT--> K8s(Service) --Proxy--> SRS(pod A)
Browsers --+---HTTP-API--> K8s(Service) --Proxy--> SRS(pod A)
+---WebRTC----> K8s(Service) --Proxy--> SRS(pod A)
```
> Note: This proxy server can be deployed in Kubernetes (K8s) and can route traffic to the SRS origin
> servers. The proxy server functions as a load balancer to distribute the load among the origin servers.
> You can also use the proxy server without Kubernetes.
This is the detailed deployment process that works with the Kubernetes (K8s) system:
```text
+-----------------------+
+---+ SRS Proxy(Deployment) +------+---------------------+
+-----------------+ | +-----------+-----------+ + +
| LB(K8s Service) +--+ +(Redis/MESH) + SRS Origin Servers +
+-----------------+ | +-----------+-----------+ + (Deployment) +
+---+ SRS Proxy(Deployment) +------+---------------------+
+-----------------------+
```
> Note: There are multiple proxy servers, so they need Redis or MESH to synchronize their state. MESH means
> the proxy servers connect to each other to sync the state and should be deployed as a StatefulSet in
> Kubernetes (K8s). The Redis solution is preferable because the proxy server can be deployed as a Deployment
> in K8s, and you can also use a Redis cluster for high availability.
> Note: There are multiple origin servers, which are deployed as Deployments in Kubernetes (K8s), as there is
> no need to sync the state between origin servers. These origin servers are completely independent, making
> the system very robust. Please note that this is different from the previous origin cluster before SRS 6.0,
> which used MESH to connect to each other, and it was not a good architecture.
If you want to build an origin cluster with a single proxy server and multiple origin servers:
```text
+--------------------+
+-------+ SRS Origin Server +
+ +--------------------+
+
+-----------------------+ + +--------------------+
+ SRS Proxy(Deployment) +------+-------+ SRS Origin Server +
+-----------------------+ + +--------------------+
+
+ +--------------------+
+-------+ SRS Origin Server +
+--------------------+
```
> Note: A single proxy server architecture is also useful if you only want to support many streams with a
> small number of viewers. The proxy server is very high performance and supports multiple processes.
> Note: If you want to use multiple proxy servers, you can simply deploy more and connect them to the same
> Redis server. These proxy servers will work together to support a large number of streams. This architecture
> is scalable.
With this architecture, you can support a large number of streams and then use edge servers to support
multiple viewers.
```text
+------------------+ +--------------------+
+ SRS Edge Server +--+ +-------+ SRS Origin Server +
+------------------+ + + +--------------------+
+ +
+------------------+ + +-----------------------+ + +--------------------+
+ SRS Edge Server +--+-----+ SRS Proxy(Deployment) +------+-------+ SRS Origin Server +
+------------------+ + +-----------------------+ + +--------------------+
+ +
+------------------+ + + +--------------------+
+ SRS Edge Server +--+ +-------+ SRS Origin Server +
+------------------+ +--------------------+
```
> Note: With this architecture, you can build a very large media system that supports a large number of
> streams and viewers. It is a complex system to maintain, so only use it if necessary.
In fact, a proxy server also works with SRS edge servers, but it is not a typical architecture.
## Protocols
Because the proxy server is a new server, not all protocols are supported yet. The supported
protocols are:
- [x] RTMP: Proxy RTMP protocol to the SRS origin server.
- [x] HTTP-FLV: Proxy HTTP-FLV protocol to the SRS origin server.
- [x] HTTP-TS: Proxy HTTP-TS protocol to the SRS origin server.
- [x] HLS: Proxy HLS protocol to the SRS origin server.
- [x] WebRTC: Proxy WebRTC(WHIP/WHEP) protocol to the SRS origin server.
- [x] SRT: Proxy SRT protocol to the SRS origin server.
- [ ] MPEG-DASH: Proxy MPEG-DASH protocol to the SRS origin server.
- [ ] RTSP: Proxy RTSP protocol to the SRS origin server.
There are also some key features not supported yet:
- [x] Single node proxy server, use memory to store state.
- [x] Redis: Connect to the Redis server to sync the state.
- [ ] MESH: Connect to other proxy servers to sync the state.
- [ ] HTTP-API: Provide an HTTP API that collects all the metrics of the origin servers.
- [ ] Exporter: Provide a Prometheus exporter that exports the metrics of the proxy server.
For a media cluster, the media server is only one part of the whole system. The control and management panel
are also very important to maintain this complex system.
## Register
The origin server can register itself to the proxy server, so the proxy server can load balance
the backend servers. The register API is a simple HTTP API:
```bash
curl -X POST http://127.0.0.1:12025/api/v1/srs/register \
-H "Connection: Close" \
-H "Content-Type: application/json" \
-H "User-Agent: curl" \
-d '{
"device_id": "origin2",
"ip": "10.78.122.184",
"server": "vid-46p14mm",
"service": "z2s3w865",
"pid": "42583",
"rtmp": ["19352"],
"http": ["8082"],
"api": ["19853"],
"srt": ["10082"],
"rtc": ["udp://0.0.0.0:8001"]
}'
#{"code":0,"pid":"53783"}
```
* `ip`: Mandatory, the IP of the backend server. Make sure the proxy server can access the backend server via this IP.
* `server`: Mandatory, the server id of backend server. For SRS, it stores in file, may not change.
* `service`: Mandatory, the service id of backend server. For SRS, it always changes when restarted.
* `pid`: Mandatory, the process id of backend server. Used to identify whether process restarted.
* `rtmp`: Mandatory, the RTMP listen endpoints of backend server. Proxy server will connect backend server via this port for RTMP protocol.
* `http`: Optional, the HTTP listen endpoints of backend server. Proxy server will connect backend server via this port for HTTP-FLV or HTTP-TS protocol.
* `api`: Optional, the HTTP API listen endpoints of backend server. Proxy server will connect backend server via this port for HTTP-API, such as WHIP and WHEP.
* `srt`: Optional, the SRT listen endpoints of backend server. Proxy server will connect backend server via this port for SRT protocol.
* `rtc`: Optional, the WebRTC listen endpoints of backend server. Proxy server will connect backend server via this port for WebRTC protocol.
* `device_id`: Optional, the device id of backend server. Used as a label for the backend server.
The listen endpoint format is `port`, or `protocol://ip:port`, or `protocol://:port`, for example:
* `1935`: Listen on port 1935 and any IP for TCP protocol.
* `tcp://:1935`: Listen on port 1935 and any IP for TCP protocol.
* `tcp://0.0.0.0:1935`: Listen on port 1935 and any IP for TCP protocol.
* `tcp://192.168.3.10:1935`: Listen on port 1935 and specified IP for TCP protocol.
You can also use SRS 5.0+ as backend server, which supports `heartbeat` feature to register itself
to proxy server.
Furthermore, you can write a curl script to register the backend server, or a dedicate backend server
manage service. For example, if you don't want to modify the nginx-rtmp code, you can use a isolate program
to register the nginx-rtmp to proxy server.
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/origin-cluster)

14
trunk/3rdparty/srs-docs/doc/perf.md vendored Normal file
View File

@ -0,0 +1,14 @@
---
title: Perf Analysis
sidebar_label: Perf Analysis
hide_title: false
hide_table_of_contents: false
---
# Perf
Please read [SRS性能(CPU)、内存优化工具用法](https://www.jianshu.com/p/6d4a89359352)
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/perf)

829
trunk/3rdparty/srs-docs/doc/performance.md vendored Normal file
View File

@ -0,0 +1,829 @@
---
title: Performance
sidebar_label: Performance
hide_title: false
hide_table_of_contents: false
---
# Performance
There is a set of tools for performance improvement and detecting memory leaking.
> Note: All tools will hurts performance more or less, so never enable these tools unless you need to fix memory issue.
## RTC
RTC is delivering over UDP, so the first and most important configuration is for kernel network:
```bash
# Query the kernel configuration
sysctl net.core.rmem_max
sysctl net.core.rmem_default
sysctl net.core.wmem_max
sysctl net.core.wmem_default
# Set the UDP buffer to 16MB
sysctl net.core.rmem_max=16777216
sysctl net.core.rmem_default=16777216
sysctl net.core.wmem_max=16777216
sysctl net.core.wmem_default=16777216
```
> Note: For Docker, it read the configuration from host, so you only need to setup the host machine.
> Note：If need to set these configurations in docker, you must run with `--network=host`.
Or, you could also modify the file `/etc/sysctl.conf` to enalbe if when reboot:
```bash
# vi /etc/sysctl.conf
# For RTC
net.core.rmem_max=16777216
net.core.rmem_default=16777216
net.core.wmem_max=16777216
net.core.wmem_default=16777216
```
Query the network statistics and UDP packets dropping:
```bash
netstat -suna
netstat -suna && sleep 30 && netstat -suna
```
For Example:
* `224911319 packets received` The total received UDP packets.
* `65731106 receive buffer errors` The total dropped UDP packets before receiving
* `123534411 packets sent` The total sent UDP packets.
* `0 send buffer errors` The total dropped UDP packets before sending.
> Note: SRS also prints about the packets dropped in application level, for example `loss=(r:49,s:0)` which means dropped 49 packets before receiving.
> Note：Please note that you must run the command in docker container, not on host machine.
The length of UDP queue:
```bash
netstat -lpun
```
For example:
* `Recv-Q 427008` Established: The count of bytes not copied by the user program connected to this socket.
* `Send-Q 0` Established: The count of bytes not acknowledged by the remote host.
Other useful parameters of netstat:
* `--udp|-u` Filter by UDP protocol.
* `--numeric|-n` Show numerical addresses instead of trying to determine symbolic host, port or user names.
* `--statistics|-s` Show statistics.
* `--all|-a` Show both listening and non-listening sockets. With the --interfaces option, show interfaces that are not up.
* `--listening|-l` Show only listening sockets. (These are omitted by default.)
* `--program|-p` Show the PID and name of the program to which each socket belongs.
## PERF
PERF is Performance analysis tools for Linux.
Show performance bottleneck of SRS:
```
perf top -p $(pidof srs)
```
To record the data:
```
perf record -p $(pidof srs)
# Press CTRL+C after about 30s.
perf report
```
Show stack or backtrace:
```
perf record -a --call-graph fp -p $(pidof srs)
perf report --call-graph --stdio
```
> Note: Record to file by `perf report --call-graph --stdio >t.txt`。
> Remark: The stack(`-g`) does not work for SRS(ST), because ST modifies the SP.
## ASAN
[Asan](https://github.com/google/sanitizers/wiki/AddressSanitizer) is Google Address Sanitizer.
### ASAN: Usage
SRS5+ supports [ASAN](https://github.com/google/sanitizers/wiki/AddressSanitizer) by default.
If you want to disable it, please check bellow configure options:
```bash
./configure -h |grep asan
--sanitizer=on|off Whether build SRS with address sanitizer(asan). Default: on
--sanitizer-static=on|off Whether build SRS with static libasan(asan). Default: off
--sanitizer-log=on|off Whether hijack the log for libasan(asan). Default: off
```
Enable leaks detection, see [halt_on_error](https://github.com/google/sanitizers/wiki/AddressSanitizerFlags)
and [detect_leaks](https://github.com/google/sanitizers/wiki/SanitizerCommonFlags):
```bash
ASAN_OPTIONS=halt_on_error=1:detect_leaks=1 ./objs/srs -c conf/console.conf
```
> Note: SRS disable memory leak detection by default, because it will cause daemon to exit with error.
Highly recommend to enable ASAN because it works great.
### ASAN: Preload
If you encounter the following error:
```bash
==4181651==ASan runtime does not come first in initial library list; you should either link runtime
to your application or manually preload it with LD_PRELOAD.
```
You should preload the ASAN library:
```bash
LD_PRELOAD=$(find /usr -name libasan.so.5 2>/dev/null) ./objs/srs -c conf/console.conf
```
> Note: Generally, the libasan.so file should be located at `/usr/lib64/libasan.so.5`
### ASAN: Options
By default, SRS use the following ASAN options:
```text
extern "C" const char *__asan_default_options() {
return "halt_on_error=0:detect_leaks=0:alloc_dealloc_mismatch=0";
}
```
* `halt_on_error=0`: Disable halt on errors by halt_on_error, only print messages, note that it still quit for fatal errors, see [halt_on_error](https://github.com/google/sanitizers/wiki/AddressSanitizerFlags).
* `detect_leaks=0`: Disable the memory leaking detect for daemon by detect_leaks, see [detect_leaks](https://github.com/google/sanitizers/wiki/SanitizerCommonFlags).
* `alloc_dealloc_mismatch=0`: Also disable alloc_dealloc_mismatch for gdb.
You can override the options by `ASAN_OPTIONS`:
```bash
ASAN_OPTIONS=halt_on_error=1:detect_leaks=1:alloc_dealloc_mismatch=1 ./objs/srs -c conf/console.conf
```
Note that the `ASAN_OPTIONS` will be loaded before the `main()` function, so you can set it in the shell,
but can not set in the `main()` function.
## GPROF
GPROF is a GNU tool, see [SRS GPROF](./gprof.md) and [GNU GPROF](http://www.cs.utah.edu/dept/old/texinfo/as/gprof.html).
Usage:
```
# Build SRS with GPROF
./configure --gprof=on && make
# Start SRS with GPROF
./objs/srs -c conf/console.conf
# Or CTRL+C to stop GPROF
killall -2 srs
# To analysis result.
gprof -b ./objs/srs gmon.out
```
## GPERF
GPERF is [google tcmalloc](https://github.com/gperftools/gperftools), please see [GPERF](./gperf.md)。
### GPERF: GCP
GCP is for CPU performance analysis, see [GCP](https://gperftools.github.io/gperftools/cpuprofile.html).
Usage:
```
# Build SRS with GCP
./configure --gperf=on --gcp=on && make
# Start SRS with GCP
./objs/srs -c conf/console.conf
# Or CTRL+C to stop GCP
killall -2 srs
# To analysis cpu profile
./objs/pprof --text objs/srs gperf.srs.gcp*
```
> Note: For more details, please read [cpu-profiler](https://github.com/ossrs/srs/tree/4.0release/trunk/research/gperftools/cpu-profiler).
Install tool for graph:
```bash
yum install -y graphviz
```
Output svg graph to open by Chrome:
```bash
./objs/pprof --svg ./objs/srs gperf.srs.gcp >t.svg
```
### GPERF: GMD
GMD is for memory corrupt detecting, see [GMD](http://blog.csdn.net/win_lin/article/details/50461709).
Usage:
```
# Build SRS with GMD.
./configure --gperf=on --gmd=on && make
# Start SRS with GMD.
env TCMALLOC_PAGE_FENCE=1 ./objs/srs -c conf/console.conf
```
> Note: For more details, please read [heap-defense](https://github.com/ossrs/srs/tree/4.0release/trunk/research/gperftools/heap-defense).
> Note: Need link with `libtcmalloc_debug.a` and enable env `TCMALLOC_PAGE_FENCE`.
### GPERF: GMC
GMC is for memory leaking, see [GMC](https://gperftools.github.io/gperftools/heap_checker.html).
Usage:
```
# Build SRS with GMC
./configure --gperf=on --gmc=on && make
# Start SRS with GMC
env PPROF_PATH=./objs/pprof HEAPCHECK=normal ./objs/srs -c conf/console.conf 2>gmc.log
# Or CTRL+C to stop gmc
killall -2 srs
# To analysis memory leak
cat gmc.log
```
> Note: For more details, please read [heap-checker](https://github.com/ossrs/srs/tree/4.0release/trunk/research/gperftools/heap-checker).
### GPERF: GMP
GMD is for memory performance, see [GMP](https://gperftools.github.io/gperftools/heapprofile.html).
Usage:
```
# Build SRS with GMP
./configure --gperf=on --gmp=on && make
# Start SRS with GMP
./objs/srs -c conf/console.conf
# Or CTRL+C to stop gmp
killall -2 srs
# To analysis memory profile
./objs/pprof --text objs/srs gperf.srs.gmp*
```
> Note: For more details, please read [heap-profiler](https://github.com/ossrs/srs/tree/4.0release/trunk/research/gperftools/heap-profiler).
## VALGRIND
Valgrind is a powerful tool for memory leak and other issue.
### Valgrind: Memcheck
SRS3+ also supports valgrind.
```
valgrind --leak-check=full --show-leak-kinds=all ./objs/srs -c conf/console.conf
```
> Remark: For ST to support valgrind, see [state-threads](https://github.com/ossrs/state-threads#usage) and [ST#2](https://github.com/ossrs/state-threads/issues/2).
> Remark: For HTTP valgrind API, you should upgrade your SRS to required version, see [#4150](https://github.com/ossrs/srs/pull/4150).
### Valgrind: Incremental Memory Leak Detection
To use Valgrind to detect memory leaks in SRS, even though Valgrind hooks are supported in ST, there are
still many false positives. A more reasonable approach is to have Valgrind report incremental memory leaks.
This way, global and static variables can be avoided, and detection can be achieved without exiting the
program. Follow these steps:
1. Compile SRS with Valgrind support: `./configure --valgrind=on && make`
1. Start SRS with memory leak detection enabled: `valgrind --leak-check=full --show-leak-kinds=all ./objs/srs -c conf/console.conf`
1. Trigger memory detection by using curl to access the API and generate calibration data. There will still be many false positives, but these can be ignored: `curl http://127.0.0.1:1985/api/v1/valgrind?check=added`
1. Retry memory detection, util the valgrind leak summary is stable, no any new lost blocks.
1. Perform load testing or test the suspected leaking functionality, such as RTMP streaming: `ffmpeg -re -i doc/source.flv -c copy -f flv rtmp://127.0.0.1/live/livestream`
1. Stop streaming and wait for SRS to clean up the Source memory, approximately 30 seconds.
1. Perform incremental memory leak detection. The reported leaks will be very accurate at this point: `curl http://127.0.0.1:1985/api/v1/valgrind?check=added`
```text
HTTP #0 11.176.19.95:42162 GET http://9.134.74.169:1985/api/v1/valgrind?check=added, content-length=-1
query check=added
==1481822== LEAK SUMMARY:
==1481822== definitely lost: 0 (+0) bytes in 0 (+0) blocks
==1481822== indirectly lost: 0 (+0) bytes in 0 (+0) blocks
==1481822== possibly lost: 3,406,847 (+0) bytes in 138 (+0) blocks
==1481822== still reachable: 18,591,709 (+0) bytes in 819 (+0) blocks
==1481822== of which reachable via heuristic:
==1481822== multipleinheritance: 536 (+0) bytes in 4 (+0) blocks
==1481822== suppressed: 0 (+0) bytes in 0 (+0) blocks
==1481822== Reachable blocks (those to which a pointer was found) are not shown.
```
> Note: To avoid interference from the HTTP request itself on Valgrind, SRS uses a separate coroutine to perform periodic checks. Therefore, after accessing the API, you may need to wait a few seconds for the detection to be triggered.
### Valgrind: Still Reachable
Sometimes, you will receive the `still reachable` report for static or global variables, like this example:
```text
==3430715== 1,040 (+1,040) bytes in 1 (+1) blocks are still reachable in new loss record 797 of 836
==3430715== at 0x4C3F963: calloc (vg_replace_malloc.c:1595)
==3430715== by 0x7D8DB0: SrsConfig::get_hls_vcodec(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >) (srs_app_config.cpp:7156)
==3430715== by 0x781283: SrsHlsMuxer::segment_open() (srs_app_hls.cpp:418)
# It's caused by static variable:
string SrsConfig::get_hls_vcodec(string vhost) {
SRS_STATIC string DEFAULT = "h264";
SrsConfDirective* conf = get_hls(vhost);
if (!conf) {
return DEFAULT;
```
You can easily work around this by publishing the stream, stopping it, and then triggering the memory leak detection:
1. Publish stream to initialize the static and global variables: `ffmpeg -re -i doc/source.flv -c copy -f flv rtmp://127.0.0.1/live/livestream`
1. Trigger memory detection by using curl to access the API and generate calibration data. There will still be many false positives, but these can be ignored: `curl http://127.0.0.1:1985/api/v1/valgrind?check=added`
1. Retry memory detection, util the valgrind leak summary is stable, no any new lost blocks.
1. Perform load testing or test the suspected leaking functionality, such as RTMP streaming: `ffmpeg -re -i doc/source.flv -c copy -f flv rtmp://127.0.0.1/live/livestream`
1. Stop streaming and wait for SRS to clean up the Source memory, approximately 30 seconds.
1. Perform incremental memory leak detection. The reported leaks will be very accurate at this point: `curl http://127.0.0.1:1985/api/v1/valgrind?check=added`
With the variables initialized, the `still reachable` report will be gone.
## Syscall
Please use [strace -c -p PID](https://man7.org/linux/man-pages/man1/strace.1.html) for syscal performance issue.
## OSX
For macOS, please use [Instruments](https://stackoverflow.com/questions/11445619/profiling-c-on-mac-os-x)
```
instruments -l 30000 -t Time\ Profiler -p 72030
```
> Remark: You can also click `Sample` button in `Active Monitor`.
## Multiple Process and Softirq
You can run softirq(Kernel Network Transmission) on CPU0, so run SRS on other CPUs:
```bash
taskset -p 0xfe $(pidof srs)
```
Or run SRS on CPU1:
```bash
taskset -pc 1 $(pidof srs)
```
Then you can run `top` and press `1` to see each CPU statistics:
```bash
top # Press 1
#%Cpu0 : 1.8 us, 1.1 sy, 0.0 ni, 90.8 id, 0.0 wa, 0.0 hi, 6.2 si, 0.0 st
#%Cpu1 : 67.6 us, 17.6 sy, 0.0 ni, 14.9 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
```
Or use `mpstat -P ALL`
```bash
mpstat -P ALL
#01:23:14 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
#01:23:14 PM all 33.33 0.00 8.61 0.04 0.00 3.00 0.00 0.00 0.00 55.02
#01:23:14 PM 0 2.46 0.00 1.32 0.06 0.00 6.27 0.00 0.00 0.00 89.88
#01:23:14 PM 1 61.65 0.00 15.29 0.02 0.00 0.00 0.00 0.00 0.00 23.03
```
> Note: Use `cat /proc/softirqs` to check softirq type, please see [Introduction to deferred interrupts (Softirq, Tasklets and Workqueues)](https://0xax.gitbooks.io/linux-insides/content/Interrupts/linux-interrupts-9.html)
> Note: If SRS run with softirq at CPU0, the total CPU will be larger than total of running on different CPUs.
If you got more CPUs, you can run softirq to multiple CPUs:
```bash
# grep virtio /proc/interrupts | grep -e in -e out
29: 64580032 0 0 0 PCI-MSI-edge virtio0-input.0
30: 1 49 0 0 PCI-MSI-edge virtio0-output.0
31: 48663403 0 11845792 0 PCI-MSI-edge virtio0-input.1
32: 1 0 0 52 PCI-MSI-edge virtio0-output.1
# cat /proc/irq/29/smp_affinity
1 # Bind softirq of virtio0 incoming to CPU0.
# cat /proc/irq/30/smp_affinity
2 # Bind softirq of virtio0 outgoing to CPU1.
# cat /proc/irq/31/smp_affinity
4 # Bind softirq of virtio1 incoming to CPU2.
# cat /proc/irq/32/smp_affinity
8 # Bind softirq of virtio1 outgoing to CPU3.
```
To disable softirq balance and force to run on CPU0, see [Linux: scaling softirq among many CPU cores](http://natsys-lab.blogspot.com/2012/09/linux-scaling-softirq-among-many-cpu.html)
and [SMP IRQ affinity](https://www.kernel.org/doc/Documentation/IRQ-affinity.txt) by:
```bash
for irq in $(grep virtio /proc/interrupts | grep -e in -e out | cut -d: -f1); do
echo 1 > /proc/irq/$irq/smp_affinity
done
```
> Note：Run `echo 3 > /proc/irq/$irq/smp_affinity` if bind to CPU0 and CPU1.
Then run SRS on other CPUs except CPU0:
```bash
taskset -a -p 0xfe $(cat objs/srs.pid)
```
You can improve about 20% performance by bind softirq to CPU0.
You can also setup in the startup script.
## Process Priority
You can set SRS to run in higher priority:
```bash
renice -n -15 -p $(pidof srs)
```
> Note: The value of nice is `-20` to `19` and default is `0`.
To check the priority, which is the `NI` field of top:
```bash
top -n1 -p $(pidof srs)
# PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
# 1505 root 5 -15 519920 421556 4376 S 66.7 5.3 4:41.12 srs
```
## Performance Banchmark
The performance benchmark for SRS, compare with nginx-rtmp single process.
Provides detail benchmark steps.
The latest data, read [performance](https://github.com/ossrs/srs/tree/develop#performance).
### Hardware
The client and server use lo net interface to test:
* Hardware: VirtualBox on ThinkPad T430
* OS: CentOS 6.0 x86_64 Linux 2.6.32-71.el6.x86_64
* CPU: 3 Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz
* Memory: 2007MB
### OS
Login as root, set the fd limits:
* Set limit: `ulimit -HSn 10240`
* View the limit:
```bash
[root@dev6 ~]# ulimit -n
10240
```
* Restart SRS：`sudo /etc/init.d/srs restart`
### NGINX-RTMP
NGINX-RTMP version and build command.
* NGINX: nginx-1.5.7.tar.gz
* NGINX-RTMP: nginx-rtmp-module-1.0.4.tar.gz
* Read [nginx-rtmp](http://download.csdn.net/download/winlinvip/6795467)
* Build:
```bash
./configure --prefix=`pwd`/../_release \
--add-module=`pwd`/../nginx-rtmp-module-1.0.4 \
--with-http_ssl_module && make && make install
```
* Config nginx：`_release/conf/nginx.conf`
```bash
user root;
worker_processes 1;
events {
worker_connections 10240;
}
rtmp{
server{
listen 19350;
application live{
live on;
}
}
}
```
* The limit of fd:
```bash
[root@dev6 nginx-rtmp]# ulimit -n
10240
```
* Start: ``./_release/sbin/nginx``
* Check nginx started:
```bash
[root@dev6 nginx-rtmp]# netstat -anp|grep 19350
tcp 0 0 0.0.0.0:19350 0.0.0.0:* LISTEN 6486/nginx
```
### SRS
SRS version and build.
* SRS: [SRS 0.9](https://github.com/ossrs/srs/releases/tag/0.9)
* Build: ``./configure && make``
* Config SRS：`conf/srs.conf`
```bash
listen 1935;
max_connections 10240;
vhost __defaultVhost__ {
gop_cache on;
forward 127.0.0.1:19350;
}
```
* Check limit fds:
```bash
[root@dev6 trunk]# ulimit -n
10240
```
* Start SRS: ``nohup ./objs/srs -c conf/srs.conf >/dev/null 2>&1 &``
* Check SRS started:
```bash
[root@dev6 trunk]# netstat -anp|grep "1935 "
tcp 0 0 0.0.0.0:1935 0.0.0.0:* LISTEN 6583/srs
```
### Publish and Play
Use centos to publish RTMP:
* Start FFMPEG:
```bash
for((;;)); do \
./objs/ffmpeg/bin/ffmpeg \
-re -i doc/source.flv \
-acodec copy -vcodec copy \
-f flv rtmp://127.0.0.1:1935/live/livestream; \
sleep 1;
done
```
* SRS RTMP stream URL: `rtmp://192.168.2.101:1935/live/livestream`
* Nginx-RTMP stream URL: `rtmp://192.168.2.101:19350/live/livestream`
### Client
The RTMP load test tool, read [srs-bench](https://github.com/ossrs/srs-bench)
The sb_rtmp_load used to test RTMP load, support 800-3k concurrency for each process.
* Build: `./configure && make`
* Start: `./objs/sb_rtmp_load -c 800 -r <rtmp_url>`
### Record Data
Record data before test:
* Use top command：
```bash
srs_pid=$(pidof srs); \
nginx_pid=`ps aux|grep nginx|grep worker|awk '{print $2}'`; \
load_pids=`ps aux|grep objs|grep sb_rtmp_load|awk '{ORS=",";print $2}'`; \
top -p $load_pids$srs_pid,$nginx_pid
```
* The connections:
```bash
srs_connections=`netstat -anp|grep srs|grep ESTABLISHED|wc -l`; \
nginx_connections=`netstat -anp|grep nginx|grep ESTABLISHED|wc -l`; \
echo "srs_connections: $srs_connections"; \
echo "nginx_connections: $nginx_connections";
```
* The bandwidth in NBps:
```bash
[root@dev6 nginx-rtmp]# dstat -N lo 30
----total-cpu-usage---- -dsk/total- -net/lo- ---paging-- ---system--
usr sys idl wai hiq siq| read writ| recv send| in out | int csw
0 0 96 0 0 3| 0 0 |1860B 58k| 0 0 |2996 465
0 1 96 0 0 3| 0 0 |1800B 56k| 0 0 |2989 463
0 0 97 0 0 2| 0 0 |1500B 46k| 0 0 |2979 461
```
* The table
| Server | CPU | Mem | Conn | ENbps | ANbps | sb | Lat |
| ------ | --- | ------- | ------ | ---------- | ---------- | ------ | -------- |
| SRS | 1.0% | 3MB | 3 | - | - | - | 0.8s |
| nginx-rtmp | 0.7% | 8MB | 2 | - | - | - | 0.8s |
Memory(Mem): The memory usage in MB.
Clients(Conn): The connections/clients to server.
ExpectNbps(ENbps): The expect network bandwidth in Xbps.
ActualNbps(ANBps): The actual network bandwidth in Xbps.
srs-bench(srs-bench/sb): The mock benchmark client tool.
Latency(Lat): The latency of client.
### Benchmark SRS
Let's start performance benchmark.
* Start 500 clients
```bash
./objs/sb_rtmp_load -c 500 -r rtmp://127.0.0.1:1935/live/livestream >/dev/null &
```
* The data:
| Server | CPU | Mem | Conn | ENbps | ANbps | sb | Lat |
| ------ | --- | ------- | ------ | ---------- | ---------- | ------ | -------- |
| SRS | 9.0% | 8MB | 503 | 100Mbps | 112Mbps | 12.6% | 0.8s |
* The data for 1000 clients:
| Server | CPU | Mem | Conn | ENbps | ANbps | sb | Lat |
| ------ | --- | ------- | ------ | ---------- | ---------- | ------ | -------- |
| SRS | 23.6% | 13MB | 1003 | 200Mbps | 239Mbps | 16.6% | 0.8s |
* The data for 1500 clients:
| Server | CPU | Mem | Conn | ENbps | ANbps | sb | Lat |
| ------ | --- | ------- | ------ | ---------- | ---------- | ------ | -------- |
| SRS | 38.6% | 20MB | 1503 | 300Mbps | 360Mbps | 17% | 0.8s |
* The data for 2000 clients:
| Server | CPU | Mem | Conn | ENbps | ANbps | sb | Lat |
| ------ | --- | ------- | ------ | ---------- | ---------- | ------ | -------- |
| SRS | 65.2% | 34MB | 2003 | 400Mbps | 480Mbps | 22% | 0.8s |
* The data for 2500 clients:
| Server | CPU | Mem | Conn | ENbps | ANbps | sb | Lat |
| ------ | --- | ------- | ------ | ---------- | ---------- | ------ | -------- |
| SRS | 72.9% | 38MB | 2503 | 500Mbps | 613Mbps | 24% | 0.8s |
### Benchmark NginxRTMP
Let's start performance benchmark.
* Start 500 clients:
```bash
./objs/sb_rtmp_load -c 500 -r rtmp://127.0.0.1:19350/live/livestream >/dev/null &
```
* The data for 500 clients:
| Server | CPU | Mem | Conn | ENbps | ANbps | sb | Lat |
| ------ | --- | ------- | ------ | ---------- | ---------- | ------ | -------- |
| nginx-rtmp | 8.3% | 13MB | 502 | 100Mbps | 120Mbps | 16.3% | 0.8s |
* The data for 1000 clients:
| Server | CPU | Memory | Clients | ExpectNbps | ActualNbps | srs-bench | Latency|
| ------ | --- | ------- | ------ | ---------- | ---------- | ------ | -------- |
| nginx-rtmp | 27.3% | 19MB | 1002 | 200Mbps | 240Mbps | 30% | 0.8s |
* The data for 1500 clients:
| Server | CPU | Mem | Conn | ENbps | ANbps | sb | Lat |
| ------ | --- | ------- | ------ | ---------- | ---------- | ------ | -------- |
| nginx-rtmp | 42.3% | 25MB | 1502 | 300Mbps | 400Mbps | 31% | 0.8s |
* The data for 2000 clients:
| Server | CPU | Mem | Conn | ENbps | ANbps | sb | Lat |
| ------ | --- | ------- | ------ | ---------- | ---------- | ------ | -------- |
| nginx-rtmp | 48.9% | 31MB | 2002 | 400Mbps | 520Mbps | 33% | 0.8s |
* The data for 2500 clients:
| Server | CPU | Mem | Conn | ENbps | ANbps | sb | Lat |
| ------ | --- | ------- | ------ | ---------- | ---------- | ------ | -------- |
| nginx-rtmp | 74.2% | 37MB | 2502 | 500Mbps | 580Mbps | 35% | 0.8s |
### Performance Compare
| Server | CPU | Mem | Conn | ENbps | ANbps | sb | Lat |
| ------ | --- | ------- | ------ | ---------- | ---------- | ------ | -------- |
| nginx-rtmp | 8.3% | 13MB | 502 | 100Mbps | 120Mbps | 16.3% | 0.8s |
| SRS | 9.0% | 8MB | 503 | 100Mbps | 112Mbps | 12.6% | 0.8s |
| nginx-rtmp | 27.3% | 19MB | 1002 | 200Mbps | 240Mbps | 30% | 0.8s |
| SRS | 23.6% | 13MB | 1003 | 200Mbps | 239Mbps | 16.6% | 0.8s |
| nginx-rtmp | 42.3% | 25MB | 1502 | 300Mbps | 400Mbps | 31% | 0.8s |
| SRS | 38.6% | 20MB | 1503 | 300Mbps | 360Mbps | 17% | 0.8s |
| nginx-rtmp | 48.9% | 31MB | 2002 | 400Mbps | 520Mbps | 33% | 0.8s |
| SRS | 65.2% | 34MB | 2003 | 400Mbps | 480Mbps | 22% | 0.8s |
| nginx-rtmp | 74.2% | 37MB | 2502 | 500Mbps | 580Mbps | 35% | 0.8s |
| SRS | 72.9% | 38MB | 2503 | 500Mbps | 613Mbps | 24% | 0.8s |
### Performance Banchmark 4k
The performance is refined to support about 4k clients.
```
[winlin@dev6 srs]$ ./objs/srs -v
0.9.130
```
```
top - 19:52:35 up 1 day, 11:11, 8 users, load average: 1.20, 1.05, 0.92
Tasks: 171 total, 4 running, 167 sleeping, 0 stopped, 0 zombie
Cpu0 : 26.0%us, 23.0%sy, 0.0%ni, 34.0%id, 0.3%wa, 0.0%hi, 16.7%si, 0.0%st
Cpu1 : 26.4%us, 20.4%sy, 0.0%ni, 34.1%id, 0.7%wa, 0.0%hi, 18.4%si, 0.0%st
Cpu2 : 22.5%us, 15.4%sy, 0.0%ni, 45.3%id, 1.0%wa, 0.0%hi, 15.8%si, 0.0%st
Mem: 2055440k total, 1972196k used, 83244k free, 136836k buffers
Swap: 2064376k total, 3184k used, 2061192k free, 926124k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
17034 root 20 0 415m 151m 2040 R 94.4 7.6 14:29.33 ./objs/srs -c console.conf
1063 winlin 20 0 131m 68m 1336 S 17.9 3.4 54:05.77 ./objs/sb_rtmp_load -c 800 -r rtmp://127.0.0.1:1935/live/livestream
1011 winlin 20 0 132m 68m 1336 R 17.6 3.4 54:45.53 ./objs/sb_rtmp_load -c 800 -r rtmp://127.0.0.1:1935/live/livestream
18736 winlin 20 0 113m 48m 1336 S 17.6 2.4 1:37.96 ./objs/sb_rtmp_load -c 800 -r rtmp://127.0.0.1:1935/live/livestream
1051 winlin 20 0 131m 68m 1336 S 16.9 3.4 53:25.04 ./objs/sb_rtmp_load -c 800 -r rtmp://127.0.0.1:1935/live/livestream
18739 winlin 20 0 104m 39m 1336 R 15.6 2.0 1:25.71 ./objs/sb_rtmp_load -c 800 -r rtmp://127.0.0.1:1935/live/livestream
```
```
[winlin@dev6 ~]$ dstat -N lo 30
----total-cpu-usage---- -dsk/total- ---net/lo-- ---paging-- ---system--
usr sys idl wai hiq siq| read writ| recv send| in out | int csw
3 2 92 0 0 3| 11k 27k| 0 0 | 1B 26B|3085 443
32 17 33 0 0 17| 273B 60k| 69M 69M| 0 0 |4878 6652
34 18 32 0 0 16| 0 38k| 89M 89M| 0 0 |4591 6102
35 19 30 0 0 17| 137B 41k| 91M 91M| 0 0 |4682 6064
33 17 33 0 0 17| 0 31k| 55M 55M| 0 0 |4920 7785
33 18 31 0 0 17|2867B 34k| 90M 90M| 0 0 |4742 6530
32 18 33 0 0 17| 0 31k| 66M 66M| 0 0 |4922 7666
33 17 32 0 0 17| 137B 39k| 65M 65M| 0 0 |4841 7299
35 18 30 0 0 17| 0 28k| 100M 100M| 0 0 |4754 6752
32 17 33 0 0 18| 0 41k| 44M 44M| 0 0 |5130 8251
34 18 32 0 0 16| 0 30k| 104M 104M| 0 0 |4456 5718
```
![SRS 4k](/img/doc-advanced-guides-performance-001.png)
### Performance Banchmark 6k
SRS2.0.15, not SRS1.0, performance is refined to support 6k clients.
That is 4Gbps for 522kbps bitrate, for a single SRS process. Read https://github.com/ossrs/srs/issues/194
### Performance Banchmark 7.5k
SRS2.0.30 refined to support 7.5k clients, read https://github.com/ossrs/srs/issues/217
Winlin 2014.11
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/performance)

202
trunk/3rdparty/srs-docs/doc/raspberrypi.md vendored Normal file
View File

@ -0,0 +1,202 @@
---
title: RaspBerryPi
sidebar_label: RaspBerryPi
hide_title: false
hide_table_of_contents: false
---
# Performance benchmark for SRS on RaspberryPi
SRS can running on armv6(RaspberryPi) or armv7(Android).
The bellow data show the performance benchmark.
## Install SRS
Download the binary for armv6 from [Github](http://ossrs.net/srs.release/releases/)
or [SRS Server](http://ossrs.net/srs/releases/)
## RaspberryPi
The hardware of raspberrypi:
* [RaspberryPi](http://item.jd.com/1014155.html)：Type B
* <strong>SoC</strong> BroadcomBCM2835(CPU,GPU,DSP,SDRAM,USB)
* <strong>CPU</strong> ARM1176JZF-S(ARM11) 700MHz
* <strong>GPU</strong> Broadcom VideoCore IV, OpenGL ES 2.0, 1080p 30 h.264/MPEG-4 AVC decoder
* <strong>RAM</strong> 512MByte
* <strong>USB</strong> 2 x USB2.0
* <strong>VideoOutput</strong> Composite RCA(PAL&NTSC), HDMI(rev 1.3&1.4), raw LCD Panels via DSI 14 HDMI resolution from 40x350 to 1920x1200 plus various PAL and NTSC standards
* <strong>AudioOutput</strong> 3.5mm, HDMI
* <strong>Storage</strong> SD/MMC/SDIO socket
* <strong>Network</strong> 10/100 ethernet
* <strong>Device</strong> 8xGPIO, UART, I2C, SPI bus, +3.3V, +5V, ground(nagetive)
* <strong>Power</strong> 700mA(3.5W) 5V
* <strong>Size</strong> 85.60 x 53.98 mm(3.370 x 2.125 in)
* <strong>OS</strong> Debian GNU/linux, Fedora, Arch Linux ARM, RISC OS, XBMC
Software:
* RaspberryPi img：2014-01-07-wheezy-raspbian.img
* <strong>uname</strong>: Linux raspberrypi 3.10.25+ #622 PREEMPT Fri Jan 3 18:41:00 GMT 2014 armv6l GNU/Linux
* <strong>cpu</strong>: arm61
* <strong>Server</strong>: srs 0.9.38
* <strong>ServerType</strong>: raspberry pi
* <strong>Client</strong>：[srs-bench](https://github.com/ossrs/srs-bench)
* <strong>ClientType</strong>: Virtual Machine Centos6
* <strong>Play</strong>: PC win7, flash
* <strong>Network</strong>: 100Mbps
Stream information:
* Video Bitrate: 200kbps
* Resolution: 768x320
* Audio Bitrate: 30kbps
For arm [SRS: arm](./arm.md#raspberrypi)
## OS settings
Login as root, set the fd limits:
* Set limit: `ulimit -HSn 10240`
* View the limit:
```bash
[root@dev6 ~]# ulimit -n
10240
```
* Restart SRS：`sudo /etc/init.d/srs restart`
## Publish and Play
Use centos to publish to SRS:
* Start FFMPEG:
```bash
for((;;)); do \
./objs/ffmpeg/bin/ffmpeg \
-re -i doc/source.flv \
-acodec copy -vcodec copy \
-f flv rtmp://192.168.1.105:1935/live/livestream; \
sleep 1;
done
```
* Play RTMP: `rtmp://192.168.1.105:1935/live/livestream`
* Online Play: [Online Player](http://localhost:8080/players/srs_player.html?autostart=true&stream=livestream.flv&port=8080&schema=http)
## Client
The RTMP load test tool, read [srs-bench](https://github.com/ossrs/srs-bench)
The sb_rtmp_load used to test RTMP load, support 800-3k concurrency for each process.
* Build: `./configure && make`
* Start: `./objs/sb_rtmp_load -c 800 -r <rtmp_url>`
## Record Data
Record data before test:
* The cpu for SRS:
```bash
pid=`ps aux|grep srs|grep objs|awk '{print $2}'` && top -p $pid
```
* The cpu for srs-bench:
```bash
pid=`ps aux|grep load|grep rtmp|awk '{print $2}'` && top -p $pid
```
* The connections:
```bash
for((;;)); do \
srs_connections=`sudo netstat -anp|grep 1935|grep ESTABLISHED|wc -l`; \
echo "srs_connections: $srs_connections"; \
sleep 5; \
done
```
* The bandwidth in NBps:
```bash
[winlin@dev6 ~]$ dstat 30
----total-cpu-usage---- -dsk/total- -net/lo- ---paging-- ---system--
usr sys idl wai hiq siq| read writ| recv send| in out | int csw
0 0 96 0 0 3| 0 0 |1860B 58k| 0 0 |2996 465
0 1 96 0 0 3| 0 0 |1800B 56k| 0 0 |2989 463
0 0 97 0 0 2| 0 0 |1500B 46k| 0 0 |2979 461
```
* The table
| Server | CPU | Mem | Conn | ENbps | ANbps | sb | Lat |
| ------ | --- | ------ | ------- | ---------- | ---------- | ------- | ------- |
| SRS | 1.0% | 3MB | 3 | - | - | - | 0.8s |
Memory(Mem): The memory usage for server.
Clients(Conn): The cocurrency connections to server.
ExpectNbps(ENbps): The expect network bandwidth in Xbps.
ActualNbps(ANbps): The actual network bandwidth in Xbps.
## Benchmark SRS 0.9.38
Let's start performance benchmark.
* The data for 10 clients:
```bash
./objs/sb_rtmp_load -c 10 -r rtmp://192.168.1.105:1935/live/livestream >/dev/null &
```
| Server | CPU | Mem | Conn | ENbps | ANbps | sb | Lat |
| ------ | --- | ------ | ------- | ---------- | ---------- | ------- | ------- |
| SRS | 17% | 1.4MB | 11 | 2.53Mbps | 2.6Mbps | 1.3% | 1.7s |
* The data for 20 clients:
| Server | CPU | Mem | Conn | ENbps | ANbps | sb | Lat |
| ------ | --- | ------ | ------- | ---------- | ---------- | ------- | ------- |
| SRS | 23% | 2MB | 21 | 4.83Mbps | 5.5Mbps | 2.3% | 1.5s |
* The data for 30 clients:
| Server | CPU | Mem | Conn | ENbps | ANbps | sb | Lat |
| ------ | --- | ------ | ------- | ---------- | ---------- | ------- | ------- |
| SRS | 50% | 4MB | 31 | 7.1Mbps | 8Mbps | 4% | 2s |
The summary for RaspberryPi Type B, 230kbps performance:
| Server | CPU | Mem | Conn | ENbps | ANbps | sb | Lat |
| ------ | --- | ------ | ------- | ---------- | ---------- | ------- | ------- |
| SRS | 17% | 1.4MB | 11 | 2.53Mbps | 2.6Mbps | 1.3% | 1.7s |
| SRS | 23% | 2MB | 21 | 4.83Mbps | 5.5Mbps | 2.3% | 1.5s |
| SRS | 50% | 4MB | 31 | 7.1Mbps | 8Mbps | 4% | 2s |
## Benchmark SRS 0.9.72
The benchmark for RTMP SRS 0.9.72.
| Server | CPU | Mem | Conn | ENbps | ANbps | sb | Lat |
| ------ | --- | ------ | ------- | ---------- | ---------- | ------- | ------- |
| SRS | 5% | 2MB | 2 | 1Mbps | 1.2Mbps | 0% | 1.5s |
| SRS | 20% | 2MB | 12 | 6.9Mbps | 6.6Mbps | 2.8% | 2s |
| SRS | 36% | 2.4MB | 22 | 12.7Mbps | 12.9Mbps | 2.3% | 2.5s |
| SRS | 47% | 3.1MB | 32 | 18.5Mbps | 18.5Mbps | 5% | 2.0s |
| SRS | 62% | 3.4MB | 42 | 24.3Mbps | 25.7Mbps | 9.3% | 3.4s |
| SRS | 85% | 3.7MB | 52 | 30.2Mbps | 30.7Mbps | 13.6% | 3.5s |
## cubieboard benchmark
No data.
Winlin 2014.11
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/raspberrypi)

51
trunk/3rdparty/srs-docs/doc/reload.md vendored Normal file
View File

@ -0,0 +1,51 @@
---
title: Reload
sidebar_label: Reload
hide_title: false
hide_table_of_contents: false
---
# Reload
Almost all features of SRS support reload, donot disconnect
all connection and apply the new config.
## NotSupportedFeatures
The bellow features can not reload:
* deamon: whether start as deamon mode.
* mode: the mode of vhost.
The daemon never support reload.
The mode of vhost, to make the vhost origin or edge, should never directly
change the mode, because of:
* The origin and edge switch is too complex.
* The origin always put in a device group, never change to edge actually.
* The upnode or origin restart have no effect to user, edge will retry.
A workaround to modify the mode of vhost:
* Delete the vhost and reload.
* Ensure the vhost is deleted, for the reload is async.
* Add vhost with new mode, then reload.
## Use Scenario
The use scenario of reload:
* Donot restart server to apply new config, only `killall -1 srs`.
* Donot disconnect user connections.
## Usage
The usage of reload: `killall -1 srs`
Or send signal to process: `kill -1 7635`
Or use SRS scripts: `/etc/init.d/srs reload`
Winlin 2014.11
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/reload)

93
trunk/3rdparty/srs-docs/doc/resource.md vendored Normal file
View File

@ -0,0 +1,93 @@
---
title: Ports and Resource
sidebar_label: Ports and Resource
hide_title: false
hide_table_of_contents: false
---
# Resources
The resources of SRS.
## Ports
The ports used by SRS, kernel services:
* `tcp://1935`, for [RTMP live streaming server](./rtmp.md).
* `tcp://1985`, HTTP API server, for [HTTP-API](./http-api.md), [WebRTC](./webrtc.md), etc.
* `tcp://8080`, HTTP live streaming server, [HTTP-FLV](./flv.md), [HLS](./hls.md) as such.
* `udp://8000`, [WebRTC Media](./webrtc.md) server.
For optional HTTPS services, which might be provided by other web servers:
* `tcp://8088`, HTTPS live streaming server.
* `tcp://1990`, HTTPS API server.
For optional stream converter services, to push streams to SRS:
* `udp://8935`, Stream Converter: [Push MPEGTS over UDP](./streamer.md#push-mpeg-ts-over-udp) server.
* `tcp://8936`, Stream Converter: [Push HTTP-FLV](./streamer.md#push-http-flv-to-srs) server.
* `udp://10080`, Stream Converter: [Push SRT Media](https://github.com/ossrs/srs/issues/1147#issuecomment-577469119) server.
For external services to work with SRS:
* `udp://1989`, [WebRTC Signaling](https://github.com/ossrs/signaling#usage) server.
## APIs
The API used by SRS:
* `/api/v1/` The HTTP API path.
* `/rtc/v1/` The HTTP API path for RTC.
* `/sig/v1/` The [demo signaling](https://github.com/ossrs/signaling) API.
Other API used by [ossrs.net](https://ossrs.net):
* `/gif/v1` The statistic API.
* `/service/v1/` The latest available version API.
* `/ws-service/v1/` The latest available version API, by websocket.
* `/im-service/v1/` The latest available version API, by IM.
* `/code-service/v1/` The latest available version API, by Code verification.
The statistic path for [ossrs.net](https://ossrs.net):
* `/srs/xxx` The GitHub pages for [srs](https://github.com/ossrs/srs)
* `/release/xxx` The pages for [ossrs.net](https://ossrs.net)
* `/console/xxx` The pages for [console](http://ossrs.net/console/)
* `/player/xxx` The pages for [players and publishers](http://ossrs.net/players/)
* `/k8s/xxx` The template and repository deploy by K8s, like [srs-k8s-template](https://github.com/ossrs/srs-k8s-template)
## Mirrors
[Gitee](https://gitee.com/ossrs/srs), [the GIT usage](./git.md)
```
git clone https://gitee.com/ossrs/srs.git &&
cd srs && git remote set-url origin https://github.com/ossrs/srs.git && git pull
```
> Remark: For users in China, recomment to use mirror from CSDN or OSChina, because they are much faster.
[Gitlab](https://gitlab.com/winlinvip/srs-gitlab), [the GIT usage](./git.md)
```
git clone https://gitlab.com/winlinvip/srs-gitlab.git srs &&
cd srs && git remote set-url origin https://github.com/ossrs/srs.git && git pull
```
[Github](https://github.com/ossrs/srs), [the GIT usage](./git.md)
```
git clone https://github.com/ossrs/srs.git
```
| Branch | Cost | Size | CMD |
| --- | --- | --- | --- |
| 3.0release | 2m19.931s | 262MB | git clone -b 3.0release https://gitee.com/ossrs/srs.git |
| 3.0release | 0m56.515s | 95MB | git clone -b 3.0release --depth=1 https://gitee.com/ossrs/srs.git |
| develop | 2m22.430s | 234MB | git clone -b develop https://gitee.com/ossrs/srs.git |
| develop | 0m46.421s | 42MB | git clone -b develop --depth=1 https://gitee.com/ossrs/srs.git |
| min | 2m22.865s | 217MB | git clone -b min https://gitee.com/ossrs/srs.git |
| min | 0m36.472s | 11MB | git clone -b min --depth=1 https://gitee.com/ossrs/srs.git |
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/resource)

109
trunk/3rdparty/srs-docs/doc/reuse-port.md vendored Normal file
View File

@ -0,0 +1,109 @@
---
title: Reuse Port
sidebar_label: Reuse Port
hide_title: false
hide_table_of_contents: false
---
# Reuse Port
You can use REUSE_PORT for different use scenarios.
## For Edge Server
The [performance of SRS2](https://github.com/ossrs/srs/tree/2.0release#performance) is improved huge, but is it enough?
Absolutely NOT! In SRS3, we provide [OriginCluster](./sample-origin-cluster.md) for multiple origin servers to work together,
and [go-oryx](https://github.com/ossrs/go-oryx) as a tcp proxy for edge server, and these are not good enough, so we support
SO_REUSEPORT feature for multiple processes edge server.
![](/img/doc-guides-reuse-port-001.png)
> Remark: The SO_REUSEPORT requires Linux Kernel 3.9+, so you should upgrade your kernel for CentOS6, or you could choose Ubuntu20.
First, we start a edge server which listen at 1935:
```
./objs/srs -c conf/edge.conf
```
Then, at the same server, start another edge server which also listen at 1935:
```
./objs/srs -c conf/edge2.conf
```
> Note: They should use different pid file, or it will fail to start the second edge server.
There are two SRS edge servers:
```
[root@bf2e88b31f9b trunk]# ps aux|grep srs
root 381 0.1 0.0 19888 5752 pts/2 S+ 08:03 0:01 ./objs/srs -c conf/edge.conf
root 383 0.0 0.0 19204 5468 pts/1 S+ 08:04 0:00 ./objs/srs -c conf/edge2.conf
[root@bf2e88b31f9b trunk]# lsof -p 381
srs 381 root 7u IPv6 18835 0t0 TCP *:macromedia-fcs (LISTEN)
[root@bf2e88b31f9b trunk]# lsof -p 383
srs 383 root 7u IPv6 17831 0t0 TCP *:macromedia-fcs (LISTEN)
```
After that, we start the origin server, from which these edge server to pull streams:
```
./objs/srs -c conf/origin.conf
```
Finally, we could publish to origin/edge, and play stream from each edge server:
```
for((;;)); do \
./objs/ffmpeg/bin/ffmpeg -re -i ./doc/source.flv \
-c copy \
-f flv rtmp://192.168.1.170/live/livestream; \
sleep 1; \
done
```
Use VLC to play the RTMP stream: `rtmp://192.168.1.170:1935/live/livestream`
## For Origin Server
You can use REUSE_PORT in Origin Server. Each Origin Server is isolated, only works for HLS:
```
+-----------------+
Client --->-- + Origin Servers +------> Player
+-----------------+
```
> Note: If need to deliver RTMP or HTTP-FLV, pelease use [OriginCluster](./sample-origin-cluster.md).
Start the first Origin Server, listen at `1935` and `8080`, covert RTMP to HLS:
```bash
./objs/srs -c conf/origin.hls.only1.conf
```
Start the second Origin Server, listen at `1935` and `8080`, covert RTMP to HLS:
```bash
./objs/srs -c conf/origin.hls.only2.conf
```
Publish stream to origin, system will select a random Origin Server:
```bash
./objs/ffmpeg/bin/ffmpeg -re -i ./doc/source.flv -c copy -f flv rtmp://localhost/live/livestream1
```
Publish another stream to origin, system will select a random Origin Server:
```bash
./objs/ffmpeg/bin/ffmpeg -re -i ./doc/source.flv -c copy -f flv rtmp://localhost/live/livestream2
```
> Note: It works only for HLS, please use [OriginCluster](./sample-origin-cluster.md) for RTMP or HTTP-FLV.
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/reuse-port)

93
trunk/3rdparty/srs-docs/doc/rtmp-atc.md vendored Normal file
View File

@ -0,0 +1,93 @@
---
title: RTMP ATC
sidebar_label: RTMP ATC
hide_title: false
hide_table_of_contents: false
---
# ATC Deploy
How to deploy RTMP fault backup? When origin for edge restart, edge will
switch to another origin, so it is easy to config fault tolerance for edge,
only need to specifies multiple origin servers.
How to deploy HLS fault backup? When edge can not got a piece of ts, it
will fetch from another origin server, so the ts in these two server must
be absolutely equals. We must use atc for HLS/HDS which over http file stream.
For the deploy of HDS/HLS, read [Adobe: HDS/HLS fault backup](http://www.adobe.com/cn/devnet/adobe-media-server/articles/varnish-sample-for-failover.html):
```bash
+----------+ +----------+
+--ATC->-+ server +--ATC->-+ packager +-+ +---------+
+----------+ | RTMP +----------+ RTMP +----------+ | | Reverse | +-------+
| encoder +->-+ +->-+ Proxy +-->-+ CDN +
+----------+ | +----------+ +----------+ | | (nginx) | +-------+
+--ATC->-+ server +--ATC->-+ packager +-+ +---------+
RTMP +----------+ RTMP +----------+
```
The RTMP is in ATC, the absolute time, so server or other tools can output
HLS in multiple tools.
## Config ATC on SRS
ATC of SRS is default off, the RTMP timestamp to client always start at 0.
```bash
vhost __defaultVhost__ {
# for play client, both RTMP and other stream clients,
# for instance, the HTTP FLV stream clients.
play {
# 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
#
# default: off
atc off;
}
}
```
## ATC for Adobe Flash Player
When ATC is on, flash will start play ok when:
* sequence header: The timstamp of sequence header must equals to the first packet.
* metadata: The timstamp of metadata must equals to the first packet.
We test the flash player, it ok to play the RTMP stream with or without ATC.
## ATC for encoder
The encoder can control the atc of SRS, when encoder write a field
"bravo_atc":"true".
We can disable this feature:
```bash
vhost atc.srs.com {
# for play client, both RTMP and other stream clients,
# for instance, the HTTP FLV stream clients.
play {
# 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.
# default: off
atc_auto off;
}
}
```
Winlin 2014.11
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/rtmp-atc)

33
trunk/3rdparty/srs-docs/doc/rtmp-handshake.md vendored Normal file
View File

@ -0,0 +1,33 @@
---
title: RTMP Handshake
sidebar_label: RTMP Handshake
hide_title: false
hide_table_of_contents: false
---
# RTMP Handshake
The rtmp specification 1.0 defines the RTMP handshake:
* c0/s0: 1 bytes, specifies the protocol is RTMP or RTMPE/RTMPS.
* c1/s1: 1536 bytes, first 4 bytes is time, next 4 bytes is 0x00, 1528 random bytes.
* c2/s2: 1536 bytes, first 4 bytes is time echo, next 4 bytes is time, 1528 bytes c2==s1 and s2==c1.
This is the simple handshake, the standard handshake, and the FMLE use this handshake.
While the server connected by flash player only support simple handshake, the flash player can only play the vp6 codec, and do not support h.264+aac. Adobe changed the simple handshake to encrypted complex handshake, see: [Changed Handshake of RTMP](http://blog.csdn.net/win_lin/article/details/13006803)
The handshake summary: |
| Handshake | Depends | Player | Client | SRS | Use Scenario |
| ---- | ----- | --------------------- | -------- | --- | ---- |
| Simple<br/>Standard | No | vp6+mp3/speex | All | Supprted | Encoder, for examle, FMLE, FFMPEG |
| Complex | openssl | vp6+mp3/speex<br/>h264+aac | Flash | Supported | Flash player requires complex handshake to play h.264+aac codec. |
Player(Flash palyer): The supported codec for flash player.
Notes: When compile SRS with SSL, SRS will try complex, then simple.
Winlin 2014.10
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/rtmp-handshake)

92
trunk/3rdparty/srs-docs/doc/rtmp-pk-http.md vendored Normal file
View File

@ -0,0 +1,92 @@
---
title: RTMP vs HTTP
sidebar_label: RTMP vs HTTP
hide_title: false
hide_table_of_contents: false
---
# RTMP PK HTTP
There are two major methods to deliver video over internet, Live and WebRTC.
* Live streaming: [HLS](./hls.md), [RTMP](./rtmp.md) and [HTTP-FLV](./flv.md) for entertainment.
* WebRTC: [RTC](./webrtc.md), for communication.
Ignore other delivery protocol, which is not used on internet:
* UDP: Private protocols, realtime protocol, latence in ms.
* P2P: FlashP2P of Adobe, others are private protocol. Large latence, in minutes.
* RTSP: Private protocol not for internet.
And the protocol base on HTTP:
* HTTP progressive: Ancient protocol, not used now.
* HTTP stream: Support seek in query string, for instance, http://x/x.mp4?start=x.
* HLS: The HLS is developed by Apple. Both Apple and Android support it.
* HDS: The HLS like developed by Adobe, shit.
* DASH: The HLS like developed by some companies, not used in China.
Compare the delivery methods on internet:
* HLS: Apple HLS, for both live and vod.
* HTTP: HTTP stream, private http stream, for vod.
* RTMP: Adobe RTMP, for live stream.
## RTMP
The RTMP is stream protocol, good for:
* Realtime: RTMP latency can be 0.8-3s.
* DRM: RTMPE/RTMPS encrypt protocol.
* Stable for PC flash.
* Server input: The actual industrial standard for encoder to output to server is RTMP.
* Fault Tolerance: The RTMP edge-origin can support fault tolerance for stream protocol.
* Monitor: The stream protocol can be monitored.
RTMP is bad for:
* Complex: RTMP is more complex than HTTP, especially the edge.
* Hard to cache: Must use edge to cache.
## HTTP
The HTTP stream is the vod stream used for some video website:
HTTP is delivery files, good for:
* High performance: There are lots of good HTTP server, such as nginx, squid, traffic server.
* No small piece of file: The large file is good than pieces of file for HTTP cache.
* Firewall traverse: Almost all firewall never block the HTTP protocol.
HTTP is bad for:
* Large lantency: The http stream atleast N10s latency.
* Player does not support: Only PC flash can play http stream. Mobile platform does not support http stream.
## HLS
HLS is the open standard of Apple. HLS is supported by Android3+.
HLS is good for:
* High performance: Same to HTTP stream.
* Firewall traverse: Same to HTTP stream.
* Mobile Platform standard: Apple IOS/OSX, Android and PC/flash support HLS.
HLS is bad for:
* Large lantency: The http stream atleast N10s latency.
* Pieces of file: CDN does not like small file.
## Use Scenario
See [HTTP](./hls.md)
and [RTMP](./rtmp.md)
I recomment to use these delivery protocols in:
* Encoder always output RTMP for internet server.
* Server always accept RTMP from encoder.
* The cluster use RTMP as internal delivery protocol.
* The low latency application on PC: Use flash to play RTMP.
* Application without low latency required: RTMP or HLS.
* The vod stream on PC: Use HLS or HTTP stream.
* Apple IOS/OSX: Always use HLS. Or use library to play RTMP, like [https://www.vitamio.org](https://www.vitamio.org)
* Android: Always use HLS. Or use library to play RTMP.
Winlin 2014.11
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/rtmp-pk-http)

271
trunk/3rdparty/srs-docs/doc/rtmp-url-vhost.md vendored Normal file
View File

@ -0,0 +1,271 @@
---
title: RTMP URL
sidebar_label: RTMP URL
hide_title: false
hide_table_of_contents: false
---
# RTMP URL/Vhost
The url of RTMP is simple, and the vhost is not a new concept, although it's easy to confuse for the fresh.
What is vhost? What is app? Why FMLE should input the app and stream?
Vhost(Virtual Host) is used to seperate customers or businesses.
Let's take a look at the typical use scenaio of vhost.
![](/img/doc-main-concepts-rtmp-url-vhost-001.png)
The benifit of RTMP and HLS, see: [HLS](./hls.md)
## Use Scenario
The use scenario of vhost:
* Multiple customers cloud: For example, CDN(content delivery network) serves multiple customers. How does CDN to seperate customer and stat the data? Maybe stream path is duplicated, for example, live/livestream is the most frequently used app and stream. The vhost, similar to the virtual server, provides abstract for multiple customers.
* Different config: For example, FMLE publish h264+mp3, which should be transcoded to h264+aac. We can use vhost to use different config, h264+mp3 disabled hls while the h264+aac vhost enalbe hls.
In a word, vhost is the element of config, to seperate customer and apply different config.
## Standard RTMP URL
Standard RTMP URL is the most compatible URL, for all servers and players can identify. The RTMP URL is similar to the HTTP URL:
| HTTP | Schema | Host | Port | App | Stream |
| ----- | ----- | ----- | ----| ---- | ---- |
| http://192.168.1.10:80/players/srs_player.html | http | 192.168.1.10 | 80 | players | srs_player.html|
| rtmp://192.168.1.10:1935/live/livestream | rtmp | 192.168.1.10 | 1935 | live | livestream |
It is:
* Schema：The protocol prefix, HTTP/HTTPS for HTTP protocol, and RTMP/RTMPS/RTMPE/RTMPT for RTMP protocol, while the RTMFP is adobe flash p2p protocol.
* Host：The server ip or dns name to connect to. It is dns name for CDN, and the dns name is used as the vhost for the specified customer.
* Port：The tcp port, default 80 for HTTP and 1935 for RTMP.
* Path：The http file path for HTTP.
* App：The application for RTMP, similar to the directory of resource(stream).
* Stream：The stream for RTMP, similar to the resource(file) in specified app.
## NO Vhost
However, most user donot need the vhost, and it's a little complex, so donot use it when you donot need it. Most user actually only need app and stream.
When to use vhost? When you serve 100+ customers and use the same delivery network, they use theire own vhost and can use the sample app and stream.
The common use scenario, for example, if you use SRS to build a video website. So you are the only customer, donot need vhost. Suppose you provides video chat, there are some categories which includes some chat rooms. For example, categories are military, reader, history. The military category has rooms rock, radar; the reader category has red_masion. The config of SRS is very simple:
```bash
listen 1935;
vhost __defaultVhost__ {
}
```
When generate web pages, for instance, military category, all app is `military`. The url of chat room is `rtmp://yourdomain.com/military/rock`, while the encoder publish this stream, and all player play this stream.
The other pages of the military category use the same app name `military`, but use the different stream name, fr example, radar chat room use the stream url `rtmp://yourdomain.com/military/radar`.
When generate the pages, add new stream, the config of SRS no need to change. For example, when add a new chat room cannon, no need to change config of SRS. It is simple enough!
The reader category can use app `reader`, and the `red_mansion` chat room can use the url `rtmp://yourdomain.com/reader/red_mansion`.
## Vhost Use Scenarios
The vhost of RTMP is same to HTTP virtual server. For example, the demo.srs.com is resolve to 192.168.1.10 by dns or hosts:
| HTTP | Host | Port | Vhost |
| --- | --- | --- | ----- |
| http://demo.srs.com:80/players/srs_player.html | 192.168.1.10 | 80 | demo.srs.com |
| rtmp://demo.srs.com:1935/live/livestream | 192.168.1.10 | 1935 | demo.srs.com |
The use scenario of vhost:
* Multiple Customers: When need to serve multiple customers use the same network, for example, cctv and wasu delivery stream on the same CDN, how to seperate them, when they use the same app and stream?
* DNS scheduler: When CDN delivery content, the fast edge for the specified user is resolved for the dns name. We can use vhost as the dns name to scheduler user to different edge.
* Multiple Config sections: Sometimes we need different config, for example, to delivery RTMP for PC and transcode RTMP to HLS for android and IOS, we can use one vhost to delivery RTMP and another for HLS.
### Multiple Customers
For example, we got two customers cctv and wasu, use the same edge server 192.168.1.10, when user access the stream of these two customers:
| RTMP | Host | Port | Vhost | App | Stream |
| --- | --- | -------| ----- | ---| --------|
| rtmp://show.cctv.cn/live/livestream | 192.168.1.10 | 1935 | show.cctv.cn | live | livestream |
| rtmp://show.wasu.cn/live/livestream | 192.168.1.10 | 1935 | show.wasu.cn | live | livestream |
The config on the edge 192.168.1.10, need to config the vhost:
```bash
listen 1935;
vhost show.cctv.cn {
}
vhost show.wasu.cn {
}
```
### DNS GSLB
Please refer to the tech for DNS and CDN.
### Config Unit
For example, two customers cctv and wasu, and cctv needs mininum latency, while wasu needs fast startup.
Then we config the cctv without gop cache, and wasu config with gop cache:
```bash
listen 1935;
vhost show.cctv.cn {
chunk_size 128;
}
vhost show.wasu.cn {
chunk_size 4096;
}
```
These two vhosts is completely isolated.
## Default Vhost
The default vhost is \_\_defaultVhost\_\ introduced by FMS. When mismatch and vhost not found, use the default vhost if configed.
For example, the config of SRS on 192.168.1.10:
```bash
listen 1935;
vhost demo.srs.com {
}
```
Then, when user access the vhost:
* rtmp://demo.srs.com/live/livestream：OK, matched vhost is demo.srs.com.
* rtmp://192.168.1.10/live/livestream：Failed, no matched vhost, and no default vhost.
The rule of default vhost is same to other vhost, the default is used for the vhost not matched and not find.
## Locate Vhost
There are two ways to access the vhost on server:
* DNS name: When access the dns name equals to the vhost, by dns resolve or hosts file, we can access the vhost on server.
* Stream parameters: While publishing or playing stream, the parameter can take the vhost. This needs the server supports this way, for example, SRS can use parameter `?vhost=VHOST` and `?domain=VHOST` to access specified vhost.
For example:
```bash
RTMP URL: rtmp://demo.srs.com/live/livestream
Edge servers: 50 servers
Edge server ip: 192.168.1.100 to 192.168.1.150
Edge SRS config:
listen 1935;
vhost demo.srs.com {
mode remote;
origin: xxxxxxx;
}
```
The ways to access the url on edge servers:
| User | RTMP URL | hosts | Target |
|--------| -------- |----------------------------|--------------------------|
| User | rtmp://demo.srs.com/live/livestream | - | Resolved by DNS |
| DevOps | rtmp://demo.srs.com/live/livestream | 192.168.1.100 demo.srs.com | Connect to 192.168.1.100 |
| DevOps | rtmp://192.168.1.100/live?<br/>vhost=demo.srs.com/livestream | - | Connect to 192.168.1.100 |
| DevOps | rtmp://192.168.1.100/live<br/>...vhost...demo.srs.com/livestream | - | Connect to 192.168.1.100 |
It is sample way to access other servers.
## Parameters in URL
There is no parameters for RTMP URL, similar to query string of HTTP, we can pass parameters in RTMP URL for SRS:
* Vhost：Specifies the vhost in the RTMP URL for SRS.
* Token authentication: Not implements for SRS, while user can specifies the token in the RTMP URL, SRS can fetch the token and verify it on remote authentication server. The token authentication is better and complex than refer authentication.
The parameters in SRS URL:
* `rtmp://192.168.1.100/live/livestream?vhost=demo.srs.com`
* `rtmp://192.168.1.100/live/livestream?domain=demo.srs.com`
* `rtmp://192.168.1.100/live/livestream?token=xxx`
* `rtmp://192.168.1.100/live/livestream?vhost=demo.srs.com&token=xxx`
> Note: FMLE passes the parameters in app, which should not be used now, because it confuses people.
It's also applied to other protocols, for example:
* `http://192.168.1.100/live/livestream.flv?vhost=demo.srs.com&token=xxx`
* `http://192.168.1.100/live/livestream.m3u8?vhost=demo.srs.com&token=xxx`
* `webrtc://192.168.1.100/live/livestream?vhost=demo.srs.com&token=xxx`
> Note: SRT is another story, please read [SRT Parameters](./srt.md) for details.
## URL of SRS
SRS always simplify the problem, never make it more complex.
The RTMP URL of SRS use standard RTMP URL. Generally do not need to modify the url or add parameters in it, except:
* Change vhost: Manually change vhost in RTMP URL for debuging.
* Token authentication: To support token authentication.
Furthermore, recomment user to use one level app and stream, never use multiple level app and stream. For example:
```bash
// Not recomment multiple level app and stream, which confuse people.
rtmp://demo.srs.com/show/live/livestream
rtmp://demo.srs.com/show/live/livestream/2013
```
The srs_player and srs_publisher donot support multiple level app and stream. Both srs_player and srs_publisher make the word behind the last / to stream, the left is tcUrl(vhost/app). For example:
```bash
// For both srs_player and srs_publisher:
// play or publish the following rtmp URL:
rtmp://demo.srs.com/show/live/livestream/2013
schema: rtmp
host/vhost: demo.srs.com
app: show/live/livestream
stream: 2013
```
It simplify the url, the palyer and publisher only need user to input a url, not tcUrl and stream.
The RTMP URL of SRS:
| URL | Description |
| ---- | ------ |
| rtmp://demo.srs.com/live/livestream | Standard RTMP URL |
| rtmp://192.168.1.10/live/livestream?vhost=demo.srs.com | URL specifies vhost |
| rtmp://demo.srs.com/live/livestream?key=ER892ID839KD9D0A1D87D | URL specifies token authentication |
## Example Vhosts in SRS
The full.conf of conf of SRS contains many vhost, which used to show each feature. All features is put into the vhost demo.srs.com:
| Category | Vhost | Description |
| -------- | ----- | ---- |
| RTMP | __defaultVhost__ | Default Vhost, only RTMP.|
| RTMP | chunksize.vhost.com | Sample to set the chunk_size.|
| Forward | same.vhost.forward.vhost.com | Sample for Foward stream to the same vhost.|
| HLS | with-hls.vhost.com | Sample for HLS.|
| HLS | no-hls.vhost.com | Sample to disable the HLS.|
| RTMP | min.delay.com | Sample to config the minimum latency for RTMP.|
| RTMP | refer.anti_suck.com | Sample for Refer anti-suck DRM.|
| RTMP | removed.vhost.com | Sample to disable vhost.|
| Callback | hooks.callback.vhost.com | Sample for http callback.|
| Transcode | mirror.transcode.vhost.com | Sample for transcode, to use the sample filter of FFMPEG.|
| Transcode | crop.transcode.vhost.com | Sample for transcode, to use the crop filter of FFMPEG.|
| Transcode | logo.transcode.vhost.com | Sample for transcode, to use the logo filter of FFMPEG.|
| Transcode | audio.transcode.vhost.com | Sample for transcode, to transcode audio only.|
| Transcode | copy.transcode.vhost.com | Sample for transcode, demux and mux.|
| Transcode | all.transcode.vhost.com | Sample for transcode, all transcode features.|
| Transcode | ffempty.transcode.vhost.com | Sample for empty transcode, display the parameters.|
| Transcode | app.transcode.vhost.com | Sample for transcode, transcode specified app streams.|
| Transcode | stream.transcode.vhost.com | Sample for transcode, transcode specified streams. |
The demo.conf of conf of SRS, used for demo of SRS。
| Category | Vhost | Description |
| -------- | ----- | ---- |
| DEMO | players | The vhost for default stream of srs_player, ingest this stream.|
| DEMO | players_pub | The vhost for the srs_publisher to publish stream to.|
| DEMO | players_pub_rtmp | The low latency vhost for demo.|
| DEMO | demo.srs.com | The full features for demo.|
| Others | dev | The vhost for dev, ignore.|
Winlin 2014.10
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/rtmp-url-vhost)

326
trunk/3rdparty/srs-docs/doc/rtmp.md vendored Normal file
View File

@ -0,0 +1,326 @@
---
title: RTMP
sidebar_label: RTMP
hide_title: false
hide_table_of_contents: false
---
# RTMP
RTMP is a basic and de facto standard protocol for live streaming for many years.
However, Adobe neither maintaining RTMP protocol nor contributing as an RFC protocol, so many new features
aren't supported by RTMP, such as HEVC and opus. By March 2023, the [Enhanced RTMP](https://github.com/veovera/enhanced-rtmp)
project is finally set up, supporting HEVC and AV1. SRS and OBS now support [HEVC](https://github.com/veovera/enhanced-rtmp/issues/4)
encoding based on Enhanced RTMP.
For live streaming producing, more recent years, SRT, WebRTC and RIST have been growing rapidly. More and
more devices supported SRT or RIST in live streaming. You're also able to use WebRTC for live streaming.
For live streaming deliver, HLS is the most common used protocol, is supported by almost all CDN and devices
such as PC, iOS, Android and tablet PC. However, HLS has large (3~5s+) latency, you could use HTTP-FLV,
HTTP-TS or WebRTC for low latency use scenario.
Today, RTMP is still used in live streaming producing, for example, OBS publish RTMP stream to YouTube, Twitch, etc.
If you want to ingest stream from a device or publish to a platform, RTMP is the right choice for compatibility.
## Usage
SRS supports RTMP by default, please run by [docker](./getting-started.md) or [build from source](./getting-started-build.md):
```bash
docker run --rm -it -p 1935:1935 ossrs/srs:5 \
./objs/srs -c conf/rtmp.conf
```
Publish stream by [FFmpeg](https://ffmpeg.org/download.html) or [OBS](https://obsproject.com/download) :
```bash
ffmpeg -re -i ./doc/source.flv -c copy -f flv rtmp://localhost/live/livestream
```
Play stream by:
* RTMP (by [VLC](https://www.videolan.org/)): `rtmp://localhost/live/livestream`
SRS supports converting RTMP to other protocols, described in next sections.
## Config
The configuration about RTMP:
```bash
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;
}
}
```
> Note: These configurations are for publish and play. Note that there are some other configurations in other sections,
for example, converting RTMP to [HTTP-FLV](./flv.md#config) or HTTP-TS.
## On Demand Live Streaming
In some situations, you might want to start streaming only when someone starts watching:
1. The streaming source connects to the system but doesn't send the stream to SRS.
2. The player connects to the system and requests to play the stream.
3. The system tells the streaming source to start sending the stream to SRS.
4. The player gets the stream from SRS and plays it.
> Note: The "system" here refers to your business system, not SRS.
This is called "on-demand live streaming" or "on-demand streaming." What happens if the player stops watching?
1. The system needs to tell the streaming source to stop sending the stream.
2. Or, when the last player stops watching, SRS waits for a while and then disconnects the stream.
The second solution is recommended, as it's easier to use. Your system won't need to tell the streaming source to stop, because SRS will disconnect it automatically. You just need to enable the following configuration:
```bash
# 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 more details, you can refer to [this PR](https://github.com/ossrs/srs/pull/3105).
## Converting RTMP to HLS
If want to convert RTMP to HLS, please see [HLS](./hls.md).
## Converting RTMP to HTTP-FLV
If want to convert RTMP to HTTP-FLV or HTTP-TS, please see [HTTP-FLV](./flv.md).
## Converting RTMP to WebRTC
If want to convert RTMP to WebRTC, please see [WebRTC: RTMP to RTC](./webrtc.md#rtmp-to-rtc).
## Converting RTMP to MPEGTS-DASH
If want to convert RTMP to MPEGTS-DASH, please see [DASH](./sample-dash.md).
## Converting SRT to RTMP
If want to convert SRT to RTMP, please see [SRT](./srt.md).
## Converting WebRTC to RTMP
If want to convert WebRTC to RTMP, please see [WebRTC: RTC to RTMP](./webrtc.md#rtc-to-rtmp).
## RTMP Cluster
If want to support a large set of players, please see [Edge Cluster](./edge.md).
If want to support a larget set of publishers or streams, please see [Origin Cluster](./origin-cluster.md).
Note that there are lots of solutions for [load balancing](../../../blog/load-balancing-streaming-servers).
## Low Latency RTMP
If want to support low latency RTMP stream, please see [LowLatency](./low-latency.md).
## Timestamp Jitter
SRS support correcting the timestamp for RTMP, please see [Jitter](./time-jitter.md).
If wants SRS to keep the original timestamp, you can enable [ATC](./rtmp-atc.md).
## Performance
SRS use writev for high performance RTMP delivery, please follow [benchmark](./performance.md##performance-banchmark)
to test it.
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/rtmp)

111
trunk/3rdparty/srs-docs/doc/sample-arm.md vendored Normal file
View File

@ -0,0 +1,111 @@
---
title: ARM Deploy
sidebar_label: ARM Deploy
hide_title: false
hide_table_of_contents: false
---
# SRS ARM deploy example
SRS can deploy on ARM linux. SRS provides srs-librtmp as client library for ARM.
Compile and build ARM, read [SrsLinuxArm](./arm.md),
this artical describes how to deploy.
**Suppose the IP of ubuntu12: 192.168.1.170**
**Suppose the ARM device running in VirtualBox 1935 mapped to Ubuntu12 19350, 22 mapped to 2200.
That is, we can access Ubuntu12 19350 to access the ARM 1935, while the Ubuntu 2200 for ARM 22.**
For more information, read [SrsLinuxArm](./arm.md)
> Note: We need to patch ST, read [ST#1](https://github.com/ossrs/state-threads/issues/1) and [SrsLinuxArm](./arm.md#st-arm-bug-fix)
## Ubuntu12 cross build SRS
### Step 1, get SRS
For detail, read [GIT](./git.md)
```bash
git clone https://github.com/ossrs/srs
cd srs/trunk
```
Or update the exists code:
```bash
git pull
```
### Step 2, build SRS
For detail, read [SrsLinuxArm](./arm.md)
```bash
./configure --cross-build && make
```
> Note: To directly build on ARM device, for example RaspberryPi, use `./configure` instead. For others, please read [SrsLinuxArm](./arm.md)
### Step 3, send SRS to ARM virtual machine
For detail, read [SrsLinuxArm](./arm.md)
```bash
# Password is：root
scp -P 2200 objs/srs root@localhost:~
scp -P 2200 conf/rtmp.conf root@localhost:~
```
## Start SRS on ARM
Login to Ubuntu 2200, we are on ARM:
### Step 4, start SRS
For detail, read [SrsLinuxArm](./arm.md)
```bash
./objs/srs -c conf/rtmp.conf
```
### Step 5, start Encoder
For detail, read [SrsLinuxArm](./arm.md)
Use FFMPEG to publish stream:
```bash
for((;;)); do \
./objs/ffmpeg/bin/ffmpeg -re -i ./doc/source.flv \
-c copy \
-f flv rtmp://192.168.1.170:19350/live/livestream; \
sleep 1; \
done
```
Or use FMLE to publish stream:
```bash
FMS URL: rtmp://192.168.1.170:19350/live
Stream: livestream
```
## User Machine
Play RTMP stream on user machine.
### Step 6, play RTMP stream
RTMP url is: `rtmp://192.168.1.170:19350/live/livestream`
User can use vlc to play the RTMP stream.
Note: Please replace all ip 192.168.1.170 to your server ip.
Winlin 2014.11
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/sample-arm)

109
trunk/3rdparty/srs-docs/doc/sample-dash.md vendored Normal file
View File

@ -0,0 +1,109 @@
---
title: DASH Deploy
sidebar_label: DASH Deploy
hide_title: false
hide_table_of_contents: false
---
# DASH deploy example
Delivery DASH by SRS:
**Suppose the server ip is 192.168.1.170**
## Step 1, get SRS
For detail, read [GIT](./git.md)
```bash
git clone https://github.com/ossrs/srs
cd srs/trunk
```
Or update the exists code:
```bash
git pull
```
## Step 2, build SRS
For detail, read [Build](./install.md)
```bash
./configure && make
```
## Step 3, config SRS
Please read [DASH](https://github.com/ossrs/srs/issues/299#issuecomment-306022840)
Save bellow as config, or use `conf/dash.conf`:
```bash
# conf/dash.conf
listen 1935;
max_connections 1000;
daemon off;
srs_log_tank console;
http_server {
enabled on;
listen 8080;
dir ./objs/nginx/html;
}
vhost __defaultVhost__ {
dash {
enabled on;
dash_fragment 30;
dash_update_period 150;
dash_timeshift 300;
dash_path ./objs/nginx/html;
dash_mpd_file [app]/[stream].mpd;
}
}
```
## Step 4, start SRS
```bash
./objs/srs -c conf/dash.conf
```
> Note: You can also use other web server, such as NGINX, to delivery files of DASH.
## Step 5, start Encoder
Use FFMPEG to publish stream:
```bash
for((;;)); do \
./objs/ffmpeg/bin/ffmpeg -re -i ./doc/source.flv \
-c copy \
-f flv rtmp://192.168.1.170/live/livestream; \
sleep 1; \
done
```
The stream in SRS:
* RTMP url：`rtmp://192.168.1.170/live/livestream`
* DASH url： `http://192.168.1.170:8080/live/livestream.mpd`
## Step 6, play RTMP stream
RTMP url is: `rtmp://192.168.1.170:1935/live/livestream`
User can use vlc to play the RTMP stream.
Note: Please replace all ip 192.168.1.170 to your server ip.
## Step 7, play DASH stream
DASH url： `http://192.168.1.170:8080/live/livestream.mpd`
Please use VLC to play.
Winlin 2020.01
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/sample-dash)

137
trunk/3rdparty/srs-docs/doc/sample-ffmpeg.md vendored Normal file
View File

@ -0,0 +1,137 @@
---
title: Transcode Deploy
sidebar_label: Transcode Deploy
hide_title: false
hide_table_of_contents: false
---
# Transcode deploy example
FFMPEG can used to transcode the live stream, output the other RTMP server.
For detail, read [FFMPEG](./ffmpeg.md).
**Suppose the server ip is 192.168.1.170**
## Step 1, get SRS
For detail, read [GIT](./git.md)
```bash
git clone https://github.com/ossrs/srs
cd srs/trunk
```
Or update the exists code:
```bash
git pull
```
## Step 2, build SRS
For detail, read [Build](./install.md)
```bash
./configure --ffmpeg-tool=on && make
```
## Step 3, config file
For detail, read [FFMPEG](./ffmpeg.md)
Save the bellow as config file, or use `conf/ffmpeg.transcode.conf` instead:
```bash
# conf/ffmpeg.transcode.conf
listen 1935;
max_connections 1000;
vhost __defaultVhost__ {
transcode {
enabled on;
ffmpeg ./objs/ffmpeg/bin/ffmpeg;
engine ff {
enabled on;
vfilter {
}
vcodec libx264;
vbitrate 500;
vfps 25;
vwidth 768;
vheight 320;
vthreads 12;
vprofile main;
vpreset medium;
vparams {
}
acodec libfdk_aac;
abitrate 70;
asample_rate 44100;
achannels 2;
aparams {
}
output rtmp://127.0.0.1:[port]/[app]?vhost=[vhost]/[stream]_[engine];
}
}
}
```
## Step 4, start SRS
For detail, read [FFMPEG](./ffmpeg.md)
```bash
./objs/srs -c conf/ffmpeg.conf
```
## Step 5, start encoder
For detail, read [FFMPEG](./ffmpeg.md)
Use FFMPEG to publish stream:
```bash
for((;;)); do \
./objs/ffmpeg/bin/ffmpeg -re -i ./doc/source.flv \
-c copy \
-f flv rtmp://192.168.1.170/live/livestream; \
sleep 1; \
done
```
Or use FMLE to publish:
```bash
FMS URL: rtmp://192.168.1.170/live
Stream: livestream
```
The stream in SRS:
* Stream publish by encoder: rtmp://192.168.1.170:1935/live/livestream
* Play the original stream: rtmp://192.168.1.170:1935/live/livestream
* Play the transcoded stream: rtmp://192.168.1.170:1935/live/livestream_ff
## Step 6, play the stream
For detail, read [FFMPEG](./ffmpeg.md)
RTMP url is: `rtmp://192.168.1.170:1935/live/livestream`
User can use vlc to play the RTMP stream.
Note: Please replace all ip 192.168.1.170 to your server ip.
## Step 7, play the transcoded stream
For detail, read [FFMPEG](./ffmpeg.md)
RTMP url is: `rtmp://192.168.1.170:1935/live/livestream_ff`
User can use vlc to play the RTMP stream.
Note: Please replace all ip 192.168.1.170 to your server ip.
Winlin 2014.11
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/sample-ffmpeg)

156
trunk/3rdparty/srs-docs/doc/sample-forward.md vendored Normal file
View File

@ -0,0 +1,156 @@
---
title: Forward Deploy
sidebar_label: Forward Deploy
hide_title: false
hide_table_of_contents: false
---
# Forward deploy example
SRS can forward stream to other RTMP server.
**Suppose the server ip is 192.168.1.170**
Forward will copy streams to other RTMP server:
* Master: Encoder publish stream to master, which will forward to slave.
* Slave: Slave forward stream to slave.
We use master to listen at 1935, and slave listen at 19350.
## Step 1, get SRS
For detail, read [GIT](./git.md)
```bash
git clone https://github.com/ossrs/srs
cd srs/trunk
```
Or update the exists code:
```bash
git pull
```
## Step 2, build SRS
For detail, read [Build](./install.md)
```bash
./configure && make
```
## Step 3, config master SRS
For detail, read [Forward](./forward.md)
Save bellow as config, or use `conf/forward.master.conf`:
```bash
# conf/forward.master.conf
listen 1935;
max_connections 1000;
pid ./objs/srs.master.pid;
srs_log_tank file;
srs_log_file ./objs/srs.master.log;
vhost __defaultVhost__ {
forward {
enabled on;
destination 127.0.0.1:19350;
}
}
```
## Step 4, start master SRS
For detail, read [Forward](./forward.md)
```bash
./objs/srs -c conf/forward.master.conf
```
## Step 5, config slave SRS
For detail, read [Forward](./forward.md)
Save bellow as config, or use `conf/forward.slave.conf`:
```bash
# conf/forward.slave.conf
listen 19350;
pid ./objs/srs.slave.pid;
srs_log_tank file;
srs_log_file ./objs/srs.slave.log;
vhost __defaultVhost__ {
}
```
## Step 6, start slave SRS
For detail, read [Forward](./forward.md)
```bash
./objs/srs -c conf/forward.slave.conf
```
Note: Ensure the master and slave is ok, no error in log.
```bash
[winlin@dev6 srs]$ sudo netstat -anp|grep srs
tcp 0 0 0.0.0.0:1935 0.0.0.0:* LISTEN 7826/srs
tcp 0 0 0.0.0.0:19350 0.0.0.0:* LISTEN 7834/srs
```
## Step 7, start Encoder
For detail, read [Forward](./forward.md)
Use FFMPEG to publish stream:
```bash
for((;;)); do \
./objs/ffmpeg/bin/ffmpeg -re -i ./doc/source.flv \
-c copy \
-f flv rtmp://192.168.1.170/live/livestream; \
sleep 1; \
done
```
Or use FMLE to publish:
```bash
FMS URL: rtmp://192.168.1.170/live
Stream: livestream
```
The stream in SRS:
* Stream publish by encoder: rtmp://192.168.1.170:1935/live/livestream
* The stream forward by master SRS: rtmp://192.168.1.170:19350/live/livestream
* Play stream on master: rtmp://192.168.1.170/live/livestream
* Play strema on slave: rtmp://192.168.1.170:19350/live/livestream
## Step 8, play the stream on master
For detail, read [Forward](./forward.md)
RTMP url is: `rtmp://192.168.1.170:1935/live/livestream`
User can use vlc to play the RTMP stream.
Note: Please replace all ip 192.168.1.170 to your server ip.
## Step 9, play the stream on slave
For detail, read [Forward](./forward.md)
RTMP url is: `rtmp://192.168.1.170:19350/live/livestream`
User can use vlc to play the RTMP stream.
Note: Please replace all ip 192.168.1.170 to your server ip.
Winlin 2014.11
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/sample-forward)

158
trunk/3rdparty/srs-docs/doc/sample-hls-cluster.md vendored Normal file
View File

@ -0,0 +1,158 @@
---
title: HLS Cluster Deploy
sidebar_label: HLS Cluster Deploy
hide_title: false
hide_table_of_contents: false
---
# HLS Edge Cluster Example
Example for HLS Edge Cluster, like to create a CDN to deliver HLS files.
**Suppose the server ip is 192.168.1.170**
## Step 1, Get SRS code
For detail, read [GIT](./git.md)
```bash
git clone https://github.com/ossrs/srs
cd srs/trunk
```
Or update the exists code:
```bash
git pull
```
## Step 2, Configure and build SRS
For detail, read [Build](./install.md)
```bash
./configure && make
```
## Step 3, Config origin srs, to generate HLS files
See [HLS](./hls.md).
Please use config `conf/hls.origin.conf`, or create a config file by:
```bash
# conf/hls.origin.conf
listen 1935;
max_connections 1000;
daemon off;
srs_log_tank console;
http_server {
enabled on;
listen 8080;
}
vhost __defaultVhost__ {
hls {
enabled on;
hls_ctx off;
hls_ts_ctx off;
}
}
```
## Step 4, Config edge NGINX to deliver HLS files.
See [Nginx for HLS](./nginx-for-hls.md).
Save bellow as config, or use `conf/hls.edge.conf`:
```bash
# conf/hls.edge.conf
worker_processes 3;
events {
worker_connections 10240;
}
http {
# For Proxy Cache.
proxy_cache_path /tmp/nginx-cache levels=1:2 keys_zone=srs_cache:8m max_size=1000m inactive=600m;
proxy_temp_path /tmp/nginx-cache/tmp;
server {
listen 8081;
# For Proxy Cache.
proxy_cache_valid 404 10s;
proxy_cache_lock on;
proxy_cache_lock_age 300s;
proxy_cache_lock_timeout 300s;
proxy_cache_min_uses 1;
location ~ /.+/.*\.(m3u8)$ {
proxy_pass http://127.0.0.1:8080$request_uri;
# For Proxy Cache.
proxy_cache srs_cache;
proxy_cache_key $scheme$proxy_host$uri$args;
proxy_cache_valid 200 302 10s;
}
location ~ /.+/.*\.(ts)$ {
proxy_pass http://127.0.0.1:8080$request_uri;
# For Proxy Cache.
proxy_cache srs_cache;
proxy_cache_key $scheme$proxy_host$uri;
proxy_cache_valid 200 302 60m;
}
}
}
```
## Step 5, Start SRS Origin and NGINX Edge Server
```bash
nginx -c $(pwd)/conf/hls.edge.conf
./objs/srs -c conf/hls.origin.conf
```
> Note: Please follow instructions of [NGINX](https://nginx.org/) to download and install.
## Step 6, Publish RTMP stream to SRS Origin, to generate HLS files.
Use FFMPEG to publish stream:
```bash
for((;;)); do \
./objs/ffmpeg/bin/ffmpeg -re -i ./doc/source.flv \
-c copy -f flv rtmp://192.168.1.170/live/livestream; \
sleep 1; \
done
```
Or use OBS to publish:
```bash
Server: rtmp://192.168.1.170/live
StreamKey: livestream
```
## Step 7, Play HLS stream
HLS by SRS Origin: `http://192.168.1.170:8080/live/livestream.m3u8`
HLS by NGINX Edge: `http://192.168.1.170:8081/live/livestream.m3u8`
Note: Please replace all ip 192.168.1.170 to your server ip.
## Step 8: Benchmark and More NGINX Edge Servers
Please use [srs-bench](https://github.com/ossrs/srs-bench#usage) to simulate a set of visitors:
```bash
docker run --rm -it --network=host --name sb ossrs/srs:sb \
./objs/sb_hls_load -c 100 -r http://192.168.1.170:8081/live/livestream.m3u8
```
You could run more NGINX from another server, use the same config.
Winlin 2014.11
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/sample-hls-cluster)

14
trunk/3rdparty/srs-docs/doc/sample-hls.md vendored Normal file
View File

@ -0,0 +1,14 @@
---
title: HLS Deploy
sidebar_label: HLS Deploy
hide_title: false
hide_table_of_contents: false
---
# HLS deploy example
Migrated to [HLS](./hls.md).
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/sample-hls)

165
trunk/3rdparty/srs-docs/doc/sample-http-flv-cluster.md vendored Normal file
View File

@ -0,0 +1,165 @@
---
title: HTTP-FLV Cluster Deploy
sidebar_label: HTTP-FLV Cluster Deploy
hide_title: false
hide_table_of_contents: false
---
# HTTP FLV Cluster Example
About the HTTP FLV cluster of SRS, read [HTTP FLV](./flv.md#about-http-flv)
How to use multiple process for HTTP FLV? Please read [Reuse Port](./reuse-port.md) for detail.
This example show how to deploy three SRS instance, listen at different port at a machine(user can deploy each to different machine, use same port), while one is origin server, another two are edge servers. We can publish RTMP to origin or edge, and play the RTMP/FLV at any edge. The latency is same to RTMP, 0.8-1s.
**Suppose the server ip is 192.168.1.170**
## Step 1, get SRS
For detail, read [GIT](./git.md)
```bash
git clone https://github.com/ossrs/srs
cd srs/trunk
```
Or update the exists code:
```bash
git pull
```
## Step 2, build SRS
For detail, read [Build](./install.md)
```bash
./configure && make
```
## Step 3, config origin SRS
For detail, read [HTTP FLV](./flv.md)
Save bellow as config, or use `conf/http.flv.live.conf`:
```bash
# conf/http.flv.live.conf
listen 1935;
max_connections 1000;
http_server {
enabled on;
listen 8080;
dir ./objs/nginx/html;
}
vhost __defaultVhost__ {
http_remux {
enabled on;
mount [vhost]/[app]/[stream].flv;
hstrs on;
}
}
```
## Step 4, config edge SRS
For detail, read [HTTP FLV](./flv.md)
Save bellow as config, or use `conf/http.flv.live.edge1.conf` or `conf/http.flv.live.edge2.conf`:
```bash
# conf/http.flv.live.edge1.conf
listen 19351;
max_connections 1000;
pid objs/srs.flv.19351.pid;
srs_log_file objs/srs.flv.19351.log;
http_server {
enabled on;
listen 8081;
dir ./objs/nginx/html;
}
vhost __defaultVhost__ {
mode remote;
origin 127.0.0.1;
http_remux {
enabled on;
mount [vhost]/[app]/[stream].flv;
hstrs on;
}
}
```
## Step 5, start SRS
For detail, read [HTTP FLV](./flv.md)
```bash
./objs/srs -c conf/http.flv.live.conf &
./objs/srs -c conf/http.flv.live.edge1.conf &
./objs/srs -c conf/http.flv.live.edge2.conf &
```
## Step 6, start Encoder
For detail, read read [HTTP FLV](./flv.md)
Use FFMPEG to publish stream:
```bash
for((;;)); do \
./objs/ffmpeg/bin/ffmpeg -re -i ./doc/source.flv \
-c copy \
-f flv rtmp://192.168.1.170/live/livestream; \
sleep 1; \
done
```
Or use FMLE to publish：
```bash
FMS URL: rtmp://192.168.1.170/live
Stream: livestream
```
The streams on SRS origin:
* RTMP: `rtmp://192.168.1.170/live/livestream`
* HTTP FLV: `http://192.168.1.170:8080/live/livestream.flv`
The streams on SRS edge1:
* RTMP: `rtmp://192.168.1.170:19351/live/livestream`
* HTTP FLV: `http://192.168.1.170:8081/live/livestream.flv`
The streams on SRS edge2:
* RTMP: `rtmp://192.168.1.170:19352/live/livestream`
* HTTP FLV: `http://192.168.1.170:8082/live/livestream.flv`
## Step 7, play RTMP
For detail, read [HTTP FLV](./flv.md)
Origin RTMP url is: `rtmp://192.168.1.170:1935/live/livestream`, User can use vlc to play the RTMP stream.
Edge1 RTMP url is: `rtmp://192.168.1.170:19351/live/livestream`, User can use vlc to play the RTMP stream.
Edge2 RTMP url is: `rtmp://192.168.1.170:19352/live/livestream`, User can use vlc to play the RTMP stream.
Note: Please replace all ip 192.168.1.170 to your server ip.
## Step 8, play HTTP FLV
For detail, read [HTTP FLV](./flv.md)
Origin HTTP FLV url: `http://192.168.1.170:8080/live/livestream.flv`, User can use vlc to play the HLS stream. Or, use online SRS player(you must input the flv url): [srs-player](https://ossrs.net/players/srs_player.html)
Edge1 HTTP FLV url: `http://192.168.1.170:8081/live/livestream.flv`, User can use vlc to play the HLS stream. Or, use online SRS player(you must input the flv url): [srs-player](https://ossrs.net/players/srs_player.html)
Edge2 HTTP FLV url: `http://192.168.1.170:8082/live/livestream.flv`, User can use vlc to play the HLS stream. Or, use online SRS player(you must input the flv url): [srs-player](https://ossrs.net/players/srs_player.html)
Note: Please replace all ip 192.168.1.170 to your server ip.
Winlin 2014.11
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/sample-http-flv-cluster)

14
trunk/3rdparty/srs-docs/doc/sample-http-flv.md vendored Normal file
View File

@ -0,0 +1,14 @@
---
title: HTTP-FLV Deploy
sidebar_label: HTTP-FLV Deploy
hide_title: false
hide_table_of_contents: false
---
# HTTP FLV deploy example
Migrated to [HTTP-FLV](./flv.md).
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/sample-http-flv)

124
trunk/3rdparty/srs-docs/doc/sample-http.md vendored Normal file
View File

@ -0,0 +1,124 @@
---
title: HTTP Server Deploy
sidebar_label: HTTP Server Deploy
hide_title: false
hide_table_of_contents: false
---
# SRS HTTP server deploy example
SRS embeded HTTP server, to delivery HLS and files.
**Suppose the server ip is 192.168.1.170**
## Step 1, get SRS
For detail, read [GIT](./git.md)
```bash
git clone https://github.com/ossrs/srs
cd srs/trunk
```
Or update the exists code:
```bash
git pull
```
## Step 2, build SRS
For detail, read [Build](./install.md)
```bash
./configure && make
```
## Step 3, config SRS
For detail, read [HLS](./hls.md) and [HTTP Server](./http-server.md)
Save bellow as config, or use `conf/http.hls.conf`:
```bash
# conf/http.hls.conf
listen 1935;
max_connections 1000;
http_server {
enabled on;
listen 8080;
dir ./objs/nginx/html;
}
vhost __defaultVhost__ {
hls {
enabled on;
hls_path ./objs/nginx/html;
hls_fragment 10;
hls_window 60;
}
}
```
Note: The hls_path must exists, srs never create it. For detail, read [HLS](./hls.md)
## Step 4, start SRS
For detail, read [HLS](./hls.md) and [SRS HTTP Server](./http-server.md)
```bash
./objs/srs -c conf/http.hls.conf
```
## Step 5, start Encoder
For detail, read [HLS](./hls.md)
Use FFMPEG to publish stream:
```bash
for((;;)); do \
./objs/ffmpeg/bin/ffmpeg -re -i ./doc/source.flv \
-c copy \
-f flv rtmp://192.168.1.170/live/livestream; \
sleep 1; \
done
```
Or use FMLE(which support h.264+aac) to publish, read [Transcode2HLS](./sample-transcode-to-hls.md)：
```bash
FMS URL: rtmp://192.168.1.170/live
Stream: livestream
```
The streams on SRS:
* RTMP: `rtmp://192.168.1.170/live/livestream`
* HLS: `http://192.168.1.170:8080/live/livestream.m3u8`
## Step 6, play RTMP
For detail, read [HLS](./hls.md)
RTMP url is: `rtmp://192.168.1.170:1935/live/livestream`
User can use vlc to play the RTMP stream.
Note: Please replace all ip 192.168.1.170 to your server ip.
## Step 7, play HLS
For detail, read [HLS](./hls.md)
HLS url: `http://192.168.1.170:8080/live/livestream.m3u8`
User can use vlc to play the HLS stream.
Or, use online SRS player: [srs-player](https://ossrs.net/players/srs_player.html)
Note: Please replace all ip 192.168.1.170 to your server ip.
Winlin 2014.11
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/sample-http)

89
trunk/3rdparty/srs-docs/doc/sample-ingest.md vendored Normal file
View File

@ -0,0 +1,89 @@
---
title: Ingest Deploy
sidebar_label: Ingest Deploy
hide_title: false
hide_table_of_contents: false
---
# Ingest deploy example
SRS can start process to ingest file/stream/device, transcode or not,
then publish to SRS. For detail, read [Ingest](./ingest.md).
**Suppose the server ip is 192.168.1.170**
## Step 1, get SRS
For detail, read [GIT](./git.md)
```bash
git clone https://github.com/ossrs/srs
cd srs/trunk
```
Or update the exists code:
```bash
git pull
```
## Step 2, build SRS
For detail, read [Build](./install.md)
```bash
./configure --ffmpeg-tool=on && make
```
## Step 3, config SRS
For detail, read [Ingest](./ingest.md)
Save bellow as config, or use `conf/ingest.conf`:
```bash
# conf/ingest.conf
listen 1935;
max_connections 1000;
vhost __defaultVhost__ {
ingest livestream {
enabled on;
input {
type file;
url ./doc/source.flv;
}
ffmpeg ./objs/ffmpeg/bin/ffmpeg;
engine {
enabled off;
output rtmp://127.0.0.1:[port]/live?vhost=[vhost]/livestream;
}
}
}
```
## Step 4, start SRS
For detail, read [Ingest](./ingest.md)
```bash
./objs/srs -c conf/ingest.conf
```
The streams on SRS:
* Stream ingest: rtmp://192.168.1.170:1935/live/livestream
## Step 5, play RTMP
For detail, read [Ingest](./ingest.md)
RTMP url is: `rtmp://192.168.1.170:1935/live/livestream`
User can use vlc to play the RTMP stream.
Note: Please replace all ip 192.168.1.170 to your server ip.
Winlin 2014.11
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/sample-ingest)

156
trunk/3rdparty/srs-docs/doc/sample-origin-cluster.md vendored Normal file
View File

@ -0,0 +1,156 @@
---
title: RTMP Origin Cluster
sidebar_label: RTMP Origin Cluster
hide_title: false
hide_table_of_contents: false
---
# RTMP Origin Cluster
RTMP Origin Cluster is a powerful feature for huge pushing streams,
we could use RTMP Origin Cluster and RTMP Edge Cluster together,
to support huge pushing and pulling streams.
**Suppose your server is: 192.168.1.170**
## Step 1: Get SRS
For more information please read [here](./git.md)
```bash
git clone https://github.com/ossrs/srs
cd srs/trunk
```
Or update your repository:
```bash
git pull
```
## Step 2: Build SRS
For more information please read [here](./install.md)
```bash
./configure && make
```
## Step 3: Config the first origin, Origin ServerA
For more information please read [here](./origin-cluster.md)
You can use the file `conf/origin.cluster.serverA.conf`, or write your own:
```bash
# conf/origin.cluster.serverA.conf
listen 19350;
max_connections 1000;
daemon off;
srs_log_tank console;
pid ./objs/origin.cluster.serverA.pid;
http_api {
enabled on;
listen 9090;
}
vhost __defaultVhost__ {
cluster {
mode local;
origin_cluster on;
coworkers 127.0.0.1:9091;
}
}
```
## Step 4: Config the second origin, Origin ServerB
For more information please read [here](./origin-cluster.md)
You can use the file `conf/origin.cluster.serverB.conf`, or write your own:
```bash
# conf/origin.cluster.serverB.conf
listen 19351;
max_connections 1000;
daemon off;
srs_log_tank console;
pid ./objs/origin.cluster.serverB.pid;
http_api {
enabled on;
listen 9091;
}
vhost __defaultVhost__ {
cluster {
mode local;
origin_cluster on;
coworkers 127.0.0.1:9090;
}
}
```
## Step 5: Config edge server, which pulls streams from Origin Servers
For more information please read [here](./origin-cluster.md)
You can use the file `conf/origin.cluster.edge.conf`, or write your own:
```bash
# conf/origin.cluster.edge.conf
listen 1935;
max_connections 1000;
pid objs/edge.pid;
daemon off;
srs_log_tank console;
vhost __defaultVhost__ {
cluster {
mode remote;
origin 127.0.0.1:19351 127.0.0.1:19350;
}
}
```
## Step 6: Start SRS servers
For more information please read [here](./origin-cluster.md)
```bash
./objs/srs -c conf/origin.cluster.serverA.conf &
./objs/srs -c conf/origin.cluster.serverB.conf &
./objs/srs -c conf/origin.cluster.edge.conf &
```
## Step 7: Push stream to any Origin Server
For more information please read [here](./origin-cluster.md)
By FFmpeg:
```bash
for((;;)); do \
./objs/ffmpeg/bin/ffmpeg -re -i ./doc/source.flv \
-c copy \
-f flv rtmp://192.168.1.170:19350/live/livestream; \
sleep 1; \
done
```
Or FMLE:
```bash
FMS URL: rtmp://192.168.1.170:19350/live
Stream: livestream
```
## Step 8: Play RTMP stream from Edge server
For more information please read [here](./origin-cluster.md)
RTMP URL is: `rtmp://192.168.1.170/live/livestream`, you can choose VLC.
> Remark: Replace the IP `192.168.1.170` to your server IP.
Winlin 2018.2
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/sample-origin-cluster)

111
trunk/3rdparty/srs-docs/doc/sample-realtime.md vendored Normal file
View File

@ -0,0 +1,111 @@
---
title: RTMP Realtime Deploy
sidebar_label: RTMP Realtime Deploy
hide_title: false
hide_table_of_contents: false
---
# RTMP low latency deploy example
The SRS realtime(low latency) mode can decrease the latency to 0.8-3s.
For detail about latency, read [LowLatency](./low-latency.md).
**Suppose the server ip is 192.168.1.170**
## Step 1, get SRS
For detail, read [GIT](./git.md)
```bash
git clone https://github.com/ossrs/srs
cd srs/trunk
```
Or update the exists code:
```bash
git pull
```
## Step 2, build SRS
For detail, read [Build](./install.md)
```bash
./configure && make
```
## Step 3, config SRS
For detail, read [LowLatency](./low-latency.md)
Save bellow as config, or use `conf/realtime.conf`:
```bash
# conf/realtime.conf
listen 1935;
max_connections 1000;
vhost __defaultVhost__ {
tcp_nodelay on;
min_latency on;
play {
gop_cache off;
queue_length 10;
mw_latency 100;
}
publish {
mr off;
}
}
```
## Step 4, start SRS
For detail, read [LowLatency](./low-latency.md)
```bash
./objs/srs -c conf/realtime.conf
```
## Step 5, start Encoder
For detail, read [LowLatency](./low-latency.md)
Use FFMPEG to publish stream:
```bash
for((;;)); do \
./objs/ffmpeg/bin/ffmpeg -re -i ./doc/source.flv \
-c copy \
-f flv rtmp://192.168.1.170/live/livestream; \
sleep 1; \
done
```
Or use FMLE to publish:
```bash
FMS URL: rtmp://192.168.1.170/live
Stream: livestream
```
Note: To measure the latency, can use the clock of mobile phone.
![latency](/img/sample-realtime-001.png)
## Step 6, play RTMP
For detail, read [LowLatency](./low-latency.md)
RTMP url is: `rtmp://192.168.1.170:1935/live/livestream`
User can use vlc to play the RTMP stream.
Note: Please replace all ip 192.168.1.170 to your server ip.
Winlin 2014.12
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/sample-realtime)

120
trunk/3rdparty/srs-docs/doc/sample-rtmp-cluster.md vendored Normal file
View File

@ -0,0 +1,120 @@
---
title: RTMP Cluster Deploy
sidebar_label: RTMP Cluster Deploy
hide_title: false
hide_table_of_contents: false
---
# RTMP Edge Cluster Example
RTMP Edge cluster deploy example
RTMP Edge cluster is the kernel feature of SRS.
**Suppose the server ip is 192.168.1.170**
## Step 1, get SRS
For detail, read [GIT](./git.md)
```bash
git clone https://github.com/ossrs/srs
cd srs/trunk
```
Or update the exists code:
```bash
git pull
```
## Step 2, build SRS
For detail, read [Build](./install.md)
```bash
./configure && make
```
## Step 3, config origin SRS
For detail, read [RTMP](./rtmp.md) and [Edge](./edge.md)
Save bellow as config, or use `conf/origin.conf`:
```bash
# conf/origin.conf
listen 19350;
max_connections 1000;
pid objs/origin.pid;
srs_log_file ./objs/origin.log;
vhost __defaultVhost__ {
}
```
## Step 4, config edge SRS
For detail, read [RTMP](./rtmp.md) and [Edge](./edge.md)
Save bellow as config, or use `conf/edge.conf`:
```bash
# conf/edge.conf
listen 1935;
max_connections 1000;
pid objs/edge.pid;
srs_log_file ./objs/edge.log;
vhost __defaultVhost__ {
cluster {
mode remote;
origin 127.0.0.1:19350;
}
}
```
## Step 5, start SRS
For detail, read [RTMP](./rtmp.md) and [Edge](./edge.md)
```bash
./objs/srs -c conf/origin.conf &
./objs/srs -c conf/edge.conf &
```
## Step 6, start Enocder
For detail, read [RTMP](./rtmp.md) and [Edge](./edge.md)
Use FFMPEG to publish stream:
```bash
for((;;)); do \
./objs/ffmpeg/bin/ffmpeg -re -i ./doc/source.flv \
-c copy \
-f flv rtmp://192.168.1.170/live/livestream; \
sleep 1; \
done
```
Or use FMLE to publish:
```bash
FMS URL: rtmp://192.168.1.170/live
Stream: livestream
```
## Step 7, play RTMP
For detail, read [RTMP](./rtmp.md) and [Edge](./edge.md)
Origin RTMP url is: `rtmp://192.168.1.170:19350/live/livestream`, User can use vlc to play the RTMP stream.
Edge RTMP url is: `rtmp://192.168.1.170:1935/live/livestream`, User can use vlc to play the RTMP stream.
Note: Please replace all ip 192.168.1.170 to your server ip.
Winlin 2014.11
![](https://ossrs.io/gif/v1/sls.gif?site=ossrs.io&path=/lts/doc/en/v7/sample-rtmp-cluster)

Some files were not shown because too many files have changed in this diff Show More