Tuesday, November 28, 2006
Apache, php, MySQL Installed
Server is Up
Wednesday, November 22, 2006
Proposal Submitted/Approved
Once we get a temporary computer, loaded up with LAMP, I can start to address the backend issues. I'll need to do quite a bit of searching and find out what tools are out there to transmit and finely-control output of mpeg video to a video card. I suspect it will probably be pretty easy to just export a single file to a video card, but then what? How do you know when it's done being exported? We'll need to know right down to the correct frame so we can start outputting the next MPEG file to video.
Ideally, it will be entirely gapless, but it may be impractical to have the first frame of the next clip ready (considering hard drives spin up, and a host of other factors) after the final frame of the previous clip had been shown for exactly 1/30th of a second. Fortunately, clips almost always start and end on a black frame (usually a fade out, fade in) so that a minor delay in switching clips won't be noticed (this would tend to imply that even professional broadcasters expect a delay in between programs). There are shows/episodes at TUTV though, I've been told, that are split into multiple MPEG files, yet represent consistent video and are always shown sequentially. I'm not sure what we'll do with these - it might make sense to combine them into one file.
We should also figure out the optimal settings for the MPEG files we'll be using, so that all future MPEG files can be exported in this format.
We also need to look into whether the video card that comes with this new computer can actually be used to test video output. On our final server, the broadcast output video card will obviously not be the same video card that is used to view the console. On the temporary server, we would probably have to opt to forgo console access just to access test video. That's a rather unfortunate tradeoff. We may have to buy an additional video card to test everything out, but it will probably have to be a PCI video card seeing as the AGP slot will be taken up. To further complicate matters, Linux isn't known for it's support of a wide variety of video card drivers. We will, for obvious reasons, need to make sure that whatever video cards we use work well on Linux. The video card we ultimately buy will need to support a resolution equal to or better than the video that will be shown on home/dorm room TVs. We may also want to look at other options than a video card for outputting the broadcast content. They could include firewire output which would then be passed through a converter box.
The Proposal
Independent Study: Designing a new Broadcast Management Interface for TUTV
Background
Since 1997, TUTV,
The TUTV station feed is generated and managed by a series of video components located centrally in the station’s office in the second floor of Curtis Hall. Primarily, the station’s main video output is controlled by a 16x2 Port Audio/Video Router. The router is then interfaced, via a serial digital interface, with a Leightronix Television Automation Server. This Leightronix server operates as the central controller for the entire TUTV Television Channel. Through multiple serial interfaces, the server controls the assorted playback devices attached thereto, along with the router, to ensure that, at their scheduled time, TUTV programs are played and routed through to the public.
All scheduling for the Leightronix server is performed through a proprietary interface. Unfortunately, this has caused a history of problems at TUTV, due to the relatively high learning curve required to operate the scheduling interface, as well as the tediousness inherent in manually coding the weekly schedule in the Leightronix’ proprietary programming language.
For the vast majority of TUTV Programming, the Leightronix interfaces with another server, called the ‘Firefly’, which stores a portion of TUTV’s program archive on its hard drive in MPEG format, and plays it back, via composite video and balanced audio output, on demand as requested by the Leightronix server. An additional, separate, spectrum of knowledge is required to maintain the program archive on this server. Unfortunately, at the same time, the Firefly offers few capabilities for the easy and centralized management and recordkeeping of TUTVs program archives. This is of special importance due to a recent push by TUTV to digitize and computerize their collection of tapes of previous shows.
When archived TUTV programming isn’t being shown, the Leightronix server normally routes an Electronic Bulletin Board to the channel’s program output. This Bulletin Board consists entirely of a Microsoft Office® PowerPoint™ Presentation, running in a loop and being exported through the S-Video Output of a Microsoft Windows® computer’s video card. This is suboptimal, both in the sense that the video quality coming from this setup is not very high, and in the fact that the computer that is displaying the PowerPoint™ Presentation is also used (and better suited) for other tasks, including performing scheduling on the Leightronix device. In addition, the very use of PowerPoint™ allows for the use of only a very rudimentary slideshow as the content that TUTV is broadcasting 90+% of the time.
The Task
It is hoped that, by upgrading TUTV’s broadcast system, management of the station’s program scheduling can be made simple and efficient, while allowing maximum flexibility for the scheduling of a variety of programs, into a variety of time blocks.
Most importantly, therefore, is that a new TUTV Broadcast Management Interface provide a simple to understand way of scheduling TV Programs into various broadcast timeslots. This necessitates the creation of a database schema that contains information regarding each program in TUTV’s video archives, which would allow programs to be easily located and inserted into the schedule.
This is currently not done, and assembling this database will constitute a significant undertaking, even after the requisite interface is established. However, after this is all said and done, each item in TUTV’s archive database will be linked to a certain MPEG video file, allowing an assortment of other information to be likewise retrieved when a certain item from the archive is queried. Most importantly, program duration will be easily accessible as a data value and therefore capable of being intuitively integrated in the scheduling interface. After all programs already in the archive are detailed in the database, it will also be important to establish an interface for the easy addition of new programs to TUTV’s archive.
The scheduling interface itself, ideally, will be a very easy to use system with a drag-and-drop calendar interface, and will allow for the simple creation and management of TUTV’s program schedule. A properly designed interface will also make it possible to assign a certain series to a certain timeslot, and have the server display the next episode in the series in sequential order. The ease of use of this system will also, it is hoped, remove any factors that may currently make the scheduling of a greater number of programs inconvenient.
The Planned Approach – The Server
Intuitively, the simplest and least-intensive approach for installing a new TUTV Broadcast Management Interface would be to create a wrapper in front of the current interface and add a database to expand the functionality of the interface. While this route is still being researched, it seems unlikely that an attempt to do this would bear fruit, as even the protocol for updating schedules on the Leightronix server in Leightronix’s proprietary language appears to be proprietary and undocumented.
Therefore, the remaining options are to either find a Leightronix-like replacement that offers us the ability to wrap in our own user interface, or to design our own Leightronix-like server from scratch. The latter option, though perhaps ambitious, seems to be the only course of action likely to offer success.
In order to accomplish the task of building and designing a server interface from scratch, we would first need to acquire and assemble a computer. (Current TUTV computers cannot be used because they are in use, and also do not meet the specifications that our server would optimally have.) The main requirements for this computer would be for it to have a high quality, dedicated video output card, as well as a dedicated sound card. It should also have support for some variety of high speed data transfer for an externally attached RAID 5 array of sufficient size to hold TUTV’s video archives in MPEG format.
The Planned Approach – The Front-End (Web Interface)
The computer would be loaded with the Linux operating system (such as RedHat®), as well as a well as database (such as MySQL®), HTTP Daemon (such as Apache®) and Server-Side-Scripting (such as PHP®) software, which would allow for the storage and manipulation of scheduling data as well as the contents of the TUTV archive. Such a setup of Linux, Apache, MySQL and PHP (referred to as LAMP) is obtrusively common in the computing world, and should offer no pose no major problem. The vast majority of time at this stage would be dedicated towards the time consuming process of programming the PHP scripts that operate the web-based front-end of the TUTV Broadcast Management Interface.
The Planned Approach – The Backend (Broadcast Interface)
The major challenge, for the student endeavoring into this Independent Study project at least, will be the creation of a stable and flexible backend to the TUTV Broadcast Management Interface – in other words, the software that actually reads the schedule, plays the correct video, outputs it, and routes it to the program output. This poses a significant challenge because software must be made that is capable of running continuously, while constantly maintaining an up-to-date copy of the schedule, so that program video reflects the most recent copy of the TUTV Program Schedule. There is also much less flexibility in terms of stability for broadcast server software – if the server software ever crashes, or encounters an error, and is not able to correct itself, the channel will cease broadcasting. The server also has to be extremely precise in terms of time, because programs often will need to stop and start at a precise second (or even 1/30th of a second).
By far, the potentially most difficult element of this server setup will be playing the required videos and maintaining the level of control over playback that is necessary in a broadcast environment. Linux, for all its stability and other inherent benefits, does not have the best support for video drivers, especially on the newer technology that would optimally be used in this situation. This planned approach, however, is not a venture into previously uncharted territory. There has been much success with video output under Linux, provided that the right software and hardware is used. Perhaps one of the best sources of guidance in this regard will be the software package known as MythTV. Billed as a TiVo replacement for Linux, the open-source MythTV project offers a wide variety of features and provides a significant degree of control over the video that is outputted through the chosen device. Although this project in it’s full form can’t be integrated into TUTV’s system to meet its needs, it serves as proof in concept that TUTV can use a computer with the Linux operating system to achieve this functionality. Since it is open source, the project can be thoroughly analyzed, and serve as a source of knowledge for how MPEG video can be outputted through a video card in a controlled and effective manner. Other programs and utilities also need to be extremely thoroughly researched and experimented with in order to attempt to find software already in existence that would meet our video playback needs.
Points that will need to be closely followed include ensuring that immediately after a program ends, the next item in the schedule is processed, even if that means rerouting a loop of an electronic bulletin board to program output. Also, in the case of back-to-back programs, or single programs that are split across two files, the transitions between the two must be seamless (and thus precise to the frame). If two programs span different source devices (i.e. one is on the computer in MPEG format, and another is a VHS tape being rolled-in live) sufficient pre-roll must be used on the second source device to ensure continuously high quality program video.
With regard to router and VTR serial communication interfaces, there should be very little difficulty in controlling the two types of devices through the Linux computer, as it has inherent support for serial communications. A small script could easily be made that would accomplish the task of routing various devices on the router and cueing up and playing a tape deck.
Other Stations
Tufts, conveniently enough, is surrounded by several communities that deliver Public Access Television to their residents. As they operate on budgets similar to TUTV’s and broadcast the similar things – a bulletin board interrupted occasionally by scheduled programming, it was hoped that insight into how to best create a Broadcast Management Interface could be gleaned from these similar stations. Unfortunately, e-mails sent to Somerville Community Access Television and tv3Medford have not received replies as of the submission time of this proposal. Their websites, however, provide more information as to how these stations operate. Primarily, it seems, both stations primarily serve their communities through the cablecasting of resident-owned videos per the requests of community members. In contrast to TUTV’s operation, the Somerville and Medford Public Access Channels do not appear to repeat videos, or attempt to digitize and archive them. Instead, it seems, they broadcast by routing a video deck to their broadcast output and programming their broadcast schedule as videos are added to the lineup. While this practice likely serves these stations well, this practice, if implemented at TUTV, would be burdensome given TUTV’s vast inventory of archived programs, as well as the inherent wear on both tape decks and the tapes themselves.