[vdr] Vdr-xine OSD question
a.seppala+vdr at gmail.com
Sun Jul 13 08:54:24 CEST 2008
2008/7/12 Lucian Muresan <lucianm at users.sourceforge.net>:
> Antti Seppälä wrote:
>> 2008/7/11 Todd Luliak <javatodd32 at yahoo.com>:
>>> I am running vdr + vdr-xine plugin + coreavc + xine being output at 1080i to
>>> an HDTV as the only display. Is there a simple way to lock the OSD to the
>>> resolution of the output device such that the OSD is not rescaled when
>>> switching between SD and HD sources? I played with X-overlay, but that was
>>> not what I was after. If not, could it be done in the source somewhere or is
>>> the OSD anti-aliased and overlayed on the video before being sent to the
>>> output device (xine, in my case)? I've looked around quite a bit on the net
>>> but I guess my google-foo is failing me on this one. I just miss the
>>> rock-solid OSD of the FF card setup...
>> In an effort to create something to solve such issues with
>> xineliboutput plugin I came up with an idea of this HUD type OSD.
>> Basically it means that OSD is rendered to a separate transparent
>> surface on top of video and then these are blended together by the
>> display hardware. This way the size of the OSD is bound to the size of
>> the used window rather than the size of the video stream. In other
>> words no OSD scaling will be necessary even though the video size
>> The HUD implementation has been integrated into the CVS of
>> xineliboutput plugin. To operate it requires support for xorg render
>> extension and presence of composite display manager such as xcompmgr.
>> It also requires powerful display adapter and drivers with support for
>> these modern extensions. Maybe you can try it to see if it produces
>> results that you are hoping for?
> This sounds very good for HDTV setups which apparently all imply xorg,
> but what about DirectFB, does this HUD implementation also work there?
> Even if I still have a plain old PAL TV at the moment, when I switch to
> some "SD" channels having only 544x576 (which are then stretched to
> 720x576), the OSD suffers from the same problem, it's ugly stretched
> horizontally, and when the channel is 16:9, even worse, compressed
Unfortunately HUD is very dependent on xorg and will not work with
DirectFB. I'm not even sure whether DirectFB contains support for
similar operations without resorting to CPU intensive software
blending of the OSD.
More information about the vdr