CC: @filippoadessi

^{(This is a pre-written, saved reply.)}
If you want to test this PR please download the appropriate DEB package(s)
from the build artifacts of the associated PR's latest CI run.

After downloading the build artifact, make sure to unzip and un-tar it.

# finding out what architecture you need
# architecture is just below the TERMUX_VERSION
termux-info

# e.g.
# [...]
# TERMUX_MAIN_PACKAGE_FORMAT=debian
# TERMUX_VERSION=0.118.0
# TERMUX__USER_ID=0
# Packages CPU architecture:
# aarch64
# [...]

# =======================

# make sure `unzip` and `tar` are installed using
pkg install unzip tar

# unzip the artifact (if you have a different architecture this might be arm, i686 or x86_64 instead)
unzip debs-aarch64-*.zip

# untar the artifact
tar xf debs-aarch64-*.tar

# You should now have a debs/ directory in your current working directory
# Install the packages from the local source using
pkg install -- ./debs/*.deb

# to clean up, you can remove the debs/ directory, .tar file and .zip file
rm -rfi debs debs-aarch64-*.zip debs-aarch64-*.tar

It works! :)
Now I'm able to send live commands to ffmpeg process to modify filter params.

Thank you

Merging for inclusion in the mainline package then.

I dunno if it is a zmq related problem or other else. I receive, in a rapid sequence, this strange message from ffmpeg process:

12:04:20.282223/SRT:RcvQ:w2!W:SRT.qr: @794573044:
No room to store incoming packet seqno 2056192622,
insert offset 8191.
iFirstUnackSeqNo=2056192612
m_iStartSeqNo=2056184431
m_iStartPos=1292
m_iMaxPosOff=8191.
Space avail 10/8192 pkts.
(TSBPD ready in -43523ms, timespan 43624 ms).
GETTIME_MONOTONIC drift 4 ms

It seems like if there is no available space wherever but I have 4.5GB available in root filesystem.

I assume that's a ZMQ protocol error.
It seems like it's talking about space on the ZMQ packet stack, not space on the file system.

I unfortunately don't have experience with zmq so I can't really do anything more than guess.

I try to get other info from zmq guys! :) Thank you

There are some issues in srt repository with similar error message https://github.com/search?q=repo%3AHaivision%2Fsrt%20No%20room%20to%20store%20incoming%20packet%20seqno&type=issues

I try the following command and ffmpeg starts really slow (speed 0.0764x, fps 1.3) and close computing after few seconds with a broken pipe of x264 encoder.

ffmpeg -re -stream_loop -1 -i CAM1OFFLINE.mp4 -c:v h264 -f flv rtmp://localhost:1935/volleystream/lcam1

The video source is:
Video: h264 ([7][0][0][0] / 0x0007), yuv420p(tv, bt709, progressive), 1920x1080, q=2-31, 34 fps, 1k tbn (default)
and no audio is available (the source doesn't have an audio track).

What can cause this exagerated slowness?
The same command runs like a charm on my Mac M1.

It is slow because decoding and encoding are software only. Your Mac likely does hardware-accelerated encoding by default. It is possible on Termux too, but because of issue it was disabled.

libx264 is a software codec. The hardware codec supported by Android device is h264_mediacodec.