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

[Laurent Pinchart]

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).

-- 
Regards,

Laurent Pinchart