Good Quality DOSBox Video Capture and FFmpeg Options(susam.in)
susam.in
Good Quality DOSBox Video Capture and FFmpeg Options
https://susam.in/blog/good-quality-dosbox-video-capture/
34 comments
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
-----
For those interested in an even deeper dive:
Decoder: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/zmbv...
Encoder: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/zmbv...
This implementation was written almost immediately after dosbox added the codec.
For people on mobile/lazy: 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...
Encoder: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/zmbv...
This implementation was written almost immediately after dosbox added the codec.
How hard would it be to let dosbox emit a newer container format? I remember AVI being quite bad re overhead.
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/acd380bcde72db74f3...
Old image and video formats are great if you want something quick and dirty.
Is it the write overhead and/or read overhead... I don't know in this case, but it can really vary. Also, depending on the hardware and what's running inside dosbox, most current hardware for at least half a decade should be able to keep up fine. More so on SSD.
Ah, sorry about that. Seems I also missed the window for editing my post. Thanks for the correct link!
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!
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.
In some modes, like 320x200, pixels are 20% taller than "normal" square pixels. If you don't account for that, everything looks vertically squished.
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.
good CRT monitors would auto-sync and get the aspect ratio right.
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.
I am running DOSBox with default settings. I draw a square and then a circle with these lines of Logo code:
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/WTwfSzq
- https://imgur.com/CjMYJN6
REPEAT 4 [FD 1 RT 90]
REPEAT 360 [FD 1 RT 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/WTwfSzq
- https://imgur.com/CjMYJN6
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)
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.
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.
This is a misinterpretation of the experiment results.
By default, aspect=false. This gives incorrect results, as you observed, with Logo producing a squashed circle and square.
The fix is aspect=true (or aspect=1). This gives correct results, with non-square aspect for pixels, with Logo producing a more correct circle and square.
Because the Logo implementation was written for an actual IBM PC or compatible, it assumes that the aspect ratio of a 320x200 pixel screen is about 4:3. However, when displayed with the incorrect square-pixel aspect ratio given by default in DOSBox, it will be 8:5.
In other words, DOSBox displays graphics with a square pixel ratio by default, which is different from the original hardware. If you wrote a DOS program to draw a square number of pixels, say 128x128, then you would see that in DOSBox it would also be square, but on real hardware it would be about 20% taller than it is wide. If you use Logo you will get the opposite results, because Logo is correctly designed for the original hardware.
By default, aspect=false. This gives incorrect results, as you observed, with Logo producing a squashed circle and square.
The fix is aspect=true (or aspect=1). This gives correct results, with non-square aspect for pixels, with Logo producing a more correct circle and square.
Because the Logo implementation was written for an actual IBM PC or compatible, it assumes that the aspect ratio of a 320x200 pixel screen is about 4:3. However, when displayed with the incorrect square-pixel aspect ratio given by default in DOSBox, it will be 8:5.
In other words, DOSBox displays graphics with a square pixel ratio by default, which is different from the original hardware. If you wrote a DOS program to draw a square number of pixels, say 128x128, then you would see that in DOSBox it would also be square, but on real hardware it would be about 20% taller than it is wide. If you use Logo you will get the opposite results, because Logo is correctly designed for the original hardware.
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.)
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.)
See these screenshots of SCREEN 2 in GW-BASIC running in DOSBox:
- https://imgur.com/NZUGL1e (aspect=0)
- https://imgur.com/rnQOfA4 (aspect=1)
The one with aspect=1 looks very odd.
- https://imgur.com/NZUGL1e (aspect=0)
- https://imgur.com/rnQOfA4 (aspect=1)
The one with aspect=1 looks very odd.
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.
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.
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 .
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.
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.
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.
> It gets even pixel aspect ratio wrong, or rather, doesn't account for it in any way.
You are right. I did not account for the aspect ratio. I will consider fixing the aspect ratio and updating the images.
You are right. I did not account for the aspect ratio. I will consider fixing the aspect ratio and updating the images.
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.
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.
> doing a completely lossless capture with FFMPEG
How? Are the iframes losslessly compressed? For some reason I thought they were equivalent to JPEG.
How? Are the iframes losslessly compressed? For some reason I thought they were equivalent to JPEG.
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-discret...
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.
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.
Just a quick thing worth noting, a lot of conventional players won't open lossless h264 content. QuickTime being one example.
FFMPEG can use a variety of codecs, several of which provide actual lossless compression: https://ffmpeg.org/ffmpeg-codecs.htmlhttps://ffmpeg.org/ffmp...
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.
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.
Anyone knows what theme is used in this blog?
Seems to be based on this repo : https://github.com/susam/susam.in
> 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); even if OP's contacts had devices that could play AVIs, it's likely they couldn't play that AVI anyway...