Re: [Fed-Talk] QTSS implementation at Carswell Field (ANG)
Re: [Fed-Talk] QTSS implementation at Carswell Field (ANG)
- Subject: Re: [Fed-Talk] QTSS implementation at Carswell Field (ANG)
- From: Michael Walsh <email@hidden>
- Date: Sun, 3 Oct 2004 12:21:47 -0400
Does it bother anyone that the underlying, circa 2001, QT Broadcaster
API can handle only one broadcast per box -- Yes, just one. -- before
you have to move to more costly, third party broadcaster applications?
With Apple's dual G5 Xserve architecture you have these phat boxes and
phat throughput by which you can handle live encoding and broadcasting,
but no way in the underlying API to directly broadcast more than one
stream at the same time thus forcing you to unnecessarily increase your
server foot print, and in the end result making you less interest in
leveraging Apple's top of the line servers...
-Michael
----
Michael Joseph Walsh
Chief Technical Officer, EchoStorm, Inc.
www.echostorm.net
work e: email@hidden
personal e: email@hidden
p: 757.553.7782
"I've seen things..."
On Oct 2, 2004, at 5:49 AM, William Cerniuk wrote:
While I was aware of what happened at the end, I had no idea what lead
up to the event. Very informative post, and thanks!
MAJ H broke some real important ground. There is a viable application
of the QuickTime streaming server for military post CCTV, especially
in replacing legacy systems. Consider that a high quality MPEG-4
video can be multicast across a campus LAN in no more than 256Kb/s and
only one stream of it for 100s if not 1000's of simultaneous viewers.
This can also be extended into sending the same single stream to
another post for re-multicasting it on that post's LAN.
This model is how we produced the PERSCOM recommissioning to HR
Command last year. Only three video streams left the Army Chief
Technology Office going to different states in the US yet 2300 people
viewed the event which took place in the courtyard of the Pentagon.
This is a similar model to what we use in the Internet-syndication
Soldier's Radio and Television radio signal (not talking public
streaming product).
Personally, I see a huge potential to save the military/government and
especially the tax payer buckets of money in taking this approach.
Job well done MAJ H!
Respectfully,
Wm. Cerniuk
Wm. Cerniuk
Army CIO/G6/NETCOM/CTO
Technical Manager, Army Homepage
voice/fax : 877.529.5730
email : email@hidden
"Ya never ask a man where he is from. If he is not from Texas, he
will be too embarrassed to say; and if he is from Texas, heel be too
humble to say-so". - Wm. Tollesen
On 28 Sep 2004, at 10:15 AM, Hubert, Keil, MAJ wrote:
Howdy.
The short explnation: We just got done introducing QuickTime
streaming media
on our LAN, and we couldn't have done it without the help of Apple's
boffins. If you're considering toying with streaming, talk to these
guys
first -- save yourself the headaches that we experienced.
The rest of the story:
Back in the day, Carswell Field was lauded for having a state-of-the
art
television delivery system. A complex system of cabling and special
(proprietary) equipment was purchased when the new buildings were
stood up
in 1997-99 to allow every Windows NT desktop to be able to view the
current
CCTV broadcasts in a window on the desktop. It worked great ... for
about
two years. And that was several years ago.
Since then, our CCTV equipment has degraded. Laser splitters burned
out,
cables broke, PC interface cards became obsolete, and there were no
trained
support personnel to be had in the Guard for love or money. In FY03,
we paid
a high end consultant $50,000 to fix the system. He took our money
... and
left the system far worse than he found it. Considering that his was
the
company that installed it to begin with, this didn't bode well.
After that fiasco, we made the decision to walk away from 90% of the
CCTV
system (the PC component) and shift to four channels of live streaming
instead.
The first obstacle we had to overcome was the lack of equipment. We
bought a
refurbished XServe G4 from Small Dog Electronics and requested funds
to buy
an encoder to prove the concept. This last summer, we discovered that
Hurlburt Field, FL was going to send all of their Power Macintosh G4s
to
DRMO. We asked if they'd transfer them to us, instead. When they
agreed, we
sent a driver and GOV to fetch them.
This last month, a series of CCTV system failures had angered our
executive
caste the point that they demanded a fix before our September drill.
We set
off to have one channel of MPEG4 streaming operational. We had four
battered
(but rebuilt) G4/933 encoders, one XServe QTSS server and three weeks
to
make everything work.
The next problem was to get the server running correctly on the
network.
After extensive coordination with Bob Fimiani, Apple's Account
Manager for
the Navy and Air Force, we were able to negotiate a one-day whirlwind
consulting engagement with West Decker, a brilliant engineer from
Apple's
Austin compound.
Mr. Decker gave us ten hours of his time, and attacked our queue of
problems
with enthusiasm. By the end of the day (a holiday for our unit, so we
were
free to devote the entire day to Apple Engineering), we'd corrected
the LUN
masking problem on our Brocade Silkworm 3800 fibre channel switch,
we'd
ironed out the problems we'd had using our XServe RAID units with our
HP
Proliants, we'd corrected our 10.3.5 Open Directory services, we'd
fixed our
web hosting problems and were configured to begin QTSS streaming
services.
Not bad for one day's effort.
We spent the next two weeks struggling with the commercial and open
source
QTSS manuals. After two weeks of building and rebuilding, we were
able to
get a unicast stream of the video signal from the encoder to the
server, but
nothing thereafter.
We finally hit the last day before the deadline. In desperation, we
called
Bob Fimiani. He got us hooked up with William Cerniuk, the engineering
boffin behind army.mil. This is a man who speaks fluent military in
addition
to idiomatic streaming-speak. In the space of two hours, he'd guided
us to
bring up a sucessful, 300 kbps, multicast into our production LAN.
The final obstacle was a vexing mystery: no matter what we did, we
had no
audio signal to accompany out video stream. Mr. Cerniuk stayed on the
line
with us until we isolated the problem down to a bug with the video
interpreter itself. The Canopus ADVC-100 that converted our RF signal
to
IEEE 1394 didn't use drivers (just plug it in, and QT Broadcaster
accepts
its signal immediately), and there exists a bug somewhere between the
Conopus hardware and QT Broadcaster. The problem was that it encoded
audio
at one step below your selection: if you selected 44 KHz, it encoded
at 22;
if you selected 22 KHz, it did encode ... at 0 kbps. Once that one
setting
was changed, we were golden.
The next night, we brought the Wing's intranet home page up on the 25
foot
screen in the main conference center for the pre-drill staff meeting.
One
click off of the main page brought up an embedded QT Player within our
intranet format. Ten seconds later, we had live CNN. The commanders
were
happy.
The point to all this is that while you may be better staffed and
equipped
that we are in the ANG, you may be hard pressed to introduce streaming
services -- or any OS X services -- on your network without some kind
off
help from the Apple support team. We could not have accomplished this
eleventh-hour save without them. Thanks to all who participated.
Cheers, and good luck,
Maj H
Maj Keil Hubert | Commander | 136th Comm Flight | 817.852.3322
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Fed-talk mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Fed-talk mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden