0

I developed an application in C that can display 4 videos, and 1 sound file in the background.

The video uses the WMP object in the C++ class provided by Microsoft in the WMP SDK. The audio uses Windows' MCI (Media Control Interface) which is sent command strings.

To be able to play lots of different formats, I installed windows.7.codec.pack.

I experience a problem that when playing more than 3 media files (video or audio), the media stall. A video to be started constantly cycles from state 3 (Playing) to state 9 (Preparing new media) to state 10 (Ready to begin playing - without anything happening), and so on and so on. This is seen as a flicker of the video (state 3) followed by a few seconds of nothing (black, or desktop background, state 9). Once a video has started, it plays fine until the end.

Decreasing the number of media files to play to 2 videos and 1 audio lets it play fine; increasing to 3 video or more and 1 audio and this happens. Task Manager shows a CPU load of less than 25%, so CPU cannot be the problem.

It seems that MCI and WMP share stuff in the background because not only do videos stall, also audio stops without reporting errors (querying MCI returns that it is playing, but there is no sound).

I upgraded to windows.7.codec.pack.v4.2.6. This had a terrible performance

I reverted to windows.7.codec.pack.v4.1.6. This has a much better performance but still not perfect.

My question(s):

  • Is there any way I can configure Windows or the codec package to seamlessly handle 5 streams?

  • How can I report this problem to the developer?

  • Are there other codec packages that do not have this problem?

  • Any other suggestion?

System info: Intel i7-3520M X64 dual core at 2.9Ghz with 8GB physical memory and NVIDIA Quatro K1000M display adapter.

Paul Ogilvie
  • 25,048
  • 4
  • 23
  • 41

1 Answers1

0

I think I found the solution.

After playing a video, I called the Player's Close() method. The documentation says:

The close method releases Windows Media Player resources.

Remarks
This method closes the current digital media file, not the Player itself.

Indeed I wanted to release the media file so it would no longer be busy in the file system. However, it seems that more resources were released than just the media file. As a consequence, for a next media file to be played, the player had to allocate resources again. It seems that turned out to be a bottle neck.

No longer calling Close() but just giving it the URL (filename) of the next media file to play now solved the problem. (I still have to give some retries sometimes but the general performance is now very well acceptable.)

The media file is released when the next media file starts playing.

Paul Ogilvie
  • 25,048
  • 4
  • 23
  • 41