Puzzles with yuvoverlay

what is overlay ? Is it a function of graphic card or a function of video capture card or both?
Someone told me :
overlay means transfering video from capture card directly to video memory without cpu’s involvement.
Then according to this explaintion ,it should be the function of both.
But from doc for SDL, I can also see yuvoverlay api. Does it mean without capture card ,SDL still can provide the overlay function.

From this point, overlay should be the function of video card .
Does overlay means DMA between capture card and video card or some color space conversion by video card ?---------------------------------
Do You Yahoo!?
??? Yahoo! ???

I have looked into the Kobo Deluxe sources to find out what the semi-triple-buffer mode is, and found this piece of code in graphics/gfxengine.c:

  case GFX_BUFFER_SEMITRIPLE:
	for(i = 0; i < dirtyrects[backpage]; ++i)
		SDL_BlitSurface(softbuf, &dirtytable[backpage][i],
				screen, &dirtytable[backpage][i]);
	dirtyrects[backpage] = 0;
	i = backpage;
	backpage = frontpage;
	frontpage = i;
	sync();
	SDL_Flip(screen);
	break;

What I’m wondering, is this: The call to SDL_Flip(screen) will just halt the program until the next vertical blank on Win32 systems using DirectX
and the sync() call will be doing nothing on builds for this system, right? So, that means, that the semi-triple-buffer method does not give you
any advantages over double-buffered for a constant fps, since the program is still waiting for a vbl when doing the SDL_Flip() call. Except for
alpha-transparent blits and so on being faster this way, since you are blitting from software to software, I do not see an advantage of this method
above a direct invalidaterect() method with only one hardware buffer.

I really need an answer on this subject, since I am at a loss here with my CSDL project. It seems that triple-buffering on a Win32 system using
DirectX is not possible with SDL, and that would really prevent CSDL from being a workable solution. Could anyone enlighten me?

I have looked into the Kobo Deluxe sources to find out what the
semi-triple-buffer mode is, and found this piece of code in
graphics/gfxengine.c:

case GFX_BUFFER_SEMITRIPLE:
  for(i = 0; i < dirtyrects[backpage]; ++i)
  	SDL_BlitSurface(softbuf, &dirtytable[backpage][i],
  			screen, &dirtytable[backpage][i]);
  dirtyrects[backpage] = 0;
  i = backpage;
  backpage = frontpage;
  frontpage = i;
  sync();
  SDL_Flip(screen);
  break;

What I’m wondering, is this: The call to SDL_Flip(screen) will just
halt the program until the next vertical blank on Win32 systems using
DirectX and the sync() call will be doing nothing on builds for this
system, right?

Correct. (Actually, sync() isn’t implemented at all in current version.
The only reason it’s there is that I once had a Linux/gcc/x86/VGA-only
retrace sync hack in there.)

So, that means, that the semi-triple-buffer method does
not give you any advantages over double-buffered for a constant fps,
since the program is still waiting for a vbl when doing the SDL_Flip()
call.

Wrong. The triple buffering mode is actually meant only for targets
that support true h/w surfaces and page flipping (in fact, it will
disable itself automatically if that isn’t available), and it’s primary
function is to avoid doing read-modify-write rendering (like alpha, which
Kobo Deluxe uses) directly into VRAM.

Except for alpha-transparent blits and so on being faster this
way, since you are blitting from software to software, I do not see an

The problem is that Kobo Deluxe does use alpha blending to quite some
extent, especially in the scaled/filtered modes. That’s why I implemented
SemiTriple in the first place. (You wouldn’t believe how slow the first
verisons, without SemiTriple, were on DirectX… heh)

advantage of this method above a direct invalidaterect() method with
only one hardware buffer.

You’re forgetting that SemiTriple avoids tearing by using h/w double
buffering, and that it takes advantage of retrace sync where available -
which is not possible with a single buffered h/w screen. (At least not
with SDL, and not at all on many targets.)

I really need an answer on this subject, since I am at a loss here with
my CSDL project. It seems that triple-buffering on a Win32 system using
DirectX is not possible with SDL, and that would really prevent CSDL
from being a workable solution. Could anyone enlighten me?

SemiTriple is quite different from “real” triple buffering. To get the
benefits of both, you’d have to implement “SemiQuadruple”, which would
effectively be “SemiTriple on top of a triple buffered screen”.

SemiTriple only helps if you need to do read-modify-write rendering, and
still want h/w pageflipping. (There’s no way to have SDL give you a h/w
double buffered screen AND a software shadow surface, AFAIK.)

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Wednesday 06 March 2002 23:29, Martijn Melenhorst wrote: