Screen recording
Summary
As of October 2003, xvidcap lets you capture straight to an
mpeg4 file, using ffmpeg -- it works great! The files can be edited in avidemux. The problem is essentially
solved.
For fullscreen captures, test the x11grab that got added to ffmpeg in December 2006 (the first command suggestion is by the author):
ffmpeg -vcodec mpeg4 -qscale 2 -r 10 -vd x11:0+0,0 -s 1280x1024 out.avi
ffmpeg -f x11grab -s 1920x1200 -i :0.0 -r 8 -sameq -f audio_device -i /dev/dsp1 -acodec mp3 -ab 64K -ar 22050 -ac 2 -s 960x592
-vcodec mpeg4 out.avi
See more detailed instructions at How to record a
screencast -- note you need to play the video with -vo x11 for the recording to work!
For web pages, try http://www.tapefailure.com -- though this does not convert to an image format.
Cf. Linux screen capture technology (Aug 04)
Scan coverters
Software
- For games, check out the Machinima utilities!
For Windows, the standard application is Fraps.
- xvidcap (details below)
-
vncrec and vnc2swf (for use with VNC)
- ImageMagic (cf. Linux.com article)
- import window.png (click on the window to capture)
- import -window root cli-image-1.png (entire screen)
- mogrify -format jpeg *.tiff (convert to another format)
- mogrify -geometry 120x120 *.jpg (make thumbnails)
- nvtv -- GUI for TV out on nVidia cards (use it!)
- xtv -- monitor a remote desktop continuously or intermittently (try it!)
- scr2avi -- also records sound (corresponded with developer in late Oct 2003)
- gerd -- gtk+ event recorder (not active but otherwise promising)
- Gimp -- choose File -> Aquire -> Screenshot
- scrot -- command line screen capture utility (in Debian)
- KDE's KSnapShot (for single images)
- xautomation -- control x-windows from the command line
- x11rec (used successfully to create animated gifs) (deb available from http://www.stanchina.net/~flavio/debian/
- "You can use the utility 'import' from the command line. It's fast and flexible."
- xscript -- instructions (some details below)
- xgrab and xgrabsc (see man pages)
- xwd -- the basic screen capture engine used by most programs
- xwd -root > screen.xwd (to capture)
- xwd -root -out screen.xwd (same thing)
- xwud -in screen.xwd (to display images)
- convert screen.xwd screen.jpg
- convert screen.jpg -sample 500x400 screen_little.jpg
- sleep 5s ; xwd -root -out screen.xwd ; convert screen.xwd screen.jpg
- Remote and dual screens
- rfb -- VNC Server for X11 - exports current display!
- x2vnc -- A dual-screen hack - link a MS-Windows and X display
- x2x -- Link two X displays together, simulating a multiheaded display
- xtv -- View the screen of a remote X11 display
- xutils -- X Window System utility programs
- xv -- screenshots
- xvfb -- virtual framebuffer X server
- xview-clients -- XView client programs
- Animation (convert stills into movies)
- ganim8 (doesn't work -- wrong dependencies, no deb file)
- gifsicle (no recent deb in Debian, but see /vc/software/debs)
- convert *.png test.mpeg (from ImageMagick)
- im2avi (uses avifile and ImageMagick)
xvidcap
The program
to use for screen recording is xvidcap. The project was abandoned
between late 1999 and May 2003, and at that point was picked up by Karl H. Beckers. It
is now able to create mpeg4 files on the fly, using ffmpeg -- just as I
had myself imagined ought to be possible. The results are stunning --
the only limitation is the capture size; if you go much above 640x480,
you start getting 100% CPU utilization and dropped frames.
On 31 October 2004, I compiled xvidcap 1.1.3 for amd64 and
it runs great remotely -- you can use it to capture movies running
locally.
Instructions
- missing dependencies ucbmpeg ucbmpeg-play tk8.0 (?)
- to capture to mpeg4, set file type as mpeg and codec as mpeg4
- click on the "select" button and then a frame to select it
- creates stunning results -- indistinguishable from the real thing
- default capture window size: edit .Xdefaults as follows (see man page):
- xvidcap*capWidth:640
- xvidcap*capHeight:480
- avidemux will read these files!
- very large screen sizes won't play properly
- ./gvidcap -v --file /tmp/bla-%d.mpeg --continue
- gvidcap --cap_geometry 640x580+230+200
-
./gvidcap --file test-%04d.png --cap_geometry 200x144 --frames 40
-
ppm2mpeg "test-%04.png" 0 40 200 144 10 100
-
# xvidcap*mkVideoCommand: ppm2mpeg "%s" %d %d %d %d %f %d &
# %s: file name of the frames, e.g. 'cap-%04d.xwd'
# %d: number of the first saved frame
# %d: number of the last saved frame
# %d: width of the frame
# %d: height of the frame
# %f: frames per second
# %d: time per frame (ms, TPF = 1000 / FPS)
-
mplayer /tmp/output.avi
# Xvidcap
# Command-line mode:
gvidcap -v --fps 5 --time 20 --cap_geometry 640x580+230+200 --nogui
# Mixer settings:
#
# Use Aumix (kmix and alsamixergui don't always show the needed options)
# Set the recording function to "vol" if recording sound from program,
# or "mic" from microphone
# Make sure iGain (Capture) is only around 50% to avoid distortion
# Also keep PCM down a bit for the same reason -- around 70%
# Frame sizes
#
# You can edit xvidcap videos in avidemux. If the heigh and width are
# not multiples of 16, pressing play will show a distorted movie (but
# you can view frame by frame without distortion, and make cuts). For
# best results, use multiples of 16. For potatohead, this works well:
gvidcap --cap_geometry 528x400
# Mr Potatohead is gvidcap --cap_geometry 522x394
# America's Army is gvidcap --cap_geometry 803x601+2+24
# Divisible by 16 gvidcap --cap_geometry 800x608+3+22
Frame rates and CPU
xvidcap will silently drop frames if the CPU cannot keep up.
This seems to be largely a function of capture window size. Here are
some results for xdaliclock, an application that in itself consumes
virtually no CPU cycles, and mpeg4:
- capture size 778x456, frame rate 30, cpu utilization 80% -- no frames dropped
- capture size 816x520, frame rate 30, cpu utilization 90% -- no frames dropped
- capture size 824x546, frame rate 30, cpu utilization 99% -- no frames dropped
- capture size 854x562, frame rate 30, cpu utilization 100% -- a few frames dropped
- capture size 956x610, frame rate 30, cpu utilization 100% -- lots of frames dropped
So if the application itself doesn't need CPU power, the maximum
capture size is around 824x546.
The default capture window size is set in ~/.Xdefaults. Now,
standard NTSC is 640 x 480, so to leave some margin for the recorded
program using up processing power, set the default to a simple 640x480
-- that should reliably capture everything.
To sizes just above or anywhere below this value, just use the selection icon (crosshairs).
As you move towards 800x600, you'll get a few dropped frames; above it,
you'll get more. To be on the safe side, stick with 640x480.
Editing a file captured in xvidcap in avidemux
Now it turns out that avidemux also likes this size -- the file is read
without any problems, and even plays well. Moreover, you can change the
frame rate to the correct 29.97.
Avidemux will read most files below 800x600. Files much above that size tend to get stuck, though the developer may fix this.
Files with odd shapes but with modes frame sizes are read fine, and
display fine frame-by-frame. However, pressing play produces messy
colors and sometimes shapes.s
Files encoded at 640x480 and 30fps are read without difficulties and even play perfectly.
You could try Misc->rebuild I & B frame after loading
to attempt to fix play problems (recommended by the developer) -- I
found it to have no effect.
Codecs
xvidcap uses the ffmpeg codec, which has several components -- not sure what all of them are:
- mpeg4 works great and is the obvious choice.
- I tried using mpeg2 with xdaliclock and got largely junk.
- Plain mpeg may work too -- not tested.
Converting to dv
You can also convert the footage to dv format if you want, using this command:
ffmpeg2raw -n -a input > file.dv
If it fails try specifying the frame rate:
ffmpeg2raw -n -r 30 -a input > file.dv
I've tested this and it works -- you can then read the file into kino.
However, there's a significant quality loss. The view in xine and
avidemux is much better, so sticking with mpeg4 is the way to go.
Other screen capture programs
(irrelevant)
- Captura
- fbshot
- Gimp
- ImageMagick
- MagiCapture
- ScreenShooter -- in Gnome (like KDE's KSnapShot)
X11rec
x11rec -- captures events as animated gifs. Can't capture a pointer.
% x11rec foo.gif
** Select an X window with a mouse. **
id: 537803852
** Hit Ctrl+Z to finish the recording. **
frames: 24
time: 1 sec.
fps: 24.00
converting each xwd file into a gif file: 24/24
creating the resulting movie file...
removing temporary files...
size: 14461 bytes
done.
This works -- it uses xwd to capture a quick succession of screen images.
It's just a script, so you could customize it to your own needs -- currently
it makes gif images and mng images (??), but perhaps it could write another
format that kino could turn into a movie? Or the mjpegtools package?
Downloaded to sigillo://root/scripts/x11rec and compiled.
Currently it uses gifsicle to turn the images into a movie -- an animated
gif! Which could be handy, although for my purposes something playable
would be just as good and perhaps simpler.
Gifsicle -- creates animated gifs
http://www.lcdf.org/~eddietwo/gifsicle/
I got gifsicle from http://www.lcdf.org/~eddietwo/gifsicle/gifsicle-1.35.tar.gz
and compiled it on sigillo. The configuration went fine. To compile I
had to have xlibs-dev, so I did it on spello. After all that, I discovered
it's in debian! just install gifsicle.
It works! I got x11rec to work all the way -- it records beautifully
and converts the result to gifimages using gifsicle. The result plays
in konqueror, and likely any browser, so you can put these images on the
web. You could even use this for powerpoint presentations... Very cool
stuff! And problem solved for now in a very elegant way.
x11rec is apparently written in Ruby, "the interpreted scripting
language for quick and easy object-oriented programming. It has many features
to process text files and to do system management tasks (as in perl).
It is simple, straight-forward, and extensible."
It should be possible to modify x11 to suit your needs precisely, but
for the moment this is working great.
See also gifsicle for making animated gifs
http://www.lcdf.org/~eddietwo/gifsicle/
Web cam related
Package: hasciicam 0.9-2
ascii for the masses
Hasciicam makes it possible to have live ASCII video on the web. It captures
video from a tv card and renders it into ascii, formatting the output
into an html page with a refresh tag or in a live ASCII window or in a
simple text file as well, giving the possibility to anybody that has a
bttv card. a linux box and a cheap modem line to show a live ASCII video
feed that can be browsable without any need for plugin, java etc.
Package: webcam 3.82
capture and upload images
webcam captures images from a video4linux device like bttv, annotates
them and and uploads them to a webserver using ftp in a endless loop.
webcamd 0.7.6-3 (11.4k)
Capture images from video devices
Package: acme 2.0-1
Enables the "multimedia buttons" found on laptops
ACME provides support for the multimedia and other feature keys found
on laptops and many modern PC keyboards.
Package: streamer 3.82
capture tool (images / movies)
A tool to capture single/multiple images or record movies from a video4linux
device.
Dan Dennedy on screen recoding
"RE: Screen recording"
In response to message #0
I have been helping another person with this on the Kino IRC channel.
There are not many good solutions. One is Cinelerra, which if you can
get it to build works pretty good, but you are at the whim of the cpu
load and then you have to adjust the AVI framerate to approximate the
overall rate, which can fluctuate. Another solution is Charlie's
smilutils/xwd2raw utility. It will generate intermediate frames as fast
as possible because it was designed to be regulated by dv1394/video1394
output. No sound. No scaling. Cruddy DV encoding. My only suggestion
for a good quality is to use a VGA scan converter and capture the video
from it.
+-DRD-+
Kino Developer
The tool is included in 0.1.2 and is now renamed as xwd2raw, It has a
-s switch to allow you to interactively select the window and now outputs
a raw dv stream, rather than piping directly to dvconnect.
A simple test like:
xwd2raw -s > file.dv
(press return after a few seconds)
playdv file.dv
should work, but with the patches on playdv or dvconnect, the following
works:
xwd2raw -s | playdv --
or: xwd2raw -s | dvconnect -s --device=/dev/video1394 --
smilutils also provides a raw2webcam, so if you want to be really odd,
you could use xwd2raw to feed that one too ;-).
Source: http://www.geocrawler.com/archives/3/3147/2002/11/0/10132000/
See http://users.pandora.be/acp/kino/smilutils.html
xscript
This may be good:
xscript is a strict superset of xvidcap
http://youpou.lip6.fr/queinnec/VideoC/xscript.html
I got the rpm from http://youpou.lip6.fr/queinnec/Programs/xscript-latest.i686.rpm
and generated a deb with "just rpm2deb *.rpm" which worked fine
and subsequently installed.
root@spello:~# just list-files xscript
/.
/usr
/usr/X11R6
/usr/X11R6/lib
/usr/X11R6/lib/X11
/usr/X11R6/lib/X11/app-defaults
/usr/X11R6/lib/X11/app-defaults/XScript
/usr/local
/usr/local/bin
/usr/local/bin/xscript
/usr/share
/usr/share/doc
/usr/share/doc/xscript-2001jun14
/usr/share/doc/xscript-2001jun14/xscript.ps.gz
/usr/share/doc/xscript
/usr/share/doc/xscript/copyright
/usr/share/doc/xscript/changelog.Debian.gz
Detailed instructions at http://youpou.lip6.fr/queinnec/VideoC/xscript.html
I got segfaults all over the place -- probably not worth bothering with.
I uninstalled but kept the deb.
Recording with a camcorder
You can plug a camcorder into the s-video port of the
computer and record. In Linux, I used these values in the "Monitor"
section:
Option "TV" "yes"
Option "ConnectedMonitor" "TV"
Option "TVStandard" "NTSC-M"
Option "TVOutFormat" "SVIDEO"
Option "TVOverScan" "1.0"
HorizSync 30-60
VertRefresh 60
Removing all modelines, this gave me a resolution of 1024x768 on the
camcorder! Yet it was grainy and harder to read than a 800x600
resolution.
Afterwards I discovered there's a nvtv Debian package, a
Tool to control TV chips on NVidia cards under
Linux This is a program to control the TV encoder chips on NVidia
cards under Linux, in order to get tv-out with a wide range of resolutions and sizes, including "overscan" modes.
This has a frontend with loads of controls -- looks really useful! I wish I'd known about it.
Sharing STDIN/STDOUT on two terminals
Posted on: Oct 20, 2003 - 10:44 PM by mangeli
Ever wanted the standard input and standard output to be shared on two terminals?
Try the following short script,
------------------- CUT HERE -------------------------
[ $# -lt 2 ] && echo "Usage: $0 program ttytodupon" && exit 2
mytty=`tty`
prog=$1
othertty=$2
sh -c "$prog|tee -a $mytty" 1>$othertty 2>&1 0>$othertty
------------------- CUT HERE -------------------------
This could be useful for capturing: just pipe the output to another
terminal. But maybe this is just for the command line? It would be nice
to get some expert advice here.
moderately related
The UMVHP Event Recorder (U Mich Visible Human Project)
I contacted Carl Berger <cberger@umich.edu>
on 9 October 2003 to ask for a copy; if he doesn't reply try his
co-author Mike Bleed <mbleed@umich.edu>. This could be extremely
useful, as it keeps stats of what the user does -- would be great for
the monster project.
I've
now tried it -- they sent a copy -- and it doesn't do screen recordings
-- it's just for tracking events. It also doesn't work very well, so
forget it for now.
|