You might have read my post about my FLV meta data and cue point reader/writer. You might also know that the F4V format (which really is simple MP4+H264+AAC) succeeded to the FLV format, and is supported by Flash 9.0.115 and up.

The MP4Info class is a simple extensible PHP class reading the MP4 container’s frames (called boxes) to get various information, namely the video duration, the video/audio codecs, the width and the height, as well as the embedded XMP meta data.

The F4V format is better than the FLV format in many aspects:

• Better compression ratio
• Better quality at similar bit rates
• Open source compressors available, through ffmpeg and libh264 (Flash 8 On2 VP6 codec is proprietary)
• Decoding H.264 is a lot less CPU intensive on the host computer than decoding On2 VP6

Categories and sub categories. Directories and sub directories. Building a tree of nodes that have parents is a common problem these days.

There are two solutions to this problem, but unfortunately, the inefficient one is often used by programmers, due to the lack of time, or to inexperience.

More …

The HTTP protocol is quite simple. But many of us under-use it, programmatically speaking. There are many very simple performance mechanisms that are often forgotten. Many developers go for disabling HTTP caching completely, as they often don’t understand how to use it, and because it can cause weird bugs when used incorrectly.

But so much things are cacheable: pages, images, CSS, JavaScript, even many REST web services! Yes, even in this social web era where content changes faster than you can write, there’s still plenty of slow changing information, such as home pages, or lists of countries, regions and cities.

Efficiently using caching translates into:

• Better response and loading time
• Decreased load on the server
• Better user experience

This article aims to present a simple explanation of the HTTP protocol and proper use of HTTP caching.

More …

If you played with the pretty cool Amazon Web Services, you probably started off fetching a sample off the Developer’s Connection pages. At least, I did.

One cool sample for Simple Queue Service is the one by Justin@AWS. But (you saw it coming, I suppose), being anti-PEAR (for many reason, such as dependencies, weight, version conflicts, non-catchiness of the name, fructose intolerance, etc.), I just couldn’t leave the sample like that. Yes, this is me again reinventing the wheel.

The original library depended on two PEAR components:

• Crypt_HMAC, for authentication
• HTTP_Request, for HTTP calls

More …

Update (Dec 20, 2008): The AMF0Parser library has been updated to better handle broken AMF0 packets. The FLVInfo2 library PHPDoc has been updated.

Update (Aug 15, 2008): The AMF0Parser library has been updated to support the Date type in the metas, added among others by the “inlet media FLVTool2″ tool.

Update (Jun 11, 2009): The project has been moved to Google Code. MP4Info, an F4V file (or more genericaly MP4 file) class is also available: check out blog post and project at Google Code.

If you’ve done Flash banners or micro-sites that embed video with cue points for synchronization before, you know that it’s a pain in the arse. There doesn’t seem to be any tool around to modify the damn points once the file is encoded, so you’ve got to re-encode the file over and over to have your things synced correctly.

If you’ve tried to reverse engineer the FLV format before, you know that it’s a pain in the arse as well. The AMF0 format is anything but intuitive, and the documentation has been lacking for a long long time — although there’s apparently an SDK now. Luckily, there was OSFlash, and SabreAMF and AMFPHP that could be used as a documentation source.

If you recognize yourself, this might be your lucky day. After many hours of trial and error, I’ve finally been able to reverse engineer it, and to build a library that extract essential FLV information, reads the Meta, and allows you to write them back — including the cue points.

More …

I got no IPod. I got no IPhone. But I’ve got an OpenID. I’m like a low class geek. But whatever. I’ve read a bit lately about OpenID and wanted to give it a try on one of my personal projects (CodeIgniter based, you bet).

I’ve stumbled upon Rémi Prévost — who’s blog a follow more or less consistently due to the lack of time — CIOpenID module. It’s basically a CI embed of Janrain’s PHP_OpenID.

His code is great and works well. But one thing I don’t like about it is that it requires a different bootstrap file (a modified version of index.php) and a somewhat hacked version of your typical .htaccess file. The reason is, CodeIgniter annihilates the $_GET variable during initialization, because GET queries aren’t secure (ok, this is overly simplified, but you get the idea).

Being who I am, and somewhat liking to reinvent the wheel during my free time, I used a different approach. Rather than using a different bootstrap file, I rather chose to use the pre_system hook.

More …

What better, on a saturday morning, than to write (or read will you say) about a PHP framework with a nice cup of java – the warm caffeinated beverage that is.

Saturday morning thought: the Java developers I know are like Jehova witnesses: they divert any programming conversation to “Java is the future, wake up from your slumber”. Java’s been the future for 10 years, yet it failed to make it into the present. But lets take another sip of coffee and digress no more…

While I personally (this is a personal blog after all) like Zend Framework for its lightness, speed and cleanliness, I rarely consider it for rapid development: I dislike the MVC, and tend to use Zend more like I use PEAR libraries. The documentation could be better too.

My love goes to CodeIgniter, a PHP framework developed by the guys at Ellislab. Setting up a CodeIgniter environment is easy as 1-2-3: Unzip (or untar if you’re a real geek), configure database, and take a sip of coffee (did I tell you I liked coffee?).

To the contrary of Zend, the documentation is a wonder: tutorial oriented while not cluttered by stating the obvious. The only thing that I could use sometimes is an API-style documentation, which is inexistent and leaves me off looking at their code.

The essential libraries are there, ready to be loaded and used: configuration, database, benchmarking, crypto, input, input validation, output, language, unit testing, and much more. Plus there’s a few very good contribs out there on their wiki and elsewhere on the web.

Enough propaganda, let’s be honest, CodeIgniter is not perfect:

• Configuration and language files are PHP declared arrays, which makes them kind of hard to maintain sometimes. Plus I’m worried (although I did no benchmark yet) about the cost of multiple file inclusion.
• The model object provides a lot of flexibility (actually, you do it the way you want), but flexibility is a double bladed knife. A real, functional yet flexible out of the box active record class would make rapid development rapider.
• The cookie-based session class sucks: All your data go in cookies + Cookies are size limited = Problems. But there’s proven and true replacements in the contribs.
• There is no “real world” caching class out of the box. Sure, there’s a caching class that caches, URL based, your output, and it works well if a URL always look the same no matter who visits it. But in that Web 2.0 world full of logins and “Hello Tommy”, it’s not the case. Yet, you can extend the output class by adding caching hooks.
• The framework is still fully PHP4 compatible, which tend to make its Object Oriented code ugly. Let’s hope they’ll drop that sooner than later.

Yet, CodeIgniter stays my first choice. There’s more pros than cons, and we built a lot of libraries over time that ease the downsides.