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

[Edward Rosten]

On Sun, 28 Sep 2008, Casey Link wrote:

> Hello,
>
> 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*from.red + wg*from.green +
> wb*from.blue);
>
> We've (a teammate and I) traced the problem back to
> cvd_src/i686/convert_rgb_to_y.cc, 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: http://www.binaryelysium.com/steps_to_align.txt
> 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/convert_rgb_to_y.cc

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);
> pvb->put_frame(pVidFrame);
>
> 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:
> http://www.binaryelysium.com/v4l_info.txt. 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 :-)


-Ed