6 ms·

Good Quality DOSBox Video Capture and FFmpeg Options

80 points by susam 7y ago

fock 7y ago
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 7y ago
  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 7y ago
    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 7y ago
      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 7y ago
        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 7y ago
        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 7y ago
        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 7y ago
        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 7y ago
        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 7y ago
        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.
    - NikkiA 7y ago
      good CRT monitors would auto-sync and get the aspect ratio right.
  - susam 7y ago
    > 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.
    - Narishma 7y ago
      If it looked squished on those CRTs, they were probably badly mis-configured.
    - susam 7y ago
      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.
grepgeek 7y ago
Anyone knows what theme is used in this blog?
- xtreak29 7y ago
  Seems to be based on this repo : https://github.com/susam/susam.in https://github.com/susam/susam.in
izacus 7y ago
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 7y ago
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 7y ago
  > doing a completely lossless capture with FFMPEG How? Are the iframes losslessly compressed? For some reason I thought they were equivalent to JPEG.
  - sp332 7y ago
    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-discrete-cosine-transform-of-type-2-lossless-or-lossy https://dsp.stackexchange.com/questions/27752/is-dct-discret...
    - Wowfunhappy 7y ago
      Just a quick thing worth noting, a lot of conventional players won't open lossless h264 content. QuickTime being one example.
    - fireattack 7y ago
      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.
  - pkroll 7y ago
    FFMPEG can use a variety of codecs, several of which provide actual lossless compression: https://ffmpeg.org/ffmpeg-codecs.htmlhttps://ffmpeg.org/ffmpeg-codecs.html#Video-Encoders https://ffmpeg.org/ffmpeg-codecs.htmlhttps://ffmpeg.org/ffmp...
anc84 7y ago
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.
akx 7y ago
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 7y ago
  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.c https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/zmbv... Encoder: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/zmbvenc.c https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/zmbv... This implementation was written almost immediately after dosbox added the codec.
  - mkesper 7y ago
    How hard would it be to let dosbox emit a newer container format? I remember AVI being quite bad re overhead.
    - tracker1 7y ago
      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.

80 points by susam 7y ago

fock 7y ago

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 7y ago
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 7y ago
  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 7y ago
    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 7y ago
      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 7y ago
        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 7y ago
        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 7y ago
        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 7y ago
        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 7y ago
        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.
  - NikkiA 7y ago
    good CRT monitors would auto-sync and get the aspect ratio right.
- susam 7y ago
  > 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.
  - Narishma 7y ago
    If it looked squished on those CRTs, they were probably badly mis-configured.
  - susam 7y ago
    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.

grepgeek 7y ago

Anyone knows what theme is used in this blog?

xtreak29 7y ago
Seems to be based on this repo : https://github.com/susam/susam.in https://github.com/susam/susam.in

izacus 7y ago

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 7y ago

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 7y ago
> doing a completely lossless capture with FFMPEG How? Are the iframes losslessly compressed? For some reason I thought they were equivalent to JPEG.
- sp332 7y ago
  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-discrete-cosine-transform-of-type-2-lossless-or-lossy https://dsp.stackexchange.com/questions/27752/is-dct-discret...
  - Wowfunhappy 7y ago
    Just a quick thing worth noting, a lot of conventional players won't open lossless h264 content. QuickTime being one example.
  - fireattack 7y ago
    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.
- pkroll 7y ago
  FFMPEG can use a variety of codecs, several of which provide actual lossless compression: https://ffmpeg.org/ffmpeg-codecs.htmlhttps://ffmpeg.org/ffmpeg-codecs.html#Video-Encoders https://ffmpeg.org/ffmpeg-codecs.htmlhttps://ffmpeg.org/ffmp...

anc84 7y ago

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.

akx 7y ago

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 7y ago
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.c https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/zmbv... Encoder: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/zmbvenc.c https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/zmbv... This implementation was written almost immediately after dosbox added the codec.
- mkesper 7y ago
  How hard would it be to let dosbox emit a newer container format? I remember AVI being quite bad re overhead.
  - tracker1 7y ago
    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.