Document the mlockall() change in NEWS.

[nageru] / x264_encoder.cpp

diff --git a/x264_encoder.cpp b/x264_encoder.cpp
index df9e9945e789370e639c8bdacc9c3d798c524900..8ee486734a9dc72b239298db5b587f9b01b62800 100644 (file)
--- a/x264_encoder.cpp
+++ b/x264_encoder.cpp
@@ -6,6 +6,7 @@
 #include "mux.h"
 #include "timebase.h"
 #include "x264_encoder.h"
+#include "x264_speed_control.h"
 
 extern "C" {
 #include <libavformat/avformat.h>
@@ -68,6 +69,9 @@ void X264Encoder::init_x264()
        param.i_timebase_num = 1;
        param.i_timebase_den = TIMEBASE;
        param.i_keyint_max = 50; // About one second.
+       if (global_flags.x264_speedcontrol) {
+               param.i_frame_reference = 16;  // Because speedcontrol is never allowed to change this above what we set at start.
+       }
 
        // NOTE: These should be in sync with the ones in h264encode.cpp (sbs_rbsp()).
        param.vui.i_vidformat = 5;  // Unspecified.
@@ -89,6 +93,33 @@ void X264Encoder::init_x264()
        } else {
                param.rc.i_vbv_max_bitrate = global_flags.x264_vbv_max_bitrate;
        }
+       if (param.rc.i_vbv_max_bitrate > 0) {
+               // If the user wants VBV control to cap the max rate, it is
+               // also reasonable to assume that they are fine with the stream
+               // constantly being around that rate even for very low-complexity
+               // content; the obvious and extreme example being a static
+               // black picture.
+               //
+               // One would think it's fine to have low-complexity codec use
+               // less bitrate, but it seems to cause problems in practice;
+               // e.g. VLC seems to often drop the stream (similar to a buffer
+               // underrun) in such cases, but only when streaming from Nageru,
+               // not when reading a dump of the same stream from disk.
+               // I'm not 100% sure whether it's in VLC (possibly some buffering
+               // in the HTTP layer), in microhttpd or somewhere in Nageru itself,
+               // but it's a typical case of problems that can arise. Similarly,
+               // TCP's congestion control is not always fond of the rate staying
+               // low for a while and then rising quickly -- a variation on the same
+               // problem.
+               //
+               // We solve this by simply asking x264 to fill in dummy bits
+               // in these cases, so that the bitrate stays reasonable constant.
+               // It's a waste of bandwidth, but it makes things go much more
+               // smoothly in these cases. (We don't do it if VBV control is off
+               // in general, not the least because it makes no sense and x264
+               // thus ignores the parameter.)
+               param.rc.b_filler = 1;
+       }
 
        // Occasionally players have problem with extremely low quantizers;
        // be on the safe side. Shouldn't affect quality in any meaningful way.
@@ -106,6 +137,10 @@ void X264Encoder::init_x264()
                exit(1);
        }
 
+       if (global_flags.x264_speedcontrol) {
+               speed_control.reset(new X264SpeedControl(x264, /*f_speed=*/1.0f, X264_QUEUE_LENGTH, /*f_buffer_init=*/1.0f));
+       }
+
        if (wants_global_headers) {
                x264_nal_t *nal;
                int num_nal;
@@ -168,6 +203,7 @@ void X264Encoder::encode_frame(X264Encoder::QueuedFrame qf)
        x264_nal_t *nal = nullptr;
        int num_nal = 0;
        x264_picture_t pic;
+       x264_picture_t *input_pic = nullptr;
 
        if (qf.data) {
                x264_picture_init(&pic);
@@ -181,9 +217,15 @@ void X264Encoder::encode_frame(X264Encoder::QueuedFrame qf)
                pic.img.i_stride[1] = WIDTH / 2 * sizeof(uint16_t);
                pic.opaque = reinterpret_cast<void *>(intptr_t(qf.duration));
 
-               x264_encoder_encode(x264, &nal, &num_nal, &pic, &pic);
-       } else {
-               x264_encoder_encode(x264, &nal, &num_nal, nullptr, &pic);
+               input_pic = &pic;
+       }
+
+       if (speed_control) {
+               speed_control->before_frame(float(free_frames.size()) / X264_QUEUE_LENGTH, X264_QUEUE_LENGTH, 1e6 * qf.duration / TIMEBASE);
+       }
+       x264_encoder_encode(x264, &nal, &num_nal, input_pic, &pic);
+       if (speed_control) {
+               speed_control->after_frame();
        }
 
        // We really need one AVPacket for the entire frame, it seems,