After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 765615 - Setting avdec_h264's (which is in a uridecodebin) parameter max-threads sometime been ignored
Setting avdec_h264's (which is in a uridecodebin) parameter max-threads somet...
Status: RESOLVED NOTABUG
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
1.6.2
Other Linux
: Normal major
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-04-26 14:36 UTC by AlexBolotsin
Modified: 2016-04-26 15:55 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description AlexBolotsin 2016-04-26 14:36:07 UTC
Hello.

I'm using urideocdebin and trying to set max-threads variable on avdec_h264. But sometimes after a bunch of restarts it spawns threads ignoring max-threads value. Especially it happens when a server has serious load - around 80%.

What should I do about it?

My pipeline looks like that:
        uridecodebin name=uridecodebin0
        souphttpsrc name=source
        typefind name=typefindelement0
        decodebin name=decodebin0
        typefind name=typefind
        hlsdemux name=hlsdemux0
        multiqueue name=multiqueue0
        tsdemux name=tsdemux0
        multiqueue name=multiqueue1
        h264parse name=h264parse0
        capsfilter name=capsfilter0
        aacparse name=aacparse0
        avdec_h264 name=avdec_h264-0
        avdec_aac name=avdec_aac0
   here uridecodebin ends
        videoconvert name=videoconvert0
        x264enc name=x264enc0
        audioconvert name=audioconvert0
        faac name=faac0
        flvmux name=flvmux0
        rtmpsink name=rtmpsink0

I'm setting max-threads in bus-watch-callback like this:

    static bool avdec_settings = false;
    if (!avdec_settings && args_has_argument(job->args, "avdec_h264.max-threads")) {
        GstElement* element = (GstElement*)GST_MESSAGE_SRC(message);
        if (element && GST_IS_ELEMENT(element)) {
            std::string factoryType = gst_plugin_feature_get_name(GST_PLUGIN_FEATURE
                (gst_element_get_factory(element)));
            if (factoryType == "avdec_h264") {
                avdec_settings = true;
                GstObject* avdec = GST_MESSAGE_SRC(message);
                int threads = args_to_int(args_get_value(job->args, "avdec_h264.max-threads"));
                g_object_set(avdec, "max-threads", threads, NULL);
            }
        }
    }

So what it does - waits for a avdec_h264 to appear in pipeline and sets it with value from arguments.

I have gst 1.6.2 running under ubuntu 14.04.3 lts.
Comment 1 Tim-Philipp Müller 2016-04-26 14:42:12 UTC
Is your callback a *sync* bus handler?
Comment 2 AlexBolotsin 2016-04-26 15:22:36 UTC
I'm not sure.

I do it like that:
    int bus_watch_id = gst_bus_add_watch(job->bus,
        (GstBusFunc) worker_bus_callback, (gpointer) job);
Comment 3 Tim-Philipp Müller 2016-04-26 15:35:21 UTC
This means you do it in the normal asynchronous bus watch which is called from your application thread.

This means that the avdec_h264 element in the streaming thread may already be up and running by the time you are processing that message, in which case the setting will not be effective.

For this particular use case you need to use a gst_bus_set_sync_handler(), but you should still process all other things in your normal existing bus watch.
Comment 4 AlexBolotsin 2016-04-26 15:55:42 UTC
You right. Setting gst_bus_set_sync_handler did the trick. Thx a lot.