Video podcasts via open RSS
Whatever you might think of the excitement about video podcasting, and whether it’s a good idea or not, there’s a common refrain with some of podcasting’s old guard.
“This is nothing new”, they’ll tell you. “We’ve had video podcasting ever since it started”.
And they’re right. RSS lets you publish any “enclosure” - audio files, like MP3 or AAC files, or video files. Apple Podcasts supports it, too.
This Week In Tech (Video) is a video version of the audio show. Subscribe in Apple Podcasts, for example, and you’ll be able to watch the entire show inside the app.
So, what’s wrong with that?
Plenty.
Double trouble
The first issue: that there are two feeds. This Week In Tech (Video) exists alongside This Week in Tech (Audio) - a bit clunky, and which leads to no way to switch between the video version and the audio version.
Having two feeds means that the show effectively halves its power in the charts. They’re not linked, so a play in the audio version isn’t the same as the video version. In essence, they’re competing with each other; any play in the video version essentially means one fewer play in the audio version. And one “follow” to the video version doesn’t count for the audio version. If 25% of people are using the video version, that means the audio version is only getting 75% of the visibility that it should be.
The fundamental Google SEO guidance that anyone will give you is - one link. Use the “canonical”. Don’t duplicate your content. Yet with a video podcast as a separate feed, you’re doing just that.
Massive files
The second issue: the files.
This Week In Tech (Video) has elected to give you files that are in HD quality. They look brilliant on a TV screen - they’re “1080p” full HD. And, as you might guess from almost three hours of 1920x1080 30fps video, they’re massive, even in H264 - every episode is 2.85GB of data, 17x the size of the already large audio files (which are 161MB).
Almost 3GB of data every episode is unrealistic for most peoples’ mobile phone deals, so you’d hope that this would only download on wifi. It’ll fill up an iPhone quickly if you’re downloading all that video, too - unless you only download one show at a time.
Only one massive file
1920x1080 30fps videos are also unrealistic for most peoples’ phones. Sure, an iPhone 15 actually has a 2556x1179 screen, but it’s unlikely that you actually need such high quality unless you’re watching in full screen, and in landscape, and if you’re really peering at the screen.
Above is the Apple iPod Nano 7th Generation, which was released in 2015. That had a video screen of 432x240. That’s all. So the TWiT file - even if it would have played if you had space on the 16GB device - would have been entirely wasted, with lots of video data that it wouldn’t be capable of. (The player supported bigger files, but would rescale them to fit them on screen).
The best quality file for that would be one that was 432x240p at 30fps. And you’re probably wondering… would that really be much smaller than 2.8GB in size? Well, of course I had to try. It looks like I could get it down to 377.9MB. That’s still… not small.
YouTube produces seven different sized videos. They’re encoded in H264, and in VP9, and in AV1. In fact, a typical video (here, the Top Gun 2 trailer), has been encoded at least 22 different times, according to this website. And, yes, the audio codecs are different too, with some using AAC and some using Opus.
Watch the same episode on YouTube, and your desktop browser will show it to you in 720p, because that’s all the screen you’re watching on needs. Only when you flick it into full-screen will YouTube put the video into 1080p - because you literally don’t need it otherwise.
On mobile, if you turn the screen off (if you’re paying for YouTube Premium, which lets you), YouTube will just stream the audio track. That’s 17x less data. Open and unlock your phone, and it grabs the video again (and it’ll probably judder a little as it does it).
With a downloaded file, you’re stuck with that massive 2.8GB file.
Only one not-massive file
Or, worse. Media Watch is a video podcast, and works on Apple Podcasts. That video podcast is a TV show which is encoded to SD PAL standards: 1024x576 at 25fps. It looks fine on your phone, but view it on your TV and it’ll be - well, it’ll be in SD, and will look watchable but soft. But it does mean that this video file is just 144MB (it helps that it’s only sixteen minutes, too).
And with all this, a download means someone can run away with your content, since RSS doesn’t do digital rights management. Less of a problem with audio than with video.
One massive cost to podcast hosts
Bandwidth isn’t free. To download TWiT in video costs 17x more than to download it in audio. Someone, somewhere, has to pay for that. And splicing programmatic ads into a video file is possible, but hard, so most people don’t bother.
The elevated cost of video podcasting - and, perhaps, the cost to ensure it’s safe material (because wherever you’ll have video, you’ll have naughtiness or worse) - is why most podcast hosts don’t do it.
A bad user experience
Unfortunately, none of this works for the user.
Someone watching on a big TV will want a different video file to someone watching on a small iPhone. Someone on a cellular connection will want a different video file than someone on wired ethernet. Some will want to stream video, to remove the requirement to have 2.8GB free on their device; others will want to download the video file to watch later.
So - yes, Apple Podcasts does support video. But it’s a bad experience - filling up peoples’ phones, costing an arm and a leg to download on mobile, or looking bad on Apple TV.
It’s no wonder that video podcasting isn’t a thing that anyone really pushes. Because yes, it’s absolutely supported on many podcast apps, but no, the YouTube experience is much, much better.
What to do?
You can get over the “two feeds” thing by using an alternateEnclosure in the same RSS feed. That’s a method to signal to a podcast app that video is available. And that’s fine, but very few podcast apps support that right now - partially because while it solves the “two feeds” issue, it doesn’t solve the rest of the problems with video.
You can get over the “one massive file” thing by linking to multi bitrate playlists. These allow you to stream - and, yes, download - depending on the capabilities of the device. The good news is that alternateEnclosure has that capability built-in - so you could advertise a file as being a m3u8 playlist, and the device could signal what size file it wants access to. And that’s fine, but if only very few apps support alternateEnclosure, even fewer support this.
You can use alternateEnclosure to link to a YouTube page, or a similar web player. And that’s fine, but removes almost all of the benefit of RSS - and requires a creator to upload onto YouTube.
Or, podcast players could download the video file and re-encode it, as a streaming file, in a format that they know is going to work. And that’s fine, but few podcast apps will want to cover the compute-cost, the storage cost, and the bandwidth cost, especially if they’re not earning from it.
There are plenty of reasons why video isn’t the right thing for podcasting. This is just one of them, in my view. But even just the technicals of video podcasting is hard. And unless we work together to solve that, we stand no chance with anything else.