This is not going to work. It's going to get you a different instance,
which will fail if the device supports only one instance.
You could try creating a pseudo-device that wraps the original and
provides out-of-process remote control of the settings.
> This is exactly what I wanted to achieve: to write a (generic) DirectShow
> class to control a specified A/V capture regardless where such device is
> opened.
See the vcam sample by Vivek which is available on my Downloads page, as a
starting point.
--
Please read this before replying:
1. Dshow & posting help: http://tmhare.mvps.org/help.htm
2. Trim & respond inline (please don't top post or snip everything)
3. Benefit others: follow up if you are helped or you found a solution
"The March Hare [MVP]" wrote:
> On Mon, 2 Mar 2009 07:11:19 -0800, tfs wrote:
>
> > This is exactly what I wanted to achieve: to write a (generic) DirectShow
> > class to control a specified A/V capture regardless where such device is
> > opened.
>
> See the vcam sample by Vivek which is available on my Downloads page, as a
> starting point.
>
Thanks for your suggestion. I have downloaded the said project and quickly
looked through the code. Basically what it does is to implement another
filter to perform the required work.
However, since most of the vendor's sample app usually have one app for
encoding (i.e. the one creates the capture device filter) and a SEPARATE app
for video quality control and input-select (i.e. the one somehow obtains the
correct IAMVideoProcAmp, IAMCrossbar filters), the latter app should be able
to be created with ease, and I seriously doubt that it requires to go to that
level of complexity as your vcam sample does.
So, are you saying that it is just impossible to control the same capture
device over 2 separate app processes? Honestly, I don't think so. However, I
don't know how.
Although this is true, only poorly designed capture devices limit
themselves to one instance. Media Center, for example, *requires* that a
device allow multiple instances. The hardware resources are not supposed
to be committed until the graph transitions out of "idle".
I commonly use the technique he describes, but I have the advantage of
being the author of the capture driver...
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.
No. Geraint told you that it was impossible ***IF*** the capture driver
limited itself to one instance. From your description, it sounds like your
vendor allows multiple instances (as many do). In that case, your original
plan will work just fine.
"Tim Roberts" wrote:
This sounds a very good news to me. I will try it on my capture hardwares (I
got a few different cards from different vendors). So, if the device allows
only 1 instance, then the subsequent attempts of binding/creating will fail
or return a NULL filter interface, then I know that this is the end of the
road. Correct?
tfs
Yes.