VOGONS

Common searches


DOSBox Feature Request Thread

Topic actions

Reply 220 of 256, by junglemontana

User metadata
Rank Newbie
Rank
Newbie
Kisai wrote:

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.

Reply 222 of 256, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 223 of 256, by Kisai

User metadata
Rank Member
Rank
Member
jmarsh wrote:

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

		/* 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.

Reply 227 of 256, by Grunt

User metadata
Rank Newbie
Rank
Newbie
Kisai wrote:

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.

Heretical idea: It is really necessary to fit recorded video into AVI? Cannot be fitted in RAW form (or ZMBV form or whatever it is) directly into some pipe with ffmpeg on another side of pipe? Today multicore computers can recode video on-the-fly withou hiccups.
Just look at it:

		Bit8u avi_header[AVI_HEADER_SIZE];
Bitu main_list;
Bitu header_pos=0;
#define AVIOUT4(_S_) memcpy(&avi_header[header_pos],_S_,4);header_pos+=4;
#define AVIOUTw(_S_) host_writew(&avi_header[header_pos], _S_);header_pos+=2;
#define AVIOUTd(_S_) host_writed(&avi_header[header_pos], _S_);header_pos+=4;
/* Try and write an avi header */
AVIOUT4("RIFF"); // Riff header
AVIOUTd(AVI_HEADER_SIZE + capture.video.written - 8 + capture.video.indexused);
AVIOUT4("AVI ");
AVIOUT4("LIST"); // List header
main_list = header_pos;
AVIOUTd(0); // TODO size of list
AVIOUT4("hdrl");

AVIOUT4("avih");
AVIOUTd(56); /* # of bytes to follow */
AVIOUTd((Bit32u)(1000000 / capture.video.fps)); /* Microseconds per frame */
AVIOUTd(0);
AVIOUTd(0); /* PaddingGranularity (whatever that might be) */
AVIOUTd(0x110); /* Flags,0x10 has index, 0x100 interleaved */
AVIOUTd(capture.video.frames); /* TotalFrames */
AVIOUTd(0); /* InitialFrames */
AVIOUTd(2); /* Stream count */
AVIOUTd(0); /* SuggestedBufferSize */
AVIOUTd(capture.video.width); /* Width */
AVIOUTd(capture.video.height); /* Height */
AVIOUTd(0); /* TimeScale: Unit used to measure time */
AVIOUTd(0); /* DataRate: Data rate of playback */
AVIOUTd(0); /* StartTime: Starting time of AVI data */
AVIOUTd(0); /* DataLength: Size of AVI data chunk */

/* Video stream list */
AVIOUT4("LIST");
AVIOUTd(4 + 8 + 56 + 8 + 40); /* Size of the list */
AVIOUT4("strl");
/* video stream header */
AVIOUT4("strh");
AVIOUTd(56); /* # of bytes to follow */
AVIOUT4("vids"); /* Type */
AVIOUT4(CODEC_4CC); /* Handler */
AVIOUTd(0); /* Flags */
AVIOUTd(0); /* Reserved, MS says: wPriority, wLanguage */
AVIOUTd(0); /* InitialFrames */
AVIOUTd(1000000); /* Scale */
AVIOUTd((Bit32u)(1000000 * capture.video.fps)); /* Rate: Rate/Scale == samples/second */
AVIOUTd(0); /* Start */
AVIOUTd(capture.video.frames); /* Length */
AVIOUTd(0); /* SuggestedBufferSize */
AVIOUTd(~0); /* Quality */
AVIOUTd(0); /* SampleSize */
AVIOUTd(0); /* Frame */
AVIOUTd(0); /* Frame */
/* The video stream format */
AVIOUT4("strf");
AVIOUTd(40); /* # of bytes to follow */
AVIOUTd(40); /* Size */
AVIOUTd(capture.video.width); /* Width */
AVIOUTd(capture.video.height); /* Height */
// OUTSHRT(1); OUTSHRT(24); /* Planes, Count */
Show last 42 lines
		AVIOUTd(0);
AVIOUT4(CODEC_4CC); /* Compression */
AVIOUTd(capture.video.width * capture.video.height*4); /* SizeImage (in bytes?) */
AVIOUTd(0); /* XPelsPerMeter */
AVIOUTd(0); /* YPelsPerMeter */
AVIOUTd(0); /* ClrUsed: Number of colors used */
AVIOUTd(0); /* ClrImportant: Number of colors important */

/* Audio stream list */
AVIOUT4("LIST");
AVIOUTd(4 + 8 + 56 + 8 + 16); /* Length of list in bytes */
AVIOUT4("strl");
/* The audio stream header */
AVIOUT4("strh");
AVIOUTd(56); /* # of bytes to follow */
AVIOUT4("auds");
AVIOUTd(0); /* Format (Optionally) */
AVIOUTd(0); /* Flags */
AVIOUTd(0); /* Reserved, MS says: wPriority, wLanguage */
AVIOUTd(0); /* InitialFrames */
AVIOUTd(4); /* Scale */
AVIOUTd(capture.video.audiorate*4); /* Rate, actual rate is scale/rate */
AVIOUTd(0); /* Start */
if (!capture.video.audiorate)
capture.video.audiorate = 1;
AVIOUTd(capture.video.audiowritten/4); /* Length */
AVIOUTd(0); /* SuggestedBufferSize */
AVIOUTd(~0); /* Quality */
AVIOUTd(4); /* SampleSize */
AVIOUTd(0); /* Frame */
AVIOUTd(0); /* Frame */
/* The audio stream format */
AVIOUT4("strf");
AVIOUTd(16); /* # of bytes to follow */
AVIOUTw(1); /* Format, WAVE_ZMBV_FORMAT_PCM */
AVIOUTw(2); /* Number of channels */
AVIOUTd(capture.video.audiorate); /* SamplesPerSec */
AVIOUTd(capture.video.audiorate*4); /* AvgBytesPerSec*/
AVIOUTw(4); /* BlockAlign */
AVIOUTw(16); /* BitsPerSample */
int nmain = header_pos - main_list - 4;
/* Finish stream list, i.e. put number of bytes in the list to proper pos */

Bonus:

  • No 2GB filesize limit
  • No waiting for encoding into different format
  • Pipe closed? No data? No problem for ffmpeg.

BTW: Where exactly goes MIDI data when recording? Video recording works perfectly but is without music. Just Sound Blaster.

Reply 228 of 256, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie

You couldn't just shove frames down a pipe, you'd need some way to communicate the frame rate/sampling rate, resolution, frame delimiters... once you've done all that you've basically recreated AVI.

DOSBox only records audio that goes through its mixer, if you're using an external midi device the output won't be recorded.

Reply 229 of 256, by Grunt

User metadata
Rank Newbie
Rank
Newbie
jmarsh wrote:

You couldn't just shove frames down a pipe,

Of course you could. See yuv4mpegpipe. Unfortunately every possible YUV pix_fmt but not a one RGB. And no rgb4mpegpipe either. I'll look into it.

jmarsh wrote:

DOSBox only records audio that goes through its mixer, if you're using an external midi device the output won't be recorded.

Oh, so what I hear is output from Windows MIDI mapper and isn't recorded into AVI?

Reply 231 of 256, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie
Kisai wrote:

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.

I'm currently reworking the AVI code to basically do the same thing (switch to a new file when approaching 2GB). At first I considered supporting OpenDML/AVI2.0 but it's a can of worms:
- requires cross-platform support for large (>2GB) file I/O
- requires detection of host filesystem limits (e.g. FAT32 only supports filesize up to 4GB)
- doesn't solve the issue of metadata needing to be written out at closing time to ensure the file is usable
- short captures have a lot of extra overhead
So the idea of OpenDML went in the bin.

What is possible though, is changing the current code to write all the headers when the file is created (with placeholder values for things like total frames, length, etc.) so that if DOSBox dies unexpectedly the capture will still be usable even without an index. Seeking will be slow and the keyframe flags are lost, but it's better than nothing.

Reply 232 of 256, by FulValBot

User metadata
Rank Newbie
Rank
Newbie
petran79 wrote:

Is it possible to add support for refresh rates higher than 60 hz? DOS games played up to 70hz in some games. Also can DOSBOX take advantage of Gsync/Freesync like WinUAE does?

I'm using DOSBox 0.74-3 with a 144hz of refresh rate without problems, but i have disabled all scaling mode in nvidia control panel... so i think that it works already with high refresh rate (i don't know if is a windows 7 problem)

Reply 233 of 256, by Tertz

User metadata
Rank Oldbie
Rank
Oldbie

Monochrome CGA mode (where any CGA app can be displayed so) in different colors: amber, green, b/w
an example of a PC with amber CGA.
An example of the patch, which is also used in ykhwong's builds.
There was an utilite for the similar.

the original CGA colors look worse sometimes than in monochrome shades mode

Last edited by Tertz on 2020-05-13, 14:25. Edited 2 times in total.

DOSBox CPU Benchmark
Yamaha YMF7x4 Guide

Reply 234 of 256, by Nicknine

User metadata
Rank Newbie
Rank
Newbie

I think DosBox could use some kind of "phonebook" feature that would essentially map fake phone numbers to addresses. This would help games where input field does not allow non-numeric symbols and/or is too small for IP address.

Reply 236 of 256, by Nicknine

User metadata
Rank Newbie
Rank
Newbie
Dominus wrote on 2020-02-25, 07:59:

What game needs this?

Doom setup program only allows 11 characters which is not enough for IP. Granted, you can bypass this by running SERSETUP directly but it's still somewhat annoying. Quake, The Need for Speed: SE and a bunch of other games have an input field that is too short to enter IP with a custom port.

Reply 237 of 256, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Don't they have an ini file or so you can edit? Might be important to know if they even work with a custom port.
Adding something like this would be fruitless otherwise

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox

Reply 238 of 256, by Nicknine

User metadata
Rank Newbie
Rank
Newbie
Dominus wrote on 2020-02-25, 08:08:

Don't they have an ini file or so you can edit? Might be important to know if they even work with a custom port.
Adding something like this would be fruitless otherwise

Quake doesn't have a phonebook. The Need for Speed: SE does but it's stored in binary so it's not easily editable.

Might be important to know if they even work with a custom port.

Resolving hostnames/addresses is handled entirely by DosBox virtual modem, the software doesn't care what you send to the modem in ATD command.