suggestion: using ffmpeg for future-proof video support

General chat related to ScummVM, adventure gaming, and so on.

Moderator: ScummVM Team

Post Reply
loki1985
Posts: 17
Joined: Sun Nov 06, 2005 8:25 pm

suggestion: using ffmpeg for future-proof video support

Post by loki1985 »

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.
User avatar
MusicallyInspired
Posts: 1074
Joined: Fri Mar 02, 2007 8:03 am
Location: Manitoba, Canada
Contact:

Post by MusicallyInspired »

OGG Theora video is better.
User avatar
ezekiel000
Posts: 443
Joined: Mon Aug 25, 2008 5:17 pm
Location: Surrey, England

Post by ezekiel000 »

MusicallyInspired wrote:OGG Theora video is better.
Irrelevant?

As I understood it loki was talking about using ffmpeg to decode the games videos for future engines, not to re-encode the videos.
jvprat
ScummVM Developer
Posts: 76
Joined: Mon Oct 30, 2006 9:10 pm

Re: suggestion: using ffmpeg for future-proof video support

Post by jvprat »

loki1985 wrote:ffmpeg is lgpl/gpl, and next to decoding a huge array of video codecs, it also supports a lot of audio codecs.
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.
User avatar
MusicallyInspired
Posts: 1074
Joined: Fri Mar 02, 2007 8:03 am
Location: Manitoba, Canada
Contact:

Post by MusicallyInspired »

Ezekiel000 wrote:
MusicallyInspired wrote:OGG Theora video is better.
Irrelevant?

As I understood it loki was talking about using ffmpeg to decode the games videos for future engines, not to re-encode the videos.
Oh. I thought he was talking about converting game videos with ffmpeg and having ResidualVM support viewing ffmpegs.
loki1985
Posts: 17
Joined: Sun Nov 06, 2005 8:25 pm

Re: suggestion: using ffmpeg for future-proof video support

Post by loki1985 »

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.
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.

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.
User avatar
clone2727
Retired
Posts: 1611
Joined: Fri Jun 09, 2006 8:23 pm
Location: NJ, USA

Re: suggestion: using ffmpeg for future-proof video support

Post by clone2727 »

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.
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: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.
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.

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.
User avatar
Longcat
Posts: 1053
Joined: Sat Sep 23, 2006 3:15 pm

Post by Longcat »

.... so. this means your secret project is Toonstruck?! omg, I love you cloney:P
User avatar
clone2727
Retired
Posts: 1611
Joined: Fri Jun 09, 2006 8:23 pm
Location: NJ, USA

Post by clone2727 »

Longcat wrote:.... so. this means your secret project is Toonstruck?! omg, I love you cloney:P
No, that would be SylvainTV's project. I just helped him with that problem :wink:
User avatar
Longcat
Posts: 1053
Joined: Sat Sep 23, 2006 3:15 pm

Post by Longcat »

Whut?! i was only joking:) is there a repository for it anywhere?
Post Reply