vdr November 2008

vdr@linuxtv.org

66 participants
68 discussions

Channel overview based upon Bouquet
by Niels Wagenaar 29 Nov '08

29 Nov '08

I was testing a patch which would allow the Reel-VDR sources to be compiled against multiproto. But during the test of Reel-VDR, I found out that the Channel Overview was only showing the channels in the chosen Bouquet. I do really like this option and I thought it was a option in the setup.conf. However, I'm not able to find that option. Can somebody enlighten me if this option exists or if I can re-create it with a plugin? Regards, Niels Wagenaar

2 2

OT: local variables limited in size to (8*1024*1024-32*1024) bytes ?
by Stefan Lucke 29 Nov '08

29 Nov '08

Hi, the attached program segfaults when using a larger local variable. Depending on used value I get segfaulst at different locations. //#define BUFSIZE (9*1024*1024-16*1024) // only segfault #define BUFSIZE (8*1024*1024-16*1024) // hello + segfault //#define BUFSIZE (8*1024*1024-32*1024) // hello + 2nd line When using last definition of BUFSIZE every thing is fine. stefan@jarada /home/nfs/extra/src/video/DVB/xlist $ ./test Speicherzugriffsfehler stefan@jarada /home/nfs/extra/src/video/DVB/xlist $ vi test.cc stefan@jarada /home/nfs/extra/src/video/DVB/xlist $ g++ -g test.cc -o test stefan@jarada /home/nfs/extra/src/video/DVB/xlist $ ./test hello ./test: argc = 1 stefan@jarada /home/nfs/extra/src/video/DVB/xlist $ vi test.cc stefan@jarada /home/nfs/extra/src/video/DVB/xlist $ g++ -g test.cc -o test stefan@jarada /home/nfs/extra/src/video/DVB/xlist $ ./test hello Speicherzugriffsfehler stefan@jarada /home/nfs/extra/src/video/DVB/xlist $ ./test stefan@jarada /home/nfs/extra/src/video/DVB/xlist $ ulimit unlimited stefan@jarada /home/nfs/extra/src/video/DVB/xlist $ gcc --version gcc (GCC) 4.1.2 (Gentoo 4.1.2 p1.1) Copyright (C) 2006 Free Software Foundation, Inc. Dies ist freie Software; die Kopierbedingungen stehen in den Quellen. Es gibt KEINE Garantie; auch nicht für MARKTGÄNGIGKEIT oder FÜR SPEZIELLE ZWECKE. -- Stefan Lucke

3 2

[ANNOUNCE] vdr-sudoku-0.3.4
by Thomas Günther 29 Nov '08

29 Nov '08

Hi! There is a new version of the Sudoku plug-in. Download: http://toms-cafe.de/vdr/sudoku/vdr-sudoku-0.3.4.tgz Changes since version 0.3.3: - Fixed solve and print mode of sudoku_generator (don't work if the dump begins with a digit - thanks to Ville Skyttä for reporting this). - Updated Finnish language texts (thanks to Ville Skyttä). - Updated French language texts (thanks to NIVAL Michaël). - Updated Italian language texts (thanks to Diego Pierotto). - Updated Spanish language texts (thanks to Bittor Corl). This plug-in generates Number Place puzzles, so called Sudokus, and let you solve it. A Sudoku puzzle consists of 9 x 9 cells subdivided into 9 regions with 3 x 3 cells. The rules are simple. There have to be the numbers from 1 to 9 in every row, column and region. In the beginning some numbers are given. These cells are painted with cyan background color. The aim of the puzzle is to find the missing numbers. There is only one solution of a Sudoku puzzle. See the project's homepage for details: http://toms-cafe.de/vdr/sudoku/ Tom

1 0

xineliboutput crashes when closing the xineliboutput/video menu
by Nicolas Huillard 27 Nov '08

27 Nov '08

Hi, This is the most annoying bug : after some time tweaking the video output (which works), the video submenu just crashes VDR upon closing (with "back", "menu" or "ok" keys). No matter that I change setting or not : closing will crash. The current video setup is : xineliboutput.Video.AspectRatio = 0 xineliboutput.Video.AutoCrop = 0 xineliboutput.Video.AutoCrop.AutoDetect = 1 xineliboutput.Video.AutoCrop.DetectSubs = 1 xineliboutput.Video.AutoCrop.FixedSize = 1 xineliboutput.Video.AutoCrop.SoftStart = 1 xineliboutput.Video.Brightness = -1 xineliboutput.Video.Contrast = -1 xineliboutput.Video.Deinterlace = bob xineliboutput.Video.DeinterlaceOptions = method=Linear,cheap_mode=1,pulldown=none,framerate_mode=full,judder_correction=1,use_progressive_frame_flag=1,chroma_filter=0,enabled=1 xineliboutput.Video.Driver = xxmc xineliboutput.Video.FieldOrder = 0 xineliboutput.Video.HUE = -1 xineliboutput.Video.IBPTrickSpeed = 0 xineliboutput.Video.MaxTrickSpeed = 12 xineliboutput.Video.Overscan = 0 xineliboutput.Video.Port = :0.0 xineliboutput.Video.Saturation = -1 xineliboutput.Video.Scale = 0 xineliboutput.Video.SwScale = 0 xineliboutput.Video.SwScale.Aspect = 0 xineliboutput.Video.SwScale.Downscale = 0 xineliboutput.Video.SwScale.Height = 576 xineliboutput.Video.SwScale.Resize = 0 xineliboutput.Video.SwScale.Width = 720 xineliboutput.VideoModeSwitching = 1 I guess there is some kind of "impossibility" here, but I didn't tweak these setting manually. (I didn't find an english-speaking xineliboutput-specific mailing list anywhere, so I guess the good spot is here) -- NH

3 5

Re: [vdr] New Video Decode and Presentation API from NVidia
by HighlyCaffeinated 27 Nov '08

27 Nov '08

I'm new to using git to obtain sources, and can't seem to get the vdpau sources into my local ffmpeg git tree. In /usr/local/src/VDPAU i've pulled the ffmpeg sources creating a ffmpeg-git directory with the usual ffmpeg data in it. I then try to pull the vdpau sources with "git clone --reference /usr/local/src/VDPAU/ffmpeg-git git://repo.or.cz/FFMpeg-mirror/ffmpeg-vdpau.git". This creates a ffmpeg-vdpau directory with nothing but .git in it; no sources. Anyone with more experince in this have any pointers on what I am doing wrong? I'm in the US running vdr 1.6.0-2 on an AMD x2 4600+ using ffmpeg and xine and have no problems with HD MPEG2 and H264 up to 1080i (some occasional stuttering), but the 1080p channels fail miserably. While waiting patiently for xine to support VDPAU, I'd like to get the driver and ffmpeg working with Mplayer to try things out. Thanks Todd

3 3

Right way to detect real name of channel
by Andreas Brachold 26 Nov '08

26 Nov '08

Hi, im looking for a right way to split long and short name of channel via SVDRP. The vdr man page say : --- Some TV stations provide a way of deriving a "short name" from the channel name, which can be used in situations where there is not much space for displaying a long name. If a short name is available for this channel, it follows the full name and is delimited by a comma, ... --- But her in Berlin exist a DVB-T channel with comma inside name "94,3 rs2" $ svdrpsend.pl lstc | cut -d ':' -f 1 | grep ',' 250-4 RTL Television,RTL;RTL World 250-8 Super RTL,S RTL;RTL World 250-201 sunshine live,sunshine;BetaDigital 250-207 ANTENNE BAYERN,ANTENNE;BetaDigital ... 250-1002 94,3 rs2;MEDIA BROADCAST ... Is this a provider mistake ? Or could vdr merge long and short channel name by a other character ? Andreas

1 0

xineliboutput sxfe / xxmc / via / EPIA ML6000 : great !
by Nicolas Huillard 26 Nov '08

26 Nov '08

Hi all, I'd like to report that I'm really impressed by the new setup I now have. The most problematic thing was proper transparent OSD which would not eat much CPU. I must tell that the xxmc (XVMC-VLD) decoding is nearly perfect, the OSD is fully transparent on this, and does not take any CPU at all, and the system is on par with softdevice. My current setup : * diskless system : EPIA ML6000 / 600MHz, 512MB, diskless, 100Mbps Ethernet, 12V power supply, no fan, no noise : 25W off the wall while decoding video * NFS root FS on the always-on server : fully Debian etch with e-tobi repository, no self compiled package, except kernel-source package for LIRC * VDR 1.6.0-2 * xineliboutput 1.0.3 * streamdev-client 0.3.4 * skinsoppalusikka 1.6.2 * femon 1.6.3 BTW : CPU usage was 2% when decoding SDTV MPEG2 video only, with no Alsa sound setup, and climbed to 20% when Alsa was finally configured and working. That's a bit strange to think that audio is 9x more CPU-intensive than video ;-) (I think it may also be a big slice of synchronization delays) Kudo to everyone involved in VDR, at all levels ! (problems/crashes reports will be for another day/post) -- NH

11 26

VDR/eHD HD Picture Breakup
by Morfsta 25 Nov '08

25 Nov '08

Hi, I've posted this to the reel multimedia forum but have had no response, so thought I'd try here. This might have been covered in German on the VDR forum or on the Reel forum so I'm hoping someone knows about it. I am using VDR and eHD (SVN 8858) and I get picture break ups (ongoing pixelisation and stutter) until I change channel up and down. This happens only on HD channels and usually occurs after about 10 minutes of completely normal viewing. Has anyone experienced this and is there any fix? Thanks, Morfsta

3 3

New Video Decode and Presentation API from NVidia
by Goga777 25 Nov '08

25 Nov '08

FROM XORG lIST I'm pleased to announce a new video API for Unix and Unix-like platforms, and a technology preview implementation of this API from NVIDIA. The API is called VDPAU (Video Decode and Presentation API for Unix). The current API documentation is here: ftp://download.nvidia.com/XFree86/vdpau/doxygen/html/index.html Some highlights of VDPAU: * Defines an API for GPU-accelerated decode of MPEG-1, MPEG-2, H.264, and VC-1 bitstreams. * Defines an API for post-processing of decoded video, including temporal and spatial deinterlacing, inverse telecine, and noise reduction. * Defines an API for timestamp-based presentation of final video frames. * Defines an API for compositing sub-picture, on-screen display, and other UI elements. Note that VDPAU does not address content protection. Some highlights/limitations of NVIDIA's current implementation: * Supported on NVIDIA GPUs with the NVIDIA second generation video processors (see the end of this announcement for a complete GPU list). * Currently, only one video stream can be decoded at a time; we hope to lift this restriction eventually. * Available in the 180.06 NVIDIA public beta release: http://www.nvidia.com/object/linux_display_ia32_180.06.html http://www.nvidia.com/object/linux_display_amd64_180.06.html http://www.nvidia.com/object/freebsd_180.06.html http://www.nvidia.com/object/solaris_display_180.06.html The VDPAU support in the NVIDIA 180.06 beta release is still very preliminary. We are aware of cases of visual corruption and in some cases GPU hangs. We will be working on these issues over the next several NVIDIA driver releases. While NVIDIA's VDPAU implementation is not ready for end user use yet, it should be far enough along that interested application developers can begin working with it. Additionally, NVIDIA has developed patches to ffmpeg and MPlayer to demonstrate a video player using VDPAU: ftp://download.nvidia.com/XFree86/vdpau/mplayer-vdpau-3076399.tar.bz2 These patches include changes against libavcodec, libavutil, ffmpeg, and MPlayer itself; they may serve as an example of how to use VDPAU. Once we do some further testing, bugfixing, and cleanup, we will contribute the MPlayer patches to the MPlayer developers. If other hardware vendors are interested, they are welcome to also provide implementations of VDPAU. The VDPAU API was designed to allow a vendor backend to be selected at run time. Thanks, Andy Ritger Manager, NVIDIA Linux Graphics Driver VDPAU is currently supported on the following NVIDIA GPUs: Desktop GPUs: GeForce 200 Series GeForce 9 Series GeForce 86xx Series GeForce 85xx Series GeForce 84xx Series GeForce 8800 GTS 512 GeForce 8800 GT GeForce 8800 GS Mobile GPUs: GeForce 98xxM GeForce 9700M GeForce 96xxM GeForce 9500M GeForce 9300M GeForce 9200M GeForce 8800M GeForce 8800M GTS GeForce 8800M GTX GeForce 8600M Motherboard GPUs: GeForce 9400 GeForce 9300 GeForce 9100 GeForce 8300 GeForce 8200 VC-1 support in NVIDIA's VDPAU implementation currently requires GeForce 9300 GS, GeForce 9200M GS, GeForce 9300M GS, or GeForce 9300M GS. _______________________________________________ xorg mailing list xorg(a)lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg

6 7

Re: [vdr] New Video Decode and Presentation API from NVidia
by Niels Wagenaar 25 Nov '08

25 Nov '08

Op Ma, 24 november, 2008 16:50, schreef VDR User: > On Mon, Nov 24, 2008 at 4:53 AM, Nicolas Huillard <nicolas(a)huillard.net> > wrote: >> It seems that things are really moving, and VDR-HD may finally work with >> cheap hardware by the time HD material is commonplace. > > You must live under a rock if HD content isn't already common where > you live/from your provider! Here is NA there's tons of HD channels, > with many more coming soon. Only, in the US most of the HDTV transports don't use H264. At least, I heard from several people that it's HDTV through MPEG2. Over here (Europe) it's mostly HDTV through H264 (only a very small number of MPEG2 HDTV channels over here). And H264 is the real problem over here and it all comes down to CPU decoding (FFMpeg or CoreAVC for Linux) or by using a device like the Reel HD Extension. Currently I need to use a Core 2 Quad (Q6600 @ 2.40GHz) to get decent and stutter-free H264 decoding using software (FFMpeg SVN, Xine-lib 1.2, Xine-UI and vdr-xine plugin). With my Core 2 Duo (E7300 @ 2.53Ghz) I didn't had enough juice (stuttering, framedrops, etc). That's why I do enjoy all this news about hardware accelerated H264 decoding on the GPU. Most of the motherboards have a GPU with this kind of features, to bad we can't use it in Linux/Xorg :( Regards, Niels Wagenaar

4 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr November 2008