[Python-Dev] SoC proposal: multimedia library

[Lino Mastrodomenico]

2007/3/25, Terry Reedy <tjreedy at udel.edu>:
> There is a Python wrapping of the cross-platform Simple Directmedia Library
> (C) that is a major part of PyGame.  Are you familiar with both and how
> does your proposal improve on the current situation.

Yes I know both Pygame and SMPEG (the SDL MPEG library used by Pygame).

The differences with my proposal are:
    * SMPEG is not a general purpose library: it only supports MPEG-1
video in a MPEG system stream container (and the corresponding audio);
    * it only supports decoding, not encoding;
    * the Pygame wrapper is strictly tied to Pygame itself and direct
playback; e.g.: AFAIK there is no way to access the uncompressed audio
track of a MPEG file, you can only "play" a movie;
    * it's CPython specific: my plan is to use only Python and ctypes,
to make it easily portable to PyPy.

The nearest existing library to what I propose that I was able to find
is PyMedia (http://www.pymedia.org/ ).
But it still isn't what I want: their interface is too low level and
not exactly pythonic and their implementation is written in C and C++
(a very old fork of the ffmpeg library).

2007/3/25, Josiah Carlson <jcarlson at uci.edu>:
> For decoding, not many packages can currently match VLC. It has wrappers
> for most major GUI toolkits, and seems to be easily accessable via
> ctypes.  There are also bindings for various media players in wxPython,
> though they are strictly play only - no screenshots, etc.

Yes, but I don't want to implement yet another media player, my
proposal is for a library that supports both encoding and decoding and
doesn't force the use of a specific output layer. E.g. you should be
able to get the uncompressed data of a video frame and pass it to
Tkinter.Image, or PIL (the Python Imaging Library), or do fancy things
to it with numpy...

> For encoding, MediaCoder exists, but seems to be Windows only.

Well, technically it works under Linux too, with Wine. ;-)
But, yes, I want something a bit more cross-platform than that.

> I would
> personally suggest limiting support and going for ffmpeg (via ctypes
> would be quickest, though a SWIG wrapping could make it more convenient).

Yes, I thought about simply writing a wrapper around ffmpeg, but I
think it would be preferable to write at least the (de)muxing part of
the library in Python since this should guarantee that at least a
subset of the functionality (e.g. an AVI file with MJPEG video and
u-law sound) is always available without any dependecy outside of the
standard library and of libraries that are pretty much always
available on Linux/MacOSX/Windows.

Of course the CPU intensive work of encoding and decoding audio and
video will be done by existing C libraries. As I said before I have a
slight preference for using ctypes instead of the CPython APIs because
this means that the library will (probably) be usable unmodified by
PyPy, but I can change my mind if the community prefers something
else.

-- 
Lino Mastrodomenico
E-mail: l.mastrodomenico at gmail.com