Re: Camera preview, thin lines in the frames

Shun-Yu Chang wrote:
> 
> 
> On Thu, Nov 12, 2009 at 9:49 PM, Ryan Raasch <[email protected] 
> <mailto:[email protected]>> 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>
> 
> 
>     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...

> 
> 
>     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)?

>     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.
> 
> 
> 
> 
> 

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list