Rendered Timelapse format is unrecognized by media player

[sdiniz-truelogic]

Hello, hope all is well.

After the time lapse is rendered to video, the MP4 isn’t recognized as a valid video. All video players I tried display a message stating the file is not a valid video. Even the web page in Fluidd to visualize the video isn’t able to display it.

To get a valid video, I download all the individual frames and use Photoshop “image sequence” feature to render the video.

I’m also able to use Handbrake video converter to convert the “unsupported” video to a supported format.

Is there a way to configure the encoding CODEC or format?

[brightandshinyobject]

I have a similar issue, I can download the file and play it directly with VLC but the browser indicates an unsupported mime type. Did you ever find a solution?

[Hawk84r]

Same here. I believe encoding settings are set to unsupported codec to play in browser and there is no control over encoding settings at all. Creality K1 on latest firmware.

[ThaStealth]

Same problem here

[zellneralex]

I debugged it with a creality owner. The issue is the crappy image creality provides. The version of ffmpeg is too old. And the sources of the image does not allow to update it to the newer version. All “new” Linux distributions use 4.3..6 and the image uses 4.2.2.

The only solution for creality users is to complain by them so that they update there sources.

The only way is to download the single snapshots and render them manual on the PC

[Hawk84r]

I debugged it with a creality owner. The issue is the crappy image creality provides. The version of ffmpeg is too old. And the sources of the image does not allow to update it to the newer version. All “new” Linux distributions use 4.3..6 and the image uses 4.2.2.

The only solution for creality users is to complain by them so that they update there sources.

The only way is to download the single snapshots and render them manual on the PC

Some debugging you did. Crappy ffmpeg version? Sure. But it does have h264_v4l2m2m encoder which IS playable in browser. Encoding frames ON machine with "ffmpeg -framerate 30 -pattern_type glob -i '*.jpg' -c:v h264_v4l2m2m -pix_fmt yuv420p out.mp4" produces crappy quality video but quite happily viewable in at least firefox.

[zellneralex]

As said, talk to creality … it works on any other distribution.

[Hawk84r]

As said, talk to creality … it works on any other distribution.

Let's get back to your research for a jiffy: you say ffmpeg is at fault here as it doesn't support required encoders and just old. OK. As we are in moonraker-timelapse we sure have rooted K1's. And as we do have that, we also have Entware that is installable from same magic installer.sh. Which is software repository, quite like apt for debian, and allows us to do something like "opkg upgrade ffmpeg". Now I have ffmpeg 5.1.2 with libx264 available and working when I run it by hand.... And guess what? Timelapse doesn't care and encodes it with mjpeg still. Care to have another swing on that research of yours?

[zellneralex]

Nope as I do not own any creality product and never will …

It is open source, so you can try to modify the python file and submit a PR if you found a solution that works on creality and any other stuff.

It’s not that hard to find: https://github.com/mainsail-crew/moonraker-timelapse/blob/main/component/timelapse.py#L683 and following

[zellneralex]

Have you checked or set the ffmpeg path

# moonraker.conf

[timelapse]
##   Following basic configuration is default to most images and don't need
##   to be changed in most scenarios. Only uncomment and change it if your
##   Image differ from standart installations. In most common scenarios 
##   a User only need [timelapse] in their configuration.
#output_path: ~/timelapse/
##   Directory where the generated video will be saved
#frame_path: /tmp/timelapse/
##   Directory where the temporary frames are saved
#ffmpeg_binary_path: /usr/bin/ffmpeg
##   Directory where ffmpeg is installed

Maybe you have 2 versions installed, you can customize that location by setting it at ffmpeg_binary_path

[Hawk84r]

ffmpeg_binary_path:

Good guess. But no dice and moonraker.log confused me to hell: 2024-01-10 19:49:30,717 [timelapse.py:render()] - start FFMPEG: /opt/bin/ffmpeg -r 30 -i '/usr/data/printer_data/frames/frame%6d.jpg' -threads 2 -g 5 -vcodec mjpeg -pix_fmt yuv420p -b:v 7M -an '/usr/data/printer_data/frames/timelapse_Kar98K Base_PLA_49m3s.gcode_10-01-2024_19h49.mp4' -y 2024-01-10 19:49:32,673 [timelapse.py:render()] - Rendering Video successful: timelapse_Kar98K Base_PLA_49m3s.gcode_10-01-2024_19h49.mp4 I do have 5.1.2 installed in /opt/bin/ffmpeg and I seen code in timelapse.py with "-vcodec libx264" pretty much hardcoded. Where the hell does mjpeg come from? Nevermind that. Just found this in my /usr/data/moonraker/moonraker/moonraker/components/timelapse.py ` # build shell command cmd = self.ffmpeg_binary_path \

• " -r " + str(fps) \
• " -i '" + inputfiles + "'" \
• filterParam \
• " -threads 2 -g 5" \
• " -vcodec mjpeg" \
• " -pix_fmt " + self.config['pixelformat'] \
• " -b:v 7M" \
• " -an" \
• " " + self.config['extraoutputparams'] \
• " '" + self.temp_dir + outfile + ".mp4' -y"` Still need explanation on how it turned into that, thou I have a hunch it was specifically tailored for K1. Also as I have warning in updater that says "Repo has untracked source files: ['moonraker/components/timelapse.py']", so is it safe to assume it is not being updated with moonraker and I can safely edit it?

[zellneralex]

That is very strange, can you ssh in your sbc and run

cd moonraker-timelapse/
git config --get remote.origin.url

I see above that it might be on a different location at your install but I have no clue where. The picture shows the expected output

I am sure creality forked our repo and modified it.

[zellneralex]

”Still need explanation on how it turned into that, thou I have a hunch it was specifically tailored for K1. Also as I have warning in updater that says "Repo has untracked source files: ['moonraker/components/timelapse.py']", so is it safe to assume it is not being updated with moonraker and I can safely edit it?”

No please do not edit it local, the message only tells you that timelapse.py was added and is not part of the original moonraker install.

The component is normally linked. See the picture

I can only show you the path used on an RasperyOS (based on Debian).

[ThaStealth]

Yeah I figured out the problem, "we" K1 users are not using your github repo directly, @Hawk84r probably and myself installed it via the K1 helper scripts tool, which uses a modified timelapse.py, which in turn uses mjpeg in the ffmpeg call:

https://github.com/Guilouz/Creality-K1-and-K1-Max/blob/main/Scripts/files/timelapse/timelapse.py#L684

I think we can conclude here that the issue is not with you/this repo, but with a crappy implementation in the K1 helper scripts.

[Hawk84r]

@zellneralex Well, git config --get remote.origin.url on moonraker returns normal repo, no fork. BUT I looked at install script - it wget's it from the repo above an copies to components. So editing it is the only way I guess. To summarize steps for making timelapse viewable:

1. opkg update && opkg upgrade ffmpeg
2. edit moonraker.cfg adding ffmpeg_binary_path: /opt/bin/ffmpeg to [timelapse] section.
3. edit /usr/data/moonraker/moonraker/moonraker/components/timelapse.py and replace lines 683-694 with same lines from https://github.com/mainsail-crew/moonraker-timelapse/blob/main/component/timelapse.py
4. reboot printer. And I agree - this isn't problem of moonraker, so this can be closed now.

[zellneralex]

I added a bug in your K1 repo https://github.com/Guilouz/Creality-K1-and-K1-Max/issues/265

[zellneralex]

For me the K1 solution is a nightmare to be honest. We still improving it and normally any update will be shown in the updater as it is an own repo and both files (py and cfg) is only linked instead of a copy. Your helper script does not seams to do that

[Guilouz]

For me the K1 solution is a nightmare to be honest. We still improving it and normally any update will be shown in the updater as it is an own repo and both files (py and cfg) is only linked instead of a copy. Your helper script does not seams to do that

I agree with you however the moonraker timelapse installer does not work on K1 systems, the paths are not conventional. Even a simple restart of the klipper or moonraker services cannot be done via the update manager. Even the Reboot and Shutdown buttons didn't work initially without modification, this OS is a real nightmare.

I will update my script with this changes.

[zellneralex]

Ok the installer is simple in the end it only links to 2 files timelapse.py -> moonraker/moomraker/component timelapse.cfg -> printer_data/config

I did not compare what else you modified in the 2 files but if we get them in the original state you could regular clone the repo and I could help you that you then link these 2 files

[zellneralex]

For me the K1 solution is a nightmare to be honest. We still improving it and normally any update will be shown in the updater as it is an own repo and both files (py and cfg) is only linked instead of a copy. Your helper script does not seams to do that

I agree with you however the moonraker timelapse installer does not work on K1 systems, the paths are not conventional. Even a simple restart of the klipper or moonraker services cannot be done via the update manager. Even the Reboot and Shutdown buttons didn't work initially without modification, this OS is a real nightmare.

I will update my script with this changes.

Do not get me wrong here, I can not tell what challenges you where facing to “jailbreak” the creality image nor am I aware of what is working and what is not working on that OS.

The issue I have is quite simple, we spend a lot of time to find a way that user have the possibility and a easy way to update

• moonraker-Timelapse
• Mainsail or Fluidd default macros (in the end they are the same)
• …

And currently as I see it that isn’t possible for the users of your script. And that is as the maintainer of these components a real nightmare. Even worse we where not even aware of that the files where modified

[Guilouz]

For me the K1 solution is a nightmare to be honest. We still improving it and normally any update will be shown in the updater as it is an own repo and both files (py and cfg) is only linked instead of a copy. Your helper script does not seams to do that

I agree with you however the moonraker timelapse installer does not work on K1 systems, the paths are not conventional. Even a simple restart of the klipper or moonraker services cannot be done via the update manager. Even the Reboot and Shutdown buttons didn't work initially without modification, this OS is a real nightmare. I will update my script with this changes.

Do not get me wrong here, I can not tell what challenges you where facing to “jailbreak” the creality image nor am I aware of what is working and what is not working on that OS.

The issue I have is quite simple, we spend a lot of time to find a way that user have the possibility and a easy way to update

• moonraker-Timelapse
• Mainsail or Fluidd default macros (in the end they are the same)
• …

And currently as I see it that isn’t possible for the users of your script. And that is as the maintainer of these components a real nightmare. Even worse we where not even aware of that the files where modified

Installer can't work because some path on K1 OS are not conventional, moonraker is installed in /usr/data/moonraker/ and not in home directory.

The timelapse.py file had been modified to overcome the codec problem on the creality OS but now this can be corrected with entware and the ffmpeg update.

[Guilouz]

@Hawk84r I have tried with stock repo with updated ffmpeg but it take a while for render, it take many minutes and 1.09Mo just for 1s video.

It use libx264 and some people had problems with this encoding with the K1 camera, they had some sort of artifacts in their rendering.

This is why I modified using mjpeg which is faster encoding level and people no longer had these artifacts, like this:

       # build shell command
        cmd = self.ffmpeg_binary_path \
            + " -r " + str(fps) \
            + " -i '" + inputfiles + "'" \
            + filterParam \
            + " -threads 2 -g 5" \
            + " -vcodec mjpeg" \
            + " -pix_fmt " + self.config['pixelformat'] \
            + " -b:v 7M" \
            + " -an" \
            + " " + self.config['extraoutputparams'] \
            + " '" + self.temp_dir + outfile + ".mp4' -y"

        # log and notify ws
        logging.info(f"start FFMPEG: {cmd}")
        result.update({
            'status': 'started',
            'framecount': str(self.framecount),
            'settings': {
                'framerate': fps,
                'pixelformat': self.config['pixelformat']
            }
        })

@zellneralex have you any idea how we can optimize this ?

[Hawk84r]

@Guilouz I have no problem with artifacts on libx264 and quality is decent. Maybe you confusing it with h264_v4l2m2m, that is available in stock ffmpeg and also can be played online? 'Cause this one have severe artifact with overall dismal quality. Weight per second is a little high with libx264, but it is even higher with mjpeg. Encoding time was longer, but definitely less then 2 minutes. My mediainfo, which is curiously identical in lenght:

[Guilouz]

@Hawk84r Can you simulate 200 take frame and tell me how long for encoding?

[Tombraider2006]

@Hawk84r Can you simulate 200 take frame and tell me how long for encoding? 743 frames 15 minutes :-(

[Guilouz]

@Tombraider2006 @Hawk84r That's why I use mjpeg for encoding, K1 have a poor CPU and only 200MB of RAM.

[iosub]

For me the K1 solution is a nightmare to be honest. We still improving it and normally any update will be shown in the updater as it is an own repo and both files (py and cfg) is only linked instead of a copy. Your helper script does not seams to do that

Hi

A workaround is to add on the timelapse camera extra options -vcodec h264 -pix_fmt yuv420p It works for me

[Hawk84r]

@Hawk84r Can you simulate 200 take frame and tell me how long for encoding?

Tested on 203 frames, fps 30, crf 23, no vbr, dlf 5 (probably all default). Mine took 8:59.31, so yea, it's bad. But quite exceptable for me as I almost never review timelapses right after printing and rarely print back-to-back.

[Guilouz]

Fixed, See here: https://github.com/Guilouz/Creality-K1-and-K1-Max/wiki/Wiki-Changelog

You can close issue.

[zellneralex]

See comment above