Setting Up Your Own Ondemand Video Site With PHP Part 1

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
Skill Level: Intermediate
Duane O'Brien (d@duaneobrien.com)

PHP developer
Freelance
Katie Horn (K4@engineering.phenomenauts.com)

Developer
Freelance
Will Robot (willrobot@gmail.com)

PHP Developer
Freelance Writer
01 Apr 2008
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" tutorial series will take you
through what you need to know to create video optimized for the Web, as well as
creating a PHP application that will keep your videos organized and readily
accessible. Part 1 lays the groundwork by assembling and installing the necessary
components and gathering and converting the video.
Section 1. Before you start
Groundwork
© Copyright IBM Corporation 1994, 2008. All rights reserved. Page 1 of 18
developerWorks® ibm.com/developerWorks
This series is 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.
Groundwork
Page 2 of 18 © Copyright IBM Corporation 1994, 2008. All rights reserved.
ibm.com/developerWorks developerWorks®
• 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.
• Download 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 both 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.)
Section 2. 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
Groundwork
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.
Groundwork
• 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
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
Groundwork
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.
Compression
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 .tar.bz 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
Groundwork
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
One of the first things you should notice is that Riva FLV Encoder comes with
Groundwork
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
Groundwork
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.
Section 3. 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
Groundwork
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.
RTMP
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.
Groundwork
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="http://www.youtube.com
/v/3g-yrjh58ms&rel=1"></param>
<param name="wmode" value="transparent"></param>
<embed src="http://www.youtube.com/v/3g-yrjh58ms&rel=1"
type="application/x-shockwave-flash" wmode="transparent"
width="425" height="355"></embed>
</object>
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.
Groundwork
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.
Section 4. 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.
Groundwork
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 CakePHP.org 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
Groundwork
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' (

'id' INT( 10 ) NOT NULL AUTO_INCREMENT PRIMARY KEY ,
'title' VARCHAR( 255 ) NOT NULL ,
'location' VARCHAR( 255 ) NOT NULL ,
'user_id' INT( 10 ) NOT NULL ,
'created' DATETIME DEFAULT NULL
) ENGINE = MYISAM ;
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
) ENGINE = MYISAM ;
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
) ENGINE = MYISAM ;
CREATE TABLE `videos_tags` (
'video_id' INT( 10 ) NOT NULL,
'tag_id' INT( 10 ) NOT NULL,
PRIMARY KEY ('video_id', 'tag_id')
) ENGINE = MYISAM ;
Create these tables in your database. Your SQL may need to be updated depending
on which database you will be using.
Groundwork
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.
Section 5. Summary
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.
Groundwork
Resources
Learn
• Get the CakePHP Manual.
• Read the five-part series "Cook up Web sites fast with CakePHP."
• Wikipedia explains Flash video encoders, which convert ordinary video to Flash
Video (FLV) format.
• PHP.net 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
• Download PHP V5.1.4 or later from PHP.net. Not all the frameworks being
examined require this release level of PHP, but for the sake of ease, all
frameworks will use the same PHP installation. This series was written using
PHP V5.2.3.
• This series and the sample application were written using MySQL V5.0.37,
which is available from MySQL.com.
• Download the latest version of FFmpeg, a command-line, open source
video-conversion utility.
Groundwork
• Download a trial version of Riva FLV Encoder V2.0 for Windows, a

video-conversion utility for Windows produced by Rothenberger Global Training
Solutions.
• Download Red5, a Java-based open source Flash server.
• Download JW FLV Media Player, a small, embeddable Flash media player.
• Download OS FLV, an open source example of a progressive HTTP Flash
player. See this demonstration video.
• Download Apache V1.3 with mod_rewrite enabled from the Apache HTTP
Server Project.
• Download CakePHP from CakePHP.org.
• Download video content from Internet Archive.
• Innovate your next open source development project with IBM trial software,
available for download or on DVD.
• Download IBM product evaluation versions, and get your hands on application
development tools and middleware products from DB2®, Lotus®, Rational®,
Tivoli®, and WebSphere®.
Discuss
• Participate in developerWorks blogs and get involved in the developerWorks
community.
• Participate in the developerWorks PHP Forum: Developing PHP applications
with IBM Information Management products (DB2, IDS).
About the authors

Duane O'Brien
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.
Katie Horn
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."
Groundwork
Will Robot
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.
Groundwork

Setting Up Your Own Ondemand Video Site With PHP Part 1

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Setting Up Your Own Ondemand Video Site With PHP Part 1

Загружено:

Авторское право:

Доступные форматы

Setting up your own on-demand video site with

PHP, Part 1: Groundwork

Skill Level: Intermediate

Duane O'Brien (d@duaneobrien.com)

Katie Horn (K4@engineering.phenomenauts.com)

Will Robot (willrobot@gmail.com)

Section 1. Before you start

About this series

About this tutorial

• Some digital video content — It can be video you've found, shot, or

• A Microsoft® Windows® XP box — The examples provided use some

• An HTTP server that supports sessions (and preferably mod_rewrite).

Section 2. The ins and outs of digital video

Jumping in with both feet

• MP4 is a compact file format with above-average sound. This format is

Size vs. quality

Frame size is your next consideration. As mentioned, your video is a series of

Figure 1. The Riva FLV encoder

video-encoding presets, presumably based on expected bandwidth available for

A few more notes on encoding

Section 3. Getting your video out there

Delivery control and streaming

Real-Time Messaging Protocol (RTMP) is Macromedia's own streaming protocol. In

Progressive Download HTTP

Listing 1. Code to embed a YouTube video player in a Web page

<object width="425" height="355">

In general, it is probably better in most cases to give up RTMP in favor of

Digital media philosophy

Section 4. Building an application to manage it all

1. You will be uploading videos to your own domain.

2. Emphasis will be on presenting your videos, not in creating a

3. Multiple users will be supported, but not self-registration (invite only).

4. Tags will be the primary way of organizing and finding videos.

Installing the framework

Setting up the tables

Listing 2. Creating the videos table

CREATE TABLE 'videos' (

Listing 3. Creating the users table

CREATE TABLE 'users' (

Listing 4. Creating the tags table

CREATE TABLE 'tags' (

Looking ahead to the application

• Download a trial version of Riva FLV Encoder V2.0 for Windows, a

About the authors

Вам также может понравиться