 |
 |
|
|
|
Search Pot-TV -> | Wednesday, March 3 |
|
|
|
|
|
|
Search Pot-TV -> | Wednesday, March 3 |
We operate on a busy schedule and a small budget, so we can't work on this stuff all the time, and we can't afford to buy the latest, expensive whatever. We prefer linux and open-source software solutions whereever possible, but presently we use both Linux (servers) and Windows (video workstations).
This page is obviously a work in progress.
Pot-TV Projects
Pot-TV Video Production Technical Pipeline
Take 1: gs2lta
Since most (all) of our video archives are in Realplayer, and since Real
offers a way to stream a looped playlist of files, we thought this would
work. The application is called "g2slta" and it doesn't work well. All files
must be encoded with the same specs (frame size, encoding rate), and our
archives aren't. The application is not easily scriptable, and requires
that we stream from our video streaming server (off site) to the studio.
This way we stream from the same, complete updated archive of pot-tv shows
(rather than always downloading the newest shows to the loop box) but we
have to pay for the streamed data 24-7 from the server to the studio (so
we're charged twice), and if the network goes down so does the video loop.
This would have been OK if realplayer was capable of playing Realplayer
files fullscreen for an extended period of time, but it is not. Realplayer,
regardless of version or OS, seems to crash after playing the stream for
several hours, at most, a day.
Take 2: SMIL
Real supports SMIL, a markup like HTML for Synchronizing Multimedia. We
tried using SMIL to compile playlists on our streaming server, and have a
real application at the studio read and loop through the SMIL playlists.
We wrote a script that pulled random (or not so random) shows from our
database and compiled them into a smil file for reading on the server. Real's implementation of SMIL doesn't work as it claims it does, and it
doesn't work consistently. We enountered many problems with SMIL, and again
the same problem with realplayer; it can't maintain a loop for longer than a
few hours, a day at most. This technique also allows us to use the main,
complete realplayer archive, but still requires the network, and network
bandwidth feeds. On boot a computer could launch realplayer on the SMIL loop
link, and whenever Realplayer crashed someone at the studio could restart
the loop by clicking the link on the desktop, but Real doesn't allow you to
start the application in fullscreen from a command line, so the process
couldn't be fully automated.
SMIL has some nice features, however, and this was SMIL ver1, since that time a newer standard of SMIL has been released. SMIL made adding extra information to the video stream easy, like tickertape news info, CNN style. But automating SMIL files from the information we had available in the db and having them work well, and reliably, seems beyond that version of SMIL. We like a lot that SMIL can do but I haven't seen any good implemenations for professional and reliable video playlists.
Hardware and OS
This loop player ran on whatever spare
equipment we have in the studio, originally a 400Mhz Pentium II. Realplayer
was running on a Windows ME,2000, or XP. The video
output was directed to a ATI Rage 128 with a composite video out, which was
then run from the studio to the TV's composite (RCA) video in. Sound was
done the same. Well, windows is not stable and not easily set up for this
custom work. The TV out often would turn off after a reboot and would need
another reboot (after accessing the "control panel") to reactivate. Linux,
on the other hand, was very difficult to get to work with the ATI's TV out
(using the framebuffer fbdev device), and wouldn't play realplayer
fullscreen. However, we found that a SVGA->composite out box made a more
reliable and cross-platform solution, and it allowed us to adjust the video
signal for the TV. Since running RCA composite over a long distance to
multiple TVs made for a degraded signal, using an RF modulator we inserted
the video and audio as a composite RF signal onto coaxial cable, so it shows
up "on cable" as channel 3. The co-ax allows for much better lossless
transmission over the wire to multiple TVs, but we may need an RF amplifier
if we split the signal to more TVs. Running the loop on linux also allowed
for more scripting and auto-initialization, and allowed the video loop
computer to also act as a file server.
Take 3: MPEG1 and VLC
At this time the only option for playing realplayer files was realplayer,
and realplayer was impossible to work with; no command-line options,
instable, no fullscreen video mode (in linux). We did, however, have (an
incomplete) mpeg1 archive, and mpeg players are plentiful, configurable,
and stable. So the loop machine (sativix) was converted into a Samba file
server to accept mpegs from Chris's editing machines, and this archive was
pooled to create looped playlists for our video loop. The problem with
mpeg1 is that our archive is incomplete, and these files are not tied into
the show database (yet) so we can't make playlists based on show content.
Mpegs are also a lot bigger than realplayer files, so we needed more storage
space. Two (or more) players were available, VLC from the VideoLAN project, and Mplayer. Mplayer is an excellent player,
but seems more intended for home users playing DVDs, whereas VLC is coming
from a project intended for broadcasting, and it's playlist funcitons are
more polished. So we now have a script that runs when sativix boots, that
runs a script that generates a playlist of about 20 shows from our available MPEG files. Sometimes
VLC will crash or hang, but the script can check for this, and so it
periodically restarts a new loop (with a fresh playlist) if VLC is not
running, and also every 8 hours just in case. This works quite well, but
we're continuing to develop the project.
Take 4:
What the store and studio would like is to have the loop pre-emptable, so
that they can select a show (or shows) from the archives and have these take
priority and play immediately (or just next in the loop) when desired. To
do this we've hooked up another monitor to sativix for the VLC video output
(right now on X but probably better with the framebuffer drivers), and the
main monitor can display the show database in a web browser, so the store
staff can select and play shows from the database in realtime. Two problems here. One,
we need to work VLC so that it can take a stream of file titles rather than
a playlist, so that it can stop one file and play new files with seamless
video. I believe VLC allows for this but there doesn't seem to be much
documentation on their playlist features. Actually, the key to this is
VLC's remote control rc interface. This thread in VLC-devel shows how to
play files from crontab. The second problem is that the
MPEGs on sativix aren't referenced by the show database, and unfortunately
the file names are often different than their realplayer counterparts. So
we need to run either a local version of the show database and hook in the
MPEGs to the show entries, or start being able to play realplayer files
also. Playing realplayer files with a linux-based, non-realplayer player is
now possible with the new Mplayer, which uses windows real codecs to play
realplayer on linux. Mplayer still seems less than optimal for looping
these files for the video loop, but hopefully their work can be incorporated
into VLC so that VLC can play old realplayer files also. We wait and hope
(and keep working).
Take 5: Mplayer
I've replaced VLC with Mplayer, the
amazing linux video app from Hungary. Mplayer supports a similar
command-line interface like VLC as well as a scriptable input for custom
front-ends, and it also supports Realplayer codecs, which is great for our
application. Mplayer is unfortunately not seamless when playing video
playlists full screen with the x11 output, the video drops back to the
desktop when changing files. This is poor behaviour for our broadcast/display
application. The commands for the playlist don't seem to support adding
files to the playlist either (neither did VLC). Realplayer seems to play
very slow on our machine, which I think is a 700Mhz PIII.
We proudly use Peer1 Networks for all our bandwith needs... |
| WWW.POT-TV.NET |