[Sao_Bento]

By Chris Meyer
http://provideocoali...time_movies/P0/

Covers some fixes and debunks some of the existing theories on how to fix it.

[a2visual]

Good link, too bad it employs a third party codec to fix it though. The gamma stripper seems useful, but running it every time through Terminal may become cumbersome with real deadlines, etc. It seems like ProRes has this same problem too, which is unfortunate.

[thomwill]

does the standard h.264 codec read the x264 version?

[thomwill]

just tried it. the export fails every time right from the beginning.

[Sao_Bento]

thomwill, on Dec 3 2008, 01:15 PM, said:

just tried it. the export fails every time right from the beginning.

Oh well, I thought it might have been worth a shot.

[a2visual]

Sao_Bento, on Dec 3 2008, 05:45 PM, said:

Oh well, I thought it might have been worth a shot.

It was definitely a good read. I never knew it didn't effect Windows machines.

[thomwill]

Sao_Bento, on Dec 3 2008, 02:45 PM, said:

Oh well, I thought it might have been worth a shot.

definitely worth trying. it might just be my machine. i'll be interested to know if anyone else tries it what kind of results they get.

[ChrisC]

a2visual, on Dec 3 2008, 07:44 PM, said:

Good link, too bad it employs a third party codec to fix it though.

The x264 codec is only needed for encoding, they resultant movies can be played back through the normal decompressor in Quicktime. I've had a couple of encodes failed but it's extremely rare, I've been using this method for a few months now and it's definitely easier than the trick with the transparency method.

[skimmas]

Using x.264 really appears to be an elegant solution. Hurray for open source
Right now I think I would chose x.264 for either avi, mov or mkv. Could this be the end of the codec war?

anyway the article seems to have some incorrections:

«QuickTime movies re-exported from applications such has QuickTime Player Pro using the H.264 codec (a common format for web content) appear brighter than the original in some contexts [...] but not in other contexts such as QuickTime Player on Windows, or the stripped-down QT Player inside After Effects.»
1. At least the videos encoded on windows machines will show the gamma shift on quicktime player for windows.

2 GammaStripper from FuelVFX - it as been reported not to work. Never worked for me (I'm on Windows).

[thomwill]

ChrisC, on Dec 3 2008, 03:27 PM, said:

The x264 codec is only needed for encoding, they resultant movies can be played back through the normal decompressor in Quicktime. I've had a couple of encodes failed but it's extremely rare, I've been using this method for a few months now and it's definitely easier than the trick with the transparency method.

well that answers my initial question, which is awesome. still doesn't explain why i can't get it to work at all. i'm running 10.4.11 with QT 7.5.5.

This post has been edited by thomwill: 04 December 2008 - 03:59 PM

[mixtracks]

This has been a huge pain for me for a while. Reading this thread motivated me to look up a x264 encoder for quicktime pro mac.

It seems like from the searching I did this is the best one.

http://www003.upp.so...e.jp/mycometg3/

Read here also;

http://discussions.a...ssageID=8551140

Just tried it, and I can confirm that it works better than the standard h264 one in quicktime, it also has a bit smaller file size.

[RustyAce]

question, will this problem be solved with snow leopard? since it will be using the same gamma default as windows?

[JMRicks]

RustyAce, on Dec 4 2008, 12:04 PM, said:

question, will this problem be solved with snow leopard? since it will be using the same gamma default as windows?

I really hope so.

And thanks for that link mixtracks.

[thomwill]

finally got it working. had an error in my aspect ration. very cool stuff.

[Albo]

You can also use Visual Hub (discontinued but still around) to make a new MP4 file with passthrough on both audio and video.

By using the "Force: FFmpegDecoding" when creating the new file, the correct gamma will be displayed.

[pixelpusher]

Just to confirm guys, is the gamma of the x264 supposed to match the gamma of your AE comp window?

Because when I export a lossless animation QT .mov, it looks darker than my comp when I open it up in QT. If I open that animation QT and export a h264 and an x264 from it, this happens:

a ) The h264 is lighter than the animation QT original, and the x264 is lighter again than that.
b ) Of the 3 QT movs, the x264 matches the comp window pretty much perfectly (gamma wise).

Is this how things are supposed to work? I imagined the first animation QT would match the comp window, then the x264 would maintain that (where the h264 doesn't).

Or have I got a different problem with my color managment pipeline?

This post has been edited by pixelpusher: 05 December 2008 - 06:19 AM

[hyp3]

I still haven't figured out a proper way to get rid of the gamma shift on the 2 platforms. Shame how Apple is not even looking into this (Maybe Snow Leopard will get rid of that problem so all QT clips can look good on both platforms).

[RustyAce]

Snow leopard is supposed to be the same gamma as windows, there was a thread about it here a while ago

[monovich]

So wait, this is or isn't a problem on Windows? I'm getting conflicting reports.

[hyp3]

It looks brighter under Windows than it does under OS X (Looks like what it should look like under OSX). Even Trailers from the Apple site look a bit bright under Windows.