Fixed x264 has hit stretch.

[nageru] / x264_encoder.cpp

diff --git a/x264_encoder.cpp b/x264_encoder.cpp
index d2a0cb91fb77a76e236c792e67c32936ba6d3c84..5017e7357913ce5d33c74efc95e262e5889fcd69 100644 (file)
--- a/x264_encoder.cpp
+++ b/x264_encoder.cpp
@@ -93,12 +93,53 @@ 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.
        param.rc.i_qp_min = 5;
 
-       // TODO: more flags here, via x264_param_parse().
+       for (const string &str : global_flags.x264_extra_param) {
+               const size_t pos = str.find(',');
+               if (pos == string::npos) {
+                       if (x264_param_parse(&param, str.c_str(), nullptr) != 0) {
+                               fprintf(stderr, "ERROR: x264 rejected parameter '%s'\n", str.c_str());
+                       }
+               } else {
+                       const string key = str.substr(0, pos);
+                       const string value = str.substr(pos + 1);
+                       if (x264_param_parse(&param, key.c_str(), value.c_str()) != 0) {
+                               fprintf(stderr, "ERROR: x264 rejected parameter '%s' set to '%s'\n",
+                                       key.c_str(), value.c_str());
+                       }
+               }
+       }
 
        x264_param_apply_profile(&param, "high");