Re: question for soc-camera driver
- Date: Wed, 9 Apr 2008 09:27:25 +0800
- From: "冯鑫" <fengxin215@xxxxxxxxx>
- Subject: Re: question for soc-camera driver
2008/4/9 Guennadi Liakhovetski <g.liakhovetski@xxxxxx>:
> 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
>
Thank you very much.I will wait for your patch and test it.
Thanks
fengxin
--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list