Re: DirectShow @ WM 5.0: Capture camera to memory?
- From: "Gary Daniels [MS]" <garydan@xxxxxxxxxxxxxxxxxxxx>
- Date: Fri, 30 Sep 2005 15:54:18 -0700
Sounds very cool. :)
Depending on the capabilities of the hardware you're running on it may or
may not be able to do 5 frames per second, that framerate is quite low. I'd
expect most capture pins to deliver 15-30 frames per second but at low
resolutions due to the software overhead of encoding and displaying a
preview. The still image pin will most likely expose higher resolutions than
the capture pin which could negativly impact your performance, but it would
allow you to run with the ultra low frame rates. I suspect you'll find your
best performance when running with the capture pin at it's lowest supported
resolution and frame rate. If the frame rate is too high you could analyze 1
in N samples delivered and just release the rest, the software overhead
should be minimal for just delivering the media sample (a memcopy),
especially if the device uses hardware to fill the video buffer.
You'll need to create a sink filter that does your processing, RGB video
formats will probably be the easiest to get you started, if your camera
doesn't support RGB outputs then you can connect the color converter filter
between the video capture filter and your filter. Later you can figure out
what YUV formats the driver outputs (YUV422 and YV12 i think are the most
common) and implement your algorithm using those to optimize performance, if
needed. fourcc.org has info on how to interpret the video formats.
Your sink filter will connect to the still image pin or capture pin on the
video capture filter, there's nothing special with the media types exposed
by those pins. If you find the overhead of using the capture pin to be too
much, it should be simple to change the sink filter to connect to the still
image pin and implement a software timer to trigger still images instead. I
think the increased resolution and software overhead for the timer will
reduce performance more than throwing away a few unneeded samples.
I get the impression from your email that you're not too familiar with
DirectShow. I'd recommend playing around with GraphEdit on Windows XP. It's
included in the desktop DirectX SDK, and I find it very useful in
visualizing what's going on. If you drag video files into it, it'll show
you the DirectShow filtergraph built to render the video. If you have a WDM
camera attached to the system you can insert the filter and render it to the
video renderer to see the output of the camera. DirectShow on Windows CE &
Windows Mobile 5.0 is the same technology as on the desktop (give or take a
few features). Once you learn how to implement filters for DirectShow,
everything i've said should make a lot more sense.
Windows CE Multimedia and Graphics
This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use.
"Ulrich Kreuzeder" <u l r i c h . k r e u z e d e r @ l i w e s t . a t>
wrote in message news:1128104079.581140@xxxxxxxxxxxxxxxxx
> Wow, this was a lot of information, I'm still chewing...
>
> Ok, so here is the goal: I want to create a library that fires events in
> case of the user
> tilting his PDA. This could be used for many funny games and applications.
>
> The events should contain information about how far the device has been
> moved
> on two axes: sideways and forwards/backwards.
>
> There are some algorithms in the literature to detect such movements, look
> for
> "optical flow analysis". These algorithms work on computing flow vectors
> between
> two images.
>
> So, what I need is a background thread constantly sampling images and
> calculating
> flow vectors. The thread should not use much processing time (leaving
> enough CPU time
> for the real application) but should be able to detect movements fast
> enough.
>
> My estimation is that 5 samples per second would be okay. I also think
> that it won't
> be necessary to compare samples in the full camera resolution, parts of
> the full
> picture and/or a reduced resolution should be sufficient.
>
> I don't need to keep the captures images, they can be thrown away
> immediately
> after computing movements.
>
> Do you still think that I should rather capture videos, not still images?
>
> Greetings,
> Ulrich
>
> "Gary Daniels [MS]" <garydan@xxxxxxxxxxxxxxxxxxxx> wrote in message
> news:eZle6HHxFHA.2728@xxxxxxxxxxxxxxxxxxxxxxx
>>A little more information on what your goal is would be useful, i'm making
>>a lot of assumptions about what your goals are.
>>
>> You want to process a sequence of still images (which is basically
>> video). The still image pin probably isn't what you want unless you want
>> to manually trigger the sequence over a long period of time (one frame
>> every few seconds, not multiple frames per second). I'm assuming you
>> don't want to interoperate with the camera application, you're writing
>> your own app. If you want to replace a filter the camera application uses
>> it would be significantly more difficult, you have to implement all of
>> the right interfaces on your filters and also adjust the registry keys to
>> get it into the graph.
>>
>> The video capture filter is what talks to the camera driver, it has up to
>> 3 outputs, preview, capture, and still. Most drivers only have two
>> outputs, capture and still, which results in the tee filter being
>> connected to the capture output to create the preview. If you just want
>> to process some images from the camera, all you would need to do is use
>> the capture graph builder to connect the video capture filter to a sink
>> filter you would create to do your processing. Implement some custom
>> interfaces on that filter or trigger some events within the filter to
>> signal the results of your processing back to your app. You can set the
>> media type and frame rate before connecting your filter, so you can get
>> the frame rate and video format you want. If you want to have a preview
>> in your app you would connect the smart tee into the graph and put in the
>> video renderer. If you want to manually trigger the video, it would be
>> the same but you would connect to the still pin instead of the capture
>> pin and your application would have to trigger the pin for each video
>> sample.
>>
>> There's sample code snippets available on MSDN for most of this.
>> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wcemultimedia5/html/wce51conVideoCaptureFilters.asp
>>
>> If you're not familiar with creating DirectShow filters, i recommend
>> "Programming Microsoft DirectShow for Digital Video and Television."
>>
>> The camera driver model is different than on desktop windows, however
>> from a DirectShow perspective it should work pretty much the same.
>>
>> Gary Daniels
>> Windows CE Multimedia and Graphics
>>
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>> You assume all risk for your use.
>>
>> "Louis Clausen [MS]" <louiscl@xxxxxxxxxxxxxxxxxxxx> wrote in message
>> news:u2CaQA8wFHA.1556@xxxxxxxxxxxxxxxxxxxxxxx
>>>I do not know the details of how to do it, but the basic idea is you
>>>would need to implement your own sink filter that exposes the
>>>IImageSinkFilter interface. This is not a trivial task, however.
>>>
>>> http://msdn.microsoft.com/library/en-us/wcemultimedia5/html/wce51lrfImageSinkFilter.asp
>>>
>>> Once you have that filter implemented, you can create a capture graph,
>>> use GetFilterGraph to get the IGraphBuilder object, then enumerate the
>>> filters to find the IImageSinkFilter object, its input pin, and the
>>> output pin that is connected. Once you have these, you can use the
>>> IGraphBuilder to disconnect the pins, remove the IImageSinkFilter
>>> filter, add your own filter, and connect the original output pin to your
>>> filter's input pin.
>>>
>>> --
>>> Louis Clausen
>>> Software Design Engineer in Test
>>> Windows CE Multimedia
>>>
>>> This posting is provided "AS IS" with no warranties, and confers no
>>> rights.
>>> You assume all risk for your use.
>>>
>>> "John Smith" <someone@xxxxxxxxxxxxx> wrote in message
>>> news:1127770874.143025@xxxxxxxxxxxxxxxxx
>>>> Hello,
>>>>
>>>> what would be the correct / easiest way to use DirectShow to write
>>>> still images captured from camera to memory directly instead of JPEG
>>>> files?
>>>>
>>>> I want to play around a little with optical flow analysis and for that
>>>> need to capture sequences of still images from the built-in camera.
>>>> There is a DirectShow capture sample in the SDK but the sample stores
>>>> images to JPEG files and therefore would cost too much performance for
>>>> me.
>>>>
>>>> Do I have to create a custom multiplexer filter and add that to the
>>>> filter graph with ICaptureGraphBuilder2::SetOutputFileName instead of
>>>> using the ASF multiplexer?
>>>>
>>>> Greetings,
>>>> Ulrich
>>>>
>>>
>>>
>>
>>
>
>
.
- Prev by Date: not valid WINDOWS CE application
- Next by Date: Re: keyboardHook question...suppressing WM_KEYDOWN
- Previous by thread: not valid WINDOWS CE application
- Next by thread: Re: keyboardHook question...suppressing WM_KEYDOWN
- Index(es):
Relevant Pages
|
