ManimCommunity
Remove `pydub` from dependencies
pydub is no longer actively maintained, and is now running into issues with audioop being removed in python 3.13. As such, we should try to remove it from our dependencies and implement the needed features ourselves.
From a quick look through the code, the main features needed to implement are:
AudioSegment.silentAudioSegment.overlayAudioSegment.from_file
https://github.com/ManimCommunity/manim/blob/ce1fff645d2b457919933c3f92cb6106fbb9b6a1/manim/scene/scene_file_writer.py#L330-L334
https://github.com/ManimCommunity/manim/blob/ce1fff645d2b457919933c3f92cb6106fbb9b6a1/manim/scene/scene_file_writer.py#L327
https://github.com/ManimCommunity/manim/blob/ce1fff645d2b457919933c3f92cb6106fbb9b6a1/manim/scene/scene_file_writer.py#L370
I read some source code of pydub and find this:
try:
import audioop
except ImportError:
import pyaudioop as audioop
It seems like, inside of pydub there is substitution functions written in python at pyaudioop.py. If those work as intended in runtime, there may not be so much of hurry and it may still work in 3.13. (One missing function was marked, but it may be some cursed global reference that no 3rd party cannot figure out without dancing with debugger)
But still, I think this is can be a issue maker and other alternativies should be investigated.
Original audioop code is in this package: https://github.com/AbstractUmbra/audioop Pydub: https://github.com/jiaaro/pydub
Unfortunately, pydubs alternate python implementation is actually broken, as I found out in #3967 Relevant upstream issue https://github.com/jiaaro/pydub/issues/815
Yeah, it is totally broken. If you resolve the import issue, then the code is just filled with type errors and mentioned function really was not there. Never tested hasty conversion of C-code.
If dependency to external ffmpeg executable is dropped, this will be broken in that regard too. PyAv does not share it's ffmpeg through envPATH.
The cases where pydub would call ffmpeg via the executable should be taken care of by manual transcoding on our end. Did you find some situation where pyav actually tries to invoke ffmpeg on the current main branch?
The cases where pydub would call ffmpeg via the executable should be taken care of by manual transcoding on our end. Did you find some situation where pyav actually tries to invoke ffmpeg on the current main branch?
I was pondering solution space and then remembered transition to Pyav. So solution space did shrink to that singular interface structures. (Personally I don't know nothing about pyav interfaces.)
I was just refering subprocess calls to ffmpeg/libav inside of pydub-packet. As far I understand, those would fail when new user does not have external ffmpeg/libav executable and only PyAv-library? And every other solutions that does not use pyav interfaces.