Web lists-archives.com

Re: Camera preview, thin lines in the frames




On Fri, Nov 13, 2009 at 12:03 AM, Ryan Raasch <ryan.raasch@xxxxxxxxx> wrote:

>
>
> Shun-Yu Chang wrote:
>
>>
>>
>> On Thu, Nov 12, 2009 at 9:49 PM, Ryan Raasch <ryan.raasch@xxxxxxxxx<mailto:
>> ryan.raasch@xxxxxxxxx>> wrote:
>>
>>
>>
>>    Shun-Yu Chang wrote:
>>
>>        Hello, list:
>>           I am new to v4l2.  I am working on integrating a usb camera
>>        device on
>>        the beagleboard(Omap3530 dev board).
>>           Now I met a camera preview issue that is there are thin lines
>>        coming out
>>        in the frames.
>>           I still have no idea how to describe this exactly. It's like
>>        the images
>>        shows here,
>>           http://0xlab.org/~jeremy/camera_preview.html<http://0xlab.org/%7Ejeremy/camera_preview.html>
>>        <http://0xlab.org/%7Ejeremy/camera_preview.html>
>>
>>
>>
>>    I have two guesses. One is the jpeg compression ,or is it jpeg? Try
>>    saving in raw RGB or Ycbcr format and viewing with imagemagick.
>>
>>
>>    The raw data I got is yuyv422. I used the mmap way. I tried to convert
>> raw data to yuv420 and jpg files both.  I used ffmpeg to convert yuv420
>> files to jpg files and I can still see the lines.
>>    I don't know how to use imagemagick to see yuv files...
>>
>>
>>
>>    Does this happen in live preview? Maybe write data from camera
>>    directly to screen to see if happening there.
>>
>>
>>    It happens in live preview.  So I save the frames directly into files
>> to verify.
>>
>>
> But if you save the files, you don't know if the compression is the
> problem. You need to visually look on the screen with a magnifying glass or
> something...


       Got your point, I will try to output to the screen without any
compression later.


>
>
>
>>
>>    The second would be the FIFO (hadn't worked with omap before) levels
>>    of the data lines to the processor in the kernel.
>>
>>    Look at the system processor (top) usage to see how much cpu% is
>>    being used. USB has high overhead.
>>
>>      the top command shows
>>    PID CPU% S  #THR     VSS     RSS UID      Name
>>  1012  56% R     1  55000K  54468K root     capture_test
>>  241  40% R     1      0K      0K root     pdflush
>>    [....Omit, others are 0%. .....]
>>    After grabing the first 100 frames to files, capture_test exits.
>>
>>
> Looks pretty busy to me. Maybe you could kill the pdflush, don't save to
> files, and look at the display with a magnifying glass.
>
>
>     I don't quite understand about FIFO levels of the data lines part.
>>    Could give an instruction where I can start to look into?
>>
>>
> It probrably has dma priorities. So if other drivers in the system
> (network, usb, display, etc.) use a lot of cpu time, the camera dma might be
> delayed.
>
>
> Are you saving the files over network (nfs)?


    No, they are saved to files on the target, then transferred back to my
laptop.



>
>     Thanks for your reply..
>>
>>    Regards,
>>    -Jeremy
>>
>>
>>
>>
>>    Regards,
>>    Ryan
>>
>>
>>           I modified capture.c sample to save the frames to picture
>>        files.  So in
>>        my guess,  the problem is not in userspace. And this is not
>>        happen on my
>>        laptop with the usb camera.
>>           Could anybody give me a clue ?  Any one would be thankful.
>>
>>
>>
>>
>>
>>


-- 
Regards,
-Jeremy
--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list