2008/7/12 Lucian Muresan lucianm@users.sourceforge.net:
Antti Seppälä wrote:
2008/7/11 Todd Luliak javatodd32@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... Thanks!
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 changes.
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 vertically.
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.