Unable to install package ha-av

Configuration
32

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!

33

Another error I got in HA journal

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'

Solved by
sudo cp ~/FFmpeg/ffmpeg /usr/bin/

34

Right, fdk was an optional lib, I’ll edit the post.

35

Thanks , compiling 32bit has solved the problem!

1 Like
36

Thank you, this solved the issue. I was able to upgrade ha-av succesfully now and can install and run HA Core 2023.6.1.

1 Like
37

I have tried doing this several times now, and I still can’t get it right. :frowning: 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.

38

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.

39

Reason is simple:

  • AV_FRAME_DATA_SEI_UNREGISTERED has been added with FFmpeg 4.4: avutil: add AV_FRAME_DATA_SEI_UNREGISTERED side data type · FFmpeg/FFmpeg@bc8ab08 · GitHub
  • Debian Bullseye provides FFmpeg 4.3: https://packages.debian.org/bullseye/ffmpeg
  • 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:

Sorry for the code-formatted links, as new users are restricted to 2 links per post.

2 Likes
40

Thanks man. Save my life

1 Like
41

Hello. If these instructions are not working for someone, use 5.1 branch instead of 6.0. ffmpeg has no support for python 3.11 yet or whatever.

1 Like
42

This is actually the question of few lines patch to define two missing enums for the distros without recent ffmpeg libraries:

--- include/libavcodec/avcodec.pxd.orig    2023-08-26 16:56:22.637714080 +0200
+++ include/libavcodec/avcodec.pxd 2023-08-26 17:29:08.000000000 +0200
@@ -11,6 +11,15 @@

 cdef extern from "libavcodec/avcodec.h" nogil:
+    """
+    // AV_FRAME_DATA_SEI_UNREGISTERED available since version 56.54.100 of libavutil (FFmpeg >= 4.4)
+    #define HAS_AV_FRAME_DATA_SEI_UNREGISTERED  (LIBAVUTIL_VERSION_INT >= 3683940)
+
+    #if !HAS_AV_FRAME_DATA_SEI_UNREGISTERED
+        #define AV_FRAME_DATA_SEI_UNREGISTERED -1
+        #define AV_CODEC_CAP_OTHER_THREADS AV_CODEC_CAP_AUTO_THREADS
+    #endif
+    """

     # custom
     cdef set pyav_get_available_codecs()
1 Like
43

If one anyway needs to recompile it, why not just compile FFmpeg 5?

44

  • Those sources compiled during ha-av module installation anyway.

  • it is NOT “just compile FFmpeg 5”. This will require system libraries replacement with the compiled ones, which could broke some other applications. Also “just compile FFmpeg 5” will require a lot of other dependencies to be installed or upgraded (recompiled).

45

Ah you mean to patch this in actual ha-av code? I thought it is a comment as explanation, but probably I do not understand how these .pxd files work. Part of it is already there, actually the important part?

Would you mind to open a PR if your extension really restores FFmpeg <4.4 support?

Exactly. And FFmpeg (its libraries) has a whole lot of dependencies, so I would recommend to upgrade the distribution instead (if the patch does not work).

46

Part of it is already there, actually the important part?

It is still in the PyAV sources, but not in the ha-av anymore, please check include/libavcodec/avcodec.pxd 10.1.0 changes

This patch works. I have installed 2023.8.4 with python 3.11.5 on rpi3 with Debian bullseye. I didn’t have chance yet to check it with real camera, but I don’t see any reason why it shouldn’t work.

1 Like
47

EDIT: Got confused myself with the commits, ignore the content of my comment from before this edit.

So v10.1.1 is newer than main? And is it necessary to not declare a missing variable for FFmpeg v6 support? Looks like FFmpeg v4.3 support was removed more as part of some cleanup, which does not add any other value.

@uvjustin pinging you here as this repo/fork has no issues section. I hope you are open to re-add FFmpeg v4.3 support with this little non-intrusive non-breaking patch.

48

I got an alert when you tagged me and was alarmed by the tone of your message. I checked and I believe your initial takeaway was incorrect. Thank you for taking another look and editing your initial message to remove the invalid accusations.

Yes, you are correct in that main branch on my forked repository is not really up to date. The only relevant branches there are the tagged releases.

For context, the original reason I forked the PyAV repo is that there was some missing functionality in the PyAV repo (see Use PyAV fork and set hvc1 codec tag for H.265 by uvjustin · Pull Request #58309 · home-assistant/core · GitHub) that we wanted to use in HA. After that change was merged upstream, we reverted to use the original PyAV repo. Later, when we wanted to update HA to Alpine 3.16, we realized that the latest version of PyAV did not yet support FFmpeg 5 and would prevent us from upgrading, so I made the relevant changes on my fork and we went back to that instead.

The takeaway is that ha-av is not generally meant to be a standalone project, but rather a small diff from the head of the PyAV repo which allows us to 1) make compatibility updates to keep up to date with the latest FFmpeg versions in the distros included with HA Container/HAOS as well as use newer versions of build tools like Cython, and 2) add one or two features which are either not relevant for or have not yet been merged upstream (side note - the main PyAV repo has been slow moving over the past several years as only one person with commit privileges has been active during that time, and even he has been busy).

Given the above, I am not inclined to open up issues on my fork as inevitably it will be filled with requests like “unable to compile” or “incompatibility with FFmpeg 4.3” which are more user help requests/feature requests than actual issues with the code. Most issues can be reported against the main PyAV repo itself. I acknowledge there may be issues that come from the (small) diff from the original repo; however, these are less likely as the content/features of these differential commits are actually used/tested from our side. Also, any such issues can still be reported against the HA core stream component if/when they show up.

As for why support for FFmpeg 4.3 was removed, it’s because it’s generally difficult to maintain compatibility across so many versions of FFmpeg when the API/ABI is changing. Some fields have been renamed, while others have been removed - that’s why there’s a deprecation period when code changes, with shims put in to smooth the transition between versions. Guess what, the stuff that was deprecated in FFmpeg 4.3 was finally removed in FFmpeg 6.0, so in order to get both versions to work with our library we’d essentially have to add some shims to our library. This is too much work to keep around and introduces more potential for bugs and inconsistent behavior across versions.

Ideally, HA users should use either HAOS or HA Container. Everyone else is considered an advanced user, and honestly it’s just too much work to spend time troubleshooting issues that only come up on a particular system. However, given that there are several other people on this thread, I do want to see what the issue is and if we can find another workaround for people. Is everyone on a similar type of device (e.g. RPi 2)?

1 Like
49

I’m very sorry about my initial accusations, I must check more carefully before throwing around with such. Thanks for explaining the reason/history behind the fork, which makes sense then, including the commit history, and thanks for being open to again look into FFmpeg 4.3 support.

So while re-adding this variable declaration should not break something, the question is whether other changes required for FFmpeg 6 support break v4.3 support elsewhere, probably in a way which is not obvious in the first place, also because HA does not necessarily make much use of ha-av, unless some A/V apps/integrations are added. However, as long as it is really just that one code block, an (older) PR on the upstream project leaves it inside, so in case this gets merged, it would reduce the diff for now: Update to ffmpeg 6.0 by wader · Pull Request #1110 · PyAV-Org/PyAV · GitHub
But according to comments, this PR breaks even FFmpeg 5 support, so overall would make things worse for users with native HA core installs on old distros, not better. Leaving the backwards compatibility code inside there hence does not seem to make sense :grinning_face_with_smiling_eyes:.

50

This is what helped in my case for ffmpeg 4.3.6-0

as the user home-assistant is runnung:

pyenv-activate.sh
pip download ha-av
vi ha-av-10.1.1/include/libavcodec/avcodec.pxd
=> add lines from DuFu
pip install ./ha-av-10.1.1

I think I don’t use any video functions in Home-Assistant, so I cannot say if everything is working, however homeassistant is starting again.

1 Like
51

Btw, in the meantime, piwheels supports Python 3.11: piwheels - ha-av

While HA supports (and appliances ship with) Python 3.12, AFAIK Python 3.11 still works, and then you can install pre-compiled ha-av wheels from there. Here is how to setup: https://piwheels.org/

However, I did not test it and are not entirely sure, since these wheels were compiled against Debian Bookworm shared libraries (FFmpeg 5.1). So it is possible that those are incompatible with the ones available on Bullseye (FFmpeg 4.3), respectively that the required ones are simply missing there. But could be tested.