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