vdr

vdr@linuxtv.org

6731 discussions

[ANNOUNCE] vdr-sudoku-0.3.2
by Thomas Günther 28 Sep '08

28 Sep '08

Hi! There is a new version of the Sudoku plug-in. Download: http://toms-cafe.de/vdr/sudoku/vdr-sudoku-0.3.2.tgz Changes since version 0.3.2: - Updated French language texts (thanks to NIVAL Michaël). 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

RGB/PAL over VGA at variable frame rate
by Thomas Hilber 27 Sep '08

27 Sep '08

Hi list, the last few days I made some interesting experiences with VGA cards I now want to share with you. goal ---- develop a budget card based VDR with PAL/RGB output and FF like output quality problem ------- as we all know current VGA graphics output quality suffers from certain limitations. Graphics cards known so far operate at a fixed frame rate not properly synchronized with the stream. Thus fields or even frames do often not appear the right time at the ouput. Some are doubled others are lost. Finally leading to more or less jerky playback. To a certain degree you can workaround this by software deinterlacing. At the cost of worse picture quality when playing interlaced material. Also CPU load is considerably increased by that. It appeared to be a privilege of so called full featured cards (expensive cards running proprietary firmware) to output true RGB PAL at variable framerate. Thus always providing full stream synchronicity. I've always been bothered by that and finally started to develop a few patches with the goal in mind to overcome these VGA graphics limitations. solution -------- graphics cards basically are not designed for variable frame rates. Once you have setup their timing you are not provided any means like registers to synchronize the frame rate with external timers. But that's exactly what's needed for signal output to stay in sync with the frame rate provided by xine-lib or other software decoders. To extend/reduce the overall time between vertical retrace I first dynamically added/removed a few scanlines to the modeline but with bad results. By doing so the picture was visibly jumping on the TV set. After some further experimenting I finally found a solution to fine adjust the frame rate of my elderly Radeon type card. This time without any bad side effects on the screen. Just trimming the length of a few scanlines during vertical retrace period does the trick. Then I tried to implement the new functionality by applying only minimum changes to my current VDR development system. Radeon DRM driver is perfectly suited for that. I just had to add a few lines of code there. I finally ended up in a small patch against Radeon DRM driver and a even smaller one against xine-lib. The last one also could take place directly in the Xserver. Please see attachments for code samples. When xine-lib calls PutImage() it checks whether to increase/decrease Xservers frame rate. This way after a short adaption phase xine-lib can place it's PutImage() calls right in the middle between 2 adjacent vertical blanking intervals. This provides maximum immunity against jitter. And even better: no more frames/fields are lost due to stream and graphics card frequency drift. Because we now cease from any deinterlacing we enjoy discontinuation of all its disadvantages: If driving a device with native interlaced input (e.g. a traditional TV Set or modern TFT with good RGB support) we have no deinterlacing artifacts anymore. Since softdecoders now are relieved of any CPU intensive deinterlacing we now can build cheap budget card based VDRs with slow CPUs. Please find attached 2 small patches showing you the basic idea and a description of my test environment. The project is far from complete but even at this early stage of development shows promising results. It should give you some rough ideas how to recycle your old hardware to a smoothly running budget VDR with high quality RGB video output. some suggestions what to do next: - detection of initial field parity - faster initial frame rate synchronisation after starting replay - remove some hard coded constants (special dependencies on my system's timing) Some more information about the project is also available here http://www.vdr-portal.de/board/thread.php?threadid=78480 Currently it's all based on Radeons but I'll try to also port it to other type of VGA cards. There will be some updates in the near future. stay tuned. -Thomas

15 83

mplayer plugin issue w h.264 files
by Torgeir Veimo 27 Sep '08

27 Sep '08

Am trying to set up the mplayer plugin to playback h.264 files encoded with handbrake on a FF card. I am getting the error Forced video codec: mpegpes Cannot find codec matching selected -vo and video format 0x31637661. with mplayer. The problem is not strictly with the plugin as I get the same error if I issue the mplayer command directly, eg; mplayer -vo mpegpes:card=2 -ao mpegpes:card=2 -vc mpegpes /video/ movies/LETTERS_FROM_IWO_JIMA-1.m4v -vf scale=512:576 I get audio out over the FF card. Here's a bit more log output; Playing /video/movies/LETTERS_FROM_IWO_JIMA-1.m4v. ISO: File Type Major Brand: ISO/IEC 14496-1 (MPEG-4 system) v2 Quicktime/MOV file format detected. [mov] Video stream found, -vid 0 [mov] Audio stream found, -aid 1 [mov] Subtitle stream found, -sid 2 VIDEO: [avc1] 480x208 24bpp 25.000 fps 0.0 kbps ( 0.0 kbyte/s) Opening /dev/dvb/adapter1/video0+audio0 Opening video filter: [scale w=512 h=576] = = ======================================================================== Forced video codec: mpegpes Cannot find codec matching selected -vo and video format 0x31637661. Read DOCS/HTML/en/codecs.html! = = ======================================================================== = = ======================================================================== Opening audio decoder: [faad] AAC (MPEG2/4 Advanced Audio Coding) AUDIO: 48000 Hz, 2 ch, s16le, 128.0 kbit/8.33% (ratio: 15995->192000) Selected audio codec: [faad] afm: faad (FAAD AAC (MPEG-2/MPEG-4 Audio) decoder) = = ======================================================================== Opening /dev/dvb/adapter1/audio0 AO: [mpegpes] 48000Hz 2ch s16be (2 bytes per sample) Video: no video Starting playback... A: 2.0 (02.0) of 8086.7 ( 2:14:46.6) 1.5% [root@htpc bin]# mplayer --version MPlayer 1.0rc2-4.3.0 (C) 2000-2007 MPlayer Team CPU: Intel(R) Pentium(R) M processor 1.73GHz (Family: 6, Model: 13, Stepping: 8) CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1 [root@htpc bin]# mplayer -vo help | grep mpegpes mpegpes Mpeg-PES to DVB card Any ideas how to resolve this? I get the same problem trying playback of avi files as well. -- Torgeir Veimo torgeir(a)pobox.com

1 1

Re: [vdr] [v4l-dvb-maintainer] [Wanted] dvb-ttpci maintainer
by Oliver Endriss 26 Sep '08

26 Sep '08

hermann pitton wrote: > Except of course a majority of plumbers at the same place at the same > time can create/propose some facts. IMO decisions must be made where the community is, i.e. on the mailing list. Not at a conference, no matter whether it is at one end of the world or on the dark side of the moon. ;-( To make it absolutely clear: I did not leave _because_ S2API was selected. I left because it was done _this_way_. Good for those, who are fine with these methods. I am not. > If you attack people such hard as Manu did, also behind the visible > lines sometimes, Marcel had a copy from me concerning Mauro and did say > nothing, you must not wonder about people starting to defend themselves. I consider flame wars ridiculous. I did not participate, and I will not participate in the future. I believe that I know very well what is going on. (During more than 30 years in software development I have seen all kinds of problems. I know how people react and why things happen.) > For sure the dirt was not started from v4l people. > > Think it over. Unlikely. I made this decision after sleeping over it for a few days. Now I feel much better. Oliver -- ---------------------------------------------------------------- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ ----------------------------------------------------------------

3 3

[Wanted] dvb-ttpci maintainer
by Oliver Endriss 26 Sep '08

26 Sep '08

Hi, due to the way S2API was pushed through (I would call it a plot) there is not much motivation left to spend my time with DVB. So - if someone wants to take over the dvb-ttpci drivers he should speak up now. The sooner the better. Oliver -- ---------------------------------------------------------------- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ ----------------------------------------------------------------

2 2

Re: [vdr] [v4l-dvb-maintainer] [Wanted] dvb-ttpci maintainer
by Oliver Endriss 25 Sep '08

25 Sep '08

hermann pitton wrote: > > Am Mittwoch, den 24.09.2008, 19:22 +0200 schrieb Oliver Endriss: > > Hi, > > > > due to the way S2API was pushed through (I would call it a plot) > > there is not much motivation left to spend my time with DVB. > > > > So - if someone wants to take over the dvb-ttpci drivers he should speak > > up now. The sooner the better. > > Oliver, > > you and Manu still stand for dvb with highest respect from _all_ I know > about. > > And for all I know else, maybe I know nothing, this was for sure not a > plot. > > Except of course a majority of plumbers at the same place at the same > time can create/propose some facts. No. They can discuss/propose anything they like, but 8 people don't have any right to make decisions. (This is why I call it a plot.) There are basic democratic rules which must be followed in a community: (1) Make a proposal (2) Discuss the proposal (3) Finally, _after_ the discussion: A poll to find a decision. > ... > Think it over. Well, I had enough time to think about it... Oliver -- ---------------------------------------------------------------- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ ----------------------------------------------------------------

5 4

Re: [vdr] [linux-dvb] [v4l-dvb-maintainer] [Wanted] dvb-ttpci maintainer
by Manu Abraham 25 Sep '08

25 Sep '08

Halim Sahin wrote: > Hi, > On Do, Sep 25, 2008 at 12:54:58 +0200, Oliver Endriss wrote: >> There are basic democratic rules which must be followed in a community: >> >> (1) Make a proposal > > Yes We have multiproto, since 2006. > > >> (2) Discuss the proposal > > Was done since 2006 > >> (3) Finally, _after_ the discussion: A poll to find a decision. > > Great thing. Why was multiproto not merged after your code review > november 2007???? > > I thing Manu wanted to do the s2 stuff himself and did not accept > any community help. http://lwn.net/Articles/297301/ API and core related patches: 31 + 1 patches, total 32 in all. http://www.kernel.org/pub/linux/kernel/people/manu/dvb_patches/ The people who contributed some way or the other (in the final stages): on the API changes alone. (Not mentioning about the people who initially provided many comments.) Marco Schluessler <marco(a)lordzodiac.de> Arvo Jarve <arvo(a)softshark.ee> Reinhard Nissl <rnissl(a)gmx.de> Oliver Endriss <o.endriss(a)gmx.de> Anssi Hannula <anssi.hannula(a)gmail.com> These folks on a whole, contributed to ~14 of the patches. > Yes I read most of the old mails from last year. > In most cases Manu wrote that multiproto is not ready. > The fact is, that many people are using (not ready multiproto stuff) > since two years. After the code review, it was left for testing. Thanks to the VDR community/Klaus for providing support for the same, so it could be tested in real life. As you can see quite some of the changes came during the test phase, as you can see from the timestamps in the multiproto tree. Regards, Manu

1 0

[Announce] svdrpservice-0.0.4
by Frank Schmirler 25 Sep '08

25 Sep '08

Hi there, a new release of the svdrpservice-Plugin is available from http://vdr.schmirler.de HISTORY 0.0.4 - Italian translation (thanks to Diego Pierotto) - Commandline parameter for default server IP and port (suggested by kris@vdrportal) - Automatic charset conversion (suggested by skiller2k1@vdrportal) Includes patches for VDR < 1.6.1 to make it report its charset in the SVDRP greeting message - Gettext support for VDR 1.5.7+ Credits to Udo Richter for his po218n.pl backward compatibility script - Accept empty responses (status code + space character) - No longer strip trailing whitespace from responses - Configurable timeouts ** What is the svdrpservice-plugin all about? It's a little helper used by a couple of other plugins (e.g. remotetimers and remoteosd) to contact an other VDR using SVDRP. So it doesn't make sense to install svdrpservice as long as no other plugin requires it. ** Some notes on the new charset conversion feature If two connected VDRs are using different charsets (e.g. a VDR 1.6 with UTF-8 and a VDR 1.4 with ISO-8859-15), svdrpservice will do an on-the-fly conversion. However the server must report the charset it uses or otherwise svdrpservice won't convert. Since VDR 1.6.0-2 and 1.7.1 the charset is included in the SVDRP greeting message. In the patches subdirectory of the plugin sources you will find patches for older VDRs (affects only a single line). Note that you don't need to patch the client VDR (i.e. the one running svdrpservice). Let me give you an example: - Server VDR running 1.6.0-2, client VDR running 1.4.7: You're all fine. No patch required - Server VDR running 1.4.7, client VDR running 1.6.0-2: You need to patch the server VDR here ** What bugs will be fixed by svdrpservice-0.0.4 - A remoteosd connection aborted whenever a menu with empty title was opened (e.g. extrecmenu plugin) - The name of a recording as returned by the SVDRP command LSTR may end with a space character. Previous svdrservice versions stripped that off. Some features of remotetimers 0.1.0 (not released yet) will fail on these recordings if an old svdrpservice version is running. Enjoy, Frank

1 0

Re: [vdr] [linux-dvb] [Wanted] dvb-ttpci maintainer
by Oliver Endriss 25 Sep '08

25 Sep '08

Goga777 wrote: > Oliver Endriss wrote: > > So - if someone wants to take over the dvb-ttpci drivers he should speak > > up now. The sooner the better. > > ah, it's very pity :( > > will you stay with VDR project ? Sure. Oliver -- ---------------------------------------------------------------- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ ----------------------------------------------------------------

1 0

Re: [vdr] [linux-dvb] [v4l-dvb-maintainer] [Wanted] dvb-ttpci maintainer
by Torgeir Veimo 25 Sep '08

25 Sep '08

This whole issue seems to be a classical case of tension during a cathedral to bazar development style project transition. -- Torgeir Veimo torgeir(a)pobox.com

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr