Why viddump command is outputting videos in very low quality?

For clarification, the viddump command was working fine for me other than the fact that for a demo length of ~15 minutes. It took a full 1.5 hr to render (is there any way to make it faster??)

But.The problem arose for me when the video (mkv format), when played back (i was using vlc for this) , was looking like a 240p yt video. I even looked in the usage.txt to see if there were any shortcomings form my side but i found none. 

I also can't use the opengl renderer for making a viddump as it immediately crashes when I just open it (I'm stuck with software renderer for now). So, is there any way to make a viddump look like a nice 1080p video using software mode only (asking this for doing it in dsda-doom's latest version again)...

Viddump will produce output in the same resolution that the game runs at, so make sure you run the game at 1080p if you want the video to be 1080p.

Are you using the default encoding settings? If not, share your configs here (the section in the config file under "Video capture encoding settings").

On 3/28/2023 at 6:28 AM, Shepardus said:

Viddump will produce output in the same resolution that the game runs at, so make sure you run the game at 1080p if you want the video to be 1080p.

 

Are you using the default encoding settings? If not, share your configs here (the section in the config file under "Video capture encoding settings").

Here's my configuration:

That looks to be the default, which should give reasonable quality in most situations. Some especially busy visuals can cause the video encoding to suffer (FIREBLU is notorious for this), so maybe it's worth asking what specifically you're trying to render.

32 minutes ago, Shepardus said:

That looks to be the default, which should give reasonable quality in most situations. Some especially busy visuals can cause the video encoding to suffer (FIREBLU is notorious for this), so maybe it's worth asking what specifically you're trying to render.

Ha, I think you are right, as i was previously trying to record a demo for e3m6 mt erebus map... Also. Is the viddumping process in itself hardware dependent?? meaning is the time taken (fast or slow) to complete it dependent on one's hardware. Cause I think a short 15 minutes demo should NOT take a whole 1.5 hrs to render.

As if that were the case, any large demo (1 hr or more) could take days to finish viddumping.

Viddump takes as long as it needs to render and encode each frame, so yes its speed depends on your hardware as well as the encoding settings. For what it's worth my own computer viddumps at about the same rate you stated, at least when I'm using CPU encoding. GPU encoding is significantly faster for me but I've yet to find settings that give me a quality/size tradeoff that I'm happy with.

Video compression algorithms aren't made for scenes like E3M6, so quality tends to suffer on them, as often seen on livestreams. To get something like that looking good you'll have to play around with the encoding settings, adjusting the bitrate or CRF or whatever to get better quality. I'm no expert at this but there's a bunch of material online on the subject, as it's not specific to Doom and FFmpeg is a widely used program. If you plan to upload your video to YouTube, you may also need to render your video at a higher resolution like 1440p or 4K (or upscale the video to that resolution before uploading), because YouTube will reencode the video and the encoding it uses depends on the resolution.

30 minutes ago, Shepardus said:

Viddump takes as long as it needs to render and encode each frame, so yes its speed depends on your hardware as well as the encoding settings. For what it's worth my own computer viddumps at about the same rate you stated, at least when I'm using CPU encoding. GPU encoding is significantly faster for me but I've yet to find settings that give me a quality/size tradeoff that I'm happy with.

 

Video compression algorithms aren't made for scenes like E3M6, so quality tends to suffer on them, as often seen on livestreams. To get something like that looking good you'll have to play around with the encoding settings, adjusting the bitrate or CRF or whatever to get better quality. I'm no expert at this but there's a bunch of material online on the subject, as it's not specific to Doom and FFmpeg is a widely used program. If you plan to upload your video to YouTube, you may also need to render your video at a higher resolution like 1440p or 4K (or upscale the video to that resolution before uploading), because YouTube will reencode the video and the encoding it uses depends on the resolution.

Yesterday i again tried to render the demo, this time at 1080p as you said before, and this time it took me a whole 5 hrs to fully render it... Atleast now it looked as i wanted it to look previously.

Resolution and bitrate are the two major factors that affect the definition of quality.

For excellent quality with x264¹ encoder, I'd recommend to use these settings :

Change the settings for a better quality audio and video :

Video capture encoding settings

`*cap_soundcommand* "ffmpeg -f s16le -ar 44100 -ac 2 -i - -c:a aac -q:a 2.0 -aac_coder twoloop -cutoff 0 -ar 48000 -ac 2 -y audio.m4a"`

`*cap_videocommand* "ffmpeg -f rawvideo -pix_fmt rgb24 -r %r -s %wx%h -i - -c:v libx264 -crf 18 -preset faster -pix_fmt yuv444p -y video.mp4"`

`*cap_muxcommand* "ffmpeg -i audio.m4a -i video.mp4 -c copy -y %f"`

`cap_tempfile1 "audio.m4a"`

`cap_tempfile2 "video.mp4"`

`cap_remove_tempfiles 1`

`cap_wipescreen 0`

`cap_fps 60`

dsda-doom.exe -timedemo nameofdemo -viddump outputvideo.mp4

Use these settings till you are encoding with a resolution of 2K. 

For 4K, I'd recommend to use VP9/Opus in a .webm container since libvpx-vp9 encoder provides 20-50% bitrate savings compared to libx264. ²

`*cap_soundcommand* "ffmpeg -f s16le -ar 44100 -ac 2 -i - -c:a libopus -vbr on -compression_level 10 -frame_duration 20 -b:a 320k -cutoff 0 -ar 48000 -ac 2 -y audio.opus"`

`*cap_videocommand* "ffmpeg -f rawvideo -pix_fmt rgb24 -r %r -s %wx%h -i - -c:v libvpx-vp9 -crf 0 -b:v 35000k -quality good -cpu-used 0 -lag-in-frames 25 -rc_lookahead 25 -pix_fmt yuv444p -y video.webm"`

`*cap_muxcommand* "ffmpeg -i audio.opus -i video.webm -c copy -y %f"`

`cap_tempfile1 "audio.opus"`

`cap_tempfile2 "video.webm"`

`cap_remove_tempfiles 1`

`cap_wipescreen 0`

`cap_fps 60`

dsda-doom.exe -timedemo nameofdemo -viddump outputvideo.webm

For future reference, check :

¹ https://trac.ffmpeg.org/wiki/Encode/H.264

² https://trac.ffmpeg.org/wiki/Encode/VP9

On 5/28/2024 at 7:56 AM, Keyboard Doomer said:

Resolution and bitrate are the two major factors that affect the definition of quality.

 

For excellent quality with x264¹ encoder, I'd recommend to use these settings :

 

Change the settings for a better quality audio and video :

 

Video capture encoding settings

 

`*cap_soundcommand* "ffmpeg -f s16le -ar 44100 -ac 2 -i - -c:a aac -q:a 2.0 -aac_coder twoloop -cutoff 0 -ar 48000 -ac 2 -y audio.m4a"`

 

`*cap_videocommand* "ffmpeg -f rawvideo -pix_fmt rgb24 -r %r -s %wx%h -i - -c:v libx264 -crf 18 -preset faster -pix_fmt yuv444p -y video.mp4"`

 

`*cap_muxcommand* "ffmpeg -i audio.m4a -i video.mp4 -c copy -y %f"`

 

`cap_tempfile1 "audio.m4a"`

 

`cap_tempfile2 "video.mp4"`

 

`cap_remove_tempfiles 1`

 

`cap_wipescreen 0`

 

`cap_fps 60`

 

dsda-doom.exe -timedemo nameofdemo -viddump outputvideo.mp4

 

 

Use these settings till you are encoding with a resolution of 2K. 

 

For 4K, I'd recommend to use VP9/Opus in a .webm container since libvpx-vp9 encoder provides 20-50% bitrate savings compared to libx264. ²

 

 

`*cap_soundcommand* "ffmpeg -f s16le -ar 44100 -ac 2 -i - -c:a libopus -vbr on -compression_level 10 -frame_duration 20 -b:a 320k -cutoff 0 -ar 48000 -ac 2 -y audio.opus"`

 

`*cap_videocommand* "ffmpeg -f rawvideo -pix_fmt rgb24 -r %r -s %wx%h -i - -c:v libvpx-vp9 -crf 0 -b:v 35000k -quality good -cpu-used 0 -lag-in-frames 25 -rc_lookahead 25 -pix_fmt yuv444p -y video.webm"`

 

`*cap_muxcommand* "ffmpeg -i audio.opus -i video.webm -c copy -y %f"`

 

`cap_tempfile1 "audio.opus"`

 

`cap_tempfile2 "video.webm"`

 

`cap_remove_tempfiles 1`

 

`cap_wipescreen 0`

 

`cap_fps 60`

 

dsda-doom.exe -timedemo nameofdemo -viddump outputvideo.webm

 

For future reference, check :

 

¹ https://trac.ffmpeg.org/wiki/Encode/H.264

 

² https://trac.ffmpeg.org/wiki/Encode/VP9

 

 

Will try this... Thanks!

On 6/3/2024 at 5:52 AM, Grassy chunks said:

Will try this... Thanks!

In case if the viddumps output in low quality for x264 encoder, then use " -preset medium " because as this is gaming content (content with high motion) which is "hard" to encode, faster presets may reduce the quality significantly, when compared to content which is "easy" to encode like drama content, or content with low motion content, so using slower preset like medium might be necessary, and I'd recommend to use preset medium, if you are creating videos for YouTube.

Watch the video.

So, yeah, " preset faster " is the first acceptable preset for general use, and it makes very less sense to go beyond medium.

On 3/29/2023 at 7:24 AM, Shepardus said:

That looks to be the default, which should give reasonable quality in most situations. Some especially busy visuals can cause the video encoding to suffer (FIREBLU is notorious for this), so maybe it's worth asking what specifically you're trying to render.

suffer in what case ? 

In terms of quality, encoding speed, or else ?

the quality is more dependent on the CRF value and resolution mainly. preset also determines quality but its a secondary factor. The default preset medium is best according to the test by Jan Ozer ( it produces optimal balance of video quality, filesize and encoding speed). But, CRF 23 ( which is default of x264 encoder), as you said, gives "good quality" for almost all situations, that's true, but CRF 17 or 18, is recommended if you want best quality, or if you want to upload it to YouTube, because YouTube does re-encode the video which we upload, and as this is lossy to lossy encoding, it degrades the video quality. This is also called Generation Loss.

On 3/30/2023 at 6:17 AM, Shepardus said:

Viddump takes as long as it needs to render and encode each frame, so yes its speed depends on your hardware as well as the encoding settings. For what it's worth my own computer viddumps at about the same rate you stated, at least when I'm using CPU encoding. GPU encoding is significantly faster for me but I've yet to find settings that give me a quality/size tradeoff that I'm happy with.

 

Video compression algorithms aren't made for scenes like E3M6, so quality tends to suffer on them, as often seen on livestreams. To get something like that looking good you'll have to play around with the encoding settings, adjusting the bitrate or CRF or whatever to get better quality. I'm no expert at this but there's a bunch of material online on the subject, as it's not specific to Doom and FFmpeg is a widely used program. If you plan to upload your video to YouTube, you may also need to render your video at a higher resolution like 1440p or 4K (or upscale the video to that resolution before uploading), because YouTube will reencode the video and the encoding it uses depends on the resolution.

Well, which codec and encoder of the codec you use for GPU encoding btw ?

(if you're using h264_qsv, then do you have some encoding settings of that encoder which will give a fine balance of video quality/filesize/encoding time ? )

28 minutes ago, Classic SSG Enjoyer said:

Well, which codec and encoder of the codec you use for GPU encoding btw ?

h264_nvenc

Haven't tweaked my settings in years, works well enough for me, and if anything goes wrong I just fall back to dsda-doom's defaults.

2 hours ago, Shepardus said:

h264_nvenc

Haven't tweaked my settings in years, works well enough for me, and if anything goes wrong I just fall back to dsda-doom's defaults.

good... 👍