I'm using things like that:
avconv -f x11grab -s 1024x768 -r 24 -i 0:0 -deadline realtime -b 5000000 -minrate 200000 -maxrate 40000000 recording-filename-000.webm
Where:
-f x11grab - enforces screen capture "format" of input.
-s 1024x768 is the resolution of input file (aka capture area). For example equals to desktop resolution. If smaller than that, recording area would be at left and top. I used 1024x768 recording area in this example.
-r 24 - framerate. Basically, 23 to 30 FPS used by real movies to give a smooth recording picture. However for screencast it could be okay to reduce this to get better picture at lower bitrates. I used 24 to do game screen capture.
-i 0:0 is a hint to use display 0:0 as source (device is in xorg notation). If you have only 1 monitor and default Xorg setup, 0:0 will be ok most of times.
-deadline realtime - is a hint to libvpx. We want live capture. We want realtime performance. So libvpx will do it best to encode VP8 in REALTIME. To do so it somewhat trades quality for speed. At given bitrate quality will be a bit worse than it would be in non-realtime way. But encoding speed would skyrocket. So on my hardware it can crunch 1024x768@24FPS, intense scenes, without dropping any frames (powerful CPU recommended though). In this example I wanted a decent-quality live capture at good FPS and quite large capture area. So CPU usage by codec could be an issue. That's why this hint really needed for good results.
-b 5000000 - target bitrate in bits/second. I used 5Mbits to get more-or-less good picture of quite intense scenes. Codec will try to keep average bitrate speed of video close to this value. The lower this value, the worse the quality and smaller the file. You can experiment a bit to get idea what bitrate is good for particular uses. Video sharing services would downconvert video if you overshoot. If you about to use own server, it's up to you to take care of traffic. If you undershoot, picture quality will be bad. Feel free to change value to get idea what's best for you. 5Mbits were intended for more or less eye-pleasant live capture of intense scenes at games where you can't easily see that picture is overcompressed. For capturing still applications you will basically need far less than that.
-minrate 200000 - is a minimum allowed bitrate for codec. Depending on a nature of thing you want to capture, sometimes you may want to force minimum bitrate to keep a reasonably looking pictire at no matter what. Sometimes codec heuristic could reduce bitrate far below values you may want, giving bad picture at some scenes. This option allows to force codec to keep minimum bitrate even if codec thinks that scene is simple and bitrate could be dropped. High value of this parameter may increase file size by preventing codec from using lower bitrates.
-maxrate 40000000 - This value controls maximum burst bitrate at intense scenes. I used really high value to allow codec to go far higher than desired average if it considers higher speed is mandatory to keep decent quality at some scene. To get a good-looking picture in all conditions it's desirable to set this high enough (40Mbits is BlueRay-like speed and will do the trick). On other hand, if you're about to stream it using your own server, you have to reduce this value at cost of some picture quality at intense scenes. Else server could fail to cope with desired burst bitrate, being unable to deliver it in realtime way to users. Then player would face buffer underrun (which is annoying). Video-sharing services will take care on their own and usually downconvert video to lower parameters at the cost of picture quality.
recording-filename-000.webm - is a file name of output. If you use .webm extension, ffmpeg/avconv are smart enough to understand you want WEBM. It is THAT simple - avconv guesses desired format from filename. So .WEBM files are WEBM inside.
That is it - this command does direct screen recording to webm file. No extra conversions needed and libvpx is hinted to be as fast as it can. There is no sound since there is no specification for sound input. It may or may not be what you want. For sound, you have to specify input source for sound stream as well.
P.S. this may look a little overcomplicated but at the end of day you can figure out that one size can't fit all. So to get a good-looking picture in all situations you may really want to have some handles for codec used and want to adjust them. Ffmpeg gives you all the handles you may ever need and far more than that. It's a heavy weaponry of video conversion and encoding. So this example is a good point to start for those who want to do more or less advanced encodings and is ready to experiment a bit to get a really decent-looking results.
