> 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...
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.
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!
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.
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:
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.
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.
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.
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 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.
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.
> 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).
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.
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.
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.
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.
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 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.
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); even if OP's contacts had devices that could play AVIs, it's likely they couldn't play that AVI anyway...
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.
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...
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.
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.
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 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/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.
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.
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.)
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.
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.
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.
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.
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 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 ).
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
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
good CRT monitors would auto-sync and get the aspect ratio right.
> 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.
If it looked squished on those CRTs, they were probably badly mis-configured.
Here's an update: I have updated the images and the video capture in the post so that the figures do not look vertically squished anymore.
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.
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...
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.
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.
Anyone knows what theme is used in this blog?
Seems to be based on this repo : https://github.com/susam/susam.in