Re: [vdr] [PATCH] RGB/PAL over VGA at variable frame rate

2008-08-14 Thread Gavin Hamill
On Thu, 2008-08-14 at 14:22 +0100, Gavin Hamill wrote: > On Thu, 2008-08-14 at 11:25 +0200, Thomas Hilber wrote: > Oh, aptitude solved the dependencies for me (needed to explicitly downgrade one package, then all was well.) Here's the "vmstat 1" output during mplayer playback... i.e. no madness

Re: [vdr] [PATCH] RGB/PAL over VGA at variable frame rate

2008-08-14 Thread Thomas Hilber
On Thu, Aug 14, 2008 at 02:22:46PM +0100, Gavin Hamill wrote: > [1] [EMAIL PROTECTED]:~# apt-get install xserver-xorg xserver-xorg-core > The following packages have unmet dependencies. > xserver-xorg: Depends: x11-xkb-utils but it is not going to be > installed > PreDepends: x1

Re: [vdr] [PATCH] RGB/PAL over VGA at variable frame rate

2008-08-14 Thread Gavin Hamill
On Thu, 2008-08-14 at 11:25 +0200, Thomas Hilber wrote: Good heavens, this is all getting rather heavyweight :) > oh - a very interesting fact. > that's different to mine (see my output of top below). Xorg takes only 0.7%(!) > CPU on my system. Are there some special patches in ubuntu that causes

Re: [vdr] [PATCH] RGB/PAL over VGA at variable frame rate

2008-08-14 Thread Thomas Hilber
On Thu, Aug 14, 2008 at 10:22:53PM +1000, Torgeir Veimo wrote: > Since you're using the vsync irq in any case, the best solution would > be to notify user space at irq time that it should 'PutImage' a new > frame. I know what you want to say. But according to my understanding xine has it's ow

Re: [vdr] [PATCH] RGB/PAL over VGA at variable frame rate

2008-08-14 Thread Torgeir Veimo
On 14 Aug 2008, at 21:53, Thomas Hilber wrote: > a good idea, but in the case of 'xserver-xorg-video-ati' true hardware > double buffers are supported. If a new PutImage() comes in the DDX > simply > toggles to the other double buffer and starts to write there. No > matter > this buffer ever

Re: [vdr] [PATCH] RGB/PAL over VGA at variable frame rate

2008-08-14 Thread Thomas Hilber
On Thu, Aug 14, 2008 at 01:15:58PM +0300, Petri Hintukainen wrote: > to, 2008-08-14 kello 11:25 +0200, Thomas Hilber kirjoitti: > > Does the Xserver poll for some resources not available or something? > > Maybe the driver is waiting for free overlay buffer ? Some drivers wait > for free hardware o

Re: [vdr] [PATCH] RGB/PAL over VGA at variable frame rate

2008-08-14 Thread Petri Hintukainen
to, 2008-08-14 kello 11:25 +0200, Thomas Hilber kirjoitti: > On Wed, Aug 13, 2008 at 09:09:45PM +0100, Gavin Hamill wrote: > > Xorg process is taking 40% CPU, with vdr taking 25%. The 'system' CPU > > usage is 32%, with 16% for user processes. [...] > Does the Xserver poll for some resources not a

Re: [vdr] [PATCH] RGB/PAL over VGA at variable frame rate

2008-08-14 Thread Jouni Karvo
> On Wed, Aug 13, 2008 at 09:09:45PM +0100, Gavin Hamill wrote: > > >> So, I started looking for other reasons. Whilst X + vdr are running, the >> Xorg process is taking 40% CPU, with vdr taking 25%. The 'system' CPU >> usage is 32%, with 16% for user processes. I thought maybe it was using >>

Re: [vdr] [PATCH] RGB/PAL over VGA at variable frame rate

2008-08-14 Thread Thomas Hilber
On Wed, Aug 13, 2008 at 09:09:45PM +0100, Gavin Hamill wrote: > OK, found a suitable recording, and after a couple of 'play 1 begin' to > SVDRP it starts OK. The picture is pretty good, but it still shifts > around the screen a bit: that's because PLL encounters very large increments of 'sync poin

Re: [vdr] [PATCH] RGB/PAL over VGA at variable frame rate

2008-08-14 Thread Thomas Hilber
On Thu, Aug 14, 2008 at 08:50:43AM +0300, Jouni Karvo wrote: > your trick is the VGA->SCART cable. I was using the TVout from the > card. I have ordered the components for the cable, and I hope I'll be > able to solder them together during the weekend. I hope I can then > reproduce your succe

Re: [vdr] OT: Finnish Yle HD olympics channel..

2008-08-14 Thread Theunis Potgieter
When I started to convert my vdr recordings to h264 using ffmpeg -vcodec libx264. I saw that running it without -threads or with -threads set to 2, it used the same cpu usage. When I changed it to -threads 3 I started to see more than 100% usage. Perhaps decoding should also use -threads 3 to see i