CodeCube.NET

If all goes well, I should have a new version of scurvy media out sometime this weekend.  stay tuned for more details

So now that I’m looking @ the next features for Scurvy Media … the issue of Audio comes up.  Currently, if you add a video to play in your XNA project, it will be silent.  Now, the problem is that the “audio pipeline” is completely separated from the content pipeline. 

Even though technically speaking, the XACT project is added and processed by the content pipeline … the audio is still gated by the requirement of wave forms being added to the XACT UI.  Thus, being able to add audio items programmatically is an issue.

I toyed around with the possibility of extracting the .wav and programmatically creating an xact project from the video importer … but comments on the forums suggested that having more than one AudioEngine instance wouldn’t be smart.  So it looks like in the meantime, I’ll have to simply provide a separate tool to extract the audio from the .avi, and then an API to sync up the audio playing with the video.

If anyone has any ideas, they’d be very welcome

despite the refactoring of the scurvy media pipeline architecture, trying to add large videos will result in an out of memory exception.  This is because under the covers, they’re using a MemoryStream … so even though *I’m* not using a lot of memory … they still are.

https://connect.microsoft.com/feedback/ViewFeedback.aspx?FeedbackID=323222&SiteID=226

I filed the above bug report … and I admit even in that bug report that my pipeline could just avoid writing so much data and I am planning on improving that … as soon as I can figure out how to write and then set the data texture data using dxt1 compression.

But I figured I’d file the bug report anyways as there could be some other reason to write lots of data to .xnb

If you haven’t already seen it, the Scurvy.Media source code contains a sample project.  It’s not very complex, just a simple example of how to use the API to display a short video using the SpriteBatch.

http://www.codeplex.com/ScurvyMedia/SourceControl/ListDownloadableCommits.aspx

Since you can download the whole repository from the link above, I didn’t bother to make a source code release.  But if you download the latest commit, you’ll see the VideoSample project.

Enjoy!

http://www.codeplex.com/ScurvyMedia

The binary release now supports GS 2.0, and sports a cleaned up pipeline architecture that has a better memory footprint, and a cleaner extensibility model.

Next on the list is audio integration and perhaps a few bugfixes.

Please note: currently, the release is only for x86, I haven’t tested the code on the 360 quite yet. More on that soon.

If you receive this error when calling the update method on the Video class:

The operation was aborted. You may not modify a resource that has been set on a device, or after it has been used within a tiling bracket.

Then this thread might offer some insight into how to avoid it:
http://forums.xna.com/thread/35536.aspx

I got around it by putting this line of code to null out the texture on the video card before the update method gets called on the Video class in the sample project:

GraphicsDevice.Textures[0] = null;
vid.Update();

Finally! the scurvy media video-to-texture library finally works in xna 2.0.  I checked in the changes that show off the new features like the video processor that lets you choose between streaming and in-memory playback mode (in the Branches folder). 

thanks for all the feedback that I’ve gotten so far, and for everyone’s patience I do this on my spare time, so it’s pretty satisfying when I finally get somewhere. 

Now that I finally got it to work, I still need to clean up the code a little bit and merge the branch back into mainline.  Once I do that, I’ll put together a binary release.

hmm, interesting … just figured out that in the latest build (not released, just in source control) of the scurvy media library, any input AVI must not be readonly.  Not the worst bug in the world, but a bug nonetheless.

I created a bug item:

http://www.codeplex.com/ScurvyMedia/WorkItem/View.aspx?WorkItemId=3245

I fleshed out the content writer and reader in my latest checkin to codeplex.  I’m almost done, there’s just a little bit of work left to do on the reader, then time for testing, and a bit of re-organization of namespaces and types.  I anticipate having it ready in another coding session or two.

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.