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.

https://www.howtogeek.com/200736/what-is-an-m … -you-play-them/

>How Can I Play MKV Files?

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

Yeah, no.

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.

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

1		/* Everything went okay, set flag again for next frame */
2		CaptureState |= CAPTURE_VIDEO;
3		//Break AVI files at 1GB by resetting video stream
4		//UINT64 maxvideosize = 0x3FF00000ULL;
5		  
6		if ((uint64_t)capture.video.writer->riff->top->write_offset >= maxfilesizemb) {
7			LOG_MSG("Reset of captured video due to over maximum video size.");
8			goto skip_video;
9		}
10		
11	}
12
13	return;
14skip_video:
15	avi_writer_end_data(capture.video.writer);
16	avi_writer_finish(capture.video.writer);
17	avi_writer_close_file(capture.video.writer);
18	capture.video.writer = avi_writer_destroy(capture.video.writer);
19#endif
20	return;
21}

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.

option (on/off) to automatically release the mouse cursor when entering debugger.
now i have to press, debugger hotkey and then ctrl+f10 to get my mouse back.

thank you 😁

Or just set autolock to false.

Yeee, fastest implementation yet 😁

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:

1		Bit8u avi_header[AVI_HEADER_SIZE];
2		Bitu main_list;
3		Bitu header_pos=0;
4#define AVIOUT4(_S_) memcpy(&avi_header[header_pos],_S_,4);header_pos+=4;
5#define AVIOUTw(_S_) host_writew(&avi_header[header_pos], _S_);header_pos+=2;
6#define AVIOUTd(_S_) host_writed(&avi_header[header_pos], _S_);header_pos+=4;
7		/* Try and write an avi header */
8		AVIOUT4("RIFF");                    // Riff header 
9		AVIOUTd(AVI_HEADER_SIZE + capture.video.written - 8 + capture.video.indexused);
10		AVIOUT4("AVI ");
11		AVIOUT4("LIST");                    // List header
12		main_list = header_pos;
13		AVIOUTd(0);				            // TODO size of list
14		AVIOUT4("hdrl");
15
16		AVIOUT4("avih");
17		AVIOUTd(56);                         /* # of bytes to follow */
18		AVIOUTd((Bit32u)(1000000 / capture.video.fps));       /* Microseconds per frame */
19		AVIOUTd(0);
20		AVIOUTd(0);                         /* PaddingGranularity (whatever that might be) */
21		AVIOUTd(0x110);                     /* Flags,0x10 has index, 0x100 interleaved */
22		AVIOUTd(capture.video.frames);      /* TotalFrames */
23		AVIOUTd(0);                         /* InitialFrames */
24		AVIOUTd(2);                         /* Stream count */
25		AVIOUTd(0);                         /* SuggestedBufferSize */
26		AVIOUTd(capture.video.width);       /* Width */
27		AVIOUTd(capture.video.height);      /* Height */
28		AVIOUTd(0);                         /* TimeScale:  Unit used to measure time */
29		AVIOUTd(0);                         /* DataRate:   Data rate of playback     */
30		AVIOUTd(0);                         /* StartTime:  Starting time of AVI data */
31		AVIOUTd(0);                         /* DataLength: Size of AVI data chunk    */
32
33		/* Video stream list */
34		AVIOUT4("LIST");
35		AVIOUTd(4 + 8 + 56 + 8 + 40);       /* Size of the list */
36		AVIOUT4("strl");
37		/* video stream header */
38        AVIOUT4("strh");
39		AVIOUTd(56);                        /* # of bytes to follow */
40		AVIOUT4("vids");                    /* Type */
41		AVIOUT4(CODEC_4CC);		            /* Handler */
42		AVIOUTd(0);                         /* Flags */
43		AVIOUTd(0);                         /* Reserved, MS says: wPriority, wLanguage */
44		AVIOUTd(0);                         /* InitialFrames */
45		AVIOUTd(1000000);                   /* Scale */
46		AVIOUTd((Bit32u)(1000000 * capture.video.fps));              /* Rate: Rate/Scale == samples/second */
47		AVIOUTd(0);                         /* Start */
48		AVIOUTd(capture.video.frames);      /* Length */
49		AVIOUTd(0);                  /* SuggestedBufferSize */
50		AVIOUTd(~0);                 /* Quality */
51		AVIOUTd(0);                  /* SampleSize */
52		AVIOUTd(0);                  /* Frame */
53		AVIOUTd(0);                  /* Frame */
54		/* The video stream format */
55		AVIOUT4("strf");
56		AVIOUTd(40);                 /* # of bytes to follow */
57		AVIOUTd(40);                 /* Size */
58		AVIOUTd(capture.video.width);         /* Width */
59		AVIOUTd(capture.video.height);        /* Height */
60//		OUTSHRT(1); OUTSHRT(24);     /* Planes, Count */

61		AVIOUTd(0);
62		AVIOUT4(CODEC_4CC);          /* Compression */
63		AVIOUTd(capture.video.width * capture.video.height*4);  /* SizeImage (in bytes?) */
64		AVIOUTd(0);                  /* XPelsPerMeter */
65		AVIOUTd(0);                  /* YPelsPerMeter */
66		AVIOUTd(0);                  /* ClrUsed: Number of colors used */
67		AVIOUTd(0);                  /* ClrImportant: Number of colors important */
68
69		/* Audio stream list */
70		AVIOUT4("LIST");
71		AVIOUTd(4 + 8 + 56 + 8 + 16);  /* Length of list in bytes */
72		AVIOUT4("strl");
73		/* The audio stream header */
74		AVIOUT4("strh");
75		AVIOUTd(56);            /* # of bytes to follow */
76		AVIOUT4("auds");
77		AVIOUTd(0);             /* Format (Optionally) */
78		AVIOUTd(0);             /* Flags */
79		AVIOUTd(0);             /* Reserved, MS says: wPriority, wLanguage */
80		AVIOUTd(0);             /* InitialFrames */
81		AVIOUTd(4);    /* Scale */
82		AVIOUTd(capture.video.audiorate*4);             /* Rate, actual rate is scale/rate */
83		AVIOUTd(0);             /* Start */
84		if (!capture.video.audiorate)
85			capture.video.audiorate = 1;
86		AVIOUTd(capture.video.audiowritten/4);   /* Length */
87		AVIOUTd(0);             /* SuggestedBufferSize */
88		AVIOUTd(~0);            /* Quality */
89		AVIOUTd(4);				/* SampleSize */
90		AVIOUTd(0);             /* Frame */
91		AVIOUTd(0);             /* Frame */
92		/* The audio stream format */
93		AVIOUT4("strf");
94		AVIOUTd(16);            /* # of bytes to follow */
95		AVIOUTw(1);             /* Format, WAVE_ZMBV_FORMAT_PCM */
96		AVIOUTw(2);             /* Number of channels */
97		AVIOUTd(capture.video.audiorate);          /* SamplesPerSec */
98		AVIOUTd(capture.video.audiorate*4);        /* AvgBytesPerSec*/
99		AVIOUTw(4);             /* BlockAlign */
100		AVIOUTw(16);            /* BitsPerSample */
101		int nmain = header_pos - main_list - 4;
102		/* 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.

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.

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?

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?

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.

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)

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

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.

What game needs this?

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.

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

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.

It's generally better to use direct serial connection (with DOSBox set to nullmodem) instead of modem if a game supports it.