vdr September 2008

vdr@linuxtv.org

88 participants
88 discussions

FW: [ANNOUNCE] DVB API improvements
by Niels Wagenaar 28 Sep '08

28 Sep '08

Hello all (and especially Klaus): It's official, the people from V4L have voted for the usage of the S2API proposal to be the future for new DVB API improvements (see the official announcement at the bottom) within the V4L tree. Currently S2API is in a real speed-train and new devices are added very rapidly. Only the devices currently in Multiproto and written by Manu Abraham are not yet ported. Also people are allready busy with patches for Kaffeine (allready done) and MythTV (not seen yet, but it's WIP according to a post on the linux-dvb mailinglist). So, this should mean that VDR 1.7.x should focus on S2API because of the obvious reasons. Has anybody started on a patch of somekind to include S2API in VDR 1.7.0 or 1.7.1? Mainly I was thinking of doing it myself (I have a Hauppauge WinTV-NOVA-HD-S2 which is allready supported in S2API) in the hope to have it working in the next weekend. But if it's allready done or in progress, then I would like to use my time for something else ;) Regards, Niels Wagenaar -----Original message----- From: Mauro Carvalho Chehab <mchehab(a)infradead.org> Sent: Tue 23-09-2008 23:19 To: DVB ML <linux-dvb(a)linuxtv.org>; Subject: [linux-dvb] [ANNOUNCE] DVB API improvements > After years of discussions, several patch series and two different proposed > approaches, LinuxTV developers finally decided that S2API is the better > technical proposal and should be accepted as the way to allow supporting newer > DTV standards, starting with DVB-S2. > > As previously announced at http://linuxtv.org/news.php?entry=2008-09-19.mchehab, > a representative group of active developers at LinuxTV community attended the > first V4L/DVB Summit, that started with the V4L/DVB miniconf at Linux > Plumbers/2008. Several other additional formal (BOF's) and informal meetings > happened there, in the benefit of the improvement of the development of > multimedia drivers and core. > > During the miniconf, both Multiproto API (proposed by Manu) and S2API (proposed > by Steven), were presented. A technical discussion was made during the DVB BOF > session in order to compare the two proposals and check for the > need/convenience of other core internal changes to draw an evolution timeline > for DVB. > > The DVB BOF had the presence of the following LinuxTV members: > > Douglas Schilling Landgraf > Hans Verkuil > Mauro Carvalho Chehab > Michael Krufky > Patrick Boettcher > Steven Toth > Thierry Merle > Manjunath Hadlii > > We had also a presence of an end-user listening to the BOF (Brandon Fouts). > > During the BOF, the LinuxTV members carefully analyzed the pros and cons for > both proposals. At the end, all people present there agreed that S2API is > technically more reliable in time than Multiproto proposal. So it was decided > that S2API will be merged upstream. > > The main arguments in favor of S2API over Multiproto are: > > - Future proof – the proposal for S2API is more flexible, easily > allowing the addition of newer features and new standard support; > > - Simplicity – S2API patches are very simple, while Multiproto > presented a very complex series of changes. Simpler approaches > reduces the time for maintaining the source code; > > - Capability of allowing improvements even on the existing standards, > like allowing diversity control that starts to appear on newer DVB > devices. > > Some improvements were proposed by the LinuxTV developers, in order to improve > the S2API, including: > > - Adding an API command for querying DVB version, to allow an easier > detection by userspace applications; > > - Name the DVB API with S2API as DVB version 5; > > - Update DVB API documentation to reflect the API changes; > > - Remove from DVB API the unused API ioctls, to match the API with the > existing implementations. > > The author of S2API got the task of adding those suggestions at the proposed > standard and send a pull request to the subsystem maintainer, together with > patches for his drivers that use the newer API. > > It was also discussed that some of the internal Multiproto API changes may be > needed in other to support some of the other existing DVB-S2 drivers that were > developed considering Multiproto API. Internal changes can be added at any time > without producing problems in the user API. > > The group aims to have a unified in-kernel DVB-S2 HVR4000 / TT-3200 tree (that > also supports all of the derivative CX24116 / STB0899 known products) within 4 > weeks from the announcement, hopefully in time for kernel 2.6.28. For that, we > would like to ask Manu to port his drivers to the new API. > > The end goal is to add proper support for all devices that would have been > supported by multiproto and S2API alike available. > > There are already volunteers working or that have offered to work on Kaffeine > and MythTV S2API support. > > We still need volunteers to work on dvb-apps support. If you feel that you like > contribute, please be our guest! > > We would like to thank you all that contributed for those discussions and > improvements to happen, > > Mauro Carvalho Chehab > V4L/DVB Maintainer >

6 7

eHD & Micronas DeCypher
by Goga777 28 Sep '08

28 Sep '08

Hi which exact name of Micronas decoder in eHD card ? is it - DeCypher DHM8100A ? http://www.micronas.com/products/application/MicRacer/index.html Goga

2 1

new reel hd pci-e card; vAti 2400 pro Mobility
by Torgeir Veimo 28 Sep '08

28 Sep '08

There's a new reel HD pci-e card available, see http://vdrportal.de/board/thread.php?threadid=80489&sid=ef2e2bfeb189c6808c2… and http://www.reel-multimedia.com/de/shop_extension_hd.php It's apparently an ATI vAti 2400 pro Mobility card, and in the thread at vdrportal.de it's stated that linux drivers will follow in October. Does anyone know if this driver will support h.264 decoding in linux with this card? -- Torgeir Veimo torgeir(a)pobox.com

3 3

[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

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr September 2008