SRS media server: the Docker quick start and the ports it leaves closed

One docker run, then a stream in from OBS or ffmpeg

The README recommends Docker over a source build, and the whole first run is a single command with five published ports:

docker run --rm -it -p 1935:1935 -p 1985:1985 -p 8080:8080 \
    -p 8000:8000/udp -p 10080:10080/udp ossrs/srs:6

Readers in China are pointed at a faster mirror of the same image, registry.cn-hangzhou.aliyuncs.com/ossrs/srs:6. Once the container is up, http://localhost:8080/ is the check that it works.

Pushing a stream in is either OBS or ffmpeg. The ffmpeg line in the README copies the codec and remuxes, it does not transcode:

ffmpeg -re -i ./doc/source.flv -c copy -f flv -y rtmp://localhost/live/livestream

The OBS equivalent is Service set to Custom, Server set to rtmp://localhost/live and Stream Key set to livestream. Playing it back has three documented routes: the RTMP URL in VLC, the HTTP-FLV URL at http://localhost:8080/live/livestream.flv, and the HLS playlist at http://localhost:8080/live/livestream.m3u8, the last two through srs-player, an HTML5 player served by the container.

The image exposes seven ports and the quick start publishes five

The Dockerfile exposes more than the README's docker run maps:

EXPOSE 1935 1985 8080 5060 9000 8000/udp 10080/udp

Six TCP ports and two UDP ports, against the five mappings in the documented run command: 1935, 1985 and 8080 over TCP, 8000 and 10080 over UDP. The two left out are 5060 and 9000, which is the pair a GB28181 deployment needs, and GB28181 is one of the protocols the project lists as supported. A reader who follows the quick start and then tries to connect a GB28181 device finds a container that is running and refusing connections, and the fix is to add the mappings by hand. The README does not mention 5060 or 9000 anywhere.

There is a second mismatch in the same command. The tag is ossrs/srs:6, so the documented install is the 6.0 line, while the paragraph above it describes SRS/8.0 as the current release. Nothing tells you which the image you just ran is meant to be.

make at the root builds a Go proxy, and the C++ server is built elsewhere

The root Makefile contains no C++ in it. `all` depends on `build`, `build` depends on `fmt` and `bin/srs-proxy`, and the binary comes out of Go:

build: fmt bin/srs-proxy
	go build -o bin/srs-proxy ./cmd/proxy

Run make at the top of the repository and you get a proxy binary and no media server. The server is in trunk/, and the way it gets built is visible in the Dockerfile: the tree is copied to /srs, the working directory moves to /srs/trunk, and then configure, make and make install run in sequence.

WORKDIR /srs/trunk
RUN ./configure ${CONFARGS} && make ${MAKEARGS} && make install

The C++ toolchain is whatever that image installs, gcc, make, g++, patch, unzip, perl, git and libasan5 on an Ubuntu 20.04 base, and the resulting image carries FFMPEG 4.1. A comment in the Dockerfile notes that SRT is enabled by default, which is why the configure line passes no SRT flag. On the Go side go.mod declares module srsx at go 1.25.0 with a Redis client, and the other targets are test, generate, run and clean.

So this is one repository with two build systems and two toolchains, and the entry point you would guess at does not build the thing you came for.

Three major lines were tagged on the same day

Look at the release dates rather than the version numbers. v8.0-d0, v7.0-a1 and v6.0-r2 were all published on 2026-09-24, and the README's own release list shows the same shape: v8.0-d0 on 2026-09-24 at 328208 lines, v7.0-a0 on 2026-09-18 at 314832 lines, v7.0-d0 on 2026-08-12, and v6.0-r1 on 2026-08-12.

The suffixes are the useful part. d0 is a development build, a0 is an alpha, r1 and r2 are release candidates. So the newest line, 8.0, has nothing in it that is finished, and the line the quick start pins you to, 6.0, is the one being prepared as a release. The default branch is develop rather than main, and the CodeQL badge in the README is scoped to branch=develop, so the integration branch and the shipping line are not the same thing.

For an adopter that means the first decision is which line you are on, and it has to be made before anything else. Picking 8.0 means building from a tag that is still moving through its own dev sequence, and picking 6.0 means taking the line the project's own quick start froze in place months ago.

The AI agent story is a markdown file under skills/

The README headline calls SRS/8.0 an AI-driven media server, and there is an AI Agent section. What it contains is one sentence and a path: use AI to understand and maintain SRS, and follow the wiki document at skills/internal-docs-for-srs/references/cpp-docs/doc/getting-started-ai.md. No command, no service and no configuration key comes with it.

The tree backs up the documentation reading rather than a runtime one. Alongside skills/ there are .agents/, .claude/, .codex/, .kiro/ and .openclaw/ directories, which is the shape of a repository that has been set up for several coding agents at once, each with its own configuration at the top level. A separate oryx/ directory, dev-docker/, tools/, scripts/, cmake/ and website/ sit next to trunk/ and cmd/.

So the practical consequence is this: if you point an agent at this repository, what it reads is the same tree you read, plus a getting-started document written for that purpose. What you do not get from the README is anything an agent calls at runtime, so budget for reading the guide and wiring the tooling yourself rather than expecting a feature you can switch on in a config file.

The documented push path remuxes, and WebRTC lives in the wiki

Two gaps in the quick start matter before you rely on it. The first is the codec list. Supported codecs are H.264, H.265, AV1, VP9, AAC, Opus and G.711, and the ffmpeg example pushes with -c copy, so nothing is converted. A source file outside that list will not be made to fit by this command; you need an ffmpeg pass in front of it, and the ffmpeg the image carries is 4.1, which is not a new release to be building a pipeline on.

The second gap is WebRTC. It is listed first among the supported protocols in the project description, and the quick start never touches it. Converting RTMP to WebRTC or the reverse is handled by a wiki page linked from the getting started guide, in English or Chinese, rather than by anything in the README. If browser ingest is the reason you are here, the README gets you a running server and stops.

A third detail belongs with these. The docker run has no volume mount, no configuration argument and no environment variable, so the container runs on whatever the image ships with, and the README does not show a config file being supplied. For a first stream that is fine. For a deployment you intend to keep, you are on your own from the moment the container starts.

The maintainer list is a per-module bus factor

SRS publishes an AUTHORS file and the README ranks maintainers by commit count, which turns into a map of who owns what. Winlin is the founder, on architecture, streaming technology and issues. XiaoZhihong covers WebRTC, QUIC and SRT with network QoS, and contributed the original WebRTC work. ChenHaibo and XiaLixin hold GB28181 between them, and ChenHaibo also owns the HTTP API and FFmpeg patches with WHIP. ZhangJunqin has H.265, the Prometheus Exporter and the API module. ShiWei maintains SRT and FLV patches for FFmpeg. ChenGuanghua is on WebRTC and QoS and introduced the Asan toolchain, and LiPeng works on WebRTC memory management and smart pointers.

That is a real answer to a question adopters rarely ask, which is who to watch. If your deployment depends on the Prometheus exporter or on GB28181, the README tells you those sit with one or two people rather than with a committee. The same section credits State Threads to three people outside the project, Genes, Mabbott and Michael Talyansky, which is worth knowing because the concurrency model underneath the server is not in this repository.

Funding runs through OpenCollective, and the CI signals in the header are CodeQL on develop, a release workflow and codecov coverage.

Editorial conclusion

Take SRS if you need one process to take RTMP in and hand it back out over HLS, HTTP-FLV, WebRTC or SRT, and if you are willing to settle on the 6.0 line that the quick start pins rather than the 8.0 the headline advertises. Before you build, decide which line and which branch you are on: the default branch is develop, and the release train tags dev, alpha and release-candidate builds in parallel. Before you deploy, publish the ports you actually need, because the documented docker run maps 1935, 1985, 8080, 8000/udp and 10080/udp while the image also exposes 5060 and 9000, which is where GB28181 traffic goes.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes