Art,
Thanks for the great information. Do you think the H.264 gamma bug would be present in footage shot with cameras using the AVCHD format like the new Panasonic HVC150?
Thanks again.
Posted by .(JavaScript must be enabled to view this email address) on 03/13 at 07:32 AM
No, the bug only seems to occur when you encode H.264 video for the web using Quicktime Pro, Compressor or FCP, and even then only under certain circumstances. I wouldn’t expect to see it at all anywhere else, especially not from a P2 camera or deck.
My understanding is that while AVC and H.264 are basically the same, the boosted gamma issue is due to how Apple implements it in their software. The bug is not inherent to H.264.
Posted by Art Adams on 03/13 at 11:28 AM
Hey Art,
I have heard that not all H.264 encoded media can be changed to Flash simply by modifying the extension, although I have had luck changing .m4v to .flv
By the way, most corporations, mine included, will only install the browser plugin for Flash, so no luck playing back local .flv files.
I tried and failed on this front in trying to create one H.264 file and by simply changing the extension get two playback formats.
Posted by .(JavaScript must be enabled to view this email address) on 03/13 at 04:36 PM
Hey Scott- you’re right about not every H.264 file working in Flash. X.264 files don’t seem to work, although Compressor-encoded H.264 files do seem to work.
Also, the extension for Flash H.264 is .f4v, not .flv. I’ve found that it works well enough, although I haven’t figure out a way to incorporate those new Flash files into my web site without making it overly complicated to navigate. It’s a pretty cool trick, though.
Posted by Art Adams on 03/13 at 04:39 PM
Are the gamma/color issues really solved?
Exactly how would you go about exporting a reference movie in the Animation codec?
Have you tried doing some tests on a simple color bar in FCP? Measure the 8-bit RGB color values using the DigitalColor Meter in OS X before and after transcoding to H.264.
Are the values the same when using the “reference movie trick”?
Compared to the original RGB values measured in the Canvas in FCP, they are only off by 1 when exporting to Animation using QuickTime Conversion. When transcoding that file to H.264 using FCP QT Conversion, Compressor, QuickTime Pro, x264Encoder, the values are way off - either too bright or too dark.
Changing the Color Space in the Filters tab in Compressor when transcoding to H.264 does not seem to do any difference.
The RGB values change too much when transcoding Animation to ProRes too. Sorenson 3 on the other hand is only off by 1 or 2. The RGB values are identical when transcoding from Animation to Photo JPEG.
I think there are some issues with either the Core Video hardware acceleration or ColorSync, or maybe even both. Why can not the colors just stay the same all the way through?
Posted by Thomas Berglund on 03/13 at 07:27 PM
(1) Well, the workarounds described seem to do the job.
(2) File>Export>Quicktime, uncheck the “save as self-contained movie” box.
(3) They appear to be the same, yes.
(4) Yes, that’s what the articles are about: H.264 encoding seems to be problematic. The latest theory that I’ve read, on the Professional list at CML (cinematography.net), is that Apple assumes that your gamma is set at 1.8 (because that’s what the Mac’s native gamma is supposed to be as a legacy from the printing industry) and helpfully adjusts movie display gamma for you. But almost none of us have our display gamma set to 1.8. Apparently that’s all changing in the next version of OS X.
(5) I’ve never found the color space tabs to do anything obvious.
(6) ProRes has the gamma shift problem as well. Sorenson 3… ewwww.
(7) Final Cut has problems displaying color accurately as well. Hopefully the next version of OS X will make everything 2.2 all the way through. We shall see…
Posted by Art Adams on 03/13 at 09:16 PM
Art and Scott,
Regarding Quicktime movie files encoded using H.264 codec or x264 codec: in both cases using Compressor for encoding, I am able to change the extension from .mov to .flv, and be able to have them played by a Flash player. I think what is important to recognize here is that the file structure is Flash compatible, and changing the extension is just “to tell” Flash to recognize the file as “it’s own” and not to discard it in the first place.
Regarding .flv extension, versus .f4v extension, reading at Adobe website at http://www.adobe.com/devnet/flv/, both extensions are valid, but .f4v is the newest implementation for the media file format.
Posted by .(JavaScript must be enabled to view this email address) on 03/13 at 10:05 PM
Unless your timeline and your source clips are animation codec (highly unlikely), exporting a reference movie will force a complete render so it doesn’t really matter if you export selfcontained or reference.
Posted by mgrenadier on 03/14 at 12:59 PM
Exactly. Unless there are any other differences between reference and self-contained QuickTime movies, I can not really understand how that can help.
Art, do you change the compressor in your sequence settings to Animation before exporting? Did you try measuring the RGB values, using the DigitalColor Meter application in OS X, before and after export?
I found this thread at Creative COW.
QuickTime, gamma, and After Effects: the definitive answers from Adobe Technical Support: http://forums.creativecow.net/readpost/2/922229
Those who have Final Cut Studio 2 installed, have this option available in QuickTime Player Preferences, but it does not really help:
“Enable Final Cut Studio color compatibility: When enabled, video is not displayed using ColorSync. Source colors are read with 2.2 gamma and are displayed in a color space with 1.8 gamma.”
I am so glad this issue finally is brought back for discussion. I filed a bug report (ID: 4321228) at bugreport.apple.com back in 2005, and the bug status is still set to “Open”.
The gamma issues have been discussed a lot already, but I am not sure we have found a real solution yet: http://www.google.com/search?q=quicktime gamma
Posted by Thomas Berglund on 03/14 at 03:25 PM
Two things.
First, do not use the deinterlace filter in Compressor - use the one in the frame controls; the filter has been depreciated (and this is indicated in the Compressor manual, page 246.)
Second - a question as something you mention doesn’t make sense -a QT reference, references the existing timeline - leaving the footage in it’s original format. How does one export it in ‘animation’ format (a different codec?)
Now, I’ll wager this: Codecs that shift the gamma are in YCr’Cb’ space and codecs in RGB space are not. No proof, but I’ll look into it.
Posted by filmgeek on 03/14 at 03:36 PM
You can change the “compressor” in your timeline settings (command-zero) to animation.
Posted by mgrenadier on 03/14 at 03:43 PM
mgrenadier - just tested this, and that does work.
I’m fairly sure that Animation is an RGB codec, which is why there’s no gamma shift.
Posted by filmgeek on 03/14 at 03:48 PM
Still, when transcoding that Animation file to H.264, there is a gamma shift. Just try exporting a Color Bar to Animation, and transcode it to H.264. Then compare the RGB color values with the DigitalColor Meter in OS X.
Posted by Thomas Berglund on 03/14 at 04:07 PM
I’m still a little confused. 
Art, you’ve inspired me to re-compress my reels, which is going to torture my computer for days.
I tried the Animation codec switch in Final Cut, sent that to Compressor, and Compressor grinds to a halt. It doesn’t like that at all. Granted, the Animation codec is 4x the size of the DV one, but even once it’s loaded to Compressor, it stops responding when I add a Destination. The normal DV 720x480 version loads and works fine.
So does the Animation codec through Compressor to X264 work? Will that get rid of the gamma tag and improve the de-interlacing? Sounds like it’s going to have to render these files 3 times to get where I want it—my poor laptop and I will be at this for a week!
Thanks for shedding some light on this.
-Graham
Posted by Graham Futerfas on 03/17 at 01:04 PM
Graham, this has been a problem in Compressor for a long time. For some reason the UI halts and becomes unresponsive when adding large Animation files. Closing the Preview window does not help.
Please send Apple some feedback about this problem: http://www.apple.com/feedback/compressor.html
As a possible workaround, I would recommend making some settings you would like to use and make droplets of them. Then drop your Animation files on your droplets.
Transcoding Animation files to x264 is no problem.
Posted by Thomas Berglund on 03/17 at 05:08 PM
FYI, Quicktime can be downloaded as a standalone app without i-tunes for the Windows world.
Posted by .(JavaScript must be enabled to view this email address) on 03/18 at 08:51 AM
Hi Graham-
What I’d do is run the Animation codec version through Quicktime Pro and X.264. That’s what I’ve been doing and it works like a charm. For the de-interlacing part I’ve been using a Graeme Nattress plugin in Final Cut, so that’s done before it ever gets compressed.
Can you save a Quicktime reference movie in the Animation codec (File>Export>Quicktime Movie, and then check “reference movie”) and then run that file through Compressor? I think that additional step worked for me.
It’s annoying to have to go through so many steps, but what I’ve done is use the saved standalone Animation codec files for use in Adobe Encore, which otherwise has gamma problems with ProRes files, and then compress X.264/H.264 from the Animation codec files. Two steps, very little waiting.
Posted by Art Adams on 03/18 at 06:51 PM
Okay, here’s a weird thing.
Some of the projects that I’m exporting from ProRes to Animation in order to re-encode for the web in X.264 are turning out very dark. I grade them in ProRes and then when they are saved off to Animation codec the brightness is down and the shadows are crushed. Photo-JPEG is consistently okay but isn’t nearly as nice with subtleties as Animation is.
Anyone have any thoughts about why this happens?
Posted by Art Adams on 03/24 at 09:38 PM
I use avid at work (animation studio) and use the h.264 codec all the time for quicktimes that get sent to clients for approval and notes via ftp. Now that I have found this thread, i dread using it. I may have to go back to using sorenson 3. I like how h.264 produce a smaller file size and better quality, but everything is washed out. And that is no good for our clients.
If anyone knows of a pc, windows, avid solution to this problem, it would be greatly appreciated.
Posted by portablemind2 on 04/01 at 04:23 PM
To solve the “washed-out Apple H.264 codec problem”, I use the x264 codec in DV Kitchen:
http://provideocoalition.com/index.php/atepper/dvkitchen_has_become_a_must_have_video_encoding_publishing_tool/
I just encoded some underwater video and x264 resulted in far nicer, richer colors (and a slightly smaller file size, and faster encoding).
SampleLab™ is a software environment that makes it easy to compare encoded samples- so you’re not encoding in the dark.
http://www.dvcreators.net/dv-kitchen/features/samplelab/
—-
For exporting from Final Cut Pro, I use this process:
http://www.dvcreators.net/how-do-i-export-a-high-quality-movie/
—-
Also, this movie has more info on H.264 playing in Flash players:
http://www.dvcreators.net/dv-kitchen-20/
Posted by Josh Mellicker from DVcreators.net on 04/29 at 01:17 PM
My initial though was, if those MOV are just as compatible, why renaming the extension? Cannot one just link to the MOV file?
Yet, if Flash plays MP4 just fine, what is the point of FLV (or F4V)?
H.264 encoded MP4 files can be losslessly produced from a MOV (almost) just as easy and fast: Open the MOV file on QuickTime, and go to menu File > Export > MPEG-4 movie> Format MP4; Vídeo format: passthrough; Audio format: passthrough.
With that you get, somewhat in an instant since it does not reencode anything, something that has far more widespread compatibility across hardware devices and software players. No need for player-dependent mov or flv files.
Or am I missing something?
Posted by elmimmo on 07/08 at 10:37 PM
On older machines H.264 in Flash players drop frames during playback.
Go to Hulu.com and watch a movie fullscreen. Hulu is H.264 .mov files playing in a Flash player.
Do they play skippy? How fast is your processor?
Posted by Josh Mellicker from DVcreators.net on 07/09 at 04:25 PM
@Josh Mellicker: I would check Hulu out, if I was on the US… (^_-*)/ From Japan all I get is a pristine black screen with a white message stating my location is not cool.
Isn’t it somewhat irrelevant to the point of the post how playable H.264 is, though? Wasn’t it about how to export H.264 with correct gamma, and how to feed Flash with it?
Posted by elmimmo on 07/09 at 04:35 PM
I was answering your question: “If Flash plays MP4 just fine, what is the point of FLV (or F4V)?”
Flash does not play MP4 fine on older machines.
Posted by Josh Mellicker from DVcreators.net on 07/09 at 04:54 PM
@Josh Mellicker: Ah, I see. Well, I wanted to say “If Flash plays MP4 just fine, what is the point of FLV (or F4V) *containing H.264*?
Posted by elmimmo on 07/09 at 05:48 PM
Ouch, hit enter too fast. Do you mean performance with MP4 and FLV or F4V containers differ even if the content is the same H.264 video data?
Posted by elmimmo on 07/09 at 05:50 PM
> “If Flash plays MP4 just fine, what is the point of FLV (or F4V) *containing H.264*?”
Ah, H.264 looks better usually.
> “Do you mean performance with MP4 and FLV or F4V containers differ even if the content is the same H.264 video data?”
Yes.
Posted by Josh Mellicker from DVcreators.net on 07/09 at 07:36 PM
