USBCAMD2 Video Freeze issue.

Hi all,

I'm having a stange problem with a USBCAMD2 based driver for a custom USB
camera we're working on. We have only 1 video stream whose format is RGB24.
In ProcessRawVideoFrameEx(), if I do the following:

frameBuffer = (BYTE*)FrameBuffer;
frameBuffer[0] = frameBuffer[1] = frameBuffer[2] = 0;
.
. fill in the rest of the frame buffer with actual data
.

the video frame is not drawn. However, if frameBuffer[0], frameBuffer[1], or
frameBuffer[2] is non-zero, the video frame is drawn (Note that only one
needs to be non-zero, not all three).
We noticed this because the video stream would "freeze" whenever the first
pixel was completely black RGB(0,0,0). As soon as the pixel goes to anything
but black, the video resumes.

Has anyone else seen this? I find it quite bizarre & can't figure out why
it's doing it.

Thanks,
Jerry

Tim
Fri May 28 00:59:32 CDT 2004

"jerry" <jerryryle@yahoo.com> wrote:
>
>I'm having a stange problem with a USBCAMD2 based driver for a custom USB
>camera we're working on. We have only 1 video stream whose format is RGB24.
>In ProcessRawVideoFrameEx(), if I do the following:
>
>frameBuffer = (BYTE*)FrameBuffer;
>frameBuffer[0] = frameBuffer[1] = frameBuffer[2] = 0;
>.
>. fill in the rest of the frame buffer with actual data
>.
>
>the video frame is not drawn. However, if frameBuffer[0], frameBuffer[1], or
>frameBuffer[2] is non-zero, the video frame is drawn (Note that only one
>needs to be non-zero, not all three).
>We noticed this because the video stream would "freeze" whenever the first
>pixel was completely black RGB(0,0,0). As soon as the pixel goes to anything
>but black, the video resumes.

Some USB camera drivers use an all black pixel as a signal that something
has gone bad in the pixel path, since real cameras don't produce true
black.
--
- Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc

jerry
Fri May 28 12:06:33 CDT 2004

Hrm..interesting. Thanks for the response. But is it documented somewhere
that returning 0 for the first pixel in the framebuffer will drop the frame?
According to the DDK, in CamProcessRawVideoFrameEx():
BytesReturned - Pointer to the number of bytes read. The minidriver must set
this to zero if it encounters any errors during processing.

But for the framebuffer, it just says:
FrameBuffer - Pointer to the buffer that receives the final processed video
frame.

And there aren't any remarks about a zero pixel in the first location of the
framebuffer dropping the frame. I also looked around in the DirectX
documentation a bit, but couldn't find anything there either.

I could imagine that this is a bug or undocumented feature that hasn't
bitten many people as I understand cameras generally don't produce actual
black. Our camera generates an overlay on the video & the first pixel
happens to be RGB(0,0,0). For now, I just set an insignificant bit of the
first pixel to ensure it's not zero. This does fix the frozen video symptom,
but I'd love confirmation that this is a "feature" to ensure I'm not doing
something else wrong.

Thanks,
Jerry


"Tim Roberts" <timr@probo.com> wrote in message
news:07ldb0525nigf0mlvi6788jotfrfo6fee5@4ax.com...
> "jerry" <jerryryle@yahoo.com> wrote:
> >
> >I'm having a stange problem with a USBCAMD2 based driver for a custom USB
> >camera we're working on. We have only 1 video stream whose format is
RGB24.
> >In ProcessRawVideoFrameEx(), if I do the following:
> >
> >frameBuffer = (BYTE*)FrameBuffer;
> >frameBuffer[0] = frameBuffer[1] = frameBuffer[2] = 0;
> >.
> >. fill in the rest of the frame buffer with actual data
> >.
> >
> >the video frame is not drawn. However, if frameBuffer[0], frameBuffer[1],
or
> >frameBuffer[2] is non-zero, the video frame is drawn (Note that only one
> >needs to be non-zero, not all three).
> >We noticed this because the video stream would "freeze" whenever the
first
> >pixel was completely black RGB(0,0,0). As soon as the pixel goes to
anything
> >but black, the video resumes.
>
> Some USB camera drivers use an all black pixel as a signal that something
> has gone bad in the pixel path, since real cameras don't produce true
> black.
> --
> - Tim Roberts, timr@probo.com
> Providenza & Boekelheide, Inc

Tim
Sat May 29 17:33:00 CDT 2004

"jerry" <jerryryle@yahoo.com> wrote:
>
>Hrm..interesting. Thanks for the response. But is it documented somewhere
>that returning 0 for the first pixel in the framebuffer will drop the frame?

No, I was actually trying to imply that it was something later on in your
driver -- perhaps some code left over from wherever the driver originally
came from. As far as I know, nothing in the Microsoft code ever looks at
the colors of the pixels.

Do you have any idea where the frame is actually going awry? Can you trace
it out of your driver into the user mode graph?
--
- Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc

Jerry
Wed Jun 02 12:16:25 CDT 2004

Well, I stepped out of CamProcessRawVideoFrameEx() and it looks like
USBCAMD2 immediately compares the first location of the frame buffer (as an
INT32) with zero. I first thought it was looking at BytesReturned, but the
location is really ((INT*)FrameBuffer)[0].

I just tried nopping out this compare in USBCAMD. That fixed it. The frames
are no longer dropped & I can even see a black pixel in the corner where
it's supposed to be.

For now, my workaround is to have CamProcessRawVideoFrameEx() ensure that
pixel zero is never true black, but it would still be nice to figure out
exactly why this feature exists.

--Jerry

"Tim Roberts" <timr@probo.com> wrote in message
news:6p3ib0h16jsc3oir37hro1ds4beiv4kkms@4ax.com...
> "jerry" <jerryryle@yahoo.com> wrote:
> >
> >Hrm..interesting. Thanks for the response. But is it documented somewhere
> >that returning 0 for the first pixel in the framebuffer will drop the
frame?
>
> No, I was actually trying to imply that it was something later on in your
> driver -- perhaps some code left over from wherever the driver originally
> came from. As far as I know, nothing in the Microsoft code ever looks at
> the colors of the pixels.
>
> Do you have any idea where the frame is actually going awry? Can you
trace
> it out of your driver into the user mode graph?
> --
> - Tim Roberts, timr@probo.com
> Providenza & Boekelheide, Inc