C++ Sample 'Playing nsv video WITHOUT winamp'

[Smelter]

Ok kiddies, the extra class is provided AS IS and PUBLIC DOMAIN. The class NSV handles the dirty work of unpacketing a file. any file. and provides pointers to every frame member and data buffer. Forget the header. This sample wraps the NSV class into the ever popular 'VCAM' sample (warning same guid), and allows any direct show savey person/programer to play the video content, provided the appropriate VFW decoder is installed!

I imagine its only a little bit of time before another output pin is added and the audio is unlocked.

[wildex999]

Smelter, do you have any IM(AIM, MSN etc.) that i can talk with you on?

*I'm suggesting a little co-working on NSV stuff =P*

[Smelter]

sure ill talk but sorry no IM

Ill be at work for a few hours . Im in P.S.T.

[wildex999]

I'll send you a PM with something for you to look at atleast =)
P.S.T?

If you do get any IM, please tell me

[Smelter]

Model 3
Every stream has a source. Here are the sources and the source and destination base classes.

Working on the destinations.

Separated file and port source nsv.

The implimentation of actual 'base classes' in Model 2 did nothing but create a need for extra class writting.

I wanted a single object to represent nsv Source. While possible, the simpler solution for me is to write two separate classes of nsv source.

A simpler bass class exist now for sources and sinks to use in broadcasting macros.

Also, primarily I didn't want to clutter the constructors with arguments just to get files and ports out of the same class. ;p

The simplicity of bits streams does not require so much writing just to be handled.

Two fully developed classes will save writing and other source/proxie types can be added as needed.

The Original NSV file/port class retains the default port behavior and renamed NSVd for 'disc'.

The new port class is named NSVp for port.

The new port class has been broken up into overidable functions created during the 'base class' development and testing.

simple test illustrated.

[wildex999]

lol, looks like you will release something near a NSV lib before me =P I Still haven't figured out the thing with the player, and my long school days make me too lazy outside weekends, to work much on anything NSV.

Owell, good luck going

[Smelter]

heh, Im not writing a lib, Im defining objects. and dont want to call the lib. The objects will do it all. I'll just populate 'form' controls with their properties!

[Smelter]

All the input at the nsv_InPorts are from NSVCAP

The green boxes are the targeted application model, which could be started now with the basic types.

[Smelter]

// This illustrates opening two ports and two files. Writes either to either.

code:


NSVp * nsv, *nsv2;

main()

{	

	int i;



	nsv=new NSVp("81");// waits for frame.

        nsv2=new NSVp("66");// waits for frame.









	NSV_Writer out("c:\\out.nsv");//Open up destinations.

	NSV_Writer out2("c:\\out2.nsv");

	

	do {

	out.CastFrame (nsv, out.output );

//write one source to as many destinations as you want.

	out2.CastFrame (nsv, out2.output ); 

	nsv->StepFrame ();

	nsv2->StepFrame ();

//buffer flowing even if frame not used, unless it is a 

//fileSource!

	i++;

	}while (i<200);

	i=0;

	do {

	out.CastFrame (nsv2, out.output );//Switch it up!

	out2.CastFrame (nsv, out2.output ); 

	nsv->StepFrame ();

	nsv2->StepFrame ();

	i++;

	}while (i<200);

	

}

Buffer on port 81 fills up while waiting for first frame
on port 66. Threads must be managed to achieve the results
wanted. The marshal is still buggy, but if you want the writter to play with, lemmee know. I probably wont release another update till it is working, and the outport is connecting to the DNAS. Anybody wana help?


// And the next samples will be actual form applications.