There's been recent talk in #xine-vdpau about expanding VDR to allow for a high color osd. Does anyone happen to know any bad implications of changing tIndex from uint8_t to a uint16_t for allowing access to more of a color palette?
On 13.04.2009 20:11, VDR User wrote:
There's been recent talk in #xine-vdpau about expanding VDR to allow for a high color osd. Does anyone happen to know any bad implications of changing tIndex from uint8_t to a uint16_t for allowing access to more of a color palette?
I believe the right way to go is to implement a full 24 (32 with alpha channel) bit OSD, as was already done for the Reelbox. This will soon be added to the core VDR code.
Klaus
Am Mon, 13 Apr 2009 20:17:50 +0200 schrieb Klaus Schmidinger Klaus.Schmidinger@cadsoft.de:
On 13.04.2009 20:11, VDR User wrote:
There's been recent talk in #xine-vdpau about expanding VDR to allow for a high color osd. Does anyone happen to know any bad implications of changing tIndex from uint8_t to a uint16_t for allowing access to more of a color palette?
I believe the right way to go is to implement a full 24 (32 with alpha channel) bit OSD, as was already done for the Reelbox. This will soon be added to the core VDR code.
Great news! I bite to my tongue, to not ask when this will happen.
Gerald
On 13.04.2009 20:17, Klaus Schmidinger wrote:
On 13.04.2009 20:11, VDR User wrote:
There's been recent talk in #xine-vdpau about expanding VDR to allow for a high color osd.
I believe the right way to go is to implement a full 24 (32 with alpha channel) bit OSD, as was already done for the Reelbox. This will soon be added to the core VDR code.
This will hopefully be a true-color OSD with transparency and the ability to scale to the needs of the output device? Like having a HD OSD even on SD playback? And (even if these times are almost history) the ability to switch between 4:3 and 16:9 based on what the output device needs?
Cheers,
Udo
On Mon, Apr 13, 2009 at 11:31 AM, Udo Richter udo_richter@gmx.de wrote:
This will hopefully be a true-color OSD with transparency and the ability to scale to the needs of the output device? Like having a HD OSD even on SD playback? And (even if these times are almost history) the ability to switch between 4:3 and 16:9 based on what the output device needs?
Let's all keep our fingers crossed tight for that. You know the saying, if you're gonna do it, might as well do it right! ;)
Klaus, this is great to hear since I know many guys have been interested in this for some time (myself included). It seems the news is traveling fast too, have already seen several inquiries about it elsewhere!
It looks like I'll be loading Photoshop later and getting back to the high color/res yaepghd themes I was working on now. :)
Cheers, Derek
Why not go all the way and implement an opengl rendered OSD with vdpau? This would of course require information from vdr in a slightly different form; ie. semantically instead of pixels. I'd suggest trying to get the OSD information as HTML from VDR, then allowing the frontend to render it in any way it deems suitable, with fancy animation, transition effects, icons etc. This might also make it easier to implement text-only OSD, eg for terminal connections.
2009/4/14 VDR User user.vdr@gmail.com
On Mon, Apr 13, 2009 at 11:31 AM, Udo Richter udo_richter@gmx.de wrote:
This will hopefully be a true-color OSD with transparency and the ability to scale to the needs of the output device? Like having a HD OSD even on SD playback? And (even if these times are almost history) the ability to switch between 4:3 and 16:9 based on what the output device needs?
Let's all keep our fingers crossed tight for that. You know the saying, if you're gonna do it, might as well do it right! ;)
Klaus, this is great to hear since I know many guys have been interested in this for some time (myself included). It seems the news is traveling fast too, have already seen several inquiries about it elsewhere!
It looks like I'll be loading Photoshop later and getting back to the high color/res yaepghd themes I was working on now. :)
Cheers, Derek
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Quoting Torgeir Veimo torgeir@pobox.com:
Why not go all the way and implement an opengl rendered OSD with vdpau? This would of course require information from vdr in a slightly different form; ie. semantically instead of pixels. I'd suggest trying to get the OSD information as HTML from VDR, then allowing the frontend to render it in any way it deems suitable, with fancy animation, transition effects, icons etc. This might also make it easier to implement text-only OSD, eg for terminal connections.
I don't think that HTML is a good idea, it should be more general. I would suggest XML with SVG for graphics and animations. Together with XSLT it would be easy to have different themes.
Gerald
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
Hi,
Klaus Schmidinger wrote:
On 13.04.2009 20:11, VDR User wrote:
There's been recent talk in #xine-vdpau about expanding VDR to allow for a high color osd. Does anyone happen to know any bad implications of changing tIndex from uint8_t to a uint16_t for allowing access to more of a color palette?
I believe the right way to go is to implement a full 24 (32 with alpha channel) bit OSD, as was already done for the Reelbox. This will soon be added to the core VDR code.
i don't want to complain, i like vdr very much (use ist now for years), but i see only a lot of new gimmicks in vdr in the last months/years. I still waiting for real client/server/multi-user functionality. I know that there are plugins (xineliboutput, streamdev and so on) but it is still not 100%. Is there anything in the queue about this topics?
Thanks a lot
Olli
Gerald Dachs wrote:
Quoting Torgeir Veimo torgeir@pobox.com:
Why not go all the way and implement an opengl rendered OSD with vdpau? This would of course require information from vdr in a slightly different form; ie. semantically instead of pixels. I'd suggest trying to get the OSD information as HTML from VDR, then allowing the frontend to render it in any way it deems suitable, with fancy animation, transition effects, icons etc. This might also make it easier to implement text-only OSD, eg for terminal connections.
I don't think that HTML is a good idea, it should be more general. I would suggest XML with SVG for graphics and animations. Together with XSLT it would be easy to have different themes.
Gerald
I second this proposal (esp. SVG for resolution scalability). XML with SVG provides a lot of possibilities. If you want to have animations etc. then PNG-format provides means for this as well. OpenGL does not provide sufficient added value for this type of usage, IMO, but it will make things way more complicated.
Full colour OSD with above mentioned means would provide real nice platform for OSD developers.
There is at least one drawback with this idea and that's additional CPU power requirements. Maybe simple XML and SVG would not be too CPU hungry after all..
Pasi
On 14.04.2009 01:42, Torgeir Veimo wrote:
This would of course require information from vdr in a slightly different form; ie. semantically instead of pixels. I'd suggest trying to get the OSD information as HTML from VDR, then allowing the frontend to render it in any way it deems suitable, with fancy animation, transition effects, icons etc. This might also make it easier to implement text-only OSD, eg for terminal connections.
This is mostly what the VDR skin interface already provides: A semantically structured description of the interface. Most skins translate this into a bitmapped OSD view, but they don't have to. The skincurses plugin for example uses the text console. VDR itself never uses the OSD directly, only through the two standard skins.
So if you want, you can write an HTML-skin or an SVG-skin or OpenGL-Skin any time you want. And by using plugin-to-plugin communications, you can easily open this for other plugins, so that they can directly use SVG or whatever too.
Cheers,
Udo
On Sat, 18 Apr 2009 13:28:24 +0200 Udo Richter udo_richter@gmx.de wrote:
This is mostly what the VDR skin interface already provides: A semantically structured description of the interface. Most skins translate this into a bitmapped OSD view, but they don't have to. The skincurses plugin for example uses the text console. VDR itself never uses the OSD directly, only through the two standard skins.
That only works if the default vdr menu layout (i.e. a simple name:value list) fits your needs. If you need a different layout you have to draw directly to the osd (with the side effect that the skincurses plugin won't work).
Bye
On 18.04.2009 15:36, Luca Olivetti wrote:
On Sat, 18 Apr 2009 13:28:24 +0200 Udo Richterudo_richter@gmx.de wrote:
This is mostly what the VDR skin interface already provides: A semantically structured description of the interface. Most skins translate this into a bitmapped OSD view, but they don't have to. The skincurses plugin for example uses the text console. VDR itself never uses the OSD directly, only through the two standard skins.
That only works if the default vdr menu layout (i.e. a simple name:value list) fits your needs. If you need a different layout you have to draw directly to the osd (with the side effect that the skincurses plugin won't work).
Sure. But as I said: VDR only uses the skin interface. Plugins do use the OSD directly, but currently expect it to be bitmapped. Vectorized structures could be provided by custom skins using plugin-to-plugin communications.
IMHO a bitmapped interface is a good compromise of flexibility and simplicity, while vectorized systems tend to be quite complex. (think of XUL (mozilla) or XAML (microsoft).)
However, there's no reason why, for example, a plugin like text2skin could not provide advanced rendering to other plugins.
Cheers,
Udo
On Sat, Apr 18, 2009 at 10:37 AM, Udo Richter udo_richter@gmx.de wrote:
This is mostly what the VDR skin interface already provides: A semantically structured description of the interface. Most skins translate this into a bitmapped OSD view, but they don't have to. The skincurses plugin for example uses the text console. VDR itself never uses the OSD directly, only through the two standard skins.
That only works if the default vdr menu layout (i.e. a simple name:value list) fits your needs. If you need a different layout you have to draw directly to the osd (with the side effect that the skincurses plugin won't work).
Sure. But as I said: VDR only uses the skin interface. Plugins do use the OSD directly, but currently expect it to be bitmapped. Vectorized structures could be provided by custom skins using plugin-to-plugin communications.
IMHO a bitmapped interface is a good compromise of flexibility and simplicity, while vectorized systems tend to be quite complex. (think of XUL (mozilla) or XAML (microsoft).)
However, there's no reason why, for example, a plugin like text2skin could not provide advanced rendering to other plugins.
If support for a high res/color OSD is present in the VDR core, why would you need a plugin to provide anything to any other plugin? Unless you mean a plugin that handles different ways of supplying the OSD such as the different techniques previously mentioned (xml, html, etc etc)?
Udo Richter wrote:
On 18.04.2009 15:36, Luca Olivetti wrote:
On Sat, 18 Apr 2009 13:28:24 +0200 Udo Richterudo_richter@gmx.de wrote:
This is mostly what the VDR skin interface already provides: A semantically structured description of the interface. Most skins translate this into a bitmapped OSD view, but they don't have to. The skincurses plugin for example uses the text console. VDR itself never uses the OSD directly, only through the two standard skins.
That only works if the default vdr menu layout (i.e. a simple name:value list) fits your needs. If you need a different layout you have to draw directly to the osd (with the side effect that the skincurses plugin won't work).
Sure. But as I said: VDR only uses the skin interface. Plugins do use the OSD directly, but currently expect it to be bitmapped. Vectorized structures could be provided by custom skins using plugin-to-plugin communications.
IMHO a bitmapped interface is a good compromise of flexibility and simplicity, while vectorized systems tend to be quite complex. (think of XUL (mozilla) or XAML (microsoft).)
However, there's no reason why, for example, a plugin like text2skin could not provide advanced rendering to other plugins.
Cheers,
Udo
This is good news. But is there anyone willing to take the task to developed either new plugin or update text2skin?
Is text2skin even maintained anymore - let alone thought to be updated by the author to vectorized direction?
Br, Pasi
-
Gerald Dachs -
Klaus Schmidinger -
Luca Olivetti -
Oliver Joa -
Pasi Juppo -
Torgeir Veimo -
Udo Richter -
VDR User