Very choppy video compared to prior versions

[Matthias Niess]

kazam --version
kazam 0.12~ppa1
(from bigwhale ppa)

I'm not sure if it is kazams fault or a problem with Unity. On my machine the resulting video is very choppy compared to the results I got with prior versions of kazam in natty. Maybe webm is a bad choice of codecs? Can we go back to x264 and mkv somehow?

[David Klasinc (bigwhale)]

Can you give a little bit of info on your hardware and resolutio you were recording at?

The problem with x264 was that it didn't work out of the box on clean Ubuntu (or Mint) install and that current ffmpeg support wasn't really elegant. Executing ffmpeg binary in separate threads isn't the best way to do things.

VP8 encoding is still quite demanding on the resources. I never experienced problems on my computer but I'm testing on quad i5.

[Matthias Niess (mniess)]

It is pretty old hardware. I have an Athlon X2 5200 and record video-only at 1680x1050. With the old version of kazam I had no perceivable skipped frames (i.e. fluent mouse movement). With this version it looks rather like a VNC presentation, if you know what I mean. The guy who wrote the OMG! article seemed to have the same problem. What is the problem with x264?

[Alan Pope 🍺🐧🐱 🦄 (popey)]

I've noticed significantly lower framerate using the gstreamer backend.

I'm recording at 1920x1080 on a 2.66GHz Core2Duo with 8GB RAM and an SSD.

I have made some comparative videos so you can see the difference. Sample 1 and 2 were made by checking lp:kazam out and installing then running it. All recorded on the same hardware under the same workload.

http://popey.com/~alan/kazam/sample1.webm - kazam gstreamer backend
http://popey.com/~alan/kazam/sample2.webm - kazam ffmpeg backend
http://popey.com/~alan/kazam/sample3.mkv - ffscreencast.sh from http://launchpad.net/ffscreencast

Sample 1 shows the worst framerate.
Sample 2 shows a better framerate but the bitrate is way too low for 1920x1080 at more than 10fps
Sample 3 shows a decent framerate and bitrate.

I realise the bitrate for Sample 3 is very high, but I can dial that down and stil get a decent framerate and picture quality.

The command used in Sample 3 was:-

ffmpeg -f alsa -ac 2 -i pulse -f x11grab -r 30 -s 1920x1200 -i :0.0 -aq 100 -acodec libfaac -vcodec libx264 -vpre lossless_ultrafast -threads 0 -sameq sample3.mkv

[David Klasinc (bigwhale)]

Right now these are the parameters for that are used for vp8enc:

self.videnc.set_property("speed", 2)
self.videnc.set_property("quality", 10)
self.videnc.set_property("threads", cores)

(number of threads is always one less than number of actual cores, if there is more than one core. The framerate is hardcoded to 15 frames per second. I can increase this to 25, but I have no idea what will happen. :>

I like the approach that Gnome used. They made a gstreamer plugin that connects directly to clutter and grabs the picture there. Apparently this is the fastest way to do it. For ximagesrc I was already told that it doesn't perform as one would like.

I'll add H264 support in couple of hours and you can try with that. I am interested what your result will be.

[David Klasinc (bigwhale)]

I pushed new sources and made a new package. Support for H264 is back, altho I still have to fine tune encoder settings.

[Matthias Niess (mniess)]

Where can I get the new packages? The ones from the bigwhale ppa still show the old behavior.

[David Klasinc (bigwhale)]

Sorry for the delay, kinda missed this one.

You can get new packages from Kazam Team unstable PPA.

https://launchpad.net/~kazam-team/+archive/unstable-series

[Matthias Niess (mniess)]

I just tried the current build from that ppa and unfortunately it makes things even worse. Using H.264/MKV I get very choppy video and only the first few seconds of the video work. I don't think this is a Unity issue, as Kazam in natty worked perfectly for me. Just using ffmpeg straight still produces perfect results (i.e. with the command Alan Pope uses for his sample3).

So I guess the new gstreamer backend is the problem. Can I change back to ffmpeg somehow?

[David Klasinc (bigwhale)]

It might be the case that gstreamer is simply too slow for this. Are you recording with audio enabled? Try disabling it and let me know what are the results.

The problem with ffmpeg is that default installation on Ubuntu doesn't include x264 or vp8 support. If you want it, you have to build ffmpeg from source. If you do that, by following the guide on Ubuntu forums, you will get the nightly build of ffmpeg and x264 and they tend to differ from one build to another. For example, in current build ffmpeg comes with completely different presets for x264. Also libx264 changed few parameters.

I will add ffmpeg support back in the future (before the Precise release), but it will be 'use at your own risk' kind of a thing.

[Matthias Niess (mniess)]

But I don't get it. I have ffmpeg 0.7.2-1ubuntu1 from "main" and libx264-116 from "universe". Using

ffmpeg -f alsa -ac 2 -i pulse -f x11grab -r 30 -s 1680x1050 -i :0.0 -aq 100 -acodec libmp3lame -vcodec libx264 -vpre lossless_ultrafast -threads 0 -sameq output.mkv

I get a very good result with libx264 as the video codec. This is out-of-the-box without compiling ffmpeg myself.

Looking at comments to the recent omgubuntu articles about screencasting many people seem to have the same problem as I do. So is the ffmpeg backend still somehow selectible (like Alan Pope suggests above)?

[David Klasinc (bigwhale)]

Hm, ffmpeg works with x264 without compiling? I wasn't aware of that, I remember that I had to compile it all the time. I have ffmpeg and libx264-116 installed. How do I check if my libx264 is from the 'universe'?

Can you tell which ffmpeg version you have? Here's mine:

ffmpeg version 0.7.2-4:0.7.2-1ubuntu1, Copyright (c) 2000-2011 the Libav developers
  built on Oct 2 2011 15:13:26 with gcc 4.6.1
  configuration: --extra-version='4:0.7.2-1ubuntu1' --arch=amd64 --prefix=/usr --enable-vdpau --enable-bzlib --enable-libgsm --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvorbis --enable-pthreads --enable-zlib --enable-libvpx --enable-runtime-cpudetect --enable-vaapi --enable-gpl --enable-postproc --enable-swscale --enable-x11grab --enable-libdc1394 --enable-shared --disable-static

And it doesn't come with x264 enabled.

With ffmpeg there's also an issue with stopping and starting the video. Alan suggessted a solution but it is really a dirty workaround. And I am not sure about mixing two audio channels.

[Matthias Niess (mniess)]

Whoch Ubuntu version are you using? I'm using stock ffmpeg and get this output: ffmpeg version 0.7.3-4:0.7.3-0ubuntu0.11.10.1, Copyright (c) 2000-2011 the Libav developers
  built on Jan 4 2012 16:21:50 with gcc 4.6.1
  configuration: --extra-version='4:0.7.3-0ubuntu0.11.10.1' --arch=i386 --prefix=/usr --enable-vdpau --enable-bzlib --enable-libgsm --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvorbis --enable-pthreads --enable-zlib --enable-libvpx --enable-runtime-cpudetect --enable-vaapi --enable-gpl --enable-postproc --enable-swscale --enable-x11grab --enable-libdc1394 --enable-shared --disable-static

Alan Pope (with his comment above) seems to be able to do the same, as the ffscreencast.sh script is supposed to run on a regular Ubuntu box.

[Matthias Niess (mniess)]

Here are some more people having the same problem:
http://www.webupd8.org/2012/01/kazam-screencaster-10-released.html

[dinamic (dinamic6661)]

same problem here with kazan 1.0.4.1 on Ubuntu 12.04, the recording is very choppy 0.5 fps (i have no problem recording full screen with RecordMyDesktop at 30fps)

[David Klasinc (bigwhale)]

I managed to reproduce this bug on my notebook with Intel graphics and i5 CPU. I'll look into it.

[CheolHan Yoon (mait)]

I have similar problem.

With VP8/WebM - very choppy

With H264/MP4 - fine

1680x1050 fps 30

$ wajig version kazam fglrx-updates
kazam/precise uptodate 1.0.6-0ubuntu1
fglrx-updates/precise uptodate 2:8.960-0ubuntu1

(wajig is just another frontend for apt, dpkg)

How can I make info for this problem? I am not CLI noob. Just give me hint. If u want, I'll drop video file links too.

[David Klasinc (bigwhale)]

Try recording with lower framerate, 15fps. Then also try recording with ffmpeg. This could be VP8 specific or it could be specific to Gstreamer's implementation of VP8.

[David Klasinc (bigwhale)]

Can someone re-confirm this bug? Using Kazam 1.0.7 in Precise/Quantal or Kazam 1.3.2 from the unstable PPA in Quantal? Please try using VP8 and H264 codecs.

[David Klasinc (bigwhale)]

I tested this with VP8 and H264 and from 1.3.2 video should be ok.

[Matthias Niess (mniess)]

I tried this with Kazam 1.3.2 in quantal. Both codecs work well. I have a newer more powerful machine, though. So I can't say if it's still choppy on my old machine, sorry.

[Matthias Niess (mniess)]

To add to my prior comment. The machine is a Xeon quad-core @2.8Ghz with 8GB of RAM. Capturing with H264 worked perfectly. Capturing with VP8/WebM produced unusable results. The same "choppiness" I experienced with older builds and additionally ratio of the video was wrong when played with totem (didn't play at all in vlc).