Re: [libdc] changes in code between legacy and juju stacks?
Capture and control API for IIDC compliant cameras
Brought to you by:
ddouxchamps,
gordp
Menu
▾
▴
Re: [libdc] changes in code between legacy and juju stacks?
|
From: Brice R. <bri...@gm...> - 2013-08-16 20:17:15
|
Btw, I can't see any effect of the compression level (i.e. setting it to a low value does not result in a low res image). Is it actually supported by the camera? Also, in format7 mode 7, what's the actual size of the image / packet? I set the ROI width to 808 and height to 850 and I get mostly valid images. With h<850 I can't decode the image. With h>850 it works but does it result in larger packets? Since the images are jpeg compressed, the total number of bytes should depend on the complexity of the image... In the code you sent me it says: #define HEIGHT 5000 //MAX 14784 No more fps smaller than 5000. Increase, decrease related to fps I don't get it. For years we have been using 3950 (but I don't know why), and it was working fine. Brice Can somebody explain the effect of adjusting the height of the ROI in mode7? And how to know the actual size of the packet? On 08/15/2013 04:53 PM, Brice Rebsamen wrote: > Hi Josep > > Changing the bpp from 9792 to 8160 solved the problem. Thank you so > much, I've wasted a lot of time on that. > > Brice > > On 08/13/2013 03:48 AM, Josep Bosch wrote: >> Hi Brice, >> >> Please find attached a script that works for me. It captures images >> in format 7 mode 7 as your code and save them to the HD. >> I had a quick look at your code and I noticed that you are trying to >> use a packet size of 9792. I couldn't manage to make it work at so >> big packets size, not sure if it was because my adapter or why, but I >> needed to decrease it to 8160 to make it work for me. >> >> I'm in holidays now and I couldn't test your code with the camera, >> but back to the lab I will test it if you couldn't solve it yet. >> >> Sorry for my slow reply. >> >> Cheers, >> >> Josep >> >> >> >> 2013/8/8 Brice Rebsamen <bri...@gm... >> <mailto:bri...@gm...>> >> >> Josep, >> >> My code does not even work with 3.2.0-48. So I'm back to my >> initial thought: it may be that my old dc1394 code (written for >> the legacy stack) has to be modified somehow to work with the >> juju stack. Could you either take a quick look at my code (the >> one I already sent some days ago, attached here again) and >> compare it with yours, or maybe just send me your code and I'll >> test it and compare it with mine? That would be very helpful. >> >> Brice >> >> >> >> On 08/05/2013 04:38 PM, Brice Rebsamen wrote: >>> Hi, and thanks for helping me, >>> >>> I tried with kernel 3.2.0-48 that Josep said was working, but it >>> didn't work for me. So it's probably a different issue. >>> >>> I have a LSI Corporation FW643 PCI Express 1394b Controller >>> (PHY/Link) >>> >>> I am not sure how large is the packet. According to flycap, the >>> max image size is 808*14784, which corresponds to 6 1600x1200 >>> images, where the 4 RGGB images have been separated and stacked >>> together. The whole thing is compressed and the jpeg compression >>> factor can be adjusted (probably allow reducing the bandwith). >>> >>> Now, in my old code the image height was set to 3950, and the >>> compression factor to 92, which works well with the legacy >>> stack. I have no idea where the 3950 comes from and how come I >>> still get the whole image with that. I tried setting it to 14784 >>> but it fails with the following error message: >>> >>> libdc1394 error: VIDEO1394_IOC_LISTEN_CHANNEL ioctl failed: >>> Invalid argument >>> libdc1394 error: Error: Failed to setup DMA capture >>> >>> >>> In the new stack, I get 2000 or more fps ! Same in corriander. >>> >>> I'm attaching the code I'm using. Again, that was working under >>> Lucid with the legacy stack. >>> >>> Thanks >>> Brice >>> >>> >>> >>> >>> On Sun, Aug 4, 2013 at 4:09 PM, Stefan Richter >>> <st...@s5... <mailto:st...@s5...>> >>> wrote: >>> >>> On Aug 04 Brice Rebsamen wrote: >>> > Thanks Josep >>> > >>> > You said that it was working with Kernel 3.2.0-48 and >>> below and that it >>> > started in 3.3; for me it fails with 3.2.0-51... >>> > Anyway, I'll try the patch tomorrow, but I wanted to know >>> first, is it >>> > for kernel 3.2? >>> >>> The patch is only applicable to kernels which contain the >>> particular >>> regression, i.e. 3.4 and later. >>> >>> Either you have a kernel into which the regressing change >>> from 3.4 was >>> backported (and then the fix can and should be backported as >>> well), or >>> your problem is something different from that 3.4 regression >>> altogether >>> (hence also not addressed by this patch). According to what >>> I am seeing >>> in http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-precise.git, the >>> regressing change was not backported into the Ubuntu 12.05 >>> kernel, and the >>> patch is neither applicable nor relevant. >>> >>> You wrote you use large packets. How large? >>> Are you using a 1394 controller from Texas Instruments or >>> from Agere/ LSI? >>> -- >>> Stefan Richter >>> -=====-===-= =--- --=-= >>> http://arcgraph.de/sr/ >>> >>> >> >> > |