-
Notifications
You must be signed in to change notification settings - Fork 15
-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Moonraker-Timelapse integration #119
Comments
Make is missing because the system is not capable of compiling anything and thus does not need make. If you want it you'd need to alter the buildroot configuration in one of the variants. You can run the install script manually but it assumes systemd is there which is not installed (since it is not needed). It will have to be installed manualy. (copy the timelapse.py to the correct dir, add the timelapse.cfg to be included in printer.cfg) It will then fail because it needs ffmpeg which is also not installed (and needs to be cross compiled anyway, you might see a pattern here). I'll have another go at it next week to see if ffmpeg, in this very specific case, does not eat all the available memory. No promisses though as ffmpeg has the tendency to eat all the memory it gets and then some and there is only 128mb available. |
I believe this could work. I looked at the plugin source code a few days ago. The only thing that ffmpeg does is to create a h264 encoded mp4 file from the saved JPEG frames. If h264 encoding needs to much memory, it should be possible to modify the plugin to use ffmpeg to just create an MJPEG video of the saved frames without re-encoding. That encoding happens after the print. |
That;'s what I figured from it. ffmpeg isn't too much of a problem to get working, just hogs memory but if the printer is idle it should be fine. h264 depends a bit on the settings, can be quite lean (just takes a while) |
Added ffmpeg and libx264/265/h264 to give people some options. See feature/ffmpeg branch. /root/printer_data/timelapse/images/ is used for images, /root/printer_data/timelapse for timelapses. timelapse plugin is collected from git and added during post_build, timelapse.cfg is included at all times as it auto-disables if the moonraker config is missing. This should also solve #84 #74. Things of note, tested with x264:
smem during long render with 456 frames from disk (about halfway during rendering):
I think the render settings need tweaking to get something properly usable. Any suggestions? Any clue how flashforge stock does it? |
@consp |
The 450 frame x264 one was ~19MB not huge, if people want to get a smaller size re-encoding is also an option outside of the printer. At about 130-150KB/frame (jpg) the mjpeg would be 60-70MB. Maybe we can tweak the snapshot's as well to reduce the size a bit if needed. If it's not re-encoding the memory use will also drop significantly is my guess but I'm not too well versed in ffmpeg. |
Ok, I can confirm that it's painly slow to render the video with default settings. Probably because lots of other processes need to be swapped. And it does sometimes trigger Klipper shutdown due to timing error, even though no print is running. I printed a calibration cube, that gives 99 frames. This is encoding with the default settings:
Limiting to one thread, already a bit faster because we are memory constrained, not CPU limited.
Using ultrafast preset, already much better. This avoid b-frames and therefore needs less memory.
Increasing CRF to 28. Makes the file smaller, but not much advantage otherwise.
Increasing the group size (less key frames). Only slight reduction in final file size:
Using constant bitrate instead of constant quality. No improvement.
No encoding, just mux MJEPG into MP4. That is very fast, but still takes some memory.
Rencoding the JPEG files. Output still looks good, but takes surprisingly much memory for the task.
These are the resulting files:
Based on these tests I would either recommend to not reencode the JEPGs or to use optimized H264 settings: I attached the video. And yes, my LEDs are a bit overpowered 😄 I think that was at 80% LED intensity and flickers a bit due to PWM. test.mp4 |
There are more things to look at:
|
I renamed the ticket to make more sense. Other points:
The time util that I used to benchmark ffmpeg was not included, I added it on master. |
Ok so I’m new to all this so be patient, I don’t think this is the Timelapse I was thinking of. What I was wanting to do was the Timelapse thru Mainsail/fluid like a beagle cam can do. Where basically it parks the print head at the same spot after every layer, takes a snapshot then resumes printing the next layer and so on. |
It seems to be a pretty common mainsail/fluid “plugin” |
This is exactly what it is but I disabled print head parking in the options (could be enabled easily). I wanted to test if I observe any slowdowns due to the timelapse plugin, fortunately not but also did not watch it closely. I consider parking the print head at each layer impractical for actual prints that are not just for show, since it can produce print artifacts. But the timelapse feature is also useful for long unattended prints, to see where the print started fail. |
Perfect! Yea I agree, and I’m sure it takes 4x as long lol. Was mainly looking to use it for instagram content, won’t be a regular occurrence. |
Forgot to push it ... it's in printer_config now
Probably a good idea, after it's settled what to use. |
Ok, after lot of testing, I think I found the optimal settings for timelapse encoding.
gives lowest memory usage I could achieve and it's also a good tradeoff between speed and final file size. I thinks it's running quite decent. This example is for 99 frames (calibration cube at 0.2 layer height): /usr/bin/time benchmark
smem during rendering:
Memory usage should be independed from the video length, and full print of 220mm should be rendered in less then 10min. To achieve this I also had to strip down ffmpeg to the bare minimum. That alone reduces memory usage by 10M! Basically all other encoder options are worse than x264. Just muxing the JPEGs without encoding does not work, because Mainsail and Fluidd can't display the file in the browser, although it works for proper players like VLC. The optimized settings for AD5M must be patched into timelapse.py |
Oof, that must have been quite some work. Good to see the memory reduced, should even be usable with klipperscreen.
We should definetly mention that so people do not complain it takes too long or report "bugs".
Might be better to just staticly include it then and update if needed. It's not like it's a high-change product. |
Was just digging around in the original firmware (to check the changes in the update).
Settings used, it uses mplayer's mencoder.
I'll edit it in and add the timelapse.py as a pre-installed file in the post buildroot script to be copied. It's a simple script, shouldn't be too much of an issue to include it as static instread of pulling it from github. |
Isn't mplayer mencoder just using ffmpeg internally, or is that really a separate thing? |
Did |
Pushed to branch, most changes are in the config, some in the file. Added file to Can be closed if merged I guess. |
It's looking good in it's current state. Render was successful even with klipperscreen running: The feature is on master now. We can close this issue. |
im trying to ssh the moonraker timelapse plugin for mainsail and i keep getting
-sh: make: not found
Seems im missing "make" any idea how to get/install it?
The text was updated successfully, but these errors were encountered: