Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
fabian

Preferred -viddump commands (cap_*command) for PrBoom+?

Recommended Posts

HI there,

 

currently, PrBoom+ uses the triple of oggenc2, x264 and mkvmerge to produce video files when run with the -viddump parameter. However, in the past, people have posted alternative commands here - mostly using only ffmpeg to perform all three tasks - to achieve the same (or even better?) results.

 

I am considering to change the default commands for the PrBoom+/UMAPINFO fork. So, if there is something like a "community consensus" about which commands are best suited - or if the ones provided by default are good enough already - I'd like to hear about this.

 

Thanks!

 

 - Fabian

 

Share this post


Link to post

I'm satisfied with -viddump command and the overall quality of the video, thanks to the config file. 

The only thing I hate about it is, when a replay is over, you must click OK at the window which shows the results* of dumping, in order to start video and audio merging process. I want it start as soon as the dumping is over, without my permission. It will start merging anyway, so why does it need me to click OK? I would spend less time on having my video recorded.

 

* - by the way, these results are incorrect if you start dumping not from the beginning of a replay (using -skipsec and -warp commands)

Edited by Dimon12321

Share this post


Link to post
9 hours ago, fabian said:

currently, PrBoom+ uses the triple of oggenc2, x264 and mkvmerge to produce video files when run with the -viddump parameter.

In the past, the defaults here were not working for me, I believe because at least one of these commands changed the parameters accepted and that broke prboom-plus's defaults. Plus, I really prefer having lossless output too.

 

9 hours ago, fabian said:

However, in the past, people have posted alternative commands here - mostly using only ffmpeg to perform all three tasks - to achieve the same (or even better?) results.

I do this, for the two reasons I said in the prior paragraph, and also because I already know how to use ffmpeg (and its command parameters tend to be stable over... forever). As a result, my settings are configured as such:

cap_soundcommand          "ffmpeg -f s16le -ar %s -ac 2 -i - -c:a copy -y temp_a.nut"
cap_videocommand          "ffmpeg -f rawvideo -pix_fmt rgb24 -r %r -s %wx%h -i - -c:v copy -y temp_v.nut"
cap_muxcommand            "ffmpeg -i temp_v.nut -i temp_a.nut -c copy -y %f"
cap_tempfile1             "temp_a.nut"
cap_tempfile2             "temp_v.nut"
cap_remove_tempfiles          1
cap_fps                      35

This does tend to result in very large files, especially given that the video is stored as an uncompressed series of frames. I have a file system with transparent compression (zfs with lz4), so it turns how to actually not need much space compared to the size of the file, and it's pretty quick.

 

If there does happen to be a consensus for lossless output by default, "-c:a flac" (audio) and "-c:v h264 -qp 0" (video) would probably be better considering disk space and most people don't have a file system with compression... it's slower to output, but still gives the same effect.

 

On the other hand, if lossy-and-small files are a better default, then probably "-c:a opus" for audio and "-c:v h264" (no -qp) for video. Swap out h264 for vp9 if an open source codec is preferred (like h264, vp9 also supports both lossless and lossy modes; lossless needs "-lossless 1" though).

Share this post


Link to post
43 minutes ago, cybermind said:

How about a hardware-accelerated option?

 

As a default value? I don't think so. 

Share this post


Link to post

@chungy Thanks for your reply. I think we are looking for a video file format that people could easily copy on their smartphones or upload to youtube. Lossless video and audio is probably more a corner case than a mainstream requirement.

The .nut format seems to be an intermediate container format specific to ffmpeg, right? And the format of the resulting video file would be determined from the file extension given at the command line?

Given that we want to achieve about the same file size and quality as with the current defaults, but using less individual commands, could you please perform a test run and convert a demo to a video with (a) the current defaults and (b) your ffmpeg based approach with "-c:a opus" for audio and "-c:v h264" (no -qp) for video? That would be great!

@cybermind Sorry for my sparse reply yesterday, it was sent from my phone. The point is we cannot make hardware-accelerated encoding the default, because this approach strictly depends on the hardware to use. What works for you and your nvidia card will not work for my intel on-board graphics or for other people's ati card. This is system specific fine tuning, but we need a default that works for everyone out-of-the-box.

Share this post


Link to post
22 hours ago, Dimon12321 said:

The only thing I hate about it is, when a replay is over, you must click OK at the window which shows the results* of dumping, in order to start video and audio merging process.

 

Do you mean the "Timed %u gametics in %u realtics = %-.1f frames per second" message?

Share this post


Link to post
2 hours ago, fabian said:

Do you mean the "Timed %u gametics in %u realtics = %-.1f frames per second" message?

Yes, I do.

Share this post


Link to post

@fabian

 

The NUT container format isn't quite specific to ffmpeg, but it doesn't have wide player support either. It mainly exists as a container that stores parameters for raw audio and video streams. Beyond that, the hard-dependence in my own config lines is limited to the temporary files and the final container format is chosen based on name.

 

I am assuming we're talking about the coelckers fork, of which video capture seems to be totally broken, doesn't matter if it's a default config or what my config actually contains:

vorb_registersong: failed
mad_registersong failed: input buffer too small (or EOF)
Exp_RegisterSongEx: Couldn't find preferred music player dumb tracker player in list
  (typo or support not included at compile time)
Exp_RegisterSongEx: Music player fluidsynth midi player on preferred list but it failed to init
Exp_RegisterSongEx: Using player opl2 synth player

 

Share this post


Link to post
5 hours ago, chungy said:

 

I am assuming we're talking about the coelckers fork, of which video capture seems to be totally broken, doesn't matter if it's a default config or what my config actually contains:

 

Oh, that looks like a different issue to tackle. Anyway, how do the different vidcap commands perform in a working prboom-plus release? 

Share this post


Link to post
22 hours ago, fabian said:

Anyway, how do the different vidcap commands perform in a working prboom-plus release? 

in what context? The defaults are still as broken for me as ever. I probably could fix the direct use of oggenc/x264 but I've never cared to.

 

Beyond that, the engine just opens a pipe to send data through stdin to whatever's listed in the config. I know how to use ffmpeg and I like ffmpeg, so that's the path I've taken.

 

If you want a reasonable lossy-mode default with ffmpeg, then just do this

cap_soundcommand          "ffmpeg -f s16le -ar %s -ac 2 -i - -c:a libopus -y temp_a.nut"
cap_videocommand          "ffmpeg -f rawvideo -pix_fmt rgb24 -r %r -s %wx%h -i - -c:v libx264 -y temp_v.nut"
cap_muxcommand            "ffmpeg -i temp_v.nut -i temp_a.nut -c copy -y %f"
cap_tempfile1             "temp_a.nut"
cap_tempfile2             "temp_v.nut"
cap_remove_tempfiles          1

vp9 is probably an even better video codec in the free software-purity sense, but the encoder is glacially slow and that's enough to make me think of it as a bad default.

Share this post


Link to post
On 5/30/2020 at 6:42 PM, chungy said:

in what context? The defaults are still as broken for me as ever. I probably could fix the direct use of oggenc/x264 but I've never cared to.

 

Hm, could you probably file this as an issue (with some extra information, e.g. software or OpenGL rendering, windowed or fullscreen, etc.) on the Github project page, so I am not losing track of it?

Share this post


Link to post

So, these are my own findings so far. I performed a little benchmark by letting prboom-plus play back and transform into video the three internal demos of doom2.wad on my otherwise idle computer (i5-8265U) strictly using the ports default config (software rendering in a 640x480 window, i.e. starting with an empty config file). These are the versions of the Debian packages that I used:

 

$ dpkg -l prboom-plus mkvtoolnix vorbis-tools x264 ffmpeg | grep ^ii
ii  ffmpeg         7:4.2.2-1+b1              amd64        Tools for transcoding, streaming and playing of multimedia files
ii  mkvtoolnix     47.0.0-1+b1               amd64        Set of command-line tools to work with Matroska files
ii  prboom-plus    2:2.5.1.7um+git72-1       amd64        enhanced clone of the classic first-person shooter Doom
ii  vorbis-tools   1.4.0-11                  amd64        several Ogg Vorbis tools
ii  x264           2:0.155.2917+git0a84d98-2 amd64        video encoder for the H.264/MPEG-4 AVC standard

 

These are the timed results of the conversions. Here, "old" means the current defaults using three separate tools and "new" means the alternative approach using only the ffmpeg tool.

 

$ for i in 1 2 3; do time prboom-plus -timedemo demo${i} -viddump old${i}.mkv; done
[...]
real	0m36,867s
user	1m3,935s
sys	0m2,049s
[...]
real	1m2,572s
user	1m52,028s
sys	0m3,178s
[...]
real	2m18,871s
user	4m12,484s
sys	0m7,102s

[...]

$ for i in 1 2 3; do time prboom-plus -timedemo demo${i} -viddump new${i}.mkv; done
[...]
real	0m32,506s
user	0m56,178s
sys	0m1,933s
[...]
real	0m53,701s
user	1m35,178s
sys	0m3,194s
[...]
real	2m4,840s
user	3m45,225s
sys	0m6,932s

So, all in all, the "new" approach using only ffmpeg is a bit faster for all three demos.

 

 ls -lh *.mkv
-rw-r--r-- 1 fabian fabian 7,4M Jun  6 16:23 new1.mkv
-rw-r--r-- 1 fabian fabian  11M Jun  6 16:23 new2.mkv
-rw-r--r-- 1 fabian fabian  30M Jun  6 16:26 new3.mkv
-rw-r--r-- 1 fabian fabian  23M Jun  6 16:15 old1.mkv
-rw-r--r-- 1 fabian fabian  29M Jun  6 16:16 old2.mkv
-rw-r--r-- 1 fabian fabian  69M Jun  6 16:18 old3.mkv

Also, the produced files are all smaller by quite a margin.

 

And these are the resulting stream properties of the dumped video files:

$ ffprobe old1.mkv 2>&1 | grep Stream
    Stream #0:0: Video: h264 (High), yuv420p(progressive), 640x480, SAR 1:1 DAR 4:3, 60 fps, 60 tbr, 1k tbn, 120 tbc (default)
    Stream #0:1: Audio: vorbis, 22050 Hz, stereo, fltp (default)
$ ffprobe new1.mkv 2>&1 | grep Stream
    Stream #0:0: Video: h264 (High 4:4:4 Predictive), yuv444p(progressive), 640x480, 60 fps, 60 tbr, 1k tbn, 120 tbc (default)
    Stream #0:1: Audio: opus, 48000 Hz, stereo, fltp (default)

 

So, IMHO nothing speaks against changing the defaults to the "new" ffmpeg-based approach presented by @chungy here.

Share this post


Link to post
On 5/28/2020 at 7:38 PM, chungy said:
Spoiler

 



cap_soundcommand          "ffmpeg -f s16le -ar %s -ac 2 -i - -c:a copy -y temp_a.nut"
cap_videocommand          "ffmpeg -f rawvideo -pix_fmt rgb24 -r %r -s %wx%h -i - -c:v copy -y temp_v.nut"
cap_muxcommand            "ffmpeg -i temp_v.nut -i temp_a.nut -c copy -y %f"
cap_tempfile1             "temp_a.nut"
cap_tempfile2             "temp_v.nut"
cap_remove_tempfiles          1
cap_fps                      35

This does tend to result in very large files, especially given that the video is stored as an uncompressed series of frames. I have a file system with transparent compression (zfs with lz4), so it turns how to actually not need much space compared to the size of the file, and it's pretty quick.

 

If there does happen to be a consensus for lossless output by default, "-c:a flac" (audio) and "-c:v h264 -qp 0" (video) would probably be better considering disk space and most people don't have a file system with compression... it's slower to output, but still gives the same effect.

 

 

 

Could you please help me set encoding parameters for a high-quality video encoding?

For now I have this (using 2.5.1.7, build 12 June 2020):

cap_videocommand "ffmpeg -f rawvideo -pix_fmt rgb24 -r %r -s %wx%h -i - -c:v libx264 -preset veryslow -crf 0 -y temp_v.nut"

Even though I'm kinda satisfied with the overall size, but the encoding speed is really slow. How to solve it?

ZeroMaster suggested this (for 2.5.1.5) for 1080p60: 

cap_videocommand "x264 -o output.264 --bitrate 96000 (some other cmds)"

It works fine and the quality is brilliant for upscaling. So, I'm wondering how to get an equivalent for ffmpeg?

 

Edited by Dimon12321

Share this post


Link to post

I don't know what you're doing with "-preset veryslow -crf 0" in there, but that's the reason why it's slow (one of the parameters is even explicit about it!). Take it out and it should be nice and speedy. To translate ZeroMaster's x264-based suggestion, add "-b:v 96k" in place of the preset and crf parameters -- I don't really suggest doing this unless you've actually tested the resulting quality.

 

As an aside: "-crf 0" is mistakingly thrown around sometimes to represent lossless encoding, which it is not. "-qp 0" is for actual lossless in H264.

Edited by chungy

Share this post


Link to post

hello

 

sorry if I jump in here a little offtopic, but the answers here were very accurate and my problem should be little.

when I use timedemo to create demos, everything goes fine, but if I use "portmidi" in music settings, then the ogg file has no music sound.

using the other music setting produces terrible music outputs sadly, but keeps the music.

 

what I do wrong?

Share this post


Link to post

@blob1024 -viddump isn't flexible when it comes to recording music. IIRC, it doesn't record music if you use Portmidi or SDL, and OPL2's sound quality is terrible.
The best option here is to set "Preferred MIDI player" to Fluidsynth and pick a soundfont which feets well to the WAD you want to record. Put an .sf2 file in the folder with PrBoom+, open a configuration file (glboom-plus.cfg or prboom-plus.cfg), find these lines and adapt them.

 

snd_midiplayer            "fluidsynth"
snd_soundfont             "Scc1t2.sf2" <-- enter the name of .sf2 you'd like to be used

Here's a comparison video of MIDI soundfonts.

Share this post


Link to post
2 hours ago, Dimon12321 said:

@blob1024 -viddump isn't flexible when it comes to recording music. IIRC, it doesn't record music if you use Portmidi or SDL, and OPL2's sound quality is terrible.
The best option here is to set "Preferred MIDI player" to Fluidsynth and pick a soundfont which feets well to the WAD you want to record. Put an .sf2 file in the folder with PrBoom+, open a configuration file (glboom-plus.cfg or prboom-plus.cfg), find these lines and adapt them.

 

snd_midiplayer            "fluidsynth"
snd_soundfont             "Scc1t2.sf2" <-- enter the name of .sf2 you'd like to be used

Here's a comparison video of MIDI soundfonts.

amazing. this was of a great help. I found scc1t2 and gm22 the best fonts as well

sounds pretty much like portmidi-one, im very happy thanks!

Share this post


Link to post

one last thing I wanted to know was about the FPS. I see its 35 as default, for more fluid and enjoyable videos I tried to change it to 60, with disastrous results. the viddump produced a mp4-video file with faster speed than normal.

Am I again doing something wrong? or should I simply stick with 35 fps always?

Share this post


Link to post

I set both cap_fps and the framerate in cap_videocommand (replacing the "%r") to 60 and that worked for me. I remember having a similar issue with the default cap_videocommand (before the default switched to ffmpeg, I haven't tried with ffmpeg yet).

Share this post


Link to post
17 hours ago, blob1024 said:

Am I again doing something wrong? or should I simply stick with 35 fps always?

 

Inside glboom-plus.cfg. That should work. Using 2.5.1.7

# Video capture encoding settings
cap_soundcommand          "ffmpeg -f s16le -ar %s -ac 2 -i - -c:a libopus -y temp_a.nut"
cap_videocommand          "ffmpeg -f rawvideo -pix_fmt rgb24 -r %r -s %wx%h -i - -c:v libx264 -b:v 95M -y temp_v.nut"
cap_muxcommand            "ffmpeg -i temp_v.nut -i temp_a.nut -c copy -y %f"
cap_tempfile1             "temp_a.nut"
cap_tempfile2             "temp_v.nut"
cap_remove_tempfiles          1
cap_fps                      60

 

Share this post


Link to post

Hey, looking for help with viddump with 2.5.1.7 latest git build. It works, but I get random frames flickering in once in a while. Here's an example, you can see a bunch in the first 10 seconds. This happens with either the GL or software renderer.

 

Also I have to use -timedemo to play demos, and have to leave the demo playing onscreen while it's dumping the video (i.e. can't switch to another program while I'm waiting), but IIRC that's maybe just how PrB+'s viddump works?

 

 

Edited by plums

Share this post


Link to post

It's either a bugged version of the source port or the video encoder you're using has an internal problem. Some builds of x264.exe may provide this kind of a problem. I haven't seen such issues in ffmpeg, so I can't say for sure. Have you faced this problem earlier?

 

If you record a video in full-screen, you'll need to leave the demo playing on screen. If it's being recorded in a window, you can put various windows on the foreground, there will be no issues.

Share this post


Link to post
36 minutes ago, Dimon12321 said:

It's either a bugged version of the source port or the video encoder you're using has an internal problem. Some builds of x264.exe may provide this kind of a problem. I haven't seen such issues in ffmpeg, so I can't say for sure. Have you faced this problem earlier?

I'm using Linux, haven't had any problems like this before (though since getting the computer I'm using, I haven't done much video stuff, and never -viddump).

 

Quote

If you record a video in full-screen, you'll need to leave the demo playing on screen. If it's being recorded in a window, you can put various windows on the foreground, there will be no issues.

That works (e: with OpenGL output only, but that's fine), and actually reduces the flickering somewhat(?), thanks.

Edited by plums

Share this post


Link to post

If you're on Linux, you need to have a compositing window manager so that windows above the prboom-plus one don't interrupt the game's repaint and also video recording.

Share this post


Link to post

@spd7693 was asking for help with converting lmps in Clippy's latest map thread, I'm replying here instead. AFAIK these are the current requirements for viddump on Windows.

 

Quote

Well, if someobody tells me how I can convert those LMP's so that I can post them on YouTube or give me some tutorial on OBS for recording, I might finally start doing that.

 

Here's a config for windows that I used in Wine to viddump lmps: prboom-plus.cfg.zip Put it in your prboom-plus folder. You can rename it to something like prbvideo.cfg to not overwrite your normal config, if you want. Run prboom-plus -config prbvideo.cfg to load it, set the video options to how you want your video output to be. glboom-plus works too. Use windowed mode so that you can still do other things while the video renders, thanks to @Dimon12321 for the tip. I had problems with vsync, so try turning it off if you use glboom-plus.

 

Get ffmpeg from https://www.gyan.dev/ffmpeg/builds/ffmpeg-release-full.7z. Put ffmpeg.exe into your PrBoom+ directory.

 

Then run prboom-plus -config prbvideo.cfg -file wadname.wad -timedemo demoname.lmp -viddump myvideo.mkv

 

Post here if you can't get it working.

 

 

edit: The config I posted outputs a video at 35 FPS, since that is all I could get working with older PrB versions (which is what spd7693 said he used). New 2.5.1.7 versions shouldn't need that config. So maybe this wasn't the right thread for this, sorry :p

 

 

Edited by plums

Share this post


Link to post
On 10/29/2020 at 11:13 PM, plums said:

Then run prboom-plus -config prbvideo.cfg -file wadname.wad -timedemo demoname.lmp -viddump myvideo.mkv

 

Post here if you can't get it working.

 

Runs, but since GLBoom+ can't read pictures from that format as the title pic, it crushes before I can configure the video. Will work on everything else I think, but not that. 

Share this post


Link to post
1 hour ago, spd7693 said:

 

Runs, but since GLBoom+ can't read pictures from that format as the title pic, it crushes before I can configure the video. Will work on everything else I think, but not that. 

Try this, I replaced the titlepic with a vanilla-compatible edit.

choices1.zip

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×