








(11)
Your rating: Now say why...
Important Note: MyCometG3 (the developer) has been shut down. Every product which has GPL/LGPL license term are freely available under GPL/LGPL, so you are free to fork your own source tree. Every product which does not have GPL/LGPL license term are freely available under 3-clause-BSD.





(12)


| Downloads:96,326 |
| Version Downloads:2,045 |
| Type:Multimedia & Design : Video |
| License:Free |
| Date:30 Dec 2011 |
| Platform:Intel |
| Price:Free |
Overall (Version 1.x):![]() ![]() ![]() ![]() ![]() |
Features:![]() ![]() ![]() ![]() ![]() |
Ease of Use:![]() ![]() ![]() ![]() ![]() |
Value:![]() ![]() ![]() ![]() ![]() |
Stability:![]() ![]() ![]() ![]() ![]() |
+7
+2
+19
Thanks for the continued updates.
I am getting some great quality from FCPX using this directly with Compressor.
Using a quality encoder like MainConcept used to require a re-encode but I am now getting as good results with x264 and not needing the extra step.
+2
If you specified target data rate, some key frame may show broken image, with Apple H.264 Software Decoder. You can check such stream using QuickTime X player.
If you have found decoding problem with output from x264Encoder please try to :
- change Behavior tag - qmin from 0 to 3 or grater value
inside libavcodec settings dialog.
It would make such stream decodable. (Re-encoding is required though)
//
Such erratic stream should be decodable with Perian 1.2.2.
But current implementation of QuickTime X/QuickTime 7's H.264 software decoder seems to have incompatibility problem (under Snow leopard).
+1
+1
Version 1223 fixe the decoding problem for me.
Thank a lot for your good job.
+2
+63
Desterwallaboo reviewed on 03 Feb 2011
libx264's Weightp change is introduced on:
git.videolan.org/gitweb.cgi?p=x264.git;a=commitdiff;h=e440dc0f7909c67cdca148fc8a9ea413521e0e5b
and implemented under x264Encoder 1.2.19.
+111
More Info:
http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Levels
and
http://www.mplayerhq.hu/DOCS/HTML/en/menc-feat-quicktime-7.html
and
http://forum.doom9.org/showthread.php?t=102609
and
http://mewiki.project357.com/wiki/X264_Settings
:-)
All limitation in such link is too old.
At least QuickTime 7.6.x support has got advanced features, and if GPU support is available such limitation can vary.
QuickTime 7.6 is released over two years ago, and it provides support for 10.4, 10.5, 10.6. I guess this covers most of active users in the world.
You said "7.x.x" but do you think pre-7.6 is really required to support?
+2
+111
+1
Would you give me which parameter is required?
+3
+49
Best Regards
+3
+10
+3
+3
Symbiotic_ic reviewed on 21 May 2010
Highly recommended.
-1
+49
Mac Adam reviewed on 13 May 2010
thanks for the speed upgrade :)
Does the xvid project dead ?
because it could be a speed alternative,
but it look slower ?
best regards
+1
I recommend you to use x264 for every devices.
-1
+41
+1
+111
Source:
[1] http://en.wikipedia.org/wiki/MPEG-4_Part_14#History_of_MP4
+2
Instead, Try MPEG Streamclip 1.9.2. It can produce mp4 file directly, using x264Encoder.
If you have made some mov file, you can re-encapsulate into mp4 using QuickTime Player 7's mp4 exporter (No transcode; set video track as is, set audio track as is).
-1
+41
+4
+55
+2
If I open imovie, choose Export with Quicktime and then click settings, the whole system either freezes or imovie crashes. If on the other hand I encode a movie with h264 first and afterwards change the encoder to x264, I can access the settings, make the changes I want and export the movie. Then I can use the x264 codec without any problems as long as I don't try to open up settings - if I do I have to go through the whole process again.
I don't have any skills whatsoever with programming so I don't really have any suggestions to what might be wrong, other than that it seems to have something to do with the settings window. Might be some incompatibility with other programs I have installed. Anybody else have experienced the same?
+3
- /Users/xxxx/Library/Logs/DiagnosticReports/app_yyyy-mm-dd-xxxxxx_macname.crash
My E-mail address is written at bottom of README.rtf.
+3
+2
-1
+3
My question: What exactly does the "Gamma 2.2" checkbox do?
Background: I have .MTS Panasonic TM700 footage converted to ProRes, editing in Final Cut. The video looks good until I export using "Quicktime Conversion." Using x264 I set nclc=111 (HD) and my output file looks too dark in QuickTime X, QuickTime 7, Movist, VLC. Also if I convert after to a .mkv container (Mkvtoolnix) it's still dark. (meaning it's not just a container error) Setting nclc=111 AND checking the gamma2.2 checkbox fixes the problem.
My problem: I'm scared by checking gamma2.2 I'm actually making a mistake by artificially forcing lighter footage and there's an error somewhere else in my flow. (like user StarHawk79 had) ProRes has native 2.2 gamma, so I don't understand why FCP exports darker footage. I'm on Snow Leopard (10.6.3) / Intel so OS gamma is now 2.2, FCP v7.0.2. I notice if I export to another codec (say Prores Proxy) it's also darker, and I can't fix it. I'm not sure where the problem is.
Thanks in advance!
-1
2. Gamma checkbox is extra parameter, so only nclc is recommended though.
Gamma 2.2 checkbox is intended for data source (non-common yuv color space) which does not have correct color info like nclc. Such professional processing software should NOT use this checkbox.
Under correct quicktime environment, or application which implements nclc correctly; when nclc parameter is specified, gamma 2.2 setting should be ignored (because it is legacy for QT6.5 param).
Under some application/work flow, which does not handle correct nclc settings somewhere, gamma 2.2 spec "may" make better result than nclc only; but it is not correct.
-1
+3
You confirmed what I was thinking: I shouldn't have to use the gamma 2.2 checkbox with Pro apps. I think I found the problem: it's Final Cut Pro. If I use MPEG Streamclip or Compressor to convert ProRes to x264 then the video looks good just by setting nclc=111. If I use FCP "Export Quicktime Conversion" then the video is dark unless I also check "gamma 2.2." I'm guessing it's a FCP bug.
So my solution is always to Send FCP video to Compressor for conversion with x264.
Thanks again! And I'm really looking forward to when those blu-ray settings are debugged and working by the x264 team.
-1
+34
-1
+3
-1
+49
1.2.6 do not look crash
Thanks for this nice Plug-in
-1
Tell me how to reproduce the issue.
Send me crash report if available.
+49
-1
+1
+1
-1
+1
downloaded x264 in both safari and ffox. x264 not showing up in qt export as an option. please advise. thanks
+3
You have to relaunch application prior to use.
If you use QuickTime Player 10.0, it is NOT compatible.
Use QuickTime Player 7.6.3 Pro (Pro key is required).
+1
+3
http://www.youtube.com/watch?v=sZI0ET3r4O4
http://www.youtube.com/watch?v=4i5UpWuGbtc
I hope this would help you.
-1
+49
+1
- What do you mean by "Quality problem"?
- Upload settings screen captures
- Upload sample short clip (source and output with new)
- If you could, try with previous revision and also upload output with old
- Let me know the URL
+11
I've had one issue with this plugin since updating Snow Leopard. I mainly export out of iMovie, and when doing so, using x264 produces video that is darker than any of the other choices (h.264, motion jpeg, etc). This difference is noticeable when playing back through both Quicktime and VLC.
I know there was a gamma change in Snow Leopard, so Im not sure if the problem is with OSX, x264, or this particular plugin. Any ideas on what is causing this?
I have just updated to 10.6.2 and x264 still produces darker video in comparison.
If you are in Europe and SD source(=PAL), would be nclc 516.
If you are in America and SD source(=NTSC), would be nclc 616.
If you are handling HD source, would be nclc 111.
Under Standard Video Compression Settings dialog, Preview image is not correct. Test by exact output.
+11
Maybe these images can convey what I am seeing:
h.264 QTX vs x264 QTX: http://img.skitch.com/20091110-gnmnupa4249qrix9tkn7ukpcrc.jpg
h.264 QTX vs x264 VLC: http://img.skitch.com/20091110-fw7us894uje8js2br4batreeex.jpg
h.264 QTX vs x264 QTX 6-1-6:http://img.skitch.com/20091110-1d79sjwwqc95e1dy4hsnq39jeh.jpg
h.264 QT7 vs x264 QT7:http://img.skitch.com/20091110-jwtejgapcj52q86bssuc8isiy3.jpg
All images captured running Snow Leopard 10.6.2 with default Color LCD Display profile.
I used QuickTime Player 7. I can not reproduce your issue.
If you could, please upload short clip(~3 sec) and let me know via mail.
+11
I get over 1000 spam mails a week. I had NEVER put my mail address on my site though!
+11
These were both encoded using iMovie '09 8.0.5 on MacOSX 10.6.2. The x264 file with x264 1.1.7 with default settings and h.264 file with built-in Quicktime h.264 with default settings.
x264 Encode Test-No nclc atom: http://dl.dropbox.com/u/277171/x264%20Encode%20Test%20-%20No%20nclc%20atom.mov
h.264 Encode Test (for comparison): http://dl.dropbox.com/u/277171/h264%20Encode%20Test.mov
I did not notice this difference until I upgraded to Snow Leopard.
+11
- apple h.264 has nclc 616 in mov.
- x264 sample does not have nclc atom.
Upload x264 with nclc 616 please.
+11
+11
- Is it able to upload source data (not exported but source data)?
- what version of imovie are you using?
mov file is desirable. I don't know iMovie is capable of exporting movie without transcode though...
+11
If I were to go to the x264 settings, I would notice that the preview window was much darker than the source file: http://img.skitch.com/20091113-exj43gmr26386griduc2abquxe.jpg
Switching to h.264 (or any other choice) showed a preview window much closer to the original source: http://img.skitch.com/20091113-ns842yu76qws2fskm1hxtkfay9.jpg
So, right now Im thinking the x264 file will be darker than the h.264. This IS true and what my original pictures above showed.
But in reality, what is happening is h.264 is actually producing video that is LIGHTER than the source! I was able to go through iMovie package files to find the source and compare: http://img.skitch.com/20091113-8wx6km4b2hasuiujrm3scw3qri.jpg
http://img.skitch.com/20091113-qnfp9tu3b1itmjaxyhjn56kbkp.jpg
What threw me off was the preview window. x264's preview window is darker than the source, but exports OK. h.264's preview window looks OK, but exports video that is lighter than the source.
Does that make sense? Thank you for looking over this with me, and for always keeping this Quicktime plugin up to date!
+13
No way to use it like this. Thnks
+1
+322
+13
Sorry but it is what I get......
+322
+13
The old roads are always the better ones :-D Thnks again
+49
From the last version was add "min keyf", the playback still not read smooth in vlc or quicktime.
+13
Can it create some trouble using FCP/FCE w/h AVCHD cameras?
+19
Davidson69 rated on 01 Jan 2012
niekd rated on 30 Dec 2011
humbee rated on 18 Nov 2011
+2
Chealion rated on 18 Sep 2011
+2
Chealion rated on 29 Jul 2011
+1
Jolyjumper rated on 01 May 2011
thomas.overbye rated on 11 Apr 2011