• Blender Sequencer – Getting Started
• Learning the Sequence Editor and also the old tutorial
• Another tutorial based upon the above guides

Related Articles

• Creating Screencasts under Linux
• How to annotate PDF files in Linux using Xournal
• How to author DVD with menus under Linux
• Security Guides for Operating Systems by the NSA
• Awesome tutorials

Someone could argue that the clip is quite editable to a certain degree using scripts (found via these screencasting instructions) like the following:

#!/bin/bash
# 2008-06-20
# fedora-av-splice.sh
# Simple shellscript to mix theora video+audio using gstreamer pipeline
# Takes 3 arguments wavfile theoravideo output-theora-video
 
if [ $# -lt 3 ] ; then
  echo "Usage: $0 wavfile theora-video output-video"
  echo "Ex: $0 english-audio.wav desktop-recording.ogg english-desktop-video.ogg"
else
   gst-launch-0.10 \
     filesrc location=$2 \! decodebin name="video" \
     filesrc location=$1 \! decodebin name="audio" \
     audio. \! queue \! audioconvert \! vorbisenc \! queue \! mux. \
     video. \! queue \! ffmpegcolorspace \! theoraenc quality=32 \! oggmux name=mux \! filesink location="$3"
 
fi

Then again this is not the kind of “editability” I was referring to.

Anyway, if you have to use one of these tools, but need to make a few adjustments to the final clip, here is how to re-encode the ogv file to xvid or mpeg4 formats using mencoder. Note that in order to preserve as much quality as possible I use two-pass encoding.

Using mencoder’s xvid codec:

mencoder out.ogv -ovc xvid -xvidencopts bitrate=1000:pass=1 -o xvid.avi
mencoder out.ogv -ovc xvid -xvidencopts bitrate=1000:pass=2 -o xvid.avi

Using mencoder’s mpeg4 codec:

mencoder out.ogv -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=1000:turbo:vpass=1 -o mpeg4.avi
mencoder out.ogv -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=1000:vpass=2 -o mpeg4.avi

Choose whichever you think that better preserves quality.

Regarding bitrate, I’ve used 1000kbps as I think it creates good results while not exceeding the filesize of the original video.

In order to get some information about the ogv file, you can use ogginfo:

[gnot@galeon bin]$ ogginfo out.ogv
Processing file "out.ogv"...
New logical stream (#1, serial: 1bd82e14): type unknown
New logical stream (#2, serial: 16113fc8): type theora
Theora headers parsed for stream 2, information follows...
Version: 3.2.0
Vendor: Xiph.Org libTheora I 20060526 3 2 0
Width: 592
Height: 368
Total image: 592 by 368, crop offset (0, 0)
Framerate 1000/100 (10.00 fps)
Pixel aspect ratio 1:1 (1:1.000000)
Frame aspect 4:3
Colourspace unspecified
Pixel format 4:2:0
Target bitrate: 45 kbps
Nominal quality setting (0-63): 63
User comments section follows...
        recordMyDesktop=0.3.8.1
Logical stream 1 ended
Theora stream 2:
        Total data length: 7012059 bytes
        Playback length: 4m:27.799s
        Average bitrate: 209.471516 kb/s
Logical stream 2 ended

Your comments are welcome.

Related Articles

• TV Grabbing On A Pentium 3
• Using Blender for Basic Video Editing in Linux
• How to author DVD with menus under Linux
• Install OpenSolaris in VirtualBox – Screencast
• Kernel 2.6.17 and lirc_gpio driver

Good ASCII art can take time and talent to look just right, but you can skip through that effort with AAlib, a library devoted to converting any image into an ASCII art equivalent. Since a movie is basically a system of moving images, MPlayer has added support for AAlib as a video output option. This means that each frame in the movie is converted to an ASCII equivalent and displayed on the screen.

Software that is used to accomplish the task includes MPlayer multimedia player built with support for the ASCII art library (aalib) and the color ASCII art library (libcaca).

Read the full article here

Related Articles

• Training Videos
• Creative Commons v3.0 Licenses Launched
• 50-Monitor Display
• TV Grabbing On A Pentium 3
• Screenshot of a menu under GNOME: ROUND 2

Related Articles

• Fedora sound recording problems… solved
• Software that detects violations of open source licenses
• Microsoft’s Open Source Software Lab
• RHEL kernel source released with patches already applied
• Epiphany Python Console – Open New Tab

Related Articles

• Watch Videos in ASCII Art
• How to author DVD with menus under Linux
• How to recover lost files
• Creative Commons v3.0 Licenses Launched
• The hole trick

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…

Related Articles

• Creating Screencasts under Linux
• Watch Videos in ASCII Art
• Fedora sound recording problems… solved
• Kernel 2.6.17 and lirc_gpio driver
• A powerful command, SED

Some General Info

The traditional way of sharing a collection of audio files across a local home network is by sharing the directory that contains them, so that everybody can access these files. This works well, but I guess it’s time to move on to the next level of music sharing through the Digital Audio Access Protocol (DAAP).

A very interesting article, published on Linux.com, was the motive in order to start reading about DAAP. In brief, this protocol was originally developed by Apple and is implemented in the company’s popular audio player, iTunes. What makes DAAP so important is the fact that it uses ZeroConf, also developed by Apple and originally called Rendezvous, to announce and discover the music shares across the LAN. All this is done automatically, usually requiring zero configuration by the user.

Τhe requirements for using DAAP in order to share your music are:

1. an implementation of the protocol itself, either in the form of a daemon or have it built-in within a music management application.
2. an implementation of ZeroConf.

Hopefully, as you might have already read in the linked pages above, there is just enough native linux software that satisfies both of the above requirements. This small article will deal with the Avahi daemon, a promising implementation of ZeroConf, and Rhythmbox, built with DAAP support. These are available OOTB in FC5 and will most probably be included in the upcoming releases of the major Linux distributions, if not already included (this is beyond my knowledge).

How To Share Across The LAN

Rhythmbox, if built with DAAP support, includes a new tab in the preferences panel, called “Sharing“. This is where the user can enable music collection sharing, set a name for the share and even set a password in order to control access.

Having enabled this, when Rhythmbox is started, it uses D-Bus to send a message to the Avahi daemon informing it that the player implements a service based on the DAAP protocol, which gives access to the user’s music collection and can also recognize other users’ music shares. Avahi, after collecting all the needed information about that service, it publishes it as a mDNS/DNS-SD service and makes it available in the local subnet, so that all other workstations are notified about the new available service. All this is accomplished without any user intervention, which makes it very convenient even for unexperienced users.

Even if Rhythmbox does not share its music collection, it, if built with DAAP support, still informs Avahi through D-Bus, that it can recognize other users’ music shares and, eventually, all these available shares are displayed in Rhythmbox’ music sources list. Each of these shares includes the whole music database, which by the way can be searched as if it was the local music collection, plus any playlists. The outcome of all these operations is that all the available music on the local network is viewable and searchable from within Rhythmbox’ user interface!

More Than A Mouse Click

Although enabling the sharing of the music collection in Rhythmbox should be enough, it requires one more step so that other workstations on the LAN can actually read the published music. Actually, this is only required in the case that the workstation which shares the music is protected by a firewall. The fact that this aspect is not even mentioned in the Rhythmbox documentation is, at least, surprising.

So, which port should be open? Hopefully, Rhythmbox’ DAAP service uses the DAAP protocol’s default port:

3689 TCP

Opening this port on the workstation that shares the music is mandatory. A workstation, which is supposed to only read music shares, is not required to have port 3689 open.

But, what about if the service did not use the standard port? How to find information about the available services on the local machine or accross the local network? Read on…

Avahi

As it was previously mentioned, Avahi’s responsibilities, by default, are to publish and announce any local services to the whole subnet (Multicast Server) and also to collect information about other services that are available on the subnet and make it available to the workstation it runs on (Service Discovery). Furthermore, Avahi can publish services that run on workstations on which Avahi is not installed.

The Avahi distribution, among others, includes some utilities in order to assist users in finding information about the available ZeroConf services on the network. A command-line tool (avahi-browse) and a graphical one (avahi-discover) are provided.

You can use avahi-browse like in the example below:

# avahi-browse -a -r -t

Some info about the parameters:
-a : Show all services, regardless of the type.
-r : Resolve the services and provide detailed information about their parameters.
-t : Terminate when an apparently complete list has been printed to stdout.

The information, that the above command provides, includes the port number on which a service is run.

If you like it graphically, you can use the avahi-discover-standalone utility. Run it from a terminal:

# avahi-discover-standalone

Select any of the services that are shown and the service’s information will be displayed.

Final Words

The implementation of the DAAP protocol that is built in Rhythmbox makes it possible to share music with Apple’s music management application, iTunes, which cannot run natively in Linux. Apart from that, a UNIX server implementation of the DAAP protocol, mt-daapd, can be used to share your audio files from a central location. The importance of DAAP is that it makes the synchronization of music across a local network extremely easy.

This small article is also a small introduction to Avahi and to what a user can achieve with it. It seems that I just discovered multicast DNS and automatic service discovery. Well, this is not absolutely true. I just discovered some useful things a user can do with it, so I intend to spend some more time with Avahi and hopefully post some more info about its usage in future articles.

Related Articles

• My Music
• Set up an anonymous FTP server with vsftpd in less than a minute
• Auto-closing SSH tunnels
• Set up the VNC Server in Fedora
• SSH Tunnels Headaches

Shiznix writes in his article:

This howto is written in the attempt to help those reading to:

1. Accomplish transferring a video media file (.avi, .mpg, .wmv, .mov, etc.) to DVD media in a format that will allow it to be played on a standalone DVD player.
2. Create professional style menus with audio to allow selection of Titles, Chapters & other menus.

Read the full article here…

Also, do not miss this post, if you need animated menus.

Excellent work!

Related Articles

• Issue addressed: Author feeds deliver full content
• Awesome AWK Tutorial
• Training Videos
• Error when using old run/bin installers under Linux
• The hole trick

Prerequisites

In order to use LIRC you will need the necessary hardware components, a remote control and an infrared receiver. LIRC supports a lengthy list of such devices. You can check if your equipment is supported at this page.

Next thing is to download the latest stable LIRC package from the project page and configure it properly for your equipment. For this article I’ll use the traditional way of compiling and installing software, so some such experience is required from your part. Of course, if you are into package building, you can build your own RPM or DEB package.

Configure, Compile, Install

Extract the LIRC package in a temporary directory (~/tmp/):

# tar -xzvf lirc-X.X.X.tar.gz -C ~/tmp/

The most important part of the LIRC pre-compilation configuration is the choice of the appropriate driver for your hardware. For more info check the LIRC Documentation. Normally, if you know your hardware, change to the directory where you have extracted the LIRC package and issue the following command in order to check which driver name you should use:

# ./configure --help

Next, configure the package for your system. Because some kernel modules are built together with LIRC, you will need to have the kernel development package (eg kernel-devel) for your running kernel installed. To configure LIRC issue the command:

# ./configure \
--prefix=/usr \
--with-x \
--with-transmitter \
--enable-sandboxed \
--with-moduledir=/lib/modules/$(uname -r)/extra/lirc \
--with-kerneldir=/path/to/kernel/headers \
--with-driver=DRIVER

Substitute DRIVER with the appropriate driver name and edit the path to your kernel headers/sources in the --with-kerneldir option. Note that the --with-kerneldir option can be safely omitted.
We use the --enable-sandboxed option, so that the installation script does not try to create any device nodes for LIRC. An UDEV rule, that we will create later on, will take care of this.

If the configuration script fails due to missing dependencies, make sure you have all the necessary development tools, libraries and kernel headers installed in your system. Just read carefully the on-screen error messages to see what is missing.

After this configuration is finished, you will see a message in your terminal about which LIRC module will be used. Take a note of the module name, as you will need it later on.

NOTE: On Fedora, I was not able to build the required lirc_gpio module. My IR receiver is attached on my KWorld TV tuner card, so this module was absolutely needed. In such a case you will probably want to read my post about the The Complete Fedora Kernel Headers.

Next, proceed to the LIRC compilation:

# make

and installation. This step is needed to be done as root:

# make install

If for any reason you want to uninstall all LIRC files, from within our current directory, issue the command:

# make uninstall

Special Note: Before you update your system kernel at some later time, you will need to uninstall LIRC. After the kernel upgrade, you will have to repeat the previous configuration, compilation and installation steps, so that the LIRC module is built for your new kernel.

The final step is to create an UDEV rule, so that the LIRC devices are created properly and with appropriate permissions.

Create a text file, named 10-lirc.rules, in the /etc/udev/rules.d/ directory and add the following to it:

KERNEL=="lirc[0-9]*", NAME=="lirc%n", GROUP=="disk", MODE=="0660"
KERNEL=="lirc0", SYMLINK=="lirc"

Finally, make sure you add the users you want to have access to the LIRC server to the group disk. Alternatively, if you want all the users to be able to access LIRC, then modify the MODE in the UDEV rule above from MODE=="0660" to MODE=="0666".

That’s it.

The LIRC Server Configuration

It seems that the LIRC daemon (lircd) does not load the default module (driver) automatically when it starts, so this module should be loaded manually.

To load the appropriate module and the LIRC server at boot time, all you have to do is to add the following lines to the /etc/rc.d/rc.local file. As root:

modprobe MODULE_NAME
lircd

Substitute MODULE_NAME with the module name you had taken a note of when configuring LIRC. For me, it would be lirc_gpio. The LIRC daemon, by default, uses the driver that was defined during the LIRC pre-compilation configuration.

The LIRC daemon also needs a configuration file (/etc/lircd.conf), which contains the proper addresses of your remote control’s buttons. The LIRC package contains some ready made remote configs, but I suggest you create your own. Read on…

The Remote Control Configuration file

In this section we will create a configuration file for our remote control by using an utility named irrecord, which was built together with the rest of the LIRC components. Since irrecord is a lircd client, the LIRC daemon needs to be running prior to using this tool.

So, as root, load the appropriate LIRC module and start the daemon:

# modprobe MODULE_NAME
# lircd

Now, change to a temporary directory and start irrecord:

# irrecord REMOTE_NAME

REMOTE_NAME is the remote control config file that will be created in the current directory. This will also be the name of your remote control that will be used within the created file. If you need to change it, do it by hand after this operation is finished. All you have to do is to follow the on-screen instructions. Generally, you will be asked to give names for the remote control buttons and to press each one of them.

After you are finished, copy the REMOTE_NAME file into /etc/, naming it lircd.conf. As root:

# cp REMOTE_NAME /etc/lircd.conf

Kill the running lircd instance and start the daemon again, so that it uses the new configuration:

# killall lircd
# lircd

Applications and LIRC Support

There are three kinds of applications:

1. Those which could and actually have been built with LIRC support. These act as LIRC clients when there is a running LIRC daemon.
2. Those which do support LIRC, but have not been compiled with the LIRC support enabled.
3. Those which do not support LIRC at all.

Generally, most multimedia applications, video and audio players, TV viewers and FM tuner applications, support LIRC. Also, many applications provide a method (separate utility or options) to send commands to a running instance of the application. This is particularly useful for programs that belong to the 2nd and 3rd categories. LIRC provides an utility, called irexec (LIRC client), which can be used to execute any command we want. This way, those applications can be controlled with the remote control through LIRC.

In order to use our remote control with a certain application, we have to create a configuration file that contains the mappings between the remote control’s buttons and the commands that will be executed when each button is pressed.

This file can be:

• named .lircrc and placed in the user’s home directory.
• named lircrc (without the period in front of the name) and placed in the /etc/ directory for system-wide configuration.

Information about this file’s format can be found in the relevant section of the LIRC Documentation.

Quick Tests

Here are some sample .lircrc files, so that you can test your installation. Make sure you have loaded the proper LIRC module and you have started the LIRC daemon. Save one of them as .lircrc and place it in your home directory.

Special Note: In the following sample config files, substitute the remote control name with the name you have used for your own remote control and the button name with a name of any of your own remote control’s buttons.

The first two samples will work with Xine and MPlayer respectively. These two players are usually built with LIRC support and, when launched, they act as LIRC clients.

Load Xine and press the specified button on your remote control. It should toggle between full-screen and window-mode.

# .lircrc - XINE sample test
begin
    prog = xine
    remote = KWTV878RF
    button = ZOOM
    config = ToggleFullscreen
    repeat = 0
end

Use the following config with MPlayer.

# .lircrc - MPLAYER sample test
begin
    prog = mplayer
    remote = KWTV878RF
    button = ZOOM
    config = vo_fullscreen
    repeat = 0
end

For applications that are not LIRC clients themselves, but which provide a method to send commands to a running instance of the application, the configuration is a bit different. The LIRC client irexec is used in these cases. When you press a button on the remote control, irexec executes the specified command. This requires that irexec is running. Start it as a user:

# irexec

Save the following as .lircrc and launch TVtime. The specified button on the remote control should toggle between full-screen and window-mode.

# .lircrc - TVtime sample test
begin
    prog = irexec
    remote = KWTV878RF
    button = ZOOM
    config = tvtime-command TOGGLE_FULLSCREEN
    repeat = 0
end

To start irexec and have it run in the background, start it as shown below:

# irexec &

To kill it:

# killall irexec

Some hints for more complicated configurations

Here are some hints for those of you who need complicated setups.

Toggle Buttons

You can create toggle buttons, for example you can set the same button to Play or Pause a video stream, by setting two config = command directives. They will be executed in turns. For example:

# Toggle button example
begin
    prog = irexec
    remote = remoteA
    button = buttonA
    config = play_command
    config = pause_command
    repeat = 0
end

Using this configuration, when buttonA is pressed for the first time, the play_command is executed. The second time buttonA is pressed, the pause_command is executed.

Modes

Let’s assume that you want to control many applications with your remote control. Some of them are LIRC clients and some are controlled through irexec. You can define various modes (groups of button to command mappings), one for each application.

First of all, read the .lircrc format page from the LIRC Documentation very carefully.

Keep in mind the following rule:

Each time you start a LIRC client and there is a mode within your configuration with a name equal to the application’s name, then this mode is automatically entered.

This means that if there is a mode named mplayer inside .lircrc and you start the mplayer program, which is a LIRC client, then the mplayer mode is automatically entered and only the button mappings that exist within this mode are functional.

Save the following as ~/.lircrc, substitute the remote control name and button names with your own, and start irexec:

# Example with modes
# MAIN BEGIN (irexec mode) - Application Selection Mode
# ---------------
begin irexec
    begin
        prog   = irexec
        remote = KWTV878RF
        button = 1
        # Start TVtime
        config = tvtime --window &
        # Enter tvtime mode
        mode = tvtime
    end
    begin
        prog   = irexec
        remote = KWTV878RF
        button = 2
        # Start Totem player and play DVD
        config = totem dvd:/ &
        # Enter totem mode
        mode = totem
    end
    begin
        prog   = irexec
        remote = KWTV878RF
        button = 3
        # Start Xine and play DVD
        config = xine dvd:/ --hide-gui &
        # Enter xine mode
        mode = xine
    end
end irexec
# ---------------
# MAIN END (irexec mode end)
# APP MODES BEGIN
# ---------------
# tvtime mode
begin tvtime
    begin
        prog = irexec
        button = POWER
        config = tvtime-command QUIT
        # Enter irexec mode
        mode = irexec
    end
    begin
        prog = irexec
        button = ZOOM
        config = tvtime-command TOGGLE_FULLSCREEN
    end
end tvtime
# totem mode
begin totem
    begin
        prog = irexec
        button = POWER
        config = totem --quit
        # Enter irexec mode
        mode = irexec
    end
    begin
        prog = irexec
        button = ZOOM
        config = totem --fullscreen
    end
end totem
# xine mode
begin xine
    begin
        prog = xine
        button = POWER
        config = Quit
        # Enter irexec mode
        mode = irexec
    end
    begin
        prog = xine
        button = ZOOM
        config = ToggleFullscreen
    end
end xine
# ---------------
# APP MODES END

I hope this example is clear enough. What is going on here is that when irexec (LIRC client) is executed, then the irexec mode is entered. When you press button "1", then TVtime is launched and the tvtime mode is entered. When you press the "POWER" button, TVtime quits and the irexec mode is entered etc. etc.

Furthermore, even if you do not start irexec, when you launch any LIRC enabled application, like Xine, MPlayer, Gnomeradio etc, then the appropriate mode will be entered automatically and you will be able to control this application remotely.

As you have probably already read in the LIRC Documentation, you can modularize this configuration by keeping each application mode in a separate file. Just don’t forget to include those separate files by adding a line like the following in ~/.lircrc. For example:

include ~/.lirc/tvtime.lircrc

Final Notes

Maybe you will need some time to familiarize yourself with the .lircrc format and probably more time reading the LIRC documentation, but you will be satisfied with the result.

For information about what commands are available for each application, please refer to the application’s documentation, project web site or support forum.

Also, if you need more information or support for LIRC, please ask your questions in relevant web forums. I have written all I know in this guide, so I am afraid I cannot help you more.

LIRC can do more things, for example it can be used to transmit IR signals or to connect to other LIRC servers accross the network. These have not been covered, not only because I consider such info as "too much" for a new user, but also because I have not been able to devote any time to experiment with these features.

This guide was written while using a Fedora 4 system.

Further Reading

You should read:

1. The LIRC Manual (Documentation)

Related Articles

• Kernel 2.6.17 and lirc_gpio driver
• The Complete Fedora Kernel Headers
• Creative PC-CAM Series webcams in linux
• Build a single native kernel module
• How to Disable IPv6 in Fedora and CentOS

Version: 0.3
Requires: Zenity, Totem

Download the script from the link below:
add_to_totem_playing_list.tar.gz

Update: Please use Jim’s method described in the comments. It’s by far a more decent solution! Thanks Jim :-)

Related Articles

• Search for viruses from Nautilus
• Send to Desktop – Create Symlink
• Print to CUPS printer instances
• Mailing List Manager
• Organizing Mailing List messages with Evolution