Code Monkey home page Code Monkey logo

ossrs / srs Goto Github PK

View Code? Open in Web Editor NEW
24.3K 845.0 5.2K 247.69 MB

SRS is a simple, high-efficiency, real-time video server supporting RTMP, WebRTC, HLS, HTTP-FLV, SRT, MPEG-DASH, and GB28181.

Home Page: https://ossrs.io

License: MIT License

Shell 2.33% CMake 0.06% Python 0.19% HTML 3.38% C++ 87.47% Makefile 0.03% JavaScript 5.76% Go 0.59% CSS 0.01% Dockerfile 0.03% Lua 0.04% Batchfile 0.01% NSIS 0.09%
rtmp live-streaming live media-server hls webrtc srt low-latency video-conferencing video

srs's Issues

Support RAW API, support read/write API, which means support calling the http API to modify configuration and reload.

!!! Attention, the RAW API has been disabled after version 4.0, please refer to #2653 for background information.

!!! RAW API is removed from SRS 4.0, please see #2653

Other than the ability to reload, all other RAW API capabilities have been removed.

Provide an HTTP API to modify the configuration file and then reload the effective configuration.
https://github.com/winlinvip/simple-rtmp-server/issues/319

TRANS_BY_GPT3

WebRTC: Support WebRTC, for video meeting, SFU server, video converence.

WebRTC is now quite mature, with stable playback and the protocol already being an RFC. There are also quite a few corresponding open-source projects. However, I believe that WebRTC still lacks a high-performance, simple and easy-to-use server. I have analyzed the existing servers before and found various issues. SRS has a great opportunity to solve these problems.

See English or Chinese

MP3: Support mp3 for RTMP/HLS/HTTP-FLV/HTTP-TS/HLS etc.

SRS 3/4 supports MP3 over RTMP/HTTP-FLV/HTTP-TS, however there is some bugs need to be fixed.

Usage

Start SRS server:

# For RTMP/HTTP-FLV/HLS
./objs/srs -c conf/mp3.conf

# For HTTP-TS
./objs/srs -c conf/mp3.ts.conf

# For HTTP-MP3
./objs/srs -c conf/mp3.http.conf

# For RTMP(MP3) to WebRTC
./objs/srs -c conf/mp3.rtc.conf

Publish RTMP stream with mp3 audio:

ffmpeg -stream_loop -1  -re -i doc/source.flv -vcodec copy -acodec libmp3lame \
    -f flv rtmp://localhost/live/livestream

Play live stream:

  • RTMP by VLC or ffplay: rtmp://localhost/live/livestream
  • HTTP-FLV by VLC, ffplay or H5(srs-player): http://localhost:8080/live/livestream.flv
  • HTTP-MP3 by VLC, ffplay or H5(srs-player): http://localhost:8080/live/livestream.mp3
  • HTTP-TS by VLC, ffplay or H5(srs-player): http://localhost:8080/live/livestream.ts
  • HLS by VLC, ffplay or H5(srs-player): http://localhost:8080/live/livestream.m3u8
  • Covert RTMP(MP3) to WebRTC, play by H5(srs-player): webrtc://localhost/live/livestream

Status

I tested the ability for MP3 over serval protocols, found that some is ok but others fail, and listed the test result bellow.

  • Push RTMP stream with mp3 audio. SRS 4.0+
  • Play RTMP stream with mp3 audio by VLC/ffplay. SRS 4.0+
  • Play HTTP-FLV stream with mp3 audio by VLC/ffplay/H5(srs-player). SRS 4.0+
  • Play HTTP-MP3 stream with mp3 audio by VLC/ffplay/H5(srs-player). SRS 4.0+
  • #3334
  • #3337
  • #3338
  • #3339
  • #3340
  • DVR live stream to FLV file with MP3 audio. SRS4.0+
  • DVR live stream to MP4 file with MP3 audio. SRS4.0+
  • xqq/mpegts.js#83
  • Regresstion test for mp3 audio. SRS 5.0+ #3358
  • Play MPEG-DASH with MP3 audio. No plan.

Note: There is a bug for playing HTTP-TS with mp3 audio by H5, see mpegts.js #83

FRSC: Supports sub-millisecond latency, replaceable fast channel technology.

https://github.com/winlinvip/simple-rtmp-server/issues/120

Supports sub-100 millisecond latency, replaceable fast channel technology
Support <500ms latency, FRSC(fast RTMP-compatible stream channel tech)

Sub-100 millisecond latency requires improvement on the existing RTMP mechanism:

  1. Consider using UDP instead of TCP for encoder transmission, server internal communication, and client transmission. Support switchable UDP/TCP mechanism, for example, only the client uses TCP/RTMP while others use UDP private protocols.
  2. Consider non-interlaced media stream transmission: The encoder BLE supports non-interlaced output, where the audio stream timestamp increases monotonically, the video stream increases monotonically, but they are not mixed together. Mixing them would increase latency. The server does not mix them internally (interlaced) either, instead, the mixing of video and audio is done at the edge server or on the client side (own client).
  3. Consider using IO mechanism instead of timeout mechanism: Currently, the server logic waits for 300 milliseconds for client control messages and then sends all pending packets together to the client. This introduces a delay of 300 milliseconds, which increases at each level (according to average probability). If the 300-millisecond timeout mechanism is replaced with an IO mechanism, i.e., the "write" event for packet transmission becomes an IO "read" event, it can wait for two file descriptors to determine whether there is a message from the client or a message to be written.
  4. Packet loss mechanism: Consider supporting packet loss at the edge or in the encoder to control the delay within the sub-500 millisecond range, ideally around 300 milliseconds for Flash clients. If the server controls the delay within 200 milliseconds, the overall system delay can be controlled within 500 milliseconds. If the client is a custom client, the delay can be even lower (server-side control within 200 milliseconds).
  5. Rollback to standard mechanism: Support standard RTMP, for example, within the encoder/server cluster, use low-latency distribution mechanism. If it is detected that the client is Flash-based, the edge should mix the video and audio streams and send them to the client with monotonically increasing timestamps.

In summary, supporting sub-100 millisecond latency requires a comprehensive set of mechanisms and customization on top of RTMP. Compatibility with standard RTMP should also be considered. Therefore, the main goal of the system is to establish a fast channel, control the latency within the sub-100 millisecond range, and support integration with universal solutions at any point in the fast channel.

TRANS_BY_GPT3

Can RTMP stream forwarding be specified through a URL?

Currently, the forwarding mode in circulation needs to be configured through a configuration file. Can you please add the option to configure the forwarding URL?

For example:
Forwarding URL: rtmp://192.168.1.2/myapp/mystream?forward=rtmp://cdn.com/myapp/mystream?XXXXXX

This would make it more convenient to change whether the stream needs to be forwarded at any time. Currently, we have a use case where most of the streams only need to be viewed within the local network and do not require internet access. However, sometimes certain playback sources need to be played on the internet. Configuring this forwarding through a config file is not very flexible.

Could you please add this functionality or suggest a way to achieve a similar effect? Alternatively, could you provide guidance on how I can quickly modify the code to achieve this functionality?

TRANS_BY_GPT3

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.