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

[Nicolas Dufresne]

Le mercredi 13 juillet 2022 à 01:38 +0300, Laurent Pinchart via libcamera-devel
a écrit :
> Hi Pavel,
> 
> On Wed, Jul 13, 2022 at 12:19:33AM +0200, Pavel Machek via libcamera-devel wrote:
> > On Tue 2022-07-12 22:56:01, Kieran Bingham wrote:
> > > Quoting Pavel Machek via libcamera-devel (2022-07-12 22:44:56)
> > > > 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...
> > 
> > 
> >                 {
> >                   unsigned int j, r = 0;
> >                   unsigned char *p = data.data();                                               
> >                   unsigned char *p = dummy;
> >                   for (j = 0; j < length; j++) {
> >                     r += p[j];
> >                   }
> >                   volatile int foo = r;
> > 
> >                   (void) foo;
> >                 }
> 
> 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).

Very good point. So to make this faster, you can do a threaded memcpy of the
memory before doing the writes (Android has a special memcpy for this purpose),
not idea of course.

The "manual cache" mode in V4L2 is only usable for mmap, it yields issues from
our testing for DMABuf (artifacts when buffers are re-queued). It is also need
to be opted in for each drivers, mainline only MTK have such a driver.

Nicolas