Smelter
12th April 2007, 07:00
I've stepped back from the NSV format and built a customizable source filter for use with nsvcap.
This build does 30 fps only so if your nsvcap framerate setting is not '30 it won't render in nsvcap. This shall be addressed in future builds, but for my purpose this is complete. If you want , leme know I'll give up the source and you can enlarge or whatever.
What makes this 'fake' capture device different?
Well not much really. I took my nsvport cam idea a step further.
'RGBcam' will monitor port 6226 for a CSender object in your application. Until I learn to use 'named pipes' its sockets :p
CSender will 'presentimage(char* buffer,int size)'
char *buffer is the pointer to 320*240*32 bit BI_RGB bits.
CSender hands them to RGBcam.
RGBcam will handle disconects and new conects on the fly.
If you develope more than one image provider with CSender, you can start and stop them, change them up while RGBcam tools away!
You can use RGBcam with no input also, either streaming the last good image recieved or black at the start.
I have included an extreamly small demo that captues the screen and sends it to RGBcam.
I have included a demo that captures DirectX rendering into RGBcam. its based on another sample that originally wrote the rendering to an avi file, but I intercepted the bits before compression :)
the directX demo 'buffer movie' needs your mouse movements above the window to make a dynamic movie sample. nsvcap will wait for this mouse action ;)
You can fire up one or the other sample app.
Dont panic, 'Buffer movie' wont appear unless RGBcam is loaded, as its a minimal sample.
the 'dib' test screen capture is automatic frame generation.
This build does 30 fps only so if your nsvcap framerate setting is not '30 it won't render in nsvcap. This shall be addressed in future builds, but for my purpose this is complete. If you want , leme know I'll give up the source and you can enlarge or whatever.
What makes this 'fake' capture device different?
Well not much really. I took my nsvport cam idea a step further.
'RGBcam' will monitor port 6226 for a CSender object in your application. Until I learn to use 'named pipes' its sockets :p
CSender will 'presentimage(char* buffer,int size)'
char *buffer is the pointer to 320*240*32 bit BI_RGB bits.
CSender hands them to RGBcam.
RGBcam will handle disconects and new conects on the fly.
If you develope more than one image provider with CSender, you can start and stop them, change them up while RGBcam tools away!
You can use RGBcam with no input also, either streaming the last good image recieved or black at the start.
I have included an extreamly small demo that captues the screen and sends it to RGBcam.
I have included a demo that captures DirectX rendering into RGBcam. its based on another sample that originally wrote the rendering to an avi file, but I intercepted the bits before compression :)
the directX demo 'buffer movie' needs your mouse movements above the window to make a dynamic movie sample. nsvcap will wait for this mouse action ;)
You can fire up one or the other sample app.
Dont panic, 'Buffer movie' wont appear unless RGBcam is loaded, as its a minimal sample.
the 'dib' test screen capture is automatic frame generation.