Arduino RFID Door Lock
XBee network controller
LS30 Burglar Alarm
TRS-80 software I wrote
My PGP Key
Library of C
CMD File Utils
Hats I wear
Ethical Internet Advertising
Age of plenty
Your donation gives me time
to develop more cool free stuff
Stop the Australian (Anti)Vaccination Network
I do a lot of video work online. Here are some notes about it:
PVR means Personal Video Recorder (or was that Programmed Video Recorder?).
Anyway, I record my favourite TV shows in real time so that I can watch
them later (since I don't have time to watch them in real time!). Here's what
- MPlayer (it includes an encoding
program called mencoder)
I use a script like this to capture a TV program on demand:
# Use NFS filesystem for recording
# Create directory, just in case
mkdir -p $(dirname $OUTFILE)
echo Start `date '+%Y-%m-%d %H:%M:%S'` CHANNEL=$CHANNEL DURATION=$DURATION OUTFILE=$OUTFILE >> ~/tmp/capture-tv.log
aumix -v 0 -w 0 -m 0 -i 90 -c 0 2>/dev/null
mencoder -tv on:driver=v4l:width=320:height=240:channel=$CHANNEL:chanlist=australia -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=550 -oac mp3lame -endpos $DURATION -o $OUTFILE >/dev/null
if [ $s = 0 ] ; then
aumix -v 50 -w 80 -m 0 -i 90 -c 0 2>/dev/null
echo End `date '+%Y-%m-%d %H:%M:%S'` CHANNEL=$CHANNEL DURATION=$DURATION OUTFILE=$OUTFILE RC=$s >> ~/tmp/capture-tv.log
The interesting things to note about that script are:
- It writes the encoded output to an NFS-mounted directory. NFS isn't necessary, but plenty
of disk space is. A 30-minute show is about 300-400 megs at this bitrate, so make sure you
can either watch your shows regularly or have enough disk space to skip a few days and then
watch a few at one sitting.
- The TV audio-in is fed from the TV capture card using a short loopback cable to the
sound card. Turn off the speaker and microphone before capturing (and turn them on
again afterward, to my preferred settings).
- mencoder has been told to use the Australian channel frequencies.
The quality of recording using this system is not that great, but it is watchable, and it
is far, far more convenient than messing with VHS videotapes.
A project to write a video device frame capture program capable of saving
image frames to disk at full speed (i.e. 25 frames/second of PAL).
Copyright (C) 2001, Nick Andrew <email@example.com>
Distributed under the terms of the GNU Public Licence
The video-capture program started life as `vidcat.c', written by
rasca _at_ gmx.de and part of rasca's `w3cam' project. See http://www.rasca.de/
It was useful for once-off capturing of a frame from a video capture
device, but I wanted to do multiple-frame captures which would be
suitable to feed into mpeg2encode. I also wanted a program which could
capture all 25 frames per second (PAL). `vidcat.c' could not do that.
Although other programs exist which can capture video and audio
simultaneously I needed only a lightweight video-only capture program.
While modifying this program I wrote video_device.h and video_device.c
which provide an abstraction layer to controlling the video capture
device. The abstraction is incomplete, but I learnt a lot about
the Video4Linux API and it made video-capture.c easier to write and
understand. The major advantage of using the abstraction is that it
uses the double-buffering provided by all (?) video device drivers,
such that the device driver is capturing the next frame while the user
code is processing the previous frame.
WHAT THE PROGRAM CAN DO:
- capture single frame as ppm or jpeg
- loop, capturing as quickly as it can, and writing to separate output files
(frame%d.ppm or frame%d.jpg ?)
- capture in various sizes, from certain device channels, in certain
formats (i.e. PAL or NTSC)
- writing to separate output files is _very slow_ and unsuitable for 25fps
capture (at least on my machine). To do 25fps continuously, the program
must write to a single file. There's a modification of mpeg2encode
out there to read all frames from a single file, and a corresponding
modification of a capture program to write that format. I have to go
look for it again and do the same thing.
- Full rate capture may also require multi-threading or a dual-process
design (e.g. one process to capture and buffer the frames, another
to write them to a file).
The names of the video input channels (the signal sources from which the
card will capture) are hardcoded (a relic from vidcat.c) and apply to
the bttv driver, but not necessarily any others.
For example, the bttv driver and my card report the following channel
names to me:
- Channel 0: name Television, tuners 1, flags tuner audio, type tv, norm 0
- Channel 1: name Composite1, tuners 0, flags audio, type camera, norm 0
- Channel 2: name S-Video, tuners 0, flags audio, type camera, norm 0
whereas these are hardcoded in video-capture.c as "tv", "comp1", "comp2",
However my USB video camera which uses the ov511.o device driver defines
a single input channel which is called "Camera", numbered 0.
So to capture from the camera at this time, video-capture must be
called with the "-i tv" option.
To fix this, the program should query the device to obtain all channel
names and compare them against the argument to "-i".
- Setting the picture (brightness, colour etc) and tuning (TV channels)
is not supported. Use xawtv to set all these parameters before running
Just type "make", get in, sit down, shut up, hold on!
Only read permission on the video device (/dev/video0 etc...)
Nick Andrew <firstname.lastname@example.org>