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: > 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. 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? > 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 :) > 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.linuxtv.org/pipermail/vdr/attachments/20070421/40fda72d/attachment-0001.pgp
