Board index » delphi » Screen Capture bug in 95/98

Screen Capture bug in 95/98

I tryed to make a program that capture the video windows of RealPlayer
and what happened is very weird on 95/98 while it does work correctly on
NT4.

The weird thing is when the capture is done I display the resulting
captured window on an Timage component and all I see is a black window
unless I move my application to make my display image windows overlap
the realplayer windows. In this case, the section of the realplayer
windows that intersect with my display image window show some image
part. This is updated each
time I move my application.

The weirdest thing is that if I save my image to a BMP format and load
it with another application like PainBrush the same thing happen with
this application, the picture is black unless overlapping with the
realplayer.

I have tryed many different screen capture software and library and all
had the same behavior.

Does anyone understand what's happening?

Thanks

Vital Tremblay

 

Re:Screen Capture bug in 95/98


Quote
> The weird thing is when the capture is done I display the resulting
> captured window on an Timage component and all I see is a black window
> unless I move my application to make my display image windows overlap

...

As far as I know, it's so, because realplayer ( and many of other video
apps ) do not bring images to screen using GDI/BitBlt operations. Instead of
this, they are using overlay technique.

Most modern vga compatible cards are capable to display areas, readen from
different memory areas within video card. A memory area represents normal
screen ( "desktop" ), another area contains overlayed area ( "video screen
of realplayer" ). Video hardware is capable to scale, mix with desktop and
event alpha blend video overlays.
(further information is available in msdn)

You cannot get data directly from such an overlay window, since your bitblt
request ( programmatically or just pressing Print/Screen) are operating on
desktop, meanwhile desktop does not contains actual video data. Actual video
data is send over a separate memory area to overlay window.

However, assuming you are using Media Player/MCI to display video,
increasing it's width and height by one pixel ( letting renderer to scale
it ) may help you to grab it thru GDI... ( hoping your video card/codec
cannot co-operate on hardware scaling. If so, it will be scaled by software
and post to the screen using normal GDI methods. In that case, standart
capturing should work. )

As another alternative, you may deal with codec directly. In this situation,
codec will provide you video frame by frame.

By the way, latest version of winamp ( V2.76 ) has a "visualization studio",
which is a good example about utilizing overlays.

Regards,

Re:Screen Capture bug in 95/98


Quote
exception wrote:
> As far as I know, it's so, because realplayer ( and many of other video
> apps ) do not bring images to screen using GDI/BitBlt operations. Instead of
> this, they are using overlay technique.

Does it has a way (using directx or something else) to get the true pixel of the
screen instead of a context?

Quote
> Most modern vga compatible cards are capable to display areas, readen from
> different memory areas within video card. A memory area represents normal
> screen ( "desktop" ), another area contains overlayed area ( "video screen
> of realplayer" ). Video hardware is capable to scale, mix with desktop and
> event alpha blend video overlays.
> (further information is available in msdn)

Thanks I will see if I could get something there.

Quote

> You cannot get data directly from such an overlay window, since your bitblt
> request ( programmatically or just pressing Print/Screen) are operating on
> desktop, meanwhile desktop does not contains actual video data. Actual video
> data is send over a separate memory area to overlay window.

> However, assuming you are using Media Player/MCI to display video,
> increasing it's width and height by one pixel ( letting renderer to scale
> it ) may help you to grab it thru GDI... ( hoping your video card/codec
> cannot co-operate on hardware scaling. If so, it will be scaled by software
> and post to the screen using normal GDI methods. In that case, standart
> capturing should work. )

That won't help to much since too impreditable.

Quote

> As another alternative, you may deal with codec directly. In this situation,
> codec will provide you video frame by frame.

Yes that could be a way, provided I could get the doc.
Thanks for all your informations

Vital

Other Threads