Unable to install package ha-av

Configuration
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.