New pyffmpeg and NumPy dependency
Lorenzo Mancini
I have just received a "heads-up" message from Bertrand Nouvel about
the incoming new version of pyffmpeg.
First of all I would like to thank him on this list for such an
effort. I am a long time user of pyffmpeg and I'm enthusiast to see
that the project is indeed very alive and a much needed refactoring is
around the corner.
Yet, after a first skimming of the source code I have a perplexity,
namely the choice of building the new pyffmpeg on NumPy. I'm sure
this was a much thought upon decision, but I didn't see any rationale
for it and I would like to start a discussion about the possible
aftermaths.
My doubts spark from both the heaviness of NumPy as a dependency and
the relatively superficial use of it in pyffmpeg (as far as I have
understood after my first look at the source, it's primarily used as a
collection of containers). I feel like all what it's used for could
be equally accomplished with a much lighter layer of software. Maybe
the brand new audio support played a role in choosing NumPy?
Thanks,
--
Lorenzo Mancini
Bertrand Nouvel
The choice of numpy has arise, on one side because of audio, and on the other side because it seems, IMHO, to be now the standard for representing numerical arrays in Pyhon.
I made this choice before to decide to make my version of pyffmpeg public and before I performed the complete rewrite of the code.
My use of PyFFMPEG is mainly related image analysis /
signal analysis and so on, so for me numpy was really natural and quite light compared to all the other layer that may come afterwards, so I
never imagined that someone will believe it has heavy, especially with respect to PIL, but it is true that numpy encapsulates LaPACK ATLAS and FFTW ... Which of course not always necessary for everyone.
Of course, since I did this choice before I was thinking to share this, I
did not discuss about this issue, and you are right, it is meaningful to discuss about it.
In the current code I am not that much dependant on numpy,
however I've made some structure for buffering incoming audio packets,
and slicing them regularly according to hardware device capabilities
and this structure is for the moment written using numpy.
If we do not take in account this evolution, we may think about allowing
the package to detect he meaningful packages installed for our operation and let the user choose the encapsulation of the data it prefers.
We may then consider at least 3 modes :
Video : Numpy | PIL | Ctypes
Audio : Numpy | Ctypes| Ctypes
I will have a look to see how much it would be complicated to
this feature.
Thanks for your comment,
Bertrand