Skip to content
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

Timelapse render #1317

Closed
Fires04 opened this issue Apr 24, 2016 · 18 comments

Comments

Projects
None yet
5 participants
@Fires04
Copy link

commented Apr 24, 2016

Hello, I got problem with timelapse.
In control window my webcam works well .. But if I download rendered timelapse I have errors in video : https://www.youtube.com/watch?v=L3VTmWisaiU ??

Version octoprint: latest stable
Timelapse setup : timed 25fps, 0 post, 10sec interval)
Camera: Genius - I do not know exact type some cheap but same problem with other webcam.

Timelapse should be rendered without artefact.

Timelapse has been rendered with artefacts.

Version: 1.2.10 (master branch)

Prusa I3 original Czech

Chrome 49.02623 , Windows 10 Czech x64

http://pastebin.com/1aCcQDWR

https://www.youtube.com/watch?v=L3VTmWisaiU

I have read the FAQ.

Google group with this problem : https://groups.google.com/forum/#!topic/octoprint/BDvEiUO0H5E

@GitIssueBot

This comment has been minimized.

Copy link
Collaborator

commented Apr 24, 2016

Hi @Fires04,

It looks like there is some information missing from your bug report that will be needed in order to solve the problem. Please take a look at the Contribution Guidelines which will provide you with a template to fill out here so that your bug report is ready to be investigated (I promise I'll go away then too!).

If you did not intend to report a bug, please take special note of the title format to use as described in the Contribution Guidelines.

I'm marking this one now as needing some more information. Please understand that if you do not provide that information within the next two weeks (until 2016-05-08 12:00) I'll close this ticket so it doesn't clutter the bug tracker. This is nothing personal, so please just be considerate and help the maintainers solve this problem quickly by following the guidelines linked above. Remember, the less time the devs have to spend running after information on tickets, the more time they have to actually solve problems and add awesome new features. Thank you!

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being, so don't expect any replies from me :) Your ticket is read by humans too, I'm just not one of them.

@Fires04

This comment has been minimized.

Copy link
Author

commented Apr 24, 2016

Hello, I got problem with timelapse.
In control window my webcam works well .. But if I download rendered timelapse I have errors in video : https://www.youtube.com/watch?v=L3VTmWisaiU ??

Version octoprint: latest stable
Timelapse setup : timed 25fps, 0 post, 10sec interval)
Camera: Genius - I do not know exact type some cheap but same problem with other webcam.

Timelapse should be rendered without artefact.

Timelapse has been rendered with artefacts.

Version: 1.2.10 (master branch)

Prusa I3 original Czech

Chrome 49.02623 , Windows 10 Czech x64

http://pastebin.com/1aCcQDWR

https://www.youtube.com/watch?v=L3VTmWisaiU

I have read the FAQ.

Google group with this problem : https://groups.google.com/forum/#!topic/octoprint/BDvEiUO0H5E

@foosel

This comment has been minimized.

Copy link
Owner

commented Apr 26, 2016

The timelapse is rendered basically by stitching the snapshots taken from your camera together. OctoPrint is basically doing nothing else than downloading those images from the camera (or rather, the webcam server) and then invoking ffmpeg to have it stitch all images together.

Nowhere in that workflow does OctoPrint itself process those images in any way.

What I'd suggest for you to take a look is how the snapshot images look like, because chances are high those are already broken. If so you'll need to figure out how to fix that (bug in mjpg-streamer? broken chipset driver? at least nothing OctoPrint can do anything about). If you are running OctoPi, you can go to http://octopi.local/webcam/?action=snapshot, refresh that page repeatedly, see if that shows the same errors in the displayed single image. You refreshing that page in the browser is basically the exact same thing that OctoPrint is doing when taking snapshots for the timelapse recording.

Please report back how that goes.

@Fires04

This comment has been minimized.

Copy link
Author

commented Apr 26, 2016

Hi, call action right on octopi produce perfect image .. So problem has to be in process of merging images to video

@foosel

This comment has been minimized.

Copy link
Owner

commented Apr 26, 2016

Does it produce a perfect image every time?

Next step would be: Start a print with enabled timelapse, some time before it ends (but after it has been running for a while) SSH into your pi and secure what's in ~/.octoprint/timelapse/tmp:

mkdir ~/timelapseBackup
cp -r ~/.octoprint/timelapse/tmp/* ~/timelapseBackup

Go through those images, make sure they also are fine. Keep them around and compare with the rendered video. If the images are fine again but the video is definitely not, I agree, it has to be something to do with how ffmpeg stitches them together, but figuring out what that might be (wrong parameter which would mean a new feature needed in OctoPrint to be able to adjust those parameters in the first place vs. bug in the ffmpeg version you are using which I can do absolutely nothing about) we'll tackle if necessary.

Oh, and if you could provide a screenshot of your Timelapse settings (Settings > Webcam), that might also be interesting, maybe it's an odd configuration value that's at fault.

Also, which version of OctoPi are you running?

@Fires04

This comment has been minimized.

Copy link
Author

commented Apr 26, 2016

Hi,

  1. images are allways ok (sometimes blurry but it is just because hotend movement)
  2. screen of webcam setting LINK
  3. I try download tmp folder while I was printing all images are OK. LINK
  4. Any way to update ffmpeg ? I do not install or update ffmpeg after OctoPi intall.
  5. version : Version: 1.2.10 (master branch)
  6. it is bit rate ok ? I think I do not change this value
@foosel

This comment has been minimized.

Copy link
Owner

commented Apr 27, 2016

OctoPi version. 1.2.10 is an OctoPrint version.

If you didn't touch ffmpeg, it should be ok as it was shipped with OctoPi. Bitrate of 5000k should also work, you could try 10000k though. Also worth a try would be - temporarily - disabling the image rotation, see if that changes things. Since that rotation setting is applied by ffmeg during rendering the video, it might be worth a shot.

@Fires04

This comment has been minimized.

Copy link
Author

commented Apr 28, 2016

Hi, I try disable rotation and now it is all OK.

@foosel

This comment has been minimized.

Copy link
Owner

commented Apr 29, 2016

Sounds like a bug in ffmpeg then I fear, nothing I can do to fix this that I can think of right now. I've never seen this myself though when I tested timelapse creation with rotation enabled, so it's not a general issue with ffmpeg either (just did another test for good measure).

So, as a summary: probably caused by ffmpeg, maybe there are alternative parameters that could solve this, but without being able to reproduce I can't look into this. Leaving this open as "unreproduced" for now, maybe other people will chime in that are seeing the same issue and we can establish a pattern that might help to figure out exactly what's going on.

@Coolway99

This comment has been minimized.

Copy link

commented Jul 30, 2016

I can confirm this bug in Octoprint 1.2.14. My videos look the same as above. What's weird is that they used to render properly. My latest "correctly" rendered video was 2016-06-11 with the first incorrectly rendered one being on 2016-07-15. I am also using the rotation options, and the "/webcam/?action=snapshot" does not have any errors in it.

The differences between those dates in terms of webcam is that I turned on the "rotate by 90 degrees" option.

@VBen

This comment has been minimized.

Copy link

commented Jan 14, 2017

I can confirm this bug too. I occures only if rotation is applied
My current octoprint version is: 1.3.0 (master branch)

@foosel

This comment has been minimized.

Copy link
Owner

commented Jan 16, 2017

As mentioned above, the OctoPrint version is sadly pretty irrelevant here. If at all, this is an ffmpeg issue, which OctoPrint uses to stitch together the movie from the individual snapshots, and which also is the one responsible for rotating the images here. The only thing OctoPrint itself does with those images is capturing them, putting them in a folder and then calling ffmpeg (named avconv in Raspbian/OctoPi) to have it render the movie.

The OctoPi version and especially the ffmpeg version (avconv -version via SSH) might help.

Personally, I just tried it again with a current OctoPi image, a C270 webcam and the 90° rotation turned on and the video looks completely fine.

For reference:

pi@octopi:~ $ avconv -version
avconv version 11.6-6:11.6-1~deb8u1+rpi1, Copyright (c) 2000-2014 the Libav developers
  built on Mar 22 2016 15:53:22 with gcc 4.9.2 (Raspbian 4.9.2-10)
avconv 11.6-6:11.6-1~deb8u1+rpi1
libavutil     54.  3. 0 / 54.  3. 0
libavcodec    56.  1. 0 / 56.  1. 0
libavformat   56.  1. 0 / 56.  1. 0
libavdevice   55.  0. 0 / 55.  0. 0
libavfilter    5.  0. 0 /  5.  0. 0
libavresample  2.  1. 0 /  2.  1. 0
libswscale     3.  0. 0 /  3.  0. 0
@VBen

This comment has been minimized.

Copy link

commented Jan 16, 2017

I'm using a different version, i can't find the version you are using.
can you provide a deb package of the older version?

pi@octopi2:~ $ avconv -version
avconv version 11.8-6:11.8-1~deb8u1+rpi1, Copyright (c) 2000-2016 the Libav developers
built on Oct 8 2016 02:37:00 with gcc 4.9.2 (Raspbian 4.9.2-10)
avconv 11.8-6:11.8-1~deb8u1+rpi1
libavutil 54. 3. 0 / 54. 3. 0
libavcodec 56. 1. 0 / 56. 1. 0
libavformat 56. 1. 0 / 56. 1. 0
libavdevice 55. 0. 0 / 55. 0. 0
libavfilter 5. 0. 0 / 5. 0. 0
libavresample 2. 1. 0 / 2. 1. 0
libswscale 3. 0. 0 / 3. 0. 0

@foosel

This comment has been minimized.

Copy link
Owner

commented Jan 17, 2017

It's a stock Raspbian version, the one that came with OctoPi 0.13 actually. I just upgraded that install to your version though:

pi@octopi:~ $ avconv -version
avconv version 11.8-6:11.8-1~deb8u1+rpi1, Copyright (c) 2000-2016 the Libav developers
  built on Oct  8 2016 02:37:00 with gcc 4.9.2 (Raspbian 4.9.2-10)
avconv 11.8-6:11.8-1~deb8u1+rpi1
libavutil     54.  3. 0 / 54.  3. 0
libavcodec    56.  1. 0 / 56.  1. 0
libavformat   56.  1. 0 / 56.  1. 0
libavdevice   55.  0. 0 / 55.  0. 0
libavfilter    5.  0. 0 /  5.  0. 0
libavresample  2.  1. 0 /  2.  1. 0
libswscale     3.  0. 0 /  3.  0. 0

Re-ran the previous test, still couldn't reproduce the issue. Then I had an idea and upped the image resolution to 720p (it was still running at stock). And look at that, I got a reproduction!

image

So... the ffmpeg version itself seems to at least not matter with regards to 11.8-6 vs 11.6-6, but image resolution does.

Sadly, if it turns out that this is indeed a bug in ffmpeg that I cannot get around by some change in the calling parameters, there's nothing I can do about that, only the ffmpeg authors. Rotating the images from within OctoPrint to get around that would be too much overhead.

I'll have to experiment though if there maybe is some way to get around this issue yet.

@foosel

This comment has been minimized.

Copy link
Owner

commented Jan 17, 2017

Ok, I think I found the issue, or at least I was able now to produce a rotated video without the issue. Apparently ffmpeg ignores the pix_fmt parameter when a video filter is also provided via vf (which is done for the rotation). Adding the pixel format to the video filter makes stuff work. I have to admit I don't fully understand yet why this causes issues with higher resolutions but not with the lower ones, but my understanding of ffmpeg, mpeg and color spaces is way too limited to expect that I guess.

I'll be able to change that within OctoPrint. Will probably have to wait for 1.3.2 though, I already put out the release candidate for 1.3.1 which - unless there are blocking issues with it - will turn into 1.3.1 proper.

Would anyone of you affected by this be able to give e.g. the maintenance branch a test spin once I've fixed things there to verify that it indeed resolves the issue for you?

@foosel

This comment has been minimized.

Copy link
Owner

commented Jan 17, 2017

This is now fixed at least for me via the above commit on the maintenance branch. Please test.

@VBen

This comment has been minimized.

Copy link

commented Jan 17, 2017

@foosel I tested it, it works fine for me
Thank you

@VBen

This comment has been minimized.

Copy link

commented Jan 27, 2017

@Fires04 and @Coolway99 : Does the fix work for you?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.