[vdr] Xineliboutput: can achieve similar to softdevice's mgatv
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
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
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
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
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
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)?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://www.linuxtv.org/pipermail/vdr/attachments/20070421/40fda72d/attachment-0001.pgp
More information about the vdr