Re: [vdr] Trouble with softdevice -vo dfb:mgatv OSD with vdr 2.0.4
I can't really say if the CVS server is still available. It's been such a long time since I did work on softdevice, and I wasn't the main developer either. On 5 November 2013 00:04, Marko Mäkelä wrote: > On Mon, Nov 04, 2013 at 10:30:14PM +1000, Torgeir Veimo wrote: >> >> Softdevice had transparency 'dithering' for when there's only 1-bit >> transparency, did you look at that option? > > > Thanks, but I guess I will be fine with the transparency key. The screen > output would not be so much for watching videos, but mainly for setting up > timers and cutting recordings. For watching, the plan is to stream the > videos to the Samsung SmartTV in the living room. > > I will try to put back the dirty_lines[] optimization that I removed in my > initial attempt (trying to make it as simple as possible). The system felt > slow without that. > > You are one of the Softdevice authors, right? Is the CVS tree at berlios.de > still open for patches? AFAICT, recent years the mailing list archive are > corrupted, and the latest commit was a couple of years ago. > > > Best regards, > > Marko > > ___ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Trouble with softdevice -vo dfb:mgatv OSD with vdr 2.0.4
On Mon, Nov 04, 2013 at 10:30:14PM +1000, Torgeir Veimo wrote: Softdevice had transparency 'dithering' for when there's only 1-bit transparency, did you look at that option? Thanks, but I guess I will be fine with the transparency key. The screen output would not be so much for watching videos, but mainly for setting up timers and cutting recordings. For watching, the plan is to stream the videos to the Samsung SmartTV in the living room. I will try to put back the dirty_lines[] optimization that I removed in my initial attempt (trying to make it as simple as possible). The system felt slow without that. You are one of the Softdevice authors, right? Is the CVS tree at berlios.de still open for patches? AFAICT, recent years the mailing list archive are corrupted, and the latest commit was a couple of years ago. Best regards, Marko ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Trouble with softdevice -vo dfb:mgatv OSD with vdr 2.0.4
Softdevice had transparency 'dithering' for when there's only 1-bit transparency, did you look at that option? On 4 November 2013 06:01, Marko Mäkelä wrote: > On Fri, Nov 01, 2013 at 11:19:48PM +0200, Marko Mäkelä wrote: >> >> If I change the assignment to isTrueColor=false, the square goes away and >> I will get the familiar gray rectangles on the screen (from the "else" block >> that I omitted above). > > > I did some further studying. The truecolor OSD was implemented early 2011. > As far as I understand, the softdevice plugin is converting palette-based > bitmaps into an ARGB layer. There is a comment at the end of the definition > of class cOsd in osd.h that shows how the conversion should be done. > > It looks like I should simply follow this example, possibly implementing > some kind of threshold mapping on the Alpha channel in case the Matrox does > not implement 8-bit translucency but just a 1-bit transparency flag. So, I > will try to remove the palette mapping from SoftOsd.c and replace the > GetBitmap() call with the RenderPixmaps() loop. > > > Best regards, > > Marko > > ___ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Trouble with softdevice -vo dfb:mgatv OSD with vdr 2.0.4
On Sun, Nov 03, 2013 at 05:25:36PM -0800, VDR User wrote: Have you tried softhddevice for output? http://projects.vdr-developer.org/git/vdr-plugin-softhddevice.git/ It looks like this is based on the X server. I see no reference to DirectFB in the README.txt or the Makefile. The Matrox MGA450 is a very old graphics card. Also the computer is 11 or 12 years old, featuring a 900 MHz Celeron and 256 MB RAM. DirectFB meets these requirements. I do not have plans to replace my Hauppauge Nova-T PCI 90002 tuner(s) with DVB-T2 either, so I do not even care about HDTV for now. Thanks for the hint anyway! I could at least compare how the OSD is implemented there. Best regards, Marko ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Trouble with softdevice -vo dfb:mgatv OSD with vdr 2.0.4
Have you tried softhddevice for output? http://projects.vdr-developer.org/git/vdr-plugin-softhddevice.git/ On Sun, Nov 3, 2013 at 2:42 PM, Marko Mäkelä wrote: > On Sun, Nov 03, 2013 at 10:01:54PM +0200, Marko Mäkelä wrote: >> >> On Fri, Nov 01, 2013 at 11:19:48PM +0200, Marko Mäkelä wrote: >>> >>> If I change the assignment to isTrueColor=false, the square goes away and >>> I will get the familiar gray rectangles on the screen (from the "else" block >>> that I omitted above). >> >> >> I did some further studying. The truecolor OSD was implemented early 2011. >> As far as I understand, the softdevice plugin is converting palette-based >> bitmaps into an ARGB layer. There is a comment at the end of the definition >> of class cOsd in osd.h that shows how the conversion should be done. >> >> It looks like I should simply follow this example, possibly implementing >> some kind of threshold mapping on the Alpha channel in case the Matrox does >> not implement 8-bit translucency but just a 1-bit transparency flag. So, I >> will try to remove the palette mapping from SoftOsd.c and replace the >> GetBitmap() call with the RenderPixmaps() loop. > > > I figured this out for the most part. The pixmap gets first converted to an > ARGB buffer cSoftOsd::OSD_Bitmap in FlushPixmaps() and DrawConvertPixmap(). > From OSD_Bitmap it gets converted to the screen memory. I did not change the > latter conversion. > > Maybe I did something wrong regarding DirtyDrawPort and DirtyViewport, > because I got occasional crashes when activating the OSD. When using a > full-screen OSD (filling the entire 1280×1024 panel) the bottom 4 or so > lines were never erased. > > I did not get to see DVB subtitles yet, either due to them not being present > in the live sendings at the moment I tested, or due to misconfiguration. I > guess that VDR 2.0 would allow the subtitles to be alpha-blended with the > OSD layer. > > My patch against softdevice-cvs is attached. I compiled it with the > following: > > vdr 2.0.4 > ffmpeg 0.5.13 > DirectFB 1.0.1 > DFB++ 1.0.0 > > Best regards, > > Marko > > ___ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Trouble with softdevice -vo dfb:mgatv OSD with vdr 2.0.4
On Sun, Nov 03, 2013 at 10:01:54PM +0200, Marko Mäkelä wrote:
On Fri, Nov 01, 2013 at 11:19:48PM +0200, Marko Mäkelä wrote:
If I change the assignment to isTrueColor=false, the square goes
away and I will get the familiar gray rectangles on the screen
(from the "else" block that I omitted above).
I did some further studying. The truecolor OSD was implemented early
2011. As far as I understand, the softdevice plugin is converting
palette-based bitmaps into an ARGB layer. There is a comment at the
end of the definition of class cOsd in osd.h that shows how the
conversion should be done.
It looks like I should simply follow this example, possibly
implementing some kind of threshold mapping on the Alpha channel in
case the Matrox does not implement 8-bit translucency but just a
1-bit transparency flag. So, I will try to remove the palette mapping
from SoftOsd.c and replace the GetBitmap() call with the
RenderPixmaps() loop.
I figured this out for the most part. The pixmap gets first converted to
an ARGB buffer cSoftOsd::OSD_Bitmap in FlushPixmaps() and
DrawConvertPixmap(). From OSD_Bitmap it gets converted to the screen
memory. I did not change the latter conversion.
Maybe I did something wrong regarding DirtyDrawPort and DirtyViewport,
because I got occasional crashes when activating the OSD. When using a
full-screen OSD (filling the entire 1280×1024 panel) the bottom 4 or so
lines were never erased.
I did not get to see DVB subtitles yet, either due to them not being
present in the live sendings at the moment I tested, or due to
misconfiguration. I guess that VDR 2.0 would allow the subtitles to be
alpha-blended with the OSD layer.
My patch against softdevice-cvs is attached. I compiled it with the
following:
vdr 2.0.4
ffmpeg 0.5.13
DirectFB 1.0.1
DFB++ 1.0.0
Best regards,
Marko
Index: SoftOsd.c
===
RCS file: /cvsroot/softdevice/softdevice/SoftOsd.c,v
retrieving revision 1.37
diff -p -u -r1.37 SoftOsd.c
--- SoftOsd.c 17 Apr 2011 16:06:31 - 1.37
+++ SoftOsd.c 3 Nov 2013 22:35:48 -
@@ -25,7 +25,6 @@
//#define SCALEDEBV(out...) printf(out)
//#define SCALEDEBH(out...) printf(out)
-
#ifndef OSDDEB
#define OSDDEB(out...)
#endif
@@ -55,16 +54,17 @@
#define COLOR_64BIT(x) ( ((x)<<32) | (x) )
#define ALPHA_VALUE(x) ( (x) << 24 )
-// the same constants for MMX mode
+//#undef USE_MMX
+//#undef USE_MMX2
+
+#ifdef USE_MMX2
static uint64_t transparent_thr= COLOR_64BIT(ALPHA_VALUE(TRANSPARENT_THRESHOLD>>1));
static uint64_t opacity_thr= COLOR_64BIT(ALPHA_VALUE(OPACITY_THRESHOLD>>1));
static uint64_t pseudo_transparent = COLOR_64BIT(COLOR_KEY);
+#endif // USE_MMX2
int cSoftOsd::colorkey;
-//#undef USE_MMX
-//#undef USE_MMX2
-
#undef SPLAT_U16
#ifdef USE_MMX2
#define SPLAT_U16(X) " pshufw $0b0, " X ", " X " \n"
@@ -85,7 +85,7 @@ cSoftOsd::cSoftOsd(cVideoOut *VideoOut,
OSDDEB("cSoftOsd constructor\n");
OutputConvert=&cSoftOsd::ARGB_to_ARGB32;
bitmap_Format=PF_None; // forces a clear after first SetMode
-OSD_Bitmap=new uint32_t[OSD_STRIDE*(OSD_HEIGHT+4)];
+OSD_Bitmap=new tColor[OSD_STRIDE*(OSD_HEIGHT+4)];
videoOut = VideoOut;
xPan = yPan = 0;
@@ -93,9 +93,10 @@ cSoftOsd::cSoftOsd(cVideoOut *VideoOut,
voutMutex.Lock();
videoOut->OpenOSD();
colorkey=videoOut->GetOSDColorkey();
+#ifdef USE_MMX2
pseudo_transparent=(uint64_t)colorkey | ((uint64_t) colorkey)<<32;
+#endif // USE_MMX2
-xOfs=X;yOfs=Y;
ScreenOsdWidth=ScreenOsdHeight=0;
int Depth=16; bool HasAlpha=false; bool AlphaInversed=false;
bool IsYUV=false;
@@ -115,9 +116,6 @@ void cSoftOsd::Clear() {
for (int i=OSD_STRIDE*(OSD_HEIGHT+2)-1; i!=0; i--)
OSD_Bitmap[i]=fill;
OSD_Bitmap[0]=fill;
-
-// no dirty lines, everything has to be redrawn anyway
-memset(dirty_lines,false,sizeof(dirty_lines));
}
/* --*/
@@ -302,7 +300,7 @@ bool cSoftOsd::SetMode(int Depth, bool H
// format change, redraw everything
bitmap_Format= PF_AYUV;
Clear();
-FlushBitmaps(false);
+FlushPixmaps();
OSDDEB("SetMode switched to YUV mode\n");
return true;
};
@@ -338,7 +336,7 @@ bool cSoftOsd::SetMode(int Depth, bool H
if (old_bitmap_Format != bitmap_Format ||
videoOut->OSDNeedsRedraw()) {
Clear();
-FlushBitmaps(false);
+FlushPixmaps();
OSDDEB("SetMode switched old_bitmap_Format %d -> bitmap_Format %d\n",
old_bitmap_Format,bitmap_Format);
return true;
@@ -357,15 +355,14 @@ void cSoftOsd::Flush(void)
Re: [vdr] Trouble with softdevice -vo dfb:mgatv OSD with vdr 2.0.4
On Fri, Nov 01, 2013 at 11:19:48PM +0200, Marko Mäkelä wrote: If I change the assignment to isTrueColor=false, the square goes away and I will get the familiar gray rectangles on the screen (from the "else" block that I omitted above). I did some further studying. The truecolor OSD was implemented early 2011. As far as I understand, the softdevice plugin is converting palette-based bitmaps into an ARGB layer. There is a comment at the end of the definition of class cOsd in osd.h that shows how the conversion should be done. It looks like I should simply follow this example, possibly implementing some kind of threshold mapping on the Alpha channel in case the Matrox does not implement 8-bit translucency but just a 1-bit transparency flag. So, I will try to remove the palette mapping from SoftOsd.c and replace the GetBitmap() call with the RenderPixmaps() loop. Best regards, Marko ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Trouble with softdevice -vo dfb:mgatv OSD with vdr 2.0.4
Hi all,
I used to follow the vdr development between 1.3.x and 1.6.0. I stopped
updating my system around 2007, because it was working well enough for
me.
This year, I bought a Samsung SmartTV, hoping that it could be replace
the old PC. Little did I know that the USB interface does not deliver
enough power to USB-powered hard disks, or that the TV wants to encrypt
all recordings with a device-specific key, in *.srf files.
So, I decided to revive my aging VDR setup, and maybe use DLNA or the
http://projects.vdr-developer.org/projects/plg-smarttvweb/wiki/SamsungSmartTVClient
as the primary output method once the system has been upgraded. I
installed a recent Debian distribution and compiled vdr 2.0.4, DirectFB
1.0.1, DFB++ 1.0.1, ffmpeg (latest 0.5 or 0.6 IIRC; 0.9 was already too
new) and latest softdevice-cvs. I had to patch softdevice a little.
Finally, I got a smooth picture with -P'softdevice -vo dfb:mgatv' on a
nearly-HDTV VGA panel. Not bad for 11-year-old hardware.
The only remaining problem is that I do not see any OSD menu. Usually
when I activate the OSD, I get a random square (often white) somewhere,
sometimes on the top left corner of the screen. It turned out that this
square is being written by osd.c. cSoftOsd in softdevice is derived from
cOsd. It overrides cOsd::SetAreas() so that it can ignore OSD events
when the output is suspended. Otherwise, it is just calling the method
in the base class. You can see the code at
http://cvs.berlios.de/cgi-bin/viewcvs.cgi/softdevice/softdevice/SoftOsd.c?view=annotate
From the Softdevice diagnostic messages and code I understood that the
Matrox MGA450 might not support an alpha channel on the primary layer
that is overlaid on top of the back end scaler (BES) layer. Instead, it
could simply be a color key (black is transparent). The pixel format of
the OSD seems to be 32bpp nevertheless.
The problematic code is in cOsd::SetAreas(), vdr-2.0.4/osd.c:1811
onwards:
isTrueColor = NumAreas == 1 && Areas[0].bpp == 32;
if (isTrueColor) {
width = Areas[0].x2 - Areas[0].x1 + 1;
height = Areas[0].y2 - Areas[0].y1 + 1;
cPixmap *Pixmap = CreatePixmap(0, cRect(Areas[0].x1, Areas[0].y1,
width, height));
Pixmap->Clear();
bitmaps[numBitmaps++] = new cBitmap(10, 10, 8); // dummy bitmap for
GetBitmap()
}
else {
If I change the assignment to isTrueColor=false, the square goes away
and I will get the familiar gray rectangles on the screen (from the
"else" block that I omitted above). For example, when I press OK, there
will be a rectangle at the bottom. Unfortunately, the rectangles are all
gray, no other colours or text in them. According to strace, fontconfig
and some *.ttf fonts are being loaded, so I suppose that the graphics
are being generated, and the problem is somewhere in cOsd or cSoftOsd.
Could someone help me get more than the rectangles on the screen?
Best regards,
Marko
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
