Re: Question about Camera driver with DirectShow

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.

.

Relevant Pages

  • Re: Question about Camera driver with DirectShow
    ... Does the null driver support YUV422? ... > I tried the camera application in pimg.exe. ... The video files captured are playable and they are a little jerky. ... >> As for frame buffer allocation, we support three different modes, driver ...
    (microsoft.public.windowsce.embedded)
  • Re: Mapping kernel memory to user space
    ... > I have a USB high-speed camera driver. ... > out of my camera thorugh USB is about 45MB/s. ... > buffer to user-provided buffer. ... > application or even playing with a mouse resulted in frame drops. ...
    (microsoft.public.development.device.drivers)
  • Re: Mapping kernel memory to user space
    ... > I have a USB high-speed camera driver. ... > out of my camera thorugh USB is about 45MB/s. ... > buffer to user-provided buffer. ... > application or even playing with a mouse resulted in frame drops. ...
    (microsoft.public.development.device.drivers)
  • Mapping kernel memory to user space
    ... I have a USB high-speed camera driver. ... buffer to user-provided buffer. ... application or even playing with a mouse resulted in frame drops. ...
    (microsoft.public.development.device.drivers)
  • bt848 video capture driver
    ... The driver doesn't attach at boot, but I can get it to run using modload. ... stubbornly refuses to recognise that the machine has a video capture card. ... The camera I'm using is a fairly basic Philips model borrowed ... nothing terribly serious or needing ultra high quality or complex ...
    (comp.unix.solaris)
Loading