Ok, here's my story.  So I'm working on the next version of Scurvy Media.  One of the things that I'd finally like to get in is the storage of texture/frame data as DXT compressed textures.  Unfortunately, the math required to read those textures has escaped me thus far.  I'm sure I'm missing something fundamental, so I figured I'd finally just ask those who know much more than I :-)

Here's what I have:
First, in my importer/processor, I load a Texture2DContent object that I then convert to a Dxt3BitmapContent pixel format

Then, in the content writer, I write each "frame" to the XNB file

Then, at runtime in the content reader, I stream the pixel data out of the file stream and try to set it to the texture:

Now at the risk of exposing my ignorance, I'm sure the problem lies in the way that I am reading the data from the stream.  A good friend of mine helped me write that piece in the first place (for which I am deeply thankful :-P ).  So the question is, what's the right way of reading out the dxt data and setting it to the texture?

Some stats:

• Video resolution: 160 x 120
• Size of the byte array that gets written to the XNB for one frame: 19200
• Size of the Bgr565[] Array that I'm using: 9600
• If I comment out the 'ConvertBitmapType' line, this all works without a hitch.
  

Again, I will reitorate, I'm 100% certain that I'm going about this the wrong way ... some guidance would be very much appreciated :-)  Thanks in advance!!

This approach looks sane to me, although I'd probably use DXT1 rather than DXT3 format (assuming you don't have alpha channels in the video, that will only require half the output size).

DXT formats store data in 4x4 blocks. DXT1 uses 8 bytes per block, while 2-5 use 16. It's tempting to say DXT1 uses half a byte per texel and the others 1 byte per texel, but the block structure is important if your texture has mipmaps, since the < 4 size mip levels get rounded up to an entire block.

So it makes sense that in DXT3 format, your 160x120 image will require 40x30 blocks * 16 bytes per block = 19200 bytes.

I don't know why this would fail using a Bgr565 array (I've never tried that) but I'd be inclined to read the data in and set it from an array of 19200 bytes, rather than using the packed vector type here. Theoretically both should give the same result, but why complicate things by using a specific format that doesn't actually match the type of your data?

What actually goes wrong when you run this code?

I get an InvalidOperationException with the following message:

"The size of the data passed in is too large or too small for this resource."

However, taking your advice, I changed it so that the surface format of the texture is dxt3 (I'll switch to using dxt1 as per your suggestion, but i figured I'd take it one step at a time :-) ), and also to just pass in the bytes directly.  I now get something rendering :-D however, it's a little funky.



The top 1/4 of the video plays perfectly, but the bottom part of the video looks all jacked up as in the screenshot above.  Any thoughts as to what the culprit might be?

I hate to be tacky and bump my own post ... but **bump** :-)

but seriously ... at a very minimum, I'd love to hear some thoughts about how I might debug this.  to review, it works perfectly fine when I don't convert to dxt.  But switching to dxt gives me a texture like the screenshot above.

Once I get this, scurvy media will just about be ready for a new release that will definitely support larger videos (since the frames are now compressed).  I've gotten the disk streaming code multithreaded, and am just about done double buffering it to avoid stalls.  I also have it running on the xbox 360, though I need to do some perf tuning there.

help me obi-wan, you're my only hope! :-P  thanks!!

Beats me!

My first guess would be that you're somehow only setting 1/4 the neccessary amount of data into this texture, and getting uninitialized garbage in the rest, but it isn't immediately obvious from your code how that could be happening.

That won't work. You are converting data to DXT3, and then you're reading that in and trying to use it as 565. When you convert the data to a new format, that's what you're getting in the bytes.

I would second the recommendation to use DXT1, by the way. 565 has no alpha, so the DXT3 format is totally unnecessary.

Oops, I should have mentioned, I have in fact switched to using dxt1 with just about the same result (except that now the top half of the texture renders correctly, while the bottom half is gibberish).

And then at runtime

So as you can see, I'm using (as far as I can tell) the same bitmap type both when I convert it in the pipeline, and when I initialize the texture @ runtime.

Still encountering this issue, however, I finally got off my lazy bum and cleaned up my code for a new Scurvy Media release.  I included the ability to compress the frame data using dxt1 as a processor Property ("Use Compression").  If you download the latest release (binary and source included in the release) and set the sample project's use compression flag to true, you will see the behavior described above. 

http://codecube.net/?p=40

That's bizarre.

It would be worth printing out the texture resolution and data length counts both inside the pipeline and at runtime, as a sanity check to make sure these are the same. I don't see how that code could be failing unless something is somehow going missing en-route.

Oooh... one more thing to check: stream.Read is allowed to read less than the requested amount: you should check the return value from this and loop if it hasn't read as much as you asked for (yeah, a crazy behavior IMHO, but that's the way it is for some reason :-)

Shawn Hargreaves:

(yeah, a crazy behavior IMHO, but that's the way it is for some reason :-)

That "crazyness" allows to read a file in fixed chunks without having to check that the files contents is a multiple of said chunk size. But the reading-less-than-request usually happens at the end of the file only, though :)