DOSBox Feature Request Thread

[junglemontana]

There is a feature in dosbox-x that should be backported to dosbox. OpenDML (AVI 2.0) avi support. I actually have a diff between r4000 and dosbox-x's files for that somewhere, but basically the issue is that if you're recording the video using the internal recording mechanism, if it hits the file size limit (2GB), the avi file is completely unusable. I originally worked around it just by having it stop and immediately restart the recording every X frames, which was more of a bandaid workaround than a true fix.

Unfortunately that diff is against an older version of dosbox, and not vanilla dosbox. Not a trivial change, but it touches the avi writer and wav writer in the process.

I agree that this would be useful. However, a modern format such as MKV would be even better.

[awgamer]

https://www.howtogeek.com/200736/what-i ... play-them/

>How Can I Play MKV Files?

>Because MKV isn’t an industry standard, not all media players support it..

Yeah, no.

[jmarsh]

Most DOSBox recordings need to be edited afterwards and there's not a lot of support for editing Matroska, plus the only way to store ZMBV data in it would be to use VFW codec mode which gives no benefits over AVI.

[Kisai]

Most DOSBox recordings need to be edited afterwards and there's not a lot of support for editing Matroska, plus the only way to store ZMBV data in it would be to use VFW codec mode which gives no benefits over AVI.

I looked at this and other containers before and basically only VFW AVI is suitable to store dosbox data because it's frame-based. OpenDML just works-around the signed 32-bit file size (2GB) by just making additional indexes more or less. The dosbox-x code (at least 32-bit) seems to solve the "dosbox has overflowed the 2GB limit" by instead just making everything after 2GB quasi-playable (eg you can't seek to it, and ffmpeg can't read it past 2GB and assume it ends at 2GB.) Not really that much of an improvement, but better than the status quo which makes the entire video unusable the second it hits 2GB. So it's still buggy. I did however make an improvement to the original work around in this case

Note this is using the dosbox-x opendml code already applied, but this is essentially how I solve the file size limit

Code: Select all

      /* Everything went okay, set flag again for next frame */
      CaptureState |= CAPTURE_VIDEO;
      //Break AVI files at 1GB by resetting video stream
      //UINT64 maxvideosize = 0x3FF00000ULL;
       
      if ((uint64_t)capture.video.writer->riff->top->write_offset >= maxfilesizemb) {
         LOG_MSG("Reset of captured video due to over maximum video size.");
         goto skip_video;
      }
      
   }

   return;
skip_video:
   avi_writer_end_data(capture.video.writer);
   avi_writer_finish(capture.video.writer);
   avi_writer_close_file(capture.video.writer);
   capture.video.writer = avi_writer_destroy(capture.video.writer);
#endif
   return;
}

Basically telling dosbox to close the capture as soon as it's near 2GB (in this case I used 1GB just to make the file sizes more manageable) by a configuration variable. Because the flag isn't reset, Dosbox opens a new file at the next frame, thus no capture data is lost and is essentially identical to hitting the capture button twice at the end of the same frame.

Another thing that does need to happen, but this requires making a different change to dosbox that I haven't looked into, is to make sure that the video is properly closed when dosbox is closed, because that's the other reason why the video ends up unusable.