Delay / lag / stall with WMF Video Player

Using Cinder
1

Hi all. I’ve recently run into some issues with the WMF player and am curious if others have seen this as well, and hopefully may have some ideas for fixes…

I have a kiosk app with some moderate video playback needs. Most of the time I’m playing only a single HD video, though there is a moment where I’m playing 9 thumbnails simultaneously (all HD – the resolution isn’t necessary but the GPU load/bandwidth in GPU-Z seems fine handling this on a GTX1080). All of the videos (these + more, about 36 total) are preloaded at app launch, and the VRAM is at about 3.5GB (out of 8GB).

My issue is that on occasion, when either playing a video, or seeking to a new position (sometimes forward, sometimes behind the current position) and playing, the video (and the whole app, I think) seems to hang for a few seconds. It’s very inconsistent and hard to reproduce, but it seems like it may occur when the video hasn’t been played in a while (and other videos have), so maybe whatever cache/buffer is created by WMF or the WMF block is stale, or that given video is no longer cached, and part of that video needs to get loaded again? I haven’t dug into the internals of the block to understand what’s going on :grimacing:

Anyway, I’m hoping for some tips or tricks here. I would love to not switch to loading these videos on demand, or deal with swapping out the video player entirely :grimacing::grimacing::grimacing:. Oh, and this is running on Windows 7 Pro, 64bit, VS2015.

Thanks for any leads!

1 Like
2

Hey @mattfelsen,

There are two things which I can think off. Seeking backwards with H264 and using B frames means that the decoder needs to search back for the last I frame and maybe even previous PPS/SPS nals. That might give some delays, depending how you encoded your video. The other thing is that it might be your decoder that simply can’t handle that many videos. But like you said it mainly happens when users scrub the video.

You can try to encode the video with only I frames; enable fast start with mp4 (it’s an ffmpeg option) and optimize for decoding (i.e. don’t use fancy h264 features).

Hope this helps, good luck!
roxlu

3

@mattfelsen I’m facing similar issues using WMF player. Did any of @roxlu’s suggestions solve your problems?

4

Hey @Craigson. Not really…I had already been using a video with I-frames every frame (via keyint=1 passed to ffmpeg when encoding). The seeking was fast when it worked, but occasionally produced that delay when load testing in the studio. As it turns out, it hasn’t been much of an issue in production so I haven’t pursued it further.

Also, my understanding with mp4 fast start was it that it was only relevant for web streaming? I forget if I did tests with & without (I believe the “Web optimized” checkbox in Handbrake is the same thing?) so no thoughts there…