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


Ignore:
Timestamp:
Jun 6, 2013, 9:35:33 PM (5 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.