yi-hack-MStar replaces the firmware on half of the Yi camera range

Two firmwares for two chipsets, and you cannot mix them

The project is custom firmware for Yi cameras based on the MStar platform, and it is built on the work of TheCrypt0, whose yi-hack-v4 covers the other half of the range. The readme is emphatic about the split, saying in bold that you cannot choose between TheCrypt0 and MStar. If your camera is on the Hi3518e chipset you have to use TheCrypt0, and if it is on the MStar Infinity chipset you have to use this one. That is a reasonable boundary for a clone, since the two are different platforms with different boot chains, and it is worth checking before anything else, because a firmware built for the wrong SoC will not boot. The author also says they have no time to support the project and invites you to clone or fork it and modify it as you want, which tells you what kind of relationship with the code to expect.

Flashing is an SD card, two lights and a web interface

The install procedure is written as ten steps and it is unusually explicit. You check the supported cameras section and note the file prefix for your model, then format an SD card as FAT32, with the recommendation to format it using the camera's own native format function, and to remove all the files if the card is already formatted. You download the latest release matching the prefix, extract the archive to the root of the card, which produces directories such as `home_y203c` and `sys_y203c`, insert the card and reboot the camera. The yellow light then comes on and flashes for roughly thirty seconds, which means the firmware is being flashed, and the camera boots. The yellow light comes on again for the final stage, which takes up to two minutes, and then a blue light indicates that the WiFi connection worked, though it can be disabled with the app if you would rather it did not. After that you browse to the camera's web interface, and the IP address comes from the mobile app under Camera Settings, Network Info, IP Address, or from the list of connected devices on your router. The updates afterwards go through the Maintenance page in that web interface, with an Upgrade Firmware button and a reboot.

The RTSP server reads the video out of kernel memory

The streaming feature is the reason most people flash this firmware, and the implementation detail is the interesting part. The author wrote a daemon that reads the video stream directly from the kernel driver memory and sends it to an application based on live555, and the result is three RTSP URLs, one for the high resolution stream, one for the low resolution stream and one for audio only:

rtsp://IP-CAM/ch0_0.h264             (high res)
rtsp://IP-CAM/ch0_1.h264             (low res)
rtsp://IP-CAM/ch0_2.h264             (only audio)

The code derives from live555 and from an archive of source that was posted in a discussion thread on the 1080p repository, so this is a port of somebody else's server rather than something written from scratch. The alternative to this approach would be to ask the camera's own application for a stream over the vendor's protocol, which is what the vendor firmware does internally, and the reason the author went lower is that the vendor route does not give you a standard stream you can point anything at.

The audio path is where the real work went

The audio support was contributed separately and the readme explains the whole data path, which is the clearest description of how the camera's sound stack is put together. It goes from the microphone through the ADC, into the kernel sound driver, through the TinyAlsa library, into the OMX ALSA plugin, and finally into the camera application. The constraint that makes this hard is that the audio has to be cloned at one point in that chain so it can be both sent to the original application and tapped for the RTSP server, and the readme lists why each step is awkward. The kernel driver can be used by one sink, TinyAlsa can only be opened by one sink, and the OMX libraries are closed source and not compatible with the available I1 SDK. The solution was to replace the original TinyAlsa library with a version that copies the read audio frames into a pipe, and the RTSP server then reads that pipe through a patched WAV file source, with the WAV header read twice being the reason the author hardcoded it.

Standard camera interfaces, and a web page for the recordings

The rest of the feature list is the set of things a vendor firmware tends to hide. There is an ONVIF server with support for stream, snapshot, ptz, presets, events and WS-Discovery, which is the standardised interface network video recorders expect. There is a snapshot service that returns a jpg over a web request, with the resolution and the watermark as parameters:

http://IP-CAM/cgi-bin/snapshot.sh?res=low&watermark=yes        (select resolution: low or high, and watermark: yes or no)
http://IP-CAM/cgi-bin/snapshot.sh                              (default high without watermark)

There is MQTT event publishing for motion detection and baby crying detection, a web server for configuration, SSH through dropbear, Telnet through busybox, an FTP server and an FTP push mode that exports mp4 video to a server, plus a web page for managing motion detect events and viewing recorded video, PTZ control and presets where the camera supports them, a timelapse feature, a swap file on the SD card, and load, save and reset of the configuration. Authentication is applied to the HTTP, RTSP and ONVIF servers, and there are also separate projects for Google Drive and OneDrive synchronisation and an rsync based backup.

Region locks, watermarks and the cloud

Three features are worth singling out because they are the ones that change what the device can do rather than what it can connect to. Proxychains-ng is included but disabled by default, with the comment that it is useful if the camera is region locked, which is the practical meaning that a camera sold in one market will not stream to a server in another. The original watermark image is removed, which is a matter of the image the camera burns into its own video output. And the possibility to disable all the cloud features is listed among the settings, alongside the ones copied from the official app, which are the camera on and off, the video saving mode, the detection sensitivity, the motion detections, the baby crying detection, the status LED, the infrared LED and the rotation. The repository also ships a `stock_firmware/` directory and a `VERSION` file, so the original firmware is kept alongside the replacement.

Who is maintaining this, and under what licence

The project is GPL-3.0 licensed, which is the right licence for firmware that people flash onto their own devices and then modify, and the tree includes the source, the build scripts and the stock firmware images, with submodules configured in the repository. The releases are versioned 0.5.8 from 2026-09-27, 0.5.7 from January 2026 and 0.5.6_1 from December 2025, so the project is still shipping, and the last push to the repository was on the same day as the newest release. The honest caveat is the one in the readme, that the author has no time to support the project and invites you to fork it. A separate repository of optional utilities exists alongside, some of them experimental, including text to speech. And the unbricking section in the table of contents is there for a reason, since a firmware flash on a consumer camera is an operation that can leave a device with no working software, and the value of that section is that somebody thought about it before you needed it.

Editorial conclusion

yi-hack-MStar suits somebody with a Yi camera on the MStar chipset who wants a proper video stream, standard camera interfaces and control over a device that came with a locked down cloud, and it suits somebody who wants to read how a firmware replacement is assembled from a stock image plus a set of services. It is a poor fit if your camera is on the Hi3518e chipset, because the readme is explicit that the two projects are alternatives rather than choices, and it is a poor fit if you need someone to maintain it, since the author says plainly that they have no time to support the project. Before you flash it, check three things: which chipset your camera has and which project that implies, that you can restore the original firmware if the flash goes wrong, and that you are comfortable with the fact that the streaming path here reads video out of kernel driver memory, which is the clever part and also the part that breaks first when the vendor changes something.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. roleoroleo/yi-hack-MStar on GitHub