
Good Quality DOSBox Video Capture and FFmpeg Options - susam
https://susam.in/blog/good-quality-dosbox-video-capture/
======
akx
There's a whole lot of additional subtlety to

> my contacts who might be on devices that do not support playing AVI files,
> so I decided to convert this to MP4 format

– a file being an AVI tells you practically nothing about the actual codecs
and streams contained within, and the same stands for MP4.

It seems DOSbox writes AVI files that contain video encoded in its own ZMBV
codec (see
[https://wiki.multimedia.cx/index.php/DosBox_Capture_Codec);](https://wiki.multimedia.cx/index.php/DosBox_Capture_Codec\);)
even if OP's contacts had devices that could play AVIs, it's likely they
couldn't play that AVI anyway...

    
    
        Input #0, avi, from 'dosbox_000.avi':
          Duration: 00:00:03.64, start: 0.000000, bitrate: 1532 kb/s
            Stream #0:0: Video: zmbv (ZMBV / 0x56424D5A), pal8, 640x400, 98 kb/s, 70.09 fps, 70.09 tbr, 70.09 tbn, 70.09 tbc
            Stream #0:1: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 44100 Hz, 2 channels, s16, 1411 kb/s

~~~
molticrystal
At the time of me writing this, you missed a space between the ");" and the
url for the dosbox codec.

For people on mobile/lazy:
[https://wiki.multimedia.cx/index.php/DosBox_Capture_Codec](https://wiki.multimedia.cx/index.php/DosBox_Capture_Codec)

\-----

For those interested in an even deeper dive:

Decoder:
[https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/zmbv...](https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/zmbv.c)

Encoder:
[https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/zmbv...](https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/zmbvenc.c)

This implementation was written almost immediately after dosbox added the
codec.

~~~
mkesper
How hard would it be to let dosbox emit a newer container format? I remember
AVI being quite bad re overhead.

~~~
akx
I think AVI is being used because it's apparently _very_ easy to write a valid
AVI file without extra libraries:

[https://github.com/svn2github/dosbox/blob/acd380bcde72db74f3...](https://github.com/svn2github/dosbox/blob/acd380bcde72db74f3b476253899016f686bc0ef/src/hardware/hardware.cpp#L132)

~~~
naikrovek
Old image and video formats are great if you want something quick and dirty.

------
fock
I went there, expecting some information how DOSBox was hacked to emulate some
old-fashioned CRT-visuals and output 4K-content. Got instructions on how to
convert AVI to another format with ffmpeg. Great!

~~~
vardump
It gets even pixel aspect ratio wrong, or rather, doesn't account for it in
any way.

In some modes, like 320x200, pixels are 20% taller than "normal" square
pixels. If you don't account for that, everything looks vertically squished.

~~~
neatcoder
Isn't that the right DOSBOX behavior? I think it should maintain the original
aspect ratio as it looked in the old CRT monitors. I remember drawing circles
in CRT monitors on IBM PCs and the circles did look vertically squished. Why
should DOSBOX or FFMPEG alter that original aspect ratio? Altering that
artificially would be like lying about what the real output looked like in the
good old days.

~~~
klodolph
If you use DOSBox with default settings, the pixel aspect ratio will be
square. Old PCs, as you remember, had non-square aspect ratios, and so the
graphics will look incorrect, they will look squashed horizontally.

~~~
susam
I am running DOSBox with default settings. I draw a square and then a circle
with these lines of Logo code:

    
    
      REPEAT 4 [FD 1 RT 90]
    
      REPEAT 360 [FD 1 RT 1]
    

I find that both the square and the circle appear squashed. On measuring the
pixel height and width of these figures as they appear on my desktop, I see
that the square is 400 pixels in width and 320 pixels in height. That's an
aspect ratio of 5:4. Similarly, the circle is 460 pixels in width and 364
pixels in height. That's an aspect ratio of 1.26:1.

I find the same aspect ratio in full screen (Alt + Enter) mode too. In the
full screen mode, the square is 200 pixels in width and 160 pixels in height
and the circle is 230 pixels in width and 182 pixels in height.

Here are the screenshots:

\- [https://imgur.com/l9YpTqp](https://imgur.com/l9YpTqp)

\- [https://imgur.com/WTwfSzq](https://imgur.com/WTwfSzq)

\- [https://imgur.com/CjMYJN6](https://imgur.com/CjMYJN6)

~~~
Crinus
Edit the dosbox configuration file and change aspect=0 to aspect=1, it'll
resize the output to be aspect correct but it might be a bit blurry (IIRC the
scale3x scaler will do a pixel-scale and then _that_ will be bilinearly
resized, giving mostly crispy pixels with a bit of in-between bleeding which
is probably the best you can get with an LCD monitor)

~~~
susam
With aspect=1, the square is 400 pixels high and 384 pixels wide, not exactly
an aspect ratio of 1:1 but quite close, 1.04:1.

The parent of my earlier comment, i.e., the one by klodolph, claims that the
pixel aspect ratio would be square by default in DOSBox, so I thought I would
verify it once. As per my experiments, that does not seem to be the case.

~~~
fireattack
I think what he meant is that,

The pixels are square in DOSBox, but the graphics from these old programs are
designed for non-square pixel ratio. So, if you display it with square pixel,
the display aspect ratio will be wrong.

(Of course, this still contradicts with what neatcoder said, but I can't
remember if these programs were "squished" on CRTs or not.)

~~~
susam
See these screenshots of SCREEN 2 in GW-BASIC running in DOSBox:

\- [https://imgur.com/NZUGL1e](https://imgur.com/NZUGL1e) (aspect=0)

\- [https://imgur.com/rnQOfA4](https://imgur.com/rnQOfA4) (aspect=1)

The one with aspect=1 looks very odd.

~~~
klodolph
The one with aspect=1 looks incorrectly configured.

There are a number of different graphics modes, they have different pixel
aspect ratios, you can also adjust the monitor, it is possible that back in
school you were using a different mode or a different monitor. I think there
are some other factors that can affect this.

~~~
susam
Back in school, I played with SCREEN 0, SCREEN 1, and SCREEN 2 documented in
the GW-BASIC user manual. Here's a copy:
[http://www.antonis.de/qbebooks/gwbasman/screens.html](http://www.antonis.de/qbebooks/gwbasman/screens.html)
.

The reason why I stick to aspect=0 (the DOSBox default) is that this is the
one that more closely reproduces the experience I had with the CRT monitors at
school. I agree that the actual monitor or the way it is configured could
affect the aspect ratio we observe. Perhaps ours was not adjusted to produce
1:1 square while working with IBM Logo. But it did produce 1:1 square with GW-
BASIC SCREEN 1 mode.

~~~
klodolph
CGA/EGA/VGA is supposed to have a pixel aspect ratio of 1:1.2 in 320x200 mode.
If you adjusted the monitor to give 1:1 square pixels, then this was unusual.

~~~
susam
I think I know why the screenshot for SCREEN mode looks odd with aspect=1. The
documentation at
[https://www.dosbox.com/wiki/Dosbox.conf](https://www.dosbox.com/wiki/Dosbox.conf)
mentions,

> Do aspect correction. It only affects non-square pixel modes like VGA Mode
> 13h, which has a resolution of 320x200 pixels and is used by many DOS games
> (DOOM, etc).

However SCREEN 2 mode of GW-BASIC has a resolution of 640x200 (
[http://www.antonis.de/qbebooks/gwbasman/screens.html](http://www.antonis.de/qbebooks/gwbasman/screens.html)
).

~~~
klodolph
That mode is also non-square, with an aspect of 0.6:1. The IBM PC and its
various video cards in the early days used a number of tricks to keep the cost
down, one of those tricks is to keep the horizontal and vertical sync signals
the same for different modes as much as possible. (Recently I’ve started to
appreciate just how many tricks they used to keep the cost down, without
sacrificing _hardware_ reliability in the process!)

For both 320x200 and 640x200, HSYNC ran at 15.75 kHz, VSYNC ran at 60 Hz. When
you go from 320x200 to 640x200, all that happens is the pixel clock (the rate
at which you read out from RAM) is doubled, so you get exactly two pixels
horizontally packed in where there used to be one pixel. The older hardware,
like EGA video cards, can only generate one other HSYNC speed: 21.8 kHz, for
special 350-line modes. When VGA came out, it doubled the HSYNC frequency and,
for these modes, would just read each row out twice.

[http://www.minuszerodegrees.net/video/bios_video_modes.htm](http://www.minuszerodegrees.net/video/bios_video_modes.htm)

So SCREEN 1 should have 1.2:1 ratio, and SCREEN 2 should have a 0.6:1 ratio.

One of the better ways to verify this kind of thing is to compare box art from
DOS video games to screenshots taken from DOSBox or sprites extracted from the
data files. You can see that the screenshots from DOSBox match the sprite
files, if you leave aspect unadjusted, but if you look at the box art from the
retail packaging, you will (often) see artwork and screenshots with the
correct aspect ratio, just like you see on real hardware.

Here's a DOOM Wiki page discussing it, with a number of pictures and sources:
[https://doom.fandom.com/wiki/Aspect_ratio](https://doom.fandom.com/wiki/Aspect_ratio)

------
izacus
Good guides except for one things - Constrained Baseline isn't a thing for
years now. Even Android 2.x devices supported at least Main profile, so I
strongly recommend NEVER using Baseline H.264 profile. Using it will
absolutely trash video quality at the same bitrate.

------
torgoguys
FWIW, I've found that for screen captures, doing a completely lossless capture
with FFMPEG often results in much smaller files. This is true mostly for
situations where there is a lot of duplicate frames, not high action video
games. And of course the quality can't be beat.

~~~
pjc50
> doing a completely lossless capture with FFMPEG

How? Are the iframes losslessly compressed? For some reason I thought they
were equivalent to JPEG.

~~~
sp332
If you configure the encoder for lossless compression (-crf 0) then it won't
quantize the image data. There might be rounding errors in the DCT, but it's
pretty close to lossless. And there might still be a loss of data in other
stages of processing, like converting RGB to YUV 4:2:0 or something.

[https://dsp.stackexchange.com/questions/27752/is-dct-
discret...](https://dsp.stackexchange.com/questions/27752/is-dct-discrete-
cosine-transform-of-type-2-lossless-or-lossy)

~~~
fireattack
So basically JPEG with 100% quality (a JPEG with all quantization table
factors being being 1).

I personally won't call it lossless then, since no one will call 100% JPEG
(even the 4:4:4 one) "lossless" (there is an entirely separate "true" lossless
JPEG that no one uses).

But I'm not trying to argue if it's the term H264/video codec community uses.

------
anc84
I recommend "-tune animation" for content like this.

Also I second izacus' "don't use baseline". I would even use a higher profile,
for quality's sake. For bad clients you would always convert content if
needed. Unless of course, you are one of those users constrained by them in
the first place.

------
grepgeek
Anyone knows what theme is used in this blog?

~~~
xtreak29
Seems to be based on this repo :
[https://github.com/susam/susam.in](https://github.com/susam/susam.in)

