I'd recently completed a major overhaul on the technology that drives my website (see my website framework articles) and so now I'm combing through the content to ensure good quality and completeness.
Largely this has meant adding an illustrative image to every page (those using WordPress would understand this as the 'featured image') - which ensures links share nicely, and stand-out, on social media platforms; kind of important. But with over 200 pages (still) to do I needed something to break the work up lest it drive me Quietly Insane...
SO I took a look at my Video section. I had 50 videos in that section and checking through them all I noticed 2 of them weren't playing correctly. I was getting audio but with a fixed, blank, white video image throughout. Obviously at some point I'd batch compressed the whole directory and hadn't noticed these two errors, godammitohell. I fixed these by going back to the original source files and did the compression anew, this time checking the output files!
Since your website has to deliver its images and media to each and every one of your site visitors that ask for it, it's important to make the files as lightweight as possible (ie. small); otherwise your site runs really slow and ends up costing more to deliver it to people; well, you might have 'unlimited bandwidth' in your website server contract (and you should look to have that!) so it doesn't cost more money but heavy payloads (large files) clogging up the internet makes you a bad cyber-citizen. Not as bad as people sending spam e-mails, but still somewhat rogueish.
You'll also find with (unnecessarily) large video files that playback continually 'buffers' for a very unsatisfactory experience.
This means that media (images, audio, video) always ends up geting compressed when its added to a website (or should). Web compression though, will be 'lossy' - quality is lost and it can never be recovered from the resulting compressed file. But technology constantly moves forward (even if Moore's Law is or has broken down). We haven't even normalised HD TV broadcasting yet I'm already using a 4K monitor on my PC. At some point websites will be serving much higher quality media, so we will need to change the compression we use at some future time.
Therefore always keep your original media files in tact. Create compressed copies for your website today.
But how big are these files and how big should they be?
I found around another 50 video files in my archives that I'd never done anything with. I decided to review them and put some more up on my website. Which meant a whole bunch of video compression needed to be done. I thought I might as well make notes as I go, in case my findings prove useful to others. Which are these very notes, in fact.
Much of this archive footage was gifted to me by Calm Carl, host and organiser of London's excellent Sing 4 Your Supper open-mic. The source material is typically shot on a mobile phone in a dimly lit or (high contrast) stage-lit room. The subject being me, i.e. a solo performer pretty much tethered to the spot by the mic stand (i.e. with relatively slow and constrained movement). I should think many solo performers, poets or singer songwriters, will have similar videos that they want to host on their websites. The fine details of how I compressed these files may be of use.
Looking at these files as they came off the phone some typical file sizes are given in the table below. Obviously the size of the file directly depends on the duration of the video so I've included that also; giving then an indication of how many MB/minute the video from the phone requires:
(click or tap any table row to enlarge)
There's quite a bit of variation but we can see that roughly each minute of video is costing around 90MB of storage space - under these conditions. You might find something very different in your own recordings, but this gives me a base line to understand how much compression I'm looking for.
Try searching for "how big should a video file be for web" and you won't get very much help - this is the very essence of the 'how long is a piece of string' question. So instead we need to think about the things that effect the size of the file and ask how big (or small) should each of those things be.
The things that influence the size of a video file are:
The resolution (pixel width and height)
The frames per second
The 'quality' of the rendering of the frames
Short videos are good not only in keeping the file size low but also in terms of keeping the interest of your website visitors. There's a lot of talk about reduced attention spans in this day and age, and that's something that might well enrage you; something you want to push back on. But irrespective of that, web browsing is intrinsically fickle. It's not like TV, people don't recline on the settee and let the internet wash over them; they sit up at a computer managing many intrusions and distractions. Short videos are way more likely to be actually watched.
Your website video will be watched on a variety of devices, from small mobile phone screens to 4K desktop monitors. For illustration lets look at the actual screen resolution that is in use around the world as of 2020 (refer statcounter GlobalStats):
Obviously the table greatly simplifies the story, but I think that's a good thing. You can follow the link to inspect the raw data and make your own mind up about things if you like.
Now, maybe becasue of telly, our default thinking about video resolution is that it should be HD (1920x1080 pixels) - especially since that futureproofs us as more and more people move to FullHD monitors. And looking at the table above I can see that FullHD will adequately serve at least 76% of the audience (since FullHD will play well on lower resolution screens). BUT we could reduce our filesizes by one third if we opted to use a resolution around 1500x900 pixels and still make full use of the screens of over 50% of the audience. When you further consider that videos aren't always played fullscreen a resolution (as of 2020) of 1440x900 seems like a good compromise; which is 40% fewer pixels than FullHD. That doesn't mean files (of equal duration) would be 40% smaller, but the saving will be significant.
Now we know the target resolution we can think about how many frames we want per second. Each frame being either the full resolution (key frames) or some fraction of it; thats a complex consideration in itself but suffice it to say (just now) the more frames we render per second the greater the resulting file size. Animations, or slideshows, are typically fine at around 12fps (or even less) as their is very little change from frame to frame. High quality video may operate at 60fps (larger rates are typically used to create slomo effects) but web is typically around 24-30fps. Twiddling within this range can sometimes help, especially for very large files, but in the main choose something in this range and stick to it. I'm going to standardise on 24fps because I know my subject isn't typically moving around a lot or quickly. I suppose a guitartist might prefer 30fps so we can appreciate the dance of their fingers upon their fretboards...
All of which brings us to the question of the 'quality' of the video render. At 24fps a wholly lossless quality (100%) will generate 24 full frame images (1440x900 pixels) every second, or 1780MB/minute - which is much larger than any of our source files! Clearly we don't want to do that.
By lowering the quality, instead of generating a full image for every frame, we start with a full image (frame 0) then progressively describe the changes from frame to frame. Until there have been so many changes its worth generating another full image (called a key frame). Of course its more complaex than that, but this is the underlying principle of the quality setting (er, I think).
Quality is usually set either as a fixed value on a scale (0-100% or 0-51RF, for example) or else as the video bitrate. The former is easy to conceptualise but tells us little about the actual data cost of the rendered video (only experimentation makes the impact clear). The bitrate (or actually the average bitrate) makes greater sense when comparing videos. For example we can do a web search and see that YouTube suggests 8Mbps for FullHD video. But this is an answer 'in the general case' - it takes no account of the nature of the subject we are dealing with. Plus of course we are closer to HD Ready resolution than to Full HD. Based on a few trials I'm going to standardise on 2Mbps to compress my video files.
There is one more important impact on the quality, noise. Because live performance videos are typically poorly lit (or moodily lit if you prefer) a lot of noise appears in the shadow areas. The thing is, the nature of noise is that it changes constantly (thus audio noise sounds like static). This means that there are a lot of changes from frame to frame in the video that have nothing to do with the subject. If we can eliminate noise we can have a dramatic effect on reducing the resulting video filesize, as we have massively reduced the changes from frame-to-frame within the video. Noise reduction also reduces detail, so you need to check the results to ensure everything looks okay.
So now I know exactly the nature of the video file that I want to publish:
High Noise Reduction
So now I need to transcode my original source file into a target copy of the file with the above settings.
To do this I use the open-source (i.e. free but donate if you can) software handbrake - you can download it here:https://handbrake.fr/downloads.php
To demonstrate all of the foregoing you can view the two videos below. The first is as-shot at the venue and the second is after transcoding with denoise. The original file was arounf 117Mb per minute, the transcoded version is about 16Mb per minute - which is a massive improvement for playback
So it seems to me, that dimly-lit solo performer mobile phone shot video need not be any larger than 15-20Mb per minute on your website. Use a transcoder (like handbrake) to reduce your filesizes and 'buffering' will hopefully become a thing pretty much of the past...