On Tue, Sep 05, 2006 at 06:33:51PM +0200, Stefan Lucke wrote:
> I think I found the bug. My first thought from this morning lead my to the
> direction, but it _only_ fixed the OSD drawing and _not_ the shrinked
> picture above the downscaled 16:9 rect. This rect is from clear background
> operation.
>
> Attached patch fixes both: OSD and clear background.
Thank you, Stefan! I tested this on fresh DirectFB and DFB++ CVS, and
it really fixes those issues.
The two problematic clips look correct now. I tried setting
cDFBVideoOut::fieldParity to 1 in the constructor, but it made them
look worse. The BBC News clip looks completely okay now, but the clip
I made last week may merely be suffering from dropped frames now
(due to very big movement).
Now I only have one wishlist item left for DirectFB on Matrox cards:
get rid of that busy-waiting in IDirectFBSurface::Flip() by implementing
some ioctl() calls to make it interrupt-driven. Meanwhile, this patch
seems to substantially reduce the CPU consumption on my system:
Index: video-dfb.c
===================================================================
RCS file: /cvsroot/softdevice/softdevice/video-dfb.c,v
retrieving revision 1.70
diff -p -u -r1.70 video-dfb.c
--- video-dfb.c 5 Aug 2006 17:51:25 -0000 1.70
+++ video-dfb.c 6 Sep 2006 20:37:47 -0000
@@ -1300,6 +1300,7 @@ void cDFBVideoOut::ShowOSD ()
scrSurface->SetBlittingFlags(DSBLIT_BLEND_ALPHACHANNEL);
scrSurface->Blit(osdSurface, &osdsrc, 0, 0);
}
+ usleep(1000);
scrSurface->Flip(NULL, DSFLIP_WAITFORSYNC);
}
@@ -1499,6 +1500,7 @@ void cDFBVideoOut::YUV(sPicBuffer *buf)
}
//scrSurface->Flip(NULL, (setupStore->useMGAtv) ?
DSFLIP_WAITFORSYNC:DSFLIP_ONSYNC);
+ usleep(2000);
scrSurface->Flip(NULL, DSFLIP_WAITFORSYNC);
}
else
According to "top", the vdr process consumes 52 to 67 per cent of CPU
(900 MHz Celeron).
I plan to make some OProfile measurements this weekend. At the very least,
I will measure the impact of colour space transformation (i.e., let
-vo dfb:mgatv show wrong colours by pretending it uses the native output
colour space of ffmpeg).
Marko
_______________________________________________
Softdevice-devel mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/softdevice-devel
