The VideoLAN Forums

I am using libvlc_video_set_callbacks and libvlc_video_set_format to playback a video to a D3D 11 texture.

I can then apply the texture to some geometry and see the texture. At the moment I'm allowing LibVLC to handle the audio playback directly to the system sound driver itself, so I can hear the audio too.

The video plays nicely, however if I increase the size of the target texture above about 2k or I use a high res video (4k x 2k) then after the first few frames the video stalls and I get no more frames of video.

Debug code indicates that LibVLC is still calling Lock, Unlock and Display but I'm not seeing the later frames appear on my texture.

My CPU and GPU don't appear to be maxed out, but I'm at a loss as to why it should work for a bit and then video completely stall.

I have added code to test whether the problem is in my rendering side, I can write to the texture after the Display callback and I see the texture updating dynamically.

I've also turned on LibVLC logging (see below) and the problem appears to be that the frames are taking too long to decode and so playback is failing.

However if I don't use libvlc_video_set_callbacks then LibVLC creates a window and plays back the video successfully without stalling, which would suggest it does have the capability to play the video without stalling and there must be something causing it to be much more expensive than it should be.

Can anyone suggest what could cause this? Or how to debug.

Thanks

Jules

Are you too slow to release the lock?

what might cause the problem ? I have also encountered the same problem.

Most likely it's too slow to update the texture each frame, especially for larger textures and this ends up holding up decoding.

It's an inefficient way to do things, but the only official way at the moment to update hardware surfaces in this way.

When you render to a window, it's likely using the hardware to decode, and directly copying the decoded frames to the hardware surface representing the window. What you are doing is probably decoding using software (or maybe hardware, and then each frame copied to system memory), then uploading this to GPU memory for your texture, which is much less efficient.

Most likely it's too slow to update the texture each frame, especially for larger textures and this ends up holding up decoding.

It's an inefficient way to do things, but the only official way at the moment to update hardware surfaces in this way.

When you render to a window, it's likely using the hardware to decode, and directly copying the decoded frames to the hardware surface representing the window. What you are doing is probably decoding using software (or maybe hardware, and then each frame copied to system memory), then uploading this to GPU memory for your texture, which is much less efficient.

Yup. Or use the vbridge patch.