[MPlayer-DOCS] Interested in contributing case studies

[Jeff Clagg]

On Fri, Oct 20, 2006 at 01:37:00PM -0400, Mark Pilgrim wrote:
> On 10/19/06, Guillaume POIRIER <poirierg at 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)