1. You can call the function User::ScreenInfo(). This will give you a memory location of the screen memory for real hardware and under WINS it will give you a Win32 handle to a bitmap. You can use these to draw directly to the screen.
2. You can create a CFbsScreenDevice and then use it to create a CFbsBitGc, which will then allow you to draw to any part of the screen.
Although I've not tried the first method and so it might turn out to be faster in general I would recommend the 2nd method because:
a. You don't have to know how the screen memory is laid out.
b. You can use the same code for WINS and MARM builds.

There are various problems with these methods:
i. You will need to know the current screen mode (color depth) of the screen. This isn't too difficult to find out, but will need it in order to create the screen device or to know how the memory is laid out.
ii. The current screen mode may change under your feet. There is no way to fix this other than arrange for it not to happen (see next point of a way to do this) or check every now and again to see if it has changed, however, by the time you detect it will probably be too late.
iii. WSERV brings up a important warning dialogue in front of all the running apps (such as a battery low message), this will then immediately get blitted over by the direct drawing or at least it is likely to seriously interfere with it. Since whatever the dialogue does is likely that you will not get to read it I suggest the best solution to this problem is to arrange for the dialogue not to come up in front of you in the first place. The best way to do this is to create yourself a high priority group window and then create a blank (or other type of window) covering the part of the screen that you want the video to appear in.
iv. The screen size mode may change (that is the same as a flip on the R380s).
v. In GT6.0 and ER5 there is a WINS bug which means that you don't get exactly what you want displayed when using the CFbsScreenDevice method. This is because the device that you create for the video and the device that WSERV create will both have there own off screen bitmap which will be drawn to the WINS32 window obliterating what was drawn into the other off screen bitmap. This bug is fixed in GT6.1.

There is another solution that does not suffer for any of these problems (or at least has workarounds for them), this is to wait for GT6.2 which will include a new WSERV feature which sets up for you a CFbsScreenDevice and CFbsBitGc and allows you to do direct draw to the visible area of a window and also tells you when to stop because the window's visible area has changed.