Changes between Version 45 and Version 46 of Encode/H.264


Ignore:
Timestamp:
Oct 23, 2013, 7:48:52 PM (13 years ago)
Author:
llogan
Comment:

add iOS compatibility table; nits

Legend:

Unmodified
Added
Removed
Modified

  • Encode/H.264

    v45 v46  
    1313
    1414=== 1. Choose a CRF value ===
    15 The range of the quantizer scale is 0-51; where 0 is lossless, 23 is default, and 51 is worst possible. A lower value is a higher quality and a subjectively sane range is 18-28. Consider 18 to be visually lossless: it should look the same or nearly the same as the input but it isn't technically lossless.
     15The range of the quantizer scale is 0-51: where 0 is lossless, 23 is default, and 51 is worst possible. A lower value is a higher quality and a subjectively sane range is 18-28. Consider 18 to be visually lossless or nearly so: it should look the same or nearly the same as the input but it isn't technically lossless.
    1616
    17 Increasing the CRF value +6 is roughly half the bitrate while -6 is roughly twice the bitrate. General usage is to choose the highest CRF value that still provides an acceptable quality. If the output looks good, then try a higher value and if it looks bad then choose a lower value.
     17The range is exponential, so increasing the CRF value +6 is roughly half the bitrate while -6 is roughly twice the bitrate. General usage is to choose the highest CRF value that still provides an acceptable quality. If the output looks good, then try a higher value and if it looks bad then choose a lower value.
    1818
    19   '''Note:''' The CRF quantizer scale mentioned on this page only applies to 8-bit x264 (10-bit x264 quantizer scale is 0-63). You can see what you are using with `x264 --help` listed under `Output bit depth`. 8-bit is more common amongst distributors.
     19  '''Note:''' The CRF quantizer scale mentioned on this page only applies to 8-bit x264 (10-bit x264 quantizer scale is 0-63). You can see what you are using with `x264 --help` listed under `Output bit depth`. 8-bit is more common among distributors.
    2020
    2121=== 2. Choose a preset ===
    … …  
    3131
    3232{{{
    33 ffmpeg -i input -c:v libx264 -preset -tune dummy.mp4
     33ffmpeg -y -i input -c:v libx264 -preset -tune -f mp4 /dev/null
    3434}}}
    3535
     36  '''Note:''' Windows users should use `NUL` instead of `/dev/null`.
     37
    3638=== 3. Use your settings ===
    37 Once you've chosen your settings, apply them for the rest of your videos if you are encoding more. This will ensure that they will all have similar quality.
     39Once you've chosen your settings apply them for the rest of your videos if you are encoding more. This will ensure that they will all have similar quality.
    3840
    3941=== CRF Example ===
    40 
    41 The following example will encode a video with x264, using a slower than normal preset, with a slightly better quality than the default (23).
    4242
    4343{{{
    … …  
    4545}}}
    4646
    47 Note that in this example, the audio stream of the input file is simply copied over to the output and not re-encoded.
     47Note that in this example the audio stream of the input file is simply [http://ffmpeg.org/ffmpeg.html#Stream-copy stream copied] over to the output and not re-encoded.
    4848
    4949----
    … …  
    7373
    7474== Lossless H.264 ==
    75 You can use `-qp 0` or `-crf 0` to encode a lossless output. Use of `-qp` is recommended over `-crf` for lossless because 8-bit and 10-bit x264 use different `-crf` values for lossless.  Two useful presets for this are `ultrafast` or `veryslow` since either a fast encoding speed or best compression are usually the most important factors. Most non-FFmpeg based players will not be able to decode lossless, so if compatibility is an issue you should not use lossless.
     75You can use `-qp 0` or `-crf 0` to encode a lossless output. Use of `-qp` is recommended over `-crf` for lossless because 8-bit and 10-bit x264 use different `-crf` values for lossless.  Two useful presets for this are `ultrafast` or `veryslow` since either a fast encoding speed or best compression are usually the most important factors. Most non-FFmpeg based players will not be able to decode lossless (but !YouTube can), so if compatibility is an issue you should not use lossless.
    7676
    7777=== Lossless Example (fastest encoding) ===
    … …  
    107107
    108108{{{
    109 ffmpeg -i input -c:v libx264 -b:v 1000k ...
     109ffmpeg -i input -c:v libx264 -b:v 1000k output.mp4
    110110}}}
    111111
    … …  
    127127You can also also use a crf with a maximum bit rate by specifying both crf *and* maxrate settings, like
    128128{{{
    129 ffmpeg -i input -c:v libx264 -crf 20 -maxrate 400k -bufsize 1835k
     129ffmpeg -i input -c:v libx264 -crf 20 -maxrate 400k -bufsize 1835k output.mp4
    130130}}}
    131131
    … …  
    138138=== Compatibility ===
    139139
    140 If you want your videos to have highest compatibility with target players (for instance, with older iOS versions or all Android devices) then you'll want to specify 
     140If you want your videos to have highest compatibility with target players (for instance, with older iOS versions or all Android devices) then you'll want to specify:
    141141{{{
    142142-profile:v baseline
    143143}}}
    144 which disables some advanced features but provides for better compatibility.  Typically you may not need this setting.  Also if you do use this setting, it increases the bit rate quite a bit, compared to what's needed to achieve the same quality in higher profiles.
     144This disables some advanced features but provides for better compatibility. Typically you may not need this setting, but if you do use this setting it may increase the bit rate quite a bit compared to what is needed to achieve the same quality in higher profiles.
    145145
    146 For a list of supported profiles and their description, run
     146||||||||= '''iOS Compatability''' ([https://developer.apple.com/library/mac/documentation/NetworkingInternet/Conceptual/StreamingMediaGuide/UsingHTTPLiveStreaming/UsingHTTPLiveStreaming.html#//apple_ref/doc/uid/TP40008332-CH102-SW8 source]) =||
     147||= '''Profile''' =||= '''Level''' =||= '''Devices''' =||= '''Options''' =||
     148|| Baseline || 3.0 || All devices || `-profile:v baseline -level 3.0` ||
     149|| Baseline || 3.1 || iPhone 3G and later, iPod touch 2nd generation and later || `-profile:v baseline -level 3.1` ||
     150|| Main || 3.1 || iPad (all versions), Apple TV 2 and later, iPhone 4 and later || `-profile:v main -level 3.1` ||
     151|| Main || 4.0 || Apple TV 3 and later, iPad 2 and later, iPhone 4S and later || `-profile:v main -level 4.0` ||
     152|| High || 4.0 || Apple TV 3 and later, iPad 2 and later, iPhone 4S and later || `-profile:v high -level 4.0` ||
     153|| High || 4.1 || iPad 2 and later and iPhone 4S and later || `-profile:v high -level 4.1` ||
     154
     155For a list of supported profiles and their descriptions see:
    147156{{{
    148157x264 --fullhelp
    149158}}}
    150159
    151 Keep in mind that Apple Quicktime only supports YUV 420 color space for x264 encoded movies, and does not support anything higher than the "main" profile. This leaves only 2 options for Quicktime compatible clips: baseline and main. All of the other profiles are currently not supported with Quicktime, although they will play back in pretty much any other player.
     160Keep in mind that Apple !QuickTime only supports YUV 420 color space for x264 encoded movies, and does not support anything higher than the "main" profile. This leaves only 2 options for !QuickTime compatible clips: baseline and main. All of the other profiles are currently not supported with !QuickTime, although they will play back in pretty much any other player.
     161
     162{{{#!comment
     163Has anyone tested this recently? It seems oddly stupid, even for QT not to support main.
     164}}}
    152165
    153166=== Pre-testing your settings ===
    … …  
    177190=== Will a graphics card make x264 encode faster? ===
    178191
    179 No. libx264 doesn't use them (at least not yet). There are some proprietary encoders that utilize the GPU, but that does not mean they are well optimized, though encoding time may be faster; and they might be [http://phoronix.com/forums/showthread.php?50697-Test-tool-for-snb-h264-encoder-in-libva-git&p=205580#post205580 worse than x264] anyway, and possibly slower. Regardless, FFmpeg today doesn't support any means of gpu encoding, outside of libx264.
     192Not necessarily. [http://git.videolan.org/?p=x264.git;a=commit;h=3a5f6c0aeacfcb21e7853ab4879f23ec8ae5e042 x264 supports OpenCL] for some lookahead operations. There are also some proprietary encoders that utilize the GPU, but that does not mean they are well optimized, though encoding time may be faster; and they might be [http://phoronix.com/forums/showthread.php?50697-Test-tool-for-snb-h264-encoder-in-libva-git&p=205580#post205580 worse than vanilla x264], and possibly slower. Regardless, FFmpeg today doesn't support any means of GPU encoding, outside of libx264.
    180193
    181194=== Encoding for dumb players ===
    182195
    183 You may need to use `-pix_fmt yuv420p` for your output to work in Quicktime and most other players. These players only supports YUV 420 color space for H.264 encoded clips. Otherwise, depending on your source, ffmpeg may output to a pixel format that may be incompatible with these players.
     196You may need to use `-pix_fmt yuv420p` for your output to work in !QuickTime and most other players. These players only supports YUV 420 color space for H.264 encoded clips. Otherwise, depending on your source, ffmpeg may output to a pixel format that may be incompatible with these players.