Hi all ! I am trying to test the ffmpeg player with pygame on Ubuntu. $ python examples/movieplayer.py ~/clip_0.mov
I get "pygame.error: Could not find the beginning of MPEG data" ...since I am using Motion-JPEG saved exporting pygame surfaces as JPEG images, and using mencoder to encode JPEG files to a motion-JPEG movie in the Quicktime container. See http://code.google.com/p/toonloop/source/browse/trunk/py/toon/mencoder.py for movie conversion. How can I specify the codec to motion-JPEG ? Next, it would be nice to have a PyOpenGL demo. Should be pretty straightforward to write. My two cents : YUV seem faster for OpenGL texture uploads. Converting to RGB should be an option. Hence, maybe it is better to wrap the ffmpeg library rather than the SDL_ffmpeg. a 2009/5/7 Lenard Lindstrom <le...@telus.net>: > Sorry, I don't know how to synch up sound and image. Pyame uses SDL_mixer, > which is a wrapper for sound support in SDL. I suppose smpeg takes care of > sound internally. And one has to be careful using SDL directly if SDL_mixer > is used. But I am unsure of the details. It may just be a matter of not > directly initializing sound support in SDL if using SDL_mixer. > > Lenard > > Tyler Laing wrote: >> >> Lenard, >> >> Thanks for the advice and info. :) It looks like by default the pygame >> surfaces don't support YUV, but overlays do. The simple case will use the >> overlay module, via c, to play the movie. This is more than suitable for 90% >> of usecases, and will be transparent to most people. It also benefits from >> hardware acceleration. >> >> For the other 10% of stuff that people want to do, it looks like a bit of >> a tougher technical challenge. I like Rene's idea of separate and >> manipulatable streams, which allows for some neat stuff to be done. If I use >> the ffmpeg api directly, then I am able to do this. Via ffmovie or ffplay, >> it is not possible. Do you have any information for how to do sound, any >> reccomendations on where to look? I'm already beginning to look at mixer.c >> for how it is done, via SDL. >> >> -Tyler >> >> On Thu, May 7, 2009 at 10:20 AM, Lenard Lindstrom <le...@telus.net >> <mailto:le...@telus.net>> wrote: >> >> I have built the movie module for both Windows and Linux. It is >> included in the Windows distribution. movieext.c was a first >> attempt at using SDL_ffmpeg. I don't know about sdl surfaces and >> YUV, but the overlay.py example program does try to play a movie >> using YUV. Unfortunately it rejects the only pgm file in the >> examples/data directory so I have not gotten it to work. I only >> know about overlay because I have recently updated the module to >> Python 3. So I don't know if it will be of any help. >> >> Lenard >> >> Tyler Laing wrote: >> >> Hi Lenard, >> >> I'm looking at the movie module now. Are we compiling movie.c >> or movieext.c? I didn't think of the overlay module, I'll look >> at that as well, thanks. :) So thats a no, on sdl surfaces >> being able to playback YUV? >> >> And yes, it looks like smpeg does a direct copy to display. >> >> On Thu, May 7, 2009 at 9:36 AM, Lenard Lindstrom >> <le...@telus.net <mailto:le...@telus.net> >> <mailto:le...@telus.net <mailto:le...@telus.net>>> wrote: >> >> Hi Tyler, >> >> My opinion is the few dependencies the better. If >> SDL_ffmpeg can >> be left out that would be good. As for YUV playback have >> you had a >> look at the overlay module? It may be what is needed. Also, did >> you look at the existing movie module? Maybe smpeg does direct >> copy to display so it may not be a useful source of ideas >> in this >> case. >> >> Lenard >> >> >> >> Tyler Laing wrote: >> >> Hello all, >> >> I've been looking at SDL_ffmpeg and ffmpeg. >> >> There are some considerations for choosing each. >> SDL_ffmpeg is >> fairly simple to interact with, load, play, pause a >> movie. You >> can interact with each frame, and so on. However, >> SDL_ffmpeg >> converts every frame from YUV to RGB, to make it easier >> on the >> programmers to use image manipulation functions and so on. >> This is a performance hit, for sure. Considering Python's >> reputation already for being slow, having a movie >> module take >> that kind of hit will result in a further stain to the >> reputation, when sometimes, rarely, movies stutter or pause >> when they shouldn't. It can take a long time to recover >> from a >> negative reputation. >> >> For ffmpeg, it offers much the same capability, but without >> the SDL conveniences. It does offer far more capability >> with >> movie files than SDL_ffmpeg does though. I think, but >> I'm not >> sure, that the pygame surfaces do not need to have the >> frames >> of the movie be in YUV format? Or its a quick operation to >> convert the surface for YUV then back to RGB. Something >> like >> that, correct me if I'm wrong. So we don't need every >> frame to >> be converted to RGB, except when we do need it. >> >> If I went with ffmpeg, I was considering a design where we >> explicitly convert the movie from YUV to RGB, with a simple >> convert function. From the point its called, to the >> point it >> is called again, the movie is in RGB format. It fits >> with the >> python philosophy that "Explicit is better than implicit." >> (-The Zen of Python, by Tim Peters) >> >> Personally, I would prefer to work with ffmpeg, because >> of the >> greater functionality, and the lack of conversion >> performance hit. >> >> -Tyler >> >> -- Visit my blog at http://oddco.ca/zeroth/zblog >> >> >> >> >> >> -- Visit my blog at http://oddco.ca/zeroth/zblog >> >> >> >> >> >> -- >> Visit my blog at http://oddco.ca/zeroth/zblog > > -- Alexandre Quessy http://alexandre.quessy.net/
