🔒 Locked

AVI optimization

Started by AdamR Sep 10, 2006 at 2:42 PM 0 replies 400+ views

Original Post

Sep 10, 2006 at 2:42 PM

void CAviEngine::PlayMovieAsTextures()									// Grabs A Frame From The Stream
{

	if(m_timerUpdate.CheckStatus())
	{

	
	m_lpbi = (LPBITMAPINFOHEADER)AVIStreamGetFrame(m_pgf, m_iFrame);	// Grab Data From The AVI Stream (note will crash if you can't open the avi)
	m_pdata=(char *)m_lpbi+m_lpbi->biSize;//+lpbi->biClrUsed * sizeof(RGBQUAD);	// Pointer To Data Returned By AVIStreamGetFrame on;y with 8 bit color

	// Convert Data To Requested Bitmap Format
	DrawDibDraw (m_hdd, m_hdc, 0, 0, -1, -1, m_lpbi, m_pdata, 0, 0, m_width, m_height, 0);


	//get the surface the lock it transfer the data then unlock it	
	m_hr = m_aviTextures->GetSurfaceLevel(0, &m_pSurface);
	
	m_pSurface->LockRect(&m_rectLocked, NULL, D3DLOCK_DISCARD);
	memcpy(m_rectLocked.pBits, data, m_widthTex*m_heightTex*4);
	m_pSurface->UnlockRect();
	
	m_timerUpdate.SetTimer(MILLISECONDS, 32);
	}
}

I'm looking for a way to optimize the way I'm running AVIs in my current project. Currently, I: 1) Grab data from the AVI stream representing the current frame 2) Convert data to the requested bitmap format Now that I have the bitmap info, is there a way I can create the texture from file from memory now that I have the bitmap that I want. If not, is there an alternative to locking/unlocking the surface texture. Thanks EDIT: Please remember to use 'source' tags in future... [Edited by - jollyjeffers on September 10, 2006 3:03:36 PM]

jollyjeffers

245

jollyjeffers

Sep 10, 2006 at 3:13 PM

Have you got any profiling data that you can use to identify where your performance problem really is? Profiling data is also very useful when you want to check whether changes actually make a difference [wink]

Copying data to a resource used for rendering is always going to be problematic when it comes to performance.

Your simple lock-memcpy-unlock is pretty good and I reckon it'll be substantially faster than any create-from-file-in-memory approach. Creating/destroying resources in your core loop isn't usually a good idea.

I'd recommend you look into a "bounded buffer" (aka "ring buffer") approach in order to maximize any CPU/GPU parallelism. Create an array of several (e.g. 3-10) textures and where frame N renders from N in the array the CPU writes to N+1. That way you should only end up modifying the oldest texture in the queue and hopefully it won't be in the command queue on the GPU and you reduce the chances to stalling...

hth
Jack

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.