[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [libcvd-members] Issues converting Rgb<byte> to byte with V4L1

From: Edward Rosten
Subject: Re: [libcvd-members] Issues converting Rgb<byte> to byte with V4L1
Date: Wed, 1 Oct 2008 11:37:07 -0600 (MDT)

On Sun, 28 Sep 2008, Casey Link wrote:


A project I am working on implements libcvd, and I'm having some
troubles adapting it to my V4L1 camera.

First, I should note that I am using the V4L1Buffer< Rgb<byte> >
object, and I give this emphasis because in the documentation[1] it
says "<CVD::Rgb<CVD::byte> > should work to but crashes with my
current driver ?!"
That pretty much sums up the issues I am having.

Specifically, line 99  of cvd/internal/convert_pixel_types.h segfaults:
0xb7d82169 in CVD::ConvertImage<CVD::Rgb<unsigned char>, unsigned
char, CVD::Pixel::CIE<CVD::Rgb<unsigned char>, unsigned char>,
1>::convert (address@hidden, address@hidden)
 at ./cvd/internal/convert_pixel_types.h:99
99                to = scalar_convert<Scalar,typename
Pixel::Component<Rgbish>::type,double>(wr* + wg* +

We've (a teammate and I) traced the problem back to
cvd_src/i686/, and we think the issue stems from
the while() control structure not terminating correctly. I printed the
output of steps_to_align() for 'rgb' and 'gray' and here is a sample
of the output:
I think that either rgb or gray are being ++ed outside the allocated
memory for the program.

Looks like it. As a temporary workaround, try compiling the library with --without-assembler, which should substitute the file cvs_src/noarch/

Can you try this and see if it works?

The code that calls all this is:
V4L1Buffer< Rgb<byte> >* pvb = (V4L1Buffer< Rgb<byte> >*) mptr;
VideoFrame<Rgb<byte> > *pVidFrame = pvb->get_frame();
convert_image(*pVidFrame, imBW);     // This one fails
convert_image(*pVidFrame, imRGB);

What's strange is that the first time the above code is called, it
works fine, but the second time it dies on the indicated line.

This could indicate that the problem is elsewhere. Trashing memory can have delayed effects. Have you tried running the program through valgrind?

I'm using the CVS version of libcvd, gcc 4.2.3, and you can see my
v4l1 device information here: I just noticed in that info
output that my camera claims to support RGB24 - there's no mention of
RGB 16 - could this be related?

This should be OK. There's no code in libCVD for rgb16 (presumably 565) at the moment.

I'd appreciate any suggestions :) I'm almost tempted to go try  a V4L2 camera.

If you can play video with video_play_source, then it should be OK to use the camera. As an alternative, you could try running the code on a list of images (using a videofilebuffer). Again, this will test your part of the code, while temporarily avoiding any wierdness from V4L (of which there is no shortage :-)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]