Could I Run a TV Station on Linux?
JesusQuintana asks: "I'm working with a low-power television station to update their playback system. Currently they're using tape and I've been tasked to move them to computerized playback (MPEG-2, etc.) There are proprietary solutions (very expensive) and there are companies that bundle software with Windows and standard x86 hardware. Overall, they are generally unimpressive and won't sell the software without bundling it with their own hardware. (They won't let us buy our own storage.) We have the expertise to build our own infrastructure (NAS, redundancy, etc.), but really just need the equivalent of iTunes for high quality video. There are lots of other pieces needed to complete the work-flow (such as encoding the media), which could be accomplished on Mac or Windows or even Linux. But what about playback? We need something that will play back these files at their scheduled times (perhaps scheduling cron jobs to change playlists) to broadcast quality hardware (SDI or YUV video). Could we run a TV station on Linux?"
yes
With Linux, all you have to do is concatenate 6 strings on the command line and edit 3 configuration files and you can accomplish anything!
There some pretty good information about TV station automation here
Mplayer should be able to do the job.
I think you are Looking for the Video Lan project, specifically the VLC player:
VLC
It wouldn't even be all that complex.
MySQL database that indexes all content.
Also have a table for the schedule.
Batch job queues up content. As one piece of content finishes, next piece is queued up and plays.
All of this can be made fairly redundant without too much effort. Setting up your schedule can be point & click.
The real work will be if you want to make it fancier to give the advertising department more direct control over what ads run when, as opposed to having the programming manager schedule all of that.
All of this can pretty easily give you a very detailed automated log of what content played when, when you gave your station ID's, what ads played, etc.
Pick one good well known scripting language, learn it well, and use it. I'm not going to enter the holy war of telling you which one to use.
MySQL can be replaced with PostgreSQL if you prefer. Doesn't matter which. You're not keeping your content in the database, just an index of where to find the content on the filesystem plus the broadcast schedule.
The REAL work in all of this is making it resilient so you don't hit dead air. Redundant systems with automated failover, etc. And the cost of entry may be high, but I can't recommend highly enough that your content be stored on a redundant SAN or NAS infrastructure. Most of my long nights repairing things have dealt with failed hard disks. A decent SAN or NAS will allow you to rest easily at night.
Additionally a system like this will allow you to have a much more intelligent content-rich web site.
And I'm also sure there are people at Google who would love to talk to you about your ad delivery system if you put something like this in place. You would like to increase your ad revenue, wouldn't you? Google is working on breaking into this space in a big way. It would be worth making a few calls.
Teach me how to do my job.
Thanks!
(I kid! I kid!)
Support a great indie game: http://www.abaddon360.com
tv station!..yes...but does it run linux.... oh wait..that's the question.
my site of misleading and incorrect information!
The BBC runs a lot of their system (including the weather graphics) on Linux I'd say that the answer is yes. The more important question is how hard is it for me to do it.
Think of the Children; Sleep with your Sister
Most all of the compositing, editing, and formatting software is for windows. For some very limited sorts of things, you could probably roll your own, but it would take a lot of development time, and probably be hard to use.
/
However, you should check out Apple's final cut pro. I've seen it used for small-medium sized TV stations, and it's not too hard to use. I like it.
http://www.apple.com/finalcutstudio/
http://www.apple.com/uk/pro/profiles/tourdefrance
Not to be a technology nay-sayer, but does this low-power TV station need all of this high-faluting stuff?
Sometimes I have visions of throwing a load of technology at a problem, and then leaving someone with a solution they can't run, maintain, or understand. And then they've leaped back even further in technology when it all becomes inoperative.
The thing you have to ask yourself, is do they really need it, and can they be updated to it without damaging them in the long run?
[ No, I'm not a complete luddite, I just wonder if this is a step they might actually be ready to take ]
Cheers
Lost at C:>. Found at C.
NO, MythTV is way overkill for something like this. He just needs a video player, possibly with a dynamic playlist.
Everyone seems to be forgetting the little part about translating the MPEG compressed video into a broadcast quality NTSC signal, preferrably without noticable artifacting and color problems. Depending on the equipment, a simple TV-OUT port could be used, but would that really give the results a television station needs?
Also, let's not forget that he needs to future-proof his solution for digital transmissions. While there's tons of NTSC equipment on the market, what does one use to broadcast in digital? Presumably, he'll need encoders that are well suited to broadcast technology and an advanced digital to analog signal coverter at a minimum. He'll also need to understand whether he will have to support SDTV broadcasts, HDTV broadcasts, or both. If it's both, does his software support anamorphic encoding? If not, what is the hit from multi-encoding?
I'm barely even scratching the surface of the problems he's going to have. Right now, Linux has media software intended for home use. Setting things up for a professional television station is a whole other ball of wax that probably hasn't been considered yet.
Javascript + Nintendo DSi = DSiCade
By "very expensive", the author means incredibly expensive. The hardware is decent, but the software and the interfaces to modern broadcast automation is ugly -- still stuck back in the mentality of text-based programs at best (which makes any GUI app as hard, if not harder, to use). For non-traditional media, like a LPTV (Where frame-accurate automation is not required, where the content can controlled (minimal legacy support, a small number of possible inputs, etc), a full, commercial solution is also overkill. All you would need is a database, a machine (or 2) dedicated to output (for quality and redundancy more than anything), and a controller that queues schedules from the database and sends commands to the output servers as needed. So, yes, Linux will save you not only a bundle of money, as long as you have the ability to program some decent interfaces, but also some frustration.
Yes, this can be implemented on a linux box very easily.
Long story short I implemented this in 2002 at the University at Albany, SUNY with a friend.
It requires a dedicated server and a dedicated encoder.
What will make the process easier is going all digital on your content development.
It currently has a barebones site: Albany Student Television
You can use any number of devices to keep the content automated and going from cron to java scripts to shell scripts and what have you. The challenge is figuring out what you want to do and how you want it managed?
Since 2002 there is a lot more technology out there. Our solution at the time was to use windows explorer with embedded media playing. Two draw backs were an occasional refresh logo in the top, and IE's tendency to be unstable.
I worked on a high-def digital cinema preshow playback system based on Linux. It is currently running in over 400 cinemas. Of course it would take work to find and glue them together. You would also need TV compatible video output with Linux drivers.
Fight Spammers!
Making it redundant is important, but the other challenge is making sure that it's usable by programming people who don't have significant technical expertise (at least not of this sort). Intutive ways to queue up programs, ads, etc. You can have a system with all of the bells and whistles in terms of redundancy, storage, etc, but if nobody knows how to use it effectively, it doesn't matter.
This sig has been temporarily disconnected or is no longer in service
You can even write the entire program to run the station itself in a mere 11 characters of APL code.
Where were you when the voynix came?
...it appears to me that BBC America is probably run by two people and an automated system. My reasoning for this? The glitches I see from time to time. Sometimes the schedule on their web site will say they are showing a certain program, when they are showing something else. Sometimes I've even seen things like a program go to commercial break and when the break is over, you're in the middle of a different program. I suspect these are automation glitches. My second reason for saying this is that I have a series of BBC America station IDs I've edited out of the regular program streams and I have an automated playlist system that can simulate a live BBC America feed just with the programs I've recorded and commercials I've produced myself. So the answer is: yes you can. The real question is, how much of your time do you want to dedicate to doing it and are you up to the challenge. I did it purely for the fun of running a virtual TV station. Would I trust it to work for a low-power TV station? Sure. But I think you'd definitely want better hardware than what I've got. Just make sure it's supported in Linux, or else it's a show stopper. (No pun intended)
-"...bad old ideas look confusingly fresh when they are packaged as technology" - Jaron Lanier (Digital Maoism on Edge.o
If you're running off remote disks, then the NAS MUST be capable of greater output than is required to transmit, as you absolutely must allow for dropped packets and other glitches that force a retransmit. If there's not enough time to fix the problem, then you're going to transmit a picture with noise.
ALWAYS work ahead and cache pre-processed frames. There should be enough processed frames (encoded, digested and all ready to blast to the mast) that in the event of a failover (you DO have failover, don't you?
Your NAS should use a striped RAID array (although each stripe may also be mirrored). Striping is essential in keeping the data flowing fast, and your hardware should be geared to maximizing that throughput. Let the realtime handle the scheduling.
Don't bother using cron, or some other such userland service to start things. Exploit the FIFO queue. It won't run the next thing in the queue until the previous thing is finished. So long as you guarantee the stop time, you implicitly guarantee the next start time. You can then use cron to kill programs that overrun.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
In a way you are asking two different questions here, due to the technical difficulties involved with a TV station playback. So, lets put it this way then:
Do you require Frame Accurate playback? The reason that the profesional solutions you briefly mentioned are expensive and require their own storage are that they Garuntee frame accurate playback, no droped frames and everything else needed to playback everything flawlessly. One thing to remember about that, though. So long as you only keep the current days video on the server, you can stick with a video server with under 1/4 terrabyte of storage space (12Mbps vid+aud=~128GB) and have a seperate NAS for the next days video that just gets moved onto the video server throughout the day as what has already been played gets deleted.
The main problem with most consumer video playback I have seen is that it is not frame accurate. Even on a decent computer, most video programs don't run at exactly the framerate of the video using consumer playback programs. Also, unlike the profesional hardware, the consumer programs don't pre-buffer the next file for playback so that there is a delay between the end of one file and the beginning of the next.
We're also going to need to know what kind of outputs you want. Analog? What kind? SDI? HD-SDI What does your video router handle? Theoretically you could use a VGA/DVI output to a VGA/DVI-SDI adapter, if that's what you use. You'd also need to run it through a frame sync, but that's pretty standard for most stations anyway. Most likely you will not want to use the video card ouput of a PC, VGA/DVI/S-Video due to the need for then having a consumer program play it out.
For proffesional level playout you're going to want a card with hardware playback. SkyMicro and ViewCast make some playback cards that will run under linux that it looks like you could use. I'm just listing them as an example that showed up after a quick googling. These capture/playback cards are essentially going to become the heart of your system if you want something resembling a cheap profesional system.
So, as I said. It depends on how high end a system you want. However, it looks like it is possible to get a decent one going. One thing to remember, and I state it as habit, trial test whatever cards you are looking at before buying. Some of these cards can run to $2000 a piece and you're probably going to want redundancy.
Fly me to the moon Let me sing among those stars Let me see what spring is like On jupiter and mars
These are Linux commands, remember? To start the tv station program would be something like "tsain"
If you want to do it for real, take a look at the MLT project: http://mlt.sourceforge.net/
That has support for for example the Bluefish444 SDI cards, and do playout of real broadcast formats, such as DVCPRO, but also regular MPEG formats.
It also provides ShotCut, a really competent Non-linear editor, that can send edited clips directly to playout.
I know it is in use in one of Indias largest broadcasters, and they transmit to millions of viewers. So it would definitely be good enough for a small station like the one you are talking about.
You're stuck in the mindset of proprietary programming. Just publish a couple of videos under the GPL, then everyone who wants to can modify them into their own ideal TV Shows.
Reduce, reuse, cycle
I designed something similar to this for their CNN Headline news division in Atlanta. The long and short of it is yes you can do it, but rollout approach is very important. For HL, the issue was the shear amount of requirment responsabilities. Everything from "if a plane crashes, do not show American Airlines commercials", to "In this special case, do this" type of thing.... It performs flawlessly, but you really need a good senior developer to pull it off...
For instance, you could start with, say GNU/make. Now that is a pretty handy chunk of software but it sadly lacks video playing facilities. You can freely download the source code, spend a few evenings writing the video playback code you need and you're done. And it won't cost you a cent!
Engineering is the art of compromise.
See http://www.princetonservergroup.com/ Princeton Server Group
Seriously, I've thought about what I'd do with a MythTV box. I've wanted it set it up to play my DVD collection according to a schedule, inserting promos for other upcoming shows between chapters and trailers for the next episode (some DVDs like The X-Files put the 10 and 30 second ads all on the last disk). Then some lower-third overlays for inserting severe weather information, caller-ID, and signaling of when someone's at the door. If I had a family, I'd get the kids involved with a camera to produce periodic news updates.
Basically turning it into what TiVo had once advertised: controlling my own TV network.
Unfortunately I've been happily employed on other coding tasks and haven't had the time even to put together a system for basic recording tasks let alone learn the source tree of MythTV to gauge how feasible it would be to adapt it for 24-hour scripted network control.
Oh, say does that Star-Spangled Banner entwine / The myrtle of Venus with Bacchus's vine?
Or just buy one of these. He can do his MPEG decoding in linux, output to either DVI or VGA, and use a broadcast quality scan converter like the Magni to pump out a clean NTSC signal. In YUV if he wants.
1984 was supposed to be a warning, not an instruction manual.
Well, I've never run Linux for "years" but I'll share my experiences.
I think in the end it is about setting up any computer system to do the job it is designed for in a way that will continue until hardware wears out or power dies. Kernel patches and Security Updates are the exceptions. Windows has more critical patches but probably doesn't affect me as much as a lot of people, since I pair down my servers to not run software they don't need. For stability I usually use an enterprise system with security updates enabled which translates to almost never needing to reboot for security updates. Almost every security update is about software, not kernels in Windows, Unix, xBSD and Linux as long as you start out with a stable kernel.
Cliff probably would be well served by whatever OS he chooses as long as it supports the choice of software well. The trick will be finding software that serves the purpose well. My approach is to see first if there is OSS that meets the need well and then to look at commercial options if not or if they offer something that offers enough service or time savers to offset the cost. I think that the question that Cliff needs to be asking isn't about the OS but rather about what OSS software is out there for specific tasks and how it compares to propritary offerings.
B) Eliminate all the stupid users. This is frowned upon by society.
I'm going to be honest here...
I'd stop looking at 1 platform solutions.
Why not consider perhaps Linux for part of the solution? Perhaps Linux based storage system, and maybe Mac / Windows workstations.
When you go 1 platform, no matter which, your limited. When you use standards between the platforms you gain a lot more. That's why you go with SMB over AppleShare for example.
Don't limit yourself to a platform. Just use things that work well together. There aren't many companies that go 100% 1 platform. Especially in media.
This is utterly rubbish. Many modern broadcast systems have very sophisticated and very easy to manage front ends for handling staggering numbers of encoders/muxes/routing/modulating equipment. Of course the expense comes from redundancy, so that the broadcaster has minimal off-air time if a mux or encoder fails by having software managed backups (IE spare muxes and encoders). Advertisers will get very upset if their content isn't aired correctly. So in modern systems, switching from failed equipment can be detected and done so quickly that the consumer in most cases will not notice that the switch and associated re-routing has occurred. Equipment which can do this cleanly does not come cheap.
:)
Anyway, back to the original question. It's not stated whether the output is analog or digital. If digital, then the transport mux and program tables and all the other DVB mandatory content has to be correctly generated. Encoding high quality complient MPEG-2 on the fly requires some pretty serious hardware support in the professional encoders, so there is no way this could be done with a PC - sure you can encode crappy quality MPEG at low resolutions, but trying to produce professional quality video that makes the most out of your bitrate really isn't going to happen (good motion compensation is non-trivial, in a "You may think it's a long way down the road to the chemist, but that's just peanuts to quality motion compensation!" kind of way).
Of course, you can encode offline and store the transport streams on disk, but then when you mux the output with all the other DVB content, you've got to have consistent GOP structures, PCRs (Program Clock References), presentation time stamps, time codes etc, which is immensely difficult to achieve, especially if you're planning on splicing in adverts and other content (hint - this is one reason why satellite and cable broadcasters encode live from SDI inputs).
If you're trying to replace a tape archive (rather than "Run a TV Station on Linux" - which is a whole lot more, as discussed above), then perhaps you can MPEG encode the videos offline with a good quality software encoder and play it back raw (SDI/YUV) to the head-end bits that do the final encoding/modulating, but even then, getting it all synchronised correctly is likely to be non-trivial (you can't just produce your SDI frames willy-nilly you know - it's got to be synced to the rest of the station, just like the original tape system must have been - possibly off a "black and burst" generator).
Really, I think you're in for a very tough time trying to do this with Linux and OSS, unless you're willing to accept very low quality results that might not integrate with a professional broadcast system.
But, good luck nonetheless.
biopowered.co.uk - catalytically cracking triglycerides for home automotive use since 2008. Just say no to big oil!
The whole "accidentally switching over with your mouse" thing is a real problem that needs to be directly addressed.
This is what you need:
*) At least one seperate video card monitor output per video channel (Matrox Gxxx, NVidia MVS 440)
*) A decent scan-line converter to convert and interlace the VGA into NTSC (one per sim. channel)
*) Ideally, a programmable, matrixed video switch.
With a decent 3U server you can stuff in a few PCI or PCIe cards and handle 4-7 channels simultaneously on one box without framedrops.
You're going to need to fiddle with your X configuration until you (at least) have a seperate screen per monitor. Disable your core pointer and input handling on the non-console X servers. Make sure to set the vertical frequency to 59.94 Hz so that you don't get flicker or tearing. Set the backdrop of each screen using xsri/xsetroot to an image to the effect of "Technical Difficulties, Please Wait" in case a playback program crashes or fails to launch.
Then what you do is manually launch fullscreen versions of (mplayer, vlc, whatever) in response to program events on an 'open' screen. Then you switch the matrix so that the VGA channel you just started a new video stream on, and send that to the scan-converter (and the rest of the broadcast stack).
You could (automatically, manually) script of all of this. I could imagine a cron job that wakes up at 15 second intervals to parse a configuration file that sort of encodes the days schedule -- starttimes, running times, intro padding time, which output channel to direct the matrix switch to, filenames or pointers to directories containing ad segments of various lengths, whatever.
You purposefully allow playback overlap, at which point the script would just allocate a new video channel to run the new video in, and issue a matrix switch so the video looks like it just cuts from one segment to the next at the appropriate time. When the running time is reached (or the player exits at the end of playback), it "reclaims" the channel so new videos can be run there.
You can manually assign input and output channel numbers instead of worrying about having the script keep track (or get the schedule entry app to do it for you).
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Yup the FCC forcing technologies down the public's throat. DTV takes TV from the poor. (No) Thanks, Michael Powell.
:)
And HD radio, gets you more quality (signal quality, not content quality alas, the current signals sound fine, except the music is sorry), but if they hadn't approved it, and allowed more stations, we'd have more choice.
Tuners couldn't handle stations less that 3 slots apart. If 97.1 is a station, 97.3 and 97.5 couldn't be and 97.7 would be the next open one. Then it was down to 2 slots. 97.1 and 97.5 are both stations serving Vegas (97.5's transmitter is in Mesquite, but it obviously targets the Vegas market - their callsign is KVEG - you'd only know they are in Mesquite by the full station IDs on the hour). We could get it down to every slot and have a 97.3 FM. But with HD radio using the bandwidth, that'll never happen.
I'd rather have double the stations than double the bandwidth. As would most everyone except hard-core audiophiles who probably still have tube radios.
Just because it CAN be done, doesn't mean it should!
Actually, what if you use two copies of VLC, have one set up in web interface mode just to feed a stream to another that plays it out to video. This allows you to change the playlist on the fly and do rudimentary switching.
Note that you should have some sort of live switcher for master control upstream of the server, with a camera pointed at a logo (and possibly a live set) for backup.
Video Production Support