2007/3/25, Terry Reedy <[EMAIL PROTECTED]>:
> 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 <[EMAIL PROTECTED]>:
> 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: [EMAIL PROTECTED]
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
