| 49 | | == Latency == |
| 50 | | You can decrease latency by specify that I-frames come "more frequently" (or always, in the case of x264's zerolatency), though this can increase frame size/decrease quality, see [http://mewiki.project357.com/wiki/X264_Encoding_Suggestions here] for alternatives. |
| | 49 | == Latency/cpu-usage == |
| | 50 | |
| | 51 | You can decrease latency by specify that I-frames come "more frequently" (or always, in the case of x264's zerolatency), though this can increase frame size/decrease quality, see [http://mewiki.project357.com/wiki/X264_Encoding_Suggestions here] for some alternatives. To decrease cpu usage required to stream, you could (if capturing from live source) instruct the live source to feed a "smaller stream" (ex: webcam stream 640x480 instead of 1024x1280), or you could set a lower "output quality" setting, or specify a lower output bitrate. Or try a different output codec, or specify new parameters (for instance, different profile for libx264). Also specifying $ -threads 0 (the default) instructs the encoder to use all available cpu cores, which can speed up processing. You could also resize your input first, before transcoding it, so it's not as large. Applying a smoothing filter like hqdn3d before encoding might help it compress better. |
| | 52 | |
| | 53 | You could set a "maximum bit rate" or a lower "q rating" (quality level). If you're able to capture with a pixel format that matches your output format, that might help, since it avoids a conversion. Using 64-bit instead of 32-bit executables (for those that have a choice) can result in a slight speedup. |
| | 54 | |
| | 55 | In general the more cpu you use to compress, the better the output image will be, or the large of an image you can handle. |
