Changes between Version 56 and Version 57 of Encode/H.264


Ignore:
Timestamp:
Nov 18, 2016, 9:07:40 PM (3 years ago)
Author:
llogan
Comment:

removed -qp cargo-cult info, removed dead link, various nits

Legend:

Unmodified
Added
Removed
Modified
  • Encode/H.264

    v56 v57  
    8282As with CRF, choose the slowest preset you can tolerate.
    8383
    84 In pass 1 specify a output format (with "-f") that matches the output format in pass 2. Also in pass 1, specify the audio codec used in pass 2; in many cases "-an" in pass 1 will not work. 
     84In pass 1 specify a output format with `-f` that matches the output format in pass 2. Also in pass 1, specify the audio codec used in pass 2; in many cases `-an` in pass 1 will not work.
     85
     86{{{#!comment
     87In which cases is the above true?
     88}}}
    8589
    8690See [http://www.mplayerhq.hu/DOCS/HTML/en/menc-feat-dvd-mpeg4.html Making a high quality MPEG-4 ("DivX") rip of a DVD movie]. It is an MEncoder guide, but it will give you an insight about how important it is to use two-pass when you want to efficiently use every bit when you're constrained with storage space.
     
    9094== Lossless H.264 ==
    9195
    92 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 (but !YouTube can), so if compatibility is an issue you should not use lossless.
     96You can use `-crf 0` to encode a lossless output. 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.
     97
     98Note that lossless output files will likely be huge.
    9399
    94100=== Lossless Example (fastest encoding) ===
    95101
    96102{{{
    97 ffmpeg -i input -c:v libx264 -preset ultrafast -qp 0 output.mkv
     103ffmpeg -i input -c:v libx264 -preset ultrafast -crf 0 output.mkv
    98104}}}
    99105
     
    102108
    103109{{{
    104 ffmpeg -i input -c:v libx264 -preset veryslow -qp 0 output.mkv
     110ffmpeg -i input -c:v libx264 -preset veryslow -crf 0 output.mkv
    105111}}}
    106112
     
    121127== Additional Information & Tips ==
    122128
    123 === ABR (Average Bit Rate) ===
    124 
    125 {{{
    126 ffmpeg -i input -c:v libx264 -b:v 1000k output.mp4
    127 }}}
    128 
    129 This provides something of a "running average" target, with the end goal that the final file match this number "overall on average" (so basically, if it gets a lot of black frames, which cost very little, it will encode them with less than the requested bitrate, but then the next few seconds of (non-black) frames it will encode at very high quality, to bring the average back in line).  Using 2-pass can help this method to be more effective.  You can also use this in combination with a "max bit rate" setting in order to prevent some of the swings.
    130 
    131129=== CBR (Constant Bit Rate) ===
    132130
     
    143141=== CRF with maximum bit rate ===
    144142
    145 You can also also use a crf with a maximum bit rate by specifying both crf *and* maxrate settings, like
     143You can also also use `-crf` with a maximum bit rate by specifying both `-crf` and `-maxrate`:
    146144{{{
    147145ffmpeg -i input -c:v libx264 -crf 20 -maxrate 400k -bufsize 1835k output.mp4
    148146}}}
    149147
    150 This will effectively "target" crf 20, but if the output exceeds 400kb/s, it will degrade to something less than crf 20 in that case.
     148This will effectively "target" `-crf 20`, but if the output exceeds 400kb/s, it will degrade to something less than `-crf 20` in that case.
    151149
    152150=== Low Latency ===
     
    158156==== All devices ====
    159157
    160 If you want your videos to have highest compatibility with target devices (older iOS versions or all Android devices):
     158If you want your videos to have highest compatibility with older devices:
    161159
    162160{{{
     
    164162}}}
    165163
    166 This disables some advanced features but provides for better compatibility. Typically you may not need this setting (and therefore avoid using `-profile:v` and `-level`), 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.
     164This disables some advanced features but provides for better compatibility. Typically you may not need this setting (and therefore avoid using `-profile:v` and `-level`), but if you do use this setting it may increase the bit rate compared to what is needed to achieve the same quality in higher profiles.
    167165
    168166==== iOS ====
     
    180178{{{
    181179#!div style="border: 1pt dotted; margin: 1em; background-color: #fffff9;"
    182 * This table does not include any additional restrictions which may be required by your device.
    183 * `-level` may not set the correct number of reference frames (`-refs`) if you're using an older build. See ticket #3307.
    184 }}}
    185 
    186 ==== Apple Quicktime ====
    187 
    188 Apple !QuickTime only supports YUV planar color space with 4:2:0 chroma subsampling (use `-pix_fmt yuv420p`) for H.264 video. For information on additional restrictions see [http://mewiki.project357.com/wiki/X264_Encoding_Suggestions#QuickTime-compatible_Encoding QuickTime-compatible Encoding].
     180'''Note:'''  This table does not include any additional restrictions which may be required by your device.
     181}}}
     182
     183==== !QuickTime ====
     184
     185!QuickTime only supports YUV planar color space with 4:2:0 chroma subsampling (use `-vf format=yuv420p` or `-pix_fmt yuv420p`) for H.264 video.
    189186
    190187==== Blu-ray ====
     
    194191=== Pre-testing your settings ===
    195192
    196 Encode a random section instead of the whole video with the `-ss` and `-t` options to quickly get a general idea of what the output will look like.
     193Encode a random section instead of the whole video with the `-ss` and `-t`/`-to` options to quickly get a general idea of what the output will look like.
     194
    197195* `-ss`: Offset time from beginning. Value can be in seconds or HH:MM:SS format.
    198 * `-t`: Output duration. Value can be in seconds or HH:MM:SS format.
     196* `-t`: Duration. Value can be in seconds or HH:MM:SS format.
     197* `-to`: Stop writing the output at specified position. Value can be in seconds or HH:MM:SS format.
    199198
    200199=== `faststart` for web video ===
     
    203202
    204203=== Custom preset file ===
    205 Add `-fpre or -vpre` output option.
    206 
    207 First ffmpeg searches for a file named arg.ffpreset in the directories `$FFMPEG_DATADIR` (if set), and `$HOME/.ffmpeg`, and in the datadir defined at configuration time (usually PREFIX/share/ffmpeg) or in a ffpresets folder along the executable on win32, in that order. For example, if the argument is libx264-1080p, it will search for the file libx264-1080p.ffpreset.
     204
     205Refer to the `-vpre` output option in the [https://ffmpeg.org/ffmpeg.html#Preset-files documentation].
     206
    208207----
    209208
     
    211210
    212211=== Will two-pass provide a better quality than CRF? ===
     212
    213213[http://web.archive.org/web/20140206073211/http://doom10.org/index.php?PHPSESSID=okj08qe73ictdtv532augv8nu7&topic=267.msg2071#msg2071 No], though it does allow you to target a file size more accurately.
    214214
     
    223223=== Will a graphics card make x264 encode faster? ===
    224224
    225 Not 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.
     225For x264 specifically, probably not. [http://git.videolan.org/?p=x264.git;a=commit;h=3a5f6c0aeacfcb21e7853ab4879f23ec8ae5e042 x264 supports OpenCL] for some lookahead operations.
     226
     227See [[HWAccelIntro]] for information on supported hardware based H.264 encoders and decoders.
    226228
    227229=== Encoding for dumb players ===
    228230
    229 You may need to use `-pix_fmt yuv420p` for your output to work in !QuickTime and most other players. These players only supports the YUV planar color space with 4:2:0 chroma subsampling for H.264 video. Otherwise, depending on your source, ffmpeg may output to a pixel format that may be incompatible with these players.
     231You may need to use `-vf format=yuv420p` (or the alias `-pix_fmt yuv420p`) for your output to work in !QuickTime and most other players. These players only supports the YUV planar color space with 4:2:0 chroma subsampling for H.264 video. Otherwise, depending on your source, `ffmpeg` may output to a pixel format that may be incompatible with these players.
    230232
    231233----
     
    233235== Additional Resources ==
    234236
    235 * [http://en.wikibooks.org/wiki/MeGUI/x264_Settings x264 Settings - MeWiki] (outdated, doesn't even mention presets)
    236 * [http://en.wikibooks.org/wiki/MeGUI/x264_Settings/x264_Encoding_Suggestions x264 Encoding Suggestions - MeWiki]
    237237* [http://slhck.info/articles/crf Constant Rate Factor Guide]