I experimented with running a streaming community television station and managed to keep it on the air for awhile, maybe six months? As it turned out the technical side of it wasn't the hard part, the creative part was. While I'm an experienced filmmaker, and I thought that was enough, in the end I didn't have the time or energy to create much of anything for the channel or build support in the community to make things to air.
I plan to revisit this when those things change, maybe in the next year or two.
In the meantime I wanted to take some notes about the ideas I had during the process, because I think hyperlocal streaming in the form of community television has a lot of potential, and I fear that people who might have the time and connections to create such things are concerned about the technical side of it. As a result I see a lot of local programming being "published" on platforms like YouTube, which aside from being straight-up evil, conflate all sorts of things that have no relevance to a local community with the process of watching the shows that the channel airs.
For my channel I strung-together a number of open-source projects to create both a live broadcast as well as a library of shows that would air automatically when nothing was being shown live. This centered around a piece of software whose name I can't remember, which worked pretty good and had some useful features but was not exactly easy to setup and last I checked is no longer maintained. This was good enough to try things out, and I know people who use this regularly so I can say that it works but I don't see it being an option for someone who simply wants to start broadcasting without a lot of help from IT nerds like me.
This got me thinking about how I'd create a simple, safe, reasonably-secure turnkey streaming television station. Something that could be easily deployed to a cheap hosting service or on your own hardware. The "model" I use for this is one of a local UHF station (if you don't know what that is, I recommend the film UHF to get an accurate, realistic idea of what I'm going for). These stations (at least the ones I remember watching in my youth) broadcast a combination of live local shows and news (and replays of these live broadcasts), scheduled self-produced programming and occasionally shows, movies and other media from other sources. Some also participated in "networks" and aired national programming for local audiences (remember this was a time when what you could watch on television was limited to what you could receive from nearby stations).
The shows these stations aired were intended for local audiences because local audiences were the only people who could receive them. While some carried feeds of national broadcasts, much of their airtime was made-up of shows and other coverage that was only really important to the people within receiving range of their transmitter. While it's possible for anyone in the world to watch the programming of a streaming version of this type of station, I think there's tremendous value in providing a local community with news and shows that are important to that community. So while it's no longer a technical limitation, I believe that it should be a policy limitation that material made for a local community streaming station be not only relevant to the station's local community, but so much so that it's largely irrelevant to people outside of that community. This might seem draconian or at least counter-intuitive, but I believe that a production rule like this leads to types of programming that serve the community in ways other types cannot and will revive a richness in local programming that has been gone for half a century. The community can still tune-in to shows that are relevant to the wider world anywhere else on the Internet, but having at least one place where you know you'll see things that relate specifically to you and your local community is very rare right now.
My design for the technical implementation of such a station consists of a single program which does six things:
* Provide a broadcast stream
* Receive a live feed stream
* Record the live feed stream to disk
* Populate the broadcast stream with recordings stored on disk when not receiving a live feed stream to broadcast
* Publish a web interface for watching the stream
* Publish a web interface for monitoring and managing the station
Implementing this as a single program creates some risks, but I believe these risks are a worthwhile trade-off for a community television station. It's possible the program could crash, knocking the station off-the-air. This happened to UHF stations too, and given the simplicity of the station software, a crash of the main program is likely to self-recover in a matter of seconds. Larger outages are possible if something goes wrong with the machine the software is running on but again recovery from most causes of this can be automatic and bring the station back on-the-air in minutes. It's possible to design the system in a way that virtually any imaginable source of an outage can be avoided but if a station like this can be broadcasting 99% of the time it will be more reliable than just about every other streaming service.
As with my original experimental station I'm imposing a few constraints on the design:
* Standard Definition video
* One CODEC
* A maximum show/segment duration of 30 minutes
The reason for requiring SD video is simple: it's good enough. Limiting the station to SD not only reduces the resources needed to broadcast shows, it also reduces the resources needed to produce them. The equipment, sets, lighting even wardrobe and makeup needed to look good in SD is accessible to a much wider range of people and communities than what is needed to produce shows shot in higher resolutions, and the workflow of editing, storing and broadcasting higher resolutions is far more resource intensive as well. Very high quality, professional-grade SD cameras can be had almost for free, as are computers capable of editing SD footage, and of course any equipment you already have that produces higher-definition video can always be configured to produce something lower. SD also constrains the "frame", eliminating the complexities integrating shows with differing aspect ratios. No stretching, no zooming, etc. Composition is left to the authors of the show, not left for every television to decide.
SD video also means a very inexpensive station can serve a larger number of viewers simultaneously than if higher-resolutions were allowed. This directly impacts both the cost of operating the station as well as limits the places the station can run. Restricting shows to standard definition makes this form of broadcasting accessible to a larger number of communities and allows for greater autonomy at the same time.
The last thing I'll say about SD video is that it has been around a long time and there's lots of hardware capable of playing it back. This allows a larger audience to receive and watch the station. I even created a set-top box for tuning-in to my experimental station on any existing TV (even old CRT units). The cost of the hardware for such a tuner is incredibly low, even at cottage manufacturing scales.
The primary reason for sticking to a single CODEC is to eliminate the need for the station software to do transcoding - converting one video format to another for broadcast. Transcoding is a very resource-intensive process, often requiring multiple processors to avoid interfering with the live broadcast signal and it can easily be completely eliminated by encoding all source material in the same CODEC used for the broadcast stream. This may sound restrictive or inconvenient but in practice it's liberating, because it eliminates any question when it comes time to export a show from the editing process or configuring the output stream of a device for a live broadcast. The selection of the single CODEC is largely dictated by what CODEC is supported for playback in web browsers as this is the most restrictive environment where the channel can be watched. Most other receivers have the capability to play streams of multiple formats so I expect that there's a single CODEC which sits at the intersection of these needs (I found something before, but I just don't remember the name off the top of my head).
The last constraint (show length) is something I just added. I don't have a lot of data to back this up, but keeping the maximum duration of a show or segment fixed makes it a lot easier to be confident that the station software's stability can be confirmed before it goes live. Allowing undefined show lengths means allowing undefined file sizes and while a well-designed station software shouldn't be doing things in a way where the size of an input file matters too much the problem can be avoided all-together by breaking things up. This limit also has benefits on the producing side. Limiting a show to 30 minutes puts a natural frame around the scale of a production, and while a given show could be composed of multiple 30 minute segments, the simplicity of keeping a show to one segment incentivizes brevity. This limit also aids in scheduling as it's easier to find slots for 30 minutes or less of material than it is for multiple hours of it, and of course finally this provides natural breaks in the broadcast for station identification and other things.
I have a fair amount of experience building things like this, and I don't think there's anything here that stretches my abilities too far. I'm confident that I could produce an initial version of this in about a week if I could dedicate myself to it for the whole time. That is unlikely to ever happen, so instead I'm going to start a new repository for this and break it down into a few pieces that I do think I'll have time to hack-on, most likely starting with the broadcast stream, streaming a test pattern, and then wiring the input side of the "live" mode to the output of the broadcast stream. Once I get that far what I expect to be the hardest part of the work will be done, the rest is the "grunt" work of reading and writing data to files, creating a little HTTP API and some very basic HTML.
We'll see how it goes.
Jason J. Gullickson