Hi,
thanks to the work of Udo Richter I may announce you a preview version of the osdteletext plugin. This version features an extensive rewrite of the display code. This makes the display substantially faster and offers a clean architecture for future development. Additionally, it aims at strict adherence to the standard.
Such a rewrite offers many ways for new bugs, so this is a preview release and any bug reports are welcome.
The new version is available from: http://www.wiesweg-online.de/linux/vdr/vdr-osdteletext-0.5-pre1.tgz
Marcel
Hello Marcel,
* Marcel Wiesweg marcel.wiesweg@gmx.de [30-03-05 14:23]:
The new version is available from: http://www.wiesweg-online.de/linux/vdr/vdr-osdteletext-0.5-pre1.tgz
i think the link is: http://www.wiesweg-online.de/linux/vdr/vdr-osdteletext-0.5.0-pre1.tgz
Thx for this great piece of software.
Marcel Wiesweg wrote:
Hi,
thanks to the work of Udo Richter I may announce you a preview version of the osdteletext plugin. This version features an extensive rewrite of the display code. This makes the display substantially faster and offers a clean architecture for future development. Additionally, it aims at strict adherence to the standard.
Such a rewrite offers many ways for new bugs, so this is a preview release and any bug reports are welcome.
Thanks for the new version :)
The "Half page" (don't confuse with "zoom") function doesn't do anything here.
The "change background" appears to work with xine, but not in my FF DVB card.
I have configured the teletext osd to be smaller than normal so that it has full colors. It was previously positioned in the right down corner, but now it is in the middle of screen. Could there be a configuration option for this?
BTW, normal-height text has always been very flickering, even more when resized to smaller size. Is there anything that could be done to avoid that?
Another BTW: couldn't it be possible to use multiple 2bpp drawing areas with invidual intelligent palettes to have more colors than 2bpp mode currently has?
Marcel Wiesweg wrote:
thanks to the work of Udo Richter I may announce you a preview version of the osdteletext plugin.
Ok, some comments what to check for:
* Rendering code is all new, so check for strange looking text pages. In 4 color mode, some colors may be wrong of course, so also check 8 color half height mode. Compare them to your TV's teletext if possible.
* OSD display modes may behave strangely, loose garbage on screen, may even be invisible or simillar.
* User interface: Entering strange stuff, dropping out of usual visual feedback, etc. (for example, switching to channel 9999 or other invalid will crash VDR...)
* Non-german non-english users: Sorry, no font switching for now. Promise, I'll add that. ;)
Cheers,
Udo
Anssi Hannula wrote:
The "Half page" (don't confuse with "zoom") function doesn't do anything here.
Feared that... ;) The new code tries to fit the half-height mode into existing OSD memory, but CanHandleAreas is too optimistic in calculating the memory size. I already calculate using 10 lines backup, but thats not enough obviously...
display.c, line 244: // Add some backup // CanHandleAreas is not accurate enough if (Upper) { Areas[0].y2=Areas[0].y2-10; } else { Areas[0].y1=Areas[0].y1+10; } Try increasing the +/- 10 here...
The "change background" appears to work with xine, but not in my FF DVB card.
At least works for my card, without re-initializing the osd.
I have configured the teletext osd to be smaller than normal so that it has full colors. It was previously positioned in the right down corner, but now it is in the middle of screen. Could there be a configuration option for this?
The new default is to center inside VDR's osd area, and not squish it into the corner. Some offset option could be added.
BTW, normal-height text has always been very flickering, even more when resized to smaller size. Is there anything that could be done to avoid that?
Probably interlaced trouble. With an OSD height of 506 lines, pixels will be same on even and odd frames. Anything with less lines will sometimes have 1-pixel thin lines, appearing only on one frame, causing it to flicker.
Another BTW: couldn't it be possible to use multiple 2bpp drawing areas with invidual intelligent palettes to have more colors than 2bpp mode currently has?
:) My thought. There's already an interface for different OSD areas with different color mappings, but no code to calculate best colors. Even better would be some really smart code that calculates optimized zone areas and uses 1bpp, 2bpp and 4bpp to get the maximum out of it. But this is a hard job to calculate...
Cheers,
Udo
Udo Richter wrote:
Anssi Hannula wrote:
The "Half page" (don't confuse with "zoom") function doesn't do anything here.
Feared that... ;) The new code tries to fit the half-height mode into existing OSD memory, but CanHandleAreas is too optimistic in calculating the memory size. I already calculate using 10 lines backup, but thats not enough obviously...
display.c, line 244: // Add some backup // CanHandleAreas is not accurate enough if (Upper) { Areas[0].y2=Areas[0].y2-10; } else { Areas[0].y1=Areas[0].y1+10; } Try increasing the +/- 10 here...
The problem seems to be that it tries to find the largest mode possible with 3Bpp, and so it ends up using the full size as I have resized the OSD down ;)
The "change background" appears to work with xine, but not in my FF DVB card.
At least works for my card, without re-initializing the osd.
Oops, sorry, works here too. Probably I looked too fast, as the osd blinked when using in earlier version
BTW, normal-height text has always been very flickering, even more when resized to smaller size. Is there anything that could be done to avoid that?
Probably interlaced trouble. With an OSD height of 506 lines, pixels will be same on even and odd frames. Anything with less lines will sometimes have 1-pixel thin lines, appearing only on one frame, causing it to flicker.
Thanks, I now use width 506 and height 358, and the text is much more readable :)
...where another question arises: Why doesn't the setup allow less than 480 height? I edited setup.conf manually.
Another BTW: couldn't it be possible to use multiple 2bpp drawing areas with invidual intelligent palettes to have more colors than 2bpp mode currently has?
:) My thought. There's already an interface for different OSD areas with different color mappings, but no code to calculate best colors. Even better would be some really smart code that calculates optimized zone areas and uses 1bpp, 2bpp and 4bpp to get the maximum out of it. But this is a hard job to calculate...
I thought of that too, but it would indeed be complex to calculate the areas.
Anssi Hannula wrote:
Oops, sorry, works here too. Probably I looked too fast, as the osd blinked when using in earlier version
Yes, now updates without re-initializing the whole OSD. Although there is a flaw in VDR: The color wont be updated without some screen changes, so color will change on next clock or page update.
...where another question arises: Why doesn't the setup allow less than 480 height? I edited setup.conf manually.
OSD size is limited to MINOSDHEIGHT, MAXOSDHEIGHT, MINOSDWIDTH and MAXOSDWIDTH from <vdr/config.h>. These are the limits for the VDR OSD. The lower limits probably are more of practical meaning for VDR, so they should be dropped for osdteletext...
Cheers,
Udo
... missed one...
Anssi Hannula wrote:
The problem seems to be that it tries to find the largest mode possible with 3Bpp, and so it ends up using the full size as I have resized the OSD down ;)
Actually it starts with full size, realizes that full size should work, and ends on an osd size that drops 10 lines at top or bottom. Thats what happens for me.
Cheers,
Udo
Udo Richter wrote:
... missed one...
Anssi Hannula wrote:
The problem seems to be that it tries to find the largest mode possible with 3Bpp, and so it ends up using the full size as I have resized the OSD down ;)
Actually it starts with full size, realizes that full size should work, and ends on an osd size that drops 10 lines at top or bottom. Thats what happens for me.
Here also. What about fixing the canhandleareas() in VDR rather than have a workaround?
-
Anssi Hannula -
Marcel Wiesweg -
Matthias Fechner -
Udo Richter