Setting up your own on-demand video site with PHP, Part 1: Groundwork

On-demand video isn't just for entertainment -- Build an enterprise-ready on-demand video library with open source tools

Setting up your own on-demand video site doesn't have to be complicated. Upload some videos and put them up for people to watch — easy enough. But if you're going to be doing a lot of videos, you'll need a way to keep them organized. This three-part "Setting up your own on-demand video site with PHP" series takes you through everything you need to know to create video optimized for the Web, as well as creating a PHP application that will help keep your videos organized and accessible. Here in Part 1, we lay the groundwork by assembling and installing the necessary components and gathering and converting the video. Part 2 builds the basic application. And in Part 3, you add create a slick user interface and integrate the example with YouTube.


Duane O'Brien, PHP developer, Freelance

Duane O'Brien has been a technological Swiss army knife since the Oregon Trail was text only. His favorite color is sushi. He has never been to the moon.

developerWorks Contributing author

Katie Horn, Developer, Freelance

According to her mother, Katie Horn has spent far too much of her 28 years on the computer. She has a degree in computer science from Chapman University, after which she has mostly enjoyed the jobs with "systems" or "engineer" somewhere in the title. Despite a degree of proficiency in the area, she would prefer never again to be called "network admin."

Will Robot, PHP Developer, Freelance Writer

Will Robot is a semi-professional dabbler in too many things. He lives with between four and five cats and thinks anything can be improved with the addition of a laser and at least two blinking LEDs.

01 April 2008

Also available in Portuguese

Before you start

This series was written with the developer in mind. You should be comfortable working with PHP and Web applications. You don't need to be an expert to go through this series, but not a lot of time will be spent explaining PHP syntax and Web application concepts. If you're unfamiliar with either, but keen to learn, feel free to dive right in. It wouldn't hurt to have some basic understanding of digital video, but we'll explain most of what you need to know.

About this series

Part 1 covers the putting together of the pieces, installing the components, dealing with video conversion, and preparing for the application. We lay out lot of groundwork here. There's a lot to learn about digital video, and we'll need to get set up for doing all the coding in Part 2.

In Part 2, you build a basic application to manage the uploaded files and the tagging. You'll be using a PHP framework — CakePHP to be exact — to help jump-start this process. The application won't be another video-sharing site. The focus will be on managing your own files and getting them up there for people to see.

In Part 3, you add some advanced features and create a slick user interface. We'll smooth out the UI and look at using APIs from popular video-sharing sites to disseminate your videos. If Part 1 is about getting up to speed, and Part 2 is about making it all work, then Part 3 is about making it awesome.

About this tutorial

In Part 1 of a three-part series on creating an on-demand video site with PHP, we begin by looking at the different flavors of digital video and their particular nuances. When creating video for the Web, the overarching issue you need to keep in mind is whether you want your video to be small and easy to download or whether you want it to be the best quality possible. We'll also look at converting your video to the Flash Video (FLV) format and examine some options for streaming. There's not a lot of coding to be done at this stage, but we do have to get the framework installed and set up the database.

System requirements

To work with digital video in this series, you'll need to set up a few things. (installation of basic components won't be covered here):

  • Some digital video content — It can be video you've found, shot, or imported from another medium.
  • A Microsoft® Windows® XP box — The examples provided use some software written for Windows XP.
  • FFmpeg is an open source command-line video-conversion utility.
  • Riva FLV Encoder V2.0 for Windows is a video-conversion utility that is no-cost for the first 30 days of use.
  • Wikipedia for FLV-conversion programs for other platforms.
  • Red5 is a Java™-based open source Flash server.
  • JW FLV Media Player V3.15 is a small, embeddable Flash media player.

For the Web application, you'll also need:

  • An HTTP server that supports sessions (and preferably mod_rewrite) — This series was written using Apache V1.3 with mod_rewrite enabled.
  • The 1.2 beta version of CakePHP.
  • PHP V5.1.4 or greater — Not all the frameworks being examined require this release level of PHP, but all frameworks will use the same PHP installation. This series was written using PHP V5.2.3.
  • A reasonably recent version of MySQL — Several other database options are available and supported, but this series and the sample application were written using MySQL V5.0.37.

If you don't know anything about writing code, PHP, databases, etc., you will find this series challenging. You should get up to speed a little on writing Web applications in PHP first. (See Resources for links to each project.)

The ins and outs of digital video

If you've downloaded digital video content, you're painfully aware of the different video formats, some quite obscure. Before you can jump into sharing your videos, you need to understand something about the formats you are likely to encounter, as well as some considerations you need to make when you begin converting your video from one format to another.

Jumping in with both feet

Getting into digital video can be a daunting proposition. There is a dizzying array of video formats out there in the cold, and uncountable tools to edit, convert, fold, spindle, and mutilate them. To add to the fun, much of the information can seem confusing or even downright contradictory, leaving you adrift in a sea of information overload. However, since our goal is to stream video through our Web site and not distribute DVD-quality video, we can toss a lot of the more esoteric concepts into a corner and concentrate on the practical problems.

Getting video

If you are getting your video from an old analog camcorder that records on tape, you will need a video-capture card or an external USB or Firewire video-capture device. If you have a digital video camera that supports analog-to-digital signal conversion, you can actually run the old video through your camera and into your computer as if it came from the DV camera.

If you are working from a digital camcorder, the information is already digital and all you have to do is plug your camera into your computer. Check your manual for instructions on how to transfer your video to your system.

If you do not have a digital camera, you can use pre-existing video from sources such as the Internet Archive (see Resources) or other free or cheap stock-footage sites. You can even create video slide shows out of photos in many editing tools, including software that may have come bundled with your system.

File formats

It seems there are an infinite number of file formats and no end to the amount of detail you could get into on each one. Let's narrow it down to the ones we are most likely to deal with for digital video. The most common formats:

  • DV and HDV are typical formats for video cameras, and are widely supported by software on many platforms. HDV is essentially a higher-resolution DV file.
  • AVI is a common Microsoft format with support on other platforms, though this format is considered somewhat outdated since other formats, including Microsoft's newer WMV format, have similar quality with a smaller file size.
  • MOV is the Apple Quicktime format and is widely supported across most platforms, making it a popular choice. This format was the de-facto Web streaming format of choice until FLV came along.
  • MP4 is a compact file format with above-average sound. This format is popular for use with mobile devices and is useful across many platforms, but you may run into problems using it on older systems.

The last format to mention is Flash Video (FLV). We will be converting our video to FLV format in order to stream them from our site. Right now, with the Flash player installed on most systems connected to the Web, FLV is one of the most supported formats around, meaning more people will be able to watch your video. FLV also gives you access to a wide range of Flash-based media players, which will come in handy later.

Size vs. quality

Streaming digital video is a battle of compromise. Ideally, you would present a full-screen high-resolution video with little or no compression indistinguishable from a DVD. Of course, in the real world, that means long download times, so let's take a look at all of the important factors involved.

When you're converting your video file from its original format into your ready-to-stream FLV, there are three factors you can control: time, frame size, and compression. Each of these is an element of the file containing information that you can adjust to cut down on the size of your file.


Time is the most straight forward. If you have a video that is twice as big as you want, just cut half of it out. Of course, this may not always result in a usable video, but it is something you have control over when you are shooting your footage, so it shouldn't be entirely discounted. Another option in the realm of time is that instead of taking out parts of the video, you could just show less of the whole thing. A video file is essentially a series of still images shown in sequence so this can be done by reducing the frame rate, showing fewer images for a longer period of time. The compromise here is that the fewer frames per second, the choppier and jerkier the video gets. Take this too far and you end up with a slide show.

Frame size

Frame size is your next consideration. As mentioned, your video is a series of frames, each being a grid of pixels taking up space and memory. It shouldn't be an intuitive leap that if you remove some of these pixels, you are reducing the size of your file considerably. Each pixel you crop out frees up a pixels worth of space multiplied by the number of frames in the file. Just remember when reducing the size to trim the same amount from the height and the width to maintain the same shape. You may remember the age of postage stamp sized videos in the middle of huge empty screens. There's no need to go that far anymore. A target of around 640x480 pixels is a good size for the Web these days, so you don't have to sacrifice too much. Of course, there is a trade-off here, as well. When you dispose of these pixels, you aren't just cutting them off the sides (well, you could but that would result in some odd videos):You are taking an amount of information and averaging it together to make the same image smaller. The image will not contain the same level of detail, and if you take too large a file and make it too small, you may get some unpleasant artifacting. As an aside, it is also possible to take a small video and make it larger, but the results are typically far worse than just leaving it the size it is.


Our last element is compression. We will ignore a great deal of the subject for now and stick to the most relevant points. In a digital image, compression is done by looking for information that can be removed without us noticing. Areas of repeating information — pixels that are the same or similar — are replaced with a description of the area so an approximation can be shown to us when we open the image. An example would be a blue sky. The area that makes up the sky may contain thousands of different blues, but we only really notice a few. So the compression takes these areas, averages them, and dumps all those blues we don't really see, notes the areas that should be filled with the same blue, and next time we open the picture, it shows us a simpler sky.

With our series of images, compression can also work in the dimension of time. In the same way that a flat area can be averaged, so can a stream of information. Since a pixel may not change much from frame to frame, why not replace the stream of 1,000 similar blue pixels with an instruction to just not change it for the next 999 frames? Of course, if too much compression is used, this can make your video look odd. You have probably seen video where huge flat areas sit static until the blocky shape of something in motion passes over them. This can be caused by applying too much compression.

So with these concepts in mind, we can move on to the conversion of your file from its original format to .flv for you to use on your Web site.

Converting to FLV

There are quite a few video-conversion programs available. The open source command-line utility FFmpeg (see System requirements) could be used directly, but the project has a policy of never cutting releases in favor of presenting daily snapshots of the source code as it stands. So, we don't recommend using FFmpeg unless you have some time to kill, are comfortable downloading and manipulating files with extensions like and have a C compiler handy.

Happily, there are freeware programs out there that use FFmpeg to do all the actual work, but wrap it all up in a relatively soothing GUI with a nice, friendly installer. For the purposes of this article, we will be using one such program: Riva FLV Encoder V2.0 for Windows (see System requirements). For those of you who aren't Windows users, you may find it useful to check up on what Wikipedia has to say about available FLV-conversion programs.

Riva is simple enough that reasonably adventurous beginners will be able to turn short videos into decent FLV files within minutes of installation. Once you launch the program, just use it to browse to the video you want to encode and click the Encode button near the bottom of the screen. Once it's done cranking away on your video (It might take a little while — longer for longer videos), you will be able to preview the FLV you just made by clicking the freshly activated Preview button at the bottom of the screen. Now that you have verified that it really is that simple, we can relax and start poking around a bit.

Figure 1. The Riva FLV encoder
The Riva FLV encoder

One of the first things you should notice is that Riva FLV Encoder comes with video-encoding presets, presumably based on expected bandwidth available for different connection speeds. Since our goal is to produce a video suitable for streaming to a wide variety of different setups, you can safely ignore their "Offline" preset and head up the list for something a little more realistic.

Riva's ISDN preset is 240x180, with 15 frames per second and a bitrate of 96 Kbps. In contrast, their DSL preset sits at 640x480, with 25 frames per second and a bitrate of 360 Kbps. You probably want to play to something in the middle of those two extremes, so it is safe to think of those specs as lower and upper boundaries, outside of which you probably don't want to stray (unless you really want to). YouTube, for example, encodes videos at 320x240, with a variable frame rate, and a slightly variable bitrate right around 310 Kbps.

Sadly, there is no universal "right" set of numbers that always produces an ideal result across the board. Video encoding always works best when you have the time to tweak the process on a case-by-case basis. Mimicking popular setups will get you something that will generally work in a satisfactory manner, but a de-humanized encoding process is incapable of watching the video afterward to make sure it still communicates what it was intended to. Until somebody manages to write an automatic encoder that can do things like validate comedic timing, the encoding process will remain as it is: a variably complicated balancing act.

A few more notes on encoding

Generally speaking, videos with less overall movement can afford to have a higher frame rate without taking quite so much of a hit in picture quality and will be, therefore, much easier to encode in a satisfactory manner. Sadly, the opposite is also true: Videos that have a lot of exciting movement are likely to present problems, such as the picture suddenly turning from something perfectly discernible to a mass of colored blobs, exactly at the point when the action is supposed to get good.

The picture size you choose to convert to should be the same aspect ratio as your source video or it will end up framed incorrectly. Typically, in America, you'll be working with NTSC video, which has a 4:3 aspect ratio, while Europe's PAL is in 5:4. Most HD video has a native aspect ratio of 16:9. Also, you will find that the picture almost always comes out cleaner if the math is easier to perform. For example: Let's say you decide you want to shrink a video's display size. If you arrive at your target size by dividing the width and height of the original by 2, the encoder will be able to throw out every other row and column of pixels to get your desired size. That's easy. If you instead choose to divide the size of the original by, say, 3/2, the encoder now has to figure out how it wants to trash half a row of pixels for every full line you're keeping. That ends up taking a lot of averaging and can result in images that are far less clean than the slightly smaller video generated with more convenient math.

It is likely your source video is interlaced if it was shot using a video-recording device primarily meant to output straight to pre-HDTV. If you ever had to convert your image from analog to digital, it is probably interlaced. Riva FLV Encoder can "deinterlace" your video for you, and because the practice of interlacing video was meant to be used for television and makes no sense at all on the vast majority of computer displays, you probably want that. If you're not sure if you have interlaced video or not, it's probably a great deal easier to try encoding both ways and comparing the results than to go digging around for your lost hardware manuals.

Getting your video out there

OK — so you've got a handle on video formats, you can convert your video to FLV, and you've got a pretty good handle on what you need to do to keep your video files at a reasonable size. Now you need to look at how to get your video out there for people to see. When it comes to delivery of your video, you have a couple of options. You can try hard to keep your video files from being easily available for download or you can control what gets distributed by controlling what you make available to the world. Both choices have their positive and negative aspects. Just remember that you're not just putting a file up on a server for other people to download — it's a little more than that.

Delivery control and streaming

It is not necessary to view an FLV file via a stream. You could allow users to download the file and view it directly on their machines, but the video would be out of your control and loose in the world. You could add some control back in by delivering your FLV video by embedding the entire thing within in a Flash file. However, individually wrapping your videos in their own SWF files isn't scalable: You would have to manually build a new, separate Flash player every time you had a new video. This is comparable to buying a new DVD player every time you rent a movie.

That leaves us with two streaming options: RTMP and progressive download HTTP.

Real-Time Messaging Protocol (RTMP) is Macromedia's own streaming protocol. In order to be able to publish full-fledged RTMP streams, you must first install RTMP media server software. Then you will be able to stream not only your FLV video files but RTMP real-time "broadcast" streams as well through the media server. Because RTMP requires installation of server software, there is a lot more overhead involved in getting the first stream off the ground.

Progressive download in HTTP is a newer alternative for those who are either unable or unwilling to install a new service on their Web space. Many have found it convenient that the connections all take place over HTTP because it requires no additional protocols, and the server side of the code is fairly straightforward to tackle in, say, PHP. However, it is worthwhile to point out that if all your videos are being hosted over HTTP, there is not much to stop determined parties from deducing where you keep your source files and downloading them directly outside of the player. Also, as progressive download in HTTP is not technically a stream at all, you won't be able to host real-time broadcasts.

Both streaming options require the use of a video player object built in Flash, which you will either need to find or create yourself with a Flash authoring tool.


Macromedia developed the RTMP protocol for streaming and intends for those who wish to publish RTMP streams to do so with their media server software. Now, to publish with RTMP, we can use Red5 (see System requirements) — a Java-based, open source Flash server, which was reverse-engineered from Macromedia's media server.

Of course, using Red5 will necessitate installing the service somewhere and unblocking the relevant ports between your media server and the rest of the world. Using Red5 or any other RTMP media server won't be an option unless you have that kind of control.

Progressive Download HTTP

Fortunately for the majority of webmasters, there is an option which only requires a good install of PHP: Progressive Download HTTP. But it's not just those unable to use RTMP who choose to use it. Of the current video-sharing sites on the internet, the big players seem to prefer Progressive Download HTTP over RTMP streaming.

Rather than pay Macromedia for expensive media server licenses, or risk provoking a lawsuit by running a media powerhouse with a reverse-engineered proprietary protocol, they chose to author their own software and use HTTP for data transfers. HTTP will make it through firewalls without a fuss where RTMP may not. Perhaps most important of all: While they did give up the ability to publish live streams by moving away from RTMP, they gained greater flexibility with their presentation without causing themselves a huge bandwidth problem. Progressive HTTP allows for clients to skip to any of the key frames in a video before that location has made it to the client's buffer, without starting the download over again. This is only possible if it can be safely assumed that the stream is static in nature — an assumption that, because of its ability to present live streams as well as static ones, is not safe to make with RTMP protocol by design.

See Resources for OS-FL, an open source example of a progressive HTTP Flash player. Because it is PHP-driven, it isn't so much a matter of installing anything as much as it is dropping the source code somewhere you like, assuming you've got a good install of PHP. Also, it is extremely easy to embed the player on pages that also live on the same server. However, please note that if you view source with your browser on a loaded page with an embedded video (for example, their demonstration page), the entire FLV URL is dangling out in the open for all the world to see, should they care to look. Should you hit that URL directly in a browser, there is nothing stopping you saving direct copies of all their videos.

How does YouTube get around the direct download problem? First of all, they authored their own custom video player in Flash, which, among other things, adds a certain degree of mystery into the parameters it accepts.

Listing 1 is a snippet of code that would embed a YouTube video player in a page.

Listing 1. Code to embed a YouTube video player in a Web page
<object width="425" height="355">
    <param name="movie" value="
    <param name="wmode" value="transparent"></param>
    <embed src="" 
	    type="application/x-shockwave-flash" wmode="transparent" 
		width="425" height="355"></embed>

Notice the movie parameter (and the embed's source) is not a direct reference to a FLV file. By their design, we don't know what their Flash-based video player does to the URL passed in the parameter, but we can deduce that at the very least, it is a more sophisticated system than most webmasters will have the time, patience, or resources to set up. We see this by throwing the raw URL into a browser and not getting a .flv for our troubles. In fact, YouTube goes to a lot of trouble to make sure nothing but their video player ever touches their videos directly. Keeping that mystery intact could easily be a full-time job for more than one person.

In general, it is probably better in most cases to give up RTMP in favor of Progressive Download HTTP, unless there is no other way to tackle your particular problems. If you needed to publish live streams, you don't really have a choice: You have to go the RTMP route. If your ability to maintain relative control is the only thing steering you away from using progressive download HTTP, you should probably go ahead and get Macromedia Flash and write your own custom video player, injecting as much mystery as possible, and employing some clever server-side redirects.

While you should be aware that all of the techniques we have mentioned can be beaten if someone is determined enough, it is nearly always good practice to keep your more sensitive URLs somewhere where, at the very least, they won't get spidered and indexed directly.

Digital media philosophy

In the end, your content will probably get distributed or circulated in ways for which you were unprepared. That may be important to you, and it may not. The world of online media distribution is a constant battle between people who want to control their media and viewers who want to see media distributed without restriction. The byproduct of this battle is an ever-escalating arms race of media rippers and media-restriction protocols. You should make up your own mind in this area, but if you decide you want to control your media as much as possible, you should be prepared for the eventuality that no matter what you do, someone will still find a way to redistribute your media. This isn't to say that controlling your own media is never worth it — just that if you're looking for a way to keep anyone from ever ripping your media, you'll never find what you're looking for.

Building an application to manage it all

If you're going to do many videos, you will eventually find yourself wishing you had something that could help you manage your files better. There are so many video-sharing sites out there already that it seems a little silly to really try and create yet another one. Arguably, what you want isn't a better video-sharing site: It's something to help you manage your video files. We're going to build a really simple application for just this purpose. You won't do any coding just yet — that comes in Part 2. But you will need to install the framework we're going to use to build the application and set up some database tables.

Application overview

There isn't much sense in reinventing the wheel by building yet another video-sharing site like all of the others out there. Instead, this application will take a different approach to online video management:

  1. You will be uploading videos to your own domain.
  2. Emphasis will be on presenting your videos, not in creating a video-sharing community.
  3. Multiple users will be supported, but not self-registration (invite only).
  4. Tags will be the primary way of organizing and finding videos.

Tags are already fairly ubiquitous, but most sites that use tags still use categories for the main method of organization. As for the other points, the primary use of the application would be to host it on your own site, so you and your support staff can post your own videos, not to get lots of random people uploading video to your site. Think about these specific points in terms of database design, while you go over framework installation.

Installing the framework

In order to minimize the amount of application overhead code we need to write, we're going to use a PHP framework called CakePHP to do some of the heavy lifting. If you've never used a framework or CakePHP before, there's lots of reading material available out there that can help get you started. Between now and Part 2, you may find it useful to do a little bit of reading on the subject.

Visit and download the 1.2 beta version (see System requirements). The 1.2 version has loads of new features we'll want to use in our application. Installing CakePHP is reasonably straightforward as long as you have already met the prerequisites. In this tutorial, we used Apache V1.3 with mod_rewrite, PHP V5.2.3, and MySQL V5.

Download and unzip CakePHP, and configure your Web server to use CakePHP's webroot directory as document root. For example, if you unzipped CakePHP into the /cakephp directory, set your document root to the /cakephp/app/webroot directory. You will also need to make a change to the /cakephp/app/config/database.php.default file. Copy this file to /cakephp/app/config/database.php and enter the host, login, password, and database name for your system. Also, in /column/protected/cakephp/app/config/core.php, you should change the definition of CAKE_SESSION_STRING, so Cake won't complain about the default value. You can simply replace the default value with something like this: define('CAKE_SESSION_STRING', 'The important thing here is that no one is on fire.');.

Now that you've got Cake installed, you can jump into setting up your database tables. That means getting a clearer image of what the application will look like.

Setting up the tables

Let's take a look at what this application is going to do and identify what tables you'll need to get there.

You'll be uploading files to your own domain. This means you'll need a videos table to contain information about these specific files. Each file will need an ID field and at least a title. You could actually store the video files in the database, but that's not going to work out well in the end. Instead, you'd be better off storing the files on the file system and remembering the location. That means you'll also want a location field. To round things off, you can throw on a created field and a user_id field to keep track of which videos belong to whom.

Listing 2. Creating the videos table
CREATE TABLE 'videos' ( 
'title' VARCHAR( 255 ) NOT NULL , 
'location' VARCHAR( 255 ) NOT NULL , 
'user_id' INT( 10 ) NOT NULL , 

Multiple users will be supported, but not self-registration. This means you'll need a users table to store user information. At the very least, you will need username, password, e-mail, and first- and last-name fields.

Listing 3. Creating the users table
CREATE TABLE 'users' ( 
'username' VARCHAR( 40 ) NOT NULL , 
'password' VARCHAR( 40 ) NOT NULL , 
'email' VARCHAR( 255 ) NOT NULL , 
'firstname' VARCHAR( 40 ) NOT NULL , 
'lastname' VARCHAR( 40 ) NOT NULL 

Tags will be the primary way of organizing and finding video. This means you'll need a tags table to contain specific tags and a videos_tags table to join the two.

Listing 4. Creating the tags table
CREATE TABLE 'tags' ( 
'text' VARCHAR( 40 ) NOT NULL

CREATE TABLE `videos_tags` ( 
'video_id' INT( 10 ) NOT NULL, 
'tag_id' INT( 10 ) NOT NULL,
PRIMARY KEY ('video_id', 'tag_id')

Create these tables in your database. Your SQL may need to be updated depending on which database you will be using.

Looking ahead to the application

In Part 2, you are going to build an application to help you manage your video files. That doesn't sound too complicated, does it? Well, that depends entirely on what you want to get out of the application. Simple file management isn't really complicated, new, or interesting. If you want the application to be worth using, it needs to offer more.

Spend some time poking around your favorite digital video sites. Take notes about what you like and what you hate. Get a feel for how the different sites work. How are they the same? How are they different?

When it comes time to start working on the application, we know there are at least a few things we need. Beyond simple file management, we need a way to keep the files organized. This will allow you or a viewer to find files on given topics easily. Make a list of other features you think will be good to have. Some of those will be covered in this series, others you may need to work out yourself.

You should also spend some time getting familiar with the open source FLV player and PHP libraries. We make heavy use of them in Part 2. The player itself is simple to embed — you just use a line of PHP that looks like this: <?php flv("YOUR_VIDEO.flv", -1, -1, "0xFF0000", "0x000000"); ?>.

But you don't have to be a total PHP guru to recognize that the FLV function in that line is not standard PHP. The function is defined in the OS FLV libraries. Spend as much time getting familiar with it as you can. Part 2 will be a coding frenzy, and you'll be glad you spent the time reading ahead.


At this point you've laid out a lot of the pieces for your new video Web site. In Part 2, you'll build an application that will help you keep your video files organized, including file management and tagging. In the meanwhile, you should spend some time collecting (or shooting) some digital video and experimenting with format conversion to get familiar with the ins and outs of the compression trade-offs we mentioned earlier.



  • Get the CakePHP Manual.
  • is the central resource for PHP developers.
  • Check out the "Recommended PHP reading list."
  • Browse all the PHP content on developerWorks.
  • Expand your PHP skills by checking out IBM developerWorks' PHP project resources.
  • To listen to interesting interviews and discussions for software developers, check out developerWorks podcasts.
  • Using a database with PHP? Check out the Zend Core for IBM, a seamless, out-of-the-box, easy-to-install PHP development and production environment that supports IBM DB2 V9.
  • Stay current with developerWorks' Technical events and webcasts.
  • Check out upcoming conferences, trade shows, webcasts, and other Events around the world that are of interest to IBM open source developers.
  • Visit the developerWorks Open source zone for extensive how-to information, tools, and project updates to help you develop with open source technologies and use them with IBM's products.
  • Watch and learn about IBM and open source technologies and product functions with the no-cost developerWorks On demand demos.

Get products and technologies



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Open source on developerWorks

Zone=Open source
ArticleTitle=Setting up your own on-demand video site with PHP, Part 1: Groundwork