Hi guys! I recently created a little art project using a Luckfox Pico 2B Mini. I successfully created a working RTSP video server that isn't bound by the limitations of the SDK. As you probably know, the SDK only allows streaming a camera, and only very low quality (8 kHz mono) audio is possible.
Now it is possible to run realtime visuals on the Luckfox, and display it to a screen. The maximum resolution I tried was 640x480 at 25 fps with 44.1 kHz stereo PCM sound. It works fine; higher resolutions are limited by RAM constraints. The only drawback is the stream lag, which is up to 2-3 seconds at times. This doesn't mean the stream stutters, it's just that much behind what the board actually outputs. So it's not a feasible way to run a video game, but it's still good enough for visual demos, which was my goal. My device now plays Bad Apple and a demo I made.
You can find the code in this repository:
https://tomcatmwi.github.com/family_friendly
Dear Luckfox team! Here is my honest criticism to you. You may be OK engineers, but you're woefully mentally unequipped to be hackers. The "OK engineers" part is because the SDK is a terrible mess. Setting a specific version of a specific Linux distribution as a requirement is outright lame, but it's not even the worst part. The whole shebang barely works, and it severely constrains development. For example how come the hardware H264 encoder is inaccessible? Why did you decide that I don't need it? I bought the whole board, I want to use the whole board!
My impression of your product is that it was all built with rigid compliance in mind, expecting users to do only what they are allowed to. This makes it a poor project platform. Sorry, but you need more to beat Raspberry Pi than just awesome ideas and a low price tag. You must implement those ideas, or you're never going to win. More rock and roll please!
SDK-free RTSP streaming on Luckfox Pico
Thank you for your feedback.
At the moment, our resources and capacity are limited, so we are unable to refactor the entire SDK based on Rockchip. While advanced users may have the need to use different kernel versions, the majority of users prioritize stability and a working system.Using alternative kernel versions can lead to compatibility issues with Rockchip’s proprietary drivers, such as the H.264 hardware encoder you mentioned.
We are only a solution provider based on Rockchip chips and are not involved in the development of the chip drivers. The materials and documentation we have are the same as those provided by Rockchip, and our work is mainly based on secondary development using those resources. Therefore, we are not in a position to decide which parts can be made public and which cannot.
At the moment, our resources and capacity are limited, so we are unable to refactor the entire SDK based on Rockchip. While advanced users may have the need to use different kernel versions, the majority of users prioritize stability and a working system.Using alternative kernel versions can lead to compatibility issues with Rockchip’s proprietary drivers, such as the H.264 hardware encoder you mentioned.
We are only a solution provider based on Rockchip chips and are not involved in the development of the chip drivers. The materials and documentation we have are the same as those provided by Rockchip, and our work is mainly based on secondary development using those resources. Therefore, we are not in a position to decide which parts can be made public and which cannot.
Had a similar case where it booted but stayed on a white screen with no output. Feels like a display init or firmware issue did you check if the driver is actually loading?tomcatmwi wrote: ↑2026-04-05 21:04 Hi guys! I recently created a little art project using a Luckfox Pico 2B Mini. I successfully created a working RTSP video server that isn't bound by the limitations of the SDK. As you probably know, the SDK only allows streaming a camera, and only very low quality (8 kHz mono) audio is possible.
Now it is possible to run realtime visuals on the Luckfox, and display it to a screen. The maximum resolution I tried was 640x480 at 25 fps with 44.1 kHz stereo PCM sound. It works fine; higher resolutions are limited by RAM constraints. The only drawback is the stream lag, which is up to 2-3 seconds at times. This doesn't mean the stream stutters, it's just that much behind what the board actually outputs. So it's not a feasible way to run a video game, but it's still good enough for visual demos, which was my goal. My device now plays Bad Apple and a demo I made.
You can find the code in this repository:
https://tomcatmwi.github.com/family_friendly
Dear Luckfox team! Here is my honest criticism to you. You may be OK engineers, but you're woefully mentally unequipped to be hackers. The "OK engineers" part is because the SDK is a terrible mess. Setting a specific version of a specific Linux distribution as a requirement is outright lame, but it's not even the worst part. The whole shebang barely works, and it severely constrains development. For example how come the hardware H264 encoder is inaccessible? Why did you decide that I don't need it? I bought the whole board, I want to use the whole board!
My impression of your product is that it was all built with rigid compliance in mind, expecting users to do only what they are allowed to. This makes it a poor project platform. Sorry, but you need more to beat Raspberry Pi than just awesome ideas and a low price tag. You must implement those ideas, or you're never going to win. More rock and roll please!