diff --git a/ext/x264/gstx264enc.c b/ext/x264/gstx264enc.c index a99a8e1946..0951ea7e78 100644 --- a/ext/x264/gstx264enc.c +++ b/ext/x264/gstx264enc.c @@ -46,6 +46,17 @@ * applied, followed by the user-set properties, fast first pass restrictions and * finally the profile restrictions. * + * Some settings, including the default settings, may lead to quite + * some latency (i.e. frame buffering) in the encoder. This may cause problems + * with pipeline stalling in non-trivial pipelines, because the encoder latency + * is often considerably higher than the default size of a simple queue + * element. Such problems are caused by one of the queues in the other + * non-x264enc streams/branches filling up and blocking upstream. They can + * be fixed by relaxing the default time/size/buffer limits on the queue + * elements in the non-x264 branches, or using a (single) multiqueue element + * for all branches. Also see the last example below. + * + * * * Example pipeline * |[ @@ -66,6 +77,14 @@ * constant quality at around Q25 using the 'medium' speed/quality preset and * restricting the options used so that the output is H.264 Baseline Profile * compliant and finally multiplexing the output in Quicktime mov format. + * |[ + * gst-launch -v videotestsrc num-buffers=1000 ! tee name=t ! queue ! xvimagesink \ + * t. ! queue ! x264enc rc-lookahead=5 ! fakesink + * ]| This example pipeline will encode a test video source to H264 while + * displaying the input material at the same time. As mentioned above, + * specific settings are needed in this case to avoid pipeline stalling. + * Depending on goals and context, other approaches are possible, e.g. + * tune=zerolatency might be configured, or queue sizes increased. * */