* Camera preview, thin lines in the frames
@ 2009-11-12 11:39 Shun-Yu Chang
2009-11-12 13:49 ` Ryan Raasch
0 siblings, 1 reply; 5+ messages in thread
From: Shun-Yu Chang @ 2009-11-12 11:39 UTC (permalink / raw)
To: V4L-Linux
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
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@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Camera preview, thin lines in the frames
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
0 siblings, 1 reply; 5+ messages in thread
From: Ryan Raasch @ 2009-11-12 13:49 UTC (permalink / raw)
To: Shun-Yu Chang; +Cc: V4L-Linux
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
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.
Does this happen in live preview? Maybe write data from camera directly
to screen to see if happening there.
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.
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Camera preview, thin lines in the frames
2009-11-12 13:49 ` Ryan Raasch
@ 2009-11-12 15:54 ` Shun-Yu Chang
2009-11-12 16:03 ` Ryan Raasch
0 siblings, 1 reply; 5+ messages in thread
From: Shun-Yu Chang @ 2009-11-12 15:54 UTC (permalink / raw)
To: Ryan Raasch; +Cc: V4L-Linux
On Thu, Nov 12, 2009 at 9:49 PM, Ryan Raasch <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.
> 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.
I don't quite understand about FIFO levels of the data lines part.
Could give an instruction where I can start to look into?
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Camera preview, thin lines in the frames
2009-11-12 15:54 ` Shun-Yu Chang
@ 2009-11-12 16:03 ` Ryan Raasch
2009-11-12 16:35 ` Shun-Yu Chang
0 siblings, 1 reply; 5+ messages in thread
From: Ryan Raasch @ 2009-11-12 16:03 UTC (permalink / raw)
To: Shun-Yu Chang; +Cc: V4L-Linux
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Camera preview, thin lines in the frames
2009-11-12 16:03 ` Ryan Raasch
@ 2009-11-12 16:35 ` Shun-Yu Chang
0 siblings, 0 replies; 5+ messages in thread
From: Shun-Yu Chang @ 2009-11-12 16:35 UTC (permalink / raw)
To: Ryan Raasch; +Cc: V4L-Linux
On Fri, Nov 13, 2009 at 12:03 AM, Ryan Raasch <ryan.raasch@gmail.com> wrote:
>
>
> 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>
>> <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@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2009-11-12 16:35 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
2009-11-12 16:35 ` Shun-Yu Chang
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox