I’ve never met Ian Albert, but years ago he painstakingly scraped and pasted together a set of maps and backgrounds from a various oldschool games, an effort that’s helped me in a bunch of odd little ways over the years and for which I’m grateful. Of particular interest today are the original Super Mario Brothers maps; for the sake of this exercise, let’s start with world 1, level 1.
ImageMagick and FFMpeg are a pair of “classically-Linux” command-line tools, in terms of how insanely complex and opaque they appear until you’ve worked with them for a bit and can sort of see the logic of their approaches. Even then the documentation takes some getting used to – the man page should just say “don’t bother, go to the website” – and even then you’ve gotta kind of fumble your way towards competence if you want to use them day to day.
Well, maybe you don’t, but I sure do. In any case once you know they exist you muddle your way to doing a lot with them. In particular, “convert” from the ImageMagick tool suite lets you upscale some of those Mario-level gifs to PNGs, like so:
$> convert mario-1-1.gif -scale 300% mario-1-1.png
We’re doing this conversion because FFMpeg (apparently?) doesn’t like to pan over gifs as an input stream but is happy to do that with PNGs, and scaling it up gets you an image size better suited for modern screens. We’re admittedly scaling up and then compressing something that eventually gets upscaled again, which looks like it should bea waste of effort. I’ve tested it, though, and on this machine at least it looks like movie upscaling comes out a lot mushier than static image upscaling and this approach is quite a bit crisper.
In any case, then you run “file” on that resulting image to see how big it is:
$> file ./mario-1-1.png
./mario-1-1.png: PNG image data, 10152 x 672, 4-bit colormap, non-interlaced
Do a bit of loose math to figure out your frame width and subtract 16/9 * 672 – that is, the aspect ration of your monitor times the height of the image – from the length – to get the number you need to work with next – in my case rounding to 1200, it’s 8952.
That’s the number of frames you’re going to tell FFMpeg to pan across, like so:
$> ffmpeg -loop 1 -framerate 5 -i mario-1-1.png -vf crop=1200:672:n:0 -frames:v 8952 -pix_fmt yuv420p mario-1-1.mp4
Now, order of operations and operation context both matters in FFMpeg usage, which adds a degree of complexity to figuring out wtf you’re doing with it, but walking through that command:
the “-loop” option is specific to the image processing part of ffpmeg, and in turn specific to some image-processing formats, so “loop 1” might or might not error out saying “unrecognized option”, depending on where you put it in the command line and which image types you’re choosing to process, which is not super helpful. In this case, it works for .png input files, and it means “go through this set of input images once”. We’ll get back to “-framerate” in a moment.
“-i” is input the png of the mario level we made earlier. The rest of this command is where the proverbial action is.
“-vf” means “create a filtergraph”, which is FFMpeg-ese for “transform the set of input images you’ve decoded in the following way”. “The following” can get pretty crazy, as you might imagine, but fortunately for us this will be reasonably simple in intent, despite the somewhat daunting syntax.
In this case, it means “crop out a sub-image from the given input image, of with 1200 and height 672, starting at horizontal offset “n” and vertical offset 0. “n” in this case is implicitly provided by the “frames” part, as we iterate over the frames from zero to the value of “-frames:v”
The “-pix_fmt yuv420p” part – “pixel format”, is what that means – I don’t really understand, beyond the fact that FFMpeg can encode videos in way more formats than browsers can easily decode, and its’ default idea of “best” doesn’t work everywhere. This incantation seems to fix that, which isn’t particularly satisfying but is definitely part of the whole fumbling-towards-competence part I mentioned.
In any case, the “-framerate 5” part is the interesting bit. That’s there because about nine thousand frames – 8952 specifically – divided by the number of seconds in a 30 minute meeting is very close to five. Five frames per second is really slow, so the resulting output video is, as predicted by our basic arithmetic, a lazy 29 minutes and 50 seconds long:
… and that’s the story of how you make a videoconference background that scrolls slowly through a Mario level over the course of half an hour.
A few notes:
- If you leave out the framerate option and just want to see it scroll by at a default 25 frames per second, the movie is five minutes and change, which is amusingly a few seconds longer than the best speedruns of the entire game.
- That
crop=1200:672:n:0option elides a lot of possible complexity; there’s an entire mathematical-expression interpreter under the hood ofof crop and all the other FFMPeg filters, so if you want a 1080p movie panning diagonally across some of the many classic and modern works of art that are available now from any number of places, you can roll your own with relative ease. - The temptation to edit these to say something like “Thank you, Mario! But Peach went to another meeting.” is strong; if I get around to that, the fonts are here or maybe here.
- I really need to get out of the house more. I guess we all do?
Update: A friend points me at FFMprovisr:
“FFmpeg is a powerful tool for manipulating audiovisual files. Unfortunately, it also has a steep learning curve, especially for users unfamiliar with a command line interface. This app helps users through the command generation process so that more people can reap the benefits of FFmpeg.”
Thank you, Sumana!