[MPlayer-DOCS] Re: Draft: iPod encoding guide
poirierg at gmail.com
Fri Jan 12 10:59:24 CET 2007
On 1/12/07, Mark Pilgrim <pilgrim at gmail.com> wrote:
> Oh hell, I found some stupid copy-and-paste errors. Just ignore draft
> 1 and let's all start the discussion with draft 2 (attached).
\o/ Excellent! \o/
Here is a few remarks:
+ The iPod 5G supports the H.264 baseline profile with a maximum size of
+ 320 x 240 and a maximum bitrate of 768kbps. The screen on the iPod 5G
+ is exactly 320 x 240, so this works out well for source material with a
+ 4x3 aspect ratio. For widescreen source material, you can choose to crop
+ the video horizontally or scale the video down to 320 x (some number smaller
+ than 240). The iPod 5G will correctly display widescreen videos by
+ centering them vertically within the iPod screen; there is no need to add
+ black bars to the encoded video file itself.</para>
The specs I found here (http://www.apple.com/ipod/specs.html) do not
seem to corroborate your findings:
Video formats supported: H.264 video, up to 1.5 Mbps, 640 by 480
pixels, 30 frames per sec., Low-Complexity version of the H.264
Baseline Profile with AAC-LC audio up to 160 Kbps, 48 kHz, stereo
audio in .m4v, .mp4, and .mov file formats; H.264 video, up to 768
Kbps, 320 by 240 pixels, 30 frames per sec., Baseline Profile up to
Level 1.3 with AAC-LC audio up to 160 Kbps, 48 kHz, stereo audio in
.m4v, .mp4, and .mov file formats; MPEG-4 video, up to 2.5 Mbps, 640
by 480 pixels, 30 frames per sec., Simple Profile with AAC-LC audio up
to 160 Kbps, 48 kHz, stereo audio in .m4v, .mp4, and .mov file formats
Well, maybe it's due to the fact that these are the iPod's 5.5G's tech specs...
But apparently, after some googling, it seems that both 5 and 5.5 G
support the same video constrains.
Could you test 1.5 Mbps, 640 by 480 pixels on your 5G? (Google tells
me that the screen is 320 by 240 pixels, so 640 by 480 videos are just
downscaled, which could seem like a waste of bits, unless you wanna
create a video that can be both watchable on a computer, and on an
What about 25fps videos? Are they supported too?
+<para>The H.264 baseline profile imposes a number of constraints:</para>
+ <emphasis role="bold">B-frames</emphasis> are not supported. They are off
+ by default, so just skip them. This also means that
+ <option>b_pyramid</option> and <option>weight_b</option> will have no
+ <emphasis role="bold">8x8 DCT macroblocks</emphasis> are not supported.
+ This option (<option>8x8dct</option>) is off by default, so just be sure
+ not to explicitly enable it. This also means that the
+ <option>partitions=i8x8</option> option will have no effect, since it
+ requires <option>8x8dct</option>.
+ <emphasis role="bold">CABAC</emphasis> is not supported. You must
+ specifically turn it off with the <option>nocabac</option> option.
Although I don't like the fact that this looks very much alike "QT
encoding guide", I guess it will probably help the user getting
started if things are recapped here too.
_maybe_ it could be worthwhile to add to x264's encoding section a
note about the different h264 levels/profile.
How do you feel about this?
+ If you have a multi-processor machine, you can add
+ <option>threads=auto</option>. This increases encoding speed by about
+ 94% per CPU core, with very little quality penalty (about 0.005dB for
+ dual processor, about 0.01dB for a quad processor machine).
This should be moved to the x264's doc section about encoding options
(same for QT encoding guide); actually x264's section needs a serious
lifting, which I need to take care of over the weekend.
+ The second pass is the same, with <option>pass=2</option>, plus an output
+ filename, minus <option>turbo=1</option>.
I don't have any strong opinion about this, but "turbo" should either
always be on 2nd pass, or never (in that case, QT guide should be
People seem to get easily confused about the real effect of turbo, so
either way, there will always be ppl wondering if they should leave it
on or drop it on 2nd pass.
More information about the MPlayer-DOCS