Sign in to follow this  
ucfchuck

slimdx video

Recommended Posts

why is this bmpstream.Position = 0; backbuff = g_pSwapChain.GetBuffer<D3D10.Texture2D>(0); D3D10.Texture.ToStream(backbuff,SlimDX.Direct3D10.ImageFileFormat.Bmp, bmpstream); bitmap = (Bitmap)Bitmap.FromStream(bmpstream); aviStream.AddFrame(bitmap); ten times slower than this backbuff = g_pSwapChain.GetBuffer<D3D10.Texture2D>(0); D3D10.Texture2D.ToFile(backbuff, SlimDX.Direct3D10.ImageFileFormat.Bmp, "vidimg.bmp"); bitmap = (Bitmap)Image.FromFile("vidimg.bmp"); aviStream.AddFrame(bitmap); i thought for sure that keeping the data in memory would be faster than tasking the hard drive btw the avi wrapper came from http://www.codeproject.com/KB/audio-video/avifilewrapper.aspx

Share this post


Link to post
Share on other sites
Constructing from memory is faster. The problem is that you are constructing from a stream, which isn't necessarily the same thing. SlimDX can't know anything about the stream, so it is forced to read it in byte by byte and then construct from memory, which is obviously going to be a lot slower. I'd recommend extracting from a stream yourself and then using FromMemory to try to speed things up.

Share this post


Link to post
Share on other sites
MemoryStream bmpstream = new MemoryStream(5000000);




"SlimDX can't know anything about the stream, so it is forced to read it in byte by byte and then construct from memory"

Slimdx is exporting the texture to the stream, and windows is reading the bmp out of it. which side should i try to overwrite?

Share this post


Link to post
Share on other sites
Use a DataStream instead of a MemoryStream. MemoryStream is not a class we control, so we have a much more restricted interface to work with, forcing us to do things that are less that optimal in order to be correct. However, we have more control over DataStream and don't need to create unnecessary managed memory allocations.

We might not support the appropriate optimization (specialization for DataStream) in the classes you are using yet, but switching to a DataStream will allow you to take advantage of that optimization once we employ it.

Also, this is presupposing that its the SlimDX code that is the real bottleneck and not the reading of the bitmap data back out of the stream (for that there is little we can do, though, so we may as well focus on the things you can do to speed up the SlimDX side of things).

Share this post


Link to post
Share on other sites
im still getting about 1fps using the streams, compared to 8fps with the file io.

DataStream bmpstream = new DataStream(5000000, true, true);

i ran a couple tests and it definitely is the slimdx side of things that are the bottleneck.


if i use the same stream to avoid reloading the stream (using slimdx) for each new frame, but still read the bitmap from the original stream over and over i get about 10fps or a little better.

bmpstream.Position = 0;
//D3D10.Texture.ToStream(backbuff, SlimDX.Direct3D10.ImageFileFormat.Bmp, bmpstream);
bitmap = (Bitmap)Bitmap.FromStream(bmpstream);
aviStream.AddFrame(bitmap);
=>~10fps

but if i use the same bitmap to avoid reading it out of the stream over and over and just have slimdx write the stream for each frame, i get about 1fps or worse.

bmpstream.Position = 0;
D3D10.Texture.ToStream(backbuff, SlimDX.Direct3D10.ImageFileFormat.Bmp, bmpstream);
//bitmap = (Bitmap)Bitmap.FromStream(bmpstream);
aviStream.AddFrame(bitmap);
=>~1fps

Share this post


Link to post
Share on other sites
Like I said, we may not have applied the optimization there yet. However I'm not sure that it will be buying you much, since it's largely a GC pressure optimization. The fundamental operation you're doing is still not going to exceed your 0.1 seconds-per-frame performance metric -- "ToStream" on a texture is going to involve locking and fetching the data from the GPU, which is where the biggest overhead will be after the DataStream optimization.

All the DataStream optimization can provide you is the assurance that the copy from the in-CPU version of the data to the stream's backing store is done via memcpy or similar and not a loop. It's not going to be a huge gain, unfortunately; what you are doing is a fundamentally slow operation.

Share this post


Link to post
Share on other sites
well its an ultrasound cancer research platform where i wrote the scanconverter for directx10 using slimdx and it needs to eventually be DICOM compliant with mpeg2 video compression and jpeg2000 image capture, but for right now it needs just any type of video recording at a decent framerate for FDA approval and clinical trials and demos and such, im really only trying to capture the directx surface to video and not the whole application. I could go with a LEADTOOLS or dive into directshow, but both seem like about the same amount of time to get to where i need to be which seems like a couple of weeks, which is why i was trying to just export the backbuffer to an avi as a 'for now' option.

it would be faster (computationally) to just simply record the raw data out of the scanner and then replay it later but that wouldn't preserve what the user did, like zooming around and taking measurements and all those little details. so i want to records the directx surface so i can keep all the user interactions with the data.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this