Changes between Version 42 and Version 43 of Encode/H.264


Ignore:
Timestamp:
Jun 6, 2013, 6:35:33 PM (13 years ago)
Author:
llogan
Comment:

mention faststart; various nits

Legend:

Unmodified
Added
Removed
Modified

  • Encode/H.264

    v42 v43  
    136136libx264 offers a `-tune zerolatency` option. See the [[StreamingGuide]].
    137137
    138 === Compatibility ===#compatibility
     138=== Compatibility ===
    139139
    140140If 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
    … …  
    149149}}}
    150150
    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.
     151Keep 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.
    152152
    153153=== Pre-testing your settings ===
    … …  
    156156* `-t`: Output duration. Value can be in seconds or HH:MM:SS format.
    157157
     158=== `faststart` for web video ===
     159
     160You can add `-movflags +faststart` as an output option if your videos are going to be viewed in a browser. This will move some information to the beginning of your file and allow the video to begin playing before it is completely downloaded by the viewer. It is not required if you are going to use a video service such as !YouTube.
     161
    158162----
    159163
    160 == FAQ ==#faq
     164== FAQ ==
    161165
    162166=== Will two-pass provide a better quality than CRF? ===
    … …  
    175179No. 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.
    176180
    177 === Encoding for !QuickTime Player ===
     181=== Encoding for dumb players ===
    178182
    179 You will need to use `-pix_fmt yuv420p` for your output to work in QT Player. This is because Apple Quicktime 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 QT and other players that are not based on FFmpeg.
     183You 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.