fabian Posted May 28, 2020 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 3 Share this post Link to post
Dimon12321 Posted May 28, 2020 (edited) 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 May 28, 2020 by Dimon12321 0 Share this post Link to post
chungy Posted May 28, 2020 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). 2 Share this post Link to post
cybermind Posted May 28, 2020 How about a hardware-accelerated option? 0 Share this post Link to post
fabian Posted May 28, 2020 43 minutes ago, cybermind said: How about a hardware-accelerated option? As a default value? I don't think so. 0 Share this post Link to post
fabian Posted May 29, 2020 @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. 0 Share this post Link to post
fabian Posted May 29, 2020 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? 1 Share this post Link to post
Dimon12321 Posted May 29, 2020 2 hours ago, fabian said: Do you mean the "Timed %u gametics in %u realtics = %-.1f frames per second" message? Yes, I do. 0 Share this post Link to post
fabian Posted May 29, 2020 (edited) 24 minutes ago, Dimon12321 said: Yes, I do. Alright, it won't be shown anymore end the end of a timedemo when dumping to a video file. https://github.com/coelckers/prboom-plus/commit/a6118c4045f360ceff07c7e06e094004d4b107d2 2 Share this post Link to post
Dimon12321 Posted May 29, 2020 8 minutes ago, fabian said: Alright, it won't be shown anymore end the end of a timedemo when dumping to a video file. https://github.com/coelckers/prboom-plus/commit/a6118c4045f360ceff07c7e06e094004d4b107d2 Wow, that's was fast! Wish you guys luck in improving this fork! 0 Share this post Link to post
chungy Posted May 29, 2020 @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 0 Share this post Link to post
fabian Posted May 29, 2020 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? 0 Share this post Link to post
chungy Posted May 30, 2020 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. 0 Share this post Link to post
fabian Posted June 6, 2020 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? 0 Share this post Link to post
fabian Posted June 6, 2020 (edited) 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. 1 Share this post Link to post
Dimon12321 Posted June 15, 2020 (edited) 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 June 15, 2020 by Dimon12321 1 Share this post Link to post
chungy Posted June 15, 2020 (edited) 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 June 15, 2020 by chungy 2 Share this post Link to post
blob1024 Posted August 13, 2020 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? 0 Share this post Link to post
Dimon12321 Posted August 13, 2020 (edited) @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. 1 Share this post Link to post
blob1024 Posted August 13, 2020 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! 1 Share this post Link to post
blob1024 Posted August 13, 2020 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? 0 Share this post Link to post
Shepardus Posted August 13, 2020 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). 0 Share this post Link to post
Dimon12321 Posted August 14, 2020 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 1 Share this post Link to post
plums Posted October 29, 2020 (edited) 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 October 29, 2020 by plums 0 Share this post Link to post
Dimon12321 Posted October 29, 2020 (edited) 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. 1 Share this post Link to post
plums Posted October 29, 2020 (edited) 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 October 29, 2020 by plums 0 Share this post Link to post
chungy Posted October 29, 2020 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. 1 Share this post Link to post
plums Posted October 29, 2020 (edited) @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 October 29, 2020 by plums 1 Share this post Link to post
spd7693 Posted November 2, 2020 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. 0 Share this post Link to post
plums Posted November 2, 2020 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 0 Share this post Link to post