public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Ryan Raasch <ryan.raasch@gmail.com>
To: Shun-Yu Chang <shunyu.chang@gmail.com>
Cc: V4L-Linux <video4linux-list@redhat.com>
Subject: Re: Camera preview, thin lines in the frames
Date: Thu, 12 Nov 2009 17:03:42 +0100	[thread overview]
Message-ID: <4AFC31DE.6060708@gmail.com> (raw)
In-Reply-To: <e858e0620911120754q597b95aah7cb3a0e997a71f02@mail.gmail.com>



Shun-Yu Chang wrote:
> 
> 
> On Thu, Nov 12, 2009 at 9:49 PM, Ryan Raasch <ryan.raasch@gmail.com 
> <mailto:ryan.raasch@gmail.com>> 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:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

  reply	other threads:[~2009-11-12 16:03 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-12 11:39 Camera preview, thin lines in the frames Shun-Yu Chang
2009-11-12 13:49 ` Ryan Raasch
2009-11-12 15:54   ` Shun-Yu Chang
2009-11-12 16:03     ` Ryan Raasch [this message]
2009-11-12 16:35       ` Shun-Yu Chang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4AFC31DE.6060708@gmail.com \
    --to=ryan.raasch@gmail.com \
    --cc=shunyu.chang@gmail.com \
    --cc=video4linux-list@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox