Web lists-archives.org

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