> Another significant difference I just found is that SDL_ffmpeg has no
> support for subtitle streams. Supporting subtitle streams is smart, it
> allows for it to be easier to internationalize games by having the game
> select the subtitle stream it wants to play. Plus, I like my cutscenes to
> have subtitles in english, as I'm hard of hearing. :)
>
> -Tyler
>
> On Thu, May 7, 2009 at 4:59 PM, Tyler Laing <
trinioler@xxxxxxxxx> wrote:
>>
>> Hi Rene,
>>
>> Perhaps. But SDL_ffmpeg is a separate project, another dependency. FFmpeg
>> is much more likely to be on someone's system. SDL_ffmpeg also uses a
>> completely different build system, complicating the process of using it
>> within pygame. I'm having trouble getting it built against ffmpeg 0.5.0 and
>> I can't find any info or instructions on building it. If I'm having trouble,
>> it'll also be difficult for others. Its just not ready for wide-scale usage,
>> in my personal view.
>>
>> Like I said, I am definitely leaning towards just using ffmpeg directly.
>> It also means I have greater control over whats going on, and don't have to
>> try to fiddle and be stopped by the limitations of sdl_ffmpeg.
>>
>> -Tyler
>>
>> On Thu, May 7, 2009 at 4:33 PM, René Dudfield <
renesd@xxxxxxxxx> wrote:
>>>
>>> Hi,
>>>
>>> I think you will end up re implementing many of the things from
>>> SDL_ffpmeg anyway.
>>>
>>> Overlay is pretty good - and is designed for movie playback. However it
>>> has limitations.
>>> The C docs are here:
http://sdl.beuc.net/sdl.wiki/SDL_Overlay
>>>
>>> It's probably a good idea to get basic playback working first, and then
>>> worry about other features.
>>>
>>> SDL_ffmpeg has most of what is needed to remake the current Movie module
>>> using ffmpeg.
>>>
>>>
>>> cu,
>>>
>>>
>>> On Fri, May 8, 2009 at 2:27 AM, Tyler Laing <
trinioler@xxxxxxxxx> 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
>