ireader/media-server: C libraries for RTSP, RTMP, HLS and MP4 demuxing

What ireader/media-server actually is, and what it is not

The repository description is a list of formats: RTSP, RTP, RTMP, FLV, HLS, MPEG-TS, MPEG-PS, MPEG-DASH, MP4, fMP4, MKV and WebM. That list describes what the code parses and writes, not a service you launch. The top-level directory confirms the shape of the project: libdash, libflv, libhls, libmkv, libmov, libmpeg, librtmp, librtp, librtsp and libsip, plus a test directory. There is no server binary directory, no configuration file format, and no administration interface mentioned anywhere in the README.

The audience is therefore narrow and specific: developers writing C programs that need to read or produce these formats. If you are looking for something to install on a NAS and point a television at, this is the wrong layer of the stack. The README's own links make the distinction clear by pointing to ZLMediaKit, described there as a C++11-based streaming media service framework, which is the kind of project that builds a service on top of format handling. The README does not claim that ireader/media-server plays that role.

One consequence is worth stating plainly. Because the project is a set of libraries, questions about "setting up a media server" cannot be answered from this repository. There is nothing to set up beyond compiling the libraries and calling them.

The library split: which module handles which format

Each directory owns a defined slice of the problem, and the README lists the codecs supported inside each. libflv handles FLV video for H.264, H.265, H.266, AV1, VP8, VP9 and VP10, FLV audio for AAC, MP3, G.711 and Opus, FLV file read and write, plus bitstream filters in both directions: annex-b to mp4 stream for video, and ADTS to ASC for AAC. Those filters are the unglamorous part that most integrations need, because camera and broadcast streams arrive in annex-b and MP4 wants length-prefixed samples.

librtmp provides an RTMP client for publish and play, and an RTMP server for live and vod streaming. libmpeg covers ITU-T H.222.0 PS and TS read and write with H.264, H.265, H.266, AAC, MP3, G.711 and Opus. librtp implements RFC3550 RTP and RTCP, carries H.264, H.265, H.266, MPEG-2, MPEG-4, VP8, VP9 and AV1 video along with G.711, G.726, G.729, MP3, AAC and Opus audio, and supports RTP header extensions and the RTCP PSFB, RTPFB and XR feedback messages. librtsp implements RFC2326 RTSP and RFC4566 SDP, with fmtp handling for H.264, H.265, H.266, AAC, Opus and G.711.

On the packaging side, libhls generates m3u8 files, segments TS and fmp4, and parses master and playlist m3u8 files. libdash covers ISO/IEC 23009-1 static and dynamic DASH with an MPD v3 and v4 parser. libmov reads and writes ISO/IEC 14496-12 MP4, supports faststart by placing moov before mdat, writes fragmented MP4, and carries H.264, H.265, H.266, AV1, VP8, VP9, JPEG and PNG video with AAC, Opus, MP3 and G.711 audio. libmkv reads and writes MKV and WebM and handles live streaming in those containers. libsip provides a SIP user agent in both UAC and UAS roles with ICE. HTTP is not in this repository at all: the README attributes the HTTP server, client and cookie support to the separate ireader/sdk project.

The codec lists are not identical across libraries. libmov lists JPEG and PNG, which the streaming libraries do not. libflv lists VP10, which libmov does not. Anyone picking a container for a given codec should read the relevant list rather than assuming coverage is uniform.

Building the libraries with make

The README gives three make invocations at the top level. The default build produces debug output; setting RELEASE=1 switches to release. Cross compilation is done by passing PLATFORM with the toolchain prefix.

make clean && make

make RELEASE=1

make PLATFORM=arm-hisiv100nptl-linux

The Makefile shows what happens underneath. The all target recurses into libdash, libflv, libhls, libmkv, libmov, libmpeg, librtmp, librtp, librtsp and libsip in that order. When PLATFORM is not set, the Makefile reads /etc/os-release to build a platform string from the distribution ID and version, and determines 32 or 64 bits from uname or getconf. The build directory is named debug or release depending on RELEASE, and the platform string is appended, which is why the test target references paths like test/$(BUILD).$(PLATFORM)/test.

There is a dependency the README states at the top: build dependence on https://github.com/ireader/sdk. The test target makes this concrete, since it runs make in ../avcodec and ../sdk before building test, then symlinks libaio.so from ../sdk/libaio/$(BUILD).$(PLATFORM)/ into the current directory and executes the test binary. In other words, the test target assumes the sdk repository is checked out as a sibling directory. The README does not describe what happens if that sibling is missing; the Makefile simply fails at that step.

The README also points to compile.cn.md for compilation notes. That file is in Simplified Chinese, and the English README does not restate its contents, so non-Chinese readers lose whatever detail it carries. For a first real use, the honest answer is that this repository does not ship a runnable example in the README. The test directory is the only entry point named, and reaching it requires the sibling sdk checkout described above.

Where the library approach stops being enough

The clearest limitation is the absence of a service layer. Nothing in the README describes session management, authentication, stream routing, recording policy or a control API. An RTMP server is listed in librtmp, but the README does not document configuration, ports or how multiple streams are distinguished, so anyone expecting to run it as a deployable endpoint has to read the source and the test directory to find out what the API expects.

The second limitation is codec coverage that varies by library. If your pipeline is H.266 over RTSP into fragmented MP4, both librtsp and libmov list H.266, so the path exists on paper. If your pipeline involves JPEG or PNG frames, only libmov lists them, and you would need to handle the transport yourself. VP10 appears only in libflv. These are not gaps in the sense of missing features; they are boundaries you have to check before designing around them.

The third is build environment. The Makefile depends on /etc/os-release to compute a default platform string, which means the non-cross-compile path assumes a Linux distribution that provides that file. The test target additionally assumes a sibling sdk checkout and manipulates libaio.so through a symlink in the current directory. Neither assumption is documented in the English README beyond the single build-dependence link.

Finally, the README records no release history and no version tags. There is a Coverity Scan build status badge at the top, which indicates static analysis is part of the project's process, but the README does not describe a release cadence, a changelog or a support policy. The last push to the default branch was on 2026-05-26.

How this differs from ZLMediaKit and from a packaged media server

The README links to ZLMediaKit and describes it as a high-performance carrier-grade streaming media service framework based on C++11. That is the honest comparison point, and the difference is architectural rather than a matter of quality. ZLMediaKit is positioned as a service framework: you get a running server that speaks these protocols. ireader/media-server is the set of C libraries underneath that kind of work, with a C API and per-format modules you link into your own program.

Choosing between them comes down to what you are building. If you need a process that accepts RTSP pushes and serves HLS to browsers, the service framework answers that directly. If you are writing a recorder, a transcoder front end, a protocol gateway or an embedded component that must parse TS and write fMP4 inside a larger C program, the library form is the one that fits, because you control the event loop and the memory model. The README's own description of the HTTP layer as living in a separate sdk repository reinforces this: the project expects you to bring your own application shell.

The same distinction applies against packaged media servers in general. Those products bundle a database, a scanner, a user interface and client apps. None of that is present here, and the README does not suggest it is planned.

Licence and the cost of staying current

The repository is MIT licensed, with a LICENSE file at the top level. MIT is permissive: it allows use in closed-source products provided the copyright notice and permission notice are retained. That matters for the embedded and commercial integrations this library set is aimed at. This is a description of the licence text, not legal advice; if your organisation has specific obligations around attribution in binary distributions, have counsel read the LICENSE file rather than relying on a summary.

Upgrade cost is harder to judge. There are no retrieved releases, so there is no changelog to diff against and no version numbers to pin. The default branch is master, and the last push was on 2026-05-26. Anyone vendoring these libraries should decide how they will track upstream changes, because there is no tagged release line documented in the README to follow. A practical approach is to record the commit hash you build against and re-run the test target after each update, since that is the only verification path the repository names. Note that the test target reaches outside the repository into a sibling sdk checkout, so it is not a self-contained check.

Editorial conclusion

Adopt ireader/media-server if you are writing a C or C++ program that needs protocol or container parsing at the library level, and you are willing to supply the session management, storage and HTTP serving yourself. Do not adopt it if you expect a running server with a web UI, user accounts or a client app, because the repository contains none of that. Before committing, read compile.cn.md for the build details the English README omits, confirm the ireader/sdk dependency builds on your target, and check whether the codec you need appears in the relevant library list, since the format coverage differs between libflv, libmov and libmpeg.

Frequently asked questions

Official sources

1. ireader/media-server on GitHub
2. Issues
3. License: MIT
4. README