'framerate' tracer doesn't produce any output in application

[Jabotical]

Gstshark is really neat, and has been useful in profiling some simple gst-launch-1.0 pipelines when we've been able to boil a situation down to its essence, and in those cases just about all of the tracers seem to function, including framerate

However, when running it in the context of an elaborate pipeline within our application, while some tracers (such as proctime) produce TRACE output and populate the datastream file, the framerate tracer doesn't output anything.

I've tried adding filters in case that might help by reducing the scope, but it doesn't make a difference.

Any thoughts on what we might be able to try, or should check?

I see this in the log, among the other tracer registrations: gsttracer.c:159:gst_tracer_register:<registry0> update existing feature 0x5610f7fcb580 (framerate)

And then this:

gsttracerrecord.c:109:gst_tracer_record_build_format: framerate.class, pad=(structure)"scope\,\ type\=\(type\)gchararray\,\ related-to\=\(GstTracerValueScope\)pad\;", fps=(structure)"value\,\ type\=\(type\)guint\,\ description\=\(string\)\"Frames\\\ per\\\ second\"\,\ flags\=\(GstTracerValueFlags\)GST_TRACER_VALUE_FLAGS_AGGREGATED\,\ min\=\(uint\)0\,\ max\=\(uint\)4294967295\;";
gsttracerrecord.c:123:gst_tracer_record_build_format: new format string: framerate, pad=(string)%s, fps=(uint)%u;

But that's about the only evidence of its existence (unlike when I include say proctime or cpuusage)

[DmitrySamoylov]

I faced the same issue yesterday.

Internally, framerate uses g_timeout_add_seconds which registers a periodically invoked callback. And this callback did not work until I created a separate thread that runs a main glib loop:

    let glib_main_loop = glib::MainLoop::new(None, false); // g_main_loop_new
    std::thread::spawn(move || glib_main_loop.run()); // g_main_loop_run

(I use GStreamer 1.16 on Ubuntu 20.04)

[Jabotical]

Ah, thank you! I'll give that a try.

I'm currently on GStreamer 1.22.3 on a variety of architectures, but this seems likely to apply regardless.

[Myralllka]

Hello! I have the same issue on BeagleBone® AI-64 with docker and Ubuntu 20.0.4, GStreamer 1.16.3 @Jabotical did it work for you?

[michaelgruner]

Hi all, the cause is exactly as pointed by @DmitrySamoylov . The periodic tracers (bitrate and framerate) use a timeout to print info periodically. These timeouts require a GMainLoop to be running in the application for them to work. As @DmitrySamoylov said, this main loop can be in a separate thread if you already have an alternative event handler.

[Jabotical]

It's been a while, but yes, I believe like Dmitry and Michael said, it worked to get the GMainLoop running in a separate thread.

[denoming]

Confirm, adding default Glib loop fixed the issue:

    auto thread = std::thread{[]() {
        const auto defaultLoop = Glib::MainLoop::create(false);
        defaultLoop->run();
    }};
    thread.detach();

Without it, following tracers will no work: framerate, cpuusage, bitrate.