[Study] bitrate_calculation_probe CPU usage

[j1elo]

@prlanzarin told about how disabling the bitrate_calculation_probe actually reduces CPU usage a fair bit:

diff --git a/src/gst-plugins/commons/kmsparsetreebin.c b/src/gst-plugins/commons/kmsparsetreebin.c
index ba70da6d..db9f93e1 100644
--- a/src/gst-plugins/commons/kmsparsetreebin.c
+++ b/src/gst-plugins/commons/kmsparsetreebin.c
@@ -170,9 +170,9 @@ kms_parse_tree_bin_configure (KmsParseTreeBin * self, const GstCaps * caps)
   if (!kms_utils_caps_is_raw (caps) && kms_utils_caps_is_video (caps)) {
     GstPad *sink = gst_element_get_static_pad (output_tee, "sink");
-    gst_pad_add_probe (sink,
-        GST_PAD_PROBE_TYPE_BUFFER | GST_PAD_PROBE_TYPE_BUFFER_LIST,
-        (GstPadProbeCallback) bitrate_calculation_probe, self, NULL);
+    // gst_pad_add_probe (sink,
+    //     GST_PAD_PROBE_TYPE_BUFFER | GST_PAD_PROBE_TYPE_BUFFER_LIST,
+    //     (GstPadProbeCallback) bitrate_calculation_probe, self, NULL);
     g_object_unref (sink);
   }

Of course, that is for an scenario where REMB (WebRTC congestion control) is not needed. However, maybe this probe is using more CPU than needed, or maybe we can reduce the frequency that this probe runs on without degradation on its effects, and save some CPU along the way.

Need to use Callgrind to inspect the actual resource usage of the probe.

[prlanzarin]

cc @mariogasparoni (the one who originally pinged me about it)