search

teltek / Galicaster

The Galicaster Project is an open initiative to provide flexible, state-of-the-art solutions for recording educational multimedia contents like lectures and conferences
galicaster.teltek.es
Other
35 stars 31 forks source link

Galicaster does not free resources correctly after a recording #29

Open rubenrua opened 11 years ago

rubenrua commented 11 years ago

We have noticed this after discovering that the number of file descriptors open by Galicaster (in /proc/PID/fd) steadily grows with each recording.

rubenrua commented 11 years ago

The underlying problem is that some resources open by the recording pipeline are never freed. For instance, sockets created by alsasink stay there after the pipeline is closed. This behaviour cannot be reproduced in C, only using python. In [1] you can see the full code used in the tests.

After studying the problem, we have found the bug is in gst.parse_bin_from_description(). Examples:

Does not properly free its resources:

self.pipeline = gst.Pipeline()
aux = "audiotestsrc ! alsasink" 
self.bin = gst.parse_bin_from_description(aux, False)
self.pipeline.add(self.bin)

Frees resources properly:

self.pipeline = gst.Pipeline()
src = gst.element_factory_make('audiotestsrc')
sink = gst.element_factory_make('alsasink')   
mbin = gst.Bin()                              
mbin.add(src, sink)        
self.pipeline.add(mbin)    
src.link(sink)

Frees resources properly:

self.pipeline = gst.Pipeline()
aux = "(audiotestsrc ! alsasink)" 
self.bin = gst.parse_launch(aux)  
self.pipeline.add(self.bin)

We are using the last example as a workaround -- using gst.parse_launch and surrounding the description with brackets "()".

[1] https://gist.github.com/rubenrua/5046986

rubenrua commented 10 years ago

I reopen the issue because the problem is not fixed if you use a Blackmagic card.

See Christian Greweling email

rubenrua commented 10 years ago

The bug is not the same. Because it can be reproduced in C language [2]. I create a new issue #99

[2] https://gist.github.com/rubenrua/dde3276a341494b75115

Alfro commented 7 years ago

I am reopening this.

In GStreamer 1.0 we are always having this issue. Testing the python snippets above, all of them have this issue now. Also, the C script [2] does not fail either. We believe it has to do with the python bindings of GStreamer, and we have opened a bug [3] on bugzilla on the GStreamer tracker.

[2] https://gist.github.com/rubenrua/dde3276a341494b75115 [3] https://bugzilla.gnome.org/show_bug.cgi?id=782553

Alfro commented 7 years ago

We believe this is causing #387 Edit: It's not. See below:

Alfro commented 7 years ago

We have confirmed this issue does not cause #387

With the help of the GStreamer people, this issue was solved for the GStreamer master branch. In the task we opened, they confirmed the change fixing this would not be backported to the 1.12 release and earlier: https://bugzilla.gnome.org/show_bug.cgi?id=782553

Having this into account, we patched the gstreamer package (gir1.2-gstreamer-1.0) for the 1.8 version and uploaded the .deb to the galicaster repository. When we deal with #531 we may have to create a package for the 1.10 version as well.