Changes between Version 23 and Version 24 of x264EncodingGuide
- Timestamp:
- 09/12/2012 12:26:37 AM (9 months ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
x264EncodingGuide
v23 v24 86 86 ---- 87 87 88 == Additional Information ,Tips ==88 == Additional Information & Tips == 89 89 90 90 === ABR (Average Bit Rate) === 91 91 92 92 {{{ 93 ffmpeg -i input - vcodec libx264 -b1000k ...93 ffmpeg -i input -c:v libx264 -b:v 1000k ... 94 94 }}} 95 95 … … 100 100 There is no native CBR mode, but you can "simulate" a constant bit rate setting by tuning the parameters of ABR, like 101 101 {{{ 102 ffmpeg -i input - vcodec libx264 -b4000k -minrate 4000k -maxrate 4000k -bufsize 1835k out.m2v102 ffmpeg -i input -c:v libx264 -b:v 4000k -minrate 4000k -maxrate 4000k -bufsize 1835k out.m2v 103 103 }}} 104 104 105 in this example, bufsizeis the "rate control buffer" so it will enforce your requested "average" (4000k in this case) across each 1835k worth of video. So basically it is assumed that the receiver/end player will buffer that much data so it's ok to fluctuate within that much.105 in this example, `-bufsize` is the "rate control buffer" so it will enforce your requested "average" (4000k in this case) across each 1835k worth of video. So basically it is assumed that the receiver/end player will buffer that much data so it's ok to fluctuate within that much. 106 106 107 107 Of course, if it's all just empty/black frames then it will still serve less than that many bits/s (but it will raise the quality level as much as it can, up to the crf level). … … 111 111 You can also also use a crf with a maximum bit rate by specifying both crf *and* maxrate settings, like 112 112 {{{ 113 ffmpeg -i input - vcodeclibx264 -crf 20 -maxrate 400k -bufsize 1835k113 ffmpeg -i input -c:v libx264 -crf 20 -maxrate 400k -bufsize 1835k 114 114 }}} 115 115 … … 118 118 === Low Latency === 119 119 120 libx264 offer a "-tune zerolatency"option see See the [[StreamingGuide]].120 libx264 offer a `-tune zerolatency` option see See the [[StreamingGuide]]. 121 121 122 122 === Compatibility === … … 124 124 If you want your videos to have highest "compatibility" with target players (for instance, with older iOS devices) then you'll want to specify 125 125 {{{ 126 -profile baseline126 -profile:v baseline 127 127 }}} 128 which removes some advanced features but is more compatible. Typically you may not need this setting. Also if you do use this setting, it increases the bit rate quite a bit , so you might get as good of compression (and possibly increased encoding speed) by just using the mpeg4 video codec instead.128 which removes some advanced features but is more compatible. Typically you may not need this setting. Also if you do use this setting, it increases the bit rate quite a bit. 129 129 130 130 === Pre-testing your settings === … … 146 146 === Why doesn't my lossless output look lossless? === 147 147 148 Blame the rgb->yuv conversion. 148 Blame the rgb->yuv conversion. If you convert to yuv422p, it should still be lossless (which is the default now). 149 149 150 150 === Will a graphics card make x264 encode faster? === 151 151 152 No. x264 doesn't use them at all. There are some proprietary encoders that utilize the GPU, but that does not mean they are very good or well optimized; and they might be [http://phoronix.com/forums/showthread.php?50697-Test-tool-for-snb-h264-encoder-in-libva-git&p=205580#post205580 slower than x264] anyway. But they might be faster.Regardless, FFmpeg today doesn't support any means of gpu encoding.152 No. x264 doesn't use them at all. There are some proprietary encoders that utilize the GPU, but that does not mean they are very good or well optimized; and they might be [http://phoronix.com/forums/showthread.php?50697-Test-tool-for-snb-h264-encoder-in-libva-git&p=205580#post205580 slower than x264] anyway. But they might be faster. Regardless, FFmpeg today doesn't support any means of gpu encoding.
