0

I am developing a Live DirectShow filter.

I have an H264 stream source which i can get streams via SDK API.

In my filter I have a Queue which i Enqueue (push) incoming stream from a thread. Then I consume (Dequeue,pop) these streams inside the filter FillBuffer...

So I make a thread safe Queue...But this causes some problem....

At FillBuffer if i check is there any incoming packets and if there is , process logic is like this:

    ...
    bool hasElement = SynchronizedQueue.pop(element);

    if(!hasElement)
    {
        return S_OK
    }
    ...

...this consume to much CPU...

Howewer using boost lib to implement lock with condition variable 

...
SynchronizedQueue.waitAndPop(element) ;// which wait until we have some

Which have a lover CPU ...But sometime when there is no data in Queue, this block FillBuffer function and filter may not be stopped...

So any design idea alternatives for a live source filter which takes input streams from a remote mechine and pass it to decoder? Or how can I make my design better....lower CPU and can be stopped?

Novalis
  • 2,265
  • 6
  • 39
  • 63

1 Answers1

0

The source filter owns a pushing thread, so you need to wait there using a synchronization object (event, mutex) to yield control until a new frame is available for pushing off the output pin.

Whenever you receive a frame from SDK and you put it onto queue, you will indicate this availability using synchronization object, e.g. you will set an event. The worker thread wlil see the event and start processing the frame.

The worker thread needs to be able to respond to two events, at least: a new frame, and filter/graph stop. So you will need WaitForMultipleObjects to wait for multiple evetns and wake up on the first occurred.

Roman R.
  • 68,205
  • 6
  • 94
  • 158
  • Well, it's `IBaseFilter::Stop` called on your object, you can definitely handle it in addition to what you and base classes are already doing. – Roman R. Aug 16 '12 at 12:37