no 10.0.0 produce the same error on 23.6.x
i will stop updating ha core on buster and wait for bookworm. slowly it becomes too much work for me to keep ha core under buster up to date.
12 june is bookworm release and a few weeks later maybe the next raspbian.
with debian12 you get python11, ffmpeg5 and rustc 1.63 out of the box.
i want to spent my time on doing cool stuff with ha and not on keep it alive 2023.5.4 is fine
I totally agree - the problem is that I canāt really stop trying as long as I have things to checkā¦ so eventually I managed upgrading ha-av to 10.1.0. I did that by recompiling ffmpeg (followed Compiling FFmpeg on the Raspberry Pi - Pi My Life Up), with a little help from another thread here (Error Ha AV with 2023.04 - #11 by kexan82).
With the following modifications to the process:
fPIC should be enabled for libvpx (add --enable-pic to its configure command)
ffmpeg needs to be compiled as a shared lib (add --disable-static and --enable-shared to the configure command)
I compiled ffmpeg 4.4 (in the last git command clone release/4.4) it might work also with 5.0 or 6.0 but I didnāt try.
After this I can upgrade to ha-av 10.1.0. I can also share the ffmpeg deb file I used, if anyone is interested (but it includes the 32bit libs, I think you guys require the 64bit version).
Now Iām a happy camper running upgraded HomeAssistant core 2023.6.0ā¦
This worked for me to compile ffmpeg version 536cd25 running on RPi armv7l.
There was a problem with the libraries being found. At first, I thought I needed to set LD_LIBRARY_PATH, but that wasnāt the solution. I needed to make sure /usr/local/lib was in a file under /etc/ld.so.conf.d . Then, sudo ldconfig
and a reboot seemed to fix it.
Thanks for this, compiling ffmpeg on the rpi4 worked for me also. Ran into the same issue where ha couldnāt find the linked libraries and ldconfig was the solution as well.
ROTFL, me too. Iām actually trying to build ffmpeg from scratch but having some troubles wit zimg and AOM probably because Iām on a aarch64 OS version.
[ 31%] Building C object CMakeFiles/aom_av1_encoder.dir/third_party/vector/vector.c.o
[ 31%] Building C object CMakeFiles/aom_av1_encoder.dir/av1/encoder/dwt.c.o
[ 31%] Built target aom_av1_encoder
make: *** [Makefile:149: all] Error 2
pi@raspberrypi4:~/ffmpeg-libraries/aom/aom_build $
/home/pi/ffmpeg-libraries/aom/aom_dsp/arm/sum_neon.h:148:25: error: incompatible types when initializing type āuint16x8_tā using type āintā
148 | const uint16x8_t a1 = vpaddq_u16(sum[2], sum[3]);
@Maurizion you probably were fooled, like me, by the fact that we might have a 64bit kernel, but the userland is only 32bit, so all compiles should be done for the 32bit version.
Doing a recap for the newcomers, to fix building of ha-av in HA 2023.6.x on a Core installation on Raspbian OS, you should do only the following part from the aforementioned guide, compiling only ffmpeg with the basic set of libraries (@00lex please correct me if Iām wrong). You should choose the most appropriate Git branch for your scenario altering the --branch release/6.0 option from the git clone command:
I get an error on configure step ERROR: libfdk_aac not found
I removed line
āenable-libfdk-aac \
from configure command and all done successfully. I donāt know if it important.
Also ldconfig should be run with sudo.
After that pip3.11 install --upgrade ha-av
done successfully.
Thank you for brief instruction!
Logger: haffmpeg.core
Source: /srv/homeassistant/lib/python3.11/site-packages/haffmpeg/core.py:139
First occurred: 12:08:06 (1 occurrences)
Last logged: 12:08:06
FFmpeg fails [Errno 2] No such file or directory: '/usr/bin/ffmpeg'
I have tried doing this several times now, and I still canāt get it right. Only one thing is confusing me, and that may be why:
You should choose the most appropriate Git branch for your scenario altering the --branch release/6.0 option from the git clone command:
I have Bullseye fully updated with the latest Python 3.11 should the git clone command in the message work for me then? Thatās about all I can think about that I may have done wrong. When Hass finally starts, it uses a lot of CPU, like 30-40 %. Never seen that before. But if I disable Stream (that was probably the last media related thing that wasnāt already disabled), it seems to work much better.
Thank you, exactly what I needed. I use HassOS for home to keep things simple, but setting up a special Pi deployment for my toy hauler and havenāt setup a core installation in years.
So either ha-av making use of AV_FRAME_DATA_SEI_UNREGISTERED gets reverted, or it wonāt be possible to compile it on any Debian version below Bookworm (and many other distros), unless FFmpeg (the development headers) is compiled as well.
If you are just installing it with pip, which is also what HA core does on first service start, then this is only relevant on 32-bit ARM and RISC-V (and other rare architectures), as PyPI provides pre-compiled wheels for x86 and aarch64: https://pypi.org/project/ha-av/#files
For 32-bit ARM Debian and Raspbian (and some Ubuntu versions where library versions match), piwheels is an alternative. But well, it provides Python 3.7 and 3.9 wheels only, until they decide to add support for Bookworm, and as it builds against respective Debian repo libraries, recent builds fail for exactly the same reason: https://piwheels.org/project/ha-av/
I do understand that going with recent dependencies/features is great, sometimes make certain things much easier, and users using distros which natively ship too old software is not an issue of upstream developers. But it would make the life of many 32-bit ARM users much easier if:
There would be a way to revert or make the use of AV_FRAME_DATA_SEI_UNREGISTERED in ha-av optional