ProVideo Coalition.com: Stunning Good Looks by Art Adams

The X.264 codec is known to be a little buggy. I like to encode the videos on my web site as 720x405 Quicktimes, as this seems to be a nice size for both viewing and for keeping file sizes down. I came to the 720x405 size by starting with the standard def video spec 720x480 and dividing the width (720) by 1.78 (or 16/9). The result is 404.49, and for quite a while I’ve been happily plugging 720x405 into Compressor and getting excellent results.

These stills are from some regional spots I shot a couple of years ago for Kaiser Permanente:

This is how the original 720x480 video frame looked when exported from Final Cut Pro. NTSC uses non-square pixels, so when this video clip is shown on an NTSC monitor the pixels will be stretched horizontally to an aspect ratio of 1.21:1 to yield a 16:9 frame.

Computer displays utilize square pixels for better resolution, so in order to make a non-square pixel NTSC image look proper on a computer we have to do a bit of resizing. This image was squeezed vertically to yield a proper 16:9 image at 720x405, although it could easily have been stretched the other direction to yield 853x480.

Unfortunately my 720x405 settings caused the X.264 encoder to crash. It worked fine at 720x480, and I encoded a 4:3 file at 640x480 without difficulty, so what was the problem? There had to be something about the 720x405 aspect ratio that X.264 didn’t like. But what could that be? I pulled out my calculator and, once again, divided 16 by 9, and divided that into 720. The answer was still 404.49. But: I’d been rounding up to 405; what if I rounded down to 404?

It worked perfectly. It seems that the X.264 encoder only works on video that it considers to be precisely 16:9 or 4:3, and if your calculations give you a frame size in one dimension that can be rounded up or rounded down to the nearest pixel then one value will probably work while the other won’t.

The last step was de-interlacing my NTSC footage. Compressor did a bang-up job of that, but the unwanted gamma shift Compressor added ruled it out. I didn’t quite trust X.264’s de-interlace option, so I dug around in my collection of FCP filters until I came across G Smart De-Interlace, part of Graeme Nattress’s File Effects plugin package. It worked like a charm.

Here’s a frame from some standard def footage that shows clear interlaced artifacts (horizontal lines) around the gentleman’s outline, particularly around his shirt and on his forehead.. On a TV set this kind of motion artifact isn’t an issue, but it’s very clear on computer playback.

This is the same frame cleaned up using the G Smart Interlace plugin in Final Cut Pro. It does an excellent job.

Perhaps someday Apple will deign to fix this “feature” of Quicktime, but don’t hold your breath. Meanwhile, this workaround is a little bit of a pain but it does work—and Quicktime H264, as a showreel format, is well worth it.

I’m on to Adobe Encore now. Encore will allow me to lay out a showreel DVD and then also export it as a fully functional Flash file that emulates a physical DVD, menus and all. More on that when it happens.

The Editing of “Courageous” Part One

Steve Hullfish | 10/14

The off-line edit of a RED feature film

Last October, I had the rare opportunity to edit a feature film called “Courageous,” which is in theaters now. “Courageous” was the number one new movie the weekend it opened (September…

Final Cut Pro X Multicam Editing webinar now available on-demand

Scott Simmons | 05/15

Plus a little screencast in this blog post on a topic we didn’t get to cover.

I had great fun last week presenting the Final Cut Pro X multicam editing webinar…

10 Final Cut Pro things FCP editors might be missing in Adobe Premiere Pro CS6

Scott Simmons | 05/11

These are a few of the things that I found myself searching for as I’ve been moving over to Premiere Pro CS6 as a FCP 7 replacement

Adobe is making a big play for Final Cut Pro users with their CS6 release of Premiere Pro. It’s vastly improved over the Premiere Pro of old and is a lot like Final…

You must be registered to comment. This is an effort to reduce spam. Please REGISTER HERE.

Good stuff! This answers my question about why my H.264 looks fine after coloring, but then looks different in QT. I use Adobe regularly so I’ll check out X.264.

Posted by Jay Friesen on 03/12 at 09:31 AM

Encoders using X.264 can be strict about the height and with dimensions of files pushed through it. Many H.264 encoders require the height and width to be a multiple of 4 or 8, some are strict enough to require it be a multiple of 16 (Apple’s H.264 QuickTime encoder doesn’t have this restrict, but you may sometimes get stray green lines on the sides of your video if one of your dimensions isn’t a multiple of 4, 8, or 16).

This may be what was causing the crashing. X.264 encoders will take videos encoded in pretty much any aspect ratio, so long as the height and width dimensions are divisible by 16 (or 4 or 8, in the case of some of the less strict ones).

You may want to try 720x400 as dimensions for X.264-encoded 16:9 videos (you can either crop slightly to the exact 1.8 aspect ratio of those dimensions, or allow the video to be ever so slightly stretched in, depending upon your preference).

As for the deinterlacing issue, you were right not to trust the X.264 deinterlacing option. I use the MyCometG3 X.264 encoder, which is great except for the poor deinterlacing quality. If you export a Final Cut movie to a reference movie file, and use that in Compressor to export to a QT movie encoded in Animation or Photo-JPEG, is the gamma shift still there? If not, Compressor could still be used for the deinterlacing process, with X.264 encoding as the final step in the post process (i’ve used a workflow similar to this in the past, and I don’t recall any gamma shift issues, although I didn’t test my results in any Windows browsers as the final video was for local use rather than the web.)

Hope this helps!

Posted by Brandon Cordy on 03/12 at 11:23 AM

Okay, now THAT actually works. I exported a Quicktime Reference movie in the Animation codec and fed that into Compressor. The gamma held! I’m totally gobsmacked. Here I thought Compressor was the problem but apparently the issue starts farther up the food chain.

I think I’m going to have to add on to this article…

Posted by Art Adams on 03/12 at 12:35 PM

Regarding making Flash video file using H.264 codec, using Compressor is pretty simple. Just use the same settings than you use to make your Quicktime H.264 (or x264 by the way) movie and then modify the three letter extension of your movie from .mov to .flv. Et voilà ! Note: H.264 flash file can only be played from Flash player version 9 update 3 and above.

HTH,

David

Posted by .(JavaScript must be enabled to view this email address) on 03/12 at 12:39 PM

Constructing or adding a player is not nearly as difficult as it used to be with Adobe CS3 or CS4 because you can export a Flash package complete with player, HTML and XML code, from Encore after or as if you author your DVD.

Posted by DanConklin on 03/13 at 07:49 AM

Sorry, that was some bad writing on my part. That last post should read “...as it used to be. With Adobe CS3 or CS4 you can…”

Posted by DanConklin on 03/13 at 01:30 PM

Has there been any updates on how FCP7 handles gamma? I’m tearing my hair out at the moment because I do not know if what i am seeing is the true gamma of my picture or not!

I graded an XDCAM EX 35Mb/s timeline in Color. I viewed the footage using an MXO. So far so good. The grade looked really nice. So I exported from Color in Prores HQ and took that timeline back into FCP6.

Now, I needed to do some work with Motion on one of the graded clips, so I opened that clip up on Motion and went to work. I noticed that for some reason this clip, unlike all the others had been flagged as being interlaced. So I went to the media properties in Motion and changed it to the correct setting of Progressive scan.

So far so good. But then I noticed another option in the properties for my clip in Motion. Gamma. It was set to 1.8. But when I output from Motion via the MXO the picture looked the same as it did when I graded it in Color.

Now the obvious thing to think is that the MXO is correctly showing the clip as 2.2 gamma. But the clip also looked very similar in the main Motion editing window as it did on the MXO output.

So, is a 2.2 correction being applied to the Motion editing window as FCP does in the Canvas and viewer windows while the actual Prores file is still in that infernal 1.8 gamma?

Pretty much what I want to know for my own reaassurance is whether the output from Color to the MXO is 2.2 gamma? After all I don’t want to grade in Color only to find that it is outputting in 1.8 gamma and then find out that when a file is output in a codec that natively uses the correct gamma that everything ends up looking far too dark!

Really I’m confused by this whole issue, as you can probably tell!

Posted by Simon Wyndham on 12/06 at 04:55 AM

Hi Simon-

I don’t know what’s going on at the moment. I got so frustrated that I took the time and energy to switch my web site over to Flash.

I’d heard that Quicktime Player X displays proper gamma while the Quicktime browser plugin doesn’t, but last week I saw an example with a spot that I was color grading where the gamma on the client’s review copy, exported in H.264 via Compressor, looked better in Safari than it did in Quicktime Player X. I honestly don’t know what the heck is going on.

I’ll see if I can take a look in the near future. I’m working on a couple of behind-the-scenes articles now, and I have a big job coming up, but I’ll try to delve into this and see if I can figure out what’s going on.

So far X.264 still seems to be the best option for encoding H.264 gamma-correct web video.

Posted by Art Adams on 12/06 at 12:37 PM

That’s interesting about your client example. It would be interesting to find out what’s going on there.

Looks like for the most part we need both the Mac Quicktime browser plugins and the PC Quicktime software and plugins to display at 2.2 and we’ll be set.

However it seems clear from when I used Prores in Motion that the default gamma for that codec is 1.8. When I set it to 2.2 everything went a lot darker. Too dark in fact. So what does appear to be happening is that the Prores codec is stored at 1.8 gamma, but the Motion canvas window and MXO output are actually compensating and displaying at 2.2.

Utterly absurd for a codec that is supposed to be for video!

I might try a test actually, and import an FCP Prores sequence into Motion, but change all the clip gamma properties to 2.2 gamma and export from there and then go into H264 from Compressor to see what happens. With all these hard drives I really can’t be doing with outputting timelines in the Animation codec. It would actually be quicker to do this extra step to Motion assuming it works.

Posted by Simon Wyndham on 12/06 at 03:50 PM

Incidentally I am trying X264 via Handbrake. But for some reason Handbrake doesn’t like Prores footage.

Posted by Simon Wyndham on 12/06 at 03:51 PM

Name:

Email:

Location:

URL:

Smileys

Remember my personal information

Notify me of follow-up comments?

Submit the word you see below:

The Quicktime Conundrum