[libcamera-devel] Video recording on PinePhone Re: libcamera on pinephone

[Laurent Pinchart]

On Wed, Jul 13, 2022 at 01:26:10AM +0200, Pavel Machek wrote:
> Hi!
> 
> > > > > > build/src/cam/cam  -c /base/i2c-csi/rear-camera at 4c -spixelformat=JPEG,width=1920,height=1080 -C2000 -F/tmp/delme2.jpg
> > > > > > 
> > > > > > somehow work, and result can be decoded using
> > > > > > 
> > > > > > time gst-launch-1.0 filesrc location=delme.unk ! jpegparse ! filesink
> > > > > > location=delme2.unk sync=false
> > > > > > 
> > > > > > or recoverjpeg, but I'm not getting 30fps. Any idea how to debug that?
> > > > > > Cam gives this output:
> > > > > 
> > > > > > 74020.783102 (30.01 fps) cam0-stream0 seq: 000001 bytesused: 2073600
> > > > > > 74020.883095 (10.00 fps) cam0-stream0 seq: 000004 bytesused: 2073600
> > > > > > 74020.949774 (15.00 fps) cam0-stream0 seq: 000006 bytesused: 2073600
> > > > > > 74021.016443 (15.00 fps) cam0-stream0 seq: 000008 bytesused: 2073600
> > > > > > 74021.049787 (29.99 fps) cam0-stream0 seq: 000009 bytesused: 2073600
> > > > > > 74021.116423 (15.01 fps) cam0-stream0 seq: 000011 bytesused: 2073600
> > > > > > 74021.183135 (14.99 fps) cam0-stream0 seq: 000013 bytesused: 2073600
> > > > > 
> > > > > I just noticed that if I don't enable file output, I'm geting nice
> > > > > 30fps. Hmm. I am outputting 60MB/sec, but with 3GB RAM, it should be
> > > > > possible to sustain that for a while...
> > > > > 
> > > > 
> > > > Are you on the 'very latest' libcamera? Laurent merged improvements to
> > > > the gstreamer buffering '8' days ago, which would have an effect in this
> > > > area.
> > > 
> > > I should update, but I see bad behaviour with src/cam/cam utility,
> > > too, so this should be it.
> > > 
> > > I'm now playing with file_sink.c. Is it possible that framedata memory
> > > is _extremely_ slow?
> > > 
> > > I did this instead of file write, and now I have 3fps instead of
> > > 15fps. Wow. I thought that 60MB/sec memory throughput should not be a
> > > problem for a modern system, but I may be wrong...
> ...
> 
> > This may be caused by the fact that the memory is mapped uncached. This
> > is an issue that needs to be addressed in the kernel first, there's
> > partial support in V4L2 to select how cache should be handled, but if I
> > recall correctly not everything is available yet. Once we'll have a
> > solution on the kernel side we'll implement it in libcamera (actually in
> > parallel, making sure the proposed API works in libcamera would be a
> > good test to make sure the design is correct, before merging the code in
> > the kernel).
> 
> Wow. Ok, uncached explains things. Is it easy to switch to do read()
> from /dev/videoX? That should be easy to do, not require ABI changes,
> and should improve performance in this case...

read() is deprecated and won't help much as there will still be a copy
reading from uncached memory. You can get the same result with a
memcpy() of the whole frame in the application.

-- 
Regards,

Laurent Pinchart