Welcome to the QuickTime Streaming Server Programming session. And we'll be covering the QuickTime Streaming Server and Darwin Streaming Server source code and API programming. One of the things that we'll be covering is how you can add your code to create your own server or modify the existing server that is available. And when you use Darwin Streaming Server source, you end up with a source code that is available to you. You end up with a server that it can run on Linux, OS X, BSD, Solaris, and Windows NT.

You want to download this and read it carefully, follow the terms of the license, then plan your changes and your additions. Go ahead, create your software. If you find that you've had to modify the server, you will want to post that you have modified the server and make those changes public.

So that was our message from our sponsor. The source that we'll be talking about is the server, of course. You have your server modules inside the server. There are files that are specific to porting the code to Windows NT or Linux. You'll want to take a look at those if you have different OS than the ones that are already supported in the build of the server. You have the various protocols that are supported inside the server, so these files will be -- are there when you download the source.

There's a client development library. We use this library in our product, in the QuickTime Streaming Server, and it basically gives you RTSP over RTP as a client, some TCP skip protection, if you want to see what a skip protection implementation looks like from a client's point of view, there's the RTSP client library in the source code. There's a proxy server. There's an MP3 and an MPEG-4 file broadcaster.

You have the file parsing and reading code that's inside the source code when you download it. And, of course, we have our web-based server UI that's part of the Darwin Streaming Server product. So all of these are available for you to look at, use it as sample code, or go ahead and change it, modify it to whatever needs that you have.

This is a diagram, a high-level diagram of the server and how it works. And it is a module-based server. There's very little, actually, that the core server does. It's just basically there to run the modules and execute tasks. Those tasks are actually implemented in each of the modules that is loaded into the server. So we start out with our clients connecting to the server over the network protocol. On the other end is the QTSS API that's going to go ahead and call your modules.

Now, this is the core server, the execution of the core server. There's one process, and it contains four main threads. The one main, main thread is simply there to watch the state of the server and gather statistics. So it's actually doing very little. There's an event thread that's out there using Select on Linux and POSIX systems. It's using Windows Messages and Mac OS X Event Queue to find out if there's an event that it needs to process. And once an event happens, like a read event, it will then go ahead, find a task that's associated with that file descriptor.

And then it will go ahead and find the task that's associated with that file descriptor. And it's going to put it on something called a task thread. And the task thread is actually going to do the work. So the event thread, after it grabs the event, throws it onto a task thread, is simply going to go back to sleep again waiting for another event. So there's just one event thread, and all the work is done by the task threads. Those threads are going to be running through their queues one at a time and processing each task.

So, some servers out there will throw off or fork a process for every request. Our server, the QuickTime Streaming Server/DaRwin Streaming Server, has two threads. There is, I mean, processes. There is the parent process, which, like the main thread, is just checking the status of something else. In this case, it's the child process.

So it forks off the child process and just waits to see if the child process has died. In the case of some unknown reason that the child process were to be killed or crash, perhaps, the parent process would go ahead and re-execute it. Now, the child process is the server that we were just looking at, and it contains the task threads, the event thread, the main thread, and the idle task thread, which is a variation on a task thread.

But there's only one task thread per processor. So that means all the work is really done by the child. So that means all the work is really generally being done on one thread. And this may mean that if you have a module or if you're doing something in the server and it's going to take a long time, what you want to do is possibly create your own private thread. And let's take a look at how these threads can affect a module or processing inside the server. So let's switch over to demo one.

And I'm going to run a file module that I have modified. And what this module is going to be doing, is blocking in order to do some long task. Maybe what you can imagine it doing is downloading a file from another server before it can stream it. So a request comes in, and it's going to have to download it first. So I'm going to open up just a regular movie file here. Now I'm going to call my special module that's going to go off and do some work.

So here it is, and it's busy downloading this file. And it's doing it in just a tight loop. It's just going to block the whole server because it's only the one task thread. And it said, okay, when I'm done, then I'm going to return from the service call into the module and respond to the request.

And you can see at that point, what had happened to the previous client who was busy watching was that they were frozen. So the server API does support having a module take a little while to do things. And the way we do that is we provide a call called setIdleTimer, which is going to tell the server to call it again because it's busy doing some work.

So, in this case, yeah, this, the module might be busy downloading something, copying a file. It could be doing a DNS lookup, which is completely blocking the server, but at least the whole server isn't frozen. So this is one of those things you have to be aware of when you're working in the server code. Now, there is one last thing I want to show you, and that is what happens... If you're going to make a call, maybe it's get host by name, where it's going to go and you have no control over when it's going to come back.

It could be 10 seconds from now. How do you deal with that? Since you can't, in the middle of the call, return control back to the server, what you need to do then is fork off your own thread. Now, the QuickTime Streaming Server source code has an OS thread class, so I just decided to use that. And what I did was I just instantiated the thread and told it to go ahead and make my blocking call.

So in this case, I have a tight loop that normally would be blocking the entire server. However, in this case, because it's on its own thread, I can still play movies. So just something to think about. There is, in most cases,

So the reason for the number of threads was to keep our thread count low, and this is a performance optimization in the server.

And the same idea is true when it comes to having only one process. The server runs faster. It is much more efficient to have fewer numbers of threads. It just means that as a programmer, you have to be aware of this architecture and design appropriately. So let's take a look at the core server now.

We have A few main objects that you're going to see in the core server. And the first one is the QTSS server. This is the class that's going to get instantiated and it's going to load up each of the modules and execute them. There are the callbacks. This is the API.

So every time a module makes a QTSS API callback into the server, it's implemented in something called QTSS callbacks. We have QTSS dictionaries in the core server. These are data storage. It's a key lookup with a value associated with the key. The QTSS dictionary, once again, is there to support the API.

We have RTSP sessions, which is the RTSP protocol with the server supports, and various other files associated with RTSP that protocol parsing and formatting. There's RTP session, yet another protocol class, and its support. Finally, we have server preferences that basically configure the server when it starts up. So all of this actually could be summarized that there's a QTSS server class that's going to load up your modules.

There's some API support classes that provide your modules with roll calls into the module and callbacks from them, and protocol support inside the core server, followed by configuration preferences. This is an example of the file module. Every time we request a movie from the Darwin Streaming Server, it's going to go through a series of calls into the file module.

In this case, normally when you're looking at our API, you're seeing the right-hand side of this diagram, which is the roll calls that this module will be getting called in. And these are the times in which the module gets called. What that means on the server side is the QTSS server, which we said owns the modules, loads them up, is going to initialize the module when it first starts up.

And after that, the module has already decided that it wants to handle RTSP requests and has told the server that, in the register role, that if there's an RTSP request coming in, I want to see it. And I want to be able to process that. So when an RTSP session gets initialized on the server from an incoming client, it's going to go ahead and call into this particular module to handle the request. In this case, let's say it was a play request.

The module's going to take that, process it, call it back into the server, which will go to the RTSP session. And in doing a QTSS play callback, this is going to kick off the RTSP session with the client. What that means is now the server is ready to respond to the client with the play request response.

And then start calling into this module for packets. And so the next roll call that this module starts receiving from the server is going to be the send packets roll. Basically, the server's going to keep saying, give me a packet, give me a packet. And the module in that roll call is going to go out, find a packet for each of the streams, and do a QTSS write. So this covers pretty much a basic module. It's going to get loaded. It's going to say, these are the rolls that I want to support. It's going to get called in those rolls, and it's going to call back into the server after it's done its own processing.

So there are a number of modules that are pre-built into the server. When you launch the server, there's several modules. And I've categorized them by content, support, and access control. What we have is-- The content modules here, which starts with the file module. This is your basic module that is going to do MPEG-4 streaming. It's going to do 3GP support. It does QuickTime movie file support.

It handles describes for RTSP. Basically, when it starts up, just as we were saying before, it's going to say, I want to handle RTSP requests, and I want to stream out packets. So it's going to do those two roll calls. The Reflector module doesn't handle files. What it does handle is incoming broadcasts, live streams.

It binds to a port. It handles requests for STP files, which then the Reflector module, when it comes time to write packets, is going to be pulling it from an incoming broadcast stream and sending them off to the client. So that's why we call it the Reflector. There's an incoming broadcast, like a live broadcast. And this module here is going to be the one that's going to be sending those packets out to the clients.

We have a relay module which is similar to the reflector module except that it has a built-in broadcaster as well. What it does is it goes in, it grabs a broadcast stream, It's coming in and then it forwards it on to another server. It could actually be a multicast address.

So, in which case, you could just go ahead and forward it on to the multicast IP address. But the idea here is that it's pushing a broadcast someplace instead of waiting for a client to come in and request the broadcast, which was the reflector module. The MP3 Streaming Module is another broadcast support module.

What this does is it grabs an incoming MP3 stream, kind of like an icecast or shellcast type of stream that might be sent to the server. So each of these is going to handle a request in a very particular way. It's going to intercept the request, decide if it belongs to itself, and it's going to respond to the client, and then handle the data.

Now we have some service support modules built into the server. Some of these, you know, if you're thinking about changing the server, let's Start here if it has to do with access log or maybe pulling out some statistics out of the server. These modules are built into the server. They're great pieces of sample code for you. There's the error log module, which obviously is just going to go ahead and record errors into a file. But we also have the access log, which has each access to a file logged into the access log.

And maybe there's something in there that you just need in addition to what's already written out. There's the average bit rate or there's the time connected. But maybe there's something else that you want thrown in there. Maybe the codec that was used. Well, take a look at the access log. Maybe what you need to do is just change that. Or you could go ahead and rewrite your own log, of course. But this is built into the server. It's there in the source for you to take a look at.

There is also some other modules like the webstats module. It's a HTTP module that will return an HTML web page. And it will pull out some information from the server and generate the web page. So a module isn't restricted to streaming protocols. There's a server that's going to call your module. You can decide whether or not you want to handle RTSP requests. Or you can decide you want to handle something else, like an HTTP request.

We have a web debug module, an admin module. The admin module is an interesting one because what it does is it takes an HTTP style request and uses and looks for something called our admin protocol. This is a URL based protocol that references any of the data that's in the server.

So this is how our UI is implemented. Basically, you can go ahead and grab anything out of the server using the admin protocol implemented in the admin module and set it as well. And you can do this remotely if you want to. Finally, we have the POSIX file system module. This one doesn't deal with requests. It doesn't deal with logging. What it is is a low-level implement support for reading files.

So each of the modules that are in the server call through the API to read a file. And it all gets funneled through the POSIX file system module. And this could be replaced so that if you needed to do something like a network file system, you can go ahead and change this implementation to do some other kinds of file system calls. Maybe you're pulling the data out of a database instead of coming right off the disk. So once again, more modules that are built into the server. more functionality that is available to you.

Finally, we have the access control modules. These start out with the access module, which handles authentication and authorization. We have a Apache-style users and groups file. Basically, it's going to go and check that file to see if a user has access to any of the movies on the server.

There's a home directory module. This one takes a look at the URL and says, "Oh, do I have a tilde John in the beginning of the path?" And it says, "Okay, this means that this movie is coming out of the user's home directory movies folder, not the main server's movies folder." So what that does is it allows users who have access only to their accounts, their movie folders in their home directory, and not to the main server, to put up movies onto the server. And then everybody can reference them, but they can only administer what they own.

There is an HTTP file module. It's kind of interesting. It's a dynamic module. We usually have it turned off. What it does is allows you to download a file. So it's not a--it could be-- an example would be like in a progressive download. It also has the ability to, on the fly, create a ref movie out of a folder of movies. So it actually pulls up, takes the request, and says, "Oh, this is a directory." And then it looks inside that directory and says, "Oh, I got three files here." It creates a ref movie.

The SpamDefense module is another one of these optional modules that comes with the source. Basically, it can limit the number of requests coming out of a single IP address. So if there's hundreds of play requests coming out of a single client and just spamming your machine, the SpamDefense module can put a clamp on that and say, look, we're only going to allow 10 movies being played from a single IP address. So these are access control types of modules. There's the data ones, the content modules, there's the basic support, and then access control. So I'm going to go over and switch back to our demo system.

And one of the nice things about having the source code is that if there's a behavior in the server that you want to change, then the code is there waiting for you. And all you have to do is find the right place to throw your code in, and you can basically change the behavior of the server. So what I did is I said I wanted a file module that every time I gave it a URL, like "next," I wanted it to give me a different movie, like this one.

So downloading the source and going in there and saying, OK, before I pass the file name off to the open file command, I want to be able to replace that. OK. Couple lines of code, swap that in there, and now I've got a new behavior in my server.

Now, you might want to create this as a module, or you might, if you have complete control of the server, then go ahead, change it. It's all right there. Add your behavior. Now, another module that I had mentioned in our talk earlier was that the Web Stats module And that's a dynamic module.

We can... You see some of these modules installed on the system. These are dynamic modules here. Basically what that means is every time you throw them into this module folder and launch the server, they're going to be executing when the server runs. These are other modules that can be thrown in there and run.

And once again, these are all part of the Darwin Streaming Server source and are available to you to look at, modify, use, or change. So getting back to that WebStats module that's in the server, what we can do with that is go ahead and call it. Let's see.

What we're doing here is we're waiting for the system to come back from doing some sort of network I/O. Okay. Now I have a server back again. So what I have inside of -- on the screen here is an admin module request into the server to find out a preference. And this module preference is WebStats, and I'm going to take a look at what it's going to show me.

Okay, so this module just grabbed the request coming into the server and said, "Hey, it's web stats. I'm going to handle it." And what it's going to do is it's going to respond, but instead of a -- since this was an HTTP GET coming into the server, what this module decided to do is it's going to generate an HTML web page and send back some information about the server.

Now, maybe what it could have been doing is copying a log file on demand over to some other machine that's collecting all these statistics or doing something like that. This module here, or maybe this command was coming in from another UI. Somebody has integrated the QuickTime Streaming Server administration into their user interface for controlling multiple servers or something like that, and this module perhaps is supporting that. So once again, there's various ways in which you can access and control the server, and This is one of them. Just toss a module in there, and away you go. You have a new feature inside a QuickTime Streaming Server. So we can switch back to slides.

Okay, so the server is a thin piece of code, but there is actually, in terms of when it's executing, but there is a lot already built into it, stuff that maybe you don't want to have to rewrite, and if you have the opportunity, you want to be able to use. So that means that we are going to be supporting RTSP over TCP for you, RTP over UDP. Apple's skip protection is built into the server. That's RTP over reliable UDP.

What that means is there's UDP packets going out with acts coming back, and the server has the ability to do retransmits using this protocol. There's RTP and RTP tunneled in HTTP, which is basically how do you get around firewalls. There's RTP over RTSP, which is RTP on top of TCP. So these are all standard protocols, streaming protocols, and they're built into the server. It automatically will handle these connections.

Now, one of the protocols that it doesn't automatically do for you is HTTP. Basically, there's a request coming in, but it itself is not going to do anything with it. If you happen to have a module that wants to, basically, you would grab that request and decide based on the URL whether it was meant for you or not and do something with it.

So, one example is the QTSS admin module that's going to look for a URL path and it's going to decide, "Yes, this is a path that belongs inside of the server and I'm going to go ahead and respond to it." The MP3 Streaming Module is another type of HTTP support module. It looks for IC protocol requests that are coming into the streaming server. Websats Module, we just looked at that.

And so on and so forth. There's other types of modules here. The refmovie module is going to take a HTTP GET on a file, a movie file, and generate a RTSP request. Send that back in the response to the GET, and that tells the QuickTime client, "Oh, what I really should be doing here is not a GET but an RTSP on the file." And it turns around and makes the RTSP request. Looks like we have web sets twice. And a web debug module.

So that's very similar to the web stats, except it gives debugging information. When the server is compiled with debug enabled, the debug module is going to show up with an HTML web page for the programmer to see real time what the memory allocation in the server is, maybe how many file descriptors are open, things like that. There are, of course, other ways of getting that type of information, but this is one way in which -- a handy way in which this can be done.

Okay, so the server has these roll calls that it's calling each of the modules in. The roll calls look like, here's a request, here's a route roll, which is sort of a prerequest call. And along with each request is going to be something called a QTSS object. And these are inside of the server.

Basically, a dictionary that goes with each of the classes that the server supports. So there's the QTSS server class, and it has an implementation called the QTSS server interface. That's the dictionary that's going to support the API. We have RTSP sessions that get generated whenever a client connects. There's an RTSP session interface that goes with that class. It's an RTSP session interface.cpp file. And basically what that is, it's a dictionary implementation for the API to access the data that's in the RTSP session object.

Same is true with RTP session, another type of protocol management class that's in the server. And for every request, there's a request object that shows up inside of our API that has an interface file associated with it that's a dictionary that's That gives access to the data. So here's the object hierarchy that's built into the server. You have your main server.

Once again, the server object has a QTSS interface file associated with it. It contains modules, server preferences, and client sessions. When we look at the server object, we'll be able to pull out the client sessions. We can pull out the server's preferences that are currently active. We can grab each of the modules that the server is running. And then within the modules, there's preferences for each module that is instantiated inside of the server.

So what that means is when you create a module, you can say, hey, I want to have my module's preferences added to the server's XML preference file. And there's an API call to allow you to do that. All of our modules that come in source code do this. So that means that... The preference is for your module or immediately configurable or editable by the admin protocol, meaning a user interface can go in there and remotely configure your preferences without you ever having to write anything to support remote admin of your module.

The client sessions, of course, you might want to find out some information about the stream in real time. What's the current bit rate of the stream or the session, all the streams that are currently playing for a given client? And so the dictionaries give us this ability to walk this tree of data real time, pull it out of the server, and if you want to log it or use it to maybe limit the number of users, you know, finding that the current bandwidth is just getting too high, and real time you want to start limiting the server in some way by number of users or by bandwidth, you can go ahead and change the data that configures the server real time by accessing our user. data hierarchy.

So I want to use the admin module that we've been talking about just to show you what some of these... objects look like. And basically, the admin module takes this admin protocol, which is a URL-style request, and maps that to the hierarchy that's inside the server and pulls out the information, and can actually set it too.

So if I wanted to grab the server object, and I want all the fields within the server object, I'm going to fire off a request to the admin module, and here it is. So now it's giving me back everything that it knows about. One of the things it has inside the server object is the list of modules. So there's a dictionary.

Up here at the top, I can see my path. There's a dictionary key called the server module objects, and here are my modules. If I were to drop a server module, I would have to drop a server module. Stop the server, drop a new dynamic module into my modules folder, and relaunch the server, it would show up in this list. Now, each of these modules has its own preference, and let's see if I can pull that out.

It has many different layers, but each module, you can see, has all of its settings and can be configured here remotely. So none of the modules really have to worry about, gee, how am I going to configure this thing? It's easily configurable once it's loaded up into the server. And since this information is written back out to the server's XML file, it can be edited even when the server isn't running. It can change the XML file to modify the preferences. So let's take a look at a stream.

And I want to see the sessions that are currently running. I have one client-server session. I want to drill down into that session. Okay, so I have some session information right now. I have a URL. Looks like I have an average bit rate, a movie file size. I want to take a look at the streams. Looks like there are two streams. I want to see if I can find the codex. Looks like I have an MPEG-4 codex.

It looks like an MPEG-4 video that's playing. So, for every single stream that's currently playing on the server, I can grab real-time information. I'm doing it through a module. If you have a module that's currently running, its job is to be monitoring how many people are watching this particular movie right now and maybe I need to start redirecting clients someplace else or maybe I just need to start denying clients. Imagine a module doing that.

The API common code, all of the modules use it. It's basically there for sets of API calls that kind of seem to go together. And, you know, I want to create a new preference and set its value, and this is where usually we throw those types of commonly used code together. So you might want to go ahead and see if there's any of that code in there for your module that you want to use or emulate.

The API modules themselves, the implementation for all the modules I've shown you, is in this directory. You can just walk through there, do a grep, just browse it, and pull up the source for any of the modules. RTSP ClientLive is... It's just a library, but basically when you instantiate it, it's going to give you the ability to connect to a streaming server as an RTSP client. You can tell it to do a describe.

It will get back the SDP response. You can ask it to start playing, and it will pull down a RTSP stream. It will do it over any of the protocols that the server supports. So this is how we test out our server using this library. If you tell it, "Instantiate something from the RTSP client live to connect and download over TCP," it will do that, or in HTTP using reliable UDP, perhaps, or skip protection. That's the RTSP client live. The server actually uses it in a couple of places.

One of them is in the relay. The other is in our file broadcasters. In particular, the playlist broadcaster has a built-in client and it uses RTSP ClientLib. And one last piece, the streaming load tool is a little piece of binary code that goes out and does load testing. And we use the RTSP ClientLib in that tool.

So RTCP utilities, if you're interested in RTCP protocol for some reason, maybe there's a bug in the server, who knows, but the code is there for you to take a look at, fix, or change if you need to. Same thing is true with HTTP. And so that's the top level of the source tree as you untar it.

When you go ahead and build our code, you're going to end up with more than just a streaming server. You have the playlist broadcaster, which is like the name says, it takes a playlist of movie files and concatenates them together and streams into the server. And these can then be turned around by the server to support each client that may be requesting the live stream. Actually, it's a pseudo live stream, of course. The playlist broadcaster will loop the list of movies if that's what you ask it to do, so it will have this continually running playback of some keynote speech or something like that.

Also, there's an MP3 broadcaster, which is the same idea, except it's doing it for MP3s instead of MPEG-4s and QuickTime movies. We have a streaming proxy, and that source code is there. There's Qt file tools. Those are for those people, once again, who are interested in the MPEG-4 movie file format and want to see how it goes out and extracts the packets out of the files.

These tools basically are command line tools that you can go ahead and rip out streams of packets from any given hinted file. The web admin is our user interface that we provide with the DaRwin Streaming Server. So let's say you want to personalize or privatize the web admin, so it doesn't say Apple QuickTime Streaming Server all over it. You want to throw in your own UI to the HTML. This web admin is in the source. You can go ahead and change it.

As well as the Qt password file. It doesn't really do much. If you want to add users and groups, you run the Qt password file. If you don't like the format for some reason, go ahead and change it. If you want to use our code, fine, it's there. Or you can replace it, of course.

So one of the things that you might want to do is just change the name if you're deploying it with your product. Your QuickTime or DaRwin Streaming Server doesn't really work for you. You want to call it My Demo Server or Your Server. And so you can go ahead and change those constants that are available in the server. There's a few places you have to go and look for things. If it's OS X, you want to look in the project builder file.

There's -- if you're dealing with the web admin, then you're going to be looking in the profile that is part of the web admin. There's basically the installer scripts. You can find it pretty much by doing a find text and file. And so then you can package it up and distribute it with, you know, maybe your hardware server product or something like that that shifts with the DaRwin Streaming Server.

Once again, building the software, we have a buildit script. This is what you would run at the command line to build our POSIX version of the server. You would just find the script and run it. It also works for OS X. If you don't want to use the project builder project, you can just execute from the command line, rebuild the binaries, and test it. It will show up inside of a build directory on OS X.

On Windows NT, it's a little bit different. We have a Windows NT support directory. So those of you who are building your software for Windows are going to go down in there, find your Visual C++ project or worksheet, load that up. You want to do a batch build, and it's going to generate a debug and release directory and throw all the binaries in there.

So once you have your software built, you want to be able to create an installer. Now, at this point, it kind of goes into how do you want to do it. The pre-built binaries that Apple has on our site for you to download are all created using this build tarball script, which goes ahead, builds it, generates an install directory, tars it up, and then you go ahead and download it, untar it, run the install script, and it goes ahead and fills it up.

And that would be for the POSIX platform. On OS X, we have a script that's going to build an OS X installer package for you. So it's going to go off and do all the pieces and throw it into this installer package. The important piece about the build OS X installer package is that there is some logic when it's installing as to how to upgrade existing installations.

or what to do about So, I'm going to start off by setting it up with the proper users and groups that the server might need. On OS X, for example, and version 5, we're going to be running as user QTSS, and the installer package will make sure that that user is on the machine so that when the server runs, it can go ahead and stream. Windows NT, we just use a make zip package that the bat file goes ahead and organizes the files for you. You might want to edit or change that yourself.

So we're going to move on to troubleshooting. So after you've gone through, you've created your module, you've edited things, you've built it, you've created an installer. If you find that you need to troubleshoot the server, there's some commonly used debugging preferences that we have. And the first three that I have here have to do with protocol. And the first one is RTSP debug printer.

So I just want to see if I can do that. And the second one is RTSP debug printer. So I just want to see if I can do that. And the first one is RTSP debug printer. So I just want to see if I can do that. Now, just following that is the packet header printout.

So, the actual data packets themselves, you don't want to -- it will -- just like the RTSP printfs will show you the RTSP, the packet header printfs are there to show you the media packets that are being sent by the server. So that means that if there's an RTP packet, a receiver report, a sender report, an application packet or an ACK, the ACKs are for the skip protection, then you'll see them as they come into the server or get sent out. And if you do have these on, you want to be able to see them, you're going to need to run the server in debug mode, which means at the command line, add a dash D.

Okay, so I'm going to just turn on the debugging printfs here just to show you what they look like. I'm going to go ahead and add, um...

So at this point, what we should have is a streaming server that has our debug printfs in it. Whenever it wakes up.

Let's try a different URL. Oh, there it is. Okay. Okay, so we don't need this anymore. Okay, so the RTSP debug printfs. We have an RTSP request here. Describe and some more information. And a file module that accepted it and sent back something called a SDP right here to the client. And this is just handy information that as you're debugging your module, you might need to take a look at these requests. So another type of request I'm going to try is

Okay, looks like what happened is it started playing.

started playing and it looks like it's streaming, but I just didn't HTTP get. So we can take a look at what all this thing is doing by looking at our RTSP debug printers. It looks like a GET went to the server and a module there picked it up and returned the HTTP GET with an RTSP URL.

: I guess that means that what I should be doing is an RTSP describe with this URL. So this could be a redirect, actually. It's not an RTSP redirect. What it is is an HTTP GET that contains a redirect in the response. Now, you can imagine this module that happens to be available inside the source code.

It's called the refmovie module, being used in lots of different ways to generate different redirects or different types of responses to the client so that you can go ahead and have it RTSP to some other movie or some other server even. So that was how we take a look at what's going on in the server when we're debugging the using the RTSP debug print apps. And let's go back to the slides.

And in the slides we'll take a look at a couple more debug printfs. Basically, you can turn these on when you compile the server. One of the useful ones, if you have a module that's doing something kind of tricky, it's handling a lot of different roll calls. Maybe it has its own threads. You might want to take a look at when it's actually getting executed. And the way to do that is find in our common utilities the base class for a task, which is the basic entity that's getting executed in the server.

And if you would turn on the debugging there, you'll find all these printfs that show up that say, oh, the server is working on an RTSP session right now, and there's an access log call right now that's being executed. So you can find out exactly when all the modules and what their interactions are by turning on this debug printfs.

In the file source, there is also another handy little flag. You can turn this on and you can pretty much see what the reads -- what kind of reading is the server doing. How often is it hitting the disk? Is it reading all over the place or does it seem to be reading sequentially? How is the caching working in the server? And this is the file source debug. There might be some reason where you are transferring the reads off to maybe a database or something like that instead of the file system, and you want to see how the reads are being handled in the server. So another debug option for you.

So as I was talking about the server and its protocols, I mentioned RTSP, RTP, SDP, Session Description Protocol, and all of these have RFCs available on the Internet. So if you want to take a look at the protocol and find out more about what clients might be doing with the server, what the server should be doing, or what you can do to change the way the behavior of the server, you can take a look at these RFCs up on the web. There's some other open source projects that handle RTSP and RTP.

One of them is the MPEG-4 IP on SourceForge. So they have an open source client that actually will play the audio and video, and it will work with our streaming server. It's an open source client. In fact, they even have an encoder, I believe, as well. So they're related.

Streaming sources are resources that you can find out there on the Internet. Live media is yet another one. These are open source. And we interoperate because we have our standards base. So as you can see, there's RFCs. When it comes to Codex, MPEG-4 is a standard that we believe strongly in and our server supports.

So the programming for our QuickTime Streaming Server is essentially just a matter of going in there and getting the source code, looking at the modules, finding out what we already are doing, thinking about what we want, you want the server to be doing, and go ahead, change the code, add your module, add your functionality, and now you have a new server. And we hope that we can add more functionality to the server for you as well. But we have -- we're making progress.

Each year there's new features into the server, and we're working on that.

So just as a side note, you can see the big yellow ball there. The QuickTime feedback forum has changed venues, so we will be moving to the marina as soon as we finish with this conversation here.

Since most of these presentations already happened, I just want to remind you that as attendees to the conference, you will be getting access to the stream versions of the presentations in the next few weeks. So if you missed any of these or you want to go back to see what was mentioned, something that you missed, this will be the opportunity to do it. And you will also be receiving a package of DVDs that contain all the sessions of the conference.

So this is coming to you in a few weeks more than the download streaming movies, which will be quite opportune for this session. So if you have any other questions or if you need some information, [email protected] is the address that you want to write any questions, and we'll try to route them to the right people. people.

Documentation. Apple QuickTime is the main page for any information on QuickTime. Developers.apple.com documentation is for general documentation on QuickTime. I don't think that we have anything special for this session, but again, as attendees to the conference, there is a number of downloads that are available only to you right now. So you have to go to the connect.apple.com, log in as a member of ADC, and you will get the download under the WWDC 2003 menu.

More information. There is a streaming server mailing list. If you want to have a conversation with all your colleagues all over the world who are using the technology, more information on what to get for the streaming server modules. We are getting to the ending of the conference, but you still have a day to go to the QuickTime lab downstairs. It's in the Sacramento room. And have an engineer in there to answer your questions about QuickTime programming.