I'd like to welcome you to the Open Directory in-depth presentation. I'm really excited about this technology. I was doing a countdown with my manager. I haven't introduced a new technology in eight years. I've been talking about Open Directory. I love Open Directory. I'm still the manager. But I am really, really excited about this technology. I think you're going to enjoy the demos. We're going to have a good time. And we're going to do a little podcasting.

Who likes podcasting by applause? So what, so I'm David O'Rourke, I'm the engineering manager. I wasn't quite sure what to put as my job title because we hadn't named the product when I made up the slide, so I am the engineering manager for podcasting and also open directory, but we're here to talk about podcasting. So what are we going to do today? First of all, as some of you might notice, podcasting has been taking the world by storm.

Solutions are coming from fast and furious from a lot of things and we at Apple, having some involvement in this technology, felt that we should have some server solutions that offer a lot of different solutions to make your life easier and try to bring podcasting to your everyday life in a way that you can manage it and deploy it. So as part of the presentation, we're going to go over podcasting today where I personally see and where Apple sees the technology and what people are doing with it. We're going to be talking about our solution for podcast production.

We're going to go over a simple case study which I think will crystallize for you what it is we really see this technology being used. We don't think this is the only usage, but it's one of the most obvious. And what changes are we making to Mac OS X Server to make sure that you can deploy this? So where is podcasting today? Well, Apple and the industry provide a wealth of tools to capture, edit and produce content.

You've got QuickTime, you've got Final Cut Pro, you've got just a ton, a ton, a ton of tools that can capture video. Some are from Apple, some are from other vendors. There's really no problem generating content. In fact, I've heard the opposite from customers. They're generating too much content and they don't know what to do with it.

There's multiple methods for publishing the content. You can publish it by RSS feeds like podcasting. You can use your blog. You can use a QuickTime streaming server. You can even distribute it by DVD if you want to sit there and feed discs into the DVD player. But it is a method by which you can distribute your content. And there's multiple ways for people to view this content.

They can use their iPod videos. They can use their DVD players. They can use their computers as a DVD player. I have Mac Mini set up at home. I bought a Mac Mini for my three televisions and use it just as a dedicated DVD player for each of the TVs.

iTunes plays back videos and even phones. How many of you in this room have phones for which you can watch video by show of hands? I mean, it's just amazing. So, you can capture the content, you can distribute it and you can play it back. So, what's missing? So, all the pieces exist today.

The challenge with all this is if you want to turn it into a podcast and get it into your customer's hand, The steps to take it from capture The toolset to DVD are mostly manual. You have to know how to use all the tools in the middle. The technology is available, but it requires someone to follow a very complex set of steps.

I sat down and tried to produce a podcast from iMovie all the way out to a blog. And while it was not terrible, it certainly wasn't something my mother could handle and certainly wasn't something I could do on a daily basis. Processes that are manual aren't repeatable. You don't want to have to have someone like myself or yourself sitting there doing this process over and over again.

And if you start thinking about it, what if I needed to do that process 50 times a day or 50 times an hour or in some cases 50 times a minute? How would you go about doing that? I don't see how you would with the tools that exist today.

So it requires expertise with a very diverse set of technologies. Like if you want to produce a video with three different bandwidths, you have to choose save as three times from Final Cut Pro. I mean, it's not terrible, but I don't want to do that for 50 videos. You need to know where to post the video. Do I use FTP? Do I use Fetch? Do I use the finder's FTP support? How do I get the video where I want it? So producing a podcast today is largely, in my opinion, a hand-built exercise.

We have all the tools, but it requires a real craftsman to produce the entire product end-to-end. And these processes, as I said, are not repeatable. It's about as automated as producing a car was prior to Model T. I mean, there were cars before the Model T, but it was a hand-built exercise to produce a car. Henry Ford came along and he made it so he could turn out, you know, I don't know, thousands an hour.

Leopard will ship, Leopard Server, slide's a mistake, Leopard Server will ship with a product we call Podcast Producer. And what Henry Ford did for producing cars, Podcast Producer will do for producing podcasts. Leopard Podcast Producer fully automates the process of content ingestion all the way out to production and publishing.

Producing anything requires planning. This is not a one-shot thing. But once it's deployed, you can use Podcaster Producer to reliably and automatically produce podcasts on a daily basis. People who are submitting content into the system don't have to know what the system is doing with the video. So they no longer have to be experts in the technology because you can internalize all that with scripts and workflows that we'll go into later.

If you go from producing 50 videos a day to 50 videos an hour, you can transparently scale the system by adding more computers to process more video per hour. Raw materials flow in, finished podcasts flow out to wherever you specify them to go. Producing something requires control of the producing infrastructure.

So we're going to build in control and management. If you have a certain set of cameras that are on campus that are recording lectures like this one or other things, you don't want the students to be able to interrupt the lecture. So we're going to put the normal server admin and manageability controls into the product so that you can control who can use the resource.

You can change the process in production. Say your site decides that we want four versions of every video rather than three versions of every video. You can change that process without having to tell the submitters that there's a new process. So, what resources does Apple think you need to deploy this type of system? Well, a producer system consists of what we consider the following four components. It consists of a set of resources from which content can be captured.

At the lowest end, this could be a Mac Mini with a digital video camera plugged into it, plugged into the network. You need a server to collect the video from all of these cameras. You need some scripts or what we call workflows that say every time a video gets submitted, do this to it. It's a stamp, it's a recipe.

Every time a video comes in, do these 12 things, do these 50 things, do these 100 things. And you need servers to store all this data. This is why we like this product because we're going to sell you servers. And you need storage to save and publish the distribution content.

X-rayed, X-San to store the content. So, what this might look like is a set of Macintosh Minis or any Macintosh, anything that can have a digital video camera plugged into it. And those things will submit data to a farm, to a server farm. The server will process the farm and then publish the video out to various web servers, email servers, QTSS servers, possibly an archival system that's unique to your institution.

And your clients can use their iMacs, their iTunes, their phones and their iPods to receive the content. And as we go through the presentation, you'll see that at every step along the way, we've adopted standards. So, there's nothing here. This proprietary. So you can intercept this and deploy it using any technologies you're already familiar with.

So what's a case study of this example? And I mentioned it earlier. A university lecture is our touchstone or the way we think about this product and make sure we're on track as we're developing it. A mythical university would put cameras into each of the lecture rooms or certain lecture rooms.

The instructors would be allowed by the system to start and stop the camera. So the model would be the instructor walks into a lecture, logs onto a machine at the podium, picks the room that he's in and says start recording. He then does his lecture for an hour or so.

When he's done, he stops the lecture and the camera uploads the video to the system. At that point, the lecture is done. The system administrator or the university has decided what will be done with all those lecture videos and they put a workflow up on the podcast producer that will execute that instructor's video.

Lectures, for example, could be sampled down to three versions, a high bitrate version, a low bitrate version, a medium. Audio could be extracted so that people could just get an audio. And lectures are automatically archived to the XSAN system for future generations of students. The lecturer doesn't have to know nor care that any of this is going on. All he did was start and stop a camera.

So an example in action is lecture walks in, logs on to Safari. We've modified Blossom, which we'll show you. And he decides he wants to start a camera, so he uses Safari, picks the camera, starts the recording. The camera in the back of the room that he picked records his lecture. He hits stop. The cameras submit the lecture to the podcast producer system. The podcast producer system chews on it for a bit. Video encoding is expensive. It takes a while.

When it's done producing all the versions of the video, it publishes it to the email server, the webinar, RSS feed, the QTSS server and copies it automatically to a system that's purely an archive server. As the archive fills up, you give us more money and we give you another X-ray.

The point is the students use the technology that they already have in Tiger and in some cases Panther to access the video so you don't have to provide your students with any actual new software for them to consume these videos. I'm looking at this slide and it's a bit too static. I think what I'd really like to do is maybe demo this. Who would like to see a demo? Fantastic. At this point in time, I'd like to invite David Kraemer up and we're going to show you this all working in real life.

Hello everyone, I'm David Kraemer and I'll be showing you Podcast Producer. So, we'll start out, I actually want to show you the student experience first to use Dave's example because we really like to focus on the end-user experience of what it's like to enjoy what you've created with your content. And then I will show you how we actually create the content in the first place and get it published out to the blog.

So, we'll start out, here's my weblog and we can go check out and see what we have here. We actually have session 531, this session, already posted. So, let's, we can subscribe to this podcast right here. Just click on that link. Opens up iTunes, iTunes subscribes. We can watch the video.

So we did this just a couple minutes ago while Dave was introducing this. So, just works like that real quick. Well, that's basically it. That's what students are going to do. They're going to get back to their room, their dorm room after the lecture. They're going to open up iTunes and it'll just automatically download the latest video.

So what's more interesting though is how to create it, because that's why you guys are here. It's about podcast producer, not podcast downloader. You all can already download podcasts. So we actually can do the recording right here from the same blog, but what the teacher, the lecturer would do is log in.

And they would see down here a new link, recording. Click here and we're given the opportunity to select which room we want to record. So right now we only have one camera hooked up. It's this guy right here. We're actually using the built-in camera on this MacBook Pro. So what I'm going to do is I'm going to record you guys. And I'll tell you when to wave.

So I title it, give it a description. I'm going to automatically post this to the blog as part of the workflow. And what's going to happen is once this recording is finished, three different versions of this video are going to be created. There's going to actually, there's going to be an audio only version so that people who don't have video capable iPods or just want to take it to go while they're listening, while they're in the gym, they can download the audio podcast. We're also going to create a iPod sized video.

And then we're also going to keep a copy of the high quality video that was recorded in case we need to create other versions at some point in the future. So just by clicking here, record, I confirm. And hopefully the little green light turned on here. You can all wave. All right. All right. So I'll stop it.

We're done. And we're done with that. So now we can pop down and take a look at What's going on? And we can see the job gets submitted from the camera to the X Grid controller and X Grid starts running this on your cluster of grid agents. In this case, we only have one agent, so it's not going to go as fast as possible.

If you had 10 agents, you could have 10 classrooms all finishing their lecture at the same time, all getting uploaded to the server and all being done in parallel. David O'Rourke, David Kramer So this is going pretty quick, but before I show you the result of this, I want to show you the email.

So what happens is when the recording is completed, an email is sent to both the administrator of the camera and the person who initiated the recording. And so here we can see that the recording succeeded. It was 13 seconds. Where was it from? And it's being uploaded and submitted to Xgrid now.

So yeah, there we are. Then this also goes to the administrator. And when XRID receives the job, the grid administrator gets an email that tells them the job started, when it was submitted and when it started. They also get the notification when it finishes. And you could use this for accounting to keep track of who did what when.

As part of the workflow, when the video was transcoded and then uploaded to the blog and the blog entry created, this email was sent out to both the administrator of the camera and to the person who initiated the recording, me. And this basically tells you which files were created, where they were put, and then also includes a link to actually subscribe to the podcast. So let's head back to the blog and reload. And we can see that our audience recording has shown up here.

You can watch it directly from the page. Everybody wave. All right, good job. So that's pretty exciting. Last step here, we head back to iTunes, click update. Every few hours it's going to update automatically. It downloads the latest video and we get the same video, dorm room delivery. I hope you like it.

Thank you, David. That was wonderful. What do you think of the demo? If you think about it that example and action from was from a live video. But picture being able to run this process for your high production value content that you're producing with Final Cut Pro. Why can't I just take a file from Final Cut Pro and copy it into the system and have a workflow applied to that too? So that the people producing your videos don't have to know all the places you want to publish them, they just submit it to the engine in the sky and the engine processes the video.

Well that's also supported by this product, so you could have iMovie or Final Cut Pro take the output from one of those files, have it submit to the system directly, have them process it and then the system will apply the same workflow rules that it would have to a live video and you can take your high production quality content and run it through the system and have a recipe applied to it.

Again at a rate that you can actually sustain and start effectively deploying podcasts. Again the students as you saw, there's no new technology out on the receiver end for the students to receive. You don't have to deploy licenses or buy content viewing software for your students or your target audience to consume the data that you're producing.

So what are we going to do in Leopard Server to produce all this? Leopard Server will include Podcast Producer. We're going to give you a technology behind the scenes overview, drill down a little deeper, let you show how some of the moving parts are working. We're going to show you how you can scale and integrate this with any existing production systems.

I was amazed at the complexity of some of the production systems that some of the high end customers that we've been discussing this with. And since there's developers in the audience, I personally believe and I'm sure you can easily see there are third party opportunities for you to leverage this platform and build value on top of this platform coming out the wazoo.

So what is podcast producer technology? The first thing is a new piece of software that's going to be installed in every Leopard desktop called the camera recording software. This is the software that was running on this PowerBook that listens on the network for a remote start and stop command.

That will be authenticated, fully secure, it can live on your private network. This software will use the podcast producer server for authentication command and control. It uploads finished videos. This is not a streaming solution. I first thought this was streaming. While the video is being recorded, it's being spooled to the local hard drive. Not until the video is finished.

Does the camera upload the video to the server? It can upload one video while capturing another video, so you can do back-to-back lectures. So one lecture finishes, the next lecture walks in, the new video is being recorded while the old one is being uploaded. If you have a fast enough network, we haven't seen many uploads even for an hour-long video take over more than 10 or 12 minutes. We're designing it to run on low-end headless CPUs, the Mac Mini. We really see the Mac Mini as a, what's the retail price right now, $699? A $699 machine plus a $400 digital video camera is a remote network controlled camera running headless.

We're going to provide some remote control software. You saw some remote control software that we've integrated with the existing Tiger Blog server, but we're also going to produce a piece of software that will have a nice user interface, a photo booth or something, that lets you see the list of cameras and record and interact in a high quality Apple user interface.

The server will enforce access controls. You will be able to say on a per camera basis who's allowed to start and stop that camera, who's allowed to submit videos, all of that sort of stuff. You will retain complete command and control of this infrastructure. It's a course since I'm the Open Directory Manager fully integrated with Open Directory.

The file transfer technology. What did we use for file transfer? Well, we dug deep, we found the most sophisticated technology we could and we used FTP. Workflows can be specified during the submission process. An important part of this that I'll be getting into later is there's not one workflow, there's many workflows and for each job submission you can pick a workflow.

If you have all your machines on a shared file system like an XSAN, which could become increasingly possible as technology moves forward, the system will use CP. We'll just use a file copy. We won't actually transfer it over anything. So picture one of these systems hooked up to a shared file system where we don't have to really do anything over the network. We just need to copy the video from the spool folder to the destination folder. So we'll do the right thing depending on whether you're directly connected to the file system or remotely connected over FTP.

There will be a podcast producer process and what this does is monitors and controls the cameras. It enforces access controls and it's the thing that notices a new job showed up in one of the drop folders and submits the job to Xgrid. That's all it does. It doesn't do any more than that. It just, it's kind of the coordinator. It's the conductor of the entire system.

Xgrid plays a key role in all of this technology. This is where we get a lot of our processing scale. What's really cool about this technology is podcast producer workflows are just Xgrid job templates with the file name left as an exercise for the reader. So anything you can specify as an Xgrid job can be run by this workflow engine. And when the file gets substituted, the podcast producer engine fills the file name in and submits the Xgrid job.

You can add additional computers to Xgrid. When there's more than one job pending, Xgrid will schedule the job on as many computers as you have. Like I said, if you go from 50 videos a day to 50 videos an hour, you just give us money for computational nodes for Xgrid and you now have a much more capable production system. For those of you who don't know, Xgrid jobs can execute any Unix command line tool or script.

What could you do with video processing with any Unix command at your beck and call for your submitted video? Workflows can be easily customized. So if you just edit the workflow, you've now got, if what we ship you as a workflow is only 12 steps and you want it to be 15 steps, go edit the workflow, boom, bada bing, bada boom, you've got your own customized workflow engine. This is an opportunity for both end user customers to customize this technology and for third parties to provide useful workflows as recipes to the podcast producer platform.

As I've said before, workflows are just an X-Grid job. We are going to ship with several common and useful workflows. You saw some of them here today. There's some other workflows we already have defined like audio only. We have some screen scraping workflows. We have a lot of workflows that the system is going to ship with.

So it will be useful to you out the gate. But the workflows that we ship by no means will be the limits of what the system is capable of doing. You can do anything for which you could buy, beg, borrow, steal or actually code a Unix command line tool.

Some examples of basic operations that will be supported by the system are video transcoding, screen size, bit rate, codec choices, audio extraction. And where do you post the output? Do I post the output to email? Do I post it to QTSS? Do I post it to an RSS feed? Do I post it to an HTTP server? Do I post it to a file copy? Or do I ship the data off to another Unix script which then processes the video even further? With the built-in command line tools and workflow templates, it's already useful, but you can customize them.

We're going to do full integration across the board. How many of you would like to see full Teams integration with this product so that the podcast producers... We figured that out. One of my jobs after WWDC is to sit down with the teams people and figure out how we're going to do the integration.

The reason we're not as far along with this is we've recently come up with this idea. You're seeing a very early technology preview. Not only is this new technology for me, and not only am I very excited about it, but it's so new to us that we're still in the process of designing it.

So you're getting a rare sneak peek at a technology that isn't yet fully flushed out and we're still designing it. So we're going to be looking for your feedback after WWDC and get your feedback. creative ideas as to what you think the product should be.

Again, I want to emphasize workflows are just Xgrid jobs and Xgrid can execute any legal Unix script or command. So you can do anything with these workflows you want to accommodate any deployment topology.

So what would a simple podcast producer deployment look like? Well, we recommend for the simple configuration two cameras, no more than two cameras, just two cameras, no. One server probably with an x-ray, all the services running on a single server. That alone is enough to get all of your content delivered to all of your students or all of your customers. A medium complexity podcast producer solution might look more like this. Three cameras, no more than three cameras.

Talking to a slightly bigger engine with computational nodes. I want you to note the correct artwork for the computational nodes at the bottom. There's not three drive bays there. So this can process more videos per hour than a single CPU could. Hosting to separate servers hosting web, RSS and QTSS.

The reason you would do this is if you had a large student population doing a lot of downloads, you don't want the web servers time impacting the video processing time. So you separate the CPUs to keep the processing on separate CPUs. The students don't know the difference. They're still using the same software. They're still receiving the links over email or however you choose to publish it.

You can even go complex. If you think about it, there are some, well, we're live recording this, multiple cameras in this particular session. What's to stop this conference room from having a podcast producer engine here at WWDC that after this lecture is over, we're tying in with a very sophisticated production system. I don't know how many of you know about the AV work that goes in to carry these conferences off. It's not simple. I tried to figure it out one day. I couldn't.

This is a very complex production enterprise and I think you can all see that this could very easily integrate with podcast producer. So all the way from live video capture with a built-in eyesight, which I won't recommend for capturing lectures, all the way up to a high-def camera submitting directly to the system through multiple broadcast and video management technology.

Third party integration opportunities here are stunning, in my opinion. The basic feature set is going to be very useful. The feature set that we ship in the box is going to be useful to an extraordinarily large number of customers. But Apple's not going to provide everything on this particular thing. There are lots and lots and lots of opportunities for developers to enhance this platform. The three integration points that I'm going to go through today are direct content submission, enhancement to workflow choices, and post-processing the results of a given workflow.

Direct content submission. How many of you would like a save as in your favorite video app that saves directly to this system so I don't have to use the finder to do a copy? So the first integration point is if you have an app that produces video content, integrate it directly into that app. We'll work with you to define the technology and the APIs. The submission protocol will be FTP. CF Network makes it trivial to use FTP.

It should be really, really easy for your application to directly support direct submission to the podcast producer system. The second integration point is the application of the product. The application is a very simple and easy way to use the FTP. You can use it to create a video, to post your video or to use the FTP. We'll talk about that in a little bit.

The second integration point I think is very obvious, workflow enhancements. I don't think the 12 or 14 workflows we're going to provide are going to cover everybody's requirements in the audience. We're going to need command line tools that do really clever things with video. We're going to need a lot of stuff. The sorts of high-end processing that could be done with this are also stunning. Could you do facial recognition on the video and produce a list of who attended? Would be a very interesting podcast producer job.

Again, Xgrid jobs are simply jobs describing a set of commands to be executed on the grid. If you have a command line tool that can process video, you can make it part of the podcast workflow. If you write new tools or scripts, I really don't see an end to this. iMovie plugins that do fancy video transformations, a huge market for that. How many of you are going to want video transformations on your podcast producer videos? I think we can integrate a lot of that stuff.

The third one is kind of a flavor of the first one, which is post-processing the results. And I think the only difference between post-processing and modifying a workflow is when is the processing done. And in this case the processing could be done after the video is published or posted. So does anyone here have a digital asset management system they've deployed on campus? I don't see any. Okay, a couple.

Yeah, certainly post-processing here would be automatic posting of the digital assets to that existing system. That could be something added to the workflow or added to the scripts. So the real issue here is whether the process works during the process or does it work after the process. Either way, I think it's a huge opportunity for third parties and consumers to customize this platform.

So in summation, podcast producer is a new and powerful set of services. We think it makes deploying and hosting and publishing podcasts easier than it's ever been. We're using standards throughout the product. There's no mystery. There's no mystery meat here. All the standards are laid bare. It's all using technology.

You've all already deployed. So this allows you to easily mix and match and substitute the system. We're going to add server command and control so that you can actually manage the system. If you have 500 cameras, you want to know who's using those cameras, when they're using the cameras, and make sure that the students aren't stopping the lectures in the middle of the lecture.

So all the major access controls and we'll be fully integrated with server admin groups and SACLs. How many people use SACLs on Tiger Server? Service access controls? We're going to be using SACL models on the camera so you can lock down a camera then only these five instructors can start and stop this camera.

And we're going to integrate the Mac OS X Server technologies, QTSS, Open Directory, Teams, Wikis, any number of technologies, because there could be a lot of different places that you want this stuff published. I learned a new feature the other day. The calendar server can have enclosures. Well, picture posting a video for an event that's scheduled that every, maybe every day on Wednesday, you know, that you go over last week's lecture. Well, you could include the lecture in the meeting maker attachment or not the meeting maker attachment, the iCal server attachment that automatically gets posted. I think the possibilities here are endless.

So podcast producer is going to allow you to manage, publish and produce podcasts on a scale never before considered. I mean, I could easily see the system managing five to six hundred videos an hour. So for more information, you can contact our technology evangelist, Skip Levens. I'm sure some of you will be ringing his phone right away.