Get Connected!
Get updates via RSS
Get updates via Email
Connect to DigitalDoyle via twitter

Patience & Persistance Pays Off – episode 1

by DigitalDoyle

I’ve been doing a lot of work for clients lately with h.264 video encoding, including searching for the optimal encoding settings for various sizes of videos intended for deployment on the web and for each of the social networking sites like YouTube, FaceBook, MySpace, etc.

Before your eyes glaze completely over, H.264 is simply a type of video file suitable for playback on the web. It’s also the same file type that BlueRay DVD and most satellite and cable companies use to deliver HD to your widescreen. The quality of this kind of video can be much higher and the filesize much lower than ever before, and the results can be amazing.

As I was testing the videos locally, on my own hosted web server, I noticed that something that should’ve been a no-brainer simply wasn’t working. Whenever I would upload a test to the site and try viewing it in a browser, the video would most often come up completely white and the player would appear to buffer forever. The audio might or might not play, or might stutter. And when an image finally did come up, it was corrupted along the bottom of the video and stayed still. No video. Not good.

This should be the simplest of processes.  You encode your video with Adobe Media Encoder, link that video to an FLVPlayback component in a Flash document, choose your video controller options, and publish both the swf that links to the (usually mp4, f4v, or flv) video, and the html file to host it. Upload the three files to the web server and viola! You’re done.

It should’ve worked just like that. But it didn’t.

The videos would play back perfectly, if I launched them from my hard drive in a browser, but would fail when uploaded to the website.  I couldn’t deliver the files to my client if I wasn’t sure everything was perfect, so I started taking the problem apart piece by piece to try to pinpoint the exact cause of the problem.

At first I suspected that my videos were being corrupted during the ftp up to the server. But I noticed that older video files in the OnVP6 format would still play perfectly. So then I suspected the h.264 encoding. Maybe I had the wrong profile or level or data rate specified. But no, all that was on target and well within spec.

Then I thought that maybe there was a problem with the latest version of the FlashPlayer plugin, v10.0.0.0. So I googled the problem looking for significant numbers of hits with people complaining about the same or similar problem. No joy.

Whenever I find no hits for a problem I’m having, it’s a pretty good indicator that the problem lies closer to home. Often it’s staring back at me in the mirror in the form of Operator Headspace Error.

But not this time.

Since it wasn’t a widespread problem, that meant it had to be with my files, or so I thought. I double and triple checked my files, rebuilt them from scratch, built them in both Flash CS3 and CS4, built and controlled them with components and pure code, but the results were always the same. It wasn’t an Adobe problem and it wasn’t something I was causing directly. I was running out of options.

If it wasn’t my files, that only left the ftp corruption idea, (which does happen rarely), or else something wasn’t right on my webserver.

I wondered if maybe the MIME types for f4v and mp4 video files hadn’t been set up yet on the server. The file types have been out for a while now and my hosting company, Esosoft, is usually right on top of all the latest stuff, so I doubted that was the problem. But I had to ask,  just to eliminate the possibility.

I’ve used Esosoft as my web hosting company since 1996 and they are outstanding, especially their service. This time was no different. I received a reply to my email asking about the MIME types in less than two minutes. They asked for links to the problem files so they could track the problem down. I love great and responsive customer service!

About an hour later I got a reply telling me that they weren’t having any problem viewing the files in multiple browsers and on multiple operating systems and couldn’t get them to fail. That was actually very good news, though, as it meant the files were most likely ok to ship to the client and the rest of the world would have no problem seeing them.

But they also said they turned off compression for those file types (f4v and mp4), because sometimes that caused problems, and they asked me to try to get the videos to play again.

As soon as I tried them again, every one of  the files all played perfectly. The compression turned out to be the problem. I was able to ship the files with confidence, knowing they were good to go.

It was another really weird and obscure problem that was very hard to track down and solve. For some reason I seem to run into those kinds of problems all the time. Thankfully I have a gift for solving complex detailed problems, (though most of the time I would prefer things just work like they should!).

A process that should’ve taken no more than a half hour, tops, wound up taking me nearly 6 hours to track down. But I learned a lot during the process.

Moral to this story is that the key to solving off the wall problems, or any kind of problem really, is to break the problem down into smaller pieces, being patient and most importantly persistent, eliminating possible causes one by one till you find the root cause.

I hope this helps someone that might’ve run into a similar problem.


So what can we do for you?

{ 0 comments… add one now }

Leave a Comment

Previous post:

Next post: