In this video, you’ll learn about the array_diff_assoc PHP function. This function calculates the difference between an original (“primary”) array and any number of comparison arrays.

It returns an array containing an values from the original array that do NOT exist in any of the comparison arrays.

The big difference between this PHP function and other “array_diff” functions is it takes the keys of each array into account, as well. Meaning, that BOTH the key and value of any element must match for that element to be calculated.

Here’s how to use it:

You can learn more about this function in the PHP Manual.

In this video, you’ll learn about the array_count_values PHP function. This function lets you count how many times a certain value occurs in an array.

It returns an array where the values of the original array are now the keys and the occurrence of each key in the original array are the values.

Here’s how to use it:

You can learn more about this function in the PHP Manual.

In this video, we’ll cover the array_combine PHP function. This function lets you specify an array of keys and an array of values and combine the two into a single array.

The resulting array contains the values specified in the keys arrays as keys and the values specified in the values array as values.

Here’s how to use it:

You can learn more about this function in the PHP Manual.

In this video, you’ll learn how to use the array_chunk PHP function. This handy function lets you break an array into smaller chunks of a size you specify.

The resulting array is a multi-dimensional array containing your chunked arrays.

Here’s how to use it:

You can also read more about this function in the PHP Manual.

In this video, you’ll learn about the array_change_key case PHP function. This function lets you change the case off all the keys in an array to either upper or lower case.

Here’s what it is and how to use it:

You can also learn more about this function in the PHP Manual.

Being a fully self-taught PHP developer, I’ve spent a LOT of time searching for and perusing online tutorials.

Some are awesome. Others… not so much. So, I figured I’d take a moment to help you separate the wheat from the chaffe.

Here’s my top 5 PHP tutorials in no particular order:

1. Tizag.com PHP Tutorial

I spent a lot of time with this little gem. For me, the best part about this tutorial is it covers the important stuff. A lot of tutorials spend way too much time covering things that don’t really matter… at least in the beginning. Tizag.com’s tutorial covers the essentials like working with MySQL, includes, arrays, file manipulation, and more. A great collection of essential PHP skills.

2. W3Schools.com PHP Tutorial

This one is really similar to the Tizag.com tutorial in that it covers the essentials. That said, it’s good to hear it explained a different way and it covers some topics and shares some tips you won’t find in the Tizag.com tutorial. You get similar essentials to the Tizag.com tutorial like working with MySQL, arrays, includes, etc… but you get a few extras like ODBC and using PHP in conjunction with XML and AJAX.

3. Learn PHP

Self-aggrandizing? Blatant self-promotion? Probably, but I really do believe this is one of the better tutorials out there. It is, of course, a tutorial by yours truly but what makes it unique is that 1) it’s a VIDEO tutorial, which are hard to find and 2) it covers in-depth what I call the “Essential Loop”… the first major skill I believe a PHP coder must learn. And, like the others, it’s free.

4. PHP For the Absolute Beginner

Again, similar content to the first two, but what make this one unique is the playful style in which it’s written. Vikram Vaswani, the author, isn’t afraid to take a stab at injection a little humor into this tutorial. Of course, sometimes the humor hits just right… and sometimes it falls flat, but you gotta respect the valiant effort.

5. WebMonkey PHP for Beginners

Another beginner tutorial that’s even more focused on the first steps of learning PHP. I like this tutorial, because it is so focused on the critical first steps: learning PHP syntax, working with variables and functions, operators and a few others. If you’re brand new to PHP, this is a good place to start and keep from getting overwhelmed.

All in all, these PHP tutorials are a great place to start. Be sure to check them out. Also, what other tutorials have you taken that you found useful? Feel free to share with the community!

This is one of those little tricks in PHP that can save you a ton of time. Reality is, when you’re dealing with MySQL results… you’ll almost always have to loop through an array of results to grab what you want and put THOSE results back into an array.

If you don’t know how to do it, it can be really frustrating. For me, when I figured this out it was one of those “sword falling from the sky” moments.

So, if you don’t know how to do it, here it is:

$my_array = array('aaa', 'bbb', 'ccc', 'aaa', 'bbb', 'ccc');

foreach ( $my_array as $k => $v ) {

if ( $v == 'ccc' ) {

$result[] = $v;

}

}

print_r($result);

The result of this code is: Array ( [0] => ccc [1] => ccc )

Pretty simple. The key part is this:

$result[]

The brackets as the end of the variable set that variable as an array and results will then be looped into that array. This comes in very handy.

Enjoy! Let me know if you have any questions.

As you’ve probably seen from the front page of my blog, I have just released a new report called The Coder’s Credo. I won’t over hype it, but it’s something I’ve put a lot of thinking into to distill my experience as a Web Developer down into useful tips for what it takes to actually be successful.

It’s short, concise, and hopefully impactful. Once you’ve read it, feel free to leave your comments here.

This is a question I get quite a bit, so I figured I’d write a post on it:

How do I create an HTML select box with options from data in my database?

Here’s how:

The Query

First, let’s look at our query. Yours might look something like this:

<?php
     $sql = "SELECT * FROM queried_table";
     $query = mysql_query($sql);
     while ( $results[] = mysql_fetch_object ( $query ) );
     array_pop ( $results );
?>

That will select everything in our table and loop it into an array of objects containing the results. Now, we can take that array and create a HTML select box with it.

The HTML Select Box

Now, that we have our array of objects from our database we can use it to populate an HTML select box dynamically with PHP. Here’s how that might look:

<select name="the_name">
     <?php foreach ( $results as $option ) : ?>
          <option value="<?php echo $option->desired_value; ?>"><?php echo $option->desired_label; ?></option>
     <?php endforeach; ?>
</select>

That’s it. The code above will loop through the array creating a new option for each element in the array… and populating each option with the desired values from your database. Of course, this is just sample code, you’ll need to work with your database structure and code to make it work for you… but, that should give you the framework for getting this kind of thing done.

Here’s a video walk-through of this, as well:

Welcome to the Wild West. When it comes to web video, that’s exactly what it feels like. Web video is confusing, hard, and “tear-your-hair-out” frustrating… if you don’t know what you’re doing. On the flip side, if you DO know what you’re doing, it’s pretty straight-forward… well, kind of.

At the very least, by the end of this article, you’ll have a good idea of where things stand, and what you need to do to get your video online… support the devices and browsers you want to support… and, do it without re-encoding your videos 100 different times (like I did).

So, let’s get started…

Codecs

Let’s start with codecs, because really the web video starts and ends with codecs… and, that’ll make sense in a minute. The word “codec” itself is a portmanteau… that is, a blend of two or more words into one word (kind of like “Bennifer” when Ben Affleck and Jennifer Lopez we’re dating… ya know!). In this case, the “two words” are “coder” and “decoder”, because that’s ultimately what a codec does. So, let’s talk about that:

Encoding

Encoding is the “coder” part of a codec and where this all begins, so let’s start there. So, there’s a couple things to get here:

1. Computers talk in 1s and 0s. Everything you see on a computer is ultimately broken down into a string of 1s and 0s. It’s hard to believe, because computers can do so much these days, however, ultimately, everything you see is a series of 1s and 0s… to the computer. We typically refer to this as “digital”… i.e. computers operate in a digital format.

2. The world is NOT comprised of 1s and 0s. Obvious, but the world… the one we record with our video cameras… does NOT break down to a series of 1s and 0s. So, by default, the world we want to record with a video camera and the computer we want to watch the video are NOT compatible, so we need…

3. Something has to turn A into B. Something has to take the lightwaves and things that exist in the real world and “translate” them into code (1s and 0s) that a computer can understand.

That’s what encoding is… it is taking the analog signals that exist in the world (lightwaves, sounds, etc.) and “coding” them into a digital format that a computer can understand.

Now, let’s try and make this a little more clear.

You remember, back in the day, the first types of camcorders we had. Those were considered “analog” camcorders, because they didn’t “digitize” (i.e. turn into code) video. Instead, those camcorders took a bunch of pictures and stored them on a “tape”. Very similar to taking a picture with real film… except camcorders did a bunch of them in succession really fast… 30 “frames” or pictures per second.

Then, computers came along and we developed ways to “digitize” our video. We could install a program on our computer, plug in our camera, and “encode” our video. At that time, the installed program (Windows Media Encoder, Pinnacle, Sony Vegas) handled the “encoding” part.

Today, however, we have digital camcorders which have hardware already in them that will encode the recorded video on the fly. So, now when we record with a digital camcorder, the video we get is already encoded in a computer-friendly format and we can simply plugin the camera and transfer the file to our computer.

BUT…

The encoding STILL has to happen. Very important to remember.

Now, if you’re like me when I started learning about all this, you probably have two questions at this point:

1. How do video encoders ACTUALLY encode video?

When I first learned about encoding and that all video had to be turned into code, it made complete sense (one of those DUH! moments), but I’m kind of a tech-head, so my first question was how?

So, here’s a general run-down of how it works. Keep in mind, the process is more detailed than this, but this will help you get your head around how it’s actually possible.

We already know that cameras and camcorders (even non-digital ones) have the ability to recognize color and put that onto some sort of medium. We won’t cover that really. But, what happens in a digital camcorder that’s different from an analog one?

A digital camcorder is still essentially “taking real fast pictures” and storing information about those pictures. Digital camcorders generally record at 30-60 frames (pictures) per second. What’s stored is the color information about each frame.

So, we know we have different “resolutions” for video. A video can be 1920×1080, 1280×720, 640×360, and pretty much anything in between. But, what does that resolution actually mean?

It represents the number of pixels in the recording or playback area. So, for example, a 1920×1080 video is 1920 pixels wide by 1080 pixels high. And, (this is key, so really pay attention here) each one of those pixels is a certain color. Think of a video as kind of a mosaic. Each pixel has it’s own unique color and those colors in combination form a picture.

So, what an encoder does is get the color information about the current frame of video and stores what color each and every pixel is for that particular frame… 30-60 times per second. And, of course, as something moves in the video… that color information changes… thus, the camcorder picks up and records the movement.

Pretty slick, if you ask me.

So, encoding is essentially about recording color information about the pixels in the frame of a video. At least, that’s the first step. That’s why videos recorded at 1920×1080 resolution are much bigger than ones recorded at 1280×720 resolution… there’s a LOT more pixels to store color information for.

But, that leads to our second question…

2. How does an encoder know what to encode the video to?

Now, that we know an encoder (whether it’s built-into your fancy HD camcorder or it’s a computer program for an analog camcorder) is simply recording and storing color information, you might wonder, like I did, is there some sort of language or standard for doing this kind of thing? Do all videos get encoded the same way?

And, this is where the codec wars begin…

Because, the answer is no… well, kind of. There is no ONE standard… there’s a series of standards.  And, these are the things you’ve probably heard of before… H.264, Theora, VP8, and so on. These are codecs. So, what exactly is a codec again?

A codec is a standard for HOW digital video will 1) be encoded and 2) be decoded. So, really smart people get together and think about how they can store that color information in a way that 1) maintains higher quality video, 2) compresses the video to smaller and smaller file sizes, and 3) use less CPU resources to do all of that.

Here’s something fun for you to try…

1. Find a video on your computer
2. Open it with a text editor (NotePad works great!) instead of a video player
3. Wait for your computer to screech to a halt.

What I’m getting at is video files are HUGE! Storing all the information takes up a lot of space. With my digital camcorder, I can record at full HD for 15-20 minutes and have  a raw file size in the gigabytes range. Try opening a 2GB text file on your computer and see what happens.

In comparison, all 1075 pages of War and Peace fit into a 2.4 MB PDF. I know, because I downloaded it just to see. And, I can open it in a couple seconds… no problem.

Actually, your computer will probably open it fine, but it will take awhile AND you’ll notice a few things:

1. You CAN actually open the file in a text editor! Why? Because it’s code! That’s so hard for people to get, but a digital video file is code… just like a HTML web page, or PHP, or javascript… it’s code! It has to be really… otherwise, your computer wouldn’t be able to process it.
2. Again, it’s HUGE. It’ll probably take you minutes (several of them) to even scroll through the whole thing.

So, video files are code… and the codec is what defines how that “encoding” process is done.

A couple points on encoding and how it’s done:

1. FPS. One factor in file size and quality is Frames Per Second. Obviously, the more FPS, the larger the file size, because there’s more information to store. Some camcorders allow you to adjust that, but more often than not, you’ll adjust it in your video editing program (Sony Vegas, Adobe Premiere, etc).

2. Key Frames. What exactly are key frames? One way we compress video to make file sizes smaller is by NOT recording ALL the color information of every particular frame. Instead, we use what are called key frames. Key frames are frames that DO record all the color information about that particular frame (every rotten pixel)… and we space key frames out, say every 5 frames. Then, we track the “changes” in color information in subsequent frames until the next key frame.

So, the first frame of a video is always a key frame. It grabs all the color information about that frame and stores it. For frames 2, 3, 4, and 5, we only track how the color information changed and store that (i.e less to store). Then, frame 6 we again grab all the color information for that frame and repeat the process.

This gives us much less information to have to store while, at the same time, ensuring our video doesn’t get too “wonky” or off track… by re-keying it every so many frames.

Again, obviously, the more key frames you have, the bigger the file.

So, that’s pretty much encoding. You take a bunch of really fast pictures, store the color information about each picture, and save it in a huge text file… kind of. We’ll talk more about that when we get to “containers”, but that’s a good way to look at it for now.

But, what about decoding? It’s a co-DEC… which implies decoding. What about that?

Ok.

Decoding

Do everything you just did in reverse. Ok, that’s decoding.

But, seriously, that’s kind of how it works. A decoder simply takes all the code in that huge text file and turns it back to into actual colored pixels on your computer screen.

How?

I don’t know. That’s what video players do. They decode the video and “play it back” using the stored color information. Exactly HOW they do that, I really don’t know, but you do need to keep a couple things in mind:

1. Compatibility. Codecs are why a flash player can’t play a .wmv file. The .wmv file was encoded using a Windows Media codec, but a flash player only understands flash-compatible codecs (H.264, VP6, Sorenson Spark, etc). So, the flash player doesn’t speak the same “language” as the video.

So, if you’re going to build a web site that uses a flash player, you’ll need to encode your video using a flash-compatible codec. Oh, and if you want it to be viewable on mobile devices, you’ll need to make sure it’s compatible with those, as well. Oh yeah, and also, don’t forget about HTML5… you’ll probably want video compatible for that, too.

Oh, but wait, since HTML5 is native to the browser, it depends what codecs that browser supports. Luckily, they all support the same codecs… oh wait, they don’t. They’re fighting right now and if you want to use HTML5 video, you’ll probably have to encode your video into 2 maybe 3 different file formats and upload them all.

Yeah, it’s kind of a mess right now in terms of what will play on what. Hopefully soon, we’ll have a universally-compatible, open codec that we can rely on to play in every digital device known to man.

(Container formats also play a part in that, but we’ll get to that.)

2. Stacking. Most “players” support what’s called a “stack”… that’s a combination of video codec, audio codec, and a container. For example, Adobe Flash supports video encoded using H.264 video, AAC audio, in an MP4 container. Each part of that matters!

If you encode your video using H.264 video, AC3 audio, in an MP4 container… that’s different! And, might not play in one or another browser or device (actually, my copy of Sony Vegas doesn’t even let me encode to AC3 audio when using the MP4 container, but you get my point).

There are common “stacks” that you can encode to in order to ensure your videos will play in what they’re supposed to. H.264 video, AAC audio, in an MP4 container is one of them. Of course, there’s also different “profiles” for each codec, as well. H.264 has 17 different profiles, the most common of which are the main, baseline, and high profiles.

Adobe Flash supports all profiles of H.264; however, the iPhone and Android phones only support the “baseline” profile. If you record a video in H.264 high profile… it won’t play in an iPhone.

Again, the “stack” you use is critical. You have to choices when it comes to supporting all the different browsers and devices:

1. Cater to the lowest common denominator. This will typically be your mobile devices. You can create a video that has the right “specs” for say an iPhone 3GS, which are:

H.264 video, up to 1.5 Mbps, 640 by 480 pixels, 30 frames per second, Low-Complexity version of the H.264 Baseline Profile with AAC-LC audio up to 160 Kbps, 48kHz, stereo audio in .m4v, .mp4, and .mov file formats

That video will then play in Adobe’s Flash Player and browsers that support H.264 natively with HTML5. However, the video is 640×480, so it’s not HD and won’t look the best when played full screen on an HD monitor.

So, it’s a trade-off.

2. Use detection to serve the right video to the right device. There are both PHP and Javascript techniques you can use to detect what browser and/or device is accessing your site and you can serve up the correct video based on that.

So, you could create a version of your video for Apple and Android devices and encode it according to their specs. Then, create a version for browsers supporting H.264, and yet another version for browsers supportng WebM. You would, then, have all major browsers and devices supported.

Of course, you have to encode and upload 3 different versions of every video you make AND detection isn’t foolproof… so, again, it’s a trade-off.

(There is a way you can encode ONE video file and have it play in all major browsers and devices… but, I’ll save that for another article.)

So, as you can see, how a video is decoded depends heavily on how it’s encoded.

Oh, but it gets better, because we haven’t even talked about “containers”, yet.

Containers

If you’re like I was, you’re probably asking yourself right about now, “What the hell is a container?”. When I first heard about containers it didn’t make any sense to me what it even was. So, let me break it down:

When you watch a video online, you have your video playing on your screen and typically you have audio that accompanies it. Now, looking at it, you probably assume that the two (audio and video) are together… but, that’s not the case.

The video file and the audio file are just that… two SEPARATE files. When you encode a video that has audio, you’re actually doing three things:

1. Encoding the video
2. Encoding the audio
3. Wrapping it in a container to hold BOTH files

Think of the container like a .zip file. Inside it is a bunch of files, but the .zip itself is one file. That’s kind of how a container works. It takes the audio and video file and stores them together in one file… along with information about the files and how to play them.

But, unlike a .zip file, you can’t just throw any audio and video files into any container. Certain containers only support certain types of audio and video files… that is, codecs.

This goes back to the section on stacking.

The MP4 container supports H.264 video and AAC audio among others; the Ogg container supports Theora video and Vorbis audio; the WebM container supports VP8 video and Vorbis audio, and so on.

The container determines what audio and video codecs you can use… or, most likely, the other way around (what codecs you want to use will determine what container you can use).

The problem with this is most people use containers and codecs interchangeably and that’s not entirely accurate. And, in fact, it’s worse because most people use containers, codecs, and file extensions interchangeably… and, that is definitely not accurate.

So, let’s talk about that… where do file extensions fit in?

File Extensions

File extensions are the 3-4 character endings to the names of our video files, e.g. .mp4, .wmv, .webm, and so on. In fact, file extensions are what most people talk about when referring to what “type” of video they’re dealing with.

Ironically, file extensions are probably the least determinant factor of the three (codec, container, and extension) when it comes to determining what type of video you have.

What does that even mean?

This: the type of video you have is mostly determined by what codec you encode it with. The container deals more with how all the files necessary for the video to play are “packaged” together. And, the file extension is 1) determined by what container is used and 2) typically interchangeable among the container’s supported file extensions.

For example, you can record a H.264 video using the MP4 container, BUT give a file extension of .mp4, .m4a, .m4v, and more In fact, the “MP4″ container supports 6 file extensions:

1. .mp4
2. .m4a
3. .m4p
4. .m4b
5. .m4r
6. .m4v

Any file with one of these extensions can be called an “MP4 video”… MP4 as in the container not the file extension. Even more, you can typically change the file extension of a video to another supported extension and the video still play.

For example, I’ve recorded videos using the .mp4 extension, then later changed the extension to .m4v… and, the video still played fine in Window Media Player and Adobe Flash.

Now, that’s not entirely universal or smart, so don’t go changing your file extensions willy-nilly, but it’s possible… and, more importantly, illustrates how little the file extension has to do with what “type” of video you have.

But, we’re all hung up on file extensions, because that’s what we see. We don’t see all the behind the scenes stuff with codecs and containers. So, it’s understandable. Just remember… the file extension is the least of your worries. Pay more attention to the container and codec you’re using… the file extension will be an natural “extension” (wow, that’s bad) of the choices you make there.

So, that’s web video. Clear as mud? Honestly, web video is a bit screwy right now, but hopefully this article will help you start making sense of it… and, hopefully, when you’re in Sony Vegas, or whatever video editing software you use, all the drop-downs and check-boxes will make a little more sense… and, you’ll be better equipped to encode your videos correctly to support the browsers, devices, and standards you want to support.

Miscellaneous Topics About Web Video

Here’s some miscellaneous discussions I felt were important when it comes to web video. These didn’t really fit into the main article, so I’m putting them here. I’ll add to them over time.

What’s the Big Deal With H.264 and Patents, Anyway?

At first, it might not seem like a big deal. Yeah, H.264 is patented… but, so what? MPEG LA, the licensors of the H.264 patent pool, laxed its restrictions on H.264 and essentially made it free to end-users. So, what’s the big deal?

It’s debatable, but the web has seen this before. Ever seen or used a GIF image? Until 2004, the main technique for encoding and decoding GIF images (yes, they’re encoded, too!) was patented. Initially, the patent was not enforced and GIFs became the de facto standard for images on the web.

Then, the company who developed the algorithm that was used to encode and decode GIF images decided to enforce the patents… hypothetically, having the right to charge any web site owner who displayed a GIF image on their web site.

Now imagine the same scenario today with video. Imagine YouTube suddenly being charged on a per-view basis for all of its videos… or, YOU being charged for all your videos on a per-view basis.

That’s the worry and that’s why Google is working on developing an open, royalty-free codec that anyone can use without ever having to pay a royalty… forever… guaranteed.

Obviously, Google has a vested interested, because of YouTube… and, nothing says MPEG LA ever would or “could” fully enforce its patent if it decided to change its mind; however, it’s possible. So, if you’re concerned about being able to create, upload, and share video online without ever having to worry about paying a royalty, it’s kind of a big deal.

(As a side note: MPEG LA looks to be blocking the adoption of WebM by creating doubt about the VP8 codec and whether or not it’s truly unencumbered by patents and royalty-free. Interestingly, Microsoft and Apple are both apart of MPEG LA’s H.264 patent pool (meaning, if royalties are charged for using H.264… they get paid!) and, none of Apple’s products support WebM… and IE9 will play WebM, but only if the user has the VP8 codec already installed… meaning, it doesn’t “natively” support it like Firefox, Opera, and Chrome.)

Conquering Web Video InfoGraphic

Here’s a little infographic I put together for web video. Hopefully, it’s useful for you:

Retention is the name of the game when it comes to membership sites. It’s a well-known fact that members COME to a membership site for the content, but they STAY for the community. Your members will stay because their friends stay.

But, how do you get your members to become friends with one another? A big key is to get your members to start interacting in the first place. And, a great way to encourage that interaction is to give your members a little reward for doing so.

In this video, we’ll talk about how to use two free WordPress plugins (CubePoints and SimplePress) to reward your members for interacting on your site, increase the activity and friendship-building that occurs, and ultimately boost your membership site’s retention rates.