On Fri, Oct 20, 2006 at 01:37:00PM -0400, Mark Pilgrim wrote:
On 10/19/06, Guillaume POIRIER <poirierg@gmail.com> wrote:
We frequently receive questions about these on our user mailing list. Having doc on how to create such files would be more that welcome.
Attached is a first draft of "Using MEncoder to create QuickTime-compatible files". I inserted it before the VCD/SVCD/DVD section, but I have no objection to moving it. There are two TODOs where I don't know whether my knowledge is NTSC-specific (it probably is). Please critique it and let me know if I've made any mistakes.
Thanks for this, but I do wish you could put text attachments inline so they're easier to reply to.
+<para> + <application>QuickTime</application> 7 supports H.264 video and AAC audio, + but it does not support the AVI container format. However, you can use + <application>MEncoder</application> to encode the video and audio, and then + use an external program such as <application>mp4creator</application> (part + of the <ulink url="http://mpeg4ip.sourceforge.net/">MPEG4IP suite</ulink>) + to remux the video and audio tracks into an MP4 container. +</para>
Seems to me like gpac's MP4Box is more widely used.
+<listitem><para> + <emphasis role="bold">B-frames</emphasis>: + <application>QuickTime</application> 7 supports a maximum of 1 B-frame, i.e. + <option>-x264encopts bframes=1</option>. This also implies that you can not + use <option>b_pyramid</option> and <option>weight_b</option>, since they + require <option>bframes</option> to be greater than 1. +</para></listitem> +<listitem><para>
Call me pedantic, but your statement here is not literally true. You CAN use b_pyramid and weight_b, but they will have no effect when bframes is 0 or 1. Which, I think, is what you should say instead.
+ <emphasis role="bold">Macroblocks</emphasis>: + <application>QuickTime</application> 7 does not support 8x8 DCT macroblocks, + so you must specify <option>-x264encopts no8x8dct</option>. This also + implies that you can not use <option>i8x8</option>, since it requires + <option>8x8dct</option>.
You can use i8x8 (indeed most will since it's default), but it has no effect without 8x8dct.
+ <emphasis role="bold">Mixed reference frames</emphasis>: in + <application>QuickTime</application> 7, each whole macroblock must use the + same reference, so you must specify + <option>-x264encopts nomixed_refs</option>.
Just curious, how did you find this out?
+ <emphasis role="bold">Motion vectors</emphasis>: + <application>QuickTime</application> 7 does not support the + <option>bime</option> option that allows <application>MEncoder</application> + to refine the two motion vectors used in bidirectional macroblocks. You + must specify <option>-x264encopts nobime</option>.
Um, extraordinary claims require extraordinary proof. Please prove that this is actually true before including it in the guide.
+<para> + The next step is truly heartbreaking. <application>QuickTime</application> + does not support the <option>autoaspect</option> option, so you will + need to scale the video yourself. This wastes a lot of disk space, but it + simply can not be avoided. Of course you want a full-resolution + video, so you will not be scaling vertically. To scale horizontally, + you first need to know what aspect ratio the source DVD uses. + <application>MPlayer</application> can tell you this:
[snip] I really have no idea what you are talking about here - first we have a bunch of x264 treatment, then you jump into autoaspect, which is not an x264 option. Also, are you saying Quicktime 7 doesn't support SAR/DAR?
+ As always, the selection of bitrate is a matter of taste. This movie + has a fair bit of action and lots of detail, but H.264 video looks + good at much lower bitrates than XviD or other MPEG-4 codecs. After + much experimentation, I chose to encode this movie at 900kbs. Yes, + you read that correctly: 900kbs. My wife thought the result looked + phenomenal on her PowerBook's screen. Your wife may have different + standards; adjust your bitrate accordingly.
s/kbs/kbps
+ You are now ready to do encode the video. Of course you will be + doing a two-pass encode. For the first pass, + you can reduce <option>subq</option> and <option>frameref</option> + to save some time. The options that are required for + <application>QuickTime</application> compatibility are displayed + in bold.
1. What's the point in telling the user to specify a bunch of options (no8x8dct, nomixed_refs, nobime,..) that are DEFAULT anyway? IMO this just confuses people about what the defaults are, and what you do/don't have to specify. Also, bframes=1 should be recommended but it is not actually required for quicktime compatibility since bframes=0 (default) would also work. 2. Why don't you just use turbo=n on the first pass?
+ If you have a multi-processor machine, you can add + <option>threads=2</option> to the end of <option>-x264encopts</option>.
More pedantry: anyone CAN add threads=2. Only some people will want to. (those with 2+ cpus, who compiled with pthreads support, and who care a lot about the speed gain,...)
+ The second pass is the same, except that you specify + <option>pass=2</option> and bump <option>subq</option> and + <option>frameref</option> up to 5.
(again, this is why you should probably use turbo, would make the guide simpler)
+ Unfortunately, <application>mp4creator</application> does not support + declaring the bitrate as a fraction (24000/1001), so you will need to + specify the rate as a decimal.
s/bitrate/framerate Also I think the limitation is actually in the .mov/.mp4 container (hopefully someone who knows will comment)