Winlin ebf8b712c9 Proxy: restructure repo as Go project with proxy as first module (#4652 )

Reorganize the SRS (Simple Realtime Server) repository to
follow a conventional Go project structure, setting the stage for a
progressive transition from a C++ project to a Go project. The proxy,
which was once contained within its own `proxy/` subdirectory, will now
be converted into the initial Go module located at the root of the
repository, serving as a template for subsequent Go modules.

- **Go module at repo root:** `go.mod` moved to repo root, module
renamed from `proxy` to `srsx`. The repo is now a proper Go project with
`cmd/` and `internal/` at the top level.
- **Elevation of Proxy Code:** Move the proxy code from
`proxy/cmd/proxy-go/` to `cmd/proxy/`, and from `proxy/internal/` to
`internal/`. The proxy serves as the inaugural application; subsequent
modules (for instance, `cmd/origin`) will mimic this arrangement.
- **Documentation Restructured:** Transfer the documentation from
`proxy/docs/` to `docs/proxy/`, revise the main README to endorse
OpenClaw as the preferred AI tool, and update `proxy/README.md` to point
to the new documentation locations.
- **Build and config:** `Makefile` moved to root, `PROXY_STATIC_FILES`
default path corrected for the new layout, `.gitignore` consolidated.
- **Cleanup:** removed standalone `proxy/LICENSE` (repo-level license
applies), all internal imports updated to `srsx/internal/...`.
- **OpenClaw workspace:** added community bot info, git workflow
conventions, and support group behavior guidance.

This restructuring was performed by OpenClaw orchestrating Claude Code
and Codex via ACP.

---------

Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
Co-authored-by: chatgpt-codex-connector[bot] <199175422+chatgpt-codex-connector[bot]@users.noreply.github.com>

2026-03-22 08:11:28 -04:00

2.7 KiB

Raw Blame History

How to Run and Test the Project

When running the project for testing or development, you should:

Build and start the proxy server
Start SRS origin server
Verify SRS registration with proxy
Publish a test stream using FFmpeg
Verify the stream is working using ffprobe

Step 1: Build and Start Proxy Server

make && 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

The proxy server should start and listen on the configured ports.

Step 2: Start SRS Origin Server

In a new terminal, start the SRS origin server. You may need to increase the file descriptor limit and use bash explicitly:

ulimit -n 10000 && bash -c "cd ~/git/srs/trunk && ./objs/srs -c conf/origin1-for-proxy.conf"

The SRS origin server should start and be ready to receive and serve streams. Check the console output for startup messages.

Step 3: Verify SRS Registration

Check the proxy logs to confirm SRS has registered itself with the proxy:

The proxy logs are printed to the console where you started the proxy server. Check the terminal running the proxy for messages indicating:

"Register SRS media server" messages when SRS registers itself with the proxy

The SRS origin server should automatically register itself with the proxy when it starts. Look for successful registration messages in proxy console outputs.

Step 4: Publish a Test Stream

In a new terminal, publish a test stream using FFmpeg:

ffmpeg -stream_loop -1 -re -i ~/git/srs/trunk/doc/source.flv -c copy -f flv rtmp://localhost/live/livestream

Note: -stream_loop -1 makes FFmpeg loop the input file infinitely, ensuring the stream doesn't quit after the file ends.

Step 5: Verify Stream with ffprobe

In another terminal, use ffprobe to verify the stream is working:

Test RTMP stream:

ffprobe rtmp://localhost/live/livestream

Test HTTP-FLV stream:

ffprobe http://localhost:8080/live/livestream.flv

Both commands should successfully detect the stream and display video/audio codec information. If ffprobe shows stream details without errors, the proxy is working correctly.

Code Conventions

Factory Functions

Factory functions should use explicit interface names: NewBootstrap(), NewMemoryLoadBalancer(), etc.
Do not use generic New() function names
This improves code clarity and makes the constructed type explicit at the call site

Example:

// Good
bs := bootstrap.NewBootstrap()

// Avoid
bs := bootstrap.New()

Global Variables

Avoid global variables for service instances
This improves testability and makes code flow explicit

2.7 KiB Raw Blame History