From owner-freebsd-multimedia@FreeBSD.ORG Sat Mar 26 23:49:51 2011 Return-Path: Delivered-To: freebsd-multimedia@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8B5C106566B; Sat, 26 Mar 2011 23:49:51 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 492298FC13; Sat, 26 Mar 2011 23:49:51 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 2FBF01E000C9; Sun, 27 Mar 2011 00:49:50 +0100 (CET) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.4/8.14.3) with ESMTP id p2QNi73Y088231; Sun, 27 Mar 2011 00:44:07 +0100 (CET) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.4/8.14.3/Submit) id p2QNi6r7088230; Sun, 27 Mar 2011 00:44:06 +0100 (CET) (envelope-from nox) From: Juergen Lock Date: Sun, 27 Mar 2011 00:44:06 +0100 To: VDR User Message-ID: <20110326234406.GB73041@triton8.kn-bremen.de> References: <20110326192838.GA68179@triton8.kn-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-multimedia@freebsd.org, lme@freebsd.org, Juergen Lock , freebsd-ports@freebsd.org, Alexander Leidinger Subject: Re: some vdr intro/installation notes (watch/record/stream tv) X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 23:49:52 -0000 On Sat, Mar 26, 2011 at 02:55:12PM -0700, VDR User wrote: > There are a few things I'd like to comment on..... > > On Sat, Mar 26, 2011 at 12:28 PM, Juergen Lock wrote: > >  So what is vdr?  It's something like a luxury settop box/pvr on a pc > > to receive/watch/record/stream digital tv channels with epg (electronic > > program guide), timers, client/server networking, webinterface etc pp. > > So if you have a FreeBSD (or Linux, but that's not covered here :) > > server you can add one or more dvb/atsc tuner(s) connected to a > > satellite dish, cable tv or just a dvb-t antenna (or receive iptv > > streams without a tuner if your isp provides those tho I don't know > > if anyone tested `real' iptv on FreeBSD yet), browse/search epg, > > set timers for automated or manual recordings, and watch the > > streams/recordings elsewhere on your lan.  Or if you have a FreeBSD > > desktop you can also connect a tuner there and do it all on one > > box - or just run a vdr client like vdr-sxfe (installed by the > > multimedia/vdr-plugin-xineliboutput port) or a client vdr instance > > using the streamdev-client plugin connected to a (possibly Linux) > > vdr server elsewhere on your lan. > > It should be noted that VDR was not designed to be a server/client > system. While it's technically possible to use it that way, keep in > mind that each client will not have it's own access to OSD, timers, > etc. Although server/client systems are widely popular these days, I > wouldn't expect this kind of major change to happen to VDR any time > soon. When and if it ever does, it's going to take a lot of work. > Unfortunately I don't recall VDR's author (Klaus Schmidinger) ever > expressing interest in this. > Hm well yeah it could still be better but what is there is not soo bad. > >  Note: vdr 1.7.17 is the development branch so expect bugs! > > (I mostly used it because the stable branch (1.6) doesn't support > > dvb-s2 and h264...) > > There are patches for the latest "stable" branch (1.6.x) which add > support for dvb-s2 and h264. The 1.6.x was considered final a long > time ago and hasn't/won't receive any updates. All development is > done in the current 1.7.x branch. Although VDR has both a "stable" > and "developer" branch, users should be aware that the developer > branch is easily as stable as the stable branch. It's by far the > users preferred branch of choice. Nobody should have any worries > about running a developer version. The only time I personally run the > stable branch is inbetween the closure of the last developer branch > and beginning of the next. In other words, I've always ran the newest > version and in all the years of doing this, I can count on one finger > how many times there was a stability issue. > Well thats even better then. :) (I also had few issues.) > > 1. Before you start installing these ports either mount an extra > >   fs with enough space for the recordings on /video or create a > >   video dir elsewhere where there is space, symlink it to /video > >   and make it writable for the vdr user.  (or if you do have one > >   big / then you can create the dir on there too of course, I just > >   disabled the mkdir in the port to avoid inadvertently filling > >   up ppl's small / fs.) > > > >   Or if you don't like a symlink you can also add your video dir > >   as -v to vdr's startup args, see below. > > You can create the default dirs and using them directly, use symlinks > to map the default dirs to dirs elsewhere, remap the defaults by > editing Makefile, or simply override the defaults using command line > options as you've mentioned. I've set my system up so everything > VDR/dvb-related goes into /dvb. This makes it very convenient and > easy to maintain and archive. Additionally I make use of symlinks > such as /vdr which is always linked to the latest VDR version, > /pluginsrc which always takes me to /vdr/PLUGINS/src, and so on. If > you're a run-and-forget user then it may not matter much but if you > tinker a lot then you might consider a similar setup -- you'll have a > much easier time navigating around the dirs. > Well I tried to at least somewhat adhere to hier(7)... > > 3. I have rc.d scripts for vdr and vdradmin-am but even if you > >   use those you still need to add plugins and their options similar > >   to this to your /etc/rc.conf: > > You can automate most of the stuff required to run VDR, and everything > else can be put in a .conf somewhere for the stuff that can't. I've > found this extremely useful and worth looking into for any level user. > Well passing plugin args is automated on Linux often but I didn't try to port those scripts, wanted to keep things simple... (editing rc.conf I think is easy enough?) > > 4. Of all the video output methods only xineliboutput and streamdev > >   seem to work (and the vdr-live webinterface browser streaming which > >   also uses streamdev), jpulz also has patches for softdevice so I made > >   a port for that too but it only gave me a black screen...  streamdev > >   doesn't have an osd so you probably want xineliboutput at least for > >   the first setup. > > Users also have the option of using vdr-xine, which is an alternative > to xineliboutput. I'm only aware of a few differences between them, > none of which have any real significance to me but the vdr-xine > author, Reinhard Nissl, is an active developer of xine-lib's vdpau > support as well. I've never used xineliboutput myself because of > Rnissl's accessibility and status as a xine-lib vdpau contributor. > The user bases for both vdr-xine and xineliboutput seem to be pretty > evenly matched from what I've seen. > I actually tried to port vdr-xine too more out of curiosity but only got netvdr:// `working' at all, and it was a slow slideshow. Probably some linuxism that I missed... Yeah I should shar that up so others can take a look. Ok just did: http://people.freebsd.org/~nox/dvb/xine/vdr-plugin-xine-slideshow.shar > >   I only very recently was able to test xineliboutput's vdpau/vaapi > >   support and it turned out I had to add patches to the libxine > >   port, so if you want to use that make sure it and ffmpeg are up > >   to date and built with the VDPAU and VAAPI knobs on.  To test > >   vdpau you can try something like: (vdr-sxfe gets installed by > >   the xineliboutput plugin port) > > With vdr-xine no patching is necessary as long as you using > xine-lib-1.2 hg revision 11658 (hash 3501e0a6f75c) or newer. I > recommend using this regardless as it contains items necessary for > VDR-1.7.17's new truecolor OSD support. > So xine-lib 1.2 is recommendable yet? I was so far trying to stick to 1.1.19 release + patches since other FreeBSD ports use libxine too and I know nothing at all about the 1.2 branch and how stable it is... :) > >        vdr-sxfe --hotkeys --video=vdpau --post tvtime:method=use_vo_driver,use_progressive_frame_flag=1 --audio=oss --reconnect xvdr+tcp://127.1 > > > >   if that looks jerky or doesn't work with hd material maybe your > >   card cannot handle the default vdpau deinterlacing method, you > >   can change that in ~/.xine/config_xineliboutput, for an `old' > >   ION I use: > > > >        video.output.vdpau_deinterlace_method:half temporal > > Your ion1 should be able to handle temporal, as mine does. Using half > temporal shouldn't be necessary. > Ok I should check that. Hmm no, a 1080i recording of `Servus TV Hockey night' I did for testing deinterlacing looks `jumpy' with temporal when there is more motion. Maybe things have improved in libxine 1.2? > >   If you don't use vdpau (I think that conflicts with compositing) > >   you can now also try compositing and running vdr-sxfe with --hud > > IIRC, the compositing issue was resolved some nvidia driver versions > ago. You may want to confirm this however at: www.nvnews.net > Oh, well I think I only got a black window when I tried --hud, guess I should look again. (Atm I disabled compositing because it interfered with hd video playback too.) > > 7. And for those that want to use lirc:  See the comms/lirc port's > > Note: LIRC users do _not_ need the remote plugin. > Yes. > > - If vdr crashes/exits at start check permissions of files/dirs it > >  needs write access to (below /usr/local/etc/vdr, /var/cache/vdr, /video) > > If you've remapped the defaults, then those dirs, which may not be the > ones you've mentioned, need to be writable. > True, tho if you install from ports may want to stick to the hier(7)-compatible defaults? > > - Small bug:  if playback of a recording doesn't start try pressing Green. > >  (or F6 with my example remote.conf keyboard mapping.) > > I've never heard of this bug. Could you elaborate? > It mostly happens with short recordings that were already played before... I think. (Tho I also yesterday saw it with vdpau on a longer recording, for the first time.) > > - Someone(tm) may want to write a `real' step-by-step guide how to > >  get a FreeBSD vdr going...  (preferably someone who has never > >  used vdr before to make sure important stuff I never think about > >  isn't left out.) > > I haven't gotten around to giving freebsd+vdr a try yet but when I do > I'll definitely be writing a howto which I'll be more then happy to > share. It will however be geared towards a vdpau based system unless > for some reason I decide to change from that, which isn't likely. > That would be nice. > And lastly I would like to point out that a small patch is required to > VDR's core to get North American dvb-s AC3 audio working. > Oh, if you have a link for that... :) Thanx! Juergen