Tee/passthrough DirectShow data as video source

4
votes

I have an application that gets video samples from a frame grabber card via DirectShow. The application then does some processing and sends the video signal over a network. I now want to duplicate this video signal such that another DirectShow-enabled software (like Skype) can use the original input signal, too.

I know that you can create Tee filters in DirectShow like the one used to split a video signal for recording and preview. However, as I understand, this filter is only useful within a single graph, ie I cannot use it to forward the video from my process to eg Skype.

I also know that I could write my own video source, but this would run in the process of the consuming application. The problem is that I cannot put the logic of my original application in such a video source filter.

The only solution I could think of is my application writing the frames to a shared memory block and a video source filter reading it from there. Synchronisation would be done using a shared mutex or so. Could that work? I specifically do not like the synchronisation part?

And more importantly, is there a better solution to solve this problem?

1
c++winapivideodirectshow
Rather than block the mutex while you read/write an entire block, you can synchronize only on the pointers to blocks. This could be lockless or with a crit-sec over a tiny data structure like a pointer queue. - VoidStar
I am pretty sure that a Windows critical section cannot be used for IPC synchronisation; wrt the lockless implementation, I am unsure whether this would work on shared memory. I do not know what the semantics of atomic CAS are here ... - Christoph
This is going to work, and it looks like appropriate approach. Mutexes are easy to deal with and yes, you cannot use critical sections across process boundaries. BTW portions of this task were discussed multiple times, e.g. here or if you search for virtual dshow source + IPC, perhaps you can grab certain important details there as well. - Roman R.
@RomanR. I interpret your answer as that there is no other solution that the shared memory/mutex approach I outlined in the question? Atm, my solution would be a triple buffer in shared memory like remis-thoughts.blogspot.de/2012/01/…, but I would not use atomics but a mutex for protecting the state flags. Btw, if you posted an answer instead a suggestion, I would accept it ... - Christoph

1 Answers

1
votes

The APIs work as you identified: a video capture application, such as Skype, is requesting video stream without interprocess communication in mind, there is no IPC involved to consume output generated in another process. Your challenge here is to provide this IPC yourself so that one application is generating the data, and then another extends existing API (virtual video source device) and picks existing data, then delivers as generated.

With video, you have a relatively big stream of data and you are interested in avoiding its excessive copying. File mappings (AKA shared memory) are the right thing to do: you put bytes in one process and they are immediately visible in another. You can synchronize access to the data using names events and mutexes which both processes use collaboratively - to signal availability of new buffer of data, as indication that used buffer is no longer in use etc.