PI Zero W H.264/Raspivid performance issue

[VigibotDev]

Sorry for my english, hello from France;)

There is a video performance issue with the last Kernel on PI ZERO W - rpi-updated TODAY- it kill the low latency H.264 with any RaspiCam (official or wide angle), and I get very poor performance with my websocket Raspivid streaming ( live cloud @ https://www.serveurperso.com/?page=robots )

Here is my project Raspivid (symlinked) cmdline :

Serveur | 15:17:57:925 | 192.168.0.1 | Zerobot | Client | /var/www/processdiffusion -t 0 -w 640 -h 480 -fps 25 -rot 180 -ih -b 1400000 -pf baseline -o - | /bin/nc 127.0.0.1 8003 -w 2

This older kernel solve the issue, and I get the very low latency as Raspberry PI 3B+ :

https://github.com/Hexxeh/rpi-firmware/commit/d985893ae67195d0cce632efe4437e5fcde4b64b

I can do more test if you need. I work hard on robotics and for sure it need more testing (all kernel must be tested).

Thanks, Pascal

[VigibotDev]

It's a kernel related issue, the same working kernel from the #182 work perfectly to workaround this issue.

But there is any other possibility (network/wifi performance or other component of software chain in relation) ask me / gide me for more testing if needed.

[6by9]

It could be either the Linux kernel or the GPU (VideoCore) firmware. Please be very careful when throwing terms around as they are very different.

A simple patch to raspivid to display the time taken from capturing the frame to delivering the buffer to the application

diff --git a/host_applications/linux/apps/raspicam/RaspiVid.c b/host_applications/linux/apps/raspicam/RaspiVid.c
index 0352cbd..6077b31 100755
--- a/host_applications/linux/apps/raspicam/RaspiVid.c
+++ b/host_applications/linux/apps/raspicam/RaspiVid.c
@@ -1446,6 +1446,13 @@ static void encoder_buffer_callback(MMAL_PORT_T *port, MMAL_BUFFER_HEADER_T *buf
          }
          if (buffer->length)
          {
+            if (buffer->pts != MMAL_TIME_UNKNOWN)
+            {
+               uint64_t current_stc;
+               mmal_port_parameter_get_uint64(port, MMAL_PARAMETER_SYSTEM_TIME, &current_stc);
+               fprintf(stderr, "Latency %llu (%llu, %llu) len %u\n", current_stc-buffer->pts, current_stc, buffer->pts, buffer->length);
+            }
+
             mmal_buffer_header_mem_lock(buffer);
             if(buffer->flags & MMAL_BUFFER_HEADER_FLAG_CODECSIDEINFO)
             {

I've just run that and got ~30000usec, or 30ms which is about what I'd expect. As you are using the -ih flag to insert inline headers, you will get an odd buffer with every I-frame that has a 0 timestamp and therefore an odd latency.

Ensure your application isn't doing anything odd by ensuring that you get the same result with -o /dev/null - Linux pipes have an overhead.

You can update the GPU firmware independently of the Linux kernel by using sudo SKIP_KERNEL=1 rpi-update <hash> to only update. That should make it trivial to identify whether it is the kernel or firmware.

[VigibotDev]

Thanks, I do the "SKIP_KERNEL=1 rpi-update" next time to check the VideoCore and post the result here. There is no problem with my app now it work on many robot platform PC, PI, Odroid XU4Q ffmpeg software h264 with 0.2/0.3s latency to browser

[Ruffio]

@Serveurperso can this be closed?

[VigibotDev]

Hello, no problem since a long time:) This is closed. We run 24/7 many robots with camera on the last Buster image fully updated to last stable kernel (no rpi-update) and Raspberry PI 2/3A/3B/4. (https://www.vigibot.com) I can make specific rpi-update version testing if you want.

[Ruffio]

@Serveurperso can you close it?