1

I wrote a simple code based on gstreamer-1.0 to decode a certain file for loop using playbin, and each time the playbin created the element mpeg2dec element, the element has a new name. The name at the very first time could be "mepg2dec0", and then it will increase the suffix index to "mpeg2dec1", "mpeg2dec2", and so long, when the file is played again.

Here is some of code quotation:

do {
    playbin=gst_element_factory_make("playbin", "play");
    g_object_set(G_OBJECT(playbin), "uri", "file:///home/gst/Videos/1.ts", NULL);
    /* add message receivers ... */
    gst_element_set_state(GST_ELEMENT(playbin), GST_STATE_PAUSED);
    gst_element_set_state(GST_ELEMENT(playbin), GST_STATE_PLAY);
    /* wait until got EOS */
    gst_element_set_state(GST_ELEMENT(playbin), GST_STATE_PAUSED);
    gst_element_set_state(GST_ELEMENT(playbin), GST_STATE_NULL);
    gst_object_unref(GST_ELEMENT(playbin));
} while(1);

Does this suffix index increase mean a possible memory leak of elements not freed?

umläute
  • 28,885
  • 9
  • 68
  • 122
user1547688
  • 121
  • 1
  • 8

1 Answers1

0

the incrementing of the suffix mainly means that something keeps track of the current suffix.

this something could be, that gstreamer allocates all elements and maintains a list of them. when a new element is added, gstreamer could check the currently allocated element-names and generate a new one based on this knowledge (e.g. trying "mepg2dec0" as a name first, and if that is already taken, try "mepg2dec1" and so on, until it finds a free name).

however, this something could also be a single integer (per elementtype), that is monotonically increasing (no index reuse), whenever a new element is created (and completely ignoring whether and which elements are destroyed).

so to answer you question:

no, having a new name for each element is no indication of whether there is a memory leak or not.

umläute
  • 28,885
  • 9
  • 68
  • 122