Re: "Direct3D9: (ERROR) :Error trying to lock driver surface" error when using VMR9

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

On 25 Апр, 11:08, "jarnobur...@xxxxxxxxx" <jarnobur...@xxxxxxxxx>
wrote:
On Apr 24, 3:13 pm, predator_mf2...@xxxxxxxxx wrote:



Hi!

I'm trying to run a video on a texture surface and use it in my
engine.
I have to use a separate render loop (not presenting in AP's
PresentImage), so my fps is not locked to the video's fps.

I've made a custom allocator-presenter for VMR9, but I get huge lags,
the graph is delaying frames, sometimes it stops rendering for 2-3
seconds and even more (while the sound continues to render). I get
this debug error most of the time:
Direct3D9: (ERROR) :Error trying to lock driver surface
This error comes out even when not using the texture! VSYNC is not
helping much, except it's making the errors coming rarely, but still
most of the frames are delayed or not desplayed at all.

I've spend weeks googling this, asking people, trying different code I
have found no answer to this.

I've tried using double buffering (rendering with a texture, getting
videodata in another texture), it's the same thing. I come to think
it's not a texture surface that the VMR is trying to lock, it's
something else.

Any help will be much apreciated!

Thanks,
Pencheff

Eh , do you have a render loop like this ?
I wanna know , i am trying to learn this too..

\\\chunk , the frame grabbing from video part:

while the 3d render engine doesnt ask for a frame:
--create some memory for a frame
--seek to a frame
--grab a frame from your video into memory
--give a signal that you have a frame ready in memory
loop

when there is asked for a frame:
--are there problems with the frame thats ready ready in memory ?
--give the frame thats ready in memory

\\\\chunk 2
do
--changes in scene ?
--render scene
loop

when there is a signal for video frame ready in memory:
--ask for a frame
--copy it to a texture

When using SampleGrabber with callbacks (and double/triple buffering)
I'm doing it this way:
--on a SampleGrabber BufferCallback copy the image to the next free
texture from the buffer and signal a new texture in the buffer
--render with last texture from the buffer

I've tried getting bitmap data from the samplegrabber buffer in the
renderloop, but this is really slowing things down to 30-40fps on my
card and at the same time CPU goes insanely high. Then I tried using
callbacks with a single texture, but then again the texture gets
locked by the renderloop while the same time the callback from the
samplegrabber is trying to write to it.

If you are going to use this, you need to setup the SampleGrabber
media type format (SetMediaType) to ARGB32, this will add a "Color
space converter" filter to the graph right before the SampleGrabber.
This way copying data from bitmap buffer to the texture buffer will be
way faster, because RGB24 consists of 3 bytes (byte by byte copying),
while ARGB32 consists of 4 bytes (long copying - 4 times faster).
.

Relevant Pages