Can vdr-xineliboutput utilize the excellent interlaced output of a Matrox G450 with VGA>SCART cable?
I'm seeing what I can only describe as video stutters/shakes with interlaced video and quick movements, long camera pans.
Using latest vdr-xineliboutput, DirectFB-1.0.0 & xine-lib-1.1.5 using Gentoo ebuilds.
Otherwise xineliboutput is working fantastically! (well without any sound but that's another issue for another day :-) )
Can vdr-xineliboutput utilize the excellent interlaced output of a Matrox G450 with VGA>SCART 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
On 18/04/07, Markus Schuster ma.schuster@gmx.de wrote:
Can vdr-xineliboutput utilize the excellent interlaced output of a Matrox G450 with VGA>SCART 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.
If you make any progress please let me know!
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.
I'm noticing these effects on a less noticeable basis with Softdevice, and here I get the audio stutters. With softdevice cpu can max out on my P3 550Mhz, especially when the OSD is shown. Whats strange is top shows cpu cost shifting constantly from less than 20% to +97%. I've never seen this behaviour with softdevice before (first time using xine-lib).
What sort of hardware do you have?
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
Fantastic was an exaggeration certainly..Just trying to be optimistic! CPU load lower with xine-lib here as well. On a purely visual basis, when xine-lib isn't stuttering (field sync tripping out?) the image is actually better than my set top box. Colours arn't as harsh, video is less pixelated , text on my scrolling news channel is very good looking, almost anti-aliased :-) However the interlacing problems are happening every couple of seconds.
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.
Should have mentioned I'm using a 16:9 CRT to view all this, and I don't have a monitor on the first head at all. Whats funny is that when I was last struggling with vdr-softdevice on an old 4:3 TV I could easily get fantastic output when I set the aspect to 16:9, of course this caused a huge overscan, meaning it wasn't much of an option.
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.
On 19 Apr 2007, at 09:55, Torgeir Veimo 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.
Hmm, I guess I'm confusing xinelibout with the xine device output plugin...
On 19/04/07, Torgeir Veimo torgeir@pobox.com 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.
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
On 19/04/07, Petri Hintukainen phintuka@users.sourceforge.net wrote:
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)
Maybe this is due to me running as root (I know this is bad, just for testing) but each time I run vdr-fbfe it seems to clobber the config_xineliboutput file, and reinstate "none" for field parity.
# field parity # { none top bottom }, default: 0 #video.device.directfb_field_parity:none
Setting wait for vertical retrace stays set at 1, after setting it a few minutes ago. I presume I want that with my G450.
ignore that, I was being an idiot, set to 'top' now.
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
On 20/04/07, Markus Schuster ma.schuster@gmx.de 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,
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
In 1849e5180704201150v36099a6u1f61a89fef75e0d5@mail.gmail.com, Alasdair Campbell wrote:
On 20/04/07, Markus Schuster ma.schuster@gmx.de 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.
On 21/04/07, Tony Houghton h@realh.co.uk wrote:
In 1849e5180704201150v36099a6u1f61a89fef75e0d5@mail.gmail.com, 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...)
In 1849e5180704210640w51c2e5bdi669de67ffe25535e@mail.gmail.com, Alasdair Campbell wrote:
On 21/04/07, Tony Houghton h@realh.co.uk wrote:
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.
2/3 sounds about the same as my experience.
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've found it seems to come and go, but I haven't really noticed what seems to trigger it. ITV3 is definitely one channel it sometimes happens on, but not always.
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 :-)
What boxstar is is a menu-driven front-end for video applications. It's written in python with SDL (pygame) for output, so it's very flexible, including DirectFB support provided your SDL is compiled with it. It can use remote controls provided they generate input device events - I had some trouble with pylirc and lacked time and inclination to get that working. It's still very early in its development cycle, but I'm not doing very much work on it at the moment because other things are taking up my time and it's got to that stage where it just about works adequately for my own needs. I hope to switch my attention back to boxstar in a few months.
Anyway, one of the things that you can get boxstar to do as a menu entry is to (optionally) shut down its display and launch a player (eg df_xine) and pass input events on to VDR via its remote plugin. Boxstar retains control of the input device so it can detect when you press the Power button which makes it kill the player and go back to its menu system. This also has the advantages that you can shut down play back to save CPU power when not watching anything, and you only have to train one program with your remote control - when playing other videos it also retains control of the input device and controls mplayer via its slave mode.
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
On Saturday 21 April 2007 07:56:52 Petri Hintukainen wrote:
On Fri, 2007-04-20 at 03:27 +0200, Markus Schuster wrote:
With Bloomberg (German news/stock channel) I see a very odd behavior: [..]
Probably channel uses smaller resolution than VDR OSD (720x576).
Yes, it does indeed :)
There are two methods for OSD blending:
- "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.
Ok, if I get this right, this is the badest option for OSD rendering? Because of the loss of quality and so on...
(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?
- "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 :)
Xine-lib directfb driver supports method 2) for only some hardware with ARGB blending capacity. For the rest method 1) is used.
And from another mail from you:
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_direc tfb.c?view=log
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.
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?
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).
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)?
Greetings, Markus
On 21/04/07, Markus Schuster ma.schuster@gmx.de 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..
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.
- "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
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
On 21/04/07, Petri Hintukainen phintuka@users.sourceforge.net wrote:
[snip]
There are two methods for OSD blending:
- "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.
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. all the best
On Tue, 2007-05-22 at 23:27 +0100, Alasdair Campbell wrote:
On 21/04/07, Petri Hintukainen phintuka@users.sourceforge.net wrote:
- "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
On 25/05/07, Petri Hintukainen phintuka@users.sourceforge.net 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
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 ;-) **
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
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
On 20/04/07, Markus Schuster ma.schuster@gmx.de wrote:
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.
I'll have a look at the softdevice src this weekend & compare with xineliboutput.
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_direct... (so, unscaled OSD might work with xine-lib 1.1.2 (?) and recent DirectFB (?)).
- Petri
On 21/04/07, Petri Hintukainen phintuka@users.sourceforge.net 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_direct... (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
On 21/04/07, Petri Hintukainen phintuka@users.sourceforge.net 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_direct... (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...!
On 22/04/07, Alasdair Campbell ragawu@gmail.com wrote:
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...!
I've realised that trying xine-lib1.1.2 and changing the xine-lib source during gentoo emerge both clobbered my framebuffer, to the extent where I couldn't run any dfb apps whatsoever. This must be the "problems with tv out" that was mentioned on the xine cvs page.
I had to reboot to fix this.
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..
-
Alasdair Campbell -
Markus Schuster -
Petri Hintukainen -
Tony Houghton -
Torgeir Veimo