tree d39bec6d838d980b3b589325c45e5b636e6edb11
parent 7a420e4c928ce4f0720a82a74e05d23ef3c362fb
author Paul Fertser <fercerpav@gmail.com> 1624015003 +0000
committer Edward A. James <eajames@us.ibm.com> 1626785949 +0000

Implement optional per-frame CRC calculation to save bandwidth

Current implementation is very CPU-efficient as it's not processing
JPEG-encoded data received from V4L2 at all.

This patch implements an optional mode where for each frame that's about
to be sent a CRC32 is calculated and if this client has already received
it before, the transmission is skipped. This of course adds some
noticeable CPU load (proportional to the frame rate requested and the
encoded JPEG size); on AST2500 it's taking about 10 % CPU when showing a
relatively complex GUI login screen with 15 FPS.

Reducing required bandwidth to 0 for static images helps a lot when
using IP KVM via poor connections, e.g. provided by cellular network
operators or some hotels, so can be beneficial for certain common
usecases.

The next optimisation to try is to dynamically alter the frame rate,
automatically ramping it up as soon as the changes start happening and
lowering after a period of inactivity; it's not yet clear if V4L2 allows
this.

Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Change-Id: I74b887cf83b5c8676f5792412805de08e1a54f32