I read this post http://www.osronline.com/ShowThread.cfm?link=214286
and I want to do something very similar.
I need to enable skype/ amcap etc. and an application I wrote to use my web
cam at the same time.
I see it’s written the right way is to have a user mode driver which one?
what is the best approach in this case?
Miriam Engel wrote:
I read this post http://www.osronline.com/ShowThread.cfm?link=214286
and I want to do something very similar.
I need to enable skype/ amcap etc. and an application I wrote to use
my web cam at the same time.
I see it’s written the right way is to have a user mode driver which one?
what is the best approach in this case?
How do you expect that to work? Who gets to decide the format? Who
manages “start” and “stop”? Amcap would be bad enough, but Skype is a
bastard of an application. It changes the format of the stream over and
over to try to manage bandwidth, by stopping and restarting. How will
you handle that?
Before you go too deeply into this, allow me to point you to
http://manycam.com . This is open source software that connects to a
video camera and rebroadcasts the stream to multiple applications. If
it does what you want, that’s an easy solution.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
I need my own solution as for one pin I want to give the existing apps to
access.
regarding managing and format decisions aren’t they the same questions
regarding the avstream splitter?
is avstream splitter what I need
http://msdn.microsoft.com/en-us/library/windows/hardware/ff554255(v=vs.85).aspx
I thought this is what I should use.
but 1. looking for better explanation and code sample
2. wanted to consult if this is really the right approach?
manycam looks interesting. but I need my own solution. I need one pin to
support any app and another pin for my specific usages.
what architecture does manycam base on?
On Wed, Aug 20, 2014 at 8:57 PM, Tim Roberts wrote:
> Miriam Engel wrote:
> > I read this post http://www.osronline.com/ShowThread.cfm?link=214286
> > and I want to do something very similar.
> > I need to enable skype/ amcap etc. and an application I wrote to use
> > my web cam at the same time.
> > I see it’s written the right way is to have a user mode driver which one?
> > what is the best approach in this case?
>
> How do you expect that to work? Who gets to decide the format? Who
> manages “start” and “stop”? Amcap would be bad enough, but Skype is a
> bastard of an application. It changes the format of the stream over and
> over to try to manage bandwidth, by stopping and restarting. How will
> you handle that?
>
> Before you go too deeply into this, allow me to point you to
> http://manycam.com . This is open source software that connects to a
> video camera and rebroadcasts the stream to multiple applications. If
> it does what you want, that’s an easy solution.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
–
Miriam Engel
On Aug 20, 2014, at 12:39 PM, Miriam Engel > wrote:
I need my own solution as for one pin I want to give the existing apps to access.
regarding managing and format decisions aren’t they the same questions regarding the avstream splitter?
No, that?s entirely different. That takes one pin as input and produces two identical pins as output, but all within the same graph. It doesn?t NEED to change the format, because that?s done before the stream gets to its input pin.
is avstream splitter what I need http://msdn.microsoft.com/en-us/library/windows/hardware/ff554255(v=vs.85).aspx
I thought this is what I should use.
You said you wanted one source to be used in two different applications. The AVStream splitter doesn?t do that. It is one filter in one graph in one application. If you aren?t clear about that, then you really aren?t ready to appreciate the difficulties you are up against in splitting to two different applications.
You need to think about the implications here. Say application #1 connects to the camera, selects 640x480, and starts the graph. Now application #2 connects. What if application #2 wants 800x600? You can?t force app #1 to change its format. So, let?s say app #2 agrees to connect at 640x480. Now what happens when app #1 decides to stop the graph. What happens to app #2?
2. wanted to consult if this is really the right approach?
It certainly won?t do what you asked.
manycam looks interesting. but I need my own solution. I need one pin to support any app and another pin for my specific usages.
what architecture does manycam base on?
You can?t have a filter with two pins in two separate graphs. Remember, those are different processes with completely separate memory spaces. Further, you can?t have the web camera filter in those different graphs; a single web camera will only allow itself to be started in one graph at a time. That means you will basically have THREE graphs involved here. You?ll need one graph talking to the real camera, pulling the frames and putting them in a buffer. Then, you?ll have a filter in N application graphs, each of which are pulling frames from that buffer. You?ll have to figure out how to share that buffer between the processes (memory-mapped file, maybe), and you STILL have the problem of figuring out how to how to manage format changes and things like brightness, contrast, shutter speed, still images, etc. What about dropped frames, if one of the graphs gets behind?
This is NOT a simple problem.
–
Tim Roberts, xxxxx@probo.commailto:xxxxx
Providenza & Boekelheide, Inc.</mailto:xxxxx>
Hi Tim,
First thanks for your detailed answers, I really appreciate it.
ok, as I understand if splitter does not enable accessing the pins from
different application then it’s probably not the solution.
regarding maintaining different resolutions,stop start etc. these are true
but in my case it will be handled the application which connects can choose
what resolution to stream and my application just needs the data. so I’m
looking for a way to be able to stream (can be exact same data) as the
other application is streaming.
I read about ksproxy but not sure if this may help in my case. I saw the
sample microsoft directs to about the properties. but I have questions:
how does the camera applciation connect over the ksproxy? is it a user mode
driver? can I duplicate the streams in the ksproxy one for the application
and one for my usages?
I did not find much documentation about teh ksproxy besides microsoft’s are
you aware of any samples or docs?
p.s. not the main question, but yet relevant I wrote the splitter using
AVHWS microsoft’s sample by settings the ksflag splitter and increasing teh
instances possible, when creating the graph in graph edit I see after the
first pin is created and used another pinis created but I cannot render it
/get streaming via the second pin do you have experience with this and know
if there’s anythign else to do. (although it does not meet my q goal I may
want to be able to do it for other need).
thanks!
On Thu, Aug 21, 2014 at 8:57 AM, Tim Roberts wrote:
> On Aug 20, 2014, at 12:39 PM, Miriam Engel wrote:
>
> I need my own solution as for one pin I want to give the existing apps to
> access.
> regarding managing and format decisions aren’t they the same questions
> regarding the avstream splitter?
>
>
> No, that’s entirely different. That takes one pin as input and produces
> two identical pins as output, but all within the same graph. It doesn’t
> NEED to change the format, because that’s done before the stream gets to
> its input pin.
>
>
> is avstream splitter what I need
> http://msdn.microsoft.com/en-us/library/windows/hardware/ff554255(v=vs.85).aspx
> I thought this is what I should use.
>
>
> You said you wanted one source to be used in two different applications.
> The AVStream splitter doesn’t do that. It is one filter in one graph in
> one application. If you aren’t clear about that, then you really aren’t
> ready to appreciate the difficulties you are up against in splitting to two
> different applications.
>
> You need to think about the implications here. Say application #1
> connects to the camera, selects 640x480, and starts the graph. Now
> application #2 connects. What if application #2 wants 800x600? You can’t
> force app #1 to change its format. So, let’s say app #2 agrees to connect
> at 640x480. Now what happens when app #1 decides to stop the graph. What
> happens to app #2?
>
>
> 2. wanted to consult if this is really the right approach?
>
>
> It certainly won’t do what you asked.
>
>
> manycam looks interesting. but I need my own solution. I need one pin to
> support any app and another pin for my specific usages.
> what architecture does manycam base on?
>
>
> You can’t have a filter with two pins in two separate graphs. Remember,
> those are different processes with completely separate memory spaces.
> Further, you can’t have the web camera filter in those different graphs; a
> single web camera will only allow itself to be started in one graph at a
> time. That means you will basically have THREE graphs involved here.
> You’ll need one graph talking to the real camera, pulling the frames and
> putting them in a buffer. Then, you’ll have a filter in N application
> graphs, each of which are pulling frames from that buffer. You’ll have to
> figure out how to share that buffer between the processes (memory-mapped
> file, maybe), and you STILL have the problem of figuring out how to how to
> manage format changes and things like brightness, contrast, shutter speed,
> still images, etc. What about dropped frames, if one of the graphs gets
> behind?
>
> This is NOT a simple problem.
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
–
Miriam Engel
Miriam Engel wrote:
First thanks for your detailed answers, I really appreciate it.
ok, as I understand if splitter does not enable accessing the pins
from different application then it’s probably not the solution.
No single filter can do that.
If you’ve looked at the AVStream architecture, then you know you have
one device which exposes some number of filters, each of which exposes
some number of pins. Each filter can be part of a different process,
but they all share the same device. Thus, you could do your buffer
sharing there.
regarding maintaining different resolutions,stop start etc. these are
true but in my case it will be handled the application which connects
can choose what resolution to stream and my application just needs the
data. so I’m looking for a way to be able to stream (can be exact same
data) as the other application is streaming.
If you just want a side door, and you don’t really need another
DirectShow graph, you can do that using extra properties without going
to the trouble of streaming it.
I read about ksproxy but not sure if this may help in my case. I saw
the sample microsoft directs to about the properties. but I have
questions:
how does the camera applciation connect over the ksproxy? is it a user
mode driver? can I duplicate the streams in the ksproxy one for the
application and one for my usages?
I did not find much documentation about teh ksproxy besides
microsoft’s are you aware of any samples or docs?
You misunderstand what ksproxy is. DirectShow is entirely a user-mode
technology. It doesn’t know anything about kernel-mode drivers. When
you bring a kernel filter (like a webcam driver) into a graph, which you
are really putting into the graph is an instance of ksproxy. Ksproxy is
a DirectShow filter, but it knows how to talk to Kernel Streaming
drivers. DirectShow talks only to ksproxy, and ksproxy converts that to
Kernel Streaming ioctls.
A ksproxy plugin just lets you put a friendly COM front-end over
whatever custom KS properties your filter exposes. It’s optional, and
it won’t help with the task you have.
p.s. not the main question, but yet relevant I wrote the splitter
using AVHWS microsoft’s sample by settings the ksflag splitter and
increasing teh instances possible, when creating the graph in graph
edit I see after the first pin is created and used another pinis
created but I cannot render it /get streaming via the second pin do
you have experience with this and know if there’s anythign else to do.
(although it does not meet my q goal I may want to be able to do it
for other need).
What happened when you tried to render it?
The AVSHWS code assumes that there is only one pin. The SetState
routine, for example, stops the device when the pin changes to “stop”
state. You would want to have the device count up instances, so that it
only did its initialization on the first Start, and only shutdown on the
last Stop.
The documentation only describes how to use a splitter pin for
filter-centric AVStream drivers. Avshws is pin-centric. You might try
your changes with avssamp, which is filter-centric.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Hi Tim,
Each filter can be part of a different process,
but they all share the same device. Thus, you could do your buffer
sharing there.
there meaning in the filter? do you mean creating 2 separate filters
connecting to the source? what type of filters and where / how will the
buffer be shared/ copied?
you just want a side door, and you don’t really need another
DirectShow graph, you can do that using extra properties without going
to the trouble of streaming it.
I do need actual copy of the streaming so only properties won’t help,
nevertheless I don’t care about the resolutions etc.
regarding the kspoxy, thanks for the explanation, the ksproxy plugin for
properties won’t help me, but as the ksproxy is a spcial type of filter
wrapping communication withe the kernel streaming
can I somehow alter the ksproxy to copy the buffers? or maybe can the
ksproxy plugin can provide more than only extending property types?
or maybe an option is just to write a user mode driver which calls the
kernel streaming and does the streaming duplication? what API do I need to
implement so my user mode driver is exposed to apps as a web cam?
On Fri, Aug 22, 2014 at 3:06 AM, Tim Roberts wrote:
> Miriam Engel wrote:
> >
> > First thanks for your detailed answers, I really appreciate it.
> > ok, as I understand if splitter does not enable accessing the pins
> > from different application then it’s probably not the solution.
>
> No single filter can do that.
>
> If you’ve looked at the AVStream architecture, then you know you have
> one device which exposes some number of filters, each of which exposes
> some number of pins. Each filter can be part of a different process,
> but they all share the same device. Thus, you could do your buffer
> sharing there.
>
>
> > regarding maintaining different resolutions,stop start etc. these are
> > true but in my case it will be handled the application which connects
> > can choose what resolution to stream and my application just needs the
> > data. so I’m looking for a way to be able to stream (can be exact same
> > data) as the other application is streaming.
>
> If you just want a side door, and you don’t really need another
> DirectShow graph, you can do that using extra properties without going
> to the trouble of streaming it.
>
>
> > I read about ksproxy but not sure if this may help in my case. I saw
> > the sample microsoft directs to about the properties. but I have
> > questions:
> > how does the camera applciation connect over the ksproxy? is it a user
> > mode driver? can I duplicate the streams in the ksproxy one for the
> > application and one for my usages?
> > I did not find much documentation about teh ksproxy besides
> > microsoft’s are you aware of any samples or docs?
>
> You misunderstand what ksproxy is. DirectShow is entirely a user-mode
> technology. It doesn’t know anything about kernel-mode drivers. When
> you bring a kernel filter (like a webcam driver) into a graph, which you
> are really putting into the graph is an instance of ksproxy. Ksproxy is
> a DirectShow filter, but it knows how to talk to Kernel Streaming
> drivers. DirectShow talks only to ksproxy, and ksproxy converts that to
> Kernel Streaming ioctls.
>
> A ksproxy plugin just lets you put a friendly COM front-end over
> whatever custom KS properties your filter exposes. It’s optional, and
> it won’t help with the task you have.
>
>
> > p.s. not the main question, but yet relevant I wrote the splitter
> > using AVHWS microsoft’s sample by settings the ksflag splitter and
> > increasing teh instances possible, when creating the graph in graph
> > edit I see after the first pin is created and used another pinis
> > created but I cannot render it /get streaming via the second pin do
> > you have experience with this and know if there’s anythign else to do.
> > (although it does not meet my q goal I may want to be able to do it
> > for other need).
>
> What happened when you tried to render it?
>
> The AVSHWS code assumes that there is only one pin. The SetState
> routine, for example, stops the device when the pin changes to “stop”
> state. You would want to have the device count up instances, so that it
> only did its initialization on the first Start, and only shutdown on the
> last Stop.
>
> The documentation only describes how to use a splitter pin for
> filter-centric AVStream drivers. Avshws is pin-centric. You might try
> your changes with avssamp, which is filter-centric.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
–
Miriam Engel
Miriam Engel wrote:
Hi Tim,
>Each filter can be part of a different process,
>but they all share the same device. Thus, you could do your buffer
>sharing there.there meaning in the filter? do you mean creating 2 separate filters
connecting to the source? what type of filters and where / how will
the buffer be shared/ copied?
You have looked at the architecture of an AVStream driver, right? There
are “devices”, “filters”, and “pins”. Each instance of the driver
(which means each single piece of hardware) has one device. That device
can expose multiple filters, or one filter that can be loaded multiple
times. All of those filter instances share the same device. The filter
modules in the AVStream samples all call in to the device to communicate
with the hardware.
Because you have that communication, the device can hold data that is
common to all of the filters, including copies of the last frames.
>you just want a side door, and you don’t really need another
>DirectShow graph, you can do that using extra properties without going
>to the trouble of streaming it.I do need actual copy of the streaming so only properties won’t help,
nevertheless I don’t care about the resolutions etc.
You don’t understand what I’m saying. The “property” interface into an
AVStream filter is basically the same as the ioctl interface to a WDM
driver. You can pass anything in and out. So, for example, you could
have your monitoring application create a new instance of the filter
(which is easy), and then just send a custom property that says “return
the next frame to me”. That would require less application overhead
than creating an entire DirectShow graph to stream those frames,
although the driver side is probably not any simpler.
regarding the kspoxy, thanks for the explanation, the ksproxy plugin
for properties won’t help me, but as the ksproxy is a spcial type of
filter wrapping communication withe the kernel streaming can I somehow
alter the ksproxy to copy the buffers? or maybe can the ksproxy plugin
can provide more than only extending property types?
A ksproxy plugin is handed a pointer to the DirectShow graph that is
being constructed. Theoretically, it might be possible for the plugin
to reconfigure the graph and insert a new filter to siphon off frames,
but the application is in control and might undo what you change. Plus,
what would you do with the frames once you had them? You still have a
storage and interprocess communication problem.
or maybe an option is just to write a user mode driver which calls the
kernel streaming and does the streaming duplication? what API do I
need to implement so my user mode driver is exposed to apps as a web cam?
Yes, that’s an option. Note that it’s not a user-mode driver in the
UMDF sense; the Kernel Streaming ioctls use METHOD_NEITHER communication
in a way that UMDF simply cannot handle. I’ve tried.
However, you can certainly write a DirectShow source filter that serves
the same purpose as ksproxy for your specific camera. All you need is a
little bit of registry tweaking to make your filter appear in the list
of “Video Capture Sources”, and capture apps will find you just like a
hardware webcam. There is a sample capture source filter here,
contributed by Vivek, that shows how to do that registration:
http://tmhare.mvps.org/downloads.htm
HOWEVER, you still have the same problem of storage and IPC. How are
you going to get those frames to your monitoring process?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Hi Tim,
regarding teh properties, you mean this could just be a communication way?
but it’s just to request frames in a certain framerate not that the device
sends teh frames when it gets them, is this what you mean?
regarding creating my own ksproxy this is really interesting.
do you know if I can also block the original webcam driver? from being
displayed to webcam apps. if I want to force all to use my ksproxy as the
source is there any way to do so? regarding the registry tweeking where
can I find how to do this?
storage and IPC I will need to handle anyway, I can handle this in the code
I will write for teh “ksproxy” duplciate buffers and send per request.
thanks!!
regarding the sample it has only source code with no intstructions of how
to register as a ksproxy
On Mon, Aug 25, 2014 at 8:33 PM, Tim Roberts wrote:
> Miriam Engel wrote:
>
> Hi Tim,
>
> >Each filter can be part of a different process,
> >but they all share the same device. Thus, you could do your buffer
> >sharing there.
>
> there meaning in the filter? do you mean creating 2 separate filters
> connecting to the source? what type of filters and where / how will the
> buffer be shared/ copied?
>
>
> You have looked at the architecture of an AVStream driver, right? There
> are “devices”, “filters”, and “pins”. Each instance of the driver (which
> means each single piece of hardware) has one device. That device can
> expose multiple filters, or one filter that can be loaded multiple times.
> All of those filter instances share the same device. The filter modules in
> the AVStream samples all call in to the device to communicate with the
> hardware.
>
> Because you have that communication, the device can hold data that is
> common to all of the filters, including copies of the last frames.
>
>
>
> >you just want a side door, and you don’t really need another
> >DirectShow graph, you can do that using extra properties without going
> >to the trouble of streaming it.
>
> I do need actual copy of the streaming so only properties won’t help,
> nevertheless I don’t care about the resolutions etc.
>
>
> You don’t understand what I’m saying. The “property” interface into an
> AVStream filter is basically the same as the ioctl interface to a WDM
> driver. You can pass anything in and out. So, for example, you could have
> your monitoring application create a new instance of the filter (which is
> easy), and then just send a custom property that says “return the next
> frame to me”. That would require less application overhead than creating
> an entire DirectShow graph to stream those frames, although the driver side
> is probably not any simpler.
>
>
>
> regarding the kspoxy, thanks for the explanation, the ksproxy plugin for
> properties won’t help me, but as the ksproxy is a spcial type of filter
> wrapping communication withe the kernel streaming can I somehow alter the
> ksproxy to copy the buffers? or maybe can the ksproxy plugin can provide
> more than only extending property types?
>
>
> A ksproxy plugin is handed a pointer to the DirectShow graph that is being
> constructed. Theoretically, it might be possible for the plugin to
> reconfigure the graph and insert a new filter to siphon off frames, but the
> application is in control and might undo what you change. Plus, what would
> you do with the frames once you had them? You still have a storage and
> interprocess communication problem.
>
>
>
> or maybe an option is just to write a user mode driver which calls the
> kernel streaming and does the streaming duplication? what API do I need to
> implement so my user mode driver is exposed to apps as a web cam?
>
>
> Yes, that’s an option. Note that it’s not a user-mode driver in the UMDF
> sense; the Kernel Streaming ioctls use METHOD_NEITHER communication in a
> way that UMDF simply cannot handle. I’ve tried.
>
> However, you can certainly write a DirectShow source filter that serves
> the same purpose as ksproxy for your specific camera. All you need is a
> little bit of registry tweaking to make your filter appear in the list of
> “Video Capture Sources”, and capture apps will find you just like a
> hardware webcam. There is a sample capture source filter here, contributed
> by Vivek, that shows how to do that registration:
> http://tmhare.mvps.org/downloads.htm
>
> HOWEVER, you still have the same problem of storage and IPC. How are you
> going to get those frames to your monitoring process?
>
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
–
Miriam Engel
Miriam Engel wrote:
regarding teh properties, you mean this could just be a communication
way? but it’s just to request frames in a certain framerate not that
the device sends teh frames when it gets them, is this what you mean?
Yes, it’s another option. You could have the streaming pin tuck a copy
of the most recent frame in the device. Then, your monitor app could
just send a single ioctl saying “send me the most recent frame” or “send
me the next frame”. That’s probably less overhead than implementing a
second pin.
regarding creating my own ksproxy this is really interesting.
do you know if I can also block the original webcam driver? from being
displayed to webcam apps. if I want to force all to use my ksproxy as
the source is there any way to do so?
There’s no good way to remove it from the list AND still be able to
access it from your own source filter. There are some slimy ways, but
they would cause their own issues.
regarding the registry tweeking where can I find how to do this?
I gave you the freaking link in my first email.
regarding the sample it has only source code with no intstructions of
how to register as a ksproxy
Of course it does. You’re not really “registering as a ksproxy”. You
are registering as a source filter in the VideoInputDeviceCategory. In
DLL.cpp, in the RegisterFilters function, you’ll see that it calls
IFilterMapper2::RegisterFilter to add the CLSID to the
VideoInputDeviceCategory. That’s all it takes. When capture
applications go to find capture devices, they just enumerate all of the
source filters in CLSID_VideoInputDeviceCategory. As long as you
register yourself there, you’ll be on equal footing with any AVStream
driver.
By the way, this doesn’t work for every application. Skype, for
instance, absolutely demands a kernel-based driver.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Hi Tim.
thanks your professional replies.
Yes, it’s another option. You could have the streaming pin tuck a copy
of the most recent frame in the device. Then, your monitor app could
just send a single ioctl saying “send me the most recent frame” or “send
me the next frame”. That’s probably less overhead than implementing a
second pin.
Regarding driver side it should monitor and save every frame, so it will be
available for the other app requesting via properties
some questions I have:
- if regular app was the first to request streaming it will work, what if
my app is the first to request streaming? can I set the setstate to running
and get frames from a property implementation? in a way that after I
started streaming -via properties another app let’s sat skype will be able
to stream? - can it be done in an avstream minidriver?
- ideally I’d like to use the existing UVCDriver which my webcam currently
uses ( USBVideo.sys/ USB Video Class) I saw the extensions that are
possible to do for the USB Video Class, how ever as far as I understand
they are all in the user mode layer, can I use this in order to save the
frames/ set camera state? if yes how?
p.s. thanks for mentioning skype demands kernel based driver this saved me
from investigating in that direction and then finding out it does not match
my needs.
thanks a lot!
On Wed, Aug 27, 2014 at 8:33 PM, Tim Roberts wrote:
> Miriam Engel wrote:
> >
> > regarding teh properties, you mean this could just be a communication
> > way? but it’s just to request frames in a certain framerate not that
> > the device sends teh frames when it gets them, is this what you mean?
>
> Yes, it’s another option. You could have the streaming pin tuck a copy
> of the most recent frame in the device. Then, your monitor app could
> just send a single ioctl saying “send me the most recent frame” or “send
> me the next frame”. That’s probably less overhead than implementing a
> second pin.
>
>
>
> > regarding creating my own ksproxy this is really interesting.
> > do you know if I can also block the original webcam driver? from being
> > displayed to webcam apps. if I want to force all to use my ksproxy as
> > the source is there any way to do so?
>
> There’s no good way to remove it from the list AND still be able to
> access it from your own source filter. There are some slimy ways, but
> they would cause their own issues.
>
>
> > regarding the registry tweeking where can I find how to do this?
>
> I gave you the freaking link in my first email.
>
>
> > regarding the sample it has only source code with no intstructions of
> > how to register as a ksproxy
>
> Of course it does. You’re not really “registering as a ksproxy”. You
> are registering as a source filter in the VideoInputDeviceCategory. In
> DLL.cpp, in the RegisterFilters function, you’ll see that it calls
> IFilterMapper2::RegisterFilter to add the CLSID to the
> VideoInputDeviceCategory. That’s all it takes. When capture
> applications go to find capture devices, they just enumerate all of the
> source filters in CLSID_VideoInputDeviceCategory. As long as you
> register yourself there, you’ll be on equal footing with any AVStream
> driver.
>
> By the way, this doesn’t work for every application. Skype, for
> instance, absolutely demands a kernel-based driver.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
Miriam Engel wrote:
Regarding driver side it should monitor and save every frame, so it
will be available for the other app requesting via properties
Well, you obviously can’t save “every frame”, because you don’t have an
infinite amount of memory. You would probably save “the most recent
frame”, and make it available via property.
some questions I have:
- if regular app was the first to request streaming it will work,
what if my app is the first to request streaming? can I set the
setstate to running and get frames from a property implementation? in
a way that after I started streaming -via properties another app let’s
sat skype will be able to stream?
Skype expects to be able to change the resolution, many times. How
would you manage that? If you’re already streaming, how could you allow
the format to change? There’s no way for the filter to force your
monitor application to change its format. That requires new buffers.
The stream has to stop and rebuild.
This is why I’m suggesting that you use properties. That way, your app
can just issue a request saying “send me the next frame”. The filter
itself is not streaming yet, so Skype can come in, do its negotiation,
set its format, and start streaming. Only then would your app get a
response.
- ideally I’d like to use the existing UVCDriver which my webcam
currently uses ( USBVideo.sys/ USB Video Class) I saw the extensions
that are possible to do for the USB Video Class, how ever as far as I
understand they are all in the user mode layer, can I use this in
order to save the frames/ set camera state? if yes how?
I thought we already talked about this. For a usbvideo.sys camera,
ksproxy extensions are only used to handle UVC Extension Units. They
are not involved in streaming. They never see the frames.
I recently did a driver for a client that wanted to apply visual effects
to a camera stream using a separate user-mode application, and change
the format as well. I had to write an upper filter driver for
usbvideo.sys to intercept the frames, hold them until the user-mode app
processed them, then send the modified frames back up to DirectShow. It
was about 5,000 lines of code, made trickier by the fact that the
details of the KS ioctls are not fully documented.
The interface between my filter and the user-mode processing app was
entirely custom. This was outside the world of AVStream and DirectShow.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.