h.264 solution…

Last week I posted how we were in the midst of searching for a way to adequately encode almost 2000 files using the h.264 codec into some sort of wrapper. The problem was deciding what type of wrapper to use. Should we use .mp4, .mov, or .m4a?

The problem centered around how long it took Sorenson Squeeze (our transcoding software) to create a mp4 from our full quality mov. What I failed to consider was how much unnecessary work Squeeze was doing. For instance, we exported from Final Cut Pro a DV25 720×480 interlaced timeline. Squeeze had to resize the file down to our output resolution of 640×480, deinterlace the footage because we were delivering via web (and you don’t put interlaced material on a progressive display like a LCD or Plasma), and then create a new mp4 file. So Squeeze took anywhere from 4-6 hours just to do 1 file. That just isn’t going to work. I’ve seen mud move faster. Hence our dilemma.

We looked at Compressor as a solution, but it didn’t offer a mp4 file using the h.264 codec. If we want h.264 it either meant wrapping it as a m4v or as a mov. The solution: stick with Squeeze but take some work off the programs shoulders, force FCP to do much of the grunt work upfront. So when we batch export from FCP our sequences were manipulated from FCP into our target resolution (640×480) and deinterlaced. Encoding a file that Squeeze no longer has to resize and deinterlace took the transcoding time down to 1-2 hours. Much better. Still not light speed, but not as slow as molasses either.

What we learned: sometimes its easier to let FCP do the grunt work, like resizing or deinterlacing, and then let a secondary software, like Squeeze, do what it’s made to do, namely, transcode.