Re: Question about Camera driver with DirectShow
- From: "GodzillaHaur" <GodzillaHaur@xxxxxxxxx>
- Date: 13 Jul 2005 18:51:59 -0700
Mr. Daniels:
(A) About the test,602, yesterday I found that this test passed.
With uninstalling all LTK databases and rollup porgrams, I install LTK
WMCETK Updates for May and June. Then it passes.
(B) About tests in "camera test", they are the same cases, 1016, 1018,
1025, 1027.
(C) Does the null driver support YUV422?
GodzillaHaur 寫道：
> Mr. Daniels:
>
> (A)
> About the test,602, it passed once with the original CETK in Microsoft
> Platform Builder for Windows Mobile 5.0 (build_14343). After updating
> LTK QFE update with May, june, and july 1, it failed consistently.
>
> (B)
> I did not made any modifications to the NULL driver. I buildt it in the
> public directory. First step is build -c. Then I used sysgen to get the
> nullcam.dll.
>
> My device is with a samsung 2440A ARM processer, 400MHz, 64MB RAM, and
> DDraw disabled.
>
> I tried the camera application in pimg.exe. Basicly, I used it to test
> CETK with the item test, camera test.
>
> There seem to be a long delay for video captures in this test case,
> 602. The video files captured are playable and they are a little jerky.
>
> When I run the test, you run it after freshly booting the device, and
> run all camera tests (including data structure, I/O, performance, DShow
> integration, and camera test). After freshly booting the device, I only
> run the DShow integration test. The result is the same with running all
> camera tests.
>
> Gary Daniels [MS] 寫道：
> > I honestly don't know what the cause of the failure you're seeing in test
> > 602. Does the test fail consistently?
> >
> > When starting a video capture, the test calls
> > ICaptureGraphBuilder::ControlStream which in then calls StartAt and StopAt
> > on each of the filters in the graph. When the filters finish processing the
> > StartAt/StopAt they send an EC_STREAM_CONTROL_STARTED or
> > EC_STREAM_CONTROL_STOPPED event back to the application. There's two
> > separate captures happening simultaniously, one for audio and one for video.
> > In this case the test does a ControlStream with the start time and stop time
> > for a capture, but EC_STREAM_CONTROL_STOPPED event is never returned for the
> > video capture. The only way this would happen is if the last video frame is
> > never processed. The test has a timeout of 5 minutes when retrieving the
> > media event, so it's not a timing issue where the test isn't waiting long
> > enough, it really is that the event is never being sent.
> >
> > Have you made any modifications to the NULL driver? Can you give me any
> > specifications on your device? From the previous posts i've gathered that
> > it's an ARM processor, what's the processor speed, available RAM, and is the
> > display driver ddraw enabled? Have you tried the camera application in
> > pimg.exe? Does there seem to be a long delay for video captures, or do they
> > go quickly? Are the video files captured playable, and if so are they smooth
> > or jerky? When you run the test, do you run it after freshly booting it or
> > are you running other tests before this one?
> >
> > As for frame buffer allocation, we support three different modes, driver
> > allocated, DirectShow allocated with a limited number of buffers, and
> > DirectShow allocated with the ability to add additional buffers as needed.
> >
> > So, here's some scenarios:
> > if your camera driver can fill a frame buffer using hardware without
> > using the CPU then you'll want to use driver allocated buffers. The
> > advantage here is you won't have to do any memory copies for filling the
> > video buffers and if your display hardware can access the camera video
> > memory then you may not need to do any memory copies for rendering the video
> > to the screen (the Bitblt/flip may be done in hardware).
> >
> > if your display driver supports overlays, flipping overlays, etc. then
> > you'll want to use DirectShow limited allocating which will let the
> > VideoRenderer allocate video memory buffers through DDraw. This has the
> > advantage of being tear free in the preview and generally uses hardware for
> > filling the overlay.
> >
> > if you have no hardware for your display driver and no camera hardware
> > for filling the video frames, then the DirectShow unlimited buffering is
> > good because you do one memory copy when filling the buffer within the
> > driver, and then that buffer is not re-copied within the buffering filter
> > for post processing (non-realtime encoding). If you were to use limited
> > buffering then a copy of the buffer would need to be made in order to pass
> > the original buffer back to the camera driver to be filled again.
> >
> > Video ports are currently not supported.
> >
> > 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.
.
- References:
- Re: Question about Camera driver with DirectShow
- From: GodzillaHaur
- Re: Question about Camera driver with DirectShow
- From: Gary Daniels [MS]
- Re: Question about Camera driver with DirectShow
- From: GodzillaHaur
- Re: Question about Camera driver with DirectShow
- Prev by Date: strange stack problem
- Next by Date: Is there any sample or resource for MAMM?
- Previous by thread: Re: Question about Camera driver with DirectShow
- Next by thread: Windows CE 1.0 SDK
- Index(es):
Relevant Pages
|
