implement viddump

[rfomin]

The video and sound are working, but they are not in sync at the moment. I just want to check how it will compile in CI and what the size of the static binaries will be.

Command line: woof -devparm -viddump -timedemo demo1
"output.mp4" file will be created.

[fabiangreffrath]

Great that you got audio working, congratulations!

[fabiangreffrath]

Some of these settings should become config options. For example, I'd prefer opus codec over mp2. And some distributions might be unable to ship patent encumbered mpeg video codecs.

[fabiangreffrath]

Also, we should try to dlopen() the libraries, so we don't have to carry them along ourselves. We could tell users to download ffmpeg binary releases from elsewhere and simply drop the libraries into the Woof executable directory. I think there are portable helper functions in DSL for this.

[rfomin]

Some of these settings should become config options. For example, I'd prefer opus codec over mp2. And some distributions might be unable to ship patent encumbered mpeg video codecs.

The MP2 supports the AV_SAMPLE_FMT_S16 format; the others require the AV_SAMPLE_FMT_FLTP format (planar float). Since OpenAL doesn't support planar formats, we need resampling. I didn't bother with that yet.

Yes, we need a lot of options. Perhaps we should create profiles: "lossless" (FFV1 codec), "fast," and "slow."

Also, we should try to dlopen() the libraries, so we don't have to carry them along ourselves.

For Linux, I have a 19 MB AppImage, which isn't bad: https://github.com/fabiangreffrath/woof/actions/runs/15091989526/artifacts/3145857687
Windows failed. I'll look into it later.

[fabiangreffrath]

The MP2 supports the AV_SAMPLE_FMT_S16 format; the others require the AV_SAMPLE_FMT_FLTP format (planar float). Since OpenAL doesn't support planar formats, we need resampling. I didn't bother with that yet.

I see, didn't think about that before.

Yes, we need a lot of options. Perhaps we should create profiles: "lossless" (FFV1 codec), "fast," and "slow."

Yes, profiles sound like a very good idea. 👍

[fabiangreffrath]

The MP2 supports the AV_SAMPLE_FMT_S16 format; the others require the AV_SAMPLE_FMT_FLTP format (planar float). Since OpenAL doesn't support planar formats, we need resampling. I didn't bother with that yet.

I see, didn't think about that before.

Apparently, opus can also encode from 16-bit samples. MP2 may be appropriate for a "fast" profile, though.

[fabiangreffrath]

Any experiences with AV1, VP8 or VP9 for video encoding? Just a thought...

[rfomin]

Any experiences with AV1, VP8 or VP9 for video encoding? Just a thought...

I use Nvidia encoders with my GPU (no VP8/VP9 support), so H.264 and H.265 are the fastest options for me. I've never tried AV1.

The current plan is to use FFV1 with paletted graphics support for the "lossless" profile and a variant of H.264 (first search for "h264_nvenc," then fall back to "x264") for the "fast" and "slow" profiles.

[fabiangreffrath]

Yes, sounds reasonable. I'd still vote for an entirely (patent) free alternative for users of very restricted ffmpeg distributions, something like "xiph" (theora + vorbis) or "webm" (vp8 + vorbis or vp9 + opus).

[fabiangreffrath]

For reference, Dosbox uses the lossless ZMBV codec for its video recordings, which might thus be a bit better supported than ffmpeg's very own ffv1 codec. Gnome Shell's screen recording feature tries (variants of) h264 and falls back to vp8 in a webm container.

https://gitlab.gnome.org/GNOME/gnome-shell/-/blob/main/js/dbusServices/screencast/screencastService.js

[rfomin]

For reference, Dosbox uses the lossless ZMBV codec for its video recordings, which might thus be a bit better supported than ffmpeg's very own ffv1 codec.

FFmpeg supports ZMBV, but FFV1 is much more sophisticated. Anyway, I will try it.

[fabiangreffrath]

Random thought: can we replace spng with ffmpeg libs while at it?

[rfomin]

Random thought: can we replace spng with ffmpeg libs while at it?

I doubt it. We use some advanced features to access the grAb chunk, for example. We have the option of replacing it with libpng, but its API is overly complicated. The same is true of ffmpeg.

BTW, ffmpeg API changes quite often, so the dlopen idea is also cumbersome. The API changes so often that there are tons of broken examples on internet.

[fabiangreffrath]

Command line: woof -devparm -viddump -timedemo demo1

-devparm ?

[fabiangreffrath]

If recording in widescreen mode, the video is completely distorted.

Is it possible that video and sound are desync because of the wipe screen? I mean, it isn't recorded on the video track, but maybe the audio track waits for it?

[rfomin]

Is it possible that video and sound are desync because of the wipe screen? I mean, it isn't recorded on the video track, but maybe the audio track waits for it?

I haven't put much effort into syncing it yet. I think viddump should only work in demo playback mode and shouldn't skip any frames. PrBoom+ has separate logic in the main loop for this.

Maybe we should rename viddump to converttovideo: -converttovideo demo.lmp output.mp4

[fabiangreffrath]

I haven't put much effort into syncing it yet. I think viddump should only work in demo playback mode and shouldn't skip any frames. PrBoom+ has separate logic in the main loop for this.

Yes, it shound't. But right now the wipe screen frames are skipped.

Maybe we should rename viddump to converttovideo: -converttovideo demo.lmp output.mp4

But people are already used to the PrBoom+ CLI syntax.

[fabiangreffrath]

Also, "-viddump" is missing from params.h. And I_MPG_Init() should quit with an error message if the source was compiled without ffmpeg support.