ovsyunlive is a Windows and Linux media gateway that puts RTSP and RTMP into a browser

A protocol translation gateway for live video

The repository description is a long list of use cases: web playback of RTSP, Web live streaming with RTMP push, no plugin playback of RTSP and RTMP directly in the browser, SIP hardware, arcade gaming streams, desktop remote control, game remote control, video conferencing, MCU and SFU conferencing, meeting streaming, RTSP monitoring, two way video talk, Web pushing, an FLV player, Web desktop streaming, WebSocket stream forwarding, http-flv and ws-flv support, live recording, multi channel stream forwarding, Gb28181 monitoring live streams, WebRTC pushing and playback, game streaming, telemedicine, video safety helmets and set top boxes. Underneath those is one job: take video arriving over one protocol and make it available over another. The project is written primarily in JavaScript and the tree carries a web_src/ directory and a www/ directory, which hold the browser side of the system, while the server side ships as compiled executables. The homepage field is empty, the repository is not archived, and the last push was on 2026-09-20. There are no GitHub releases, and the licence is one GitHub cannot classify, so the terms are not stated in the repository listing.

The ports and address scheme

The README documents a fixed port layout, which is the most operationally useful part of the document because the addresses are how you reach every function. The RTMP push address for a test stream is rtmp://IP:1937/live/test001, and the same stream is republished as RTSP on rtsp://IP:7554/live/test001, as WebRTC on webrtc://IP:7701/live/test001, as FLV over HTTP at http://IP:7701/live/streamid.flv, as SRT at srt://IP:7900 with a streamid parameter, and as ws-flv at ws://IP:7701/live/streamid.flv. The browser player for those streams is at http://IP:7701/play/index.html. The streaming address is the same identifier across every protocol, so one stream ID maps to an RTMP ingest, an RTSP endpoint, a WebRTC endpoint and two HTTP style playbacks at once. That uniformity is what makes the gateway usable: an application does not have to know which protocol its source speaks, it publishes once and every consumer protocol is derived from the same name. The demo addresses are published for the hosted test environment.

http://m.ovmeet.com:7701/play/index.html

A link that plays a stream directly is also given, with the RTSP URL as a query parameter.

http://m.ovmeet.com:7701/play/play.html?rtsp://admin:[email protected]/live0.264

Two lines of JavaScript to embed a player

The integration story is the project's strongest selling point. The README shows that embedding a stream in a page takes two lines: the page loads the minified player script, you point it at the server address, and you connect it to the stream you want to play. The reference implementation lives in the play/demo.html file: the page loads the minified player script, you declare the server address in a srvurl variable, you create an OvPlayer on the video element with that address, and you call connect with the stream URL you want to play.

The three lines above are shown with the server address variable and the connect call, and they cover the whole browser side: no plugin, no Flash, and the same code path for an RTSP source as for an RTMP one. The FLV player is described separately as cross platform with H265 support and easy integration, which matters because H265 is common in industrial camera hardware and many browsers will not decode it natively without a WebAssembly path, so the transcoding the server does is what makes those feeds watchable. The README also describes automatic intelligent audio transcoding, where the playback path converts to a format the browser recognises, and where a web RTMP push is transcoded to H264 and AAC for compatibility with mainstream platforms.

Distribution as binaries and the configuration file

How the software is delivered is worth understanding before you evaluate it. There are two test packages, a Win64 archive and a Linux archive, and the instructions are to unzip and double click start.bat on Windows, with stop.bat to stop it, and the README says the commercial version supports Windows and Linux. The server program needs an IP address assigned, and the README says to configure the exthost value in the ovmedia.ini file with the public IP address, or with an internal IP address on a LAN, and to restart afterwards. The repository tree confirms the shape of the distribution. It contains ovsyunlive.exe, ovsyunmedia.exe and ovsviser.exe, alongside a set of FFmpeg derived shared libraries such as avcodec-60.dll, avformat-60.dll, avutil-58.dll, swscale-7.dll, swresample-4.dll, avfilter-9.dll and avdevice-60.dll, plus postproc-57.dll, a crypto stack in libcrypto-1_1-x64.dll and libssl-1_1-x64.dll, and srtp2.dll for SRTP. There is also cmdsys.bat, a keys/ directory, a log/ directory, a static/ directory and the .ovsyundb/ data directory. In other words, this repository is a release drop of a compiled product rather than a source tree you can build, and the browser side lives in web_src/ and www/.

Conferencing, MCU and SFU modes

Beyond the streaming gateway the project covers the meeting and media centre side, and the README lists the problems it claims to solve: multi screen monitoring and compatibility, different encodings on the web with H265 and H264, multi protocol compatibility including SIP meetings, Gb28181 monitoring, RTSP and RTMP unified in one place, scheduling across functions, and multi screen recording. The conferencing features listed are WebRTC, RTSP and RTMP support with live participants joining, a remote whiteboard, document sharing, video recording and live streaming of the meeting, and support across PC, Android and iOS. There is a one click meeting API that takes a room, a password, a name and flags for audio, video, screen share and notification. The MCU plus SFU media centre is demonstrated separately from the MCU with SIP voice over IP bridge. The deployment story also mentions distributed clusters for arcade game live streaming, with front end nodes separated from video source service nodes, and an admin web backend that is open source while the rest of the solution ships as a green installation package.

Where ovsyunlive is the wrong tool

Four limits are worth naming. The first and largest is that the repository is a binary drop. The server side arrives as executables and DLLs with no server source in the tree, so you cannot read the code that terminates TLS, parses RTSP, handles SIP signalling or manages the meeting state, and you cannot patch it when a codec or a protocol changes. For a component that sits between your cameras and your users, that is a serious operational fact, and it is compounded by the licence, which GitHub does not classify, so the terms of use are not visible from the repository at all. The README's own wording is that the downloads are test builds, that they are adjusted and updated from time to time, and that commercial use requires authorisation, so even the licensing of the product as distributed is a question for the author rather than something you can read. The second is the precompiled FFmpeg. The DLL versions are pinned, which is good for stability and bad for security, since a server that parses RTSP from untrusted networks is exactly the kind of process where a stale media library matters, and you cannot rebuild it. The third is the fixed port scheme. Ports 1937, 7554, 7701, 7702, 7900, 7777, 9902 and 9301 are hard coded into the documented addresses, which makes the product awkward to place behind an existing reverse proxy or to run twice on one host without a network namespace. The fourth is the age of the client stack. The player is a global constructor loaded from a minified script, with no module build and no documented npm package, which fits an era of HTML5 video and does not fit a modern bundler based front end, and the same applies to the WebRTC story, since the recommended browser is Chrome and the whole conference path depends on it. The realistic alternative for a browser viewing problem is a media gateway you build yourself from FFmpeg plus a well supported player, for example an hls.js or flv.js front end over an nginx reverse proxy, which gives you source you can audit and a dependency chain you can update, at the cost of building the SIP, Gb28181 and conference bridging that ovsyunlive already provides.

Editorial conclusion

Adopt ovsyunlive if you have cameras or encoders producing RTSP or RTMP and you need those feeds in a browser, in a second screen, or inside a meeting, because the package handles the protocol conversion and the player integration in a way that takes two lines of JavaScript on the page. Do not adopt it if you need a source you can build and audit, because the repository distributes Windows executables and DLLs rather than the server source, and the licence field is one GitHub cannot classify. Verify two things before you build a product on it: which parts of the product need the commercial version, since the README describes the downloads as a test build and says commercial use requires a licence, and what the licence actually permits, because the repository's own licence classification is unknown. The practical first step is to download the Windows or Linux test package, run start.bat or the equivalent, and push a test stream to the documented RTMP address to confirm the whole chain works before designing around it.

Frequently asked questions

Official sources

1. ccallcn/ovsyunlive on GitHub
2. Issues
3. README