Could I Run a TV Station on Linux? 321
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?"
Internet TV!!! (Score:3, Interesting)
Long story short I implemented this in 2002 at the University at Albany, SUNY [albany.edu] 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 [albany.edu]
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.
FOSS Signal (Score:1, Interesting)
Based on What I See of BBC America... (Score:5, Interesting)
Re:Yes (Score:3, Interesting)
For the inventive and those that need a solution that doesn't exist, the various video formats and protocols are published and applications can be written to provide the solution needed (which is something I had to do in part for Akamai when I worked there).
As a final note, a Linux based solution would work far better and be far more reliable than a Windows based solution (it would also provide a far better ROI and a lower TCO).
PGA
Re:Do they really need it? (Score:2, Interesting)
In working for a doctors office, I was all ready to set them up with a better switch (they are running netgear now) and a couple other high tech solutions... Until I thought about it a bit more, and realized that they are fine.
What might be a better idea is to leave them where they are, and pick away at a new solution that might involve MPEG and CRON and linux stuff, but only for the day that all of the stuff they are using now is broke.
Taking your time might also mean some other solutions present themselves while you wait (Like used equipment from a slightly higher powered station upgrading all its tech bits).
Heck! Why not have a show devoted to developing a new setup for the station. Get the fans of the station involved. Now thats using Open Source!
Re:Video Lan Project (Score:5, Interesting)
I designed something similar.... (Score:3, Interesting)
Re:Just a thought... (Score:4, Interesting)
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.
Re:In for a penny, out for a pound. (Score:4, Interesting)
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.
Re:Of course you can (Score:2, Interesting)
Re:Short answer: Yes. Long answer... (Score:3, Interesting)
Realtime doesn't make things faster. Putting things in the FIFO queue won't make them noticeably faster. But each of these techniques WILL reduce the possibilities of the unexpected wrecking havoc.
The drives and the network are another matter. They will ALWAYS be much slower than the computer and there is absolutely no way to prevent unexpected events on either. In consequence, you have to estimate the worst likely case and have both be capable of being fast enough to compensate. The buffering is for the same reason. It's pure compensation - mostly for the inherent variations in timing from mechanical devices and best-effort networking, but also for machine failure. It takes 5 seconds to reboot a machine that is running LinuxBIOS, so you require an absolute minimum of 5 seconds worth of processed data to make the failover totally invisible to the audience.
I'll also point out that most TV stations have glitchy images and outage, although it's usually infrequent and relatively minor. What I'm talking about, therefore, is a system that is SUPERIOR to typical commercial-grade television, although I would personally consider inferiority by design to be a deep insult to those who use the service. The system I'm proposing would be quite capable of providing a level of service that users should reasonably be able to expect from an organization with a decent budget. What I'm saying is that you can provide that level of service on a shoestring and have cash left over.
For that matter, many TV stations use horrifically bad compression ratios, creating lines around all of the cells in the MPEG-compressed images and other artifacts that are horrible to look at. If you want quality compression and decent colour dynamics, though, your deadlines are much tighter and you have far fewer opportunities to recover from errors. On the other hand, who wants to watch a movie that looks like it was run through xv's oil-painting filter?
DTV, HD radio, forced tech adoption and choice (Score:3, Interesting)
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.