Reimplement PlayMovie using FFMPEG/libavcodec

[RockstarRaccoon]

I'm not entirely sure how difficult something like this would be, but I think it would be cool if someone could add, say, the prerendered cutscenes from the console version of Hexen, or maybe make a live action video for breifings, or maybe a video for the opening of a standalone game.

I know https://zdoom.org/wiki/PlayMovie hasn't been implemented for a while, and I'm wondering if it could be reimplemented with an open source library like libavcodec...

[dpJudas]

The main problem with video playback is that it is patented to hell.

[Graf Zahl]

Not only that, these libraries are also normally huge because the codecs are so complex. In VLC the libavcodec plugin is a hefty 14 MB alone, and it's only one of many.

[RockstarRaccoon]

Maybe add optional support for a livavcodec.dll or whatever, like with the openAL / Fmod stuff?

[Kinsie]

Did any mods even attempt to use the old implementation back in the day? I know Skulltag threatened to at some point, but that's all I've heard.

Granted, this is before everyone and their dog considered themselves Video Production Experts...

EDIT: In addition, the file size considerations would probably make video file usage about as popular around here as careless use of MP3/OGG music.

[Graf Zahl]

The old implementation was never used. It was Windows only, had its share of massive problems and finally went poof when the Direct3D backend turned out to be incompatible with that crusty old code.

Regarding file size, this possibly is more suitable for full games, not for Doom mods.

[Rachael]

The only way I can see this working is if GZDoom externalizes the work to either some sort of HTML or media toolkit that would not be included in GZDoom, itself. Otherwise, it really is not worth pulling in AV libraries to pull this off. I'm really not interested in tripling the size of GZDoom's distribution for a feature that will see niche use at best.

And then you have to be careful with including videos in your mod - because obviously not all formats will always be supported.

[wildweasel]

Someone was saying, some time ago, that RoQ might work for ZDoom's purposes...though I have no idea how feasible an implementation would even be, I've never worked with the encoder before, and adopting a semi-proprietary format from a completely different engine might throw even more burden on ZDoom (look at the headaches we're already having with MD3s).

[Chris]

In theory you could build a version of avformat/avcodec that only supported open royalty-free codecs (theora, webm). But that could be a pain to get set up for people building GZDoom, and the library sizes may still be rather large. And there's the issue that FFmpeg has a habit of changing its API whenever something looks at it funny. It's unfortunate that it's the only real means for proper video decoding that doesn't involve directly embedding reference decoder libraries and dealing with their individual quirks (something FFmpeg does do relatively well is compartmentalize individual aspects of codecs, so individual decoders can share common code, and transparently fixing up out-of-order frame decoding, where frames are presented in a different order than they're decoded).

[RockstarRaccoon]

In theory you could build a version of avformat/avcodec that only supported open royalty-free codecs (theora, webm). But that could be a pain to get set up for people building GZDoom, and the library sizes may still be rather large.

Like I said, it doesn't have to come standard, just allow users to optionally have a library on hand...

adopting a semi-proprietary format from a completely different engine might throw even more burden on ZDoom (look at the headaches we're already having with MD3s).

Could you elaborate on this? I wasn't aware there were issues...

[wildweasel]

adopting a semi-proprietary format from a completely different engine might throw even more burden on ZDoom (look at the headaches we're already having with MD3s).

Could you elaborate on this? I wasn't aware there were issues...

The main problem - aside from the known limitations of MD3 as a format - is that a reliable export pipeline to such a format is getting harder and harder to setup lately, considering that a lot of the programs that used to be in common use back when Quake 3 was a new thing are no longer so easy to obtain/install/run on modern machines.

The same goes for the RoQ format - as nice as it'd be to have one single format for movies, there is only one encoder for it, and it probably already has a very limited set of video formats that it can detect and convert from. In the future, when the commonly-used video editors drop support for those formats in favor of whatever compression algorithm works better 10, 5, or even 2 years from now, what will the budding ZDoom movie-maker do? Hang on to the programs that still work until those stop being usable on the computers of the day? The rendering pipeline would only get worse over time.

[Rachael]

Someone was saying, some time ago, that RoQ might work for ZDoom's purposes...though I have no idea how feasible an implementation would even be, I've never worked with the encoder before, and adopting a semi-proprietary format from a completely different engine might throw even more burden on ZDoom (look at the headaches we're already having with MD3s).

This might be the only solution to this. How big is the rendering engine? If it's fairly small I wouldn't mind something like this.

[Chris]

Like I said, it doesn't have to come standard, just allow users to optionally have a library on hand...

It still needs to be there to build support for when compiling. The way libavformat/libavcodec work, they can't be optionally loaded at run-time, and having some peoples' builds support video playback and others not because it was a hassle to set up properly could be a problem.

[Graf Zahl]

Someone was saying, some time ago, that RoQ might work for ZDoom's purposes...though I have no idea how feasible an implementation would even be, I've never worked with the encoder before, and adopting a semi-proprietary format from a completely different engine might throw even more burden on ZDoom (look at the headaches we're already having with MD3s).

This might be the only solution to this. How big is the rendering engine? If it's fairly small I wouldn't mind something like this.

Agreed. Libavcodec is definitely not an option.

[HAL9000]

RoQ would be a nice feature to have, I had to create animated MD3 model with texture frames on it for my project's intro animation(map), and sync audio to it. It was a nightmare to sync it to the framerate.