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!
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?
Regards,
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.
Regards, Lucian
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.
This sounds very good for HDTV setups which apparently all imply xorg, but what about DirectFB, does this HUD implementation also work there?
have you good experience with HD video 1080i video from satellites and DirectFB ? is it better than X- Window solution ?
Goga
Goga777 wrote:
This sounds very good for HDTV setups which apparently all imply xorg, but what about DirectFB, does this HUD implementation also work there?
have you good experience with HD video 1080i video from satellites and DirectFB ? is it better than X- Window solution ?
Sorry, my only HDTV capable hardware a.t.m. would be the Lenovo L220x monitor, (no TV, no DVB-S2 card, I can only try to receive what's still broadcasted on DVB-S, which again is already h264 - even my desktop PC is to weak for this), so I can't tell.
Antti Seppälä wrote:
[...]
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.
AFAIK, it does, at least for certain graphics cards (also depending on the configuration), there are so-called "layers" and the device capabilities can be queried in the API. Even if there is no good enough support for separate layers to do this, DirectFB further supports "surfaces" whithin a layer, AFAIK that's how softdevice implements the OSD, and it's not at all CPU-intense, in fact I guess those operations are also accelerated, and the OSD shows up all the time at the same, correct, native display resolution, regardless of the video resolution (i.e. it also uses the black top/bottom bars when the video is 16:9 letterboxed on my 4:3 TV, or it is drawn still at 720x576 even when the broadcast is only 544x764).
-
Antti Seppälä -
Goga777 -
Lucian Muresan -
Todd Luliak