[vdr] Xineliboutput: can achieve similar to softdevice's mgatv option?

Markus Schuster ma.schuster at gmx.de
Sat Apr 21 23:30:02 CEST 2007


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


More information about the vdr mailing list