High RAM and Disk I/O while convert is running

[ArsenArsen]

While convert is running, It will use 4GB+ of RAM and the Disk I/O is pretty high.

Repro steps:

• Use it for over 15 seconds.

I know about #25, also I ran it with TMPDIR=$HOME/tmp peek.

Thanks for this, again.

System:
Arch Linux 64 bit

$ uname-a
Linux arsen-pc 4.9.8-1-ARCH #1 SMP PREEMPT Mon Feb 6 12:59:40 CET 2017 x86_64 GNU/Linux

Intel Core i3-4170
NVidia GTX 650

[phw]

Just to get some perspective: How large is the area you are recording and what frame rate have you set?

Also I assume $HOME/tmp does exist and is not itself on a RAM disk. Some people also suggest to set MAGICK_TMPDIR in addition to TMPDIR, even though the last should also be picked up by Imagemagick, but you might want to try it ( see also http://www.imagemagick.org/discourse-server/viewtopic.php?t=7664)

[ArsenArsen]

Also I assume $HOME/tmp does exist and is not itself on a RAM disk.

Correct.

How large is the area you are recording and what frame rate have you set?

Quarter, approx, of a 1920*1080 monitor. In fact, the white lines on my screenshot are Peek window corners. Default framerate.

Some people also suggest to set MAGICK_TMPDIR in addition to TMPDIR

Will try now
EDIT: Same results.

[ArsenArsen]

Actually, the area is 1221*860 pixels, re measured it.

[phw]

Ok, yes. Can easily reproduce with such a large screen area, my RAM usage of the convert process even got as high as 9 GB (recorded for a bit more than 15 seconds with 15fps). The end result is also 18MB in size.

In the end GIF is not very well suited for large recordings, so reducing the framerate and having a smaller recording area is probably advisable, as a 18MB GIF is not really useful in many cases. So my suggestion for this kind of recording is to use the new option to use WebM instead of GIF (which will directly record to WebM, without any conversion process afterwards).

Having said this, there are maybe some things that could be done resource usage wise. The way it currently works is that a video is recorded which then gets converted to an optimized GIF with convert.

One thing I will need anyway for some use cases is instead of storing a video file store individual screenshots for each frame. Maybe this performs better with convert. It will probably use more space during recording again, but convert has to do that frame extraction anyway. Also this would allow to use gifsicle instead of convert, which allows the same kind of optimizations but is a specialized tool for the job. I don't know whether this will improve resource usage, but it is worth a try.

[ArsenArsen]

Hmm, could there be a record as webm too? Which would modify my output flag suggestion to have %f replaced with the format. Also, to add to that one too, and I'm getting a bit sidetracked here, excuse me, a - could be a good idea to have the file get sent to stdout with all other logging removed. Again, excuse me for going off topic of this issue.

[ArsenArsen]

Oh sorry about that, I miss read the comment. Will try webm today when I'm home.

[phw]

Just to get some perspective at what disk usage we can end up with lossless single image frames saved as PNGs during recording:

A PNG file with roughly the area of your recording 1221*860 ends up with slightly over 1 MB for me. Recording for 15 seconds with 15 fps will take 225 MB temp file space. On the other hand ImageMagick also generates a temporary file when decoding the video, and for me this quickly is several hundred megabyte large with such a large recording area.

[phw]

Looks like convert does adjust its resource usage based on the system. So me getting a 9 GB temporary file (I have 16 GB total memory) on the conversion while you get something above 4 GB for the same recording size and length might be caused by this, and I don't have to worry about that users actually need to have 9 GB of RAM available as a strict requirement.

One can limit the resource usage of convert with the -limit parameter, see http://stackoverflow.com/questions/15384879/imagemagick-using-more-than-2gb-of-memory-to-convert-pdf-files . Of course setting the limit to strict can result in conversion errors, also it is always a trade of and limiting one area (e.g. RAM) might increase usage in another (e.g. processing time).

[ArsenArsen]

Yeah, pretty apparent that convert limits itself just enough to not trigger OOM. For me, it's an 8GB RAM system and between things running I had chromium, KDE, Konsole, OpenSSH session, and an IDE open, which would consume about slightly less than 4GB of RAM, which adds up to the OOM statement. I'd personally sacrifice processing time for resources, but as you said, it might affect other things. Maybe webp or gifv targets for converting could solve this problem?

[phw]

GIFV is more or less just a fancy marketing term for using MP4 in place of animated GIFs :)

The current git master already had WebM support, I added additional MP4 support in 1bf5309 today.

I would recommend either using WebM or MP4 for your use case, the recording area is a bit too large for getting good results with GIF. Depending on the use case you could also try to reduce the framerate.

I keep this issue open for optimizing the resource usage of the GIF recording. I would like to try out the various ideas I have for this, but not before the 1.0 release.

[ArsenArsen]

GIFV is more or less just a fancy marketing term for using MP4 in place of animated GIFs :)

I assumed so when I couldnt find the format specs

But what about WebP? How do you think it'd bare?

[phw]

But what about WebP? How do you think it'd bare?

No idea really. WebP is very similar to WebM regarding its underlying technology. I know there is some kind of animation support for WebP also, but not sure how this compares to GIF or a real video format like WebM. Browser support seems to be not very good: http://caniuse.com/#search=webp

[ArsenArsen]

I see. Is there a AUR for peek dev or should I compile myself to test with webm?

[phw]

There is not yet a terminix-git package in the AUR. I thought about uploading one, but was too lazy to maintain it, even if it is small work. You can use this PKGBUILD I was just using myself to test installation:

pkgname=peek-git
pkgver=1.0.0b1
pkgrel=1
pkgdesc="Simple animated GIF screen recorder with an easy to use interface"
arch=('i686' 'x86_64')
url="https://github.com/phw/peek"
license=('GPL3')
provides=('peek=${pkgver}')
conflicts=('peek')
depends=(gtk3 libkeybinder3 ffmpeg imagemagick)
makedepends=(cmake vala gettext)
source=(git+https://github.com/phw/peek.git)
sha1sums=('SKIP')

build() {
        cd "${srcdir}/peek"
        cmake -DCMAKE_INSTALL_PREFIX=/usr \
                -DBUILD_TESTS=ON \
                -DGSETTINGS_COMPILE=OFF .
        make
}

check() {
        cd "${srcdir}/peek"
        make test
}

package() {
        cd "${srcdir}/peek"
        make DESTDIR=${pkgdir} install
}

[phw]

At http://littlesvr.ca/apng/gif_apng_webp1.html there is a comparisson between GIF, APNG and WebP (lossy and lossless). Interestingly GIF does very well, WebP is nearly always significantly larger. APNG also does quite well and is smaller then GIF, but again browser support is lacking (http://caniuse.com/#search=apng).

No real alternatives IMHO. I would still recommend using GIF in cases where it fits your needs and otherwise use WebM.

[ArsenArsen]

Alright, thanks. I guess that answers and closes this issue in that case?

[phw]

I have finally added that peek-git package to the AUR :) https://aur.archlinux.org/packages/peek-git/

Alright, thanks. I guess that answers and closes this issue in that case?

Yes, I will close this issue. I have also committed some changes that will help with regards to resource usage. For one, ffmpeg already encodes the recording in the format ImageMagick expects, so there is not re-encoding necessary (which costs time and a bit extra disk space). Also the intermediary files are all placed in the user's home directory now (in XDG_CACHE_DIR, which defaults to $HOME/.cache). This helps with high RAM usage due to /tmp being mounted as a RAM disk in many cases. I think /tmp is just a bad default for large temporary files.

For the future I want to analyse this in a bit more detail and see whether I can improve this even more, but let's first see how the changes are helping.

[phw]

Recorded with ImageMagick backend:

Recorded with Ffmpeg backend:

APNG version (this also uses the Ffmpeg backend, see #108):