Good afternoon everybody. My name is Steven Tona. I work on the QuickTime product marketing team and I deal mostly in the streaming side of things. And today's session is going to be a really good session. It's going to be two case studies. One from the University of Wisconsin who has set up an IPTV-based streaming solution for their entire campus network.

And that gentleman's name is Dave Schrader and he's going to walk us through exactly how they built that and how they've actually incorporated a lot of the Mac OS X technologies to provide a really TV-like experience on your computer. And then after Dave is going to be Nate Caplin from the American Electric Power Company to talk about how they're using and how they've built out QuickTime streaming services for all of their internal corporate communications. So without further ado, I'd like to invite Dave on stage to kick it off. Thanks Steven.

Hello, thanks everyone for coming out today. Ready for the campus bash tonight? Yeah. I'm Dave Schrader, University of Wisconsin-Madison, and what I'm going to be talking about today is a system that we built to deliver cable TV to the University of Wisconsin campus using an IP based system.

So we wanted to replace an aging actual coaxial cable TV network that the University had been operating for pretty much the last 20 years, and we wanted to kind of piggyback on a large network upgrade initiative that we had in progress. Now some of you may have heard me speak last year.

I talked last year about this as well, but we have a lot of new stuff going on and that's some of what I'm going to talk about today too. So for those of you who were here last year, some of this stuff is going to be a repeat.

But we looked at a lot of options from different vendors. Video Furnace, Microsoft, Reel, some other MPEG based solutions, and we eventually decided on QuickTime technologies. And once we decided on QuickTime, then it turned out that Apple's server was not the best solution. So we decided to go with the QuickTime solution.

And we decided to go with the QuickTime solution because we thought that the QuickTime solution was the best solution for our customers. We thought that the QuickTime solution was the best solution for our customers. We thought that the QuickTime solution was the best solution for our customers. We thought that the QuickTime solution was the best solution for our customers. We thought that the QuickTime solution was the best solution for our customers.

We thought that the QuickTime solution was the best solution for our customers. We thought that the QuickTime solution was the best solution for our customers. So we're going to talk about some of the decisions we made in coming to the pilot that we deployed and how we actually went about that deployment and the hardware and software that we used.

So here's some of the background. We operated this coax network that we call the Academic Television Network, or the ATN, for many years. And in addition to some local university content, things like lecture halls, our own production facilities, and things of that nature, we also had some local cable TV channels.

And we had an agreement with a local cable operator that's been acquired and changed names so many times and is now Charter Communications. And that agreement has stayed and was the basis for actually carrying the channels on our new system. And the new system we call the Digital Academic Television Network, or ATN, and our agreement with the cable operator carried over for these channels. So our main motivation for doing this was twofold. We wanted to... First of all, the old network was becoming really expensive to maintain. It was hard to find equipment. It was hard to find skilled cable television folks.

It was hard to have people crawling around in steam tunnels and repairing the equipment as it broke. And at this same time, we were upgrading the network, and we thought that it would be a good time to go to IP. But let's take a little bit of a look at the history that we went through in getting here.

So I'm going to blast through some of these. Bottom line is, in 1980, the university, we were operating a UNIVAC 1108 computer, and we were starting to get requests from various entities on campus to connect to this thing. And we realized that with twisted-pair copper, we would soon fill all the cable conduits in the computer science building where this was located. So we turned to an RF transmission system. That turns out was very similar to a cable television system.

And because it was, several departments approached us and started asking if they could put video on this network. And we allowed them to. And so that's when this all started. And then over the next several years, we went through various stages of upgrading the network. And in 1994, another important thing happened. And we actually operate a separate video network for our dorms called the RTN, or the Residential Television Network.

And that has the array of all of the channels that our local cable operator provides, all the analog channels, which is 77 channels. So most of our dorms are actually wired for coax, and that's how they get teased. And so we're going to be using that for our TV now. But the new buildings we're building, we're not wiring with coax. Everything is going to be network-based. Everything is going to be IP-based. So we needed a solution for that going forward.

One of the main things that we're doing is standardization. So we're going to standardize on management practices, equipment, monitoring, deployment-- everything that we can we're going to standardize on. We're going to converge everything to IP. This includes exploring things like doing video over IP, doing voice over IP, and retiring some of the legacy protocols that we operated like AppleTalk and IPX from the network, and use automation. Wherever possible.

The other critical change that we made, which was a difficult one, was we changed the funding model from bandwidth to people. So our new model is based on however many people a department has, and this is an ongoing billing, so it provides us with a revenue source to upgrade the network going forward.

And one of the other things that was critical that came with this new network and the consistency that we're able to deploy it with is support for something called IP multicast. And we're going to talk about that a little bit more later, but it's critical to deploying something like a service like this, in my estimation, because it allows you to deliver as many people can be listening in on the content as you want, and the overall impact on the network is still that of just one stream.

You can think of it as kind of picking up an extension in a house on a telephone, and other people are just listening in. There's not any more bandwidth that's being used. And for more information, Internet2, which is a consortium of educational institutions that operate this own separate network, Internet2 is also an organization, is one of the big proponents of multicast, and you can go to that URL for more information.

The Xserve solution that we ended up deploying, which you'll see in a moment, was a lot less expensive than dedicated products. So we had things like dedicated encoders from companies like Tanberg and Nviveo, which are professional, industrial-grade solutions. But they're about $30,000 to $50,000 per encoder. And that was really hard for us to justify if we were looking at doing something like 80 or more channels.

With the Xserve solution, we can do each channel for around $3,000 to $5,000, depending on the configuration. And some configurations, we can even do two channels per encoder, so that cuts the cost in half. And of course, the other thing, QuickTime Streaming Server, QuickTime Broadcaster, free. And another huge win for QuickTime, the client is free for Mac OS and Windows. So we have a major vendor commercial-supported player that's free, and we don't have to worry about the encumbrances of royalties and per-seat client licensing that we do. did with some of the other solutions.

And then a little bit-- some of the other corollary reasons-- QuickTime has some interesting capabilities that we can leverage in this solution. QuickTime Text Track allows us to deliver closed captioning content separate from the video. We don't have to overlay it on the video. When we went to other vendors and asked about how we're gonna do closed captioning, we were really surprised when some people's suggestions were, "Run two encoders for every channel, one with closed captioning and one without." And that seemed like a really crazy idea, so we knew there was a better way, and QuickTime Text Track lets us do that.

QuickTime Skins we're not using right now, but we have experimented with this in the past, and I think we're gonna go back to this in the future. Let's just deploy, you know, essentially a client list. I mean, the only client you have is QuickTime, but you don't have to download anything else, and we can have a custom interface presented to the end user.

And because of the granularity of this system, other uses of--it wasn't really a closed turnkey solution like some of the competitive products. So we--last year, I was telling you we were exploring some alternate uses, like, you know, doing a closed captioning search database for research purposes, video archival, and custom players, and this year, I'm happy to tell you that I can actually show you some of these things.

So here's what we deployed on in our pilot that's been up and running for over, for about a year and a half, two years now, and in a production capacity for the last year. We have an Xserve that is the head node for this system that's the web front end and does some monitoring and has some communication with the individual encoding nodes. And we threw a monitor and keyboard and mouse on it for local administration. This is in our rack. We'll show you pictures later.

And we have Xserve cluster nodes that we use as all of our streaming nodes. And those do the closed captioning capture and, most importantly, they do the encoding of the video and audio. And we have some support equipment that we use with each of these encoders, too. We use a rack-mount TV tuner and have analog video going into a FireWire converter. And that's how the video and audio gets into the machine. And then we have some closed captioning decoders that connect via serial ports. And there's all the exact hardware that we're actually using.

And one of the big moves that we're going to be making soon is switching from the dual 1 GHz G4 Xserves we have right now to probably dual 2.3 GHz Xserve G5s. And the major reason we're making that change is to support H.264. Now on this topic, I might mention that even though H.264 requires a lot more horsepower to encode live, we found that it requires about twice the horsepower to live encode. But the great thing is it gives you twice the quality at the same time.

So you can get a lot of data right. And I know that's kind of a qualitative thing, but when you see it, it does really make a difference. And the software that we're using, of course, Mac OS X Server, QuickTime Broadcaster. And QuickTime Broadcaster has the ability to do multicast broadcast directly from Broadcaster itself. So we don't even need any other applications. We just have Broadcaster configured on each client or each encoding server, excuse me.

And it doesn't even need a streaming server to support it. Broadcaster encodes, plants it directly on the network in a multicast format, and we're done. Apple Remote Desktop, of course, we use for monitoring, Server Monitor, and in our data center, we also use HP OpenView as a monitoring solution. And on the client, of course, we use QuickTime Player. But since we're using open standards, we can actually support playback on many other platforms.

We can use VLC on Linux, Solaris, or Mac OS and Windows for that matter. And many of the MPEG-4 compliant devices that are out there also are able to play back this content. When we were looking for set-top boxes, after the Mac Mini came out, we realized, hey, here's a box that's got DVI.

It's small. It's quiet. It's got a DVD drive. And it can play back this content, so why don't we start using that? So we are actually deploying Mac Minis in test deployments right now in essentially an appliance-like capacity. And we have one of these in operation right now and another one in test. And we have some interaction with the specialty player application that we wrote that we'll talk about later.

So... The other thing that we do on each encoding server is we want to set these essentially up like appliances as well. So here's kind of the general practices we use. Xserve boots, logs in as a broadcasting user. In our case, the user's called Dayton. Whenever anything goes wrong with the server, if some service hangs or if the server itself hangs and Watchdog or a hardware monitor is able to catch it, it's pretty good about just rebooting and coming back up. Now even though that's a rare occurrence, if something like that does happen, we want the server to obviously come back up and be in the state of doing what it's supposed to be doing, which is encoding and broadcasting.

Same thing with QuickTime Broadcaster. If something happens to QuickTime Broadcaster itself, we use a monitoring script that I'll show you on the next slide. So QuickTime Broadcaster started by a very simple Apple script with its configuration that it has on that particular client, which is very simple, and then it just starts broadcasting. Our closed captioning capture script is spawned by Watchdog, and if it dies for any reason, It just gets restarted.

And we use a cron job that runs every minute. That's a really short script that just checks to see if Broadcaster is running, and if it's not, relaunches Broadcaster. And even though these anomalies are a rarity and definitely not the norm, and we rarely see them, we do log to see when these things happen. It's good to know that they're there, because whenever anything does happen, we have confidence that the server is just going to keep going.

So, that's kind of a brief on this system. So what's new, especially for those of you who were here last year? And the huge thing that's new is QuickTime 7. H.264 is probably one of the most significant additions to QuickTime 7 and it is an amazing codec. Now, When you do static encoding for files that are just going to be on-demand type content, you can take your sweet time, run it on any hardware, and it's just a matter of how long you want to wait for how high of a quality you want the file to be encoded. When you do live streaming, you don't really have a choice but to live within the constraints of your processing power.

So H.264 is very processor-hungry, but we've found that on dual G5 configurations, we can do 640x480 or 720x480 depending on our input, 30 frames per second, the best quality setting of H.264, and... I think that's about it on that configuration. So it's, you know, essentially what you'd expect to be a very good quality standard definition broadcast in under 1.5 megabits a second. And that's actually really impressive.

Now the other huge things that QuickTime 7 brought, and along with Broadcaster 1.5, and some of you in this room may know what I'm talking about when I mention these things, but QuickTime Broadcaster historically, probably because of processing power that would be required in the past, threw out half of the vertical frames of the DV input.

And this is probably because back in the days of the, you know, blue and white G3, you'd be nuts to try to do 640 by 480 encoding. But now it's actually possible on the hardware that we have. So QuickTime Broadcaster has been updated and allows full frame input from a lot of devices that it didn't formerly allow it from, most notably DV.

Another thing that's new is Dayton Player, which is a Mac OS X native Cocoa application that uses QtKit in QuickTime 7 and just uses the native QuickTime frameworks that provides a TV-like interface to OS X. It gives a remote control and some informational overlays on the screen, things you'd expect from this type of an application. It makes people feel like they're using a TV and also has hooks that allow some of our classroom AV control systems.

On our campus we use NetLynx AMX AV switch control systems at the front of the classroom. These devices can send out just a Telnet command and the Mac Mini or whatever device is there can just listen on a port and the user can go up to the front of the room and press TV on our control system. That spawns the QuickTime player. They can touch CNN. Another command is sent. The player changes to CNN and the user doesn't even know they're using a Mac Mini or that it's anything other than TV.

Except for the telltale cue and the little buffering thing as the channel loads. And because we built our system in such a way that it was pretty open and granular, my organization, the Division of Information Technology, which is kind of the central IT body at UW, didn't even do this. Brian Deeth, who's an IT person in our School of Journalism and Mass Communication, decided that he wanted to explore with his faculty some research applications and we had a closed captioning search system that got developed, which we'll talk about in a little bit here too.

But Brian thought, "Hey, wouldn't it be neat to have a native Mac OS X application to view this?" So this was written and then provided to the campus community. And this is one of the great examples of the type of flexibility that QuickTime offers. And this was what I was just talking about a moment ago. We started doing text and actually video archiving as well. So several months ago we started capturing all the closed captions and all those captioning texts from all of our channels.

It's all indexed and inserted into a MySQL database. We also capture thumbnails every minute of the video and insert those into the database as binary objects. And a custom PHP web page allows the--provides the user interface for this and allows people to enter in search terms, search by times, search by pretty much whatever parameters they want, and retrieve the content.

And right now we're archiving video on a test basis. The video is retrieved using specially crafted smile URLs. And this demonstration really shows the potential for being able to do a campus-wide DVR or TiVo-like system. Why have people record it individually on their clients when we have 80,000 users, when we can just record everything centrally and then provide it to the campus? And this was also developed in cooperation with Brian Deeth at the School of Journalism. and this, we think, is going to be a great research tool.

So here's a typical Dayton node. We have our Xserve, we have a FireWire converter, we've got our closed captioning decoder, and we have a rack-mount TV tuner. In some of the boxes we also have a Miglia Alchemy TV PCI card. That's just a TV tuner. And that can operate completely independent of everything else. We could have nodes that only had the TV tuners in them, but we have some nodes that have all of the stuff that you see here.

So what does Dayton look like? There is our pilot rack. Xserve's intermixed with the rack-mount TV tuners, and they're not so deep. So what we found is that in the back we had one U of open space, and that's where we stuff our firewire converter and our closed captioning decoder. Now, you might not want to have all this kind of, you know, this much external support equipment for each of these channels, and that's why as soon as we could we started exploring the Miglia solution.

And for our next phase, what we're most likely going to be doing is getting Miglia cards for each of the servers, and then we're going to do away with all the support equipment and just have a completely internal solution, one U per channel. Here's our web page. This is what users see if they hit the web interface. This is an example of one of the channels just being played in QuickTime Player, an example of one of the channels with closed captioning.

And here is Dayton Player. So this is our new Player application. It's completely self-contained. It does not use QuickTime Player. It uses QuickTime and QTKit directly. And it, as you can see, has all the buttons you'd expect to find on a remote control and has the overlays you'd expect to find on a TV-type application.

We also have a presets drawer that comes out and we'll show you how that works. It's pretty nifty. One of the other things that Dayton Player does is since we go directly to the QuickTime frameworks and bypass Player, we can support full screen without QuickTime Pro. Here's our search page.

Here's an example of some of the search results and I'm going to show you some of that now. Can we switch to demo one please? Now, normally, before I start here, normally we deliver all this content exclusively via multicast on the University of Wisconsin campus. That means that, and we also use something called locally scoped multicast. So the public internet doesn't support multicast. So not only does that mean that we can't go over the public internet, the locally scoped addresses keep it on campus even between other campuses that do support multicast over internet too and that sort of thing.

So I set up a special unicast QuickTime streaming server. We're doing a multicast to unicast relay. And Brian's added some code to this, a nice debug menu that lets us kick over to unicast. Let me just select that. And of course we don't want just anyone to connect.

And if the demo gods are on my side, we'll have enough bandwidth for this to work properly. ...after more than three weeks in captivity... So this is how it works. You can see how some of these channel overlays and things like that work, information. Presets drawer. We have a couple of presets in here already. Let's switch to the weather channel.

Let's kick it to full screen. And so you can see what we have is a very watchable, standard definition quality TV broadcast in just over a megabit a second. text is very readable. And our concentration was really on getting text to be readable, getting text stickers to look right, getting motion and sporting events to look right. So that when people actually wanted to use this to really watch TV, they wouldn't feel like they were being short-changed.

And obviously, when you do a delivery application where you're delivering to a computer, you're kind of inherently limited in how users can watch the content. So right now, this is kind of being deployed in what I would call a normal TV capacity in just a couple of locations on campus where people are hooking up to external projectors or conventional TVs. But ideally, we'd like to get to a point where we can deploy some type of a standardized set-top box type solution along with this as well.

So the controller disappears when you have the mouse idle for a little while. And just come in here and get back out of full screen mode. Oh, and let's switch to-- and oh. Another thing I should say is all these channels are dynamically loaded from a MySQL database.

So as the content that's available changes, the channel list here and the channels that are available within the player itself will change. So I can use channel up, down, and here, and that sort of thing, or enter the numbers manually. Or I can just come down and select a channel individually.

And it loads up, when we're on campus on the multicast network, it's only a second or two for the channel to load and it's just a little bit longer here. So this is the kind of, this is what it looks like and I want to show you the closed captioning as well. Normally we do it right in the player, but when we're off campus we can't do it in the same way. So at least I can bring up the closed captioning that goes along with this. And there we go. So, thank you very much.

Normally this appears right in the window along with the video when you press this closed captioning button over here. But you know, this also demonstrates another thing that--oh, and here's how the presets thing works. This is pretty cool. You just click and hold like you do on a normal radio, and then it just gets added.

And you can put it away and you can also close these windows too and bring them back or from the window menu. And since this is all granular, we can have just the closed captioning running by itself. Not that that's useful, but, you know. Okay. So the other thing that I want to show is-- and by the way, any of you can go to this website, dayton.wis.edu, and look at "About Information" about this project. Not that that's useful, but, you know. Okay. So the other thing that I want to show is-- and by the way, any of you can go to this website, dayton.wis.edu, So here's our search page and, um... Oh, oops. Didn't want to quit.

Tied into our central authentication service on campus. Let's pick a couple of channels here, some news channels. "Start time 8 a.m., stop time now, and maybe we use White House as the example here, so."

Now Brian Deeth and I put this together-- and another testament to QuickTime is that Brian Deeth and I put this together in pretty much just our spare time.

Now George Cook of Apple was also instrumental in helping us work out some of the closed captioning capture. We have a script, a Python script that does that, that was done quick and dirty by George a couple of years ago. And it's still working. And that's actually what we use to insert all of our closed captioning stuff into the database too.

So here's our search results. And any of you who've seen video.google.com might think this looks very familiar. And you know what it does, but I would say that we thought of it first. So if I want to, and you know, so this is great that we can get the text returned back. Well, what if I want to watch this video segment here? I can click on the video. And there it is.

And actually, it looks like our bandwidth may not be on our side here. Let's just try it again. There we go. So if we go down here now and look at what we selected, and unfortunately, I wish that the video would... There we go. Okay, so... So if you look in here in the text, you can see this is that video segment that we just brought back. And this is only a one-minute chunk. Well, what if you want to do, let's say, yesterday... 3:00 p.m. Yesterday, 4:00 p.m. No search terms. And aggregation, one hour.

So we're going to get back that entire hour, and this brings up another interesting opportunity. If you want to just read a show and skim through the show, you can. There is the whole hour right there. But also, here's the entire video for that hour. So this really brings up the possibility of being able to do a campus-wide video archival system and we can build an interface to this that makes sense, that people could even have tied into a schedule and go say, "I want to watch Law & Order from last Wednesday," and that sort of thing. So that is Dayton Search. And if we could switch back to the slides, please.

So going forward, where are we going to go with this? We are going to move to the Xserve G5s and we're going to go to H.264 as our encoding platform. We're going to move to QuickTime 7 as a supported player, especially now that a QuickTime 7 public preview is out for Windows. Back home, some people have already started testing that with our H.264 test channels. Continue to develop on our text and video searching.

We're in the middle of trying to do the legal wrangling necessary to expand to 77 channels and we think that we're in good shape there. And actually we just had some news from our campus legal department. We were concerned about whether or not we could really do this image and text and video archive on campus. And our legal staff at the university has told us, basically just do it and tell the cable operator that we think that it's legal.

And... And along with some of the fair use provisions, we feel pretty confident that the content can be archived for 45 days before any copyright owner actually has to be asked. Now obviously this gets a little bit dicey, but we're delivering this content only on our own campus. So we're going to continue to develop the Dayton Player and one other thing that we did pretty neat, iChat.

You can actually invite

Who to contact? Dave Devereaux-Weber is the project manager for Dayton. He was unable to make it here. He's one of our network engineers. Me, I'd be happy to field any questions from people. There's my email address. And Brian Deeth, who is in the front row over here and will be here afterwards to answer any questions you might have. For more information, you can visit that website. That concludes my portion of this presentation and I'll pass it over to Nate Caplin of American Electric Power. Thanks.

Hello everybody, I'm Nate Caplin from AEP in Columbus, Ohio. Today I'm going to be talking about QuickTime being used for an enterprise streaming application within a large corporation on an intranet. I'll tell you about some optional webcasting solutions. We'll be talking about multicast, kind of like Dave did. I'll also be touching a little bit on the new auto-bandwidth detection feature in QuickTime 7. And I'll end with some advocacy for a few changes I'd like to see.

Some of the things you'll learn are how QuickTime 7 and Tiger can fit well within an enterprise IT architecture, how to deploy QuickTime Player to a lot of Windows desktops. I'll show you our AEP TV video portal. We'll talk about how to webcast live H.264 multiple streams with Wirecast from a single computer. And I'll actually try to demo that if the demo gods help me out.

And a little bit on using auto-bandwidth detection. Technology framework for this is all of the Apple products plus Wirecast. Dave touched on some of the differences since last year. I might expand on that. Thank you, Apple, for taking the pro-nag from QuickTime 7. That helps us a lot.

Now if you can just do full-screen playback without Pro, that would be the next great thing. QuickTime Server 5.5 and Tiger, the auto-bandwidth detection is something that we're beginning to experiment with and we think has a lot of potential. As Dave mentioned, Broadcaster 1.5 now has full high-res DV capture. Wirecast 2 has come out since last year and it allows multiple H.264 streams on the same computer from the same source.

Some other developments, Compressor 2, part of the new Final Cut 5 suite, has distributed encoding. And Tiger and Tiger Server have new iChat AV features that will allow us to finally bring video conferencing through iChat AV inside of our corporate firewall and perhaps offer that as a solution to some of our executives.

So a little bit about who AEP is. We are the largest power generator in the U.S. with over 5 million customers in 11 states and over 20,000 employees in at least 400 different work locations. Needless to say, that provides quite a challenge for us to communicate with all of our employees. A little bit about who we are within AEP.

Interactive media is a function of our corporate communications department, which is responsible for our internet websites, our intranet website called AEP Now, our video portal called AEP TV, which I'll talk about here shortly, as well as 200 or more video projects per year and at least 25 live webcasts that we do per year, usually town hall style webcasts of management talking to employees with interaction from the employees to talk back. And our department is also responsible for the annual report and other print collateral.

Some of the reasons why we picked QuickTime to use at AEP are first, obviously, like most video departments, we use QuickTime and Max to produce most of our video projects. So using QuickTime as the delivery method is just a lot more seamless of an integration with our workflow. But some of the more important reasons are that QuickTime gives us a single player that we'll install on all the versions of Windows that are deployed within our enterprise.

With Windows Media Player, which we still support and used to rely on primarily, there are different versions required for different versions of Windows and patches and bugs and it's been a real problem. We really appreciate the clean, fast user interface of QuickTime Player. Some of its advanced features like instant on and scrubbing get rid of the buffering delays that our Windows Media users are used to. And our IT department even likes it because our servers are immune from the viruses and security threats that affect Windows media servers.

Of course, open standards are always a nice selling point and the new, excellent video quality with H.264 is really promising. So, how to deploy QuickTime Player in a corporate enterprise that's all PCs. Well, first you have to get a QuickTime site license unless you want to send everybody out to Apple.com.

Fortunately, this is pretty easy to do. The site license is available on Apple.com and it's free. You're going to need to test, obviously, on all of your desktop configurations to make sure it doesn't break anything that you need to use. But, while you're doing that, it's a good idea to set the preferences the way that you'd like, such as the Hot Pics movie, the auto-update, icons on the desktop.

And then you can create a disk image for new PCs so it just simply gets wrapped into any new PCs that are deployed. For existing PCs out there already without QuickTime Player, we used a product called LandDesk, which is a remote administration and network administration utility that our company uses to create a custom installer, basically a difference installer from a configuration without QuickTime to a configuration with QuickTime. And that basically allows us to forego using the standard QuickTime installer and prevent users from being prompted several times for information and for registering, that kind of thing.

And our website, AEPTV, uses BrowserHawk, which is a server-side utility that can detect any number of configuration issues on the viewer's PCs, including whether QuickTime plugin is installed and what version it is. If we detect that the user doesn't have QuickTime at a version that is required, and if the media is only available in QuickTime format, we prompt the user that QuickTime is required to view this, and we link them to the LandDesk installer, which is quick and easy.

But that actually gets to the last point, which is driving deployment with content. Our IT department wasn't very open to the idea of broadcasting out or forcing everybody to install QuickTime Player immediately, because it is a sizable download, and we're talking about thousands of PCs. So what they did agree to was that we could basically post some of our content in QuickTime format only, as long as it wasn't mission-critical content to start with, and that would basically drive the deployment of QuickTime. drive the deployment of QuickTime Player gradually.

So AEP TV, our enterprise video portal, kind of like Dave's DATN player project, except that this is entirely web-based and it's designed to float in a small pop-up window like you see here. It is the one place to come for access to all of our videos on demand as well as our live webcasts when those are scheduled. Videos are searchable by subject and keyword. We use the homepage, which you see here, to promote new content.

But there's also menus, as you can see, to access the video library. It's tied into our intranet website, AEP Now, for related videos that link to stories. It does collect viewer statistics, feedback. It allows viewers to email videos to other coworkers. What they're actually doing is emailing a link, of course, to download the video files to their hard drive for local playback and to order DVD and tape copies. And, of course, it's all driven by a database. backend. Let me go over and demo that right now. If we could please switch to demo three.

Great. So this is my PowerBook, and I'm going to have to demo this over our VPN because this is an internal network. But what I'll do And please excuse that I'm using Internet Explorer. It's because this was designed and tested for Internet Explorer on the PC, and it does have a slight incompatibility with Safari on the Mac.

So this is AEP Now, our employee intranet. It is the default home page for all AEP employees when they launch Internet Explorer on their PCs. Basically, it allows them to have access to tools and resources throughout AEP, and the main section is constantly updated news. As you can see, if there's a story that has a video linked to it or related, it has a little icon next to the headline.

If you go to the page for that story, there's a sidebar here for AEP TV, and if you click on that, it will launch up. The AEPTV interface, which, excuse me, let me do that again because I was doing something in admin a moment ago. There we go.

The APTV interface, as you can probably tell, is driven by Flash, so Flash 6 is required. We did that so that we could basically support some of these nicer menus and better builds. But basically when somebody clicks on a video link, it takes them directly to the page for that video where they see the title, they see a caption, they get some information about its duration, and there's a button for large or small.

Now this, having tested this in advance, I know that this isn't going to play reliably because the connection over the VPN from here is quite slow. But suffice it to say, if you're on our network back home, the video pops up and starts playing almost immediately. We do two sizes, a small and a large. The largest in a 16.9 situation, the largest 640 by 360, and this is a 16.9 video. Let me surf you around the interface a little bit more by starting at the home page.

This is where we promote content, including upcoming webcasts right here. The video library categorizes everything by typical subject. So nuclear, for example, here's a video about our Cook Nuclear plant in Michigan. If you go to the live webcast section, you'll see any scheduled webcasts, and the next two that are coming up are our earnings conference call for investors and our employee earnings webcast, which we always do following that.

If you go to More Info, for example, this is our live webcasting interface. Looks very similar to On Demand, except that the buttons are basically not available yet, and it tells us what time and the date and time that this starts. One of the unique things that we do on live webcasts is allow people to submit questions in advance and during the live webcasts.

So you could say, you know, "What do you think about coal generation?" We do allow people to submit things anonymously so that they can ask sensitive questions, and people often do. That's what makes it pretty good. We allow people to provide feedback on any video they've seen or any webcast. Let me real quick go back home.

We do allow people to download videos, so you can see this video is posted in several versions. And I could, oh, of course it's made for a PC, so you have to right-click on it. Excuse me. And one of the other neat things we do is the order tape.

We take orders here for tapes or DVDs and we fill those orders weekly. And we found this is a lot more efficient, of course, than sending out a bunch of tapes or DVDs to all these different locations for people to see who don't have computers or taking them by hand. What I want to do now is real quick take you to the back end of AAP TV, the admin interface.

Which is of course password protected. Not nearly as pretty, but it does the job. I'll go into the Live Events Manager and the most recent live event is scheduled up here at the top. You'll recall that I submitted a question for the employee earnings webcast, so we can go here and see what questions have been submitted. And there we go. It's right in there. During a live webcast, let me maybe take you back to the last employee earnings webcast.

And you can get an idea for the volume of questions that comes in and what this -- oh, excuse me, this is the current one. I meant to go back to -- here we go. There we are. Now, during the live webcast, the moderator on set actually views these on a PC, and as he's going through, he can mark these as answered, or he can delete them, or he can go in and edit them and even reorder them so that he can have them, you know, set up to ask an order. It also gives us a nice way to track all the questions, and our CEO personally answers all the questions, even the ones that don't get asked during the live events.

Our clip manager is where all of the on-demand clips are available. This takes a moment to load because there are so many in there now. We have it set to come up all on one page. But this may look familiar to users of QTSS Publisher, actually. It's basically a library of content.

It can be sorted by a number of different, you know, by name or by order of entry into the system. But one of the things that it does that we like is tells us for every video what formats are posted and gives us access to statistics. So for example, if I go back to the, oh, a video called Tools, Texas, English, I can go to Stats.

And see right away how many times this video has been accessed. I'm going to guess this one hasn't been accessed much because it's just a copy of a particular commercial that we've posted. This, by the way, would be a great feature for QuickTime streaming server to have. All right. If we can go back to the slides, please.

So, doing live webcasts. First, let me give a little advice for anybody thinking about doing this. As Dave would tell you as well, setting up live webcasting can be very dicey, so you should only do it for the right reasons, not just because it's cool. The right reasons are to have audience interaction during the live webcasts, two-way communications, or if what you're announcing through the webcast is really big news that everybody has to hear about at the same time.

It's important to promote it, or else people aren't going to tune in. By promote it, I mean do that through other media, that is, email, bulletin board postings, the company newspaper. Multicast. Multicast is really the only practical way to reach hundreds or even thousands of simultaneous viewers on a network. Otherwise, the number of Unicast streams simply overloaded.

If you need to reach hundreds or thousands of users on the public internet, since it does not support multicast, you'll probably need to contract with a content delivery network like Akamai. That's what Apple does, for example. It's important to post the archived version of a live webcast quickly.

People expect that, and a lot of times people can't tune in immediately during an event, but it's really handy if it's available 15, 20 minutes after it's over. Tracking viewers like we do with AAPTV really helps you to gain some traction with upper management about the usefulness of the webcast. What we found is that eventually, live webcasts become a vital part of the communications link between employees and executives.

So having a webcasting studio. We have a traditional video studio at AAP, which we call AAP Studios. You know, obviously the most important thing when you're doing a live webcast is to produce a compelling show in the first place. That means that ideally you should script things and you should rehearse things with a crew. You need to have high-quality lighting, audio cameras, and a video switcher. You can't just do this with a little DV camera on a tripod in a closet. It's not going to be very compelling.

Well, technically you could broadcast it. Nobody's going to want to watch that. The two-way interaction can be done through webpages like you saw us do, but it can also be done by phone call-in. And we enable that too, kind of like Larry King Live. To do the technical side of the webcasting, you're going to need the fastest G5 Power Mac that you can get your hands on with QuickTime Broadcaster or Wirecast. And if you want the very highest quality possible in your video and audio streams, you should probably consider using a third-party video capture card like those offered by Aja or Decklink.

Although thanks to QuickTime Broadcaster 1.5, you can actually get quite good quality nowadays from DV. The two solutions that you might consider, Broadcaster or Wirecast, Broadcaster's great. As you saw, it works well for Dave's solution where basically he's just making a single version of each channel. It's free, it's simple, but it is limited.

Wirecast, which is a commercial program for about $450, kind of takes things up a notch by offering multiple H.264 encoding from a single computer of the same source, and as well live into the stream to kind of use it as a virtual video studio switcher, if you like. We already talked a little bit about Unicast and Multicast, but obviously Unicast isn't practical once you get beyond a certain number of users. Some would say that you could use a lot of relay servers to accomplish that. You could accomplish Unicast to a lot of users.

Well, yes, you can do that, but it does cost a lot of money and is a real bear to set up. I think before you invest your time and effort in that, you should probably invest your time and effort in getting your network administrators to enable Multicast on your network.

Multicast looks a little bit more like this. Certainly is the easiest route if you can get it to work on your network, but it is going to require a little bit of persuasion with your IT department. Now there are a number of ways, you know, Dave talked about multicasting directly from the encoder and then having a unicast relay to reach some users on the public internet.

You can do that. One of the limitations there is that the encoder has to be on a part of the network that is multicast enabled, which can be a problem in our situation because sometimes we'll go to a remote location to do a live webcast, for example, for our annual shareholders meeting. So we set up unicast directly from the encoder to the server and then we relay a multicast to the network. We also are effectively providing unicast to the network from that server as well for anyone who can't reach it. receive multicast.

So, setting up a multicast relay. I'm going to demo this in a minute, so I'll kind of skip through these slides, but this is basically what it looks like. You're going to need to know the relay name, a destination type, and a destination multicast IP address. You can check with your network administrator to get a multicast IP address that is legitimate on your network, but generally it's anything in the range 239. You're going to have to set up, you're going to have to edit the relay, give it a name, set it to pull the stream from the server itself.

Here's the window where you get to actually set your multicast IP address and your base port number. The hardest thing right now in setting up multicast with QuickTime Streaming Server is the notion of creating a multicast SDP file. Unfortunately, there's no straightforward way to do this from within the graphical user interface of QuickTime Streaming Server, but fortunately it's not that complicated, even though this looks scary. What you're seeing here is the contents of a unicast SDP file, Session Description Protocol.

This file is generated by your encoder, either QuickTime Broadcaster or Wirecast. It contains some basic information about the settings of your live webcast, including the IP address and port numbers. To make a multicast file, you simply open this up and you change a few key values. Let me go back there again. Those values are basically the multicast IP address and the base port, and the port numbers for the audio and the video streams.

It can get confusing when you have SDP files with different names, some multicast, some unicast. I suggest that you come up with a naming convention. We use a naming convention where the files, you know, we have a low and a high and a 56 kilobit, and the unicast SDPs are UC and the multicast are MC. Simple.

One additional step some folks might want to take is to open up a multicast SDP file in QuickTime Player and to export a QuickTime reference movie for it. The advantage with this is that that QuickTime movie file can then be easily emailed around to folks, made available online, and it will always open in QuickTime Player, whereas sometimes SDP files can get hijacked by third-party players like RealPlayer.

Before I go to the demo, let me touch on Auto Bandwidth Detection in QuickTime 7. Those of you who have QuickTime 7 may have noticed a new automatic setting for the connection speed in QuickTime's preferences. This is the default setting in QuickTime 7 unless you change it. The way that this actually works is by using the current refmovie method, so it is backwards compatible.

Basically you make a reference QuickTime movie with make refmovie X, which refers to two or more QuickTime movies of different sizes, and you specify the bandwidth that each requires. In the past, this would rely on the user correctly choosing their connection speed and QuickTime preferences, which they usually didn't do, and so it wasn't very practical.

But as long as the user has QuickTime 7 player and they're connecting to QuickTime streaming server on a Tiger server, the player and the server do a little bit of a handshake at the beginning where a small cache file is downloaded to measure the speed of the connection and the best choice is chosen.

This will even work on a progressive download on demand file from a web server, as long as the web server supports HTTP 1.1 byte range. While the system does have some limitations, you know, it's not dynamic, for example, and the settings aren't that granular for connection speeds, it is a good start and it does work within the existing framework that we all know. Here's what MakeRefMovieX looks like. It's a very simple application, but basically you enter in the URLs for each version and you can set the speed requirement for each one. Okay, let's go to a demo.

Demo 1, please. Great. I'm going to bring up Wirecast here. What we're actually going to try to do is demonstrate a live webcast setup with a relay on the server and then receiving the webcast on the other machine. So what I have here, and I can't lift this up high because my FireWire cable isn't very long, simple Sony camcorder with a DV cam tape in it. The DV cam tape is our last live webcast that we produced. I'm going to turn off this headphones here so you don't hear it. But basically you can see this in here. I'm going to pause it for a moment.

In Wirecast, under Broadcast Settings, this is where the power really is in this program, you can have more than one stream set up at the same time. I've already pre-configured a few of them, but basically there are three streams here, one we call LAN, one we call DSL, and one we call modem. They are at 750, 250, approximately 250, and 40 kilobits per second, respectively. If you go in and edit one of them, for example, to 750k, You can see that we are using H.264 codec. We are doing 640 by 360 because this is a 16.9 aspect program.

And we are doing that at about 686 kilobits per second. The audio is at 64 kilobits per second, MPEG-4 AAC audio. So the total bit rate is about 750 kilobits. Nate Caplin Your mileage may vary, as they say, but I believe that at 750 kilobits or lower you can get very acceptable quality, broadcast quality, as long as your content doesn't have very high motion or text tickers like some of Dave's did.

There is an option to set up direct multicast from here if you want, but we've got a manual unicast going on. From each one of these, we then saved an SDP file, that unicast SDP file, to our QuickTime streaming server's media directory. I've already done this in advance to save time, but as you can see, there's one for the 40, one for the 250, and one for the 750. So I'm going to cancel out of that right now and close this. I'm going to hit Broadcast and hit Play on here.

As you can see, the processor CPU monitor is running pretty hot here, but it is certainly within safe limits. This is a dual 2.7 G5 machine doing three simultaneous streams. So if we can go over please to Demo 3. I'm going to disconnect from my VPN so that now I'm on the same network segment.

I'm going to start up QuickTime Player and open a URL to the Unicast version of this stream, which is basically the address of our QuickTime streaming server slash the name of the Unicast STP file. If all goes well, there we have a live webcast being received in H.264 at 750 kilobits per second. Now, I know this is all very qualitative, but I think that that looks pretty darn good for 750 kilobits per second.

Can bring up one that's at 250. We'll have to warn you that I know I don't think the quality on this one is quite where it should be yet, but I'm talking with Wirecast about that. Let me bring up the 40 kilobit one as well at the same time. One thing I have always liked about QuickTime Player is that it lets you open up multiple windows at the same time. Windows Media Player still doesn't let you do that. There we go. Okay, so we know that Unicast works.

Let's go over to Demo 2, please. Okay, so here we are. Let me hide everything else for the moment so we can concentrate. Here we are in server admin, QuickTime streaming under settings, and I've clicked on relays. To set up a relay, a multicast relay, let me go ahead and delete this one, and let's just make it from scratch. I'm going to make one for the 250 kilobit stream. So you add a relay.

I recommend calling it by the name of the stream and then just the word relay. It makes it simple. What you're going to want to do if you're unicasting to the server the way I am is to request the incoming stream. The source IP address is localhost. The path is just the name of the unicast.sdp file as it appears on the server, which is just qt250.sdp. There we go. You don't need a username or password for this.

So let's save that. Then we need to go over here and add the destination IP address. Now this is any multicast IP address that's valid on your network, generally anything 239.whatever. Pretty much any address is going to work, but you might want to check with your network administrator to find out a list of addresses they might be using at that time so you don't walk on top of them. I'm just going to pick out 231.1.1.10. You have to pick a base port number, and that can be anything 9,000 or higher. So I'm going to pick, say, 9050.

The TTL is time to live, and this is the number of router and switch hops that your multicast will survive out on the network. You want to make sure it's set up to a number at least as high as the maximum number of routers or switches between your server and an end user. I'm going to hit save. 9050 and .10. Now you have to remember this information. So QT250 was 239.1.1.50 and the port was 90-- was I right on that? 9010. Thank you.

Oh, no, I'm sorry. Very important. 90/50, right? Great. So now we've created our relay. Next we have to create our multicast SDP file. If you go and you start with your unicast SDP file, just drop that on text edit and open it up. Now this may look a little scary at the beginning, but the first thing to do is go up to this first IP address and just set it to 0.0.0.0. That was the address of the encoder, which is no longer applicable for a multicast SDP file. And then this is where the destination IP needs to go, 239.1.1.10.

Right here and just a little further down where it says video, those are the port numbers. This is where we need to use that port number we picked. The audio is the first, the base port number, 9050, and the video is the base port number plus two. "50-52. 90-52. There we go. And now you simply save this as a new file. I recommend just tacking on .mc, sdp, to the same folder.

Now, to the same folder, let me qualify that. The SDP file goes on your web server, not necessarily the same thing as your QuickTime streaming server. In this case, for this demo, I've set up this Mac OS X server to have web services turned on, too, and its home directory is the same directory as the QuickTime streaming server home directory. So an HTTP address will go to the same place. All right, that file exists. So now, if I come back over to demo three, please.

If all goes well, I ought to be able to access this multicast now. by accessing at http, same address as the unicast, but add the mc.sdp to it. Connecting, buffering, there we go. Live multicast. I had already done this ahead of time with the larger stream to show you what that looks like. And boom, live multicast of a 750k bit H.264 stream. In fact, we could, I believe, QuickTime player lets you receive multiple multicasts at the same time. Let's see.

Two multicasts and one unicast. Thank you very much. From a single encoder. Great. Okay, let me quit out of QuickTime player and I'll just stop this over here on Wirecast. There we go. All right, back to the slides please. Okay, what I talked about advocacy, there are always things that Apple can do to improve. They listen to us.

It's very important that you give them feedback so that they know where you're hurting and what they can do to make their products better. I'm not going to go into these in some detail, but I would encourage you to go to the QuickTime feedback forum, which is tomorrow.

Is it at 3.30, Stephen? Yeah, it's at 3.30 tomorrow. Please show up. Please let them know what you'd like to see. Here are some of mine. They've done a great job since last year of addressing a lot of my questions. I hope that you're able to use QuickTime in your enterprise, too. Thanks.