Slashdot Mirror
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
May or may not work (I'm just guessing), but couldn't you use MythTV for playback?
XBMC is a cheap alternative to a media center PC. If you're looking to playback a series of videos you can make a playlist... For broadcasting, I'm not sure this is the application of choice for your situation, but it is an option many people overlook for video playback (outside of the living room)
Mplayer should be able to do the job.
I think you are Looking for the Video Lan project, specifically the VLC player:
VLC
Look at VLC, MPEG4IP, etc. Lots of options out there....
Don't blame me, I voted for Kodos
Blockbuster has some great instructional videos on setting up a low-cost television station.
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
"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. "
Is using Linux really going to save you that much money to justify all the work that your going to have to put in to make the whole thing come off effortlessly? Let alone the hardware your going to need regardless of software.
I have been wondering the same thing. I was expecting to be a little more elaborate, and generating the content in realtime. OTherwise, I would think that things like geekradio might be modified to fit commercials, show snippets, station announcement, etc.
The real question in doing a TV station, is how to get a license for the LPTV station? THe FCC website talks about having to check the website for when the application window is active, and they only allow license applications when they think it is convenient for them.
Also, you need a place to put the antenna, nevermind the equipment costs. Can I stick an antenna on my house? Can I use this old dead tree? I haven't been able to find out that sort of thing just yet. FCC and the City of Pittsburgh obfuscate their rules and regulations, it is a bit hard to figure out some of these things.
Zhrodague.net - I do projects and stuff too.
I'd imagine something based on gstreamer may be able to do wonders. (caveat: I've only tinkered with audio for gstreamer.) Otherwise, I bet mplayer and vlc will be mentioned quite a bit.
tv station!..yes...but does it run linux.... oh wait..that's the question.
my site of misleading and incorrect information!
Though I don't know how to accomplish the job, I thought I'd mention that--assuming you get it to work--it's nice to see linux being used to accomplish things like this in the corporate world. It shows other companies that it is indeed possible to run a business without proprietary software.
Please do let us a know what your final solution is.
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
Or at least use windows as the source of video. A local [very small] Tv station was once broadcating the "Windows is shutting down" screen for days! [This station normally broadcast what was more or less a slideshow, and used a local radio station as thew audio source.]
Stylish sheet to fix many problems in Slashdot's D3: https://gist.github.com/801524
The closest thing to a video iTunes I can think of is MythTVo wto
I did find this how to on TV output
http://ivtv.writeme.ch/tiki-index.php?page=TvOutH
I have no idea if these cards are broadcast quality.
The good thing is you can try out a some solutions without spending a lot of money.
I could be wrong but isn't this going to be a little more complex than just running a play list?
How many playback systems would you use? What kind of switch? What about audio output?
You will also need to worry about the video and audio staying in sync?
What about captioning? I does Mpeg-2 keep line-21 of the VBI intact?
I would love to see a TV station running on FOSS/Linux.
Everything from OpenOffice, Sqlledger, to Asterisk for the phone system.
Has a lot of potential as a project but there is a lot of work ahead.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
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
Hmmm I have a number of Linux servers here that would disagree with you.
I see my ftp server has served up 14TB so far this month without a hiccup, and it's using ext3.
I don't blame you for posting anonymously. It's hard to post something like that in a way that people can hold your name accountable.
QSSTV is the name of the software, and you can run an ameture tv station atleast.
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.
Wow. That really didn't come out right. English is my first language.
Paul Grosfield - the quicker picker upper.
How about running mplayer using cron?
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
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.
MPlayer & MEncoder http://www.mplayerhq.hu/
ffmpeg
x264 (library)
I use mplayer, mencoder, and ffmpeg with the x264 library to encode dvd's to the h.264 standard mp4. I use mplayer to playback dvd's and videos. You can get frontends for mplayer, but I like it because you can easily integrate it into bash scripts. If I have some time when I get home, I can post some of the scripts that I use, and perhaps try to explain some of the settings I'm using.
For scheduled playback, you can do a playlist with mplayer and use a script and a cron job for it. Another nice thing about mplayer is that you can tell it when to start and stop playback of a file, if for example you wanted to interrupt a program 5 minutes in for a commercial break you could tell it to start at 0 and elapse 5 minutes. Then you could tell it, after the commercials, to start at 5 minutes and elapse another 10 minutes. (I'd post the code now, but the firewall here is blocking the mplayer site).
Talk to the folks over at VideoLAN. The software is very robust and runs on any OS. Check the fora or get on the streaming mailing list.
The closer you are to the code, the happier you are. - Ancient Geek Proverb
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
Just type "tv-station" into the terminal and you are away.
You can script control of xmms via cron, etc. That would give you an itunes like interface. Not sure how configurable the mplayer plugin for xmms is, but mplayer supports output to crazy video hardware, etc.
One would be: Storage on Linux, Playback on OS X - if you can automate it.
Otherwise I recommend getting someone from an OSS video project (mplayer, VLC, whatever) to come and do some work on the gaps you have. Non-compression playback would be one I'd guess. Aside from that it's just about CPU speed and data throughput. Which todays PCs are sufficient for.
We suffer more in our imagination than in reality. - Seneca
Agreed. That's why I asked if it using FOSS+Hardware+Labour was really going to be economically viable compared to proprietary solutions. I like FOSS as much as the next geek. But when talking about vertical applications like running a TV station (even an LPTV). FOSS comes up short. Maybe in the future, but not now.
Look at Blackmagic Design or AJA for there cards. The card itself appers as an video card to the os, so you can run VLC or another player on that screen. This way you get an SDI signal out of it.
If you can accept an analog component signal then look into a nvidia card which has component output under linux from there drivers.
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?
from our point of view, you're doing your job VERY well.
keep up the good work.
signed, slashdot
I had another sig before, but this one is better
You said you have the expertise, didn't you? Surely that's what you meant?
For the short term, throw together a couple DVD changers and a linux-based controller. (At least two changers so the 'next' program is ready to roll the instant the 'last' one finishes.)
That'll give you time to look into file-based playback options (Mplayer, VLC, dedicated MPEG2 card). Tivo/Media Center/MythTV might actually be useful here; they manage a library of programs for you plus have a playback engine; you just need a plugin that schedules continuous playback.
When you're done, post it to Sourceforge, you'll be a hero!
Not that this wasn't entirely predictable.
...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
You're looking for something similar to a video keg, but probably with a bit more processing power and a more controlled interface.
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)
how can no one else have suggested FreeJ ? http://freej.dyne.org/
it's perfect for the job ! it's a scriptable realtime video mixer
you add media (text, an image, a video, a video stream, a video capture card or a dvb card) each is a layer
you can position, resize, change tranaparence or any of the layers
it's the perfect video frontend for a video station !
Disclaimer: I've never worked with video-out hardware in any sort of broadcasting environment.
/dev/video-out'.
In playing around with various video sources, I've come across a couple of very good, high quality pieces of software that are able to transcode video from almost any source. If you do not need client-side playback and just want to pipe re-coded a/v streams to a tv-out device, consider using transcode:
http://www.transcoding.org/cgi-bin/transcode
I've never heard of SDI, but transcode's documentation states that it supports yuv4mpeg output. Transcode is really an excellent piece of software and should fill your need quite nicely.
You might also consider mplayer, as it explicitly supports yuv4mpeg output as well. You can use mencoder (a part of mplayer) to transcode video in the same way that you would use transcode.
http://www.mplayerhq.hu/design7/news.html
As for the automatic scheduling of content to be played.. cron would do the job if your needs are simple. If, however, you need to insert content in the middle of a video during playback (read: a commercial) it will probably be insufficient. I'd suggest preprocessing the video for the next day each night. You'd need a list of timestamps where it is reasonable to stop playback of video content and then split out each video, writing yuv output to a (large) storage device.
You'd then be left with a day's worth of preprocessed video in yuv format that can be fed directly to your digital broadcast hardware in real-time. I'd imagine then that you could just feed the video directly into your output device using something like 'cat `cat video-sources.list` >
Ads? What ads?
"Blah, the windows is shutting down and errored Powerpoint screens had no class. Now the Amiga desktop. Those stations had class."
I've seen a few of those. I also saw the TV Guide channel (when it was called Prevue) where the upper half was an Amiga guru screen error screen.
What beats all, though, is the channel I saw in another city that had the blue Commodore 64 "Ready" prompt screen on Channel 2 for days.
Where were you when the voynix came?
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
If you don't mind a Windows based solution, seriously consider Newtek's VideoToaster. It's up to version 4 and is a full broadcast tv station in a box. No HD yet though. It'll do everything you need.
Commercials are a complication. Inserting them into the middle of a show would require that you either:
a) Have your scheduler aware of the "break" times in the show, tell the player to stop, insert the commercial, then start playback of the show back at the "resume" point
b) Encode the commercials into the video ahead of time (perhaps easier, but less flexible).
There's also the hardware to consider. You're going to want:
- redundant power (either an on-site generator and/or some hefty UPS's), for both your broadcasting equipment and computers.
- storage: A place to store your daily/weekly queue of shows. A storage rack or a server with a good RAID-5 array might do the trick. Hot-swappable drives would be a very good idea (tm), but in the end it's not that much different from other important files
- playback: A unit with the software to read the schedule, and a TV/video-out card with appropriate resolution. Technically for lower-res, a GeForce might work, but you'll want to disable the video on TV-out during loading (bootup) etc to avoid embarrassing splash-screens. You could transfer files locally as played, or stream through the network
- scheduling: You'll want a front-end for people to set programming schedules. A web interface may suffice. You'll also need the scripting for the playback machine to read
- encoding: As mentioned, you could do this in windows/mac and upload the files in a compatible format, but it's not all that difficult to do this in 'nix with a good encoder-card (hauppauge)
- backbone: probably a 1GB/s network to communicate between your storage and playback unit. Spare NICs, cables, and switches are usually a good idea if downtown is a big issue. Maybe a backup network you could switch on in a pinch
- redundancy: Something to save your butt if your storage server, network equipment, or playback machine dies
- hard-copy: Something to save hard-copies of your data, so that you can re-use them later and/or load/offload them to and from your storage machine. Good quality DVD's, external storage drives kept save from shock/magnetism, or perhaps some big tapes might work. A backup array might also work, but you'll want it offsite in case of local disasters
- Testing: Somebody who can check that you don't run into weird encoding errors, hard-drive/media corruption, etc
Again, a lot of this depends on your skill level. With time, money, and effort it's something I'd probably feel confident about, but most of this depends on your own ability to configure the equipment and/or do the scripting/code (or hire somebody else to do it, want my resume?)Sounds to me like all you need is a scheduler (easy enough to write) that feeds an MPEG stream to whatever device you're using to drive the broadcast signal. How hard is that? How are you converting your MPEG stream to NTSC? I've done basically the same thing for these, although that won't help you as they're basically just streamers that work with a corresponding player on somebody's PC. But I did whip it up in just a couple of hours, so hopefully your solution won't take much longer.
Or is that your question, what kind of hardware should you be looking at? If so, sorry, the phrase "need the equivalent of iTunes for high-quality video" threw me off. I'm sure you can Google just as well (or in this case, probably better) than I can...
Just junk food for thought...
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.
It all depends on what your requirements are. They have been completely and unambiguously defined, right? ....)
..... a) Maximum number of hours that needs to be available for instant playback
..... b) Maximum number of channels of simultaneous playback
..... c) Long term storage needs
You should already have the following defined:
1) Playback/Recording video resolution required (Standard broadcast resolution, High Definition (720i, 1040i,
2) Playback/Recording video quality required (What level of compression is considered acceptable?)
3) Audio playback/recording requirements (Number/quality of audio channels)
4) Archival requirements:
5) Expandability requirements
6) Reliability/uptime requirements of both the hardware and software
7) Software development/Integration/Testing Costs and Schedule
8) Budget - Labor/Equipment
9) Need date
Once you answer those questions then you can easily answer whether it would be better/easier to spend the $50K for a COTS unit or the $100K in development costs for a homebrew solution.
I saw this ( http://www.direct2pod.com/ )awhile back maybe it would work, it appears to be a video podcasting system. They imply that they have a way to encode and manage the data.
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
Noone but Gentoo buffs loads a new kernel ever 2 weeks. ...and yes, those reboots were usually either kernels or hardware re-locations.
My webservers when I ran them for an ISP didn't get a reboot, let alone a new kernel install for 6-12 months at a time.
My local public access channel seems to use linux to feed much of their programming. Maybe you can contact them to see how their "real world" experience has been with it. http://sca.scatv.org/
or a pirate station? If it's a pirate station you can do anything you want. If it's a real licensed station it's going to have to meet all sorts of FCC requirements as to signal quality. Pushing home theater solutions over the air isn't going to cut it with the feds. When was the last time you saw a guy with a home theater setup using a vectorscope and waveform monitor to set his pedestal, color burst or peak white level?
SGI
"I use a Mac because I'm just better than you are."
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...
Short answer: YES... BUT not optimal. Expect downtimes when planning to run 24x7x365
"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?"
Long answer..
For playback, skip anything that involves x86 hardware and windows... This means skipping any software based video players on x86 (including linux too). Not reliable and you will experience machine lockouts, reboots and other problems. (even dedicated linux based video play-out servers have this problem when running continuous operations) Non stop video playback at anything above mpg quality is very hardware intensive and requires dedicated hardware to achieve very low downtime. (Trust me, I've been there)
You really should look into this, or something similar:
http://www.adtecinc.com/
Even their lower end products (Edje server) should satisfy your requirements. You can even use plain ftp to send the files to the play-out server... This opens a ton of possibilities if you decide to administer such server from a Linux box.
You can use whatever implementation of x86 severs / windows / linux etc, to manage your ingest/content/monitoring, etc... but for playout and scheduling, make sure you get something that was designed for the task... even if it is a little bit more expensive.
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
Ask Slashdot is not really about asking real questions and getting real advice. It is primarily for entertainment reasons like the advice columns in teen/women's magazines.
Engineering is the art of compromise.
Unless you're in the business of developing proprietary systems, proprietary systems fail. Always.
"I have an odd craving to whisper about those few frightful hours in that ill-rumored and evilly shadowed seaport of dea
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.
"You can't do that. Broadcast television is interlaced. VGA is progressive. Never the twain shall meet."
Oh, I wouldn't say that.
BTW DVD players do an internal conversion to interlaced.
And I am a big fan of MythTV too! It is great if you are sitting in front of the TV with a remote -- which is what it is supposed to do -- but it is not geared around playing content, from pools of media, in a lineup that you'd want for a television station.
I can imagine, however, that most of it (and supporting libraries/packages) is already there for managing the media, and varied hardware. It even has the multiple backend/headend support, which would be ideal for this type of application.
I can imagine a plugin for MythTV -- mythbroadcast or something -- which lets you schedule when to play shows, what commercials to play, and how often to do things like station announcements, pass-through to other inputs, etc. Shit, even something that does those automated stations you see on cable would be a start.
Zhrodague.net - I do projects and stuff too.
Which is very hard to answer. Of course, it can be done on Linux. It can also be done on Windows, and MAC OS-X.
/. hope you'll do it with open-source, so we can start our own TV broadcast stations for free :-D
Do you want to pay the big bucks, or write code from scratch? The vendors charging the big $$ hope you're forced to buy. Of course, we on
Beer is proof that God loves us, and wants us to be happy.
more like: /etc/init.d/tv-station start
You can run Linux, Mac OS X, Windows, no matter what. It all depends on what you are able to pay upfront, in the long run, whether you are developing something yourself or if you have to use certain packages.
If you're starting absolutely fresh (no olden software that has to be migrated) I would definitely start with Linux or Mac OS. I would use Mac OS because of the relatively cheap hardware and stability that comes with them and of course the ease of install and management. I would choose Linux as the primary development platform and something you have to be able to scale for cheap to many machines. Windows is good enough for sales reps, but a BSOD on TV is more embarassing than a 1337 Kernel Panic.
What I would be more worried about is security. Not only physically, but also electronically against not only thieves and crooks, but also against unauthorized hardware access by employees (as in, oh, I got something on this thumb drive kinda thing). If you're working something real time 24/7, it's not easy to upgrade the system without having a pretty large testing environment. Also make sure you got backups. D2D backups are great in speed and shortening your backup window, but I have had more than once having whole RAID arrays fail because a single hard drive blew out the entire bus (Dell machines). This is less likely if each drive is controlled by a separate controller (like Apple's XRAID) but you should have definitely off-site tapes or something as dependable as tapes.
Another thing about them Apple's is that they allow you to micromanage the systems fairly easy while maintaining the integrity and stability of other Unix/BSD/Linux environments. Next to that, in the graphic business, almost everyone uses nothing BUT Mac's. Not only does it have specialized software but also great speed and ease-of-use while Linux takes a little longer to get to know for new graphic designers or freelancers. Next to that you also have the possibilities for compatibility with programs written for Linux (GTK, QT, X-Windows) but I wouldn't recommend using it for internet and network management and security (except for LDAP, their LDAP implementation is the greatest I have ever seen) since it's a pain in the butt and Linux works much easier and is more flexible in that area.
Also get some decent monitoring and reboot schedules on all critical machines. I have more than once seen different projects fail or have large downtimes because someone didn't monitor the SMART status of that oh-so-critical server or checked on the status of all daemons on that failover machine, they had the greatest uptime until they rebooted and it was noticed that their RAID0 array wasn't really consistent anymore for the last few months and half the server was basically running out of daemons sitting in memory and read their practical data over NAS shares.
Custom electronics and digital signage for your business: www.evcircuits.com
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.
see http://www.deltacast.tv/Products/Delta_sdi.htm - their SDI cards (1/2 size PCI) will do 8/10 bit I/O YUV or RGB on Linux 2.4 or 2.6. They also have an SDK - see http://www.deltacast.tv/Products/VideoMaster_SDK.h tm
Disclaimer: I haven't used these, but a quick google turned them up.
$ strings FTP.EXE | grep Copyright
@(#) Copyright (c) 1983 The Regents of the University of California.
If you need an editor then take a look at: http://www.jahshaka.org/ I haven't got many expirences with, but it supose to be a little different from all other major video editors... If you need to do any encoding, you might find and editor that can do it, but you will properbly be very good of with ffmpeg...
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.
I'll just save you guys some time. Here's what any slashdotter will tell you: No matter the problem, Linux will solve it. No questions. Noone is allowed to question the miraculous, life changing powers of Linux. Toilet clogged? Linux. Cat stuck in a tree? Linux. Grandma need a sponge bath? Linux.
http://enseo.com/
Shameless plug, yes it is. But what the poster asked is basically what I do day in and day out, except our clients connect to digital displays instead of TV Transmitters. I'm sure you could buy some of our older cards rather inexpensively. We have drivers for 2.4 and 2.6 kernels. We also have database software but you could probably do better on your own for a whole lot less.
You want to find cards that do your video playback decoding through the cards (need to be able to handle your compression scheme, at least 6mbps). You might want more than one card if you find there are instances you want to play out using the same content set to multiple streams (like a feed going out to a cable head end and to an internal tv network). More than one card in one machine can of course confuse control issues, so it might be better to have one machine and one card per channel all hooked up via fiber using SAN software. At that point, you can also hook up editing stations to the SAN too so that you can edit. In my experience, encoding using fiber attached storage is so very pleasing compared to doing in on a single machine's internal hard drive.
You want RAID, likely RAID 5.
If you want to do device control (which it doesn't sound like you do), there are apps that can help to do so through USB to serial cables which will allow you to do RS422 device control for stuff like dvd players, svhs decks, ect...
The biggest deal is a scheduling system that can also organize device control and multiple channel playback if you are thinking about it.
If that is the case, check out Tightrope ( www.trms.com ). You can get a machine for a couple thousand and hook it up to your storage array and get yourself some MPEG decoder cards in client playout machines, or get the whole thing from them for a bit more (which includes storage and multi head out MPEG decoder card, streaming for the web, ect). I highly recommend them. I don't work for them, but was a happy customer at my last job...
I ran a multi-head peg station for a few years...
How about Adtec Edje encoders and decoders? (http://www.adtecinc.com/products.html) Easy to setup and use. I am not affiliated, just had a good experiance with them.
$ strings FTP.EXE | grep Copyright
@(#) Copyright (c) 1983 The Regents of the University of California.
On Linux With a capture card like the Hauppage PVR350 and a very simple (but sturdy) script you could have a streaming video source...
You may then either use the same machine as a base to encode incoming streams (using multiple PVR-250 cards) or you may use other machines on a simple local network to do so... using NFS....
If the streams come already encoded you could use ffmpeg to re-encode any type of streams that is not compatible to the PVR-350..
you can buy a mac with OS X Server. http://www.apple.com/quicktime/streamingserver/ It comes with the Quicktime Streaming Server that can do MPEG 4.
You can also get a box with an OS and install the free Darwin QTSS, touch the source if you want http://developer.apple.com/opensource/server/strea ming/index.html?
in otherwords, hire Mr.(Ms. ?) tgatliff (311583) NOW
-+-=-+-=-+-=-+-=-+-=-+ *** http://www.mountainfort.com *** +-=-+-=-+-=-+-=-+-=-+-
Linux can do anything... Why next year someone will have a driver that reforms the tax code.
Whou cold havve guesed.
That being said, you really should check out Apple's QuickTime Broadcaster software:
While aimed at streaming webcasts, it has support for AppleScript and workflow automation.Plus, it's free, and has some tutorial examples available.
Also, the ADC has several QuickTime tools available:
(where IANABE == I Am Not A Broadcast Engineer)
For several months, I've been looking for a hardware MPEG-2 encoder on a PCI card with SDI input that comes with Linux 2.6 drivers. Is someone aware of such a product?
can I run a dinosaur park on Linux. Or will it only run on Unix?
There exists no way of exchanging information without making judgments. --Bene Gesserit Axiom
Nothing personal, but I think someone who asks for help on key technical issues affecting their enterprise from the "experts" on Slashdot probably doesn't have a sufficient grasp on the technology out there to "try this at home."
So, no. I take the fact that you're asking this on Slashdot to be a pretty good indication that you, personally, probably can NOT run a TV station on Linux.
Neither can I, but, then, I'm not trying to based on "someone on the interweb recommended I do this!"
HERE. Lots of information on how to use Open Source for video deployment -- and reality hacking. Long live the New Flesh!
Knowledge is power. Knowledge shared is power multiplied.
As a Gentoo user (but perhaps not a "buff" in your definition - I wonder how many users actually would be a "Gentoo buff" under your definition), I must say that I only load a new kernel whenever I have to reboot for some reason. As I use the machine as my desktop, it takes a bit of a thrashing, so I generally will need to reboot for some reason every 3-6 months. (Of course, if that kernel didn't work, I'll have to reboot right away again back into the old kernel. Not sure if I need to count that here.) Excepting when the new kernel doesn't work immediately, and when I first set up the machine, my shortest time between reboots has probably been about 4 weeks. Nothing to do with the kernel - XFree86 didn't want to come down nicely.
However, I generally compile every kernel marked stable. I just don't reboot into them unless there is a perceived security risk in delaying the upgrade. Then, assuming no such security risk, I only keep in /boot the kernel that I currently am running (and thus believe to be stable in my environment) and the latest compiled kernel so that next time I reboot it's all ready to go.
If you have time and money to burn, sure, write/integrate it yourself. Linux sounds like a great platform for this kind of application.
Remember though that it's not really a technology challenge as much as a business, workflow and reliability challenge.
There are probably a lot more reasons that the off-the-shelf systems are worth what you're asked to pay - somebody has thought at least one of them through well and done a good job with turning the true business needs into software.
It's a mistake for your station to hand this to a geek (and I proudly wear the term "geek" myself) to build a bottom-up solution. It's a mistake for your career to spend your time getting geeky vs. using your expertise to find your station the best solution to the business problem - even though the challenges of building such a system are quite attractive to you. (hint: who gets paid more - the coders/integrators, or the managers who oversee solving the business problems?)
Of course you could always wait 'till someone designs MythTVStation...
Or you could go ahead and find a product manager to help design what stations really will buy, engineer it, get venture capital to market it, take it to NAB and get rich or get poor trying to get rich - but that doesn't mean you've quickly solved the immediate problem of moving your TV station to a computerized system.
I worked at a company in the mid 90's that made their own hardware and software for ad-insertion on live broadcats. Rolling your own scheduling software isn't that hard. This is a short list of things that you have to think of to get a broad grasp of what software and hardware you need.
1. The output, does it need to be digital or analog?
1.1. If digital, you may need hw that's capable of switching live digital streams, can be expensive.
1.2. If analog, you need a quality MPEG2 card that can synch it's signal to an incoming videosignal, or possibly use a TBC to ensure good quality timing on the output (a TBC does probably already exists somwhere in the headend).
1.3 Make sure that the playback hardware support bugs (ie. logos) and overlays.
1.4 Compare different hardware to find what suits your needs. Try to buy hardware from well-known vendors and make sure that it works for the OS of your choice.
2. Ensure you have a extremely good MPEG2 encoder, if you are going to use Mac's I recommend the software BitVice (http://www.innobits.se/) since it doesn't change color/light levels at all. You probably need a small encoder farm for realistic encode times. Also, you need at least a couple of hardware encoders for real time encoding of live material or material that needs to encoded ASAP.
3. VLC (http://www.videolan.org/) can be part of the solution to distribute and playback the material. Have multiple machines for playback. It's also possible to use mplayer. Always queue up material in ram (ie. ramdisk) before playing to avoid "burping", try to avoid streaming over the network.
4. You will need to have an integrated backend software that control everything automaticly, ie. queue material up for encoding, controlling the playback of the schedule, producing logs of aired commercials for billing purposes, backing up data & logs, moving material from your videobank to the playback machines in a timely fashion.
5. Make sure you have a good monitoring software that can give you a heads up on potential problems like diskspace, network congestion, disks about to fail, temperatures etc etc.
6. You will need to have a scheduling system that's quite flexible and easy to use. It should be able to use pre-programmed templates to speed up daily and weekly scheduling. It should also should have a "sales-portion" where the sales department easily can tentavily book ads and airing times depending on the planned airing schedule. It will also need a "breaking news" function where you can pause/skip the planned schedule during live broadcats that's unplanned. It also should have automatic fail-over to another instance if something breaks. You also have to consider what to use as a "presentation layer", should it be web-based or should it use some kind of graphical GUI. Usually your and your users needs dictates this. If you contract a company or a developer for this software make sure you have a very detailed specification of what you want. The more detailed the specification on how the system should be used and how it should work the faster the sofware will be built. Also, make sure the software includes automatic stand-alone testing (ie. some kind of unit testing) of it variuos parts so you easily can test them without having a complete system.
6.1. Also, contemplate on what information and control the controlroom should have from the software.
7. Reduncy, reduncy & reduncy. Nothing costs more than not being able to broadcasts sold ads, both in lost income and badwill. Have 2 separated networks, run the cabling separate from each other, don't use the same routers/switches for the networks unless necessary. Preferably you should have twin datacenters whith their own UPS's too. It all depends on how much money you want to dump on the infrastructure versus the risk of not beeing able to broadcast.
8. Infrastructure, as I mentioned before, is very importantat. Think it through, consult with people who know storage, netw
--- Reality doesn't care about your opinions, it happens anyway and if you are in the way you'll get squished.
You could run a pretty stable universe on the right distro!
Defining Statistics and Social Research
You can store video for television station playback on Linux computers using pretty much off the shelf components. But by the time you get the output syncronous with the rest of the TV station, you might as well have purchased a Pinnacle system which will _already be in time_.
It's all fine and well to record and playback video using cheap consumer gear. The problem comes when you want to switch the video between sources or do effects. If it's not syncronous with the rest of the facility, you're screwed.
Certainly, there are SDI video cards with reference input for PCs. And many of them, like the DVS boards, are supported by OS X and Linux (many weather graphics systems you see on TV use Linux and DVS boards). But these cards are $1500 each and you're on your own when it comes to finding software that will work with them.
As far as playing video out of a cron file; if it were only that simple. Sure, you can tell it to start playing, but at what point? Are you willing to have 15 seconds of bars and tone? You'll need some sort of metadata to tell it the in-point. And how about insertions for promos and commercials? How big is the donut and where?
There's a reason that the off-the-shelf solutions are outrageously expensive. They do a lot because this isn't a trivial application.
By "low power", I'm assuming PBS or less, perhaps a PEG (public, educational, goverment) channel. I would guess that a homegrown linux solution using VLM would be of higher quality than much of the programming itself. VLC supports a telnet command-able mode which is called VLM (google for it). Under this mode, it's possible to control streaming via telnet, which means under program control (think Net::Telnet and perl as one option).
I have actually implimented a streaming system for my employer which accomplishes "repeating playouts" rather effortlessly (like "Channel 1" type services that loop over some time period, or placeholders like "having tech difficulty"). VLM supports some real-time-priority and disk caching options which makes it a very respectable playout system. My design uses three servers, two that stream (redundancy for each other) and one admin box. The admin box "registers" content, and uses a bandwidth limited rsync to move assets to the streaming boxes. In this way there is no single point of failure, the streamers are prefectly capable of carrying out their last playout sequence indefinately, and any box could be promoted to admin status trivially.
To actually accomplish TV station grade programming (ie queuing, commercials, intersticials, and so forth) would be somewhat more complex that I've done so far, however I expect it to be possible. The thing VLM is missing would be some "event trigger" mechanism, presently you have to poll for information about what or how it's doing.
The largest obsticles to clear would be the speed of the playout startup, and massaging the end and start of the MPEG assets to assure that the resulting MPEG stream itself didn't have MPEG sequencing errors. Always deciding that the start and end of an MPEG asset will be black, and that start is MPEG sequence 1 and end is sequence 0 should help that. A program to set this up ahead of time shouldn't be too hard. Building the queuing system would be a fun project. A design that feeds an hours worth of programming to VLM on one server and then switches to another server for the next hour would give you an easy framework to take servers offline for service.
Streaming MPEG has many options for injection and translation back to baseband. A simple STB like an Amino A110 can do this very cheaply. Harmonic, Terayon, etc, have numerous devices for this space.
A bit on timing... in the IP space, packet burstiness isn't too big of a deal (as long as it is linear and packets get there on time, 1 packet bursts or 20 packet bursts are okay, devices that listen to streaming MPEG have buffers to eat up burstiness). But clock drift in STBs can be off by seconds over the course of several days. You'd need to make certain that the PC source clock(s), and whatever is doing your network stream to baseband conversion didn't have any appreciable clock drift. If this timing is off, you can see undesireable affects later on. If your "low power" station goes off-air daily, this probably needn't be a big concern.
I was at WTMJ-TV Channel 4 (NBC) in Milwaukee, WI that used a Linux based tape automation system to output the signal being transmitted. It ran all of the scheduled shows and advertising. Only the live news and sports shows bypassed it. This was all run on Linux on robotic tape storage and playback. The tapes were started 2 seconds before the output was used to stablize the output. This eliminates most artifacts.
This concept can be extended to play digital video to both NTSC and ATSC outputs (its done at this affiliate). The costs for good conversion to RF HW for output to the transmitter is not that expensive. You can solve the failover, if you need the reliability, by doing two parallel players and use an intelligent switch which switches to the alternate, if the signal quality falls below a set target. A good way would be a NTSC or ATSC tuner board on another Linux PC with signal quality measurements after conversion back to a digital stream from both outputs. The PC then figures which has higher quality and switches to the signal with the highest average quality however you define it. And this could scale to more than two players, if needed.
Cron could be used for a down and dirty scheduler. Use NTP to synchronize the internal clock to a high accuracy source. When you want more accuracy, go to a RDBMS program that starts your favorite player with the digital file to play. Mplayer for example can be told to cue file xxxx and start playing at frame yyyy and output to video output 2 at the reception of signal s. Then your clock reading scheduler gives mplayer the signal. Mplayer then plays the file and a 100ms later, the scheduler switches the mixer to video output 2. When the next file gets switched to, the scheduler sends a stop to mplayer and cues the next file up. By using two or more mplayers, you can alternate between them and never output a black signal for longer than one frame, and most of the time you would not see even one black frame. Note, this also allows you to be able to play a piece without starting or stopping on a key frame (B in most MPEG(1/2/4) parlance) as long as you use a good NTSC or ATSC encoder as mplayer outputs a stream of decoded frames. If you don't want to use a HQ HW encoder, you could stipulate that the video switchovers occur on B frames (every 2 seconds on most formats) and tell mplayer to output the stream as is. That forces your file makers to make sure that the B frame occurs 100ms after any files starts at the point you schedule which can be verified by the RDBMS schedule update program using a tool to find valid B frames in a given file. Or the editor checking in a file to be played needs to give a valid list of B frame numbers for that file.
And you could still use Windows for the video editting because Linux can use SAMBA to share the video data storage to them (it becomes another virtual disk (network file system)). When you find a Linux based video editor you like, you can simply switch that function over without changing the back end one whit.
This is not very hard to set up in a few weeks and is easy to verify proper operation.
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
Can you use Linux? The question is irrelevant.
You are putting the cart before the horse.
What are your requirements? Uptime? Fault Tolerance. Ease of use? Storage? Performance?
There is a reason the proprietary solutions are expensive. There is a lot of time and effort involved, and the down side (your audience loyalty, ratings and the FCC penalties) are non-trivial.
I am sure that the tools exist for Linux (MythTV probably does most of what you want). Additionally you can fine tune a distro, and tweak the kernel to optimize performance and reliability. A LiveCD solution might even work.
Have you a configuration management system in place. Testing? Disaster recovery plan? Why Linux? Have you considered one of the BSD variants? Is there reliable and tested open source solution for Windows? Have you factored in all the costs of rolling your own solution (even if the OS is free)?
Years ago when DVDs came out I had a RealMagic holywood pro card that did native MPEG palyback and dumped a TV level signal. The actual processor on the board was a modified 486. It was just supported by a chipset that was optimised for matrix transforms.
Now I'm not sugesting you use that (although Mplayer support under linux was okay), but the manufacturer Sigma Desgins did have some broadcast level stuff available so might still do. The benefit of this was the card was only made to playback MPEG2 and did it at the same level as a set top box, where as software playback was sometimes better and often worse, but not consistent.
Or you could try to find a NewTek video toaster. Always wanted one of those to play with. Mmmm Toaster. Anyway
Apart from that, I'ld invest in solid state storage, or at least a large ram area for a buffer, to stage files for playback. And as someone else pointed out, you would want a video mixer. You should be able to find one that supports a SMPTE code or similar so that it is mixing the output from your video servers, but it controlable by MIDI. If you matched that up to playback software controlled the same way, you should be able to have a central controller scheduler and a series of playback nodes that fired of a script and timecodes. Using off the shelf midi control software you would be able to script events (ie ad breaks) etc..
I would avoid software only playback and mixing like the plague and try and find dedicated hardware to do the actual playback.
Just my $0.02.
Sure you can, but the question is, how long are they prepared to wait?
Building a server ie eminently feasible, but since most available encoders and decoders are designed for the Windows environment (where the sales volume is), you'll be hard-pressed to find drivers for Linux.
Better to attach the automation side, which is mostly a software problem. Given that you have any skill in designing complex software systems, and given, too, that you have a comprehensive understanding of the task at hand, you should be able to have a minimal system operable in a few weeks. But I say that as someone who has been in the television industry for over 30 years, and who has designed three generations of video server products.
I've also seen some real abortions designed by folks who thought they were smarter than the vendors, and who apparently place no value on their own time. That's not me, by the way, I do have a life.
Finally, I have never seen a home-brew software system that was competently documented, and delivering the tools without docs is an irresponsible act. You would be making yourself indispensable to the station's business, something for which no intelligent owner or manager will thank you.
Many folks think that writing an automation system would be fun. Few if any feel the same way about documenting it, either in the code, or on paper. That's why there are so many companies producing good commercial products.
But go ahead, knock yourself out. After a couple of years, you may have something barely capable of handling the LPTV market.
--- Bill
I believe the high end broadcast Canopus ADVC1000 is supported under Linux. This is a firewire video converter, and can even run standalone if needed. The only drawback (if you can call it that), it is DV format only....no MPEG2/4. DV will look better than MPEG in most instances, but you end up with a substantually larger file. The video quality that exits the box is outstanding!
I tried for some 3 months to come up with a viable Linux playback server for live news video playback. I never came up with something I was 100% sure would be 99% error free, so we ended up going with a pair of Apple XServes and the Canopus box. We use a JLCooper shuttle box to run the transports. The software is commercial (and expensive, $5k per license) by a company called Bug.TV. http://www.bug.tv./
Another commercial software option would be VirtualVTR http://www.virtualvtr.com/. It's for OS-X, but the guy might very well do a custom Linux version (if he hasn't already) for some extra $$.
Good luck, and let us know how it turns out.
I'm currently running a local TV station entirely on Linux products. Although our interface here is just composite to a cable modulator. It is still xloadimage/VLC/mplayer/X.org.
Support Eachother, Copy Dutch Property!
Back in the 80's, I ran a TV station using an Atari 1450XLD. It has TV out. I don't know about the mpeg 4 though. Oh, wait. I didn't run a TV station. But I did play Bounty Bob.
just make a mess of shell scripts and command line video tools. after you come up with something that works, announce a new open source Linux Distro called PenguinTV or something and put up a website.
"The Most Fun Possible on 4 wheels" is at SunBuggy in Las Vegas
If it is just a budgetary concern consider a VT[4], a great product that's very affordable.
+0 Meh
http://heroinewarrior.com/cinelerra.php3
When the source is open, the possibilities are endless.
Try the Sony NSP 1. I have one sitting in a box that I'm supposed to be running up (eventually...). It will do all sorts of fancy scheduling (ads and so on), is networkable (i.e. remote access), can play MPEG2 and MPEG4 streams and runs Linux.
Although if you just need a simple playlist, there are some cheap media players around. Mediagate comes to mind.
Anything can wake itself up at specific time... it could just be a perl script.
But you really do want at least 1 seperate screen for this, and two extras are better. It's difficult to get a video stream to "start" onscreen without a pause or video glitching programmatically unless you are going to (lets say) write a full-blown, multi-threaded QuickTime application. And I don't think that's necessary.
With two screens you accomplish a cut in a hardware device that you can use for other things too (say playing a VHS cassette, patching in a live feed, allowing input from backup servers without recabling, etc.)
Redirecting audio is as simple as ensuring you have a dedicate sound device for video playback and use that target in all your video playing software commands. Realistically, in a server environment, there aren't any other sounds. Just use the default/onboard device if its halfway decent.
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!
There's a system out there that does exactly what you're looking for. It's called the Playback Machine. I currently use it to power the television station for BayCon, which is a science fiction convention in San Jose, California. It's available from CPAN, here: http://search.cpan.org/CPAN/authors/id/S/ST/STEPHE N/Video-PlaybackMachine-0.03.tar.gz
t k/mplayer/xfree86/epia/touchscreen/whitepaper/Vide oKeg.html.
Here's how it works. You enter your schedule using a web-based front end, picking from a list of movies from a database. Whenever it's time to play a movie, the PM will play it. Whenever it isn't time, PM will play music while showing picture slides, announcements, and "up next"s. You can change the schedule while the system is running. The database backend makes it impossible to inadvertantly schedule two overlapping entries.
The main issue with it is that it's rather difficult to set up. Since I'm the primary developer and primary user, there's been little work on making it easy to install for other people. However, if others are interested in using this system, I would love to work with them. Please send me a private message if you're interested.
Another system which does the same thing is VideoKeg, which is written up here: http://ian.blenke.com/projects/videojukebox/perl/
Yes, but the PSGs require Windows client machines. I saw a live demonstration at NAB Post+ last year.
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
Only on 32 bit processors with 32 bit. 64 bit processers with 64 bit jiffies will take ok I will be dead first so not important.
It processor dependant with linux.
The roll over is the size number.
Not Lebowski fans are we, mods?
Paul Grosfield - the quicker picker upper.
Not true. You can use any type of client machine you like, Windows, MAC, Linux etc. As long as you can create valid MPEG file and have a web browser such as Firefox you can use the system. They even have a drag and drop utility now for DVDs so if you have content you don't have to convert them yourself, just copy the files the server via smb or ftp.
Before resorting to ask slashdot, I did try to look for information on low-mid level gigabit switches. The last roundup I found was dated 2002. Effectively, because the technology has reached commodity status - no one wants to review this stuff anymore.
So, I can look at NewEgg Comments, and CDW information - but that's it. Toms Hardware looked at a 24-port 10/100 + 2 Gigabit port smart switch, but that's about it. Except for one guy who wrote about cheapo dumb switches that he tried at lan parties. Some of them did not have jumbo frames.
So what did I learn from looking around: For my purposes, at home and a couple of clients, I want to be able to run bittorrent; VoIP; have web availibility. This means spanning tree (or fast spanning tree), Class of Service, port aggrigation for uplinks 802.1p, and Virtual LANs 802.1q. In a smart switch you can get three switches (maby six)for about $330. Linksys, Dlink, and SMC. The D-link seems to have slightly better features than the Linksys, and I swore off SMC because of crappy customer service.
I asked Slashdot, because I want advice by people who have used this stuff in real life. You can't even find the information on Google Groups. My two assumptions were: People had used this in the business and could say how they held up over time. People had used this junk at LAN parties. (A smart switch costs less than a high end video card) This is why I asked Slashdot.
Because I can't end anyone.
I do some work with VLC running video to IPTV settop boxes(amino). It can do IGMP UDP Broadcasts, Multicasts, etc. It can do on the fly transcoding of files as well. It can also do VOD and schedule based playing. You could do just about anything with it. I have a feeling my IPTV provider uses some form of VLC. They have issues with VOD on our boxes.. so does VLC :)
There are some questions that really affect which direction you should go. Where is the content coming from? Is it all locally produced? Is it produced live-to-tape, or is there a lot of postproduction?
You may be interested in A $300 video server tivo-based hack, which is kinda cool.
Anyway - For in and out, you could consider ASI-based transport. An advantage of using DVB-ASI out from your server is that you can easily transition to digital transmission when the time comes. The physical characteristics are similar to SDI, ie a 270mbs signal, but you're dealing with MPEG2 transport streams. You could have multiple program streams if you want. The idea here is that you can use external encoder/decoder boxes that go between audio/video (analog or SDI) and ASI (compressed domain). All you need to do is splice the files at I-frames and stream them out to the device. Hardware's pretty cheap - have had good experience with the cards from DVEO/Computer Modules. Cheap and stable, and they come with linux drivers. You'll need to write some code to make it all work, though. And external encoders/decoders aren't the cheapest thing, but they should be cheaper than most video servers
There are also ASI/MPEG stream splicers to look at - from companies like Leitch/Harris, Thales, and EVS. But you've noted they're a bit expensive.
SDI-based playout is going to be rather expensive no matter how you go. Offloading this work to an external decoder is pretty cost effective. You can also use IP as a transport instead of ASI, to an external decoder, but ASI is a bit simpler and more reliable.
In college, I wrote an automated air playout system on a mac - had a mysql db for asset management and scheduling. This was synced every so often to the website db. Had a pretty simple set of perl scripts (which included calling applescript from the command line via osascript) that handled playing to air. (used quicktime player, actually, with great success). Created blocks of clips using SMIL, which you should check out. Was able to key bugs/logos/time/temp info, too.
Between scheduled programs we cut to an Apple Keynote presentation, started and stopped by the same scripts [using applescript]. The actual presentation was auto-generated during the programming by another perl script, from another database. (Including events from a central campus events database, updated weather forecast, program schedule db for coming up next/later, advertisements/PSAs [another db with this info], and video interstitials)...
Now that was a fun project. But quite a mess at the same time.
Ask Slashdot: How do I get laid?
Uh, no they don't. They require a seperate computer with any web browser to control the user interface. But it doesn't have to be Windows. More than likely they used a Windows machine when they ran the demo at NAB, but ANY machine with ANY browser can interface with it.
My site
My films
Yes that right, see http://www.computermodules.com/
Real TV stations already use embedded Linux for almost every facet of video production, delay, schedualed playback, add insertion for SDI and HD-SDI.
For about $25K TV you get get an embedded linux system that does MPEG2 compression and
ATSC / 8VSB modulation. see http://www.8vsb.com/
I am always doing that which I can not do, in order that I may learn how to do it. - Pablo Picasso
To get a perfect interlaced signal out of a computer...
/proc/sys/dev/rtc/max-user-freq" to your rc.local, so MPlayer can use rtc for accurate timing. You probably want to used the "-fixed-vo" option as well.
Setup Slackware 10.0 (1) on a fast machine, with a recent NVidia card (2)... Install the NVidia binary driver.
Configure X.org to use a 60Hz refresh. IF you are going to need S-Video out, use a resolution of 800x600 and set "Overscan" (in xorg.conf) to a large value, around 0.8 should work.
Get mplayer working with -vo gl. Add -dr for performance. Try different yuv= parameters to gl. Try with -vf bgr24. Once OpenGL output that works, add -vf tfields,softskip (3) which will give you (absolutly great quality) interlaced video output which will rival any professional setup. Hopefully that video stream will be accepted properly by whatever your broadcast hardware is. (I'm not an analog TV broadcast guy, so I have no idea what you may have)
Also add "echo 1024 >
That should get you started, and the hardest part taken care of.
After that, it's largely left as an exersize to the reader...
bmovl (or the bmovl2 patch) should allow you to display any arbitrary on-screen graphic overlays you want.
You can write a very simple command-line program to control MPlayer via slave mode... As long as your program can keep a schedule, tell MPlayer the filename of the videos you want it to play, etc. you're all set.
If you're a real low-budget operation, you might even use MPlayer on a second machine to scan the video (before you broadcast it) for black frames. Then, you could use that info to have your scheduling program automatically insert your commercials where the feature's scene-changes occur.
And last but not least, you'll certainly want X11 running without any window manager, and probably an all-black background, to hide any minor mistakes that occur.
(1) I know Slack 10.0 will work perfectly (except for the NTP daemon) for your task. 10.2 has some X11 bugs.
(2) NVidia's binary driver is absolutely essential for proper OpenGL video output, so no ATI cards allowed.
(3) If -vf bgr24 is necessary for your NVidia card, the filter line is going to be tricky: "format=yv12,tfields,softskip,scale,format=bgr24"
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
That I'm not the only one that has had major problems with Reiser.
As much as people hail it as awesome and fast and stable, I can say they're full of shit.
It's fast. but it's unstable. and I'm not talking about reiser 4 either.
It's hit or miss, some people have no problems with it ever, while others have complete failure. I was one of those.
Some reason all the file permissions were hosed after checkinstall did something, and were unsettable. after backing up my home directory (and thank god everything of mine was on another drive and partition)
I tried reproducing the problem and no avail with ext3.
So far, and as in the past, ext3 has yet to give me any problems.
I started designing just such a thing over a year ago. It hasn't gotten to the coding stage as I never invested in the hardware necessary to do it. Unfortunately the TV station I was hoping to work with went out of business, so the project got shelved. But it would have been rather easy and cheap to do for standard definition, NTSC or PAL. High definition would have been harder because more expensive hardware would be needed, and the data rate would have been higher making it necessary to be more careful in the architecture design.
My design would have involved multiple computers in a high speed LAN. One, plus a backup, would be the "play to air engine". It would have a very lean design program that would play out the video/audio to the hardware. The hardware would do the decompression and syncronization. It could then output to composite, component, or SDI, depending on the hardware used. The other machines would essentially be specialized file servers that would serve up the video files using HTTP (not NFS or SMB). Another machine would run a scheduling database (probably MySQL) and be accessed by the engine to keep up to date on the schedule, and accessed by a web interface by programming and sales to schedule programming and select the commercials to play in breaks. And one more machine would be used by master control to ingest and segment programming. Additional machines of each type could be added as needed, such as more file storage space, and parallel ingestion.
The notes I had on the software design included putting some smarts into the system so that it would automatically handle things like commercial and PSA rotations, and master control operator directed last minute schedule or timing adjustments. Having done master control entirely manually, and semi-automated, I've seen how things can get messed up, and how the existing crop of automation facilities are really fairly bad.
I would definitely avoid commodity tools like cron for this. Things are too hard to change on the fly and confirm what is about to happen. What I would want such an engine to have is a direct display (not a refreshing web browser or anything clunky like that) that constantly showed what just played, what is playing, and a list of several things about to be played. Additionally, there would be master control commands to do things like delete or change the schedule immediately on the fly. There would also be commands to change the timing in case it becomes necessary to change when a sequence of segments or programs need to be forced to end at a different time. Then it would duplicate frames or drop frame periodically to adjust for that.
I also planned to use a very lean custom Linux system (thus making its own distribution, in effect) that can reboot very fast in case of power problems (like cheap UPSes failing) and get back on track, like being able to resume video out within a second or two of the kernel launching the first user space process. This lean system would essentially have nothing else running but the video engine program, and a shell on a 2nd console for maintenance. There would be no network services, no DNS, no SSH. It would be tight and lean. The other machines (database, ingest, storage) might have more running on them.
So, to answer your question ... most definitely yes. How good it will be depends on how goo you are at building a system that best matches the needs, and programming the software appropriately.
now we need to go OSS in diesel cars
Many embedded systems for studios already run Linux. Just think of satellite recievers. Many of the professional ones run Linux.
Of course playback is a different topic. What you can do, if you want to build something yourself, is to use n computers running a relatively simple programm just listening to commands they get via the network. (piping commands through ssh should work well enought) Then you run the output of those computers through a video-switch which you also controll (they typically have ARC-Net sockets as well as RS-232 an other standards). Then you write a little programm which can a) issue certain commands automatically at certain times b) issue commands manually and perhaps c) react to "error" conditions from your equipment.
Just setting up one computer that does everything will probably be hard. The hardest part will probably be to find a graphics card that can output genlocked video and runs with Linux. If you don't find any, get some cheap external VGA-TV converters and a consumer style video mixer. The small loss in quality should be acceptable.
Don't feed the trolls!!! While your points are all valid, he's nothing but a troll. Posting AC because this post is pointless too, but I'm not out trolling for SnG.
SMB over AppleShare? Maybe for you and me. At work, I discovered that SMB didn't work on my Powerbook, because they were using CIFS, which wasn't supported natively (or I didn't know about it). CIFS is the right solution for Windows clients, or for Linux clients with a Windows server, because SMB is horribly limited -- things like the 2 gig limit on file sizes. I asked the network admin about it, and he set up something -- on the Windows server -- to allow me to access it as an Apple shared FS of some sort.
Yes, go for open standards which are supported between platforms, in case you have to switch. But I'd argue that the cost of switching if one platform fails is less than the cost of maintaining multiple platforms just in case one fails.
And I would guess that most companies which don't go 100% to one platform would dearly like to. I know one company I worked at would've loved to go 100% Debian or Ubuntu, but had to keep Windows on all the desktops to run things like FileMaker. The one I'm currently at is almost 100% Windows -- I'm one of two people I know of who have a Mac, and I also have a small Linux server there, only for my own use. Since I'm the one admining my Mac/Linux stuff, it doesn't bother them, but if their admin had to service my machine, I'm sure he'd rather it be Windows. Another small company in town is 100% Apple, except for one Windows machine in the corner.
In my opinion, most of these companies wish there were more open standards for them to draw on, so that they could go entirely one platform.
As for a TV station, I wouldn't ever consider using Windows to do the actual broadcasting. If they have some people who are hooked on Outlook, fine, their loss if they fsck up their own workstation, but I'd run Linux for both the storage and the broadcast. I would consider alternatives, like BSD, maybe even a Mac, but I probably wouldn't bother, if I could make Linux work. And here, I think it can.
Don't thank God, thank a doctor!
Ask yourself "Why?" before continuing.
They're trying to lower the costs of running a TV station to the point beyond which systems can't deal with problems and you'll kill yourself maintaining it.
There's a reason the pros buy pro hardware and software bundled.
And there's a reason these guys can't afford it. (Hint: They don't know how to run a TV station or they'd have enough market share to pay for the stuff.)
Run away. Far away. Let them die in peace.
Meanwhile, on a more positive note -- Linux Format has run a number of articles over the last few years about how the BBC does use Linux highly successfully for certain niche portions of running a TV business. But not the whole BBC!
Feel free to do some research/homework by looking across the pond. They're far ahead of U.S. TV in using Linux, but they're also running a monopoly with government funding... meaning they play (and I mean play) with a LOT of technology over there.
NPR and PBS similarly have interesting "toys" in the States, but the big shops -- use tools that work and concentrate on their content (sorry, that's a "web" word but it seems to fit) and talent, and they make damn sure the production tools don't get in the way.
They also don't count on toy tools for on-air playback. Off-air time costs money and viewers... screwups in playback that require some geek to come fix a shell script, aren't tolerated in real professional broadcast circles.
Unless you're already hiring coders to write some amazingly good code, and you've already figured out how you do on-site 24/7 support of the systems... don't go anywhere near broadcast. That's the world they live in, and they'll eat up and spit out anything that hiccups more than once or twice a year.
+++OK ATH
There are companies selling servers to do this already. It can and has been done and is available for purchase. http://www.princetonservergroup.com/about.php
Take a look at Optibase and the VideoPlex series of mpeg-2 dekoder cards. You get the cards for nothing at ebay ect. and there is a Linux SDK available.
I'm sure you could if you're willing to write your own code. But if your real question is can I buy 'out of the box' solutions that only run on Linux, I don't think it's possible. I've tried. I'm the chief engineer for a big four station in a top 100 market, and I frequently ask vendors 'Why are you doing this on Windows?' Usually the answer boils down to 'that's what the developers know.' My plant is probably 80% windows.
Well, yes. But no. After you get your realtime requirements for your streamer going, you get all the bugs in your encoder patched up, get your own scheduler working, you'd have been better off dumping $40k in better equipment.
Another problem lies in digital conversion. Eventually (not very far down the road) you're going to be broadcasting MPEG2, not NTSC video, but I'm assuming you're somewhere where this applies. When you go down that road, you need to extend your system out further than a video output, and go straight to QAM encoders. Your system at that point will be such a cluster (read: not beowulf) that no one who comes in will understand it.
What I would do (and have done), is have your storage attached over FC or some other SAN solution, have redundant streaming boxes running a RT Kernel with GbE outputs, and run said GbE outputs into something fun from RGB Networks to take the digital back to analog. As far as content scheduling and replication across storage, I'd make sure it was independent from the streamers. With a setup like this, you're good to switch to digital broadcasting someday with minimal future expense (comparatively speaking). There's a million fine points I'm missing, but you should get the drift.
This isn't a weekend project.
It can be done. The anime con I attend in Dallas runs all their non-dvd rooms off a linux box. They had a couple of problems this year with a bad drive, but the previous year there were no problems. This past year had four rooms running 24 hrs for four days.
Should be plasuible, but i hope you're not running ARPS 331 :)
I was involved in setting up a DVB network for a commercial station. The whole job was handled by 2 people. First things first: linux stuff.
Almost all the expensive boxes running the network where in reality just linux machines running specialised software encased in a nice box. Now re the software:
Encoding: We've tried with vlc, the results where not very pretty. It works but a) The encoding part isn't up to scratch - you'll tweak and tweak but never manage to get a reasonably constant bit rate which will glitch your final broadcast. B) The PCR of the Transport Stream is not reliably kept, consequently we had several customer complaining of all sorts of wierd problems with the streams.
Transmission: using VLC to just stream over UDP presented no problems
Capture: Have a look at DekTek's hardware and StreamXpert software. The drivers are well written and documented so Linux integration should be simple. You didn't mention if you wanted ASI input/output or ip!
Scheduling: There are plenty of solutions around. We just bought cheap software from a company - again, pretty box running just linux and some custom software.
Running a TV station on Linux? Incontheivable!
Yes there are multiple alternate OS broadcast applications. I'm president of one of them, Building4Media. An associate mentioned this thread. We have about 65 of our 160 tv networks running our automation platform using the Mac platform, for example. Many of these are major networks (CNN, NFL, CSTV, BBC World Services etc.) There are other providers of non-windows systems as well. Note that we find the Mac broadcast applications usually have some PCs around, for example doing news (ENPS/iNews etc) so cross platform operation has some advantages. For your simple schedule processing playout application, several non-windows systems can apply.
When I was at MIT, they had some cute no smoking signs, like "Smokers will be nuked blue" or "You are permitted to smoke, if you file an environmental impact study 60 days prior to the show, and if anyone complains, you can't do it."
When working on the pre-show system they had a guy taking a sledge hammer to a car, having an elephant sit on the car, and then seeing it it looked like a car in the magazine.
Some of the new turn off your cell phone adds are cute.
Fight Spammers!
They sell one-channel versions and four-channel versions, at $5K and $11K respectively. Rackmount, up to 1.6 TB. Run Linux and 'mplayer'. Includes scheduling software in a web interface, lower-third graphics, etc. http://www.princetonservergroup.com/
Curator of the Jefferson Computer Museum http://www.threedee.com/jcm
If you spent more time on /. you would know that ANYTHING can be done with Linux.