Open chungy opened 2 months ago
This is deliberate, and yes, a lot of video software refuses to process non-multiple of 4 dimensions. It's good as a default, but unfortunately no option is available to override it.
src/lib/util/aviio.cpp
/**
* @def AVI_INTEGRAL_MULTIPLE
*
* @brief Ensures the integral multiple of the video dimension, because most video players are not capable to playback a video stream with a lower multiple.
*/
static constexpr int AVI_INTEGRAL_MULTIPLE = 4;
This is deliberate, and yes, a lot of video software refuses to process non-multiple of 4 dimensions. It's good as a default, but unfortunately no option is available to override it.
I'm not sure what makes this "good as a default"; because some software is buggy? Not sure what qualifies as "a lot of video software" either. The test file generated by ffmpeg plays back in everything I've tried (but maybe related to me being on Linux, where most everything is linked to ffmpeg anyhow), and obviously ffmpeg itself handles it.
At any rate, I feel like -aviwrite is a good intermediate to get raw pixels out of a system at the proper framerate and everything. Perhaps massaging the data to fit future constraints is desirable in some use cases (eg, re-encoding it to AV1), but that's easy to handle in post-processing the video, by padding, scaling, whatever is a good idea. Sometimes I've also used aviwrite just to assist in getting screenshots, since it makes it easier to go forward and backward on a frame-by-frame basis, and MAME writing it out guarantees that every frame is as the emulated system draws it.
Anyhow, editing the source at least outputs the video at the desired dimensions, but it's still getting bilinear filtering applied and not the crispy pixels that I really want. Setting -nosnapbilinear
doesn't help, it just causes uneven pixels, with some of the rows not even coming out in the output. Notably the uneven pixels even happens if I use -nosnapbilinear -snapsize $((447*4))x$((257*4))
; though at least at that size, it's possible to write a program to extract the proper raw pixels and get it back to the original size. Maybe there's two bugs here.
MAME version
mame0269-234-g233a5e82799
System information
Arch Linux, x86-64, 64GB system RAM
INI configuration details
Emulated system/software
x1 smbsp
Incorrect behaviour
The game runs at 447x257, making it impossible to capture a clean video with all pixels intact, no more or less. The system starts up at 640x480 and as such, aviwrite will start out writing a file with these parameters, but the game display remains blurry and scaled.
Running MAME with
mame x1 smbsp -snapsize 447x257 -aviwrite smbsp
will cause the emulator to instead output a file with dimensions 444x256, notably the next step downwards to multiple-of-4 dimensions.Expected behaviour
The AVI file be accurately written at 447x257. While these are unusual dimensions and most intraframe codecs (eg, H.264, AV1) require either multiple-of-2 or multiple-of-4 dimensions, MAME dumps out rawvideo in an AVI container and should not be subject to the same limitation.
ffmpeg, for example, can generate such an example file:
ffmpeg -f lavfi -i testsrc=s=447x257 -t 10 -c:v rawvideo test.avi
Steps to reproduce
mame x1 smbsp -aviwrite smbsp.avi -snapsize 447x257 -seconds_to_run 30 -nothrottle
ffprobe ~/.mame/snap/smbsp.avi
mpv --scale=oversample ~/.mame/snap/smbsp.avi
Additional details
No response