Here’s the changelog if you’re interested:

• Introduced TestStatusReporter to make reporting test status easier. DefaultReporter writes to the debug output, while the test console app implements a custom ConsoleReporter that writes it out to the stdout instead.
• Added additional methods and overloads to the Assert class for more assert options and the ability to replace your own custom TestStatusReporter instance.
• Added XBox version of Scurvy.Test assembly
• Upgraded solution to visual studio 2008
• now using SVN bindings instead of TFS Explorer
• Upgraded sample xna project to GS 3.1
• Added custom XNA test status reporter to sample project

• Support for customized Avatars
• Support for Xbox LIVE Party features
• Video playback
• Updated audio APIs for “fire-and-forget” scenarios
• Support for XACT3
• Automatic XNB serialization
• XNA Framework multi-targeting in the Visual Studio 2008 and/or Visual C# 2008 Express Edition IDE
• Downloadable content for Xbox LIVE Arcade titles that use XNA Game Studio 3.1
• Consumer notifications when an Xbox LIVE Community Game that they have purchased has been updated

Of course, the video playback feature stood out for me, as it would seem that it will affect the Scurvy.Media project.  I’ve been getting some questions on the matter so I figured I’d just put my current thoughts out there.

Basically, I think it’s great even if it ends up making the library completely obsolete.  I imagine that they will have ways around some of the roadblocks I encountered such as large filesize issues, and texture compression.  Depending on how their feature is factored, there *may* still be a place for Scurvy.Media … for example, I believe I read somewhere on the forums that it will only support WMV (don’t quote me on this, I may have misread or am not remembering right).  But if this is the case, and they’ve factored some level of extensibility into their API, then Scurvy.Media may add support for AVI videos.

In the end, I’m quite happy to see this and the other features coming out … looking forward to giving the beta a shot when it’s announced eventually

You can find the latest download here: http://www.codeplex.com/ScurvyMedia

There aren’t any new features … the reason this got caught up in the first place is because I was trying to have zune support in before I released it and then I got busy.  Oh well, c’est la vie … I still have to work out the specific surface format and data format that will work on the zune.  I think I’m close …

Please let me know if you encounter any issues with this version thanks!

Hi Joel,

We are currently doing a project in XNA and are trying to inventory the abilities to play video in game. We found the scurvy media project to be the one that is the most advanced. Only on your codeplex site it is not really clear what the requirements are of the movie to be played. so far i’ve gathered
- it should not be compressed video (xvid / divx)
- framerate game = framerate video

could you please respond to tell me if the information i’ve gathered is correct?

That’s partially correct  

• Theoretically, as far as compression goes, you can use whatever codec you want … as long as the developer’s machine has the same codec.  I’ve heard some reports of certain videos not working for certain people, but I’ve no way to determine whether they have the correct codec installed   Beneath the scenes, the content pipeline portion uses this library to decode the AVI video.  So as long as that library can read it (and it just uses your machine’s codecs), then scurvy.media should be able to translate it to the runtime format.
• As far as the framerate goes … as long as your game’s framerate does not drop below the framerate of the video, the video will play at the correct framerate.  It takes the video’s length and frame length into account … it’s just that if the game delays an update call to the video, there is no built in recovery mechanism for it to catch up.

A few more things to note … the pipeline is unfortunately sensitive to video size.  Because of the way that it decodes the video into essentially a sequence of textures, the size can tend to be a little large.  This would be fine if it was able to get on disk, because of the way that the video is streamed from the file system.  But unfortunately, the content pipeline buffers the entire contents of one .xnb file in memory first before writing to disk … so if this hits some limit, it will throw an out of memory exception.  I usually just suggest that users break down the video into multiple ones and play them sequentially if it’s too long.  I know it’s less than ideal, but it’s the workaround for the moment.

I wish your project the best of luck … please keep me informed of your progress using the library if you end up using it as I’m always looking for ways to improve it and user’s feedback is always instrumental in this.

But here’s one problem I see with it … I can almost guarantee that very few people will use XACT once 3.0 is released.  Considering that I do not see very much community involvement from the XACT team, or any individuals (where are the xact tutorials, where is the xact team blog?), I fear that an atrophying user-base will kill the project for future releases.

Much of the feedback I see about XACT seem to mimic a lot of the negative feedback of the content pipeline.  Thankfully, the XNA team hasn’t given in and allowed runtime loading of content files.  The second they enable that is the second that 99% of people move their projects to import/loading everything at runtime (and thus, introducing longer load times into their games).  By limiting that choice, I believe they’ve done the community a favor because at this point, lots of people are very familiar with building custom content pipeline extensions.

so I guess what I’m trying to say is, if you’re an XNA developer … fire up XACT, and give it some love

ps. I suppose this would be an ironic time to announce that once I upgrade Scurvy.Media to 3.0, I’m going to experiment with automatically importing the video’s audio stream using the new SoundEffect/Song APIs

After a large amount of experimentation, and tons of help from the guys over on the #Xna IRC channel, we were finally able to figure out the problem. To explain the solution, I must first explain a tiny bit about the architecture of the Scurvy.Media content pipeline.

1. Decode each frame of the video as individual textures. The pipeline currently only supports AVI video using the AVIFile library from CodeProject.
2. Write the contents of each frame sequentially into one large .XNB file through the content writer.
3. At runtime, open a stream (and keep it open), and read each texture one at a time in a separate thread.
4. use .SetData to set the contents of a texture based on whatever the current Frame is.� Technically speaking, there are two textures at play for the purpose of double buffering … but that’s largely irrelevant to the topic at hand

So the confusing part was that the code ran perfectly on windows, but on XBox the colors were all messed up.

Now that I’ve explained the architecture, I’ll explain the solution to one of the issues.� Mainly, it’s the fact that the color order on the xbox platform is *different* than it is on windows.� Why that is I don’t know, I wasn’t able to find very many sources of information on this, but c’est la vie

XBox:

• RGBA

Windows:

• BGRA

To get around this problem, I simply had to transpose the color channels as I imported the video when compiling for the xbox platform.

byte[] xpix = new byte[pix.Length];
for (int i = 0; i < pix.Length; i += 4)
{

��� int first = i, second = i + 1, third = i + 2, fourth = i + 3;
��� xpix[first] = pix[third]; //x=red
��� xpix[second] = pix[second]; //x=green
��� xpix[third] = pix[first];//x=blue
��� xpix[fourth] = pix[fourth];//x=alpha�
}

b.SetPixelData(xpix);

the code snippet above takes a byte array that uses four bytes per channel.� And it just puts it into a copy of the byte array.� Technically, I could have used the same array and just rearranged the byte values as I go … but perhaps that’s an improvement for another day.

But Avast! There still be problems on the high waters!

After making that change, the colors were still not right.� What we eventually realized is that I was writing byte data directly from windows (who’s x86 architecture is little-endian), to be read from the xbox (who’s powerpc architecture is big-endian).

Sooooo … the answer was this:

byte[] xpix = new byte[pix.Length];
for (int i = 0; i < pix.Length; i += 2)
{

��� int first = i, second = i + 1;
��� xpix[first] = pix[second];
��� xpix[second] = pix[first];
}

output.Write(xpix.Length);
output.Write(xpix);

Right before writing the byte array to disk … I flip every other byte.� Once I did that, the video was alight with correct coloration

Again, a huge thanks to the guys on the #xna IRC channel.� This wouldn’t have been possible without them.

known issue: compiling a video with compression will produce a distorted video. This issue is under investigation, and will ideally be fixed for the next release.

• Importer now throws an exception if the .avi file is readonly to avoid any confusion over why the import won’t work.
• Video now has an “End” event that is raised when the video reaches the final frame.  This can be used in cases where you need to know when the video has come to an end (like an Intro video).
• Improved the video streaming code to read fully into the byte array buffer.  Before, I was just calling .Read on the stream, which is not guaranteed to read the full amount requested.

But that’s not a requirement.  I won’t go into the properties and virtues of a good logo, since if you’re the kind of person that could come up with a great logo, you’d know them better than I.  Though if I had to give any direction (aside from the scurvy bones logo above), I’d say that I really love farseer’s logo:

It’s so simple, and iconic … and explains exactly what the farseer physics library is all about.

What will you win?  aside from my undying gratitude … the winner will be forever recognized (with a link and info on any scurvy media distribution site) as the logo’s designer.

Download

https://www.codeplex.com/Release/ProjectReleases.aspx?ProjectName=ScurvyMedia&ReleaseId=8615

Release Notes

• XBox 360 Project Support!
• Streaming playback mode is now multithreaded.  On xbox, it defaults to Core#2.
• Texture setting is now double-buffered to avoid stalls.
• Internal video related functionality has been moved to the Scurvy.Media.VideoModel namespace to avoid crowding up the root Media namespace.
• Fixed InvalidOperationException bug.  Description here. This was a side-effect of the double buffering feature above
• Improved runtime allocation profile slightly by removing debug write statements (lots of string allocation).

Known Issues

• Using “In Memory” playback type throws an exception. This will be fixed in a follow up release.
• Using compression partially garbles the texture playback.  There is an active thread on the XNA forums about this here.  Once resolved, the content pipeline will be able to support larger videos, and have a smaller disk footprint of the processed XNB file.
• Importing a large video will still throw an OutOfMemoryException.  I have a bug logged on the XNA Connect site.  However, it has been closed with no hint as to whether it was deferred, or solved.  If the compression issue noted above is resolved, it will mitigate this issue.