Good afternoon. My name is Jacob Brown, and I'm with Apple Professional Services. We've deployed Podcast Producer in different organizations, and today we're talking about deploying Podcast Producer in those organizations. We have... We have two guests today, one from Stanford University School of Medicine and one from Orange County Sheriff's Department.

After that, Jason, one of my coworkers, is going to come up and we're going to talk about some best practices for deploying Podcast Producer on OS X Leopard. And we're talking about OS X Leopard, not 10.6, 10.5 server. So with that, I'd like to introduce Andy from Stanford University. My name is Andy Wasklewicz. I'm from Stanford School of Medicine. I'm the technology architect.

Jump right in and go a quick overview of the history of what we've been doing at Stanford. Is this working or not? No. Okay, I'll stand here. So, we started, we have a rich history in capturing classroom video. We've been working for 35 plus years in classroom capture. You can see we started back in the 70s when I was just a wee lad.

And we moved through the 80s and we captured on the always highest quality VHS. And just a side note for any of you guys who are from universities that have these same type of archives. Stanford has very little of this archive left. We actually recorded over most of it. And also didn't store it in a proper location. So, if you have some archives when you go home, I'd suggest ingesting them into podcast. a producer as quickly as possible.

In '88, along with many other universities, we started streaming our classes via real streaming servers. This was a solution that the faculty really liked because they thought their content was "safe." As we moved along into 2006, 2007, the safe part of this kind of changed when we found that students were ripping all the streams and distributing them in different methods. So, like any other university, what do you do? You write a policy. So we wrote some policies, and I was contacted to come in and work with the EdTech group on deciding next steps for classroom capture.

In late 2007-2008, we started working on some prototypes with Podcast Producer as a replacement for our now-aging real systems. As you can see, the downloadable video is how we actually do most of our video now. All of our courses are, every single course that we teach is actually captured and digitized. Grand Rounds, which is something specific to the medical school. We also do any special events that happen in the school, any guest lecturers, whatever happens, we record it.

We do about 6,000 to 7,000 events a year in our educational spaces, and we capture about 2,500 classroom capture sessions. So why were we moving to Podcast Producer? Number one reason is the School of Medicine is actually restructuring itself. And one of my major responsibilities is the Li Ka Shing Center for Learning and Knowledge.

This building is a four-story educational building. It's a new educational gateway space. Every single space is capture capable, meaning that of the 130 cameras that will be in the space, they'll all be routed back, and we expect to encode these with Podcast Producer. It's a major factor for us moving towards an open system like Podcast Producer.

Another big impetus for us moving towards this system is the students. We have a very active student body, as you can tell. They are very technically savvy. They also have a level of expectation of us. Because of the quality of work that we've been doing for so long, and the timeliness of our encoding sessions being posted, students have these expectations that they hold us to.

So one of these expectations is timeliness, and what I mean by that is four hours after the class is captured, we try to have that online. So it's a pretty quick turnaround for us, and when we are investigating new products, this is one of the things that we are really trying to stress as a key component.

As you can see, also the students are requesting more of video anywhere, anytime, meaning they want to study the video where they want, when they want. If they're on the train, they're going to want to study the video where they want, when they want. If they're on the train, they want to study. If they're in the library, they want to study on their laptop, they want to have access to it.

So with that, we moved on to actually asking the deans if we could move forward with this project. And my favorite quote came in the meeting, where he says, why limit the capture system to just classroom when we could open it up to everyone? And so after I picked my jaw off the floor, I realized that this kind of validated our choice of Podcast Producer, because I knew that we could actually handle taking in all the content that was created throughout the campus. Actually, three days after he said this, the hospital came to us and asked us to ingest and distribute 150 tapes to YouTube. Exciting.

So, quickly go over our prototype system. Pretty much like everyone else in here, we have a classroom capture system. We actually mix right in the back of the classroom. We have cameras and Mac minis that are actually capture stations. I threw up the Mac Pros because our post facility, like I said, actually used Podcast Producer. Once they've cut their pieces, they actually pass it on to Podcast Producer, and it distributes where they'd like to with special workflows.

Once the file's actually passed on, it goes to shared storage. Podcast Producer actually runs the workflow. We're in an investigative state. One of the unique things about our system is we're actually investigating episode engine for the encoding portion. Once the episode's engine's done, Podcast Producer picks that file up and passes it on to wherever we're going to publish, whether that's iTunes, YouTube, wherever it happens to be. And our students pick that up on any device that they have.

I'm going to quickly go into what we capture. This is pretty typical of the content that we would be putting through the system. This is some stuff we captured in the hospital of an MD training a student. You can close your eyes if you just ate lunch, which I'm sure many of you have. This is a surgical procedure that would be passed through Podcast Producer as well. The bulk of our content is a lot of this kind of stuff. It's classroom capture.

And finally, we do a, the medical school does a lot of research in educational spaces, so we capture a lot of that and distribute that as podcasts. So currently, Capture about 35 podcasts a week. This varies from classroom materials to those special events. We're expecting to double and possibly triple that output in 2009.

Our current workflows, we're mostly using iTunes U. We have three instances of iTunes U. We have public, private, and community, and most of our content actually sits in the private location. We do very little in the public space. We're also working with our main campus on our new YouTube implementation, which should be rolling out pretty soon.

We have some custom stuff we're doing with our School of Medicine web portal. We're also, as I mentioned earlier, working with our learning management team to... Work on integration with WebCT tools. Forward-looking, we're really looking towards Sakai as our destination for most of this content. And of course, some private internal portals.

Some of the unique things about our deployment are we're actually working on, in the Li Ka Shing Center, the new educational facility, all of the 130 cameras and signal route back to one location. We're actually trying to figure out some way to stick Podcast Producer behind this and actually automate the entire process.

At the School of Medicine, we do a lot of simulation-based training, and these are Mach surgery spaces that students come into, work on certain scenarios, and then the faculty will sit with them and use this as a learning moment. They capture a lot of video and are interested in passing this through our Podcast Producer system and actually storing it in an archived format.

We're also, this is very new to Stanford, I don't know about other universities, but we don't do a lot of sharing on campus. So one of the things that we've noticed is because a lot of our work is done during the day and our classes finish at three o'clock, is the grid will sit silent in the evening. So what we're starting to do is try to integrate with other groups on campus who have some content that they'd like to encode in the evening. So it's kind of a new for us.

Quickly, just step through our final steps. We're working over the summer with Telstream to finish our integration project. We're also working on some Final Cut Server workflows for intermediate archives, as well as allowing our post-production team access to the raw content that we're capturing. We're very interested in iCal Server. We want to automate as much process as we can.

So we're really looking at iCal Server as a possible solution in integrating that with Podcast Producer. As I mentioned earlier, our content management systems and our control and switching system within the Li Ka-Shing Center. One thing that Stanford hasn't done a lot of is a ton of screen capture.

So we're actually looking at using some screen capture tools and trying to work that into the Podcast Producer workflow. And the last two bullets are... important to us and really speak to the extensibility of Podcast Producer is the Opencast initiative and ETH Zurich's replay system. So the driving force behind selecting Podcast Producer was it allowed us to really meld it into whatever we want.

And Opencast, which is an initiative out of UC Berkeley, is adding a layer that's going to allow us to interact with our registrar's office and calendaring data. And use Podcast Producer as the back end. And some of the research that's coming out of ETH Zurich with their indexing and tagging is we really see as a plug-in to Podcast Producer and allows us to really move towards where we'd like to go. Thank you. I'd like to introduce Captain Mike James.

All right, I sound, my microphone's working, I can already tell. Good afternoon, my name is Mike James, and I really am a captain from the Orange County Sheriff's Department. That's not a cool nickname I gave myself. And you might say, how does a captain from the Orange County Sheriff's Department get up here and start speaking about technology? I ask that same question myself. In 1998, we were so technologically advanced that when I went to my first day on patrol, my captain said, son, here's your hardware and here's your software, get busy.

So here we are today. We're going to talk a little bit about what we've done with Podcast Producer in the last several weeks, trying to enhance the image of the Orange County Sheriff's Department and enhance the image of what we want to do in our community and with our deputies.

I'd like to first tell you how we got involved with Apple. It was quite a unique thing. We have about 300 mobile data computers that our deputies use in the field, and we feed real-time information to them about criminals they're possibly dealing with, houses they go to, information about neighborhoods and all that kind of stuff.

So it's a very critical thing we give to them. And part of that thing, that image has to be updated constantly. And in order to update that image, we used to have to pull those units in out of the field, physically touch each one of them, go to a power source and a hard drive. And one of my technical guys said to me one day, he goes, hey, I figured out if we use an Apple iPod, I can put the image on and just USB it right into the computer. They don't have to leave the field.

So that's a great thing. So we bought four Apple iPods, which is very hard to explain to a county government why you have iPods. So now we call those 80-gigabyte secure hard drives. And the purchase thing goes through Apple, and we get them, and we get ready to go. So that was the first thing we did with them. And we were so excited by that, we started talking to them about other things. One space that Apple does very well in law enforcement is computer forensics.

And so our computer forensics guys wanted Apple things, and we said, yeah, we would do it. And we had a simultaneous process going on where we were doing Apple storage and computer forensics, and we were doing another storage device, which I'm not allowed to say, on another project. Well, my tech set up the Apple storage in about 30 minutes, never touched it before, had never seen it before. And it's been working ever since we haven't touched it.

The other storage took the company's tech three days to get it first installed, five days until it actually worked. I said, we've got to start buying some more Apple stuff because it's much easier to use. So that was our introduction to Apple in a world that doesn't use Apple, and we're going to go forward with that.

Today we're going to tell you a little bit about our challenges with trying to get this done. We're going to show you how we transitioned from a media tape library into a rich media distribution system. And again, we're just at the front edge of doing that, so it's something we're learning day by day as we go, running in against conflicts and issues, and also dealing with a big group of people who don't understand this technology. We have very young deputies coming up now that do, and we have very old deputies who don't get it and don't want to get it, don't want to understand it, and see the benefit in it.

At our academy, which we'll talk about in our future deployment, we talked about making this presentation go so deputies could actually learn the material while they're in the academy, and they responded to us by saying they have to get it the first time. And we agreed, but it's really important that they do get it.

So that's the kind of challenges we're dealing with when talking to them. We're going to look at the current infrastructure that we're using today, and again, we started with absolutely nothing. And as of last week, we actually have a podcast studio set up in our office where our sheriff and other politicians can go on. We've produced a live tape with a teleprompter and everything. So we've made great strides in a pretty short time, again, with the help of our Apple pros that help us out all the time. And then we accomplished this using Apple's X-rayed server and combined storage project.

We're going to talk to you on the screen. You'll see a bunch of varying, this is our current infrastructure that we're talking about right here. So while that's up there, I'm going to tell you some of the things we want to use it for. Again, training is very, very important to us. Training our deputies. Like every other kind of training, it's very expensive.

We have to backfill their positions so the citizens we serve don't have any downtime. And the time it takes to train them is very, very difficult. So we're hoping that in this process, we'll be able to train them in a lot faster fashion, get it to them right away, and do that.

We focus in a region of training that we call high-risk, low-frequency activity. That's activity that you don't do very often, but it's got extremely high risk to both the deputy and the public and the person you contact at the same time. So we focus on that area, and that's where we really hope to do this.

One area that we're doing this already, we started, is we tried to create, one of the parts of my division is property and evidence. We have about 100,000 items in there, including large amounts of cash, every kind of weapon imaginable, rocket launchers. And a high amount of narcotics. So last week alone, we booked 130 pounds of marijuana. Part of that is safe handling. Every day at 3:00, my employees get the munchies, and they're all really happy, but I'm not sure why yet.

So we're in the basement down there. I'm actually up on the third floor, and as we walk through the basement, there's this aroma, let's say. It kind of overcomes the whole place, and everybody wants to work in the basement. We're not sure why. Anyway, so we focus on that. One of the reasons we picked the Apple storage here, the way the flexibility gave us was great.

We know there's other options out there. We have other contract providers, but no one could provide it in the system that they gave to us that was so easy to use and so easy to enhance, and the flexibility gave us to increase our production as we decided to. And then lastly, it was a proven concept. It was something that they were clearly able to show us the benefit of, and we were clearly able to just establish it right away and start creating content with it.

Some of the reasons we were really trying to use it, in law enforcement, it's usually very, we have a very negative environment, an environment that the media doesn't fairly report on, we believe. They skip over lots of the positive things and go right to the negative things, or our negative things, that's the world we work in, and that's okay.

But one of the reasons we want to do it is we found out that we could get our message out to the residents we serve and let them understand, hey, there really are lots of good things going on. You hear about the few bad ones, but there are lots of good ones.

I worked in one of our contract cities, and in that environment, we did a survey and figured out about 90% of the residents were getting their information about us from us. So it's really an opportunity for us to enhance our message and tell them what we're doing. Again, we talked about the training, the high-risk and low-frequency, so we'll do that. Next, we're going to show you a quick demo. We converted a lot of this tape library into podcasting, and so we have one here that's our MDC training.

Welcome to the Orange County Sheriff's Department's computer-based mobile data learning program. I'm Sergeant Mike McHenry, and I'll be your guide for this learning opportunity. Mobile data programs like this one have become commonplace in law enforcement today. But unlike most mobile data computer systems, this equipment and software will offer the field officer resources and abilities far beyond most in the nation.

The Orange County Sheriff's Department's mobile data program was resurrected in about 1999, with a change in some important cellular technology. As a result of these changes, we embarked on a fact-finding process that ended with the deployment of 29... All right, that's enough of Mike. Lastly, what I'll show you up here, this is our future deployment that we're working on right now.

And this system that you'll see up there is based at our training academy. We train law enforcement officers from throughout Southern California, from the bottom, from top of San Diego all the way to the top of L.A. We're one of the last full-stress academies in the nation, and we train about six classes a year, and that training is about six months long.

One of the requirements, police officer standards of training requirements, requires us to tape every single class, audit them, and then be able to tell who was in those classes. Today, they're accomplishing that by videotape, and then they're going back and trying to find rosters. And with the Freedom of Information Act and people looking back at these things, we really needed to figure out a better way to do that. So this system allows us to do that. Not only record every class, record the instructors, record the slides, attach the metadata to it to make sure that the employees that attend those classes are then logged on there. So we go back, we can do a search.

Again, our Apple professionals helped us set that thing up. We're really thrilled to get it going. We're trying to get the final pieces of it in place and make that purchase and get that going. So with that, we're going to go ahead and get started. All right. Thank you. All right. Thanks, Mike. Thanks, Mike. Thanks, Mike. With that, I'll introduce Jason from Apple, and thanks very much.

Thank you, Captain Mike. Do I have audio back here? Here we go. All right, so I just want to talk a little bit about some of the best practices that Enterprise Pro Services has been doing in these deployments. As you can see, we have a lot of great customers we've been working with on these deployments in a variety of different uses. It's amazing to me to see podcasting take off the way it has and just the different categories of training and things that have been being put to use with it.

So I'm just going to go over a little bit of a component checklist on some of the different ways that we've been examining Podcast Producer deployments. Simply put, this is kind of a checklist of what you get when you're deploying a successful Podcast Producer solution. Off the top of the list, we're going to have the XGrid system for the encoding process, a shared file system for actually storing all this content, and then also the different types of workflows and resources you can manipulate to customize the podcast production for your environment.

As far as the Xgrid goes, again, this is where the bulk of the work gets done in Podcast Producer solutions. I'm sure most of you have attended some of the other sessions, and I'm not going to linger on this too much, but some of the things we've been considering when we're working with Xgrid is how to properly size it for a different environment.

Specifically, as we were talking with Andy earlier, we were talking about requirements, right? What is the expectation that your students, your sheriffs, your soldiers, whoever it may be, have for the rate that this content is going to get out there? By the same time, by the same token, we also have to consider different types of formats that are going to be supporting your environment. If you're encoding more formats, it's going to take longer to do it.

Now, some of the ways we've been addressing this is by adding more XGrid agents. If you have more processing power on the back end, it's going to take a little bit less time to process it. But an important thing to understand about Podcast Producer is that just because you have more agents doesn't necessarily mean you're going to be able to produce one podcast faster. It just means you can produce more podcasts simultaneously.

Some things we've been able to do also to address this is make use of different products, for example, Telestream, which Andy mentioned earlier, and also Compressor from the ProApps suite, where you're able to leverage the cores and processing you have more efficiently, as well as be able to pick up additional support for formats if you need Windows Media or RealPlay or whatever it may be.

As far as the shared file system goes, this is the consideration of where are we going to store this content, but also it's coming into play because you need something that's going to be a fast solution for all of your agents working on this simultaneously. So some numbers you guys might have seen before, when you're considering the size of the solution, you're going to need a good amount of space to store this content. The more formats you're encoding, the more content you need to keep, the larger you're going to need.

I recently deployed a solution for the Department of Defense that was about 55 terabytes, and something that was a little difficult to express is how would you get that into a raw number, right? How many hours of video, whatever it may be. So we did some math, and we found out, you know, when the codecs were supporting and whatever formats we were employing, it came out to about 2,000 years of friends. So if you need some space out there, and you know, you're like Rachel a lot, you can get a good amount of storage from Apple.

The other factor in this is going to be the amount of bandwidth you're using. So if you're starting out small, you can use something like NFS. You know, you've got a couple agents. However, as you get into a larger solution, what you'll find is NFS doesn't really scale from a throughput perspective.

At that point, it's good to deploy XSAN. You get the fiber channel in there, and not only do you have something that's faster, it grows better. So as you add on more storage down the road, you need more content, you have a system that's going to grow with you.

Now, the main part of what we've been doing lately with Pro Services has been working with different types of workflows and creating custom workflows for our customers. A big part of this to consider is that workflows are really just a series of shell commands. So if you have people in-house who are experienced working with the Unix shell, you know, they write some Bash scripts or Perl scripts, you can put those to use in your environment.

Out-of-the-box configuration, most of these are being used by the PCAST action command. This is just the default command that is included with Podcast Producer. It has a variety of different tasks for encoding or posting to iTunes or to the built-in group blog. But what you'll find is that some of it, you need a little bit more out-of-the-box than what you get.

So just to kind of reinforce this a little bit more, I have up here a typical blog workflow. This is what the basic blog workflow looks like, the one that's included with Leopard Server. And I've kind of color-coded this a little bit to divide this up into different sections so I can explain a little bit more down the road about how to customize it.

So when you're seeing the blue here, I consider these pre-encoding tasks. And the stuff you find here is usually going to be something like prepping the content before it's encoded or applying a watermark, your intro, outro videos, titling, stuff that happens before the bulk of the encoding operation. An important thing to consider here is that most of this is sequential. You can't really parallelize this very easily.

The orange is going to be your actual encoding tasks. So this is where the systems are going out. They're encoding the content into multiple formats. And then after that, you're going to have your post-encoding tasks of as far as, am I going to send out an email notification? Am I posting it to YouTube? Am I just going to put it on the blog server? To kind of get a little bit more into the way we've been approaching this from our standpoint, I have this particular task encode iPod divided up a little further.

When you look at the Encode iPod task in the blog workflow, what it's actually doing is calling PCAST action with a set of parameters like you see above. It's going to specify things like where is my working directory, what is my input file format, what is my output video file, and also what particular set of encoder settings are we using.

Now, an interesting thing about the PCAST action command is it's actually a Ruby script. So if you're comfortable with it, and you have a little bit of experience working with Ruby, you can use some of these as an example to work your way in and create more advanced configurations.

Particularly with PCAST action, when you use the encode command, it's actually going to go back to the QT encode command to do the actual binary encoding. So what ends up happening is PCAST action is called by XGrid. XGrid is going to give it the necessary parameters from the submission from Podcast Producer. And then QT encode in the end gets called with an expounded set of parameters to make the encoding happen.

So some things we've been looking at for troubleshooting this process is that, first of all, you want to make sure your underlying infrastructure is working correctly. In a minute here, I'm going to have Jacob come on back up on the stage, and I'll show you some of these particular tools we've been using. But a great one off the bat is the XGrid Mandelbrot tool.

You'll find this as part of the Xcode tools that you can install, and it's one of the example code packages. And this will actually test your XGrid to make sure it's working properly. By the same token, there are some tools like Xantuner or the Asia Kona tester that can verify your shared file systems working properly.

Once you're sure that stuff's all working right, go ahead and take a look at running the workflow, and then kind of follow the process of the workflow being run through the different logs and services that are being used. For example, PCAST agent D is where the upload is going to originally occur, then you see PCAST server D pick up the content and push it off to XGrid controller before it gets sent to finally an agent to get processed.

Some common problems we've been seeing out in the field with this stuff, for example, with PCAST Agent D is commonly the errors you're going to run into are things related to user credentials, right? My user account doesn't necessarily have the privileges to work with the Podcast Producer system, or maybe the podcast service isn't even online. I'm having network trouble. I can't reach it.

Once I've gotten past that point, I can see that PCAST ServerDeek has its own set of problems it can run into. Commonly what you'll see here is that the Xgrid user credentials aren't valid. So something you might see here is the Xgrid agent can't kick off the job. I'm sorry, the Podcast Producer can't kick off the job. Similar line is maybe Podcast Producer can't write to the shared file system because it doesn't have the necessary permissions or there's not enough disk space.

Once you've gotten past PCAST Server D, you're looking at XGrid Controller D, and commonly the problem I've seen here is either A, you don't have any agents available, or B, they get stuck at pending. And an important thing to realize about the agents that get stuck at pending is there's actually a little script in there called art.rb inside your workflow.

And what that says is whether or not the access to the shared file system is working properly. So the most common problem I've seen with agents stuck at pending is they can't access the shared file system. Maybe you're having problems with a fiber channel card, maybe the volume's not mounted on the agent, but for some reason the agent just can't get to the system.

Finally, XGrid Agent D, the problems we've seen there have been related to things like privileges and permissions. You know, my shared file system, for some reason, maybe I don't have directory information passed to all my agents, and now it doesn't see the correct set of user permissions on the shared file system.

Also, you know, it happens sometimes, maybe you have a malformed workflow, a typo in there, you have the wrong input or output, maybe you need to do a different set of actions first. So, with that in mind, I'd like to welcome Jacob back up on your stage, And he's going to give us a little demo of some of this troubleshooting we've been doing.

So I'm going to start with simply the Mandelbrot. This is a Xcode project that's actually located in-- Developer examples, Xgrid, Grid, Mandelbrot. And I'm just gonna build and go. And I already built it, so it built pretty quickly.

and it looks pretty. The second piece that we're, that, the second part that we want to kind of troubleshoot is to make sure that we're actually getting good bandwidth on our shared storage. The two tools that we use in pro services is going to be XSAN Tuner, and right here I'm going to show you the AJ Kona System Test, which is a third-party software from AJ.

And it pretty much Since I don't actually have a SAN attached here, I'm going to just write to the local hard drive. But it just gives you read and write tests. If you have a problem with your shared storage, you're going to either see that the bandwidth isn't what you expect it to be, or it's just going to fail, like if the XAN volume is not online or something to that effect. And this is a real good test just to make sure, you know, XGrid agents can all get to the shared file system.

So here we actually... shows you the average bandwidth. And if you have XAN involved, obviously, depending on the number of controllers you get, you'll get much higher speeds. So it's just testing the I/O. The Apple tool would be XAN Tuner. XAN Tuner only works with a real XAN volume, so that's why I had to use the AJ. Then the last one is actually going to Podcast Capture and doing a test.

And what I'm testing right now is to make sure my workflows are going to be working as I expect them. So I have four logs here that I'm actually going to be looking at. The system log, which is going to give me the most information. I'm going to go ahead and mark it. My podcast server D-log, my X-Grid agent log, and my controller log. So when I actually submit this, let me do a little screen capture.

And here you can tell Podcast Capture's already saying, you know, we started recording. I'm going to go ahead and publish this. And I'm just going to submit it with the blog. This is the -- what Jason showed you was the blog, so when you're -- you're going to actually see each line as it goes through here.

So Xgrid successfully, or Podcast Server, successfully sent the grid the job, and then here you can actually see the job going. And you'll see each line has what XGrid agent, the XGrid agent is actually processing. So here it's processing PCAST action, the post flight, and it tells you the actual base directory. All the information that you were getting from the workflow you'll see in the XGrid agent log. You can also verify that the job completed in Xgrid And the final piece is just to go verify it.

So this is actually in the wiki. You can just see the video. Great resolution there. So that's it. You pretty much-- you verify the-- the XGrid agents are working as expected. You verify that your bandwidth, your shared storage, is up and providing you the bandwidth that you expect. And then lastly, you verify that your workflows are actually doing what you expect them to by watching the logs and seeing if there's a failure or, in this case, they all succeeded. That's--that's what I got.

Back to slides, please. So this last section, I'd like to talk a little bit about customizing Podcast Producer. These are, again, some of the things we've been doing out there in the field and making use of these deployments to make them fit a little better for our customers.

I'm going to take a look at pre-encoding customization, things we're doing with different types of watermark resources, customizing things that are happening before the bulk of the encoding process. I'll take a quick look at some ways you can enhance the different features of the encoding process itself, and then I'll just talk briefly about the post-encoding customization.

As far as pre-encoding customization goes, you can start out small. Maybe I just want to use a different watermark image. I don't want to have an Apple logo on all my content. In that case, just create a simple PNG file, make sure it's transparent, and specify the right file in your properties and server admin.

Getting a little more advanced and you want to work with things a little bit deeper, you can take a look at using custom quartz compositions and transitions. So maybe I want to have, instead of a watermark in the lower right-hand corner, I want it in the left corner.

Or maybe I want a lower third that talks about what I'm looking at. All this stuff's possible using a tool called Quartz Composer, which can be a little bit difficult to work with at first, but it gives you a lot of flexibility in working with different types of transitions and the compositions.

As far as the encoder customization goes, another simple thing you can start out with is using custom encoder settings. Maybe you want to use a different resolution for your encoder settings than you do normally out of the box. So maybe instead of the default settings for H.264, you want to use a different resolution or a different amount of audio quality or change those in some way. You can track down some tools on the Internet that will allow you to tweak those settings. You put them in the right folder, and they're good to go.

Once you're comfortable with that, you can look at getting into more advanced encoders. So, again, I talked earlier about using Compressor and working with Telestream's product. We've had a lot of success working with Telestream's episode podcast and deploying this for customers who want to support a larger variety of formats than you would get out of the box with Podcast Producer. You know, Windows Media Format, Flash Formats, Real Media, pretty much anything out there, episode is worked with at this point.

For your post-encoding customization, a simple one you could do would be maybe posting multiple group logs. Out of the box, again, it really only caters to a single group. But to add a second group is really just a matter of duplicating your existing workflow, creating a couple custom properties, and then specifying in those custom properties what group you would prefer to post to.

Moving on from there, things you can get into for advanced settings are things like posting to custom websites. Andy talked earlier about posting to YouTube. We've been working on some tools like that to post to YouTube as well. I've seen people posting to Blogger, different type of blog systems, really anything you can call with a shell script.

You know, I want to FTP it to a server. I want to just put it in a special folder and drop it. I want to work on pushing it to my Final Cut Server solution. All these things are possible because it's all just shell scripts in the back end.

So just to talk a little bit about this, as far as if you're working on this and you want to get into some more information on Podcast Producer, we have our server evangelists who can talk about this stuff. Also, you'll find a lot of documentation on our site, on the server documentation, working with Podcast Producer.

At this point, you guys probably caught the sessions. If not, you might want to wait until WWDC releases this content on the iTunes for ADC, and then you can take a look at some of these other sessions you might have missed. But we've had a lot of content coming out on Podcast Producer this year.

Also, immediately following this session, we have a lab down in the IT lab for Podcast Producer, and you can find Jacob and myself down there talking about anything you might be able to have as far as solutions you might want to implement in your environment or talk a little bit more about that.