TV Grabbing On A Pentium 3

Lately, I have been revising a script I use for video grabbing from a bt878-based TV tuner card. What such a task requires is real CPU horsepower, but my desktop PC can only offer an old Pentium III 700MHz running at 933MHz. I decided to squeeze all the performance out of this overclocked processor in order to get TV recordings of acceptable size and quality.

The Tools

I use mencoder (part of MPlayer) for most of my video works. MPEG4 is the format of choice to encode the video stream and MP3, through the LAME library, is the one for the audio stream. The best bet would be to use the XviD codec for the video, but all my previous failed tests do not leave much room for a choice. XviD is just perfect for video file transcoding, but, when it comes to real time encoding on a Pentium 3, I can only advise against its usage. All the advanced algorithms need to be turned off, so that the encoder catches up with the video stream:

:notrellis:nolumi_mask:vhq=0:bvhq=0:nochroma_me:nochroma_opt:nohq_ac:nogmc:noqpel

By the way, the above XviD settings also mean that you will never get videos of acceptable quality.

Another excellent MPEG4 encoder, built into ffmpeg, seems to be much more friendly for real-time video encoding. The fact that the core ffmpeg libraries (libavcodec, libavformat, libpostproc) are included into MPlayer makes this choice even better. One thing you should note though is that, usually, the MPlayer binaries, available from the various repositories, are compiled with the following option:

--enable-runtime-cpudetection

This means that mplayer or mencoder will try to detect the CPU and decide how to operate everytime the user runs them. The official MPlayer documentation does not recommend using the compilation-time option above, but its usage is natural when compiling binaries whose target audience is not people with a specific CPU. Generally, if you really care about performance, do not use it.

The Script

Here is the script I use for TV grabbing:

#! /bin/bash
 
# License: GPL
 
# Shut down tvtime
tvtime-command QUIT
 
# File to write
OUTPUT=~/multimedia/videos/tv-$(date +%Y%m%d)_$(date +%H%M%S).avi
 
# Set up the mixer manually, just to avoid surpises...
amixer -c 0 set Capture cap
amixer -c 0 set Capture 80%
amixer -c 0 set Capture unmute
amixer -c 0 set Line cap
amixer -c 0 set Line 87%
amixer -c 0 set Line unmute
 
 
################ VIDEO CODECS #####################
# MPEG4
VCODEC7="lavc -lavcopts vcodec=mpeg4:vbitrate=687:mbd=0:vme=4:vqmin=2:vqmax=31:nr=300:aspect=4/3"
 
################ AUDIO CODECS #####################
ACODEC1="mp3lame -lameopts cbr:br=64:mode=0"
 
################ DEVICES ##########################
#:outfmt= i420 OR yv12
#:width=512:height=384
#:width=640:height=480
VIDEO1="device=/dev/video0:input=0:norm=pal:fps=25:width=640:height=480:outfmt=i420"
AUDIO1="alsa:adevice=hw.0,0:forceaudio"
AUDIO2="noaudio"
 
################ VIDEO FILTERS ####################
VFILTER1="pp=lb/ha/va/dr/al"
VFILTER2="pp=lb/al"
 
################ ACTION ###########################
xterm -e \
mencoder tv:// \
-tv driver=v4l2:$VIDEO1:$AUDIO1:buffersize=64 \
-vf $VFILTER1 \
-of avi \
-endpos $1 \
-ofps 25 \
-aspect 4:3 \
-oac $ACODEC1 \
-ovc $VCODEC7 \
-o $OUTPUT
 
exit 0

This script can take one argument, actually a number, which represents the duration of the recording. If no argument is passed, then it will record forever or until it is interrupted by Ctrl-C. I’m not going to explain the options that have been used, the mencoder documentation goes into much detail about them, but I will refer to some things that worth mentioning.

In the first section of the script, the filename of the output video file is set, the TV-viewing application (TVtime) is shut-down –it would be impossible to record otherwise– and the capture settings of the mixer are also set. Some viewers tend to mute Line-In when they are closed, so this generally ensures that the output video will have sound.

Next, the video codec settings are set (VCODEC7). These could certainly be further adjusted, but these offer a good balance between quality and file size. Audio (ACODEC1) is encoded at 64kbps, which is generally enough. In the Devices section, apart from the actual device settings, the TV standard (PAL), the framerate (25fps), and the resolution (640×480) of the video stream, which mencoder will try to retrieve from the TV card, are set.

Real-time encoding at the resolution of 640×480 pixels will be the CPU’s toughest job.

An important thing, before putting all these options together, is to define some post processing filters that will be used by default when the final video is reproduced by a video player. These filters (VFILTER1) include deinterlacing, horizontal and vertical deblocking, deringing and automatic level adjusting. At least, the first three should always exist, otherwise the final video quality will totally suck.

The Result

Well, I must admit it. This was the first time that I managed to capture real-time video using the MPEG4/MP3 format combination at the 640×480 resolution. Actually, it seems that the above settings bring mencoder right at the edge before it starts dropping frames. The real-time monitor, during the capture, shows that the rate, at which frames get encoded, starts at about ~10fps and reaches 24.60-24.90fps after some seconds.

The most important option, which actually gives mencoder the ability to catch up during those first seconds without dropping any frames, is the buffer:

buffersize=64

A buffer size of 64MB is enough in order to support mencoder.

The final video is not perfect. There is a noticeable amount of blurring in the image and some blocks every now and then. But, generally, it’s acceptable. The bigger amount of camera movement and scene changes the encoded material contains, the more difficult is the CPU’s job. The quality of the signal is also a determinant factor. So far, I did not have any real problems whether I recorded a talk show or a football match.

Final Words

I guess this is the limit of what a Pentium III at 933MHz can do. Real-time video encoding is not anything new to me. I’ve been experimenting with it a lot on both a Windows and a Linux system. Whatever windows driver I had tried, it would not let me go over the 384×288 resolution. Contrariwise, video4linux makes it possible to use the full potential of the capture card and go as far as the CPU can handle.

I already know that I need a complete system upgrade, but then I would have missed all the fun…

The Tools

The Script

The Result

Final Words

Related Articles