Re: SDK locking up application

Hi,

in our mfc based application i noticed up to two seconds lockups after replacing directshow implementation with leadtools sdk. Implementation is based on Callback example. The application has two threads. First for handling mfc dialogs and second for actual rendering. So message pump runs on first thread. When there was directshow implementation no other message pump was needed and everything was running pretty smoothly. After transfering it to leadtools sdk callback filter mechanism wasn't working and this changed after adding another message pump to second thread. Question is why sdk needs this? Worst problem is that during SetSource, etc it's locked up for up to two seconds.

To demostrate this i've created really simple console application. It creates interface, loads movie, runs it, wait to receive frame in callback, stops or pauses video and releases interface. Version with pause works as expected. No lockups.. But version with Stop is different. Function call _player->Stop takes more then 2seconds. What's problem? Can this explain similar behaviour in our application. How can we help this?

Pause version

Create   191ms
SetSource   343ms
Run2Rec   17ms
Rec2Rec   24ms
Rec2Rec   33ms
Pause   0ms
Release   29ms

Stop version

Create   192ms
SetSource   338ms
Run2Rec   17ms
Rec2Rec   24ms
Rec2Rec   33ms
Stop   2116ms
Release   3ms

It's running on P4 quad core. Also SetSource seems to take too long. And this doesn't change for repetable create, run, ... , release..

Demo application is attached.

Thanks for help

Pavel Domsa

 

 

 

The numbers I got for the "pause" version were pretty much the same though:

Create   96ms
SetSource   300ms
Run2Rec   12ms
Rec2Rec   24ms
Rec2Rec   34ms
Pause   0ms
Release   78ms

I'm assuming that all you did different for the "stop version" was replace _player->Stop() with _player->Pause().  If so, here's what I got:

Create   97ms
SetSource   244ms
Run2Rec   12ms
Rec2Rec   25ms
Rec2Rec   33ms
Stop   5036ms
Release   13ms

The stop was definitely longer than expected and I need to research this a little further.  Does this delay happen if you don't use multithreading?

As for the SetSource, this is a normal delay because this is the step where the player control builds the graph which can take some time since the DirectShow system must find the filters necessary for decoding the file and put them all together.  I would imagine you'd have a similar delay if you were building the graph yourself with low level DirectShow.  If you've tried this and found it to be otherwise, let me know.

In regards to why you needed a new apartment, this is to be expected.  Our COM object uses a single threaded apartment which is why it needs its own message pump.  We will not call back into the application from a different thread.

We need to play videos in MT environnment so I haven't tested singlethread.

I did some measurements in our application. It definitely looks like that using DirectShow directly is way faster.

Implementation is 100% similar to what i sent in previous example and number are:

for DirectShow- based on BaseClasses -

Create          0ms
SetSource        8ms
ConnectGraph      40ms
Play        16ms
Run2Rec        45ms
Rec2Rec        24ms
Release        0ms
Create          0ms
SetSource        7ms
ConnectGraph      38ms
Play        2ms
Run2Rec        111ms
Rec2Rec        24ms
Release        0ms

LeadTools SDK -

Create          136ms
SetSource          309ms
Run          2105ms
Run2Rec        1721ms
Release         4ms
Create          46ms
SetSource          218ms
Run          2116ms
Run2Rec        1631ms
Release         4ms
Create          42ms
SetSource          213ms
Run          2092ms
Run2Rec        1633ms
Release         4ms

Run operation takes unexpected amount of the time. I would say it's similar problem as Stop in previous example.

As you can see there are big differences in all parts. If you wish i can send you our DirectShow implementation, but it's based on BaseClasses example, so there is nothing special. Our application is time critical so we cannot afford such numbers. Also played video was one with baby from you examples and since leadcodec is registered with high priority, both implementations were using it.

Thanks for help

Pavel Domsa

 

 

 

I have reproduced this problem and have reported it with the incident number 6788IDT.  This incident will be reviewed and prioritized by our engineering department.  I will contact you when I get more information from our developers.

The developers working on your incident, 6788IDT, have let me know that this is not a bug.

The delay is caused by the callback filter which (for some internal reasons), causes a play graph to stop slowly if the callback proc is active.

The workaround is to disable the callback proc before calling the stop function.  Your code already has the framework for doing this, so all I added was the line putCallbackObj(NULL); before calling _player->Stop(); and here's the output I got:


Create   100ms
SetSource   326ms
Run2Rec   12ms
Rec2Rec   25ms
Rec2Rec   33ms
Stop   62ms
Release   17ms
Create   57ms
SetSource   207ms
Run2Rec   12ms
Rec2Rec   25ms
Rec2Rec   33ms
Stop   72ms
Release   5ms
Create   56ms
SetSource   207ms
Run2Rec   12ms
Rec2Rec   25ms
Rec2Rec   34ms
Stop   61ms
Release   16ms
Create   57ms
SetSource   195ms
Run2Rec   13ms
Rec2Rec   23ms
Rec2Rec   34ms
Stop   59ms
Release   16ms
Create   57ms
SetSource   176ms
Run2Rec   33ms
Rec2Rec   40ms
Rec2Rec   23ms
Stop   44ms
Release   16ms