CodeCube.NET

The next version is coming along nicely now I just checked in some good work around the pipeline refactor. things are much simpler now, and will be much more memory friendly … which will allow you to use larger videos.

1. The pipeline API is much simpler now. It will be much easier to extend in the future. I have an interface (IVideoContent) which the importer will return. This IVideoContent will be responsible for actually doing the work of loading the frame data for the content writer to write to disk.Particularly of interest is the fact that IVideoContent.Frames property returns an IEnumerable<Texture2DContent>. Using the yield keyword allows the writer to do it’s work one frame/texture at a time … and then it’s free for the garbage collector to collect.
2. There will be no need for a custom processor … the pipeline will just use the pass through processor.
3. In-memory vs Streaming will simply be a parameter on the importer.
   note: haven’t tested this yet, but you may not be able to parameterize an importer (if I’m reading the docs right). If that’s the case, then point 1 is moot, and I’ll simply have a processor that will let you choose options like in-mem vs streaming, and some other things like image formats.
4. Runtime API won’t be affected. as of yet, I don’t have any plans on changing that API, so code that you’ve already written won’t have to change.

So far, all the feedback I’ve gotten (aside from memory issues with large videos) has been positive. Haven’t gotten any bug reports, which leads me to believe that things are, at least, stable This is good, and makes me think that I need to put a priority on reaching a feature complete state.

The only major feature I can think of that’s missing is audio … so I’m thinking that this is what I will work on next after this version is out the door. However, if you have any requests, or ideas on what you’d like to see in the next version pipe up in the discussion forums.

I’ve checked in the initial check-in of the upgrade project to the following location in the codeplex repository:
$/Branches/2.0 Upgrade

I have to admit that I am loving the fact that I can now use the integrated source control in the big boy version of VS.  Since XNA 2.0 has handy new parameterized processors, I figure I’ll just do my planned refactors to the pipeline in 2.0.

I don’t have a binary release on this one yet, but stay tuned

In case you hadn’t heard already:
http://creators.xna.com/beta/betahome.aspx

Definitely looking forward to checking out the new “Net Rumble” starter kit … which showcases some of the new multiplayer APIs.

I decided to make an “official” binary only release which can be found here. Technically, the only new feature that wasn’t there before is a slightly more informative exception that gets thrown if you try to load a streaming video without the VideoContentManager.

Hopefully this will encourage library use, and potentially some feedback/bug reports now that you don’t have to compile the code before using it

If you’re curious about the format of the build number, I’ve found from recent experience at work, that having an informational build number can be quite useful. this is basically the format:
<major>.<minor>.<yyyy>.<mmdd>

The only reason it’s not major.minor.revision.timestamp is because there is a bug in msbuild.

On, and also … I’ve also checked in a new branch of the code. This is where I’ll hack n’ slash the pipeline code to support larger videos. The problem of course is that currently, the importer will load the whole thing into video, which, on a large video would starve your computer of memory. It will ideally just load the right kind of importer content type, and only read each frame at “write time” so that only one frame at a time would need to be in memory (or whatever the GC deems appropriate.

Slowly but surely, I’m working on this … by hook or by crook

ps. now that I’ve had to disable comments, if you have feedback on this lib, just hit up the discussion forums on the scurvy media codeplex site.