while thinking about which engines might be nice to add next, i found that the games from this area and timeframe tend to use a variety of formats for video.
AFAIK the workflow of scummvm was to implement new video codecs when needed, but i think the more recent codecs are much more complex than those in scummvm, like e.g. bink. implementing these would be possible, but i think it would be best if residual instead would chose to rely on ffmpeg for such matters.
ffmpeg is lgpl/gpl, and next to decoding a huge array of video codecs, it also supports a lot of audio codecs.
suggestion: using ffmpeg for future-proof video support
Moderator: ScummVM Team
-
MusicallyInspired
- Posts: 1136
- Joined: Fri Mar 02, 2007 8:03 am
- Location: Manitoba, Canada
- Contact:
-
ezekiel000
- Posts: 443
- Joined: Mon Aug 25, 2008 5:17 pm
- Location: Surrey, England
Re: suggestion: using ffmpeg for future-proof video support
It would probably be an overkill. Why adding support for lots of codecs if just a few are going to be used? That would increase the binary size, reducing the possibility for ResidualVM to be ported to resource-limited platforms.loki1985 wrote:ffmpeg is lgpl/gpl, and next to decoding a huge array of video codecs, it also supports a lot of audio codecs.
In some cases, the ScummVM approach has been copying the portions of ffmpeg required to decode a given format into ScummVM itself (it can be done because both projects are licensed under the GPL). That way it just contains the required bits and ScummVM devs can make their own changes to the code.
-
MusicallyInspired
- Posts: 1136
- Joined: Fri Mar 02, 2007 8:03 am
- Location: Manitoba, Canada
- Contact:
Oh. I thought he was talking about converting game videos with ffmpeg and having ResidualVM support viewing ffmpegs.Ezekiel000 wrote:Irrelevant?MusicallyInspired wrote:OGG Theora video is better.
As I understood it loki was talking about using ffmpeg to decode the games videos for future engines, not to re-encode the videos.
Re: suggestion: using ffmpeg for future-proof video support
you can enable and disable codecs when building, thus only including the needed codecs. even if not disabling any: the 3d games supported by residual will not run on platforms so limited that they would have problems with slightly increased binary size.jvprat wrote:It would probably be an overkill. Why adding support for lots of codecs if just a few are going to be used? That would increase the binary size, reducing the possibility for ResidualVM to be ported to resource-limited platforms.
In some cases, the ScummVM approach has been copying the portions of ffmpeg required to decode a given format into ScummVM itself (it can be done because both projects are licensed under the GPL). That way it just contains the required bits and ScummVM devs can make their own changes to the code.
i think it would be a motivating factor for anybody creating a prototype for a new engine for residual to just call a function/method and just have the games videos playing already, without having to manually port some code over.
Re: suggestion: using ffmpeg for future-proof video support
However, this still adds another dependency, which is not something wanted in ScummVM, and probably not for ResidualVM. I can't speak for the ResidualVM team here.loki1985 wrote:you can enable and disable codecs when building, thus only including the needed codecs. even if not disabling any: the 3d games supported by residual will not run on platforms so limited that they would have problems with slightly increased binary size.
Yeah, I don't think that would be a motivating factor. Considering how easy it is to make a video decoder based off the FFmpeg code, it's not a problem.loki1985 wrote:i think it would be a motivating factor for anybody creating a prototype for a new engine for residual to just call a function/method and just have the games videos playing already, without having to manually port some code over.
In the end, I would agree with jvprat. Each engine is different and even changes the way the codecs/formats in FFmpeg are used. For example, Toonstruck uses a hacked up Smacker decoder that has frame size data in an extra sound stream that neither FFmpeg nor the RAD decoder handle. With QuickTime, FFmpeg doesn't even fully handle what I need for Mohawk over in ScummVM. Considering how complex FFmpeg is, it would not be easy to add this code to anyone not familiar with FFmpeg. In fact, this would be the opposite of a motivating factor. So no, adding the FFmpeg dependency is not worth it.
