Re: question for soc-camera driver

[Guennadi Liakhovetski <g.liakhovetski@xxxxxx>]

On Tue, 8 Apr 2008, 冯鑫 wrote:

> 2008/4/7 Guennadi Liakhovetski <g.liakhovetski@xxxxxx>:
> >  Ok, then I'll have to request the source code of your application to test
> >  it here.
> 
> Thanks.My application come from
> http://linuxtv.org/hg/v4l-dvb/file/1abbd650fe07/v4l2-apps/test/capture_example.c.I
> modify a little.

Ok, that helped to understand and reproduce your problem, thanks! One 
reason is buffer overruns. The sample application you are using is not 
very smart, it is using only one thread, and with your modifications it 
writes a new file to the filesystem after retrieving each frame, which, of 
course, is not very easy for the PXA to handle. The data corruption I see 
here is, that the first few frames are practically unusable. For example, 
the first frame consists only of gray stripes, but soetimes it is correct 
too. Then there may be a couple of frames are of just one gray intensity, 
e.g., black, and then follow frames with wrongly positioned start of 
frame. So that the frame typically consists of four sectors.

MPlayer, for example, avoids overruns by using a separate thread for just 
data acquisition, haven't checked, maybe it is even scheduled with a 
real-time priority.

I added some FIFO overrun handling to the driver, now I seem to be able to 
re-synchronise, so that after the first corrupt frames the rest now are 
properly aligned.

Further, I had a frame sequence problem: I was getting frames like 1, 3, 
2, 5, 4, 7, 6, etc. No idea where this comes from. But limiting the number 
of buffers to 2 (like in mplayer) in the test app, "solved" this problem 
too. I'll clean up my resync patch tomorrow and will ask you to test it.

Thanks
Guennadi
---
Guennadi Liakhovetski

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