Use case as a HTPC with VDR
Paul Menzel
I want to build a home theater PC (HTPC) for my grandparents. A 32 inch
flat screen TV with HDMI connectors will be available.
The main tasks will be the following.
1. Record TV shows preferable with VDR [1].
2. Use the USB DVB-T stick TerraTec Cinergy DT USB XS Diversity [2],
which works on my x86 system.
3. Show pictures from hard disk and play MPEG2-recordings transferred
from DVD to hard disk.
My main concern is, if the Beagle Board will play the MPEG2 files (DVD
and DVB-T recordings) without any problems.
I found a project [3] which tried this already. The results sound good.
The author just says, that windows were slowly opening under his desktop
environment and that back then his movies were played with a little
delay.
What is the current state? Are the drivers mature enough to handle these
tasks?
Bests and thanks,
Paul
[1] http://www.tvdr.de
[2] http://www.terratec.net/de/produkte/Cinergy_DT_USB_XS_Diversity_1607.html
[3] http://www.syspire.de/de/content/embedded-mediacenter (German)
Frans Meulenbroeks
Interesting plan.
You might also want to look at mythtv [4]. Configuration wise it is a
small nightmare, but the usability once configured is ok.
I'm working porting mythtv to openembedded/beagle (but will try to
find time to look at tvdr and freevo too)
[4] www mythtv.org
Good luck, Frans
Frans Meulenbroeks
The major bottleneck wrt beagle is probably usb.
You're going to be a heavy user of usb (from tuner over usb to beagle
over usb to disk, while maybe playing another movie from disk over usb
to beagle.
And meanwhile some network activity may be going on.
It might help to connect one of the devices to the OTG port.
Good luck, Frans.
Paul Menzel
On 2 Nov., 19:54, Paul Menzel <pm.deb...@googlemail.com> wrote:
[…]
> 1. Record TV shows preferable with VDR [1].
I just found out that T. Brinkmann already tried something similar and
posted his results to the list. So please follow up this thread [4]
about the VDR topic.
[…]
Thanks,
Paul
[4] http://groups.google.com/group/beagleboard/browse_thread/thread/b7bec30fd5783fd8/2827c593c70b9747
yoheeb
Something that might alleviate some of the work is to make it a
diskless MythTV or VDR setup to a backend read-only FS and media
server, might cut you down to 2 usb uses, a media stick for your
pictures, and the networking, assuming you can boot over lan via usb,
which I have never tried.
T. Brinkmann
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:
Hardware:
*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)
Software:
*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
options:
VDR:
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
ip>: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)
or
mkfifo /var/2_mp (just once)
nc <local ip> 20002 > /var/2_mp &
mplayer -vo omapfb -cache 4096 -tskeepbroken -framedrop -fs /var/2_mp
(for ffnetdev)
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
loaded.
OSD output
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
windows.
Current state:
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.
Cons:
*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.
ToDo:
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
around.
*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
here.
I promise I will post my scripts etc., however, don't expect them this
week.
Regards,
T. Brinkmann
Afterthoughts:
Why VDR?
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
VDR based!
Some links:
In English:
http://www.tvdr.de/
http://www.reel-multimedia.com/en/index.html
http://linuxtv.org/vdrwiki/index.php/Main_Page
In German:
http://www.vdr-portal.de/board/index.php
http://www.vdr-wiki.de/wiki/index.php/Hauptseite
http://www.vdr-wiki.de/wiki/index.php/Plugins
T. Brinkmann
So it is rather easy to add exactly the editing tools you want to
ProjectX for demuxing, the cutting app you like best (admittedly, I
still prefer Cuttermaran under Win32), DVDAuthor for creating VOBs and
mkisofs for creating images. Or you could use the Beagleboard's DSP in
a gstreamer pipeline to convert your recordings to MPEG4. Apparently,
some people even compress/remux the dvb signal and stream to over
their ADSL lines so that they can access their VDR over the internet.
Paul Menzel
Am Dienstag, den 10.11.2009, 07:53 -0800 schrieb T. Brinkmann:
[status of project]
thank you for the great overview.
> 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
> around.
Did you already ask on the GStreamer list?
> *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).
vdr-softdevice [1] does not seem to be actively developed anymore. There
seems to be only caretaking going on if I read the changelog [2]
correctly. But I could be wrong.
You wrote that `make` aborts with an error. Could you post the build log
in another thread? Or is it better to bring this up on a more general
list or directly on the VDR list? I could do this if you sent me the
error message.
> *DSP support for VDR that doesn't rely on gst-launch. That's far
> beyond my capabilities, but I'd like it nevertheless ;)
Me too. Sounds really good. For my case I do not have the abilities and
furthermore I do not the knowledge on what has to be done.
Would that be a solution specific to VDR or is this a driver issue all
kinds of programs would benefit from?
I guess some people reading this list could give hints how this could be
accomplished.
Please tell me, how I can help. I could send in some bug reports to the
correct lists if you want me to, if you have not done it already.
> 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
> here.
Thank you for the summary.
[…]
Bests,
Paul
[1] http://softdevice.berlios.de/
[2] http://cvs.berlios.de/cgi-bin/viewvc.cgi/softdevice/softdevice/CHANGELOG?revision=1.348&view=markup
Paul Menzel
Am Montag, den 14.06.2010, 02:28 -0700 schrieb st0rfrasarn:
> Are you still working on this? I'm very interested in this.
I want to, but I kind of lack the time right now. I got VDR (1.7.10, I
think) into OpenEmbedded and Ȧngström. But some patches were needed, of
which some have been included into the current VDR 1.7.15 release. So I
want to try to update the packages soon to the latest release. Also the
plugins have not been packaged yet.
I also looked into Enna [1] as a frontend and got those package updated.
But again I could not test it yet.
> I think the best option is to use XINE.
Besides of that I did not have much time to test things. But as far as I
know, MPlayer should be better supported on the BeagleBoard than xine.
GStreamer would even been better, but the GStreamer plugin was not
usable last time.
Sorry, that I could not give you a better answer. I guess now especially
a lot of testing is needed to see what can be done.
So if you can join in and help, that would be awesome. We should make
sure though to coordinate the next steps, so that no work is done twice.
Thanks a lot,
Paul
T. Brinkmann
too much progress. When I posted first, I expermented with a natively
compiled VDR 1.6. The advantage was that vdr's ffnetdev plugin [1]
worked for me in that version. ffnetdev allows streaming and
transmisson of vdr's osd on two separate tcp ports. In principle, vlc
can be used as a client, however, vlc on the beagleboard is too slow
to display the videostream fluently.
From what I've read and expierenced, there have been changes in the
dvb api, so vdr 1.6 won't compile on my current image (Angstrom built
with the narcissus online builder in May) . However, vdr 1.7.10 is in
the feeds and it's fairly easy to compile vdr plugins natively after
installing vdr-dev. Unfortunately, ffnetdev compiles, but the
videostream breaks down after a few seconds (no matter whether I use a
client on the beagle or on a remote machine, independent of the OS).
The alternative is vdr's streamdev-plugin which is very stable. It's
also possible to use ffnetdev for the osd (transmitted via VNC
protocol) and streamdev for videostreams.
For the time being I use mplayer -vo omapfb to watch the streams.
Given good reception, this works rather well, but cpu load is fairly
high. I'm also encountering some aspect ratio issues in fullscreen
mode on a 16:10 display, but there are about 10 zillion mplayer
options which I haven't explored yet.
For a good user experience, the osd is of course necessary (and I'm
not talking about mplayer's osd but vdr's). Basically, any VNC client
should do, but then again, you don't really want separate windows for
video and osd (or do you?).
gstreamer does not work too well for me in this context. I can start
watching streams provided by vdr/streamdev with something like:
gst-launch -v gnomevfssrc location=http://192.168.1.40:3000/10 !
ffdemux_mpegts name=demux demux.audio_00 ! queue max-size-
buffers=1200 max-size-time=0 max-size-bytes=0 ! mad ! alsasink
demux.video_00 ! TIViddec2 codecName=mpeg2dec engineName=codecServer
frameRate=25 numOutputBufs=4 ! queue max-size-buffers=2 max-size-
time=0 max-size-bytes=0 ! TIDmaiVideoSink contiguousInputFrame=TRUE
framerate=25 accelFrameCopy=TRUE
I've tried several variations (including omapdmaifbsink instead of
TIDmaiVideoSink), but whatever I do, I get this error:
ERROR: from element /GstPipeline:pipeline0/GstTIViddec2:tividdec20:
failed to get a free contiguous buffer from BufTab
The only time I don't get it is when USB crashes first :(
I've tried other buffer settings unsuccessfully. Any help would be
appreciated.
Finally, some good news:
If you don't care about live tv, recording works well! In order to
program recordings, you can use the webinterface provided by vdradmin-
am. Installation is a bit tricky, but those perl modules that aren't
available from the feeds are optional anyway. In combination with the
epgsearch plugin, you can program complex serial recordings etc.
@Paul Menzel:
I'm aware of the fact that both enna and xbmc developers are working
on interfacing vdr via the xine plugin. Nevertheless, as xine has not
yet been ported to the beagleboard, I wonder whether one of the
various xine-related plugins is really such a good idea.
Regards,
Thomas
[1] For all vdr related software mentioned, see:
http://www.vdr-wiki.de/wiki/index.php/Hauptseite (German)
http://www.linuxtv.org/vdrwiki/index.php/VDR_Wiki:Portal (English)
http://www.vdrwiki.com/index.php/VDR_Wiki:Portal_de_la_comunidad
(Spanish)
T. Brinkmann
It's also possible to run vdr as a tv streaming server for your local
network. As said above, you need vdr + streamdev plugin on the beagle.
You can also try to use ffnetdev additionally to get the osd. On the
client side, you can run vlc with a command line like this:
"C:\Program Files\Video\VLC\vlc.exe" --sub-filter="remoteosd" --rmtosd-
host=192.168.1.40 --rmtosd-port=20001 --no-rmtosd-vnc-polling --no-
rmtosd-mouse-events --rmtosd-key-events --rmtosd-alpha=255 --http-
caching=4000 http://192.168.1.40:3000/channels.m3u
(where 192.168.1.40 is my vdr's ip address, 20001 is the tcp port on
which ffnetdev transmits the osd using the vnc protocol and 3000 is
the port used by streamdev)
channels.m3u is provided by streamdev. VLC accepts it as a playlist so
that you can switch channels rather comfortably. However, ffnetdev and
streamdev don't always "agree" on which channel is being watched, so
ffnetdev might create osd messages like "Channel not available" - some
fine tuning required.
On the beagleboard, however, mplayer is the better choice, but to my
best knowledge, there's no way to feed vdr's osd into mplayer. A
somewhat acceptable tv experience can be achieved by providing a
menu.conf for mplayer and defining control keys. I'm not going to
discuss mplayer options here, have a look at:
http://www.mplayerhq.hu/design7/info.html#docs
The best example of mplayer osd-menu configuration that I know about
is the traditional no-X geexbox 1.x:
http://geexbox.org/en/index.html
My future plans for vdr on the beagle run along these lines:
a) Development of a Tk/Tcl script that joins osd and video in one
resizable window. I've begun to modify sources from:
http://wiki.tcl.tk/13059
http://wiki.tcl.tk/6269
I still have two windows, though, but I haven't yet spent too much
time on this one. It looks feasible, but it's a bit, err, primitive
and it won't break any records in performance. OSD transparency might
prove a real obstacle in this case.
b) Improved gstreamer pipeline. There is a gst-plugin for rfb sources
and mixing/blending two sources should be possible. However, the
buffer error mentioned in my previous post needs to be solved first.
Controling vdr with a remote is yet another story. Obviously, your
starting point is LIRC, but as all options described above include vdr
as a streaming server _and_ a client, some xy.lircrc hackng is
necessary to get the expected reactions.
Regards,
Thomas
Paul Menzel
[…]
> gstreamer does not work too well for me in this context. I can start
> watching streams provided by vdr/streamdev with something like:
>
> gst-launch -v gnomevfssrc location=http://192.168.1.40:3000/10 !
> ffdemux_mpegts name=demux demux.audio_00 ! queue max-size-
> buffers=1200 max-size-time=0 max-size-bytes=0 ! mad ! alsasink
> demux.video_00 ! TIViddec2 codecName=mpeg2dec engineName=codecServer
> frameRate=25 numOutputBufs=4 ! queue max-size-buffers=2 max-size-
> time=0 max-size-bytes=0 ! TIDmaiVideoSink contiguousInputFrame=TRUE
> framerate=25 accelFrameCopy=TRUE
>
> I've tried several variations (including omapdmaifbsink instead of
> TIDmaiVideoSink), but whatever I do, I get this error:
> ERROR: from element /GstPipeline:pipeline0/GstTIViddec2:tividdec20:
> failed to get a free contiguous buffer from BufTab
> The only time I don't get it is when USB crashes first :(
> I've tried other buffer settings unsuccessfully. Any help would be
> appreciated.
For the list: I contacted the GStreamer folks and they told me [1] to
get in touch with the TI folks.
I found [2] and will open a ticket. Thomas could you please send some
debugging information [3] in a reply to the list? I have not yet set up
this environment, so it would be great if you could provide this
information. I will include that into my ticket. I found [4] where some
similar messages appear. In the header you will also see the information
they request.
Thanks,
Paul
[1] http://sourceforge.net/mailarchive/forum.php?thread_name=20100615003234.GA19309%40cooker.entropywave.com&forum_name=gstreamer-devel
[2] https://gstreamer.ti.com/gf/project/gstreamer_ti/
[3] https://gstreamer.ti.com/gf/project/gstreamer_ti/wiki/?pagename=FAQ (under: »How do I debug this "xyz" problem?«)
[4] https://gstreamer.ti.com/gf/project/gstreamer_ti/tracker/?action=TrackerItemEdit&tracker_item_id=309
T. Brinkmann
On 18 Jun., 10:54, Paul Menzel <pm.deb...@googlemail.com> wrote:
> (..). Thomas could you please send some
> this environment, so it would be great if you could provide this
> information.
information asap.
Thomas
lchile
Have you had any time to make any more progress?
On Jun 14, 4:13 pm, "T. Brinkmann" <mynameisnob...@nord-com.net>
wrote:
lchile
mistake?) in the Narcissus build of Angstrom an incomplete version, or
has the OSD etc been fixed?
> > (Spanish)- Hide quoted text -
>
> - Show quoted text -
