Re: [vdr] Xineliboutput: can achieve similar to softdevice's mgatv option?
On Tue, 2007-05-22 at 23:27 +0100, Alasdair Campbell wrote: On 21/04/07, Petri Hintukainen [EMAIL PROTECTED] wrote: 2) unscaled OSD: OSD and video are mixed by hardware using either colorkeying (no opacity) or hardware RGBA layer. OSD and video can be of different size and OSD can be blended outside of video frame. OSD size is constant (fbdev primary layer size, most likely 720x576). Xine-lib directfb driver supports method 2) for only some hardware with ARGB blending capacity. For the rest method 1) is used. I have experimental patch to support colorkeying mode when hardware does not support separate ARGB OSD layer, I just need to adjust it for recent xine-libs. I was wondering if you'd had a look at the patch you mentioned. I'd happily lose osd opacity in favour of a consistant look to my vdr experience - maybe others would too. I actually struggle to read some of the text with low resolution channels. Yes, patch against xine-lib 1.1.6 is available from http://phivdr.dyndns.org/xine-lib/directfb/ - Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Xineliboutput: can achieve similar to softdevice's mgatv option?
On 25/05/07, Petri Hintukainen [EMAIL PROTECTED] wrote: Yes, patch against xine-lib 1.1.6 is available from http://phivdr.dyndns.org/xine-lib/directfb/ Thanks so much for that! I'll be able to try it over the weekend and I'll let you know how I get on. many thanks -- A l a s d a i r C a m p b e l l r a g a w u @ g m a i l . c o m ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Xineliboutput: can achieve similar to softdevice's mgatv option?
On Sunday 22 April 2007 22:47:40 Petri Hintukainen wrote: Well, this changes are more than 7 month old, maybe there have been some changes to DirectFB to make it work in the meanwhile... As far as I saw it's only a two line patch, so I could try to manually revert it and compile xine-lib again... [..} Yes, changing it to #if 1 should be enough. If you are using tv-out and don't see any video after the change, problem is still there :) OK, then the problem is still there :) I'm using tv-out (crtc2) and video output is just black; sound is ok. Greetings, Markus pgp2YwK6VcFMn.pgp Description: PGP signature ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Xineliboutput: can achieve similar to softdevice's mgatv option?
On 21/04/07, Petri Hintukainen [EMAIL PROTECTED] wrote: On Fri, 2007-04-20 at 19:21 +0100, Alasdair Campbell wrote: I'll have a look at the softdevice src this weekend compare with xineliboutput. Better to compare with xine-lib (src/video_out/video_out_directfb.c), as there's not even single line of directfb code in xineliboutput :) Xine-lib DirectFB unscalded OSD (hardware alpha blending) is currently disabled for some matrox cards because of problems with tv-out. See notes on revisions 1.40 and 1.42 at http://xine.cvs.sourceforge.net/xine/xine-lib/src/video_out/video_out_directfb.c?view=log (so, unscaled OSD might work with xine-lib 1.1.2 (?) and recent DirectFB (?)). I tried to give xine-lib1.1.2-r3 a go today but after rebuilding xineliboutput against xine-libs., I still receive the message [12674] [input_vdr] WARNING: Video output driver reports it does not support unscaled overlays ! - so maybe I need an older version of xine-lib?? Unfortunatly that version is as far back as I can go with gentoo, perhaps somebody with better skills could test an older version still. Theres a chance I made a mess of trying out the older xine-lib as now I have no video just sound :-) good thing my girlfriend is out for the day...! -- A l a s d a i r C a m p b e l l r a g a w u @ g m a i l . c o m ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Xineliboutput: can achieve similar to softdevice's mgatv option?
On 21/04/07, Markus Schuster [EMAIL PROTECTED] wrote: Well, this changes are more than 7 month old, maybe there have been some changes to DirectFB to make it work in the meanwhile... As far as I saw it's only a two line patch, so I could try to manually revert it and compile xine-lib again... Worth a go? :) I'd volunteer but I don't trust myself.. -- A l a s d a i r C a m p b e l l r a g a w u @ g m a i l . c o m ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Xineliboutput: can achieve similar to softdevice's mgatv option?
On Sat, 2007-04-21 at 23:30 +0200, Markus Schuster wrote: (Well, another possibility would be upscaling video in software). Does upscaling really have to be done in software? Excuse my (maybe?) stupid question but as far as I know video scaling can be done by a backend scaler in hardware? Am I completely off here? If video is upscaled by hardware, it is typically impossible to access the upscaled video (and software-blend OSD over it). So, if OSD is not blended by HW and video is not upscaled in SW, OSD must be downscaled to video resolution. 2) unscaled OSD: OSD and video are mixed by hardware using either colorkeying (no opacity) or hardware RGBA layer. OSD and video can be of different size and OSD can be blended outside of video frame. OSD size is constant (fbdev primary layer size, most likely 720x576). OK, this sounds like the way to go :) Definetely the best way. It has best quality and does not add much overhead as everyting is done by HW. Well, this changes are more than 7 month old, maybe there have been some changes to DirectFB to make it work in the meanwhile... As far as I saw it's only a two line patch, so I could try to manually revert it and compile xine-lib again... Does the line setting 'colors[index].a' have something to do with disabling hardware alpha blending on matrox cards (according to the diff from version 1.41 to 1.42)? In my eys only the '#if 0' and '#endif' should be relevant. Yes, changing it to #if 1 should be enough. If you are using tv-out and don't see any video after the change, problem is still there :) I have experimental patch to support colorkeying mode when hardware does not support separate ARGB OSD layer, I just need to adjust it for recent xine-libs. Maybe worth a try? Yes. But you'll lose OSD transparency. And there may be flickering problems with some hardware when clearing OSD (at least there are when using X11). I haven't seen that myself with Intel+X11 or NVidia +DirectFB, so it must be related to X and/or X drivers (?). You should use --aspect=4:3 option with vdr-fbfe (or if you are not using vdr-fbfe, select 4:3 aspect ratio from plugin setup menu - Local frontend - Aspect ratio). I have tried this already. I'm not using vdr-fbfe (wanted to keep things easy at the beginning) so I changed that directly in the plugins setup options. But it doesn't make any difference here... Do I have to restart vdr to make this setting work (haven't tried yet)? You should see image scaling changed immediately when you change aspect ratio with left or right key (and you have to close menu with Ok for changes to be saved). Maybe you need to enable video scaling (scale video to window) too. - Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Xineliboutput: can achieve similar to softdevice's mgatv option?
On 20 Apr 2007, at 19:21, Alasdair Campbell wrote: I'll have a look at the softdevice src this weekend compare with xineliboutput. Why aren't you just using softdevice? -- Torgeir Veimo [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Xineliboutput: can achieve similar to softdevice's mgatv option?
On 21 Apr 2007, at 11:37, Torgeir Veimo wrote: On 20 Apr 2007, at 19:21, Alasdair Campbell wrote: I'll have a look at the softdevice src this weekend compare with xineliboutput. Why aren't you just using softdevice? Ignore my question, I hadn't read the full thread.. Saturday morning hungover.. -- Torgeir Veimo [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Xineliboutput: can achieve similar to softdevice's mgatv option?
On 21/04/07, Tony Houghton [EMAIL PROTECTED] wrote: In [EMAIL PROTECTED], Alasdair Campbell wrote: Because I'm using a 550Mhz P3, my only option is to use the xineliboutput until I figure out what is causing the big CPU load variations. As I've never had softdevice successfully running on this television, I can't really say anything about it's quality, though I know there's been lots of work in respect to the matrox cards. Another alternative is to use the other vdr xine plugin with df_xine, which gives very good results with my Matrox (G450). About the only problem is that it sometimes doesn't scale the OSD correctly, chopping off the right hand side. Something to do with 16:9 vs 4:3 I'm sure. And I'm seeing something similar to that with More4 other less popular channels on UK DVB-T. The lower resolution or incorrect imprinted aspect ratio causes the OSD to zoom to the left two thirds, with the right third off screen. As this only happens on one or two channels that I watch, It's not bothering me too much. xineliboutput is exactly what I need at the moment, with my headless recording server and one streaming client - I wanted to control the server osd directly for now. I don't know whether it can handle letterboxing an interlaced 16:9 picture for a 4:3 TV. I heard that softdevice gets, or used to get that wrong, as if it treated the two fields as one frame and scaled them together, rather than scaling each field separately. Maybe the hardware doesn't support the latter, in which case it would have to use slow software scaling. When I was using softdevice I had a 4:3 TV, but wanted to view 16:9 content in full (so with black horizontal bars above and below video). With this setup, interlaced video would show artifacts. I believe that's been fixed by the kind softdevice guys. My experience with softdevice was that the A/V sync was a bit off for live TV and way off for recordings. df_xine is spot on. If you want to be able to stop/start df_xine and/or watch other videos all with one remote control you can use boxstar as a front-end. I had issues with audio sync with softdevice too, can't really say how it deals now, as I'm underpowered. So boxstar will give me direct control over VDR similar to xineliboutput? I hadn't realised that. At the moment I'm not looking to change my setup, just tweak what I have :-) (Sorry if the formatting on this email is all wrong, I'm writing this with lynx on the console, as my laptop is without X at the moment...) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Xineliboutput: can achieve similar to softdevice's mgatv option?
On 21/04/07, Petri Hintukainen [EMAIL PROTECTED] wrote: On Fri, 2007-04-20 at 19:21 +0100, Alasdair Campbell wrote: I'll have a look at the softdevice src this weekend compare with xineliboutput. Better to compare with xine-lib (src/video_out/video_out_directfb.c), as there's not even single line of directfb code in xineliboutput :) Xine-lib DirectFB unscalded OSD (hardware alpha blending) is currently disabled for some matrox cards because of problems with tv-out. See notes on revisions 1.40 and 1.42 at http://xine.cvs.sourceforge.net/xine/xine-lib/src/video_out/video_out_directfb.c?view=log (so, unscaled OSD might work with xine-lib 1.1.2 (?) and recent DirectFB (?)). - Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr -- A l a s d a i r C a m p b e l l r a g a w u @ g m a i l . c o m ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Xineliboutput: can achieve similar to softdevice's mgatv option?
On 20/04/07, Markus Schuster [EMAIL PROTECTED] wrote:
Am Donnerstag, 19. April 2007 15:06:54 schrieb Alasdair Campbell:
config_xineliboutput
# field parity
# { none top bottom }, default: 0
#video.device.directfb_field_parity:none
That's funny, my config_xineliboutput doesn't have this config option per
default...
But I can insert it and when set to 'top' video quality is quite awesome, but
there are still some small hickups and stutters here and there (even with
vsync set to 1). Maybe some other settings are still missing, that softdevice
sets...
I've noticed problems with a couple of music video channels where
there's an effect similar to a stuck CD, surely related to field sync
but probably down to poorly transmitted content. I'm not experiencing
any problems with my favourite channels.
With Bloomberg (German news/stock channel) I see a very odd behavior: To have
to video itself fullscreen, I have to enable local frontend scaling but then
the OSD is renderd much too big. So I have to enable OSD resizing/downscaling
which results in a very unnice OSD (fonts look a bit ugly and the complete
OSD is not the nicest view.).
And channels broadcasting a 16:9 signal are always scaled up to my 4:3 CRT TV,
so I have the typical 'long faces' (I think that's only a configuration
setting, but I haven't been able to locate it...)
My experiences with a 16:9 TV are different but theres some issues
with scaling OSD that I would like to fix..
I don't want 4:3 content to stretch to my widescreen tv, so I set
Video Crop letterbox 4:3 to 16:9 - NO
OSD Everything here is set to NO or OFF
This isn't a bad setup, with 4:3 content, the OSD area shrinks
horizontally to 4:3 ratio, but the text stays nice and clear - I
noticed that any scaling of the OSD results in quite poor text.
However :-), I would prefer it if the OSD stayed at 16:9 resolution
all the time, with just the video layer beneath changing per content
aspect ratio. I'm not sure how I could cause this, or even it it's
possible with the framebuffer.
I'm currently not in a productive environment (that runs with a FF and VDR
1.26 :)) with software decoding, but from what I can say so long, using
DirectFB and the Matrox G450s TV-Out, softdevice is my personal favorite! I
think xineliboutput doesn't earn it's high version number in this 'special'
configuration.
BUT I have to admit that xineliboutput uses only half of the CPU power of
softdevice, so it's video decoder has to be more efficient...
Because I'm using a 550Mhz P3, my only option is to use the
xineliboutput until I figure out what is causing the big CPU load
variations. As I've never had softdevice successfully running on this
television, I can't really say anything about it's quality, though I
know there's been lots of work in respect to the matrox cards.
all the best,
--
A l a s d a i r C a m p b e l l
r a g a w u @ g m a i l . c o m
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Xineliboutput: can achieve similar to softdevice's mgatv option?
On Friday 20 April 2007 20:50:16 Alasdair Campbell wrote: My experiences with a 16:9 TV are different but theres some issues with scaling OSD that I would like to fix.. Maybe it's just a config-problem, at least it's a bit non-intuitive :) I noticed that any scaling of the OSD results in quite poor text. Yes, that's also my experience so far. However :-), I would prefer it if the OSD stayed at 16:9 resolution all the time, with just the video layer beneath changing per content aspect ratio. I'm not sure how I could cause this, or even it it's possible with the framebuffer. It has to be possible *somehow*, 'cause softdevice works here (on a 4:3 CRT TV) without any scaling problems, OSD has always the correct size and 16:9 content has the typical black borders on the top and the bottom... To bad I don't have a 16:9 TV available here... Because I'm using a 550Mhz P3, my only option is to use the xineliboutput until I figure out what is causing the big CPU load variations. Yes, a big plus for xineliboutput... As I've never had softdevice successfully running on this television, I can't really say anything about it's quality, though I know there's been lots of work in respect to the matrox cards. I think this comes from the fact that AFAIK at least one of the softdevice coders uses a Matrox G550 for video output ;) Greetings, Markus pgpo014S3uaXX.pgp Description: PGP signature ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Xineliboutput: can achieve similar to softdevice's mgatv option?
In [EMAIL PROTECTED], Alasdair Campbell wrote: On 20/04/07, Markus Schuster [EMAIL PROTECTED] wrote: BUT I have to admit that xineliboutput uses only half of the CPU power of softdevice, so it's video decoder has to be more efficient... Odd, because xine also uses ffmpeg. Perhaps it has a more efficient decoder for MPEG 2 and uses ffmpeg only for more exotic formats. Because I'm using a 550Mhz P3, my only option is to use the xineliboutput until I figure out what is causing the big CPU load variations. As I've never had softdevice successfully running on this television, I can't really say anything about it's quality, though I know there's been lots of work in respect to the matrox cards. Another alternative is to use the other vdr xine plugin with df_xine, which gives very good results with my Matrox (G450). About the only problem is that it sometimes doesn't scale the OSD correctly, chopping off the right hand side. Something to do with 16:9 vs 4:3 I'm sure. And I don't know whether it can handle letterboxing an interlaced 16:9 picture for a 4:3 TV. I heard that softdevice gets, or used to get that wrong, as if it treated the two fields as one frame and scaled them together, rather than scaling each field separately. Maybe the hardware doesn't support the latter, in which case it would have to use slow software scaling. My experience with softdevice was that the A/V sync was a bit off for live TV and way off for recordings. df_xine is spot on. If you want to be able to stop/start df_xine and/or watch other videos all with one remote control you can use boxstar as a front-end. -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Xineliboutput: can achieve similar to softdevice's mgatv option?
On Fri, 2007-04-20 at 03:27 +0200, Markus Schuster wrote: With Bloomberg (German news/stock channel) I see a very odd behavior: To have to video itself fullscreen, I have to enable local frontend scaling but then the OSD is renderd much too big. So I have to enable OSD resizing/downscaling which results in a very unnice OSD (fonts look a bit ugly and the complete OSD is not the nicest view.). Probably channel uses smaller resolution than VDR OSD (720x576). There are two methods for OSD blending: 1) scaled OSD: OSD is blended to each video frame in software. Because of this OSD size and resolution can't exeed video size/resolution, and OSD can't be drawn outside of video frame (=those black bars resulting from hardware scaling when fitting 4:3 video to 16:9 display or opposite). If video is lower resolution than OSD, OSD must be cropped or downscaled. (Well, another possibility would be upscaling video in software). 2) unscaled OSD: OSD and video are mixed by hardware using either colorkeying (no opacity) or hardware RGBA layer. OSD and video can be of different size and OSD can be blended outside of video frame. OSD size is constant (fbdev primary layer size, most likely 720x576). Xine-lib directfb driver supports method 2) for only some hardware with ARGB blending capacity. For the rest method 1) is used. I have experimental patch to support colorkeying mode when hardware does not support separate ARGB OSD layer, I just need to adjust it for recent xine-libs. And channels broadcasting a 16:9 signal are always scaled up to my 4:3 CRT TV, so I have the typical 'long faces' (I think that's only a configuration setting, but I haven't been able to locate it...) You should use --aspect=4:3 option with vdr-fbfe (or if you are not using vdr-fbfe, select 4:3 aspect ratio from plugin setup menu - Local frontend - Aspect ratio). - Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Xineliboutput: can achieve similar to softdevice's mgatv option?
On 19/04/07, Torgeir Veimo [EMAIL PROTECTED] wrote: On 19 Apr 2007, at 09:41, Alasdair Campbell wrote: In the original post I was just wondering if xineliboutput has been written with the matrox specific instructions that softdevice's -vo dfb:mgatv uses. As I don't understand the difference between -vo dfb: -vo dfb:mgatv I can't really say what difference this would make. I belive this is entirely dependent on what xine instance you're using with xinelib. Are you using df_xine? I think it should handle field parity correctly. I'm firing up df_xine now to see if there's any similarity. OK, playing a copy of some interlaced video with scrolling text (BBC News 24). Using df_xine -a 5:4 -l 0 -s -f top 001.vdr I get perfect output! This is what Markus and I are seeing for a few seconds before the field sync gets screwed With df_xine -a 5:4 -l 0 -s -f bottom 001.vdr The output is constantly like the stuttering video we're seeing most of the time. So somehow xineliboutput is losing field sync, should be a simple fix then... :-) Needless to say I have no audio, buts it just a configuration problem at my end. -- A l a s d a i r C a m p b e l l r a g a w u @ g m a i l . c o m ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Xineliboutput: can achieve similar to softdevice's mgatv option?
On Thu, 2007-04-19 at 12:53 +0100, Alasdair Campbell wrote: Using df_xine -a 5:4 -l 0 -s -f top 001.vdr I get perfect output! This is what Markus and I are seeing for a few seconds before the field sync gets screwed With df_xine -a 5:4 -l 0 -s -f bottom 001.vdr The output is constantly like the stuttering video we're seeing most of the time. There should be similar setting in $HOME/.xine/config_xineliboutput (search for video.device.directfb_field_parity) - Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Xineliboutput: can achieve similar to softdevice's mgatv option?
Sorry for replying to myself, but in the meantime, while waiting for xineliboutput to work again, anyone reading know if I can use df_xine for the video display, while retaining xineliboutput as the lirc transport to my headless server running vdr-xineliboutput. ** I know there has been a tremendous amount of work from everyone in respect to Matrox TV-Out already, sorry to keep bugging you all ;-) ** -- A l a s d a i r C a m p b e l l r a g a w u @ g m a i l . c o m ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Xineliboutput: can achieve similar to softdevice's mgatv option?
On Thu, 2007-04-19 at 13:54 +0100, Alasdair Campbell wrote: Sorry for replying to myself, but in the meantime, while waiting for xineliboutput to work again, anyone reading know if I can use df_xine for the video display, while retaining xineliboutput as the lirc transport to my headless server running vdr-xineliboutput. No, lirc forwarding is part of vdr-sxfe. But lirc itself has similar functionality, so it should be possible to connect two lircd's over network: -l --listen[=port] listen for network connections on port -c --connect=host[:port] connect to remote lircd server - Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Xineliboutput: can achieve similar to softdevice's mgatv option?
ignore that, I was being an idiot, set to 'top' now. -- A l a s d a i r C a m p b e l l r a g a w u @ g m a i l . c o m ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Xineliboutput: can achieve similar to softdevice's mgatv option?
Am Donnerstag, 19. April 2007 10:41:01 schrieb Alasdair Campbell: If you make any progress please let me know! I'll do! But I hope we both get a pointer in the correct direction here! What sort of hardware do you have? Here it's an old P4 with 2.0 GHz. It's at 40-50% with softdevice, so maybe your hardware is a bit too slow for softdevice? In the original post I was just wondering if xineliboutput has been written with the matrox specific instructions that softdevice's -vo dfb:mgatv uses. As I don't understand the difference between -vo dfb: -vo dfb:mgatv I can't really say what difference this would make. If you have the softdevice source code laying arround, you can have a look in that, especially 'video-dfb.c'. Search for 'setupStore-useMGAtv'. There are some if-constructs in there using this variable where some DirectFB settings (and maybe some other settings, haven't looked this closely) are set. Greetings, Markus pgpe9bOVWMQlN.pgp Description: PGP signature ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Xineliboutput: can achieve similar to softdevice's mgatv option?
Am Donnerstag, 19. April 2007 15:06:54 schrieb Alasdair Campbell:
config_xineliboutput
# field parity
# { none top bottom }, default: 0
#video.device.directfb_field_parity:none
That's funny, my config_xineliboutput doesn't have this config option per
default...
But I can insert it and when set to 'top' video quality is quite awesome, but
there are still some small hickups and stutters here and there (even with
vsync set to 1). Maybe some other settings are still missing, that softdevice
sets...
With Bloomberg (German news/stock channel) I see a very odd behavior: To have
to video itself fullscreen, I have to enable local frontend scaling but then
the OSD is renderd much too big. So I have to enable OSD resizing/downscaling
which results in a very unnice OSD (fonts look a bit ugly and the complete
OSD is not the nicest view.).
And channels broadcasting a 16:9 signal are always scaled up to my 4:3 CRT TV,
so I have the typical 'long faces' (I think that's only a configuration
setting, but I haven't been able to locate it...)
I'm currently not in a productive environment (that runs with a FF and VDR
1.26 :)) with software decoding, but from what I can say so long, using
DirectFB and the Matrox G450s TV-Out, softdevice is my personal favorite! I
think xineliboutput doesn't earn it's high version number in this 'special'
configuration.
BUT I have to admit that xineliboutput uses only half of the CPU power of
softdevice, so it's video decoder has to be more efficient...
Greetings, Markus
pgpKFnoBphwHh.pgp
Description: PGP signature
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Xineliboutput: can achieve similar to softdevice's mgatv option?
Can vdr-xineliboutput utilize the excellent interlaced output of a Matrox G450 with VGASCART cable? I'm asking myself the same question. I've played arround with xineliboutput and softdevice the last days and came across the same issues you reported. I'm seeing what I can only describe as video stutters/shakes with interlaced video and quick movements, long camera pans. I experience a very simmilar problem here. For a few seconds, video is very well and the next few seconds I have those problems you describe. It seams that sound also has some problems while video stutters (at least here), but it is not this noticeable. The problem does not happen when using the normal monitor as output device. Using latest vdr-xineliboutput, DirectFB-1.0.0 xine-lib-1.1.5 using Gentoo ebuilds. Exactly the same here, but on Debian Etch with all components built from source. That's vdr-xineliboutput 1.0.0rc1, DirectFB 1.0.0 and xine-lib 1.1.5 on Debian Etches default kernel (2.6.18). Otherwise xineliboutput is working fantastically! Well, I think it's a bit hard to say that xineliboutput works fantastically as I can't rate it with this problems. But what I can say for sure is that CPU load is a bit lower than with softdevice. But sound works for me with both :) There seem to be some problems with aspect ratio with xineliboutput, but as you say, that's another issue... Greetings, Markus pgpXHMAdGlEgs.pgp Description: PGP signature ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
