Quicktime Player h.264 Bug
I have an issue here that I’ve been trying to solve for almost a year now. (Any comments can be left on this blog post.)
I’ve been trying to figure out for almost a year now why videos I compress with certain codecs (namely h.264) are playing back in QT with pale unsaturated colors (looks like brightened gamma) while the same videos look correct in the finder preview/FCP/firefox/or the 3rd party “nice player” (when I disable core video in its prefs.)
Take for example this screenshot.
The bottom window is quicktime player playing back one of my h.264 clips, while the top window is the same clip opened up in “nice player” with “use core video” turned off in the prefs. Btw… all videos are compressed with Compressor. I could also open that clip in Final Cut Pro or Firefox and it would look correct (like the top window.)
Here are one and two other examples of other people’s h.264 clips that I have downloaded.
I’m fairly sure that Core Image/Video is the culprit here for several reasons
1) The problem didn’t start until Core Video arrived.
2) The video looks correct in applications that don’t leverage Core Video, or applications such as “Nice Player” which allows you to disable the use of Core Video in its prefs. (http://sprynthesis.com/qt_issue/niceprefs.jpg)
3) The same h.264 clips look fine on every computer I go to that has a video card which doesn’t support Core Video, such as my mac mini (which means there is actually no problem with the compressed clips themselves.)
But I want the clips to look ok on MY computer in regular quicktime, and on my friends computers that have G5’s with graphics cards that support core video.
I also have seen the problem on PC’s as well. The same clip encoded in Sorenson 3 looks great, but the h.264 encoded one looks pale. However, disabling DirectDraw Acceleration and relaunching the clip sometimes makes the clip play normal, but not always.
Originally I thought Apple’s HD trailers didn’t have this problem, on further study they definitely do. They seem to know how to keep the effect of the problem as low as possible though.
So I’m going to venture a guess that the brightness “problem” is going to be showing up with these video cards:
ATI Mobility Radeon 9700
ATI Radeon 9550, 9650, 9600, 9600 XT, 9800 XT, X800 XT, 9850 XT
nVidia GeForce FX Go 5200
nVidia GeForce FX 5200 Ultra
nVidia GeForce 6800 Ultra DDL, 6800 GT DDL
as well as the intel graphics chip in the new mac minis.
Because these are the cards that support Core Video.
Here is a link to a zip file of my short example clip. In this zip file I have the same clip compressed 3 different ways. 1) H.264 2) Sorenson 3 3) Regular Mpeg 4.
The black levels should look about the same on all videos, but the h.264 is much lighter on my screen (see the screenshot of my clip above.)
My workflow
Just in case it matters, I figured I should document my workflow for compressing videos. I’m rendering tiff files out of Maya, putting them together in After Effects 7, and rendering that out to a quicktime movie with lossless animation codec. Then I’m bringing it into compressor and making quicktime movies with h.264 multi-pass.
Is it some sort of color flow issue that I’m missing?
Any help would be greatly appreciated. This bug has been around on Apple’s forums since May with no solution posted.
Lastly here are the specs of my machine
Dual 2.7 G5
ATI Radeon XT 9850
3.5 GB RAM
Dual 23 and 20 Cinema Displays (Aluminum)
Mac OS X 10.4.5
—————
New Research, Big Update
Below is a copy of an e-mail I sent to the quicktime users mailing list, we’ll see what it turns up.
———————-
Hello all,
I’ve been searching high and low to find the solution to this problem, and baffled at how few people seem to be talking about it.
As far as I can tell, any computer which supports Core Video is displaying many of apple’s codecs with incorrect color, including the famous h.264 codec. The problem also appears to extend to some PC’s (I believe Direct Draw Acceleration utilizes the video card to play back quicktime files on some machines.)
You can read about my initial assessment and examples of the problem. http://sprynthesis.com/blog/?page_id=51
In this e-mail I’ll link to further testing I performed over the past 24 hours that clearly identifies my problem.
To follow along with my e-mail, you can download the sample files. http://sprynthesis.com/qtplayer_issue.zip
First here is my workflow.
I am working in Maya (3D app for those who didn’t know) and generating tiff sequences. Those tiff sequences are then put together in a compositing app like Shake or After Effects (I have tested both thoroughly.) I then render those tiff sequences out into a self contained quicktime movie using the (totally lossy) animation codec. No problems through this point. Then I compress the file (either straight through quicktime or using the Compressor application) into an h.264 file. This file then plays back with incorrect colors on my machine, and any other machine that supports core video, but looks fine on those that don’t. The colors aren’t totally wacky, but they are faded and shifted slightly.
This has been brought up in apple forums, and on macintouch and macfixit.
http://discussions.apple.com/thread.jspa?threadID=210793&start=0&tstart=0
http://www.macintouch.com/readerreports/quicktime7/topic2894.html
http://www.macfixit.com/article.php?story=20060331083618226&query=h.264
————
So after reading my web page about this and downloading the sample files, you can test this for yourself here by breaking out the DigitalColor Meter application from your utilities folder (set the pop-up menu to “RGB As Actual Value 8-bit).
1. Inside my folder of sample files, open the first movie called “1.single_tiff.mov”. This is simply one of the tiff files saved as a self contained movie in quicktime.
Mousing over the squares (http://www.sprynthesis.com/qt_issue/likethis.jpg) will give you your base values which all the other files SHOULD match somewhat closely. Use this as a reference file to compare all the other quicktime files to.
The bottom row should be various levels of greys, the next row up should only contain blue values, and so on with the red and green rows. The rows above that are various combinations of RGB values just for further testing.
————
2. Now move on to the “2.ae_animation.mov” file. This is the tiff sequence compressed out of after effects using the animation codec. The values of these squares should be identical to that of the first file, and they are.
————
3. Now look at the “3.h.264.mov” file. The results you will get for the RGB values of these squares will depend on whether or not your computer supports core video. If it doesn’t support core video (like the PowerPC mac mini) then your RGB values will be extremely close to that of the source file. (Hooray! The problem doesn’t affect you.)
If your computer does support Core Video, then you will see that all the black levels - except for the pure black and white (its a gamma curve problem?) - are brighter than they should be. When you mouse over the squares that should be solid RGB values, you see anywhere from trace amounts to extreme levels of other colors showing up. This is quite a problem! What’s worse? Calibrate your monitor instead to a gamma of 2.2 (like most pc users and a lot of pro mac users do) and the color shift is much worse.
Now is the fun part. Open that same h.264 file with Firefox, or download an application like the “Nice Player” (and disable core video in the Nice Player prefs.) The color problems dissappear and the file looks like its supposed to (like those without core video, the rgb values don’t match exactly, but at most they are off by a hair… very acceptable)!! Well crap… what’s a guy to do? Use Sorenson 3?
————
4. Open the “4.mpeg-4.mp4″ file. The RGB values should look pretty good in quicktime no matter what computer you view them on. Although when viewed in Nice Player or Firefox the RGB values actually seem a little low on the color squares. (Maybe this is because no ICC profile is embedded in mp4 files?)
———–
So you should be able to see my problem pretty clearly as long as your computer supports core video. My question is what is the solution? Whoever encodes the Apple HD trailers seems to know. Those videos look great on computers with and without core video.
Anyway, that’s my 2ยข. I am determined to understand what’s going on with my color conversions. Anyone who has any ideas for a solution, drop me a line! I really want to be able to trustfully use h.264 instead of falling back to Sorenson 3.
Thanks,
Robert Spryn
——————–