As mentioned in the other VDR-thread, I've been experimenting with VDR
on the beagleboard for two or three weeks now. (Read: two or three
hobbyist's weeks). A few details of my setup:
*Beagleboard Rev C2
*2 GB Sandisk SD-Card Extreme III (though I'm not sure whether a fast
card makes a difference)
*Hauppauge WinTV-Nova-T USB2 DVB-T-Receiver
*MOSCHIP 7830/7730 usb-NET adapter (for German users: the one they
sell at Conrad Electronics)
*Angström (X11 image created with Narcissus online image builder)
*a bunch of packages from the Angström feeds (including MPlayer,
GStreamer + plugins, ti-dsp-related packages)
*libcap (included in openembedded but not in Angström, so I set up the
OE environment and followed the Angström wiki, then I ran "bitbake
libcap" and installed the resulting ipk-package on the beaglebard.
*VDR 1.6.0 compiled natively on the beagleboard
*VDR-plugins: ffnetdev, streamdev-server, control (all compiled
natively on the beagleboard)
*LIRC compiled natively on the beagleboard (LIRC is available in the
feeds, but I needed lirc support for devinput i.e. my remote control).
Boot time: obviously similar to Angström without vdr.
As stated in the other thread, I haven't been able to compile the
softdevice plugin (configure works fine, but make fails). Another
theoretical option would be to use the xine-output plugin, however,
xine doesn't exist in the Angström feeds. Before using my current
setup, I also tried Debian on the beagleboard. There, vdr and several
plugins are available in the repository, so installation is absolutely
painless and xine-output works - in theory. Alas, Debian is lacking
arm7/neon optimisations, and so the xserver always crashed after the
first few seconds of video.
For the moment I'm trying less sophisticated output methods based on
the various possibilities for stream output that vdr offers. I'm
investigating the viability of different scenarios based on these
1) The ffnetdev plugin offers the current live tv signal and the osd
on two different ports. The video stream is accessible via tcp://<local
:20002, the OSD is sent VNC-style.
2) The streamdev-server plugin can stream any station from the
currently tuned bouquet (At least here in Germany, 4 stations are
transmitted on one DVB-T channel). However, the plugin is not
automatically linked to the remote control or the channel switching
process. In the case of a local client on the beagleboard, that's not
really a problem. There are several options for stream output,
currently I'm using http and TS format (see below).
Players used for output:
1) VLC can be used for either ffnetdev or streamdev-server. In the
case of ffnetdev, it has the advantage of being able to display both
the video signal and the osd in the same window. It works on the
beagleboard, but xv video output is choppy.
2) Mplayer can directly access output generated by streamdev-server as
it comes in via http. Unfortunately, Mplayer can't access ffnetdev
directly as it doesn't know how to handle addresses like tcp://192.168.1.40:20002.
My work-around was to use nc in order to write the output of ffnetdev
into a fifo /var/2_mp and to have MPlayer read from that fifo. I'm
aware that this is just a poor man's solution - feel free to come up
with something better!
MPlayer works quite well with these streams, even in fullscreen mode.
Quality and stability are slightly better with streamdev-server. A/V
synchronisation may be problematical at times, though, and the video
hangs for fractions of a second from time to time. A typical command
line might look like this:
mplayer -vo omapfb -cache 4096 -tskeepbroken -framedrop -fs
http://127.0.0.1:3000/TS/T-8468-3329-160 (for streamdev-server)
mkfifo /var/2_mp (just once)
nc <local ip> 20002 > /var/2_mp &
mplayer -vo omapfb -cache 4096 -tskeepbroken -framedrop -fs /var/2_mp
3) gstreamer & TI dsp stuff
Output from both plugins can also be rendered using gstreamer.
However, all my attempts so far ended up in USB problems (especially
with the ethernet adapter). This is not just a nuisance, at least in
conjunction with ffnetdev it's a major problem because ffnetdev
appears not to accept connections made via 127.0.0.1. So if the usb-
ethernet adapter is disconnected (not physically but according to
dmesg), the video stream breaks down as the IP address is linked to
the device. But maybe that's just because of a flaw in my gst-launch
pipeline. Here it is:
gst-launch -v tcpclientsrc host=192.168.1.40 port=20002 ! ffdemux_mpeg
name=demux demux.audio_00 ! queue max-size-buffers=1200 max-size-
time=0 max-size-bytes=0 ! mad ! osssink sync=true demux.video_00 !
TIViddec2 numOutputBufs=3 ! queue max-size-buffers=2 max-size-time=0
max-size-bytes=0 ! omapdmaifbsink sync=true
I've tried variants of this pipeline but the usb problem remained. As
far as I can see, it only occurs if the dsp related modules are
This is the area in which I've been least successful. As mentioned
above, vlc can display the osd, however, the price is choppy video
(rather slideshow) and therefore vlc is out. Tightvncviewer can
display the osd, however, it has its own window and that makes some
tricky switching between mplayer (fullscreen) and tightvncviewer
necessary. It can be done in principle, but I haven't written a
satisfactory script for that task yet.
There's also a rfbsrc plugin for gstreamer but until now, I couldn't
make gstreamer and ffnetdev agree on a colour depth (gstreamer seems
to ask for 0 bits depth?!)
An ugly but fairly easy solution is to use VDR's control plugin. It
offers the OSD in a telnet session, so forget about eye candy. It's
enough to make some settings but it's not really what you want on an
HTPC and there's also the question of how to coordinate the respective
For the time being, I've chosen the combination of vdr with streamdev-
server and MPlayer. I haven't got any good solution for VDR's OSD. As
a (temporary?) alternative I use MPlayer's OSD. You can create a
rather intricate menu system which also allows you to execute commands
directed at VDR (via VDR's SVDRP protocol). For my remote control,
I've created a ~/.lircrc configuration file which intercepts all rc
signals and makes irexec run the action I want (e.g. send a SVDRP
signal to VDR - usuallly something like "CHAN 5" for switching to
another channel OR write a command for mplayer into the fifo that is
used as a control file for mplayer).
Pros of this setup:
*average linux knowledge is sufficient to set it up
*most software used is available in the Angström feeds
*can be run with or without xserver (X is useful if you want to
integrate apps that depend on X into your OSD menu - be it VDR or
MPlayer. Something like starting Midori with the remote control. Or
you might just want to use vdr as a recording backend and watch live
TV only occasionally.)
*MPlayer OSD can be easily expanded/altered to satisfy personal needs.
*Beagleboard hardware is not optimally used - DSP remains idle.
*No VDR OSD (yet)
*Channel switching times are rather long due to MPlayer's need for
cache. Whenever I tried less then 4MB cache for a DVB stream, MPlayer
couldn't display it properly. It takes a moment for these 4MB to fill
up and then MPlayer needs a few seconds to start playing the stream.
Me: Currently, my scripts/menu definitions etc. are in a state that
doesn't allow posting them anywhere. Too many things don't work as
expected. That's why I went to some detail in my descriptions above -
get the idea but don't get annoyed by my bad scripting. If you
desperately need these broken scripts, you'll have to send me a pm.
However, I will not support anything of which I've said it's broken.
So what I need to do is to fix and improve these scripts. In addition,
I'll have a look at the problem of window management mentioned above.
Someone else, please: If there's anyone who knows how to do one of the
following things - please help!
*A stable and well-performing gstreamer pipeline for MPEG2 encoded
live streams. There is a choice of stream formats (TS, PES,ES) -
maybe it's as easy as changing that. I will try myself, but
admittedly, as far as gstreamer is concerned, I'm merely poking
*Make VDR's softdevice plugin work on the beagleboard. It supports
(amongst others) Xv output (so that bit shouldn't be too hard, I
guess) and maybe someone might even port omapfb-support from MPlayer
to that VDR plugin (if anything like that is possible at all).
*DSP support for VDR that doesn't rely on gst-launch. That's far
beyond my capabilities, but I'd like it nevertheless
There's also a thread about VDR on beagleboard here:
http://www.vdr-portal.de/board/thread.php?threadid=90377 (in German)
but currently you won't find anything there that hasn't been said
I promise I will post my scripts etc., however, don't expect them this
Because it's the best media center/tv/pvr software I've ever seen. For
a media center focused on watching and recording tv, there's simply no
alternative. There are already a lot of plugins for a variety of
purposes, you can add user defined actions to the osd menus or you
might want to write your own plugin. So it is rather easy to add
exactly the editing tools you want to accompany the built-in cutting
functions (e.g. you might want to add
One of VDRs strongest points is the interoperability of VDRs on a LAN.
For example, I can start watching a recording on my VDR in the living
room, pause it and resume viewing on my beagleboard VDR exactly where
I stopped. I can even use VDR2 to watch a recording being made on VDR1
while it is being recorded (mere timeshift is old news, timeshift
across machines is really cool). In addition, the number of DVB tuners
on a VDR is not limited, so you can easily set up a twin tuner system
and you can mix DVB-T, DVB-S and DVB-C. Guess why the pricy Reelbox is