Sorry for the late reply, we're having a typhoon here and I'm unable to access the device.
- I'm using sources from apt server. I might look into building the libcamera myself but it seems like some work is needed.
- The screenshot of the task manager is not on the host side, it is on the client side, where I use a x86 PC to recieve the stream. It is there to show that, With such low FPS, the network can be seen as no delay.
Thanks for your suggestions.
I later changed to the gstreamer pipeline on host(RPI):There are no latency issue with this method (albeit seemingly slightly higher CPU usage). I can set the FPS as low as I want and the latency seems to be pretty constant at ~200ms. There are other problem as described in this post, but generally it works at this moment.
Since this uses x264enc directly as you suggested, my conclusion is that this is the problem of rpicam-vid program.
I'll be happy to do any kind of test if you can give me some pointers to what should I do. Thanks for the reply!
My goal is not actually to use this 1 FPS settings, I'm target to find the best balance between RPI CPU usage, network throughput, and time latency. I have multiple RPIs, each RPi will need to handle 2 cameras.My first impression is that this is a quite theoretical use-case; h264 1640x1232 30Mbps 1FPS
I use v1 cameras with Pi0,3, almost full-HD, 2Mbps 25FPS. 8 frames is about 320ms, I think latency is about 200ms, others have done better measurements, was same or lower.
I don't know details about codec related latency, but I think a few or 8 frames somehow might build-in or needed for a codec to do its work. Otherwise use a 'non-interframe related' codec, MJPEG or just raw frames more or less.
- There is newer kernel+libcamera, do updates or build from source
- why does it show 16CPUs (and not 4)?
- I'm using sources from apt server. I might look into building the libcamera myself but it seems like some work is needed.
- The screenshot of the task manager is not on the host side, it is on the client side, where I use a x86 PC to recieve the stream. It is there to show that, With such low FPS, the network can be seen as no delay.
Thanks for your suggestions.
I'm not sure what is the DPB size. I'll look into it. I used both ffplay and gstreamer for the decoding. Both shows the same behavior.8 frames sounds suspiciously like the DPB size. I haven't tested, but are you sure this is on the Pi side and not receive? Many players will wait for the DPB to be full before attempting to decode anything.
Pi5 is using libavcodec and x264 under the hood. Those have a myriad of options, many of which I think you can access directly. Low latency encode is an option when using FFmpeg, so may be desirable here.
I later changed to the gstreamer pipeline on host(RPI):
Code:
gst-launch-1.0 -v libcamerasrc camera-name="/base/axi/pcie@120000/rp1/i2c@80000/imx219@10" ! video/x-raw,colorimetry=bt709,format=NV12,width=1664,height=1232,framerate=30/1 ! queue ! x264enc tune=zerolatency speed-preset=fast ! video/x-h264,profile=high,stream-format=avc ! rtph264pay pt=96 ! udpsink host=$IP port=8554Since this uses x264enc directly as you suggested, my conclusion is that this is the problem of rpicam-vid program.
I'll be happy to do any kind of test if you can give me some pointers to what should I do. Thanks for the reply!
Statistics: Posted by EwingKang — Fri Oct 04, 2024 1:18 am