Originally written .
In my article So I tried using my old Mac for a while, I included a video. The <video> tag, along with <audio>, is one of a few HTML5 tags that I use. I try to not use newer HTML tags, since it's not a given they'll be supported by older browsers, and I want my website to be decently readable in really old Netscape Navigator, and anything post-Internet Explorer 6 be damn near identical to a modern browser. But since the <video> and <audio> tags are so damn useful, and the fact that they also have decent fallbacks in those old browsers, I opt to use them. I can just have a blurb show up in the box where a video or audio clip would have been displayed, explaining that the video can't be shown, while also providing a direct link to the video or audio clip so it can be downloaded and viewed directly. This works great in my opinion.
However, just linking the video isn't really good enough, since if someone is browsing from IE6, it's definitely not a given that whatever they're browsing from can actually view that video if I only opt to serve it using modern codecs. This is less of a problem with the <audio> tag, since I serve MP3 as one of options, and even a 486 should be able to decode that if you put your mind to it, while in the more realistic case, where you're browsing from some sort of Pentium, or something comparable or faster, it should be downright trivial. I've not actually tested either, but I'll be surprised if it doesn't work, and if it doesn't, it's probably down to my encoding of them or something stupid. I'll live in bliss until someone decides to send me an email proving otherwise.
Given that this is the case, I choose to serve a pretty wide variety of video qualities, with both the <source> tag inside the <video> tag, as well as in the blurb that will be shown in browsers not supporting HTML video. Here's a list of the quality options I aim to serve, how I generate them, as well as a video rendered in all quality levels I serve so you can compare. Some of these are generated with HandBrake, and others with FFmpeg, which are both amazing pieces of software I can highly recommend. You've probably already used FFmpeg in some capacity without even knowing it. I have intentions to move the HandBrake renders over to FFmpeg so I can make a script to render a video down to all these quality levels in one go, but the process still requires some babying the way I have it set up now.
The test video I've used it just some clips I took using my phone, a Fairphone 6. I edited those together using Kdenlive (which was more of a pain than it should have been), rendered it using its default SVT-AV1 profile, and then I took that video and pushed it through Handbrake or FFmpeg to produce the results below. The video itself is just some scenes taken out on a trip. The first consists of a metro line train coming into a station. The second shows a lovely Forsythia shrub at a graveyard. The last one is shot at a memorial graveyard.
I'm a pretty big fan of AV1. I'm one of the idiots who bought an Intel Arc A770, just so I could tinker with AV1. The file sizes you get out of it are surprisingly small for the quality you get, and while encoding on CPU does take a while, I find it to be a worthwhile trade-off in most cases. This is the highest quality option I serve, and what you'll probably be served if you're watching the video from a reasonably modern device.
If you're viewing this video on Windows 7 using Microsoft Edge, you've probably noticed that you can't play this video in your browser. You might even think that's reasonable, since no Windows 7 machine is going to have AV1 acceleration and that version of Edge might not have implemented AV1 software decoding. And you would be right, however, some earlier versions of Edge did support it. There's probably some licencing bullshit involved here. Either way, the final version of Microsoft Edge that came out for Windows 7 was version 109.0.1518.140, and it doesn't play AV1, but it also doesn't skip over source attributes that speicify AV1 encoding. This means that those using Edge on Windows 7 won't be able to view a video in a video tag even if it's served with more sources, such as H.264, which obviously is supported. This is annoying, but I've not found a fix for it. I thought I could be smart about it and specify AV1 in the source tag, so Edge would wise up and realise it can't play from that source and thus skip down to the next one it then can play, but it just doesn't do that. Instead it just gets stuck.
If your browser won't play it, VLC almost certainly will, although you will need a reasonably modern and CPU to decode AV1 video without dropping frames if you don't have AV1 acceleration. Still, 'reasonably modern' here means 'released after 2010 and was actually somewhat powerful when it came out'. dav1d is an incredibly piece of software. If you want to watch the video using something other than your browser, you can download it directly.
This video was rendered with HandBrake at a CRF of 25, preset 6, variable framerate, using the AV1 10-bit SVT encoder. I would also have limited the resolution and framerate to 1080p60 if the original were higher.
This is a fairly large AV1 file given the length of it. It's a bit more than 100 MB in size, with an average bitrate of around 12-13 mbps (for comparison, blu-ray tends to have an average bitrate of about 20-30). The original files as recorded totalled up to about 175 MB, so the AV1 codec is definitely doing its job. I could probably turn down the quality quite a bit before it would bother me in order to save some space. This is just the quick and dirty solution. Both the bitrate and codec are doing an amazing job at preserving the quality. Virtually no compression artefacts are visible to my eyes. Any artefacts are there from the camera, and thus inherent to the original recording. The audio is also not an issue, but I don't expect that to be an issue with any of my videos, since the size of the audio associated with any given video is bound to be tiny compared to the actual video itself, so it just isn't worth it to compress it to a point where you can hear the compression.
H.264 has wide support, and is also one of the codecs found on Blu-rays (on virtually all later discs). Anything even vaguely modern is damn near guaranteed to play H.264 and not even break a sweat, and it will probably be supported until the heat death of the universe as a lowest common denominator. This is probably what you'll be served if your device is somewhat older. Its quality isn't as good as AV1, but it's far from bad, and it could be even better if I put more effort and bitrate into it.
If your browser won't play it, you can play it through VLC. Any CPU made after 2010 should play it, and quite a lot before then will too assuming it wasn't born e-waste. Anything even vaguely modern even has H.264 acceleration; in Nvidia cards it apparently goes back to the GeForce 6600, released all the way back in 2004. On Intel it 'only' goes back to 2010 with Westmere (the first Core series chips), but they could handle H.264 streams on CPU too if need be. If you want to watch the video using something other than your browser, you can download it directly.
This video was rendered with HandBrake using it's default 720p30 preset, with the framerate pushed up to 60. That preset sets a CRF of 23 using the veryfast preset.
The quality level of this video has dropped substantially, given that it's got fewer pixels to work with, only being 720p. That does however mean that the file size is substantially smaller, even though the codec is less efficient. This video is only 36.3 MB. The less efficient codec is however visible, but it's normally not an issue. If you pause on still frames, it doesn't take long to find visible compression artefacts, especially along edges of objects where the difference in contrast is large. In motion however, this largely isn't an issue. It also isn't an issue on still objects, since the encoder is smart enough to allocate detail where it matters. Funny how that works! It's still perfectly viewable, and very understandable why this makes for a solid lowest common denominator option for any modern device.
Theora is a free video codec that was the recommended default/baseline codec in the early HTML5 drafts. That same recommendation also recommended using Vorbis audio. It was recommended since we still weren't really past the times of Codec Hell, and Theora, being free, had no limitations on usage, so it could be used by anyone without restrictions, and thus could hopefully be implemented as a lowest common denominator that everyone could adopt without issue. For reasons I've not looked into, this recommendation got dropped, and Theora never really caught on. H.264 functionally serves this purpose nowadays. Its video quality is supposedly comparable with MPEG-4.
If your browser won't play it, you can play it through VLC. Theora is about as heavy as H.264 to decode, but hardware acceleration for it just doesn't exist, since it never caught on. Still, any vaguely new CPU should be able to decode it. If you want to watch the video using something other than your browser, you can download it directly.
This video was generated with FFmpeg using this command: ffmpeg -i input.mkv -vf scale=1280x720,fps=30 -c:v libtheora -qscale:v 3 -codec:a libvorbis -qscale:a 5 output.ogv.
-vf scale=1280x720,fps=30 scales the video to 720p and limits the framerate to 30 FPS. -c:v libtheora selects the Theora encoder to be used to render the video. -qscale:v [number] selects the quality level, where '[number]' is the desired level of quality, 10 being the highest, 0 being the lowest. The FFmpeg wiki suggested a range of 5-7, but I didn't feel I got a decent bitrate until I went down to 3, so I went with that. That gave me a file a bit bigger than the equivalent MPEG-2 one (that one is lower resolution though). -codec:a libvorbis selects Vorbis to be used to encode the audio, while -qscale:a 5 encodes that audio at roughly 192 kbps.
The video in my other article was vertical, so I had to flip the numbers around on the scale attribute, so I end up with scale=720x1280, but that's easy enough to both to and remember.
Theora is clearly a codec that hasn't had much work put into it. Not only is encoding it much slower than encoding H.264, but the results are worse, even at larger file sizes. This video clocks in at 48.1 MB, and despite only needing to encode 30 FPS compared to my H.264 file at 60 FPS, the compression artefacts are visible from the moment you start the video. It's still watchable, but it gives me that 'Youtube just knocked my resolution down to try and save bandwidth' vibe, although no bandwidth is actually being saved here. I suspect the reason it took so long to encode with such a poor result compared to H.264 is the fact that a lot less work has been put into the Theora encoder ffmpeg uses compared to the H.264 encoder. The latter is probably using every trick in the book and then some, with all ultra-optimised assembly, while the Theora encoder has probably never received any significant optimisations, given it was never a very popular codec.
MPEG-2 is the codec used on DVDs, so this video is DVD quality and should play on any machine that's capable of playing DVDs.
I've rendered this video using the NTSC resolution and frame rate, that is 720x480p30, rather than the PAL resolution and frame rate, that is, 720x576p25, as I prefer the rounder numbers that NTSC provides, and the region differences shouldn't matter. Shame on me for betraying my European heritage.
If your browser won't play it, you should be able to play it through whatever media player software you have that you would play DVDs with. Windows Media Player 11 on Windows XP worked for me after installing the relevant codecs (because of course those aren't included. I forgot you actually had to install PowerDVD or whatever back in the day. The past truly is a foreign country). If that isn't an option, there's always VLC. If you want to watch the video using something other than your browser, you can download it directly.
This video was rendered with FFmpeg using this command: ffmpeg -i input.mkv -vf scale=720x480,fps=30 -aspect 16:9 -c:v mpeg2video -b:v 7M -f vob output.mpg.
-vf scale=720x480,fps=30 scales the video to 720x480p and 30 FPS, which is one of the DVD standard resolutions. -aspect 16:9 forces a 16:9 aspect ratio, to deal with DVD resolutions not having square pixels.-c:v mpeg2video selects the mpeg2video encoder.-b:v 7M tells it to use a bitrate of 7 mbps. DVDs support more or less whatever from what I can tell, and Wikipedia tells me that they normally fall within a range of 3 to 9.5 mbps, but of course it can be highly variable. The default if you don't set a quality level will produce a very quick but low quality result. You can set -qscale:v [number], where '[number] is a number between 2 and 31 (lower is better). 2 produced a file that was over 100 Mb, and bitrates in the 10-20 MB range, so much too high. Dropping down to 7 or so produced more reasonable results, but it still spikes above 10 mbps every now and then, and I'm pretty sure a real (era appropriate) DVD player would choke on that, so I instead opted to aim for a more fixed bitrate. No audio parameters are since, since the default FFmpeg applies is MP2, which is DVD compatible, and the bitrate doesn't really matter, since DVDs can support up to 912 kbps audio.
My other video was vertical, so I needed to flip both the scale and aspect attributes to get a video that wasn't horribly streched, but it's easy enough to spot if you've forgotten. And it's just a matter of writing scale=480x720,fps=30 -aspect 9:16.
This video lives up to my expectations of DVD video. The file is somewhat bigger than the Theora encode, at 57.6 MB, and it's also running at a lower resolution than the Theora encode, so it's got more options available to reduce the amount of visible compression artefacts. They are still visible in still frames, but in motion we're back to the impression you get from the H.264 encode. The quality is obviously visibly lower compared to that version, but it reads as a lower quality recording, and not as a bit-crushed or bandwidth-crushed version of what is supposed to be a higher quality video.
MPEG-1 is the codec used on Video CDs. VCDs never caught on in the west, but they represent a decent lower floor of video quality before things start to get dire. Video CDs are roughly comparable to VHS in video quality, so they aren't great, but it should still be generally watchable. I wasn't sure if VCDs were generally playable on computers as old I was aiming at, but my doubts were happily proven wrong when I saw a video I myself rendered running on Windows 95 on a Pentium 75, playing in Windows Media Player version 6.4.07.1112, with no hardware acceleration; just running on the CPU. I was prepared to have to go even lower, but I'll call that good enough. Any lower and you start getting into machines that people don't expect to play video at all, at least not without dedicated hardware to do just that.
If your browser won't play it, you should be able to play it through whatever media player software you have, as MPEG-1 is about as old a video codecs go before there's nothing but hyper-specific stuff that never saw widespread use. It played fine for me in Windows Media Player 6.4.07.1112 on Windows 95. If you don't have anything that'll play it, there's always VLC. You might have to try your luck with an older version if your computer is old enough. If VLC can't run on your machine, then it more or less can't play video. If you want to watch the video using something other than your browser, you can download it directly.
This video was rendered using FFmpeg using this command: ffmpeg -i input.mkv -vf scale=352x240,fps=30 -aspect 16:9 -b:v 1600K -b:a 224K output.mpg.
-vf scale=352x240,fps=30 scales the video to 352x240p, which is the standard NTSC VCD resolution and framerate. Again, my European heritage has to yield to my preference for rounder numbers. -aspect 16:9 sets the aspect ration to 16:9, giving me the non-square pixels I need to correctly display the video given what resolution I have to work with. The .mpg extension on the output file apparently automatically invokes the correct encoder for MPEG-1, that being mpeg1video. The audio is also correctly selected as MP2. VCDs are traditionally limited to a fixed bitrate of 1600 kbps, so I stuck to that, hence the -b:v 1600K, since the default settings ended up using an even lower bitrate, which looked like shit, and just setting -q 1 for the best possible quality ended up quadrupling the bitrate, which seemed unreasonable. The video quality isn't a consistent 1600 kbps, since that apparently required FFmpeg to to a two-pass render, which I couldn't be arsed to do. There's probably a fixed bitrate flag in there somewhere, but I couldn't find it with a cursory search, and also don't really care all that much. This is close enough, and it does work. The audio quality is also limited to the Video CD standard of 224 kbps using -b:a 224K.
The numbers were again flipped here in my other article, since that video was vertical. The scale and aspect attributes were set to scale=480x720,fps=30 and -aspect 9:16.
This video is really only here as a catch-all option in case you're somehow watching this video on something old enough to not even be able to watch DVD video. The compression artefacts are plentiful and ever-present, so you don't actually want to watch this video this way unless you truly do not have any other options. If you somehow are in that situation though, it does work. Things are still clearly recognisable as what they actually are without squinting, although detail quickly gets lost. I'd imagine it'd look a lot better on a CRT, since those tend to hide these kinds of problems. The audio is still pretty good, despite having dropped all the way down to MP2 encoding. It's still at 224 kbps though, which probably makes up for a lot of the problems. It's not really worth it to compress it further, since the gain in smaller file sizes just isn't worth the loss in quality. If the video is just barely watchable, then the least I can do is make the audio worth listening to. The file size has dropped all the way down to 14.2 MB. I probably wouldn't want to download that over dial-up, but at least it's viable for the retro computing hobbyist out there.
Cinepak is a video codec from 1991, and about as old as you can go before it stops being digital video and starts being a slideshow or just analogue video, Dragon's Lair style. I was considering using this codec if MPEG-1 didn't prove to be playable on a Windows 95 machine that wasn't completely hopeless, as I knew that Cinepak would play even on a 486 running Windows 3.1. It wouldn't play well, but it would technically count, and maybe the more modern encoder that's part of FFmpeg could pull through and make the results not horrible. The videos I've seen that are Cinepak encoded are dire in many cases, but they were mostly encoded back in the early to late 90s. Since however MPEG-1 proved to run just fine on a suitable Windows 95 machine, I don't really see the need to scrape the bottom of the barrel. Maybe some other time.
I did prepare an FFmpeg command to spit out Cinepak video and PCM audio. ffmpeg -i input.mkv -vf scale=320x240,fps=15 -aspect 16:9 -vcodec cinepak -q:v 1 -ar 22050 -acodec adpcm_ms output.avi should prove suitable if I need it. It probably needs some tweaks, but I can get back to that if I need to.