[Python-Dev] SoC proposal: multimedia library (original) (raw)

Lino Mastrodomenico l.mastrodomenico at gmail.com
Sun Mar 25 12:22:27 CEST 2007

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

More information about the Python-Dev mailing list